Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-16 Thread Neil Jerram
Stefano Maffulli stef...@openstack.org writes:

 On 12/09/2014 04:11 PM,  by wrote:
[vad] how about the documentation in this case?... bcos it needs some
 place to document (a short desc and a link to vendor page) or list these
 kind of out-of-tree plugins/drivers...  just to make the user aware of
 the availability of such plugins/driers which is compatible with so and
 so openstack release.  
 I checked with the documentation team and according to them, only the
 following plugins/drivers only will get documented...
 1) in-tree plugins/drivers (full documentation) 
 2) third-party plugins/drivers (ie, one implements and follows this new
 proposal, a.k.a partially-in-tree due to the integration module/code)...
 
 *** no listing/mention about such completely out-of-tree plugins/drivers***

 Discoverability of documentation is a serious issue. As I commented on
 docs spec [1], I think there are already too many places, mini-sites and
 random pages holding information that is relevant to users. We should
 make an effort to keep things discoverable, even if not maintained
 necessarily by the same, single team.

 I think the docs team means that they are not able to guarantee
 documentation for third-party *themselves* (and has not been able, too).
 The docs team is already overworked as it is now, they can't take on
 more responsibilities.

 So once Neutron's code will be split, documentation for the users of all
 third-party modules should find a good place to live in, indexed and
 searchable together where the rest of the docs are. I'm hoping that we
 can find a place (ideally under docs.openstack.org?) where third-party
 documentation can live and be maintained by the teams responsible for
 the code, too.

 Thoughts?

I suggest a simple table, under docs.openstack.org, where each row has
the plugin/driver name, and then links to the documentation and code.
There should ideally be a very lightweight process for vendors to add
their row(s) to this table, and to edit those rows.

I don't think it makes sense for the vendor documentation itself to be
under docs.openstack.org, while the code is out of tree.

Regards,
Neil


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-16 Thread Anne Gentle
On Tue, Dec 16, 2014 at 4:05 AM, Neil Jerram neil.jer...@metaswitch.com
wrote:

 Stefano Maffulli stef...@openstack.org writes:

  On 12/09/2014 04:11 PM,  by wrote:
 [vad] how about the documentation in this case?... bcos it needs some
  place to document (a short desc and a link to vendor page) or list these
  kind of out-of-tree plugins/drivers...  just to make the user aware of
  the availability of such plugins/driers which is compatible with so and
  so openstack release.
  I checked with the documentation team and according to them, only the
  following plugins/drivers only will get documented...
  1) in-tree plugins/drivers (full documentation)
  2) third-party plugins/drivers (ie, one implements and follows this new
  proposal, a.k.a partially-in-tree due to the integration module/code)...
 
  *** no listing/mention about such completely out-of-tree
 plugins/drivers***
 
  Discoverability of documentation is a serious issue. As I commented on
  docs spec [1], I think there are already too many places, mini-sites and
  random pages holding information that is relevant to users. We should
  make an effort to keep things discoverable, even if not maintained
  necessarily by the same, single team.
 
  I think the docs team means that they are not able to guarantee
  documentation for third-party *themselves* (and has not been able, too).
  The docs team is already overworked as it is now, they can't take on
  more responsibilities.
 
  So once Neutron's code will be split, documentation for the users of all
  third-party modules should find a good place to live in, indexed and
  searchable together where the rest of the docs are. I'm hoping that we
  can find a place (ideally under docs.openstack.org?) where third-party
  documentation can live and be maintained by the teams responsible for
  the code, too.
 
  Thoughts?

 I suggest a simple table, under docs.openstack.org, where each row has
 the plugin/driver name, and then links to the documentation and code.
 There should ideally be a very lightweight process for vendors to add
 their row(s) to this table, and to edit those rows.

 I don't think it makes sense for the vendor documentation itself to be
 under docs.openstack.org, while the code is out of tree.


Stef has suggested docs.openstack.org/third-party as a potential location
on the review at [1] https://review.openstack.org/#/c/133372/.

The proposal currently is that the list's source would be in the
openstack-manuals repository, and the process for adding to that repo is
the same as all OpenStack contributions.

I plan to finalize the plan in January, thanks all for the input, and keep
it coming.

Anne


 Regards,
 Neil


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-15 Thread Stefano Maffulli
On 12/09/2014 04:11 PM,  by wrote:
[vad] how about the documentation in this case?... bcos it needs some
 place to document (a short desc and a link to vendor page) or list these
 kind of out-of-tree plugins/drivers...  just to make the user aware of
 the availability of such plugins/driers which is compatible with so and
 so openstack release.  
 I checked with the documentation team and according to them, only the
 following plugins/drivers only will get documented...
 1) in-tree plugins/drivers (full documentation) 
 2) third-party plugins/drivers (ie, one implements and follows this new
 proposal, a.k.a partially-in-tree due to the integration module/code)...
 
 *** no listing/mention about such completely out-of-tree plugins/drivers***

Discoverability of documentation is a serious issue. As I commented on
docs spec [1], I think there are already too many places, mini-sites and
random pages holding information that is relevant to users. We should
make an effort to keep things discoverable, even if not maintained
necessarily by the same, single team.

I think the docs team means that they are not able to guarantee
documentation for third-party *themselves* (and has not been able, too).
The docs team is already overworked as it is now, they can't take on
more responsibilities.

So once Neutron's code will be split, documentation for the users of all
third-party modules should find a good place to live in, indexed and
searchable together where the rest of the docs are. I'm hoping that we
can find a place (ideally under docs.openstack.org?) where third-party
documentation can live and be maintained by the teams responsible for
the code, too.

Thoughts?

/stef

[1] https://review.openstack.org/#/c/133372/

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-12 Thread Yuriy Shovkoplias
Dear neutron community,

Can you please clarify couple points on the vendor code decomposition?
 - Assuming I would like to create the new driver now (Kilo development
cycle) - is it already allowed (or mandatory) to follow the new process?

https://review.openstack.org/#/c/134680/

- Assuming the new process is already in place, are the following
guidelines still applicable for the vendor integration code (not for vendor
library)?

https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
The following is a list of requirements for inclusion of code upstream:

   - Participation in Neutron meetings, IRC channels, and email lists.
   - A member of the plugin/driver team participating in code reviews of
   other upstream code.

Regards,
Yuri

