Greetings,
In addition to the problems creating or editing profiles through the web, but not sub-profiles, I found another problem. However, this time the problem is with sub-profiles. Specifically, the values for distro and distro-name are "~" instead of the values which should be inherited from the parent. This in turn is causing problems in koan's get_distro_files() routine, as it builds URIs for the kernel and initrd around line 1017 (in head).
For reference, I am attaching both the reports and dumpvars output for a profile and a sub-profile.
I will also add that this whole deal with profiles and sub-profiles is a major pain for me right now. Depending on how much time I have, I may see what I can do to fix this problem (if somebody has not already), but it is almost easier for me to drop back to 1.6.6 and hack in the support for FC12 at this point.
- Doug
Greetings everyone,
Having some time after being laid off on Wednesday, I was starting to look at the problem with sub-profiles not inheriting the distro and distro-name from the parent profile. While doing so, I was in areas which started me looking at the distros and images in more detail, since I have had a need for things such as entries for NetBSD based systems, system routers, etc.
After looking at this, the following items occurred to me:
1) There is really no way to define a "system" which does not have provisions for booting from either an image or distro/profile.
2) If going the profile route for a system, the model is still very biased towards the model where you have an kernel and initrd, along with the distros/repos more fitting the RH/Fedora/Centos model (I cannot speak to Suse, Debian, Ubuntu quite yet).
3) In thinking about it, even images need the ability to be wrapped by profiles.
Now, while I realize cobbler is intended for installing systems, because it often manages DHCP and DNS entries, it occurs to me that there should be provisions for adding entries for things such as routers, switches, CRACs, sensors, etc. At the lab where I was working, we had around 700 physical servers and roughly 200 additional pieces of equipment. Some of the latter would never boot from the network, and may or may not support upgrading via image uploads via TFTP. Others would load their images directly via TFTP, and not use PXE for the loading. But with few exceptions, many would be getting their network configuration via DHCP.
At this point, it occurred to me that we need some combination of breed/OS Version/architecture which allows us to define these entries, be it through the image or distro/profile route. With this, we could have:
a) A distro with a breed of "redhat" with any version requires a kernel/initrd. b) A distro with a combination which requires a kernel, but no initrd.
or... the magic
c) A distro with a combination which does not network boot, but only defines the system for DHCP/DNS (say "other"/"noboot"). d) A distro with a combination which has some image which boots differently, such as being downloaded directly from TFTP.
This means that images could effectively become nearly the same as a distro or distro+profile. And based on this, other decisions could be made, such as how to pass along information like kickstart files (or the OS equivilent). Or whether or not an initrd is truely needed for a distro.
As for why one might want to have a profile wrapped around an image. Right now, say I want to do installs of NetBSD, using a version modified to do an install driven using a file it retrieves. But using the same image, I want to have installs for fileservers, workstations, etc., just as I do with redhat based systems with kickstart.
So, with all this, I am wondering what folks think of this. Is it worth discussing further?
- Doug
One other thing I noticed while working on my previous message. While comparing the definition for distros and images, I found that the order of the fields was inconsistent between them. I have reordered the fields defined in item_image.py to match more closely those in a distro, but there are still two issues I am wondering how to fix. They include:
1) The "Image Type" really looks like it should be rendered as a "Select", but it is being rendered as a text field. 2) The "Virt NICs" field really should have the variable named something like "virt_network_count", but that means that the variable in previously defined images needs to be renamed.
I have not yet had a chance to dig up how to fix either of these yet, but here are the patches I have so far... (which also makes spacing and the use of single vs. double quotes more consistent with the same definitions in item_distro.py).
- Doug
cobbler-devel@lists.fedorahosted.org