fuel-dev team mailing list archive

[Roman Zhnichkov <rzhnichkov@xxxxxxxxxxxx>]

Andrew,
  thanks for this catch, we'll investigate alternatives.

--
Roman Zhnichkov



On Thu, Feb 20, 2014 at 11:00 PM, Andrew Woodward <xarses@xxxxxxxxx> wrote:

> I've reviewed most of the zabbix commit request and I see that it
> contains many uses of stored configs which wont work any longer since
> we don't have the puppet db / master anymore so there is likely a bit
> of work there. Additionally we should not merge it because it's
> licensed under AGPL which at this point will not be accepted. I've
> reached out to the upstream authors and have requested a change in
> license but this should not be expected. We should be reviewing
> additional module providers that have a more suitable upstream license
> and possibly less work to work in our environment.
>
> On Wed, Feb 19, 2014 at 11:34 AM, Dmitry Borodaenko
> <dborodaenko@xxxxxxxxxxxx> wrote:
> > David,
> >
> > As far as I understand the difference between #4 and #1 is that in the
> > case of #4 Zabbix server is not deployed by Fuel (pre-existing
> > monitoring server), so our job is to collect the server details from
> > the operator and configure Zabbix agents to report to that server.
> >
> > -DmitryB
> >
> > On Wed, Feb 19, 2014 at 6:56 AM, David Easter <deaster@xxxxxxxxxxxx>
> wrote:
> >> Use cases 1 & 2 are fine for MVP in the first release, yes.
> >>
> >> Would the mechanism for deploying use case #4 be the same as use case
> #1 –
> >> just configuring the server to monitor agents in multiple clouds?
> >>
> >> Thanks,
> >>
> >> - David J. Easter
> >>   Product Line Manager,  Mirantis
> >>
> >> From: Roman Zhnichkov <rzhnichkov@xxxxxxxxxxxx>
> >> Date: Wednesday, February 19, 2014 at 4:30 AM
> >> To: David Easter <deaster@xxxxxxxxxxxx>
> >> Cc: "fuel-dev@xxxxxxxxxxxxxxxxxxx" <fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >> Subject: Re: [Fuel-dev] Zabbix feature review request
> >>
> >> Guys,
> >>   in other words there are several use cases for Zabbix server
> placement:
> >>
> >> Zabbix server as separate role on dedicated hardware
> >> Zabbix server role combined with some other role (compute or storage,
> since
> >> Zabbix uses MySQL, so we don't want to mix OpenStack and Zabbix data in
> the
> >> same DB)
> >> Zabbix server on fuel-master
> >> Remote Zabbix server outside of OpenStack environment
> >> Combination of any of 4 previous items (for example, we have Zabbix
> server
> >> on fuel-master monitoring all existing environments and some other
> Zabbix
> >> servers monitoring particular OpenStack environments)
> >>
> >> Also we have general requirements:
> >>
> >> HA for Zabbix server
> >> Dynamic configuration (automatic node deletion when removing node from
> the
> >> environment, requires orchestration patching)
> >>
> >> As MVP I propose to have use cases 1 and 2 implemented (Zabbix server as
> >> separate role ans Zabbix server role combined with compute or storage)
> with
> >> dynamic configuration requirement.
> >>
> >> Use cases 3-5 as well as HA for Zabbix are subject to further
> >> implementation.
> >>
> >> We'll update the specification according with that.
> >>
> >> Any comments or suggestions?
> >>
> >>
> >> --
> >> Roman Zhnichkov
> >>
> >>
> >>
> >> On Tue, Feb 18, 2014 at 8:21 PM, David Easter <deaster@xxxxxxxxxxxx>
> wrote:
> >>>
> >>> On 2/18/14, 4:23 AM, "Bogdan Dobrelya" <bdobrelia@xxxxxxxxxxxx> wrote:
> >>>
> >>> >On 02/18/2014 12:05 PM, Dmitry Nikishov wrote:
> >>> >> From this conversation we got following points:
> >>> >> 1. It should be possible to install zabbix as a separate role
> >>> >> 2. Combining zabbix role with other roles should be supported as
> well
> >>> >> 3. There should be support for configuring zabbix agents to point
> them
> >>> >> to the remote zabbix server
> >>> >> 4. Possible zabbix installation on fuel-master?
> >>> >> 5. In case of one zabbix server monitoring multiple environments,
> nodes
> >>> >> should be separated into hostgroups.
> >>> >>
> >>> >> Concerns:
> >>> >> 1. perfomance when alot of nodes are being monitored by single
> server
> >>>
> >>> True.  We’d need to publish the maximum number of nodes that can be
> >>> monitored efficiently by one server.  If the number of monitored nodes
> >>> goes above that number, we’d recommend a dedicated server within the
> >>> largest deployed cloud (for example) to split the burden.
> >>>
> >>> >> 2. if zabbix agents were configured to connect to the remote server
> >>> >> (outside the environment), once this env gets deleted, it's nodes
> will
> >>> >> be rebooted into bootstrap. However, they won't be deleted from
> zabbix.
> >>> >> It's not clear how to remove them from zabbix server.
> >>>
> >>> We’d have to build in automation to do that for the user.  I.e. if a
> >>> remote node is deleted, update the corresponding zabbix server’s info.
> >>>
> >>> >>
> >>> >> Open question: if there will be support for zabbix on fuel-master,
> >>> >> there
> >>> >> should be an option either to enable or disable it somewhere in the
> >>> >>fuelmenu
> >>> >>
> >>> >> Any thoughts?
> >>>
> >>> Configuration of the “local” zabbix server would need to be an option,
> >>> yes.  It’s very possible that you’d have a situation where the “local”
> >>> zabbix server is watching some clouds while a dedicated zabbix server
> >>> within one of the deployed clouds is watching only the nodes within
> that
> >>> cloud.  I.e. there can be a mixture.  Fuel would need to keep track of
> >>> which nodes were being monitored by which server(s).
> >>>
> >>> >Looks like "2 - Can Zabbix be set up in HA (even in active/passive)?"
> >>> >wasn't addressed by either of the points, e.g.:
> >>> >- How can we configure HA zabbix in case of:
> >>> >* one of the zabbix nodes is a master node?
> >>> >* some of the zabbix nodes were externally configured by the user
> >>> > himself?
> >>> >* some of the zabbix nodes belong to the different envs and combined
> >>> >with the another roles.
> >>> >>
> >>> >>
> >>> >> 2014-02-15 1:16 GMT+04:00 Andrew Woodward <xarses@xxxxxxxxx
> >>> >> <mailto:xarses@xxxxxxxxx>>:
> >>> >>
> >>> >>     Based on the way the data-points appear to be collected, there
> is
> >>> >>     definitely a point where monitoring the nodes will become too
> >>> >>     intense for a node sharing roles (or even a single node) (I've
> >>> >>     personally overloaded most monitoring systems in default
> >>> >>     configurations with ~200 nodes.) However a single pane of glass
> to
> >>> >>     view all clusters is extremely important to the operations
> teams.
> >>> >> It
> >>> >>     is therefor necessary for us to be able to specify an existing
> >>> >>     Zabbix server that may be deployed elsewhere, or even completely
> >>> >>     outside the scope of fuel.
> >>> >>
> >>> >>     So to get down to it. we should be able to (1) install Zabbix
> as a
> >>> >>     role (2) separately of the Zabbix role configure Zabbix agents
> on
> >>> >>     nodes inside a cluster to point to a Zabbix node. (3) if a
> Zabbix
> >>> >>     role is defined in the cluster assume that it should be used to
> >>> >>     configure (2) but allow it to be replaced anyway.
> >>> >>
> >>> >>
> >>> >>
> >>> >>     On Fri, Feb 14, 2014 at 11:42 AM, David Easter
> >>> >> <deaster@xxxxxxxxxxxx
> >>> >>     <mailto:deaster@xxxxxxxxxxxx>> wrote:
> >>> >>
> >>> >>         Good observation!  For a situation where the tenant for each
> >>> >>         cloud were
> >>> >>         the same, that would certainly make sense, yes.  Perhaps
> that
> >>> >>         should even
> >>> >>         be the default if it doesn’t impact the abilities of the
> Fuel
> >>> >>         Master node.
> >>> >>          I.e. install the Zabbix server on the Fuel Node by default
> and
> >>> >>         the Zabbix
> >>> >>         agents pointing back to the Fuel Master Node by default.  If
> >>> >> the
> >>> >>         operator
> >>> >>         decides that a given environment needs its own dedicated
> Zabbix
> >>> >>         server,
> >>> >>         the operator could add a role on an existing node, or a
> >>> >>         standalone node,
> >>> >>         for a Zabbix server and all agents in the environment would
> >>> >> then
> >>> >>         point to
> >>> >>         that deployed server.  Then the URL for the deployed Zabbix
> >>> >>         server would
> >>> >>         properly appear when the environment were opened.
> >>> >>
> >>> >>         In answer to your question, though; were a service provider
> (or
> >>> >>         large IT
> >>> >>         organization) to create clouds for its customers, it may
> make
> >>> >>         more sense
> >>> >>         to provide a monitoring service that the customer could draw
> >>> >>from
> >>> >>         independently of other customers.  Or in instances where the
> >>> >>         clouds are
> >>> >>         highly separated from each other in terms of data content or
> >>> >>         internal
> >>> >>         departments.  By creating a Zabbix server per environment,
> this
> >>> >>         would
> >>> >>         address issues of ensuring isolation of access and data.
> >>> >>
> >>> >>         Thanks,
> >>> >>
> >>> >>         - David J. Easter
> >>> >>           Product Line Manager
> >>> >>
> >>> >>
> >>> >>
> >>> >>         On 2/14/14, 11:32 AM, "Dmitry Borodaenko"
> >>> >>         <dborodaenko@xxxxxxxxxxxx <mailto:dborodaenko@xxxxxxxxxxxx
> >>
> >>> >>wrote:
> >>> >>
> >>> >>         >What about deploying Zabbix on the Fuel node itself?
> >>> >>         >
> >>> >>         >In a scenario where a large number of OpenStack
> environments
> >>> >> is
> >>> >>         >deployed from the same Fuel node, I'm struggling to come up
> >>> >>with a
> >>> >>         >scenario where operator would prefer to have a separate
> >>> >>monitoring
> >>> >>         >server for each environment, instead of monitoring all
> >>> >>environments
> >>> >>         >from a single pane of glass.
> >>> >>         >
> >>> >>         >-DmitryB
> >>> >>         >
> >>> >>         >
> >>> >>         >On Fri, Feb 14, 2014 at 9:08 AM, David Easter
> >>> >>         <deaster@xxxxxxxxxxxx <mailto:deaster@xxxxxxxxxxxx>>
> >>> >>         >wrote:
> >>> >>         >> Correct.  Just to understand, there’s growing concern
> from
> >>> >>         our customer
> >>> >>         >> base about how many servers they need in an OpenStack
> >>> >>         environment that
> >>> >>         >> don’t add to the compute power of the environment.  We
> >>> >>         already require
> >>> >>         >>the
> >>> >>         >> Fuel Master Node on its own server, so _requiring_ a
> Zabbix
> >>> >>         node of its
> >>> >>         >> own will be more difficult to justify - especially in
> small
> >>> >>         environments
> >>> >>         >> (5-10 servers).
> >>> >>         >>
> >>> >>         >> While it is completely proper to point out that
> individual
> >>> >>         services
> >>> >>         >>_can_
> >>> >>         >> (and perhaps should) be installed on their own nodes for
> >>> >>         performance
> >>> >>         >> reasons, the option to combine them with other roles on
> the
> >>> >>         same server
> >>> >>         >> needs to be an option when performance is not an issue.
>  In
> >>> >>other
> >>> >>         >>words, I
> >>> >>         >> should be able to have a Zabbix server running on the
> same
> >>> >>         server as my
> >>> >>         >> compute or controller function.  I should also be able to
> >>> >>         install it on
> >>> >>         >> its own standalone server if I’m concerned about
> >>> >> performance.
> >>> >>         >>
> >>> >>         >> Thanks,
> >>> >>         >>
> >>> >>         >> - David J. Easter
> >>> >>         >>   Product Line Manager,  Mirantis
> >>> >>         >>
> >>> >>         >>
> >>> >>         >> On 2/13/14, 7:49 AM, "Matthew Mosesohn"
> >>> >>         <mmosesohn@xxxxxxxxxxxx <mailto:mmosesohn@xxxxxxxxxxxx>>
> wrote:
> >>> >>         >>
> >>> >>         >>>Dmitry,
> >>> >>         >>>
> >>> >>         >>>I think it would be logical to say that it should be
> trivial
> >>> >>to
> >>> >>         >>>reinstall a separate Zabbit node since it doesn't contain
> >>> >> any
> >>> >>         data
> >>> >>         >>>critical to the production environment. I think if you
> can
> >>> >>         remove and
> >>> >>         >>>add a new zabbix server to a deployed environment, it
> would
> >>> >>         meet a lot
> >>> >>         >>>of our users' needs.
> >>> >>         >>>
> >>> >>         >>>
> >>> >>         >>>On Thu, Feb 13, 2014 at 6:54 PM, Dmitry Nikishov
> >>> >>         <nikishov.da@xxxxxxxxx <mailto:nikishov.da@xxxxxxxxx>>
> >>> >>         >>>wrote:
> >>> >>         >>>> Matthew,
> >>> >>         >>>> It should be possible to install Zabbix alongside with
> >>> >>         OpenStack
> >>> >>         >>>>components
> >>> >>         >>>> on a controller, compute etc. However, Zabbix isn't an
> >>> >>         OpenStack
> >>> >>         >>>>component,
> >>> >>         >>>> it does not directly affect cluster. So there's no
> need to
> >>> >>         combine it
> >>> >>         >>>>with
> >>> >>         >>>> other roles or making it high-available. It makes
> sense to
> >>> >>         install it
> >>> >>         >>>>on a
> >>> >>         >>>> separate node.
> >>> >>         >>>>
> >>> >>         >>>> Bogdan,
> >>> >>         >>>> I like the idea of combining metering, monitoring and
> >>> >>         logging on one
> >>> >>         >>>>node.
> >>> >>         >>>> However, I think it would be better to have separate
> roles
> >>> >>         for all
> >>> >>         >>>>three of
> >>> >>         >>>> them. But these roles should not conflict with each
> other.
> >>> >>         This way it
> >>> >>         >>>>will
> >>> >>         >>>> be more customizable.
> >>> >>         >>>>
> >>> >>         >>>> 2014-02-13 16:07 GMT+03:00 Bogdan Dobrelya
> >>> >>         <bdobrelia@xxxxxxxxxxxx <mailto:bdobrelia@xxxxxxxxxxxx>>:
> >>> >>         >>>>
> >>> >>         >>>>> On 02/13/2014 02:33 PM, Matthew Mosesohn wrote:
> >>> >>         >>>>> > Dmitry,
> >>> >>         >>>>> >
> >>> >>         >>>>> > I have two questions:
> >>> >>         >>>>> > 1 - Can Zabbix Server Role be combined with any
> other
> >>> >>         role? (like
> >>> >>         >>>>> > controller)
> >>> >>         >>>>> > 2 - Can Zabbix be set up in HA (even in
> >>> >> active/passive)?
> >>> >>         What are
> >>> >>         >>>>>the
> >>> >>         >>>>> > obstacles?
> >>> >>         >>>>> >
> >>> >>         >>>>>
> >>> >>         >>>>> And even if it cannot, I believe the good point is to
> use
> >>> >>         it as
> >>> >>         >>>>> Monitoring & Metering & Logging node, see my comments
> >>> >>         inside the doc.
> >>> >>         >>>>>
> >>> >>         >>>>> > On Thu, Feb 13, 2014 at 4:28 PM, Дмитрий Никишов
> >>> >>         >>>>><nikishov.da@xxxxxxxxx <mailto:nikishov.da@xxxxxxxxx>>
> >>> >>         >>>>> > wrote:
> >>> >>         >>>>> >> Hello everyone.
> >>> >>         >>>>> >>
> >>> >>         >>>>> >> I've been working on Zabbix integration for a while
> >>> >>         now, and I'd
> >>> >>         >>>>>like
> >>> >>         >>>>> >> know
> >>> >>         >>>>> >> what do you guys think about it.
> >>> >>         >>>>> >>
> >>> >>         >>>>> >> The specification:
> >>> >>         >>>>> >>
> >>> >>         >>>>> >>
> >>> >>
> >>>
> >>> >>>>>>> >>>>>>>
> https://docs.google.com/document/d/1g9xtBrgwgpeNV5YYxTMFu2h-yIK_PC1Z
> >>> >>>>>>>JD
> >>> >>         >>>>>mw
> >>> >>         >>>>>84RquJk
> >>> >>         >>>>> >>
> >>> >>         >>>>> >> Changes to fuel-library so far:
> >>> >>         >>>>>https://review.openstack.org/#/c/73254/
> >>> >>         >>>>> >> Changes to fuel-main and fuel-web will be coming
> soon.
> >>> >>         >>>>> >>
> >>> >>         >>>>> >> There is an open question related to UI - parameter
> >>> >>         validation:
> >>> >>         >>>>> >> - there should be only one zabbix-server node
> >>> >>         >>>>> >> - "Install Zabbix" checkbox should only be
> available
> >>> >> if
> >>> >>         there is a
> >>> >>         >>>>>node
> >>> >>         >>>>> >> with
> >>> >>         >>>>> >> "zabbix-server" role
> >>> >>         >>>>> >>
> >>> >>         >>>>> >> --
> >>> >>         >>>>> >> Regards
> >>> >>         >>>>> >> Dmitry Nikishov
> >>> >>         >>>>> >>
> >>> >>         >>>>> >> --
> >>> >>         >>>>> >> Mailing list: https://launchpad.net/~fuel-dev
> >>> >>         >>>>> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>> >>         <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >>> >>         >>>>> >> Unsubscribe : https://launchpad.net/~fuel-dev
> >>> >>         >>>>> >> More help   : https://help.launchpad.net/ListHelp
> >>> >>         >>>>> >>
> >>> >>         >>>>> >
> >>> >>         >>>>>
> >>> >>         >>>>>
> >>> >>         >>>>> --
> >>> >>         >>>>> Best regards,
> >>> >>         >>>>> Bogdan Dobrelya,
> >>> >>         >>>>> Skype #bogdando_at_yahoo.com
> >>> >><http://bogdando_at_yahoo.com>
> >>> >>         >>>>> Irc #bogdando
> >>> >>         >>>>
> >>> >>         >>>>
> >>> >>         >>>>
> >>> >>         >>>>
> >>> >>         >>>> --
> >>> >>         >>>> Regards
> >>> >>         >>>> Dmitry Nikishov
> >>> >>         >>>
> >>> >>         >>>--
> >>> >>         >>>Mailing list: https://launchpad.net/~fuel-dev
> >>> >>         >>>Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>> >>         <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >>> >>         >>>Unsubscribe : https://launchpad.net/~fuel-dev
> >>> >>         >>>More help   : https://help.launchpad.net/ListHelp
> >>> >>         >>
> >>> >>         >>
> >>> >>         >>
> >>> >>         >> --
> >>> >>         >> Mailing list: https://launchpad.net/~fuel-dev
> >>> >>         >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>> >>         <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >>> >>         >> Unsubscribe : https://launchpad.net/~fuel-dev
> >>> >>         >> More help   : https://help.launchpad.net/ListHelp
> >>> >>         >
> >>> >>         >
> >>> >>         >
> >>> >>         >--
> >>> >>         >Dmitry Borodaenko
> >>> >>
> >>> >>
> >>> >>
> >>> >>         --
> >>> >>         Mailing list: https://launchpad.net/~fuel-dev
> >>> >>         Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>> >>         <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >>> >>         Unsubscribe : https://launchpad.net/~fuel-dev
> >>> >>         More help   : https://help.launchpad.net/ListHelp
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >>     --
> >>> >>     If google has done it, Google did it right!
> >>> >>
> >>> >>     --
> >>> >>     Mailing list: https://launchpad.net/~fuel-dev
> >>> >>     Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>> >>     <mailto:fuel-dev@xxxxxxxxxxxxxxxxxxx>
> >>> >>     Unsubscribe : https://launchpad.net/~fuel-dev
> >>> >>     More help   : https://help.launchpad.net/ListHelp
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> Regards
> >>> >> Dmitry Nikishov
> >>> >>
> >>> >>
> >>> >> This body part will be downloaded on demand.
> >>> >>
> >>> >
> >>> >
> >>> >--
> >>> >Best regards,
> >>> >Bogdan Dobrelya,
> >>> >Skype #bogdando_at_yahoo.com
> >>> >Irc #bogdando
> >>> >
> >>> >--
> >>> >Mailing list: https://launchpad.net/~fuel-dev
> >>> >Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>> >Unsubscribe : https://launchpad.net/~fuel-dev
> >>> >More help   : https://help.launchpad.net/ListHelp
> >>>
> >>>
> >>>
> >>> --
> >>> Mailing list: https://launchpad.net/~fuel-dev
> >>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~fuel-dev
> >>> More help   : https://help.launchpad.net/ListHelp
> >>
> >>
> >>
> >> --
> >> Mailing list: https://launchpad.net/~fuel-dev
> >> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> >> Unsubscribe : https://launchpad.net/~fuel-dev
> >> More help   : https://help.launchpad.net/ListHelp
> >>
> >
> >
> >
> > --
> > Dmitry Borodaenko
> >
> > --
> > Mailing list: https://launchpad.net/~fuel-dev
> > Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> > Unsubscribe : https://launchpad.net/~fuel-dev
> > More help   : https://help.launchpad.net/ListHelp
>
>
>
> --
> If google has done it, Google did it right!
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>