Open Stack

On 08/04/2013 08:24 PM, Angus Salkeld wrote:
> On 02/08/13 13:26 -0300, Sandy Walsh wrote:
>>
>>
>> On 08/02/2013 12:27 PM, Eoghan Glynn wrote:
>>>
>>>> On 08/01/2013 07:22 PM, Doug Hellmann wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Aug 1, 2013 at 10:31 AM, Sandy Walsh
>>>>> <sandy.walsh at rackspace.com
>>>>> <mailto:sandy.walsh at rackspace.com>> wrote:
>>>>>
>>>>>     Hey y'all,
>>>>>
>>>>>     I've had a little thorn in my claw on this topic for a while and
>>>>>     thought
>>>>>     I'd ask the larger group.
>>>>>
>>>>>     I applaud the efforts of the people working on the alarming
>>>>> additions
>>>>>     to
>>>>>     Ceilometer, but I've got concerns that we're packaging things the
>>>>>     wrong way.
>>>>>
>>>>>     I fear we're making another Zenoss/Nagios with Ceilometer. It's
>>>>> trying
>>>>>     to do too much.
>>>>>
>>>>>     The current trend in the monitoring work (#monitoringlove) is
>>>>> to build
>>>>>     your own stack from a series of components. These components
>>>>> take in
>>>>>     inputs, process them and spit out outputs.
>>>>>     Collectors/Transformers/Publishers. This is the model CM is
>>>>> built on.
>>>>>
>>>>>     Making an all-singing-all-dancing monolithic monitoring package
>>>>> is the
>>>>>     old way of building these tools. People want to use best-of-breed
>>>>>     components for their monitoring stack. I'd like to be able to use
>>>>>     reimann.io <http://reimann.io> for my stream manager, diamond
>>>>> for my
>>>>>     collector, logstash for
>>>>>     my parser, etc. Alarming should just be another consumer.
>>>>>
>>>>>     CM should do one thing well. Collect data from openstack, store
>>>>> and
>>>>>     process them, and make them available to other systems via the
>>>>> API or
>>>>>     publishers. That's all. It should understand these events
>>>>> better than
>>>>>     any other product out there. It should be able to produce
>>>>> meaningful
>>>>>     metrics/meters from these events.
>>>>>
>>>>>     Alarming should be yet another consumer of the data CM
>>>>> produces. Done
>>>>>     right, the If-This-Then-That nature of the alarming tool could be
>>>>>     re-used by the orchestration team or perhaps even scheduling.
>>>>>     Intertwining it with CM is making the whole thing too complex
>>>>> and rigid
>>>>>     (imho).
> 
> Heat is using the alarm api.

Perhaps you've misread the intent of that paragraph? It was to
illustrate the *other* projects that could benefit from a standalone
alarming module.

> 
>>>>>
>>>>>     CM should be focused on extending our publishers and input
>>>>> plug-ins.
>>>>>
>>>>>     I'd like to propose that alarming becomes its own project
>>>>> outside of
>>>>>     Ceilometer. Or, at the very least, its own package, external of
>>>>> the
>>>>>     Ceilometer code base. Perhaps it still lives under the CM
>>>>> moniker, but
>>>>>     packaging-wise, I think it should live as a separate code base.
>>>>>
>>>>> It is currently implemented as a pair of daemons (one to monitor the
>>>>> alarm state, another to send the notifications). Both daemons use a
>>>>> ceilometer client to talk to the REST API to consume the sample
>>>>> data or
>>>>> get the alarm details, as required. It looks like alarms are triggered
>>>>> by sending RPC cast message, and that those in turn trigger the
>>>>> webhook
>>>>> invocation. That seems pretty loosely coupled, as far as the runtime
>>>>> goes. Granted, it's still in the main ceilometer code tree, but that
>>>>> doesn't say anything about how the distros will package it.
>>>>>
>>>>> I'll admit I haven't been closely involved in the development of this
>>>>> feature, so maybe my quick review of the code missed something that is
>>>>> bringing on this sentiment?
>>>>
>>>> No, you hit the nail on the head. It's nothing with the implementation,
>>>> it's purely with the packaging and having it co-exist within
>>>> ceilometer.
>>>> Since it has its own services, uses Oslo, the CM client and operates
>>>> via
>>>> the public API, it should be able to live outside the main CM codebase.
>>>> My concern is that it has a different mandate than CM (or the CM
>>>> mandate
>>>> is too broad).
>>>>
>>>> What really brought it on for me was doing code reviews for CM and
>>>> hitting all this alarm stuff and thinking "this is mental context
>>>> switch
>>>> from what CM does, it really doesn't belong here." (though I'm happy to
>>>> help out with the reviews)
>>>>
>>>> -S
>>>
>>> Hi Sandy,
>>>
>>> In terms of distro packaging, the case that I'm most familiar (Fedora
>>> & derivatives)
>>> already splits out the ceilometer packaging in a fairly fine-grained
>>> manner (with
>>> separate RPMs for the various services and agents). I'd envisage a
>>> similar packaging
>>> approach will be followed for the alarming services, so for
>>> deployments for which
>>> alarming is not required, this functionality won't be foisted on anyone.
>>
>> Thanks for the feedback Eoghan.
>>
>> I don't imagine that should be a big problem. Packaging in the sense of
>> the code base is different issue. If, for all intents and purposes,
>> alarming is a separate system: uses external api's, only uses sanctioned
>> CM client libraries, is distro packaged separately and optionally
>> installed/deployed then I don't understand why it has to live in the CM
>> codebase?
>>
>>> Now we could think about splitting it out even further to aid the
>>> sort of composability
>>> you desire, however this functionality is needed by Heat, so it makes
>>> sense for it to
>>> live in one of the integrated projects (as opposed to a newly
>>> incubated split-off).
>>
>> I'm not purposing it becomes a newly incubated project. I think it makes
>> sense to live under the CM moniker. But code-wise, it should be a
>> separate repo. This wouldn't pose any problem since -infra already does
>> this with its many repos.
>>
>>> In terms of the context switching required for reviewing alarming
>>> patches, I don't
>>> see that as a huge issue for two reasons:
>>>
>>>  - larger projects such as nova already require immensely greater
>>> context switching
>>>    of it's team of core devs
>>>
>>>  - core devs can and do concentrate their reviewing on some
>>> functional sub-domains,
>>>    i.e. everyone doesn't have to the entire spectrum of patches
>>
>> Having it in a separate repo would lessen the chance of leakage between
>> dependencies. Are there libraries that alarming needs that CM doesn't
>> need? Is the db model growing in ways that aren't core to CM? Is there
> 
> No, alarming has no new depenancies.

