[et-mgmt-tools] Cobbler 0.3.4-1 comments

[Michael DeHaan]

Michael DeHaan wrote:
> David,
>
> Thanks for the feedback, a few comments below... I'll look into 
> incorporating some of this into 0.3.6.
>
> David Mackintosh wrote:
>> Hi there,
>>
>> I've just done a moderate sized cobbler installation (currently
>> twelve distros with more to come, eventually more than a hundred
>> systems) and have a few comments based on what I have seen so far. 
>> These are probably minor quibbles. 
>> This is installed from the 0.3.4-1.src.rpm
>> 1.  Cobbler doesn't appear to understand -v, -V, or --version
>>
>> ...which isn't entirely necessary if it is installed from rpm
>> (rpm -qa | grep cobbler gets me the info I needed) but it would
>> still be nice.
>>   
> That's valid, though I would hope everyone is always installing from 
> the RPM.
>> 2.  Brief output should at least be an option, if not a default.
>>
>> I want the equivilent of
>> # cobbler list --profiles | grep profile
>>
>> ...since the vast majority of the time I don't care about the details
>> of a profile, I only want to see the list of names because I have so
>> many of them I've forgotten what I called the one I want.  Yes this
>> is mostly my fault for frequently forgetting/changing my "standards"
>> but it would be nice if the tool could help.
>>   
> This would be a good add.
>> 3.  Semantically, since cobbler uses
>>
>> # cobbler system add [...]
>>
>> ...cobbler should therefore understand
>>
>> # cobbler system list
>>
>> ...instead of requiring
>>
>> # cobbler list --systems
>>
>> I have nothing against the latter, but the former fits more
>> semantically into the COMMAND OBJECT ACTION model I like to use. 
>> Perhaps this form of the command would be a good place to put the
>> brief output.    
> I find myself typing the same things occasionally and wondering why I 
> didn't do it that way :)
>
> Perhaps "cobbler system list" and "cobbler system list --full".
>
>> Or maybe you want to change the other commands to the form
>>
>> # cobbler add --system
>>
>> ...but either way it should be more consistant.
>>
>> 4.  Sorted output would be nice.
>>
>> The output of the various lists are not sorted by either order-added
>> or some kind of alpha-numerical sort; either would be adequate, and
>> the latter obviously preferred.
>>   
> This makes good sense and is an easy fix.
>> One could even argue that since the "index" of a profile/distro/name
>> which preceeds the name will probably change as other things are
>> added and removed, and are not used anywhere (ie you can't refer to a
>> profile as "profile #3" anywhere) it should be dropped entirely from
>> the output.    
> True.
>> 5.  Unless I misunderstand something, if I define my profiles with
>>     URLs to ks.cfg files instead of file references, there is nothing
>>     served through httpd by cobbler.  In this case it would be nice
>>     if cobbler didn't restart my httpd every time I ran cobbler sync.
>>   
> Yes and no.   The restart /is/ unneccessary.   As to why the web 
> directory is there, cobbler's web directory is also used to serve up 
> configuration files for koan as well as to mirror kickstart trees and 
> (in 0.3.5) yum repositories.    Adding some logic to know when a 
> restart is required does make sense, though.   Basically once cobbler 
> is used beyond minimal PXE support, the web directory starts to grow 
> increasingly important.  
>> 6.  If manage_dhcp is set to 0, cobbler check should not complain
>>     about missing dhcpd pieces.In my case dhcpd is on another system 
>> under another set of script'scontrol, so cobbler needn't be bothered 
>> about those details.  Maybe an option to tell it not to warn about 
>> those kinds of things would
>> be in order (squelch_dhcp_warnings or something).
>>
>> END COMMENTS
>>
>>   
> Cobbler check is there for people who really don't know what setting 
> up a PXE environment entails (i.e. whether or not they set up 
> next-server or not), and can use those pointers.   Those that 
> understand the warnings should be able to know when they don't 
> apply.    They do apply when manage_dhcp is not set and the user is 
> running a local DHCP server.  This should probably stay as is, though 
> if the warnings are confusing, they definitely should be amended, and 
> I could use some suggestions as to how they were confusing and what 
> you think they ought to say instead.
>
>> All that said, these are exceedingly minor quibbles.  Cobbler has
>> already saved me a ton of time and made me look good in front of two
>> moderately-sized customers (always a plus). 
>> I do have a question about the implementation -- is there anything
>> that would prevent cobbler from running on, say, a Solaris system?  I
>> ask because I already have a fairly extensive host-management system
>> set up that runs on Solaris, and it would be reasonably
>> straight-forward to integrate cobbler into it so that a user could
>> say
>> # need_shoes --system="text-name" --profile="profile-name"
>>
>> (ie need_shoes asks the cobbler for boots, or maybe you'd name it after
>> a shoe vendor or something... to beat a naming convention to death :)
>>
>> ...and have that script dig the IP address and MAC out of NIS, doctor
>> dhcpd (if necessary -- I'm already doing much of that, which is why in
>> my past comments I was resistant to cobbler doing it as well), and
>> do the final "cobbler sync" automatically, making it a one-stop for
>> my administrators.
>>   
> Cobbler's rather RHEL/Fedora/Centos centric at this point, and I 
> really don't intend on changing that.  Namely it knows
> the job it needs to do and wants to do that job well. 
> I _do_ think it is reasonable to be able to provision other forms of 
> targets, similarly to the steps cobbler already takes to allow PXE 
> provisioning of IA64
> Linux systems (which require different bootloader configuration 
> files).   So if it's just something that involves some minor support 
> in action_sync.py to build a slightly different bootloader config, 
> that might be a good patch candidate.
>
>
>> A second question -- while thinking about #5 above, it occured to me
>> that I don't immediately understand why cobbler copies the vmlinuz
>> and initrd.img files into the httpd tree.  Why do you do that?
>>   
> It's all about koan.   Koan allows for provisioning of remote systems 
> when a PXE environment is not available.
>
> For instance:
>
> "yum install koan"
> "koan --replace-self --server=cobbler.example.com --profile=fc6test"
> /sbin/reboot
>
> Koan also does virtual image installs (currently it only supports Xen, 
> though this will probably expand later):
>
> "yum install koan"
> "koan --virt --server=cobbler.example.com --profile=myvirtualwebserver"
>
>
>> Thanks again for cobbler.
>>
>>   
> You're welcome!  Thanks again for the comments!
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> et-mgmt-tools mailing list
>> et-mgmt-tools at redhat.com
>> https://www.redhat.com/mailman/listinfo/et-mgmt-tools
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools

Incidentally, I've added the following features today, since they were 
such good ideas for usability improvements.   I'll wait awhile on the 
official release as 0.3.5 is just out, and I want to give folks a chance 
to play with the repository features.

The list of newness:

cobbler list now just list the names of the various items, so it's 
easier to read and find the name of a profile you might want to use.
cobbler report now does what "cobbler list" used to do, that is, output 
a ton of information
cobbler <object> list works, as does "cobbler <object> report", this 
conforms to the subject verb form that is used for most other commands
cobbler list and report are now sorted by name
"cobbler repo sync" does the same as "cobbler reposync" (again, subject 
verb compliance), not to be confused with just plain "cobbler sync"
Apache is only restarted when it needs to be (i.e. the config needs to 
be changed)