On Thu, Dec 11, 2014 at 3:23 AM, Gary Kotton gkot...@vmware.com wrote:


 On 12/11/14, 12:50 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 +100. I vote -1 there and would like to point out that we *must* keep
 history during the split, and split from u/s code base, not random
 repositories. If you don't know how to achieve this, ask oslo people,
 they did it plenty of times when graduating libraries from oslo-incubator.
 /Ihar
 
 On 10/12/14 19:18, Cedric OLLIVIER wrote:
  https://review.openstack.org/#/c/140191/
 
  2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com
  mailto:arma...@gmail.com:
 
 
  By the way, if Kyle can do it in his teeny tiny time that he has
  left after his PTL duties, then anyone can do it! :)
 
  https://review.openstack.org/#/c/140191/

 This patch looses the recent hacking changes that we have made. This is a
 slight example to try and highly the problem that we may incur as a
 community.

 
  Fully cloning Dave Tucker's repository [1] and the outdated fork of
  the ODL ML2 MechanismDriver included raises some questions (e.g.
  [2]). I wish the next patch set removes some files. At least it
  should take the mainstream work into account (e.g. [3]) .
 
  [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
  https://review.openstack.org/#/c/113330/ [3]
  https://review.openstack.org/#/c/96459/
 
 
  ___ OpenStack-dev
  mailing list OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
 
 iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
 ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
 E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
 PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
 l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
 lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
 =dfe/
 -END PGP SIGNATURE-
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-12 Thread Armando M.
On 12 December 2014 at 23:01, Yuriy Shovkoplias yshovkopl...@mirantis.com
wrote:

 Dear neutron community,

 Can you please clarify couple points on the vendor code decomposition?
  - Assuming I would like to create the new driver now (Kilo development
 cycle) - is it already allowed (or mandatory) to follow the new process?

 https://review.openstack.org/#/c/134680/


Yes. See [1] for more details.


 - Assuming the new process is already in place, are the following
 guidelines still applicable for the vendor integration code (not for vendor
 library)?

 https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers
 The following is a list of requirements for inclusion of code upstream:

- Participation in Neutron meetings, IRC channels, and email lists.
- A member of the plugin/driver team participating in code reviews of
other upstream code.


I see no reason why you wouldn't follow those guidelines, as a general rule
of thumb. Having said that, some of the wording would need to be tweaked to
take into account of the new contribution model. Bear in mind, that I
started adding some developer documentation in [2], to give a practical
guide to the proposal. More to follow.

Cheers,
Armando

[1]
http://docs-draft.openstack.org/80/134680/17/check/gate-neutron-specs-docs/2a7afdd/doc/build/html/specs/kilo/core-vendor-decomposition.html#adoption-and-deprecation-policy
[2]
https://review.openstack.org/#/q/status:open+project:openstack/neutron+branch:master+topic:bp/core-vendor-decomposition,n,z


 Regards,
 Yuri

 On Thu, Dec 11, 2014 at 3:23 AM, Gary Kotton gkot...@vmware.com wrote:


 On 12/11/14, 12:50 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512
 
 +100. I vote -1 there and would like to point out that we *must* keep
 history during the split, and split from u/s code base, not random
 repositories. If you don't know how to achieve this, ask oslo people,
 they did it plenty of times when graduating libraries from
 oslo-incubator.
 /Ihar
 
 On 10/12/14 19:18, Cedric OLLIVIER wrote:
  https://review.openstack.org/#/c/140191/
 
  2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com
  mailto:arma...@gmail.com:
 
 
  By the way, if Kyle can do it in his teeny tiny time that he has
  left after his PTL duties, then anyone can do it! :)
 
  https://review.openstack.org/#/c/140191/

 This patch looses the recent hacking changes that we have made. This is a
 slight example to try and highly the problem that we may incur as a
 community.

 
  Fully cloning Dave Tucker's repository [1] and the outdated fork of
  the ODL ML2 MechanismDriver included raises some questions (e.g.
  [2]). I wish the next patch set removes some files. At least it
  should take the mainstream work into account (e.g. [3]) .
 
  [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
  https://review.openstack.org/#/c/113330/ [3]
  https://review.openstack.org/#/c/96459/
 
 
  ___ OpenStack-dev
  mailing list OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
 
 iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
 ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
 E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
 PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
 l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
 lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
 =dfe/
 -END PGP SIGNATURE-
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-11 Thread Ihar Hrachyshka
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

+100. I vote -1 there and would like to point out that we *must* keep
history during the split, and split from u/s code base, not random
repositories. If you don't know how to achieve this, ask oslo people,
they did it plenty of times when graduating libraries from oslo-incubator.
/Ihar

On 10/12/14 19:18, Cedric OLLIVIER wrote:
 https://review.openstack.org/#/c/140191/
 
 2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com 
 mailto:arma...@gmail.com:
 
 
 By the way, if Kyle can do it in his teeny tiny time that he has 
 left after his PTL duties, then anyone can do it! :)
 
 https://review.openstack.org/#/c/140191/
 
 Fully cloning Dave Tucker's repository [1] and the outdated fork of
 the ODL ML2 MechanismDriver included raises some questions (e.g.
 [2]). I wish the next patch set removes some files. At least it
 should take the mainstream work into account (e.g. [3]) .
 
 [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
 https://review.openstack.org/#/c/113330/ [3]
 https://review.openstack.org/#/c/96459/
 
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org 
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
=dfe/
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-11 Thread Gary Kotton

On 12/11/14, 12:50 PM, Ihar Hrachyshka ihrac...@redhat.com wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

+100. I vote -1 there and would like to point out that we *must* keep
history during the split, and split from u/s code base, not random
repositories. If you don't know how to achieve this, ask oslo people,
they did it plenty of times when graduating libraries from oslo-incubator.
/Ihar

On 10/12/14 19:18, Cedric OLLIVIER wrote:
 https://review.openstack.org/#/c/140191/
 
 2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com
 mailto:arma...@gmail.com:
 
 
 By the way, if Kyle can do it in his teeny tiny time that he has
 left after his PTL duties, then anyone can do it! :)
 
 https://review.openstack.org/#/c/140191/

This patch looses the recent hacking changes that we have made. This is a
slight example to try and highly the problem that we may incur as a
community.

 
 Fully cloning Dave Tucker's repository [1] and the outdated fork of
 the ODL ML2 MechanismDriver included raises some questions (e.g.
 [2]). I wish the next patch set removes some files. At least it
 should take the mainstream work into account (e.g. [3]) .
 
 [1] https://github.com/dave-tucker/odl-neutron-drivers [2]
 https://review.openstack.org/#/c/113330/ [3]
 https://review.openstack.org/#/c/96459/
 
 
 ___ OpenStack-dev
 mailing list OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iQEcBAEBCgAGBQJUiXcIAAoJEC5aWaUY1u57dBMH/17unffokpb0uxqewPYrPNMI
ukDzG4dW8mIP3yfbVNsHQXe6gWj/kj/SkBWJrO13BusTu8hrr+DmOmmfF/42s3vY
E+6EppQDoUjR+QINBwE46nU+E1w9hIHyAZYbSBtaZQ32c8aQbmHmF+rgoeEQq349
PfpPLRI6MamFWRQMXSgF11VBTg8vbz21PXnN3KbHbUgzI/RS2SELv4SWmPgKZCEl
l1K5J1/Vnz2roJn4pr/cfc7vnUIeAB5a9AuBHC6o+6Je2RDy79n+oBodC27kmmIx
lVGdypoxZ9tF3yfRM9nngjkOtozNzZzaceH0Sc/5JR4uvNReVN4exzkX5fDH+SM=
=dfe/
-END PGP SIGNATURE-

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-10 Thread Kevin Benton
Remove everything out of tree, and leave only Neutron API framework as 
integration
platform, would lower the attractions of the whole Openstack Project.
Without a default good enough reference backend from community, customers
have to depends on packagers to fully test all backends for them.

That's not what's being proposed. Please read the spec.
There will still be a tested reference implementation from the community
that gates all changes. Where the code lives has no impact on customers.

On Wed, Dec 10, 2014 at 12:32 AM, loy wolfe loywo...@gmail.com wrote:

 Remove everything out of tree, and leave only Neutron API framework as
 integration platform, would lower the attractions of the whole
 Openstack Project. Without a default good enough reference backend
 from community, customers have to depends on packagers to fully test
 all backends for them. Can we image nova without kvm, glance without
 swift? Cinder is weak because of default lvm backend, if in the future
 Ceph became the default it would be much better.

 If the goal of this decomposition is eventually moving default
 reference driver out, and the in-tree OVS backend is an eyesore, then
 it's better to split the Neutron core with base repo and vendor repo.
 They only share common base API/DB model, each vendor can extend their
 API, DB model freely, using a shim proxy to delegate all the service
 logic to their backend controller. They can choose to keep out of
 tree, or in tree (vendor repo) with the previous policy that
 contribute code reviewing for their code being reviewed by other
 vendors.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-10 Thread Cedric OLLIVIER
 https://review.openstack.org/#/c/140191/

2014-12-09 18:32 GMT+01:00 Armando M. arma...@gmail.com:


 By the way, if Kyle can do it in his teeny tiny time that he has left
 after his PTL duties, then anyone can do it! :)

 https://review.openstack.org/#/c/140191/

 Fully cloning Dave Tucker's repository [1] and the outdated fork of the
ODL ML2 MechanismDriver included raises some questions (e.g. [2]).
I wish the next patch set removes some files. At least it should take the
mainstream work into account (e.g. [3]) .

[1] https://github.com/dave-tucker/odl-neutron-drivers
[2] https://review.openstack.org/#/c/113330/
[3] https://review.openstack.org/#/c/96459/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Salvatore Orlando
 for patches) for a few days so that we will can just
 focus on this. I stated what I think should be the process on the review.
 For those who do not feel like finding the link:
• Create a stack forge project for ML2
• Create the shim in Neutron
• Update devstack for the to use the two repos and the shim
  When #3 is up and running we switch for that to be the gate. Then we
 start a stopwatch on all other plugins.

 As was pointed out on the spec (see Miguel’s comment on r15), the ML2
 plugin and the OVS mechanism driver need to remain in the main Neutron repo
 for now.  Neutron gates on ML2+OVS and landing a breaking change in the
 Neutron repo along with its corresponding fix to a separate ML2 repo would
 be all but impossible under the current integrated gating scheme.
 Plugins/drivers that do not gate Neutron have no such constraint.


 Maru


  Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash
 out the details at the meetup. Sadly I will not be able to attend – so you
 will have to delay on the tar and feathers.
  Thanks
  Gary
 
 
  From: mest...@mestery.com mest...@mestery.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Sunday, December 7, 2014 at 7:19 PM
  To: OpenStack List openstack-dev@lists.openstack.org
  Cc: openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Gary, you are still miss the point of this proposal. Please see my
 comments in review. We are not forcing things out of tree, we are thinning
 them. The text you quoted in the review makes that clear. We will look at
 further decomposing ML2 post Kilo, but we have to be realistic with what we
 can accomplish during Kilo.
 
  Find me on IRC Monday morning and we can discuss further if you still
 have questions and concerns.
 
  Thanks!
  Kyle
 
  On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com wrote:
  Hi,
  I have raised my concerns on the proposal. I think that all plugins
 should be treated on an equal footing. My main concern is having the ML2
 plugin in tree whilst the others will be moved out of tree will be
 problematic. I think that the model will be complete if the ML2 was also
 out of tree. This will help crystalize the idea and make sure that the
 model works correctly.
  Thanks
  Gary
 
  From: Armando M. arma...@gmail.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Saturday, December 6, 2014 at 1:04 AM
  To: OpenStack List openstack-dev@lists.openstack.org, 
 openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Hi folks,
 
  For a few weeks now the Neutron team has worked tirelessly on [1].
 
  This initiative stems from the fact that as the project matures,
 evolution of processes and contribution guidelines need to evolve with it.
 This is to ensure that the project can keep on thriving in order to meet
 the needs of an ever growing community.
 
  The effort of documenting intentions, and fleshing out the various
 details of the proposal is about to reach an end, and we'll soon kick the
 tires to put the proposal into practice. Since the spec has grown pretty
 big, I'll try to capture the tl;dr below.
 
  If you have any comment please do not hesitate to raise them here
 and/or reach out to us.
 
  tl;dr 
 
  From the Kilo release, we'll initiate a set of steps to change the
 following areas:
   • Code structure: every plugin or driver that exists or wants to
 exist as part of Neutron project is decomposed in an slim vendor
 integration (which lives in the Neutron repo), plus a bulkier vendor
 library (which lives in an independent publicly available repo);
   • Contribution process: this extends to the following aspects:
   • Design and Development: the process is largely unchanged
 for the part that pertains the vendor integration; the maintainer team is
 fully auto governed for the design and development of the vendor library;
   • Testing and Continuous Integration: maintainers will be
 required to support their vendor integration with 3rd CI testing; the
 requirements for 3rd CI testing are largely unchanged;
   • Defect management: the process is largely unchanged,
 issues affecting the vendor library can be tracked with whichever
 tool/process the maintainer see fit. In cases where vendor library fixes
 need to be reflected in the vendor integration, the usual OpenStack defect
 management apply.
   • Documentation: there will be some changes to the way
 plugins and drivers are documented with the intention of promoting
 discoverability of the integrated solutions.
   • Adoption and transition plan: we strongly advise maintainers to
 stay abreast of the developments of this effort, as their code, their CI,
 etc will be affected. The core team will provide guidelines and support
 throughout

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Armando M.
 Kotton gkot...@vmware.com wrote:

  Hi Kyle,
  I am not missing the point. I understand the proposal. I just think
 that it has some shortcomings (unless I misunderstand, which will certainly
 not be the first time and most definitely not the last). The thinning out
 is to have a shim in place. I understand this and this will be the entry
 point for the plugin. I do not have a concern for this. My concern is that
 we are not doing this with the ML2 off the bat. That should lead by example
 as it is our reference architecture. Lets not kid anyone, but we are going
 to hit some problems with the decomposition. I would prefer that it be done
 with the default implementation. Why?

 The proposal is to move vendor-specific logic out of the tree to increase
 vendor control over such code while decreasing load on reviewers.  ML2
 doesn’t contain vendor-specific logic - that’s the province of ML2 drivers
 - so it is not a good target for the proposed decomposition by itself.


