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