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

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

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

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

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

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

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

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]

[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] 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  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  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

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

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

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  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] 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 
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 
> 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 “oth

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 > 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 mailto:ges...@cisco.com>> wrote:

Clint Byrum 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 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
then GBP would use:
  connecti

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  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  wrote:
>
>> Clint Byrum  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  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  wrote:

> Clint Byrum  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  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 11:24 AM, Clint Byrum  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  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

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

[Henry Gessau]

Clint Byrum  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  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

[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  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

[Mike Bayer]

On Oct 4, 2014, at 1:10 AM, Kevin Benton  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  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

[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  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

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 
To: "OpenStack Development Mailing List (not for usage questions)" 

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

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