Re: [openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[P. Ramanjaneya Reddy]

>From paste logs..

2015-11-13 18:07:00.926 INFO neutron.manager [-] Loading Plugin:
*networking_sfc.services.sfc.plugin.SFCPlugin*
2015-11-13 18:07:00.974 INFO
n*etworking_sfc.services.sfc.driver_manager* [-] Configured portchain
driver names: ['dummy']
2015-11-13 18:07:00.975 ERROR stevedore.extension [-] Could not load
'dummy': No module named portchain.drivers.dummy



networking_sfc.services.sfc.plugin.SFCPlugin

==> it should be networking_sfc.services.sfc.plugin.SfcPlugin


n*etworking_sfc.services.sfc.driver_manager ==> wrong path specified.*



*It seems driver changes are not been latest and also check serivce
plugin path.*

*Before run devstack, please merge all pacthes(cli/driver..) changes
on master networking-sfc*

Thanks & Regards,

Ramanji.


On Tue, Nov 17, 2015 at 12:03 AM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi networking-sfc folks,
>
>
>
> I can’t seem to be able to deploy the current networking-sfc using
> DevStack and my hint is that the latest review stack is dependent on
> previous patches that have not been updated/rebased yet ([1] and [2]) – and
> are depending on outdated patches.
>
>
>
> In [3] you can see the output of q-svc after a clean DevStack installation
> (based on master) with the local.conf specified in [4].
>
> I have pointed /opt/stack/networking-sfc to the last patch in the
> networking-sfc review stack, [5].
>
>
>
> Please advise on how to proceed in order to get networking-sfc to work.
>
>
>
> [1] https://review.openstack.org/#/c/227285
>
> [2] https://review.openstack.org/#/c/227100
>
> [3] http://paste.openstack.org/show/479020/
>
> [4] http://paste.openstack.org/show/479021/
>
> [5] https://review.openstack.org/#/c/238428/
>
>
>
> Best regards,
>
>
>
> [image: intel]
>
>
>
> *Igor Duarte Cardoso*
>
> Software Engineer
>
> +353 61 777 858
>
> SIE1-2-170
>
> Intel Shannon Ltd.
>
> Dromore House, East Park
>
> Shannon, Co. Clare
>
> IRELAND
>
>
>
> --
> Intel Research and Development Ireland Limited
> Registered in Ireland
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
> Registered Number: 308263
>
> This e-mail and any attachments may contain confidential material for the
> sole use of the intended recipient(s). Any review or distribution by others
> is strictly prohibited. If you are not the intended recipient, please
> contact the sender and delete all copies.
>
>
> __
> 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

[openstack-dev] [neutron][networking-sfc] Deploying current networking-sfc

[Duarte Cardoso, Igor]

Hi networking-sfc folks,

I can't seem to be able to deploy the current networking-sfc using DevStack and 
my hint is that the latest review stack is dependent on previous patches that 
have not been updated/rebased yet ([1] and [2]) - and are depending on outdated 
patches.

In [3] you can see the output of q-svc after a clean DevStack installation 
(based on master) with the local.conf specified in [4].
I have pointed /opt/stack/networking-sfc to the last patch in the 
networking-sfc review stack, [5].

Please advise on how to proceed in order to get networking-sfc to work.

[1] https://review.openstack.org/#/c/227285
[2] https://review.openstack.org/#/c/227100
[3] http://paste.openstack.org/show/479020/
[4] http://paste.openstack.org/show/479021/
[5] https://review.openstack.org/#/c/238428/

Best regards,

[intel]

Igor Duarte Cardoso
Software Engineer
+353 61 777 858
SIE1-2-170
Intel Shannon Ltd.
Dromore House, East Park
Shannon, Co. Clare
IRELAND

--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263


This e-mail and any attachments may contain confidential material for the sole
use of the intended recipient(s). Any review or distribution by others is
strictly prohibited. If you are not the intended recipient, please contact the
sender and delete all copies.
__
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][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Networking-sfc not just a shell. It has API, DB, DB Migration, Common Driver 
Manager, OVS Driver, OVS Agent, CLI, Horizon etc. codes uploaded for review for 
over one month. The project team is in the final review stage. And a patch for 
adding DevStack support for networking-sfc has also been uploaded for review. 
Once these codes are merged, the codes will be ready for download and 
deployment. 

Thanks,
Cathy

-Original Message-
From: Sean M. Collins [mailto:s...@coreitpro.com] 
Sent: Monday, November 16, 2015 12:39 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

Networking-sfc is still just a shell - there is no functional code.

-- 
Sean M. Collins

__
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][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Hi Duarte,

We have just rebased the patches. We are in the stage of more comprehensive 
testing, bug fixes, review, and incorporating review comments. The code patches 
including the devstack patch will be merged once they are properly reviewed, 
and you can then download and deploy this functionality.

Thanks,
Cathy

From: Duarte Cardoso, Igor [mailto:igor.duarte.card...@intel.com]
Sent: Monday, November 16, 2015 10:34 AM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

Hi networking-sfc folks,

I can't seem to be able to deploy the current networking-sfc using DevStack and 
my hint is that the latest review stack is dependent on previous patches that 
have not been updated/rebased yet ([1] and [2]) - and are depending on outdated 
patches.

In [3] you can see the output of q-svc after a clean DevStack installation 
(based on master) with the local.conf specified in [4].
I have pointed /opt/stack/networking-sfc to the last patch in the 
networking-sfc review stack, [5].

Please advise on how to proceed in order to get networking-sfc to work.

[1] https://review.openstack.org/#/c/227285
[2] https://review.openstack.org/#/c/227100
[3] http://paste.openstack.org/show/479020/
[4] http://paste.openstack.org/show/479021/
[5] https://review.openstack.org/#/c/238428/

Best regards,

[intel]

Igor Duarte Cardoso
Software Engineer
+353 61 777 858
SIE1-2-170
Intel Shannon Ltd.
Dromore House, East Park
Shannon, Co. Clare
IRELAND


--
Intel Research and Development Ireland Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.
__
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][networking-sfc] Deploying current networking-sfc

