May 2019 - openstack-discuss - lists.openstack.org

Neutron - Nova cross project topics
by Sean Mooney 04 May '19

04 May '19

https://etherpad.openstack.org/p/ptg-train-xproj-nova-neutron PTG summary: below is a summary of the section i lead for the cross project sessions. hopefully the others can extend this with there sections too. Topic: Optional NUMA affinity for neutron ports (sean-k-mooney) Summary: we will model numa affinity of neutron port via a new qos rule type that will be applied to the port. neutron will comunicate the policy to nova allowing different policies per interface. the numa polices will be defined in the spec and willl likely just be the ones we support already today in the the pci alias. AR: sean-k-mooney to write sibling specs for nova and neutron Topic: track neutron ports in placement. Summary: nova will create RPs for each SR-IOV PF and apply the nic feature flags and physnet as traits. the RP name will contain the PF netdev name. neutron l2 agents will add inventoies of ports under exsiting agent RPs. this will allow us to track the capsity of each network backend as well as schdule based on nic feature flag, vnic type and physnets. details will be worked out in the specs and it will target the U cycle AR: sean-k-mooney to write sibling specs for nova and neutron for U Topic: port binding records https://review.openstack.org/#/c/645173/ Summary: os-vif will be extended to contain new fields to record the conectiviy type and ml2 driver that bound the vif. each neutron ml2 driver will be modified to add a serialised os-vif object to the binding responce. the nova.network.model.vif object will be extended to store the os-vif object. the virt drivers will conditionnall skip calling the nova vif to os-vif vif object conversion function and fall back to the legacy workflow if not present in the nova vif object. initially none of the legacy code willl be removed untill all ml2 drivers are updated. AR: Sean and Rodolfo to update spec and with nova spec for nova specific changes. Topic: boot vms with unaddressed port. https://blueprints.launchpad.net/nova/+spec/boot-vm-with-unaddressed-port Summary: Agreed we should do this and we should depend on the port binding records change. AR: rodlofo to start codeing this up and update the spec.

1 0

Retiring aeromancer
by Stephen Finucane 04 May '19

04 May '19

The aeromancer project appears to be dead and has had no activity in over four years. I would like to retire the repository. Please let me know if there are any objections. I'm proposing patches now with topic retire-aeromancer. Stephen

2 1

Retiring alexandria
by Stephen Finucane 04 May '19

04 May '19

The alexandria project appears to be dead and has had no activity in over three years. I would like to retire the repository. Please let me know if there are any objections. I'm proposing patches now with topic retire-alexandria. Stephen

1 0

Retiring mors
by Stephen Finucane 04 May '19

04 May '19

The aeromancer project appears to be dead and has had no activity in nearly two years. I would like to retire the repository. Please let me know if there are any objections. I'm proposing patches now with topic retire-mors. Stephen

1 0

Retiring ailuropoda
by Stephen Finucane 04 May '19

04 May '19

The ailuropoda project appears to be dead and has had no activity in nearly three years. I would like to retire the repository. Please let me know if there are any objections. I'm proposing patches now with topic retire-ailuropoda. Stephen

1 0

Retiring hurricane
by Stephen Finucane 04 May '19

04 May '19

The x/hurricane repo was created but has not been populated in the two years since. I would like to retire the repository. Please let me know if there are any objections. I'm proposing patches now with topic retire-hurricane. Stephen

1 0

Retiring bilean
by Stephen Finucane 04 May '19

04 May '19

The Bilean appears to be dead and has had no activity in over two years. I would like to retire the repository. Please let me know if there are any objections. I'm proposing patches now with topic retire-bilean. Stephen

1 0

[placement][nova][ptg] Summary: Shared resource providers for shared disk on compute hosts
by Chris Dent 04 May '19

04 May '19

See also: https://etherpad.openstack.org/p/ptg-train-xproj-nova-placement There's a spec in progress about turning on support for shared disk providers [1]. We discussed some of the details that need to be resolved and actions that need to be taken. The next action is for Tushar to update the spec to reflect the decisions and alternatives: * For some virt drivers, we need example one or two tools for: * creating a shared disk provider, setting inventory, creating aggregate, adding compute nodes to the aggregate * updating inventory when the (absolute) size of the storage changes These were initially discussed as example tools that live in the placement repo but it might actually be better in nova. There's an abandoned example [2] from long ago. * Other virt drivers (and potentially Ceph w/libvirt if a reliable source of identifier is available) will be able to manage this sort of thing themselves in update_provider_tree. * Other options (for managing the initial management of the shared disk provider) include: * write the provider info into a well-known file on the shared disk * variations on the inventory.yaml file * We would like to have shared disk testing in the gate. Matt has started https://review.opendev.org/#/c/586363/ but it does not test multinode, yet. Note that apart from the sample tools described above, which might be in the placement repo, the required actions here are on the nova side. At least until we find bugs on the placement side resulting from this work. [1] https://review.opendev.org/#/c/650188/ [2] https://review.opendev.org/382613 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[nova][ptg] Summary: API inconsistency cleanups
by Eric Fried 04 May '19

04 May '19

Spec: https://review.openstack.org/#/c/603969/ Summary: The spec describes a bunch of mostly-unrelated-to-each-other API cleanups, listed below. The spec proposes to do them all in a single microversion. Consensus: - 400 for unknown/invalid params in querystring / request body => Do it. - Remove OS-* prefix from request and response field. - Proposed alternative: accept either, return both => Don't do it (either way) - Making server representation always consistent among all APIs returning the complete server representation. => Do it (in the same microversion) - Return ``servers`` field as an empty list in response of GET /os-hypervisors when there are no servers (currently it is omitted) => Do it (in the same microversion) - Consistent error codes on quota exceeded => Don't do it - Lump https://review.opendev.org/#/c/648919/ (change flavors.swap default from '' [string] to 0 [int] in the response) into the same effort? => Do it (in the same microversion) efried .

1 0

[nova][ptg] Summary: Using Forbidden Aggregates
by Eric Fried 04 May '19

04 May '19

Spec: https://review.opendev.org/#/c/609960/ Summary: - TL;DR: Allows you to say "You can't land on a host that does X unless you specifically require X". Example: Keep my Windows-licensed hosts for Windows instances. - Exploit placement enablement for forbidden aggregates [1] in Nova - Set (nova) aggregate metadata with a syntax similar/identical to that of extra_specs for required traits (e.g. 'trait:CUSTOM_WINDOWS_ONLY': 'required') - During scheduling, nova will discover all aggregates with metadata of this form. For each: - Construct a list of the traits in the aggregate metadata - Subtract traits required by the server request's flavor+image. - If any traits from the aggregate remain, add this aggregate's UUID (which corresponds to a placement aggregate) to the list of "forbidden aggregates" for the GET /allocation_candidates request. Agreements: - The "discover all aggregates" bit has the potential to be slow, but is better than the alternative, which was having the admin supply the same information in a confusing conf syntax. And if performance becomes a problem, we can deal with it later; this does not paint us into a corner. - Spec has overall support, but a few open questions. Answer those, and we're good to approve and move forward. efried [1] https://docs.openstack.org/placement/latest/specs/train/approved/2005297-ne…

2 1