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

[Ivar Lazzaro]

Hello Team,

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

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

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

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

Please share your thoughts, Thanks,
Ivar.

[0]
http://eavesdrop.openstack.org/meetings/networking_policy/2015/networking_policy.2015-04-09-18.00.log.txt
[1] https://bugs.launchpad.net/group-based-policy/+bug/1443606
[2] https://review.openstack.org/#/c/170972/
[3] https://review.openstack.org/#/c/173051/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [stable] freeze exception

[Ivar Lazzaro]

Hello Folks,

I'd like to request a freeze exception for the following changeset:

https://review.openstack.org/169844

I believe that's an unharmful change, I apologize for getting it under
review so late :)

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

[openstack-dev] [Group-Based-Policy] Use cases for External Policy chains

[Ivar Lazzaro]

Hello,

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

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

Thanks for your feedbacks,
Ivar.

[0] https://bugs.launchpad.net/group-based-policy/+bug/1432779
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Hello Folks,

[tl;dr]

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

[boringpostwithexampleandstuff]

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

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

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

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

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

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

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

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

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

Thanks,
Ivar.

[0] https://bugs.launchpad.net/group-based-policy/+bug/1432816
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Group-Based-Policy] How to deal with "improvements"

[Ivar Lazzaro]

Hello Folks,

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

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

Please provide guidance, thanks,

Ivar.

[0]
https://github.com/stackforge/group-based-policy-specs/blob/master/specs/juno/introduce-shared-attribute.rst
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron][cisco][apic] entry point for APIC agent

[Ivar Lazzaro]

Hi Ihar,

That was missed for the Juno release, I'll post a patch on master and then
backport it to stable/juno.

Thanks for catching that,
Ivar.

On Fri Feb 20 2015 at 11:06:11 AM Ihar Hrachyshka 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi,
>
> does anyone know why we don't maintain an entry point for APIC agent
> in setup.cfg? The code in [1] looks like there is a main() function
> for the agent, but for some reason it's not exposed to any
> console_script during installation of neutron.
>
> Is there any reason not to do it?
>
> [1]:
> http://git.openstack.org/cgit/openstack/neutron/tree/neutron
> /plugins/ml2/drivers/cisco/apic/apic_topology.py#n320
>
> /Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJU54WDAAoJEC5aWaUY1u57m/oH/1sUvwf9v/sKYbfZXU23h0I4
> GJpPfI70l0NktkFIObO2tikshaSKygC0wv7zk6HGEiE2b0ATC5fRv0VaNtk7WMKu
> PqCWK6PV6IvuphZbt4f6A7mJ7JpSn06SQe0TEPABx9DUhybjXJ6iP0hSSb/Te+2M
> MP17IlepgHNasegiCD1VsWKAy3ZmnC5GwM+H6qKIe2pmn7NjBqXh8uRxbv/IzGjJ
> 3YxHhS35xHd31neR9B7V16peXy1lTjwFkyw8XlJNufAmOhCVsN0uIDAhwv3XJRHF
> +9MOgpB0fpVqxbEWrflW1Lmy06Hr/scq/t7bQt4Lntu3A+PQEQJ0kx4aHElreyw=
> =K7In
> -END PGP SIGNATURE-
>
> __
> 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] moving openvswitch ports between namespaces considered harmful

[Ivar Lazzaro]

I agree with Kevin that we should adopt veth pairs for fixing the issue in
the short term, at least until CT gets merged and distributed in OVS. At
that point the transition to a OVS based solution will make a lot of sense,
given that the numbers show that it's worth of course ;)

On Sun Feb 15 2015 at 7:17:39 AM Thomas Graf 
wrote:
>
> FYI: Ivar (CCed) is also working on collecting numbers to compare both
> architectures to kick of a discussion at the next summit. Ivar, can
> you link to the talk proposal?
>

Thanks for bringing this up Thomas! Here is the link to the talk proposal
[0].
Any with suggestion, idea or random comment is very welcome!

Ivar.

[0]
https://www.openstack.org/vote-paris/presentation/taking-security-groups-to-ludicrous-speed-with-open-vswitch
__
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] UniqueConstraint for name and tenant_id in security group

[Ivar Lazzaro]

In general, I agree with Jay about the opaqueness of the names. I see
however good reasons for having user-defined unique attributes (see
 Clint's point about idempotency).
A middle ground here could be granting to the users the ability to specify
the resource ID.
A similar proposal was made some time ago by Eugene [0]


[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-September/046150.html

On Thu, Dec 11, 2014 at 6:59 AM, Mark McClain  wrote:
>
>
> On Dec 11, 2014, at 8:43 AM, Jay Pipes  wrote:
>
> I'm generally in favor of making name attributes opaque, utf-8 strings
> that are entirely user-defined and have no constraints on them. I consider
> the name to be just a tag that the user places on some resource. It is the
> resource's ID that is unique.
>
> I do realize that Nova takes a different approach to *some* resources,
> including the security group name.
>
> End of the day, it's probably just a personal preference whether names
> should be unique to a tenant/user or not.
>
> Maru had asked me my opinion on whether names should be unique and I
> answered my personal opinion that no, they should not be, and if Neutron
> needed to ensure that there was one and only one default security group for
> a tenant, that a way to accomplish such a thing in a race-free way, without
> use of SELECT FOR UPDATE, was to use the approach I put into the pastebin
> on the review above.
>
>
> I agree with Jay.  We should not care about how a user names the
> resource.  There other ways to prevent this race and Jay’s suggestion is a
> good one.
>
> mark
>
>
>
> ___
> 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] Core/Vendor code decomposition

[Ivar Lazzaro]

Hi Armando,

Thanks for your feedback!

Okay, so if I understand you correctly, you're saying that was easier for
> you to go entirely out of tree, and that you have done so already. Okay,
> good for you, problem solved!
>
> One point that should be clear here is that, if someone is completely
> comfortable with being entirely out of tree, and he/she has done so already
> (I know of a few other examples besides the apic driver), then this
> proposal does not apply to them.
>
> They are way ahead of us, and kudos to them!
>

Actually, the apic driver lives out of tree only for the icehouse release,
that was just a practical example of how the "satellite" approach would
work.

Honestly, I think we can only declare victory and say that the "problem is
solved" only when we finally define a standard way for this split to
happen! And that's the whole point of the current proposal [0] and also the
point of this discussion.
If it wasn't the case, we could have just said "by M all the vendor code
will be removed, it's your problem now!" :)

My concern about the current proposal is that it still keeps a lot of
vendor code in tree. I was so wondering why this is necessary, thus looking
for feedback on the approach hinted in my previous email.

Well, you live in a nice wonderland, I envy you! This co-gating decision is
> the result of a discussion with infra folks.


Then the white rabbit in my head lied to me :) !! Thanks for the
clarification. The ML2 part of my previous email was just an almost
orthogonal discussion though, it doesn't change the fact that IMHO we could
handle the standard split differently.

Ivar.

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

On Tue, Dec 9, 2014 at 2:21 PM, Armando M.  wrote:

>
>
> On 9 December 2014 at 13:59, Ivar Lazzaro  wrote:
>
>> I agree with Salvatore that the split is not an easy thing to achieve for
>> vendors, and I would like to bring up my case to see if there are ways to
>> make this at least a bit simpler.
>>
>> At some point I had the need to backport vendor code from Juno to
>> Icehouse (see first attempt here [0]). That in [0] was some weird approach
>> that put unnecessary burden on infra, neutron cores and even packagers, so
>> I decided to move to a more decoupled approach that was basically
>> completely splitting my code from Neutron. You can find the result here [1].
>> The focal points of this approach are:
>>
>> * **all** the vendor code is removed;
>> * Neutron is used as a dependency, pulled directly from github for UTs
>> (see test-requirements [2]) and explicitly required when installing the
>> plugin;
>> * The Database and Schema is the same as Neutron's;
>> * A migration script exists for this driver, which uses a different (and
>> unique) version_table (see env.py [3]);
>> * Entry points are properly used in setup.cfg [4] in order to provide
>> migration scripts and Driver/Plugin shortcuts for Neutron;
>> * UTs are run by including Neutron in the venv [2].
>> * The boilerplate is taken care by cookiecutter [5].
>>
>
>> The advantage of the above approach, is that it's very simple to pull off
>> (only thing you need is cookiecutter, a repo, and then you can just
>> replicate the same tree structure that existed in Neutron for your own
>> vendor code). Also it has the advantage to remove all the vendor code from
>> Neutron (did I say that already?). As far as the CI is concerned, it just
>> needs to "learn" how to install the new plugin, which will require Neutron
>> to be pre-existent.
>>
>> The typical installation workflow would be:
>> - Install Neutron normally;
>> - pull from pypi the vendor driver;
>> - run the vendor db migration script;
>> - Do everything else (configuration and execution) just like it was done
>> before.
>>
>> Note that this same satellite approach is used by GBP (I know this is a
>> bad word that once brought hundreds of ML replies, but that's just an
>> example :) ) for the Juno timeframe [6]. This shows that the very same
>> thing can be easily done for services.
>>
>
> Okay, so if I understand you correctly, you're saying that was easier for
> you to go entirely out of tree, and that you have done so already. Okay,
> good for you, problem solved!
>
> One point that should be clear here is that, if someone is completely
> comfortable with being entirely out of tree, and he/she has done so already
> (I know of a few other examples besides the apic driver), then this
> proposal does not apply to them.
>
> They are way ahead of us, and kudos to them!
>
> As far you're concerned, Ivar, if you wa

Re: [openstack-dev] [Neutron] Core/Vendor code decomposition

[Ivar Lazzaro]

I agree with Salvatore that the split is not an easy thing to achieve for
vendors, and I would like to bring up my case to see if there are ways to
make this at least a bit simpler.

At some point I had the need to backport vendor code from Juno to Icehouse
(see first attempt here [0]). That in [0] was some weird approach that put
unnecessary burden on infra, neutron cores and even packagers, so I decided
to move to a more decoupled approach that was basically completely
splitting my code from Neutron. You can find the result here [1].
The focal points of this approach are:

* **all** the vendor code is removed;
* Neutron is used as a dependency, pulled directly from github for UTs (see
test-requirements [2]) and explicitly required when installing the plugin;
* The Database and Schema is the same as Neutron's;
* A migration script exists for this driver, which uses a different (and
unique) version_table (see env.py [3]);
* Entry points are properly used in setup.cfg [4] in order to provide
migration scripts and Driver/Plugin shortcuts for Neutron;
* UTs are run by including Neutron in the venv [2].
* The boilerplate is taken care by cookiecutter [5].

The advantage of the above approach, is that it's very simple to pull off
(only thing you need is cookiecutter, a repo, and then you can just
replicate the same tree structure that existed in Neutron for your own
vendor code). Also it has the advantage to remove all the vendor code from
Neutron (did I say that already?). As far as the CI is concerned, it just
needs to "learn" how to install the new plugin, which will require Neutron
to be pre-existent.

The typical installation workflow would be:
- Install Neutron normally;
- pull from pypi the vendor driver;
- run the vendor db migration script;
- Do everything else (configuration and execution) just like it was done
before.

Note that this same satellite approach is used by GBP (I know this is a bad
word that once brought hundreds of ML replies, but that's just an example
:) ) for the Juno timeframe [6]. This shows that the very same thing can be
easily done for services.

As far as ML2 is concerned, I think we should split it as well in order to
treat all the plugins equally, but with the following caveats:

* ML2 will be in a openstack repo under the networking program (kind of
obvious);
* The drivers can decide wether to stay in tree with ML2 or not (for a
better community effort, but they will definitively evolve slower);
* Don't care about the governance, Neutron will be in charge of this repo
and will have the ability to promote whoever they want when needed.

