Re: [openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork core

[Mohammad Banikazemi]

+1
Vikas has been working on various aspects of Kuryr with dedication for some
time. So yes it's about time :)

Best,

Mohammad




From:   Antoni Segura Puimedon 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   08/16/2016 05:55 PM
Subject:[openstack-dev] [Kuryr] Proposing vikasc for kuryr-libnetwork
core



Hi Kuryrs,

I would like to propose Vikas Choudhary for the core team for the
kuryr-libnetwork subproject. Vikas has kept submitting patches and reviews
at a very good rhythm in the past cycle and I believe he will help a lot to
move kuryr forward.

I would also like to propose him for the core team for the kuryr-kubernetes
subproject since he has experience in the day to day work with kubernetes
and can help with the review and refactoring of the prototype upstreaming.

Regards,

Antoni Segura Puimedon
__
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] [kuryr] kuryr-libnetwork split

[Mohammad Banikazemi]

Did this resolve the problem? https://review.openstack.org/#/c/336549/



From:   Vikas Choudhary <choudharyvika...@gmail.com>
To: Antoni Segura Puimedon <toni+openstac...@midokura.com>
Cc: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>, Mohammad
Banikazemi/Watson/IBM@IBMUS, Gal Sagie <gal.sa...@gmail.com>,
Irena Berezovsky <ir...@midokura.com>
Date:   07/01/2016 11:29 AM
Subject:Re: [kuryr] kuryr-libnetwork split



Hi Toni,

There seems to be some problem with. I cloned kuryr-libnetwork:
  git clone http://github.com/openstack/kuryr-libnetwork.git

But when pushed patch, on gerrit its showing project "openstack/kuryr"

PTAL, https://review.openstack.org/#/c/336617/



-Vikas

On Fri, Jul 1, 2016 at 6:40 PM, Antoni Segura Puimedon  wrote:
  Hi fellow kuryrs!

  In order to proceed with the split of kuryr into a main lib and it's
  kuryr libnetwork component, we've cloned the contents of openstack/kuryr
  over to openstack/kuryr-libnetwork.

  The idea is that after this, the patches that will go to openstack/kuryr
  will be to trim out the kuryr/kuryr-libnetwork specific parts and make a
  release of the common parts so that openstack/kuryr-libnetwork can start
  using it.

  I propose that we use python namespaces and the current common code in
  kuryr is moved to:
  kuryr/lib/


  which openstack/kuryr-libnetwork would import like so:

      from kuryr.lib import binding

  So, right now, patches in review that are for the Docker ipam or remote
  driver, should be moved to openstack/kuryr-libnetwork and soon we should
  make openstack/kuryr-libnetwork add kuryr-lib to the requirements.

  Regards,

  Toni

__
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] [Kuryr] [Neutron] Waiting until Neutron Port isActive

[Mohammad Banikazemi]

Hi Neil,

Currently, when a docker libnetwork "join" operation in Kuryr is returned,
it is not guaranteed that the network connectivity has been established.
There are containers that check for network connectivity as the first thing
they do when they come up and under heavy load some notice there is no
connectivity and simply bail out. I am trying to deal with such a use case,

Thanks for pointing out that option 2 won't work for you. I think Salvatore
also alluded to that in his response. What you are suggesting with pinging
the container from the appropriate namespace may be worth a try but then
there may be containers that do not allow ingress traffic while they are up
and happy. So short of what Salvatore suggested in his earlier email (and I
am not sure if that can be done without additions to Neutron), we are left
with option 1.

Keep in mind that users can choose not to enable the blocking option and
things will be as they are right now. Would that be reasonable?

Best,

Mohammad



From:   Neil Jerram <n...@tigera.io>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   06/10/2016 09:25 AM
Subject:Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron
Port is Active



Hi Mohammad,

Why is the blocking needed?  Is it to report some kind of status back to
Docker/Kubernetes, or to allow some follow-on action to happen?

When using networking-calico as the driver, I think that only option (1)
would work, out of the options you've suggested below.  (3) doesn't work,
as you say, because Calico doesn't involve an L2 agent.  Also Calico
doesn't use the RPC message queue for reporting port status, because we've
found that that message queue is in itself a scalability bottleneck.

I guess another option would be for the using system to determine for
itself when the port appears to be working, e.g. by the host pinging the
container/pod's IP address.

Regards,
    Neil


On Wed, Jun 8, 2016 at 4:23 PM Mohammad Banikazemi <m...@us.ibm.com> wrote:
  For the Kuryr project, in order to support blocking until vifs are
  plugged in (that is adding config options similar to the following
  options define in Nova: vif_plugging_is_fatal and vif_plugging_timeout),
  we need to detect that the Neutron plugin being used is done with
  plugging a given vif.

  Here are a few options:

  1- The simplest approach seems to be polling for the status of the
  Neutron port to become Active. (This may lead to scalability issues but
  short of having a specific goal for scalability, it is not clear that
  will be the case.)
  2- Alternatively, We could subscribe to the message queue and wait for
  such a port update event.
  3- It was also suggested that we could use l2 agent extension to detect
  such an event but that seems to limit us to certain Neutron plugins and
  therefore not acceptable.

  I was wondering if there are other and better options.

  Best,

  Mohammad
  __

  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] [Kuryr] [Neutron] Waiting until Neutron Port isActive

[Mohammad Banikazemi]

When you write "Neutron has the ability already of sending an event as a
REST call to notify a third party", that third party can be Nova only as of
now and notifying any other party requires changes to Neutron. It seems
that one needs to add a notifier for Kuryr similar to the one that exists
for Nova that you have pointed to here: [1]. Furthermore, Nuetron needs to
be changed to call this new notifier. I suppose one can make the current
Nova notifier more generic and have the third party (the client to use for
notifying the third party) configurable.
Have I understood this correctly or there is such a generic framework
already in place?

Best,

Mohammad



From:   Salvatore Orlando <salv.orla...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   06/08/2016 01:06 PM
Subject:Re: [openstack-dev] [Kuryr] [Neutron] Waiting until Neutron
Port is Active



Neutron has the ability already of sending an event as a REST call to
notify a third party that a port became active [1]
This is used by Nova to hold on booting instances until network has been
wired.
Perhaps kuryr could leverage this without having to tap into the AMQP bus,
as that would be implementation-specific - since there would be an
assumption about having a plugin that communicates with the reference impl
l2 agent.

Salvatore

[1]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/notifiers/nova.py



On 8 June 2016 at 17:23, Mohammad Banikazemi <m...@us.ibm.com> wrote:
  For the Kuryr project, in order to support blocking until vifs are
  plugged in (that is adding config options similar to the following
  options define in Nova: vif_plugging_is_fatal and vif_plugging_timeout),
  we need to detect that the Neutron plugin being used is done with
  plugging a given vif.

  Here are a few options:

  1- The simplest approach seems to be polling for the status of the
  Neutron port to become Active. (This may lead to scalability issues but
  short of having a specific goal for scalability, it is not clear that
  will be the case.)
  2- Alternatively, We could subscribe to the message queue and wait for
  such a port update event.
  3- It was also suggested that we could use l2 agent extension to detect
  such an event but that seems to limit us to certain Neutron plugins and
  therefore not acceptable.

  I was wondering if there are other and better options.

  Best,

  Mohammad

  __

  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-dev] [Kuryr] [Neutron] Waiting until Neutron Port is Active

[Mohammad Banikazemi]

For the Kuryr project, in order to support blocking until vifs are plugged
in (that is adding config options similar to the following options define
in Nova: vif_plugging_is_fatal and vif_plugging_timeout), we need to detect
that the Neutron plugin being used is done with plugging a given vif.

Here are a few options:

1- The simplest approach seems to be polling for the status of the Neutron
port to become Active. (This may lead to scalability issues but short of
having a specific goal for scalability, it is not clear that will be the
case.)
2- Alternatively, We could subscribe to the message queue and wait for such
a port update event.
3- It was also suggested that we could use l2 agent extension to detect
such an event but that seems to limit us to certain Neutron plugins and
therefore not acceptable.

I was wondering if there are other and better options.

Best,

Mohammad
__
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] [kuryr] Port binding query

[Mohammad Banikazemi]

Yes, we want to use the same naming conventions when possible.
Submitted a fix here: https://review.openstack.org/#/c/315799/

Best,

Mohammad




From:   Antoni Segura Puimedon <toni+openstac...@midokura.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Cc:     Mohammad Banikazemi/Watson/IBM@IBMUS
Date:   05/12/2016 11:51 AM
Subject:Re: [openstack-dev] [kuryr] Port binding query





On Thu, May 12, 2016 at 4:50 PM, Neil Jerram <n...@tigera.io> wrote:
  I'm trying Kuryr with networking-calico and think I've hit an unhelpful
  inconsistency. A Neutron port has 'id' and 'device_id' fields that are
  usually different. When Nova does VIF binding for a Neutron port, it
  generates the Linux device name from 'tap' + port['id']. But when Kuryr
  does VIF binding for a Neutron port, I think it generates the Linux
  device name from 'tap' + port['device_id'].

  Thoughts? Does that sound right, or have I misread the code and my logs?
  If it's correct, it marginally impacts the ability to use identical agent
  and Neutron driver/plugin code for the two cases (Nova and Kuryr).

I think we are supposed to behave like Nova, binding wise.

@Banix: Can you confirm that it is a bug and not a feature?

>From a quick grepping I see hat nova sets the name to be:

    nova/network/neutronv2/api.py:    devname = "tap" +
current_neutron_port['id']

Whereas in Kuryr we use the first 8 characters of the Docker endpoint id.


  Thanks,
      Neil


  __

  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] [Kuryr] will we use os-vif in kuryr

[Mohammad Banikazemi]

Yes, we have been aware of the os-vif effort and will try to use it as soon
as it is released. The scripts we currently use are to enable the use of
the Neutron reference plugins/drivers in the meantime.

Best,

Mohammad




From:   "Daniel P. Berrange" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   02/18/2016 05:36 AM
Subject:Re: [openstack-dev] [Kuryr] will we use os-vif in kuryr



On Thu, Feb 18, 2016 at 09:01:35AM +, Liping Mao (limao) wrote:
> Hi Kuryr team,
>
> I see couple of commits to add support for vif plug.
> https://review.openstack.org/#/c/280411/
> https://review.openstack.org/#/c/280878/
>
> Do we have plan to use os-vif?
> https://github.com/openstack/os-vif

FYI, we're trying reasonably hard to *not* make any assumptions about
what compute or network services are using os-vif. ie, we want os-vif
as a framework to be usable from Nova, or any other compute manager,
and likewise be usable from Neutron or any other network manager.
Obviously the actual implementations may be different, but the general
os-vif framework tries to be agnostic.

Regards,
Daniel
--
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/
:|
|: http://libvirt.org  -o- http://virt-manager.org
:|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/
:|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc
:|

__
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] [Kuryr] New Container Networking Model - Kubernetes, Kuryr, and Neutron

[Mohammad Banikazemi]

The log of this IRC meeting can be found here:
http://eavesdrop.openstack.org/meetings/kuryr/2016/kuryr.2016-01-26-15.03.log.html

Best,

Mohammad




From:   Mohammad Banikazemi/Watson/IBM@IBMUS
To: "OpenStack Development Mailing List \(not for usage questions
\)" <openstack-dev@lists.openstack.org>
Date:   01/25/2016 03:04 PM
Subject:Re: [openstack-dev] [Kuryr] New Container Networking Model -
Kubernetes, Kuryr, and Neutron



 The #openstack-kuryr channel.

Best,

Mohammad


Inactive hide details for Steve Gordon ---01/25/2016 02:12:39 PM
Original Message - > From: "Mohammad Banikazemi"  From: "Mohammad
Banikazemi" <m...@us.ibm.com>

From: Steve Gordon <sgor...@redhat.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date: 01/25/2016 02:12 PM
Subject: Re: [openstack-dev] [Kuryr] New Container Networking Model -
Kubernetes, Kuryr, and Neutron



- Original Message -
> From: "Mohammad Banikazemi" <m...@us.ibm.com>
> To: openstack-dev@lists.openstack.org
>
> We are going to discuss CNI, the Container Network Interface at 15:00 UTC
> on Tuesday (!0am EST). In particular, we like to start putting together a
> plan for supporting CNI in the Kuryr project. All interested parties are
> welcome and encouraged to attend.
>
> Thanks,
>
> Mohammad

Hi Mohammad,

Dumb question - which channel? #openstack-kuryr or one of the meeting
channels?

Thanks,

Steve

__
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] [Kuryr] New Container Networking Model - Kubernetes, Kuryr, and Neutron

[Mohammad Banikazemi]

 The #openstack-kuryr channel.

Best,

Mohammad




From:   Steve Gordon <sgor...@redhat.com>
To: "OpenStack Development  Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>
Date:   01/25/2016 02:12 PM
Subject:Re: [openstack-dev] [Kuryr] New Container Networking Model -
Kubernetes, Kuryr, and Neutron



- Original Message -----
> From: "Mohammad Banikazemi" <m...@us.ibm.com>
> To: openstack-dev@lists.openstack.org
>
> We are going to discuss CNI, the Container Network Interface at 15:00 UTC
> on Tuesday (!0am EST). In particular, we like to start putting together a
> plan for supporting CNI in the Kuryr project. All interested parties are
> welcome and encouraged to attend.
>
> Thanks,
>
> Mohammad

Hi Mohammad,

Dumb question - which channel? #openstack-kuryr or one of the meeting
channels?

Thanks,

Steve

__
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] [Kuryr] New Container Networking Model - Kubernetes, Kuryr, and Neutron

[Mohammad Banikazemi]

We are going to discuss CNI, the Container Network Interface at 15:00 UTC
on Tuesday (!0am EST). In particular, we like to start putting together a
plan for supporting CNI in the Kuryr project. All interested parties are
welcome and encouraged to attend.

Thanks,

Mohammad
__
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] [kuryr] Does Kuryr support multi-tenant

[Mohammad Banikazemi]

Considering that the underlying container technology is not multi-tenant
(as of now), your observation is correct in that all neutron resources are
made for a single tenant. Until Docker supports multi tenancy, we can
possibly use network options and/or wrappers for docker/swarm clients to
achieve some kind of multi tenancy support. Having said that, I should add
that as of now we do not have such a feature in Kuryr.

Best,

Mohammad




From:   "Liping Mao (limao)" 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   01/25/2016 06:39 AM
Subject:[openstack-dev]  [kuryr] Does Kuryr support multi-tenant



Hi  Kuryr guys,

I’m a new bee in kuryr, and using devstack to try kuryr now, I notice when
I use kuryr to create network/port for container, the resources are in
“admin”.
Do kuryr support multi-tenant now? For example, if I want try kuryr in demo
tenant, how can I do this?

Thanks for your help and any help would be appreciated.

Regards,
Liping Mao
__
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] [Kuryr] Docker Swarm and Kuryr Integration Demo

[Mohammad Banikazemi]

I have a demo video of Docker Swarm and Kuryr Integration posted here:
http://mbanikazemi.com/2016/01/07/docker-swarm-and-kuryr/

Best,

Mohammad




From:   Gal Sagie <gal.sa...@gmail.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@lists.openstack.org>, Eran Gampel
<eran.gam...@huawei.com>, Antoni Segura Puimedon
<t...@midokura.com>, Vikas Choudhary
<choudharyvika...@gmail.com>, Irena Berezovsky
<ir...@midokura.com>, Taku Fukushima <tfukush...@midokura.com>,
Mohammad Banikazemi/Watson/IBM@IBMUS, Kyle Mestery
<mest...@mestery.com>, Jaume Devesa <devv...@gmail.com>
Date:   12/29/2015 01:37 AM
Subject:[Kuryr] Progress Update and Kubernetes Integration



Hello everyone,

Just wanted to give you all some progress update at what we have been doing
in Kuryr,
We conducted an IRC meeting today, you can see the logs here [1]

1) We got Docker pluggable IPAM support in Kuryr thanks to Vikas Choudhary,
there
   are still some small points to address but most of the code is already
merged.
   I plan to write a blog post about it describing the mechanism

2) Mohammad Banikazemi verified Kuryr works with Docker Swarm seamlessly
   and we are compatible with latest Docker libnetwork

3) We have fullstack job running in the gate, basically these tests are
running with a
    working Openstack environment with Kuryr deployed and using Neutron
client and
    Docker python client to simulate different scenarios and test Kuryr
functionality
    in addition to our unit tests.

4) We have Rally job running, we plan to contribute Docker plugin to Rally
and have
    some of the above tests run benchmarking operation, i think this is a
very important
    goal as it will also help us benchmark different Neutron backends and
solutions
    in terms of containers networking and let users/operators have better
comparison
    between their different options.

5) We are working on packaging for Kuryr (Thanks to Jaume Devesa for that)

6) We are working on investigating using Linux CAPABILITIES rather then
using
    rootwrap or running as root for Kuryr (Thanks to Antoni Segura
Puimedon)

We also decided to give Kubernetes integration higher priority and are now
brain storming
design options to integrate Kubernetes and Kuryr which means integrating
Kubernetes with Neutron (OpenStack networking abstraction).
If you have any idea in that area or done something similar (or in the
middle of doing it)
Please share it in this Etherpad [2].
Our goal is to expose the different ways to do this to the user and find
the best common
method.

We are also starting to approach the Kuryr-Magnum integration and nested
containers and
hope to achieve some progress on this by the end of the release.

Thanks everyone that contribute and help, its greatly appreciated by all of
us!
If you would like to join , feel free to step in our IRC channel at
freenode #openstack-kuryr
Join the IRC meeting [3] or just email me with any question/idea.

Thanks
Gal.

[1]
http://eavesdrop.openstack.org/meetings/kuryr/2015/kuryr.2015-12-29-03.01.html

[2] https://etherpad.openstack.org/p/kuryr_k8s
[3] https://wiki.openstack.org/wiki/Meetings/Kuryr
__
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] [nova][neutron][devstack] New proposed 'default' network model

[Mohammad Banikazemi]

"Fox, Kevin M"  wrote on 09/15/2015 02:57:10 PM:

> From: "Fox, Kevin M" 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 09/15/2015 02:59 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> Most projects let you specify a name, and only force you to use a
> uuid IFF there is a conflict, leaving it up to the user to decide if
> they want the ease of use of names and being careful to name things,
> or having to use uuid's and not.

That is how Neutron works as well. If it doesn't in some cases, then those
are bugs that need to be filed and fixed.

mb@ubuntu14:~$ neutron net-create x1
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| 02fd014d-3a84-463f-a158-317411528ff3 |
| mtu   | 0|
| name  | x1   |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 1037 |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tenant_id | ce56abd5661f4140a5df98927a6f54d8 |
+---+--+
mb@ubuntu14:~$ neutron net-delete x1
Deleted network: x1

mb@ubuntu14:~$ neutron net-create x1
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| db95539c-1c33-4791-a87f-608872ed3e86 |
| mtu   | 0|
| name  | x1   |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 1010 |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tenant_id | ce56abd5661f4140a5df98927a6f54d8 |
+---+--+
mb@ubuntu14:~$ neutron net-create x1
Created a new network:
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| id| b2b3dd55-0f6f-46e7-aaef-c4a89a5d1ef9 |
| mtu   | 0|
| name  | x1   |
| port_security_enabled | True |
| provider:network_type | vxlan|
| provider:physical_network |  |
| provider:segmentation_id  | 1071 |
| router:external   | False|
| shared| False|
| status| ACTIVE   |
| subnets   |  |
| tenant_id | ce56abd5661f4140a5df98927a6f54d8 |
+---+--+
mb@ubuntu14:~$ neutron net-delete x1
Multiple network matches found for name 'x1', use an ID to be more
specific.
mb@ubuntu14:~$ neutron net-delete db95539c-1c33-4791-a87f-608872ed3e86
Deleted network: db95539c-1c33-4791-a87f-608872ed3e86
mb@ubuntu14:~$ neutron net-delete x1
Deleted network: x1
mb@ubuntu14:~$


Best,

Mohammad



>
> Neutron also has the odd wrinkle in that if your a cloud admin, it
> always gives you all the resources back in a listing rather then
> just the current tenant with a flag saying all.
>
> This 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mohammad Banikazemi]

"Fox, Kevin M"  wrote on 09/15/2015 02:00:03 PM:

> From: "Fox, Kevin M" 
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 09/15/2015 02:02 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> We run several clouds where there are multiple external networks.
> the "just run it in on THE public network" doesn't work. :/
>
> I also strongly recommend to users to put vms on a private network
> and use floating ip's/load balancers.


Just curious to know how many floating IPs you have in each instance of
your OpenStack cloud.

Best,

Mohammad




