koan is designed to deploy what is specified in Cobbler. It's
designed around centralized management.
fair enough - can i ask then what is the intended purpose of
"--profile=PROFILE cobbler profile to install" as that would do exactly
as i want but as you state it does not handle the IP issues i have
Alas things are not as simple as scripting a cobbler edit as once
deployed into the stack, these machines are basically application
stacks, then when and what they get rebuilt to is handled by another
process that is local to a box on the stack and so only has access to
koan. It seems to me that koan/cobbler has the info available to it,
ie kickstart_sys, however it seems to not make use of it?
That doesn't work because the kickstart_sys file without doing the
associated cobbler edit points to the /old/ cobbler profile, not the
new one. Once you issue the cobbler command to remap it, the kickstart
is then correct, and you can use koan with the --system flag (or leave
it off and let things be autodetected).
Really the easiest option here is to just use the profiles with
DHCP. Failing that, you should just issue the cobbler commands to
remap systems to new profiles.
for me dhcp in production is not really an option. i can get away with
it for bare metal but alas not for rebuilds
We're not going to do client-side templating of kickstart files in
koan because we already do that Cobbler side, and also because to
support older distros (EL3), we can't use the same templating
engine... which
adds way too much complexity, and it is also hard to explain why we'd
actually need that feature if we already have a cobbler command that
does the same thing :)
In conclusion ... (A) use profiles with DHCP, or (B) run cobbler edit
command before using koan. Those are the two suggestions.
thanks for your advice regarding this issue - i'll see what i can come
up with.
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools