<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Jan 16, 2019 at 8:33 PM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 1/14/2019 12:01 PM, Chris Dent wrote:<br>
> As discussed in the recent pupdate [1] there will be a meeting this<br>
> Wednesday at 1700 UTC to discuss the current state of the placement<br>
> extraction and get some idea on the critical items that need to be<br>
> addressed to feel comfy.<br>
> <br>
> If you're interested in this topic, meet near that time in the<br>
> #openstack-placement IRC channel and someone will produce links<br>
> for a hangout, etherpad, whatever is required.<br>
> <br>
> Thanks.<br>
> <br>
> [1] <br>
> <a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001666.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001666.html</a><br>
<br>
Here is my attempt at summarizing the call we had. Notes are in the <br>
etherpad [1].<br>
<br></blockquote><div><br></div><div>Thanks for the notes. I apologize but I had other things to do at that time which led me unable to attend this call.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Deployment tools:<br>
<br>
* Lee is working on TripleO support for extracted placement and <br>
estimates 3 more weeks for just deploy (base install) support to be <br>
done, and at least 3 more weeks for upgrade support after that. Read <br>
Lee's status update for details [2].<br>
* If nova were to go ahead and drop placement code and require extracted <br>
placement before TripleO is ready, they would have to pin nova to a git <br>
SHA before that which would delay their Stein release.<br>
* Having the extraction span release boundaries would ease the upgrade <br>
pain for TripleO.<br>
<br></blockquote><div><br></div><div>That sounds a reasonable trade-off IMHO.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Nested providers / reshaper / VGPU:<br>
<br>
* VGPU reshaper work for nested resource providers in libvirt and xenapi <br>
drivers has stalled and there is still hesitation to move forward with <br>
extracting placement before that reshape flow, including in an upgrade, <br>
is tested to know that nova does not need any last minute data <br>
migrations which require direct access to the placement database. In <br>
other words, we have not yet confirmed that the placement reshaper API <br>
will be fully sufficient until a real driver is using it.<br>
* Matt (me!) has agreed to rebase and address the comments on the <br>
libvirt patch [3] to try and push that forward.<br></blockquote><div><br></div><div>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.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* We still need someone to write a functional test which creates a <br>
server with a flat resource structure, reshapes that to nested, and then <br>
creates another server against the same provider tree.<br>
<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Data migration:<br>
<br>
* The only placement-specific online data migration in nova is <br>
"create_incomplete_consumers" and we agreed to copy that into placement <br>
and add a placement-status upgrade check for it. The data migration code <br>
will build on top of Tetsuro's work [4]. Matt is signed up to work on <br>
both of those commands.<br>
<br>
Miscellaneous:<br>
<br>
* Placement release notes will start at the current release and <br>
reference the nova release notes for anything older (Ocata->Rocky).<br>
* Chris is already working on some other things like docs and small <br>
governance changes (os-traits), but those are all on hold until the <br>
placement code in nova is dropped which is dependent on the deployment <br>
tooling support and reshaper changes above.<br>
* We agreed to checkpoint again in three weeks so Wednesday February 6 <br>
at let's say the same time, 1700 UTC.<br>
<br></blockquote><div><br></div><div>Worth adding it in agendas, then.</div><div><br></div><div>-Sylvain</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[1] <a href="https://etherpad.openstack.org/p/placement-extract-stein-5" rel="noreferrer" target="_blank">https://etherpad.openstack.org/p/placement-extract-stein-5</a><br>
[2] <br>
<a href="http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001783.html" rel="noreferrer" target="_blank">http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001783.html</a><br>
[3] <a href="https://review.openstack.org/#/c/599208/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/599208/</a><br>
[4] <a href="https://review.openstack.org/#/c/624942/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/624942/</a><br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
</blockquote></div></div>