For many reasons. Such as, if
> you don't, the ip that gets assigned to the vm helps it become a
> pet. you can't replace the vm and get the same IP. Floating IP's and
> load balancers can help prevent pets. It also prevents security
> issues with DNS and IP's. Also, for every floating ip/lb I have, I
> usually have 3x or more the number of instances that are on the
> private network. Sure its easy to put everything on the public
> network, but it provides much better security if you only put what
> you must on the public network. Consider the internet. would you
> want to expose every device in your house directly on the internet?
> No. you put them in a private network and poke holes just for the
> stuff that does. we should be encouraging good security practices.
> If we encourage bad ones, then it will bite us later when OpenStack
> gets a reputation for being associated with compromises.
>
> I do consider making things as simple as possible very important.
> but that is, make them as simple as possible, but no simpler.
> There's danger here of making things too simple.
>
> Thanks,
> Kevin
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: Tuesday, September 15, 2015 10:02 AM
> To: openstack-dev
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > On 15 September 2015 at 08:04, Monty Taylor 
wrote:
> >
> > > Hey all!
> > >
> > > If any of you have ever gotten drunk with me, you'll know I hate
floating
> > > IPs more than I hate being stabbed in the face with a very angry
fish.
> > >
> > > However, that doesn't really matter. What should matter is "what is
the
> > > most sane thing we can do for our users"
> > >
> > > As you might have seen in the glance thread, I have a bunch of
OpenStack
> > > public cloud accounts. Since I wrote that email this morning, I've
added
> > > more - so we're up to 13.
> > >
> > > auro
> > > citycloud
> > > datacentred
> > > dreamhost
> > > elastx
> > > entercloudsuite
> > > hp
> > > ovh
> > > rackspace
> > > runabove
> > > ultimum
> > > unitedstack
> > > vexxhost
> > >
> > > Of those public clouds, 5 of them require you to use a floating IP to
get
> > > an outbound address, the others directly attach you to the public
network.
> > > Most of those 8 allow you to create a private network, to boot vms on
the
> > > private network, and ALSO to create a router with a gateway and put
> > > floating IPs on your private ip'd machines if you choose.
> > >
> > > Which brings me to the suggestion I'd like to make.
> > >
> > > Instead of having our default in devstack and our default when we
talk
> > > about things be "you boot a VM and you put a floating IP on it" -
which
> > > solves one of the two usage models - how about:
> > >
> > > - Cloud has a shared: True, external:routable: True neutron network.
I
> > > don't care what it's called  ext-net, public, whatever. the "shared"
part
> > > is the key, that's the part that lets someone boot a vm on it
directly.
> > >
> > > - Each person can then make a private network, router, gateway, etc.
and
> > > get floating-ips from the same public network if they prefer that
model.
> > >
> > > Are there any good reasons to not push to get all of the public
networks
> > > marked as "shared"?
> > >
> >
> > The reason is simple: not every cloud deployment is the same: private
is
> > different from public and even within the same cloud model, the network
> > topology may vary greatly.
> >
> > Perhaps Neutron fails in the sense that it provides you with too much
> > choice, and perhaps we have to standardize on the type of networking
> > profile expected by a user of OpenStack public clouds before making
changes
> > that would fragment this landscape even further.
> >
> > If you are advocating for more flexibility without limiting the
existing
> > one, we're only making the problem worse.
>
> As with the Glance image upload API discussion, this is an example
> of an extremely common use case that is either complex for the end
> user or for which they have to know something about the deployment
> in order to do it at all. The usability of an OpenStack cloud running
> neutron 

Re: [openstack-dev] [nova][neutron][devstack] New proposed 'default' network model

[Mohammad Banikazemi]

Thanks Kevin for your answer. My question was different. You mentioned in
your email that you run several clouds. That's why I used the word
"instance" in my question to refer to each of those clouds. So let me put
the question in a different way: in the biggest cloud you run, how many
total floating IPs do you have. Just a ballpark number will be great. 10s,
100s, 1000s, more?

Thanks,

Mohammad

"Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 03:43:45 PM:

> From: "Fox, Kevin M" <kevin@pnnl.gov>
> To: "OpenStack Development Mailing List (not for usage questions)"
> <openstack-dev@lists.openstack.org>
> Date: 09/15/2015 03:49 PM
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model
>
> I'm not quite sure how to read your question. I think it can be
> taken multiple ways. I'll guess at what you meant though. If I
> interpreted wrong, please ask again.
>
> For the instances that have floating ip's, usually either 1 or 2.
> One of our clouds has basically a public
> network directly on the internet, and a shared private network that
> crosses tenants but is not internet facing. We can place vm's on
> either network easily by just attaching floating ip's. The private
> shared network has more floating ip's assigned then the internet one
usually.
>
> As LBaaS is maturing, we're using it more and more, putting the
> floating ips on the LB instead of the instances, and putting a pool
> of instances behind it. So our instance counts are growing faster
> then our usage of floating IP's.
>
> Thanks,
> Kevin
>
> From: Mohammad Banikazemi [m...@us.ibm.com]
> Sent: Tuesday, September 15, 2015 12:23 PM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> 'default' network model

> "Fox, Kevin M" <kevin@pnnl.gov> wrote on 09/15/2015 02:00:03 PM:
>
> > From: "Fox, Kevin M" <kevin@pnnl.gov>
> > To: "OpenStack Development Mailing List (not for usage questions)"
> > <openstack-dev@lists.openstack.org>
> > Date: 09/15/2015 02:02 PM
> > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> > 'default' network model
> >
> > We run several clouds where there are multiple external networks.
> > the "just run it in on THE public network" doesn't work. :/
> >
> > I also strongly recommend to users to put vms on a private network
> > and use floating ip's/load balancers.
>
>
> Just curious to know how many floating IPs you have in each instance
> of your OpenStack cloud.
>
> Best,
>
> Mohammad
>
>
>
>
> For many reasons. Such as, if
> > you don't, the ip that gets assigned to the vm helps it become a
> > pet. you can't replace the vm and get the same IP. Floating IP's and
> > load balancers can help prevent pets. It also prevents security
> > issues with DNS and IP's. Also, for every floating ip/lb I have, I
> > usually have 3x or more the number of instances that are on the
> > private network. Sure its easy to put everything on the public
> > network, but it provides much better security if you only put what
> > you must on the public network. Consider the internet. would you
> > want to expose every device in your house directly on the internet?
> > No. you put them in a private network and poke holes just for the
> > stuff that does. we should be encouraging good security practices.
> > If we encourage bad ones, then it will bite us later when OpenStack
> > gets a reputation for being associated with compromises.
> >
> > I do consider making things as simple as possible very important.
> > but that is, make them as simple as possible, but no simpler.
> > There's danger here of making things too simple.
> >
> > Thanks,
> > Kevin
> > 
> > From: Doug Hellmann [d...@doughellmann.com]
> > Sent: Tuesday, September 15, 2015 10:02 AM
> > To: openstack-dev
> > Subject: Re: [openstack-dev] [nova][neutron][devstack] New proposed
> > 'default' network model
> >
> > Excerpts from Armando M.'s message of 2015-09-15 09:30:35 -0700:
> > > On 15 September 2015 at 08:04, Monty Taylor <mord...@inaugust.com>
wrote:
> > >
> > > > Hey all!
> > > >
> > > > If any of you have ever gotten drunk with me, you'll know I
> hate floating
> > > > IPs more than I hate being stabbed in the face with a very angry
fish.
> > > >
> > > > However, that doesn't really matter. What 

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

[Mohammad Banikazemi]

Please note that the meeting will be held in #openstack-meeting-4 channel
on Freenode starting this Monday August 3rd at 1500 UTC.
The agenda and other related information will be kept at:
https://wiki.openstack.org/wiki/Meetings/Kuryr

Best,

Mohammad



From:   Gal Sagie gal.sa...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Cc: Eran Gampel eran.gam...@toganetworks.com, Irena Berezovsky
ir...@midokura.com
Date:   07/29/2015 01:12 PM
Subject:Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers
networking  to Neutron



Hi Yalei,

We set a date/time, its going to be Monday at 15:00 UTC
If you can't attend, i will be happy to update you on IRC when i am around,
and you
can also approach Antoni (apuimedo in IRC) if you have any questions.

Hope to see you involved!

Gal.


On Wed, Jul 29, 2015 at 12:53 PM, Wang, Yalei yalei.w...@intel.com wrote:
  Interested in, have the time been determined?





  /Yalei





  From: Antoni Segura Puimedon [mailto:toni+openstac...@midokura.com]
  Sent: Friday, July 24, 2015 3:30 AM
  To: Stephen Wong
  Cc: Eran Gampel; OpenStack Development Mailing List (not for usage
  questions); Irena Berezovsky
  Subject: Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers
  networking to Neutron











  On Thu, Jul 23, 2015 at 8:10 PM, Stephen Wong stephen.kf.w...@gmail.com
  wrote:


  +1 for Monday








  +1 for Monday UTC. Maybe at 14 or 15h ?



  On Wed, Jul 22, 2015 at 10:29 PM, Mohammad Banikazemi m...@us.ibm.com
  wrote:


  Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I
  realize there are several networking related weekly meetings, but I would
  like to see if we can find a different time. I suggest the same time,
  that is 1600 UTC but either on Mondays or Thursdays.

  Please note there is the Ironic/Neutron Integration meeting at the same
  time on Mondays but that conflict may be a smaller conflict. Looking at
  the meetings listed at [2] I do not see any other conflict.

  Best,

  Mohammad

  [1] https://wiki.openstack.org/wiki/Meetings/ML2
  [2] http://eavesdrop.openstack.org


  Inactive hide details for Gal Sagie ---07/22/2015 12:31:46 PM---Hello
  Everyone, Project Kuryr is now officially part of NeutronGal Sagie
  ---07/22/2015 12:31:46 PM---Hello Everyone, Project Kuryr is now
  officially part of Neutron's big tent.

  From: Gal Sagie gal.sa...@gmail.com
  To: OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@lists.openstack.org, Eran Gampel 
  eran.gam...@toganetworks.com, Antoni Segura Puimedon t...@midokura.com
  , Irena Berezovsky ir...@midokura.com
  Date: 07/22/2015 12:31 PM
  Subject: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking
  to Neutron









  Hello Everyone,

  Project Kuryr is now officially part of Neutron's big tent.
  Kuryr is aimed to be used as a generic docker remote driver that connects
  docker to Neutron API's
  and provide containerised images for the common Neutron plugins.
  We also plan on providing common additional networking services API's
  from other sub projects
  in the Neutron big tent.

  We hope to get everyone on board with this project and leverage this
  joint effort for the many different solutions out there (instead of
  everyone re-inventing the wheel for each different project).

  We want to start doing a weekly IRC meeting to coordinate the different
  requierments and
  tasks, so anyone that is interested to participate please share your time
  preference
  and we will try to find the best time for the majority.

  Remember we have people in Europe, Tokyo and US, so we won't be able to
  find time that fits
  everyone.

  The currently proposed time is  Wedensday at 16:00 UTC

  Please reply with your suggested time/day,
  Hope to see you all, we have an interesting and important project ahead
  of us

  Thanks


  Gal.
  __

  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




--
Best Regards ,

The G.
__
OpenStack Development Mailing

Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers networking to Neutron

[Mohammad Banikazemi]

Daneyon Hansen (danehans) daneh...@cisco.com wrote on 07/23/2015
03:40:38 PM:

 From: Daneyon Hansen (danehans) daneh...@cisco.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org, Mohammad Banikazemi/Watson/
 IBM@IBMUS, Steven Dake (stdake) std...@cisco.com
 Cc: Eran Gampel eran.gam...@toganetworks.com, Irena Berezovsky
 ir...@midokura.com
 Date: 07/23/2015 03:45 PM
 Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing
 Dockers networking to Neutron

 From: Antoni Segura Puimedon toni+openstac...@midokura.com
 Reply-To: OpenStack Development Mailing List (not for usage questions)

 openstack-dev@lists.openstack.org
 Date: Thursday, July 23, 2015 at 11:16 AM
 To: Mohammad Banikazemi m...@us.ibm.com, Steven Dake (stdake) 
 std...@cisco.com
 Cc: Eran Gampel eran.gam...@toganetworks.com, OpenStack
 Development Mailing List (not for usage questions) openstack-
 d...@lists.openstack.org, Irena Berezovsky ir...@midokura.com
 Subject: Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing
 Dockers networking to Neutron

 Why is a separate OpenStack project needed to contribute to
 libnetwork? I would think the Neutron community would follow the
 libnetwork contrib guidelines and submit the code.


While there may be contributions to docker/libnetwork at some point, the
project is not about contributing to libnetwork. For example, the Neutron
driver itself won't be part of the docker or libnetwork tree. Making other
OpenStack and Neutron services available for use by containers may be a
good reason  for having it under the OpenStack and Neutron umbrella but I
think one can debate where a project fits best.

Best,

Mohammad
__
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][Kuryr][kolla] - Bringing Dockers networking to Neutron

[Mohammad Banikazemi]

 $ docker -d --kv-store=consul:localhost:8500 --
 label=com.docker.network.driver.kuryr.bind_interface=eth0 --
 label=com.docker.network.driver.kuryr.neutron_api=10.10.10.10

--label=com.docker.network.driver.kuryr.token=AUTH_tk713d067336d21348bcea1ab220965485


Toni, Why do you want to have this configuration parameters known to
docker? Docker uses a plugin through the libnetwork remote driver. What
that plugin does and how for example it gets to the Neutron server is what
the plugin has to deal with. No?

I can see some information regarding IP address management may be relevant
to docker and I see the use of labels but think other parameters should not
be of concern to docker.

You have referred to use of an authentication token. I think that is a
possible place were labels can be eventually used for identifying different
tenants/users but that requires a longer discussion.

Best,

Mohammad
__
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][Kuryr][kolla] - Bringing Dockers networking to Neutron

[Mohammad Banikazemi]

I let the creators of the project speak for themselves but here is my take
on project Kuryr.

The goal is not to containerize Neutron or other OpenStack services. The
main objective is to use Neutron as a networking backend option for Docker.
The original proposal was to do so in the context of using containers (for
different Neutron backends or vif types). While the main objective is
fundamental to the project, the latter (use of containers in this
particular way) seems to be a tactical choice we need to make. I see
several different options available to achieve the same goal in this
regard.

Now, there is another aspect of using containers in the context of this
project that is more interesting at least to me (and I do not know if
others share this view or not) and that is the use of containers for
providing network services that are not available through libnetwork as of
now or in near future or ever. From the talks I have had with libnetwork
developers the plan is to stay with the basic networking infrastructure and
leave additional features to be developed by the community and to do so
possibly by using what else,  containers.

So take the current features available in libnetwork. You mainly get
support for connectivity/isolation for multiple networks across multiple
hosts. Now if you want to route between these networks, you have to devise
a solution yourself. One possible solution would be having a router service
in a container that gets connected to say two Docker networks. Whether the
router service is implemented with the use of the current Neutron router
services or by some other solutions is something to look into and discuss
but this is a direction where I think Kuryr (did I spell it right? ;)) can
and should contribute to.

Just my 2 cents on this topic.

Best,

Mohammad




From:   Steven Dake (stdake) std...@cisco.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org, Eran Gampel
eran.gam...@toganetworks.com, Antoni Segura Puimedon
t...@midokura.com, Irena Berezovsky ir...@midokura.com,
gal.sa...@gmail.com gal.sa...@gmail.com
Date:   07/23/2015 11:34 AM
Subject:Re: [openstack-dev] [Neutron][Kuryr][kolla] - Bringing Dockers
networking to Neutron



Gal,

I’m not clear exactly what you plan to do with regards to building docker
containers for Neutron, but the Kolla project has developed both
linuxbridge and ovs agents as well as a complete running Neutron system
inside container technology.  We can launch it AIO with docker-compose, or
alternatively it can be launched AIO or multinode with Ansible.  Note we
have a complete OpenStack implementation, not just Neutron.

We would welcome additional driver support using the standard OpenStack
gerrit workflow.

https://github.com/stackforge/kolla/tree/master/docker/centos/binary/neutron

Note we are also in the process of adding build from source to our tree
here:

https://github.com/stackforge/kolla/tree/master/docker/centos/source/neutron

For further background on Kolla, check out our wiki page:

https://wiki.openstack.org/wiki/Kolla

Best wishes,
-steve

From: Gal Sagie gal.sa...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date: Wednesday, July 22, 2015 at 9:28 AM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org, Eran Gampel 
eran.gam...@toganetworks.com, Antoni Segura Puimedon t...@midokura.com,
Irena Berezovsky ir...@midokura.com
Subject: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to
Neutron


  Hello Everyone,

  Project Kuryr is now officially part of Neutron's big tent.
  Kuryr is aimed to be used as a generic docker remote driver that
  connects docker to Neutron API's
  and provide containerised images for the common Neutron plugins.
  We also plan on providing common additional networking services API's
  from other sub projects
  in the Neutron big tent.

  We hope to get everyone on board with this project and leverage this
  joint effort for the many different solutions out there (instead of
  everyone re-inventing the wheel for each different project).

  We want to start doing a weekly IRC meeting to coordinate the
  different requierments and
  tasks, so anyone that is interested to participate please share your
  time preference
  and we will try to find the best time for the majority.

  Remember we have people in Europe, Tokyo and US, so we won't be able
  to find time that fits
  everyone.

  The currently proposed time is  Wedensday at 16:00 UTC

  Please reply with your suggested time/day,
  Hope to see you all, we have an interesting and important project
  ahead of us

  Thanks
  Gal.
  __

Re: [openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking to Neutron

[Mohammad Banikazemi]

Gal, This time conflicts with the Neutron ML2 weekly meeting time [1]. I
realize there are several networking related weekly meetings, but I would
like to see if we can find a different time. I suggest the same time, that
is 1600 UTC but either on Mondays or Thursdays.

Please note there is the Ironic/Neutron Integration meeting at the same
time on Mondays but that conflict may be a smaller conflict. Looking at the
meetings listed at [2] I do not see any other conflict.

Best,

Mohammad

[1] https://wiki.openstack.org/wiki/Meetings/ML2
[2] http://eavesdrop.openstack.org




From:   Gal Sagie gal.sa...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org, Eran Gampel
eran.gam...@toganetworks.com, Antoni Segura Puimedon
t...@midokura.com, Irena Berezovsky ir...@midokura.com
Date:   07/22/2015 12:31 PM
Subject:[openstack-dev] [Neutron][Kuryr] - Bringing Dockers networking
to  Neutron




Hello Everyone,

Project Kuryr is now officially part of Neutron's big tent.
Kuryr is aimed to be used as a generic docker remote driver that connects
docker to Neutron API's
and provide containerised images for the common Neutron plugins.
We also plan on providing common additional networking services API's from
other sub projects
in the Neutron big tent.

We hope to get everyone on board with this project and leverage this joint
effort for the many different solutions out there (instead of everyone
re-inventing the wheel for each different project).

We want to start doing a weekly IRC meeting to coordinate the different
requierments and
tasks, so anyone that is interested to participate please share your time
preference
and we will try to find the best time for the majority.

Remember we have people in Europe, Tokyo and US, so we won't be able to
find time that fits
everyone.

The currently proposed time is  Wedensday at 16:00 UTC

Please reply with your suggested time/day,
Hope to see you all, we have an interesting and important project ahead of
us

Thanks
Gal.
__
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] Modular L2 Agent

[Mohammad Banikazemi]

Thanks Sean for creating the rfe. I think we can go beyond the OVS and LB
agents and aim for providing a framework where any agent (if and when
needed) can benefit from it.  We can continue the discussion on launchpad.

Best,

Mohammad





From:   Sean M. Collins s...@coreitpro.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   06/25/2015 11:38 AM
Subject:Re: [openstack-dev] [Neutron] Modular L2 Agent



On Mon, Jun 22, 2015 at 06:42:11AM MDT, Kyle Mestery wrote:
 Is there an RFE files for this? At this point, since Liberty-1 is this
 week, an RFE would be the best approach forward. My gut is leaning
towards
 this not being in-scope for Liberty at this point, but an RFE would allow
 us to have the discussion on the bug there too.

I didn't see one, so I filed one.

https://bugs.launchpad.net/neutron/+bug/1468803

Hopefully I did it right?

--
Sean M. Collins

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

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

[openstack-dev] [Neutron] Modular L2 Agent

[Mohammad Banikazemi]

During the last couple of ML2 group meetings, the subject of Modular L2
Agents has come up again and I was tasked to bring up the subject to the
attention of the larger community.
We are aware of the ongoing efforts to improve the L2 agent(s) and the
patches which are currently under review and those that got merged
recently. The question is whether the Neutron community thinks the effort
started (and suspended) a while ago around creating a modular L2 agent is
worth pursuing at all and if yes, whether this is a good cycle to get that
work possibly restarted.

Best,

Mohammad__
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] [Nova][Neutron] Status of the nova-network to Neutron migration work

[Mohammad Banikazemi]

 signature.asc deleted by Mohammad Banikazemi/Watson/
 IBM]

__
 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-operators] [Neutron] allow_overlapping_ips (was: Deprecating the use_namespaces option ...)

[Mohammad Banikazemi]

The allow_overlapping_ips configuration option in it's current form was
mainly used to cover older distros that did not support namespaces as you
have mentioned. That's why in its current form this option operates across
all networks of all tenants. That is, if the option is set to false,
overlapping IPs are not allowed even across tenants.
If the option is to be redefined/reimplemented/interpreted as allowing or
disallowing overlapping IPs within the scope of a single tenant, then I
think that would be useful to some.

Mohammad




From:   Carl Baldwin c...@ecbaldwin.net
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   03/25/2015 11:37 AM
Subject:[openstack-dev] [Openstack-operators] [Neutron]
allow_overlapping_ips (was: Deprecating the use_namespaces
option ...)



Yesterday, I got looking at another option that I had completely
forgotten about.  It is allow_overlapping_ips, set in neutron.conf
and defaults to False.  It appears that when it is False, Neutron
doesn't allow any overlapping IPs throughout the deployment, across
all networks.  My guess is that the vast majority of deployments will
set this to True as a matter of course.

My suspicion is that this option is related to the use_namespaces
option because if namespaces are not used, then isolating routing
domains would not be possible on the network node.  However, there may
be other reasons for needing this option.

I'm not yet proposing this option be deprecated.  I'm asking for
feedback from operators and others who might be using the default
value of False.

Carl

On Tue, Mar 24, 2015 at 1:21 PM, Assaf Muller amul...@redhat.com wrote:
 Note that https://review.openstack.org/#/c/166888/ has been merged.
 This means that the option has been deprecated for K and will be
 removed in L. Anyone using the non-default value of False will be looking
 at errors in his logs.

 - Original Message -


 On 3/23/2015 3:56 AM, Miguel Ángel Ajo wrote:
  I see you point Van,
 
  In the other hand, removing it, cleans up lot of conditional code
parts
  (moving parts at the other side),
  and also the non-netns case is not tested by upstream CI, AFAIK, so it
  could be broken anytime
  and we would not notice it.
 
 
 
  Miguel Ángel Ajo
 
  On Monday, 23 de March de 2015 at 9:25, Van Leeuwen, Robert wrote:
 
  I think there are valid reasons to not use namespaces:
 
* Fewer moving parts == less can potentialy fail
* Troubleshooting is easier due to less places to look / need no
  familiarity with namespaces  tools
* If I remember correctly setting up a namespace can get really
  slow when you have a lot of them on a single machine
 
 
   IMHO, those shouldn’t be valid reasons anymore, since they were due
   iproute, or sudo issues
   that have been corrected long ago, and all distros installing
neutron
   are supporting netns at this
 
  Well, you exactly made my point:
  There is lots that can and will go wrong with more moving parts.
  That they are fixed at the moment does not mean that there will not
