Open Stack

On 4/26/2019 8:50 AM, Jay Bryant wrote:
> The team has talked about this a little bit in our team meetings.  We 
> had previously talked to the placement team about how it could benefit 
> Cinder and I think we had reach the conclusion that there wasn't really 
> any benefit that Cinder could get from placement.
> 
> I think, however, the open item is if Placement can benefit from Cinder 
> if we were to make available volume and storage backend information to 
> Placement.  If so we would need to understand the work involved.
> 
> It might be worth planning some cross project time at the PTG just to 
> sync up on where things are at.  Let me know if you are interested in 
> doing this.

Modeling AZ affinity in a central location (placement) between compute 
nodes and volumes would likely benefit the wonky 
[cinder]/cross_az_attach and related config options in cinder. We have a 
class of bugs in nova when that is enforced (cross_az_attach=False) 
which maybe useful for HPC and Edge workloads, but isn't tested or 
supported very well at this time. Granted, it might be as simple as 
reporting volumes (or their backend pool) as a resource provider and 
then putting that provider and the compute node provider in a resource 
provider aggregate (sort of like how we model [but don't yet use] shared 
DISK_GB resources). My thinking is if you had that modeled and nova is 
configured with cross_az_attach=False, and a server is created with some 
pre-existing volumes, the nova scheduler translates that to a request to 
placement for compute nodes only in the aggregate with whatever storage 
backend is providing those volume resources (the same AZ essentially). 
But this is probably low priority and arguably re-inventing an already 
somewhat broken wheel. Would have to think about how doing this with 
placement would be superior to what we have today.

-- 

Thanks,

Matt