Re: [openstack-dev] [Group-based-policy] Question on GBP installation

[Sumit Naiksatam]

Hi Yuki,

Thanks for your email. We are currently in the process of updating the
packages, and will update this webpage once that happens.

Thanks,
~Sumit.


On Mon, Aug 22, 2016 at 2:17 AM, Yuki Miyahara  wrote:
> Hi GBP Team,
>
> Now I'm trying to install OpenStack (Liberty) with GBP on RHEL7.2[1],
> but I can't find following packages from
> https://www.rdoproject.org/repos/rdo-release.rpm.
>  - openstack-neutron-gbp
>  - python-gbpclient
>  - openstack-dashboard-gbp
>
> Do you know where it is?
>
> [1] https://www.rdoproject.org/networking/neutron-gbp/
>
> Regards,
> Yuki Miyahara
>
> __
> 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] [Group-based-policy] Question on GBP installation

[Yuki Miyahara]

Hi GBP Team,

Now I'm trying to install OpenStack (Liberty) with GBP on RHEL7.2[1],
but I can't find following packages from
https://www.rdoproject.org/repos/rdo-release.rpm.
 - openstack-neutron-gbp
 - python-gbpclient
 - openstack-dashboard-gbp

Do you know where it is?

[1] https://www.rdoproject.org/networking/neutron-gbp/

Regards,
Yuki Miyahara

__
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] [Group-based-policy] what does policy rule action redirect do

[Sumit Naiksatam]

On Mon, Jun 13, 2016 at 3:17 AM, yong sheng gong <18618199...@163.com> wrote:
> hi,
>
> I have followed the steps at
> https://github.com/openstack/group-based-policy/blob/master/gbpservice/tests/contrib/devstack/exercises/gbp_servicechain.sh
>
> and I can see the firewall and lb are created right.
>
> But I thought the vm client-1's traffic will be redirected to firewall, lb
> and last to web-vm-1 somehow.
>

The rendering of the REDIRECT action is specific to the configured
traffic plumber, which in turn would depend on the underlying network
technology that provides connectivity, and also the nature of the
services being chained.

> howerver, I cannot see how it is done, or "redirect" action just helps to
> lauch a firewall, and lb and do nothing others.
>

I suspect you are using the default configuration, in which case a
traffic stitching plumber is used, and for the choice of Neutron FWaaS
firewall, and Neutron LBaaS LB, no traffic steering is required.
Creating the service instances in the appropriate context is enough to
get the traffic to flow through the services configured in the chain.

>
> any idea?
>
> thanks
> yong sheng gong
>
>
>
>
>
>
> __
> 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] [Group-based-policy] what does policy rule action redirect do

[yong sheng gong]

hi,


I have followed the steps at
https://github.com/openstack/group-based-policy/blob/master/gbpservice/tests/contrib/devstack/exercises/gbp_servicechain.sh


and I can see the firewall and lb are created right.


But I thought the vm client-1's traffic will be redirected to firewall, lb and 
last to web-vm-1 somehow.


howerver, I cannot see how it is done, or "redirect" action just helps to lauch 
a firewall, and lb and do nothing others.




any idea?


thanks
yong sheng gong__
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] [Group-based-policy] what does policy rule action redirect do

[gong_ys2004]

hi,
I have followed the steps 
athttps://github.com/openstack/group-based-policy/blob/master/gbpservice/tests/contrib/devstack/exercises/gbp_servicechain.sh
and I can see the firewall and lb are created right.
But I thought the vm client-1's traffic will be redirected to firewall, lb and 
last to web-vm-1 somehow.
howerver, I cannot see how it is done, or "redirect" action just helps to lauch 
a firewall, and lb and do nothing others.

any idea?
thanksyong sheng gong
__
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] [group-based-policy] Can PTs move to other PTGs?

[Duarte Cardoso, Igor]

Hi GBP,

While I was working on the QoS PoC for GBP I observed that policy targets 
require to be associated to a PTG. They also don't seem to be updatable with a 
different PTG, at least not with the CLI. However, looking at the API I see, 
for policy targets:

'policy_target_group_id': {'allow_post': True, 'allow_put': True,
   'validate': {'type:uuid_or_none': None},
   'required': True, 'is_visible': True},

The PTG seems to be updatable, and can even be None. Both Horizon and the CLI 
don't seem to allow/offer a way to change the PTG or even detach the PT from 
the PTG. So, my questions are, should PTs be allowed to move to other PTGs? Or 
even not belong to any at all? Depending on the answer, should the snippet 
above be corrected?

Best regards,
Igor.

__
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] [Group-based-policy] Service Chain work with LBaaS/FWaaS

[Sumit Naiksatam]

Hi Yao, Responses inline.

Thanks,
~Sumit.

On Fri, May 6, 2016 at 12:32 AM, 姚威  wrote:
> Hi all,
>
> I know that GBP can work with neutron(ml2) by resource_mapping, and
> group/policy all work well.
> Assume that I have installed and enabled LBaaS and FWaaS，can I use service
> chain of gbp by `chain_mapping` or other plugins ?
>

Yes. You might want to take a look at the Austin summit video and the
accompanying document which describes all this. Both are available
here:
https://wiki.openstack.org/wiki/GroupBasedPolicy/Austin

> Another question. I use GBP and Cisco APIC as native driver, what is the GBP
> service chain work flow? Such as create a service spec/node and apply it to
> a rule.
>

I believe the answer is yes since the APIC driver is a driver, and the
API is the same for all the drivers.

> I have searched over Internet, less reference and discussion.
>
>
> Thanks
>
> Yao Wei
>
>
> __
> 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] [Group-based-policy] Service Chain work with LBaaS/FWaaS

[姚威]

Hi all,


I know that GBP can work with neutron(ml2) by resource_mapping, and 
group/policy all work well.
Assume that I have installed and enabled LBaaS and FWaaS，can I use service 
chain of gbp by `chain_mapping` or other plugins ? 


Another question. I use GBP and Cisco APIC as native driver, what is the GBP 
service chain work flow? Such as create a service spec/node and apply it to a 
rule.


I have searched over Internet, less reference and discussion.




Thanks


Yao Wei__
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] [Group-based-policy] do we have any usage doc about service function chaining feature?

[Anthony Chow]

I find this URL very useful for Group Based Policy:

https://wiki.openstack.org/wiki/GroupBasedPolicy

https://wiki.openstack.org/wiki/GroupBasedPolicy

Also GitHub usually has good description on how to install.

Hope this is useful, have a nice weekend,

anthony.



On Fri, Mar 11, 2016 at 12:58 AM, gong_ys2004 
wrote:

> Hi,
> I failed to find any usage doc about GBP project's SFC feature.
> Could any one please help to point me to the location?
>
> Thanks
> yong sheng gong
>
> __
> 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] [Group-based-policy] do we have any usage doc about service function chaining feature?

[gong_ys2004]

Hi,I failed to find any usage doc about GBP project's SFC feature.Could any one 
please help to point me to the location?
Thanksyong sheng gong__
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] [Group Based Policy] [Policy] [GBP]

[Sumit Naiksatam]

Hi, Thanks for your question, but we haven’t explored this option. We
will be happy to discuss this and provide any help/pointers you may
need. Please feel free to join our weekly IRC meeting and/or drop into
the #openstack-gbp channel to discuss further.

~Sumit.

On Sun, Dec 13, 2015 at 9:10 AM, Ernesto Valentino
 wrote:
> Hello,
> how can i write an application with gbp using the libcloud? Thanks in
> advance. Best regards,
>
> ernesto
>
>
> __
> 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] [Group Based Policy] [Policy] [GBP]

[Ernesto Valentino]

Hello,
how can i write an application with gbp using the libcloud? Thanks in
advance. Best regards,

ernesto
__
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] [group-based-policy] Meeting today

[Duarte Cardoso, Igor]

Hi GBP team,

Is the meeting today not going to happen due to US Thanksgiving?

Best regards,

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

__
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] [group-based-policy] Meeting today

[Sumit Naiksatam]

Hi Igor, Yes, no meeting today. We discussed in last week’s IRC. Happy
Thanksgiving! ;-)

Best,
~Sumit.

On Thu, Nov 26, 2015 at 9:31 AM, Duarte Cardoso, Igor
 wrote:
> Hi GBP team,
>
>
>
> Is the meeting today not going to happen due to US Thanksgiving?
>
>
>
> Best regards,
>
>
>
> Igor Duarte Cardoso
>
> -
>
> Intel Research and Development Ireland Limited
>
> Registered in Ireland
>
> Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
>
> Registered Number: 308263
>
>
>
>
> __
> 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] [group-based-policy] QoS support in GBP

[Duarte Cardoso, Igor]

Hi OpenStack Group-based Policy team,

As I unofficially said before, I am interested in bringing basic QoS to GBP via 
the Neutron QoS API which currently offers bandwidth limitation at the port and 
network level, since Liberty.

I have added the item to today's Meeting Agenda for an initial discussion about 
this and where it would best fit for GBP.

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] [group-based-policy] QoS support in GBP

[Sumit Naiksatam]

Thanks Igor. This is certainly of interest, let’s discuss during the IRC
meeting today.

Just a friendly reminder - for those in those in the US time zones, we
start an earlier today on account on the fall time changes.

~Sumit.

On Thu, Nov 12, 2015 at 6:47 AM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi OpenStack Group-based Policy team,
>
>
>
> As I unofficially said before, I am interested in bringing basic QoS to
> GBP via the Neutron QoS API which currently offers bandwidth limitation at
> the port and network level, since Liberty.
>
>
>
> I have added the item to today’s Meeting Agenda for an initial discussion
> about this and where it would best fit for GBP.
>
>
>
> 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] [Group-based-policy]

[Ernesto Valentino]

Dear sirs,
I'm a student trying to testing Group Based Policy functionalities. I have
some questions about it, because from the documentation is not clear to me
what role assume opendaylight in the plug-in.
I can use gbp only with openstack or is mandatory to use it with
opendaylight? And next, if I want to add my personal nfv to gbp is there a
possibility to do that or not ? Thanks so much for answering.
Waiting for your kind reply.

Best regards,
Ernesto Valentino
__
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] [Group-based-policy]

[Duarte Cardoso, Igor]

Hi Ernesto,

Let me answer the first question for you.

You can use GBP without OpenDaylight.

OpenDaylight has a separate Group-based Policy project, which might make you 
wonder if you need it to run OpenStack GBP. Don’t worry, you can deploy 
OpenStack GBP right away without OpenDaylight.

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

From: Ernesto Valentino [mailto:ern.valent...@gmail.com]
Sent: Tuesday, November 10, 2015 3:05 PM
To: openstack-dev@lists.openstack.org
Subject: [openstack-dev] [Group-based-policy]

Dear sirs,
I'm a student trying to testing Group Based Policy functionalities. I have some 
questions about it, because from the documentation is not clear to me what role 
assume opendaylight in the plug-in.
I can use gbp only with openstack or is mandatory to use it with opendaylight? 
And next, if I want to add my personal nfv to gbp is there a possibility to do 
that or not ? Thanks so much for answering.
Waiting for your kind reply.

Best regards,
Ernesto Valentino
--
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] [Group-based-policy]

[Sumit Naiksatam]

On Tue, Nov 10, 2015 at 8:41 AM, Duarte Cardoso, Igor <
igor.duarte.card...@intel.com> wrote:

> Hi Ernesto,
>
>
>
> Let me answer the first question for you.
>
>
>
> You can use GBP without OpenDaylight.
>
>
>
> OpenDaylight has a separate Group-based Policy project, which might make
> you wonder if you need it to run OpenStack GBP. Don’t worry, you can deploy
> OpenStack GBP right away without OpenDaylight.
>
>
>
> 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
>
>
>
> *From:* Ernesto Valentino [mailto:ern.valent...@gmail.com]
> *Sent:* Tuesday, November 10, 2015 3:05 PM
> *To:* openstack-dev@lists.openstack.org
> *Subject:* [openstack-dev] [Group-based-policy]
>
>
>
> Dear sirs,
>
> I'm a student trying to testing Group Based Policy functionalities. I have
> some questions about it, because from the documentation is not clear to me
> what role assume opendaylight in the plug-in.
>
> I can use gbp only with openstack or is mandatory to use it with
> opendaylight? And next, if I want to add my personal nfv to gbp is there a
> possibility to do that or not ?
>


​Can you elaborate​ a little as to what exactly you mean by a “personal
NFV”?


Thanks so much for answering.
>
> Waiting for your kind reply.
>
>
>
> Best regards,
>
> Ernesto Valentino
>
> --
> 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

Re: [openstack-dev] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal

[Robert Kukura]

I believe that, on the stable branch at least, we need to fix the 
migrations so that upgrades are possible. This probably means fixing 
them the same way on the master branch first and backporting the fixes 
to stable/juno. All migrations that were present in the initial juno 
release need to be restored to the exact state they were in that 
release, and new migrations need to be added that make the needed schema 
changes, preserving state of existing deployments. I'm assuming there is 
more involved than just the constraint removal in Ivar's [2], but 
haven't checked yet. I think it would be OK to splice these new 
migrations into the chain on master just after the final migration that 
was present in the juno release, since we are not trying to support 
trunk chasers on master. Does this make sense? I do not think it should 
be difficult, unless schema changes were introduced for which deployment 
state cannot be preserved/defaulted.


-Bob

On 4/15/15 3:30 AM, Sumit Naiksatam wrote:

Thanks Ivar for tracking this and bringing it up for discussion. I am
good with taking approach (1).



On Mon, Apr 13, 2015 at 1:10 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:

Hello Team,

As per discussion in the latest GBP meeting [0] I'm hunting down all the
backward incompatible changes made on DB migrations regarding the removal of
unnamed constraints.
In this report [1] you can find the list of affected commits.

The problem is that some of the affected commits are already back ported to
Juno! and others will be [2], so I was wondering what's the plan regarding
how we want back port the compatibility fix to stable/juno.
I see two possibilities:

1) We backport [2] as is (with the broken migration), but we cut the new
stable release only once [3] is merged and back ported. This has the
advantage of having a cleaner backport tree in which all the changes in
master are cherry-picked without major changes.

2) We split [3] in multiple patches, and we only backport those that fix
commits that are already in Juno. Patches like [2] will be changed to
accomodate the fixed migration *before* being merged into the stable branch.
This will avoid intra-release code breakage (which is an issue for people
installing GBP directly from code).

Please share your thoughts, Thanks,
Ivar.

[0]
http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-04-09-18.00.log.txt
[1] https://bugs.launchpad.net/group-based-policy/+bug/1443606
[2] https://review.openstack.org/#/c/170972/
[3] https://review.openstack.org/#/c/173051/

__
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 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] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal

[Sumit Naiksatam]

Thanks Ivar for tracking this and bringing it up for discussion. I am
good with taking approach (1).



On Mon, Apr 13, 2015 at 1:10 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
 Hello Team,

 As per discussion in the latest GBP meeting [0] I'm hunting down all the
 backward incompatible changes made on DB migrations regarding the removal of
 unnamed constraints.
 In this report [1] you can find the list of affected commits.

 The problem is that some of the affected commits are already back ported to
 Juno! and others will be [2], so I was wondering what's the plan regarding
 how we want back port the compatibility fix to stable/juno.
 I see two possibilities:

 1) We backport [2] as is (with the broken migration), but we cut the new
 stable release only once [3] is merged and back ported. This has the
 advantage of having a cleaner backport tree in which all the changes in
 master are cherry-picked without major changes.

 2) We split [3] in multiple patches, and we only backport those that fix
 commits that are already in Juno. Patches like [2] will be changed to
 accomodate the fixed migration *before* being merged into the stable branch.
 This will avoid intra-release code breakage (which is an issue for people
 installing GBP directly from code).

 Please share your thoughts, Thanks,
 Ivar.

 [0]
 http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-04-09-18.00.log.txt
 [1] https://bugs.launchpad.net/group-based-policy/+bug/1443606
 [2] https://review.openstack.org/#/c/170972/
 [3] https://review.openstack.org/#/c/173051/

 __
 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] [Group-Based-Policy] Fixing backward incompatible unnamed constraints removal

[Ivar Lazzaro]

Hello Team,

As per discussion in the latest GBP meeting [0] I'm hunting down all the
backward incompatible changes made on DB migrations regarding the removal
of unnamed constraints.
In this report [1] you can find the list of affected commits.

The problem is that some of the affected commits are already back ported to
Juno! and others will be [2], so I was wondering what's the plan regarding
how we want back port the compatibility fix to stable/juno.
I see two possibilities:

1) We backport [2] as is (with the broken migration), but we cut the new
stable release only once [3] is merged and back ported. This has the
advantage of having a cleaner backport tree in which all the changes in
master are cherry-picked without major changes.

2) We split [3] in multiple patches, and we only backport those that fix
commits that are already in Juno. Patches like [2] will be changed to
accomodate the fixed migration *before* being merged into the stable
branch. This will avoid intra-release code breakage (which is an issue for
people installing GBP directly from code).

Please share your thoughts, Thanks,
Ivar.

[0]
http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-04-09-18.00.log.txt
[1] https://bugs.launchpad.net/group-based-policy/+bug/1443606
[2] https://review.openstack.org/#/c/170972/
[3] https://review.openstack.org/#/c/173051/
__
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] [Group-Based-Policy] Service Chain Instance ownership

[Sumit Naiksatam]

Hi Ivar, Thanks for bringing this up and my apologies for the late
response (although I noticed that you already provided a fix, so
thankfully you were not blocked ;-)). As discussed during the GBP IRC
meeting, my suggestion would also be to use the first option, and
create the service chain instances as admin. I agree that ideally it
would be nice for the users to at least be able to see the created
service chain instances, but that might require some kind of resource
level access control. We should deal with it as a separate
enhancement/feature.

Thanks,
~Sumit.



On Thu, Mar 19, 2015 at 3:13 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
 Hello Folks,

 [tl;dr]

 On implicit chains, the Service Chain Instance ownership in GBP is
 inconsistent, depending on the actor triggering the chain. Possible solution
 is to have all the implicit SCI owned by an admin, or by the provider of the
 chain. Any suggestion is welcome.

 [boringpostwithexampleandstuff]

 I've recently file a bug [0] regarding Service Chain Instance ownership, and
 I would like to get some advice on how to proceed with it.

 Let's take the following final state as an example:

 PTG-A ---PRS-Chain---PTG-B

 PTG A is providing a PRS with a redirect action, which is consumed by PTG-B.
 Reaching this state triggers an implicit SCI creation based on the policy
 action.
 The above state can be reached in multiple ways, some of them are:

 - PTG-A provides PRS-Chain (which is already consumed by PTG-B);
 - PTG-B consumes PRS-Chain (which is already provided by PTG-A);
 - Redirect action is added to PRS-Chain (which is already provided and
 consumed).

 Depending on how that state is reached, in today's implementation the tenant
 owning the SCI may be ultimately different! This is definitively a problem,
 especially when PTG-A and PTG-B are owned by different tenants.
 If having inconsistent behavior on the same state isn't bad enough, another
 issue is that whoever triggers the SCI deletion should also own the SCI or
 will get an exception! And this is definitively not part of the intent.
 In short, we need to decide who has to own the chain instances (and with
 them, the network services themselves). There are two main choices:

 - An Admin owns them all. This will not impact the users' quota, and makes
 it easier to bridge different tenants' networks (when needed/applicable).
 The downside (?) is that the user will never see the SCI and will never be
 able to control the services without admin permissions;

 - The Provider is always the owner. This solution is trickier as far as
 quota are concerned, especially when the services are created using VMs
 (NFV). does the provider need to care about that? why has my VM limit
 suddenly dropped to 0 now that I'm providing this cursed PRS? On the upside,
 the provider can control and modify the service itself if he needs to.

 I personally am a fan of the first option, the user should only care about
 the Intent, and not about this kind of details. But I would like to have
 some insight from the community, especially from other projects that may
 have had this issue and can *provide* (ahah) a bit of their wisdom :)

 Thanks,
 Ivar.

 [0] https://bugs.launchpad.net/group-based-policy/+bug/1432816

 __
 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] [Group-Based-Policy] Use cases for External Policy chains

[Igor Cardoso]

Ivar,

With the currently supported set of services I also agree, but as more
services get supported in the future, or we hand out that choice to
tenants' VMs, it starts to justify a generic model that does not
restrict whether EPs should provide service chains.

That said, I do not yet totally understand the fundamental difference
between having providers/consumers or just changing policy
classifiers' directions. For instance, I could have a provider PTG and
a consumer EP with the traffic headed towards PTG redirecting to some
chain. Likewise, PTG could be the consumer and EP the provider and
still have traffic headed towards the PTG redirecting to some chain.
About this I would very much appreciate a simple clarification.

For the use cases, and now looking at providers/consumers as more than
traffic directionality, an EP could be created as an external source
of video which would then pass through a video transcoding service
function (eventually deployed as a Nova instance) before reaching the
consuming PTGs (that could aggregate users of a telecommunications
service provider, per home, region, subscription type, etc.,
in the context of NFV). It's just an example from the tip of my head.

Cheers,

On Thu, Mar 19, 2015 at 10:28 PM Ivar Lazzaro ivarlazz...@gmail.com wrote:

 Hello,

 As a follow up on [0] I have a question for the community.
 There are multiple use cases for a PTG *providing* a ServiceChain which is
 *consumed* by an External Policy (think about LB/FW/IDS and so forth).
 However, given the current set of services we support, I don't see any use
 case for having the External Policy as the provider on a PRS with a chain.

 Am I missing something? And if not, how should we manage a REDIRECT action
 provided by an External Policy? We could either ignore, validate or treat
 that particular action just like a normal ALLOW.

 Thanks for your feedbacks,
 Ivar.

 [0] https://bugs.launchpad.net/group-based-policy/+bug/1432779
 __
 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] [Group-Based-Policy] Service Chain Instance ownership

[Ivar Lazzaro]