be
  a new bug in the future…
 
  Cheers,
  Robert van Leeuwen
  ___
  OpenStack-operators mailing list
  openstack-operat...@lists.openstack.org
  mailto:openstack-operat...@lists.openstack.org
 
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
 
 
 
 
__
  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
 

 FWIW we were doing CI without namespaces before Kilo simply due to RHEL
 6.5 not having the support w/o a kernel patch.

 Since Kilo dropped py26 support we moved to RHEL 7* for py27 and that
 has namespace support so it's no longer an issue for us.

 --

 Thanks,

 Matt Riedemann



__
 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 

Re: [openstack-dev] [neutron] Generic question about synchronizing neutron agent on compute node with DB

[Mohammad Banikazemi]

It is perhaps worth mentioning that there is an effort to implement a
generic synchronization mechanism (between Neutron and backend
controllers/devices) in the ML2 plugin [1]. A possible framework for its
eventual implementation is in an early discussion/proof-of-concept WIP
state [2].

-Mohammad

[1] https://blueprints.launchpad.net/neutron/+spec/ml2-driver-sync
[2] https://review.openstack.org/#/c/154333/



From:   Cory Benfield cory.benfi...@metaswitch.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   03/16/2015 04:48 AM
Subject:Re: [openstack-dev] [neutron] Generic question about
synchronizing   neutron agent on compute node with DB



On Sun, Mar 15, 2015 at 22:37:59, Sławek Kapłoński wrote:
 Maybe good idea for the beginning could be to implement some periodic
 task
 called from agent to check db config and compare it with real state on
 host?
 What do You think? Or maybe I'm competly wrong with such idea and it
 should be
 done in different way?

This is almost exactly what we do in our Calico ML2 driver. Each of our
agents will periodically request its complete state from a neutron-server
node and will ensure that its local state matches that expected state. This
interval is configurable, to allow administrators to make a trade-off
between DB/network load and convergence time.

With reliable transport this is in principle almost never needed (messages
only really get lost on agent crash, and the agent will resynchronize when
it starts back up anyway), but it provides assurances that the fabric is
capable of bringing itself into consistency without administrator
intervention.

Having similar function in other neutron agents would be valuable for the
exact same reasons, but do bear in mind the potentially increased load this
kind of resynchronization can place on databases and servers.

Cory
__
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] Bulk network operations

[Mohammad Banikazemi]

Saksham, The Neutron bulk operations are by definition atomic [1]: Bulk
operations are always performed atomically, meaning that either all or none
of the objects in the request body are created.

Best,

Mohammad

[1] https://wiki.openstack.org/wiki/Neutron/APIv2-specification



From:   Saksham Varma (sakvarma) sakva...@cisco.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   01/26/2015 08:01 PM
Subject:Re: [openstack-dev] [Neutron] Bulk network operations



Modifying the subject line.

From: Saksham Varma sakva...@cisco.com
Reply-To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Date: Tuesday, January 27, 2015 at 5:21 AM
To: openstack-dev@lists.openstack.org openstack-dev@lists.openstack.org
Subject: [openstack-dev] Bulk network operations

Hi,

I was working on bulk network operations for one of Cisco’s plugins. I was
wondering how do other plugins handle failures in bulk requests. Are all
the requests in the bulk payload rolled back, if any fails (like an atomic
strategy)? Or is it like a best effort, which is not necassarily atomic?

Thanks,
Saksham
__
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] FYI: Just abandoned old reviews

[Mohammad Banikazemi]

Looks like some reviews which should have been marked by this script were
not. At least I noticed one such review [1].

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



From:   Kyle Mestery mest...@mestery.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   01/26/2015 10:21 AM
Subject:[openstack-dev] [neutron] FYI: Just abandoned old reviews



I just ran the Nova abandon script [1] against the neutron repositories, so
a lot of old reviews were cleaned out of the system this morning. If your
review needs to be re-instated, you can do this manually as the message
should indicate.

I've also proposed the abandon script into the neutron repository as well
for future use [2]. Thanks to Sean for pointing me at the script last week!

Thanks,
Kyle

[1]
https://github.com/openstack/nova/blob/master/tools/abandon_old_reviews.sh
[2] https://review.openstack.org/150055
__
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][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Mohammad Banikazemi]

I had done some work on looking at L2 agents and identifying how we may
want to go about creating a Modular L2 Agent framework to make the agent
code more modular, avoid code replication across multiple L2 agents, and to
make adding new features and writing new agents (if/when necessary) easier.
I will be happy to take a stab at writing the blueprint/spec based on that
work and what is specified in the etherpad [1].

I had to take a few weeks off from work and therefore had to miss the
Summit; This happened right around the time that paying our technical
debts was becoming a common phrase in Neutron (for good reasons) and from
what I can gather from the etherpad [1] the scope for this effort may have
expanded and there are others who have volunteered to work on various
aspects of this effort. So, if there are others who want to start the task
force by writing this blueprint/spec, that is perfectly fine with me. If
not, I will be happy to get that started.

Best,

Mohammad (banix)





From:   Carl Baldwin c...@ecbaldwin.net
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date:   11/18/2014 12:19 PM
Subject:[openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an L2
agent debt repayment task force



At the recent summit, we held a session about debt repayment in the
Neutron agents [1].  Some work was identified for the L2 agent.  We
had a discussion in the Neutron meeting today about bootstrapping that
work.

The first order of business will be to generate a blueprint
specification for the work similar, in purpose, to the one that is
under discussion for the L3 agent [3].  I personally am at or over
capacity for BP writing this cycle.  We need a volunteer to take this
on coordinating with others who have been identified on the etherpad
for L2 agent work (you know who you are) and other volunteers who have
yet to be identified.

This task force will use the weekly Neutron meeting, the ML, and IRC
to coordinate efforts.  But first, we need to bootstrap the task
force.  If you plan to participate, please reply to this email and
describe how you will contribute, especially if you are willing to be
the lead author of a BP.  I will reconcile this with the etherpad to
see where gaps have been left.

I am planning to contribute as a core reviewer of blueprints and code
submissions only.

Carl

[1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
[2]
http://eavesdrop.openstack.org/meetings/networking/2014/networking.2014-11-18-14.02.html

[3] https://review.openstack.org/#/c/131535/

___
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][L2 Agent][Debt] Bootstrapping an L2 agent debt repayment task force

[Mohammad Banikazemi]

Salvatore Orlando sorla...@nicira.com wrote on 11/18/2014 04:15:35 PM:

 From: Salvatore Orlando sorla...@nicira.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 11/18/2014 04:19 PM
 Subject: Re: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping
 an L2 agent debt repayment task force

 I think we should also get rid of some nonsenses in the way events
 are processed by the l2 agent. Carl did something similar for the l3
agent.
 In the past release cycle I put some patches to avoid event
 starvation or to prevent the same event to be processed multiple
 times, but I did not address the root cause of the issue.

 This is probably already in the etherpad under the bullet ovsdb
 monitor improvements. It seems the current assignee is Terry, but I
 guess nobody would mind If I submit a spec for it just to assess
 what are the point of conflicts with other tasks, and then maybe
 either I or Terry do the actual work.

 Regarding the modular l2 agent, I think that was the one item for
 which the consensus was to defer. Not because it wasn't deemed
 important. I think the concern here was that it was a major
 refactoring which pretty much would have blocked all other
 activities. But I am happy to reconsider or find a strategy to
 ensure the modular l2 agent could fit into kilo plans.



I was not aware of this development regarding Modular L2 Agent. It wasn't
obvious from the etherpad but that is understandable. There is so much you
can capture in an etherpad. Thanks for clarifying it promptly.



 Salvatore

 On 18 November 2014 19:32, Mohammad Banikazemi m...@us.ibm.com wrote:
 I had done some work on looking at L2 agents and identifying how we
 may want to go about creating a Modular L2 Agent framework to make
 the agent code more modular, avoid code replication across multiple
 L2 agents, and to make adding new features and writing new agents
 (if/when necessary) easier. I will be happy to take a stab at
 writing the blueprint/spec based on that work and what is specified
 in the etherpad [1].

 I had to take a few weeks off from work and therefore had to miss
 the Summit; This happened right around the time that paying our
 technical debts was becoming a common phrase in Neutron (for good
 reasons) and from what I can gather from the etherpad [1] the scope
 for this effort may have expanded and there are others who have
 volunteered to work on various aspects of this effort. So, if there
 are others who want to start the task force by writing this
 blueprint/spec, that is perfectly fine with me. If not, I will be
 happy to get that started.

 Best,

 Mohammad (banix)



 [image removed] Carl Baldwin ---11/18/2014 12:19:00 PM---At the
 recent summit, we held a session about debt repayment in the Neutron
 agents [1].  Some work w

 From: Carl Baldwin c...@ecbaldwin.net
 To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
 Date: 11/18/2014 12:19 PM
 Subject: [openstack-dev] [Neutron][L2 Agent][Debt] Bootstrapping an
 L2 agent debt repayment task force




 At the recent summit, we held a session about debt repayment in the
 Neutron agents [1].  Some work was identified for the L2 agent.  We
 had a discussion in the Neutron meeting today about bootstrapping that
 work.

 The first order of business will be to generate a blueprint
 specification for the work similar, in purpose, to the one that is
 under discussion for the L3 agent [3].  I personally am at or over
 capacity for BP writing this cycle.  We need a volunteer to take this
 on coordinating with others who have been identified on the etherpad
 for L2 agent work (you know who you are) and other volunteers who have
 yet to be identified.

 This task force will use the weekly Neutron meeting, the ML, and IRC
 to coordinate efforts.  But first, we need to bootstrap the task
 force.  If you plan to participate, please reply to this email and
 describe how you will contribute, especially if you are willing to be
 the lead author of a BP.  I will reconcile this with the etherpad to
 see where gaps have been left.

 I am planning to contribute as a core reviewer of blueprints and code
 submissions only.

 Carl

 [1] https://etherpad.openstack.org/p/kilo-neutron-agents-technical-debt
 [2] http://eavesdrop.openstack.org/meetings/networking/2014/
 networking.2014-11-18-14.02.html
 [3] https://review.openstack.org/#/c/131535/

 ___
 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

Re: [openstack-dev] [Neutron] - what integration with Keystone is allowed?

[Mohammad Banikazemi]

In the patch being referred to here and in the IBM controller, the project
ID is the unique identifier used. The name is simply an additional piece of
information that may perhaps be used for debugging. The back-end
(controller) keeps a name not as a unique identifier but in addition to the
unique identifier which is the project ID. For all practical purposes, we
can set the project name for all projects to Kevin Benton and nothing will
change functionally.

This should be obvious from the code and how the project id and not the
name has been used in the plugin. Perhaps the commit message can specify
this clearly to avoid any confusion.

Best,

Mohammad





From:   Dolph Mathews dolph.math...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   09/22/2014 10:53 AM
Subject:Re: [openstack-dev] [Neutron] - what integration with Keystone
is  allowed?




On Sun, Sep 21, 2014 at 3:58 PM, Kevin Benton blak...@gmail.com wrote:
  So based on those guidelines there would be a problem with the IBM patch
  because it's storing the tenant name in a backend controller, right?


It would need to be regarded as an expiring cache if Neutron chose to go
that route. I'd wholly recommend against it though, because I don't see a
strong use case to use names instead of IDs here (correct me if I'm wrong).

  On Sep 21, 2014 12:18 PM, Dolph Mathews dolph.math...@gmail.com
  wrote:
   Querying keystone for tenant names is certainly fair game.

   Keystone should be considered the only source of truth for tenant names
   though, as they are mutable and not globally unique on their own, so
   other services should not stash any names from keystone into long term
   persistence (users, projects, domains, groups, etc-- roles might be an
   odd outlier worth a separate conversation if anyone is interested).

   Store IDs where necessary, and use IDs on the wire where possible
   though, as they are immutable.

   On Sat, Sep 20, 2014 at 7:46 PM, Kevin Benton blak...@gmail.com wrote:
 Hello all,

 A patch has come up to query keystone for tenant names in the IBM
 plugin.[1] As I understand it, this was one of the reasons another
 mechanism driver was reverted.[2] Can we get some clarity on the level
 of integration with Keystone that is permitted?

 Thanks

 1. https://review.openstack.org/#/c/122382
 2. https://review.openstack.org/#/c/118456

 --
 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
  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] - what integration with Keystone is allowed?

[Mohammad Banikazemi]

Akihiro Motoki amot...@gmail.com wrote on 09/22/2014 12:50:43 PM:

 From: Akihiro Motoki amot...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org
 Date: 09/22/2014 12:53 PM
 Subject: Re: [openstack-dev] [Neutron] - what integration with
 Keystone is allowed?

 In Keystone, as Dolph says, a tenant name is not globally unique,
 so IMHO tenant_id needs to be passed to a back-end controller
 to ensure uniqueness of tenant (or project).


Yes, that has been the case in this plugin (and the patch in question does
not change that).


 tenant_name can be an additional information.
 For example it can be used in a GUI of a back-end controller,
 so I think it may be useful for some purpose.


Exactly.


Best,

Mohammad


 Thanks,
 Akihiro


 On Sun, Sep 21, 2014 at 8:46 AM, Kevin Benton blak...@gmail.com wrote:
  Hello all,
 
  A patch has come up to query keystone for tenant names in the IBM
  plugin.[1] As I understand it, this was one of the reasons another
  mechanism driver was reverted.[2] Can we get some clarity on the level
  of integration with Keystone that is permitted?
 
  Thanks
 
  1. https://review.openstack.org/#/c/122382
  2. https://review.openstack.org/#/c/118456
 
  --
  Kevin Benton
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



 --
 Akihiro Motoki amot...@gmail.com

 ___
 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

[Mohammad Banikazemi]

I can only see the use of a separate project for Group Policy as a tactical
and temporary solution. In my opinion, it does not make sense to have the
Group Policy as a separate project outside Neutron (unless the new project
is aiming to replace Neutron and I do not think anybody is suggesting
that). In this regard, Group Policy is not similar to Advanced Services
such as FW and LB.

So, using StackForge to get things moving again is fine but let us keep in
mind (and see if we can agree on) that we want to have the Group Policy
abstractions as part of OpenStack Networking (when/if it proves to be a
valuable extension to what we currently have). I do not want to see our
decision to make things moving quickly right now prevent us from achieving
that goal. That is why I think the other two approaches (from the little I
know about the incubator option, and even littler I know about the feature
branch option) may be better options in the long run.

If I understand it correctly some members of the community are actively
working on these options (that is, the incubator and the Neutron feature
branch options) . In order to make a better judgement as to how to proceed,
it would be very helpful if we get a bit more information on these two
options and their status here on this mailing list.

Mohammad





From:   Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   09/05/2014 04:31 AM
Subject:Re: [openstack-dev] [neutron][policy] Group-based Policy next
steps



Tl;dr - Neutron incubator is only a wiki page with many uncertainties. Use
StackForge to make progress and re-evaluate when the incubator exists.


I also agree that starting out in StackForge as a separate repo is a better
first step. In addition to the uncertainty around packaging and other
processes brought up by Mandeep, I really doubt the Neutron incubator is
going to have the review velocity desired by the group policy contributors.
I believe this will be the case based on the Neutron incubator patch
approval policy in conjunction with the nature of the projects it will
attract.

Due to the requirement for two core +2's in the Neutron incubator, moving
group policy there is hardly going to do anything to reduce the load on the
Neutron cores who are in a similar overloaded position as the Nova
cores.[1] Consequently, I wouldn't be surprised if patches to the Neutron
incubator receive even less core attention than the main repo simply
because their location outside of openstack/neutron will be a good reason
to treat them with a lower priority.

If you combine that with the fact that the incubator is designed to house
all of the proposed experimental features to Neutron, there will be a very
high volume of patches constantly being proposed to add new features, make
changes to features, and maybe even fix bugs in those features. This new
demand for reviewers will not be met by the existing core reviewers because
they will be busy with refactoring, fixing, and enhancing the core Neutron
code.

Even ignoring the review velocity issues, I see very little benefit to GBP
starting inside of the Neutron incubator. It doesn't guarantee any
packaging with Neutron and Neutron code cannot reference any incubator
code. It's effectively a separate repo without the advantage of being able
to commit code quickly.

There is one potential downside to not immediately using the Neutron
incubator. If the Neutron cores decide that all features must live in the
incubator for at least 2 cycles regardless of quality or usage in
deployments, starting outside in a StackForge project would delay the start
of the timer until GBP makes it into the incubator. However, this can be
considered once the incubator actually exists and starts accepting
submissions.

In summary, I think GBP should move to a StackForge project as soon as
possible so development can progress. A transition to the Neutron incubator
can be evaluated once it actually becomes something more than a wiki page.


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

Re: [openstack-dev] [Neutron] Use public IP address as instance fixed IP

[Mohammad Banikazemi]

Would this work? We used to have warnings in Neutron docs indicating that
instances should not be attached to external networks:
It is important to understand that you should not attach the instance to
Ext-Net directly. Instead, you must use a floating IP to make it accessible
from the external network.

In this particular case and with the OVS plugin, the traffic on the
external network which now hosts tenant VMs (on OpenStack compute nodes)
should get routed from the br-int to the external bridge br-ex using for
example the appropriate vlan id (what if external network does not use
vlan?) and then to the external network without doing the NATing. Would
this traffic go through the veth pair connecting the br-int and br-ex?

Mohammad



From:   Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   08/23/2014 01:37 AM
Subject:Re: [openstack-dev] [Neutron] Use public IP address as instance
fixed IP



Yes, you should be able to create a shared/external network within Neutron
to accomplish this.


On Fri, Aug 22, 2014 at 7:25 AM, Bao Wang bywan...@gmail.com wrote:
  Thank you for your response. Could this be done naturally with Openstack
  neutron or have to be done manually outside neutron ?  As we are
  expecting to orchestrate hundreds of NFV with all similar network
  configuration, programmability is another key element.


  On Thu, Aug 21, 2014 at 3:52 PM, Kevin Benton blak...@gmail.com wrote:
   Have you tried making the external network shared as well? Instances
   that need a private IP with NAT attach to an internal network and go
   through the router like normal. Instances that need a public IP without
   NAT would just attach directly to the external network.


   On Thu, Aug 21, 2014 at 7:06 AM, Bao Wang bywan...@gmail.com wrote:
 I have a very complex Openstack deployment for NFV. It could not be
 deployed as Flat. It will have a lot of isolated private networks.
 Some interfaces of a group VM instances will need bridged network with
 their fixed IP addresses to communicate with outside world while other
 interfaces from the same set of VM should keep isolated with real
 private/fixed IP addresses. What happen if we use public IP addresses
 directly as fixed IP on those interfaces ? Will this work with
 Openstack neutron networking ? Will Openstack do NAT automatically on
 those ?


 Overall, the requirement is to use the fixed/public IP to communicate
 with outside directly on some interfaces of some VM instances while
 keeping others as private. The floating IP is not an option here

 ___
 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




--
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] Feature Proposal Freeze is 9 days away

[Mohammad Banikazemi]

What would be the best practice for those who realize their work will not
make it in Juno? Is it enough to not submit code for review? Would it be
better to also request a change in milestone?

Thanks,

Mohammad




From:   Kyle Mestery mest...@mestery.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   08/12/2014 09:15 AM
Subject:[openstack-dev] [neutron] Feature Proposal Freeze is 9 days
away



Just a reminder that Neutron observes FPF [1], and it's 9 days away.
We have an incredible amount of BPs which do not have code submitted
yet. My suggestion to those who own one of these BPs would be to think
hard about whether or not you can realistically land this code in Juno
before jamming things up at the last minute.

I hope we as a team can refocus on the remaining Juno tasks for the
rest of Juno now and land items of importance to the community at the
end.

Thanks!
Kyle

[1] https://wiki.openstack.org/wiki/FeatureProposalFreeze

___
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

[Mohammad Banikazemi]

Thierry Carrez thie...@openstack.org wrote on 08/07/2014 06:23:56 AM:

 From: Thierry Carrez thie...@openstack.org
 To: openstack-dev@lists.openstack.org
 Date: 08/07/2014 06:25 AM
 Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
 and the way forward

 Armando M. 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.
 I agree with you: it is possible to change your mind on a topic and
 revisit past decisions.
 In past OpenStack history we did revert merged
 commits and remove existing functionality because we felt it wasn't that
 much of a great idea after all. Here we are talking about making the
 right decision *before* the final merging and shipping into a release,
 which is kind of an improvement. The spec system was supposed to help
 limit such cases, but it's not bullet-proof.

 In the end, if there is no consensus on that question within the Neutron
 project (and I hear both sides have good arguments), our governance
 gives the elected Neutron PTL the power to make the final call. If the
 disagreement is between projects (like if Nova disagreed with the
 Neutron decision), then the issue could be escalated to the TC.


It is good to know that the OpenStack governance provides a way to resolve
these issues but I really hope that we can reach a consensus.

Best,

Mohammad



 Regards,

 --
 Thierry Carrez (ttx)

 ___
 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

[Mohammad Banikazemi]

Jay Pipes jaypi...@gmail.com wrote on 08/06/2014 04:09:20 PM:

 From: Jay Pipes jaypi...@gmail.com
 To: openstack-dev@lists.openstack.org
 Date: 08/06/2014 04:12 PM
 Subject: Re: [openstack-dev] Fwd: FW: [Neutron] Group Based Policy
 and the way forward

 On 08/06/2014 03:46 PM, Kevin Benton 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.

 So, in short, GBP is an effort to provide an API that substitutes
 generic names for specific names in order to allow custom proprietary
 hardware vendors to wire in their hardware using an API that better
 matches their own internal modelling.

 Would that be a good statement of the end-goal of GBP?


No. That would be incorrect.
If you have the time, please see the following article. Even though it is
more than a year old, it may help in clarifying the intent of the policy
work.

M. Banikazemi, D, Olshefski, A. Shaikh, J. Tracey, G. Wang, Meridian: an
SDN platform for cloud network services, IEEE Communications Magazine,
vol. 51, no. 2, February 2013

http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=truearnumber=6461196

Best,

-Mohammad


 -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] How to improve the specs review process (was Re: [Neutron] Group Based Policy and the way forward)

[Mohammad Banikazemi]

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.

Best,

Mohammad




