osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[placement][ptg] Summary of Summaries


I produced several summary messages at the end of the PTG [1] but
then disappeared into a dark corporate belly, so I thought it might
be useful to do a quick check in to assert and verify some status.
I'll be doing a full pupdate on Friday. If any of the below doesn't
align with your memories, please let me know.

At the end the PTG there were some open questions about priorities
so I produced an etherpad listing all the existing RFE stories along
with the new ones produced by discussions at the PTG and asked
people to register their preferences. Thus far only three people
(including me) have voted. Please look at

     https://etherpad.openstack.org/p/placement-ptg-train-rfe-voter

to register your input. As things currently stand our priorities
are what you would expect based on who is available to work and the
work that needs to be done to be able to satisfy other projects'
dependencies on placement:

* Consumer types, spec at: https://review.opendev.org/#/c/654799/
* Nested things:
     * request group mapping in allocation candidates:
       https://review.opendev.org/#/c/657582/
     * the remaining "nested magic:
       https://review.opendev.org/#/c/658510/

The latter is a WIP and will almost certainly need someone besides
Eric to finish it off. Multiple inter-related features will come out
of that. See the related story [2].

"support any trait in allocation candidates" and "support mixing
required traits with any traits" are still under review but have
been de-emphasized. If we're able to get to them that's great, but
they are not critical. Same is also true for managing a
local-to-placement container.

Since the PTG several of us have recognized/acknowledged a thing we
already pretty much knew: Queries for nested providers in a highly
populated but sparsely used cloud will be less performant than
desired. There are things we can do to monitor and fix this. Tetsuro
has already started some changes [3] and in the gaps I'm working on
making changes to placeload [4] to build nested providers to be used
in the perfload job.

"Support resource provider partitioning" is also being
de-emphasized, but based on several recent conversations I suspect
we will want it soon, and any performance improvements we get before
then will be important.

So, to summarize this summary of summaries:

Look at https://etherpad.openstack.org/p/placement-ptg-train-rfe-voter
and review the three specs above. If you think other priorities are
necessary please speak up and explain why.

Thanks to everyone for their participation in the PTG and especially
the virtual pre-PTG. We got a lot figured out and were still able to
attend other sessions.

[1]
* Nested magic: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005823.html
* Shared disk: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005829.html
* Consumer Types: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005878.html
* Placement, Ironic, Blazar: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/005880.html

[2] https://storyboard.openstack.org/#!/story/2005575
[3] https://review.opendev.org/#/c/658977/
[4] https://pypi.org/project/placeload/

-- 
Chris Dent                       Ù©â??̯â??Û¶           https://anticdent.org/
freenode: cdent                                         tw: @anticdent