>> So, in this case I dont think I want to create a system
object. The
>> virt-image data defines that "This image requires N network interfaces"
>> it is at provisioning time this is turned into bridges, or direct
>> connections. I would like to be able to deinf the number of nics in in
>> the CobblerImage type.
>>
>>
> Well, you don't know what to do with respect to the configuration of
> those nics, in that case, you'd only know how many there were.
>
Yes, that would be ideal. Then.. allow the user to define this on the
command line. Would you be willing to add this bit of metadata to the
image object?
Yes, this sounds reasonable.
--required-interfaces=N, default=1 ?
> If you were to assign a mac address, you would have to create the
system
> object.
>
> So, in this case, the record of the image that acts as the clonable
> source is just an image record, but each /installation/ of that image
> would need a new corresponding system record in order to assign (and
> know) the MAC address of the NICs.
>
> Since that is required to get the IP's reserved and DNS going, system
> records are unavoidable.
>
> If you're just using the appliance for ISV demoware, sure, but otherwise
> you need to know (and therefore store in cobbler) all of that
> information. Since Cobbler is in play, were are talking about datacenter
> deployment, and not the demo case.
>
> Given, pending features such as the "auto assign interfaces from network
> object" feature we've been talking about for some time, as well as being
> able to auto-assign MAC addresses from a free pool will, in the future,
> substantially reduce the amount of information you need to feed in to
> get this working.
>
> Currently virtual koan per-profile installations get 1 NIC, if you want
> more, you have to use system objects.
>
Can you explain again how systems and images intersect?
There are two object chains possible in Cobbler:
distro -> profile -> system
image -> system
Basically a system is binding of another cobbler object to a specific
hardware, with additional customizations applied on top.
(Profiles can also have "repos" which are the last object type. Images
do not have repos).
>>>> 4) Virt-image supports defining pygub with a kernel
and initrd. There is
>>>> no way to model this in the image data
>>>>
>>>>
>>>>
>>> I'm not sure I understand why virt-image would want to do this. It seems
>>> like it would rather want to boot off the disk images and we'd use
>>> regular koan (as before) to do kernel+initrd installs.
>>>
>>> I assume this /might/ be for replacing the kernel+initrd before booting
>>> the image though this seems to be a slightly weird use case because it
>>> doesn't treat the virtual system like a physical system -- you could
>>> also just yum update the kernel, no?
>>>
>>>
>> Again, the virt-image data lets me bundle this as a transportable item.
>> If the goal is to push the image data into cobbler, and hten back out, I
>> would need a place to store this.
>>
>>
>>
> I need to understand the use case here. Perhaps this feature could just
> not be supported? If we are talking about a workflow that is:
>
> (A) install a virt image however and customize it
> (B) copy it into cobbler using the appliance tools for mass-cloning
> (C) use koan to mass-clone it
>
> It doesn't seem like there is a need to keep the kernel/initrd outside
> when they are already in the disk image. Pygrub is a Xen paravirt thing,
> sure, but in that case it dives inside the image to get the
> kernel+initrd out, so you wouldn't have to track it seperately. No?
>
>
The use case which I was assuming was the following:
(I) I have a an appliance bundle. Defined as a virt-image.xml file and
1-n disks. This is an output of the appliance-creator, virt-converter,
or some other means.
(II) I install it to cobber for mass cloning. This represents all
necessary virt-image.xml data as cobbler metadata.
(III) use koan to mass clone it.
The issue is that the appliance bundler supports 2 different modesl. One
is a HVM model where the kernel and initrd are in the image. The second
is a PV model where the kernel and inird are external to the image (but
in the bundle). I currently have no way to model the second type in the
cobbler metadata.
For traditional paravirt, the kernel and initrd are in the disk image,
pygrub just rips them out, but they are transported
with the image. So I don't see why this needs to be tracked, you can say
"uses pygrub", but you don't need the kernel+initrd
outside the image because pygrub takes care of that, right?
One last thing, can you take a peek at the latest version at [1]? It
implements most of what we discussed except for the the multiple files.
Since the virt-install libraries are an abstraction layer themselves, I
would like to know the user provided virt-type in order to use the
correct connection. Would you have an issue with adding this to the
start_install API?
Ok, it's n my list after I get some patches merged and finish
implementing a few rounds of XMLRPC tests to help out the Spacewalk effort.
That API addition sounds fine to me.
-- bk
[1]
http://github.com/bkearney/koan/tree/devel
_______________________________________________
cobbler mailing list
cobbler(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/cobbler