On 03/12/09 12:13, James Carlson wrote:
> michael schuster writes:
>
>> James Carlson wrote:
>>
>>> Michael Schuster writes:
>>>
>>>> * import/export: the initial requirement was to have a means to take the
>>>> current configuration of the load balancer ("ilbadm export <file>"),
>>>> transport it to another machine by whatever means and re-apply ("ilbadm
>>>> import <file>") it there.
>>>>
>>>> Q1: Would people agree that this requirement makes sense?
>>>>
>>> It's a little surprising to me. It sounds a bit like you're
>>> reinventing "svccfg export" and "svccfg import," and I'm not sure why
>>> or how far down that path you really want to go.
>>>
>> that would imply that we're storing the information you're referring to
>> within the SMF framework ... which is not the case. As of now, all SMF does
>> is start and stop ilbd, maybe store the location of the persistent config
>> (file).
>>
>
> When you go for wider review (not sure why I'm on the list right now),
> I expect you'll get similar questions about your configuration
> mechanism.
>
> The more you replicate SMF functionality into the design, the more
> likely it is that someone will ask why that's necessary.
>
>
>>> Should ilbadm have its own profile mechanism?
>>>
>> what exactly do you mean by that?
>>
>
> SMF has 'profiles' for basic service configuration. They're being
> enhanced now to provide a lot more control over services through the
> profile mechanism, and this will be used (in turn) by NWAM to set up
> services on systems, and to switch between sets of services when
> changing "location."
>
> In addition, I believe the enhanced profile mechanism will be a part
> of how we intend to provide install-time configuration for enterprise
> types of deployments.
>
> If ilbadm is being designed with its own configuration management
> repository, and if we end up with more uses for the enhanced profiles,
> then it may end up needing to support something like this.
>
>
>>> What about
>>> customization at install time (as with jumpstart scripts)? Snapshot
>>> and rollback?
>>>
>> has not been considered.
>>
>
> OK.
>
rollback and snapshot was considered and after talking to intersted
folks have decided its not a high priority feature, and we are not
planning on doing it in phase 1.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/ilb-dev/attachments/20090312/df511473/attachment.html>
