On Thu, Dec 09, 2010 at 11:11:32AM -0500, James Whittington wrote:
>    In a perfect world I would prefer for a downed slave to not block many
>    actions in Opsview.
> 
>    I would think the Opsview master server would have a warning status on the
>    load configuration screen to let me know a config update or slave upgrade
>    did not complete.

I'd certainly favour this over failing an update on master. The update should
output to stdout why or at least where a slave update failed. 

Having said this, we don't yet use slaves, but will be doing so soon. It seems 
it ought to be simpler to repair a failed slave update than redo the entire
upgrade.

>    There would be a pending actions queue that could be re-run to clear the
>    warning status.
> 
> 
> 
>    In our case we have a lot of slave servers at remote locations so the
>    blocking behavior of applying a config is the archilles heel so to say, at
>    least from the service provider perspective.
> 
> 
> 
>    I understand there are many valid reasons to keep everything in synch but
>    I would think the architecture could be tweaked to be more accepting of
>    downed monitoring nodes.
> 
> 
> 
>    James Whittington
> 
>    VC3, Inc.
> 
> 
> 
>    From: [email protected]
>    [mailto:[email protected]] On Behalf Of Ton Voon
>    Sent: Thursday, December 09, 2010 9:10 AM
>    To: Opsview Users
>    Subject: Re: [opsview-users] FW: How do we push new versions to the slave
>    servers after the master is upgraded?
> 
> 
> 
>    Thanks for all the feedback.
> 
> 
> 
>    Emilio, that's a good idea re: parameter to fail the upgrade or not, so
>    I've updated the description
>    at [1]https://secure.opsera.com/jira/browse/OPS-896
> 
> 
> 
>    Paul, I've noted the idea re: different ssh ports
>    in [2]https://secure.opsera.com/jira/browse/OPS-1455
> 
> 
> 
>    Ton
> 
> 
> 
>    On 9 Dec 2010, at 12:33, Emilio Scalise wrote:
> 
>    When I upgrade opsview I often need to disable my slave machine and then
>    re-enable later it.
>    It would be nice if there is an option to disable the fail if there is an
>    error upgrading slaves behaviour (naturally the default setting should be
>    the current behaviour).
> 
>    Regards,
>    Emilio
> 
>    Il 09/12/2010 12:49, Ton Voon ha scritto:
> 
> 
> 
>    On 8 Dec 2010, at 17:53, Paul wrote:
> 
> 
> 
>      Hi James,
> 
>      ASAIK the suggested way you describe below should work OK. I'm running
>      slaves on a different port than 22, so upgrade always yell slaves can;t
>      be updated. Then I modify two files, indicating the correct port and
>      re-run the update process - which has worked for me for the past 5 times
>      :)
> 
>      Good luck
>      Paul
> 
> 
> 
>    Hi Paul,
> 
> 
> 
>    One thing we were thinking was to force an upgrade to fail if the slaves
>    failed to update. This is the most common case and necessary if, for
>    instance, we make a major update to nagios which will generate a new style
>    configuration which an older nagios would die trying to run (thus slaves
>    just appear to have stopped working)
> 
> 
> 
>    However, this blocks your process. Suggestions?
> 
> 
> 
>    Ton
> 
>  _______________________________________________
> 
>  Opsview-users mailing list
>  [3][email protected]
>  [4]http://lists.opsview.org/lists/listinfo/opsview-users
> 
>    <ATT00001..c>
> 
>    Ton Voon
>    Product Architect
>    Global Headquarters: Unit 69 Suttons Business Park | Reading | Berkshire |
>    RG6 1AZ | UK
> 
>    UK:               +44 (0) 845 057 7887
>    USA:     +1 866 879 9184
>    Email:    [5][email protected]
>    Skype:   tonvoon
>    Web:     [6]www.opsview.com
> 
>    This e-mail is confidential, intended only for the named recipient(s)
>    above and may contain information that is privileged and confidential. If
>    you receive this message in error, or are not the named recipient(s),
>    please notify the sender at the phone number above, do not copy this
>    message, do not disclose its contents to anyone, and delete this e-mail
>    message from your computer. Although we routinely screens for viruses,
>    addressees should scan this e-mail and any attachments for viruses. Opsera
>    makes no representation or warranty as to the absence of viruses in this
>    e-mail or any attachments.


> _______________________________________________
> Opsview-users mailing list
> [email protected]
> http://lists.opsview.org/lists/listinfo/opsview-users


-- 
regards,
tony
_______________________________________________
Opsview-users mailing list
[email protected]
http://lists.opsview.org/lists/listinfo/opsview-users

Reply via email to