Very good summary, thanks for leading the PTG and neutron so well. :)
On Mon, Mar 12, 2018 at 11:25 PM fumihiko kakuma <kak...@valinux.co.jp> wrote: > Hi Miguel, > > > * As part of the neutron-lib effort, we have found networking projects > that > > are very inactive. Examples are networking-brocade (no updates since May > of > > 2016) and networking-ofagent (no updates since March of 2017). Miguel > > Lavalle will contact these projects leads to ascertain their situation. > If > > they are indeed inactive, we will not support them as part of neutron-lib > > updates and will also try to remove them from code search > > networking-ofagent has been removed in the Newton release. > So it will not be necessary to support it as part of neutron-lib updates. > > Thanks > kakuma. > > > On Mon, 12 Mar 2018 13:45:27 -0500 > Miguel Lavalle <mig...@mlavalle.com> wrote: > > > Hi All! > > > > First of all, I want to thank you the team for the productive week we had > > in Dublin. Following below is a high level summary of the discussions we > > had. If there is something I left out, please reply to this email thread > to > > add it. However, if you want to continue the discussion on any of the > > individual points summarized below, please start a new thread, so we > don't > > have a lot of conversations going on attached to this update. > > > > You can find the etherpad we used during the PTG meetings here: > > https://etherpad.openstack.org/p/neutron-ptg-rocky > > > > > > Retrospective > > ========== > > > > * The team missed one community goal in the Pike cycle ( > > https://governance.openstack.org/tc/goals/pike/deploy-api-in-wsgi.html) > and > > one in the Queens cycle (https://governance.openstack. > > org/tc/goals/queens/policy-in-code.html) > > > > - Akihiro Motoki will work on https://governance.openstack.o > > rg/tc/goals/queens/policy-in-code.html during Rocky > > > > - We need volunteers to complete https://governance.op > > enstack.org/tc/goals/pike/deploy-api-in-wsgi.html) and the two new goals > > for the Rocky cycle: https://governance.openstack.o > > rg/tc/goals/rocky/enable-mutable-configuration.html and > > https://governance.openstack.org/tc/goals/rocky/mox_removal.html. > Akihiro > > Motoki will lead the effort for mox removal > > > > - We decided to add a section to our weekly meeting agenda where we are > > going to track the progress towards catching up with the community goals > > during the Rocky cycle > > > > * As part of the neutron-lib effort, we have found networking projects > that > > are very inactive. Examples are networking-brocade (no updates since May > of > > 2016) and networking-ofagent (no updates since March of 2017). Miguel > > Lavalle will contact these projects leads to ascertain their situation. > If > > they are indeed inactive, we will not support them as part of neutron-lib > > updates and will also try to remove them from code search > > > > * We will continue our efforts to recruit new contributors and develop > core > > reviewers. During the conversation on this topic, Nikolai de Figueiredo > and > > Pawel Suder announced that they will become active in Neutron. Both of > > them, along with Hongbin Lu, indicated that are interested in working > > towards becoming core reviewers. > > > > * The team went through the blueprints in the backlog. Here is the status > > for those blueprints that are not discussed in other sections of this > > summary: > > > > - Adopt oslo.versionedobjects for database interactions. This is a > > continuing effort. The contact is Ihar Hrachyshka (ihrachys). > Contributors > > are wanted. There is a weekly meeting led by Ihar where this topic is > > covered: http://eavesdrop.openstack.org/#Neutron_Upgrades_Meeting > > > > - Enable adoption of an existing subnet into a subnetpool. The final > > patch in the series to implement this feature is: > > https://review.openstack.org/#/c/348080. Pawel Suder will drive this > patch > > to completion > > > > - Neutron in-tree API reference (https://blueprints.launchpad. > > net/neutron/+spec/neutron-in-tree-api-ref). There are two remaining TODOs > > to complete this blueprint: > https://bugs.launchpad.net/neutron/+bug/1752274 > > and https://bugs.launchpad.net/neutron/+bug/1752275. We need volunteers > for > > these two work items > > > > - Add TCP/UDP port forwarding extension to L3. The spec was merged > > recently: https://specs.openstack.org/openstack/neutron-specs/specs/qu > > eens/port-forwarding.html. Implementation effort is in progress: > > https://review.openstack.org/#/c/533850/ and > https://review.openstack.org/# > > /c/535647/ > > > > - Pure Python driven Linux network configuration ( > > https://bugs.launchpad.net/neutron/+bug/1492714). This effort has been > > going on for several cycles gradually adopting pyroute2. Slawek Kaplonski > > is continuing it with https://review.openstack.org/#/c/545355 and > > https://review.openstack.org/#/c/548267 > > > > > > Port behind port API proposal > > ====================== > > > > * Omer Anson proposed to extend the Trunk Port API to generalize the > > support for port behind port use cases such as containers nested as > > MACVLANs within a VM or HA proxy port behind amphora VM port: > > https://bugs.launchpad.net/bugs/1730845 > > > > - After discussing the proposed use cases, the agreement was to > develop > > a specification making sure input is provided by the Kuryr and Octavia > teams > > > > > > ML2 and Mechanism drivers > > ===================== > > > > * Hongbin Lu presented a proposal (https://bugs.launchpad.net/ne > > utron/+bug/1722720) to add a new value "auto" to the port attribute > > admin_state_up. > > > > - This is to support SR-IOV ports, where admin_state_up == "auto" > would > > mean that the VF link state follows that of the PF. This may be useful > when > > VMs use the link as a trigger for its own HA mechanism > > - The agreement was not to overload the admin_state_up attribute with > > more values, since it reflects the desired administrative state of the > port > > and add a new attribute for the intended purpose > > > > * Zhang Yanxian presented a specification (https://review.openstack.org/ > > 506066) to support SR-IOV bonds whereby a Neutron port is associated with > > two VFs in separate PFs. This is useful in NFV scenarios, where link > > redundancy is necessary. > > > > - Nikolai de Figueiredo agreed to help to drive this effort forward, > > starting with the specification both in the Neutron and the Nova sides > > - Sam Betts indicated this type of bond is also of interest for > Ironic. > > He requested to be kept in the loop > > > > * Ruijing Guo proposed to support VLAN transparency in Neutron OVS agent. > > > > - There is a previous incomplete effort to provide this support: > > https://bugs.launchpad.net/neutron/+bug/1705719. Patches are here: > > > https://review.openstack.org/#/q/project:openstack/neutron+topic:bug/1705719 > > - Agreement was for Ruijing to look at the existing patches to > re-start > > the effort. Thomas Morin may provide help for this > > - While on this topic, the conversation temporarily forked to the use > of > > registers instead of ovsdb port tags in L2 agent br-int and possibly > remove > > br-tun. Thomas Morin committed to draft a RFE for this. > > > > * Mike Kolesnik, Omer Anson, Irena Berezovsky, Takashi Yamamoto, Lucas > > Alvares, Ricardo Noriega, Miguel Ajo, Isaku Yamahata presented the > proposal > > to implement a common mechanism to achieve synchronization between > > Neutron's DB and the DBs of sub-projects / SDN frameworks > > > > - Currently each sub-project / SDN framework has its own solution for > > this problem. The group thinks that a common solution can be achieved > > - The agreement was to create a specification where the common > solution > > can be fleshed out > > - The synchronization mechanism will exist in Neutron > > > > * Mike Kolesnik (networking-odl) requested feedback from members of other > > Neutron sub-projects about the value of inheriting ML2 Neutron's unit > tests > > to get "free testing" for mechanism drivers > > > > - The conclusion was that there is no value in that practice for the > > sub-rpojects > > - Sam Betts and Miguel Lavalle will explore moving unit tests utils to > > neutron-lib to enable subprojects to create their own base classes > > - Mike Kolesnik will document a guideline for sub-projects not to > > inherit unit tests from Neutron > > > > > > API topics > > ======== > > > > * Isaku Yamahata presented a proposal of a new API for cloud admins to > > retrieve the physical networks configured in compute hosts > > > > - This information is currently stored in configuration files. In > > agent-less environments it is difficult to retrieve > > - The agreement was to extend the agent API to expose the physnet as a > > standard attribute. This will be fed by a pseudo-agent > > > > * Isaku Yamahata presented a proposal of a new API to report mechanism > > drivers health > > > > - The overall idea is to report mechanism driver status, similar to > the > > agents API which reports agent health. In the case of mechanism drivers > > API, it would report connectivity to backend SDN controller or MQ server > > and report its health/config periodically > > - Thomas Morin pointed out that this is relevant not only for ML2 > > mechanism drivers but also for all drivers of different services > > - The agreement was to start with a specification where we scope the > > proposal into something manageable for implementation > > > > * Yushiro Furukawa proposed to add support of 'snat' as a loggable > resource > > type: https://bugs.launchpad.net/neutron/+bug/1752290 > > > > - The agreement was to implement it in Rocky > > - Brian Haley agreed to be the approver > > > > * Hongbin Lu indicated that If users provide different kinds of invalid > > query parameters, the behavior of the Neutron API looks unpredictable ( > > https://bugs.launchpad.net/neutron/+bug/1749820) > > > > - The proposal is to improve the predictability of the Neutron API by > > handling invalid query parameters consistently > > - The proposal was accepted. It will need to provide API > discoverability > > when behavior changes on filter parameter validation > > - It was also recommended to discuss this with the API SIG to get > their > > guidance. The discussion already started in the mailing list: > > > http://lists.openstack.org/pipermail/openstack-dev/2018-March/128021.html > > > > > > Openflow Manager and Common Classification Framework > > ========================================== > > > > * The Openflow manager implementation needs reviews to continue making > > progress > > > > - The approved spec is here: https://specs.openstack.org/op > > enstack/neutron-specs/specs/backlog/pike/l2-extension-ovs-fl > > ow-management.html > > - The code is here: https://review.openstack.org/323963 > > - Thomas Morin, David Shaughnessy and Miguel Lavalle discussed and > > reviewed the implementation during the last day of the PTG. The result of > > that conversation was reflected in the patch. Thomas and Miguel committed > > to continue reviewing the patch > > > > * The Common Classification Framework (https://specs.openstack.org/o > > penstack/neutron-specs/specs/pike/common-classification-framework.html) > > needs to be adopted by its potential consumers: QoS, SFC, FWaaS > > > > - David Shaughnessy and Miguel Lavalle met with Slawek Kaplonski over > > IRC the last day of the PTG (http://eavesdrop.openstack.or > > g/irclogs/%23openstack-neutron/%23openstack-neutron.2018-03- > > 02.log.html#t2018-03-02T12:00:34) to discuss the adoption of the > framework > > in QoS code. The agreement was to have a PoC for the DSCP marking rule, > > since it uses OpenFlow and wouldn't involve big backend changes > > > > - David Shaughnessy and Yushiro Furukawa are going to meet to discuss > > adoption of the framework in FWaaS > > > > > > Neutron to Neutron interconnection > > ========================= > > > > * Thomas Morin walked the team through an overview of his proposal ( > > https://review.openstack.org/#/c/545826) for Neutron to Neutron > > interconnection, whereby the following requirements are satisfied: > > > > - Interconnection is consumable on-demand, without admin intervention > > - Have network isolation and allow the use of private IP addressing > end > > to end > > - Avoid the overhead of packet encryption > > > > * Feedback was positive and the agreement is to continue developing and > > reviewing the specification > > > > > > L3 and L3 flavors > > ============ > > > > * Isaku Yamahata shared with the team that the implementation of routers > > using the L3 flavors framework gives rise to the need of specifying the > > order in which callbacks are executed in response to events > > > > - Over the past couple of months several alternatives have been > > considered: callback cascading among resources, SQLAlchemy events, > > assigning priorities to callbacks responding to the same event > > - The agreement was an approach based on assigning a priority > structure > > to callbacks in neutron-lib: https://review.openstack.org/#/c/541766 > > > > * Isaku Yamahata shared with the team the progress made with the PoC for > an > > Openflow based DVR: https://review.openstack.org/#/c/472289/ and > > https://review.openstack.org/#/c/528336/ > > > > - There was a discussion on whether we need to ask the OVS community > to > > do ipv6 modification to support this PoC. The conclusion was that the > > feature already exists > > - There was also an agreement for David Chou add Tempest testing for > the > > scenario of mixed agents > > > > > > neutron-lib > > ======== > > > > * The team reviewed two neutron-lib specs, providing feedback through > > Gerrit: > > > > - A spec to rehome db api and utils into neutron-lib: > > https://review.openstack.org/#/c/473531. > > - A spec to decouple neutron db models and ovo for neutron-lib: > > https://review.openstack.org/#/c/509564/. There is agreement from Ihar > > Ihrachys that OVO base classes should go into neutron-lib. But he asked > not > > to move yet neutron.objects.db.api since it's still in flux > > > > * Manjeet Singh Bhatia proposed making payload consistent for all the > > callbacks so all the operations of an object get same type of payload. ( > > https://bugs.launchpad.net/neutron/+bug/1747747) > > > > - The agreement was for Manjeet to document all the instances in the > > code where this is happening so he and others can work on making the > > payloads consistent > > > > > > Proposal to migrate neutronclient python bindings to OpenStack SDK > > ================================================== > > > > * Akihiro Motoki proposed to change the first priority of neutron-related > > python binding to OpenStack SDK rather than neutronclient python > bindings, > > given that OpenStack SDK became official in Queens ( > > > http://lists.openstack.org/pipermail/openstack-dev/2018-February/127726.html > > ) > > > > - The proposal is to implement all Neutron features in OpenStack SDK > as > > the first citizen and the neutronclient OSC plugin consumes corresponding > > OpenStack SDK APIs > > - New features should be supported in OpenStack SDK and > > OSC/neutronclient OSC plugin as the first priority > > - If a new feature depends on neutronclient python bindings, it can be > > implemented in neutornclient python bindings first and they are ported as > > part of existing feature transition > > - Existing features only supported in neutronclient python bindings > are > > ported into OpenStack SDK, and neutronclient OSC plugin will consume them > > once they are implemented in OpenStack SDK > > - There is no plan to drop the neutronclient python bindings since > not a > > small number of projects consumes it. It will be maintained as-is > > - Projects like Nova that consume a small set of neutron features can > > continue using neutronclient python bindings. Projects like Horizon or > Heat > > that would like to support a wide range of features might be better off > > switching to OpenStack SDK > > - Proposal was accepted > > > > > > Cross project planning with Nova > > ======================== > > > > * Minimum bandwidth support in the Nova scheduler. The summary of the > > outcome of the discussion and further work done after the PTG is the > > following: > > > > - Minimum bandwidth support guarantees a port minimum bandwidth. > Strict > > minimum bandwidth support requires cooperation with the Nova scheduler, > to > > avoid physical interfaces bandwidth overcommitment > > - Neutron will create in each host networking RPs (Resource Providers) > > under the compute RP with proper traits and then will report resource > > inventories based on the discovered and / or configured resource > inventory > > in the host > > - The hostname will be used by Neutron to find the compute RP created > by > > Nova for the compute host. This convention can create ambiguity in > > deployments with multiple cells, where hostnames may not be unique. > However > > this problem is not exclusive to this effort, so its solution will be > > considered out of scope > > - Two new standard Resource Classes will be defined to represent the > > bandwidth in each direction, named as `NET_BANDWIDTH_INGRESS_BITS_SEC` > and > > `NET_BANDWIDTH_EGRESS_BITS_SEC > > - New traits will be defined to distinguish a network back-end agent: > > `NET_AGENT_SRIOV`, `NET_AGENT_OVS`. Also new traits will be used to > > indicate which physical network a given Network RP is connected to > > - Neutron will express a port's bandwidth needs through the port API > in > > a new attribute named "resource_request" that will include ingress > > bandwidth, egress bandwidth, the physical net and the agent type > > - The first implementation of this feature will support server create > > with pre-created Neutron ports having QoS policy with minimum bandwidth > > rules. Server create with networks having QoS policy minimum bandwidth > rule > > will be out of scope of the first implementation, because currently, in > > this case, the corresponding port creations happen after the scheduling > > decision has been made > > - For the first implementation, Neutron should reject a QoS minimum > > bandwidth policy rule created on a bound port > > - The following cases don't involve any interaction in Nova and as a > > consequence, Neutron will have to adjust the resource allocations: QoS > > policy rule bandwidth amount change on a bound port and QoS aware sub > port > > create under a bound parent port > > - For more detailed discussion, please go to the following specs: > > https://review.openstack.org/#/c/502306 and > https://review.openstack.org/# > > /c/508149 > > > > * Provide Port Binding Information for Nova Live Migration ( > > https://specs.openstack.org/openstack/neutron-specs/specs/ > > backlog/pike/portbinding_information_for_nova.html and > > https://specs.openstack.org/openstack/nova-specs/specs/ > > queens/approved/neutron-new-port-binding-api.html). > > > > - There was no discussion around this topic > > - There was only an update to both teams about the solid progress that > > has been made on both sides: https://review.openstack.org/#/c/414251/ > and > > https://review.openstack.org/#/q/status:open+project: > > openstack/nova+branch:master+topic:bp/neutron-new-port-binding-api > > - The plan is to finish this in Rocky > > > > * NUMA aware switches https://review.openstack.org/#/c/541290/ > > > > - The agreement on this topic was to do this during Rocky entirely in > > Nova using a config option which is a list of JSON blobs > > > > * Miguel Lavalle and Hongbin Lu proposed to add device_id of the > associated > > port to the floating IP resource > > > > - The use case is to allow Nova to filter instances by floating IPs > > - The agreement was that this would be adding an entirely new contract > > to Nova with new query parameters. This will not be implemented in Nova, > > especially since the use case can already be fulfilled by making 3 API > > calls in a client: find floating IP via filter (Neutron), use that to > > filter port to get the device_id (Neutron), use that to get the server > > (Nova) > > > > > > Team photos > > ========= > > > > * Thanks to Kendall Nelson, the official PTG team photos can be found > here: > > https://www.dropbox.com/sh/dtei3ovfi7z74vo/AABT7UR5el6iXRx5WihkbOB3a/ > > Neutron?dl=0 > > > > * Thanks to Nikolai de Figueiredo for sharing with us pictures of our > team > > dinner. Please find a couple of them attached to this message > > -- > fumihiko kakuma <kak...@valinux.co.jp> > > > __________________________________________________________________________ > 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