From:   Stefano Maffulli stef...@openstack.org
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   08/06/2014 04:47 PM
Subject:Re: [openstack-dev] How to improve the specs review process
(was Re: [Neutron] Group Based Policy and the way forward)



On Wed 06 Aug 2014 01:21:26 PM PDT, Eugene Nikanorov wrote:
 So I don't think it's fair to blame reviewers here.

Just want to be super clear: there is no 'blaming' here. This is a
request to regroup and look at why we are having this conversation about
GBP now, this late in cycle, and about such fundamental topics (the
choice of 'endpoint' as name is only one of them), after in-person
conversations over more than one release cycle and summits.

I am available for the meeting on Monday, Kyle.

In order to prepare for the meeting we should agree on the scope of the
root cause analysis. I think the problem should be framed around the
message Mark McClain sent, especially the Why this email which I quote
below:

 Our community has been discussing and working on Group Based Policy
 (GBP) for many months.  I think the discussion has reached a point
 where we need to openly discuss a few issues before moving forward.
[...]

I think the fact that this very fair question has been raised so late is
the problem we need to find the cause for. Would you agree?

We'll use time during the meeting on Monday to use a simple technique to
investigate this deeply, no need to spend time now and via email.

/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] Auth token in context

[Mohammad Banikazemi]

Yes, Here: https://review.openstack.org/#/c/111756/



From:   Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Cc: isaku.yamah...@gmail.com
Date:   08/04/2014 01:01 PM
Subject:Re: [openstack-dev] 答???: [Neutron] Auth token in context



That makes sense. Is there a patch up for review to make this available in
the context?


On Mon, Aug 4, 2014 at 8:21 AM, Isaku Yamahata isaku.yamah...@gmail.com
wrote:
  ServiceVM wants auth token.
  When creating l3 router which runs inside VM, it launches VM.
  So neutron interacts with other projects like serivcevm server or nova.

  thnaks,


  On Sun, Jul 20, 2014 at 12:14:54AM -0700,
  Kevin Benton blak...@gmail.com wrote:

   That makes sense. Shouldn't we wait for something to require it before
   adding it though?
  
  
   On Sat, Jul 19, 2014 at 11:41 PM, joehuang joehu...@huawei.com wrote:
  
 Hello, Kevin
   
   
   
The leakage risk may be one of the design purpose. But  Nova/Cinder
  has
already stored the token into the context, because Nova needs to
  access
Neutron.Cinder.Glance, And Cinder interact with Glance
   
   
   
For Neutron, I think why the token has not been passed to the
  context, is
because that Neutron only reactively provide service (exactly PORT )
  to
Nova currently, so Neutron has not call other services' API by using
  the
token.
   
   
   
If the underlying agent or plugin wants to use the token, then the
requirement will be asked by somebody.
   
   
   
BR
   
   
   
Joe
   
   
 --
*???件人:* Kevin Benton [blak...@gmail.com]
*???送??:* 2014年7月19日 4:23
   
*收件人:* OpenStack Development Mailing List (not for usage
  questions)
*主???:* Re: [openstack-dev] [Neutron] Auth token in context
   
  I suspect it was just excluded since it is authenticating
  information
and there wasn't a good use case to pass it around everywhere in the
context where it might be leaked into logs or other network requests
unexpectedly.
   
   
On Fri, Jul 18, 2014 at 1:10 PM, Phillip Toohill 
phillip.tooh...@rackspace.com wrote:
   
 It was for more of a potential use to query another service. Don't
think well go this route though, but was curious why it was one of
  the only
values not populated even though there's a field for it.
   
  From: Kevin Benton blak...@gmail.com
Reply-To: OpenStack Development Mailing List (not for usage
  questions)
openstack-dev@lists.openstack.org
Date: Friday, July 18, 2014 2:16 PM
To: OpenStack Development Mailing List (not for usage questions) 
openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [Neutron] Auth token in context
   
  What are you trying to use the token to do?
   
   
On Fri, Jul 18, 2014 at 9:16 AM, Phillip Toohill 
phillip.tooh...@rackspace.com wrote:
   
Excellent! Thank you for the response, I figured it was possible,
  just
concerned me to why everything else made it to context except for
  the
token.
   
So to be clear, you agree that it should at least be passed to
  context
and
because its not could be deemed a bug?
   
Thank you
   
On 7/18/14 2:03 AM, joehuang joehu...@huawei.com wrote:
   
Hello, Phillip.

Currently, Neutron did not pass the token to the context. But
Nova/Cinder
did that. It's easy to do that, just 'copy' from Nova/Cinder.

1.  How Nova/Cinder did that
class NovaKeystoneContext(wsgi.Middleware)
///or CinderKeystoneContext for cinder

              auth_token = req.headers.get('X_AUTH_TOKEN',
                                     req.headers.get
  ('X_STORAGE_TOKEN'))
              ctx = context.RequestContext(user_id,
                                     project_id,
                                     user_name=user_name,
                                     project_name=project_name,
                                     roles=roles,
                                     auth_token=auth_token,

  remote_address=remote_address,

  service_catalog=service_catalog)

2.  Neutron not passed token. Also not good for the third part
  network
infrastructure to integrate the authentication with KeyStone.
class NeutronKeystoneContext(wsgi.Middleware)
.
# token not get from the header and not passed to context.
  Just
change here like what Nova/Cinder did.
        context.Context(user_id, tenant_id, roles=roles,
                              user_name=user_name,
tenant_name=tenant_name,
                              request_id=req_id)
        req.environ['neutron.context'] = ctx

I think I'd better to report a bug for your case.

Best Regards
Chaoyi Huang ( Joe Huang )
-???件原件-
???件人: 

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

[Mohammad Banikazemi]

I don't think another extension is needed. Beyond the CLI, very limited
changes (additions) in the model/db such as those I suggested in [1] can be
helpful and will minimize the changes needed on the client side.

Best,

Mohammad

[1] https://review.openstack.org/#/c/103755/ (Patch Set 3)



From:   Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   07/31/2014 03:01 AM
Subject:Re: [openstack-dev] [neutron][policy] Bridging the 2-group gap
in group policy



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

  

Re: [openstack-dev] [neutron] [third-party] Update on third party CI in Neutron

[Mohammad Banikazemi]

Thanks Kyle for the update. As noted below, we have been in the process of upgrading the SDN-VE CI system to a Zuul based system and this has caused an interruption in our voting. We have resolved the issues we were facing with standing up our new system and are close to having our system voting again. Daya (dkam...@us.ibm.com)who owns our new CI system (and myself) will be participating in the Third Party Testing meetings on Monday and onward.Best,Mohammad-Kyle Mestery mest...@noironetworks.com wrote: -To: "OpenStack Development Mailing List (not for usage questions)" openstack-dev@lists.openstack.orgFrom: Kyle Mestery mest...@noironetworks.comDate: 07/11/2014 11:58AMSubject: [openstack-dev] [neutron] [third-party] Update on third party CI in	NeutronSince Juno-2 is quickly approaching, I wanted to update everyone on wherewe're at with regards to third party testing in Neutron. The etherpad here [1]was the original link with status. The link here [2] shows what is expected of
Neutron third party CI systems.On the CI status side, I'd like to ask the owners of the following CI systemsto attend Monday's third party meeting [3] to discuss the status of their CIsystems. These are the ones which appear to be in trouble, aren't running,
or have some issues.CiscoNot enough logs being saved.Log retention issues.Citrix Netscaler LBaaS driverI don't think this has a third party CI system running.
Embrane (both plugin and LBaaS driver)Logs are tarred up and not viewable in web browser.Inconsistent runs at times.IBM SDN-VECurrently inactive, moving to a new system.
One ConvergenceVery high failure rate for patch runs.OpenDaylightLogs are tarred up and not viewable in web browserPLUMgridNot saving enough logs
RadwareLogs are not viewable in browserTail-FInconsistent past runs, need updates on status.vArmour FWaaS driverCan't view logs.Inconsistent runs against patches.
I'd like to take some time in the Monday meeting to go over the issues theseCI systems are having and give the maintainers a chance to discuss this withus. The third party team is hopeful we can spend the energy in the meeting
working with CI maintainers who are actively interested in making progresson improving their CI systems.Per my email to the list in June [4], the expectation is that third party CIsystems in Neutron are running and following the guidelines set forth by
both Neutron and Infra. The weekly meeting is a place to seek help, andwe're happy that a large number of third party CI owners and maintainersare using this resource.I'd also like to encourange anyone with a patch for a plugin or driver in Neutron
to participate in the third-party meetings going forward as well. This will helpto ensure your CI system is running while your patch is being reviewed, and youactively work to sort out issues during the review process to ensure smooth
merging of your plugin or driver.Thank you!Kyle[1] https://etherpad.openstack.org/p/ZLp9Ow3tNq[2] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
[3] https://wiki.openstack.org/wiki/Meetings/ThirdParty[4] http://lists.openstack.org/pipermail/openstack-dev/2014-June/037665.html

___OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://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][ML2] Modular L2 agent architecture

[Mohammad Banikazemi]

Zang, thanks for your comments.

I think what you are suggesting is perhaps orthogonal to having Resource
and Agent drivers. By that I mean we can have what you are suggesting and
keep the Resource and Agent drivers. The reason for having Resource drivers
is to provide the means for possibly extending what an agent does in
response to say changes to a port in a modular way. We can restrict the
access to Resource drivers from the events loop only. That restriction is
not there in the current model but would adding that address your concerns?
What are your thoughts? As Salvatore has mentioned in his email in this
thread, that is what the current OVS agent does wrt port updates. That is,
the update to ports get processed from the events loop.

As a separate but relevant issue, we can and should discuss whether having
the Resource and Agent drivers is useful in making the agent more modular.
The idea behind using these drivers is to have the agent use a collection
of drivers rather than mixin classes so we can more easily select what
(and how) functionalities an agent support and reuse as much as we can
across L2 agents. Are there better ways of achieving this? Any thoughts?

Best,

Mohammad





From:   Zang MingJie zealot0...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   06/19/2014 06:27 AM
Subject:Re: [openstack-dev] [Neutron][ML2] Modular L2 agent
architecture



Hi:

I don't like the idea of ResourceDriver and AgentDriver. I suggested
use a singleton worker thread to manager all underlying setup, so the
driver should do nothing other than fire a update event to the worker.

The worker thread may looks like this one:

# the only variable store all local state which survives between
different events, including lvm, fdb or whatever
state = {}

# loop forever
while True:
event = ev_queue.pop()
if not event:
sleep() # may be interrupted when new event comes
continue

origin_state = state
new_state = event.merge_state(state)

if event.is_ovsdb_changed():
if event.is_tunnel_changed():
setup_tunnel(new_state, old_state, event)
if event.is_port_tags_changed():
setup_port_tags(new_state, old_state, event)

if event.is_flow_changed():
if event.is_flow_table_1_changed():
setup_flow_table_1(new_state, old_state, event)
if event.is_flow_table_2_changed():
setup_flow_table_2(new_state, old_state, event)
if event.is_flow_table_3_changed():
setup_flow_table_3(new_state, old_state, event)
if event.is_flow_table_4_changed():
setup_flow_table_4(new_state, old_state, event)

if event.is_iptable_changed():
if event.is_iptable_nat_changed():
setup_iptable_nat(new_state, old_state, event)
if event.is_iptable_filter_changed():
setup_iptable_filter(new_state, old_state, event)

   state = new_state

when any part has been changed by a event, the corresponding setup_xxx
function rebuild the whole part, then use the restore like
`iptables-restore` or `ovs-ofctl replace-flows` to reset the whole
part.

___
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] Help in writing new neutron plugin

[Mohammad Banikazemi]

Have you looked at https://wiki.openstack.org/wiki/NeutronDevelopment
In particular, this section may be useful to you: Developing a Neutron
Plugin

You may also want to look at the following presentation/talk and look for
more such presentations from OpenStack Summits:

http://www.slideshare.net/mestery/modular-layer-2-in-openstack-neutron
https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/openstack-neutron-modular-layer-2-plugin-deep-dive

Hope this helps,

Mohammad





From:   shiva m anjane...@gmail.com
To: openstack-dev@lists.openstack.org,
Date:   06/19/2014 07:22 AM
Subject:[openstack-dev] Help in writing new neutron plugin



HI,

I am looking at documents to understand how to write a new neutron plugin.
I working with devstack with ryu setup from last 4 months. I am trying to
write some test plugin to get hands-on.

Can any one please help where to start looking neutron code, where to embed
new code. Also I am looking for beginner kind of documentation to write ML2
type driver and mechanism drivers,


Thanks
Shiva___
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][ml2] Tracking the reviews for ML2 related specs

[Mohammad Banikazemi]

Hi Irena,

The R columns are for non-core subgroup reviews and the C columns are
for the core reviewers.
As of now, we only have specs listed/tracked in this wiki. Expanding the
wiki to include the code was briefly discussed last week. One option that
comes to mind is expanding the table for merged specs (the second table in
the wiki page) for tracking the reviews of the code. I have updated that
table and you and others can update the row for your specs and we can
discuss during the ML2 meeting and see if others see this as helpful. I
think considering the limited number of specs/code being tracked this may
be helpful as long as the code owners keep the table up to date.

Best,

Mohammad




From:   Irena Berezovsky ire...@mellanox.com
To: Mohammad Banikazemi/Watson/IBM@IBMUS,
Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   06/15/2014 12:51 AM
Subject:RE: [openstack-dev] [Neutron][ml2] Tracking the reviews for ML2
related specs



Hi Mohammad,
Thank you for sharing the links.
Can you please elaborate on columns of the table in [1]. Is [R] supposed to
be for spec review and [C] for code review?
If this correct, would it be possible to add [C] columns for already merged
specs that still have the code under review?

Thanks a lot,
Irena

From: Mohammad Banikazemi [mailto:m...@us.ibm.com]
Sent: Friday, June 13, 2014 8:02 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Neutron][ml2] Tracking the reviews for ML2
related specs



In order to make the review process a bit easier (without duplicating too
much data and without creating too much overhead), we have created a wiki
to keep track of the ML2 related specs for the Juno cycle [1]. The idea is
to organize the people who participate in the ML2 subgroup activities and
get the related specs reviewed as much as possible in the subgroup before
asking the broader community to review. (There is of course nothing that
prevents others from reviewing these specs as soon as they are available
for review.) If you have any ML2 related spec under review or being
planned, you may want to update the wiki [1] accordingly.

We will see if this will be useful or not. If you have any comments or
suggestions please post here or bring them to the IRC weekly meetings [2].

Best,

Mohammad

[1] https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
[2] https://wiki.openstack.org/wiki/Meetings/ML2

___
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

[Mohammad Banikazemi]

I had tried to address the comment on the review board where Carlos had
raised the same issue. Should have posted here as well.

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

Patch Set 3:
Carlos, The plan is not to have multiple drivers for enforcing policies. At
least not right now. With respect to using same config options by drivers,
we can have a given group policy driver and possibly an ML2 mechanism
driver use the same config namespace. Does this answer your questions?

Best,

Mohammad



From:   Sumit Naiksatam sumitnaiksa...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   06/12/2014 01:10 PM
Subject:Re: [openstack-dev] [neutron][group-based-policy] GP mapping
driver



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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][ml2] Tracking the reviews for ML2 related specs

[Mohammad Banikazemi]

In order to make the review process a bit easier (without duplicating too
much data and without creating too much overhead), we have created a wiki
to keep track of the ML2 related specs for the Juno cycle [1]. The idea is
to organize the people who participate in the ML2 subgroup activities and
get the related specs reviewed as much as possible in the subgroup before
asking the broader community to review. (There is of course nothing that
prevents others from reviewing these specs as soon as they are available
for review.) If you have any ML2 related spec under review or being
planned, you may want to update the wiki [1] accordingly.

We will see if this will be useful or not. If you have any comments or
suggestions please post here or bring them to the IRC weekly meetings [2].

Best,

Mohammad

[1] https://wiki.openstack.org/wiki/Tracking_ML2_Subgroup_Reviews
[2] https://wiki.openstack.org/wiki/Meetings/ML2___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron][ML2] Modular L2 agent architecture

[Mohammad Banikazemi]

Following the discussions in the ML2 subgroup weekly meetings, I have added
more information on the etherpad [1] describing the proposed architecture
for modular L2 agents. I have also posted some code fragments at [2]
sketching the implementation of the proposed architecture. Please have a
look when you get a chance and let us know if you have any comments.

[1] https://etherpad.openstack.org/p/modular-l2-agent-outline
[2] https://review.openstack.org/#/c/99187/___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][ML2] Modular agent architecture

[Mohammad Banikazemi]

Hi Mathieu,

Thanks for the email. As discussed during the ML2 IRC meeting [2], we have
not decided on a design. That is why we do not have a spec for review yet.
The idea is that we spend a bit more time and figure out the details and
try out some possible options before we go ahead with the spec. So new
comments/suggestions are much appreciated.

In addition to having different drivers we want to reduce the code
replication across current agents. I am wondering if with what you are
proposing as dataplane drivers, we will end up with having different
drivers which look like the current agents and we do not deal with reducing
code replication across agents. If this is not a correct assessment could
you describe how we can avoid code replication across agents/drivers.

Let me briefly explain what I have outlined in [3] (also mentioned in [2]).
We are thinking of having drivers for each extension or probably better
said each functionality. So we can have a base l2 connectivity driver, an
l2pop driver, a sg driver (not to be confused with sq drivers), so on so
forth. I think in your email you are referring to these drivers (or
something close to them) as Extension drivers. In [3] they are called Agent
Drivers.

Then we have the Resource Drivers which will be essentially used for
realizing these features depending on the technology/resource being used
(e.g., using  OVS switches, or Linux Bridges, or some other technology).
The main reason for using such a organization is to be able to have
different agent drivers utilize the same resource and reuse code. The
challenge is figuring out the api for such a driver. Any thoughts on this?

Mohammad

[3] https://etherpad.openstack.org/p/modular-l2-agent-outline




From:   Mathieu Rohon mathieu.ro...@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org, Mohammad
Banikazemi/Watson/IBM@IBMUS,
Date:   05/30/2014 06:25 AM
Subject:[openstack-dev][Neutron][ML2] Modular agent architecture



Hi all,

Modular agent seems to have to choose between two type of architecture [1].

As I understood during the last ML2 meeting [2], Extension driver
seems to be the most reasonnable choice.
But I think that those two approaches are complementory : Extension
drivers will deal with RPC callbacks form the plugin, wheras Agent
drivers will deal with controlling the underlying technology to
interpret those callbacks.

It looks like a controlPlane/Dataplane architecture. Could we have a
control plane manager on which each Extension driver should register
(and register callbacks it is listening at), and a data plane manager,
on which each dataplane controller will register (ofagent, ovs, LB..),
and which implement a common abastract class.
A port will be managed by only one dataplane controller, and when a
control plane driver wants to apply a modification on a port, it will
retrieve the correct dataplane controller for this port in order to
call one of the abstracted method to modify the dataplane.


[1]
https://wiki.openstack.org/wiki/Neutron/ModularL2Agent#Possible_Directions
[2]
http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-05-28-16.02.log.html


___
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

[Mohammad Banikazemi]

Thanks for the continued interest in discussing Group Policy (GP). I
believe these discussions with the larger Neutron community can benefit the
GP work.

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.

Please note that for better or worse we have produced several documents
during the previous cycle. We have tried to collect them on the GP wiki
page [1]. The latest design document [2] should give a broad view of the GP
extension and the model being proposed. The PoC document [3] may clarify
our PoC plans and where the mapping driver stands wrt other pieces of the
work.  (Please note some parts of the plan as described in the PoC document
was not implemented.)

Hope my explanation and these documents (and other documents available on
the GP wiki) are helpful.

Best,

Mohammad

[1] https://wiki.openstack.org/wiki/Neutron/GroupPolicy   - GP wiki
page
[2]
https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/
- GP design document
[3]
https://docs.google.com/document/d/14UyvBkptmrxB9FsWEP8PEGv9kLqTQbsmlRxnqeF9Be8/
- GP PoC document




From:   Armando M. arma...@gmail.com
To: OpenStack Development Mailing List, (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   05/26/2014 09:46 PM
Subject:Re: [openstack-dev] [neutron][group-based-policy] GP mapping
driver




On May 26, 2014 4:27 PM, Mohammad Banikazemi m...@us.ibm.com wrote:

 Armando,

 I think there are a couple of things that are being mixed up here, at
least as I see this conversation :). The mapping driver is simply one way
of implementing GP. Ideally I would say, you do not need to implement the
GP in terms of other Neutron abstractions even though you may choose to do
so. A network controller could realize the connectivities and policies
defined by GP independent of say networks, and subnets. If we agree on this
point, then how we organize the code will be different than the case where
GP is always defined as something on top of current neutron API. In other
words, we shouldn't organize the overall code for GP based solely on the
use of the mapping driver.


The mapping driver is embedded in the policy framework that Bob had
initially proposed. If I understood what you're suggesting correctly, it
makes very little sense to diverge or come up with a different framework
alongside the legacy driver later on, otherwise we may end up in the same
state of the core plugins': monolithic vs ml2-based. Could you clarify?

 In the mapping driver (aka the legacy driver) for the PoC, GP is
implemented in terms of other Neutron abstractions. I agree that using
python-neutronclient for the PoC would be fine and as Bob has mentioned it
would have been probably the best/easiest way of having the PoC implemented
in the first place. The calls to python-neutronclient in my understanding
could be eventually easily replaced with direct calls after refactoring
which lead me to ask a question concerning the following part of the
conversation (being copied here again):


Not sure why we keep bringing this refactoring up: my point is that if GP
were to be implemented the way I'm suggesting the refactoring would have no
impact on GP...even if it did, replacing remote with direct calls should be
avoided IMO.




 [Bob:]

   The overhead of using python-neutronclient is that unnecessary
   serialization/deserialization are performed as well as socket
communication
   through the kernel. This is all required between processes, but not
within a
   single process. A well-defined and efficient mechanism to invoke
resource
   APIs within the process, with the same semantics as incoming REST
calls,
   seems like a generally useful addition to neutron. I'm hopeful the