Hello Folks,

[tl;dr]

On implicit chains, the Service Chain Instance ownership in GBP is
inconsistent, depending on the actor triggering the chain. Possible
solution is to have all the implicit SCI owned by an admin, or by the
provider of the chain. Any suggestion is welcome.

[boringpostwithexampleandstuff]

I've recently file a bug [0] regarding Service Chain Instance ownership,
and I would like to get some advice on how to proceed with it.

Let's take the following final state as an example:

PTG-A ---PRS-Chain---PTG-B

PTG A is providing a PRS with a redirect action, which is consumed by
PTG-B. Reaching this state triggers an implicit SCI creation based on the
policy action.
The above state can be reached in multiple ways, some of them are:

- PTG-A provides PRS-Chain (which is already consumed by PTG-B);
- PTG-B consumes PRS-Chain (which is already provided by PTG-A);
- Redirect action is added to PRS-Chain (which is already provided and
consumed).

Depending on how that state is reached, in today's implementation the
tenant owning the SCI may be ultimately different! This is definitively a
problem, especially when PTG-A and PTG-B are owned by different tenants.
If having inconsistent behavior on the same state isn't bad enough, another
issue is that whoever triggers the SCI deletion should also own the SCI or
will get an exception! And this is definitively not part of the intent.
In short, we need to decide who has to own the chain instances (and with
them, the network services themselves). There are two main choices:

- An Admin owns them all. This will not impact the users' quota, and makes
it easier to bridge different tenants' networks (when needed/applicable).
The downside (?) is that the user will never see the SCI and will never be
able to control the services without admin permissions;

- The Provider is always the owner. This solution is trickier as far as
quota are concerned, especially when the services are created using VMs
(NFV). does the provider need to care about that? why has my VM limit
suddenly dropped to 0 now that I'm providing this cursed PRS? On the
upside, the provider can control and modify the service itself if he needs
to.

I personally am a fan of the first option, the user should only care about
the Intent, and not about this kind of details. But I would like to have
some insight from the community, especially from other projects that may
have had this issue and can *provide* (ahah) a bit of their wisdom :)

Thanks,
Ivar.

[0] https://bugs.launchpad.net/group-based-policy/+bug/1432816
__
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] Group Based Policy - Kilo-2 development milestone

[Sumit Naiksatam]

Hi All,

The second milestone release of the Kilo development cycle, “kilo-2
is now available for the Group Based Policy project. It contains a
bunch of bug fixes and enhancements over the previous release. You can
find the full list of fixed bugs, features, as well as tarball
downloads, at:

https://launchpad.net/group-based-policy/kilo/kilo-gbp-2
https://launchpad.net/group-based-policy-automation/kilo/kilo-gbp-2
https://launchpad.net/group-based-policy-ui/kilo/kilo-gbp-2

Many thanks to those who contributed towards this milestone. The next
development milestone, kilo-3, is scheduled for April 15th.

Best,
~Sumit.

__
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] [Group-Based-Policy] How to deal with improvements

[Sumit Naiksatam]

Hi Ivar, My personal preference is to see information related to a
particular feature in one place. So in cases like the ones you
describe, I would propose that we update the existing spec. Of course,
there is the problem of updating the same spec across different
releases (since we create a new directory for every release). Perhaps,
even in such cases we can start by copying over the original spec as
the first patch set, and then amend the specs to add the new changes
(thus making it clear as to what the delta is).

Definitely would like to hear what others think about this.

Thanks,
~Sumit.


On Wed, Mar 11, 2015 at 5:51 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
 Hello Folks,

 As a follow up of [0] I was working on a proposal for adding the same
 sharing capabilities to servicechain constructs. While thinking about the
 use cases for doing this, a question came to my mind: How should I deal with
 this improvement from  a process perspective?

 I'm not sure adding sharing capabilities to 2 more objects is exactly a new
 feature... It is more of a follow up of an existing one! What is the
 expected process in this case? Should I create a new spec? Modify the
 existing one? Create a detailed launchpad blueprint without a spec?

 Please provide guidance, thanks,

 Ivar.

 [0]
 https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/introduce-shared-attribute.rst

 __
 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] [Group-based-policy][GBP] PTL Candidacy

[Bhandaru, Malini K]

Sumit's candidacy for GBP PTL is confirmed!

Regards
Malini

-Original Message-
From: Sumit Naiksatam [mailto:sumitnaiksa...@gmail.com] 
Sent: Thursday, March 12, 2015 12:04 AM
To: OpenStack Development Mailing List (not for usage questions)
Cc: Bhandaru, Malini K
Subject: [Group-based-policy][GBP] PTL Candidacy

Hi All,

I would like to announce my candidacy for the Group Based Policy (GBP) [1] 
project’s PTL position [2].

I have been involved with GBP for more than a year now. I was responsible for 
setting it up as a StackForge project across multiple repositories, and have 
been serving as the de facto lead. I have made contributions to the project in 
terms of design, implementation, and reviews [3].

My focus during the Kilo cycle has, and, will be to improve the quality of our 
code (reduce bug count, identify and remove obvious performance issues, clear 
technical debt), and most of all to gather feedback from users on the GBP Juno 
release. Based on this feedback, I would like to steer the project in the 
Liberty release towards better integration with other OpenStack components, and 
advanced features that will allow to comprehensively manage and automate policy 
enforcement across those components.

I have enjoyed working with each and every one of the GBP team members, and 
look forward to working with them in the formal capacity of a PTL. I am proud 
of what the team has achieved, and hope to facilitate its growth even further.

To summarize, I am very excited about this opportunity in playing a part in 
GBP’s mission to fully realize the intent-based policy-driven abstractions' 
model.

Best,
Sumit Naiksatam.
(IRC: SumitNaiksatam)

[1] https://wiki.openstack.org/wiki/GroupBasedPolicy
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-March/058783.html
[3] http://stackalytics.com/report/contribution/group-based-policy-group/150
__
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] [Group-based-policy][GBP] PTL Candidacy

[Sumit Naiksatam]

Hi All,

I would like to announce my candidacy for the Group Based Policy (GBP)
[1] project’s PTL position [2].

I have been involved with GBP for more than a year now. I was
responsible for setting it up as a StackForge project across multiple
repositories, and have been serving as the de facto lead. I have made
contributions to the project in terms of design, implementation, and
reviews [3].

My focus during the Kilo cycle has, and, will be to improve the
quality of our code (reduce bug count, identify and remove obvious
performance issues, clear technical debt), and most of all to gather
feedback from users on the GBP Juno release. Based on this feedback, I
would like to steer the project in the Liberty release towards better
integration with other OpenStack components, and advanced features
that will allow to comprehensively manage and automate policy
enforcement across those components.

I have enjoyed working with each and every one of the GBP team
members, and look forward to working with them in the formal capacity
of a PTL. I am proud of what the team has achieved, and hope to
facilitate its growth even further.

To summarize, I am very excited about this opportunity in playing a
part in GBP’s mission to fully realize the intent-based policy-driven
abstractions' model.

Best,
Sumit Naiksatam.
(IRC: SumitNaiksatam)

[1] https://wiki.openstack.org/wiki/GroupBasedPolicy
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-March/058783.html
[3] http://stackalytics.com/report/contribution/group-based-policy-group/150

__
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] [Group-Based-Policy] How to deal with improvements

[Ivar Lazzaro]

Hello Folks,

