Re: [openstack-dev] [Neutron][Nova] Neutron mid-cycle summary report

[Martin Hickey]

Not a bother. Great to have the Neutrinos in Cork ! :-)




From:   "Armando M." 
To: "OpenStack Development Mailing List (not for usage questions)"

Cc: Martin Hickey/Ireland/IBM@IBMIE
Date:   27/08/2016 01:14
Subject:[Neutron][Nova] Neutron mid-cycle summary report



Hi Neutrinos,

For those of you who couldn't join in person, please find a few notes below
to capture some of the highlights of the event.

I would like to thank everyone one who helped me put this report together,
and everyone who helped make this mid-cycle a fruitful one.

I would also like to thank IBM, and the individual organizers who made
everything go smoothly. In particular Martin, who put up with our moody
requests: thanks Martin!!

Feel free to reach out/add if something is unclear, incorrect or
incomplete.

Cheers,
Armando

~~~

We touched on these topics (as initially proposed on
https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems)

  Keystone v3 and project-id adoption:
dasm and amotoki have been working to making the Neutron server
process project-id correctly [1]. Looking at the spec [2], we
are half way through having completed the DB migration, being
Keystone v3 complaint, and having updated the client bindings
[3].
  [1] https://review.openstack.org/#/c/357977/
  [2] https://review.openstack.org/#/c/257362/
  [3] https://review.openstack.org/#/q/topic:bp/keystone-v3
  Neutron-lib:
HenryG, dougwig and kevinbenton worked out a plan to get
the common_db_mixin into neutron-lib. Because of the risk of
regression, this is being deferred until Ocata opens up.
However, simpler changes like the he model_base move to lib was
agreed on and merged.
A plan to provide test support was discussed. The current
strategy involves providing test base classes in lib (this
reverses the stance conveyed in Austin). The usual steps
involved require to making public the currently private
classes, ensure the lib's copies are up-to-date with core
neutron, and deprecate the ones located in Neutron.
rtheis and armax worked on having networking-ovn test
periodically against neutron-lib [1,2,3].
  [1] https://review.openstack.org/#/c/357086/
  [2] https://review.openstack.org/#/c/359143/
  [3] https://review.openstack.org/#/c/357079/
A tool (tools/migration_report.sh) helps project team determine
the level of dependency they have with Neutron. It should be
improved to report the exact offending imports.
Right now neutron-lib 0.4.0 is released and available in
global-requirements/upper-constraints.
  Objects and hitless upgrades:
Ihar gave the team an overview and status update [1]
There was a fruitful discussion that hopefully set the way
forward for Ocata. The discussed plan was to start Ocata with
the expectation that no new contract scripts are landing in
Ocata, and to revisit the requirement later if for some reason
we see any issue with applying the requirement in practice.
Some work was done to deliver necessary objects for
push-notifications. Patches up for review. Some review cycles
were spent to work on landing patches moving model definitions
under neutron/db/models
  [1]
  
http://lists.openstack.org/pipermail/openstack-dev/2016-August/101838.html
  OSC transition:
rtheis gave an update to the team on the state of the
transition. Core resources commands are all available through
OSC; QoS, Metering and *-aaS are still not converted.
There is some confusion on how to tackle openstacksdk support.
We discussed the future goal of python binding of Networking
API. OSC uses OpenStack SDK for network commands and Neutron
OSC plugin uses python bindings from python-neutronclient. A
question is to which project developers who add new features
implement, both, openstack SDK or python-neutronclient? There
was no conclusion at the mid-cycle. It is not specific to
neutron. Similar situation can happen for nova, cinder and
other projects and we need to raise it to the community.
Ocata is going to be the first release where the neutronclient
CLI is officially deprecated. It may take us more than the
usual two cycles to remove it altogether, but that's a signal
to developer and users to seriously develop against OSC, and
report bugs against OSC.
Several pending contributio

Re: [openstack-dev] [Neutron][Nova] Neutron mid-cycle summary report

[Miguel Angel Ajo Pelayo]

Hi Armando,

Thanks for the report, I'm adding some notes inline (OSC/SDK)