core
   refactoring effort will provide this (and am willing to help make
sure it
   does), but we need something we can use until that is available.
  

 [Armando:]

  I appreciate that there is a cost involved in relying on distributed
  communication, but this must be negligible considered what needs to
  happen end-to-end. If the overhead being referred here is the price to
  pay for having a more dependable system (e.g. because things can be
  scaled out and/or made reliable independently), then I think this is a
  price worth paying.
 
  I do hope that the core refactoring is not aiming at what you're
  suggesting, as it sounds in exact opposition to some of the OpenStack
  design

Re: [openstack-dev] [neutron][group-based-policy] GP mapping driver

[Mohammad Banikazemi]

Armando,

I think there are a couple of things that are being mixed up here, at least
as I see this conversation :). The mapping driver is simply one way of
implementing GP. Ideally I would say, you do not need to implement the GP
in terms of other Neutron abstractions even though you may choose to do so.
A network controller could realize the connectivities and policies defined
by GP independent of say networks, and subnets. If we agree on this point,
then how we organize the code will be different than the case where GP is
always defined as something on top of current neutron API. In other words,
we shouldn't organize the overall code for GP based solely on the use of
the mapping driver.

In the mapping driver (aka the legacy driver) for the PoC, GP is
implemented in terms of other Neutron abstractions. I agree that using
python-neutronclient for the PoC would be fine and as Bob has mentioned it
would have been probably the best/easiest way of having the PoC implemented
in the first place. The calls to python-neutronclient in my understanding
could be eventually easily replaced with direct calls after refactoring
which lead me to ask a question concerning the following part of the
conversation (being copied here again):


[Bob:]
  The overhead of using python-neutronclient is that unnecessary
  serialization/deserialization are performed as well as socket
communication
  through the kernel. This is all required between processes, but not
within a
  single process. A well-defined and efficient mechanism to invoke
resource
  APIs within the process, with the same semantics as incoming REST
calls,
  seems like a generally useful addition to neutron. I'm hopeful the core
  refactoring effort will provide this (and am willing to help make sure
it
  does), but we need something we can use until that is available.
 

[Armando:]
 I appreciate that there is a cost involved in relying on distributed
 communication, but this must be negligible considered what needs to
 happen end-to-end. If the overhead being referred here is the price to
 pay for having a more dependable system (e.g. because things can be
 scaled out and/or made reliable independently), then I think this is a
 price worth paying.

 I do hope that the core refactoring is not aiming at what you're
 suggesting, as it sounds in exact opposition to some of the OpenStack
 design principles.

From the summit sessions (in particular the session by Mark on refactoring
the core), I too was under the impression that there will be a way of
invoking Neutron API within the plugin with the same semantics as through
the REST API. Is this a misunderstanding?

Best,

Mohammad







Armando M. arma...@gmail.com wrote on 05/24/2014 01:36:35 PM:

 From: Armando M. arma...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 05/24/2014 01:38 PM
 Subject: Re: [openstack-dev] [neutron][group-based-policy] GP mapping
driver

 On 24 May 2014 05:20, Robert Kukura kuk...@noironetworks.com wrote:
 
  On 5/23/14, 10:54 PM, Armando M. wrote:
 
  On 23 May 2014 12:31, Robert Kukura kuk...@noironetworks.com wrote:
 
  On 5/23/14, 12:46 AM, Mandeep Dhami wrote:
 
  Hi Armando:
 
  Those are good points. I will let Bob Kukura chime in on the
specifics of
  how we intend to do that integration. But if what you see in the
  prototype/PoC was our final design for integration with Neutron core,
I
  would be worried about that too. That specific part of the code
  (events/notifications for DHCP) was done in that way just for the
  prototype
  - to allow us to experiment with the part that was new and needed
  experimentation, the APIs and the model.
 
  That is the exact reason that we did not initially check the code to
  gerrit
  - so that we do not confuse the review process with the prototype
  process.
  But we were requested by other cores to check in even the prototype
code
  as
  WIP patches to allow for review of the API parts. That can
unfortunately
  create this very misunderstanding. For the review, I would recommend
not
  the
  WIP patches, as they contain the prototype parts as well, but just
the
  final
  patches that are not marked WIP. If you such issues in that part of
the
  code, please DO raise that as that would be code that we intend to
  upstream.
 
  I believe Bob did discuss the specifics of this integration issue
with
  you
  at the summit, but like I said it is best if he represents that side
  himself.
 
  Armando and Mandeep,
 
  Right, we do need a workable solution for the GBP driver to invoke
  neutron
  API operations, and this came up at the summit.
 
  We started out in the PoC directly calling the plugin, as is
currently
  done
  when creating ports for agents. But this is not sufficient because
the
  DHCP
  notifications, and I think the nova notifications, are needed for VM
  ports.
  We also really should be generating the other notifications,
enforcing
  quotas, etc. for the 

Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services Research Thesis Applicability to the OpenStack Project

[Mohammad Banikazemi]

Hi Mike. I think we still owe you a response to your earlier email as we
recover from the summit but let me address your current questions below.

 On May 22, 2014, at 6:55 PM, Mike Grima mike.r.gr...@gmail.com wrote:

 Hello,

 Just to make sure I understand:

 1.) I’m assuming that you can dilettante which policies apply to specific
VM’s within a group (Is this correct?).  With regards to DENY permissions,
they are handled specially.  In such a case, all other VM’s are provided
with ALLOW permissions for that rule, while the destined VM for the DENY
policy is provided with a DENY.
Let's start from the question about Deny. There are no Deny actions. By
default there is no connectivity. If you want to establish that you do it
with Allow or other actions; otherwise no connectivity. Hence no need to
have Deny.

The policies generally apply to the whole group. The idea is to simplify
the use of contract and policy rules by applying them to a group of like
minded :) endpoints.
 — Would you necessarily want to automatically provide all other VM’s with
an ALLOW privilege?  Not all VM’s in that group may need access to that
port...

So you may reconsider how you group your endpoints into groups so you can
apply policies to groups of endpoints with similar characteristics/roles.

 2.) Group Policy does support a Hierarchy. (Is this correct?)


Yes. A contract can have another as a child contract.
 3.) On a separate note: Is the Group Policy feature exposed via a RESTful
API akin to FWaaS?

Yes, That's the plan for the group policy extension similar to other
extensions.


 Thank you,

 Mike Grima, RHCE


 On May 22, 2014, at 2:08 AM, A, Keshava keshav...@hp.com wrote:

  Hi,
 
  1. When the group policy is applied ( across to all the VMs ) say deny
for specific TCP port = 80, however because some special reason one of that
VM needs to 'ALLOW TCP port' how to handle this ?
  When deny is applied to any one of VM in that group ,   this framework
takes care of
  individually breaking that and apply ALLOW for other VM
automatically ?
  and apply Deny for that specific VM ?
 
  2. Can there be 'Hierarchy of Group Policy  ?
 
 
 
  Thanks  regards,
  Keshava.A
 
  -Original Message-
  From: Michael Grima [mailto:mike.r.gr...@gmail.com]
  Sent: Wednesday, May 21, 2014 5:00 PM
  To: openstack-dev@lists.openstack.org
  Subject: Re: [openstack-dev] [Neutron][FWaaS]Firewall Web Services
Research Thesis Applicability to the OpenStack Project
 
  Sumit,
 
  Unfortunately, I missed the IRC meeting on FWaaS (got the timezones
screwed up...).
 
  However, in the meantime, please review this section of my thesis on
the OpenStack project:
 
https://docs.google.com/document/d/1DGhgtTY4FxYxOqhKvMSV20cIw5WWR-gXbaBoMMMA-f0/edit?usp=sharing

 
  Please let me know if it is missing anything, or contains any wrong
information.  Also, if you have some time, please review the questions I
have asked in the previous messages.
 
  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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] reservation of fixed ip

[Mohammad Banikazemi]

Well, for a use case we had in mind we were trying to figure out how to
simply get an IP address on a subnet. We essentially want to use such an
address internally by the controller and make sure it is not used for a
port that gets created on a network with that subnet. In this use case, an
interface to IPAM for removing an address from the pool of available
addresses (and the interface to possibly return the address to the pool)
would be sufficient.

Mohammad



From:   Carl Baldwin c...@ecbaldwin.net
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   05/22/2014 06:19 PM
Subject:Re: [openstack-dev] [Neutron] reservation of fixed ip



If an IP is reserved for a tenant, should the tenant need to
explicitly ask for that specific IP to be allocated when creating a
floating ip or port?  And it would pull from the regular pool if a
specific IP is not requested.  Or, does the allocator just pull from
the tenant's reserved pool whenever it needs an IP on a subnet?  If
the latter, then I think Salvatore's concern still a valid one.

I think if a tenant wants an IP address reserved then he probably has
a specific purpose for that IP address in mind.  That leads me to
think that he should be required to pass the specific address when
creating the associated object in order to make use of it.  We can't
do that yet with all types of allocations but there are reviews in
progress [1][2].

Carl

[1] https://review.openstack.org/#/c/70286/
[2] https://review.openstack.org/#/c/83664/

On Thu, May 22, 2014 at 12:04 PM, Sławek Kapłoński sla...@kaplonski.pl
wrote:
 Hello


 Dnia Wed, 21 May 2014 23:51:48 +0100
 Salvatore Orlando sorla...@nicira.com napisał:

 In principle there is nothing that should prevent us from
 implementing an IP reservation mechanism.

 As with anything, the first thing to check is literature or related
 work! If any other IaaS system is implementing such a mechanism, is
 it exposed through the API somehow?
 Also this feature is likely to be provided by IPAM systems. If yes,
 what constructs do they use?
 I do not have the answers to this questions, but I'll try to document
 myself; if you have them - please post them here.

 This new feature would probably be baked into neutron's IPAM logic.
 When allocating an IP, first check from within the IP reservation
 pool, and then if it's not found check from standard allocation pools
 (this has non negligible impact on availability ranges management, but
 these are implementation details).
 Aspects to consider, requirement-wise, are:
 1) Should reservations also be classified by qualification of the
 port? For instance, is it important to specify that an IP should be
 used for the gateway port rather than for a floating IP port?

 IMHO it is not required when IP is reserved. User should have
 possibility to reserve such IP for his tenant and later use it as he
 want (floating ip, instance or whatever)

 2) Are reservations something that an admin could specify on a
 tenant-basis (hence an admin API extension), or an implicit mechanism
 that can be tuned using configuration variables (for instance create
 an IP reservation a for gateway port for a given tenant when a router
 gateway is set).

 I apologise if these questions are dumb. I'm just trying to frame this
 discussion into something which could then possibly lead to
 submitting a specification.

 Salvatore


 On 21 May 2014 21:37, Collins, Sean sean_colli...@cable.comcast.com
 wrote:

  (Edited the subject since a lot of people filter based on the
  subject line)
 
  I would also be interested in reserved IPs - since we do not deploy
  the layer 3 agent and use the provider networking extension and a
  hardware router.
 
  On Wed, May 21, 2014 at 03:46:53PM EDT, Sławek Kapłoński wrote:
   Hello,
  
   Ok, I found that now there is probably no such feature to reserve
   fixed ip for tenant. So I was thinking about add such feature to
   neutron. I mean that it should have new table with reserved ips
   in neutron database and neutron will check this table every time
   when new port will be created (or updated) and IP should be
   associated with this port. If user has got reserved IP it should
   be then used for new port, if IP is reserver by other tenant - it
   shouldn't be used. What You are thinking about such possibility?
   Is it possible to add it in some future release of neutron?
  
   --
   Best regards
   Sławek Kapłoński
   sla...@kaplonski.pl
  
  
   Dnia Mon, 19 May 2014 20:07:43 +0200
   Sławek Kapłoński sla...@kaplonski.pl napisał:
  
Hello,
   
I'm using openstack with neutron and ML2 plugin. Is there any
way to reserve fixed IP from shared external network for one
tenant? I know that there is possibility to create port with IP
and later connect VM to this port. This solution is almost ok
for me but problem is when user delete this instance - then
port is also deleted and 

Re: [openstack-dev] [neutron][group-based-policy] Should we revisit the priority of group-based policy?

[Mohammad Banikazemi]

Thanks to everyone who participated in the Group Policy meeting [1] earlier
today. A lot of good discussion that hopefully will continue with
participation from the larger community. I wanted to first make a comment
about how the Group Policy work was received outside the Neutron community
and then focus on finding a way for us to make progress.

I think we had a really good feedback from the larger OpenStack community
and I would say a wide support for addition of policy abstractions to
Neutron. If the feedback we received at the summit in Hong Kong was mostly
positive, in Atlanta the support was overwhelmingly positive in my opinion.
I just wanted to make sure this does not get lost in our discussions.

Needless to say, we will work on a path to have the Group Policy work
included in Neutron in a way that keeps the quality of code in Neutron
preserved. To rephrase what Armando said in the IRC meeting earlier today,
we all share a common goal and that is to do what's right. I think it may
be beneficial that for the moment and for the next few days as we try to
find the best path forward, we forget about any particular
cycle/milestone/priority and look for the best path forward and see where
that leads us. To this end, the group policy team will be setting up a
meeting with Armando (and others who are interested) to in particular
discuss the possibility of making the code less tightly coupled with
Neutron core. We will also consider how we can address Marun's and Mark's
concerns by trying to have a simpler but functional set of patches that can
be reviewed more effectively such that we can build on them in an iterative
manner.

Meanwhile, please do continue the discussion on the mailing list.

Best,

Mohammad

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



From:   Armando M. arma...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   05/22/2014 11:24 PM
Subject:Re: [openstack-dev] [neutron][group-based-policy] Should we
revisit the priority of group-based policy?



On 22 May 2014 13:59, Mandeep Dhami dh...@noironetworks.com wrote:

 Maru's concerns are that:
 1. It is large
 2. It is complex

 And Armando's related concerns are:
 3. Could dev/review cycles be better spent on refactoring
 4. If refactored neutron was available, would a simpler option become
more
 viable

This is not what I meant to say, and if this was the message that came
across I apologize for the confusion; let me rephrase:

After looking (and relooking) at the initial patches proposed I
started to question why the GP plugin functionality was so tightly
integrated with the Neutron core functionality; even though I might
guess the thinking process, I wonder if such tight coupling was the
result of design decisions made without thoroughly considering
alternative approaches. Without going too much into details during
this email, I can see in the above mentioned patches that lots of
plumbing code (like Nova and dhcp notifiers handling code) is put in
place to make direct calls to core plugin methods: this spills
implementation details across multiple parts of the project; it's
fragile because it's prone to ripple effects due to lack of proper
encapsulation: if a change is made in the plugin API or its
implementation, the whole thing needs to be looked at, end-to-end:
this does not scale from a human perspective (probably only a handful
of people can really say that they know the Neutron codebase
inside-out), it is difficult to maintain, it is difficult to test, it
is difficult to extend. etc etc.

Instead, I was advocating for an approach where GP and Neutron Core
integrate via (a well defined and stable) REST API, or similar (more
abstracted) mechanisms; this has obvious benefits because the two
become suddenly loosely coupled: a change done in the way Neutron
deals with DHCP messages is not going to have any effect to how the GP
plugin create resources. Also, any potential refactoring of the
Neutron Core will not cause the GP team to take the burden of bringing
the current implementation forward.

This is why I was proposing that we talk about the introduction of
integration hooks, should they (or lack thereof) have been the culprit
of such an initial design approach. Please, take my comments as
initial reviews to the above patches, if you will :)

To be constructive, as a core reviewer who should suggest
alternatives, I would invite the people reading this thread to have a
look at [1] and [2]: these were introduced by RAX to their cut of
Neutron, having in mind exactly what I have been saying: adding
functionality with zero impact to existing code. If something along
those lines can be achieved, then this would be very beneficial for
the progress of the GP effort as it transitions and evolves
into/within Neutron, IMO.

Having said that, I am making these points without particular
reference to the complexity of 

Re: [openstack-dev] [Neutron] ML2 extensions info propagation

[Mohammad Banikazemi]

Hi Mathieu,

Yes, the enhancement of the get_device_details method sounds like an
interesting and useful option.
The option of using drivers in the agent for supporting extensions is to
make the agent more modular and allow for selectively supporting extensions
as needed by a given agent. If we take the approach you are suggesting and
eliminate or reduce the use of extension specific RPCs how can we achieve
the modularity goal above? Is there a way to make these options useful
together? More broadly, what would be the impact of your proposal on the
modularity of the agent (if any)?

Please note that as per discussion during the ML2 meeting yesterday we are
going to have a single etherpad for each of ML2 sessions. The etherpad for
the Modular Layer 2 Agent session can be found at [2] from your original
email below. We may reorganize the information that is already there but
please do add your comments there.

Thanks,

Mohammad




From:   Mathieu Rohon mathieu.ro...@gmail.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
Date:   05/07/2014 10:25 AM
Subject:[openstack-dev] [Neutron] ML2 extensions info propagation



Hi ML2er and others,

I'm considering discussions around ML2 for the summit. Unfortunatly I
won't attend the summit, so I'll try to participate through the
mailing list and etherpads.

I'm especially interested in extension support by Mechanism Driver[1]
and Modular agent[2]. During the Juno cycle I'll work on the capacity
to propagate IPVPN informations (route-target) down to the agent, so
that the agent can manage MPLS encapsulation.
I think that the easiest way to do that is to enhance
get_device_details() RPC message to add network extension informations
of the concerned port in the dict sent.

Moreover I think this approach could be generalized, and
get_device_details() in the agent should return serialized information
of a port with every extension informations (security_group,
port_binding...). When the core datamodel or the extension datamodel
would be modified, this would result in a port_update() with the
updated serialization of the datamodel. This way, we could get rid of
security-group and l2pop RPC. Modular agent wouldn't need to deal with
one driver by extension which need to register its RPC callbacks.

Those informations should also be stored in ML2 driver context. When a
port is created by ML2 plugin, it calls super() for creating core
datamodel, which will return a dict without extension informations,
because extension informations in the Rest call has not been processed
yet. But once the plugin call its core extension, it should call MD
registered extensions as proposed by nader here [4] and then call
make_port_dict(with extension), or an equivalent serialization
function, to create the driver context. this seralization function
would be used by get_device_details() RPC callbacks too.

Regards,

Mathieu

[1]https://etherpad.openstack.org/p/ML2_mechanismdriver_extensions_support
[2]https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
[3]http://summit.openstack.org/cfp/details/240
[4]https://review.openstack.org/#/c/89211/

___
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][QoS] Interest in a meeting at the Networking pod at the design summit?

[Mohammad Banikazemi]

Sounds good.  Thanks.

Mohammad

On May 8, 2014, at 3:02 PM, Stephen Wong s3w...@midokura.com wrote:

Hi Sean,

    Perfect (I assume it is local time, i.e. 2:30pm EDT).

    And I also assume this will be at the Neutron pod?

- Stephen


On Thu, May 8, 2014 at 9:22 AM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:
On Tue, May 06, 2014 at 07:17:26PM EDT, Mohammad Banikazemi wrote:

 There are networking talks in the general session in the afternoon on
 Thursday including the talk on Network Policies from 1:30 to 2:10pm.
 Anything after that is ok with me.

How does 2:30PM on Thursday sound to everyone?

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

___
OpenStack-dev mailing listopenstack-...@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] Mid-Cycle Meeting Location

[Mohammad Banikazemi]

Kyle Mestery mest...@noironetworks.com wrote on 05/08/2014 04:45:43 PM:

 From: Kyle Mestery mest...@noironetworks.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 05/08/2014 04:46 PM
 Subject: [openstack-dev] [neutron] Mid-Cycle Meeting Location

 Hi everyone:

 I've settled on a date, location, and agenda for the Neutron mid-cycle
 Meeting. The logistical information is at the etherpad referenced
 below [1]. The tl;dr for those curious:

 Date: July 9-11
 Location: Cisco office in Bloomington, MN
 Agenda: nova-network parity sprint and completion of tasks

 I've setup a hotel block of 15 rooms at this point, please add
 yourself to the list of attendees so I can track the room block
 reservation. The hotel is within walking distance of the Cisco office.
 There are lots of other hotels all very close as well.

 Thanks, looking forward to seeing everyone next week as well as at the
 Mid-Cycle Meeting!

 Kyle

 [1] https://etherpad.openstack.org/p/neutron-juno-mid-cycle-meeting


Please bear with me as I ask a question on nova-network parity work items
that may have been addressed earlier. Is the auto-associating floating IPs
part of the work items? I see a blueprint on this topic [2] but do not see
it listed in [3] or [4].

Thanks,

Mohammad


[2]
https://blueprints.launchpad.net/neutron/+spec/auto-associate-floating-ip
[3] https://etherpad.openstack.org/p/neutron-nova-parity
[4]
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Mohammad Banikazemi]

+1.

Please announce a date/time here so we can perhaps avoid any conflicts with
others who plan to use the networking pod.

Best,

Mohammad



From:   Stephen Wong s3w...@midokura.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   05/06/2014 12:39 PM
Subject:Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the
Networking pod at the design summit?



Hi Sean,

    Yes. Please count me in (we need to integrate QoS parameters as
possible actions for group-policy).

Thanks,
- Stephen


On Tue, May 6, 2014 at 9:19 AM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:
  For those attending, to discuss the QoS API current status?

  --
  Sean M. Collins
  ___
  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] [Neutron][ml2] Etherpad for the design session on Modular L2 Agents

[Mohammad Banikazemi]

Please note that I have created an etherpad for the Modular L2 Agent
session at [1].
It relates to one of the three topics that are to be discussed during the
Modular Layer2 Agent design session scheduled for Thursday
11:50am-12:30pm [2].
Please update the etherpad and/or use the ML or contact me if you have any
comments/suggestions/criticism. (I have also asked several people who have
worked on the agents and/or expressed interest in this topic individually
for their input.)

Thanks,

-Mohammad