As a follow up of [0] I was working on a proposal for adding the same
sharing capabilities to servicechain constructs. While thinking about the
use cases for doing this, a question came to my mind: How should I deal
with this improvement from  a process perspective?

I'm not sure adding sharing capabilities to 2 more objects is exactly a new
feature... It is more of a follow up of an existing one! What is the
expected process in this case? Should I create a new spec? Modify the
existing one? Create a detailed launchpad blueprint without a spec?

Please provide guidance, thanks,

Ivar.

[0]
https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/introduce-shared-attribute.rst
__
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] Group Based Policy - Kilo-1 development milestone

[Sumit Naiksatam]

Hi All,

The first milestone release of the Kilo development cycle, “kilo-1 is
now available for the Group Based Policy project. It contains a bunch
of bug fixes and enhancements over the previous release. You can find
the full list of fixed bugs, features, as well as tarball downloads,
at:

https://launchpad.net/group-based-policy/kilo/kilo-gbp-1
https://launchpad.net/group-based-policy-automation/kilo/kilo-gbp-1

Many thanks to those who contributed towards this milestone. The next
development milestone, kilo-2, is scheduled for March 16th.

Best,
~Sumit.

__
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] [Group-based-policy] New addition to the core team

[Sumit Naiksatam]

Hi, I would like to propose Magesh GV (magesh-gv) to the Group-based
Policy (GBP) core team based on his excellent contribution to the
project. We discussed this during the weekly IRC meeting [1] and the
current core team unanimously supports this. Let us know if there are
any objections, otherwise Magesh, welcome to the core team!

Thanks,
~Sumit.
[1] 
http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-01-08-18.08.log.html

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

[openstack-dev] [Group-based Policy] Review of patches

[Sumit Naiksatam]

Hi, We are meeting in the #openstack-gbp channel today (10/14) 18.00 UTC to
jointly review some of the pending patches:

https://review.openstack.org/#/q/status:open+project:stackforge/group-based-policy+branch:master,n,z

Please join if you would like to provide feedback.

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

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Robert Kukura]

On 10/7/14 6:36 PM, Ivar Lazzaro wrote:
I posted a patch that implements the Different DB Different Chain 
approach [0].
That does not mean that this approach is the chosen one! It's just to 
have a grasp of what the change looks like.


The Same DB different chain solution is much simpler to implement 
(basically you just specify a different version table in the alembic 
environment) so I haven't posted anything for that.


One thing I'm particularly interested about is to hear packagers 
opinions about which approach would be the preferred one: Same DB or 
Different?
It seems to me that deployment tools such as puppet scripts would also 
be simpler if the GBP service plugin used the neutron DB, as there would 
be no need to create a separate DB, set its permissions, put its URL 
into neutron's config file, etc.. All that would be needed at deployment 
time is to run the additional gbp-db-manage tool to perform the GBP DB 
migrations. Am I missing anything?


With dependencies only in one direction, and the foreign keys GBP 
depends on (neutron resource IDs) unlikely to be changed by neutron 
migrations during Kilo, I don't think we need to worry about 
interleaving GBP migrations with neutron migrations. On initial 
deployments or version upgrades, it should be sufficient to run 
gbp-db-manage after neutron-db-manage. On downgrades, some situations 
might require running gbp-db-manage before neutron-db-manage. This seems 
not to be effected by whether the two migration chains are in the same 
DB/schema or different ones.
Also, on the line of Bob's comment in my patch, is there any kind of 
compatibility or performance issue anyone is aware of about in using 
cross schema FKs?
In addition to compatibility and performance, I'm also concerned about 
DB connection management when the same server is using multiple 
connection URLs. I'm not convinced the approach in the patch is 
sufficient. At least with some DBs, wouldn't we we need a separate 
sqlalchemy.create_engine() call with each DB's connection URL, which 
might require using separate context and session objects rather than the 
ones neutron uses?


-Bob


Thanks,
Ivar.

[0] https://review.openstack.org/#/c/126383/

On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro ivarlazz...@gmail.com 
mailto:ivarlazz...@gmail.com wrote:


I believe Group-based Policy (which this thread is about) will
use the Neutron
database configuration for its dependent database.

If Neutron is configured for:
connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
connection = mysql://user:pass@locationX:3306/neutron_gbp


That's correct, that would be the likely approach if we go with
the different schema route.

if you can get the “other database” to be accessible from the
target database via “otherdatabase.sometable”, then you’re in.
from SQLAlchemy’s perspective, it’s just a name with a dot.  
It’s the database itself that has to support the foreign key

at the scope you are shooting for.


I'm experimenting this approach with our code and it seems to be
the case. '
I feel that having the constraint of pointing the same database
connection with a different schema is pretty acceptable given how
tight is GBP to Neutron.

On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau ges...@cisco.com
mailto:ges...@cisco.com wrote:

Clint Byrum cl...@fewbar.com mailto:cl...@fewbar.com wrote:

 Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:

 On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com
mailto:blak...@gmail.com wrote:

 Does sqlalchemy have good support for cross-database
foreign keys? I was under the impression that they cannot be
implemented with the normal syntax and semantics of an
intra-database foreign-key constraint.

 cross “database” is not typically portable, but cross
“schema” is.

 different database vendors have different notions of
“databases” or “schemas”.

 if you can get the “other database” to be accessible from
the target database via “otherdatabase.sometable”, then you’re in.

 from SQLAlchemy’s perspective, it’s just a name with a
dot.   It’s the database itself that has to support the
foreign key at the scope you are shooting for.


 All true, however, there are zero guarantees that databases
will be
 hosted on the same server, and typically permissions are
setup to prevent
 cross-schema joins.

I believe Group-based Policy (which this thread is about) will
use the Neutron
database configuration for its dependent database.

If Neutron is configured for:
  connection = mysql://user:pass@locationX:3306/neutron
   

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Ivar Lazzaro]

 It seems to me that deployment tools such as puppet scripts would also be
 simpler if the GBP service plugin used the neutron DB, as there would be no
 need to create a separate DB, set its permissions, put its URL into
 neutron's config file, etc.. All that would be needed at deployment time is
 to run the additional gbp-db-manage tool to perform the GBP DB migrations.
 Am I missing anything?


That's correct, being a new schema it needs to be created, the access
granted, and the connection URL configured in neutron.conf (doable also
with devstack in the extra-conf option).


 With dependencies only in one direction, and the foreign keys GBP depends
 on (neutron resource IDs) unlikely to be changed by neutron migrations
 during Kilo, I don't think we need to worry about interleaving GBP
 migrations with neutron migrations. On initial deployments or version
 upgrades, it should be sufficient to run gbp-db-manage after
 neutron-db-manage. On downgrades, some situations might require running
 gbp-db-manage before neutron-db-manage. This seems not to be effected by
 whether the two migration chains are in the same DB/schema or different
 ones.


That's correct too. Also, this is true for the downgrade even with a
different schema.


 In addition to compatibility and performance, I'm also concerned about DB
 connection management when the same server is using multiple connection
 URLs. I'm not convinced the approach in the patch is sufficient. At least
 with some DBs, wouldn't we we need a separate sqlalchemy.create_engine()
 call with each DB's connection URL, which might require using separate
 context and session objects rather than the ones neutron uses?


That should not be the case. We are not using a separate DB connection. The
connection is in fact the same, the only thing that changes is the schema.
For the sql engine this  should be only a matter of namespacing (different
schema - different namespace), therefore I don't see any relevant
performance/connection/greenthread issue.
However I'm no DBMS expert, any additional feedback on this matter is
welcome.

