Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Kevin Benton]

No, I wouldn't consider that to be monkey-patching. That's something that
we have a pluggable driver interface for. As Ihar pointed out, you will
have to be careful maintaining it since the class you are subclassing may
move or alter the '_build_cmdline_callback' method, but that isn't a huge
deal.

What I wouldn't want to see is a sub-project modifying core components of
the OVS agent or ML2 plugin and claiming that it is still using the OVS
agent or ML2 plugin.

On Mon, Aug 31, 2015 at 4:36 AM, Neil Jerram 
wrote:

> Hi Kevin,
>
> I currently have an example of this kind of thing that I'm working on, and
> I'd appreciate hearing your view on what is the best solution.
>
> My requirement was to change some of the command line options with which
> the DHCP agent invokes Dnsmasq.  My first implementation of this was in
> core Neutron, triggered by an interface driver method or property, and you
> can see various versions of that at [1].  Then I realized that I could also
> do this using an out-of-core subclass of Dnsmasq, and you can see that
> approach at [2].
>
> [1] https://review.openstack.org/#/c/206077/
> [2] https://review.openstack.org/#/c/218486/
>
> I guess the question is: would you consider [2] to be a monkey-patch, in
> the sense that you had in mind when writing below?  If it is, I guess that
> means that I should continue pursuing the approach of [1].
>
> Many thanks,
> Neil
>
>
>
> On 31/08/15 06:53, Kevin Benton wrote:
>
> If your sub-project requires changes to the Neutron API or client, then
> those need to be made in the in the main neutron and client projects.
> monkey-patching or completely replacing components of the main neutron
> project is not the way to go.
>
> The purpose of big tent isn't to have a bunch of sub-projects change the
> neutron core APIs and reference in ways they deem necessary. That will lead
> to a terrible user experience where the core functionality changes
> depending on which sub-projects are loaded. Sub-projects should add new
> extensions or write drivers/plugins for various backends.
>
> On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver 
> wrote:
>
>> It's possible that I've misunderstood "Big Tent/Stadium", but I thought
>> we were talking about enhancements to Neutron, not separate unrelated
>> projects.
>>
>> We have several efforts focused on adding capabilities to Neutron. This
>> isn't about "polluting" the Neutron namespace but rather about adding
>> capabilities that Neutron currently is missing.
>>
>> My concern is that we need to add to the Neutron API, the Neutron CLI,
>> and enhance the capabilities of the OvS agent. I'm under the impression
>> that the "Neutron Stadium" allows us to do this, but I'm fuzzy on the
>> implementation details.
>>
>> Is the "Neutron Stadium" expected to allow additions to the Neutron API,
>> the Neutron client, and the Neutron components such as ML2 and the OvS
>> agent?
>>
>>
>>
>> __
>> 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
>>
>
>
>
> --
> Kevin Benton
>
>
>
> __
> 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
>
>


-- 
Kevin Benton
__
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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Jay Pipes]

On 08/31/2015 01:50 AM, Kevin Benton wrote:

The purpose of big tent isn't to have a bunch of sub-projects change the
neutron core APIs and reference in ways they deem necessary. That will
lead to a terrible user experience where the core functionality changes
depending on which sub-projects are loaded.


Exactly correct.

Best,
-jay

__
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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Neil Jerram]

Thanks, Kevin and Ihar, for your advice on this.  I think I know what to do 
with my change now, and I hope I haven't too much hijacked the previous 
direction of this thread.

Regards,
  Neil


From: Kevin Benton
Sent: Monday, 31 August 2015 16:38
To: OpenStack Development Mailing List (not for usage questions)
Reply To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or 
packaging


No, I wouldn't consider that to be monkey-patching. That's something that we 
have a pluggable driver interface for. As Ihar pointed out, you will have to be 
careful maintaining it since the class you are subclassing may move or alter 
the '_build_cmdline_callback' method, but that isn't a huge deal.

What I wouldn't want to see is a sub-project modifying core components of the 
OVS agent or ML2 plugin and claiming that it is still using the OVS agent or 
ML2 plugin.

On Mon, Aug 31, 2015 at 4:36 AM, Neil Jerram 
<neil.jer...@metaswitch.com<mailto:neil.jer...@metaswitch.com>> wrote:
Hi Kevin,

I currently have an example of this kind of thing that I'm working on, and I'd 
appreciate hearing your view on what is the best solution.