As far as cogating is concerned, I think that using the above approach the
breaking will exist just as long as the infra job understands how to
install the ML2 driver from it's own repo. I don't see it as a big issue,
But maybe it's just me, and my fabulous world where stuff works for no good
reason. We could at least ask the infra team to understand it it's feasible.
Moreover, this is a work that we may need to do anyway! So it's better to
just start it now thus creating an example for all the vendors that have to
go through the split (back on Gary's point).

Appreciate your feedback,
Ivar.

[0] https://review.openstack.org/#/c/123596/
[1] https://github.com/noironetworks/apic-ml2-driver/tree/icehouse
[2]
https://github.com/noironetworks/apic-ml2-driver/blob/icehouse/test-requirements.txt
[3]
https://github.com/noironetworks/apic-ml2-driver/blob/icehouse/apic_ml2/neutron/db/migration/alembic_migrations/env.py
[4] https://github.com/noironetworks/apic-ml2-driver/blob/icehouse/setup.cfg
[5] https://github.com/openstack-dev/cookiecutter
[6] https://github.com/stackforge/group-based-policy

On Tue, Dec 9, 2014 at 9:53 AM, Salvatore Orlando 
wrote:

>
>
> On 9 December 2014 at 17:32, Armando M.  wrote:
>
>>
>>
>> On 9 December 2014 at 09:41, Salvatore Orlando 
>> wrote:
>>
>>> I would like to chime into this discussion wearing my plugin developer
>>> hat.
>>>
>>> We (the VMware team) have looked very carefully at the current proposal
>>> for splitting off drivers and plugins from the main source code tree.
>>> Therefore the concerns you've heard from Gary are not just ramblings but
>>> are the results of careful examination of this proposal.
>>>
>>> While we agree with the final goal, the feeling is that for many plugin
>>> maintainers this process change might be too much for what can be
>>> accomplished in a single release cycle.
>>>
>> We actually gave a lot more than a cycle:
>>
>>
>> https://review.openstack.org/#/c/134680/16/specs/kilo/core-vendor-decomposition.rst
>> LINE 416
>>
>> And in all honestly, I can only tell that getting this done by such an
>> experienced team like the Neutron team @VMware shouldn't take that long.
>>
>
> We are probably not experienced enough. We always love to learn new things.
>
>
>>
>> By the way, if Kyle can do it in his teeny tiny time that he has left
>> after his PTL duties, then anyone can do it! :)
>>
>>

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

[Ivar Lazzaro]

While I agree that a unified endpoint could be a good solution for now, I
think that the easiest way of doing this would be by implementing it as an
external Neutron service.

Using python entry_points, the advanced service extensions can be loaded in
Neutron just like we do today (using neutron.conf).

We will basically have a new project for which Neutron will be a dependency
(not the other way around!) so that any module of Neutron can be
imported/used just like the new code was living within Neutron itself.

As far as UTs are concerned, Neutron will also be in the test-requirements
for the new project, which means that any existing UT framework in Neutron
today can be easily reused by the new services.

This is compliant with the requirement that Neutron stays the only
endpoint, giving the ability to the user to load the new services when she
wants by configuring Neutron alone, while separating the concerns more
easily and clearly.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

>
> There would not be a service or REST API associated with the Advanced
> Services code base? Would the REST API to talk to those services be part of
> the Neutron repository?


This is a good question.

Also, I would love to have more details about the following point:

- The Advance Service Library would be an optional dependency of Neutron


If I understand correctly, the Advanced Services implementation will
probably use Neutron's resources for L2/L3 connectivity (eg. create a
port). So why are we planning on having this library as a Neutron's
dependency and not the way around?
Wouldn't this require extra changes in Neutron to happen before the split
can happen? Also, shouldn't the AS APIs exist in the AS project?

Imho, having this project act as an external Neutron extension makes more
sense. Have you considered this option? It requires less cross-project
changes and provides a very clear separation of concerns.

Thanks for your heads up,
Ivar.

On Tue, Nov 18, 2014 at 2:45 PM, Doug Hellmann 
wrote:

>
> On Nov 18, 2014, at 5:31 PM, Mark McClain  wrote:
>
> All-
>
> Over the last several months, the members of the Networking Program have
> been discussing ways to improve the management of our program.  When the
> Quantum project was initially launched, we envisioned a combined service
> that included all things network related.  This vision served us well in
> the early days as the team mostly focused on building out layers 2 and 3;
> however, we’ve run into growth challenges as the project started building
> out layers 4 through 7.  Initially, we thought that development would float
> across all layers of the networking stack, but the reality is that the
> development concentrates around either layer 2 and 3 or layers 4 through
> 7.  In the last few cycles, we’ve also discovered that these concentrations
> have different velocities and a single core team forces one to match the
> other to the detriment of the one forced to slow down.
>
> Going forward we want to divide the Neutron repository into two separate
> repositories lead by a common Networking PTL.  The current mission of the
> program will remain unchanged [1].  The split would be as follows:
>
> Neutron (Layer 2 and 3)
> - Provides REST service and technology agnostic abstractions for layer 2
> and layer 3 services.
>
> Neutron Advanced Services Library (Layers 4 through 7)
> - A python library which is co-released with Neutron
> - The advance service library provides controllers that can be configured
> to manage the abstractions for layer 4 through 7 services.
>
> Mechanics of the split:
> - Both repositories are members of the same program, so the specs
> repository would continue to be shared during the Kilo cycle.  The PTL and
> the drivers team will retain approval responsibilities they now share.
> - The split would occur around Kilo-1 (subject to coordination of the
> Infra and Networking teams). The timing is designed to enable the proposed
> REST changes to land around the time of the December development sprint.
> - The core team for each repository will be determined and proposed by
> Kyle Mestery for approval by the current core team.
> - The Neutron Server and the Neutron Adv Services Library would be
> co-gated to ensure that incompatibilities are not introduced.
> - The Advance Service Library would be an optional dependency of Neutron,
> so integrated cross-project checks would not be required to enable it
> during testing.
> - The split should not adversely impact operators and the Networking
> program should maintain standard OpenStack compatibility and deprecation
> cycles.
>
> This proposal to divide into two repositories achieved a strong consensus
> at the recent Paris Design Summit and it does not conflict with the current
> governance model or any proposals circulating as part of the ‘Big Tent’
> discussion.
>
> Kyle and mark
>
> [1]
> https://git.openstack.org/cgit/openstack/governance/plain/reference/programs.yaml
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> There would not be a service or REST API associated with the Advanced
> Services code base? Would the REST API to talk to those services be part of
> the Neutron repository?
>
> Doug
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

>
> It seems to me that deployment tools such as puppet scripts would also be
> simpler if the GBP service plugin used the neutron DB, as there would be no
> need to create a separate DB, set its permissions, put its URL into
> neutron's config file, etc.. All that would be needed at deployment time is
> to run the additional gbp-db-manage tool to perform the GBP DB migrations.
> Am I missing anything?
>
>
That's correct, being a new schema it needs to be created, the access
granted, and the connection URL configured in neutron.conf (doable also
with devstack in the extra-conf option).


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

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


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


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

Ivar.

On Fri, Oct 10, 2014 at 2:59 PM, Robert Kukura 
wrote:

>
> On 10/7/14 6:36 PM, Ivar Lazzaro wrote:
>
> I posted a patch that implements the "Different DB Different Chain"
> approach [0].
> That does not mean that this approach is the chosen one! It's just to have
> a grasp of what the change looks like.
>
>  The "Same DB different chain" solution is much simpler to implement
> (basically you just specify a different version table in the alembic
> environment) so I haven't posted anything for that.
>
>  One thing I'm particularly interested about is to hear packagers
> opinions about which approach would be the preferred one: Same DB or
> Different?
>
> It seems to me that deployment tools such as puppet scripts would also be
> simpler if the GBP service plugin used the neutron DB, as there would be no
> need to create a separate DB, set its permissions, put its URL into
> neutron's config file, etc.. All that would be needed at deployment time is
> to run the additional gbp-db-manage tool to perform the GBP DB migrations.
> Am I missing anything?
>
> With dependencies only in one direction, and the foreign keys GBP depends
> on (neutron resource IDs) unlikely to be changed by neutron migrations
> during Kilo, I don't think we need to worry about interleaving GBP
> migrations with neutron migrations. On initial deployments or version
> upgrades, it should be sufficient to run gbp-db-manage after
> neutron-db-manage. On downgrades, some situations might require running
> gbp-db-manage before neutron-db-manage. This seems not to be effected by
> whether the two migration chains are in the same DB/schema or different
> ones.
>
>  Also, on the line of Bob's comment in my patch, is there any kind of
> compatibility or performance issue anyone is aware of about in using cross
> schema FKs?
>
> In addition to compatibility and performance, I'm also concerned about DB
> connection management when the same server is using multiple connection
> URLs. I'm not convinced the approach in the patch is sufficient. At least
> with some DBs, wouldn't we we need a separate sqlalchemy.create_engine()
> call with each DB's connection URL, which might require using separate
> context and session objects rather than the ones neutron uses?
>
> -Bob
>
>
>  Thanks,
> Ivar.
>
>  [0] https://review.openstack.org/#/c/126383/
>
> On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro 
> wrote:
>
>>  I believe Group-based Policy (which this thread is about) will use the
>>> Neu

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

[Ivar Lazzaro]

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

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

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

Thanks,
Ivar.

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

On Mon, Oct 6, 2014 at 11:09 AM, Ivar Lazzaro  wrote:

> I believe Group-based Policy (which this thread is about) will use the
>> Neutron
>> database configuration for its dependent database.
>>
>> If Neutron is configured for:
>>   connection = mysql://user:pass@locationX:3306/neutron
>> then GBP would use:
>>   connection = mysql://user:pass@locationX:3306/neutron_gbp
>
>
> That's correct, that would be the likely approach if we go with the
> "different schema" route.
>
> if you can get the “other database” to be accessible from the target
>> database via “otherdatabase.sometable”, then you’re in.
>> from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the
>> database itself that has to support the foreign key at the scope you are
>> shooting for.
>>
>
> I'm experimenting this approach with our code and it seems to be the case.
> '
> I feel that having the constraint of pointing the same database connection
> with a different schema is pretty acceptable given how tight is GBP to
> Neutron.
>
>
> On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau  wrote:
>
>> Clint Byrum  wrote:
>> >
>> > Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
>> >>
>> >> On Oct 4, 2014, at 1:10 AM, Kevin Benton  wrote:
>> >>
>> >>> Does sqlalchemy have good support for cross-database foreign keys? I
>> was under the impression that they cannot be implemented with the normal
>> syntax and semantics of an intra-database foreign-key constraint.
>> >>
>> >> cross “database” is not typically portable, but cross “schema” is.
>> >>
>> >> different database vendors have different notions of “databases” or
>> “schemas”.
>> >>
>> >> if you can get the “other database” to be accessible from the target
>> database via “otherdatabase.sometable”, then you’re in.
>> >>
>> >> from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the
>> database itself that has to support the foreign key at the scope you are
>> shooting for.
>> >>
>> >
>> > All true, however, there are zero guarantees that databases will be
>> > hosted on the same server, and typically permissions are setup to
>> prevent
>> > cross-schema joins.
>>
>> I believe Group-based Policy (which this thread is about) will use the
>> Neutron
>> database configuration for its dependent database.
>>
>> If Neutron is configured for:
>>   connection = mysql://user:pass@locationX:3306/neutron
>> then GBP would use:
>>   connection = mysql://user:pass@locationX:3306/neutron_gbp
>>
>> > Typically we use the public API's when we want to access data in a
>> > different application. The database is a private implementation detail
>> > of each application.
>>
>> Currently GPB is very tightly coupled to Neutron.
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] how to add a new plugin to the neutron repo?

[Ivar Lazzaro]

Hi,

There are mainly two things you need to know when proposing a new Neutron
Plugin (or even any Openstack feature):

- The process [0];
- The tools [1].

