Open Stack

Sandy Walsh wrote on 2013-07-19:

> 
> 
> On 07/19/2013 09:47 AM, Day, Phil wrote:
>>> -----Original Message-----
>>> From: Sean Dague [mailto:sean at dague.net]
>>> 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
>> 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