+1 On Wed, May 2, 2012 at 6:28 AM, Loic Dachary <l...@enovance.com> wrote:
> On 05/01/2012 09:57 PM, Andrew Clay Shafer wrote: > > I'm glad to see people championing the effort to implement metering. Is > there someway to refocus the enthusiasm for solving the metering problem > into engineering a general solution in OpenStack? > > > > I'm just going to apologize in advance, but I don't think this project > is headed in the right direction. > > > > I believe metering should be a first class concern of OpenStack and the > way this project is starting is almost exactly backwards from what I think > a solution to metering should look like. > > > > The last thing I want to see right now is a blessed OpenStack metering > project adding more agents, coupled to a particular db and making policy > decisions about what is quantifiable. > > > > I think there are really three problems that need to be solved to do > metering, what data to get, getting the data and doing things with the data. > > > > From my perspective, a lot if not all of the data events should be > coming out of the services themselves. There is already a service that > should know when an instance gets started by what tenant. A cross cutting > system for publishing those events and a service definition for collecting > them seems like a reasonable place to start. To me that should look awful > lot like a message queue or centralized logging. Once the first two > problems are solved well, if you are so inclined to collect the data into a > relational model, the schema will be obvious. > > > > If the first two problems are solved well, then I could be persuaded > that a service that provides some of the aggregation functionality is a > great idea and a reference implementation on a relational database isn't > the worst thing in the world. > > > > Without a general solution for the first two problems, I believe the > primary focus on a schema and db is premature and sub-optimal. I also > believe the current approach likely results in a project that is generally > unusable. > > > > Does anyone else share my perspective? > It would be better if all OpenStack core components agreed on unified > interfaces / messages for metering that would be easy to harvest without > installing agents on nodes. This is also true for many services outside of > the OpenStack eco-system. However, much in the same way munin and nagios > plugins are developped outside of the project for which they provide > graphing and monitoring (for instance we recently published swift munin > plugins in the repository where ops usually look for them : > https://github.com/munin-monitoring/contrib/tree/master/plugins/swift and > there is no glance plugin or up-to-date nova plugins yet ), metering agents > will be developed separately, most of the time. > > As I wrote in a previous mail, once we manage to provide an implementation > that proves useful, we will be in a position to approach the core OpenStack > components. Integrating the metering agents as part of the core component, > much in the same way it's currently done in nova. That will reduce the > overall complexity of deploying OpenStack with metering (which must not be > mandatory). However, there is very little chance that all components > developed around OpenStack are convinced and there will always be a need > for a metering that is external to the component. Therefore, even if > metering eventually manages to become a first class concern for the core > OpenStack components, the proposed architecture of the metering project ( > per node agents when necessary and a collector harvesting them into a > storage ) will keep being used for other components. > > Do you think I'm wrong ? We're at a very early stage and now is the time > to question everything :-) > > > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