On Sat, Aug 27, 2016 at 2:13 AM, Armando M.  wrote:
> Hi Neutrinos,
>
> For those of you who couldn't join in person, please find a few notes below
> to capture some of the highlights of the event.
>
> I would like to thank everyone one who helped me put this report together,
> and everyone who helped make this mid-cycle a fruitful one.
>
> I would also like to thank IBM, and the individual organizers who made
> everything go smoothly. In particular Martin, who put up with our moody
> requests: thanks Martin!!
>
> Feel free to reach out/add if something is unclear, incorrect or incomplete.
>
> Cheers,
> Armando
>
> ~~~
>
> We touched on these topics (as initially proposed on
> https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems)
>
> Keystone v3 and project-id adoption:
>
> dasm and amotoki have been working to making the Neutron server process
> project-id correctly [1]. Looking at the spec [2], we are half way through
> having completed the DB migration, being Keystone v3 complaint, and having
> updated the client bindings [3].
>
> [1] https://review.openstack.org/#/c/357977/
> [2] https://review.openstack.org/#/c/257362/
> [3] https://review.openstack.org/#/q/topic:bp/keystone-v3
>
> Neutron-lib:
>
> HenryG, dougwig and kevinbenton worked out a plan to get the common_db_mixin
> into neutron-lib. Because of the risk of regression, this is being deferred
> until Ocata opens up. However, simpler changes like the he model_base move
> to lib was agreed on and merged.
> A plan to provide test support was discussed. The current strategy involves
> providing test base classes in lib (this reverses the stance conveyed in
> Austin). The usual steps involved require to making public the currently
> private classes, ensure the lib's copies are up-to-date with core neutron,
> and deprecate the ones located in Neutron.
> rtheis and armax worked on having networking-ovn test periodically against
> neutron-lib [1,2,3].
>
> [1] https://review.openstack.org/#/c/357086/
> [2] https://review.openstack.org/#/c/359143/
> [3] https://review.openstack.org/#/c/357079/
>
> A tool (tools/migration_report.sh) helps project team determine the level of
> dependency they have with Neutron. It should be improved to report the exact
> offending imports.
> Right now neutron-lib 0.4.0 is released and available in
> global-requirements/upper-constraints.
>
> Objects and hitless upgrades:
>
> Ihar gave the team an overview and status update [1]
> There was a fruitful discussion that hopefully set the way forward for
> Ocata. The discussed plan was to start Ocata with the expectation that no
> new contract scripts are landing in Ocata, and to revisit the requirement
> later if for some reason we see any issue with applying the requirement in
> practice.
> Some work was done to deliver necessary objects for push-notifications.
> Patches up for review. Some review cycles were spent to work on landing
> patches moving model definitions under neutron/db/models
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-August/101838.html
>
> OSC transition:
>
> rtheis gave an update to the team on the state of the transition. Core
> resources commands are all available through OSC; QoS, Metering and *-aaS
> are still not converted.

QoS is being pushed up by Rodolfo in a series of bugs on SDK/OSC:
  
https://review.openstack.org/#/q/owner:rodolfo.alonso.hernandez%2540intel.com+status:open

Those are almost there.

> There is some confusion on how to tackle openstacksdk support. We discussed
> the future goal of python binding of Networking API. OSC uses OpenStack SDK
> for network commands and Neutron OSC plugin uses python bindings from
> python-neutronclient. A question is to which project developers who add new
> features implement, both, openstack SDK or python-neutronclient? There was
> no conclusion at the mid-cycle. It is not specific to neutron. Similar
> situation can happen for nova, cinder and other projects and we need to
> raise it to the community.
>
> Ocata is going to be the first release where the neutronclient CLI is
> officially deprecated. It may take us more than the usual two cycles to
> remove it altogether, but that's a signal to developer and users to
> seriously develop against OSC, and report bugs against OSC.
> Several pending contributions into osc-lib.
> An update is available on [1,2]
>
> [1] https://review.openstack.org/#/c/357844/
> [2] https://etherpad.openstack.org/p/osc-neutron-support
>
> Stability squash:
>
> armax was bug deputy for the week of the mid-cycle; nothing critical showed
> up in the gate, however pluggable ipam [1] switch merged, which might have
> some unexpected repercussions down the road.
> A number of bugs older than a year were made expirable [2].
> kevinbenton and armax devised a strategy and started working on [3] to
> ensure DB retriable errors are no longer handled at the API layer.
> T