• Cause we will fix them quicker as it is something that prevent
 Neutron from moving forwards
• We will just need to fix in one place first and not in N (where
 N is the vendor plugins)
• This is a community effort – so we will have a lot more eyes on
 it
• It will provide a reference architecture for all new plugins
 that want to be added to the tree
• It will provide a working example for plugin that are already
 in tree and are to be replaced by the shim
  If we really want to do this, we can say freeze all development (which
 is just approvals for patches) for a few days so that we will can just
 focus on this. I stated what I think should be the process on the review.
 For those who do not feel like finding the link:
• Create a stack forge project for ML2
• Create the shim in Neutron
• Update devstack for the to use the two repos and the shim
  When #3 is up and running we switch for that to be the gate. Then we
 start a stopwatch on all other plugins.

 As was pointed out on the spec (see Miguel’s comment on r15), the ML2
 plugin and the OVS mechanism driver need to remain in the main Neutron repo
 for now.  Neutron gates on ML2+OVS and landing a breaking change in the
 Neutron repo along with its corresponding fix to a separate ML2 repo would
 be all but impossible under the current integrated gating scheme.
 Plugins/drivers that do not gate Neutron have no such constraint.


 Maru


  Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash
 out the details at the meetup. Sadly I will not be able to attend – so you
 will have to delay on the tar and feathers.
  Thanks
  Gary
 
 
  From: mest...@mestery.com mest...@mestery.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Sunday, December 7, 2014 at 7:19 PM
  To: OpenStack List openstack-dev@lists.openstack.org
  Cc: openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Gary, you are still miss the point of this proposal. Please see my
 comments in review. We are not forcing things out of tree, we are thinning
 them. The text you quoted in the review makes that clear. We will look at
 further decomposing ML2 post Kilo, but we have to be realistic with what we
 can accomplish during Kilo.
 
  Find me on IRC Monday morning and we can discuss further if you still
 have questions and concerns.
 
  Thanks!
  Kyle
 
  On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com wrote:
  Hi,
  I have raised my concerns on the proposal. I think that all plugins
 should be treated on an equal footing. My main concern is having the ML2
 plugin in tree whilst the others will be moved out of tree will be
 problematic. I think that the model will be complete if the ML2 was also
 out of tree. This will help crystalize the idea and make sure that the
 model works correctly.
  Thanks
  Gary
 
  From: Armando M. arma...@gmail.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Saturday, December 6, 2014 at 1:04 AM
  To: OpenStack List openstack-dev@lists.openstack.org, 
 openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Hi folks,
 
  For a few weeks now the Neutron team has worked tirelessly on [1].
 
  This initiative stems from the fact that as the project matures,
 evolution of processes and contribution guidelines need to evolve with it.
 This is to ensure that the project can keep on thriving in order to meet
 the needs of an ever growing community.
 
  The effort of documenting intentions, and fleshing out the various
 details of the proposal is about to reach an end, and we'll soon kick the
 tires to put the proposal into practice. Since the spec has grown pretty
 big, I'll try to capture the tl;dr below.
 
  If you have any comment please do not hesitate to raise them here
 and/or reach out to us.
 
  tl;dr

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Salvatore Orlando
 investment. This proposal actually promotes new and pre-existing investment.

 [1] https://review.openstack.org/#/c/104452/
 [2] https://review.openstack.org/#/c/103728/
 [3] https://review.openstack.org/#/c/136091/

3 - Regarding the above discussion on ML2 or not ML2. The point on
 co-gating is well taken. Eventually we'd like to remove this binding -
 because I believe the ML2 subteam would also like to have more freedom on
 their plugin. Do we already have an idea about how doing that without
 completely moving away from the db_base class approach?

 Sure, if you like to participate in the process, we can only welcome you!


I actually asked you if you already had an idea... should I take that as a
no?

 Thanks for your attention and for reading through this

 Salvatore

 [1]
 http://git.openstack.org/cgit/openstack/neutron/tree/neutron/plugins/vmware/plugin.py#n22

 On 8 December 2014 at 21:51, Maru Newby ma...@redhat.com wrote:


 On Dec 7, 2014, at 10:51 AM, Gary Kotton gkot...@vmware.com wrote:

  Hi Kyle,
  I am not missing the point. I understand the proposal. I just think
 that it has some shortcomings (unless I misunderstand, which will certainly
 not be the first time and most definitely not the last). The thinning out
 is to have a shim in place. I understand this and this will be the entry
 point for the plugin. I do not have a concern for this. My concern is that
 we are not doing this with the ML2 off the bat. That should lead by example
 as it is our reference architecture. Lets not kid anyone, but we are going
 to hit some problems with the decomposition. I would prefer that it be done
 with the default implementation. Why?

 The proposal is to move vendor-specific logic out of the tree to
 increase vendor control over such code while decreasing load on reviewers.
 ML2 doesn’t contain vendor-specific logic - that’s the province of ML2
 drivers - so it is not a good target for the proposed decomposition by
 itself.


• Cause we will fix them quicker as it is something that prevent
 Neutron from moving forwards
• We will just need to fix in one place first and not in N
 (where N is the vendor plugins)
• This is a community effort – so we will have a lot more eyes
 on it
• It will provide a reference architecture for all new plugins
 that want to be added to the tree
• It will provide a working example for plugin that are already
 in tree and are to be replaced by the shim
  If we really want to do this, we can say freeze all development (which
 is just approvals for patches) for a few days so that we will can just
 focus on this. I stated what I think should be the process on the review.
 For those who do not feel like finding the link:
• Create a stack forge project for ML2
• Create the shim in Neutron
• Update devstack for the to use the two repos and the shim
  When #3 is up and running we switch for that to be the gate. Then we
 start a stopwatch on all other plugins.

 As was pointed out on the spec (see Miguel’s comment on r15), the ML2
 plugin and the OVS mechanism driver need to remain in the main Neutron repo
 for now.  Neutron gates on ML2+OVS and landing a breaking change in the
 Neutron repo along with its corresponding fix to a separate ML2 repo would
 be all but impossible under the current integrated gating scheme.
 Plugins/drivers that do not gate Neutron have no such constraint.


 Maru


  Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash
 out the details at the meetup. Sadly I will not be able to attend – so you
 will have to delay on the tar and feathers.
  Thanks
  Gary
 
 
  From: mest...@mestery.com mest...@mestery.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Sunday, December 7, 2014 at 7:19 PM
  To: OpenStack List openstack-dev@lists.openstack.org
  Cc: openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Gary, you are still miss the point of this proposal. Please see my
 comments in review. We are not forcing things out of tree, we are thinning
 them. The text you quoted in the review makes that clear. We will look at
 further decomposing ML2 post Kilo, but we have to be realistic with what we
 can accomplish during Kilo.
 
  Find me on IRC Monday morning and we can discuss further if you still
 have questions and concerns.
 
  Thanks!
  Kyle
 
  On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com
 wrote:
  Hi,
  I have raised my concerns on the proposal. I think that all plugins
 should be treated on an equal footing. My main concern is having the ML2
 plugin in tree whilst the others will be moved out of tree will be
 problematic. I think that the model will be complete if the ML2 was also
 out of tree. This will help crystalize the idea and make sure that the
 model works correctly.
  Thanks
  Gary
 
  From: Armando M. arma...@gmail.com
  Reply-To: OpenStack

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Ivar Lazzaro
 not be the first time and most definitely not the last). The thinning out
 is to have a shim in place. I understand this and this will be the entry
 point for the plugin. I do not have a concern for this. My concern is that
 we are not doing this with the ML2 off the bat. That should lead by example
 as it is our reference architecture. Lets not kid anyone, but we are going
 to hit some problems with the decomposition. I would prefer that it be done
 with the default implementation. Why?

 The proposal is to move vendor-specific logic out of the tree to
 increase vendor control over such code while decreasing load on reviewers.
 ML2 doesn’t contain vendor-specific logic - that’s the province of ML2
 drivers - so it is not a good target for the proposed decomposition by
 itself.


• Cause we will fix them quicker as it is something that
 prevent Neutron from moving forwards
• We will just need to fix in one place first and not in N
 (where N is the vendor plugins)
• This is a community effort – so we will have a lot more eyes
 on it
• It will provide a reference architecture for all new plugins
 that want to be added to the tree
• It will provide a working example for plugin that are already
 in tree and are to be replaced by the shim
  If we really want to do this, we can say freeze all development
 (which is just approvals for patches) for a few days so that we will can
 just focus on this. I stated what I think should be the process on the
 review. For those who do not feel like finding the link:
• Create a stack forge project for ML2
• Create the shim in Neutron
• Update devstack for the to use the two repos and the shim
  When #3 is up and running we switch for that to be the gate. Then we
 start a stopwatch on all other plugins.

 As was pointed out on the spec (see Miguel’s comment on r15), the ML2
 plugin and the OVS mechanism driver need to remain in the main Neutron repo
 for now.  Neutron gates on ML2+OVS and landing a breaking change in the
 Neutron repo along with its corresponding fix to a separate ML2 repo would
 be all but impossible under the current integrated gating scheme.
 Plugins/drivers that do not gate Neutron have no such constraint.


 Maru


  Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash
 out the details at the meetup. Sadly I will not be able to attend – so you
 will have to delay on the tar and feathers.
  Thanks
  Gary
 
 
  From: mest...@mestery.com mest...@mestery.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Sunday, December 7, 2014 at 7:19 PM
  To: OpenStack List openstack-dev@lists.openstack.org
  Cc: openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Gary, you are still miss the point of this proposal. Please see my
 comments in review. We are not forcing things out of tree, we are thinning
 them. The text you quoted in the review makes that clear. We will look at
 further decomposing ML2 post Kilo, but we have to be realistic with what we
 can accomplish during Kilo.
 
  Find me on IRC Monday morning and we can discuss further if you still
 have questions and concerns.
 
  Thanks!
  Kyle
 
  On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com
 wrote:
  Hi,
  I have raised my concerns on the proposal. I think that all plugins
 should be treated on an equal footing. My main concern is having the ML2
 plugin in tree whilst the others will be moved out of tree will be
 problematic. I think that the model will be complete if the ML2 was also
 out of tree. This will help crystalize the idea and make sure that the
 model works correctly.
  Thanks
  Gary
 
  From: Armando M. arma...@gmail.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Saturday, December 6, 2014 at 1:04 AM
  To: OpenStack List openstack-dev@lists.openstack.org, 
 openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Hi folks,
 
  For a few weeks now the Neutron team has worked tirelessly on [1].
 
  This initiative stems from the fact that as the project matures,
 evolution of processes and contribution guidelines need to evolve with it.
 This is to ensure that the project can keep on thriving in order to meet
 the needs of an ever growing community.
 
  The effort of documenting intentions, and fleshing out the various
 details of the proposal is about to reach an end, and we'll soon kick the
 tires to put the proposal into practice. Since the spec has grown pretty
 big, I'll try to capture the tl;dr below.
 
  If you have any comment please do not hesitate to raise them here
 and/or reach out to us.
 
  tl;dr 
 
  From the Kilo release, we'll initiate a set of steps to change the
 following areas:
   • Code structure: every plugin or driver that exists or wants
 to exist as part of Neutron project

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Vadivel Poonathan
 to remain in the main Neutron 
 repo
 for now.  Neutron gates on ML2+OVS and landing a breaking change in the
 Neutron repo along with its corresponding fix to a separate ML2 repo 
 would
 be all but impossible under the current integrated gating scheme.
 Plugins/drivers that do not gate Neutron have no such constraint.


 Maru


  Sure, I’ll catch you on IRC tomorrow. I guess that you guys will
 bash out the details at the meetup. Sadly I will not be able to attend – 
 so
 you will have to delay on the tar and feathers.
  Thanks
  Gary
 
 
  From: mest...@mestery.com mest...@mestery.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Sunday, December 7, 2014 at 7:19 PM
  To: OpenStack List openstack-dev@lists.openstack.org
  Cc: openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron] Core/Vendor code
 decomposition
 
  Gary, you are still miss the point of this proposal. Please see my
 comments in review. We are not forcing things out of tree, we are 
 thinning
 them. The text you quoted in the review makes that clear. We will look at
 further decomposing ML2 post Kilo, but we have to be realistic with what 
 we
 can accomplish during Kilo.
 
  Find me on IRC Monday morning and we can discuss further if you
 still have questions and concerns.
 
  Thanks!
  Kyle
 
  On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com
 wrote:
  Hi,
  I have raised my concerns on the proposal. I think that all
 plugins should be treated on an equal footing. My main concern is having
 the ML2 plugin in tree whilst the others will be moved out of tree will 
 be
 problematic. I think that the model will be complete if the ML2 was also
 out of tree. This will help crystalize the idea and make sure that the
 model works correctly.
  Thanks
  Gary
 
  From: Armando M. arma...@gmail.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Saturday, December 6, 2014 at 1:04 AM
  To: OpenStack List openstack-dev@lists.openstack.org, 
 openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Hi folks,
 
  For a few weeks now the Neutron team has worked tirelessly on [1].
 
  This initiative stems from the fact that as the project matures,
 evolution of processes and contribution guidelines need to evolve with 
 it.
 This is to ensure that the project can keep on thriving in order to meet
 the needs of an ever growing community.
 
  The effort of documenting intentions, and fleshing out the various
 details of the proposal is about to reach an end, and we'll soon kick the
 tires to put the proposal into practice. Since the spec has grown pretty
 big, I'll try to capture the tl;dr below.
 
  If you have any comment please do not hesitate to raise them here
 and/or reach out to us.
 
  tl;dr 
 
  From the Kilo release, we'll initiate a set of steps to change the
 following areas:
   • Code structure: every plugin or driver that exists or wants
 to exist as part of Neutron project is decomposed in an slim vendor
 integration (which lives in the Neutron repo), plus a bulkier vendor
 library (which lives in an independent publicly available repo);
   • Contribution process: this extends to the following aspects:
   • Design and Development: the process is largely
 unchanged for the part that pertains the vendor integration; the 
 maintainer
 team is fully auto governed for the design and development of the vendor
 library;
   • Testing and Continuous Integration: maintainers
 will be required to support their vendor integration with 3rd CI testing;
 the requirements for 3rd CI testing are largely unchanged;
   • Defect management: the process is largely
 unchanged, issues affecting the vendor library can be tracked with
 whichever tool/process the maintainer see fit. In cases where vendor
 library fixes need to be reflected in the vendor integration, the usual
 OpenStack defect management apply.
   • Documentation: there will be some changes to the
 way plugins and drivers are documented with the intention of promoting
 discoverability of the integrated solutions.
   • Adoption and transition plan: we strongly advise
 maintainers to stay abreast of the developments of this effort, as their
 code, their CI, etc will be affected. The core team will provide 
 guidelines
 and support throughout this cycle the ensure a smooth transition.
  To learn more, please refer to [1].
 
  Many thanks,
  Armando
 
  [1] https://review.openstack.org/#/c/134680
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread Ivar Lazzaro
 to remain in the main Neutron 
 repo
 for now.  Neutron gates on ML2+OVS and landing a breaking change in the
 Neutron repo along with its corresponding fix to a separate ML2 repo 
 would
 be all but impossible under the current integrated gating scheme.
 Plugins/drivers that do not gate Neutron have no such constraint.


 Maru


  Sure, I’ll catch you on IRC tomorrow. I guess that you guys will
 bash out the details at the meetup. Sadly I will not be able to attend – 
 so
 you will have to delay on the tar and feathers.
  Thanks
  Gary
 
 
  From: mest...@mestery.com mest...@mestery.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Sunday, December 7, 2014 at 7:19 PM
  To: OpenStack List openstack-dev@lists.openstack.org
  Cc: openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron] Core/Vendor code
 decomposition
 
  Gary, you are still miss the point of this proposal. Please see my
 comments in review. We are not forcing things out of tree, we are 
 thinning
 them. The text you quoted in the review makes that clear. We will look at
 further decomposing ML2 post Kilo, but we have to be realistic with what 
 we
 can accomplish during Kilo.
 
  Find me on IRC Monday morning and we can discuss further if you
 still have questions and concerns.
 
  Thanks!
  Kyle
 
  On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com
 wrote:
  Hi,
  I have raised my concerns on the proposal. I think that all
 plugins should be treated on an equal footing. My main concern is having
 the ML2 plugin in tree whilst the others will be moved out of tree will 
 be
 problematic. I think that the model will be complete if the ML2 was also
 out of tree. This will help crystalize the idea and make sure that the
 model works correctly.
  Thanks
  Gary
 
  From: Armando M. arma...@gmail.com
  Reply-To: OpenStack List openstack-dev@lists.openstack.org
  Date: Saturday, December 6, 2014 at 1:04 AM
  To: OpenStack List openstack-dev@lists.openstack.org, 
 openst...@lists.openstack.org openst...@lists.openstack.org
  Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
  Hi folks,
 
  For a few weeks now the Neutron team has worked tirelessly on [1].
 
  This initiative stems from the fact that as the project matures,
 evolution of processes and contribution guidelines need to evolve with 
 it.
 This is to ensure that the project can keep on thriving in order to meet
 the needs of an ever growing community.
 
  The effort of documenting intentions, and fleshing out the various
 details of the proposal is about to reach an end, and we'll soon kick the
 tires to put the proposal into practice. Since the spec has grown pretty
 big, I'll try to capture the tl;dr below.
 
  If you have any comment please do not hesitate to raise them here
 and/or reach out to us.
 
  tl;dr 
 
  From the Kilo release, we'll initiate a set of steps to change the
 following areas:
   • Code structure: every plugin or driver that exists or wants
 to exist as part of Neutron project is decomposed in an slim vendor
 integration (which lives in the Neutron repo), plus a bulkier vendor
 library (which lives in an independent publicly available repo);
   • Contribution process: this extends to the following aspects:
   • Design and Development: the process is largely
 unchanged for the part that pertains the vendor integration; the 
 maintainer
 team is fully auto governed for the design and development of the vendor
 library;
   • Testing and Continuous Integration: maintainers
 will be required to support their vendor integration with 3rd CI testing;
 the requirements for 3rd CI testing are largely unchanged;
   • Defect management: the process is largely
 unchanged, issues affecting the vendor library can be tracked with
 whichever tool/process the maintainer see fit. In cases where vendor
 library fixes need to be reflected in the vendor integration, the usual
 OpenStack defect management apply.
   • Documentation: there will be some changes to the
 way plugins and drivers are documented with the intention of promoting
 discoverability of the integrated solutions.
   • Adoption and transition plan: we strongly advise
 maintainers to stay abreast of the developments of this effort, as their
 code, their CI, etc will be affected. The core team will provide 
 guidelines
 and support throughout this cycle the ensure a smooth transition.
  To learn more, please refer to [1].
 
  Many thanks,
  Armando
 
  [1] https://review.openstack.org/#/c/134680
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-09 Thread loy wolfe
Remove everything out of tree, and leave only Neutron API framework as
integration platform, would lower the attractions of the whole
Openstack Project. Without a default good enough reference backend
from community, customers have to depends on packagers to fully test
all backends for them. Can we image nova without kvm, glance without
swift? Cinder is weak because of default lvm backend, if in the future
Ceph became the default it would be much better.

If the goal of this decomposition is eventually moving default
reference driver out, and the in-tree OVS backend is an eyesore, then
it's better to split the Neutron core with base repo and vendor repo.
They only share common base API/DB model, each vendor can extend their
API, DB model freely, using a shim proxy to delegate all the service
logic to their backend controller. They can choose to keep out of
tree, or in tree (vendor repo) with the previous policy that
contribute code reviewing for their code being reviewed by other
vendors.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-08 Thread Maru Newby

