[et-mgmt-tools] Cobbler patch OMAPI v2 ;)

[Michael DeHaan]

Pablo Iranzo Gómez wrote:
> 	Morning!
>
> El mar, 29-04-2008 a las 22:27 -0400, Michael DeHaan escribió:
>   

Applied to devel branch.    As with John's patch, I'm going to be 
working on moving this around
into the 'modules' directory, though this is very good to see.   Thanks!

--Michael

>> Should be applied Thursday or so barring any other comments, and that 
>> will make this easier for people to test.   I also need to do a test 
>> release for 0.9 soon (let's call this 0.9.1 ... there will be more test 
>> releases with some other features likely being added prior to the 1.0).
>>     
>
> 	Count with me for the beta-testing :)
>
>
>   
>> Quick question -- Should omapi in settings be off by default?  It only 
>> works with modifications to the dhcp.template to enable it -- though we 
>> /could/ enable that by default in the template and solve the problem.
>>     
>
> 	For me, as cobbler is rewriting dhcp info, should be enabled by
> default. This could need another check for the code I submitted
> yesterday to check if "manage dhcp is enabled for isc".
>
> 	For example, in trigger, the code is:
>
>      if manage_dhcp_mode == "isc":
>         if not omapi:
>           if not omapi_port:
>             rc = os.system("/sbin/service dhcpd restart")
>
> 	So, if manage mode is "ISC", and omapi is not enabled nor omapi_port,
> then it does a restart. 
>
> 	I don't think that this could hurt anyone if already using Cobbler for
> managing DHCP, if not, system will just do the other tasks, but nothing
> about DHCP
>
>   
>> Comments from folks who use Cobbler for DHCP management?
>>
>> The main goal of this is to keep DHCP running throughout sync operations 
>> -- but also to allow for less reasons to ever need to do "sync".  Since 
>> kickstart generation is now dynamic in 0.9/1.0, the only real reason to 
>> run sync is to rebuild some of the tftpboot tree, the rest of the 
>> "partial" data gets built each time you make a change to the associated 
>> objects (and all descendents automatically update).  
>>     
>
>
> 	Well, regarding this, right now I had to put the new stanza for
> cleaning leases just in case of machines removal. The best thing will be
> to put the code in "cobbler system add" "cobbler system remove" and
> "cobbler system rename" in order to just make this calls when needed,
> remmoving the need for the "leases-cleanup code", as the systems will
> get created on DHCP or removed dinamically.
>
>   
>> We can probably even make that less important as time goes on, by 
>> knowing basic things like if we add a profile, we can also quickly 
>> rebuild the pxemenus (since the number of profiles is going to be very 
>> small, etc).
>>     
>
> 	That would be a good point, in this way, cobbler state could just use
> "sync" for forcing a full cobbler files recreation just to be sure,
> remove possible problems, as all the other operations would get
> inmediate action on system .
>
> 	Regards
> 	Pablo
>
> PD: Attached patch adds an extra check to the DHCP leases cleanup code
> to check if we're doing ISC
>
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> et-mgmt-tools mailing list
> et-mgmt-tools at redhat.com
> https://www.redhat.com/mailman/listinfo/et-mgmt-tools