[Kyle Mestery]

On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant  wrote:

> On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> > On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
> >> This is a challenge. Personally, I haven't been able to get it all
> working
> >> yet. But we're in a dilemma because we want to get good reviews of the
> code
> >> before merging. Since the full functionality is quite a lot of code we
> >> wanted to chop it into more easily reviewable chunks. Unfortunately that
> >> makes it more difficult to pull it all in at once to test the whole
> thing
> >> prior to completing the review and merge.
> >
> > I would be concerned about that. I am sympathetic to the chicken and egg
> > problem of a new repo and new code, but I briefly looked at both of
> > those reviews and they both are quite large. 1K LOC is usually the upper
> > limit for a sane patch set. It may be worth trying to break into
> > smaller, more manageable pieces - even if the initial commits just
> > create some empty classes and stubbed methods, and then later start
> > introducing the actual method bodies in small pieces with good unit
> > tests for each one. Small pieces. Tiny steps.
>
> Another thing I've been thinking about is the difference between having
> a repo like networking-sfc where a sub-group is able to try out new
> things while also managing expectations with consumers of Neutron.  How
> does someone know the difference between something a bit more
> experimental vs. when an API is established and can be considered stable
> and maintained with backwards copmatibility like any other OpenStack
> REST API?
>
> In the case of SFC, consumers of the API should know it's tagged as
"release:independent" [1], and also it should be clear there is no release
made and the code isn't stable in the docs, but that isn't currently the
case looking here [2]. Thus, I've submitted [3] to make this a bit more
clear, comments welcome.

[1] http://governance.openstack.org/reference/projects/neutron.html
[2] http://docs.openstack.org/developer/networking-sfc/
[3] https://review.openstack.org/246001


> I think networking-sfc should be able to keep merging code, including
> the proposed API, but I think it should be clearly marked as
> experimental and subject to change.  That's based on my experience so
> far studying this proposal, SFC more generally, and watching other
> efforts happening within Neutron that affect this.
>
> How can we manage these expectations more clearly?
>
> Well, since it hasn't released yet, I agree, lets experiment and let other
backends try this out, and at the same time not lock things down. We just
need to be clear about the intent here.

Thanks,
Kyle


> --
> Russell Bryant
>
> __
> 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][networking-sfc] Deploying current networking-sfc

[Sean M. Collins]

On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
> This is a challenge. Personally, I haven't been able to get it all working
> yet. But we're in a dilemma because we want to get good reviews of the code
> before merging. Since the full functionality is quite a lot of code we
> wanted to chop it into more easily reviewable chunks. Unfortunately that
> makes it more difficult to pull it all in at once to test the whole thing
> prior to completing the review and merge.

I would be concerned about that. I am sympathetic to the chicken and egg
problem of a new repo and new code, but I briefly looked at both of
those reviews and they both are quite large. 1K LOC is usually the upper
limit for a sane patch set. It may be worth trying to break into
smaller, more manageable pieces - even if the initial commits just
create some empty classes and stubbed methods, and then later start
introducing the actual method bodies in small pieces with good unit
tests for each one. Small pieces. Tiny steps.

My $0.02 USD

-- 
Sean M. Collins

__
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][networking-sfc] Deploying current networking-sfc

[Russell Bryant]

On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
>> This is a challenge. Personally, I haven't been able to get it all working
>> yet. But we're in a dilemma because we want to get good reviews of the code
>> before merging. Since the full functionality is quite a lot of code we
>> wanted to chop it into more easily reviewable chunks. Unfortunately that
>> makes it more difficult to pull it all in at once to test the whole thing
>> prior to completing the review and merge.
> 
> I would be concerned about that. I am sympathetic to the chicken and egg
> problem of a new repo and new code, but I briefly looked at both of
> those reviews and they both are quite large. 1K LOC is usually the upper
> limit for a sane patch set. It may be worth trying to break into
> smaller, more manageable pieces - even if the initial commits just
> create some empty classes and stubbed methods, and then later start
> introducing the actual method bodies in small pieces with good unit
> tests for each one. Small pieces. Tiny steps.