My requirement was to change some of the command line options with which the 
DHCP agent invokes Dnsmasq.  My first implementation of this was in core 
Neutron, triggered by an interface driver method or property, and you can see 
various versions of that at [1].  Then I realized that I could also do this 
using an out-of-core subclass of Dnsmasq, and you can see that approach at [2].

[1] https://review.openstack.org/#/c/206077/
[2] https://review.openstack.org/#/c/218486/

I guess the question is: would you consider [2] to be a monkey-patch, in the 
sense that you had in mind when writing below?  If it is, I guess that means 
that I should continue pursuing the approach of [1].

Many thanks,
Neil



On 31/08/15 06:53, Kevin Benton wrote:
If your sub-project requires changes to the Neutron API or client, then those 
need to be made in the in the main neutron and client projects. monkey-patching 
or completely replacing components of the main neutron project is not the way 
to go.

The purpose of big tent isn't to have a bunch of sub-projects change the 
neutron core APIs and reference in ways they deem necessary. That will lead to 
a terrible user experience where the core functionality changes depending on 
which sub-projects are loaded. Sub-projects should add new extensions or write 
drivers/plugins for various backends.

On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver 
<pcar...@paulcarver.us<mailto:pcar...@paulcarver.us>> wrote:
It's possible that I've misunderstood "Big Tent/Stadium", but I thought we were 
talking about enhancements to Neutron, not separate unrelated projects.

We have several efforts focused on adding capabilities to Neutron. This isn't 
about "polluting" the Neutron namespace but rather about adding capabilities 
that Neutron currently is missing.

My concern is that we need to add to the Neutron API, the Neutron CLI, and 
enhance the capabilities of the OvS agent. I'm under the impression that the 
"Neutron Stadium" allows us to do this, but I'm fuzzy on the implementation 
details.

Is the "Neutron Stadium" expected to allow additions to the Neutron API, the 
Neutron client, and the Neutron components such as ML2 and the OvS agent?



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Kevin Benton


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev




--
Kevin Benton
__
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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Neil Jerram]

Hi Kevin,

I currently have an example of this kind of thing that I'm working on, and I'd 
appreciate hearing your view on what is the best solution.

My requirement was to change some of the command line options with which the 
DHCP agent invokes Dnsmasq.  My first implementation of this was in core 
Neutron, triggered by an interface driver method or property, and you can see 
various versions of that at [1].  Then I realized that I could also do this 
using an out-of-core subclass of Dnsmasq, and you can see that approach at [2].

[1] https://review.openstack.org/#/c/206077/
[2] https://review.openstack.org/#/c/218486/

I guess the question is: would you consider [2] to be a monkey-patch, in the 
sense that you had in mind when writing below?  If it is, I guess that means 
that I should continue pursuing the approach of [1].

Many thanks,
Neil


On 31/08/15 06:53, Kevin Benton wrote:
If your sub-project requires changes to the Neutron API or client, then those 
need to be made in the in the main neutron and client projects. monkey-patching 
or completely replacing components of the main neutron project is not the way 
to go.

The purpose of big tent isn't to have a bunch of sub-projects change the 
neutron core APIs and reference in ways they deem necessary. That will lead to 
a terrible user experience where the core functionality changes depending on 
which sub-projects are loaded. Sub-projects should add new extensions or write 
drivers/plugins for various backends.

On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver 
> wrote:
It's possible that I've misunderstood "Big Tent/Stadium", but I thought we were 
talking about enhancements to Neutron, not separate unrelated projects.

We have several efforts focused on adding capabilities to Neutron. This isn't 
about "polluting" the Neutron namespace but rather about adding capabilities 
that Neutron currently is missing.

My concern is that we need to add to the Neutron API, the Neutron CLI, and 
enhance the capabilities of the OvS agent. I'm under the impression that the 
"Neutron Stadium" allows us to do this, but I'm fuzzy on the implementation 
details.

Is the "Neutron Stadium" expected to allow additions to the Neutron API, the 
Neutron client, and the Neutron components such as ML2 and the OvS agent?



__
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



--
Kevin Benton

__
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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Ihar Hrachyshka]

