policy for systemd preset files for spins?

[Matthew Miller]

See this ticket:

https://fedorahosted.org/fesco/ticket/945


  A spin preset (or whatever they're called) sounds like a reasonable idea.
  We seem to have procedures and guidelines for distro-wide defaults now
  (file bugs against systemd); do we have anything for presets that are
  local to spins (e.g. what numeric precedence they get, what they're
  called, etc.)? If not, what needs to happen to create them?

  ...

  This should be discussed, and a proposal brought forward. 

  ----

  For background, this feature:
  http://fedoraproject.org/wiki/Features/PackagePresets

  We want something like 80-fedora-cloud.preset, but how do we ensure that
  '80' is the right number, and that it's okay to use "fedora-cloud"
as the
  name?

  And, where should the contents of this file be stored and developed?

  The argument for not having cloud-init on by default seems to apply
  equally well to any "fedora-cloud-release" rpm containing a preset which
  activates that package — all we've done is added a layer of complication
  for the same result (install a package, get services activated).

  On the other hand, if we develop and distribute outside of RPM, how do we
  make it easy for people doing their own custom cloud images to get it?

Any opinions? Does the SIG want to maintain a registry? First come, first
serve? 

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Bruno Wolff III]

On Mon, Oct 08, 2012 at 15:10:12 -0400,
   Matthew Miller <mattdm(a)fedoraproject.org&gt; wrote:
>   We want something like 80-fedora-cloud.preset, but how do we ensure that
>   '80' is the right number, and that it's okay to use "fedora-cloud"
> as the
>   name?
>
>   And, where should the contents of this file be stored and developed? 
Right now one would probably do this in %post. In an image installed from 
this live is supposed to keep the preset, then you'd copy it to the 
appropriate space in the file system. You can also do the copy in the 
livesys service, so that it only is there on the live image.

In the future were installing from live images isn't a copy, then things 
will need to change.

If you are installing these outside of a package (such as in %post) then 
they should go in /etc/systemd/system-preset/ .

[Matthew Miller]

On Tue, Oct 09, 2012 at 11:21:57AM -0500, Bruno Wolff III wrote:
>  > We want something like 80-fedora-cloud.preset, but how do we
> ensure that
>  > '80' is the right number, and that it's okay to use
> "fedora-cloud" as the
>  > name?
>  >
>  > And, where should the contents of this file be stored and developed?
>
>  Right now one would probably do this in %post. In an image installed
>  from this live is supposed to keep the preset, then you'd copy it to 
Is there a repository of %post snippets that we recommend?


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Bill Nottingham]

Matthew Miller (mattdm(a)fedoraproject.org) said: 
>  See this ticket:
>  
>  https://fedorahosted.org/fesco/ticket/945
>  
>  
>    A spin preset (or whatever they're called) sounds like a reasonable idea.
>    We seem to have procedures and guidelines for distro-wide defaults now
>    (file bugs against systemd); do we have anything for presets that are
>    local to spins (e.g. what numeric precedence they get, what they're
>    called, etc.)? If not, what needs to happen to create them?
>  
>    ...
>  
>    This should be discussed, and a proposal brought forward.  
You'd theoretically want it to take effect when creating the live image,
which implies in the spin-kickstart's file's %pre. That's a glorious hack,
however.

A cleaner way to do it is to *package* it in in a spin specific package that
gets pulled in by the appropriate spin early in the transaction so it's
there for all services. So, for example, fedora-release requires:

spin-preset

and you have a myspin-release package that provides:

spin-preset.

And you then have some generic-preset package for the DVD install.

Of course, this is back-of-the-envelope design one drink into the evening -
I'm open to better ideas.

Bill

[Matthew Miller]

On Tue, Oct 09, 2012 at 10:23:05PM -0400, Bill Nottingham wrote:
>  A cleaner way to do it is to *package* it in in a spin specific
> package that
>  gets pulled in by the appropriate spin early in the transaction so it's
>  there for all services. So, for example, fedora-release requires: 
Right, so, the problem is: the reason we're doing all this is so that cloud
init won't default to on-when-installed, so that if people install it by
accident, they won't accidentally get... cloudinited.

But if we have a cloud-preset package that turns on cloud-init when
installed, we've just moved the problem up one layer of abstraction with no
particular gain that I can see, unless you value obfuscation for its own
sake. :)

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Bill Nottingham]

Matthew Miller (mattdm(a)fedoraproject.org) said: 
>  On Tue, Oct 09, 2012 at 10:23:05PM -0400, Bill Nottingham wrote:
>  > A cleaner way to do it is to *package* it in in a spin specific package that
>  > gets pulled in by the appropriate spin early in the transaction so it's
>  > there for all services. So, for example, fedora-release requires:
>  
>  Right, so, the problem is: the reason we're doing all this is so that cloud
>  init won't default to on-when-installed, so that if people install it by
>  accident, they won't accidentally get... cloudinited.
>  
>  But if we have a cloud-preset package that turns on cloud-init when
>  installed, we've just moved the problem up one layer of abstraction with no
>  particular gain that I can see, unless you value obfuscation for its own
>  sake. :) 
The idea is that the cloud-preset package would only be on the cloud spins.

If you're installing random preset files from the repo, or, god forbid,
*everything* including conflicting presets, you get to step on all the sharp
pieces, and I hope you're up-to-date on your shots.

Bill

[Matthew Miller]

On Tue, Oct 09, 2012 at 10:48:25PM -0400, Bill Nottingham wrote:
>  The idea is that the cloud-preset package would only be on the cloud
> spins. 
Well that's also true for the cloud-init package itself. If we can say
"don't do that" for preset files, why can't we say "don't do
that" for
cloud-init?

-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;

[Bill Nottingham]

Matthew Miller (mattdm(a)fedoraproject.org) said: 
>  On Tue, Oct 09, 2012 at 10:48:25PM -0400, Bill Nottingham wrote:
>  > The idea is that the cloud-preset package would only be on the cloud spins.
>  
>  Well that's also true for the cloud-init package itself. If we can say
>  "don't do that" for preset files, why can't we say "don't do
> that" for
>  cloud-init? 
A preset file is a definition of "I want this system to be a $FOO". A
package install is just "I want to have $BAR installed". The idea is to try
and separate policy from code.

Bill

[Matthew Miller]

On Tue, Oct 09, 2012 at 11:15:47PM -0400, Bill Nottingham wrote:
>  > > The idea is that the cloud-preset package would only be on
> the cloud spins.
>  > Well that's also true for the cloud-init package itself. If we can say
>  > "don't do that" for preset files, why can't we say "don't
> do that" for
>  > cloud-init?
>  A preset file is a definition of "I want this system to be a $FOO". A
>  package install is just "I want to have $BAR installed". The idea is to try
>  and separate policy from code. 
Okay, I can buy that.


-- 
Matthew Miller  ☁☁☁  Fedora Cloud Architect  ☁☁☁  <mattdm(a)fedoraproject.org&gt;