Sandy Walsh wrote on 2013-07-19: > > > On 07/19/2013 09:47 AM, Day, Phil wrote: >>> -----Original Message----- >>> From: Sean Dague [mailto:[email protected]] >>> Sent: 19 July 2013 12:04 >>> To: OpenStack Development Mailing List >>> Subject: Re: [openstack-dev] [Nova] Ceilometer vs. Nova internal metrics >>> collector for scheduling (was: New DB column or new DB table?) >>> >>> On 07/19/2013 06:18 AM, Day, Phil wrote: >>>> Ceilometer is a great project for taking metrics available in Nova and >>>> other >>> systems and making them available for use by Operations, Billing, >>> Monitoring, etc - and clearly we should try and avoid having multiple >>> collectors of the same data. >>>> >>>> But making the Nova scheduler dependent on Ceilometer seems to be the >>> wrong way round to me - scheduling is such a fundamental operation that I >>> want Nova to be self sufficient in this regard. In particular I don't >>> want the >>> availability of my core compute platform to be constrained by the >>> availability >>> of my (still evolving) monitoring system. >>>> >>>> If Ceilometer can be fed from the data used by the Nova scheduler then > that's >>> a good plus - but not the other way round. >>> >>> I assume it would gracefully degrade to the existing static allocators if >>> something went wrong. If not, well that would be very bad. >>> >>> Ceilometer is an integrated project in Havana. Utilization based >>> scheduling would be a new feature. I'm not sure why we think that >>> duplicating the metrics collectors in new code would be less buggy >>> than working with Ceilometer. Nova depends on external projects all >>> the time. >>> >>> If we have a concern about robustness here, we should be working as an >>> overall project to address that. >>> >>> -Sean >>> >> Just to be cleat its about a lot more than just robustness in the code - its >> the > whole architectural pattern of putting Ceilometer at the centre of Nova > scheduling that concerns me. >> >> As I understand it Celiometer can collect metrics from more than one copy of > Nova - which is good; I want to run multiple independent copies in different > regions and I want to have all of my monitoring data going back to one place. > However that doesn't mean that I now also want all of those independent copies > of Nova depending on that central monitoring infrastructure for something as > basic as scheduling. (I don't want to stop anyone that does either - but I > don't > see why I should be forced down that route). >> >> The original change that sparked this debate came not from anything to do > with utilisation based scheduling, but the pretty basic and simple desire to > add > new types of consumable resource counters into the scheduler logic in a more > general way that having to make a DB schema change. This was generally > agreed to be a good thing, and it pains me to see that valuable work now > blocked > on what seems to be turning into an strategic discussion around the role of > Ceilometer (Is it a monitoring tool or a fundamental metric bus, etc). >> >> At the point where Ceilomter can be shown to replace the current scheduler > resource mgmt code in Nova, then we should be talking about switching to it - > but in the meantime why can't we continue to have incremental improvements > in the current Nova code ? > > +1
+1 We can keep discussion to determine R&R for Nova and Ceilometer. Can we have a decision to make so we can move forward to have incremental improvements in Nova? Thanks. -- Shane > >> >> Cheers >> Phil >> >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
