Hi Dave and Ethan,
A roll-up of an IRC conversation Dave and I had has brought some
new ideas out but still shows there's much to think about for 4566:
ClayB: I have a further question about 4655 if you have another second?
dminer: ok
ClayB: I'm wondering about the backward compatibility path for
delete-service/delete-client even if the macros are split up. Would
searching for service specific keys and removing only those be
reasonable?
ClayB: Or would you see a migration script being better (though
that could really munge things too if there's something unexpected)
dminer: I'm not sure what the client macro would be useful for
once those are removed
ClayB: Well if it's empty we could go ahead and remove it but I
was thinking the assumption was router, netmask, DNSsrv etc might
be assigned there
dminer: the difficult line here is ensuring that we clean up
only when the user really wants/expects us to
dminer: i'd be more inclined to have the user declare intent,
either to keep or delete the macro, than to try to parse it finely
ClayB: We could set the assumption that we're removing and warn
on only cleaning up. Thus the expectation is that we're as
destructive as possible. An interesting approach to avoiding users
saying, "Hey that removed stuff I didn't think it would"
ClayB: Cool, that'd be easily possible to have it as another
option for delete-client. It seems delete-service shouldn't leave
dangling stuff though?
ClayB: I.e. a delete-service is one way to ensure machines
won't be booting back after install. And if left, a bootfile record
to nowhere will cause PXE to burp or DHCP administrators to scratch
their head (if they're expecting a higher up macro to define the
bootfile)
dminer: i think we need to decide on what the general principle
is, such as perhaps delete-service deletes everything that appears
to be directly associated
dminer: but i'm not sure what the right answer is offhand
ClayB: Okay. I can roll this up to Caiman-Discuss and continue
the conversation with a break for thought, if that's okay? I have a
nice object framework for implementing delete-service/client DHCP
clean-up but should get my wad going back soonish and then Ethan
pointed out it wasn't agreed how to do it. I can also leave the
DHCP bits out for now.
dminer: ok
ClayB: Cool, I'll roll-up this for now. Thank you for the
thoughts
Thank you,
Clay
On Thu, 27 Aug 2009, Ethan Quach wrote:
>
>
> Dave Miner wrote:
>> Clay Baenziger wrote:
>>> Hi Dave,
>>> As our resident DHCP guru, what are your thoughts about us stripping
>>> out service specific data from a installadm(1) created DHCP macro?
>>> My arguments for it would be that leaving the service specific data
>>> behind (BootSvrA, BootFile) is troubling for a system admin (i.e. the
>>> system won't boot if it tries PXE Booting (and Access Exception is only
>>> such a helpful error). Further, the paths on the server may be
>>> inadvertently redeployed leading to a client getting unindented data.
>>> An argument against is the admin may have modified the macro and
>>> expect it to stay around. I would say that we can use the data we already
>>> have about a service to check the macro values are original and if they've
>>> changed, we could take no action.
>>> I like the idea in bug 4566 about splitting into a client specific
>>> macro (router, DNS server, etc.) and having that include the service
>>> specific macro. But for now, I'm working on installadm
>>> delete-service/delete-client and think this should make life easier for an
>>> admin (and with relatively little code too).
>>> Do you have any thoughts to add?
>>
>> I would prefer to see the effort expended to restructure the macros a I
>> suggested in the comments on this bug. It seems likely to be little more
>> difficult to do that work and then allow for clean deletion of the macro
>> than to spend effort attempting to do detailed editing of the macro. To
>> me, this falls into fixing it right rather than introducing band-aids.
>
> At first glance, this appears to factor out pretty easily:
>
> - a Sparc client macro would just need to include the
> a sparc install service macro.
>
> (currently, the macro content for a sparc service, and
> a sparc client that's set up to use said service are
> identical)
>
>
> - an x86 client macro would need BootFile, GrubMenu, and
> inclusion of an x86 install service macro.
>
> (though 7481 says we need to get rid of GrubMenu usage
> anyway)
>
>
> -ethan
>