[openstack-dev] [Neutron][Nova] Neutron mid-cycle summary report

[Armando M.]

Hi Neutrinos,

For those of you who couldn't join in person, please find a few notes below
to capture some of the highlights of the event.

I would like to thank everyone one who helped me put this report together,
and everyone who helped make this mid-cycle a fruitful one.

I would also like to thank IBM, and the individual organizers who made
everything go smoothly. In particular Martin, who put up with our moody
requests: thanks Martin!!

Feel free to reach out/add if something is unclear, incorrect or incomplete.

Cheers,
Armando

~~~

We touched on these topics (as initially proposed on
*https://etherpad.openstack.org/p/newton-neutron-midcycle-workitems
*)


   - Keystone v3 and project-id adoption:
  - dasm and amotoki have been working to making the Neutron server
  process project-id correctly [1]. Looking at the spec [2], we
are half way
  through having completed the DB migration, being Keystone v3
complaint, and
  having updated the client bindings [3].
 - [1] https://review.openstack.org/#/c/357977/
 - [2] https://review.openstack.org/#/c/257362/
 - [3] https://review.openstack.org/#/q/topic:bp/keystone-v3
  - Neutron-lib:
  - HenryG, dougwig and kevinbenton worked out a plan to get the
common_db_mixin
  into neutron-lib. Because of the risk of regression, this is
being deferred
  until Ocata opens up. However, simpler changes like the he model_base
  move to lib was agreed on and merged.
  - A plan to provide test support was discussed. The current strategy
  involves providing test base classes in lib (this reverses the stance
  conveyed in Austin). The usual steps involved require to making
  public the currently private classes, ensure the lib's copies are
  up-to-date with core neutron, and deprecate the ones located in
  Neutron.
  - rtheis and armax worked on having networking-ovn test periodically
  against neutron-lib [1,2,3].
 - [1] https://review.openstack.org/#/c/357086/
 - [2] https://review.openstack.org/#/c/359143/
 - [3] https://review.openstack.org/#/c/357079/
  - A tool (tools/migration_report.sh) helps project team determine the
  level of dependency they have with Neutron. It should be
improved to report
  the exact offending imports.
  - Right now neutron-lib 0.4.0 is released and available in
  global-requirements/upper-constraints.
   - Objects and hitless upgrades:
  - Ihar gave the team an overview and status update [1]
  - There was a fruitful discussion that hopefully set the way forward
  for Ocata. The discussed plan was to start Ocata with the
expectation that
  no new contract scripts are landing in Ocata, and to revisit the
  requirement later if for some reason we see any issue with applying the
  requirement in practice.
  - Some work was done to deliver necessary objects for
  push-notifications. Patches up for review. Some review cycles
were spent to
  work on landing patches moving model definitions under neutron/db/models
  - [1] http://lists.openstack.org/pipermail/openstack-dev/
 2016-August/101838.html
  - OSC transition:


   - rtheis gave an update to the team on the state of the transition. Core
  resources commands are all available through OSC; QoS, Metering and *-aaS
  are still not converted.
  - There is some confusion on how to tackle openstacksdk support. We
  discussed the future goal of python binding of Networking API. OSC uses
  OpenStack SDK for network commands and Neutron OSC plugin uses python
  bindings from python-neutronclient. A question is to which project
  developers who add new features implement, both, openstack SDK or
  python-neutronclient? There was no conclusion at the mid-cycle. It is not
  specific to neutron. Similar situation can happen for nova, cinder and
  other projects and we need to raise it to the community.


   - Ocata is going to be the first release where the neutronclient CLI is
  officially deprecated. It may take us more than the usual two cycles to
  remove it altogether, but that's a signal to developer and users to
  seriously develop against OSC, and report bugs against OSC.
  - Several pending contributions into osc-lib.
  - An update is available on [1,2]


   - [1] https://review.openstack.org/#/c/357844/
 - [2] https://etherpad.openstack.org/p/osc-neutron-support
  - Stability squash:
  - armax was bug deputy for the week of the mid-cycle; nothing
  critical showed up in the gate, however pluggable ipam [1] switch merged,
  which might have some unexpected repercussions down the road.
  - A number of bugs older than a year were made expirable [2].
  - kevinbenton and armax devised a strategy and started working on [3]
  to ensure DB retriable errors