On Dec 7, 2014, at 10:51 AM, Gary Kotton gkot...@vmware.com wrote:

 Hi Kyle,
 I am not missing the point. I understand the proposal. I just think that it 
 has some shortcomings (unless I misunderstand, which will certainly not be 
 the first time and most definitely not the last). The thinning out is to have 
 a shim in place. I understand this and this will be the entry point for the 
 plugin. I do not have a concern for this. My concern is that we are not doing 
 this with the ML2 off the bat. That should lead by example as it is our 
 reference architecture. Lets not kid anyone, but we are going  to hit some 
 problems with the decomposition. I would prefer that it be done with the 
 default implementation. Why?

The proposal is to move vendor-specific logic out of the tree to increase 
vendor control over such code while decreasing load on reviewers.  ML2 doesn’t 
contain vendor-specific logic - that’s the province of ML2 drivers - so it is 
not a good target for the proposed decomposition by itself.


   • Cause we will fix them quicker as it is something that prevent 
 Neutron from moving forwards
   • We will just need to fix in one place first and not in N (where N is 
 the vendor plugins)
   • This is a community effort – so we will have a lot more eyes on it
   • It will provide a reference architecture for all new plugins that 
 want to be added to the tree
   • It will provide a working example for plugin that are already in tree 
 and are to be replaced by the shim
 If we really want to do this, we can say freeze all development (which is 
 just approvals for patches) for a few days so that we will can just focus on 
 this. I stated what I think should be the process on the review. For those 
 who do not feel like finding the link:
   • Create a stack forge project for ML2
   • Create the shim in Neutron
   • Update devstack for the to use the two repos and the shim
 When #3 is up and running we switch for that to be the gate. Then we start a 
 stopwatch on all other plugins.

As was pointed out on the spec (see Miguel’s comment on r15), the ML2 plugin 
and the OVS mechanism driver need to remain in the main Neutron repo for now.  
Neutron gates on ML2+OVS and landing a breaking change in the Neutron repo 
along with its corresponding fix to a separate ML2 repo would be all but 
impossible under the current integrated gating scheme.  Plugins/drivers that do 
not gate Neutron have no such constraint.


Maru


 Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash out the 
 details at the meetup. Sadly I will not be able to attend – so you will have 
 to delay on the tar and feathers.
 Thanks
 Gary
 
 
 From: mest...@mestery.com mest...@mestery.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Sunday, December 7, 2014 at 7:19 PM
 To: OpenStack List openstack-dev@lists.openstack.org
 Cc: openst...@lists.openstack.org openst...@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
 Gary, you are still miss the point of this proposal. Please see my comments 
 in review. We are not forcing things out of tree, we are thinning them. The 
 text you quoted in the review makes that clear. We will look at further 
 decomposing ML2 post Kilo, but we have to be realistic with what we can 
 accomplish during Kilo.
 
 Find me on IRC Monday morning and we can discuss further if you still have 
 questions and concerns.
 
 Thanks!
 Kyle
 
 On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com wrote:
 Hi,
 I have raised my concerns on the proposal. I think that all plugins should 
 be treated on an equal footing. My main concern is having the ML2 plugin in 
 tree whilst the others will be moved out of tree will be problematic. I 
 think that the model will be complete if the ML2 was also out of tree. This 
 will help crystalize the idea and make sure that the model works correctly.
 Thanks
 Gary
 
 From: Armando M. arma...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Saturday, December 6, 2014 at 1:04 AM
 To: OpenStack List openstack-dev@lists.openstack.org, 
 openst...@lists.openstack.org openst...@lists.openstack.org
 Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition
 
 Hi folks,
 
 For a few weeks now the Neutron team has worked tirelessly on [1].
 
 This initiative stems from the fact that as the project matures, evolution 
 of processes and contribution guidelines need to evolve with it. This is to 
 ensure that the project can keep on thriving in order to meet the needs of 
 an ever growing community.
 
 The effort of documenting intentions, and fleshing out the various details 
 of the proposal is about to reach an end, and we'll soon kick the tires to 
 put the proposal into practice. Since the spec has grown pretty big, I'll 
 try to capture the tl;dr below.
 
 If you have any comment please do not hesitate to raise them here

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-07 Thread Gary Kotton
Hi,
I have raised my concerns on the proposal. I think that all plugins should be 
treated on an equal footing. My main concern is having the ML2 plugin in tree 
whilst the others will be moved out of tree will be problematic. I think that 
the model will be complete if the ML2 was also out of tree. This will help 
crystalize the idea and make sure that the model works correctly.
Thanks
Gary

From: Armando M. arma...@gmail.commailto:arma...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Saturday, December 6, 2014 at 1:04 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition

Hi folks,

For a few weeks now the Neutron team has worked tirelessly on [1].

This initiative stems from the fact that as the project matures, evolution of 
processes and contribution guidelines need to evolve with it. This is to ensure 
that the project can keep on thriving in order to meet the needs of an ever 
growing community.

The effort of documenting intentions, and fleshing out the various details of 
the proposal is about to reach an end, and we'll soon kick the tires to put the 
proposal into practice. Since the spec has grown pretty big, I'll try to 
capture the tl;dr below.

If you have any comment please do not hesitate to raise them here and/or reach 
out to us.

tl;dr 

From the Kilo release, we'll initiate a set of steps to change the following 
areas:

  *   Code structure: every plugin or driver that exists or wants to exist as 
part of Neutron project is decomposed in an slim vendor integration (which 
lives in the Neutron repo), plus a bulkier vendor library (which lives in an 
independent publicly available repo);
  *   Contribution process: this extends to the following aspects:
 *   Design and Development: the process is largely unchanged for the part 
that pertains the vendor integration; the maintainer team is fully auto 
governed for the design and development of the vendor library;
 *   Testing and Continuous Integration: maintainers will be required to 
support their vendor integration with 3rd CI testing; the requirements for 3rd 
CI testing are largely unchanged;
 *   Defect management: the process is largely unchanged, issues affecting 
the vendor library can be tracked with whichever tool/process the maintainer 
see fit. In cases where vendor library fixes need to be reflected in the vendor 
integration, the usual OpenStack defect management apply.
 *   Documentation: there will be some changes to the way plugins and 
drivers are documented with the intention of promoting discoverability of the 
integrated solutions.
  *   Adoption and transition plan: we strongly advise maintainers to stay 
abreast of the developments of this effort, as their code, their CI, etc will 
be affected. The core team will provide guidelines and support throughout this 
cycle the ensure a smooth transition.

To learn more, please refer to [1].

Many thanks,
Armando

[1] https://review.openstack.org/#/c/134680
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-07 Thread Kyle Mestery
Gary, you are still miss the point of this proposal. Please see my comments
in review. We are not forcing things out of tree, we are thinning them. The
text you quoted in the review makes that clear. We will look at further
decomposing ML2 post Kilo, but we have to be realistic with what we can
accomplish during Kilo.