You're correct. There are no module dependencies currently. However, the
CM database has alarming specific tables in it and the CM API has alarm
operations exposed in it.

> 
>> greater volatility in the project overall because of the increased
>> number of branches going in? Will new developers have a harder time
>> onboarding due to more code?
>>
>> I think the answer is yes across the board.
> 
> No. It is called community building. The more people you have involved in
> a project the more you can get things done (more bugs fixed etc...).
> It's about people working together.

I don't understand how this is a discussion of community building? I'm
sure the CM team will continue to review alarm patches (myself included)
and new developers that are interested in alarming will continue to jump
in. I think my proposal would, in fact, increase the community adoption
of the alarm effort since it would be a smaller, more focused code base
to learn.

I can think of far more benefits for having alarming as a separate repo
than I can otherwise. Fewer merge conflicts, fewer db migrations for
operators, faster stablizing api, adoption by groups who don't need
monitoring, etc.

>>
>> We're all in agreement that alarming is essentially standalone already
> er, no. There is a rest api and a db api that are built in.
> 
>> ... now it just needs its own repo.
> 
> Huge -1 to this anti-effort.

Sorry, but this is not an anti-effort. It's an effort to make the code
base smaller, more focused and manageable.

If an operator wants to use a different alarm module they shouldn't have
to expose alarm operations in the API or put unused tables in the
production database. That's all.

> We have to move alarming out because you don't like looking at it?
> Dam, this sounds really arrogant.

Once again, I believe you've misread my intent (which is quite likely my
fault since email is such a poor medium). When I say context switch it's
not that I dislike looking at it or my brain is unable to read the code
... it's that my brain keeps saying "this doesn't belong here".

I've repeated stated that I understand the rationale for the alarm
effort, that I will continue to assist it where I can and applaud the
efforts of the team working on it. I'm simply offering a proposal for
making both projects even better.

But, as this is turning into a personal attack and I've offered my
suggestion, I'll drop the thread.

-S


> 
> 
> -Angus
> 
>>> That being said, the efforts of team members such as yourself who
>>> make an obvious
>>> effort to review a wide range of patches, is of course appreciated!
>>> Cheers,
>>> Eoghan
>>>
>>>>
>>>>>
>>>>> Doug
>>>>>
>>>>>
>>>>>
>>>>>     Please, change my view. :)
>>>>>
>>>>>     -S
>>>>>
>>>>>     Side note: I might even argue that the statistical features of
>>>>> CM are
>>>>>     going a little too far. My only counter-argument is that
>>>>> statistics are
>>>>>     the only way to prevent us from sending large amounts of data
>>>>> over the
>>>>>     wire for post-processing. But that's a separate discussion.
>>>>>
>>>>>
>>>>>     _______________________________________________
>>>>>     OpenStack-dev mailing list
>>>>>     OpenStack-dev at lists.openstack.org
>>>>>     <mailto: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