Re: [zones-discuss] [smf-discuss] Possible solution to automated installation of "single user" patches

2008-09-02 Thread Jordan Brown
Narendra Kumar S.S wrote:
>   Is there any particular reason, why you are not proposing to move 
> filesystem/local to single-user milestone.

That was option #1 in my list.  However, there were those who objected 
to changing the definition of single-user mode in this way.  In 
addition, there are these late-breaking issues with Sun Cluster et al.

>   That looks very simple fix

Yes.

> and will solve all the problems.

No.  It would address the particular breakage that we're seeing today, 
but would not address the systemic problem that there is no agreement on 
when and how these services should be run.

Re-read the proposal.  It describes the issues and constraints.  I 
believe that today (even without this most recent patchadd issue) there 
are a number of cases where we are avoid problems only because we've 
been lucky, and because we've worked around the problems in a few cases.

___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [smf-discuss] Possible solution to automated installation of "single user" patches

2008-09-02 Thread Nicolas Williams
On Mon, Sep 01, 2008 at 07:13:56PM +0200, Renaud Manus wrote:
> Sure :-)
> 
> Both Sun Cluster and AVS introduce new services. Some of them
> (eg. global-devices & system/nws_scm) are dependent on
> milestone/single-user and add filesystem/local as their dependent.
> 
> If we were to move filesystem/local into ms/single-user,
> it would create a dependency loop between those services and
> SMF doesn't allow it.
> 
> eg.
> 
> fs/local <- ms/single-user <- system/nws_scm <- fs/local

Perhaps we need to split fs/local?
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [smf-discuss] Possible solution to automated installation of "single user" patches

2008-09-01 Thread Renaud Manus
Sure :-)

Both Sun Cluster and AVS introduce new services. Some of them
(eg. global-devices & system/nws_scm) are dependent on
milestone/single-user and add filesystem/local as their dependent.

If we were to move filesystem/local into ms/single-user,
it would create a dependency loop between those services and
SMF doesn't allow it.

eg.

fs/local <- ms/single-user <- system/nws_scm <- fs/local

Oups!

-- Renaud


Narendra Kumar S.S wrote:
> Renaud,
> 
>   Can you please elaborate on this?
> 
> Regards,
> Narendra
> 
> 
> 
> On Mon, Sep 1, 2008 at 10:33 PM, Renaud Manus <[EMAIL PROTECTED] 
> > wrote:
> 
> After more investigation, moving filesystem/local to single-user
> milestone is not an option when Sun Cluster or Sun Storagetek
> AVS comes into play.
> 
> -- Renaud
> 
> 
> Narendra Kumar S.S wrote:
> 
> Jordan,
> 
>  Is there any particular reason, why you are not proposing
> to move filesystem/local to single-user milestone.
>  That looks very simple fix and will solve all the problems.
> 
> Regards,
> Narendra
> 
> 
> On Sat, Aug 30, 2008 at 8:00 AM, Jordan Brown
> <[EMAIL PROTECTED] 
> >> wrote:
> 
>Jordan Brown wrote:
> > Proposal 2:
> > - Make the new patching service depend on
> system/filesystem/local.
> > - Modify patchadd to temporarily enable
> system/filesystem/local
>before
> > patching, and disable it afterward, *if* it is offline.  Note
>that when
> > the patching service runs, system/filesystem/local will be
> online
>and so
> > patchadd will not need to manipulate it.
> 
>I added part of this late and it's a little misleading.  It
> suggests
>that patchadd wouldn't need to manipulate s/f/l, and that's
> not quite
>right.  *When invoked from the patch service*, patchadd
> wouldn't need to
>manipulate s/f/l.  When invoked interactively (from
>milestone/single-user), in this scenario patchadd would still
> have to
>enable s/f/l.
>___
>smf-discuss mailing list
>[EMAIL PROTECTED]
> 
>  >
> 
> 
> 
> 
> 
> -- 
> Warm Regards,
> Narendra
> 
> Visit my blogs at:
> http://ssnarendrakumar.blogspot.com/
> ___ ___ __ _
> / __/ / __/ / | / /
> _\ \ _ \ \ / /| |/ /
> \___/ \___/ /_/ |__/
> 
> 
> 
> 
> 
> 
> ___
> smf-discuss mailing list
> [EMAIL PROTECTED] 
> 
> 
> 
> 
> -- 
> Warm Regards,
> Narendra
> 
> Visit my blogs at:
> http://ssnarendrakumar.blogspot.com/
> ___ ___ __ _
> / __/ / __/ / | / /
> _\ \ _ \ \ / /| |/ /
> \___/ \___/ /_/ |__/
___
zones-discuss mailing list
zones-discuss@opensolaris.org


Re: [zones-discuss] [smf-discuss] Possible solution to automated installation of "single user" patches

2008-09-01 Thread Renaud Manus
After more investigation, moving filesystem/local to single-user
milestone is not an option when Sun Cluster or Sun Storagetek
AVS comes into play.

-- Renaud

Narendra Kumar S.S wrote:
> Jordan,
> 
>   Is there any particular reason, why you are not proposing to move 
> filesystem/local to single-user milestone.
>   That looks very simple fix and will solve all the problems.
> 
> Regards,
> Narendra
> 
> 
> On Sat, Aug 30, 2008 at 8:00 AM, Jordan Brown <[EMAIL PROTECTED] 
> > wrote:
> 
> Jordan Brown wrote:
>  > Proposal 2:
>  > - Make the new patching service depend on system/filesystem/local.
>  > - Modify patchadd to temporarily enable system/filesystem/local
> before
>  > patching, and disable it afterward, *if* it is offline.  Note
> that when
>  > the patching service runs, system/filesystem/local will be online
> and so
>  > patchadd will not need to manipulate it.
> 
> I added part of this late and it's a little misleading.  It suggests
> that patchadd wouldn't need to manipulate s/f/l, and that's not quite
> right.  *When invoked from the patch service*, patchadd wouldn't need to
> manipulate s/f/l.  When invoked interactively (from
> milestone/single-user), in this scenario patchadd would still have to
> enable s/f/l.
> ___
> smf-discuss mailing list
> [EMAIL PROTECTED] 
> 
> 
> 
> 
> -- 
> Warm Regards,
> Narendra
> 
> Visit my blogs at:
> http://ssnarendrakumar.blogspot.com/
> ___ ___ __ _
> / __/ / __/ / | / /
> _\ \ _ \ \ / /| |/ /
> \___/ \___/ /_/ |__/
> 
> 
> 
> 
> ___
> smf-discuss mailing list
> [EMAIL PROTECTED]
___
zones-discuss mailing list
zones-discuss@opensolaris.org