On Fri, 17 Aug 2018 16:51:10 +0100 (BST), Chris Dent wrote:
Earlier I posted a message about a planning etherpad for the
extraction of placement
http://lists.openstack.org/pipermail/openstack-dev/2018-August/133319.html
https://etherpad.openstack.org/p/placement-extract-stein
One of the goals of doing the planning and having the etherpad was
to be able to get to the PTG with some of the issues resolved so
that what little time we had at the PTG could be devoted to
resolving any difficult technical details we uncovered in the lead
up.
One of the questions that has come up on the etherpad is about how
placement should be positioned, as a project, after the extraction.
The options are:
* A repo within the compute project
* Its own project, either:
* working towards being official and governed
* official and governed from the start
The etherpad has some discussion about this, but since that etherpad
is primarily for listing out the technical concerns I thought it
might be useful to bring the discussion out into a wider audience,
in a medium more oriented towards discussion. As placement is a
service targeted to serving the entire OpenStack community, talking
about it widely seems warranted.
The outcome I'd like to see happen is the one that makes sure
placement becomes useful to the most people and is worked on by the
most people, as quickly as possible. If how it is arranged as a
project will impact that, now is a good time to figure that out.
If you have thoughts about this, please share them in response.
Thanks for kicking off this discussion, Chris.
I'd like to see placement extracted as a repo within the compute
project, as a start. My thinking is, placement was developed to solve
several long-standing problems and limitations in Nova (including poor
filter scheduler performance, parallel scheduling races, resource
tracker issues, and shared storage accounting, just to name a few).
We've seen exciting progress in finally solving a lot of these issues as
we've been developing placement. But, there is still a significant
amount of important work to do in Nova that depends on placement. For
example, we need to integrate nested resource providers into the virt
drivers in Nova to leverage it for vGPUs and NUMA modeling. We need
affinity modeling in placement to properly handle affinity with multiple
cells. We need shared storage accounting to properly handle disk usage
for deployments on shared storage.
As we've worked to develop placement and use it in Nova, we've found in
most cases that we've had to develop the Nova side and the placement
side together, at the same time, to make things work. This isn't really
surprising, as with any brand new functionality, it's difficult to
fulfill a use case completely without integrating things together and
iterating until everything works. Given that, I'd rather see placement
stay under compute so we can iterate quickly, as we still need to
develop new features in placement and exercise them for the first time,
in Nova. Once the major aforementioned efforts have been figured out and
landed with close coordination, I think it would make more sense to look
at placement being outside of the compute project.
Cheers,
-melanie
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