[1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
[2]
http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the Networking pod at the design summit?

[Mohammad Banikazemi]

There are networking talks in the general session in the afternoon on
Thursday including the talk on Network Policies from 1:30 to 2:10pm.
Anything after that is ok with me.

Thanks,

Mohammad




From:   Kevin Benton blak...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   05/06/2014 07:08 PM
Subject:Re: [openstack-dev] [Neutron][QoS] Interest in a meeting at the
Networking pod at the design summit?



+1


On Tue, May 6, 2014 at 3:50 PM, Collins, Sean 
sean_colli...@cable.comcast.com wrote:
  On Tue, May 06, 2014 at 03:04:09PM EDT, Mohammad Banikazemi wrote:
  
   +1.
  
   Please announce a date/time here so we can perhaps avoid any conflicts
  with
   others who plan to use the networking pod.
  
   Best,

  Agreed. So - Thursday seems to be a pretty light in the afternoon -
  there are only design summit sessions in the morning, perhaps that would
  be the best time?

  --
  Sean M. Collins
  ___
  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][ml2] Etherpad for the design session on Modular L2 Agents

[Mohammad Banikazemi]

Thanks for the suggestion. That's what I plan to do next (barring other
possible suggestions). While the sharing is limited in some cases, it
appears to be significant in other cases (e.g., the ovs and the mlnx
agents).

Best,

Mohammad



From:   yamam...@valinux.co.jp (YAMAMOTO Takashi)
To: openstack-dev@lists.openstack.org,
Date:   05/06/2014 08:24 PM
Subject:Re: [openstack-dev] [Neutron][ml2] Etherpad for the design
session on Modular L2 Agents



 Please note that I have created an etherpad for the Modular L2 Agent
 session at [1].
 It relates to one of the three topics that are to be discussed during the
 Modular Layer2 Agent design session scheduled for Thursday
 11:50am-12:30pm [2].
 Please update the etherpad and/or use the ML or contact me if you have
any
 comments/suggestions/criticism. (I have also asked several people who
have
 worked on the agents and/or expressed interest in this topic individually
 for their input.)

can you pick a few existing agents (eg. ovs and lb) and prototype
a modular agent to demonstrate how much of the code can be shared
by this effort?

YAMAMOTO Takashi


 Thanks,

 -Mohammad

 [1] https://etherpad.openstack.org/p/juno-neutron-modular-l2-agent
 [2]

http://junodesignsummit.sched.org/event/4205f2c4084e8a0c3bd8d420803ddf02#.U2k7RdyZpjI


___
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 Applicability to the OpenStack Project

[Mohammad Banikazemi]

Hi Mike, Thanks for your interest in OpenStack and Neutron. Are there any
published papers you can point us to? It may be easier to understand your
work by reading/reviewing your papers.

Best,

Mohammad




From:   Mike Grima mike.r.gr...@gmail.com
To: openstack-dev@lists.openstack.org,
Date:   05/06/2014 09:21 PM
Subject:[openstack-dev] [Neutron][FWaaS]Firewall Web Services Research
Thesis Applicability to the OpenStack Project



Hi Everyone,

I am an Information Security grad student, and I am wrapping up a thesis
on exposing host firewall capabilities via web services for KVM virtual
machines. The purpose of which is to:
A.  Make the firewall management of KVM virtual machines easier to
perform on the host (from the KVM administrator’s perspective)
B.  Provide the ability to enforce network security policies on
hosted virtual machines via the host’s firewall.
C.  Provide the ability for future security appliances and
vulnerability scanners to leverage the exposed web services to
close network security vulnerabilities on hosted virtual
machines (via modification of the host’s firewall rules). This
can allow security appliances to automatically respond to
security incidents as they occur.

I just recently stumbled upon the OpenStack project, and noticed the
Firewall as a Service (FWaaS) plugin and documentation that has been
developed this past year.  There are a lot of similarities to my thesis,
and I would like to know if some of the research I have performed could
be of value to the OpenStack project.  Perhaps they could be useful in
the development of use cases, or maybe inspire future ideas for
enhancements and features?  I am still in the process of wrapping up
the thesis, so I would like to avoid posting it for the time being.
However, once I have completed the write-up, I would be more than
happy to share it with the OpenStack community.

I have recorded screen videos showcasing the above three points in
action.  Perhaps the most relevant to recent events is the 4th video,
which showcases how FWaaS (in general, not the OpenStack plugin) could
be used by OpenVAS (in this case) to detect virtual machines that are
vulnerable to Heartbleed, and immediately issue a command to the web
service to close access to the HTTPS port.

The web-services are being exposed via a Java Jetty web server running
on the KVM host itself.  I made a Java client app for interfacing with
the web services.

Below are the videos:
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

Please let me know if the above could prove useful for the OpenStack
project.  Concurrence from you guys would be helpful illustrating the
significance of my research.

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] [Neutron] Flavor(?) Framework

[Mohammad Banikazemi]

As I understand the proposed flavor framework, the intention is to provide
a mechanism for specifying different flavors of a given service type
as they  are already defined. So using the term type may be confusing.
Here we want to specify possibly different set of capabilities within a
given defined service type.

Mohammad




From:   Jay Pipes jaypi...@gmail.com
To: openstack-dev@lists.openstack.org,
Date:   04/25/2014 12:09 PM
Subject:Re: [openstack-dev] [Neutron] Flavor(?) Framework



On Fri, 2014-04-25 at 13:41 +, Akihiro Motoki wrote:
 Hi,

 I have a same question from Mark. Why is flavor not desired?
 My first vote is flavor first, and then type.

Some reasons:

First, flavor, in English, can and often is spelled differently
depending on where you live in the world (flavor vs. flavour).

Second, type is the appropriate term for what this is describing, and
doesn't have connotations of taste, which flavor does.

I could also mention that the term flavor is a vestige of the
Rackspace Cloud API and, IMO, should be killed off in place of the more
common and better understood instance type which is used by the EC2
API.

 There is similar cases in other OpenStack projects.
 Nova uses flavor and Cinder uses (volume) type for similar cases.
 Both cases are similar to our use cases and I think it is better to
 use
 either of them to avoid more confusion from naming for usesr and
 operators.

 Cinder volume_type detail is available at [1]. In Cinder volume_type,
 we can define multiple volume_type for one driver.
 (more precisely, volume_type is associated to one backend
 defintion
 and we can define multiple backend definition for one backend
 driver).

 In addition, I prefer to managing flavor/type through API and
 decoupling
 flavor/type definition from provider definitions in configuration
 files
 as Cinder and Nova do.

Yes, I don't believe there's any disagreement on that particular point.
This effort is all about trying to provide a more comfortable and
reasonable way for classification of these advanced services to be
controlled by the user.

Best,
-jay

 [1]
 http://docs.openstack.org/admin-guide-cloud/content/multi_backend.html

 Thanks,
 Akihiro

 (2014/04/24 0:05), Eugene Nikanorov wrote:

  Hi neutrons,
 
 
  A quick question of the ^^^
  I heard from many of you that a term 'flavor' is undesirable, but so
  far there were no suggestions for the notion that we are going to
  introduce.
  So please, suggest you name for the resource.
  Names that I've been thinking of:
   - Capability group
   - Service Offering
 
 
  Thoughts?
 
 
  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

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

Re: [openstack-dev] [Neutron][ML2][Ml2Plugin] Setting _original_network in NetworkContext:

[Mohammad Banikazemi]

Nader,

During the last ML2 IRC weekly meeting [1] having per-MD extensions was
mentioned. This is an important topic in my opinion. You may want to add a
proposal for a design session on this topic at [2] and/or add this topic to
the agenda for the next ML2 weekly meeting [3] for further discussion.

Mohammad

[1]
http://eavesdrop.openstack.org/meetings/networking_ml2/2014/networking_ml2.2014-04-02-16.00.log.html

[2] http://summit.openstack.org
[3] https://wiki.openstack.org/wiki/Meetings/ML2



From:   Nader Lahouti nader.laho...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org, Andre Pech
ap...@aristanetworks.com,
Date:   04/03/2014 01:16 PM
Subject:Re: [openstack-dev] [Neutron][ML2][Ml2Plugin] Setting
_original_network in NetworkContext:



Thanks a lot Andre for the reply.
My comments inline:

On Wed, Apr 2, 2014 at 12:37 PM, Andre Pech ap...@aristanetworks.com
wrote:



  On Fri, Mar 28, 2014 at 6:44 PM, Nader Lahouti nader.laho...@gmail.com
  wrote:
   Hi Mathieu,

   Thanks a lot for your reply.

   Even in the neutron/neutron/db/db_base_plugin_v2.py: create_network()
   passes network object:
   911def create_network(self, context, network):
   912Handle creation of a single network.
   913# single request processing
   914n = network['network']    'n' has all the
   network info (including extensions)
   915# NOTE(jkoelker) Get the tenant_id outside of the session to
   avoid
   916#unneeded db action if the operation raises
   917tenant_id = self._get_tenant_id_for_create(context, n)
   918with context.session.begin(subtransactions=True):
   919args = {'tenant_id': tenant_id,
   920'id': n.get('id') or uuidutils.generate_uuid(),
   921'name': n['name'],
   922'admin_state_up': n['admin_state_up'],
   923'shared': n['shared'],
   924'status': n.get('status', constants.
   NET_STATUS_ACTIVE)}
   925network = models_v2.Network(**args)  = 'network' does
   not include extensions.
   926context.session.add(network)
   927return self._make_network_dict(network, process_extensions=
   False)
   even if process_extensions set to True, we still have issue.

   If using original_network, causes confusion can we add a new parameter
   and use it in mechanism driver?
   Also haven't received any reply from salvotore.

  Yes, not re-using original_network would be my preference.


Will add new parameter to avoid re-using original_network.


   * Another issue with the Ml2Plugin regarding the extensions is that
   neutron api can fail as it cannot find any handler in the plugin for
   request such as get/update/create/delete.


   For instance I added 'config_profile' as an extensions to network
   resource and get this error.


   2014-03-28 12:27:02.495 TRACE  resource.py: neutron.api.v2.resource
   File


   /opt/stack/neutron/neutron/api/v2/base.py, line 273, in index


   2014-03-28 12:27:02.495 TRACE  resource.py: neutron.api.v2.resource
   ret


   urn self._items(request, True, parent_id)


   2014-03-28 12:27:02.495 TRACE  resource.py: neutron.api.v2.resource
   File


   /opt/stack/neutron/neutron/api/v2/base.py, line 226, in _items


   2014-03-28 12:27:02.495 TRACE  resource.py: neutron.api.v2.resource
   obj_getter = getattr(self._plugin, self._plugin_handlers[self.LIST])


   2014-03-28 12:27:02.495 TRACE resource.py: neutron.api.v2.resource
   AttributeError: 'Ml2Plugin' object has no attribute
   'get_config_profiles'


   2014-03-28 12:27:02.495 TRACE  resource.py: neutron.api.v2.resource



   We need to add either (1) Make Ml2Plugin code aware of such an attribute
   (e.g. adding another base class, which may not be a good solution) or
   (2) make the changes in neutron/neutron/api/v2/base.py to understand if
   Ml2Plugin is supported then get the attributes from mechanism driver.
   (3) any other idea?

   I already implemented (2) in my private repo, to fix this error.
   Also, I have already opened a BP to for supporting extensions in MD, and
   if it is okay I can include the fix as part of that BP.

  Yes, we don't really have great support for extensions today, so fixing
  this in the context of making extensions work in general with ML2 and
  MechanismDrivers, this sounds great.

  Thanks for taking this on,

Sure. Will add it as part of
https://blueprints.launchpad.net/neutron/+spec/neutron-ml2-mechanismdriver-extensions

Thanks,
Nader.



  Andre



   Thanks,
   Nader.



   On Fri, Mar 28, 2014 at 8:22 AM, Mathieu Rohon mathieu.ro...@gmail.com
   wrote:
 hi nader,

 I don't think this parameter could be used in this case. As andre said
 , tha original-network is usefull for update and delete commands. It
 would led to 

[openstack-dev] [neutron][policy] Presentation from last summit

[Mohammad Banikazemi]

During the Group Policy IRC meeting earlier today, the talk I gave during
the last summit (in Hong Kong) came up. I couldn't find the link to the
slides during the meeting. In case anyone is interested, the slides can be
found here:
https://www.openstack.org/assets/presentation-media/MB-Openstack-Nov2013v7.pptx
During the meeting, I referred to the example on slide #21. (If you want to
have a look, use the ppt presentation mode.)

The recording of the presentation can be found here:
https://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/network-abstraction-at-different-layers-of-the-stack

Best,

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

Re: [openstack-dev] [Neutron] advanced servicevm framework IRC meeting March 18(Tuesday) 23:00 UTC

[Mohammad Banikazemi]

Thanks for setting up the meeting.
I would second the request for change of the time slot; Hope to attend this
one and see if we can come up with a better time slot.
With respect to other suggestions, it would be great if we start with a
report on the current state of this work. Something similar to what you
started last week (from what I gather from the logs of the meeting) but
going a bit more into details. I personally would like to see how this fits
in the advanced services framework in general and how we can utilize it
within the group policy framework we are trying to develop.

Best,

Mohammad



From:   Isaku Yamahata isaku.yamah...@gmail.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Cc: isaku.yamah...@gmail.com
Date:   03/18/2014 05:00 AM
Subject:Re: [openstack-dev] [Neutron] advanced servicevm framework IRC
meeting March 18(Tuesday) 23:00 UTC



Hi Balaji.

Let's discuss/determine on the time at the meeting as it is listed as
agenda.
Sorry for inconvenience for the first time.
Do you have any feedback other than the meeting time?

thanks,

On Tue, Mar 18, 2014 at 06:18:01AM +,
balaj...@freescale.com balaj...@freescale.com wrote:

 Hi Isaku Yamahata,

 Is it possible to have any convenient slot between 4.00 - 6.30 PM - UTC.

 So, that folks from asia can also join the meetings.

 Regards,
 Balaji.P

  -Original Message-
  From: Isaku Yamahata [mailto:isaku.yamah...@gmail.com]
  Sent: Tuesday, March 18, 2014 11:35 AM
  To: OpenStack Development Mailing List
  Cc: isaku.yamah...@gmail.com
  Subject: [openstack-dev] [Neutron] advanced servicevm framework IRC
  meeting March 18(Tuesday) 23:00 UTC
 
  Hello. This is a reminder for servicevm framework IRC meeting.
  date: March 18 (Tuesday) 23:00 UTC
  channel: #openstack-meeting
 
  the followings are proposed as agenda.
  Meeting wiki: https://wiki.openstack.org/wiki/Meetings/ServiceVM
 
  * the current status summary
  * decide the time/day/frequency
 
  Thanks,
  --
  Isaku Yamahata isaku.yamah...@gmail.com
 
  ___
  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

--
Isaku Yamahata isaku.yamah...@gmail.com

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

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

Re: [openstack-dev] [neutron][policy] Integrating network policies and network services

[Mohammad Banikazemi]

Louis, We are still working on the details of the new contract based model.
To get an idea please refer to the original project google document [1] and
look under the section titled
Use Cases: 3-tier Application with Security Policies where policies are
described through a provider/consumer relationship. The contract model is
similar to the model being worked out by a similarly named project in
OpenDaylight. You can find more information on the contract model there
[2].

Best,

Mohammad


[1]
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.gebyoou6khks
[2]
https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin



From:   Louis.Fourie louis.fou...@huawei.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   03/18/2014 03:23 PM
Subject:Re: [openstack-dev] [neutron][policy] Integrating network
policies and network services



Mohammad,
  Can you share details on the contract-based policy model?
   -  Louis

From: Mohammad Banikazemi [mailto:m...@us.ibm.com]
Sent: Friday, March 14, 2014 3:18 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron][policy] Integrating network policies and
network services



We have started looking at how the Neutron advanced services being defined
and developed right now can be used within the Neutron policy framework we
are building. Furthermore, we have been looking at a new model for the
policy framework as of the past couple of weeks. So, I have been trying to
see how the services will fit in (or can be utilized by) the policy work in
general and with the new contract-based model we are considering in
particular. Some of the I like to discuss here are specific to the use of
service chains with the group policy work but some are generic and related
to service chaining itself.

If I understand it correctly, the proposed service chaining model requires
the creation of the services in the chain without specifying their
insertion contexts. Then, the service chain is created with specifying the
services in the chain, a particular provider (which is specific to the
chain being built) and possibly source and destination insertion contexts.

1- This fits ok with the policy model we had developed earlier where the
policy would get defined between a source and a destination policy endpoint
group. The chain could be instantiated at the time the policy gets defined.
(More questions on the instantiation below marked as 1.a and 1.b.) How
would that work in a contract based model for policy? At the time a
contract is defined, it's producers and consumers are not defined yet.
Would we postpone the instantiation of the service chain to the time a
contract gets a producer and at least a consumer?

1.a- It seems to me, it would be helpful if not necessary to be able to
define a chain without instantiating the chain. If I understand it
correctly, in the current service chaining model, when the chain is
created, the source/destination contexts are used (whether they are
specified explicitly or implicitly) and the chain of services become
operational. We may want to be able to define the chain and postpone its
creation to a later point in time.

1.b-Is it really possible to stand up a service without knowing its
insertion context (explicitly defined or implicitly defined) in all cases?
For certain cases this will be ok but for others, depending on the
insertion context or other factors such as the requirements of other
services in the chain we may need to for example instantiate the service
(e.g. create a VM) at a specific location that is not known when the
service is created. If that may be the case, would it make sense to not
instantiate the services of a chain at any level (rather than instantiating
them and mark them as not operational or not routing traffic to them)
before the chain is created? (This leads to question 3 below.)

2- With one producer and multiple consumers, do we instantiate a chain
(meaning the chain and the services in the chain become operational) for
each consumer? If not, how do we deal with using the same
source/destination insertion context pair for the provider and all of the
consumers?

3- For the service chain creation, I am sure there are good reasons for
requiring a specific provider for a given chain of services but wouldn't it
be possible to have a generic chain provider which would instantiate each
service in the chain using the required provider for each service (e.g.,
firewall or loadbalancer service) and with setting the insertion contexts
for each service such that the chain gets constructed as well? I am sure I
am ignoring some practical requirements but is it worth rethinking the
current approach?

Best,

Mohammad___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http

Re: [openstack-dev] [Neutron] Docs for new plugins

[Mohammad Banikazemi]

I think the docs get updated for each release, so probably the newly added
stuff (after I3) will be picked up by the RC1 release date. (cc'ing Tom
Fifield for a definitive answer.)

By the way I do see the odl config table in the openstack-manuals source
tree:
https://github.com/openstack/openstack-manuals/blob/master/doc/common/tables/neutron-ml2_odl.xml
and that is being referenced here:
https://github.com/openstack/openstack-manuals/blob/master/doc/config-reference/networking/section_networking-plugins-ml2.xml

Best,

Mohammad




From:   Kyle Mestery mest...@noironetworks.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   03/17/2014 09:40 AM
Subject:Re: [openstack-dev] [Neutron] Docs for new plugins



Edgar:

I don't see the configuration options for the OpenDaylight ML2
MechanismDriver
added here yet, even though the code was checked in well over a week ago.
How long does it take to autogenerate this page from the code?

Thanks!
Kyle



On Wed, Mar 12, 2014 at 5:10 PM, Edgar Magana emag...@plumgrid.com wrote:
  You should be able to add your plugin here:
  
http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html

  Thanks,

  Edgar

  From: Mohammad Banikazemi m...@us.ibm.com
  Date: Monday, March 10, 2014 2:40 PM
  To: OpenStack List openstack-dev@lists.openstack.org
  Cc: Edgar Magana emag...@plumgrid.com
  Subject: Re: [openstack-dev] [Neutron] Docs for new plugins



  Would like to know what to do for adding documentation for a new plugin.
  Can someone point me to the right place/process please.

  Thanks,

  Mohammad

  ___
  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
inline: graycol.gif___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][policy] Integrating network policies and network services

[Mohammad Banikazemi]

Kanzhe, thanks for your response to my comments and questions. Please see
below.

 From: Kanzhe Jiang kan...@gmail.com

[...]
 On Fri, Mar 14, 2014 at 3:18 PM, Mohammad Banikazemi m...@us.ibm.com
wrote:

[...]
 3- For the service chain creation, I am sure there are good reasons
 for requiring a specific provider for a given chain of services but
 wouldn't it be possible to have a generic chain provider which
 would instantiate each service in the chain using the required
 provider for each service (e.g., firewall or loadbalancer service)
 and with setting the insertion contexts for each service such that
 the chain gets constructed as well? I am sure I am ignoring some
 practical requirements but is it worth rethinking the current approach?

 Service Chaining often means a form of traffic steering. Depending
 on how the steering is done, the capabilities of different providers
 differ. Different provider may define different context of
 individual service in the chain. For example, a bump-in-the-wire
 service can be inserted as a virtual wire or L3 next hop. So it will
 be hard to define a generic chain provider.

With respect to Question 3 above, yes you are right we need possibly
different providers for this generic chain service type. The solution
could be having the chain as a service type itself which can be provided
by different providers. Different providers can implement the instantiation
of a chain differently. This is similar to the current service-chain model
in that there may be different providers for a service-chain with the
difference being that the service type itself is generic and not specific
to a particular chain such as firewall-vpn.

Best,

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

Re: [openstack-dev] [neutron][policy] Integrating network policies and network services

[Mohammad Banikazemi]

I think there are a couple of issues here:

1- Having network services in VMs: There was a design summit session in
this regard in Hong Kong: Framework for Advanced Services in VMs [1]. There
is a corresponding blueprint [2] and some code submitted for early review
marked as work in progress [3].  We should follow up on this work and see
its status and what the plans for near future are. This seems to be
increasingly more relevant and more important.

2- Is it worth revisiting the requirement for having service chain types
specific to particular chains of services? The argument I have heard for
the current design is that the set of chains that are practically used are
very limited. Furthermore, having generic service type chain drivers may be
difficult to develop. With respect to limited use cases, I think even if
that is the case right now, we may be pushing ourselves into a corner as
more diverse set of network services and functions become available (as
suggested by Carlos). So I think the real question is are there practical
barriers in developing a more generic service type for service chains.

Best,

-Mohammad


[1]
http://icehousedesignsummit.sched.org/event/1deb4de716730ca7cecf0c3b968bc592
[2] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
[3] https://review.openstack.org/#/c/72068/



From:   Kanzhe Jiang kanzhe.ji...@bigswitch.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   03/17/2014 12:54 PM
Subject:Re: [openstack-dev] [neutron][policy] Integrating network
policies and network services




Hi Carlos,

The provider mechanism is currently under discussion in advanced service
group. However, your use-case of chaining non-neutron service has not been
considered in the proposal. If you believe it is an important feature,
please definitely be vocal, even better to have a proposal. :-)


 3- For the service chain creation, I am sure there are good
 reasons for requiring a specific provider for a given chain of
 services but wouldn't it be possible to have a generic chain
 provider which would instantiate each service in the chain using
 the required provider for each service (e.g., firewall or
 loadbalancer service) and with setting the insertion contexts for
 each service such that the chain gets constructed as well? I am
 sure I am ignoring some practical requirements but is it worth
 rethinking the current approach?



Service Chaining often means a form of traffic steering. Depending
on how the steering is done, the capabilities of different
providers differ. Different provider may define different context
of individual service in the chain. For example, a bump-in-the-wire
service can be inserted as a virtual wire or L3 next hop. So it
will be hard to define a generic chain provider.

  I’m partially with Mohammad on this.

  For what I’ve understood from the service chaining proposal, there would
  be different service chain provider implementations with each one
  restricting to a statically defined and limited number of services for
  chaining (please correct me if I’m mistaken). This is, and taking the
  “Firewall-VPN-ref-Chain” service chain provider from the document as
  example, users would be limited to creating chains “firewall - VPN” (and
  I’m not even considering the restrictiveness of service providers) but
  not “VPN - firewall”, or introducing a LB in the middle.


  My rough understanding on chaining, in a broad term, would be to firstly
  support generic L2/L3 chaining, and not restricting to Neutron services
  (FWaaS, LBaaS, VPNaaS) if that is the case, but should also be valid for
  them as they can be reached via network ports as well.

  Last week during the advanced services meeting I presented the following
  use case. DPI (Deep Packet Inspection) is an example of a absent Neutron
  service as of now. Users wanting to run a DPI instance in OpenStack would
  have to create a virtual machine and run it there which is fine. Now, in
  case they want to filter inbound traffic from a (public) network, traffic
  should be steered first to the VM running the DPI and then to the final
  destination. Currently in OpenStack it is not possible to configure this
  and I don’t see how in the proposed BP it would be. It was given the
  example of a DPI, but it can be virtually any service type and service
  implementation. Sure users wouldn’t get all the fancy APIs OpenStack
  providers instantiate and configure services.






--
Kanzhe Jiang
MTS at BigSwitch___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
inline: graycol.gif___
OpenStack-dev mailing list

[openstack-dev] [neutron][policy] Integrating network policies and network services

[Mohammad Banikazemi]

We have started looking at how the Neutron advanced services being defined
and developed right now can be used within the Neutron policy framework we
are building. Furthermore, we have been looking at a new model for the
policy framework as of the past couple of weeks. So, I have been trying to
see how the services will fit in (or can be utilized by) the policy work in
general and with the new contract-based model we are considering in
particular. Some of the I like to discuss here are specific to the use of
service chains with the group policy work but some are generic and related
to service chaining itself.

If I understand it correctly, the proposed service chaining model requires
the creation of the services in the chain without specifying their
insertion contexts. Then, the service chain is created with specifying the
services in the chain, a particular provider (which is specific to the
chain being built) and possibly source and destination insertion contexts.

1- This fits ok with the policy model we had developed earlier where the
policy would get defined between a source and a destination policy endpoint
group. The chain could be instantiated at the time the policy gets defined.
(More questions on the instantiation below marked as 1.a and 1.b.) How
would that work in a contract based model for policy? At the time a
contract is defined, it's producers and consumers are not defined yet.
Would we postpone the instantiation of the service chain to the time a
contract gets a producer and at least a consumer?

1.a- It seems to me, it would be helpful if not necessary to be able to
define a chain without instantiating the chain. If I understand it
correctly, in the current service chaining model, when the chain is
created, the source/destination contexts are used (whether they are
specified explicitly or implicitly) and the chain of services become
operational. We may want to be able to define the chain and postpone its
creation to a later point in time.

1.b-Is it really possible to stand up a service without knowing its
insertion context (explicitly defined or implicitly defined) in all cases?
For certain cases this will be ok but for others, depending on the
insertion context or other factors such as the requirements of other
services in the chain we may need to for example instantiate the service
(e.g. create a VM) at a specific location that is not known when the
service is created. If that may be the case, would it make sense to not
instantiate the services of a chain at any level (rather than instantiating
them and mark them as not operational or not routing traffic to them)
before the chain is created? (This leads to question 3 below.)

2- With one producer and multiple consumers, do we instantiate a chain
(meaning the chain and the services in the chain become operational) for
each consumer? If not, how do we deal with using the same
source/destination insertion context pair for the provider and all of the
consumers?

3- For the service chain creation, I am sure there are good reasons for
requiring a specific provider for a given chain of services but wouldn't it
be possible to have a generic chain provider which would instantiate each
service in the chain using the required provider for each service (e.g.,
firewall or loadbalancer service) and with setting the insertion contexts
for each service such that the chain gets constructed as well? I am sure I
am ignoring some practical requirements but is it worth rethinking the
current approach?

Best,

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

Re: [openstack-dev] [Neutron] Docs for new plugins

[Mohammad Banikazemi]

Thanks for your response.

It looks like the page you are referring to gets populated automatically
and I see a link already added to it for the new plugin. I also see a file
corresponding to the new plugin having been created and populated with the
plugin config options in the latest openstack-manuals cloned from github.

After talking to the docs people on #openstack-docs, now I know that these
files get created automatically and periodically. Any changes to the docs
should come through changes to the config file in the code which will be
automatically picked up at some point when the docs scripts get executed.

It looks like there is nothing to be done in this front for adding the docs
for the new plugin. If that seems reasonable, I will close the bug I had
opened for the the docs for our plugin.

Thanks,

-Mohammad







From:   Edgar Magana emag...@plumgrid.com
To: Mohammad Banikazemi/Watson/IBM@IBMUS, OpenStack Development
Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   03/12/2014 06:10 PM
Subject:Re: [openstack-dev] [Neutron] Docs for new plugins



You should be able to add your plugin here:
http://docs.openstack.org/havana/config-reference/content/networking-options-plugins.html

Thanks,

Edgar

From: Mohammad Banikazemi m...@us.ibm.com
Date: Monday, March 10, 2014 2:40 PM
To: OpenStack List openstack-dev@lists.openstack.org
Cc: Edgar Magana emag...@plumgrid.com
Subject: Re: [openstack-dev] [Neutron] Docs for new plugins



Would like to know what to do for adding documentation for a new plugin.
Can someone point me to the right place/process please.

Thanks,

Mohammad

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

Re: [openstack-dev] [Neutron] Docs for new plugins

[Mohammad Banikazemi]

Tom Fifield t...@openstack.org wrote on 03/12/2014 10:51:54 PM:

 From: Tom Fifield t...@openstack.org
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org, Edgar Magana emag...@plumgrid.com,
 Date: 03/12/2014 10:59 PM
 Subject: Re: [openstack-dev] [Neutron] Docs for new plugins

 On 13/03/14 13:43, Mohammad Banikazemi wrote:
  Thanks for your response.
 
  It looks like the page you are referring to gets populated
automatically
  and I see a link already added to it for the new plugin. I also see a
  file corresponding to the new plugin having been created and populated
  with the plugin config options in the latest openstack-manuals cloned
  from github.
 
  After talking to the docs people on #openstack-docs, now I know that
  these files get created automatically and periodically. Any changes to
  the docs should come through changes to the config file in the code
  which will be automatically picked up at some point when the docs
  scripts get executed.

 Just to clarify one point - the text comes from the code, in the oslo
 option registration's helptext, not from the configuration files in etc.


Thanks for clarifying this point and for the initial information as well.
Yes, by config file in the code I was referring to the config.py file in
our plugin (and a few other Neutron plugins I have seen) where the plugin
options and corresponding helptexts get registered by using register_opts()
from oslo.


  It looks like there is nothing to be done in this front for adding the
  docs for the new plugin. If that seems reasonable, I will close the bug
  I had opened for the the docs for our plugin.
 
  Thanks,
 
  -Mohammad
 
 
 
 
 
  Inactive hide details for Edgar Magana ---03/12/2014 06:10:31 PM---You
  should be able to add your plugin here: http://docs.openEdgar Magana
  ---03/12/2014 06:10:31 PM---You should be able to add your plugin here:
  http://docs.openstack.org/havana/config-reference/conten
 
  From: Edgar Magana emag...@plumgrid.com
  To: Mohammad Banikazemi/Watson/IBM@IBMUS, OpenStack Development
Mailing
  List (not for usage questions) openstack-dev@lists.openstack.org,
  Date: 03/12/2014 06:10 PM
  Subject: Re: [openstack-dev] [Neutron] Docs for new plugins
 
 

 
 
 
  You should be able to add your plugin here:
  _http://docs.openstack.org/havana/config-reference/content/
 networking-options-plugins.html_
 
  Thanks,
 
  Edgar
 
  *From: *Mohammad Banikazemi _...@us.ibm.com_ mailto:m...@us.ibm.com*
  Date: *Monday, March 10, 2014 2:40 PM*
  To: *OpenStack List _openstack-dev@lists.openstack.org_
  mailto:openstack-dev@lists.openstack.org*
  Cc: *Edgar Magana _emagana@plumgrid.com_
mailto:emag...@plumgrid.com*
  Subject: *Re: [openstack-dev] [Neutron] Docs for new plugins
 
  Would like to know what to do for adding documentation for a new
plugin.
  Can someone point me to the right place/process please.
 
  Thanks,
 
  Mohammad
 
 
 
  ___
  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] Docs for new plugins

[Mohammad Banikazemi]

Would like to know what to do for adding documentation for a new plugin.
Can someone point me to the right place/process please.

Thanks,

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

Re: [openstack-dev] [neutron][policy] Using network services with network policies

[Mohammad Banikazemi]

Thanks Sumit and Stephen for information provided.

It appears to me that we can (and should) use the notion of
services/service chains within the group policy extension (and that has
been always one of our options). If this is a reasonable approach, then we
need to see how we can bring in these services to our group policy and if
there are changes we may require.

The first thing that comes to mind is to have a new service insertion
context, namely policy (or should it be policy_rule?). If that is in place,
then a service chain (we can start with a chain of one single service) gets
created with it's context set to a particular policy. While the service
plugin is responsible for standing up the service, the connectivity is
established through the implementation of the group policy extension, in
particular the redirect action. Is this a reasonable approach? This
approach requires some kind of coordination wrt how these operations are
done by the service plugin and the group policy extension. May be a policy
simply provides the insertion context for creation of the service chain (in
isolation and by the appropriate service plugin) and policy rules are then
used to make the service operational. This is different from how services
are expected to be instantiated right now. Right? Thinking aloud here.
Please comment.

A lot of interesting things to work on. May be Juno is where all these
efforts come to fruition together :)

Mohammad



From:   Sumit Naiksatam sumitnaiksa...@gmail.com
To: Mohammad Banikazemi/Watson/IBM@IBMUS,
Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   02/17/2014 02:12 AM
Subject:Re: [openstack-dev] [neutron][policy] Using network services
with network policies



Thanks Mohammad for bringing this up. I responded in another thread:
http://lists.openstack.org/pipermail/openstack-dev/2014-February/027306.html


~Sumit.

On Sun, Feb 16, 2014 at 7:27 AM, Mohammad Banikazemi m...@us.ibm.com wrote:
 During the last IRC call we started talking about network services and
how
 they can be integrated into the group Policy framework.

 In particular, with the redirect action we need to think how we can
 specify the network services we want to redirect the traffic to/from.
There
 has been a substantial work in the area of service chaining and service
 insertion and in the last summit advanced service in VMs were
discussed.
 I think the first step for us is to find out the status of those efforts
and
 then see how we can use them. Here are a few questions that come to mind.
 1- What is the status of service chaining, service insertion and advanced
 services work?
 2- How could we use a service chain? Would simply referring to it in the
 action be enough? Are there considerations wrt creating a service chain
 and/or a service VM for use with the Group Policy framework that need to
be
 taken into account?

 Let's start the discussion on the ML before taking it to the next call.

 Thanks,

 Mohammad

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

[openstack-dev] [neutron][policy] Using network services with network policies

[Mohammad Banikazemi]

During the last IRC call we started talking about network services and how
they can be integrated into the group Policy framework.

In particular, with the redirect action we need to think how we can
specify the network services we want to redirect the traffic to/from. There
has been a substantial work in the area of service chaining and service
insertion and in the last summit advanced service in VMs were discussed.
I think the first step for us is to find out the status of those efforts
and then see how we can use them. Here are a few questions that come to
mind.
1- What is the status of service chaining, service insertion and advanced
services work?
2- How could we use a service chain? Would simply referring to it in the
action be enough? Are there considerations wrt creating a service chain
and/or a service VM for use with the Group Policy framework that need to be
taken into account?

Let's start the discussion on the ML before taking it to the next call.

Thanks,

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

Re: [openstack-dev] [Neutron] Group Policy questions

[Mohammad Banikazemi]

Hi Carlos,

We have just started looking at the same issues you have mentioned. Please
follow the email thread started by me earlier today ([openstack-dev]
[neutron][policy] Using network services with network policies). We will be
spending more time on these topics during our upcoming weekly IRC calls as
well.

Best,

-Mohammad




From:   Carlos Gonçalves m...@cgoncalves.pt
To: openstack-dev@lists.openstack.org,
Date:   02/12/2014 01:43 PM
Subject:[openstack-dev] [Neutron] Group Policy questions



Hi,

I’ve a couple of questions regarding the ongoing work on Neutron Group
Policy proposed in [1].

1. One of the described actions is redirection to a service chain. How do
you see BPs [2] and [3] addressing service chaining? Will this BP implement
its own service chaining mechanism enforcing traffic steering or will it
make use of, and thus depending on, those BPs?

2. In the second use case presented in the BP document, “Tired application
with service insertion/chaining”, do you consider that the two firewalls
entities can represent the same firewall instance or two running and
independent instances? In case it’s a shared instance, how would it support
multiple chains? This is, HTTP(s) traffic from Inet group would be
redirected to the firewall and then passes through the ADC; traffic from
App group with destination DB group would also be redirected to the very
same firewall instance, although to a different destination group as the
chain differs.

Thanks.

Cheers,
Carlos Gonçalves

[1]
https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
[2]
https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
[3]
https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
inline: graycol.gif___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [qa] Adding support for a new plugin

[Mohammad Banikazemi]

Hi everybody,

We have a new Neutron plugin being reviewed (approved for the Icehouse-3
milestone) and would like to add the corresponding file in devstack. Not
being sure as to how to do this, I opened a blueprint
( https://blueprints.launchpad.net/devstack/+spec/ibm-sdnve-plugin-support )
 and submitted the patch here: https://review.openstack.org/#/c/71359/

I am wondering if this is the correct way of doing this and I have the
patch submitted to the right place. Could the qa core people or those who
are familiar with the process comment.

Thanks,

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

Re: [openstack-dev] [neutron] [group-policy] Canceling tomorrows meeting

[Mohammad Banikazemi]

Hi everybody,

Since some of us are away attending the OpenDaylight Summit, we are going
to cancel the Thursday Feb 6 meeting.
We have started coding for our PoC implementation and should have some code
for review by next week. Please use the mailing list for discussing Group
Policy related matters.

Best,

Mohammad




From:   Kyle Mestery mest...@siliconloons.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   01/29/2014 06:35 PM
Subject:[openstack-dev] [neutron] [group-policy] Canceling tomorrows
meeting



Folks:

We’ve decided to cancel tomorrows IRC meeting. If you have
action items around the POC we’re all working on, please
continue down that path for now. We’ll sync up for a meeting
the following week again.

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

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

[openstack-dev] [neutron] [third-party-testing] Which patchset triggered the test

[Mohammad Banikazemi]

Have a question regarding the Jenkins/Gerrit setup for third party testing
setups.

When Jenkins get triggered by a patchset through the Gerrit trigger
plug-in, you can execute a set of shell scripts. How do you get the
information about the patchset that triggered the test? In particular, in
your scripts how do you figure out which patchset triggered the test. Here
is why I am asking this question:
During our earlier IRC calls we said, one approach for testing would be
using devstack to install OpenStack and run appropriate tests. The devstack
stack.sh brings in the master branch without the patchset which triggered
the test. How do I access the patchset I want to test? Am I missing
something here?

Thanks,

Mohammad___
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-testing] Which patchset triggered the test

[Mohammad Banikazemi]

Thanks a lot for answering my question and also for updating the
multi-node/3rd party testing google doc as well.

Mohammad




From:   Roey Chen ro...@mellanox.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   01/20/2014 04:25 PM
Subject:Re: [openstack-dev] [neutron] [third-party-testing] Which
patchset triggered the test



Mohammad,

You can get the information you want from the environment variables that
the Gerrit plugin sets.

Just like it was mentioned here:
https://etherpad.openstack.org/p/multi-node-neutron-tempest
if you'll set NEUTRON_BRANCH=$GERRIT_REFSPEC in the localrc
then Devstack will pull the change which triggered the build.

Try env shell command to find out what are the rest of the environment
variables.

Best,
---
Roey



From: Mohammad Banikazemi [m...@us.ibm.com]
Sent: Monday, January 20, 2014 9:32 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [neutron] [third-party-testing] Which patchset
triggered the test



Have a question regarding the Jenkins/Gerrit setup for third party testing
setups.

When Jenkins get triggered by a patchset through the Gerrit trigger
plug-in, you can execute a set of shell scripts. How do you get the
information about the patchset that triggered the test? In particular, in
your scripts how do you figure out which patchset triggered the test. Here
is why I am asking this question:
During our earlier IRC calls we said, one approach for testing would be
using devstack to install OpenStack and run appropriate tests. The devstack
stack.sh brings in the master branch without the patchset which triggered
the test. How do I access the patchset I want to test? Am I missing
something here?

Thanks,

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


inline: graycol.gif___
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-testing] Sharing information

[Mohammad Banikazemi]

Jay Pipes jaypi...@gmail.com wrote on 01/17/2014 04:32:55 PM:

 From: Jay Pipes jaypi...@gmail.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 01/17/2014 04:37 PM
 Subject: Re: [openstack-dev] [neutron] [third-party-testing] Sharing
 information

 On Thu, 2014-01-16 at 15:37 +, Sullivan, Jon Paul wrote:
   From: Jay Pipes [mailto:jaypi...@gmail.com]
   On Thu, 2014-01-16 at 10:39 +, Sullivan, Jon Paul wrote:
 From: Kyle Mestery [mailto:mest...@siliconloons.com]

 FYI, here [1] are the meeting logs from today’s meeting.

 A couple of things have become apparent here:

 1. No one has a working Neutron 3rd party testing rig yet which
is
 voting
 consistently. If I’ve missed something, please, someone
correct
   me.
 2. People are still hung on issues around Jenkins/gerrit
   integration.
   
This issue can be very easily resolved if people were to use
Jenkins
   Job Builder [2] for the creation of their Jenkins testing jobs.  This
   would allow the reuse of simple macros already in existence to
guarantee
   correct configuration of Jenkins jobs at 3rd party sites.  This would
   also allow simple reuse of the code used by the infra team to create
the
   openstack review and gate jobs, ensuring 3rd party testers can
generate
   the correct code from the gerrit change and also publish results back
in
   a standard way.
   
I can't recommend Jenkins Job Builder highly enough if you use
   Jenkins.
   
[2] https://github.com/openstack-infra/jenkins-job-builder
  
   ++ It's a life-saver. We used it heavily in ATT with our
   Gerrit/Jenkins/Zuul CI system.
  
   -jay
 
  It seems to me that shared JJB macros could be the most concise
 and simple way
  of describing 3rd party testing integration requirements.
 
  So the follow-on questions are:
  1. Can the 3rd party testing blueprint enforce, or at least link to,
 use of specific JJB macros for integration to the openstack gerrit?
1a. Where should shared JJB code be stored?

 Well, technically, this already exists. The openstack-infra/config
 project already has pretty much everything a 3rd party would ever need
 to setup an OpenStack environment, execute Tempest (or other) tests
 against the environment, save and publish artifacts, and send
 notifications of test results upstream.

  2. Is it appropriate for 3rd party testers to share their tests as
 JJB code, if they are willing?
2a. Would this live in the same location as (1a)?

 Why would 3rd party testers be using anything other than Tempest for
 integration testing? Put another way... if a 3rd party *is* using
 something other than Tempest, why not put it in Tempest :)

  For those unfamiliar with JJB, here is a little example of what
 you might do:
 
  Example of (untested) JJB macro describing how to configure Jenkins to
  trigger from gerrit:
  snip

 As much as JJB is total awesomesauce -- as it prevents people needing to
 manually update Jenkins job config.xml files -- any 3rd party that is
 attempting to put together a test environment/platform for which you
 intend to interact with the upstream CI system should go check out
 devstack-gate [1], read the scripts, and grok it.

 I'm working on some instructions to assist admins in 3rd party testing
 labs in setting all of their platform up using the upstream tools like
 devstack-gate and JJB, and this documentation should be done around
 middle of next week. I'll post to the ML with links to that
 documentation when it's done.


That would be great. Thanks. Please note that Icehouse-2 is the deadline
for Neutron 3rd party test setups to be operational.

 Best,
 -jay

 [1] https://github.com/openstack-infra/devstack-gate


 ___
 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] unnecessary return statement in ovs_lib

[Mohammad Banikazemi]

Came across the following issue while looking at ovs_lib [1]:

The BaseOVS class has the add_bridge() method which after creating an OVS
bridge, returns an OVSBridge object. BaseOVS class is only used by
OVSBridge defined in the same file. OVSBridge has a create() method that
calls the add_bridge() nethod mentioned earlier but do not use the return
value. (See the methods add_bridge and create below.)

What seems odd is the return statement at the end of add_bridge() which is
not used anywhere and doesn't make much sense as far as I can see but I may
be missing something. The OVSBase is never directly used anywhere in
Neutron directory. Of course the return does not do any harm beyond
creating an unused object but it looks to me that it should be removed
unless there is a good reason (or a potential future use case) for it.

Should we remove the return statement?

-Mohammad



class BaseOVS(object):
...
def add_bridge(self, bridge_name):
self.run_vsctl([--, --may-exist, add-br, bridge_name])
return OVSBridge(bridge_name, self.root_helper)



