Fedora server implementation straw man

[Shawn Starr]

On January 27, 2014 09:06:31 PM Matthew Miller wrote:
> On Mon, Jan 27, 2014 at 11:33:30AM -0700, Kevin Fenzi wrote:
> > * 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.
> 
> As I understand it, yes, that could be a thing. Possibly even a new "hub",
> with spokes for each selected server role, if chosing more than one is a
> supported configuration. Bonus: the same code can be used in firstboot, so
> you can easily develop both or either options.
> 
> More here:
> 
> http://vpodzime.fedorapeople.org/anaconda-addon-development-guide

Hello folks,

I previously worked with Red Hat on their Red Hat HPC Solution (our original Fork/redo of 
NPACI Rocks which was.. difficult). It's discontinued now.

We had the concept of kits to do metapackages. I have the last CVS snapshot code available 
for people to examine. I will have to mirror it somewhere as my laptop as a VM/web server 
can only handle so much bandwidth :)

The concept was this:

kit-something ---> pulls in:  kit-client-configs / kit-server-configs <--- pulls in RPM 
dependencies for packages. Kits == Roles basically.

Now, we didn't have comps.xml to work with but we could maybe do something like: We 
have a roles.xml which maps to comps.xml groups.

So, then "Fedora Server Role" maps to X groups in comps.xml which pulls in the direct RPM 
dependencies.

The "Fedora Server Role" RPM/whatever can have then its own "turn key" configuration 
template/setup files for the groups it pulls in to configure them out-of-the-box.

so:

role-something ---> pulls in: role-client-configs / role-server-configs <--- pulls in comps.xml 
group package RPM dependencies as part of each grouping

That way, we dont break existing users where a Desktop also contains server configurations 
(comps.xml -> RPM dependencies only) and we gain the ability to have a higher-level 
grouping which adds on turn-key meta configurations that are *optional*.

So its a one way-dependency mapping and both use cases win!

Thoughts?

Thanks,
Shawn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/server/attachments/20140127/764aff13/attachment-0001.html>