Re: [openstack-dev] [Release-job-failures][group-based-policy] Release of openstack/group-based-policy failed

2018-07-10 Thread Sumit Naiksatam
Thanks Doug for noticing this. I am guessing this was a transient
issue. How do we trigger this job again to confirm?

On Tue, Jul 10, 2018 at 9:21 AM, Doug Hellmann  wrote:
> Excerpts from zuul's message of 2018-07-10 06:38:24 +:
>> Build failed.
>>
>> - release-openstack-python 
>> http://logs.openstack.org/5b/5bbcfd7b41d39339ff9b9f8654681406d2508205/release/release-openstack-python/269f8ce/
>>  : FAILURE in 6m 31s
>> - announce-release announce-release : SKIPPED
>> - propose-update-constraints propose-update-constraints : SKIPPED
>>
>
> The release job failed trying to pip install something due to an SSL
> error.
>
> http://logs.openstack.org/5b/5bbcfd7b41d39339ff9b9f8654681406d2508205/release/release-openstack-python/269f8ce/job-output.txt.gz#_2018-07-10_06_37_26_065386
>
> __
> 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] Help required to install devstack with GBP

2018-05-31 Thread Sumit Naiksatam
Hi, Sure we can help you. Could you please take a look at the neutron logs
and let me know what exception you are seeing? Also, please let me know
which branch you are trying to install.

Thanks,
~Sumit.

On Thu, May 31, 2018 at 1:52 AM, ., Alex Dominic Savio <
alex.will...@microfocus.com> wrote:

>
>
> Hi Experts,
>
>
>
> I have been trying to install devstack with gbp as per the instruction
> given in the  GitHub https://github.com/openstack/group-based-policy
>
> This I am running on Ubuntu 16.x as well as 14.x but both the attempts
> were not successful.
>
> It fails stating “neutron is not started”
>
>
>
> Can you please help me with this issue to get pass ?
>
>
>
>
>
> Thanks & Regards,
>
> *Alex Dominic Savio*
> Product Manager, ITOM-HCM
> Micro Focus
> Bagmane Tech Park
>
> Bangalore, India.
>
> (M)+91 9880634388
> alex.will...@microfocus.com
> --
>
> [image: cid:image003.jpg@01D3ED74.F4E1E2F0]
>
>
>
> __
> 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] [all][QA][group-based-policy][zaqar][packaging_deb][fuel][networking-*] Marking <= mitaka EOL

2017-08-29 Thread Sumit Naiksatam
Hi Tony, Thanks for reaching out. With regards to
“group-based-policy”, branches < mitaka (meaning Liberty or older) can
be EOL’ed. We would still like to have the stable/mitaka branches for
a little more time if that’s possible. This applies to the repos:
group-based-policy
group-based-policy-automation
group-based-policy-ui
python-group-based-policy-client

Thanks,
~Sumit.

