Hi Gordan,
I think you have highlighted an issue that I was just thinking
about. We need to define what is the expected behavior when a user
rolls back (or boots a previous BE). I am plan on working on those use
cases and will post them soon.
-Sanjay
On 02/17/10 09:45 AM, Liane Praza wrote:
> Gordon Ross wrote:
>>> Gordon Ross wrote:
>>>> What prevents the simple strategy of sharing all of /var?
>>>> (Simple is beautiful:)
>>>>
>>>> Could we just move things that can't be shared to /etc?
>>
>> And I should have added: And if necessary, make symbolic links
>> for things the have to move and for which we don't control the
>> applications looking for them...
>>
>> Would that work for the case of /var/svc/manifest ?
>
> It will not. The reasons were hashed out on smf-discuss when the
> Early Manifest Import project did their ARC/design review there.
>
>>
>>> Some things, e.g. /var/svc/manifest are Public interfaces that we
>>> can't just change easily. That particular one we're deprecating
>>> over time (PSARC 2010/013), but we can't just move the public
>>> interfaces without interfering with ISV applications.
>>>
>>> Though, arguably, your larger point should lead to guidance for any
>>> new projects delivering to /var. (Sanjay, is your project going to
>>> provide that guidance?)
>>>
>>> liane
>>
>>
>> I guess the fundamental argument is: There are relatively few things
>> in /var that can not be shared, so it's better to deal with those things
>> that can NOT be shared as the exceptions, and make everything else
>> shared
>> across boot environments.
>>
>> As for the "versioned DB in /var" problem, one suffers either way:
>> If that DB is kept per BE, you have stale data in alternate BEs.
>> The version change on upgrade is easier to deal with.
>>
>> Typically, customers just want a reasonable way to "roll back" after
>> an upgrade, so it's probably sufficient to snapshot the (shared) /var
>> filesystem with a snap name that can be easily associated with the
>> BE it goes with. Then if and when a roll back is necessary, either
>> zfs clone or rollback /var to the snapshot that BE requires. It's
>> not surprising to lose recent DB updates during a roll-back, and
>> it may even be desirable (to completely restore prior state).
>
> I admit I haven't closely followed the conversation until now, so
> don't have a specific (or at least an informed-enough) opinion to
> comment or offer a complete alternative to Sanjay's updated proposal.
>
> liane
> _______________________________________________
> caiman-discuss mailing list
> caiman-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