Although the above documents cover those two points pretty well, I can give
you a high level overview of what the process looks like.
I'll not cover the "how to implement a plugin" part since it looks like you
are already past that :)

In order to add a new plugin/feature to the neutron repo, you first need to
propose it through our *specification process*.
The first step is to file a blueprint on launchpad [2] (register a
blueprint), in which you very briefly explain what you are trying to
attempt.
You can find many examples on how to write a blueprint in [2], but it'll
more or less look like this:


> *name: ferryboat-l2-plugin**title: L2 Neutron Plugin for supporting
> Ferryboat framework*


>
> *Summary:*
> *This proposal tracks the implementation of a new Neutron core plugin
> which allows the user **to implement L2 networks on the Ferryboat
> technology. In its first release, the plugin will support:*
>
> *- Port, Subnet, Network APIs;*
> *- Router APIs;**- Floating IPs;*
> *Security group support is planned for further iterations.*


Once you have filed the blueprint, you can publish your spec[3](look at
"Spec + Blueprints lifecycle" section) in the spec repo[4].
To do that, follow the Gerrit Workflow ([1] for details).
In a nutshell, you need to:

- Clone the spec repository locally,
- Write a specification following the template, it should be targeted to
Kilo (specs/kilo)
- Run "git review" so that it can be reviewed by the core dev team.

Once you do that, you spec will be published for review in the Openstack's
review board [5], where it'll have to wait for some core reviewer's
attention in order to
get approved.

Now to the actual patch:
When the specification gets approved (or even in parallel actually), you
can publish you Ferryboat plugin code for review just like you did for the
spec.
GerritWorkflow[1] will provide you a very clear understanding on how to
configure/use git in order to be able to do that.
So, again, you'll have to clone the Neutron's repository, add your code in
a local branch properly named, and then run "git review" so that it gets
published in the
review board.
In order to get approved and finally merged in the main Neutron repo, your
plugin needs to pass at least the following criteria:

- Pass all the unit tests;
- Its own unit tests have to be implemented! With as much code coverage as
possible;
- The Spec discussed above have to be approved and properly targeted;
- A *Third party CI system [5] *needs to be in place and positively voting
your patch;
- At least 2 core developers need to approve the patch based on its
compliance in terms of functionalities and code quality.

For those who implement a Neutron plugin for the first time, the Third
Party Ci system is usually the moment in which things get very hard!
The documentation pointed in [5][6], plus participating the weakly CI
meetings, should be enough for you to understand what needs to be done.
Very rapidly, Neutron needs to make sure that your plugin actually works,
and you want to make sure that no changes are trying to break your plugin!
To reach the goal,
you'll need to setup a continuous integration system "at home" which votes
a rightful amount of patches in review in order to validate that your
implementation is not
broken. Without a CI in place you plugin won't be approved, and removed if
already in tree.

The above should cover roughly 60% of the whole process, there are other
small details like the commit format, unit testing, and other things that
would be useless to overload here.
More than that, I suggest you to go on the IRC channels and look for help
there. My IRC alias is ivar-lazzaro, feel free to contact me :)

Last but not least, the first push in Openstack (especially if it's
something so big as a vendor plugin) is always tough! You'll go through a
TON of review rounds and nasty issues.
But don't be discouraged! It gets way better once you grasp the whole
process :)

Cheers,
Ivar.

[0] https://wiki.openstack.org/wiki/NeutronDevelopment
[1] https://wiki.openstack.org/wiki/Gerrit_Workflow
[2] https://launchpad.net/neutron
[3] https://wiki.openstack.org/wiki/Neutron/BlueprintTemplate
[4] https://github.com/openstack/neutron-specs
[5]
https://review.openstack.org/#/q/status:open+project:openstack/neutron-specs,n,z
[4] https://github.com/openstack/neutron
<https://github.com/openstack/neutron-specs>
[5] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
[6] http://ci.openstack.org/third_party.html
[7] https://wiki.openstack.org/wiki/IRC

On Sun, Oct 5, 2014 at 9:51 PM, thanh le giang 
wrote:

> Hi all
>
>
>
> I want to add a plugin to the Public Neutron Repository. Althou

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

[Ivar Lazzaro]

>
> I believe Group-based Policy (which this thread is about) will use the
> Neutron
> database configuration for its dependent database.
>
> If Neutron is configured for:
>   connection = mysql://user:pass@locationX:3306/neutron
> then GBP would use:
>   connection = mysql://user:pass@locationX:3306/neutron_gbp


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

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

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


On Sat, Oct 4, 2014 at 8:54 AM, Henry Gessau  wrote:

> Clint Byrum  wrote:
> >
> > Excerpts from Mike Bayer's message of 2014-10-04 08:10:38 -0700:
> >>
> >> On Oct 4, 2014, at 1:10 AM, Kevin Benton  wrote:
> >>
> >>> Does sqlalchemy have good support for cross-database foreign keys? I
> was under the impression that they cannot be implemented with the normal
> syntax and semantics of an intra-database foreign-key constraint.
> >>
> >> cross “database” is not typically portable, but cross “schema” is.
> >>
> >> different database vendors have different notions of “databases” or
> “schemas”.
> >>
> >> if you can get the “other database” to be accessible from the target
> database via “otherdatabase.sometable”, then you’re in.
> >>
> >> from SQLAlchemy’s perspective, it’s just a name with a dot.   It’s the
> database itself that has to support the foreign key at the scope you are
> shooting for.
> >>
> >
> > All true, however, there are zero guarantees that databases will be
> > hosted on the same server, and typically permissions are setup to prevent
> > cross-schema joins.
>
> I believe Group-based Policy (which this thread is about) will use the
> Neutron
> database configuration for its dependent database.
>
> If Neutron is configured for:
>   connection = mysql://user:pass@locationX:3306/neutron
> then GBP would use:
>   connection = mysql://user:pass@locationX:3306/neutron_gbp
>
> > Typically we use the public API's when we want to access data in a
> > different application. The database is a private implementation detail
> > of each application.
>
> Currently GPB is very tightly coupled to Neutron.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Hi,

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

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

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

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

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

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

Cheers,
Ivar.

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

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

[Ivar Lazzaro]

On Wed, Aug 27, 2014 at 5:06 PM, Jeremy Stanley  wrote:
>
> Good point, and that definitely is a reason to just keep those
> pieces in their own separate Git repositories outside of the core
> Neutron repository in perpetuity (even after they "graduate" from
> incubation). One package per repository. That should be chiseled in
> stone somewhere.


Just asking, wasn't there a proposal about doing something similar for all
the neutron services? (l3/fw/lb/vnp ...)

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

Re: [openstack-dev] [infra] [neutron] [tc] Neutron Incubator workflow

[Ivar Lazzaro]

Quoting Stefano from a different thread [0]:

The rationale for the separate repository is that Neutron's code needs a
> lot of love for the *existing* codebase, before new features can be
> added (and before core team can accept more responsibilities for it).
> But progress is unstoppable: new features are being proposed every cycle
> and reviewers bandwidth is not infinite.


The long term purpose of the incubator should be to gather all the big new
features that may require fast iteration before becoming stable and being
eventually merged into the main tree. This is especially important for
"core" new features, that may have a higher impact on Neutron's stability.
A great example was made by Kevin with DVR.

[0]
http://lists.openstack.org/pipermail/openstack-dev/2014-August/044224.html


On Wed, Aug 27, 2014 at 1:32 PM, Kevin Benton  wrote:

> I agree that components isolated to one service or something along those
> lines where there is a clear plugin point in Neutron, it might make sense
> to separate them permanently. However, at that point why even bother with
> the Neutron incubator when a new project can be started?
>
> The feature branch idea sounds interesting for the one-time big
> experimental changes. Are there any other projects that do this right now?
>
>
> On Wed, Aug 27, 2014 at 12:30 PM, James E. Blair 
> wrote:
>
>> Kevin Benton  writes:
>>
>> > From what I understand, the intended projects for the incubator can't
>> > operate without neutron because they are just
>> extensions/plugins/drivers.
>>
>> I could have phrased that better.  What I meant was that they could
>> operate without being actually in the Neutron repo, not that they could
>> not operate without Neutron itself.
>>
>> The proposal for the incubator is that extensions be developed outside
>> of the Neutron repo.  My proposed refinement is that they stay outside
>> of the Neutron repo.  They live their entire lives as extension modules
>> in separate projects.
>>
>> > For example, if the DVR modifications to the reference reference L3
>> plugin
>> > weren't already being developed in the tree, DVR could have been
>> developed
>> > in the incubator and then merged into Neutron once the bugs were ironed
>> out
>> > so a huge string of Gerrit patches didn't need to be tracked. If that
>> had
>> > happened, would it make sense to keep the L3 plugin as a completely
>> > separate project or merge it? I understand this is the approach the load
>> > balancer folks took by making Octavia a separate project, but I think it
>> > can still operate on its own, where the reference L3 plugin (and many of
>> > the other incubator projects) are just classes that expect to be able to
>> > make core Neutron calls.
>>
>> The list of Juno/Kilo candidates doesn't seem to have projects that are
>> quite so low-level.
>>
>> If a feature is going to become part of the neutron core, then it should
>> be developed in the neutron repository.  If we need a place to land code
>> that isn't master, it's actually far easier to just use a feature branch
>> on the neutron repo.  Commits can land there as needed, master can be
>> periodically merged into it, and when the feature is ready, the feature
>> branch can be merged into master.
>>
>> I think between those two options: incubate/spin-out components that are
>> high-level enough not to have deep integration in the neutron core, and
>> using feature branches for large experimental changes to the core
>> itself, we can handle the problems the incubator repo is intended to
>> address.
>>
>> -Jim
>>
>> ___
>> 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] [third-party] What tests are required to be run

[Ivar Lazzaro]

That's great!

Also, I would suggest we decide on a 'standard' way for CI owners to
comunicate their CIs status (eg. MyCompany CI is not voting waiting for bug
#9001 to be fixed).
Using the ML for that may be confusing... What about an etherpad (linked
from [0]) or a dedicated section of [0] itself?

Ivar.

[0]
https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin_and_Drivers


On Sat, Aug 16, 2014 at 1:02 AM, Edgar Magana 
wrote:

>  Ivar,
>
>  Very valid point. This is why I need clarification from those CI owner.
> I will run a new test with a basic change in the Neutron DB code. That
> should be covered by almost all CI systems.
>
>  Edgar
>
>   From: Ivar Lazzaro 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Friday, August 15, 2014 at 3:47 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [neutron] [third-party] What tests are
> required to be run
>
>   Hi Edgar,
>
>  Nice shot, to be the inquisitor is not necessarily a bad thing :)
>
>  I know some CIs are 'stuck' waiting for bugs to be fixed or certain
> patches to be merged, but I was wondering if it is a requirement that CIs
> vote *ALL* the Neutron patches. Some may have missed your call just because
> of their filters (see [0] section 'what changes to run against').
>
>  Cheers,
> Ivar.
>
>  [0] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>
>
>
>
> On Sat, Aug 16, 2014 at 12:35 AM, Edgar Magana 
> wrote:
>
>> Team,
>>
>> I did a quick audit on the Neutron CI. Very sad results. Only few plugins
>> and drivers are running properly and testing all Neutron commits.
>> I created a report here:
>>
>> https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
>> _and_Drivers
>>
>>
>> We will discuss the actions to take on the next Neutron IRC meeting. So
>> please, reach me out to clarify what is the status of your CI.
>> I had two commits to quickly verify the CI reliability:
>>
>> https://review.openstack.org/#/c/114393/
>>
>> https://review.openstack.org/#/c/40296/
>>
>>
>> I would expect all plugins and drivers passing on the first one and
>> failing for the second but I got so many surprises.
>>
>> Neutron code quality and reliability is a top priority, if you ignore this
>> report that plugin/driver will be candidate to be remove from Neutron
>> tree.
>>
>> Cheers,
>>
>> Edgar
>>
>> P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty
>> job!
>>
>>
>> On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>>
>> >Folks, I'm not sure if all CI accounts are running sufficient tests.
>> >Per the requirements wiki page here [1], everyone needs to be running
>> >more than just Tempest API tests, which I still see most neutron
>> >third-party CI setups doing. I'd like to ask everyone who operates a
>> >third-party CI account for Neutron to please look at the link below
>> >and make sure you are running appropriate tests. If you have
>> >questions, the weekly third-party meeting [2] is a great place to ask
>> >questions.
>> >
>> >Thanks,
>> >Kyle
>> >
>> >[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
>> >[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>> >
>> >___
>> >OpenStack-dev mailing list
>> >OpenStack-dev@lists.openstack.org
>> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] [third-party] What tests are required to be run

[Ivar Lazzaro]

Hi Edgar,

Nice shot, to be the inquisitor is not necessarily a bad thing :)

