Open Stack

From: Angus Salkeld [asalkeld at redhat.com]
Sent: Sunday, November 18, 2012 6:32 PM

>>Well, now we're getting to the crux of the matter and one that I brought up in the IRC meeting yesterday. My concern is that ceilometer is becoming a kitchen sink for this stuff. Two summits ago the mandate was clear "There is no billing, we need billing, so let's build this ..." (I remember because I suggested to look at Yagi/StackTach/Tach back then). This was also the impetus for the "integration" proposal as I saw the scope widening. To have ceilometer become a set of low-level tools that can be used to get data out and away from core OpenStack services and a basis for other tools to build upon (Heat, CloudWatch/Synaps, StackTach, etc). Tools of this sort are vitally important to a successful OpenStack deployment, but it should be mix-and-match or "your mileage may vary".

>I don't think that approach helps users. When there is no clear official solution
then it's up to the deployer to somehow go and find and evaluate these projects?
That doesn't make sense to me. I think we should be making it super easy for
people to deploy OpenStack. Of course this doesn't mean that it's the only
solution just an obvious one.

>I understand your concern (re: putting too much in one project), but in this
case I am not sure it's so bad as the complexity of each is not great. If we
put billing and Monitoring/alarming into the same project it would not be
complex project.

Yeah, sorry, I think I framed that poorly. Ultimately it's just a naming concern. Ceilometer is a great name and already has the eye of the foundation and effort around CI, Versioning, etc. I guess my proposal would be a different/separate library that does the low level stuff and Ceilometer can be the "all dancing" layer on top of it. But, if someone else wants to use StackTach or Synaps or whatever, they still could. And these would be built on the "yet unnamed" common layer. 

But again, there needs to be a separation of these two layers in some fashion. 

>>
>>I think ceilometer should be a smaller, more tightly focused collection of utilities, vs. trying to be all things to all people.

>I think a bigger project pulls in a bigger community and makes it more successful
in the long run.

I can see that argument. I wonder how many would build on the upper layer vs the lower level described above?

>>If a project like Heat runs into problems with something like the RBAC mechanism or the polling interval from Compute, that would be the Ceilometer teams job to broker a solution with Core and expose that solution to everyone.
>>
>>The Rackspace Linux/Windows agents for Xen are open sourced:
>>https://github.com/rackspace/openstack-guest-agents-windows-xenserver
>>https://github.com/rackspace/openstack-guest-agents-unix

>It is not easy to get people to install guest agents that you want, it
is far easier to provide an api for them to use and an example implementation
of using that api. For some reason guest agents seem to be a sensitive issue.

>So this is part of the api that CloudWatch provides to post stats back to the
Monitoring service.

Anything you install in user space is an agent. There may be differing degrees of how invasive they are (ie. rootkits). If you want to collect data from the users perspective you pretty well have to. And, there are often efficiencies to be gained (for example, the way the above agents use in-memory XenStore to move data between user/host space).

-S