Open Stack

There are two threads here that need to be unraveled from each other.

1. We need to prevent fuel from doing anything if the OS is out of
disk space. It leads to a very broken database from which it requires
a developer to reset to a usable state.
>From this point we need to
* develop a method for locking down the DB writes so that fuel becomes
RO until space is freed
* develop a method (or re-use existing) to notify the user that a
serious error state exists on the host. ( that could not be dismissed)
* we need some API that can lock / unlock the DB
* we need some monitor process that will trigger the lock/unlock

2. We need monitoring for the master node and fuel components in
general as discussed at length above.
unless we intend to use this to also monitor the services on deployed
nodes (likely bad), then what we use to do this is irrelevant to
getting this started. If we are intending to use this to also monitor
deployed nodes, (again bad for the fuel node to do) then we need to
standardize with what we monitor the cloud with (Zabbix currently) and
offer a single pane of glass. Federation in the monitoring becomes a
critical requirement here as having more than one pane of glass is an
operations nightmare.

Completing #1 is very important in the near term as I have had to
un-brick several deployments over it already. Also, in my mind these
are also separate tasks.

On Thu, Nov 27, 2014 at 1:19 AM, Simon Pasquier <spasquier at mirantis.com> wrote:
> I've added another option to the Etherpad: collectd can do basic threshold
> monitoring and run any kind of scripts on alert notifications. The other
> advantage of collectd would be the RRD graphs for (almost) free.
> Of course since monit is already supported in Fuel, this is the fastest path
> to get something done.
> Simon
>
> On Thu, Nov 27, 2014 at 9:53 AM, Dmitriy Shulyak <dshulyak at mirantis.com>
> wrote:
>>
>> Is it possible to send http requests from monit, e.g for creating
>> notifications?
>> I scanned through the docs and found only alerts for sending mail,
>> also where token (username/pass) for monit will be stored?
>>
>> Or maybe there is another plan? without any api interaction
>>
>> On Thu, Nov 27, 2014 at 9:39 AM, Przemyslaw Kaminski
>> <pkaminski at mirantis.com> wrote:
>>>
>>> This I didn't know. It's true in fact, I checked the manifests. Though
>>> monit is not deployed yet because of lack of packages in Fuel ISO. Anyways,
>>> I think the argument about using yet another monitoring service is now
>>> rendered invalid.
>>>
>>> So +1 for monit? :)
>>>
>>> P.
>>>
>>>
>>> On 11/26/2014 05:55 PM, Sergii Golovatiuk wrote:
>>>
>>> Monit is easy and is used to control states of Compute nodes. We can
>>> adopt it for master node.
>>>
>>> --
>>> Best regards,
>>> Sergii Golovatiuk,
>>> Skype #golserge
>>> IRC #holser
>>>
>>> On Wed, Nov 26, 2014 at 4:46 PM, Stanislaw Bogatkin
>>> <sbogatkin at mirantis.com> wrote:
>>>>
>>>> As for me - zabbix is overkill for one node. Zabbix Server + Agent +
>>>> Frontend + DB + HTTP server, and all of it for one node? Why not use
>>>> something that was developed for monitoring one node, doesn't have many deps
>>>> and work out of the box? Not necessarily Monit, but something similar.
>>>>
>>>> On Wed, Nov 26, 2014 at 6:22 PM, Przemyslaw Kaminski
>>>> <pkaminski at mirantis.com> wrote:
>>>>>
>>>>> We want to monitor Fuel master node while Zabbix is only on slave nodes
>>>>> and not on master. The monitoring service is supposed to be installed on
>>>>> Fuel master host (not inside a Docker container) and provide basic info
>>>>> about free disk space, etc.
>>>>>
>>>>> P.
>>>>>
>>>>>
>>>>> On 11/26/2014 02:58 PM, Jay Pipes wrote:
>>>>>>
>>>>>> On 11/26/2014 08:18 AM, Fox, Kevin M wrote:
>>>>>>>
>>>>>>> So then in the end, there will be 3 monitoring systems to learn,
>>>>>>> configure, and debug? Monasca for cloud users, zabbix for most of the
>>>>>>> physical systems, and sensu or monit "to be small"?
>>>>>>>
>>>>>>> Seems very complicated.
>>>>>>>
>>>>>>> If not just monasca, why not the zabbix thats already being deployed?
>>>>>>
>>>>>>
>>>>>> Yes, I had the same thoughts... why not just use zabbix since it's
>>>>>> used already?
>>>>>>
>>>>>> Best,
>>>>>> -jay
>>>>>>
>>>>>> _______________________________________________
>>>>>> OpenStack-dev mailing list
>>>>>> OpenStack-dev at lists.openstack.org
>>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Andrew
Mirantis
Ceph community