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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
_______________________________________________
et-mgmt-tools mailing list
et-mgmt-tools@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/et-mgmt-tools
