[placement] update 19-12
HTML: https://anticdent.org/placement-update-19-12.html Placement update 19-12. Nearing 1/4 of the way through the year. I won't be around on Monday, if someone else can chair the [meeting](http://eavesdrop.openstack.org/#Placement_Team_Meeting) that would be great. Or feel free to cancel it. # Most Important An RC2 was cut earlier this week, expecting it to be the last, but there are a [couple of patches](https://review.openstack.org/#/q/project:openstack/placement+branch:stable/s...) which could be put in an RC3 if we were inclined that way. Discuss. We merged a first suite of [contribution guidelines](https://docs.openstack.org/placement/latest/contributor/contributing.html). These are worth reading as they explain how to manage bugs, start new features, and be a good reviewer. Because of the introduction of StoryBoard, processes are different from what you may have been used to in Nova. Because of limited time and space and conflicting responsibilities the Placement team will be doing a [Virtual Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004225.htm...). # What's Changed * The contribution guidelines linked above describe how to manage specs, which will now be in-tree. If you have a spec to propose or re-propose (from stein in nova), it now goes in ``doc/source/specs/train/approved/``. * Some [image type traits](https://review.openstack.org/648147) have merged (to be used in a nova-side request pre-filter), but the change has exposed an issue we'll need to resolve: os-traits and os-resource-classes are under the cycle-with-intermediary style release which means that at this time in the cycle it is difficult to make a release which can delay work. We could switch to independent. This would make sense for libraries that are basically lists of strings. It's hard to break that. We could also investigate making os-traits and os-resource-classes required-projects in job templates in zuul. This would allow them to be "tox siblings". Or we could wait. Please express an opinion if you have one. * In discussion in `#openstack-nova` about the patch to [delete placement from nova](https://review.openstack.org/#/c/618215/), it was decided that rather than merge that after the final RC, we would wait until the PTG. There is discussion on the patch which attempts to explain the reasons why. # Specs/Blueprint/Features * The spec for [forbidden aggregate membership](https://docs.openstack.org/placement/latest/specs/train/approved/2005297-neg...) has merged. * The two traits-related specs from stein will need to be re-proposed to placement for train: * [any traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approved/placeme...) * [mixing required traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approved/placeme...) * The spec for [request group mapping](https://review.openstack.org/597601) will need to be revisited. # Bugs * StoryBoard stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement): 4 * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 14. * [In progress placement bugs](https://goo.gl/vzGGDQ) 7. +1. We should do a bug squash day at some point. Should we wait until after the PTG or no? Note that the [contribution guidelines](https://docs.openstack.org/placement/latest/contributor/contributing.html) has some information on how to evaluate new stories and what tags to add. # osc-placement osc-placement is currently behind by 13 microversions. Pending changes: * [support for 1.19](https://review.openstack.org/#/c/641094/) * [support for 1.21](https://review.openstack.org/#/c/641123/) * [aggregate allocation ratio tool](https://review.openstack.org/#/c/640898/) # Main Themes Be thinking about what you'd like the main themes to be. Put them on the [PTG etherpad](https://etherpad.openstack.org/p/placement-ptg-train). # Other Placement * <https://review.openstack.org/#/q/topic:2005297-negative-aggregate-membership> Negative member of aggregate filtering resource providers and allocation candidates. This is nearly ready. * <https://review.openstack.org/#/c/645255/> This is a start at unit tests for the PlacementFixture. It is proving a bit "fun" to get right, as there are many layers involved. Making sure seemingly unrelated changes in placement don't break the nova gate is important. Besides these unit tests, there's discussion on the PTG etherpad of running the nova functional tests, or a subset thereof, in placement's check run. On the one hand this is a pain and messy, but on the other consider what we're enabling: Functional tests that use the real functionality of an external service (real data, real web requests), not stubs or fakes. * <https://review.openstack.org/641404> Use ``code`` role in api-ref titles # Other Service Users There's a lot here, but it is certain this is not all of it. If I missed something you care about, followup mentioning it. * <https://review.openstack.org/552924> Nova: Spec: Proposes NUMA topology with RPs * <https://review.openstack.org/622893> Nova: Spec: Virtual persistent memory libvirt driver implementation * <https://review.openstack.org/641899> Nova: Check compute_node existence in when nova-compute reports info to placement * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1790204> Workaround doubling allocations on resize * <https://review.openstack.org/555081> Nova: Spec: Standardize CPU resource tracking * <https://review.openstack.org/646029> Nova: Spec: Use in_tree getting allocation candidates * <https://review.openstack.org/645316> Nova: Pre-filter hosts based on multiattach volume support * <https://review.openstack.org/606199> Ironic: A fresh way of looking at step retrieval * <https://review.openstack.org/647396> Nova: Add flavor to requested_resources in RequestSpec * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/640080> Nova: Use aggregate_add_host in nova-manage * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Nova: count quota usage from placement * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/648500> Tempest: Init placement client in tempest Manager object * <https://review.openstack.org/624335> puppet-tripleo: Initial extraction of the Placement service from Nova * <https://review.openstack.org/#/q/topic:bug/1821824> Nova: bug fix prevent forbidden traits from working as expected * <https://review.openstack.org/648665> Nova: Spec for a new nova virt driver to manage an RSD * <https://review.openstack.org/#/q/topic:bug/1819460> Nova: Handle placement error during re-schedule * <https://review.openstack.org/#/c/642067/> Helm: Allow more generic overrides for nova placement-api * <https://review.openstack.org/647578> Nova: add spec for image metadata prefiltering -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
On Mar 29, 2019, at 9:07 AM, Chris Dent <cdent+os@anticdent.org> wrote:
* Some [image type traits](https://review.openstack.org/648147) have merged (to be used in a nova-side request pre-filter), but the change has exposed an issue we'll need to resolve: os-traits and os-resource-classes are under the cycle-with-intermediary style release which means that at this time in the cycle it is difficult to make a release which can delay work. We could switch to independent. This would make sense for libraries that are basically lists of strings. It's hard to break that.
Especially since strings cannot be removed. +1 to moving to independent releases.
We could also investigate making os-traits and os-resource-classes required-projects in job templates in zuul. This would allow them to be "tox siblings". Or we could wait. Please express an opinion if you have one.
I googled ’tox siblings’ and got a lot of family relationship advice. So no, I have no opinion on this.
We should do a bug squash day at some point. Should we wait until after the PTG or no?
I don’t think PTG makes a difference. Let’s wait until after Stein is released, and figure out a good date then. -- Ed Leafe
On Mon, 1 Apr 2019, Ed Leafe wrote:
On Mar 29, 2019, at 9:07 AM, Chris Dent <cdent+os@anticdent.org> wrote:
We could also investigate making os-traits and os-resource-classes required-projects in job templates in zuul. This would allow them to be "tox siblings". Or we could wait. Please express an opinion if you have one.
I googled ’tox siblings’ and got a lot of family relationship advice. So no, I have no opinion on this.
https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling-... -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Chris- On 4/1/19 9:55 AM, Chris Dent wrote:
On Mon, 1 Apr 2019, Ed Leafe wrote:
On Mar 29, 2019, at 9:07 AM, Chris Dent <cdent+os@anticdent.org> wrote:
We could also investigate making os-traits and os-resource-classes required-projects in job templates in zuul. This would allow them to be "tox siblings". Or we could wait. Please express an opinion if you have one.
If this is the magic potion that makes it possible for e.g. my nova patch to Depends-On: my os-traits patch and have that actually work, then yes, please, definitely do this. Otherwise I have to wait until the os-traits patch is merged, released, and percolated through u-c before the nova patch has a hope of running through the check pipeline. If "tox siblings" is something different, then I have no opinion due to ignorance. -efried
participants (3)
-
Chris Dent
-
Ed Leafe
-
Eric Fried