Find me on IRC Monday morning and we can discuss further if you still have
questions and concerns.

Thanks!
Kyle

On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton gkot...@vmware.com wrote:

  Hi,
 I have raised my concerns on the proposal. I think that all plugins should
 be treated on an equal footing. My main concern is having the ML2 plugin in
 tree whilst the others will be moved out of tree will be problematic. I
 think that the model will be complete if the ML2 was also out of tree. This
 will help crystalize the idea and make sure that the model works correctly.
 Thanks
 Gary

   From: Armando M. arma...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Saturday, December 6, 2014 at 1:04 AM
 To: OpenStack List openstack-dev@lists.openstack.org, 
 openst...@lists.openstack.org openst...@lists.openstack.org
 Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition

   Hi folks,

  For a few weeks now the Neutron team has worked tirelessly on [1].

  This initiative stems from the fact that as the project matures,
 evolution of processes and contribution guidelines need to evolve with it.
 This is to ensure that the project can keep on thriving in order to meet
 the needs of an ever growing community.

  The effort of documenting intentions, and fleshing out the various
 details of the proposal is about to reach an end, and we'll soon kick the
 tires to put the proposal into practice. Since the spec has grown pretty
 big, I'll try to capture the tl;dr below.

  If you have any comment please do not hesitate to raise them here and/or
 reach out to us.

  tl;dr 

  From the Kilo release, we'll initiate a set of steps to change the
 following areas:

- Code structure: every plugin or driver that exists or wants to exist
as part of Neutron project is decomposed in an slim vendor integration
(which lives in the Neutron repo), plus a bulkier vendor library (which
lives in an independent publicly available repo);
- Contribution process: this extends to the following aspects:
   - Design and Development: the process is largely unchanged for the
   part that pertains the vendor integration; the maintainer team is fully
   auto governed for the design and development of the vendor library;
   - Testing and Continuous Integration: maintainers will be required
   to support their vendor integration with 3rd CI testing; the 
 requirements
   for 3rd CI testing are largely unchanged;
   - Defect management: the process is largely unchanged, issues
   affecting the vendor library can be tracked with whichever tool/process 
 the
   maintainer see fit. In cases where vendor library fixes need to be
   reflected in the vendor integration, the usual OpenStack defect 
 management
   apply.
   - Documentation: there will be some changes to the way plugins and
   drivers are documented with the intention of promoting discoverability 
 of
   the integrated solutions.
- Adoption and transition plan: we strongly advise maintainers to stay
abreast of the developments of this effort, as their code, their CI, etc
will be affected. The core team will provide guidelines and support
throughout this cycle the ensure a smooth transition.

 To learn more, please refer to [1].

  Many thanks,
 Armando

  [1] https://review.openstack.org/#/c/134680

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

2014-12-07 Thread Gary Kotton
Hi Kyle,
I am not missing the point. I understand the proposal. I just think that it has 
some shortcomings (unless I misunderstand, which will certainly not be the 
first time and most definitely not the last). The thinning out is to have a 
shim in place. I understand this and this will be the entry point for the 
plugin. I do not have a concern for this. My concern is that we are not doing 
this with the ML2 off the bat. That should lead by example as it is our 
reference architecture. Lets not kid anyone, but we are going to hit some 
problems with the decomposition. I would prefer that it be done with the 
default implementation. Why?

  1.  Cause we will fix them quicker as it is something that prevent Neutron 
from moving forwards
  2.  We will just need to fix in one place first and not in N (where N is the 
vendor plugins)
  3.  This is a community effort – so we will have a lot more eyes on it
  4.  It will provide a reference architecture for all new plugins that want to 
be added to the tree
  5.  It will provide a working example for plugin that are already in tree and 
are to be replaced by the shim

If we really want to do this, we can say freeze all development (which is just 
approvals for patches) for a few days so that we will can just focus on this. I 
stated what I think should be the process on the review. For those who do not 
feel like finding the link:

  1.  Create a stack forge project for ML2
  2.  Create the shim in Neutron
  3.  Update devstack for the to use the two repos and the shim

When #3 is up and running we switch for that to be the gate. Then we start a 
stopwatch on all other plugins.

Sure, I’ll catch you on IRC tomorrow. I guess that you guys will bash out the 
details at the meetup. Sadly I will not be able to attend – so you will have to 
delay on the tar and feathers.
Thanks
Gary


From: mest...@mestery.commailto:mest...@mestery.com 
mest...@mestery.commailto:mest...@mestery.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Sunday, December 7, 2014 at 7:19 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Cc: openst...@lists.openstack.orgmailto:openst...@lists.openstack.org 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

Gary, you are still miss the point of this proposal. Please see my comments in 
review. We are not forcing things out of tree, we are thinning them. The text 
you quoted in the review makes that clear. We will look at further decomposing 
ML2 post Kilo, but we have to be realistic with what we can accomplish during 
Kilo.

Find me on IRC Monday morning and we can discuss further if you still have 
questions and concerns.

Thanks!
Kyle

On Sun, Dec 7, 2014 at 2:08 AM, Gary Kotton 
gkot...@vmware.commailto:gkot...@vmware.com wrote:
Hi,
I have raised my concerns on the proposal. I think that all plugins should be 
treated on an equal footing. My main concern is having the ML2 plugin in tree 
whilst the others will be moved out of tree will be problematic. I think that 
the model will be complete if the ML2 was also out of tree. This will help 
crystalize the idea and make sure that the model works correctly.
Thanks
Gary

From: Armando M. arma...@gmail.commailto:arma...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Saturday, December 6, 2014 at 1:04 AM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org, 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org 
openst...@lists.openstack.orgmailto:openst...@lists.openstack.org
Subject: [openstack-dev] [Neutron] Core/Vendor code decomposition

Hi folks,

For a few weeks now the Neutron team has worked tirelessly on [1].

This initiative stems from the fact that as the project matures, evolution of 
processes and contribution guidelines need to evolve with it. This is to ensure 
that the project can keep on thriving in order to meet the needs of an ever 
growing community.

The effort of documenting intentions, and fleshing out the various details of 
the proposal is about to reach an end, and we'll soon kick the tires to put the 
proposal into practice. Since the spec has grown pretty big, I'll try to 
capture the tl;dr below.

If you have any comment please do not hesitate to raise them here and/or reach 
out to us.

tl;dr 

From the Kilo release, we'll initiate a set of steps to change the following 
areas:

  *   Code structure: every plugin or driver that exists or wants to exist as 
part of Neutron project is decomposed in an slim vendor integration (which 
lives in the Neutron repo), plus a bulkier vendor library (which lives in an 
independent publicly available repo);
  *   Contribution process: this extends to the following aspects:
 *   Design and Development: the process