Open Stack

On Wed, Jan 16, 2019 at 8:33 PM Matt Riedemann <mriedemos at gmail.com> wrote:

> On 1/14/2019 12:01 PM, Chris Dent wrote:
> > As discussed in the recent pupdate [1] there will be a meeting this
> > Wednesday at 1700 UTC to discuss the current state of the placement
> > extraction and get some idea on the critical items that need to be
> > addressed to feel comfy.
> >
> > If you're interested in this topic, meet near that time in the
> > #openstack-placement IRC channel and someone will produce links
> > for a hangout, etherpad, whatever is required.
> >
> > Thanks.
> >
> > [1]
> >
> http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001666.html
>
> Here is my attempt at summarizing the call we had. Notes are in the
> etherpad [1].
>
>
Thanks for the notes. I apologize but I had other things to do at that time
which led me unable to attend this call.

Deployment tools:
>
> * Lee is working on TripleO support for extracted placement and
> estimates 3 more weeks for just deploy (base install) support to be
> done, and at least 3 more weeks for upgrade support after that. Read
> Lee's status update for details [2].
> * If nova were to go ahead and drop placement code and require extracted
> placement before TripleO is ready, they would have to pin nova to a git
> SHA before that which would delay their Stein release.
> * Having the extraction span release boundaries would ease the upgrade
> pain for TripleO.
>
>
That sounds a reasonable trade-off IMHO.

Nested providers / reshaper / VGPU:
>
> * VGPU reshaper work for nested resource providers in libvirt and xenapi
> drivers has stalled and there is still hesitation to move forward with
> extracting placement before that reshape flow, including in an upgrade,
> is tested to know that nova does not need any last minute data
> migrations which require direct access to the placement database. In
> other words, we have not yet confirmed that the placement reshaper API
> will be fully sufficient until a real driver is using it.
> * Matt (me!) has agreed to rebase and address the comments on the
> libvirt patch [3] to try and push that forward.
>

Thanks Matt for it. The rebase should be quite easy-forward since it's just
a matter of exploding methods into smaller ones, but devil can be in
details and some UTs could require some extra work.

* We still need someone to write a functional test which creates a
> server with a flat resource structure, reshapes that to nested, and then
> creates another server against the same provider tree.
>
>
I won't be on perpetual PTO like I was in December/early January and I
certainly hope to finish all my internal/customer duties hopefully next
week (or the customer wouldn't be happy). So, if you still trust me about
havint time for upstream, this is then the priority for me.


Data migration:
>
> * The only placement-specific online data migration in nova is
> "create_incomplete_consumers" and we agreed to copy that into placement
> and add a placement-status upgrade check for it. The data migration code
> will build on top of Tetsuro's work [4]. Matt is signed up to work on
> both of those commands.
>
> Miscellaneous:
>
> * Placement release notes will start at the current release and
> reference the nova release notes for anything older (Ocata->Rocky).
> * Chris is already working on some other things like docs and small
> governance changes (os-traits), but those are all on hold until the
> placement code in nova is dropped which is dependent on the deployment
> tooling support and reshaper changes above.
> * We agreed to checkpoint again in three weeks so Wednesday February 6
> at let's say the same time, 1700 UTC.
>
>
Worth adding it in agendas, then.

-Sylvain

[1] https://etherpad.openstack.org/p/placement-extract-stein-5
> [2]
>
> http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001783.html
> [3] https://review.openstack.org/#/c/599208/
> [4] https://review.openstack.org/#/c/624942/
>
> --
>
> Thanks,
>
> Matt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190117/3e39befb/attachment-0001.html>