Fedora server implementation straw man

Kevin Fenzi kevin at scrye.com
Mon Jan 27 18:33:30 UTC 2014

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,

  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. 

  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. 

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

  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.

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

  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). 

ok. Poke holes away. ;) 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140127/06f964e3/attachment.sig>

More information about the server mailing list