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-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-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] 
 mailto:[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] mailto:[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


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] 
 mailto:[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] mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED] mailto:[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]
 mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
 mailto:[EMAIL PROTECTED]
 
 
 
 
 
 -- 
 Warm Regards,
 Narendra
 
 Visit my blogs at:
 http://ssnarendrakumar.blogspot.com/
 ___ ___ __ _
 / __/ / __/ / | / /
 _\ \ _ \ \ / /| |/ /
 \___/ \___/ /_/ |__/
 
 
 
 
 
 
 ___
 smf-discuss mailing list
 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
 
 
 
 
 -- 
 Warm Regards,
 Narendra
 
 Visit my blogs at:
 http://ssnarendrakumar.blogspot.com/
 ___ ___ __ _
 / __/ / __/ / | / /
 _\ \ _ \ \ / /| |/ /
 \___/ \___/ /_/ |__/
___
zones-discuss mailing list
zones-discuss@opensolaris.org