I know some CIs are 'stuck' waiting for bugs to be fixed or certain patches
to be merged, but I was wondering if it is a requirement that CIs vote
*ALL* the Neutron patches. Some may have missed your call just because of
their filters (see [0] section 'what changes to run against').

Cheers,
Ivar.

[0] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting




On Sat, Aug 16, 2014 at 12:35 AM, Edgar Magana 
wrote:

> Team,
>
> I did a quick audit on the Neutron CI. Very sad results. Only few plugins
> and drivers are running properly and testing all Neutron commits.
> I created a report here:
> https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers#Existing_Plugin
> _and_Drivers
>
>
> We will discuss the actions to take on the next Neutron IRC meeting. So
> please, reach me out to clarify what is the status of your CI.
> I had two commits to quickly verify the CI reliability:
>
> https://review.openstack.org/#/c/114393/
>
> https://review.openstack.org/#/c/40296/
>
>
> I would expect all plugins and drivers passing on the first one and
> failing for the second but I got so many surprises.
>
> Neutron code quality and reliability is a top priority, if you ignore this
> report that plugin/driver will be candidate to be remove from Neutron tree.
>
> Cheers,
>
> Edgar
>
> P.s. I hate to be the inquisitor hereŠ but someone has to do the dirty job!
>
>
> On 8/14/14, 8:30 AM, "Kyle Mestery"  wrote:
>
> >Folks, I'm not sure if all CI accounts are running sufficient tests.
> >Per the requirements wiki page here [1], everyone needs to be running
> >more than just Tempest API tests, which I still see most neutron
> >third-party CI setups doing. I'd like to ask everyone who operates a
> >third-party CI account for Neutron to please look at the link below
> >and make sure you are running appropriate tests. If you have
> >questions, the weekly third-party meeting [2] is a great place to ask
> >questions.
> >
> >Thanks,
> >Kyle
> >
> >[1] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
> >[2] https://wiki.openstack.org/wiki/Meetings/ThirdParty
> >
> >___
> >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] Simple proposal for stabilizing new features in-tree

[Ivar Lazzaro]

Hi Robert,

I think this is a great proposal.
Easy to understand and (at a first glance) easy to implement.
Also, it seems the perfect compromise for those who wanted GBP (as a
representative for this kind of extension) in tree, and those who wanted it
to be more mature first.

Fwiw, You have my support on this.
Ivar.
On Aug 8, 2014 10:27 PM, "Robert Kukura"  wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

[Ivar Lazzaro]

That's ok for me as well!
+1
On Aug 8, 2014 10:04 PM, "Prasad Vellanki" <
prasad.vella...@oneconvergence.com> wrote:

> It sounds good
> +1
>
>
> On Fri, Aug 8, 2014 at 12:44 PM, Sumit Naiksatam  > wrote:
>
>> Thanks Jay for your constructive feedback on this. I personally think
>> that 'policy-target' is a good option. I am not sure what the rest of
>> the team thinks, perhaps they can chime in.
>>
>> On Fri, Aug 8, 2014 at 8:43 AM, Jay Pipes  wrote:
>> > On 08/07/2014 01:17 PM, Ronak Shah wrote:
>> >>
>> >> Hi,
>> >> Following a very interesting and vocal thread on GBP for last couple of
>> >> days and the GBP meeting today, GBP sub-team proposes following name
>> >> changes to the resource.
>> >>
>> >>
>> >> policy-point for endpoint
>> >> policy-group for endpointgroup (epg)
>> >>
>> >> Please reply if you feel that it is not ok with reason and suggestion.
>> >
>> >
>> > Thanks Ronak and Sumit for sharing. I, too, wasn't able to attend the
>> > meeting (was in other meetings yesterday and today).
>> >
>> > I'm very happy with the change from endpoint-group -> policy-group.
>> >
>> > policy-point is better than endpoint, for sure. The only other
>> suggestion I
>> > might have would be to use "policy-target" instead of "policy-point",
>> since
>> > the former clearly delineates what the object is used for (a target for
>> a
>> > policy).
>> >
>> > But... I won't raise a stink about this. Sorry for sparking long and
>> > tangential discussions on GBP topics earlier this week. And thanks to
>> the
>> > folks who persevered and didn't take too much offense to my questioning.
>> >
>> > Best,
>> > -jay
>> >
>> >
>> >
>> > ___
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> 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

[Ivar Lazzaro]

Hi Jay,

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

I hope this answers your question,
Ivar.


On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes  wrote:

> On 08/08/2014 08:55 AM, Kevin Benton wrote:
>
>> The existing constructs will not change.
>>
>
> A followup question on the above...
>
> If GPB API is merged into Neutron, the next logical steps (from what I can
> tell) will be to add drivers that handle policy-based payloads/requests.
>
> Some of these drivers, AFAICT, will *not* be deconstructing these policy
> requests into the low-level port, network, and subnet
> creation/attachment/detachment commands, but instead will be calling out
> as-is to hardware that speaks the higher-level abstraction API [1], not the
> lower-level port/subnet/network APIs. The low-level APIs would essentially
> be consumed entirely within the policy-based driver, which would
> effectively mean that the only way a system would be able to orchestrate
> networking in systems using these drivers would be via the high-level
> policy API.
>
> Is that correct? Very sorry if I haven't explained clearly my question...
> this is a tough question to frame eloquently :(
>
> Thanks,
> -jay
>
> [1] http://www.cisco.com/c/en/us/solutions/data-center-
> virtualization/application-centric-infrastructure/index.html
>
>  On Aug 8, 2014 9:49 AM, "CARVER, PAUL" > > wrote:
>>
>> Wuhongning [mailto:wuhongn...@huawei.com
>> ] wrote:
>>
>>  >Does it make sense to move all advanced extension out of ML2, like
>> security
>>  >group, qos...? Then we can just talk about advanced service
>> itself, without
>>  >bothering basic neutron object (network/subnet/port)
>>
>> A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
>> still
>> think it's too late in the game to be shooting down all the work
>> that the
>> GBP team has put in unless there's a really clean and effective way of
>> running AND iterating on GBP in conjunction with Neutron without being
>> part of the Juno release. As far as I can tell they've worked really
>> hard to follow the process and accommodate input. They shouldn't have
>> to wait multiple more releases on a hypothetical refactoring of how
>> L3+ vs
>> L2 is structured.
>>
>> But, just so I'm not making a horrible mistake, can someone reassure
>> me
>> that GBP isn't removing the constructs of network/subnet/port from
>> Neutron?
>>
>> I'm under the impression that GBP is adding a higher level abstraction
>> but that it's not ripping basic constructs like network/subnet/port
>> out
>> of the existing API. If I'm wrong about that I'll have to change my
>> opinion. We need those fundamental networking constructs to be present
>> and accessible to users that want/need to deal with them. I'm viewing
>> GBP as just a higher level abstraction over the top.
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Hi Paul,

Don't need to worry, you are perfectly right, GBP API is not replacing
anything :).

Also thanks for sharing your opinion on this matter.

Thanks,
Ivar.


On Fri, Aug 8, 2014 at 5:46 PM, CARVER, PAUL  wrote:

> Wuhongning [mailto:wuhongn...@huawei.com] wrote:
>
> >Does it make sense to move all advanced extension out of ML2, like
> security
> >group, qos...? Then we can just talk about advanced service itself,
> without
> >bothering basic neutron object (network/subnet/port)
>
> A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I still
> think it's too late in the game to be shooting down all the work that the
> GBP team has put in unless there's a really clean and effective way of
> running AND iterating on GBP in conjunction with Neutron without being
> part of the Juno release. As far as I can tell they've worked really
> hard to follow the process and accommodate input. They shouldn't have
> to wait multiple more releases on a hypothetical refactoring of how L3+ vs
> L2 is structured.
>
> But, just so I'm not making a horrible mistake, can someone reassure me
> that GBP isn't removing the constructs of network/subnet/port from Neutron?
>
> I'm under the impression that GBP is adding a higher level abstraction
> but that it's not ripping basic constructs like network/subnet/port out
> of the existing API. If I'm wrong about that I'll have to change my
> opinion. We need those fundamental networking constructs to be present
> and accessible to users that want/need to deal with them. I'm viewing
> GBP as just a higher level abstraction over the top.
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> 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

[Ivar Lazzaro]

Hi Pedro,

I agree that having as much users/operators as possible using the API is
the winner option.
I think you should move this comment also in the main thread since it looks
that the Subject has been accidentally modified.

Cheers,
Ivar.


On Thu, Aug 7, 2014 at 1:28 AM, Pedro Marques 
wrote:

>
> On Aug 6, 2014, at 3:56 PM, Armando M.  wrote:
>
>
> On 6 August 2014 15:47, Kevin Benton  wrote:
>
>> I think we should merge it and just prefix the API for now with
>> '/your_application_will_break_after_juno_if_you_use_this/'
>>
>
> And you make your call based and what pros and cons exactly, If I am ask?
>
> Let me start:
>
> Option 1:
>   - pros
> - immediate delivery vehicle for consumption by operators
>
>
> Since our collective goal is to maximize the benefits for OpenStack
> users/operators, that seems to be the winner.
>
>   - cons
> - code is burder from a number of standpoints (review, test, etc)
>
>
> Any piece of code is a burden.
>
>
> Option 2:
>   - pros
> - enable a small set of Illuminati to iterate faster
>
>
> This is probably not intentional from your part ,but your choice of words
> make it seem that you are deriding the efforts of the team behind this
> effort. While i may disagree technically here and there with their current
> design, it seems to me that the effort in question is rather broad based in
> terms of support (from multiple different organizations) and that the team
> has put a non trivial effort in making the effort public. I don't think we
> can characterize the team either as a "secret group" or a "small set".
>
>   Pedro.
>
>
>   - cons
> - integration burden with other OpenStack projects (keystone, nova,
> neutron, etc)
>
> Cheers,
> Armando
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

+1 Kevin. I really fail to see how a patch which has been ready for a long
time now is the worst enemy of Nova Parity. This is starting to feel kind
of ad-hoc...
On Aug 6, 2014 11:42 PM, "Kevin Benton"  wrote:

> >In all seriousness, folks, I'm bringing up points about the proposed API
> because I see the current mess of Neutron integration with Nova, I see that
> nova-network has been "undeprecated" due to continuing lack of parity and
> HA concerns in Neutron, and I want things to be better, not worse.
>
> Again, I haven't seen any evidence that ongoing development of this new
> API is preventing any of the parity work from happening. Nobody is
> advocating that the parity work be delayed because of this. We are all
> aware of the threats the TC has put forth with regard to demoting Neutron
> to incubation unless the parity demands are met. If you want ongoing
> development to stop, this should be a clear requirement and it should be
> evenly applied to all work (LBaaS separation, ML2 enhancements, any third
> party drivers, etc).
>
>
>
> On Wed, Aug 6, 2014 at 3:10 PM, Jay Pipes  wrote:
>
>> On 08/06/2014 04:51 PM, Pedro Marques wrote:
>>
>>> Neutron allows vendors to speak to proprietary device APIs, it was
>>> designed to do so, AFAIK. It is also possibly to "entirely swap out
>>> all of the Neutron core"... the proponents of the group based policy
>>> didn't have to go through so much trouble if that was their intent.
>>> As far as i know most plugins talk to a proprietary API.
>>>
>>> I happen to disagree technically with a couple of choices made by
>>> this proposal; but the blueprint was approved. Which means that i
>>> lost the argument, or didn't raise it on time, or didn't argue
>>> convincingly... regardless of the reason, the time to argue about the
>>> goal has passed. The decision of the community was to approve the
>>> spec and that decision should be respected.
>>>
>>
>> Sure, no problem. I'll just go back to Nova and wait around to help clean
>> up the mess.
>>
>> In all seriousness, folks, I'm bringing up points about the proposed API
>> because I see the current mess of Neutron integration with Nova, I see that
>> nova-network has been "undeprecated" due to continuing lack of parity and
>> HA concerns in Neutron, and I want things to be better, not worse.
>>
>> Neutron contributors need to recognize that Nova is the pre-eminent
>> consumer of Neutron interfaces, and until those interfaces are stable,
>> consistent regardless of underlying hardware or driver choices, and
>> generally preferable for Nova to recommend as its default network driver,
>> then the Neutron project is sitting as an island unto itself.
>>
>> The fact that not enough Nova developers (including yours truly) are
>> paying attention to what is going on in Neutron spec-land and roadmap is a
>> serious problem we should deal with directly (cross-project spec meetings,
>> better documentation and communication, shared bug triaging and
>> verification meetings, etc). Otherwise, these kinds of conversations are
>> likely to continue.
>>
>> Best,
>> -jay
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Kevin Benton
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Edgar,

Actually, As Pedro said, I think that the time for discussing these kind of
concerns was the BP approval. The fact that it has been approved after many
proposals and reviews means that a community effort wanted the GBP to be
implemented in this release cycle the way it was presented at that time.

With this, I absolutely don't want to say that you should not express your
disagreement! I'm just saying that it should be expressed differently (a BP
to propose your model in K?). Otherwise, the whole BP process becomes just
pointless.

Meanwhile, imho, blocking the patch feels really unfair.

Ivar.
 On Aug 6, 2014 11:00 PM, "Edgar Magana"  wrote:

>  Ivar,
>
>  Of course and this is why we are having this conversation, in order to
> merge our different opinions.
>
>  Edgar
>
>   From: Ivar Lazzaro 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, August 6, 2014 at 1:41 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
> forward
>
>   Hi Edgar,
>
>  Actually, I think that other reviewers saw that name clash, and still
> thought it was ok to use the same terminology in such a different context.
> BP reviews are a community effort right? So of course someones' idea may
> be different from yours.
>
>  Regards,
> Ivar.
>
>
> On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
> wrote:
>
>> Basically, I am admitting that I did not catch in my review the part of
>> the endpoint term that Jay was pointing out.
>>
>> Edgar
>>
>> On 8/6/14, 11:32 AM, "Sumit Naiksatam"  wrote:
>>
>> >Not sure what you are talking about? You claim now that you had
>> >suggestion which was not considered, yet you +2'ed a patch, by stating
>> >that "All looks good to me!".
>> >
>> >On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>> >wrote:
>> >> That is the beauty of the open source projects, there is always a
>> >>smartest
>> >> reviewer catching out the facts that you don¹t.
>> >>
>> >> Edgar
>> >>
>> >> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
>> wrote:
>> >>
>> >>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>> >>>
>> >>>"
>> >>>Edgar Magana
>> >>>Jul 2 8:42 AM
>> >>>
>> >>>Patch Set 13: Code-Review+2
>> >>>
>> >>>All looks good to me! I am not approving yet because Nachi was also
>> >>>reviewing this code and I would like to see his opinion as well.
>> >>>"
>> >>>
>> >>>That would suggest that you were happy with what was in it. I don't
>> >>>see anything in the review comments that suggests otherwise.
>> >>>
>> >>>[1]  https://review.openstack.org/#/c/95900/
>> >>>
>> >>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana <
>> edgar.mag...@workday.com>
>> >>>wrote:
>> >>>> This is the consequence of a proposal that is not following the
>> >>>>standardized
>> >>>> terminology (IETF - RFC) for any Policy-based System:
>> >>>> http://tools.ietf.org/html/rfc3198
>> >>>>
>> >>>> Well, I did bring  this point during the Hong Kong Summit but as you
>> >>>>can see
>> >>>> my comments were totally ignored:
>> >>>>
>> >>>>
>> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>> >>>>Ir
>> >>>>upCD9E/edit
>> >>>>
>> >>>> I clearly saw this kind of issues coming. Let me quote myself what I
>> >>>> suggested: "For instance: "endpoints" should be "enforcement point"
>> >>>>
>> >>>> I do not understand why GBP did not include this suggestionŠ
>> >>>>
>> >>>> Edgar
>> >>>>
>> >>>> From: Kevin Benton 
>> >>>> Reply-To: "OpenStack Development Mailing List (not for usage
>> >>>>questions)"
>> >>>> 
>> >>>> Date: Wednesday, August 6, 2014 at 10:22 AM
>> >>>> To: "OpenStack Development Mailing List (not for us

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

[Ivar Lazzaro]

+1 Mohammad.
On Aug 6, 2014 11:08 PM, "Mohammad Banikazemi"  wrote:

> Yes, indeed.
> I do not want to be over dramatic but the discussion on the original "Group
> Based Policy and the way forward" thread is nothing short of heartbreaking.
> After months and months of discussions, three presentations at the past
> three summits, a design session at the last summit, and (most relevant to
> this thread) the approval of the spec, why are we talking about the merits
> of the work now?
>
> I understand if people think this is not a good idea or this is not a good
> time. What I do not understand is why these concerns were not raised
> clearly and openly earlier.
>
> Best,
>
> Mohammad
>
>
> [image: Inactive hide details for Stefano Maffulli ---08/06/2014 04:47:21
> PM---On Wed 06 Aug 2014 01:21:26 PM PDT, Eugene Nikanorov wro]Stefano
> Maffulli ---08/06/2014 04:47:21 PM---On Wed 06 Aug 2014 01:21:26 PM PDT,
> Eugene Nikanorov wrote: > So I don't think it's fair to blame re
>
> From: Stefano Maffulli 
> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still
thought it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
wrote:

> Basically, I am admitting that I did not catch in my review the part of
> the endpoint term that Jay was pointing out.
>
> Edgar
>
> On 8/6/14, 11:32 AM, "Sumit Naiksatam"  wrote:
>
> >Not sure what you are talking about? You claim now that you had
> >suggestion which was not considered, yet you +2'ed a patch, by stating
> >that "All looks good to me!".
> >
> >On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
> >wrote:
> >> That is the beauty of the open source projects, there is always a
> >>smartest
> >> reviewer catching out the facts that you don¹t.
> >>
> >> Edgar
> >>
> >> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
> wrote:
> >>
> >>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
> >>>
> >>>"
> >>>Edgar Magana
> >>>Jul 2 8:42 AM
> >>>
> >>>Patch Set 13: Code-Review+2
> >>>
> >>>All looks good to me! I am not approving yet because Nachi was also
> >>>reviewing this code and I would like to see his opinion as well.
> >>>"
> >>>
> >>>That would suggest that you were happy with what was in it. I don't
> >>>see anything in the review comments that suggests otherwise.
> >>>
> >>>[1]  https://review.openstack.org/#/c/95900/
> >>>
> >>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana  >
> >>>wrote:
>  This is the consequence of a proposal that is not following the
> standardized
>  terminology (IETF - RFC) for any Policy-based System:
>  http://tools.ietf.org/html/rfc3198
> 
>  Well, I did bring  this point during the Hong Kong Summit but as you
> can see
>  my comments were totally ignored:
> 
> 
> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
> Ir
> upCD9E/edit
> 
>  I clearly saw this kind of issues coming. Let me quote myself what I
>  suggested: "For instance: "endpoints" should be "enforcement point"
> 
>  I do not understand why GBP did not include this suggestionŠ
> 
>  Edgar
> 
>  From: Kevin Benton 
>  Reply-To: "OpenStack Development Mailing List (not for usage
> questions)"
>  
>  Date: Wednesday, August 6, 2014 at 10:22 AM
>  To: "OpenStack Development Mailing List (not for usage questions)"
>  
> 
>  Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>  forward
> 
>  What I was referring to was also not Keystone's definition of an
> endpoint.
>  It's almost as if the term has many uses and was not invented for
> Keystone.
>  :-)
> 
>  http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
> 
>  Did a similar discussion occur when Heat wanted to use the word
> 'template'
>  since this was clearly already in use by Horizon?
> 
>  On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
> >
> > On 08/06/2014 02:12 AM, Kevin Benton wrote:
> >>
> >> Given that, pointing to the Nova parity work seems a bit like a red
> >> herring. This new API is being developed orthogonally to the
> >>existing
> >> API endpoints
> >
> >
> > You see how you used the term endpoints there? :P
> >
> > -jay
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
>  ___
>  OpenStack-dev mailing list
>  OpenStack-dev@lists.openstack.org
>  http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> >>>
> >>>___
> >>>OpenStack-dev mailing list
> >>>OpenStack-dev@lists.openstack.org
> >>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >___
> >OpenStack-dev mailing list
> >OpenStack-dev@lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> ___
> 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)

[Ivar Lazzaro]

+1 Eugene,

Still, there's a point in Stefano's thread:

There's a time for discussing merging strategies, models, and naming
conventions... And this time is called BP approval :)

Just saying.
Ivar.



On Wed, Aug 6, 2014 at 10:21 PM, Eugene Nikanorov 
wrote:

>
>
>
> On Wed, Aug 6, 2014 at 11:07 PM, Stefano Maffulli 
> wrote:
>
>> On 08/06/2014 11:19 AM, Edgar Magana wrote:
>> > That is the beauty of the open source projects, there is always a
>> smartest
>> > reviewer catching out the facts that you don¹t.
>>
>> And yet, the specification clearly talks about 'endpoints' and nobody
>> caught it where it supposed to be caught so I fear that something failed
>> badly here:
>>
>
> I know that there's whole other thread on naming.
> I believe everybody has reviewed this having keystone's "endpoint" in mind
> and understanding that those are different terms where keystone endpoints
> should have been named 'service_endpoints' or something.
> There's no UX or technical reasons to not to reuse terms used in different
> projects and in different domains.
>
> So I don't think it's fair to blame reviewers here.
>
> Thanks,
> Eugene.
>
>>
>> https://review.openstack.org/#/c/89469/10
>>
>> What failed and how we make sure this doesn't happen again? This to me
>> is the most important question to answer.  If I remember correctly we
>> introduced the concept of Specs exactly to discuss on the ideas *before*
>> the implementation starts. We wanted things like architecture, naming
>> conventions and other important decisions to be socialized and agreed
>> upon *before* code was proposed. We wanted to avoid developers to spend
>> time implementing features in ways that are incompatible and likely to
>> be rejected at code review time. And yet, here we are.
>>
>> Something failed and I would ask for all core reviewers to sit down and
>> do an exercise to identify the root cause. If you want we can start from
>> this specific case, do some simple root cause analysis together and take
>> GBP as an example. Thoughts?
>>
>> /stef
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Hi Aaron,

Please note that the user using the current reference implementation
doesn't need to create Networks, Ports, or anything else. As a matter of
fact, the mapping is done implicitly.

Also, I agree with Kevin when he says that this is a whole different
discussion.

Thanks,
Ivar.


On Wed, Aug 6, 2014 at 9:12 PM, Aaron Rosen  wrote:

> Hi Ryan,
>
>
> On Wed, Aug 6, 2014 at 11:55 AM, Ryan Moats  wrote:
>
>> Jay Pipes  wrote on 08/06/2014 01:04:41 PM:
>>
>> [snip]
>>
>>
>> > AFAICT, there is nothing that can be done with the GBP API that cannot
>> > be done with the low-level regular Neutron API.
>>
>> I'll take you up on that, Jay :)
>>
>> How exactly do I specify behavior between two collections of ports
>> residing in the same IP subnet (an example of this is a bump-in-the-wire
>> network appliance).
>>
>> Would you mind explaining what behavior you want between the two
> collection of ports?
>
>
>>  I've looked around regular Neutron and all I've come up with so far is:
>>  (1) use security groups on the ports
>>  (2) set allow_overlapping_ips to true, set up two networks with
>> identical CIDR block subnets and disjoint allocation pools and put a
>> vRouter between them.
>>
>> Now #1 only works for basic allow/deny access and adds the complexity of
>> needing to specify per-IP address security rules, which means you need the
>> ports to have IP addresses already and then manually add them into the
>> security groups, which doesn't seem particularly very orchestration
>> friendly.
>>
>
> I believe the referential security group rules solve this problem (unless
> I'm not understanding):
>
> neutron security-group-create group1
> neutron security-group-create group2
>
> # allow members of group1 to ssh into group2 (but not the other way
> around):
> neutron security-group-rule-create --direction ingress --port-range-min 22
> --port-range-max 22 --protocol TCP --remote-group-id group1 group2
>
> # allow members of group2 to be able to access TCP 80 from members of
> group1 (but not the other way around):
> neutron security-group-rule-create --direction ingress --port-range-min 80
> --port-range-max 80 --protocol TCP --remote-group-id group2 group1
>
> # Now when you create ports just place these in the desired security
> groups and neutron will automatically handle this orchestration for you
> (and you don't have to deal with ip_addresses and updates).
>
> neutron port-create --security-groups group1 network1
> neutron port-create --security-groups group2 network1
>
>
>>
>> Now #2 handles both allow/deny access as well as provides a potential
>> attachment point for other behaviors, *but* you have to know to set up the
>> disjoint allocation pools, and your depending on your drivers to handle the
>> case of a router that isn't really a router (i.e. it's got two interfaces
>> in the same subnet, possibly with the same address (unless you thought of
>> that when you set things up)).
>>
>>
> Are you talking about the firewall as a service stuff here?
>
>
>>  You can say that both of these are *possible*, but they both look more
>> complex to me than just having two groups of ports and specifying a policy
>> between them.
>>
>
> Would you mind proposing how this is done in the Group policy api? From
> what I can tell in the new proposed api you'd need to map both of these
> groups to different endpoints i.e networks.
>
>>
>>
>> Ryan Moats
>>
>>
>> Best,
>
> Aaron
>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Salvatore,

Can you expand on point 2? Not sure what means in this case to 'treat it
accordingly'.

Thanks,
Ivar.


On Wed, Aug 6, 2014 at 7:44 PM, Salvatore Orlando 
wrote:

> As Ronak said, this thread is starting to move in a lot of different
> directions, ranging from correctness of the blueprint approval process to
> nova/neutron integration, which are rather off topic.
>
> In particular it seems things are being skewed towards a discussion around
> nova parity, whereas actually some people have just chimed in with their
> honest opinion that with all the stuff still needed to finally be able to
> make neutron "THE" openstack networking solution, the effort towards adding
> a new tenant facing API appears to have a lesser priority.
>
> I just want to reassure everybody that the majority of the core team and a
> large part of the community have actually made this their first priority.
> For what is worth, some of them have even delayed plugin/driver specific
> development to this aim.
>
> So I would invite to go back to the original subject of the discussion,
> that is to say decide as a community what would the best way forward for
> this effort.
> I see so far the following options:
> - merge the outstanding patches, assuming there are no further technical
> concerns, and include GBP in Juno.
> - consider GBP an 'experimental' V3 tenant API (this was mentioned
> somewhere in this thread) and treat it accordingly
> - delay to the next release
> - move the development of the service plugin to stackforge as suggested to
> this thread.
>
> More options are obviously welcome!
>
> Regards,
> Salvatore
>
>
> On 6 August 2014 19:40, Ivar Lazzaro  wrote:
>
>> Which kind of uncertainty are you referring to?
>>
>> Given that the blueprint was approved long ago, and the code has been
>> ready and under review following those specs... I think GBP is probably the
>> patch with the least effort to be merged right now.
>>
>> Ivar.
>>
>>
>> On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon  wrote:
>>
>>>
>>> On Aug 6, 2014 10:21 AM, "Ronak Shah" 
>>> wrote:
>>> >
>>> > We have diverged our attention towards nova-network-> neutron parity
>>> on this thread unnecessarily.
>>> >
>>> > Can we discuss and collectively decide on what is the way forward for
>>> GBP in Juno release?
>>> >
>>> > Efforts have been made by the subteam starting from throwing PoC at
>>> last summit to spec approval to code review.
>>> >
>>> > There are usefulness to this feature and I think everyone is on the
>>> same page there.
>>> >
>>> > Let us not discourage the effort by bringing in existing neutron issue
>>> in play.
>>>
>>> > Yes, we has a neutorn community needs to fix that with highest
>>> priority.
>>> > But this is orthogonal effort.
>>>
>>> The efforts may be orthogonal, but the review team and bandwidth of said
>>> team is one and the same. Making nova-network the highest priority means
>>> pushing other blueprints back as needed.  And since there is still so much
>>> uncertainty around GPB this late in the cycle, IMHO it's a good candidate
>>> for getting deferred.
>>>
>>> > If endpoint is not a likeable preferred name than lets propose more
>>> meaningful alternative.
>>> > Let us try to find a middle ground on how this feature can be made
>>> generally available.
>>> >
>>> > Thanks,
>>> > Ronak
>>> >
>>> > ___
>>> > 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] Group Based Policy and the way forward

[Ivar Lazzaro]

Which kind of uncertainty are you referring to?

Given that the blueprint was approved long ago, and the code has been ready
and under review following those specs... I think GBP is probably the patch
with the least effort to be merged right now.

Ivar.


On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon  wrote:

>
> On Aug 6, 2014 10:21 AM, "Ronak Shah"  wrote:
> >
> > We have diverged our attention towards nova-network-> neutron parity on
> this thread unnecessarily.
> >
> > Can we discuss and collectively decide on what is the way forward for
> GBP in Juno release?
> >
> > Efforts have been made by the subteam starting from throwing PoC at last
> summit to spec approval to code review.
> >
> > There are usefulness to this feature and I think everyone is on the same
> page there.
> >
> > Let us not discourage the effort by bringing in existing neutron issue
> in play.
>
> > Yes, we has a neutorn community needs to fix that with highest priority.
> > But this is orthogonal effort.
>
> The efforts may be orthogonal, but the review team and bandwidth of said
> team is one and the same. Making nova-network the highest priority means
> pushing other blueprints back as needed.  And since there is still so much
> uncertainty around GPB this late in the cycle, IMHO it's a good candidate
> for getting deferred.
>
> > If endpoint is not a likeable preferred name than lets propose more
> meaningful alternative.
> > Let us try to find a middle ground on how this feature can be made
> generally available.
> >
> > Thanks,
> > Ronak
> >
> > ___
> > OpenStack-dev mailing list
> > OpenStack-dev@lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Ivar Lazzaro]

Hi Joe,

Are you suggesting to stop/remove everything that is not related to Nova
Parity for the Juno release? Because then I fail to see why this and Mark's
proposal are targeted  only to GBP.

In my humble opinion, these kind of concerns should be addressed at BP
approval time. Otherwise the whole purpose of the BP process feels void.

If we really feel like proposing a new way of addressing new features in
Neutron (which basically is a workflow change), we should discuss all of it
for the next release without blocking patches which went through the whole
approval process and are ready to be merged after community effort (BP
process, Weakly meetings, POC, reviews). Just like has been done in other
similar cases (eg. 3rd Party CI). This of course is IMHO.

Ivar.
On Aug 6, 2014 4:55 PM, "Joe Gordon"  wrote:

>
>
>
> On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton  wrote:
>
>> Are there any parity features you are aware of that aren't receiving
>> adequate developer/reviewer time? I'm not aware of any parity features that
>> are in a place where throwing more engineers at them is going to speed
>> anything up. Maybe Mark McClain (Nova parity leader) can provide some
>> better insight here, but that is the impression I've gotten as an active
>> Neutron contributor observing the ongoing parity work.
>>
>
> I cannot speak for which parts of nova-parity are short staffed, if any,
> but from an outsiders perspective I don't think neutron will hit full
> parity in Juno. And I would be very surprised to hear that more developers
> working on parity won't help. For example we are already in Juno-3 and the
> following work is yet to be completed (as per the neutron gap wiki):
>
> * Make check-tempest-dsvm-neutron-full stable enough to vote
> * Grenade testing
> * DVR (Neutron replacement for Nova multi-host)
> * Document Open Source Options
> * Real world (not in gate) performance, stability and scalability testing
> (performance parity with nova-networking).
>
>
>
>>
>> Given that, pointing to the Nova parity work seems a bit like a red
>> herring. This new API is being developed orthogonally to the existing API
>> endpoints and I don't think it was ever the expectation that Nova would
>> switch to this during the Juno timeframe anyway. The new API will not be
>> used during normal operation and should not impact the existing API at all.
>>
>
>>
>
>>
>
>> On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague  wrote:
>>
>>> On 08/05/2014 07:28 PM, Joe Gordon wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <
>>> kuk...@noironetworks.com
>>> > > wrote:
>>> >
>>> > On 8/4/14, 4:27 PM, Mark McClain wrote:
>>> >> All-
>>> >>
>>> >> tl;dr
>>> >>
>>> >> * Group Based Policy API is the kind of experimentation we be
>>> >> should attempting.
>>> >> * Experiments should be able to fail fast.
>>> >> * The master branch does not fail fast.
>>> >> * StackForge is the proper home to conduct this experiment.
>>> > The disconnect here is that the Neutron group-based policy sub-team
>>> > that has been implementing this feature for Juno does not see this
>>> > work as an experiment to gather data, but rather as an important
>>> > innovative feature to put in the hands of early adopters in Juno
>>> and
>>> > into widespread deployment with a stable API as early as Kilo.
>>> >
>>> >
>>> > The group-based policy BP approved for Juno addresses the critical
>>> > need for a more usable, declarative, intent-based interface for
>>> > cloud application developers and deployers, that can co-exist with
>>> > Neutron's current networking-hardware-oriented API and work nicely
>>> > with all existing core plugins. Additionally, we believe that this
>>> > declarative approach is what is needed to properly integrate
>>> > advanced services into Neutron, and will go a long way towards
>>> > resolving the difficulties so far trying to integrate LBaaS, FWaaS,
>>> > and VPNaaS APIs into the current Neutron model.
>>> >
>>> > Like any new service API in Neutron, the initial group policy API
>>> > release will be subject to incompatible changes before being
>>> > declared "stable", and hence would be labeled "experimental" in
>>> > Juno. This does not mean that it is an experiment where to "fail
>>> > fast" is an acceptable outcome. The sub-team's goal is to stabilize
>>> > the group policy API as quickly as possible,  making any needed
>>> > changes based on early user and operator experience.
>>> >
>>> > The L and M cycles that Mark suggests below to "revisit the status"
>>> > are a completely different time frame. By the L or M cycle, we
>>> > should be working on a new V3 Neutron API that pulls these APIs
>>> > together into a more cohesive core API. We will not be in a
>>> position
>>> > to do this properly without the experience of using the proposed
>>> > group

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

[Ivar Lazzaro]

+1 Hemanth.


On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi 
wrote:

> Hi,
>
> I believe that the API has been reviewed well both for its usecases and
> correctness. And the blueprint has been approved after sufficient exposure
> of the API in the community. The best way to enable users to adopt GBP is
> to introduce this in Juno rather than as a project in StackForge. Just as
> in other APIs any evolutionary changes can be incorporated, going forward.
>
> OS development processes are being followed in the implementation to make
> sure that there is no negative impact on Neutron stability with the
> inclusion of GBP.
>
> Thanks,
> -hemanth
>
>
> On Mon, Aug 4, 2014 at 1:27 PM, Mark McClain 
> wrote:
>
>>  All-
>>
>> tl;dr
>>
>> * Group Based Policy API is the kind of experimentation we be should
>> attempting.
>> * Experiments should be able to fail fast.
>> * The master branch does not fail fast.
>> * StackForge is the proper home to conduct this experiment.
>>
>>
>> Why this email?
>> ---
>> 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 recognize that
>> this discussion could create frustration for those who have invested
>> significant time and energy, but the reality is we need ensure we are
>> making decisions that benefit all members of our community (users,
>> operators, developers and vendors).
>>
>> Experimentation
>> 
>> I like that as a community we are exploring alternate APIs.  The process
>> of exploring via real user experimentation can produce valuable results.  A
>> good experiment should be designed to fail fast to enable further trials
>> via rapid iteration.
>>
>> Merging large changes into the master branch is the exact opposite of
>> failing fast.
>>
>> The master branch deliberately favors small iterative changes over time.
>>  Releasing a new version of the proposed API every six months limits our
>> ability to learn and make adjustments.
>>
>> In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental
>> APIs.  The results have been very mixed as operators either shy away from
>> testing/offering the API or embrace the API with the expectation that the
>> community will provide full API support and migration.  In both cases, the
>> experiment fails because we either could not get the data we need or are
>> unable to make significant changes without accepting a non-trivial amount
>> of technical debt via migrations or draft API support.
>>
>> Next Steps
>> --
>> Previously, the GPB subteam used a Github account to host the
>> development, but the workflows and tooling do not align with OpenStack's
>> development model. I’d like to see us create a group based policy project
>> in StackForge.  StackForge will host the code and enable us to follow the
>> same open review and QA processes we use in the main project while we are
>> developing and testing the API. The infrastructure there will benefit us as
>> we will have a separate review velocity and can frequently publish
>> libraries to PyPI.  From a technical perspective, the 13 new entities in
>> GPB [1] do not require any changes to internal Neutron data structures.
>>  The docs[2] also suggest that an external plugin or service would work to
>> make it easier to speed development.
>>
>> End State
>> -
>> APIs require time to fully bake and right now it is too early to know the
>> final outcome.  Using StackForge will allow the team to retain all of its
>> options including: merging the code into Neutron, adopting the repository
>> as sub-project of the Network Program, leaving the project in StackForge
>> project or learning that users want something completely different.  I
>> would expect that we'll revisit the status of the repo during the L or M
>> cycles since the Kilo development cycle does not leave enough time to
>> experiment and iterate.
>>
>>
>> mark
>>
>> [1]
>> http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370
>> [2]
>> https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078
>> [3]
>>
>> ___
>> 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] Specs approved for Juno-3 and exceptions

[Ivar Lazzaro]

I agree that it's important to set a guideline for this topic.
What if the said reviewer is "on vacation or indisposed"? Should a fallback
strategy exist for that case? A reviewer could indicate a "delegate core"
to review its -2s whenever he has no chance to do it.

Thanks,
Ivar.


On Fri, Jul 25, 2014 at 5:35 PM, Mandeep Dhami 
wrote:

>
> What would be a good guideline for "timely manner"? I would recommend
> something like 2-3 days unless the reviewer is on vacation or is
> indisposed. Is it possible to update gerrit/jenkins to send reminders to
> reviewers in such a scenario?
>
> Regards,
> Mandeep
> -
>
>
>
>
> On Fri, Jul 25, 2014 at 3:14 PM, Kyle Mestery  wrote:
>
>> On Fri, Jul 25, 2014 at 4:48 PM, Mandeep Dhami 
>> wrote:
>> >
>> > Thanks for the deck Jay, that is very helpful.
>> >
>> > Also, would it help the process by having some clear
>> guidelines/expectations
>> > around review time as well? In particular, if you have put a -1 or -2,
>> and
>> > the issues that you have identified have been addressed by an update
>> (or at
>> > least the original author thinks that he has addressed your concern),
>> is it
>> > reasonable to expect that you will re-review in a "reasonable time"?
>> This
>> > way, the updates can either proceed, or be rejected, as they are being
>> > developed instead of accumulating in a backlog that we then try to get
>> > approved on the last day of the cut-off?
>> >
>> I agree, if someone puts a -2 on a patch stressing an issue and the
>> committer has resolved those issues, the -2 should also be resolved in
>> a timely manner. If the issue can't be resolved in the review itself,
>> as this wiki page [1] indicates, the issue should be moved to the
>> mailing list.
>>
>> Thanks,
>> Kyle
>>
>> [1] https://wiki.openstack.org/wiki/CodeReviewGuidelines
>>
>> > Regards,
>> > Mandeep
>> >
>> >
>> >
>> > On Fri, Jul 25, 2014 at 12:50 PM, Steve Gordon 
>> wrote:
>> >>
>> >> - Original Message -
>> >> > From: "Jay Pipes" 
>> >> > To: openstack-dev@lists.openstack.org
>> >> >
>> >> > On 07/24/2014 10:05 AM, CARVER, PAUL wrote:
>> >> > > Alan Kavanagh wrote:
>> >> > >
>> >> > >> If we have more work being put on the table, then more Core
>> >> > >> members would definitely go a long way with assisting this, we
>> cant
>> >> > >> wait for folks to be reviewing stuff as an excuse to not get
>> >> > >> features landed in a given release.
>> >> >
>> >> > We absolutely can and should wait for folks to be reviewing stuff
>> >> > properly. A large number of problems in OpenStack code and flawed
>> design
>> >> > can be attributed to impatience and pushing through code that wasn't
>> >> > ready.
>> >> >
>> >> > I've said this many times, but the best way to get core reviews on
>> >> > patches that you submit is to put the effort into reviewing others'
>> >> > code. Core reviewers are more willing to do reviews for someone who
>> is
>> >> > clearly trying to help the project in more ways than just pushing
>> their
>> >> > own code. Note that, Alan, I'm not trying to imply that you are
>> guilty
>> >> > of the above! :) I'm just recommending techniques for the general
>> >> > contributor community who are not on a core team (including myself!).
>> >>
>> >> I agree with all of the above, I do think however there is another
>> >> un-addressed area where there *may* be room for optimization - which
>> is how
>> >> we use the earlier milestones. I apologize in advance because this is
>> >> somewhat tangential to Alan's points but I think it is relevant to the
>> >> general frustration around what did/didn't get approved in time for the
>> >> deadline and ultimately what will or wont get reviewed in time to make
>> the
>> >> release versus being punted to Kilo or even further down the road.
>> >>
>> >> We land very, very, little in terms of feature work in the *-1 and *-2
>> >> milestones in each release (and this is not just a Neutron thing). Even
>> >> though we know without a doubt that the amount of work currently
>> approved
>> >> for J-3 is not realistic we also know that we will land significantly
>> more
>> >> features in this milestone than the other two that have already been
>> and
>> >> gone, which to my way of thinking is actually kind of backwards to the
>> ideal
>> >> situation.
>> >>
>> >> What is unclear to me however is how much of this is a result of
>> >> difficulty identifying and approving less controversial/more
>> straightforward
>> >> specifications quickly following summit (keeping in mind this time
>> around
>> >> there was arguably some additional delay as the *-specs repository
>> approach
>> >> was bedded down), an unavoidable result of human nature being to
>> *really*
>> >> push when there is a *hard* deadline to beat, or just that these
>> earlier
>> >> milestones are somewhat impacted from fatigue from the summit (I know
>> a lot
>> >> of people also try to take some well earned time off around this
>> period + of
>> >> course many are still concentrat

Re: [openstack-dev] [neutron] [third-party] Current status of Neutron 3rd Party CI and how to move forward

[Ivar Lazzaro]

Hi Kyle,

Embrane's CI was blocked by some nasty bugs affecting the testing
environment. It resumed yesterday (6/12) [0].
Unfortunately it's still non voting (only commenting so far). Not sure if
this is a requirement or not, but it should be able to put +1/-1
immediately after the voting right is granted.
I'll keep an eye on it to make sure it is stable again.

Thanks sorting out the CI situation :D!

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


On Fri, Jun 13, 2014 at 10:07 AM, Kyle Mestery 
wrote:

> I've spent some time doing some initial analysis of 3rd Party CI in
> Neutron. The tl;dr is that it's a mess, and it needs fixing. And I'm
> setting a deadline of Juno-2 for people to address their CI systems
> and get them in shape or we will remove plugins and drivers in Juno-3
> which do not meet the expectations set out below.
>
> My initial analysis of Neutron 3rd Party CI is here [1]. This was
> somewhat correlated with information from DriverLog [2], which was
> helpful to put this together.
>
> As you can see from the list, there are a lot of CI systems which are
> broken right now. Some have just recently started working again.
> Others are working great, and some are in the middle somewhere. The
> overall state isn't that great. I'm sending this email to
> openstack-dev and BCC;ing CI owners to raise awareness of this issue.
> If I have incorrectly labeled your CI, please update the etherpad and
> include links to the latest voting/comments your CI system has done
> upstream and reply to this thread.
>
> I have documented the 3rd Party CI requirements for Neutron here [3].
> I expect people to be following these guidelines for their CI systems.
> If there are questions on the guidelines or expectations, please reply
> to this thread or reach out to myself in #openstack-neutron on
> Freenode. There is also a third-party meeting [4] which is a great
> place to ask questions and share your experience setting up a 3rd
> party CI system. The infra team has done a great job sponsoring and
> running this meeting (thanks Anita!), so please both take advantage of
> it and also contribute to it so we can all share knowledge and help
> each other.
>
> Owners of plugins/drivers should ensure their CI is matching the
> requirements set forth by both infra and Neutron when running tests
> and posting results. Like I indicated earlier, we will look at
> removing code for drivers which are not meeting these requirements as
> set forth in the wiki pages.
>
> The goal of this effort is to ensure consistency across testing
> platforms, making it easier for developers to diagnose issues when
> third party CI systems fail, and to ensure these drivers are tested
> since they are part of the integrated releases we perform. We used to
> require a core team member to sponsor a plugin/driver, but we moved to
> the 3rd party CI system in Icehouse instead. Ensuring these systems
> are running and properly working is the only way we can ensure code is
> working when it's part of the integrated release.
>
> Thanks,
> Kyle
>
> [1] https://etherpad.openstack.org/p/ZLp9Ow3tNq
> [2]
> http://www.stackalytics.com/driverlog/?project_id=openstack%2Fneutron&vendor=&release_id=
> [3] https://wiki.openstack.org/wiki/NeutronThirdPartyTesting
> [4] https://wiki.openstack.org/wiki/Meetings/ThirdParty
>
> ___
> 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][Advanced Services] Requesting reviewers

[Ivar Lazzaro]

Hi Sumit,

Review commitment sound like a good idea. Is this aiming core reviewers
only?
What number of cores / non cores are you ideally trying to reach?

Thanks,
Ivar.


On Fri, May 30, 2014 at 7:21 PM, Sumit Naiksatam 
wrote:

> During the Neutron Advanced Services' meeting this week [1], we
> discussed a plan to make the review process more predictable and
> accountable (as an experiment within this sub-team).
>
> We are soliciting reviewers who will commit to reviewing at least the
> prioritized blueprints [2] on a weekly basis and help make progress.
> If you feel comfortable making this commitment, please add your name
> to the top of this wiki page [2]. This will help the task owners to
> reach out to you and reconcile issues faster. It will also aid the
> core reviewers in making a judgement based on the feedback from of
> this reviewer team.
>
> Thanks,
> ~Sumit.
>
> [1]
> http://eavesdrop.openstack.org/meetings/networking_advanced_services/2014/networking_advanced_services.2014-05-28-17.31.log.html
>
> [2] https://wiki.openstack.org/wiki/Neutron/AdvancedServices/JunoPlan
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



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

Re: [openstack-dev] [Neturon][CI] Embrane CI is attacking gerrit

[Ivar Lazzaro]

Hi Nachi, Russel

I've stopped our Jenkins server... That should stop this crazy attack.
However, I am wondering how this happened, we didn't set any voting mechanism 
on it yet...

Sorry  about that,
Ivar.
-Original Message-
From: Nachi Ueno [mailto:na...@ntti3.com] 
Sent: Monday, January 13, 2014 3:13 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neturon][CI] Embrane CI is attacking gerrit

Hi Russell

Thanks. I got it

2014/1/13 Russell Bryant :
> On 01/13/2014 05:26 PM, Nachi Ueno wrote:
>> Hi folks
>>
>> I get Embrane CI comment in my review about 10 times in min.
>> https://review.openstack.org/#/c/58897/
>>
>> Embrane CI looks like broken, and we should stop it now.
>
> A good place to bring up issues like this is #openstack-infra on IRC.  
> I brought it up there and Jeremy Stanley got it disabled quickly.  
> Thanks, Jeremy!
>
> --
> Russell Bryant
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

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

Re: [openstack-dev] [neutron] Third party Neutron plugin testingmeeting

[Ivar Lazzaro]

+1 for 1700UTC Thursday on IRC

-Original Message-
From: Kyle Mestery [mailto:mest...@siliconloons.com] 
Sent: Tuesday, December 10, 2013 9:21 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [neutron] Third party Neutron plugin testing 
meeting

On Dec 10, 2013, at 10:45 AM, "Veiga, Anthony" 
 wrote:
> -Original Message-
> From: Kyle Mestery 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Tuesday, December 10, 2013 10:48
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Subject: [openstack-dev] [neutron] Third party Neutron plugin testing 
> meeting
> 
>> Last week I took an action item to organize a meeting for everyone 
>> who is doing third-party testing in Neutron for plugins, whether this 
>> is vendor or Open Source based. The idea is to share ideas around 
>> setups and any issues people hit. I'd like to set this meeting up for 
>> this week, Thursday at 1700UTC. I would also like to propose we make 
>> this a dial in meeting using the Infrastructure Conferencing bridges 
>> [1]. If this time works, I'll set something up and reply to this 
>> thread with the dial in information.
> 
> +1 for the meeting time.  Any particular reason for voice over IRC?
> 
We kind of decided that doing this over voice initially would be expedient, but 
I am fine with moving to IRC. If I don't hear objections, lets assume we will 
meet at 1700UTC Thursday on #openstack-meeting-alt.


>> 
>> Also, I've started a etherpad page [2] with information. It would be 
>> good for people to add information to this etherpad as well. I've 
>> coupled this pad with information around multi-node gate testing for 
>> Neutron as well, as I suspect most of the third-party testing will 
>> require multiple nodes as well.
> 
> I'll start filling out our setup.  I have some questions around 
> Third-Party Testing in particular, and look forward to this discussion.
> 
Awesome, thanks Anthony!

>> 
>> Thanks!
>> Kyle
>> 
>> [1] https://wiki.openstack.org/wiki/Infrastructure/Conferencing
>> [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
> 
> 
> ___
> 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][LBaaS] Vendor feedback needed

[Ivar Lazzaro]

Hi Eugene,

Right now (before the model change discussed during the summit) our 
implementation, in regards to your question, can be summarized as follows:


-  Whenever a Pool is created, a port on the specific subnet/network is 
created and associated to it;

-  Whenever a VIP is associated to the Pool, our Service Manager places 
the interfaces of a newly created appliance based on the information got from 
the VIP's and Pool's port (i.e. network_type and segmentation_id);

-  In order to wire the VIP with an external network, a Floating IP can 
be associated to its port (or the VIP created ON the external network itself);

-  VIP and Pool on the same network/subnet is supported as well.


The new model (LoadBalancer object) would change how and when the Load Balancer 
appliance is created, but the way the interfaces are placed into the networks 
remains the same.
I hope this answers your question.

Regards,
Ivar.

From: Samuel Bercovici [mailto:samu...@radware.com]
Sent: Wednesday, December 04, 2013 7:11 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed

Hi Eugene,

We currently support out-of-the-box VIP and Nodes on the same network.
The VIP can be associated with a floating IP if need to access from the 
"external" network.

We are considering other options but will address as we get to this.

Regards,
-Sam.


From: Eugene Nikanorov [mailto:enikano...@mirantis.com]
Sent: Wednesday, December 04, 2013 1:14 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [Neutron][LBaaS] Vendor feedback needed

Hi load balancing vendors!

I have specific question: how drivers for your solutions 
(devices/vms/processes) are going to wire a VIP with external and tenant 
networks?
As we're working on creating a suite for third-party testing, we would like to 
make sure that scenarios that we create fits usage pattern of all providers, if 
it is possible at all.
If it is not possible, we need to think of more comprehensive LBaaS API and 
tests.

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

[openstack-dev] [Neutron] Tenant's info from plugin/services

[Ivar Lazzaro]

Hello Everyone,

I was wondering if there's a "standard" way within Neutron to retrieve tenants' 
specific information (e.g. "name") from a plugin/service.
The call "context" already provides the tenant's UUID, but that may be useful 
to have some extra info in certain cases.

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

Re: [openstack-dev] [Neutron] Embrane's Neutron Plugin

[Ivar Lazzaro]

Hi Salvatore,

Thank you very much for your feedback,
I already knew about the 'maintainer' policy, and I saw in the Neutron wiki 
that: "This may be achieved by having an existing core dev agree to maintain a 
plugin, or by having one of the developers of the plugin become a member of the 
core developer team". I am aware of the core-developer's duties as described in 
the wiki, and if the team agrees I will be really glad to be part of it in 
order to maintain the plugin and contribute to the project even more :)

The plugin is not exactly a derivative of OVS's, it's designed to work on top 
of any L2 plugin, provided that the needed support is implemented.
For now, we are only supporting OVS's plugin, but I plan on extending the 
number of supported plugins as long as the model is approved (or alternatively 
switch to an Openstack "standard" model :) ).

As you suggested, I'll push the plugin code as a draft soon, which will make it 
easier to discuss this kind of things.

Thank you,
Ivar.



From: Salvatore Orlando [sorla...@nicira.com]
Sent: Wednesday, July 10, 2013 11:17 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] [Neutron] Embrane's Neutron Plugin

Hi Ivar,

thanks for your interest in Openstack and Neutron.
A few replies inline; I hope you'll find them useful.

Salvatore


On 10 July 2013 02:40, Ivar Lazzaro mailto:i...@embrane.com>> 
wrote:

Hi,

My name is Ivar Lazzaro, I’m an Italian developer currently employed at Embrane.


Embrane provides L3 to L7 network services, (including routing, load balancing, 
SSL offloads, firewalls and IPsec VPNs), and we have developed a Neutron plugin 
that we would like to share and contribute to Openstack[1].

That would be great!
the current policy for Neutron plugins is that each plugin should have a member 
of the core team which will act as a 'maintainer'; this figure is not required 
to be an 'expert' of the specific plugin technology. His duties are mainly 
those of keeping track of bugs/blueprints, review code, and interact with the 
developers.


My experience with OpenStack started with the Essex edition, which I deployed 
and managed as a "user". Embrane leverages any existing form of L2 to offer 
connectivity at L3 and above, and therefore our interest in contributing to 
OpenStack grew as L3 (and above) capabilities started to be added to Neutron, 
leading to the realization of a Neutron plugin.


I'd like to talk about it with you before "blindly" requesting a review, and 
get your feedback and advice in order to improve it at the most!

Sounds a very sensible approach, since we're already halfway through the 
release cycle, and finding resources for reviewing code might not be the 
easiest thing.


The idea is to provide L3 connectivity in Openstack through our software 
platform, called heleos, obviously using a plugin to follow the Neutron 
workflow.Since we don't provide L2 connectivity (which is part of the core APIs 
as well) our plugin is going to work together with one of the existing, which 
will manage L2 connectivity and share all the information needed.


Therefore, whenever a user chooses to use Embrane's Neutron plugin, he 
specifies one of the supported existing plugins in the configuration file, and 
L2 connectivity will be provided by that specific choice.

At the current state, for instance, our plugin is able to work with the 
OpenVSwitch's so that:


-create_network() will call OVS plugin;

-create_port() will call OVS plugin;

-crate_router() will call Embrane's which will use knowledge from the OVS 
plugin in order to provide L3 connectivity.


It looks like your plugin is pretty much a derivative of the OVS plugin, which 
replaces the L3 agent with Embrane's heleos.
I think this approach makes some sense, but in the medium/long term you would 
like to be able to run your plugin on top of any L2 plugin.

There is a Neutron blueprint for that, and that is 
https://blueprints.launchpad.net/neutron/+spec/quantum-l3-routing-plugin
That blueprint is unfortunately a bit stuck at the moment.
It would be good for the whole community to understand whether we can actually 
still merge it during the Havana timeframe.


and so forth...

The calls can be asynchronous (using Router "status" in a way similar to the 
LBaaS extension).


Without going too much into details, that's all about the L3 plugin that we 
would like to share. We are also interested in sharing a LBaaS service plugin, 
but I'll do a different blueprint for that one.

I think it won't harm pushing your code as a draft on gerrit.

All your feedback and comments are welcome :)


Thanks,

Ivar.


[1] https://blueprints.launchpad.net/neutron/+spec/embrane-neutron-plugin

_

[openstack-dev] [Neutron] Embrane's Neutron Plugin

[Ivar Lazzaro]

Hi,

My name is Ivar Lazzaro, I’m an Italian developer currently employed at Embrane.


Embrane provides L3 to L7 network services, (including routing, load balancing, 
SSL offloads, firewalls and IPsec VPNs), and we have developed a Neutron plugin 
that we would like to share and contribute to Openstack[1].


My experience with OpenStack started with the Essex edition, which I deployed 
and managed as a "user". Embrane leverages any existing form of L2 to offer 
connectivity at L3 and above, and therefore our interest in contributing to 
OpenStack grew as L3 (and above) capabilities started to be added to Neutron, 
leading to the realization of a Neutron plugin.


I'd like to talk about it with you before "blindly" requesting a review, and 
get your feedback and advice in order to improve it at the most!


The idea is to provide L3 connectivity in Openstack through our software 
platform, called heleos, obviously using a plugin to follow the Neutron 
workflow.Since we don't provide L2 connectivity (which is part of the core APIs 
as well) our plugin is going to work together with one of the existing, which 
will manage L2 connectivity and share all the information needed.


Therefore, whenever a user chooses to use Embrane's Neutron plugin, he 
specifies one of the supported existing plugins in the configuration file, and 
L2 connectivity will be provided by that specific choice.

At the current state, for instance, our plugin is able to work with the 
OpenVSwitch's so that:


-create_network() will call OVS plugin;

-create_port() will call OVS plugin;

-crate_router() will call Embrane's which will use knowledge from the OVS 
plugin in order to provide L3 connectivity.


and so forth...

The calls can be asynchronous (using Router "status" in a way similar to the 
LBaaS extension).


Without going too much into details, that's all about the L3 plugin that we 
would like to share. We are also interested in sharing a LBaaS service plugin, 
but I'll do a different blueprint for that one.

All your feedback and comments are welcome :)


Thanks,

Ivar.


[1] https://blueprints.launchpad.net/neutron/+spec/embrane-neutron-plugin
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev