On 04/12/11 - 06:32:26PM, Jeff VanDellen wrote:
Thanks! I've read through the majority of the documentation. I see that oz has a flag to pass a kickstart file to an install, but I didn't see any more docs that go into more detail. I would love to get involved, and I do write really good documentation and would be willing to help as much as time allows. Additionally, I would really like to get StormOnDemand added as a cloud provider in the image factory project.
Excellent, would love the help.
I'm not entirely sure where to start, so I'll give an overview of the ideas behind Oz. You can ask questions where appropriate, and maybe we can get closer to what your questions are.
The premise behind Oz is that the user should not have to enter in very many details in order to get an install going. Right now, the only information Oz requires is the type of OS (Fedora, RHEL, Windows, etc), the architecture, the "Release" (Windows 2003, Fedora 14, etc), and the path to the ISO to do installation. Oz has built-in knowledge of everything else it needs, including automatic installation files (kickstart, autoattend, etc). Given the above information, Oz knows how to setup the install CD for a totally unattended install, launch the install, and finish it off.
That being said, there are places that the user can override Oz's default. One of these places is by passing in an alternate auto install config file (for instance, a custom kickstart file). This can be useful for just using the Oz infrastructure with your custom kickstart.
That being said, we really want to have a more formal way to change some installation-time parameters from within the Oz TDL. For instance, every single OS that we've run across so far has the ability to set the root/Administrator password during install, so we should probably have a <rootpw> element in the TDL that allows the user to specify this. In this same vein every OS allows you to specify custom partitioning schemes, so we should probably have a way to let the user specify those in the TDL.
Hopefully this is a good overview. Let me know where your specific questions are.
Currently the storm api is in beta and there is not currently a method for users to upload custom images, but I would like to know more details on steps required to make that possible, what are the requirements on our side and your side. And of course I would like to help in anyway possible.
Justin Clift's mail responds to this part pretty well, so I'll let that conversation take its own course.