Ivar.

On Fri, Oct 10, 2014 at 2:59 PM, Robert Kukura kuk...@noironetworks.com
wrote:


 On 10/7/14 6:36 PM, Ivar Lazzaro wrote:

 I posted a patch that implements the Different DB Different Chain
 approach [0].
 That does not mean that this approach is the chosen one! It's just to have
 a grasp of what the change looks like.

  The Same DB different chain solution is much simpler to implement
 (basically you just specify a different version table in the alembic
 environment) so I haven't posted anything for that.

  One thing I'm particularly interested about is to hear packagers
 opinions about which approach would be the preferred one: Same DB or
 Different?

 It seems to me that deployment tools such as puppet scripts would also be
 simpler if the GBP service plugin used the neutron DB, as there would be no
 need to create a separate DB, set its permissions, put its URL into
 neutron's config file, etc.. All that would be needed at deployment time is
 to run the additional gbp-db-manage tool to perform the GBP DB migrations.
 Am I missing anything?

 With dependencies only in one direction, and the foreign keys GBP depends
 on (neutron resource IDs) unlikely to be changed by neutron migrations
 during Kilo, I don't think we need to worry about interleaving GBP
 migrations with neutron migrations. On initial deployments or version
 upgrades, it should be sufficient to run gbp-db-manage after
 neutron-db-manage. On downgrades, some situations might require running
 gbp-db-manage before neutron-db-manage. This seems not to be effected by
 whether the two migration chains are in the same DB/schema or different
 ones.

  Also, on the line of Bob's comment in my patch, is there any kind of
 compatibility or performance issue anyone is aware of about in using cross
 schema FKs?

 In addition to compatibility and performance, I'm also concerned about DB
 connection management when the same server is using multiple connection
 URLs. I'm not convinced the approach in the patch is sufficient. At least
 with some DBs, wouldn't we we need a separate sqlalchemy.create_engine()
 call with each DB's connection URL, which might require using separate
 context and session objects rather than the ones neutron uses?

 -Bob


  Thanks,
 Ivar.

  [0] https://review.openstack.org/#/c/126383/

 On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro ivarlazz...@gmail.com
 wrote:

  I believe Group-based Policy (which this thread is about) will use the
 Neutron
 database configuration for its dependent database.

 If Neutron is configured for:
   connection = mysql://user:pass@locationX:3306/neutron
 then GBP would use:
   connection = mysql://user:pass@locationX:3306/neutron_gbp


  That's correct, that would be the likely approach if we go with the
 different schema route.

  if you can get the “other database” to be accessible from the target
 database via 

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Ivar Lazzaro]

I posted a patch that implements the Different DB Different Chain
approach [0].
That does not mean that this approach is the chosen one! It's just to have
a grasp of what the change looks like.

The Same DB different chain solution is much simpler to implement
(basically you just specify a different version table in the alembic
environment) so I haven't posted anything for that.

One thing I'm particularly interested about is to hear packagers opinions
about which approach would be the preferred one: Same DB or Different?
Also, on the line of Bob's comment in my patch, is there any kind of
compatibility or performance issue anyone is aware of about in using cross
schema FKs?

Thanks,
Ivar.

[0] https://review.openstack.org/#/c/126383/

On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 I believe Group-based Policy (which this thread is about) will use the
 Neutron
 database configuration for its dependent database.

 If Neutron is configured for:
   connection = mysql://user:pass@locationX:3306/neutron
 then GBP would use:
   connection = mysql://user:pass@locationX:3306/neutron_gbp


 That's correct, that would be the likely approach if we go with the
 different schema route.

 if you can get the “other database” to be accessible from the target
 database via “otherdatabase.sometable”, then you’re in.
 from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the
 database itself that has to support the foreign key at the scope you are
 shooting for.


 I'm experimenting this approach with our code and it seems to be the case.
 '
 I feel that having the constraint of pointing the same database connection
 with a different schema is pretty acceptable given how tight is GBP to
 Neutron.


 On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau ges...@cisco.com wrote:

 Clint Byrum cl...@fewbar.com wrote:
 
  Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
 
  On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com wrote:
 
  Does sqlalchemy have good support for cross-database foreign keys? I
 was under the impression that they cannot be implemented with the normal
 syntax and semantics of an intra-database foreign-key constraint.
 
  cross “database” is not typically portable, but cross “schema” is.
 
  different database vendors have different notions of “databases” or
 “schemas”.
 
  if you can get the “other database” to be accessible from the target
 database via “otherdatabase.sometable”, then you’re in.
 
  from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the
 database itself that has to support the foreign key at the scope you are
 shooting for.
 
 
  All true, however, there are zero guarantees that databases will be
  hosted on the same server, and typically permissions are setup to
 prevent
  cross-schema joins.

 I believe Group-based Policy (which this thread is about) will use the
 Neutron
 database configuration for its dependent database.

 If Neutron is configured for:
   connection = mysql://user:pass@locationX:3306/neutron
 then GBP would use:
   connection = mysql://user:pass@locationX:3306/neutron_gbp

  Typically we use the public API's when we want to access data in a
  different application. The database is a private implementation detail
  of each application.

 Currently GPB is very tightly coupled to Neutron.


 ___
 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] [Group-based Policy] Database migration chain

[Ivar Lazzaro]

 I believe Group-based Policy (which this thread is about) will use the
 Neutron
 database configuration for its dependent database.

 If Neutron is configured for:
   connection = mysql://user:pass@locationX:3306/neutron
 then GBP would use:
   connection = mysql://user:pass@locationX:3306/neutron_gbp


That's correct, that would be the likely approach if we go with the
different schema route.

if you can get the “other database” to be accessible from the target
 database via “otherdatabase.sometable”, then you’re in.
 from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the
 database itself that has to support the foreign key at the scope you are
 shooting for.


I'm experimenting this approach with our code and it seems to be the case. '
I feel that having the constraint of pointing the same database connection
with a different schema is pretty acceptable given how tight is GBP to
Neutron.


On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau ges...@cisco.com wrote:

 Clint Byrum cl...@fewbar.com wrote:
 
  Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
 
  On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com wrote:
 
  Does sqlalchemy have good support for cross-database foreign keys? I
 was under the impression that they cannot be implemented with the normal
 syntax and semantics of an intra-database foreign-key constraint.
 
  cross “database” is not typically portable, but cross “schema” is.
 
  different database vendors have different notions of “databases” or
 “schemas”.
 
  if you can get the “other database” to be accessible from the target
 database via “otherdatabase.sometable”, then you’re in.
 
  from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the
 database itself that has to support the foreign key at the scope you are
 shooting for.
 
 
  All true, however, there are zero guarantees that databases will be
  hosted on the same server, and typically permissions are setup to prevent
  cross-schema joins.

 I believe Group-based Policy (which this thread is about) will use the
 Neutron
 database configuration for its dependent database.

 If Neutron is configured for:
   connection = mysql://user:pass@locationX:3306/neutron
 then GBP would use:
   connection = mysql://user:pass@locationX:3306/neutron_gbp

  Typically we use the public API's when we want to access data in a
  different application. The database is a private implementation detail
  of each application.

 Currently GPB is very tightly coupled to Neutron.


 ___
 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] [Group-based Policy] Database migration chain

[Mike Bayer]

On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com wrote:

 Does sqlalchemy have good support for cross-database foreign keys? I was 
 under the impression that they cannot be implemented with the normal syntax 
 and semantics of an intra-database foreign-key constraint. 

