Ok... so it's about done, but not quite :)
So lots of folks have expressed interest in being able to provision
hardware with Multiple NICs (for instance you might want to use cobbler
to manage DHCP for both of them), as well as create virtual machines
that way. For those that are so interested, read on. This is
describing how things work upstream now (in git) as I work on polishing
this up. I would not recommend trying the codebase at this point,
though it should be ready for experimentation soon enough.
It's going to work much like before. In the interest of readability,
I'm giving command line examples, though this will all work through the
Web UI also.
All the old commands and the old templates you have will still work.
Upgrades will be seamless also.
Here's how it works now:
cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF
[--ip=192.168.1.50] [--hostname=test12345.example.com] [--dhcp-tag=...]
[...]
If you want more NICs, it's:
cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF
[--ip=192.168.1.50] [--hostname=test12345.example.com]
[--mac1=...] [--ip1=...]
[--hostname1=...] [--dhcp-tag=...]
Koan looks the same, basically (for both Xen or KVM, depending on your
virt type setting in cobbler). Notice these are unchanged:
koan --server=cobbler.example.org --virt --profile=profileXYZ
koan --server=cobbler.example.org --virt --system=test1234
However, if you need to override the virtual bridge to be used, you can
only do so for --profile (not --system) in koan. (Also, for profiles,
the restriction is that you'll only get one NIC with a random MAC.
You can't get two.). This is so that we don't inflate koan with a lot
of options that duplicate things in Cobbler.
So, the virtualization provisioning by profile remains as:
koan --server=cobbler.example.org --virt --profile=profileXYZ
[--virt-bridge=mybridge0]
If you wanted to specify a cobbler system that used two seperate
bridges, you now have to do that in cobbler. If you don't define
them, cobbler will
need to try and guess, and most likely you do not want that... Besides,
with this much information it will be good to keep it all centrally:
cobbler system add --name=test1234 --mac=AA:BB:CC:DD:EE:FF
[--ip=192.168.1.50] [--hostname=test12345.example.com]
[--virt-bridge0=xenbr0]
[--mac1=...] [--ip1=...]
[--hostname1=...] [--virt-bridge1=xenbr1]
I'll make this much more clear on the Wiki as things go on. I don't
think it really complicates things in practice as if you don't want
multiple NICs for virtual machines,
this is all largely optional... and for those that do, the Web UI will
make it easy enough to understand. I wanted to bring this up now for
those that had an idea
how they thought multiple NICs might work from a user perspective to
speak up if this really wouldn't work for them.
Another topic -- Earlier there was the discussion of having overrides
for things like the virtual mac address in koan. Given the complexity
of all of the above, and wanting to keep things simple and centrally
managed, this is most likely not going to happen as it would
overcomplicate the model a bit too much. Again, these are things that
are easily
enough expressed in cobbler.
Right now we can override -virt-name, --virt-path, and --virt-type in
koan ... which will likely stay for now, though since they are all
settable in cobbler they may become
deprecated. - -virt-name can be controlled by creating a system object,
--virt-path can be set in profile and/or system objects, and --virt-type
can be set globally and in the various objects.
For hardcore templating users, variables like $mac_address can be used
for the first entry (backwards compatibility), though
$mac_address_intf1, and $mac_address_intf2 will also work. Or you'll be
able to walk the interfaces as they are exposed to templating as a hash.
If anyone is manually generating YAML to create Cobbler files, this does
imply a format change, so it would be a good time to switch over to the
cobbler API. (I know a few people are mapping Cobbler from LDAP this
way...which is not really a version-safe way to go).
Hopefully I did not confuse anyone too much by the above.
Again, the WUI code is not in git yet, and koan isn't completely tested,
but that is my best guess as to how the above will look at this point.
More info on the Wiki later.
--Michael
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