> On 31 Aug 2015, at 13:36, Neil Jerram  wrote:
> 
> Hi Kevin,
> 
> I currently have an example of this kind of thing that I'm working on, and 
> I'd appreciate hearing your view on what is the best solution.
> 
> My requirement was to change some of the command line options with which the 
> DHCP agent invokes Dnsmasq.  My first implementation of this was in core 
> Neutron, triggered by an interface driver method or property, and you can see 
> various versions of that at [1].  Then I realized that I could also do this 
> using an out-of-core subclass of Dnsmasq, and you can see that approach at 
> [2].
> 
> [1] https://review.openstack.org/#/c/206077/
> [2] https://review.openstack.org/#/c/218486/
> 
> I guess the question is: would you consider [2] to be a monkey-patch, in the 
> sense that you had in mind when writing below?  If it is, I guess that means 
> that I should continue pursuing the approach of [1].
> 

I believe Dnsmasq class does not intend to maintain a stable API, so the method 
that you override may change its name at any moment, breaking your subproject. 
The fact that the method name starts with underscore only suggests that it’s 
not the best approach to extend it. If you would like to base your driver on 
top of Dnsmasq, ideally, you would work with neutron community to detect pieces 
that are absolutely needed for your subproject, and work on defining a stable 
API that you can then reuse.

But if the only thing you need is to pass some custom configuration to dnsmasq, 
then you may already have all you need. Specifically, you could configure 
dnsmasq_config_file = in dhcp_agent.ini to point to a file that contains all 
your custom settings.

Ihar
__
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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Kevin Benton]

If your sub-project requires changes to the Neutron API or client, then
those need to be made in the in the main neutron and client projects.
monkey-patching or completely replacing components of the main neutron
project is not the way to go.

The purpose of big tent isn't to have a bunch of sub-projects change the
neutron core APIs and reference in ways they deem necessary. That will lead
to a terrible user experience where the core functionality changes
depending on which sub-projects are loaded. Sub-projects should add new
extensions or write drivers/plugins for various backends.

On Fri, Aug 28, 2015 at 7:19 PM, Paul Carver  wrote:

> It's possible that I've misunderstood "Big Tent/Stadium", but I thought we
> were talking about enhancements to Neutron, not separate unrelated projects.
>
> We have several efforts focused on adding capabilities to Neutron. This
> isn't about "polluting" the Neutron namespace but rather about adding
> capabilities that Neutron currently is missing.
>
> My concern is that we need to add to the Neutron API, the Neutron CLI, and
> enhance the capabilities of the OvS agent. I'm under the impression that
> the "Neutron Stadium" allows us to do this, but I'm fuzzy on the
> implementation details.
>
> Is the "Neutron Stadium" expected to allow additions to the Neutron API,
> the Neutron client, and the Neutron components such as ML2 and the OvS
> agent?
>
>
>
> __
> 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
>



-- 
Kevin Benton
__
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-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Paul Carver]

Has anyone written anything up about expectations for how Big Tent or 
Neutron Stadium projects are expected to be 
installed/distributed/packaged?


In particular, I'm wondering how we're supposed to handle changes to 
Neutron components. For the networking-sfc project we need to make 
additions to the API and corresponding additions to neutronclient as 
well as modifying the OvS agent to configure new flow table entries in OvS.


The code is in a separate Git repo as is expected of a Stadium project 
but it doesn't make sense that we would package altered copies of files 
that are deployed by the regular Neutron packages.


Should we be creating 99%+ of the functionality in filenames that don't 
conflict and then making changes to files in the Neutron and 
neutronclient repos to stitch together the 1% that adds our new 
functionality to the existing components? Or do we stage the code in the 
Stadium project's repo then subsequently request to merge it into the 
neutron/neutronclient repo? Or is there some other preferred way to 
integrate the added features?




__
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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Ihar Hrachyshka]

 On 28 Aug 2015, at 14:08, Paul Carver pcar...@paulcarver.us wrote:
 
 Has anyone written anything up about expectations for how Big Tent or 
 Neutron Stadium projects are expected to be installed/distributed/packaged?
 

Seems like your questions below are more about extendability than e.g. 
packaging.

 In particular, I'm wondering how we're supposed to handle changes to Neutron 
 components. For the networking-sfc project we need to make additions to the 
 API and corresponding additions to neutronclient as well as modifying the OvS 
 agent to configure new flow table entries in OvS.
 
 The code is in a separate Git repo as is expected of a Stadium project but it 
 doesn't make sense that we would package altered copies of files that are 
 deployed by the regular Neutron packages.
 