cross “database” is not typically portable, but cross “schema” is.   

different database vendors have different notions of “databases” or “schemas”.

if you can get the “other database” to be accessible from the target database 
via “otherdatabase.sometable”, then you’re in.

from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the database 
itself that has to support the foreign key at the scope you are shooting for.



 
 On Fri, Oct 3, 2014 at 5:25 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
 Hi,
 
 Following up the latest GBP team meeting [0][1]:
 
 As we keep going with our Juno stackforge implementation [2], although the 
 service is effectively a Neutron extension, we should avoid breaking 
 Neutron's migration chain by adding our model on top of it (and subsequently 
 changing Neutron's HEAD [3]). If we do that, upgrading from Juno to Kilo will 
 be painful for those who have used GBP. 
 
 There are roughly a couple of possibilities for reaching this goal:
 
 1) Using a separate DBs with separate migration chain;
 2) Using the same DB with separate chain (and different alembic version 
 table).
 
 Personally I prefer the option 1, moving to a completely different database 
 while leveraging cross database foreign keys.
 
 Please let me know your preference, or alternative solutions! :)
 
 Cheers,
 Ivar.
 
 [0] 
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html
 [1] 
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html
 [2] https://github.com/stackforge/group-based-policy
 [3] https://review.openstack.org/#/c/123617/
 
 ___
 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

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

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Clint Byrum]

Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
 
 On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com wrote:
 
  Does sqlalchemy have good support for cross-database foreign keys? I was 
  under the impression that they cannot be implemented with the normal syntax 
  and semantics of an intra-database foreign-key constraint. 
 
 cross “database” is not typically portable, but cross “schema” is.   
 
 different database vendors have different notions of “databases” or “schemas”.
 
 if you can get the “other database” to be accessible from the target database 
 via “otherdatabase.sometable”, then you’re in.
 
 from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the 
 database itself that has to support the foreign key at the scope you are 
 shooting for.
 

All true, however, there are zero guarantees that databases will be
hosted on the same server, and typically permissions are setup to prevent
cross-schema joins.

Typically we use the public API's when we want to access data in a
different application. The database is a private implementation detail
of each application.

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

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Henry Gessau]

Clint Byrum cl...@fewbar.com wrote:
 
 Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:

 On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com wrote:

 Does sqlalchemy have good support for cross-database foreign keys? I was 
 under the impression that they cannot be implemented with the normal syntax 
 and semantics of an intra-database foreign-key constraint. 

 cross “database” is not typically portable, but cross “schema” is.   

 different database vendors have different notions of “databases” or 
 “schemas”.

 if you can get the “other database” to be accessible from the target 
 database via “otherdatabase.sometable”, then you’re in.

 from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the 
 database itself that has to support the foreign key at the scope you are 
 shooting for.

 
 All true, however, there are zero guarantees that databases will be
 hosted on the same server, and typically permissions are setup to prevent
 cross-schema joins.

I believe Group-based Policy (which this thread is about) will use the Neutron
database configuration for its dependent database.

If Neutron is configured for:
  connection = mysql://user:pass@locationX:3306/neutron
then GBP would use:
  connection = mysql://user:pass@locationX:3306/neutron_gbp

 Typically we use the public API's when we want to access data in a
 different application. The database is a private implementation detail
 of each application.

Currently GPB is very tightly coupled to Neutron.


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

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Mike Bayer]

On Oct 4, 2014, at 11:24 AM, Clint Byrum cl...@fewbar.com wrote:

 
 Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
 
 On Oct 4, 2014, at 1:10 AM, Kevin Benton blak...@gmail.com wrote:
 
 Does sqlalchemy have good support for cross-database foreign keys? I was 
 under the impression that they cannot be implemented with the normal syntax 
 and semantics of an intra-database foreign-key constraint. 
 
 cross “database” is not typically portable, but cross “schema” is.   
 
 different database vendors have different notions of “databases” or 
 “schemas”.
 
 if you can get the “other database” to be accessible from the target 
 database via “otherdatabase.sometable”, then you’re in.
 
 from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the 
 database itself that has to support the foreign key at the scope you are 
 shooting for.
 
 
 All true, however, there are zero guarantees that databases will be
 hosted on the same server, and typically permissions are setup to prevent
 cross-schema joins.

the impression I’ve gotten so far is that they are looking to have different 
sets of database tables isolated into groups that can be migrated 
independently, and rather than using multiple alembic version tables, they’d go 
with this approach. This to me means that on a postgresql backend these would 
just be individual sub-schemas, and on a MySQL backend would be other databases 
that are limited to being on the same host (which is MySQL’s version of 
“schemas”, in that the “CREATE SCHEMA” command is a synonym for “CREATE 
DATABASE).

 
 Typically we use the public API's when we want to access data in a
 different application. The database is a private implementation detail
 of each application.

I was just having a discussion on IRC the other day with a Neutron dev stating 
that they’d like to break out several parts of Neutron into “plugins”, which 
would have their own database tables but still linked to the database tables of 
the core Neutron application.   If this is the case, within an architecture 
like that you’d have different sub-applications cross-accessing databases.




 
 ___
 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] [Group-based Policy] Database migration chain

[Ivar Lazzaro]

Hi,

Following up the latest GBP team meeting [0][1]:

As we keep going with our Juno stackforge implementation [2], although the
service is effectively a Neutron extension, we should avoid breaking
Neutron's migration chain by adding our model on top of it (and
subsequently changing Neutron's HEAD [3]). If we do that, upgrading from
Juno to Kilo will be painful for those who have used GBP.

There are roughly a couple of possibilities for reaching this goal:

1) Using a separate DBs with separate migration chain;
2) Using the same DB with separate chain (and different alembic version
table).

Personally I prefer the option 1, moving to a completely different database
while leveraging cross database foreign keys.

Please let me know your preference, or alternative solutions! :)

Cheers,
Ivar.

[0]
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html
[1]
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html
[2] https://github.com/stackforge/group-based-policy
[3] https://review.openstack.org/#/c/123617/
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Group-based Policy] Database migration chain

[Kevin Benton]

Does sqlalchemy have good support for cross-database foreign keys? I was
under the impression that they cannot be implemented with the normal syntax
and semantics of an intra-database foreign-key constraint.

On Fri, Oct 3, 2014 at 5:25 PM, Ivar Lazzaro ivarlazz...@gmail.com wrote:

 Hi,

 Following up the latest GBP team meeting [0][1]:

 As we keep going with our Juno stackforge implementation [2], although the
 service is effectively a Neutron extension, we should avoid breaking
 Neutron's migration chain by adding our model on top of it (and
 subsequently changing Neutron's HEAD [3]). If we do that, upgrading from
 Juno to Kilo will be painful for those who have used GBP.

 There are roughly a couple of possibilities for reaching this goal:

 1) Using a separate DBs with separate migration chain;
 2) Using the same DB with separate chain (and different alembic version
 table).

 Personally I prefer the option 1, moving to a completely different
 database while leveraging cross database foreign keys.

 Please let me know your preference, or alternative solutions! :)

 Cheers,
 Ivar.

 [0]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html
 [1]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html
 [2] https://github.com/stackforge/group-based-policy
 [3] https://review.openstack.org/#/c/123617/

 ___
 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

[openstack-dev] [Group-based Policy] Today's IRC meeting summary and renaming of resources

[Sumit Naiksatam]

