Open Stack

On 04/08/2019 10:25 AM, Chris Dent wrote:
> 
>  From the etherpad [1]:
> 
> * do we need this?
> * what is it?
> * who is going to drive it?
> 
> As as I recall, allocation partitioning (distinct from
> resource provider partitioning) is a way of declaring that a set of
> allocations below to a specific service. This is useful as a way,
> for example, of counting instances spawned via nova. Right now it is
> possible to count vcpus, ram and disk but if something besides nova
> is making allocations using those resource classes how do we
> distinguish?

This is more "consumer type" than anything else. In order to satisfy 
usage requests for certain classes of quota (really, just "num 
instances"), we need to know which consumers in the consumers table are 
"Nova instances" and which are not.

Obviously, all consumers are currently Nova instances in placement since 
(AFAIK) no other services have begun using placement to store allocations.

And because placement doesn't have such concepts as "local deleted" or 
"soft deleted allocations" we could actually accurately count the number 
of instances using a single simple query:

  SELECT COUNT(DISTINCT a.consumer_id)
  FROM allocations AS a
  JOIN consumers AS c
  ON a.consumer_id = c.id
  WHERE c.project_id = $PROJECT_ID
  AND c.type_id = $NOVA_INSTANCE_TYPE_ID;

> Of course it's important to also ask "should we distinguish?". If
> there's a concept of unified limits does it matter whether a VCPU is
> consume by _this_ nova or something else if they are consumed by the
> same user?

So this is referring to resource provider partition (source partition), 
not consumer type. For the problem of detecting whether an instance is 
in *this* Nova or another Nova deployment that uses the same placement 
service, we need a source partition identifier in the resource_providers 
table.

Also keep in mind that Keystone's unified limits are still divisible by 
*region*, which would serve as a natural source partition identifier I 
suppose.

> This functionality is closely tied to resource provider
> partitioning. In a complex placement scenario, where placement is
> managing multiple instance spawning tools, in multiple cloud-like
> things, it seems like both would be needed.

Yes, this. In order to get the number of Nova instances in a specific 
deployment of Nova (or region), the above query would instead look like 
this:

  SELECT COUNT(DISTINCT a.consumer_id)
  FROM allocations AS a
  JOIN consumers AS c
  ON a.consumer_id = c.id
  JOIN resource_providers AS rp
  ON a.resource_provider_id
  WHERE c.project_id = $PROJECT_ID
  AND c.type_id = $NOVA_INSTANCE_TYPE_ID
  AND rp.source_partition_id = $NOVA_REGION_ID;

> The ongoing work to implement quota counting in placement [2] has a
> workaround for instances not being counted in placement, but the
> "more than one nova per placement" limitation has to be documented.
> 
> How urgent is this? Is there anyone available to do the work this
> cycle? How damaging is it to punt to U? What details are missing in
> the above description?

Not sure of the answers to this question. As with most features like 
this, 95% of the work seems to end up being in the upgrade path and not 
adding the feature itself. For both the consumer type and source 
partition identification, the upgrade path would entail setting default 
consumer type for all existing consumers and source partition 
identifiers for all existing resource providers.

Best,
-jay

> [1] https://etherpad.openstack.org/p/placement-ptg-train
> [2] 
> https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement
>