<div dir="ltr"><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>I already told about that in a separate thread, but let's put it here too for more visibility.<br><br></div><div>tl;dr: I suspect existing allocations are being lost when we upgrade a compute service from Queens to Rocky, if those allocations are made against inventories that are now provided by a child Resource Provider.<br><br><br></div>I started reviewing <a href="https://review.openstack.org/#/c/565487/">https://review.openstack.org/#/c/565487/</a> and bottom patches to understand the logic with querying nested resource providers. From what I understand, the scheduler will query Placement using the same query but will get (thanks to a new microversion) not only allocation candidates that are root resource providers but also any possible child.<br></div><br></div>If so, that's great as in a rolling upgrade scenario with mixed computes (both Queens and Rocky), we will still continue to return both old RPs and new child RPs if they both support the same resource classes ask.<br>Accordingly, allocations done by the scheduler will be made against the corresponding Resource Provider, whether it's a root RP (old way) or a child RP (new way).<br></div><br></div>Do I still understand correctly ? If yes, perfect, let's jump to my upgrade concern.<br></div>Now, consider the Queens->Rocky compute upgrade. If I'm an operator and I start deploying Rocky on one compute node, it will provide to Placement API new inventories that are possibly nested.<br></div>In that situation, say for example with VGPU inventories, that would mean that the compute node would stop reporting inventories for its root RP, but would rather report inventories for at least one single child RP.<br></div>In that model, do we reconcile the allocations that were already made against the "root RP" inventory ? I don't think so, hence my question here. <br><div><div><div><div><div><br></div><div>Thanks,<br></div><div>-Sylvain<br><br></div></div></div></div></div></div>