Fedora server implementation straw man

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/27/2014 01:33 PM, Kevin Fenzi wrote:
> ok, so I figure I will see if I can't get some discussion going on 
> implementation plans. Here's a straw man proposal for everyone to
> knock holes in and propose better ways to do our implementation. ;)
> 
> 
> * Our deliverable will be a iso image similar to the current
> netinstall iso image. It will be that + all packages needed to
> install/deploy our featured roles and base things they need. This
> will allow installing from the net or using the iso stand alone to
> install server roles.
> 
> * We add comps groups for each featured server role we support. So,
> for example: 'server-freeipa'. This comps group has all the
> packages listed we want to install to setup the role as we
> determine is best. This may include packages that are not direct
> dependencies on the server pacakges.
> 
> * The roles use cockpit to manage and configure the server role
> post install. If there's a way (not sure if there is), we could
> look at adding a anaconda 'spoke' for the server install that runs
> this at install time for folks that want to configure then? Or on
> firstboot.
> 
> * We create a new fedora-server-$role package for each role. This
> role package contains the 'glue' we add to turn this into a fedora
> server role from just a install with the packages and local config.
> We will need to come up with guidelines and what these packages
> will contain, but:

Ok, so aside from the monitoring/backup stuff you list below, the
primary purpose of this role package is to drop whatever is needed on
the system in order to produce the API that Cockpit will consume to
set up the configuration? (Or, in the more rare cases where a
reasonable default exists, drop that default on the system and go)?


> 
> 1 A way to express what items should be monitored when the role is 
> installed/running. Perhaps /etc/server/$role/monitoring/ports and 
> processes and such.
> 

We really need to come up with a clearer definition of "monitor" here.
What exactly does /etc/server/$role/monitoring/ports mean? Just a set
of ports that have to be accessible publicly for it to be considered
working? I assume we'd also be including firewalld configuration as
part of the role API so that we can handle that properly.


> 2 A way to express data that should be backed up if you want to 
> backup the role. Perhaps /etc/server/$role/backups/datadirs and 
> configdirs or databases.
> 
> 3. We may want to change systemd presets to indicate things that 
> should be running/enabled/etc when the role package is installed.
> 

As mentioned above, this should generally be done when Cockpit (or
other management tool) *deploys* the role. It should only be done by
the package if it meets the "may be packaged in such a way that it can
be uninstalled as a complete unit" Conditional Requirement[1]


> 4. Anything else we need to impement an "API" for roles. Are we
> going to define this soon?
> 


Yes, we need to have a breakout session somewhere to start working
this out. My suggestion would be for us to standardize on something
that is already available on the system (to avoid growing new
dependencies). My suggestion would be for us to build a D-BUS service,
since that will be easily consumed by Cockpit, OpenLMI and many languages.


> 5. We can tie this package to specific versions of requirements.
> So, for example, if there's a new freeipa update and we haven't
> valided fedora-server-freeipa with it, the requirement can be on
> the older version and the users will not be updated until we push
> an update to this package.
> 

I'm going to suggest that *can* has to be *must* (within a certain
reasonable level). I.e. we should probably allow the release number to
change without forcing the role package to be regenerated.

E.g.
Requires mydep >= 1.2.2
Conflicts mydep >= 1.3

as opposed to:
Requires mydep == 1.2.2-1


> 6. We setup specific bodhi requirements (like critpath) for server 
> role packages, requiring specific testing before they can go
> stable.
> 

I'd *really* like for us to be testing things holistically, rather
than individually. It's probably not enough for us to just check "Is
this in a role package? Yes: require more testing".

I think it's fine for the individual *packages* to continue in the
process that they are now. However, in order to bring something into
the *role*, we should have to test it as a complete system.

This has impact on Fedora Infrastructure, as it will mean that we will
need to retain multiple (non-parallel-installable) versions of
packages in the repositories, since we will always need to be able to
satisfy the role requirements (which may be older than the upstream
package).

Now, I'd be in favor of implementing something like the CRITPATH
process (possibly even the old style, requiring a proventester) for
updating the role package alone. There are two reasons for this:

1) Having the role package installed is a pretty clear indication that
you are actually trying to use the role holistically.
2) It encourages a more comprehensive set of system tests as opposed
to package tests (since people will be testing how the role works,
specifically.


> 7. We may have a fedora-server-base or fedora-server-common
> package to contain common/base stuff all roles need/user and make
> the role packages require it. We would need to be very careful
> about updates of this however.
> 
> * Users can install fedora-server-freeipa via yum/dnf after the
> fact, or via the iso image/anaconda.
> 
> * Users can decide they don't care about our valueadding/glue and 
> remove fedora-server-freeipa and it will just go back to a machine 
> with all those packages installed (ie, uninstalling shouldnt 
> hopefully do anything other than allow them to remove required 
> packages and ignore our old glue).
> 

It's off-topic, but I would like to see us also build a
fedora-server-release package that does much the same: allows us to
identify the minimum set of stuff that we call "Fedora Server" and if
you want to remove some pieces of it, you can... but you're no longer
building atop our tested platform.


> ok. Poke holes away. ;)
> 
> kevin
> 


[1]
https://fedoraproject.org/wiki/Server/Product_Requirements_Document#Conditional_Requirements
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLms34ACgkQeiVVYja6o6NmzACgqAC/lreABLsGeP1iEUX4KOdW
7nYAnA0Ng54vK3w6CatJBthmpz7lvbPh
=j2BK
-----END PGP SIGNATURE-----