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