[et-mgmt-tools] Cobbler and Koan for _my_ needs

[Michael DeHaan]

Matthias Saou wrote:
> Michael DeHaan wrote :
>
>   
>> Hmm, this looks like leftover bits from when the name had to be a MAC. 
>> Since the MAC
>> is a seperate field now, I'll see why it's not being used if it's provided.
>>
>> However, even so, you can still add the optional parameter --virt-name 
>> to name your guest.
>>
>> koan --virt --system=AA:BB:CC:DD:EE:FF --server=cobbler.example.org --virt-name=blinky
>>     
>
> Indeed, this is fine as a temporary workaround :-)
>
> FWIW, using koan --display seems to imply that the MAC address isn't
> getting sent by Cobbler.
>   
It is, it's just not being displayed :)
>   
>>> I don't want to override anything on the koan command line. I'm more
>>> than fine with having everything in Cobbler!
>>>
>>> But in my case, I'd need my profile to be :
>>> - virt_path: /dev/data/$name,/dev/data/swap$name
>>>   (I'm not sure if this can be done, I can live with overriding it in
>>>    all system configurations, which is what I've done for now)
>>> - virt_ram: 512
>>>   
>>>       
>> This would put them in two directories, which should be sufficient:
>>
>> --virt-path=/dev/data,/dev/data/swap/
>>     
>
> I'm actually using unpartitioned LVM volumes for my guests :-) So the
> above uses the pre-created /dev/data/test and /dev/data/swaptest LVs.
> My tests have shown better performance that with files.
>   

That works too. Specify two LVM volumes

It was too early for my brain to notice the "/dev" in your path, 
apparently :)

Names in LVM volumes are carved out based on the name of the virtual 
machine.

> I haven't tried not having the LVs pre-created and using
> "virt-path: '/dev/data/$name,/dev/data/swap$name'" with
> "virt_file_size: 4,2", but I suspect it won't work :-)
>
>   
>>> Then the default system associated to be :
>>> - virt_path: <<inherit>>
>>> - virt_ram: <<inherit>>
>>> ...where I only change the name, hostname and MAC address.
>>>
>>> Here I'd like to be able to change virt_ram on a per-system basis, but
>>> it doesn't seem possible currently (or maybe I just need to "manually"
>>> add it to the system file?).
>>>   
>>>       
>> It's not like we couldn't add it, it just seems to go against the design 
>> of having profiles
>> that define the requirements of what they are running. This is the same 
>> reason you
>> can't request more virtual disk for a specific system -- the idea is 
>> that you would
>> use inherited profiles to do this, and then just map the system to the 
>> profile that it
>> was going to be assigned to.
>>     
>
> This will basically add one layer of configuration for very little to
> no gain in my case. I can live with that and do understand that the
> line must be hard to draw between inherited profiles and systems.
>   
Kind of, yes. I'm trying to enforce the idiom of mapping systems to what 
they do.
It's an important abstraction if you want to avoid managing a very large 
pool of systems
with nothing in common, and especially important when you start scaling 
up into a very
large number of systems (say, thousands). It makes things both 
predictable and repeatable.

Inherited profiles are really there so that you can manage batches of 
profiles with some
things in common (for instance, all db servers), but you might want to 
inherit from that
profile to set settings that are site specific, or specific to a certain 
type of needy hardware.
This makes interchanging hardware repeatable, because you contain that 
information
in the profile, not in the individual (and non-reusable) system object.

> It does seem like the WebUI doesn't currently know of inherited
> profiles, though.
>   
You are too observant :)

This will likely come in a later release, when we figure out how to show
those relationships best. Not a ton of people use them and I didn't want 
to add the complexity early on.

> Thanks for all your help :-)
>   

No problem. Thanks for all the good feedback and info on your 
environment. It's useful
to hear from folks about this kind of thing.

> Matthias
>
>