Hi, For the past couple of weeks one of the agenda items on our weekly
IRC meetings [1][2] has been to finalize on resources'  naming
convention to avoid any conflict/confusion in the future. Based on
community feedback we had earlier agreed to rename Endpoints and
Endpoint Groups to Policy Targets and Policy Target Groups
respectively. Since then we have received additional feedback to
rename Contracts to Policy Rules Set, and Policy Labels to Policy
Tags. If there are no major objections, we will move forward with
these name changes.

For more information on these resources, please refer to the
Group-based Policy spec [3].

Please also note that current GBP development is continuing in the
StackForge repos [4].

Thanks,
~Sumit.

[1] 
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-09-25-18.02.log.html
[2] 
http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-10-02-18.01.log.html
[3] https://review.openstack.org/#/c/87825
[4] https://wiki.openstack.org/wiki/GroupBasedPolicy/StackForge/repos

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

Re: [openstack-dev] Group-Based Policy Understanding and Queries

[Sachi Gupta]

Hi All,

Request you all to provide inputs of the below queries:

As per my understanding GBP constructs are mapped to neutron calls for 
example - creating an endpoint, the neutron mapping driver will map it to 
the existing port creation method. Similarly to achieve the complete 
functionality of GBP openstack, I have checked for the neutron calls and 
it includes network, subnet, port, router, security group.

Creating a contract - policy rules..Will this include a call to firewall 
rules or only security group calls will be done?
I need to integrate Openstack with Opendaylight(ODL). To achieve the 
interface between two will it be done by ML2 plugin and neutron mapping 
driver of Openstack or something additional is required?
The neutron northbound APIs of ODL include network, subnet, port, router, 
security groups, firewall calls. Any other call that needs to be included 
a part from these in ODL.
Do the neutron calls that will be mapped by the neutron mapping driver of 
openstack are something different from the previous neutron calls that 
were being made without using GBP??? For example: The network create call 
that was used previously with ODL without using GBP in openstack. Will it 
be different from the network call to ODL that will be made by GBP mapping 
driver of openstack.
How the GBP project in openstack will be affecting the Opendaylight 
neutron calls??



Thanks in Advance
Sachi Gupta



From:   Sumit Naiksatam sumitnaiksa...@gmail.com
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date:   09/23/2014 04:33 AM
Subject:Re: [openstack-dev] Group-Based Policy Understanding and 
Queries



Thanks for your interest in GBP, responses inline.

On Sun, Sep 21, 2014 at 11:35 PM, Sachi Gupta sachi.gu...@tcs.com wrote:
 Hi All,

 Request you all to provide inputs on below understanding:

 Openstack: Group-based policy is a blueprint for Juno-3 release of
 Openstack. It will extend OpenStack Networking with policy and 
connectivity
 abstractions that enable significantly more simplified and
 application-oriented interfaces than with the current Neutron API model.
 When will be the code ready for Group-based policy as an open source?

The code has been in review in gerrit for a while now, you can find
all the links to all the patches here:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
We are also consolidating this code in Stackforge so that its usable
starting  from the Juno release.

 Openstack group policy API will be an extension to the Neutron APIs. 
There
 will be a policy manager to manage the policy and policy rules. Will GBP 
a
 part of neutron?? If yes, then will GBP be a part of Horizon under 
neutron?

The wiki page above has links to client, Horizon and Heat patches.

 Policy driver which will act as an interface(ODL Policy Driver). For eg. 
we
 used neutron ML2 plugin as an interface between Openstack neutron and 
ODL
 neutron northbound. When will the policy driver for ODL available?
 Openstack policy driver for ODL will act as an interface to ODL. Which 
API
 in ODL, Policy calls from Openstack ODL Policy driver will be hitting??


I know that this was planned, so you would probably need to check with
the author of the following patch for the status on this:
https://review.openstack.org/#/c/105606/
We can also bring this up for discussion during the weekly IRC:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy



 Thanks  Regards
 Sachi Gupta

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. Thank you


 ___
 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] Group-Based Policy Understanding and Queries

[Sachi Gupta]

Hi All,

Request you all to provide inputs on below understanding:

Openstack: Group-based policy is a blueprint for Juno-3 release of 
Openstack. It will extend OpenStack Networking with policy and 
connectivity abstractions that enable significantly more simplified and 
application-oriented interfaces than with the current Neutron API model. 
When will be the code ready for Group-based policy as an open source?

Openstack group policy API will be an extension to the Neutron APIs. There 
will be a policy manager to manage the policy and policy rules. Will GBP a 
part of neutron?? If yes, then will GBP be a part of Horizon under 
neutron?

Policy driver which will act as an interface(ODL Policy Driver). For eg. 
we used neutron ML2 plugin as an interface between Openstack neutron and 
ODL neutron northbound. When will the policy driver for ODL available?

Openstack policy driver for ODL will act as an interface to ODL. Which API 
in ODL, Policy calls from Openstack ODL Policy driver will be hitting??


Thanks  Regards
Sachi Gupta
=-=-=
Notice: The information contained in this e-mail
message and/or attachments to it may contain 
confidential or privileged information. If you are 
not the intended recipient, any dissemination, use, 
review, distribution, printing or copying of the 
information contained in this e-mail message 
and/or attachments to it are strictly prohibited. If 
you have received this communication in error, 
please notify us by reply e-mail or telephone and 
immediately and permanently delete the message 
and any attachments. Thank you


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

Re: [openstack-dev] Group-Based Policy Understanding and Queries

[Sumit Naiksatam]

Thanks for your interest in GBP, responses inline.

On Sun, Sep 21, 2014 at 11:35 PM, Sachi Gupta sachi.gu...@tcs.com wrote:
 Hi All,

 Request you all to provide inputs on below understanding:

 Openstack: Group-based policy is a blueprint for Juno-3 release of
 Openstack. It will extend OpenStack Networking with policy and connectivity
 abstractions that enable significantly more simplified and
 application-oriented interfaces than with the current Neutron API model.
 When will be the code ready for Group-based policy as an open source?

The code has been in review in gerrit for a while now, you can find
all the links to all the patches here:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches
We are also consolidating this code in Stackforge so that its usable
starting  from the Juno release.

 Openstack group policy API will be an extension to the Neutron APIs. There
 will be a policy manager to manage the policy and policy rules. Will GBP a
 part of neutron?? If yes, then will GBP be a part of Horizon under neutron?

The wiki page above has links to client, Horizon and Heat patches.

 Policy driver which will act as an interface(ODL Policy Driver). For eg. we
 used neutron ML2 plugin as an interface between Openstack neutron and ODL
 neutron northbound. When will the policy driver for ODL available?
 Openstack policy driver for ODL will act as an interface to ODL. Which API
 in ODL, Policy calls from Openstack ODL Policy driver will be hitting??


I know that this was planned, so you would probably need to check with
the author of the following patch for the status on this:
https://review.openstack.org/#/c/105606/
We can also bring this up for discussion during the weekly IRC:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy



 Thanks  Regards
 Sachi Gupta

 =-=-=
 Notice: The information contained in this e-mail
 message and/or attachments to it may contain
 confidential or privileged information. If you are
 not the intended recipient, any dissemination, use,
 review, distribution, printing or copying of the
 information contained in this e-mail message
 and/or attachments to it are strictly prohibited. If
 you have received this communication in error,
 please notify us by reply e-mail or telephone and
 immediately and permanently delete the message
 and any attachments. Thank you


 ___
 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