Hi Jay, Lianhao, All,

Sorry if this comes out of order - for some reason I am not receiving the 
messages so I'm cut-and-pasting from the archive :( 

I think I might mean something closer to Brian's blue print (now I've seen it) 
https://blueprints.launchpad.net/nova/+spec/heterogeneous-instance-types 

Really I want to do resource management the way vcpu, memory and disk do. The 
scheduler chooses where to place instances according to an understanding of the 
available and free resources (and updates that when scheduling multiple 
instances, as in the consume_from_instance method of 
nova.scheduler.host_manager.HostState). Likewise, the compute node checks (in 
the test method of nova.compute.claims.Claim ) that they are available before 
accepting an instance. When the instance is created it reports back the usage 
to the database via the resource tracker. This is actually accounting what has 
been allocated, not an on-going measure of what is being used. 

Extra specs can certainly be used, but that does not provide the feedback loop 
between the compute nodes and the scheduler necessary to do the accounting of 
resource consumption.

What I would need for a generic way to do this is plugins at the compute node, 
a way to pass arbitrary resource consumption information back through the 
database, and plugins at the scheduler. So I am going beyond what is described 
here but the basic mechanisms are the same. The alternative is to code in each 
new resource we want to manage (which may not be that many really - but they 
may not be there for all installations).

Interestingly the 
https://blueprints.launchpad.net/nova/+spec/generic-host-state-for-scheduler 
blueprint (referenced in the patch) does talk about going to ceilometer. And 
that does seem to make sense to me. 

BTW, I'm getting all the other emails - just not this thread!

Bemused...
Paul


On 07/18/2013 10:44 AM, Murray, Paul (HP Cloud Services) wrote:
> Hi All,
>
> I would like to chip in with something from the side here (sorry to stretch 
> the discussion out).
>
> I was looking for a mechanism to do something like this in the context of 
> this blueprint on network aware scheduling: 
> https://blueprints.launchpad.net/nova/+spec/network-bandwidth-entitlement 
> Essentially the problem is that I need to add network bandwidth resource 
> allocation information just like vcpu, memory and disk space already has. I 
> could hard code this just as they are, but I can also think of a couple of 
> others we would like to add that may be more specific to a given 
> installation. So I could do with a generic way to feed this information back 
> from the compute node to the scheduler just like this.
>
> However, my use case is not the same - it is not meant to be for 
> monitored/statistical utilization info. But I would like a similar mechanism 
> to allow the scheduler to keep track of more general / extensible resource 
> allocation.

How is that a different use case from Lianhao's? You mean instead of 
collected usage metrics you want to allocate based on the value of a 
transient statistic like current network bandwidth utilisation?

> Do you have any thoughts on that? Again, don't mean to deflect the discussion 
> - just I have another use case.

I tend to agree with both Brian and Sean on this. I agree with Sean in 
that it seems duplicative to store compute_node_resources in the Nova 
database when a simple REST call to Ceilometer would avoid the 
duplication. And I agree with Brian that the extra_specs scheduler 
filters seem like they would fit the "check a current bandwidth 
statistic" type use case you describe above, Paul.

Best,
-jay

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to