Re: [openstack-dev] [nova][placement] Freezing placement for extraction
> If we're going to do the extraction in Stien, which we said we'd do in > Dublin, we need to start that as early as possible to iron out any > deployment bugs in the switch. We can't wait until the 2nd or 3rd > milestone, it would be too risky. I agree that the current extraction plan is highly risky and that if it's going to happen, we need plenty of time to clean up the mess. I imagine what Sylvain is getting at here is that if we followed the process of other splits like nova-volume, we'd be doing this differently. In that case, we'd freeze late in the cycle when freezing is appropriate anyway. We'd split out placement such that the nova-integrated one and the separate one are equivalent, and do the work to get it working on its own. In the next cycle new changes go to the split placement only. Operators are able to upgrade to stein without deploying a new stein service first, and can switch to the split placement at their leisure, separate from the release upgrade process. To be honest, I'm not sure how we got to the point of considering it acceptable to be splitting out a piece of nova in a single cycle such that operators have to deploy a new thing in order to upgrade. But alas, as has been said, this is politically more important than ... everything else. --Dan __ 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
Re: [openstack-dev] [nova][placement] Freezing placement for extraction
On 8/31/2018 9:41 AM, Sylvain Bauza wrote: Apologies for having missed the large and wide discussions about placement future in the past weeks. I was off so I just saw the consensus yesterday evening my time. Now that disclaimer is done, can I know the reasoning why we call the freeze as of now and not waiting for either Stein-2 or Stein-3 ? If we're going to do the extraction in Stien, which we said we'd do in Dublin, we need to start that as early as possible to iron out any deployment bugs in the switch. We can't wait until the 2nd or 3rd milestone, it would be too risky. My main concern is that the reshaper series is still being reviewed for Nova. Some other changes using Placement (like drivers using nested Resource Providers and the likes) are also not yet implemented (or even be uploaded) and I'm a bit afraid of us discovering yet another cross-services problem (say with having two distinct computes having different versions) that would make the fix more harder than just fixing directly. The Placement-side changes for the reshaper changes are merged. The framework code for compute is either merged or on it's way. The outstanding changes for reshaper are: 1. libvirt and xenapi driver changes to use it - remember me emailing you and the xen team about this last week? We couldn't hold up the existing patches forever. 2. The offline migration stuff for FFU (I believe Dan was signed up for that). 3. Docs and whatever other polishing is needed. So there is nothing related to reshaper that should block Placement extraction happening at this point. Sure we could hit some very weird bug once the driver implementation happens - that's a risk we talked about last week when we removed the -2 from the Placement API change, but again, without people around to work on the driver changes, we can't just sit and hold forever because that pushes out the extraction which makes delivering a smooth upgrade for the extraction during stein riskier, so pick your poison. -- Thanks, Matt __ 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
Re: [openstack-dev] [nova][placement] Freezing placement for extraction
On Thu, Aug 30, 2018 at 6:34 PM, Eric Fried wrote: > Greetings. > > The captains of placement extraction have declared readiness to begin > the process of seeding the new repository (once [1] has finished > merging). As such, we are freezing development in the affected portions > of the openstack/nova repository until this process is completed. We're > relying on our active placement reviewers noticing any patches that > touch these "affected portions" and, if that reviewer is not a nova > core, bringing them to the attention of one, so we can put a -2 on it. > > Apologies for having missed the large and wide discussions about placement future in the past weeks. I was off so I just saw the consensus yesterday evening my time. Now that disclaimer is done, can I know the reasoning why we call the freeze as of now and not waiting for either Stein-2 or Stein-3 ? My main concern is that the reshaper series is still being reviewed for Nova. Some other changes using Placement (like drivers using nested Resource Providers and the likes) are also not yet implemented (or even be uploaded) and I'm a bit afraid of us discovering yet another cross-services problem (say with having two distinct computes having different versions) that would make the fix more harder than just fixing directly. > Once the extraction is complete [2], any such frozen patches should be > abandoned and reproposed to the openstack/placement repository. > > Since there will be an interval during which placement code will exist > in both repositories, but before $world has cut over to using > openstack/placement, it is possible that some crucial fix will still > need to be merged into the openstack/nova side. In this case, the fix > must be proposed to *both* repositories, and the justification for its > existence in openstack/nova made clear. > > We surely can do such things for small fixes that don't impact a lot of files. What I'm a bit afraid of is any large change that would get some merge conflicts. Sure, we can find ways to fix it too, but again, why shouldn't we just wait for Stein-2 ? -Sylvain (yet again apologies for the late opinion). For more details on the technical aspects of the extraction process, > refer to this thread [3]. > > For information on the procedural/governance process we will be > following, see [4]. > > Please let us know if you have any questions or concerns, either via > this thread or in #openstack-placement. > > [1] https://review.openstack.org/#/c/597220/ > [2] meaning that we've merged the initial glut of patches necessary to > repath everything and get tests passing > [3] > http://lists.openstack.org/pipermail/openstack-dev/2018-August/133781.html > [4] https://docs.openstack.org/infra/manual/creators.html > > __ > 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 > __ 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