class OVSBridge(BaseOVS):
...
def create(self):
self.add_bridge(self.br_name)



[1]
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ovs_lib.py
___
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-testing] Sharing information

[Mohammad Banikazemi]

Sounds good. Thanks.

Mohammad



From:   Kyle Mestery mest...@siliconloons.com
To: Mohammad Banikazemi/Watson/IBM@IBMUS,
Cc: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org
Date:   01/14/2014 09:31 AM
Subject:Re: [openstack-dev] [neutron] [third-party-testing] Sharing
information



Thanks for sending this note Mohammad. I am all in favor of another
3rd party testing meeting on IRC. How about if we shoot for tomorrow,
Wednesday the 15, at 2200 UTC? Please ack if that works for everyone.

Thanks,
Kyle

On Jan 13, 2014, at 5:08 PM, Mohammad Banikazemi m...@us.ibm.com wrote:

 Hi everybody,

 I see that we already have at least two 3rd party testing setups (from
Arista and Midokura) up and running. Noticed their votes on our newly
submitted plugin.
 The etherpad which is to be used for sharing information about setting up
3rd party testing (as well as multi-node testing) [1] seems to have not
been updated recently. Would those who have setup their 3rd party testing
successfully be willing to share more information as to what they have done
and possibly update the etherpad?

 Would it be of value to others if we have another IRC meeting to discuss
this matter?
 (Kyle, I am sure you are busy so I took the liberty to send this note.
Please let us know what you think.)

 Thanks,

 Mohammad


 [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest

 graycol.gifKyle Mestery ---12/19/2013 09:17:44 AM---Apologies folks, I
meant 2200 UTC Thursday. We'll still do the meeting today.

 From:  Kyle Mestery mest...@siliconloons.com
 To:OpenStack Development Mailing List \(not for usage questions
\) openstack-dev@lists.openstack.org,
 Date:  12/19/2013 09:17 AM
 Subject:   Re: [openstack-dev] [neutron] [third-party-testing]
Reminder:Meeting tomorrow



 Apologies folks, I meant 2200 UTC Thursday. We'll still do the
 meeting today.

 On Dec 18, 2013, at 4:40 PM, Don Kehn dek...@gmail.com wrote:

  Wouldn't 2200 UTC be in about 20 mins?
 
 
  On Wed, Dec 18, 2013 at 3:32 PM, Itsuro ODA o...@valinux.co.jp wrote:
  Hi,
 
  It seems the meeting was not held on 2200 UTC on Wednesday (today).
 
  Do you mean 2200 UTC on Thursday ?
 
  Thanks.
 
  On Thu, 12 Dec 2013 11:43:03 -0600
  Kyle Mestery mest...@siliconloons.com wrote:
 
   Hi everyone:
  
   We had a meeting around Neutron Third-Party testing today on IRC.
   The logs are available here [1]. We plan to host another meeting
   next week, and it will be at 2200 UTC on Wednesday in the
   #openstack-meeting-alt channel on IRC. Please attend and update
   the etherpad [2] with any items relevant to you before then.
  
   Thanks again!
   Kyle
  
   [1]
http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/

   [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  On Wed, 18 Dec 2013 15:10:46 -0600
  Kyle Mestery mest...@siliconloons.com wrote:
 
   Just a reminder, we'll be meeting at 2200 UTC on
#openstack-meeting-alt.
   We'll be looking at this etherpad [1] again, and continuing
discussions from
   last week.
  
   Thanks!
   Kyle
  
   [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest
  
   ___
   OpenStack-dev mailing list
   OpenStack-dev@lists.openstack.org
   http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
  --
  Itsuro ODA o...@valinux.co.jp
 
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 
 
 
  --
  
  Don Kehn
  303-442-0060
  ___
  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



inline: graycol.gif___
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-testing] Sharing information

[Mohammad Banikazemi]

Hi everybody,

I see that we already have at least two 3rd party testing setups (from
Arista and Midokura) up and running. Noticed their votes on our newly
submitted plugin.
The etherpad which is to be used for sharing information about setting up
3rd party testing (as well as multi-node testing) [1] seems to have not
been updated recently. Would those who have setup their 3rd party testing
successfully be willing to share more information as to what they have done
and possibly update the etherpad?

Would it be of value to others if we have another IRC meeting to discuss
this matter?
(Kyle, I am sure you are busy so I took the liberty to send this note.
Please let us know what you think.)

Thanks,

Mohammad


[1] https://etherpad.openstack.org/p/multi-node-neutron-tempest



From:   Kyle Mestery mest...@siliconloons.com
To: OpenStack Development Mailing List \(not for usage questions
\) openstack-dev@lists.openstack.org,
Date:   12/19/2013 09:17 AM
Subject:Re: [openstack-dev] [neutron] [third-party-testing] Reminder:
Meeting tomorrow



Apologies folks, I meant 2200 UTC Thursday. We'll still do the
meeting today.

On Dec 18, 2013, at 4:40 PM, Don Kehn dek...@gmail.com wrote:

 Wouldn't 2200 UTC be in about 20 mins?


 On Wed, Dec 18, 2013 at 3:32 PM, Itsuro ODA o...@valinux.co.jp wrote:
 Hi,

 It seems the meeting was not held on 2200 UTC on Wednesday (today).

 Do you mean 2200 UTC on Thursday ?

 Thanks.

 On Thu, 12 Dec 2013 11:43:03 -0600
 Kyle Mestery mest...@siliconloons.com wrote:

  Hi everyone:
 
  We had a meeting around Neutron Third-Party testing today on IRC.
  The logs are available here [1]. We plan to host another meeting
  next week, and it will be at 2200 UTC on Wednesday in the
  #openstack-meeting-alt channel on IRC. Please attend and update
  the etherpad [2] with any items relevant to you before then.
 
  Thanks again!
  Kyle
 
  [1]
http://eavesdrop.openstack.org/meetings/networking_third_party_testing/2013/

  [2] https://etherpad.openstack.org/p/multi-node-neutron-tempest
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 On Wed, 18 Dec 2013 15:10:46 -0600
 Kyle Mestery mest...@siliconloons.com wrote:

  Just a reminder, we'll be meeting at 2200 UTC on
#openstack-meeting-alt.
  We'll be looking at this etherpad [1] again, and continuing discussions
from
  last week.
 
  Thanks!
  Kyle
 
  [1] https://etherpad.openstack.org/p/multi-node-neutron-tempest
 
  ___
  OpenStack-dev mailing list
  OpenStack-dev@lists.openstack.org
  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

 --
 Itsuro ODA o...@valinux.co.jp


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



 --
 
 Don Kehn
 303-442-0060
 ___
 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

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

Re: [openstack-dev] [neutron] [policy] Complementary or alternative semantics?

[Mohammad Banikazemi]

Hi Tim,

It is complementary (as an extension to the core API).

Mohammad



From:   Tim Hinrichs thinri...@vmware.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   01/06/2014 07:35 PM
Subject:[openstack-dev] [neutron] [policy] Complementary or alternative
semantics?




Over the holidays I realized there's something about the proposed Neutron
policy API that I don't understand.  Is the proposed API complementary to
the core API, or is it intended to be an alternative?  By complementary, I
mean that a user can create a bunch of networks, subnets, and ports and
then constrain how those things interoperate by writing policy.  By an
alternative, I mean that a user must choose either networks/subnets/ports
or policy, but cannot choose both.  I had always assumed we were talking
about a complementary API but wanted to double-check.

Thanks,
Tim

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

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

Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

[Mohammad Banikazemi]

Please have a look at the agenda for tomorrow at
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
It would be great if we could at least close on the following two items
tomorrow:

1.  Converged model by allowing policies to have a destination 
group and
  a source group. Each of these groups can have one or more end points.
2.  Minimum set of actions to support: security, redirect, (and 
possibly
  qos)

We don't need to be perfect and we can always revisit but if we agree on
these we can start thinking about a PoC implementation which itself may
lead to more design issues that we will need to consider and discuss.

Based on the discussions we have had, other items that we need to discuss
include the conflict resolution and also the capability to query a plugin
for supported actions.

Mohammad



From:   Anees A Shaikh/Watson/IBM@IBMUS
To: Stephen Wong s3w...@midokura.com,
Cc: openstack-dev@lists.openstack.org
Date:   12/18/2013 08:02 PM
Subject:Re: [openstack-dev] [neutron][policy] Policy-Rules discussions
based on Dec.12 network policy meeting



folks, sorry for the late input ... a few additional thoughts...

 Hi Prasad,

 Thanks for the comments, please see responses inline.

 On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
 prasad.vellanki at oneconvergence.com wrote:
  Hi
  Please see inline 
 
 
  On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong s3wong at
 midokura.com wrote:
 
  Hi,
 
  During Thursday's  group-policy meeting[1], there are several
  policy-rules related issues which we agreed should be posted on the
  mailing list to gather community comments / consensus. They are:
 
  (1) Conflict resolution between policy-rules
  --- a priority field was added to the policy-rules attributes
  list[2]. Is this enough to resolve conflict across policy-rules (or
  even across policies)? Please state cases where a cross policy-rules
  conflict can occur.
  --- conflict resolution was a major discussion point during
  Thursday's meeting - and there was even suggestion on setting
priority
  on endpoint groups; but I would like to have this email thread
focused
  on conflict resolution across policy-rules in a single policy first.

I agree with keeping the focus on intra-policy conflicts and even there
would suggest we try to keep things dead simple to start at the expense of
some flexibility in handling every use case.  This is a classic problem in
policy frameworks and I hope we don't grind to a halt trying to address
it.

 
  (2) Default policy-rule actions
  --- there seems to be consensus from the community that we need
to
  establish some basic set of policy-rule actions upon which all
  plugins/drivers would have to support
  --- just to get the discussion going, I am proposing:
 
 
  Or should this be a query the plugin for supported actions and thus
the user
  knows what functionality the plugin can support.  Hence there is no
default
  supported list.

 I think what we want is a set of must-have actions which
 application can utilize by default while using the group-policy APIs.
 Without this, application would need to perform many run time checks
 and have unpredictable behavior across different deployments.

 As for querying for a capability list - I am not against having
 such API, but what is the common use case? Having a script querying
 for the supported action list and generate policies based on that?
 Should we expect policy definition to be so dynamic?

My view is that the query capability may be where we try to go eventually,
but we should start with a must-have list that is very small, e.g., just
the security policy.  Other action types would be optional but
well-defined.



 
  a.) action_type: 'security'action: 'allow' | 'drop'
  b.) action_type: 'qos'action: {'qos_class': {'critical' |
  'low-priority' | 'high-priority' |
 
 'low-immediate' | 'high-immediate' |
 
 'expedite-forwarding'}
   (a subset of DSCP values - hopefully in language that
can
  be well understood by those performing application deployments)
  c.) action_type:'redirect'   action: {UUID, [UUID]...}
   (a list of Neutron objects to redirect to, and the list
  should contain at least one element)
 
 
  I am not sure making the UUIDs a list of neutron objects or endpoints
will
  work well. It seems that it should more higher level such as list of
  services that form a chain. Lets say one forms a chain of services,
  firewall, IPS, LB. It would be tough to expect user to derive the
neutron
  ports create a chain of them. It could be a VM UUID.

 Service chain is a Neutron object with UUID:

 https://docs.google.com/document/d/
 1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#

 so this is not defined by the group-policy subgroup, but from a
 different project. We expect operator / tenant to define a service
 chain for the 

Re: [openstack-dev] [neutron] [policy] Policy-group relationship

[Mohammad Banikazemi]

Stephen Wong s3w...@midokura.com wrote on 12/15/2013 12:00:32 PM:

 From: Stephen Wong s3w...@midokura.com
 To: OpenStack Development Mailing List (not for usage questions)
 openstack-dev@lists.openstack.org,
 Date: 12/15/2013 12:04 PM
 Subject: Re: [openstack-dev] [neutron] [policy] Policy-group relationship

 Hi Mohammad,

 Good writeup, one minor comment at the end below (look for [s3wong]).

 On Thu, Dec 12, 2013 at 3:42 PM, Mohammad Banikazemi m...@us.ibm.com
wrote:
  Continuing the discussion we had earlier today during the Neutron Group
  Policy weekly meeting [0], I would like to initiate a couple of email
  threads and follow up on a couple of important issues we need to agree
on so
  we can move forward. In this email thread, I would like to discuss the
  policy-group relationship.
 
  I want to summarize the discussion we had during the meeting [1] and
see if
  we have reached an agreement:
 
  There are two models for expressing the relationship between Groups and
  Policies that were discussed:
  1- Policies are defined for a source Group and a destination Group
  2- Groups specify the Policies they provide and the Policies they
  consume
 
  As expressed during the IRC meeting, both models have strong support
and we
  decided to have a resource model that can be used to express both
models.
  The solution we came up with was rather simple:
 
  Update the resource model (shown in the attribute tables and the
taxonomy in
  the google doc [2]) such that policy can refer to a list of source
Groups
  and a list of destination Groups.
  This boils down to having two attributes namely, src_groups and
  destination_groups (both list of uuid-str type) replacing the current
  attributes src_group and dest_group, respectively.
 
  This change simply allows the support for both models. For supporting
model
  1, specify a single source Group and a single destination Group. For
model
  2, specify the producers of a Policy in the source Group list and
specify
  the consumers of the Policy in the destination Group list.

 [s3wong] this is interesting. Let's say we have two groups A  B, and
 A wants to send traffic to B, so in this case, B is providing a policy
 which A will consume. In your proposal above, I would have to put A in
 destination group list and B in source group list although the traffic
 direction is the reverse. Would that cause a bit of a confusion?


Yeah, that's a good point. Producers are the destination of traffic flows.
So should we have them under destination group? Even that is a bit
confusing.
May be we need different names for the two groups.

-Mohammad

 Thanks,
 - Stephen


 
  If there is agreement, I will update the taxonomy and the attribute
tables
  in the doc.
 
  Best,
 
  Mohammad
 
 
  [0] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
  [1]
  http://eavesdrop.openstack.org/meetings/networking_policy/2013/
 networking_policy.2013-12-12-16.01.log.html
  [2]
  https://docs.google.com/document/d/
 1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n
  (Note the new additions are at the end of the document.)
 
 
  ___
  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] [neutron] [policy] Policy-group relationship

[Mohammad Banikazemi]

Continuing the discussion we had earlier today during the Neutron Group
Policy weekly meeting [0], I would like to initiate a couple of email
threads and follow up on a couple of important issues we need to agree on
so we can move forward. In this email thread, I would like to discuss the
policy-group relationship.

I want to summarize the discussion we had during the meeting [1] and see if
we have reached an agreement:

There are two models for expressing the relationship between Groups and
Policies that were discussed:
1- Policies are defined for a source Group and a destination Group
2- Groups specify the Policies they provide and the Policies they
consume

As expressed during the IRC meeting, both models have strong support and we
decided to have a resource model that can be used to express both models.
The solution we came up with was rather simple:

Update the resource model (shown in the attribute tables and the taxonomy
in the google doc [2]) such that policy can refer to a list of source
Groups and a list of destination Groups.
This boils down to having two attributes namely, src_groups and
destination_groups (both list of uuid-str type) replacing the current
attributes src_group and dest_group, respectively.

This change simply allows the support for both models. For supporting model
1, specify a single source Group and a single destination Group. For model
2, specify the producers of a Policy in the source Group list and specify
the consumers of the Policy in the destination Group list.

If there is agreement, I will update the taxonomy and the attribute tables
in the doc.

Best,

Mohammad


[0] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
[1]
http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html
[2]
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n
   (Note the new additions are at the end of the document.)
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Calling a controller from within a session in the plugin

[Mohammad Banikazemi]

Have a question regarding calling an external SDN controller in a plugin.
The ML2 model brings up the fact that it is preferred not to call an
external controller within a database session by splitting up each call
into two calls: *_precommit and *_postcommit. Makes sense.

Looking at the existing monolithic plugins, I see some plugins that do not
follow this approach and have the call to the controller from within a
session. The obvious benefit of this approach would be a simpler cleanup
code segment for cases where the call to controller fails. So my question
is whether it is still OK to use this simpler approach in monolithic
plugins. As we move to the ML2 model, we will be using the ML2 approach but
in the meantime, we leave the option of calling the controller within a
session as an OK option. Would that be reasonable?

-Mohammad

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

[openstack-dev] [neutron] [policy] Neutron Policy IRC meeting

[Mohammad Banikazemi]

Hello everybody,

Following up the action items from our last meeting and in preparation for
our next IRC meeting on Dec 5th (see below), I have started updating the
google document [1].
I have added the tables describing the attributes of new Neutron objects. I
will be also working on adding a few possible action types for policy
rules.

Please visit the document and make suggestions and provide feedback.

Thanks,

-Mohammad

[1]
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#



From:   Kyle Mestery (kmestery) kmest...@cisco.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   11/21/2013 12:03 PM
Subject:[openstack-dev] [neutron] [policy] Logs and notes from first
Neutron Policy IRC meeting



HI all!

The Neutron Policy sub-team had it's first IRC meeting today [1].
Relevant logs from the meeting are here [2]. We're hoping to
continue the discussion going forward. I've noted action items
in both the meeting logs and on the wiki page. We'll cover those
for the next meeting we have.

Note: We'll not meet next week due to the Thanksgiving holiday
in the US.

Hope to see everyone on #openstack-meeting-alt at 1600 UTC
on Thursday December 5th! In the meantime, please continue
the discussion in IRC on #openstack-neutron and on the
openstack-dev mailing list.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
[2] http://eavesdrop.openstack.org/meetings/networking_policy/2013/

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

inline: graycol.gif___
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 Sub-team Meetings

[Mohammad Banikazemi]

Kyle,

Thank you for organizing this.

I think the original email you sent out did not solicit any comments
(except for possibly proposing a different time for the weekly meetings).
So that is probably why you have not heard from anybody (including me). So
we are ready to have the meeting but if the consensus is that people need
more time to prepare that is fine too.
I think we need to set an agenda for our meeting (similar to what you do
for the ML2 calls) so we have a better idea of what we need to do during
the meeting. In the proposal, we have identified new object resources.
Should we start making those definitions and their relationship with other
objects more precise. Just a suggestion.

Thanks,

Mohammad




From:   Kyle Mestery (kmestery) kmest...@cisco.com
To: OpenStack Development Mailing List (not for usage questions)
openstack-dev@lists.openstack.org,
Date:   11/13/2013 01:09 PM
Subject:Re: [openstack-dev] [neutron] Group-based Policy Sub-team
Meetings



On Nov 13, 2013, at 10:36 AM, Stephen Wong s3w...@midokura.com
 wrote:

 Hi Kyle,

So no meeting this Thursday?

I am inclined to skip this week's meeting due to the fact I haven't heard
many
replies yet. I think a good starting point for people would be to review
the
BP [1] and Design Document [2] and provide feedback where appropriate.
We should start to formalize what the APIs will look like at next week's
meeting,
and the Design Document has a first pass at this.

Thanks,
Kyle

[1]
https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction

[2]
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit?usp=sharing


 Thanks,
 - Stephen

 On Wed, Nov 13, 2013 at 7:11 AM, Kyle Mestery (kmestery)
 kmest...@cisco.com wrote:
 On Nov 13, 2013, at 8:58 AM, Stein, Manuel (Manuel)
manuel.st...@alcatel-lucent.com wrote:

 Kyle,

 I'm afraid your meeting vanished from the Meetings page [2] when user
amotiki reworked neutron meetings ^.^
 Is the meeting for Thu 1600 UTC still on?

 Ack, thanks for the heads up here! I have re-added the meeting. I only
heard
 back from one other person other than yourself, so at this point I'm
inclined
 to wait until next week to hold our first meeting unless I hear back
from others.

 A few heads-up questions (couldn't attend the HK design summit Friday
meeting):

 1) In the summit session Etherpad [3], ML2 implementation mentions
insertion of arbitrary metadata to hint to underlying implementation. Is
that (a) the plug-ing reporting its policy-bound realization? (b) the user
further specifying what should be used? (c) both? Or (d) none of that but
just some arbitrary message of the day?

 I believe that would be (a).

 2) Would policies _always_ map to the old Neutron entities?
 E.g. when I have policies in place, can I query related network/port,
subnet/address, router elements on the API or are there no equivalents
created? Would the logical topology created under the policies be exposed
otherwise? for e.g. monitoring/wysiwyg/troubleshoot purposes.

 No, this is up to the plugin/MechanismDriver implementation.

 3) Do the chain identifier in your policy rule actions match to
Service Chain UUID in Service Insertion, Chaining and API [4]

 That's one way to look at this, yes.

 4) Are you going to describe L2 services the way group policies work? I
mean, why would I need a LoadBalancer or Firewall instance before I can
insert it between two groups when all that load balancing/firewalling
requires is nothing but a policy for group communication itself? -
regardless the service instance used to carry out the service.

 These are things I'd like to discuss at the IRC meeting each week. The
goal
 would be to try and come up with some actionable items we can drive
towards
 in both Icehouse-1 and Icehouse-2. Given how close the closing of
Icehouse-1
 is, we need to focus on this very fast if we want to have a measurable
impact in
 Icehouse-1.

 Thanks,
 Kyle


 Best, Manuel

 [2]
https://wiki.openstack.org/wiki/Meetings#Neutron_Group_Policy_Sub-Team_Meeting

 [3]
https://etherpad.openstack.org/p/Group_Based_Policy_Abstraction_for_Neutron
 [4]
https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#


 -Original Message-
 From: Kyle Mestery (kmestery) [mailto:kmest...@cisco.com]
 Sent: Montag, 11. November 2013 19:41
 To: OpenStack Development Mailing List (not for usage questions)
 Subject: [openstack-dev] [neutron] Group-based Policy
 Sub-team Meetings

 Hi folks! Hope everyone had a safe trip back from Hong Kong.
 Friday afternoon in the Neutron sessions we discussed the
 Group-based Policy Abstraction BP [1]. It was decided we
 would try to have a weekly IRC meeting to drive out further
 requirements with the hope of coming up with a list of
 actionable tasks to begin working on by December.
 I've tentatively set the meeting [2] for Thursdays at 1600
 UTC on the #openstack-meeting-alt IRC channel.