Another thing I've been thinking about is the difference between having
a repo like networking-sfc where a sub-group is able to try out new
things while also managing expectations with consumers of Neutron.  How
does someone know the difference between something a bit more
experimental vs. when an API is established and can be considered stable
and maintained with backwards copmatibility like any other OpenStack
REST API?

I think networking-sfc should be able to keep merging code, including
the proposed API, but I think it should be clearly marked as
experimental and subject to change.  That's based on my experience so
far studying this proposal, SFC more generally, and watching other
efforts happening within Neutron that affect this.

How can we manage these expectations more clearly?

-- 
Russell Bryant

__
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][networking-sfc] Deploying current networking-sfc

[Sean M. Collins]

Networking-sfc is still just a shell - there is no functional code.

-- 
Sean M. Collins

__
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][networking-sfc] Deploying current networking-sfc

[Paul Carver]

On 11/16/2015 3:39 PM, Sean M. Collins wrote:

Networking-sfc is still just a shell - there is no functional code.



To be more clear, most of the code has not yet been merged. Click here 
for a link to all the pending reviews that contain lots of functional 
code targetted at merging into the networking-sfc repo:


https://review.openstack.org/#/q/status:open+project:openstack/networking-sfc,n,z

I believe Igor is aware of this and is trying to figure out how to pull 
all the necessary pending changes that are targetted at the 
networking-sfc repo but which haven't merged yet.


This is a challenge. Personally, I haven't been able to get it all 
working yet. But we're in a dilemma because we want to get good reviews 
of the code before merging. Since the full functionality is quite a lot 
of code we wanted to chop it into more easily reviewable chunks. 
Unfortunately that makes it more difficult to pull it all in at once to 
test the whole thing prior to completing the review and merge.


Either way, there's a whole lot of code. It just* needs to be reviewed.

* Ok, "just" may downplay the amount of effort needed.


__
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][networking-sfc] Deploying current networking-sfc

[Cathy Zhang]

Hi Kyle,

Thanks for adding patch [3] to clarify the current API status.

Cathy

From: Kyle Mestery [mailto:mest...@mestery.com]
Sent: Monday, November 16, 2015 2:16 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron][networking-sfc] Deploying current 
networking-sfc

On Mon, Nov 16, 2015 at 4:03 PM, Russell Bryant 
<rbry...@redhat.com<mailto:rbry...@redhat.com>> wrote:
On 11/16/2015 01:42 PM, Sean M. Collins wrote:
> On Mon, Nov 16, 2015 at 04:11:42PM EST, Paul Carver wrote:
>> This is a challenge. Personally, I haven't been able to get it all working
>> yet. But we're in a dilemma because we want to get good reviews of the code
>> before merging. Since the full functionality is quite a lot of code we
>> wanted to chop it into more easily reviewable chunks. Unfortunately that
>> makes it more difficult to pull it all in at once to test the whole thing
>> prior to completing the review and merge.
>
> I would be concerned about that. I am sympathetic to the chicken and egg
> problem of a new repo and new code, but I briefly looked at both of
> those reviews and they both are quite large. 1K LOC is usually the upper
> limit for a sane patch set. It may be worth trying to break into
> smaller, more manageable pieces - even if the initial commits just
> create some empty classes and stubbed methods, and then later start
> introducing the actual method bodies in small pieces with good unit
> tests for each one. Small pieces. Tiny steps.

Another thing I've been thinking about is the difference between having
a repo like networking-sfc where a sub-group is able to try out new
things while also managing expectations with consumers of Neutron.  How
does someone know the difference between something a bit more
experimental vs. when an API is established and can be considered stable
and maintained with backwards copmatibility like any other OpenStack
REST API?
In the case of SFC, consumers of the API should know it's tagged as 
"release:independent" [1], and also it should be clear there is no release made 
and the code isn't stable in the docs, but that isn't currently the case 
looking here [2]. Thus, I've submitted [3] to make this a bit more clear, 
comments welcome.

[1] http://governance.openstack.org/reference/projects/neutron.html
[2] http://docs.openstack.org/developer/networking-sfc/
[3] https://review.openstack.org/246001

I think networking-sfc should be able to keep merging code, including
the proposed API, but I think it should be clearly marked as
experimental and subject to change.  That's based on my experience so
far studying this proposal, SFC more generally, and watching other
efforts happening within Neutron that affect this.

How can we manage these expectations more clearly?
Well, since it hasn't released yet, I agree, lets experiment and let other 
backends try this out, and at the same time not lock things down. We just need 
to be clear about the intent here.
Thanks,
Kyle

--
Russell Bryant

__
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

__
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