On Wed, Aug 23, 2017 at 8:14 PM, Tony Breeds  wrote:
> Hello all,
> We have a number of old stable/* branches hanging around and I'd
> like to mark anything <= stable/mitaka as EOL.  I've highlighted a few
> projects on the subject line:
>
> QA: Are the older branches of grenade safe to go?  IIUC we don't use
> them as we don't do grenade testing on $oldest stable branch
> group-based-policy: In the past you've requested your old branches stay
> around Do you still need this?  Is there value in
> the *all* staying active?


> zaqar: I see that liberty was EOL and then reactivated do you still need
>liberty2?
> packaging_deb: As these repos have the $project origin using the
>standard series-eol tag doesn't make sense  for exaxple
>deb-nova gets a mitaka-eol from the nova repo.   So I've
>picked mitaka-eol-dpkg.
> fuel, networking-*: There are several entries for these projects groups
> so I'm calling them out here for attention.
>
> I'm proposing we do this removal during the PTG.  Once we've done the
> series based branches we can look at old versioned releases like
> stable/16.04 etc.
>
> It's hard to present the data in a clear way so given infra will be the
> ultimate actioners of this list I present this as a shell script:
>
> ---
> eol-branch.sh -- stable/essex essex-eol openstack/anvil
> eol-branch.sh -- stable/folsom folsom-eol openstack/anvil
> eol-branch.sh -- stable/grizzly grizzly-eol openstack/anvil
> eol-branch.sh -- stable/havana havana-eol openstack/openstack
> eol-branch.sh -- stable/icehouse icehouse-eol \
>  openstack/astara openstack/networking-brocade \
>  openstack/networking-cisco openstack/networking-mlnx \
>  openstack/networking-odl openstack/networking-plumgrid \
>  openstack/nova-solver-scheduler \
>  openstack/sahara-image-elements openstack/tricircle \
>  openstack/trio2o openstack/vmware-nsx
> eol-branch.sh -- stable/icehouse icehouse-eol-dpkg \
>  openstack/deb-networking-cisco \
>  openstack/deb-networking-mlnx openstack/deb-networking-odl
> eol-branch.sh -- stable/juno juno-eol \
>  openstack/astara openstack/astara-appliance \
>  openstack/astara-horizon openstack/astara-neutron \
>  openstack/group-based-policy \
>  openstack/group-based-policy-automation \
>  openstack/group-based-policy-ui openstack/mistral \
>  openstack/mistral-dashboard openstack/mistral-extra \
>  openstack/networking-bigswitch \
>  openstack/networking-brocade openstack/networking-cisco \
>  openstack/networking-mlnx openstack/networking-odl \
>  openstack/networking-plumgrid \
>  openstack/nova-solver-scheduler \
>  openstack/openstack-resource-agents \
>  openstack/powervc-driver openstack/proliantutils \
>  openstack/puppet-n1k-vsm openstack/puppet-vswitch \
>  openstack/python-group-based-policy-client \
>  openstack/python-mistralclient \
>  openstack/python-muranoclient openstack/vmware-nsx
> eol-branch.sh -- stable/juno juno-eol-dpkg \
>  openstack/deb-mistral openstack/deb-networking-cisco \
>  openstack/deb-networking-mlnx openstack/deb-networking-odl \
>  openstack/deb-python-mistralclient \
>  openstack/deb-python-muranoclient \
>  openstack/deb-python-proliantutils
> eol-branch.sh -- stable/kilo kilo-eol \
>  openstack-dev/grenade openstack/murano-apps \
>  openstack/networking-h3c openstack/requirements
> eol-branch.sh -- stable/kilo kilo-eol1 \
>  openstack/group-based-policy \
>  openstack/group-based-policy-automation \
>  openstack/group-based-policy-ui \
>  openstack/python-group-based-policy-client
> eol-branch.sh -- stable/kilo_v2 kilo_v2-eol openstack/networking-bigswitch
> eol-branch.sh -- stable/liberty liberty-eol \
>  openstack-dev/grenade openstack/ceilometer-powervm \
>  openstack/ceilometer-zvm openstack/ceilometermiddleware \
>  openstack/fuel-plugin-calico openstack/group-based-policy \
>  

Re: [openstack-dev] [all][stable][ptls] Tagging mitaka as EOL

2017-04-13 Thread Sumit Naiksatam
Hi Tony, Kindly do not EOL openstack/group-based-policy, we are
maintaining this branch.

Thanks,
~Sumit.



On Thu, Apr 13, 2017 at 4:40 PM, Tony Breeds  wrote:
> On Thu, Apr 13, 2017 at 08:20:50AM -0600, Alex Schultz wrote:
>
>> I would not include puppet-midonet without verification from those
>> devs. I believe it is still in use.
>
> Okay I'll leave them in the NOT EOLing list.  I assumed that puppet-midonet
> would just plain fail once there wasn't a stable/mitaka branch in the otehr
> repos.
>
> Yours Tony.
>
> __
> 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] [OpenStack-Infra] [all][stable][ptls] Tagging liberty as EOL

2016-12-14 Thread Sumit Naiksatam
On Wed, Dec 14, 2016 at 4:54 AM, Joshua Hesketh
 wrote:
> The repos listed[0] have had stable/liberty branch removed and replaced with
> a liberty-eol tag. Any open reviews have been abandoned.
>
> Please let me know if there are any mistakes or latecomers to the list.

Hi Joshua, Apologies for chiming in late, but we request that the
openstack/group-based-policy repo’s stable/liberty branch be _not_
removed/EOL’ed and the currently open patches not be abandoned. We
have consumers of this branch and we do backport bug fixes. Thanks in
advance!

~Sumit.

>
> Cheers,
> Josh
>
> [0]
> https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>
> On Fri, Dec 9, 2016 at 3:55 PM, Joshua Hesketh 
> wrote:
>>
>> Hey Tony and all,
>>
>> I'm happy to take care of these retirements. However I probably can't get
>> to it until Tuesday next week. So assuming no other infra root beats me to
>> it I'll look at it then.
>>
>> Cheers,
>> Josh
>>
>> On Thu, Dec 8, 2016 at 3:58 PM, Tony Breeds 
>> wrote:
>>>
>>> On Tue, Nov 22, 2016 at 01:35:48PM +1100, Tony Breeds wrote:
>>>
>>> > I'll batch the removal of the stable/liberty branches between Nov 28th
>>> > and Dec
>>> > 3rd (UTC+1100).  Then during Decemeber I'll attempt to cleanup
>>> > zuul/layout.yaml
>>> > to remove liberty exclusions and jobs.
>>>
>>> This took longer as there are a few repos that are scheduled for EOL that
>>> were a
>>> little problematic during the kilo cycle.  I've updated the list at [1]
>>>
>>> Can the infra team please run eol_branch.sh [2] over the repos listed at
>>> that
>>> URL [1] and flagged with 'Please EOL'.  The others will need to be done
>>> later.
>>>
>>> eol_branch.sh needs just the repo names what can be generated with
>>> something like:
>>>
>>> URL=https://gist.githubusercontent.com/tbreeds/93cd346c37aa46269456f56649f0a4ac/raw/liberty_eol_data.txt
>>> eol_branch.sh REPOS=$(curl -s $URL | awk '/Please EOL/ {print $1}')
>>>
>>> The data format is a balance between human and machine readable.
>>>
>>> Yours Tony.
>>>
>>> [1]
>>> https://gist.github.com/tbreeds/93cd346c37aa46269456f56649f0a4ac#file-liberty_eol_data-txt
>>> [2]
>>> http://git.openstack.org/cgit/openstack-infra/release-tools/tree/eol_branch.sh
>>>
>>> ___
>>> OpenStack-Infra mailing list
>>> openstack-in...@lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
>>
>>
>
>
> ___
> OpenStack-Infra mailing list
> openstack-in...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra

__
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] Question on GBP installation

2016-08-22 Thread 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] [stable][all] Tagging kilo-eol for "the world"

2016-06-24 Thread Sumit Naiksatam
Hi Tony, Thanks for your response, and no worries! We can live with
the kilo-eol tag, no need to try to delete it. And as you suggested,
we can add a second eol tag when we actually EoL this branch.

As regards reviving the deleted branches, would a bug have to be
created somewhere to track this, or is this already on the radar of
the infra team (thanks in advance if it already is)?

~Sumit.

On Fri, Jun 24, 2016 at 4:17 PM, Tony Breeds <t...@bakeyournoodle.com> wrote:
> On Fri, Jun 24, 2016 at 11:20:12AM -0700, Sumit Naiksatam wrote:
>> Hi, I had earlier requested in this thread that the stable/kilo branch
>> for the following repos be not deleted:
>>
>> > openstack/group-based-policy
>> > openstack/group-based-policy-automation
>> > openstack/group-based-policy-ui
>> > openstack/python-group-based-policy-client
>>
>> and the request was ack’ed by Tony (also in this thread). However, I
>> just noticed that these branches have been deleted. Can this deletion
>> please be reversed?
>
> Firstly I appologise.  I clearly gave Josh the wrong list of repos, which
> included the repos above.
>
> I'm sure we can re-create the branch from the SHA and that *should* allow
> development to continue hhowever due to the ditributed nature of gut deleteing
> the tag is "hard".  What this means in practise is that when you do decide to
> dop the kilo branch you'll end up with a kilo-eol-for-real-this-time :) or
> similar tag.
>
> Again I'm sorry fo the mistake.
>
> Yours Tony.
>
> __
> 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] [stable][all] Tagging kilo-eol for "the world"

2016-06-24 Thread Sumit Naiksatam
Hi, I had earlier requested in this thread that the stable/kilo branch
for the following repos be not deleted:

> openstack/group-based-policy
> openstack/group-based-policy-automation
> openstack/group-based-policy-ui
> openstack/python-group-based-policy-client

and the request was ack’ed by Tony (also in this thread). However, I
just noticed that these branches have been deleted. Can this deletion
please be reversed?

Thanks,
~Sumit.

On Fri, Jun 24, 2016 at 10:32 AM, Andreas Jaeger  wrote:
> On 06/24/2016 02:09 PM, Joshua Hesketh wrote:
>>
>> Hi all,
>>
>> I have completed removing stable/kilo branches from the projects listed
>> [0]*. There are now 'kilo-eol' tags in place at the sha's where the
>> branches were.
>>
>> *There are a couple of exceptions. oslo-incubator was listed but is an
>> unmaintained project so no further action was required. Tony and I have
>> also decided to hold off
>> on openstack-dev/devstack, openstack-dev/grenade, openstack-dev/pbr
>> and openstack/requirements until we are confident removing the
>> stable/kilo branch will have no negative effects on the projects who
>> opt-ed out of being EOL'd.
>>
>> In this process we noted a couple of repositories still have branches
>> from Juno and even earlier. I haven't put together a comprehensive list
>> of old branches, but rather if your project has an outdated branch that
>> you would like removed and/or tagged as end-of-life, please let me know.
>>
>> For those interested in the script I used or other infra cores looking
>> to perform this next time, it is up for review in the release-tools
>> repo: https://review.openstack.org/333875
>
>
> Thanks, Joshua.
>
> We're now removing the special handling of kilo branches from project-config
> as well - it looks odd for some projects where kilo is removed from
> conditions and we still have icehouse or juno. Followup changes are welcome.
>
> https://review.openstack.org/334008
> https://review.openstack.org/333910
> https://review.openstack.org/333977
>
> Andreas
> --
>  Andreas Jaeger aj@{suse.com,opensuse.org} Twitter: jaegerandi
>   SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
>GF: Felix Imendörffer, Jane Smithard, Graham Norton,
>HRB 21284 (AG Nürnberg)
> GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126
>
>
>
> __
> 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

2016-06-13 Thread 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] [stable][all] Tagging kilo-eol for "the world"

2016-06-09 Thread Sumit Naiksatam
On Thu, Jun 9, 2016 at 3:10 PM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>
>> On 10 Jun 2016, at 00:03, Sumit Naiksatam <sumitnaiksa...@gmail.com> wrote:
>>
>> On Thu, Jun 9, 2016 at 2:26 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>>>
>>>> On 09 Jun 2016, at 11:16, Sumit Naiksatam <sumitnaiksa...@gmail.com> wrote:
>>>>
>>>> Hi Tony, The following repos should not be included in the EoL list since 
>>>> they will not be EoL'ed at this time:
>>>> openstack/group-based-policy
>>>> openstack/group-based-policy-automation
>>>> openstack/group-based-policy-ui
>>>> openstack/python-group-based-policy-client
>>>
>>> Would you mind clarifying why you absolutely need to maintain those old 
>>> branches for those projects, and how do you plan to do it if no tempest 
>>> jobs will be able to install other components for you?
>>>
>>
>> We are continuing to fix bugs for kilo users.
>
> How are you supposed to validate that those fixes don’t break interactions 
> with other components?
>
We expect that any such fixes will be fairly contained, and well
covered by the UTs. In addition we will be doing our due diligence
with offline integration testing.

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

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


Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

2016-06-09 Thread Sumit Naiksatam
On Thu, Jun 9, 2016 at 2:26 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:
>
>> On 09 Jun 2016, at 11:16, Sumit Naiksatam <sumitnaiksa...@gmail.com> wrote:
>>
>> Hi Tony, The following repos should not be included in the EoL list since 
>> they will not be EoL'ed at this time:
>> openstack/group-based-policy
>> openstack/group-based-policy-automation
>> openstack/group-based-policy-ui
>> openstack/python-group-based-policy-client
>
> Would you mind clarifying why you absolutely need to maintain those old 
> branches for those projects, and how do you plan to do it if no tempest jobs 
> will be able to install other components for you?
>

We are continuing to fix bugs for kilo users.

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

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


Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

2016-06-09 Thread Sumit Naiksatam
Hi Tony, The following repos should not be included in the EoL list since
they will not be EoL'ed at this time:
openstack/group-based-policy
openstack/group-based-policy-automation
openstack/group-based-policy-ui
openstack/python-group-based-policy-client

Thanks,
Sumit.
On Jun 9, 2016 12:16 AM, "Tony Breeds"  wrote:

> On Fri, Jun 03, 2016 at 04:25:01PM +1000, Tony Breeds wrote:
> > On Thu, Jun 02, 2016 at 08:31:43PM +1000, Tony Breeds wrote:
> > > Hi all,
> > > In early May we tagged/EOL'd several (13) projects.  We'd like to
> do a
> > > final round for a more complete set.  We looked for projects meet one
> or more
> > > of the following criteria:
> > > - The project is openstack-dev/devstack, openstack-dev/grenade or
> > >   openstack/requirements
> > > - The project has the 'check-requirements' job listed as a template in
> > >   project-config:zuul/layout.yaml
> > > - The project is listed in governance:reference/projects.yaml and is
> tagged
> > >   with 'release:managed' or 'stable:follows-policy' (or both).
> >
> > So We've had a few people opt into EOL'ing which is great.
> >
> > I've Moved the lists from paste.o.o to a gist.  The reason for that is I
> can
> > update them, the URL doesn't change and there is a revision history (or
> sorts).
> >
> > The 2 lists are now at:
> https://gist.github.com/tbreeds/7de812a5d363fab4bd425beae5084c87
>
> I have just re-generated the stats for open changes.  The details are at:
> https://gist.github.com/tbreeds/7de812a5d363fab4bd425beae5084c87
>
> The summary looks like:
> All Repos : 1007
> Checked Repos : 318
> Repos with kilo branches  : 172
> EOL Repos : 152
> NOT EOL Repos :  20
> Tagged Repos  :  15
> Open Reviews  :  48
>
> I have abandoned about half of the 48 reviews above but the rest I don't
> have
> permission to abandon.
>
> The remaining reviews are at: http://tiny.cc/os-kilo-still-open
>
> The repos below have been left open:
> Open
> Repo Project Reviews
> Notes
>  --- ---
> -
> openstack/cookbook-openstack-bare-metal   Chef OpenStack
> openstack/cookbook-openstack-block-storageChef OpenStack
> openstack/cookbook-openstack-client   Chef OpenStack
> openstack/cookbook-openstack-common   Chef OpenStack
> openstack/cookbook-openstack-compute  Chef OpenStack
> openstack/cookbook-openstack-dashboardChef OpenStack
> openstack/cookbook-openstack-data-processing  Chef OpenStack
> openstack/cookbook-openstack-database Chef OpenStack
> openstack/cookbook-openstack-identity Chef OpenStack
> openstack/cookbook-openstack-imageChef OpenStack
> openstack/cookbook-openstack-integration-test Chef OpenStack
> openstack/cookbook-openstack-network  Chef OpenStack
> openstack/cookbook-openstack-object-storage   Chef OpenStack
> openstack/cookbook-openstack-ops-database Chef OpenStack
> openstack/cookbook-openstack-ops-messagingChef OpenStack
> openstack/cookbook-openstack-orchestrationChef OpenStack
> openstack/cookbook-openstack-telemetryChef OpenStack
> openstack/murano-apps murano   3
> openstack/openstack-ansible OpenStackAnsible
> openstack/packstack  BigTent
>
> Yours Tony.
>
> __
> 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

2016-05-06 Thread 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] [Policy] [GBP]

2015-12-14 Thread 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

2015-11-26 Thread 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

2015-11-12 Thread 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]

2015-11-10 Thread 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] [Policy][Group-based-policy] SFC Use Case

2015-11-02 Thread Sumit Naiksatam
Hi Naresh, I believe you are hitting this bug:

https://bugs.launchpad.net/group-based-policy/+bug/1418839

Try an AWS-type template [1] and it should work. Alternatively, you
can get the HOT template to work in your local environment by applying
this small fix:
https://review.openstack.org/#/c/160629/1/gbpservice/neutron/db/servicechain_db.py

Thanks,
~Sumit.

[1] 
https://github.com/openstack/group-based-policy/blob/master/gbpservice/tests/contrib/devstack/gbp-templates/firewall-lb-servicechain/fw.template

On Mon, Nov 2, 2015 at 10:28 PM, NareshA kumar
<n...@criterionnetworks.com> wrote:
> Hi Sumit,
> Can you kindly share an example yaml file for firewall. With my yaml file I
> am able to create vm through heat but while creating service node it says
> "Invalid file format".
>
> Regards.
> Naresh
>
> On Mon, Nov 2, 2015 at 1:31 PM, Sumit Naiksatam <sumitnaiksa...@gmail.com>
> wrote:
>>
>> Hi Naresh, You should be able to use the same heat templates.
>>
>> Thanks,
>> ~Sumit.
>>
>> On Fri, Oct 30, 2015 at 3:06 AM, NareshA kumar
>> <n...@criterionnetworks.com> wrote:
>> > Hi,
>> > I have tried GBP in Kilo. Now I want to try GBP+SFC integration in Kilo.
>> > Regarding which i have few questions,
>> >
>> > Is GBP+SFC supported now in Kilo?
>> > If yes, please suggest me some links to follow.
>> > For creating SFC in kilo where can I find heat templates?
>> >
>> > Regards,
>> >
>> > Naresh.
>> >
>> >
>> >
>> > __
>> > 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] [Policy][Group-based-policy] Service chain node creation fails

2015-11-02 Thread Sumit Naiksatam
Hi Naresh, I can try and help you with this. Can you unicast the file to me?

Thanks,
~Sumit.

On Sun, Nov 1, 2015 at 10:26 PM, NareshA kumar
 wrote:
> Hi,
> When I try to create a Service chain node by giving the yaml file as heat
> template it says "Invalid file format". But with the same file I am able to
> create a stack using "heat stack-create"  command.
>
> What am I missing here?
> Is there is any log file that can provide me the details of my error?
>
> Anyone please help me . I am stuck here for a long time.
>
> Regards,
> Naresh.
>
> __
> 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] [Policy][Group-based-policy] SFC Use Case

2015-11-02 Thread Sumit Naiksatam
Hi Naresh, You should be able to use the same heat templates.

Thanks,
~Sumit.

On Fri, Oct 30, 2015 at 3:06 AM, NareshA kumar
 wrote:
> Hi,
> I have tried GBP in Kilo. Now I want to try GBP+SFC integration in Kilo.
> Regarding which i have few questions,
>
> Is GBP+SFC supported now in Kilo?
> If yes, please suggest me some links to follow.
> For creating SFC in kilo where can I find heat templates?
>
> Regards,
>
> Naresh.
>
>
> __
> 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] [Policy][Group-based-policy]

2015-09-15 Thread Sumit Naiksatam
Hi Sagar,

GBP has a single REST API interface. The CLI, Horizon and Heat are
merely clients of the same REST API.

There was a similar question on this which I had responded to in a
different mailer:
http://lists.openstack.org/pipermail/openstack/2015-September/013952.html

and I believe you are cc'ed on that thread. I have provided more
information on how you can run the CLI in the verbose mode to explore
the REST request and responses. Hope that will be helpful, and we are
happy to guide you through this exercise (catch us on #openstack-gbp
for real time help).

Thanks,
~Sumit.

On Tue, Sep 15, 2015 at 3:45 AM, Sagar Pradhan  wrote:
>
>  Hello ,
>
> We were exploring group based policy for some project.We could find CLI and
> REST API documentation for GBP.
> Do we have separate REST API for GBP which can be called separately ?
> From documentation it seems that we can only use CLI , Horizon and Heat.
> Please point us to CLI or REST API documentation for GBP.
>
>
> Regards,
> Sagar
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

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


Re: [openstack-dev] [neutron] [fwaas] -IPv6 support in Kilo

2015-06-02 Thread Sumit Naiksatam
Hi Rukhsana, When you say IPv6 support for FWaaS in Kilo can you
indicate exactly what you are looking for?

The FWaaS rules in the resource model support both formats (which I
recall has always been the case). A particular implementation/driver
may not support ipv6 (and which is what you are seeing in the
referenced code).

Thanks,
~Sumit.

On Tue, Jun 2, 2015 at 10:57 AM, Rukhsana Ansari
rukhsana.ans...@oneconvergence.com wrote:
 Hi,

 I was browsing the code to understand IPv6  support For FWaaS in Kilo.

 I don't see a restriction in the db code or in reference fwaas_plugin.py

 However, from  this:
 https://github.com/openstack/neutron-fwaas/blob/stable/kilo/neutron_fwaas/services/firewall/drivers/vyatta/vyatta_fwaas.py#L126

 I gather that at least Vyatta does not have IPv6 firewall support.

 Would greatly appreciate it if someone could explain  the reasons for this
 restriction.

 Thanks
 -Rukhsana

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


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


[openstack-dev] [Neutron][FWaaS] No IRC meeting on May 13th and 20th

2015-05-12 Thread Sumit Naiksatam
Hi, Per agreement in the last IRC meeting we will not be having the
IRC meeting for the next couple of weeks. See you all in Vancouver!

~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] [neutron][FWaaS] No weekly IRC meeting today (04/22)

2015-04-22 Thread Sumit Naiksatam
Hi, Since some of the regular folks are not going be available for the
meeting today, it was suggested that we skip the meeting today.

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] Fixing backward incompatible unnamed constraints removal

2015-04-15 Thread 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


Re: [openstack-dev] [Group-Based-Policy] Service Chain Instance ownership

2015-03-27 Thread 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] [tc] Group Based Policy project proposal

2015-03-25 Thread Sumit Naiksatam
Hi All,

The GBP PTL elections [1] were completed earlier, hence we have
removed the GBP project proposal [2] from WIP (originally posted on
March 5th).

We would request the TC to take note and consider this proposal during
the next meeting. The team will be happy to answer questions and
provide more information via ML, and/or IRC on the #openstack-gbp
channel.

Thanks,
~Sumit, IRC: SumitNaiksatam
(on behalf of GBP-team).

[1] http://lists.openstack.org/pipermail/openstack-dev/2015-March/059317.html
[2] https://review.openstack.org/#/c/161902

On Thu, Mar 5, 2015 at 11:11 PM, Sumit Naiksatam
sumitnaiksa...@gmail.com wrote:
 Hi All,

 The OpenStack Group Based Policy team of contributors has submitted a
 proposal [1] to add “Group Based Policy” as a project in the OpenStack
 namespace in accordance with the new governance changes [2]. We would
 request the TC to take note and consider this proposal during the next
 meeting. The team will be happy to answer questions and provide more
 information via ML, and/or IRC on the #openstack-gbp channel.

 Thanks,
 ~Sumit, IRC: SumitNaiksatam
 (on behalf of GBP-team).

 [1] https://review.openstack.org/#/c/161902
 [2] http://governance.openstack.org/reference/new-projects-requirements.html

__
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

2015-03-17 Thread 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] [keystone][congress][group-policy] Fetching policy from a remote source

2015-03-16 Thread Sumit Naiksatam
On Mon, Mar 16, 2015 at 8:10 AM, Adam Young ayo...@redhat.com wrote:
 Oslo policy has been released as a stand alone library.  This is great, in
 that the rules engine is relatively non-applicaition specific, and I assume
 that all of the policy based project are planning to migrate over to using
 the policy library instead of the incubated version.

 Part of the push toward a more dynamic policy mechanism is figuring out how
 to fetch and cache the policy files from Keystone.  I suspect that the other
 services have the same issue.

 1.  How long should a service hold on to the cached version of the policy
 file?
 2.  How can we avoid the stampeding herd if Keystone pushes out a
 notification change event?
 3.  How do we securely cache the file and still make it possible to debug.

 The PKI tokens have a lot of these same issues, and have a one-off mechanism
 for handling it.  We should probably look in to commonizing this function.

 There general mechanism should be fetch and cache but I think it should
 not be tied to keystone token validation so much as capable of using it if
 necessary.  I'm guessing that access to policy rules are typically
 controlled by auth token validated services.  Is this correct?

 Maybe the right level of abstraction is a callback function for fetching the
 file to be cached, with the default being something that uses
 python-requests, and then an  auth plugin based alternative for those that
 require Keystone tokens.

 Before I go off and write a spec, I'd like to know what the prior art is
 here.  I'd also like to know if there oslo policy library is part of the
 plans for the other groups that are doing policy based work?


Thanks Adam for bringing this up. As regards the group-based-policy
(GBP) project, we leverage the access control policy just like other
projects do, so the questions you raise above are definitely relevant
to GBP. We do not manage the lifecycle of this aspect of policy, so we
hope to use whatever comes out of this discussion.

 __
 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] How to deal with improvements

2015-03-13 Thread 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


[openstack-dev] [Group-based-policy][GBP] PTL Candidacy

2015-03-12 Thread 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] [tc] Group Based Policy project proposal

2015-03-05 Thread Sumit Naiksatam
Hi All,

The OpenStack Group Based Policy team of contributors has submitted a
proposal [1] to add “Group Based Policy” as a project in the OpenStack
namespace in accordance with the new governance changes [2]. We would
request the TC to take note and consider this proposal during the next
meeting. The team will be happy to answer questions and provide more
information via ML, and/or IRC on the #openstack-gbp channel.

Thanks,
~Sumit, IRC: SumitNaiksatam
(on behalf of GBP-team).

[1] https://review.openstack.org/#/c/161902
[2] http://governance.openstack.org/reference/new-projects-requirements.html

__
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] [Policy][Group-based-policy] Bug squashing day

2015-03-04 Thread Sumit Naiksatam
Thanks to the entire team for participating today, we made very good
progress with knocking off a number of long standing bugs. We will
also be cutting a new stable/juno release towards the end of this week
since we ended up back porting quite a few fixes.

On Sat, Feb 28, 2015 at 10:56 AM, Sumit Naiksatam
sumitnaiksa...@gmail.com wrote:
 Hi, Per our discussion in the last weekly IRC meeting, we will have
 the bug squashing day for GBP on Tuesday, March 3rd. We will
 coordinate activities over the #openstack-gbp channel. Please join and
 participate.

 Thanks,
 ~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] [Neutron] FWaaS - question about drivers

2015-02-20 Thread Sumit Naiksatam
Inline...

On Wed, Feb 18, 2015 at 7:48 PM, Vikram Choudhary
vikram.choudh...@huawei.com wrote:
 Hi,

 You can write your own driver. You can refer to below links for getting some 
 idea about the architecture.

 https://wiki.openstack.org/wiki/Neutron/ServiceTypeFramework

This is a legacy construct and should not be used.

 https://wiki.openstack.org/wiki/Neutron/LBaaS/Agent


The above pointer is to a LBaaS Agent which is very different from a
FWaaS driver (which was the original question in the email).

FWaaS does use pluggable drivers and the default is configured here:
https://github.com/openstack/neutron-fwaas/blob/master/etc/fwaas_driver.ini

For example for FWaaS driver implementation you can check here:
https://github.com/openstack/neutron-fwaas/tree/master/neutron_fwaas/services/firewall/drivers

 Thanks
 Vikram

 -Original Message-
 From: Sławek Kapłoński [mailto: ]
 Sent: 19 February 2015 02:33
 To: openstack-dev@lists.openstack.org
 Subject: [openstack-dev] [Neutron] FWaaS - question about drivers

 Hello,

 I'm looking to use FWaaS service plugin with my own router solution (I'm not 
 using L3 agent at all). If I want to use FWaaS plugin also, should I write 
 own driver to it, or should I write own service plugin?
 I will be grateful for any links to some description about this FWaaS and 
 it's architecture :) Thx a lot for any help


 --
 Best regards
 Sławek Kapłoński
 sla...@kaplonski.pl

 __
 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] [Neutron] FWaaS - question about drivers

2015-02-20 Thread Sumit Naiksatam
Hi Slawek,

During the Kilo development cycle the repositories of the three
services - FWaaS, LBaaS, VPNaaS, have split from the main neutron
repo. The pointers I posted were from this split repo. What you are
referring to is the Juno version of the code (during which all the
code was in one Neutron repo). FWaaS driver behavior is same in both
cases, so it really depends on which OpenStack release you want to
work with. Hope that clarifies.

Thanks,
~Sumit.

On Fri, Feb 20, 2015 at 3:05 PM, Sławek Kapłoński sla...@kaplonski.pl wrote:
 Hello,

 Thx for tips. I have one more question. You point me fo neutron-fwaas project
 which for me looks like different project then neutron. I saw fwaas service
 plugin directly in neutron in Juno. So which version should I use: this
 neutron-fwaas or service plugin from neutron? Or maybe it is the same or I
 misunderstand something?

 --
 Pozdrawiam / Best regards
 Sławek Kapłoński
 sla...@kaplonski.pl

 Dnia piątek, 20 lutego 2015 14:44:21 Sumit Naiksatam pisze:
 Inline...

 On Wed, Feb 18, 2015 at 7:48 PM, Vikram Choudhary

 vikram.choudh...@huawei.com wrote:
  Hi,
 
  You can write your own driver. You can refer to below links for getting
  some idea about the architecture.
 
  https://wiki.openstack.org/wiki/Neutron/ServiceTypeFramework

 This is a legacy construct and should not be used.

  https://wiki.openstack.org/wiki/Neutron/LBaaS/Agent

 The above pointer is to a LBaaS Agent which is very different from a
 FWaaS driver (which was the original question in the email).

 FWaaS does use pluggable drivers and the default is configured here:
 https://github.com/openstack/neutron-fwaas/blob/master/etc/fwaas_driver.ini

 For example for FWaaS driver implementation you can check here:
 https://github.com/openstack/neutron-fwaas/tree/master/neutron_fwaas/service
 s/firewall/drivers
  Thanks
  Vikram
 
  -Original Message-
  From: Sławek Kapłoński [mailto: ]
  Sent: 19 February 2015 02:33
  To: openstack-dev@lists.openstack.org
  Subject: [openstack-dev] [Neutron] FWaaS - question about drivers
 
  Hello,
 
  I'm looking to use FWaaS service plugin with my own router solution (I'm
  not using L3 agent at all). If I want to use FWaaS plugin also, should I
  write own driver to it, or should I write own service plugin? I will be
  grateful for any links to some description about this FWaaS and it's
  architecture :) Thx a lot for any help
 
 
  --
  Best regards
  Sławek Kapłoński
  sla...@kaplonski.pl
 
  __
  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] [Neutron] FWaaS - question about drivers

2015-02-20 Thread Sumit Naiksatam
Inline...

On Fri, Feb 20, 2015 at 3:38 PM, Sławek Kapłoński sla...@kaplonski.pl wrote:
 Hello,

 Thx guys. Now it is clear for me :)
 One more question. I saw that in this service plugin there is hardcoded quota
 1 firewall per tenant. Do you know why it is so limited? Is there any
 important reason for that?

This is a current limitation of the reference implementation, since we
associate the FWaaS firewall resource with all the neutron routers.
Note that this is not a limitation of the FWaaS model, hence, if your
backend can support it, you can override this limitation.

 And second thing. As there is only one firewall per tenant so all rules from
 it will be applied on all routers (L3 agents) from this tenant and for all
 tenant networks, am I right? If yes, how it is solved to set firewall rules

In general, this limitation is going away in the Kilo release. See the
following patch under review which removes the limitation of one
router per tenant:
https://review.openstack.org/#/c/152697/

 when for example new router is created? L3 agent is asking about rules via rpc
 or FwaaS is sending such notification to L3 agent?

In the current implementation this is automatically reconciled.
Whenever a new router comes up, the FWaaS agent pulls the rules, and
applies it on the interfaces of the new router.

 Sorry if my questions are silly but I didn't do anything with this service
 plugins yet :)

 --
 Pozdrawiam / Best regards
 Sławek Kapłoński
 sla...@kaplonski.pl

 Dnia piątek, 20 lutego 2015 16:27:33 Doug Wiegley pisze:
 Same project, shiny new repo.

 doug

  On Feb 20, 2015, at 4:05 PM, Sławek Kapłoński sla...@kaplonski.pl wrote:
 
  Hello,
 
  Thx for tips. I have one more question. You point me fo neutron-fwaas
  project which for me looks like different project then neutron. I saw
  fwaas service plugin directly in neutron in Juno. So which version
  should I use: this neutron-fwaas or service plugin from neutron? Or maybe
  it is the same or I misunderstand something?
 
  --
  Pozdrawiam / Best regards
  Sławek Kapłoński
  sla...@kaplonski.pl
 
  Dnia piątek, 20 lutego 2015 14:44:21 Sumit Naiksatam pisze:
  Inline...
 
  On Wed, Feb 18, 2015 at 7:48 PM, Vikram Choudhary
 
  vikram.choudh...@huawei.com wrote:
  Hi,
 
  You can write your own driver. You can refer to below links for getting
  some idea about the architecture.
 
  https://wiki.openstack.org/wiki/Neutron/ServiceTypeFramework
 
  This is a legacy construct and should not be used.
 
  https://wiki.openstack.org/wiki/Neutron/LBaaS/Agent
 
  The above pointer is to a LBaaS Agent which is very different from a
  FWaaS driver (which was the original question in the email).
 
  FWaaS does use pluggable drivers and the default is configured here:
  https://github.com/openstack/neutron-fwaas/blob/master/etc/fwaas_driver.i
  ni
 
  For example for FWaaS driver implementation you can check here:
  https://github.com/openstack/neutron-fwaas/tree/master/neutron_fwaas/serv
  ice s/firewall/drivers
 
  Thanks
  Vikram
 
  -Original Message-
  From: Sławek Kapłoński [mailto: ]
  Sent: 19 February 2015 02:33
  To: openstack-dev@lists.openstack.org
  Subject: [openstack-dev] [Neutron] FWaaS - question about drivers
 
  Hello,
 
  I'm looking to use FWaaS service plugin with my own router solution (I'm
  not using L3 agent at all). If I want to use FWaaS plugin also, should I
  write own driver to it, or should I write own service plugin? I will be
  grateful for any links to some description about this FWaaS and it's
  architecture :) Thx a lot for any help
 
 
  --
  Best regards
  Sławek Kapłoński
  sla...@kaplonski.pl
 
  
  __
  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

 __
 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

[openstack-dev] Group Based Policy - Kilo-1 development milestone

2015-02-16 Thread 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] [neutron][fwaas] No IRC meeting on Feb 11th eom

2015-02-10 Thread Sumit Naiksatam


__
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] [Policy][Group-based-policy] Policy violations investigation

2015-01-27 Thread Sumit Naiksatam
Hi Ariel,

This is indeed one of the use cases that is very relevant to, and can
be supported, with the GBP model. The GBP policy actions provide a way
to “redirect” to a service-instance/chain on matching a traffic
classifier. If you are able to represent the “honeypot” functionality
as a Neutron advanced service, or wrap it in an implemented service,
then you can integrate it with today’s implementation. The GBP team
will be happy to provide you with more information on how you can
propose and implement any changes that you may need to make for this
integration. Also, feel free to catch us in #openstack-gbp and/or
during the GBP weekly IRC meeting [1].

Thanks,
~Sumit.

[1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

On Tue, Jan 27, 2015 at 8:19 AM, Ariel Zeitlin ariel.zeit...@gmail.com wrote:
 Hi,
 I want to propose an idea of investigation of policy violations (for
 white-list policies defined by GBP) by, for instance, redirecting the
 violating sessions to a HoneyPot.
 Meaning, that if the only communication between Group A and Group B is by
 port 80 (as described in the GPB) then an access to port 22 from Group A to
 Group B will be redirected to and answered by a HoneyPot that will
 investigate the real reason for policy violation, or simply log and drop the
 violating connection attempt.

 In tightly defined policies world as achieved through GBP an attacker trying
 to propagate inside the network is more likely to hit a wall and then
 actually create a golden lead for his detection.

 Do you think this concept can/should to be part of GBP and what would be the
 best way to promote it (sorry, I am pretty new to OpenStack and GBP
 specifically).

 Thanks,
 Ariel


 __
 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] [Policy][Group-based-policy] ODL Policy Driver Specs

2015-01-23 Thread Sumit Naiksatam
 questions);
 groupbasedpolicy-...@lists.opendaylight.org; Yapeng Wu
 Cc: bu...@noironetworks.com
 Subject: Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver
 Specs

 Hi,

 While working on the integration of Openstack With ODL GBP, I have the below
 queries:
 1.Endpoint-group Create: When I create a new policy-target-group
 from Openstack say gbp target-policy-group-create group1, it internally
 creates a l2.policy which includes the creation of the network and subnet.
 Meaning creation of EPG will create Network and subnet implicitly in
 Openstack and also the corresponding EPG, subnet, l3-context,
 l2-flood-domain, l2-bridge-domain will be created in the ODL GBP. So during
 the above EPG creation, neutron network and subnet call will come to the
 neutron northbound of ODL or only to ODL GBP??
 [Yapeng] First, when creating policy-target-group, you need to give
 “provided-policy-rule-sets” or “consumed-policy-rule-sets” parameter.
 Currently we don’t support policy-target-group update. Second, neutron
 network and subnet call won’t go to ODL.
 2.
 2.In ODL, there is no Endpoint create API, instead there is an API
 to register the endpoints. So what is the sync between the OS and ODL for
 Endpoint create and register.?
 [Yapeng] The current working scheme is as follow: ODL GBP has new APIs for
 openstack-endpoint register and unregister supports.[1][2] When Openstack
 GBP creates policy-target, a neutron port will be created by implicit
 driver, openstack-endpoint register API will be invoked and the OVS
 tap-port-id will be passed as parameter to ODL GBP. Later when VM is booted,
 the OVS tap-port-id will be populated on openvswitch, this will trigger ODL
 to update ovs flow tables.

 [1] https://git.opendaylight.org/gerrit/#/c/13554/
 [2] https://git.opendaylight.org/gerrit/#/c/13896/


 Thanks  Regards
 Sachi Gupta



 From:Yapeng Wu yapeng...@huawei.com
 To:OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date:01/12/2015 09:01 PM
 Subject:Re: [openstack-dev] [Policy][Group-based-policy] ODL
 PolicyDriverSpecs
 




 Hello, Sachi,

 They both works. “End point group” has been renamed to “policy target
 group”. It is recommended to use “gbp policy-target-group-create”.

 Yapeng


 From: Sachi Gupta [mailto:sachi.gu...@tcs.com]
 Sent: Monday, January 12, 2015 7:03 AM
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy Driver
 Specs

 Hi,

 Can anyone explain the difference between gbp group-create and gbp
 policy-target-group-create??

 I think both these are working same.

 Thanks  Regards
 Sachi Gupta




 From:Sumit Naiksatam sumitnaiksa...@gmail.com
 To:OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date:11/26/2014 01:35 PM
 Subject:Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy
 DriverSpecs
 





 Hi, This GBP spec is currently being worked on:
 https://review.openstack.org/#/c/134285/

 It will be helpful if you can add [Policy][Group-based-policy] in
 the subject of your emails, so that the email gets characterized
 correctly.

 Thanks,
 ~Sumit.

 On Tue, Nov 25, 2014 at 4:27 AM, Sachi Gupta sachi.gu...@tcs.com wrote:
 Hey All,

 I need to understand the interaction between the Openstack GBP and the
 Opendaylight GBP project which will be done by ODL Policy driver.

 Can someone provide me with specs of ODL Policy driver for making my
 understanding on call flow.


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

[openstack-dev] [Neutron][FWaaS] No FWaaS meeting on Jan 14th

2015-01-14 Thread Sumit Naiksatam
We will skip today's FWaaS IRC meeting since a number of people in the
team are not available.

Thanks,
~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] [all] Group Based Policy - Announcing Release

2015-01-12 Thread Sumit Naiksatam
The first release of Group Based Policy (GBP) [1] is now available! It
is designed to work with OpenStack stable Juno, and comprises of four
components:
Service, Client, Heat Automation, and Horizon UI

This release includes GBP network policy drivers for connectivity
rendering using Neutron, configured with any core plugin (including
ML2)[2], or OpenDaylight Controller [3]. In addition, vendor-specific
policy drivers are available for Cisco ACI [4], Nuage Virtual
Services’ Platform (VSP) [5], and One Convergence Network
Virtualization and Service Delivery (NVSD) Controller [6].

This release introduces the foundation of the Group Based Policy model
that provides for the following features:

* Intent-driven declarative abstractions
* Separation of application, network, and security concerns
* Late binding to facilitate non-linear workflows
* Ability to introduce operator modulation in the form of admin constraints
* Policy-driven Network Services’ composition and chaining
* Policy-driven external connectivity abstractions

Fedora [7] and Ubuntu [8] packages are available for installation
(RHEL and CentOS packages are being tested). An all-in-one single-step
devstack installation is also available with usage instructions [2].
Please give it a try; we would greatly appreciate your feedback.
Please also join the weekly IRC meetings [9] or on #openstack-gbp.

Thanks,
Team GBP.

[1] https://wiki.openstack.org/wiki/GroupBasedPolicy
[2] https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallDevstack
[3] 
https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallODLIntegrationDevstack
[4] https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallCiscoACI
[5] https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallNuage
[6] https://wiki.openstack.org/wiki/GroupBasedPolicy/InstallOneConvergence
[7] https://openstack.redhat.com/Neutron_GBP
[8] https://launchpad.net/~group-based-policy-drivers/+archive/ubuntu/ppa
[9] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

__
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] [Policy][Group-based-policy] ODL Policy Driver Specs

2015-01-12 Thread Sumit Naiksatam
Hi, The 'group' CLI commands are an alias to the 'policy-target-group'
commands and are provided for convenience of use. Per your
observation, both are equally functional and supported.

Thanks,
~Sumit.

On Mon, Jan 12, 2015 at 4:02 AM, Sachi Gupta sachi.gu...@tcs.com wrote:
 Hi,

 Can anyone explain the difference between gbp group-create and gbp
 policy-target-group-create??

 I think both these are working same.

 Thanks  Regards
 Sachi Gupta




 From:Sumit Naiksatam sumitnaiksa...@gmail.com
 To:OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date:11/26/2014 01:35 PM
 Subject:Re: [openstack-dev] [Policy][Group-based-policy] ODL Policy
 DriverSpecs
 



 Hi, This GBP spec is currently being worked on:
 https://review.openstack.org/#/c/134285/

 It will be helpful if you can add [Policy][Group-based-policy] in
 the subject of your emails, so that the email gets characterized
 correctly.

 Thanks,
 ~Sumit.

 On Tue, Nov 25, 2014 at 4:27 AM, Sachi Gupta sachi.gu...@tcs.com wrote:
 Hey All,

 I need to understand the interaction between the Openstack GBP and the
 Opendaylight GBP project which will be done by ODL Policy driver.

 Can someone provide me with specs of ODL Policy driver for making my
 understanding on call flow.


 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 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] New addition to the core team

2015-01-08 Thread 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


Re: [openstack-dev] 答复: Re: [neutron][AdvancedServices] Confusion about the solution of the service chaining!

2015-01-08 Thread Sumit Naiksatam
Hi Alan,

On Wed, Jan 7, 2015 at 9:54 PM,  lv.erc...@zte.com.cn wrote:
 Hi Sumit,

 thanks for your reply, one more question,

 If I just using the 'group-based-policy-service-chaining' to developing the
 service chaining feuture, how to map the network service in the neutron to
 the GBP model, because all the network service we implemented are based on
 neutron model, but the 'group-based-policy-service-chaining' setup the
 service chaining based on GBP model, so how can we setup the service
 chaining for network services based the neutron model using the
 'group-based-policy-service-chaining' ?

The current model and implementation leverage the Neutron services as
is (the model is actually agnostic of the service
definition/implementation). Will be happy to further discuss this,
feel free to ping on #openstack-gbp.

Thanks,
~Sumit.


 BR
 Alan




 发件人: Sumit Naiksatam sumitnaiksa...@gmail.com
 收件人: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 日期: 2015/01/08 10:46
 主题:Re: [openstack-dev] [neutron][AdvancedServices] Confusion about
 the solution of the service chaining!
 



 Hi Alan,

 Responses inline...

 On Wed, Jan 7, 2015 at 4:25 AM,  lv.erc...@zte.com.cn wrote:
 Hi,

 I want to confirm that how is the project about Neutron Services
 Insertion,
 Chaining, and Steering going, I found that all the code implementation
 about service insertion、service chaining and traffic steering list in
 JunoPlan were Abandoned .

 https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan

 and I also found that we have a new project about GBP and
 group-based-policy-service-chaining be located at:


 https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-abstraction


 https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining

 so I'm confused with solution of the service chaining.


 Yes, the above two blueprints have been implemented and are available
 for consumption today as a part of the Group-based Policy codebase and
 release. The GBP model uses a policy trigger to drive the service
 composition and can accommodate different rendering policies like
 realization using NFV SFC.

 We are developing the service chaining feature, so we need to know which
 one
 is the neutron's choice.

 It would be great if you can provide feedback on the current
 implementation, and perhaps participate and contribute as well.

 Are the blueprints about the service insertion,
 service chaining and traffic steering list in JunoPlan all Abandoned ?


 Some aspects of this are perhaps a good fit in Neutron and others are
 not. We are looking forward to continuing the discussion on this topic
 on the areas which are potentially a good fit for Neutron (we have had
 this discussion before as well).

 BR
 Alan



 
 ZTE Information Security Notice: The information contained in this mail
 (and
 any attachment transmitted herewith) is privileged and confidential and is
 intended for the exclusive use of the addressee(s).  If you are not an
 intended recipient, any disclosure, reproduction, distribution or other
 dissemination or use of the information contained is strictly prohibited.
 If you have received this mail in error, please delete it and notify us
 immediately.



 ___
 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



 
 ZTE Information Security Notice: The information contained in this mail (and
 any attachment transmitted herewith) is privileged and confidential and is
 intended for the exclusive use of the addressee(s).  If you are not an
 intended recipient, any disclosure, reproduction, distribution or other
 dissemination or use of the information contained is strictly prohibited.
 If you have received this mail in error, please delete it and notify us
 immediately.



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


Re: [openstack-dev] [neutron][AdvancedServices] Confusion about the solution of the service chaining!

2015-01-07 Thread Sumit Naiksatam
Hi Alan,

Responses inline...

On Wed, Jan 7, 2015 at 4:25 AM,  lv.erc...@zte.com.cn wrote:
 Hi,

 I want to confirm that how is the project about Neutron Services Insertion,
 Chaining, and Steering going, I found that all the code implementation
 about service insertion、service chaining and traffic steering list in
 JunoPlan were Abandoned .

 https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan

 and I also found that we have a new project about GBP and
 group-based-policy-service-chaining be located at:

 https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-abstraction

 https://blueprints.launchpad.net/group-based-policy/+spec/group-based-policy-service-chaining

 so I'm confused with solution of the service chaining.


Yes, the above two blueprints have been implemented and are available
for consumption today as a part of the Group-based Policy codebase and
release. The GBP model uses a policy trigger to drive the service
composition and can accommodate different rendering policies like
realization using NFV SFC.

 We are developing the service chaining feature, so we need to know which one
 is the neutron's choice.

It would be great if you can provide feedback on the current
implementation, and perhaps participate and contribute as well.

 Are the blueprints about the service insertion,
 service chaining and traffic steering list in JunoPlan all Abandoned ?


Some aspects of this are perhaps a good fit in Neutron and others are
not. We are looking forward to continuing the discussion on this topic
on the areas which are potentially a good fit for Neutron (we have had
this discussion before as well).

 BR
 Alan



 
 ZTE Information Security Notice: The information contained in this mail (and
 any attachment transmitted herewith) is privileged and confidential and is
 intended for the exclusive use of the addressee(s).  If you are not an
 intended recipient, any disclosure, reproduction, distribution or other
 dissemination or use of the information contained is strictly prohibited.
 If you have received this mail in error, please delete it and notify us
 immediately.



 ___
 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] [neutron][FWaaS] No weekly IRC meetings on Dec 24th and 31st

2014-12-20 Thread Sumit Naiksatam
Hi, We will skip the meetings for the next two weeks since most team
members are not available to meet. Please continue to keep the
discussions going over the mailing and lists and the IRC channel.
Check back on the wiki page for the next meeting and agenda [1].

Thanks,
~Sumit.
[1] https://wiki.openstack.org/wiki/Meetings/FWaaS

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


[openstack-dev] [Neutron][Advanced Services] Suspending weekly IRC meetings

2014-12-15 Thread Sumit Naiksatam
Hi All, Since the split of the Neutron services (FWaaS, LBaaS, VPNaaS) into
individual repositories is done, and the follow-up activities are
progressing, I am proposing that we suspend the weekly IRC Advanced
Services' meeting [1] until we need it again.

Thanks,
~Sumit.
[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [neutron] Changes to the core team

2014-12-03 Thread Sumit Naiksatam
On Wed, Dec 3, 2014 at 9:07 PM, Adam Young ayo...@redhat.com wrote:
 On 12/03/2014 06:24 PM, Sukhdev Kapur wrote:

 Congratulations Henry and Kevin. It has always been pleasure working with
 you guys.


 If I may express my opinion, Bob's contribution to ML2 has been quite
 substantial. The kind of stability ML2 has achieved makes a statement of his
 dedication to this work. I have worked very closely with Bob on several
 issues and co-chaired ML2-Subteam with him and have developed tremendous
 respect for his dedication.
 Reading his email reply makes me believe he wants to continue to contribute
 as core developer. Therefore, I would like to take an opportunity to appeal
 to the core team to consider granting him his wish - i.e. vote -1 on his
 removal.

 If I might venture an outside voice in support of Bob:  you don't want to
 chase away the continuity.  Yes, sometimes the day job makes us focus on
 things other than upstream work for a while, but I would say that you should
 err on the side of keeping someone that is otherwise still engaged.
 Especially when that core has been as fundamental on a project as I know Bob
 to have been on Quantumer Neutron.

I would definitely echo the above sentiments; Bob has continually made
valuable design contributions to ML2 and Neutron that go beyond the
review count metric. Kindly consider keeping him as a part of the core
team.

That said, a big +1 to both, Henry and Kevin, as additions to the core
team! Welcome!!

Thanks,
~Sumit.







 regards..
 -Sukhdev






 On Wed, Dec 3, 2014 at 11:48 AM, Edgar Magana edgar.mag...@workday.com
 wrote:

 I give +2 to Henry and Kevin. So, Congratulations Folks!
 I have been working with both of them and great quality reviews are always
 coming out from them.

 Many thanks to Nachi and Bob for their hard work!

 Edgar

 On 12/2/14, 7:59 AM, Kyle Mestery mest...@mestery.com wrote:

 Now that we're in the thick of working hard on Kilo deliverables, I'd
 like to make some changes to the neutron core team. Reviews are the
 most important part of being a core reviewer, so we need to ensure
 cores are doing reviews. The stats for the 180 day period [1] indicate
 some changes are needed for cores who are no longer reviewing.
 
 First of all, I'm proposing we remove Bob Kukura and Nachi Ueno from
 neutron-core. Bob and Nachi have been core members for a while now.
 They have contributed to Neutron over the years in reviews, code and
 leading sub-teams. I'd like to thank them for all that they have done
 over the years. I'd also like to propose that should they start
 reviewing more going forward the core team looks to fast track them
 back into neutron-core. But for now, their review stats place them
 below the rest of the team for 180 days.
 
 As part of the changes, I'd also like to propose two new members to
 neutron-core: Henry Gessau and Kevin Benton. Both Henry and Kevin have
 been very active in reviews, meetings, and code for a while now. Henry
 lead the DB team which fixed Neutron DB migrations during Juno. Kevin
 has been actively working across all of Neutron, he's done some great
 work on security fixes and stability fixes in particular. Their
 comments in reviews are insightful and they have helped to onboard new
 reviewers and taken the time to work with people on their patches.
 
 Existing neutron cores, please vote +1/-1 for the addition of Henry
 and Kevin to the core team.
 
 Thanks!
 Kyle
 
 [1] http://stackalytics.com/report/contribution/neutron-group/180
 
 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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




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



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


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


Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

2014-11-18 Thread Sumit Naiksatam
On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif mha...@brocade.com wrote:
 I agree with Paul as advanced services go beyond just L4-L7.  Today, VPNaaS
 deals with L3 connectivity but belongs in advanced services.  Where does
 Edge-VPN work belong?  We need a broader definition for advanced services
 area.


So the following definition is being proposed to capture the broader
context and complement Neutron's current mission statement:

To implement services and associated libraries that provide
abstractions for advanced network functions beyond basic L2/L3
connectivity and forwarding.

What do people think?

 Thanks,
 —Hanif.

 From: Paul Michali (pcm) p...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Tuesday, November 18, 2014 at 4:08 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into
 separate repositories

 On Nov 18, 2014, at 6:36 PM, Armando M. arma...@gmail.com wrote:

 Mark, Kyle,

 What is the strategy for tracking the progress and all the details about
 this initiative? Blueprint spec, wiki page, or something else?

 One thing I personally found useful about the spec approach adopted in [1],
 was that we could quickly and effectively incorporate community feedback;
 having said that I am not sure that the same approach makes sense here,
 hence the question.

 Also, what happens for experimental efforts that are neither L2-3 nor L4-7
 (e.g. TaaS or NFV related ones?), but they may still benefit from this
 decomposition (as it promotes better separation of responsibilities)? Where
 would they live? I am not sure we made any particular progress of the
 incubator project idea that was floated a while back.


 Would it make sense to define the advanced services repo as being for
 services that are beyond basic connectivity and routing? For example, VPN
 can be L2 and L3. Seems like restricting to L4-L7 may cause some confusion
 as to what’s in and what’s out.


 Regards,

 PCM (Paul Michali)

 MAIL …..…. p...@cisco.com
 IRC ……..… pc_m (irc.freenode.com)
 TW ………... @pmichali
 GPG Key … 4525ECC253E31A83
 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



 Cheers,
 Armando

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

 On 18 November 2014 15:32, Doug Wiegley do...@a10networks.com wrote:

 Hi,

  so the specs repository would continue to be shared during the Kilo
  cycle.

 One of the reasons to split is that these two teams have different
 priorities and velocities.  Wouldn’t that be easier to track/manage as
 separate launchpad projects and specs repos, irrespective of who is
 approving them?

 Thanks,
 doug



 On Nov 18, 2014, at 10:31 PM, Mark McClain m...@mcclain.xyz wrote:

 All-

 Over the last several months, the members of the Networking Program have
 been discussing ways to improve the management of our program.  When the
 Quantum project was initially launched, we envisioned a combined service
 that included all things network related.  This vision served us well in the
 early days as the team mostly focused on building out layers 2 and 3;
 however, we’ve run into growth challenges as the project started building
 out layers 4 through 7.  Initially, we thought that development would float
 across all layers of the networking stack, but the reality is that the
 development concentrates around either layer 2 and 3 or layers 4 through 7.
 In the last few cycles, we’ve also discovered that these concentrations have
 different velocities and a single core team forces one to match the other to
 the detriment of the one forced to slow down.

 Going forward we want to divide the Neutron repository into two separate
 repositories lead by a common Networking PTL.  The current mission of the
 program will remain unchanged [1].  The split would be as follows:

 Neutron (Layer 2 and 3)
 - Provides REST service and technology agnostic abstractions for layer 2
 and layer 3 services.

 Neutron Advanced Services Library (Layers 4 through 7)
 - A python library which is co-released with Neutron
 - The advance service library provides controllers that can be configured
 to manage the abstractions for layer 4 through 7 services.

 Mechanics of the split:
 - Both repositories are members of the same program, so the specs
 repository would continue to be shared during the Kilo cycle.  The PTL and
 the drivers team will retain approval responsibilities they now share.
 - The split would occur around Kilo-1 (subject to coordination of the
 Infra and Networking teams). The timing is designed to enable the proposed
 REST changes to land around the time of the December development sprint.
 - The core team for each repository will be determined and proposed by
 Kyle Mestery for approval by the current core team.
 - The Neutron Server and the Neutron Adv Services Library would be
 co-gated to ensure 

Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into separate repositories

2014-11-18 Thread Sumit Naiksatam
On Tue, Nov 18, 2014 at 11:04 PM, henry hly henry4...@gmail.com wrote:
 Is FWaas L2/3 or L4/7?


Thats a good question, and what has been asked here in the context of
VPNaaS as well. Hence the proposed definition below avoids
characterizing the advanced services project purely as L4-7 because
that would not be accurate (in the context of any of existing three
services, or proposed new services).

 On Wed, Nov 19, 2014 at 11:10 AM, Sumit Naiksatam
 sumitnaiksa...@gmail.com wrote:
 On Tue, Nov 18, 2014 at 4:44 PM, Mohammad Hanif mha...@brocade.com wrote:
 I agree with Paul as advanced services go beyond just L4-L7.  Today, VPNaaS
 deals with L3 connectivity but belongs in advanced services.  Where does
 Edge-VPN work belong?  We need a broader definition for advanced services
 area.


 So the following definition is being proposed to capture the broader
 context and complement Neutron's current mission statement:

 To implement services and associated libraries that provide
 abstractions for advanced network functions beyond basic L2/L3
 connectivity and forwarding.

 What do people think?

 Thanks,
 —Hanif.

 From: Paul Michali (pcm) p...@cisco.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Tuesday, November 18, 2014 at 4:08 PM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [tc][neutron] Proposal to split Neutron into
 separate repositories

 On Nov 18, 2014, at 6:36 PM, Armando M. arma...@gmail.com wrote:

 Mark, Kyle,

 What is the strategy for tracking the progress and all the details about
 this initiative? Blueprint spec, wiki page, or something else?

 One thing I personally found useful about the spec approach adopted in [1],
 was that we could quickly and effectively incorporate community feedback;
 having said that I am not sure that the same approach makes sense here,
 hence the question.

 Also, what happens for experimental efforts that are neither L2-3 nor L4-7
 (e.g. TaaS or NFV related ones?), but they may still benefit from this
 decomposition (as it promotes better separation of responsibilities)? Where
 would they live? I am not sure we made any particular progress of the
 incubator project idea that was floated a while back.


 Would it make sense to define the advanced services repo as being for
 services that are beyond basic connectivity and routing? For example, VPN
 can be L2 and L3. Seems like restricting to L4-L7 may cause some confusion
 as to what’s in and what’s out.


 Regards,

 PCM (Paul Michali)

 MAIL …..…. p...@cisco.com
 IRC ……..… pc_m (irc.freenode.com)
 TW ………... @pmichali
 GPG Key … 4525ECC253E31A83
 Fingerprint .. 307A 96BB 1A4C D2C7 931D 8D2D 4525 ECC2 53E3 1A83



 Cheers,
 Armando

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

 On 18 November 2014 15:32, Doug Wiegley do...@a10networks.com wrote:

 Hi,

  so the specs repository would continue to be shared during the Kilo
  cycle.

 One of the reasons to split is that these two teams have different
 priorities and velocities.  Wouldn’t that be easier to track/manage as
 separate launchpad projects and specs repos, irrespective of who is
 approving them?

 Thanks,
 doug



 On Nov 18, 2014, at 10:31 PM, Mark McClain m...@mcclain.xyz wrote:

 All-

 Over the last several months, the members of the Networking Program have
 been discussing ways to improve the management of our program.  When the
 Quantum project was initially launched, we envisioned a combined service
 that included all things network related.  This vision served us well in 
 the
 early days as the team mostly focused on building out layers 2 and 3;
 however, we’ve run into growth challenges as the project started building
 out layers 4 through 7.  Initially, we thought that development would float
 across all layers of the networking stack, but the reality is that the
 development concentrates around either layer 2 and 3 or layers 4 through 7.
 In the last few cycles, we’ve also discovered that these concentrations 
 have
 different velocities and a single core team forces one to match the other 
 to
 the detriment of the one forced to slow down.

 Going forward we want to divide the Neutron repository into two separate
 repositories lead by a common Networking PTL.  The current mission of the
 program will remain unchanged [1].  The split would be as follows:

 Neutron (Layer 2 and 3)
 - Provides REST service and technology agnostic abstractions for layer 2
 and layer 3 services.

 Neutron Advanced Services Library (Layers 4 through 7)
 - A python library which is co-released with Neutron
 - The advance service library provides controllers that can be configured
 to manage the abstractions for layer 4 through 7 services.

 Mechanics of the split:
 - Both repositories are members of the same program, so the specs
 repository would continue to be shared during the Kilo cycle.  The PTL

Re: [openstack-dev] [Policy][Group-based-policy] GBP Juno/Kilo next steps meeting

2014-11-11 Thread Sumit Naiksatam
On Tue, Nov 11, 2014 at 9:49 AM, Gregory Lebovitz
gregory.i...@gmail.com wrote:
 +1, summary?

 On Tue, Nov 11, 2014 at 3:31 AM, Igor Cardoso igordc...@gmail.com wrote:

 Hello Sumit.
 Unfortunately I could not go to the round table meeting, sorry for the
 absence.
 Did you talk about traffic steering? Is there some place or etherpad with
 a summary of what was discussed/outlined?


The breakout session used the same etherpad as the design summit session:
https://etherpad.openstack.org/p/kilo-gbp-design-summit-topics

Thanks,
~Sumit.

 Cheers,

 On 5 November 2014 17:22, Sumit Naiksatam sumitnaiksa...@gmail.com
 wrote:

 Hi,

 We had a productive design session discussion on Tuesday. However, we
 could not get to the point where we discussed all the next steps and
 specific action items for Juno/Kilo GBP releases. We will be meeting
 tomorrow (Thursday) morning from in the Le Meridian to cover these.

 Time: 10 to 11 AM (before the Neutron sessions start)
 Location: Round tables (just outside the design session rooms), Floor
 -1, Le Meridian.

 Thanks,
 ~Sumit.

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




 --
 Igor Duarte Cardoso.
 http://igordcard.com
 @igordcard

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




 --
 
 Open industry-related email from
 Gregory M. Lebovitz

 ___
 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] [neutron][advanced services] Weekly IRC meeting day/time change

2014-11-09 Thread Sumit Naiksatam
Hi All,

Following up from the discussions during the Kilo Summit, we will be
resuming the Advanced Services' meetings [1]. The new day/time will be
Tuesday 17.00 UTC on #openstack-meeting-4 to follow the LBaaS meeting
[2].

Hope you can join.

Thanks,
~Sumit.

[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-November/050005.html

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


[openstack-dev] [Policy][Group-based-policy] GBP Juno/Kilo next steps meeting

2014-11-05 Thread Sumit Naiksatam
Hi,

We had a productive design session discussion on Tuesday. However, we
could not get to the point where we discussed all the next steps and
specific action items for Juno/Kilo GBP releases. We will be meeting
tomorrow (Thursday) morning from in the Le Meridian to cover these.

Time: 10 to 11 AM (before the Neutron sessions start)
Location: Round tables (just outside the design session rooms), Floor
-1, Le Meridian.

Thanks,
~Sumit.

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


[openstack-dev] [Policy][Group-based Policy] Review meeting for service redirect/chain patches

2014-10-27 Thread Sumit Naiksatam
Hi, We will be meeting in the #openstack-gbp channel on 10/28 at 16.00
UTC to jointly review some of the pending patches:

https://review.openstack.org/#/c/128559/
https://review.openstack.org/#/c/128551/
https://review.openstack.org/#/c/128552/
https://review.openstack.org/#/c/128555/
https://review.openstack.org/#/c/128556/
https://review.openstack.org/#/c/130004/
https://review.openstack.org/#/c/129545
https://review.openstack.org/#/c/130920/

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] [Neutron][LBaaS][Octavia] Octavia's API becoming spun out LBaaS

2014-10-26 Thread Sumit Naiksatam
Several people have been requesting that we resume the Advanced
Services' meetings [1] to discuss some of the topics being mentioned
in this thread. Perhaps it might help people to have a focussed
discussion on the topic of advanced services' spin-out prior to the
design summit session [2] in Paris. So I propose that we resume our
weekly IRC meetings starting this Wednesday (Oct 29th), 17.30 UTC on
#openstack-meeting-3.

Thanks,
~Sumit.

[1] https://wiki.openstack.org/wiki/Meetings/AdvancedServices
[2] 
http://kilodesignsummit.sched.org/event/8a0b7c1d64883c08286e4446e163f1a6#.VE3Ukot4r4y

On Sun, Oct 26, 2014 at 7:55 PM, Sridar Kandaswamy (skandasw)
skand...@cisco.com wrote:
 Hi Doug:

 On 10/26/14, 6:01 PM, Doug Wiegley do...@a10networks.com wrote:

Hi Brandon,

 4. I brought this up now so that we can decide whether we want to
 discuss it at the advanced services spin out session.  I don't see the
 harm in opinions being discussed before the summit, during the summit,
 and more thoroughly after the summit.

I agree with this sentiment.  I¹d just like to pull-up to the decision
level, and if we can get some consensus on how we move forward, we can
bring a concrete plan to the summit instead of 40 minutes of Kumbaya.  We
love each other.  Check.  Things are going to change sometime.  Check.  We
might spin-out someday.  Check.  Now, let¹s jump to the interesting part.

 3. The main reason a spin out makes sense from Neutron is that the scope
 for Neutron is too large for the attention advances services needs from
 the Neutron Core.  If all of advanced services spins out, I see that

There is merit here, but consider the sorts of things that an advanced
services framework should be doing:

- plugging into neutron ports, with all manner of topologies
- service VM handling
- plugging into nova-network
- service chaining
- applying things like security groups to services

Š this is all stuff that Octavia is talking about implementing itself in a
basically defensive manner, instead of leveraging other work.  And there
are specific reasons for that.  But, maybe we can at least take steps to
not be incompatible about it.  Or maybe there is a hierarchy of Neutron -
Services - LB, where we¹re still spun out, but not doing it in a way that
we have to re-implement the world all the time.  It¹s at least worth a
conversation or three.

 In total agreement and I have heard these sentiments in multiple
 conversations across multiple players.
 It would be really fruitful to have a constructive conversation on this
 across the services, and there are
 enough similar issues to make this worthwhile.

 Thanks

 Sridar


Thanks,
Doug




On 10/26/14, 6:35 PM, Brandon Logan brandon.lo...@rackspace.com wrote:

Good questions Doug.  My answers are as follows:

1. Yes
2. Some time after Kilo (same as I don't know when)
3. The main reason a spin out makes sense from Neutron is that the scope
for Neutron is too large for the attention advances services needs from
the Neutron Core.  If all of advanced services spins out, I see that
repeating itself within an advanced services project.  More and more
advanced services will get added in and the scope will become too
large.  There would definitely be benefits to it though, but I think we
would end up being right where we are today.
4. I brought this up now so that we can decide whether we want to
discuss it at the advanced services spin out session.  I don't see the
harm in opinions being discussed before the summit, during the summit,
and more thoroughly after the summit.

Yes the brunt of the time will not be spent on the API, but since it
seemed like an opportunity to kill two birds with one stone, I figured
it warranted a discussion.

Thanks,
Brandon

On Sun, 2014-10-26 at 23:15 +, Doug Wiegley wrote:
 Hi all,

 Before we get into the details of which API goes where, I¹d like to see
us
 answer the questions of:

 1. Are we spinning out?
 2. When?
 3. With or without the rest of advanced services?
 4. Do we want to wait until we (the royal ³we² of ³the Neutron team²)
have
 had the Paris summit discussions on vendor split-out and adv. services
 spinout before we answer those questions?  (Yes, that question is
leading.)

 To me, the ³where does the API live² is an implementation detail, and
not
 where the time will need to be spent.

 For the record, my answers are:

 1. Yes.
 2. I don¹t know.
 3. I don¹t know; this needs some serious discussion.
 4. Yes.

 Thanks,
 doug

 On 10/24/14, 3:47 PM, Brandon Logan brandon.lo...@rackspace.com
wrote:

 With the recent talk about advanced services spinning out of Neutron,
 and the fact most of the LBaaS community has wanted LBaaS to spin out
of
 Neutron, I wanted to bring up a possibility and gauge interest and
 opinion on this possibility.
 
 Octavia is going to (and has) an API.  The current thinking is that an
 Octavia driver will be created in Neutron LBaaS that will make a
 requests to the Octavia API.  When LBaaS spins out of Neutron, 

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

2014-10-14 Thread 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


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

2014-10-02 Thread 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] [infra] Nominating Andreas Jaeger for project-config-core

2014-09-26 Thread Sumit Naiksatam
+1, Andreas has been very responsive, prompt, and helpful in his reviews.

On Fri, Sep 26, 2014 at 11:12 AM, Sergey Lukjanov
slukja...@mirantis.com wrote:
 +1

 On Fri, Sep 26, 2014 at 10:45 AM, Anita Kuno ante...@anteaya.info wrote:
 On 09/26/2014 11:35 AM, James E. Blair wrote:
 I'm pleased to nominate Andreas Jaeger to the project-config core team.

 The project-config repo is a constituent of the Infrastructure Program
 and has a core team structured to be a superset of infra-core with
 additional reviewers who specialize in the area.

 Andreas has been doing an incredible amount of work simplifying the
 Jenkins and Zuul configuration for some time.  He's also been making it
 more complicated where it needs to be -- making the documentation jobs
 in particular a model of efficient re-use that is far easier to
 understand than what he replaced.  In short, he's an expert in Jenkins
 and Zuul configuration and both his patches and reviews are immensely
 helpful.

 Please respond with support or concerns and if the consensus is in
 favor, we will add him next week.

 Thanks,

 Jim

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

 It is a pleasure for me to read Andreas reviews since I always learn
 something.

 I think Andreas will be a big asset to the project-config repo and
 support him becoming a core reviewer.

 Thanks,
 Anita.

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



 --
 Sincerely yours,
 Sergey Lukjanov
 Sahara Technical Lead
 (OpenStack Data Processing)
 Principal Software Engineer
 Mirantis Inc.

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

2014-09-26 Thread Sumit Naiksatam
On Fri, Sep 26, 2014 at 10:22 AM, Stephen Wong
stephen.kf.w...@gmail.com wrote:
 CC'ed ODL GBP --- although this doesn't concern them at this point, it may
 be of interest to the team

 On Fri, Sep 26, 2014 at 12:10 AM, Sachi Gupta sachi.gu...@tcs.com wrote:

 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.

 Correct.


 Creating a contract - policy rules..Will this include a call to firewall
 rules or only security group calls will be done?

 At this point, only security group calls.


We have also used FWaaS rules in our experiments earlier, but it won't
be a part of the initial version of the mapping. In general, the GBP
model is independent of the rendering.



 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?


 That should be enough.

 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.


 Even FWaaS APIs are supported in ODL now? If so, I guess ODL is even
 ready to do (basic) 'redirect' action once it is implemented on the mapping
 driver then.

 And no, you should not need any other APIs.


 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.

 No. The intent of mapping driver is to allow network policies to be
 rendered by current Neutron plugins. So the ODL calls should NOT be any
 different from before, the magic happens in the mapping driver layer.



 How the GBP project in openstack will be affecting the Opendaylight
 neutron calls??


 It doesn't. That said, I fully expect the ODL Neutron handling layer to
 support GBP APIs in the (near) future. When that happens, instead of using
 the mapping driver, you will have an additional choice of using the ODL GBP
 driver.

 Hope it helps,
 - Stephen






 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

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

2014-09-22 Thread 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


Re: [openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-09 Thread Sumit Naiksatam
-September/044872.html*
 http://lists.openstack.org/pipermail/openstack-dev/2014-September/044872.html

 --
 Kevin Benton


 On Thu, Sep 4, 2014 at 11:24 PM, Mandeep Dhami *dh...@noironetworks.com*
 dh...@noironetworks.com wrote:


I agree. Also, as this does not preclude using the incubator when it
is ready, this is a good way to start iterating on implementation in
parallel with those issues being addressed by the community.

In my view, the issues raised around the incubator were significant
enough (around packaging, handling of updates needed for
horizon/heat/celiometer, handling of multiple feature branches, etc) that
we we will probably need a design session in paris before a consensus will
emerge around a solution for the incubator structure/usage. And if you are
following the thread on nova for 'Averting the Nova crisis ...', the final
consensus might actually BE to use separate stackforge project for plugins
anyways, and in that case we will have a head start ;-)

Regards,
Mandeep
-


On Thu, Sep 4, 2014 at 10:59 PM, Prasad Vellanki 
*prasad.vella...@oneconvergence.com*
prasad.vella...@oneconvergence.com wrote:
   Sumit
   Thanks for initiating this and also good discussion today on the
   IRC.

   My thoughts are that it is important to make this available to
   potential users and customers as soon as possible so that we can get 
 the
   necessary feedback. Considering that the neutron cores and community 
 are
   battling nova parity and stability now, I would think it would be 
 tough to
   get any time for incubator or neutron feature branch any time soon.
   I would think it would be better to move GBP into stackforge and
   then look at incubator or neutron feature branch when available.

   prasadv


   On Wed, Sep 3, 2014 at 9:07 PM, Sumit Naiksatam 
   *sumitnaiksa...@gmail.com* sumitnaiksa...@gmail.com wrote:
  Hi,

  There's been a lot of lively discussion on GBP a few weeks back
  and we
  wanted to drive forward the discussion on this a bit more. As
  you
  might imagine, we're excited to move this forward so more
  people can
  try it out.  Here are the options:

  * Neutron feature branch: This presumably allows the GBP
  feature to be
  developed independently, and will perhaps help in faster
  iterations.
  There does seem to be a significant packaging issue [1] with
  this
  approach that hasn’t been completely addressed.

  * Neutron-incubator: This allows a path to graduate into
  Neutron, and
  will be managed by the Neutron core team. That said, the
  proposal is
  under discussion and there are still some open questions [2].

  * Stackforge: This allows the GBP team to make rapid and
  iterative
  progress, while still leveraging the OpenStack infra. It also
  provides
  option of immediately exposing the existing implementation to
  early
  adopters.

  Each of the above options does not preclude moving to the other
  at a later time.

  Which option do people think is more preferable?

  (We could also discuss this in the weekly GBP IRC meeting on
  Thursday:
 *https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy*
  https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy)

  Thanks!

  [1]
  
 *http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html*
  
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
  [2]
  
 *http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html*
  
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

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


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


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




 --
 Kevin Benton___
 OpenStack-dev mailing list
 OpenStack-dev

[openstack-dev] [neutron][policy] Group-based Policy next steps

2014-09-03 Thread Sumit Naiksatam
Hi,

There's been a lot of lively discussion on GBP a few weeks back and we
wanted to drive forward the discussion on this a bit more. As you
might imagine, we're excited to move this forward so more people can
try it out.  Here are the options:

* Neutron feature branch: This presumably allows the GBP feature to be
developed independently, and will perhaps help in faster iterations.
There does seem to be a significant packaging issue [1] with this
approach that hasn’t been completely addressed.

* Neutron-incubator: This allows a path to graduate into Neutron, and
will be managed by the Neutron core team. That said, the proposal is
under discussion and there are still some open questions [2].

* Stackforge: This allows the GBP team to make rapid and iterative
progress, while still leveraging the OpenStack infra. It also provides
option of immediately exposing the existing implementation to early
adopters.

Each of the above options does not preclude moving to the other at a later time.

Which option do people think is more preferable?

(We could also discuss this in the weekly GBP IRC meeting on Thursday:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy)

Thanks!

[1] http://lists.openstack.org/pipermail/openstack-dev/2014-August/044283.html
[2] http://lists.openstack.org/pipermail/openstack-dev/2014-August/043577.html

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


Re: [openstack-dev] [neutron] Incubator concerns from packaging perspective

2014-08-22 Thread Sumit Naiksatam
On Thu, Aug 21, 2014 at 7:28 AM, Kyle Mestery mest...@mestery.com wrote:
 On Thu, Aug 21, 2014 at 5:12 AM, Ihar Hrachyshka ihrac...@redhat.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA512

 On 20/08/14 18:28, Salvatore Orlando wrote:
 Some comments inline.

 Salvatore

 On 20 August 2014 17:38, Ihar Hrachyshka ihrac...@redhat.com
 mailto:ihrac...@redhat.com wrote:

 Hi all,

 I've read the proposal for incubator as described at [1], and I
 have several comments/concerns/suggestions to this.

 Overall, the idea of giving some space for experimentation that
 does not alienate parts of community from Neutron is good. In that
 way, we may relax review rules and quicken turnaround for preview
 features without loosing control on those features too much.

 Though the way it's to be implemented leaves several concerns, as
 follows:

 1. From packaging perspective, having a separate repository and
 tarballs seems not optimal. As a packager, I would better deal with
 a single tarball instead of two. Meaning, it would be better to
 keep the code in the same tree.

 I know that we're afraid of shipping the code for which some users
 may expect the usual level of support and stability and
 compatibility. This can be solved by making it explicit that the
 incubated code is unsupported and used on your user's risk. 1) The
 experimental code wouldn't probably be installed unless explicitly
 requested, and 2) it would be put in a separate namespace (like
 'preview', 'experimental', or 'staging', as the call it in Linux
 kernel world [2]).

 This would facilitate keeping commit history instead of loosing it
 during graduation.

 Yes, I know that people don't like to be called experimental or
 preview or incubator... And maybe neutron-labs repo sounds more
 appealing than an 'experimental' subtree in the core project.
 Well, there are lots of EXPERIMENTAL features in Linux kernel that
 we actively use (for example, btrfs is still considered
 experimental by Linux kernel devs, while being exposed as a
 supported option to RHEL7 users), so I don't see how that naming
 concern is significant.


 I think this is the whole point of the discussion around the
 incubator and the reason for which, to the best of my knowledge,
 no proposal has been accepted yet.


 I wonder where discussion around the proposal is running. Is it public?

 The discussion started out privately as the incubation proposal was
 put together, but it's now on the mailing list, in person, and in IRC
 meetings. Lets keep the discussion going on list now.


In the spirit of keeping the discussion going, I think we probably
need to iterate in practice on this idea a little bit before we can
crystallize on the policy and process for this new repo. Here are few
ideas on how we can start this iteration:

* Namespace for the new repo:
Should this be in the neutron namespace, or a completely different
namespace like neutron labs? Perhaps creating a separate namespace
will help the packagers to avoid issues of conflicting package owners
of the namespace.

* Dependency on Neutron (core) repository:
We would need to sort this out so that we can get UTs to run and pass
in the new repo. Can we set the dependency on Neutron milestone
releases? We already publish tar balls for the milestone releases, but
I am not sure we publish these as packages to pypi. If not could we
start doing that? With this in place, the incubator would always lag
the Neutron core by at the most one milestone release.

* Modules overlapping with the Neutron (core) repository:
We could initially start with the features that required very little
or no changes to the Neutron core, to avoid getting into the issue of
blocking on changes to the Neutron (core) repository before progress
can be made in the incubator.

* Packaging of ancillary code (CLI, Horizon, Heat):
We start by adding these as subdirectories inside each feature. The
packaging folks are going to find it difficult to package this.
However, can we start with this approach, and have a parallel
discussion on how we can evolved this strategy? Perhaps the individual
projects might decide to allow support for the Neutron incubator
features once they can actually see what goes into the incubator,
and/or other projects might also follow the incubator approach.

If we have loose consensus on the above, some of us folks who are
involved with features that are candidates for the incubator (e.g.
GBP, LBaaS), can immediately start iterating on this plan, and report
back our progress in a specified time frame.

Thanks,
~Sumit.


 2. If those 'extras' are really moved into a separate repository
 and tarballs, this will raise questions on whether packagers even
 want to cope with it before graduation. When it comes to supporting
 another build manifest for a piece of code of unknown quality, this
 is not the same as just cutting part of the code into a separate
 experimental/labs package. So unless I'm explicitly asked to
 package the 

Re: [openstack-dev] Network/Incubator proposal (was Re: [Octavia] Minutes from 8/13/2014 meeting)

2014-08-19 Thread Sumit Naiksatam
+1 for neutron-labs! ;-)

On Tue, Aug 19, 2014 at 10:35 AM, Stefano Maffulli
stef...@openstack.org wrote:
 On 08/19/2014 08:39 AM, Eichberger, German wrote:
 Just to be clear: We all think the incubator is a great idea and if
 some things are ironed out will be a good way to onboard new projects
 to Neutron. What bothers me is the timing. Without warning we were
 put in an incubator in the span of like 8 days.

 No, not without warning: 8 days and we're still discussing the solution
 for code that has been developed by sub-teams and for which the core
 team has not reached consensus whether to merge it or not. As a
 reminder, until we started this discussion, the alternative for 'lack of
 consensus 3 days before feature freeze' was to leave code out of the
 tree. We've done it that way in the past.

 Incubator is a *proposal* to improve the situation, provide a way for
 code that is considered mature by a sub-team to be shipped to customers
 from a git.openstack.org repository (as opposed from somewhere else, as
 it happened in the past).

 The full details are on this wiki page:
 https://wiki.openstack.org/wiki/Network/Incubator

 This makes it
 difficult to plan and adds unnecessary uncertainty. Who is
 guaranteeing that if I tell my management LBaaS v2 will be in Kilo
 that nobody will throw a wrench in five months time?

 Great question! There is no simple answer: it's a risk everyone involved
 in OpenStack decides to run because that risk of a last minute wrench is
 balanced by the benefits of getting back a full working engine and spare
 parts, with manuals.

 That said, there are a lot of ways to mitigate that risk in any case.
 One is to pay attention to the priorities set by the project leaders and
 help them, first.

 Us, the people on this list, should be the ones explaining our managers
 what this OpenStack collaboration is all about. If it's not clear to you
 how, come to the Upstream Training sessions in Paris to get some ideas.
 https://wiki.openstack.org/wiki/OpenStack_Upstream_Training

 What I like to see from the Neutron Core team is timely communication
 with proper transition plans: For example if there is a change in how
 things are done it should be implemented at the beginning of a cycle
 and projects started before the change should have a grace period
 where things are done the old way. I understand that some things
 might have to be retroactively but that should be kept to a minimum -

 Yep, this is a very reasonable request. I think the that Neutron Core
 Team (and other teams, too) has space for improvements in the way they
 communicate to sub-teams and to the Foundation.

 This change comes too close to the end of the cycle, I agree and I think
 I understand the pain you're going through: it's bad. The only reason
 why I support this effort to change *now* is that the alternative to a
 new repository with LBaaSv2 code is more likely to be a 'no, come back
 for Kilo' (based on past experience). I find the 'no' to be unacceptable
 and 'yes' very unlikely. Incubator sounds like a good compromise.

 I'd focus our energies to addressing the shortcomings of the Incubator
 proposal. I, to start, would advocate for calling this repository
 'Labs', a place where cool and interesting things are given a chance to
 be tried out and if they stick, users like them, moved to a more
 permanent home (or die). Incubator sound too much like something that
 needs maturing and it may not be the case (plus it sounds too
 burocratic, with rules to graduation, etc).

 The sooner we iron out the wrinkles in the proposal the sooner we start
 educating distributions that there is good code in there that they may
 want to package and ship to users.


 /stef

 --
 Ask and answer questions on https://ask.openstack.org

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

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


Re: [openstack-dev] [neutron] Which changes need accompanying bugs?

2014-08-13 Thread Sumit Naiksatam
On Wed, Aug 13, 2014 at 5:43 PM, Angus Lees g...@inodes.org wrote:
 On Wed, 13 Aug 2014 11:11:51 AM Kevin Benton wrote:
 Is the pylint static analysis that caught that error prone to false
 positives? If not, I agree that it would be really nice if that were made
 part of the tox check so these don't have to be fixed after the fact.

 At the moment pylint on neutron is *very* noisy, and I've been looking through
 the reported issues by hand to get a feel for what's involved.  Enabling
 pylint is a separate discussion that I'd like to have - in some other thread.


I think enabling pylint check was discussed at the start of the
project, but for the reasons you mention, it was not considered.

 --
  - Gus

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

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


Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis and OpenStack Applicability - UPDATED

2014-08-13 Thread Sumit Naiksatam
Hi Michael,

Thanks for keeping us in the loop on the progress at your end. This is
very nice work. I quickly read through the section you referenced in
your email, and it does capture the current state of the work in
OpenStack/Neutron.

~Sumit.

On Wed, Aug 13, 2014 at 6:05 PM, Michael Grima mike.r.gr...@gmail.com wrote:
 Hi Everyone,

 Not sure if you remember, but a few months ago, I made the following
 thread on here titled: Firewall Web Services Research Thesis
 Applicability to the OpenStack Project
 (http://lists.openstack.org/pipermail/openstack-dev/2014-May/034575.html)

 To provide a recap, this is a thesis that I am researching, and
 examines the potential advantages of exposing a host's firewall via a
 web service.  The purpose of which is to improve the security of IaaS
 environments by now providing the ability for external security
 appliances, such as vulnerability scanners and IDS's, the ability to
 dynamically (and perhaps automatically) respond to incidents and close
 open ports to problematic virtual machines.  My thesis examines the
 perspective of the infrastructure administrator, as opposed to the
 domain administrator.

 At the time I made the initial post, I was actively writing my thesis,
 and I am happy to report that it is effectively done.

 You can download the PDF here:
 https://docs.google.com/file/d/0B7WyzOL96X9QWDl6R3RqRE0tMWc/edit

 I have a section that specifically mentions OpenStack (Page 44,
 Section 5.3).  Please review that section and let me know if it
 accurately and properly describes the OpenStack effort and
 corresponding projects (FWaaS, and Neutron).

 Of course, if you find any issues, please don't hesitate to point them out.

 Below are screen-videos showcasing my thesis in action:
 1.) Demo 1: Adding new rules/policies and manipulating traffic
 https://docs.google.com/file/d/0B7WyzOL96X9QU0dQa0xEekFxVlk/edit

 2.) Demo 2: Same as Demo 1, but showcasing platform independence by
 applying rules to a Windows Server 2008 R2 VM
 https://docs.google.com/file/d/0B7WyzOL96X9QMnRaZXBhU1FFc28/edit

 3.) Sample OpenVAS Scenario where a VM can --only-- operate a HTTP
 server on port 80.  Any other server that is detected is a
 violation of policy and would need to be blocked.
 https://docs.google.com/file/d/0B7WyzOL96X9QYXdFdC1XbHp2R3M/edit

 4.) OpenVAS Heartbleed Demo (as described above):
 https://docs.google.com/file/d/0B7WyzOL96X9QMzRMR1UzX09vRDA/edit

 5.) Earlier prototype of my thesis working with XEN instead of KVM:
 https://docs.google.com/file/d/0B7WyzOL96X9QTVowem1ZYjJrRWM/edit

 I would be happy to answer any questions you may have.

 Thank You

 --
 Mike Grima, RHCE

 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-12 Thread Sumit Naiksatam
Per the blueprint spec [1], what has been proposed are optional
extensions which complement the existing Neutron core resources'
model:


The main advantage of the extensions described in this blueprint is
that they allow for an application-centric interface to Neutron that
complements the existing network-centric interface.


It has been pointed out earlier in this thread that this is not a
replacement for the current Neutron core resources/API.

[1] 
https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm

On Tue, Aug 12, 2014 at 1:22 AM, loy wolfe loywo...@gmail.com wrote:
 Hi Paul,

 Below are some other useful GBP reference pages:
 https://wiki.opendaylight.org/view/Project_Proposals:Group_Based_Policy_Plugin
 http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps13004/ps13460/white-paper-c11-729906_ns1261_Networking_Solutions_White_Paper.html

 I think the root cause of this long argument, is that GBP core model was not
 designed native for Neutron, and they are introduced into Neutron so
 radically, without careful tailoring and adaption. Maybe the GBP team also
 don't want to do so, their intention is to maintain a unified model across
 all kinds of platform including Neutron, Opendaylight, ACI/Opflex, etc.

 However, redundancy and duplication exists between EP/EPG/BD/RD and
 Port/Network/Subnet. So mapping is used between these objects, and I think
 this is why so many voice to request moving GBP out and on top of Neutron.

 Will GBP simply be an *addition*? It absolutely COULD be, but objectively
 speaking, it's core model also allow it to BE-ABLE-TO take over Neutron core
 resource (see the wiki above). GBP mapping spec suggested a nova -nic
 extension to handle EP/EPG resource directly, thus all original Neutron core
 resource can be shadowed away from user interface: GBP became the new
 openstack network API :-) However no one can say depreciate Neutron core
 here and now, but shall we leave Neutron core just as *traditional/legacy*?

 Personally I prefer not to throw NW-Policy out of Neutron, but at the
 perquisite that its core model should be reviewed and tailored. A new
 lightweight model carefully designed native for Neutron is needed, but not
 directly copying a whole bunch of monolithic core resource from existing
 other system.

 Here is the very basic suggestion: because core value of GBP is policy
 template with contracts , throw away EP/EPG/L2P/L3P model while not just
 renaming them again and again. APPLY policy template to existing Neutron
 core resource, but not reinvent similar concept in GBP and then do the
 mapping.


 On Mon, Aug 11, 2014 at 9:12 PM, CARVER, PAUL pc2...@att.com wrote:

 loy wolfe [mailto:loywo...@gmail.com] wrote:



 Then since Network/Subnet/Port will never be treated just as LEGACY

 COMPATIBLE role, there is no need to extend Nova-Neutron interface to

 follow the GBP resource. Anyway, one of optional service plugins inside

 Neutron shouldn't has any impact on Nova side.



 This gets to the root of why I was getting confused about Jay and others

 having Nova related concerns. I was/am assuming that GBP is simply an

 *additional* mechanism for manipulating Neutron, not a deprecation of any

 part of the existing Neutron API. I think Jay's concern and the reason

 why he keeps mentioning Nova as the biggest and most important consumer

 of Neutron's API stems from an assumption that Nova would need to change

 to use the GBP API.





 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Sumit Naiksatam
Hi Jay, To extend Ivar's response here, the core resources and core
plugin configuration does not change with the addition of these
extensions. The mechanism to implement the GBP extensions is via a
service plugin. So even in a deployment where a GBP service plugin is
deployed with a driver which interfaces with a backend that perhaps
directly understands some of the GBP constructs, that system would
still need to have a core plugin configured that honors Neutron's core
resources. Hence my earlier comment that GBP extensions are
complementary to the existing core resources (in much the same way as
the existing extensions in Neutron).

Thanks,
~Sumit.

On Fri, Aug 8, 2014 at 9:49 AM, Ivar Lazzaro ivarlazz...@gmail.com wrote:
 Hi Jay,

 You can choose. The whole purpose of this is about flexibility, if you want
 to use GBP API 'only' with a specific driver you just can.
 Additionally, given the 'ML2 like' architecture, the reference mapping
 driver can ideally run alongside by filling the core Neutron constructs
 without ever 'disturbing' your own driver (I'm not entirely sure about this
 but it seems feasible).

 I hope this answers your question,
 Ivar.


 On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/08/2014 08:55 AM, Kevin Benton wrote:

 The existing constructs will not change.


 A followup question on the above...

 If GPB API is merged into Neutron, the next logical steps (from what I can
 tell) will be to add drivers that handle policy-based payloads/requests.

 Some of these drivers, AFAICT, will *not* be deconstructing these policy
 requests into the low-level port, network, and subnet
 creation/attachment/detachment commands, but instead will be calling out
 as-is to hardware that speaks the higher-level abstraction API [1], not the
 lower-level port/subnet/network APIs. The low-level APIs would essentially
 be consumed entirely within the policy-based driver, which would effectively
 mean that the only way a system would be able to orchestrate networking in
 systems using these drivers would be via the high-level policy API.

 Is that correct? Very sorry if I haven't explained clearly my question...
 this is a tough question to frame eloquently :(

 Thanks,
 -jay

 [1]
 http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html

 On Aug 8, 2014 9:49 AM, CARVER, PAUL pc2...@att.com
 mailto:pc2...@att.com wrote:

 Wuhongning [mailto:wuhongn...@huawei.com
 mailto:wuhongn...@huawei.com] wrote:

  Does it make sense to move all advanced extension out of ML2, like
 security
  group, qos...? Then we can just talk about advanced service
 itself, without
  bothering basic neutron object (network/subnet/port)

 A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
 still
 think it's too late in the game to be shooting down all the work
 that the
 GBP team has put in unless there's a really clean and effective way
 of
 running AND iterating on GBP in conjunction with Neutron without
 being
 part of the Juno release. As far as I can tell they've worked really
 hard to follow the process and accommodate input. They shouldn't have
 to wait multiple more releases on a hypothetical refactoring of how
 L3+ vs
 L2 is structured.

 But, just so I'm not making a horrible mistake, can someone reassure
 me
 that GBP isn't removing the constructs of network/subnet/port from
 Neutron?

 I'm under the impression that GBP is adding a higher level
 abstraction
 but that it's not ripping basic constructs like network/subnet/port
 out
 of the existing API. If I'm wrong about that I'll have to change my
 opinion. We need those fundamental networking constructs to be
 present
 and accessible to users that want/need to deal with them. I'm viewing
 GBP as just a higher level abstraction over the top.


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




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



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



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


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


Re: [openstack-dev] [neutron] [third-party] Freescale CI log site is being blocked

2014-08-08 Thread Sumit Naiksatam
Actually I am able to access the logs in this CI over the internet and
through my service provider. I have copy-pasted the log from the
latest freescale run here (to validate if this is indeed the latest
run):
http://paste.openstack.org/show/92229/

But good point Kevin, when I was trying to post this on paste, it did
complain about the log text appearing like spam.

On Fri, Aug 8, 2014 at 10:58 AM, Kevin Benton blak...@gmail.com wrote:
 Does your log server allow anonymous uploads that caused it to host malware
 or something that led to it being blocked?


 On Fri, Aug 8, 2014 at 7:12 AM, Kyle Mestery mest...@mestery.com wrote:

 Trinath:

 In looking at your FWaaS review [1], I noticed the site you are using
 for log storage is being blacklisted again, at least by Cisco WSA
 appliances. Thus, I cannot see the logs for it. Did you change the
 location of your log storage again? Is anyone else seeing this issue?

 Thanks,
 Kyle


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

 ___
 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] [Neutron][policy] Group Based Policy - Renaming

2014-08-08 Thread Sumit Naiksatam
Thanks Jay for your constructive feedback on this. I personally think
that 'policy-target' is a good option. I am not sure what the rest of
the team thinks, perhaps they can chime in.

On Fri, Aug 8, 2014 at 8:43 AM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/07/2014 01:17 PM, Ronak Shah wrote:

 Hi,
 Following a very interesting and vocal thread on GBP for last couple of
 days and the GBP meeting today, GBP sub-team proposes following name
 changes to the resource.


 policy-point for endpoint
 policy-group for endpointgroup (epg)

 Please reply if you feel that it is not ok with reason and suggestion.


 Thanks Ronak and Sumit for sharing. I, too, wasn't able to attend the
 meeting (was in other meetings yesterday and today).

 I'm very happy with the change from endpoint-group - policy-group.

 policy-point is better than endpoint, for sure. The only other suggestion I
 might have would be to use policy-target instead of policy-point, since
 the former clearly delineates what the object is used for (a target for a
 policy).

 But... I won't raise a stink about this. Sorry for sparking long and
 tangential discussions on GBP topics earlier this week. And thanks to the
 folks who persevered and didn't take too much offense to my questioning.

 Best,
 -jay



 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-08 Thread Sumit Naiksatam
On Fri, Aug 8, 2014 at 12:45 PM, Armando M. arma...@gmail.com wrote:
 On 8 August 2014 10:56, Kevin Benton blak...@gmail.com wrote:

 There is an enforcement component to the group policy that allows you to
 use the current APIs and it's the reason that group policy is integrated
 into the neutron project. If someone uses the current APIs, the group policy
 plugin will make sure they don't violate any policy constraints before
 passing the request into the regular core/service plugins.


 This is the statement that makes me trip over, and I don't understand why
 GBP and Neutron Core need to be 'integrated' together as they have. Policy
 decision points can be decentralized from the system under scrutiny, we
 don't need to have one giant monolithic system that does everything; it's an
 architectural decision that would make difficult to achieve composability
 and all the other good -ilities of software systems.


Adding the GBP extension to Neutron does not change the nature of the
software architecture of Neutron making it more or less monolithic. It
fulfills a gap that is currently present in the Neutron API, namely -
to complement the current imperative abstractions with a app
-developer/deployer friendly declarative abstraction [1]. To
reiterate, it has been proposed as an “extension”, and not a
replacement of the core abstractions or the way those are consumed. If
this is understood and interpreted correctly, I doubt that there
should be reason for concern.

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

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


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


Re: [openstack-dev] [Neutron] Simple proposal for stabilizing new features in-tree

2014-08-08 Thread Sumit Naiksatam
On Fri, Aug 8, 2014 at 1:21 PM, Robert Kukura kuk...@noironetworks.com wrote:
 [Note - I understand there are ongoing discussion that may lead to a
 proposal for an out-of-tree incubation process for new Neutron features.
 This is a complementary proposal that describes how our existing development
 process can be used to stabilize new features in-tree over the time frame of
 a release cycle or two. We should fully consider both proposals, and where
 each might apply. I hope something like the approach I propose here will
 allow the implementations of Neutron BPs with non-trivial APIs that have
 been targeted for the Juno release to be included in that release, used by
 early adopters, and stabilized as quickly as possible for general
 consumption.]


+1. I think this proposal is simple to understand, has limited process
and operational overhead while achieving the desired benefit of
handing preview features to early adopters with the right set of
expectations.

 According to our existing development process, once a blueprint and
 associated specification for a new Neutron feature have been reviewed,
 approved, and targeted to a release, development proceeds, resulting in a
 series of patches to be reviewed and merged to the Neutron source tree. This
 source tree is then the basis for milestone releases and the final release
 for the cycle.

 Ideally, this development process would conclude successfully, well in
 advance of the cycle's final release, and the resulting feature and its API
 would be considered fully stable in that release. Stable features are
 ready for widespread general deployment. Going forward, any further
 modifications to a stable API must be backwards-compatible with previously
 released versions. Upgrades must not lose any persistent state associated
 with stable features. Upgrade processes and their impact on a deployments
 (downtime, etc.) should be consistent for all stable features.

 In reality, we developers are not perfect, and minor (or more significant)
 changes may be identified as necessary or highly desirable once early
 adopters of the new feature have had a chance to use it. These changes may
 be difficult or impossible to do in a way that honors the guarantees
 associated with stable features.

 For new features that effect the core Neutron API and therefore impact all
 Neutron deployments, the stability requirement is strict. But for features
 that do not effect the core API, such as services whose deployment is
 optional, the stability requirement can be relaxed initially, allowing time
 for feedback from early adopters to be incorporated before declaring these
 APIs stable. The key in doing this is to manage the expectations of
 developers, packagers, operators, and end users regarding these new optional
 features while they stabilize.

 I therefore propose that we manage these expectations, while new optional
 features in the source tree stabilize, by clearly labeling these features
 with the term preview until they are declared stable, and sufficiently
 isolating them so that they are not confused with stable features. The
 proposed guidelines would apply during development as the patches
 implementing the feature are first merged, in the initial release containing
 the feature, and in any subsequent releases that are necessary to fully
 stabilize the feature.

 Here are my initial not-fully-baked ideas for how our current process can be
 adapted with a preview feature concept supporting in-tree stabilization of
 optional features:

 * Preview features are implementations of blueprints that have been
 reviewed, approved, and targeted for a Neutron release. The process is
 intended for features for which there is a commitment to add the feature to
 Neutron, not for experimentation where failing fast is an acceptable
 outcome.

 * Preview features must be optional to deploy, such as by configuring a
 service plugin or some set of drivers. Blueprint implementations whose
 deployment is not optional are not eligible to be treated as preview
 features.

 * Patches implementing a preview feature are merged to the the master branch
 of the Neutron source tree. This makes them immediately available to all
 direct consumers of the source tree, such as developers, trunk-chasing
 operators, packagers, and evaluators or end-users that use DevStack,
 maximizing the opportunity to get the feedback that is essential to quickly
 stabilize the feature.

 * The process for reviewing, approving and merging patches implementing
 preview features is exactly the same as for all other Neutron patches. The
 patches must meet HACKING standards, be production-quality code, have
 adequate test coverage, have DB migration scripts, etc., and require two +2s
 and a +A from Neutron core developers to merge.

 * DB migrations for preview features are treated similarly to other DB
 migrations, forming a single ordered list that results in the current
 overall DB schema, including the schema for 

Re: [openstack-dev] [Neutron][policy] Group Based Policy - Renaming

2014-08-07 Thread Sumit Naiksatam
Ryan, point well taken. I am paraphrasing the discussion from today's
GBP sub team meeting on the options considered and the eventual
proposal for policy-point and policy-group:

18:36:50 SumitNaiksatam_ so regarding the endpoint terminology
18:36:53 SumitNaiksatam_ any suggestions?
18:36:56 arosen ivar-lazzaro:  If you are expressing your intent of
doing enforcement at both points you do care then.
18:37:09 rockyg regXboi: Edgar Magana suggested using the IETF
phrasing -- enforcement point
18:37:31 mscohen i was thinking “edgar point” would be good.  and we
won’t have to change our slides from EP.
18:37:44 arosen ivar-lazzaro:  would be great to see an example
using the CLI how one sets something up that in GBP that does
enforcement at the instance and router.
18:37:44 rockyg mschoen ++
18:37:55 SumitNaiksatam_ rockyg: although enforcement point tends to
be used in a slightly different context
18:38:02 rockyg mscohen ++
18:38:04 regXboi I was involved in the early IETF policy days, and
I'm not a big from of ep
18:38:04 SumitNaiksatam_ mscohen: we dont want to overload the terminology
18:38:13 SumitNaiksatam_ regXboi: +1
18:38:17 rkukura I’m not entirely sure “enforcement point” is the
same as our usage of endpoint
18:38:25 SumitNaiksatam_ rkukura: exactly
18:38:28 mscohen SumitNaiksatam: i am joking of course
18:38:42 SumitNaiksatam_ mscohen: :-)
18:38:54 rockyg Yeah.  that's the problem with endpoint.  It's right
for networking, but it already has another definition in
virtualization world.
18:38:54 SumitNaiksatam_ how about network-endpoint (someone else
suggested that)?
18:38:55 rkukura I think enforcement point is more like the SG or
FWaaS that is used to render the intent
18:39:07 SumitNaiksatam_ rkukura: agree
18:39:09 regXboi so... let's hit the thesaurus
18:39:16 rockyg Rkukara, agree
18:39:38 rkukura I had always throught endpoint was the right word
for both our usage and for keystone, with similar meanings, but
different meta-levels
18:40:01 regXboi rkukura: if we can find something different, let's
consider it
18:40:11 regXboi there is enough of a hill to climb
18:40:35 regXboi how about terminus?
18:40:52 * regXboi keeps reading synonyms
18:41:06 rms_13 network-endpoint?
18:41:12 regXboi um... no
18:41:27 regXboi I think that won't help
18:41:58 LouisF policy-point/policy groups?
18:42:07 rkukura group member?
18:42:14 mscohen termination-point, gbp-id, policy point maybe
18:42:18 SumitNaiksatam sorry i dropped off again!
18:42:23 regXboi I think member
18:42:31 regXboi unless that's already used somewhere
18:42:33 SumitNaiksatam i was saying earlier, what about policy-point?
18:42:36 s3wong #chair SumitNaiksatam
18:42:37 openstack Current chairs: SumitNaiksatam SumitNaiksatam_
banix rkukura s3wong
18:42:41 rkukura regXboi: Just “member” and “group”?
18:42:44 SumitNaiksatam s3wong: :-)
18:43:04 s3wong SumitNaiksatam: so now either way works for you :-)
18:43:09 regXboi rkurkura: too general I think...
18:43:15 nbouthors policy-provider, policy-consumer
18:43:16 regXboi er rkukura ... sorry
18:43:17 yyywu i still like endpoint better.
18:43:23 rockyg bourn or bourne 1  (bɔːn)
18:43:23 rockyg
18:43:23 rockyg — n
18:43:23 rockyg 1.  a destination; goal
18:43:23 rockyg 2.  a boundary
18:43:25 regXboi I think policy-point and policy-group
18:43:27 SumitNaiksatam yyywu: :-)
18:43:34 rockyg Bourne-point?
18:43:40 SumitNaiksatam rockyg: :-)
18:44:04 SumitNaiksatam more in favor of policy-point and policy-group?
18:44:36 SumitNaiksatam i thnk LouisF suggested as well
18:44:49 mscohen +1 to policy-point
18:44:50 rms_13 +1 to policy-point and policy-group
18:44:55 yyywu +1
18:44:56 nbouthors SumitNaiksatam: +1 too
18:45:07 rockyg +1
18:45:08 rms_13 FINALLY... YEAH
18:45:18 SumitNaiksatam okay so how about we float this in the ML?
18:45:21 s3wong +1
18:45:31 prasadv +1
18:45:35 rms_13 Yes... lets do that
18:45:37 rkukura +1
18:45:44 SumitNaiksatam so that we dont end up picking up an
overlapping terminology again
18:45:55 SumitNaiksatam who wants to do it? as in send to the ML?
18:46:07 * SumitNaiksatam waiting to hand out an AI :-P
18:46:16 SumitNaiksatam regXboi: ?
18:46:17 rms_13 I can do it
18:46:26 regXboi hmm?
18:46:31 SumitNaiksatam rms_13: ah you put your hand up first
18:46:36 * regXboi apologies - bouncing between multiple IRC meetings
18:46:47 hemanthravi policy-endpoint ?
18:46:57 SumitNaiksatam #action rms_13 to send “policy-point”
“policy-group” suggestion to mailing list

On Thu, Aug 7, 2014 at 2:18 PM, Ryan Moats rmo...@us.ibm.com wrote:
 Edgar-

 I can't speak for anyone else, but in my mind at least (and having been
 involved in the work that led up to 3198),
 the members of the groups being discussed here are not PEPs.   As 3198
 states, being a PEP implies running COPS
 and I don't see that as necessary for membership in GBP groups.

 Ryan Moats

 Edgar Magana edgar.mag...@workday.com wrote on 08/07/2014 04:02:43 PM:

 From: Edgar Magana edgar.mag...@workday.com


 To: OpenStack 

Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and theway forward

2014-08-07 Thread Sumit Naiksatam
And while we are on this, just wanted to remind all those interested
to attend the weekly GBP meeting later today:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

On Wed, Aug 6, 2014 at 8:12 PM, Mike Cohen co...@noironetworks.com wrote:
 Its good to see such a lively debate about this topic.  With the disclaimer
 of someone who has worked on this project, I have a strong preference
 towards Option 1 as well (ie. merging it in the tree).  We’ve actually
 already heard from users on this thread who want to use this([1] and [2]),
 others who have at least expressed some interest ([3]).   Making it easier
 for them to consume it is a very much worth the effort.

 You’ll also see a strong willingness from our team to compromise on things
 like naming conventions (endpoints can certainly become something else to
 avoid confusion for example) and labels the community wants to place on this
 in terms of support (maybe a “beta” or “preview” disclaimer) so it does not
 send the wrong message to users.

 From our group’s perspective, we’re happy to see the discussion occur so
 everyone can weigh in but we also are seeking *closure* on this topic,
 especially considering we have operators asking for it and we have limited
 time to actually merge it in Juno-3.  Hopefully we can achieve this closure
 asap so we can move forward with our work (both on this project and other
 Neutron projects).

 Thanks,
 Mike

 [1]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/042036.html
 [2]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/042043.html
 [3]
 http://lists.openstack.org/pipermail/openstack-dev/2014-August/042180.html


 From: Stephen Wong stephen.kf.w...@gmail.com

 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 9:03 PM

 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the
 way forward

 Hi,

 Thanks to Armando for steering the discussion back to the original
 intent.


 On Wed, Aug 6, 2014 at 3:56 PM, Armando M. arma...@gmail.com wrote:


 On 6 August 2014 15:47, Kevin Benton blak...@gmail.com wrote:

 I think we should merge it and just prefix the API for now with
 '/your_application_will_break_after_juno_if_you_use_this/'


 And you make your call based and what pros and cons exactly, If I am ask?

 Let me start:

 Option 1:
   - pros
 - immediate delivery vehicle for consumption by operators


 Buried inside these 100+ posts are posts from two OpenStack users
 pleading for their desire to use GBP APIs for their Juno deployments. While
 that is a small sample size, it does prove that there is legitimate
 interests from our user base to get their hands on this feature.

 User feedback is the best way to evolve the APIs moving forward - as
 long as these APIs/implementation do not jeopardize the stability of
 Neutron. And as many folks in the thread had pointed out, the GBP
 implementation currently has really gone the extra mile to ensure it does
 NOT do that.



   - cons
 - code is burder from a number of standpoints (review, test, etc)


 This is a legitimate concern - that said, if you take a look at the
 first patch:

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

 there are 30 human reviewers (non-CI) signed up to review the patch at
 this time, and among them 9 Neutron core members (8 if you don't count
 Sumit, who is the author), as well as a Nova core. From the reception, I
 believe the community does not generally treat reviewing GBP related patches
 as a burden, but likely as an item of interest. Additionally, with such
 board and strong community base willing to involve in reviewing the code, I
 think with these many eyes it will hopefully help lessen the burden on
 Neutron cores to review and merge these set of patches.




 Option 2:
   - pros
 - enable a small set of Illuminati to iterate faster



 As a subgroup, we have already iterated the model and APIs for about a
 year, with around 40 IRC meetings for community discussions, a PoC demo that
 was presented to about 300 audiences back at J-Summit, and actual
 implementations in gerrit for months now. Indeed with about 35+ people
 responding to this thread, I have yet to see anyone making a claim that GBP
 model and APIs as they are now are crap, we have to scrap it and rethink. I
 would like to think that we are at a point where we will do phase by phase
 enhancements - as should practically any other APIs in OpenStack - rather
 than rapid iterations within a cycle. While we already have some user
 feedbacks, we would love to get more and more user and developer community
 feedbacks to evolve GBP to better fit their needs, and stackforge
 unfortunately does not serve that purpose well.



   - cons
 - integration burden with other OpenStack projects 

Re: [openstack-dev] [Neutron] Bug squashing day

2014-08-07 Thread Sumit Naiksatam
Indeed, thanks much Eugene for taking on this critical activity.
Please let me know if I can help in any way as well.

On Thu, Aug 7, 2014 at 7:39 AM, Kyle Mestery mest...@mestery.com wrote:
 On Thu, Aug 7, 2014 at 9:31 AM, Eugene Nikanorov
 enikano...@mirantis.com wrote:
 Hi neutron folks,

 Today should have been 'Bug squashing day' where we go over existing bugs
 filed for the project and triage/prioritize/comment on them.

 I've created an etherpad with (hopefully) full list of neutron bugs:
 https://etherpad.openstack.org/p/neutron-bug-squashing-day-2014-08-07

 I was able to walk through a couple of almost thousand of bugs we have.
 My target was to reduce the number of open bugs, so some of them I moved to
 incomplete/invalid/won't fix state (not many though); then, to reduce the
 number of high importance bugs, especially if they're hanging for too long.

 As you can see, bugs in the etherpad are sorted by importance.
 Some of my observations include:
 - almost all bugs with High priority really seem like issues we should be
 fixing.
 In many cases submitter or initial contributor abandoned his work on the
 bug...
 - there are a couple of important bugs related to DVR where previously
 working stuff
 is broken, but in all cases there are DVR subteam members working on those,
 so we're good here so far.

 I also briefly described resolution for each bug, where 'n/a' means that bug
 just needs to be fixed/work should be continued without any change to state.
 I'm planning to continue to go over this list and expect more bugs will go
 away which previously have been marked as medium/low or wishlist.

 If anyone is willing to help - you're welcome!

 Thanks for setting this up Eugene! I've been down with a nasty cold
 yesterday and still not feeling well today, I will try to be on
 #openstack-neutron off and on today. I encourage other Neutron cores
 to be there as well so we can coordinate the work and help new bugfix
 submitters.

 Thanks!
 Kyle

 Thanks,
 Eugene.



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


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

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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Tue, Aug 5, 2014 at 11:46 PM, Gary Kotton gkot...@vmware.com wrote:
 Correct, this work is orthogonal to the parity work, which I understand is
 coming along very nicely.

Agree Gary and Kevin. I think the topic of Nova integration has
created confusion in people’s mind (at least the non-Neutron folks)
with regards to what is being proposed in the Group-based Policy (GBP)
feature. So to clarify - GBP is an optional extension, like many other
existing Neutron extensions. It is not meant to replace the Neutron
core API and/or the current Nova-Neutron interaction in Juno.

 Do new features in Nova also require parity -
 https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks
 (for example enables the MTU to be configured instead of via a configuration
 variable)
 At the moment it seems like a moving target.

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack List openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 9:12 AM

 To: OpenStack List openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 Are there any parity features you are aware of that aren't receiving
 adequate developer/reviewer time? I'm not aware of any parity features that
 are in a place where throwing more engineers at them is going to speed
 anything up. Maybe Mark McClain (Nova parity leader) can provide some better
 insight here, but that is the impression I've gotten as an active Neutron
 contributor observing the ongoing parity work.

 Given that, pointing to the Nova parity work seems a bit like a red herring.
 This new API is being developed orthogonally to the existing API endpoints
 and I don't think it was ever the expectation that Nova would switch to this
 during the Juno timeframe anyway. The new API will not be used during normal
 operation and should not impact the existing API at all.


 On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague s...@dague.net wrote:

 On 08/05/2014 07:28 PM, Joe Gordon wrote:
 
 
 
  On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura kuk...@noironetworks.com
  mailto:kuk...@noironetworks.com wrote:
 
  On 8/4/14, 4:27 PM, Mark McClain wrote:
  All-
 
  tl;dr
 
  * Group Based Policy API is the kind of experimentation we be
  should attempting.
  * Experiments should be able to fail fast.
  * The master branch does not fail fast.
  * StackForge is the proper home to conduct this experiment.
  The disconnect here is that the Neutron group-based policy sub-team
  that has been implementing this feature for Juno does not see this
  work as an experiment to gather data, but rather as an important
  innovative feature to put in the hands of early adopters in Juno and
  into widespread deployment with a stable API as early as Kilo.
 
 
  The group-based policy BP approved for Juno addresses the critical
  need for a more usable, declarative, intent-based interface for
  cloud application developers and deployers, that can co-exist with
  Neutron's current networking-hardware-oriented API and work nicely
  with all existing core plugins. Additionally, we believe that this
  declarative approach is what is needed to properly integrate
  advanced services into Neutron, and will go a long way towards
  resolving the difficulties so far trying to integrate LBaaS, FWaaS,
  and VPNaaS APIs into the current Neutron model.
 
  Like any new service API in Neutron, the initial group policy API
  release will be subject to incompatible changes before being
  declared stable, and hence would be labeled experimental in
  Juno. This does not mean that it is an experiment where to fail
  fast is an acceptable outcome. The sub-team's goal is to stabilize
  the group policy API as quickly as possible,  making any needed
  changes based on early user and operator experience.
 
  The L and M cycles that Mark suggests below to revisit the status
  are a completely different time frame. By the L or M cycle, we
  should be working on a new V3 Neutron API that pulls these APIs
  together into a more cohesive core API. We will not be in a position
  to do this properly without the experience of using the proposed
  group policy extension with the V2 Neutron API in production.
 
 
  If we were failing miserably, or if serious technical issues were
  being identified with the patches, some delay might make sense. But,
  other than Mark's -2 blocking the initial patches from merging, we
  are on track to complete the planned work in Juno.
 
  -Bob
 
 
 
  As a member of nova-core, I find this whole discussion very startling.
  Putting aside the concerns over technical details and the pain of having
  in tree experimental APIs (such as nova v3 API), neutron still isn't the
  de-facto networking solution from nova's perspective and it won't be
  until neutron has feature and 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

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

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana edgar.mag...@workday.com wrote:
 This is the consequence of a proposal that is not following the standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you can see
 my comments were totally ignored:
 https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestion…

 Edgar

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I was referring to was also not Keystone's definition of an endpoint.
 It's almost as if the term has many uses and was not invented for Keystone.
 :-)

 http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

 Did a similar discussion occur when Heat wanted to use the word 'template'
 since this was clearly already in use by Horizon?

 On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

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


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


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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
Not sure what you are talking about? You claim now that you had
suggestion which was not considered, yet you +2'ed a patch, by stating
that All looks good to me!.

On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana edgar.mag...@workday.com wrote:
 That is the beauty of the open source projects, there is always a smartest
 reviewer catching out the facts that you don¹t.

 Edgar

 On 8/6/14, 10:55 AM, Sumit Naiksatam sumitnaiksa...@gmail.com wrote:

Edgar, you seemed to have +2'ed this patch on July 2nd [1]:


Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.


That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

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

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana edgar.mag...@workday.com
wrote:
 This is the consequence of a proposal that is not following the
standardized
 terminology (IETF - RFC) for any Policy-based System:
 http://tools.ietf.org/html/rfc3198

 Well, I did bring  this point during the Hong Kong Summit but as you
can see
 my comments were totally ignored:

https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIr
upCD9E/edit

 I clearly saw this kind of issues coming. Let me quote myself what I
 suggested: For instance: endpoints should be enforcement point

 I do not understand why GBP did not include this suggestionŠ

 Edgar

 From: Kevin Benton blak...@gmail.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: Wednesday, August 6, 2014 at 10:22 AM
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org

 Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
 forward

 What I was referring to was also not Keystone's definition of an
endpoint.
 It's almost as if the term has many uses and was not invented for
Keystone.
 :-)

 http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

 Did a similar discussion occur when Heat wanted to use the word
'template'
 since this was clearly already in use by Horizon?

 On Aug 6, 2014 9:24 AM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 02:12 AM, Kevin Benton wrote:

 Given that, pointing to the Nova parity work seems a bit like a red
 herring. This new API is being developed orthogonally to the existing
 API endpoints


 You see how you used the term endpoints there? :P

 -jay

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


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


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


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

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


Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:
I believe the referential security group rules solve this problem (unless
 I'm not understanding):

 I think the disconnect is that you are comparing the way to current mapping
 driver implements things for the reference implementation with the existing
 APIs. Under this light, it's not going to look like there is a point to this
 code being in Neutron since, as you said, the abstraction could happen at a
 client. However, this changes once new mapping drivers can be added that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. With the
 latter, a mapping driver could determine that communication between these
 two hosts can be prevented by using an ACL on a router or a switch, which
 doesn't violate the user's intent and buys a performance improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


Kevin, you have captured the GBP value prop and difference very
succinctly. The major difference is in the declarative (GBP) versus
imperative (current) style of programming.

This has been stated very clearly and explicitly in the blueprint
spec. If one does not appreciate the difference or advantage of one
over the other, then this discussion is pointless.

 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:

 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:

 I believe the referential security group rules solve this problem
 (unless
 I'm not understanding):


 I think the disconnect is that you are comparing the way to current
 mapping
 driver implements things for the reference implementation with the
 existing
 APIs. Under this light, it's not going to look like there is a point to
 this
 code being in Neutron since, as you said, the abstraction could happen at
 a
 client. However, this changes once new mapping drivers can be added that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks
 this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must
 support
 security groups and there is nowhere except for the firewall rules on
 that
 port to implement it without violating the user's expectation. With the
 latter, a mapping driver could determine that communication between these
 two hosts can be prevented by using an ACL on a router or a switch, which
 doesn't violate the user's intent and buys a performance improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Kevin, you have captured the GBP value prop and difference very
 succinctly. The major difference is in the declarative (GBP) versus
 imperative (current) style of programming.

 This has been stated very clearly and explicitly in the blueprint
 spec. If one does not appreciate the difference or advantage of one
 over the other, then this discussion is pointless.


 One does appreciate the value of having porcelain APIs overlay a plumbing
 API. This discussion was about the proper way and place to introduce such
 functionality.

 However, it seems to me that the end-goal of the GBP effort is *actually* to
 provide a higher-layer API to Neutron that would essentially enable
 proprietary vendors to entirely swap out all of Neutron core for a new set
 of drivers that spoke proprietary device APIs.

 If this is the end-goal, it should be stated more clearly, IMO.


The goal and design intent is unambiguously stated in the spec [1];

L36-L38
The policy framework described in this blueprint complements the current
Neutron model with the notion of policies that can be applied between
groups of endpoints.

Note the choice of words - complements. The implementation also has
been faithful to this intent.

I am not sure why you would draw the conclusion that you did.

[1] 
https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm

 The classic plumbing versus porcelain API conversation [1] is a good one,
 and one worth having in the context of Neutron.

 It's almost like some Neutron contributor folks are saying let's add a
 porcelain API so we can ditch all the existing plumbing APIs and replace
 with our own stuff. And that's not what the point of plumbing vs. porcelain
 is.

 -jay

 [1] http://git-scm.com/book/en/Git-Internals-Plumbing-and-Porcelain


 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
On Wed, Aug 6, 2014 at 1:52 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/06/2014 04:36 PM, Sumit Naiksatam wrote:

 On Wed, Aug 6, 2014 at 1:27 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 04:13 PM, Sumit Naiksatam wrote:


 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:


 I believe the referential security group rules solve this problem
 (unless
 I'm not understanding):



 I think the disconnect is that you are comparing the way to current
 mapping
 driver implements things for the reference implementation with the
 existing
 APIs. Under this light, it's not going to look like there is a point to
 this
 code being in Neutron since, as you said, the abstraction could happen
 at
 a
 client. However, this changes once new mapping drivers can be added
 that
 implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks
 this
 IP) compared to a higher level declarative abstraction (make sure
 these
 two endpoints cannot communicate). With the former, the ports must
 support
 security groups and there is nowhere except for the firewall rules on
 that
 port to implement it without violating the user's expectation. With the
 latter, a mapping driver could determine that communication between
 these
 two hosts can be prevented by using an ACL on a router or a switch,
 which
 doesn't violate the user's intent and buys a performance improvement
 and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Kevin, you have captured the GBP value prop and difference very
 succinctly. The major difference is in the declarative (GBP) versus
 imperative (current) style of programming.

 This has been stated very clearly and explicitly in the blueprint
 spec. If one does not appreciate the difference or advantage of one
 over the other, then this discussion is pointless.



 One does appreciate the value of having porcelain APIs overlay a
 plumbing
 API. This discussion was about the proper way and place to introduce such
 functionality.

 However, it seems to me that the end-goal of the GBP effort is *actually*
 to
 provide a higher-layer API to Neutron that would essentially enable
 proprietary vendors to entirely swap out all of Neutron core for a new
 set
 of drivers that spoke proprietary device APIs.

 If this is the end-goal, it should be stated more clearly, IMO.


 The goal and design intent is unambiguously stated in the spec [1];

 L36-L38
 The policy framework described in this blueprint complements the current
 Neutron model with the notion of policies that can be applied between
 groups of endpoints.

 Note the choice of words - complements. The implementation also has
 been faithful to this intent.

 I am not sure why you would draw the conclusion that you did.

 [1]
 https://review.openstack.org/#/c/89469/10/specs/juno/group-based-policy-abstraction.rst,cm


 OK, cool. Then it seems to me that would be a perfect justification for
 having this code and API live outside of the Neutron tree, then?

 In other words, what benefit does having the GBP code in the Neutron
 codebase give us?


And for that I would again request that you look at the following
stated in the blueprint spec ;-):

L43-48
This proposal suggests a model that allows application administrators to
express their networking requirements using group and policy
abstractions, with the specifics of policy enforcement and
implementation left to the underlying policy driver. The main
advantage of the extensions described in this blueprint is that they
allow for an application-centric interface to Neutron that complements
the existing network-centric interface.

L52-78 also spell out some of the details of these claims.


 -jay


 ___
 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] Fwd: FW: [Neutron] Group Based Policy and the way forward

2014-08-06 Thread Sumit Naiksatam
I would reword that to:

'/your_application_may_break_after_juno_if_you_use_this/'

in the event of the possibility that it doesn't break. ;-)

On Wed, Aug 6, 2014 at 3:47 PM, Kevin Benton blak...@gmail.com wrote:
 I think we should merge it and just prefix the API for now with
 '/your_application_will_break_after_juno_if_you_use_this/'

 On Aug 6, 2014 4:41 PM, Armando M. arma...@gmail.com wrote:

 This thread is moving so fast I can't keep up!

 The fact that troubles me is that I am unable to grasp how we move
 forward, which was the point of this thread to start with. It seems we have
 2 options:

 - We make GBP to merge as is, in the Neutron tree, with some minor
 revision (e.g. naming?);
 - We make GBP a stackforge project, that integrates with Neutron in some
 shape or form;

 Another option, might be something in between, where GBP is in tree, but
 in some sort of experimental staging area (even though I am not sure how
 well baked this idea is).

 Now, as a community we all need make a decision; arguing about the fact
 that the blueprint was approved is pointless. As a matter of fact, I think
 that blueprint should be approved, if and only if the code has landed
 completely, but I digress!

 Let's together come up with pros and cons of each approach and come up
 with an informed decision.

 Just reading free form text, how are we expected to do that? At least I
 can't!

 My 2c.
 Armando


 On 6 August 2014 15:03, Aaron Rosen aaronoro...@gmail.com wrote:




 On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton blak...@gmail.com wrote:

 I believe the referential security group rules solve this problem
  (unless I'm not understanding):

 I think the disconnect is that you are comparing the way to current
 mapping driver implements things for the reference implementation with the
 existing APIs. Under this light, it's not going to look like there is a
 point to this code being in Neutron since, as you said, the abstraction
 could happen at a client. However, this changes once new mapping drivers 
 can
 be added that implement things differently.

 Let's take the security groups example. Using the security groups API
 directly is imperative (put a firewall rule on this port that blocks this
 IP) compared to a higher level declarative abstraction (make sure these
 two endpoints cannot communicate). With the former, the ports must support
 security groups and there is nowhere except for the firewall rules on that
 port to implement it without violating the user's expectation. With the
 latter, a mapping driver could determine that communication between these
 two hosts can be prevented by using an ACL on a router or a switch, which
 doesn't violate the user's intent and buys a performance improvement and
 works with ports that don't support security groups.

 Group based policy is trying to move the requests into the declarative
 abstraction so optimizations like the one above can be made.


 Hi Kevin,

 Interesting points. Though, let me ask this. Why do we need to move to a
 declarative API abstraction in neutron in order to perform this optimization
 on the backend? For example, In the current neutron model say we want to
 create a port with a security group attached to it called web that allows
 TCP:80 in and members who are in a security group called database. From this
 mapping I fail to see how it's really any different from the declarative
 model? The ports in neutron are logical abstractions and the backend system
 could be implemented in order to determine that the communication between
 these two hosts could be prevented by using an ACL on a router or switch as
 well.

 Best,

 Aaron



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



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



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


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


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


Re: [openstack-dev] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

2014-08-06 Thread Sumit Naiksatam
I definitely agree that such cross-pollination across projects is ideal.

However, I think (and not to deviate from the general discussion on
making blueprint specs review more effective), Kevin's question was
specifically in the context of the GBP blueprint. It is not clear in
that case that a Nova reviewer would have caught the terminology
overlap. Or in other words, anyone else could have caught that, and it
did not have to be a Nova reviewer (perhaps a Keystone reviewer might
have been more perceptive).

Also the model being proposed in the GBP extensions is more
user-centrci (user being the app deployer). Nova's interaction with
Neutron is more in the consumption of the current network/port level
imperative APIs.

On Wed, Aug 6, 2014 at 5:40 PM, Richard Woo richardwoo2...@gmail.com wrote:
 I agreed with Jay. Nova is one of the consumer of Neutron project, someone
 from Nova project should participate reviewing related blueprint in neutron
 project.

 Richard


 On Wed, Aug 6, 2014 at 8:28 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/06/2014 07:54 PM, Kevin Benton wrote:

 I'm curious, how would having Nova reviewers look at this have helped?


 As I mentioned on a previous email, Nova is the pre-eminent consumer of
 Neutron's API.

 Best,
 -jay

 On Wed, Aug 6, 2014 at 5:41 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:

 On 08/06/2014 07:08 PM, CARVER, PAUL wrote:

 On Aug 6, 2014, at 2:01 PM, Mohammad Banikazemi m...@us.ibm.com
 mailto:m...@us.ibm.commailto:mb@us.__ibm.com

 mailto:m...@us.ibm.com
wrote:

 Yes, indeed.
 I do not want to be over dramatic but the discussion on the
 original Group
 Based Policy and the way forward thread is nothing short of
 heartbreaking.
 After months and months of discussions, three presentations
 at the past three
 summits, a design session at the last summit, and (most
 relevant to this
 thread) the approval of the spec, why are we talking about
 the merits of the
 work now?

 I understand if people think this is not a good idea or this
 is not a good
 time. What I do not understand is why these concerns were
 not raised clearly
 and openly earlier.


 I have to agree here. I'm not sure whether my organization needs
 GBP or not.
 It's certainly not our top priority for Neutron given a variety
 of other more
 important functional gaps. However, I saw their demo at the
 summit and it was
 clear that a lot of work had gone into it even before Icehouse.
  From the demo
 it was clearly a useful enhancement to Neutron even if it wasn't
 at the top
 of my priority list.

 For people to be asking to justify the why this far into the
 Juno cycle
 when the spec was approved and the code was demoed at the summit
 really
 brings the OpenStack process into question. It's one thing to
 discuss
 technical merits of contributions but it's totally different to
 pull the rug
 out from under a group of contributors at the last minute after
 such a long
 period of development, discussion, and demo.

 Seeing this sort of last minute rejection of a contribution
 after so much
 time has been invested in it could very easily have a chilling
 effect on
 contributors.


 I don't disagree with you, Paul.

 I blame myself for not paying the attention I should have to this
 earlier in the process.

 FWIW, I had a good conversation with Sumit and Kevin on
 #openstack-neutron this afternoon about this particular topic. We
 agree on some things; disagree on others.

 Bottom line, I go back to what I said in a previous email: the Nova
 and Neutron development teams need to do a much better job in being
 directly involved in each other's spec discussions and design
 conversations.

 Best,
 -jay


 _
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.__org
 mailto:OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev
 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



 ___
 OpenStack-dev mailing list
 

Re: [openstack-dev] [Neutron][third-party] Arista CI hits 10, 000 runs this morning

2014-08-06 Thread Sumit Naiksatam
Nice work Sukhdev, worth commending! Thanks for sharing!!

On Wed, Aug 6, 2014 at 7:06 PM, Baohua Yang yangbao...@gmail.com wrote:
 Woo~
 Really nice work!


 On Thu, Aug 7, 2014 at 7:09 AM, Sukhdev Kapur sukhdevka...@gmail.com
 wrote:

 Folks,

 Just wanted to share with you that Arista CI has been up and running 24x7
 since the beginning of this year with no down time.

 This morning it posted a vote on 10,000th Neutron patch

 cheers..
 -Sukhdev


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




 --
 Best wishes!
 Baohua

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


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


Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Sumit Naiksatam
That's right Kevin, EPG (and its association to the L2/3_Policy)
capture the attributes which would represent the network-template
being referenced here.

Jay, what Bob mentioned here was an option to use the endpoint as a
one-to-one replacement for the option of using a Neutron port. This is
more so in the context of providing an evolutionary path (from the way
Nova currently does it using a pre-defined port). However, if it makes
sense to make Nova aware of the EPG right at the outset, then that is
even better.

I have also noted your suggestion on clarifying the endpoint
terminology. This was already done in one of the patches you had
reviewed earlier, and will do that in the first patch as well (where
you pointed it out now).

Thanks,
~Sumit.

On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com wrote:
 Specifying an endpoint group would achieve the --networking-template effects
 you described. The endpoint group would have all of the security policies,
 IP allocation policies, connectivity policies, etc. already setup.


 On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com wrote:

 On 08/05/2014 01:13 PM, Robert Kukura wrote:


 On 8/5/14, 11:04 AM, Gary Kotton wrote:

 Hi,
 Is there any description of how this will be consumed by Nova. My
 concern is this code landing there.

 Hi Gary,

 Initially, an endpoint's port_id is passed to Nova using nova boot ...
 --nic port-id=port-uuid ..., requiring no changes to Nova. Later,
 slight enhancements to Nova would allow using commands such as nova
 boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
 epg-id=endpoint-group-uuid 


 Hi Bob,

 How exactly is the above a friendlier API for the main user of Neutron,
 which is Nova? I thought one of the main ideas behind the GBP stuff was to
 create a more declarative and intuitive API for users of Neutron -- i.e.
 Nova -- to use in constructing needed networking objects. The above just
 seems to me to be exchanging one low-level object (port) with another
 low-level object (endpoint or endpoint group)?

 Perhaps the disconnect is due to the term endpoint being used, which,
 everywhere else in the OpenStack universe, means something entirely
 different from GBP.

 I guess, based on my understanding of the *intent* of the GBP API, I would
 have expected an API more like:

  nova boot ... --networking-template UUID

 where --networking-template would refer to a network, subnet topology, IP
 assignment policy, collection of security groups and firewall policies that
 the tenant had established prior to booting an instance... thereby making
 the API more intuitive and less cluttered.

 Or is it that I just don't understand this new endpoint terminology?

 Best,
 -jay


 ___
 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] [Neutron] Group Based Policy and the way forward

2014-08-05 Thread Sumit Naiksatam
On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes jaypi...@gmail.com wrote:
 On 08/05/2014 04:26 PM, Stephen Wong wrote:

 Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
 integration, and the preliminary idea, as Bob alluded to, is to add
 endpoint as an option in place of Neutron port. But if we can make
 Nova EPG-aware, it would be great.


 Is anyone listening to what I'm saying? The term endpoint is obtuse and
 completely disregards the existing denotation of the word endpoint in use
 in OpenStack today.


Yes, listening, absolutely. I acknowledged your point in this thread
as well as on the review. Your suggestion on the thread seemed to be
to document this better and clarify. Is that sufficient for moving
forward, or are you thinking something else?

 So, we've gone ahead and replaced the term port in the caller interface --
 which, besides being too entirely too low-level, actually did describe what
 the object was -- to using a term endpoint that doesn't describe even
 remotely what the thing is (a template for a collection of
 networking-related policies and objects) and that already has a well-known
 definition in the OpenStack ecosystem.


Couple of things -

The endpoint, as is being used in this context, does not refer to
the template that you are referring to (if I understand you
correctly). The template in some ways is analogous to the endpoint
group (or EPG), and is defined as a collection of endpoints. Kevin,
Stephen, and I, have been alluding to that in this thread earlier.

Why endpoint? The thinking, among the people discussing this, was
that it needs to be something more abstract than the very specific
network port terminology, and something with which can associate
policies and labels/tags. I am not advocating that this is the perfect
naming convention, and I do appreciate the concern that there is
overlap with an endpoint being used in a different context elsewhere
in OpenStack. This overlap however escaped everybody's attention until
it manifested in the code and your review (after having gone through
review in two design summit sessions and being in discussion over
several months).

 That is my point. That is why I brought up the comment on the original patch
 in the series that some docstrings would be helpful for those not entirely
 subscribed to the Tenets of National Dvorkinism.

 These interfaces should speak plain old concepts, not networking guru
 arcanum.

 Best,
 -jay

 On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
 sumitnaiksa...@gmail.com mailto:sumitnaiksa...@gmail.com wrote:

 That's right Kevin, EPG (and its association to the L2/3_Policy)
 capture the attributes which would represent the network-template
 being referenced here.

 Jay, what Bob mentioned here was an option to use the endpoint as a
 one-to-one replacement for the option of using a Neutron port. This is
 more so in the context of providing an evolutionary path (from the way
 Nova currently does it using a pre-defined port). However, if it makes
 sense to make Nova aware of the EPG right at the outset, then that is
 even better.

 I have also noted your suggestion on clarifying the endpoint
 terminology. This was already done in one of the patches you had
 reviewed earlier, and will do that in the first patch as well (where
 you pointed it out now).

 Thanks,
 ~Sumit.

 On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton blak...@gmail.com
 mailto:blak...@gmail.com wrote:
   Specifying an endpoint group would achieve the
 --networking-template effects
   you described. The endpoint group would have all of the security
 policies,
   IP allocation policies, connectivity policies, etc. already setup.
  
  
   On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes jaypi...@gmail.com
 mailto:jaypi...@gmail.com wrote:
  
   On 08/05/2014 01:13 PM, Robert Kukura wrote:
  
  
   On 8/5/14, 11:04 AM, Gary Kotton wrote:
  
   Hi,
   Is there any description of how this will be consumed by Nova.
 My
   concern is this code landing there.
  
   Hi Gary,
  
   Initially, an endpoint's port_id is passed to Nova using nova
 boot ...
   --nic port-id=port-uuid ..., requiring no changes to Nova.
 Later,
   slight enhancements to Nova would allow using commands such as
 nova
   boot ... --nic ep-id=endpoint-uuid ... or nova boot ... --nic
   epg-id=endpoint-group-uuid 
  
  
   Hi Bob,
  
   How exactly is the above a friendlier API for the main user of
 Neutron,
   which is Nova? I thought one of the main ideas behind the GBP
 stuff was to
   create a more declarative and intuitive API for users of Neutron
 -- i.e.
   Nova -- to use in constructing needed networking objects. The
 above just
   seems to me to be exchanging one low-level object (port) with
 another
   low-level

[openstack-dev] [Neutron][policy] Long standing -2 on Group-based policy patch

2014-08-04 Thread Sumit Naiksatam
The first patch[1] of this high priority approved blueprint[2][3]
targeted for Juno-3 has been blocked by a core reviewer’s (Mark
McClain) -2 since July 2nd. This patch was at patch-set 13 then, and
has been repeatedly reviewed and updated to the current patch-set 22.
However, there has been no comment or reason forthcoming from the
reviewer on why the -2 still persists. The dependent patches have also
gone through numerous iterations since.

There is a team of several people working on this feature across
different OpenStack projects since Oct 2013. The feature has been
discussed and iterated over weekly IRC meetings[4], design sessions
spanning two summits, mailing list threads, a working PoC
implementation, and a code sprint. Blocking the first patch required
for this feature jeopardizes this year-long effort and the delivery of
this feature in Juno. For many, this may sound like an all too
familiar story[5], and hence this team would like to mitigate the
issue while there is still time.

Mark, can you please explain why your -2 still persists? If there are
no major outstanding issues, can you please remove the -2?

Neutron-PTL, can you please provide guidance on how we can make
progress on this feature?

For the benefit of anyone not familiar with this feature, please see [6].

Thanks,
Group-based Policy Team.

[1] https://review.openstack.org/#/c/95900/
[2] 
https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
[3] https://review.openstack.org/#/c/95900
[4] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
[5] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041651.html
[6] https://wiki.openstack.org/wiki/Neutron/GroupPolicy

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


[openstack-dev] [Neutron][policy] Group-based Policy weekly meeting invite and agenda

2014-07-31 Thread Sumit Naiksatam
Greetings! This is a reminder for the weekly IRC Sub-team meeting
occurring on Thursdays at 1800 UTC on #openstack-meeting-3 [1].

Tomorrow's agenda is posted here:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014

In particular, we propose to focus on two items:

* A long standing -2 on the first patch [2].

* Suggestion for a profiled API [3].

Hope you can join us.

Thanks,
~Sumit (on behalf of Neutron GBP team).

[1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
[2] https://review.openstack.org/#/c/95900
[3] http://lists.openstack.org/pipermail/openstack-dev/2014-July/041566.html

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


Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap in group policy

2014-07-31 Thread Sumit Naiksatam
Thanks Kevin and others for the input here. We have put this on
today's Group Policy IRC meeting agenda:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy#July_31st.2C_2014

On Wed, Jul 30, 2014 at 11:59 PM, Kevin Benton blak...@gmail.com wrote:
 I agree. Ryan, can you propose a patch based off of the existing group
 policy work so we can get an idea of what changes are required to implement
 this level of abstraction?

 It sounds like this is work that can be built entirely on top of the
 existing abstractions and APIs offered by the current GBP work. If that's
 the case, it could be contained in the CLI or possibly introduced in another
 extension if it requires too much complexity in the client.

 Cheers,
 --
 Kevin Benton

 On Jul 30, 2014 12:25 PM, Mandeep Dhami dh...@noironetworks.com wrote:

 Hi Ryan:

 As I stated in the patch review, the suggestion to use a profiled API
 like IETF/CCITT is indeed very interesting. As a profiled API has not been
 tried with any neutron model before, and as there is no existing design
 pattern/best practices for how best to structure that, my recommendation is
 to create a new patch (dependent on this patch) to try that experiment.

 That patch will also clarify what is meant you mean by a profiled API
 and how that might interact with other openstack services like Heat and
 Horizon.

 Regards,
 Mandeep
 -



 On Wed, Jul 30, 2014 at 11:13 AM, Hemanth Ravi hemanthrav...@gmail.com
 wrote:

 Hi,

 Adding this CLI command seems to be a good way to provide support for the
 second model. This can be submitted as a new review patch to work through
 the approaches to implement this. I suggest the current CLI patch [1] be
 reviewed for the existing spec and completed.

 Ryan, would it possible for you to start a new review submit for the new
 command(s). Could you also provide any references for profiled API in
 IETF, CCITT.

 Thanks,
 -hemanth

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


 On Tue, Jul 29, 2014 at 3:16 PM, Ryan Moats rmo...@us.ibm.com wrote:

 As promised in Monday's Neutron IRC minutes [1], this mail is a trip
 down memory lane looking at the history of the
 Neutron GP project..  The original GP google doc [2] included specifying
 policy via both a produce/consume 1-group
 approach and as a link between two groups.  There was an email thread
 [3] that discussed the relationship between
 these models early on, but that discussion petered out and during a
 later IRC meeting [4] the concept of contracts
 were added, but without changing the basic use case requirements from
 the original document.  A followup meeting [5]
 began the discussion of how to express the original model from the
 contract data model but that discussion doesn't
 appear to have been completed either.  The PoC in Atlanta raised a set
 of issues [6],[7] around the complexity of the
 resulting PoC code.

 The good news is that having looked through the proposed GP code commits
 (links to which can be found at [8) I
 believe that folks that want to be able to specify policies via the
 2-group approach (and yes, I'm one of them) can have
 that without changing the model encoded in those commits. Rather, it can
 be done via the WiP CLI code commit by
 providing a profiled API - this is a technique used by the IETF,
 CCITT, etc. to allow a rich API to be consumed in
 common ways.  In this case, what I'm envisioning is something like

 neutron policy-apply [policy rule] [src group] [destination group]

 in this case, the CLI would perform the contract creation for the policy
 rule, and assigning the proper produce/consume
 edits to the specified source and destination groups.  Note:  this is in
 addition to the CLI providing direct access to the
 underlying data model.  I believe that this is the simplest way to
 bridge the gap and provide support to folks who want
 to specify policy as something between two groups.

 Ryan Moats (regXboi)

 References:
 [1]
 http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-07-28-21.02.log.txt
 [2]
 https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#
 [3]
 http://lists.openstack.org/pipermail/openstack-dev/2013-December/022150.html
 [4]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-02-27-19.00.log.html
 [5]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-03-20-19.00.log.html
 [6]
 http://lists.openstack.org/pipermail/openstack-dev/2014-May/035661.html
 [7]
 http://eavesdrop.openstack.org/meetings/networking_policy/2014/networking_policy.2014-05-22-18.01.log.html
 [8] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy


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



 ___
 OpenStack-dev mailing list
 

Re: [openstack-dev] [Neutron][policy] Group-based Policy code sprint

2014-07-29 Thread Sumit Naiksatam
The code sprint was pretty productive and attended by current and new members:
https://wiki.openstack.org/wiki/Neutron/GroupPolicy/JunoCodeSprint

We were able to fix some of our DB migration issues, and also make
significant progress with the API intercept discussion.

The following is a status report:

1. Code for GBP API with reference implementation
Majority of the code has been in review for a while now, and we are
iterating with the reviewers. The code has been split up into multiple
patches and the series starts here:
https://review.openstack.org/#/c/95900

More information on the patch series can be found here:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy/Patches

Team of several people has worked, or are working on this.

2. Client/CLI for GBP
The Client/CLI for the first series (EP, EPG, L2P, L3P) is available.
The CLI catering to the resources in the other two series will be
posted shortly.

Subra Ongole is working on this.

3. Tempest tests for GBP API
The API tests for the first series are posted. Those for the other two
series are in the works along with the scenario tests.

Miguel and Sumit are working on this.

4. Horizon
This also seems to be under control. Ronak and Abishek are working on this.

5. Vendor Driver implementation
Six different drivers are in the works. We spent a good part of the
code sprint in discussing the vendor drivers. It seems that these
drivers will be able to leverage the Implicit and (parts of) the
Resource Mapping Drivers. They will also use existing libraries from
their monolithic plugins or ML2 drivers for connectivity to their
backends. This will reduce the code need to be written for these
drivers.

6. API Intercept
This allows for better integration with Nova. Kevin Benton is working on this.

6. Docs for GBP API
Sumit will start soon.

7. Devstack
No changes will most likely be required here.

If you like to participate in the future in this work stream, please
join the weekly IRC meetings:
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

and checkout the team wiki:
https://wiki.openstack.org/wiki/Neutron/GroupPolicy

Thanks,
~Sumit (on behalf of GBP team).

On Tue, Jul 15, 2014 at 12:33 PM, Sumit Naiksatam
sumitnaiksa...@gmail.com wrote:
 Hi All,

 The Group Policy team is planning to meet on July 24th to focus on
 making progress with the pending items for Juno, and also to
 facilitate the vendor drivers. The specific agenda will be posted on
 the Group Policy wiki:
 https://wiki.openstack.org/wiki/Neutron/GroupPolicy

 Prasad Vellanki from One Convergence has graciously offered to host
 this for those planning to attend in person in the bay area:
 Address:
 2290 N First Street
 Suite # 304
 San Jose, CA 95131

 Time: 9.30 AM

 For those not being able to attend in person, we will post remote
 attendance details on the above Group Policy wiki.

 Thanks for your participation.

 ~Sumit.

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


Re: [openstack-dev] will juno support IPSet ?

2014-07-28 Thread Sumit Naiksatam
There is an approved blueprint spec for this:
http://docs-draft.openstack.org/24/101124/12/check/gate-neutron-specs-docs/d7bacf5/doc/build/html/specs/juno/add-ipset-to-security.html

On Mon, Jul 28, 2014 at 10:44 PM, Israel Ziv israel@huawei.com wrote:
 Hi!
 I wonder if it is planned to support IPSet (dynamically update iptables rules 
 against IP addresses or ports without performance penalty) in next openstack 
 (juno) release?
 Thanks
 Israel ZIv

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

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


Re: [openstack-dev] [Neutron] Group-based Policy code sprint

2014-07-17 Thread Sumit Naiksatam
Just sending me a unicast reply that you are coming should be good.

Thanks for your interest.

Sumit.
On Jul 17, 2014 12:26 PM, Kevin Benton blak...@gmail.com wrote:

 Is there somewhere we should RSVP to this?


 On Tue, Jul 15, 2014 at 12:33 PM, Sumit Naiksatam 
 sumitnaiksa...@gmail.com wrote:

 Hi All,

 The Group Policy team is planning to meet on July 24th to focus on
 making progress with the pending items for Juno, and also to
 facilitate the vendor drivers. The specific agenda will be posted on
 the Group Policy wiki:
 https://wiki.openstack.org/wiki/Neutron/GroupPolicy

 Prasad Vellanki from One Convergence has graciously offered to host
 this for those planning to attend in person in the bay area:
 Address:
 2290 N First Street
 Suite # 304
 San Jose, CA 95131

 Time: 9.30 AM

 For those not being able to attend in person, we will post remote
 attendance details on the above Group Policy wiki.

 Thanks for your participation.

 ~Sumit.

 ___
 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] [Neutron] Flavor framework proposal

2014-07-16 Thread Sumit Naiksatam
To the earlier question on whether we had defined what we wanted to
solve with the flavors framework, a high level requirement was
captured in the following approved spec for advanced services:
https://review.openstack.org/#/c/92200

On Wed, Jul 16, 2014 at 5:18 AM, Eugene Nikanorov
enikano...@mirantis.com wrote:
 Some comments inline:


 Agreed-- I think we need to more fully flesh out how extension list / tags
 should work here before we implement it. But this doesn't prevent us from
 rolling forward with a version 1 of flavors so that we can start to use
 some of the benefits of having flavors (like the ability to use multiple
 service profiles with a single driver/provider, or multiple service profiles
 for a single kind of service).

 Agree here.



 Yes, I think there are many benefits we can get out of the flavor
 framework without having to have an extensions list / tags at this revision.
 But I'm curious: Did we ever define what we were actually trying to solve
 with flavors?  Maybe that's the reason the discussion on this has been all
 of the place: People are probably making assumptions about the problem we're
 trying to solve and we need to get on the same page about this.


 Yes, we did!
  The original problem has several aspects aspects:
 1) providing users with some information about what service implementation
 they get (capabilities)
 2) providing users with ability to specify (choose, actually) some
 implementation details that don't relate to a logical configuration
 (capacity, insertion mode, HA mode, resiliency, security standards, etc)
 3) providing operators a way to setup different modes of one driver
 4) providing operators to seamlessly change drivers backing up existing
 logical configurations (now it's not so easy to do because logical config is
 tightly coupled with provider/driver)

 The proposal we're discussing right is mostly covering points (2), (3) and
 (4) which is already a good thing.
 So for now I'd propose to put 'information about service implementation' in
 the description to cover (1)

 I'm currently implementing the proposal (API and DB parts, no integration
 with services yet)


 Thanks,
 Eugene.

 ___
 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] [Neutron] Group-based Policy code sprint

2014-07-15 Thread Sumit Naiksatam
Hi All,

The Group Policy team is planning to meet on July 24th to focus on
making progress with the pending items for Juno, and also to
facilitate the vendor drivers. The specific agenda will be posted on
the Group Policy wiki:
https://wiki.openstack.org/wiki/Neutron/GroupPolicy

Prasad Vellanki from One Convergence has graciously offered to host
this for those planning to attend in person in the bay area:
Address:
2290 N First Street
Suite # 304
San Jose, CA 95131

Time: 9.30 AM

For those not being able to attend in person, we will post remote
attendance details on the above Group Policy wiki.

Thanks for your participation.

~Sumit.

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


Re: [openstack-dev] [congress] mid-cycle policy summit

2014-07-11 Thread Sumit Naiksatam
Thanks for initiating this discussion. We would be happy to
participate and host this at the Cisco office as well if need be.

~Sumit.

On Fri, Jul 11, 2014 at 12:32 PM, Sean Roberts seanrobert...@gmail.com wrote:
 I need feedback from the congress team on which two days works for you.

 11-12 September
 18-19 September


 ~sean

 On Jul 10, 2014, at 5:56 PM, Sean Roberts seanrobert...@gmail.com wrote:

 I'm thinking location as yahoo Sunnyvale or VMware Palo Alto.

 ~sean

 On Jul 10, 2014, at 5:12 PM, sean roberts seanrobert...@gmail.com wrote:

 The Congress team would like to get us policy people together to discuss how
 each project is approaching policy and our common future prior to the Paris
 summit. More details about the Congress can be found here
 https://wiki.openstack.org/wiki/Congress.

 I have discussed the idea with mestery and mikal, but I wanted to include as
 many other projects as possible.

 I propose this agenda

 first day each project talks about their policy approach
 second day whiteboarding and discussion about integrating our policy
 approaches

 I propose a few dates

 11-12 September
 18-19 September

 ~Sean Roberts


 ___
 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] DVR and FWaaS integration

2014-07-07 Thread Sumit Naiksatam
To level set, the FWaaS model was (intentionally) made agnostic of
whether the firewall was being subject to the E-W or N-S traffic (or
both). The possibility of having to use a different
strategy/implementation to handle the two sets of traffic differently,
is an artifact of the backend implementation (and DVR in this case). I
am not sure that the FWaaS user needs to be aware of this distinction.
Admittedly, this makes the implementation of FWaaS harder on the DVR
reference implementation.

This incompatibility issue between FWaaS and DVR was raised several
times in the past, but unfortunately we don't have a clean technical
solution yet. I am suspecting that this issue will manifest for any
service (NAT/VPNaaS?) that was leveraging the connection tracking
feature of iptables in the past.

The FWaaS team has also been trying to devise a solution for this
(this is a standing item on our weekly IRC meetings), but we would
need more help from the DVR team on this (I believe that was the
original plan in talking to Swami/Vivek/team).

Would it be possible for the relevant folks from the DVR team to
attend the FWaaS meeting on Wednesday [1] to facilitate a dedicated
discussion on this topic? That way it might be possible to get more
input from the FWaaS team on this.

Thanks,
~Sumit.

[1] https://wiki.openstack.org/wiki/Meetings/FWaaS


On Fri, Jul 4, 2014 at 12:23 AM, Narasimhan, Vivekanandan
vivekanandan.narasim...@hp.com wrote:
 Hi Yi,



 Swami will be available from this week.



 Will it be possible for you to join the regular DVR Meeting (Wed 8AM PST)
 next week and we can slot that to discuss this.



 I see that FwaaS is of much value for E/W traffic (which has challenges),
 but for me it looks easier to implement the same in N/S with the

 current DVR architecture, but there might be less takers on that.



 --

 Thanks,



 Vivek





 From: Yi Sun [mailto:beyo...@gmail.com]
 Sent: Thursday, July 03, 2014 11:50 AM
 To: openstack-dev@lists.openstack.org
 Subject: Re: [openstack-dev] DVR and FWaaS integration



 The NS FW will be on a centralized node for sure. For the DVR + FWaaS
 solution is really for EW traffic. If you are interested on the topic,
 please propose your preferred meeting time and join the meeting so that we
 can discuss about it.

 Yi

 On 7/2/14, 7:05 PM, joehuang wrote:

 Hello,



 It’s hard to integrate DVR and FWaaS. My proposal is to split the FWaaS into
 two parts: one part is for east-west FWaaS, this part could be done on DVR
 side, and make it become distributed manner. The other part is for
 north-south part, this part could be done on Network Node side, that means
 work in central manner. After the split, north-south FWaaS could be
 implemented by software or hardware, meanwhile, east-west FWaaS is better to
 implemented by software with its distribution nature.



 Chaoyi Huang ( Joe Huang )

 OpenStack Solution Architect

 IT Product Line

 Tel: 0086 755-28423202 Cell: 0086 158 118 117 96 Email: joehu...@huawei.com

 Huawei Area B2-3-D018S Bantian, Longgang District,Shenzhen 518129, P.R.China



 发件人: Yi Sun [mailto:beyo...@gmail.com]
 发送时间: 2014年7月3日 4:42
 收件人: OpenStack Development Mailing List (not for usage questions)
 抄送: Kyle Mestery (kmestery); Rajeev; Gary Duan; Carl (OpenStack Neutron)
 主题: Re: [openstack-dev] DVR and FWaaS integration



 All,

 After talk to Carl and FWaaS team , Both sides suggested to call a meeting
 to discuss about this topic in deeper detail. I heard that Swami is
 traveling this week. So I guess the earliest time we can have a meeting is
 sometime next week. I will be out of town on monday, so any day after Monday
 should work for me. We can do either IRC, google hang out, GMT or even a
 face to face.

 For anyone interested, please propose your preferred time.

 Thanks

 Yi



 On Sun, Jun 29, 2014 at 12:43 PM, Carl Baldwin c...@ecbaldwin.net wrote:

 In line...

 On Jun 25, 2014 2:02 PM, Yi Sun beyo...@gmail.com wrote:

 All,
 During last summit, we were talking about the integration issues between
 DVR and FWaaS. After the summit, I had one IRC meeting with DVR team. But
 after that meeting I was tight up with my work and did not get time to
 continue to follow up the issue. To not slow down the discussion, I'm
 forwarding out the email that I sent out as the follow up to the IRC meeting
 here, so that whoever may be interested on the topic can continue to discuss
 about it.

 First some background about the issue:
 In the normal case, FW and router are running together inside the same box
 so that FW can get route and NAT information from the router component. And
 in order to have FW to function correctly, FW needs to see the both
 directions of the traffic.
 DVR is designed in an asymmetric way that each DVR only sees one leg of
 the traffic. If we build FW on top of DVR, then FW functionality will be
 broken. We need to find a good method to have FW to work with DVR.

 ---forwarding email---
  During the IRC meeting, we think 

[openstack-dev] [neutron] Specs repo

2014-07-03 Thread Sumit Naiksatam
Is this still the right repo for this:
https://github.com/openstack/neutron-specs

The latest commit on the master branch shows June 25th timestamp, but
we have had a lots of patches merging after that. Where are those
going?

Thanks,
~Sumit.

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


Re: [openstack-dev] [Neutron] [FWaaS] [sequritygroup] [Development]

2014-06-16 Thread Sumit Naiksatam
Inline...

~Sumit.

On Sun, Jun 15, 2014 at 9:25 AM, Salvatore Orlando sorla...@nicira.com wrote:
 Hi Israel,

 please find my answers inline.
 I'm not really an expert in this area, but I hope these answers are helpful,
 and, hopefully, correct!

 Salvatore


 On 15 June 2014 14:55, Israel Ziv israel@huawei.com wrote:

 Hi!

 Please let me know if I’ve reached the proper group.

 I am going through neutron’s code and have a few questions.



 1.   I understood that

 a.   ‘securitygroups’ enables intra-subnet “firewall” and is aimed to
 allow/deny traffic between tenants.

 This is kind of correct. However, rather than intra-subnet I would say
 that the firewall rules are enforced at the port level - and they're
 obviously not just for allowing or deny traffic among tenants, as they allow
 to express a wide variety of rules.
 Another thing to note is that security group rules' action always is ALLOW -
 and they're enforced on a baseline default DENY ALL policy

 b.  ‘FWaaS’ enables inter-subnet “firewall” and is aimed to allow/deny
 traffic within tenant.

 This is correct too, but as before I would point out that the real
 difference is that these rules are enforced at the router level. Also the
 nature of the rule is different as the associated actions can be either
 ALLOW or DENY.


Also, the fact the FWaaS rules are applied on the Neutron router is an
artifact of the reference implementation. The FWaaS model itself is
independent of where/how the firewall/rules are realized.

 c.   Did I understand correctly?

 2.   Does a securitygroup rule generation have effect on the perimeter
 firewall of the cloud?

 If by perimeter you mean the 'edge' of cloud, ie: where your router's
 gateway ports are plugged, then I would say no. However, I don't remember
 whether security group rules are enforced on external networks as well; and
 also I'm not sure security groups are the right abstraction in that case.




 Regards

 Israel Ziv


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



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


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


Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

2014-06-12 Thread Sumit Naiksatam
Hi Carlos,

I noticed that the point you raised here had not been followed up. So
if I understand correctly, your concern is related to sharing common
configuration information between GP drivers, and ML2 mechanism
drivers (when used in the mapping)? If so, would a common
configuration file  shared between the two drivers help to address
this?

Thanks,
~Sumit.

On Tue, May 27, 2014 at 10:33 AM, Carlos Gonçalves m...@cgoncalves.pt wrote:
 Hi,

 On 27 May 2014, at 15:55, Mohammad Banikazemi m...@us.ibm.com wrote:

 GP like any other Neutron extension can have different implementations. Our
 idea has been to have the GP code organized similar to how ML2 and mechanism
 drivers are organized, with the possibility of having different drivers for
 realizing the GP API. One such driver (analogous to an ML2 mechanism driver
 I would say) is the mapping driver that was implemented for the PoC. I
 certainly do not see it as the only implementation. The mapping driver is
 just the driver we used for our PoC implementation in order to gain
 experience in developing such a driver. Hope this clarifies things a bit.


 The code organisation adopted to implement the PoC for the GP is indeed very
 similar to the one ML2 is using. There is one aspect I think GP will hit
 soon if it continues to follow with its current code base where multiple
 (policy) drivers will be available, and as Mohammad putted it as being
 analogous to an ML2 mech driver, but are independent from ML2’s. I’m
 unaware, however, if the following problem has already been brought to
 discussion or not.

 From here I see the GP effort going, besides from some code refactoring, I'd
 say expanding the supported policy drivers is the next goal. With that ODL
 support might next. Now, administrators enabling GP ODL support will have to
 configure ODL data twice (host, user, password) in case they’re using ODL as
 a ML2 mech driver too, because policy drivers share no information between
 ML2 ones. This can become more troublesome if ML2 is configured to load
 multiple mech drivers.

 With that said, if it makes any sense, a different implementation should be
 considered. One that somehow allows mech drivers living in ML2 umbrella to
 be extended; BP [1] [2] may be a first step towards that end, I’m guessing.

 Thanks,
 Carlos Gonçalves

 [1]
 https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions
 [2] https://review.openstack.org/#/c/89208/


 ___
 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


  1   2   >