Of course you should not ship you custom version of neutron with your 
sub-project. Instead, you should work with neutron team to make sure you have 
all needed to extend it without duplicating efforts in your project.

 Should we be creating 99%+ of the functionality in filenames that don't 
 conflict and then making changes to files in the Neutron and neutronclient 
 repos to stitch together the 1% that adds our new functionality to the 
 existing components? Or do we stage the code in the Stadium project's repo 
 then subsequently request to merge it into the neutron/neutronclient repo? Or 
 is there some other preferred way to integrate the added features?
 

I presume that all sub-projects should use their own python namespace and not 
pollute neutron.* namespace. If that’s not the case for your sub-project, you 
should migrate to a new namespace asap.

If there is anything missing in neutron or neutronclient for you to integrate 
with it, then you should work in those repositories to get the extension hooks 
or features you miss, and after it’s in neutron, you will merely utilise them 
from your sub-project. Of course it means some kind of dependency on the 
progress in neutron repository to be able to estimate feature plans in your 
sub-project.

Ihar
__
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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Kyle Mestery]

On Fri, Aug 28, 2015 at 8:07 AM, Ihar Hrachyshka ihrac...@redhat.com
wrote:

  On 28 Aug 2015, at 14:08, Paul Carver pcar...@paulcarver.us wrote:
 
  Has anyone written anything up about expectations for how Big Tent or
 Neutron Stadium projects are expected to be
 installed/distributed/packaged?
 

 Seems like your questions below are more about extendability than e.g.
 packaging.


I agree, though I will say that your project is listed as
release:independent [1]. This means that networking-sfc will NOT release
when neutron and neutron-[fwaas, lbaas, vpnaas] release Liberty, but can
release whenever it desires. This would be when the code is complete and
the team has decided a release should be made. The process for handling
this release is documented here [2] (though wait for that to refresh based
on the review which merged here [3]).

[1] http://governance.openstack.org/reference/projects/neutron.html
[2]
http://docs.openstack.org/developer/neutron/devref/sub_project_guidelines.html#releases
[3] https://review.openstack.org/#/c/217723/


  In particular, I'm wondering how we're supposed to handle changes to
 Neutron components. For the networking-sfc project we need to make
 additions to the API and corresponding additions to neutronclient as well
 as modifying the OvS agent to configure new flow table entries in OvS.
 
  The code is in a separate Git repo as is expected of a Stadium project
 but it doesn't make sense that we would package altered copies of files
 that are deployed by the regular Neutron packages.
 

 Of course you should not ship you custom version of neutron with your
 sub-project. Instead, you should work with neutron team to make sure you
 have all needed to extend it without duplicating efforts in your project.

  Should we be creating 99%+ of the functionality in filenames that don't
 conflict and then making changes to files in the Neutron and neutronclient
 repos to stitch together the 1% that adds our new functionality to the
 existing components? Or do we stage the code in the Stadium project's repo
 then subsequently request to merge it into the neutron/neutronclient repo?
 Or is there some other preferred way to integrate the added features?
 

 I presume that all sub-projects should use their own python namespace and
 not pollute neutron.* namespace. If that’s not the case for your
 sub-project, you should migrate to a new namespace asap.

 If there is anything missing in neutron or neutronclient for you to
 integrate with it, then you should work in those repositories to get the
 extension hooks or features you miss, and after it’s in neutron, you will
 merely utilise them from your sub-project. Of course it means some kind of
 dependency on the progress in neutron repository to be able to estimate
 feature plans in your sub-project.

 I'll second Ihar here. If you have dependencies in other projects, those
need to be worked in so they can be consumed by networking-sfc.


 Ihar
 __
 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

Re: [openstack-dev] [neutron][sfc] Neutron stadium distribution and/or packaging

[Paul Carver]

It's possible that I've misunderstood Big Tent/Stadium, but I thought 
we were talking about enhancements to Neutron, not separate unrelated 
projects.


We have several efforts focused on adding capabilities to Neutron. This 
isn't about polluting the Neutron namespace but rather about adding 
capabilities that Neutron currently is missing.


My concern is that we need to add to the Neutron API, the Neutron CLI, 
and enhance the capabilities of the OvS agent. I'm under the impression 
that the Neutron Stadium allows us to do this, but I'm fuzzy on the 
implementation details.


Is the Neutron Stadium expected to allow additions to the Neutron API, 
the Neutron client, and the Neutron components such as ML2 and the OvS 
agent?



__
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