from:"\"Salvatore Orlando\""

It is however interesting that both "lock wait timeouts" and "missing
savepoint" errors occur in operations pertaining the same table -
securitygroups in this case.
I wonder if the switch to pymysl has not actually uncovered some other bug
in Neutron.

I have no opposition to a revert, but since this will affect most projects,
it's probably worth finding some time to investigate what is triggering
this failure when sqlalchemy is backed by pymysql before doing that.

Salvatore

On 12 June 2015 at 03:32, Eugene Nikanorov  wrote:

> Hi neutrons,
>
> I'd like to draw your attention to an issue discovered by rally gate job:
>
> http://logs.openstack.org/96/190796/4/check/gate-rally-dsvm-neutron-rally/7a18e43/logs/screen-q-svc.txt.gz?level=TRACE
>
> I don't have bandwidth to take a deep look at it, but first impression is
> that it is some issue with nested transaction support either on sqlalchemy
> or pymysql side.
> Also, besides errors with nested transactions, there are a lot of Lock
> wait timeouts.
>
> I think it makes sense to start with reverting the patch that moves to
> pymysql.
>
> Thanks,
> Eugene.
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [neutron] Microversioning work questions and kick-start

As most of you already know, work is beginning to move forward on the
micro-versioned Neutron API, for which a specification is available at [1]

>From a practical perspective there is one non-negligible preliminary issue
that needs attention. then Neutron API URI prefix includes the full version
number - currently 2.0. For instance:

 http://neutron_server:9696/v2.0/networks.json

This clearly makes a microversioned approach a bit weird - if you have to
use, for instance, 2.0 as a URI prefix for API version 2.12.
On the one hand it might make sense to start the micro-versioned API as a
sort of clean slate, possibly using a version-agnostic URI prefix or no
prefix at all; also as pointed out by some community members it will give a
chance to validate this versioned API approach.
This will have however the drawback that both the unversioned,
extension-based so-called 2.0 API will keep living and evolving
side-by-side with the versioned API, and then switching to the versioned
API will not be transparent to clients.
It would be good to receive some opinions from the developer and user
community on the topic.

Furthermore, another topic that has been brought up is whether plugins
should be allowed to control the version of the API server, like specifying
minimum and maximum version. My short answer is no, because the plugin
should implement the API, not controlling it. Also, the spec provides a
facility for plugins to disable features if they are unable to support them.

Finally, I received queries from several community members that would be
keen on helping supporting this microversioning effort. I wonder if the PTL
and the API lieutenants would ok with agreeing to have a team of developers
meeting regularly, working towards implementing this feature, and report
progress and/or issues to the general Neutron meeting.

Salvatore

[1] https://review.openstack.org/#/c/136760/
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone] [nova] [oslo] [neutron][cross-project] Split Policy rules into two parts.

I am not able to say whether this works for Nova. Surely works for Neutron
- from a functional perspective at least.

I still don't know however whether this choice is the best way to proceed,
and perhaps you can help me understand better.

Role checks are always expressed through policy.json and can be enforced in
middleware. Does this mean that there is also a centralized policy.json, or
will we keep per-project policy files even for role checks?

Scope checks - ie: application-specific checks - can be enforced in any way
the application developers wish. They can use policy.json, be hardcoded or,
if they wish ask Pythia, the Oracle of Delphi. From an operator
perspective, this means that every project can enforce policies in a
different way. Is this going to be practical and maintainable? I can't
speak for operators, but I would like to understand a bit better what this
implies for them.

Salvatore







On 11 June 2015 at 17:47, Adam Young  wrote:

>  Sean had a really good point when he mentioned that the Developers know
> what need to be enforced, and I think this is why he suggested that the
> base policy implementation be in Python code, not the policy JSON DSL.
>
> The main thrust of the dynamic policy has been to get the role-to-api
> assignment more flexible.  However, there is another side to each policy
> rule; figureing out where the project (nee' tenant) id is in the request;
> is it part of the URL, part of the request body, or in the object returned
> from the database.  This part really should be handled by the developer
> working on the policy rule, and it should not be changed.
>
> So...what if we say that we split policy into two checks;  a role check,
> and a scope check.  Both checks must pass in order for the user to get
> access to the API.  The Scope check is not going to be dynamic;  once set,
> they will pretty much stay set.   It might be done using the policy.json,
> or done in code, but it will be separate from the role check.
>
>
> The Neutron policy checks for things like
>
> "shared": "field:networks:shared=True", "shared_firewalls":
> "field:firewalls:shared=True", "shared_firewall_policies":
> "field:firewall_policies:shared=True", "shared_subnetpools":
> "field:subnetpools:shared=True",
>
> Would be handled by the dev teams later policy check; anything that
> requires actually fetching the object from the database is postponed to
> this stage.
>
>
> The role check will come from the policy.json file.  This will allow the
> operator to fine tune how roles are handled.  Any thing else that can be
> explicitly checked based on the token will be fair game, but not API
> specific values;  no database fetch will be performed at this point.  The
> assumption is that this policy check could be generic enough to be
> performed in middleware, and might even be enforced based on the URL
> instead of the pseudo random namespacing we do now.
>
> Does this suggestion work for Nova?  I think it will make the overall
> policy much easier to maintain in the field.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Neutron] Quota enforcement

Aloha!

As you know I pushed spec [1] during the Kilo lifecycle, but given the lazy
procrastinator that I am, I did not manage to complete in time for the
release.

This actually gave me a chance to realise that the spec that I pushed and
had approved did not make a lot of sense. Even worse, there were some false
claims especially when it comes to active-active DB clusters such as mysql
galera.

Thankfully nobody bothered to look at that - possibly because it renders
horribly in HTML - and that spared me a public shaming.

I have been then following a different approach. And a set of patches,
including a devref one [2], if up for review [3]. This hardly completes the
job: more work is required on the testing side, both as unit and functional
tests.

As for the spec, since I honestly would like to spare myself the hassle of
rewriting it, I would kindly ask our glorious drivers team if they're ok
with me submitting a spec in the shorter format approved for Liberty
without going through the RFE process, as the spec is however in the Kilo
backlog.

For testing I wonder what strategy do you advice for implementing
functional tests. I could do some black-box testing and verifying quota
limits are correctly enforced. However, I would also like to go a bit
white-box and also verify that reservation entries are created and removed
as appropriate when a reservation is committed or cancelled.
Finally it would be awesome if I was able to run in the gate functional
tests on multi-worker servers, and inject delays or faults to verify the
systems behaves correctly when it comes to quota enforcement.

Do these kinds of test even make sense? And are they feasible at all? I
doubt we have any framework for injecting anything in neutron code under
test.

Finally, please note I am using DB-level locks rather than non-locking
algorithms for making reservations. I can move to a non-locking algorithm,
Jay proposed one for nova for Kilo, and I can just implement that one, but
first I would like to be convinced with a decent proof (or sort of) that
the extra cost deriving from collision among workers is overshadowed by the
cost for having to handle a write-set certification failure and retry the
operation.

Please advice.

Regards,
Salvatore

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo-backlog/better-quotas.html
[2] https://review.openstack.org/#/c/190798/
[3]
https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/better-quotas,n,z
__
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] [api] [Nova] [Ironic] [Magnum] Microversion guideline in API-WG

2015-06-10 Thread Salvatore Orlando

As a further data point, Neutron has been trying to introduce
microversioning for a while, without success so far.

Given the sheer amount of backends the management layer integrates with,
and the constant need for the various subteams to "experiment" with the
API, the proposal [1] has probably some differences with the proposed
guideline.

Since the proposal is not yet approved nor implemented, perhaps it would be
worth looking at those differences, and get your advice on whether it might
be better if neutron adheres to the current guideline proposal or whether
it might be the case to include Neutron's requirements in the current
guideline proposal.

Salvatore

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

On 10 June 2015 at 06:28, Xu, Hejie  wrote:

>  I updated the Microversion specification in API-WG
> https://review.openstack.org/187112
>
>
>
> The new patchset adds min/max version headers as Ironic used:
>
> X-Openstack-[PROJECT]-API-Minimum-Version
>
> X-Openstack-[PROJECT]-API-Maximum-Version
>
>
>
> And new response body for invalid version request.
>
>
>
>   {
>
> "versionFault": {
>
>   "max_version": "5.2",
>
>   "min_version": "2.1",
>
>   "description": "Version 5.3 is not supported by the API. \
>
>   Minimum is 2.1 and maximum is 5.2."
>
> }
>
>   }
>
>
>
> Which for backward compatible can add the existed fields in the response
> also. For example, the nova response is
>
>
>
>   {
>
> "versionFault": {
>
>   "max_version": "5.2",
>
>   "min_version": "2.1",
>
>   "description": "Version 5.3 is not supported by the API. \
>
>   Minimum is 2.1 and maximum is 5.2."
>
> },
>
> "computeFault": {
>
>   "message": "Version 5.3 is not supported by the API. \
>
>   Minimum is 2.1 and maximum is 5.2.",
>
>   "code": 406
>
> }
>
>   }
>
>
>
> The “computeFault” fields is included by current implementation, we can
> still add here, hope deprecated in the future.
>
>
>
> And the “experimental” flag in the X-OpenStack-Nova-API-Version header was
> deleted. It mentioned in the nova-spec but
>
> It didn’t implement. And I didn’t saw the same thing in the ironic. For
> current all the things satisfied all the cases. If we
>
> “experimental” flag still usefull, we can propose separately.
>
>
>
> Thanks
>
> Alex
>
>
>
> *From:* Devananda van der Veen [mailto:devananda@gmail.com]
> *Sent:* Monday, June 8, 2015 1:59 AM
> *To:* OpenStack Development Mailing List
> *Subject:* Re: [openstack-dev] [api] [Nova] [Ironic] [Magnum]
> Microversion guideline in API-WG
>
>
>
>
> On Jun 5, 2015 4:36 AM, "Sean Dague"  wrote:
> >
> > On 06/05/2015 01:28 AM, Adrian Otto wrote:
> > >
> > >> On Jun 4, 2015, at 11:03 AM, Devananda van der Veen
> > >> mailto:devananda@gmail.com>> wrote:
> > >>
> > >>
> > >> On Jun 4, 2015 12:00 AM, "Xu, Hejie"  > >> > wrote:
> > >> >
> > >> > Hi, guys,
> > >> >
> > >> > I’m working on adding Microversion into the API-WG’s guideline which
> > >> make sure we have consistent Microversion behavior in the API for
> user.
> > >> > The Nova and Ironic already have Microversion implementation, and as
> > >> I know Magnum https://review.openstack.org/#/c/184975/ is going to
> > >> implement Microversion also.
> > >> >
> > >> > Hope all the projects which support( or plan to) Microversion can
> > >> join the review of guideline.
> > >> >
> > >> > The Mircoversion specification(this almost copy from nova-specs):
> > >> https://review.openstack.org/#/c/187112
> > >> > And another guideline for when we should bump Mircoversion
> > >> https://review.openstack.org/#/c/187896/
> > >> >
> > >> > As I know, there already have a little different between Nova and
> > >> Ironic’s implementation. Ironic return min/max version when the
> requested
> > >> > version doesn’t support in server by http-headers. There isn’t such
> > >> thing in nova. But that is something for version negotiation we need
> > >> for nova also.
> > >> > Sean have pointed out we should use response body instead of http
> > >> headers, the body can includes error message. Really hope ironic team
> > >> can take a
> > >> > look at if you guys have compelling reason for using http headers.
> > >> >
> > >> > And if we think return body instead of http headers, we probably
> > >> need think about back-compatible also. Because Microversion itself
> > >> isn’t versioned.
> > >> > So I think we should keep those header for a while, does make sense?
> > >> >
> > >> > Hope we have good guideline for Microversion, because we only can
> > >> change Mircoversion itself by back-compatible way.
> > >>
> > >> Ironic returns the min/max/current API version in the http headers for
> > >> every request.
> > >>
> > >> Why would it return this information in a header on success and in the
> > >> body on failure? (How would this inconsistency benefit users?)
> > >>
> > >> To be clear, I'm not opposed to *also* having a useful error message
> > >> in th

Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs

2015-06-09 Thread Salvatore Orlando

Jay is pretty much right.

In Neutron's case it is even more trivial. Somebody copied the extension
manager from Nova, and a sort of extension interface with this namespace.
And every neutron developer, including me felt compelled to filling that up
with something that resembled an XML namespace URI (which often resolve to
nowhere anyway).

I think a patch for blanking out those namespace is a great low hanging
fruit for new contributors.
But on the other hand I'm pretty sure Kevin is wiping them out as a part of
the Pecan refactor.

Salvatore

On 9 June 2015 at 20:33, Kevin Benton  wrote:

> I heard rumors that Oracle was going to introduce XML-as-a-service to
> OpenStack to make it enterprise-grade. If that's the case, we'll be ahead
> of everyone with our namespaces.
> On Jun 9, 2015 12:04 PM, "Brandon Logan" 
> wrote:
>
>> I believe XML support got removed from the API last cycle.
>> 
>> From: Jay Pipes 
>> Sent: Tuesday, June 9, 2015 1:08 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [Neutron] API Extensions - Namespace URLs
>>
>> On 06/08/2015 05:10 PM, Sean M. Collins wrote:
>> > Hi,
>> >
>> > Within each API extension in the neutron tree, there is a method:
>> >
>> >  def get_namespace(cls):
>> >
>> > Which returns a string, containing a URL.
>>
>> 
>>
>> > I believe that they all 404.
>> >
>> > A dumb question to start, then progressively smarter questions:
>> >
>> > * What is the purpose of the URLs?
>>
>> They are the sad detritus left from XML support.
>>
>> > * Should the URL point to documentation?
>>
>> Perhaps.
>>
>> > * What shall we do about the actual URLs 404'ing?
>>
>> Honestly, I'd prefer the namespaces just be removed, but I'm not sure
>> what Neutron's position is about XML and the REST API...
>>
>> Best,
>> -jay
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - L3 scope-aware security groups

2015-06-08 Thread Salvatore Orlando

Kevin,

On 8 June 2015 at 23:52, Kevin Benton  wrote:

> There is a bug in security groups here:
> https://bugs.launchpad.net/neutron/+bug/1359523
>
> In the example scenario, it's caused by conntrack zones not being
> isolated. But it also applies to the following scenario that can't be
> solved by zones:
>
> create two networks with same 10.0.0.0/24
> create port1 in SG1 on net1 with IP 10.0.0.1
> create port2 in SG1 on net2 with IP 10.0.0.2
> create port3 in SG2 on net1 with IP 10.0.0.2
> create port4 in SG2 on net2 with IP 10.0.0.1
>

> port1 can communicate with port3 because of the allow rule for port2's IP
> port2 can communicate with port4 because of the allow rule for port1's IP
>

So this would be a scenario when bug 1359523 hits even with conntrack zone
separation, with the subtle, and terrible difference that there is a way to
enable cross-network plugging? For instance to reach port1 on net1, all I
have to do is create a network with a CIDR with some overlap with net1's,
and then wait until a VM is created with an IP that exists also on net1 -
and then jackpot, that VM will basically have access to all of net1's
instances?

The scenario you're describing is quite concerning from a security
perspective. Shouldn't there be L2 isolation to prevent something like this?

The solution will require the security groups processing code to understand
> that a member of a security group is not actually reachable by another
> member and skip the allow rule for that member.
>

The paragraph above is a bit obscure to me.

>
> With the current state of things, it will take a tone of kludgy code to
> check for routers and router interfaces to see if two IPs can communicate
> without NAT. However, if we end up with the concept of address-scopes, it
> just becomes a simple address scope comparison.
>

This is fine, but I wonder how's that related to what you described
earlier. Is the vulnerability triggered by the fact that both networks can
be attached to the same router? In that case I think that if the l3 mgmt
code works as expected it would reject adding an interface for a subnet
with an overlap with another already attached subnet, thus implementing an
implicit address scope of 0.0.0.0/0 (for v4).

>
> Implement address scopes.
>

Sure, my master.

>
>
> Cheers!
> --
> Kevin Benton
>
> __
> 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] L3 agent rescheduling issue

2015-06-07 Thread Salvatore Orlando

On 5 June 2015 at 01:29, Itsuro ODA  wrote:

> Hi,
>
> > After trying to reproduce this, I'm suspecting that the issue is actually
> > on the server side from failing to drain the agent report state queue in
> > time.
>
> I have seen before.
> I thought the senario at that time as follows.
> * a lot of create/update resource API issued
> * "rpc_conn_pool_size" pool exhausted for sending notify and blocked
>   farther sending side of RPC.
> * "rpc_thread_pool_size" pool exhausted by waiting "rpc_conn_pool_size"
>   pool for replying RPC.
> * receiving state_report is blocked because "rpc_thread_pool_size" pool
>   exhausted.
>
>
I think this could be a good explanation couldn't it?
Kevin proved that the periodic tasks are not mutually exclusive and that
long process times for sync_routers are not an issue.
However, he correctly suspected a server-side involvement, which could
actually be a lot of requests saturating the RPC pool.

On the other hand, how could we use this theory to explain why this issue
tend to occur when the agent is restarted?
Also, Eugene, what do you mean by stating that the issue could be in
agent's "fairness"?

Salvatore



> Thanks
> Itsuro Oda
>
> On Thu, 4 Jun 2015 14:20:33 -0700
> Kevin Benton  wrote:
>
> > After trying to reproduce this, I'm suspecting that the issue is actually
> > on the server side from failing to drain the agent report state queue in
> > time.
> >
> > I set the report_interval to 1 second on the agent and added a logging
> > statement and I see a report every 1 second even when sync_routers is
> > taking a really long time.
> >
> > On Thu, Jun 4, 2015 at 11:52 AM, Carl Baldwin 
> wrote:
> >
> > > Ann,
> > >
> > > Thanks for bringing this up.  It has been on the shelf for a while now.
> > >
> > > Carl
> > >
> > > On Thu, Jun 4, 2015 at 8:54 AM, Salvatore Orlando  >
> > > wrote:
> > > > One reason for not sending the heartbeat from a separate greenthread
> > > could
> > > > be that the agent is already doing it [1].
> > > > The current proposed patch addresses the issue blindly - that is to
> say
> > > > before declaring an agent dead let's wait for some more time because
> it
> > > > could be stuck doing stuff. In that case I would probably make the
> > > > multiplier (currently 2x) configurable.
> > > >
> > > > The reason for which state report does not occur is probably that
> both it
> > > > and the resync procedure are periodic tasks. If I got it right
> they're
> > > both
> > > > executed as eventlet greenthreads but one at a time. Perhaps then
> adding
> > > an
> > > > initial delay to the full sync task might ensure the first thing an
> agent
> > > > does when it comes up is sending a heartbeat to the server?
> > > >
> > > > On the other hand, while doing the initial full resync, is the  agent
> > > able
> > > > to process updates? If not perhaps it makes sense to have it down
> until
> > > it
> > > > finishes synchronisation.
> > >
> > > Yes, it can!  The agent prioritizes updates from RPC over full resync
> > > activities.
> > >
> > > I wonder if the agent should check how long it has been since its last
> > > state report each time it finishes processing an update for a router.
> > > It normally doesn't take very long (relatively) to process an update
> > > to a single router.
> > >
> > > I still would like to know why the thread to report state is being
> > > starved.  Anyone have any insight on this?  I thought that with all
> > > the system calls, the greenthreads would yield often.  There must be
> > > something I don't understand about it.
> > >
> > > Carl
> > >
> > >
> __
> > > 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
> > >
> >
> >
> >
> > --
> > Kevin Benton
>
> --
> Itsuro ODA 
>
>
> __
> 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] L3 agent rescheduling issue

2015-06-04 Thread Salvatore Orlando

One reason for not sending the heartbeat from a separate greenthread could
be that the agent is already doing it [1].
The current proposed patch addresses the issue blindly - that is to say
before declaring an agent dead let's wait for some more time because it
could be stuck doing stuff. In that case I would probably make the
multiplier (currently 2x) configurable.

The reason for which state report does not occur is probably that both it
and the resync procedure are periodic tasks. If I got it right they're both
executed as eventlet greenthreads but one at a time. Perhaps then adding an
initial delay to the full sync task might ensure the first thing an agent
does when it comes up is sending a heartbeat to the server?

On the other hand, while doing the initial full resync, is the  agent able
to process updates? If not perhaps it makes sense to have it down until it
finishes synchronisation.

Salvatore

[1]
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/agent/l3/agent.py#n587

On 4 June 2015 at 16:16, Kevin Benton  wrote:

> Why don't we put the agent heartbeat into a separate greenthread on the
> agent so it continues to send updates even when it's busy processing
> changes?
> On Jun 4, 2015 2:56 AM, "Anna Kamyshnikova" 
> wrote:
>
>> Hi, neutrons!
>>
>> Some time ago I discovered a bug for l3 agent rescheduling [1]. When
>> there are a lot of resources and agent_down_time is not big enough
>> neutron-server starts marking l3 agents as dead. The same issue has been
>> discovered and fixed for DHCP-agents. I proposed a change similar to those
>> that were done for DHCP-agents. [2]
>>
>> There is no unified opinion on this bug and proposed change, so I want to
>> ask developers whether it worth to continue work on this patch or not.
>>
>> [1] - https://bugs.launchpad.net/neutron/+bug/1440761
>> [2] - https://review.openstack.org/171592
>>
>> --
>> Regards,
>> Ann Kamyshnikova
>> Mirantis, Inc
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

I'm not sure if you can test this behaviour on your own because it requires
the VMware plugin and the eventlet handling of backend response.

But the issue was manifesting and had to be fixed with this mega-hack [1].
The issue was not about several workers executing the same code - the
loopingcall was always started on a single thread. The issue I witnessed
was that the other API workers just hang.

There's probably something we need to understand about how eventlet can
work safely with a os.fork (I just think they're not really made to work
together!).
Regardless, I did not spent too much time on it, because I thought that the
multiple workers code might have been rewritten anyway by the pecan switch
activities you're doing.

Salvatore


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

On 3 June 2015 at 02:20, Kevin Benton  wrote:

> Sorry about the long delay.
>
> >Even the LOG.error("KEVIN PID=%s network response: %s" % (os.getpid(),
> r.text)) line?  Surely the server would have forked before that line was
> executed - so what could prevent it from executing once in each forked
> process, and hence generating multiple logs?
>
> Yes, just once. I wasn't able to reproduce the behavior you ran into.
> Maybe eventlet has some protection for this? Can you provide small sample
> code for the logging driver that does reproduce the issue?
>
> On Wed, May 13, 2015 at 5:19 AM, Neil Jerram 
> wrote:
>
>> Hi Kevin,
>>
>> Thanks for your response...
>>
>> On 08/05/15 08:43, Kevin Benton wrote:
>>
>>> I'm not sure I understand the behavior you are seeing. When your
>>> mechanism driver gets initialized and kicks off processing, all of that
>>> should be happening in the parent PID. I don't know why your child
>>> processes start executing code that wasn't invoked. Can you provide a
>>> pointer to the code or give a sample that reproduces the issue?
>>>
>>
>> https://github.com/Metaswitch/calico/tree/master/calico/openstack
>>
>> Basically, our driver's initialize method immediately kicks off a green
>> thread to audit what is now in the Neutron DB, and to ensure that the other
>> Calico components are consistent with that.
>>
>>  I modified the linuxbridge mech driver to try to reproduce it:
>>> http://paste.openstack.org/show/216859/
>>>
>>> In the output, I never received any of the init code output I added more
>>> than once, including the function spawned using eventlet.
>>>
>>
>> Interesting.  Even the LOG.error("KEVIN PID=%s network response: %s" %
>> (os.getpid(), r.text)) line?  Surely the server would have forked before
>> that line was executed - so what could prevent it from executing once in
>> each forked process, and hence generating multiple logs?
>>
>> Thanks,
>> Neil
>>
>>  The only time I ever saw anything executed by a child process was actual
>>> API requests (e.g. the create_port method).
>>>
>>
>>
>>
>>  On Thu, May 7, 2015 at 6:08 AM, Neil Jerram >> > wrote:
>>>
>>> Is there a design for how ML2 mechanism drivers are supposed to cope
>>> with the Neutron server forking?
>>>
>>> What I'm currently seeing, with api_workers = 2, is:
>>>
>>> - my mechanism driver gets instantiated and initialized, and
>>> immediately kicks off some processing that involves communicating
>>> over the network
>>>
>>> - the Neutron server process then forks into multiple copies
>>>
>>> - multiple copies of my driver's network processing then continue,
>>> and interfere badly with each other :-)
>>>
>>> I think what I should do is:
>>>
>>> - wait until any forking has happened
>>>
>>> - then decide (somehow) which mechanism driver is going to kick off
>>> that processing, and do that.
>>>
>>> But how can a mechanism driver know when the Neutron server forking
>>> has happened?
>>>
>>> Thanks,
>>>  Neil
>>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> <
>>> http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>>
>>> --
>>> Kevin Benton
>>>
>>>
>>>
>>> __
>>> 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
>>
>
>
>
> --
> Kevin Benton
>
>

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 3 June 2015 at 07:12, John Griffith  wrote:

>
>
> On Tue, Jun 2, 2015 at 7:19 PM, Ian Wienand  wrote:
>
>> On 06/03/2015 07:24 AM, Boris Pavlovic wrote:
>>
>>> Really it's hard to find cores that understand whole project, but
>>> it's quite simple to find people that can maintain subsystems of
>>> project.
>>>
>>
>>   We are made wise not by the recollection of our past, but by the
>>   responsibility for our future.
>>- George Bernard Shaw
>>
>> Less authorities, mini-kingdoms and
>> turing-complete-rule-based-gerrit-subtree-git-commit-enforcement; more
>> empowerment of responsible developers and building trust.
>>
>> -i
>>
>>
>> __
>> 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
>>
>
> All of the debate about the technical feasibility, additional repos
> aside, the one question I always raise when topics like this come up is
> "how does that really solve the problem".  In other words, there's still a
> finite number of folks that dedicate the time to be "subject matter
> experts" and do the reviews.
>
> Maybe this will help, I don't know.  But I have the same argument as I
> made in my spec to remove drivers from Cinder altogether, creating "another
> repo" and moving things around just creates more overhead and does little
> to address the lack of review resources.
>

In the neutron project we do not have yet enough data points to assess
impact of driver/plugin split on review turnaround. On the one hand it
seems that there is no statistically significant improvement in review
times for the "core" part, but on the other hand average review times for
plugin/driver code have improved a lot. So I reckon that there's been a
clear advantage on this front. There is always a flip of the coin, of
course: plugin maintainers have to do extra work to chase changes in
openstack/neutron.

However, this is a bit out of scope for this thread. I'd say that splitting
out a project in several repositories is an option, but not always the
right one. In the case of neutron plugins and drivers, it made sense
because there is a stable-ish interface between the core system and the
plugin, and because there's usually little overlap of responsibilities.

> I understand you're not proposing new repos Boris, although it was
> mentioned in this thread.
>
> I do think that we could probably try and do something like growing the
> Lieutenant model that the Neutron team is hammering out.  Not sure... but
> seems like a good start; again assuming there are enough
> qualified/interested Lieutenants.  I'm not sure, but that's kind of how I
> interpreted your proposal but one additional step of ACL's; is that
> accurate?
>

While I cannot answer for Boris, my opinion is that the lieutenant system
actually tries to provide a "social" solution to the problem, where as ACLs
are a technical solution. I personally think that the belief that there's
always a tool to fix any problem is a giant unicorn - as Robert put it
there's no technical solution to a social problem. A technical solution
would probably end up bringing more process, more bureaucracy, and
therefore more annoyance... but I'm digressing.

In my opinion the lieutenant system is an attempt to build networks of
trusted and responsible developers who share interest (more or less vested)
and knowledge on a specific subsystem of a project. If implemented
correctly, it will ensure those networks are small enough so that trust can
be achieved in a simple way.
I'd rather rely on trust and common sense than on a set of ACLs that
probably at some point will get in the way and be more a hindrance than a
help.

Salvatore

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

Re: [openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)

On 2 June 2015 at 23:59, Ian Cordasco  wrote:

>
>
> On 6/2/15, 16:24, "Boris Pavlovic"  wrote:
>
> >Hi stackers,
> >
> >
> >Issue
> >---
> >
> >
> >Projects are becoming bigger and bigger overtime.
> >More and more people would like to contribute code and usually core
> >reviewers
> >team can't scale enough. It's very hard to find people that understand
> >full project and have enough time to do code reviews. As a result team is
> >very small under heavy load and many maintainers just get burned out.
> >
> >
> >We have to solve this issue to move forward.
> >
> >
> >
> >
> >Idea
> >--
> >
> >
> >Let's introduce subsystems cores.
> >
> >
> >Really it's hard to find cores that understand whole project, but it's
> >quite simple to find people that can maintain subsystems of project.
> >
> >
> >
> >
> >How To
> >---
> >
> >
> >Gerrit is not so simple as it looks and it has really neat features ;)
> >
> >
> >For example we can write own rules about who can put +2 and merge patch
> >based on changes files.
> >
> >
> >We can make special "subdirectory core" ACL group.
> >People from such ACL group will be able to merge changes that touch only
> >files from some specific subdirs.
> >
> >
> >As a result with proper organization of directories in project we can
> >scale up review process without losing quality.
> >
> >
> >
> >
> >Thoughts?
> >
> >
> >
> >
> >Best regards,
> >Boris Pavlovic
>
> I like this very much. I recall there was a session at the summit about
> this that Thierry and Kyle led.


Indeed, and Kyle has already transformed that into facts [1]


> If I recall correctly, the discussion
> mentioned that it wasn't (at this point in time) possible to use gerrit
> the way you describe it, but perhaps people were mistaken?
>

I recall that too, and I also recall fungi stating the same thing back in
Paris.
Gerrit doesn't really have a concept of subsystems, as far as I can
understand; in theory gerrit could be changed to support this, but that's
another discussion.
The networking community is currently adopting multiple repositories to
this aim. This has worked very well for 3rd party plugins, and quite well
for advanced services.
For the 'neutron' proper project, which is however large enough to identify
multiple subsystems in it, the lieutenant mode described in [1] will be
enforced with a bit of common sense - from what I gather. If you're a core
for subsystem X, nominated by its lieutenant, you're not supposed to +/-2
patches that only marginally affect your subsystem or do not affect it at
all.


>
> If we can do this exactly as you describe it, that would be awesome.

If
> there's a problem in limiting people to what files they can approve
> changes for, then an alteration might be that those people get +2 but not
> +W. This provides a signal to whomever has +W that the review is very much
> ready to be merged. Does that sound fair?
>

neutron-specs adopts this approach (all cores can +2 but only a handful can
+A).
I think it works, in the assumption of a lieutenant systems, but for
projects with a large patch turnaround might constitute a bottleneck,
especially when there are gate-breaking issues that need to be approved
ASAP.
Generally speaking, I believe having 2 ties of cores (those with +A rights
and those without) is an experiment worth doing. I don't think it creates
an "elite" among developers; on the other hand, it gives SMEs a chance to
have a greater impact.



> Cheers,
> Ian
>
>
Salvatore

[1]
http://git.openstack.org/cgit/openstack/neutron/tree/doc/source/policies/core-reviewers.rst


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

Re: [openstack-dev] Interconnecting projects

I suspect a "BaaS" (Bridge-as-a-service) proposal is lurking in this thread.

While the idea of yet-another-aas is probably not desirable at this time,
it might be worth trying and understand - from an exclusively logical
perspective (ie: the API consumer point of view) - what would be the
difference between having a single logical network shared across a number
of tenants, and a group of distinct networks interconnected by bridge ports.

I've tried in the past to look at "unique" use cases for a network bridge
feature; it might seem important to enforce that all the traffic between
two network goes through a predefined channel where security and traffic
shaping policies might be applied. On the other hand, I believe the same
result can be achieved - in the logical model - with features such as
security groups. This unless the Neutron API consumer explicitly wants to
describe a topology where all the traffic is forced to flow through a
specific logical appliance, but then we'll descend in the NFV/SFC/etc area.

Another thing to keep in mind is that routers can be used to this aim, but
- as Anik correctly noted - this is an admin-only feature at the moment.
Allowing router owners to interconnect other tenants' networks, leveraging
concepts such as keystone groups, is something that should be a natural
evolution of the RBAC work.
Still, this will leave us with a L3 interconnection, and not a direct L2
network-network connection.

Salvatore

On 2 June 2015 at 18:58, Fawad Khaliq  wrote:

> Great!
> A correction here: RBAC proposal does address some of the use cases on
> interconnecting tenants.
>
> Fawad Khaliq
>
>
> On Tue, Jun 2, 2015 at 9:41 PM, Anik  wrote:
>
>> That's exactly what I was asking for. Thanks Fawad.
>>
>> Regards,
>> Anik
>> 201-245-1569
>>
>>   --
>>  *From:* Fawad Khaliq 
>> *To:* OpenStack Development Mailing List (not for usage questions) <
>> openstack-dev@lists.openstack.org>
>> *Cc:* Anik 
>> *Sent:* Tuesday, June 2, 2015 9:29 AM
>> *Subject:* Re: [openstack-dev] Interconnecting projects
>>
>>
>> On Tue, Jun 2, 2015 at 9:14 PM, Assaf Muller  wrote:
>>
>> Check out:
>>
>> http://specs.openstack.org/openstack/neutron-specs/specs/liberty/rbac-networks.html
>>
>> If I understand correctly, what Anik is probably asking for is way to
>> connect two OpenStack projects together from a network point of view, where
>> a private network in Project1 can be connected to a Router in  Project2.
>> AFAIK, I don't think we are planning to expose such model in RBAC where a
>> tenant (non-admin) has a way control who can see/connect-to his/her
>> resources.
>>
>> @Anik, please correct me if I am wrong.
>>
>>
>>
>> Kevin is trying to solve exactly this problem. We're really hoping to
>> land it in
>> time for Liberty.
>>
>> - Original Message -
>> > Hi,
>> >
>> > Trying to understand if somebody has come across the following scenario:
>> >
>> > I have a two projects: Project 1 and Project 2
>> >
>> > I have a neutron private network in Project 1, that I want to connect
>> that
>> > private network to a neutron port in Project 2.
>> >
>> > This does not seem to be possible without using admin credentials. I am
>> not
>> > talking about a shared provider network here.
>> >
>> > It seems that the problem lies in the fact that there is no data model
>> today
>> > that lets one Project have knowledge about any other Project inside the
>> same
>> > OpenStack region.
>> >
>> > Any pointers there will be helpful.
>> > Regards,
>> > Anik
>> > 201-245-1569
>> >
>> >
>> __
>> > OpenStack Development Mailing List (not for usage questions)
>> > Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> >
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> 
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [neutron] - dnsmasq 'dhcp-authoritative' option broke multiple DHCP servers

2015-05-26 Thread Salvatore Orlando

>From the bug Kevin reported it seems multiple dhcp agents per network have
been completely broken by the fix for bug #1345947, so a revert of patch
[1] (and stable backports) should probably be the first thing to do - if
nothing else because the original bug has not nearly the same level of
severity of the one it introduced.
Before doing this however, I am wondering why the various instances of
dnsmasq end up returning NAKs. I expect all instances to have the same
hosts file, so they should be able to respond to DHCPDISCOVER/DHCPREQUEST
correctly. Is the dnsmasq log telling us exactly why the authoritative
setting is preventing us from doing so? (this is more of a curiosity in my
side)

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



On 26 May 2015 at 06:57, Ihar Hrachyshka  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 05/26/2015 04:35 AM, Kevin Benton wrote:
> > Hi,
> >
> > A recent change[1] to pass '--dhcp-authoritative' to dnsmasq has
> > caused DHCPNAK messages when multiple agents are scheduled to a
> > network [2].
> >
> > This was back-ported to Icehouse and Juno so we need a fix that is
> > compatible with both of them.
> >
> > I have two fixes for this so far and a third alternative if we
> > don't like those.
> >
> > The first is hacky, but it's only a few-line change.[3] It adds an
> > iptables rule that just stops the DHCPNAKs from making it to the
> > client. This is clean to back-port but it doesn't protect clients
> > that have filtering disabled (e.g. bare metal).
> >
> > The second persists the DHCP leases to a database.[4] The downside
> > to this was always that being rescheduled to another agent would
> > mean no entries in the lease file. This approach adds a work-around
> > to generate an initial fake lease file based on all of the ports in
> > the network.
> >
> > A third approach that I don't have a patch pushed for yet is very
> > similar to the second. When dnsmasq is in the leasefile-ro mode, it
> > will call the script passed to --dhcp-script to get a list of
> > leases to start with. This script would be built with the same
> > logic as the second one. The only difference between the second
> > approach is that dnsmasq wouldn't persist leases to a database.
> >
>
> Actually, that approach was initially taken for bug 1345947, but then
> the patch was abandoned to be replaced with a simpler
> - --dhcp-authoritative approach that ended up with unexpected NAKs for
> multi agent setup.
>
> See: https://review.openstack.org/#/c/108272/12
>
> Maybe we actually want to restore the work and merge it after
> conflicts are resolved and --dhcp-authoritative option is killed; the
> patch was almost merged when --dhcp-authoritative suggestion emerged,
> so most of nitpicking work should be complete now (though at the same
> time, I totally trust our community to find another pile of nits to
> work on for the next few weeks!)
>

That was my thought as well.
However, we should check whether that patch is ok to backport. For instance
I see what it appears to be adding a script:

[2]
https://review.openstack.org/#/c/108272/12/bin/neutron-dhcp-agent-dnsmasq-lease-init


>
> ===
>
> Speaking of regression testing... Are full stack tests already
> powerful enough for us to invoke multiple DHCP agents and test the
> scenario?
>
> Ihar
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJVZHvHAAoJEC5aWaUY1u57vukIAJLPpQ9O236NYtOaRTzkL7g8
> Io1DmF6jyhJYFqfzoFcrFVbNmM0EsNtvMgZIhI8oYINkkoBYMJPoS2a8FvVUpZHw
> u/fmdvdbZgJwy4BCAEF0t+R1t1XLo6eTcPp8f3jABzExWyrLoKEbHJ0aWb5xwJ3u
> V74HXxo/PVifrNfxsQPn57ZxqgBvl4GSQAFQKE4FX/H81HWRWRuB5a9aC+hkYC9w
> 7FqXpf+IFCaS7tYdTSqJUa2/bKs268RQGoVqAYEtmVV5pA3OiMsy459rdLcHqqxS
> 67lryFh1DTMwI77LjDEanXzWIdMhb3t0YZw7ewpBBLl6P/Lh7xobIOGX2GeOyJ0=
> =xivW
> -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

[openstack-dev] [Neutron] Stepping down from Neutron core team

2015-05-21 Thread Salvatore Orlando

After putting the whole OpenStack networking contributors community through
almost 8 cycles of pedant comments and annoying "what if" questions, it is
probably time for me to relieve neutron contributors from this burden.

It has been a pleasure for me serving the Neutron community (or Quantum as
it was called at the time), and now it feel right - and probably overdue -
to relinquish my position as a core team member in a spirit of rotation and
alternation between contributors.

Note: Before you uncork your champagne bottles, please be aware that I will
stay in the Neutron community as a contributors and I might still end up
reviewing patches.

Thanks for being so understanding with my pedant remarks,
Salvatore
__
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] [new][cognitive] Announcing Cognitive - a project to deliver Machine Learning as a Service for OpenStack

2015-05-14 Thread Salvatore Orlando

On 15 May 2015 at 00:19, Debojyoti Dutta  wrote:

> Hi!
>
> It is a great pleasure to announce the development of a new project called
> Cognitive.  Cognitive provides Machine Learning [1] as a Service that
> enables operators to offer next generation data science based services on
> top of their OpenStack Clouds.
>

I was indeed wondering when "Machine Learning as a Service" would come up...


> This project will begin as a StackForge project baed upon an empty
> cookiecutter [2] repo.  The repos to work in are:
> Server: https://github.com/stackforge/cognitive
> Client: https://github.com/stackforge/python-cognitiveclient
>
> Please join us via iRC on #openstack-cognitive on freenode.
>
> We will be holding a doodle poll to select times for our first meeting the
> week after summit.  This doodle poll will close May 24th and meeting times
> will be announced on the mailing list at that time.  At our first IRC
> meeting, we will draft additional core team members. We would like to
> invite interested individuals to join this exciting new development effort!
>

>From my little experience, "drafting" core members before even actually
having a code base has drawbacks. Also, it seems the initial starting team
is already large enough for ensuring support for 1 or 2 release cycle.


>
>

> Please commit your schedule in the doodle poll here:
> http://doodle.com/drrka5tgbwpbfbxy
>
> Initial core team: Steven Dake, Aparupa Das Gupa, Debo~ Dutta, Johnu
> George,  Kyle Mestery, Sarvesh Ranjan, Ralf Rantzau, Komei Shimamura, Marc
> Solanas, Manoj Sharma, Yathi Udupi, Kai Zhang.
>

Hey! What's the Neutron PTL doing there? Sorry we need his reviews we can't
loan it to you!


>
> A little bit about Cognitive:
> Data driven applications on cloud infrastructure increasingly rely on
> Machine Learning. Most data driven applications today use Machine Learning
> (ML). This often requires application developers and data scientists to
> write their own machine learning stack or deploy other packages to do any
> kind of data science based applications. Data scientists also need to have
> an easy way to rapidly experiment with data without having to write basic
> infrastructure for data manipulations. Cognitive is a Machine Learning
> service on top of OpenStack and provides machine learning based services to
> tenants (API, workbench, compute service).
>

I wonder what kind of services you would offer; also you could have shared
something about the architecture of this service. Is it providing a full
machine learning stack, or just facilitating the use of existing one?

But I see that there's a link to a wiki page below. This might have all the
answers.


>
>
> For information about blueprints check out:
> https://blueprints.launchpad.net/cognitive
> https://blueprints.launchpad.net/python-cognitiveclient
>
> For more details, check out our Wiki:
> https://wiki.openstack.org/wiki/Cognitive
>

... and unfortunately the wiki is empty ;)


>
> Please join the awesome Cognitive team in designing a world class Machine
> Learning as a Service solution.
>
> We look forward to seeing you on IRC on #openstack-cognitive.
>
> Regards,
> Debo~ Dutta (on behalf of the initial team)
>
> [1] http://en.wikipedia.org/wiki/Machine_learning
> [2] https://github.com/openstack-dev/cookiecutter
>
> __
> 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][QoS] Neutron QoS (Quality Of Service) update

2015-05-08 Thread Salvatore Orlando

On 7 May 2015 at 10:32, Miguel Ángel Ajo  wrote:

> Gal, thank you very much for the update to the list, I believe it’s very
> helpful,
> I’ll add some inline notes.
>
> On Thursday, 7 de May de 2015 at 8:51, Gal Sagie wrote:
>
> Hello All,
>
> I think that the Neutron QoS effort is progressing into critical point and
> i asked Miguel if i could post an update on our progress.
>
> First, i would like to thank Sean and Miguel for running this effort and
> everyone else that is involved, i personally think its on the right track,
> However i would like to see more people involved, especially more Neutron
> experienced members because i believe we want to make the right decisions
> and learn from past mistakes when making the API design.
>
> Feel free to update in the meeting wiki [1], and the spec review [2]
>
> *Topics*
>
> *API microversioning spec implications [3]*
> QoS can benefit from this design, however some concerns were raised that
> this will
> only be available at mid L cycle.
> I think a better view is needed how this aligns with the new QoS design and
> any feedback/recommendation is use full
>
> I guess an strategy here could be: go on with an extension, and translate
> that into
> an experimental API once micro versioning is ready, then after one cycle
> we could
> “graduate it” to get versioned.
>

Indeed. I think the guy who wrote the spec mentioned how to handle
extensions which are in the pipeline already, and has a kind word for QoS
in particular.

>
> *Changes to the QoS API spec: scoping into bandwidth limiting*
> At this point the concentration is on the API and implementation
> of bandwidth limiting.
>
> However it is important to keep the design easily extensible for some next
> steps
> like traffic classification and marking
> *.*
>
> This is important for architecting your data model, RPC interfaces, and to
some extent even the control plane.
>From a user perspective (and hence API design) the question to ask would be
whether a generic QoS API (for instance based on generic QoS policies which
might have a different nature) is better than an explicit ones - where you
would have distinct URIs for rate limiting, traffic shaping, marking, etc.

I am not sure of what could be the right answer here. I tend to think
distinct URIs are more immediate to use. On the other hand users will have
to learn more APIs, but even with a generic framework users will have to
learn how to create policies for different types of QoS policies.

>
> *Changes to the QoS API spec: modeling of rules (class hierarchy)
> (Guarantee split out)*
> There is a QoSPolicy which is composed of different QoSRules, there is
> a discussion of splitting the rules into different types like
> QoSRule.
> (This in order to support easy extension of this model by adding new type
> of rules which extend the possible parameters)
>
> Plugins can then separate optional aspects into separate rules.
> Any feedback on this approach is appreciated.
>
> *Discuss multiple API end points (per rule type) vs single*
>
>
> here, the topic name was incorrect, where I said API end points, we were
> meaning URLs or REST resources.. (thanks Irena for the correction)
>

So probably my previous comment applies here as well.

>
>
> In summary this means  that in the above model, do we want to support
> /v1/qosrule/..  or   /v1/qosrule/ API's
> I think the consensus right now is that the later is more flexible.
>
> Miguel is also checking the possibility of using something like:
> /v1/qosrule/type/... kind of parsing
> Feedback is desired here too :)
>
> *Traffic Classification considerations*
> The idea right now is to extract the TC classification to another data
> model
> and attach it to rule
> that way no need to repeat same filters for the same kind of traffic.
>
>
Didn't you say you were going to focus on rate limiting? ;)

>
> Of course we need to consider here what it means to "update" a classifier
> and not to introduce too much dependencies
>
> About this, the intention is not to fully model this, or to include it in
> the data model now,
> but try to see how could we do it in future iterations and see if it fits
> the current data model
> and APIs we’re proposing.
>

Can classifier management be considered an admin mgmt feature like instance
flavour?

>
>
>
> *The ingress vs egress differences and issues*
> Egress bandwidth limiting is much more use full and supported,
> There is still doubt on the support of Ingress bandwidth limiting in OVS,
> anyone
> that knows if Ingress QoS is supported in OVS we want your feedback :)
>
> I do not think so, but don't take my word for granted.
You can ping somebody in #openvswitch or post to ovs-disc...@openvswitch.org


> (For example implementing OF1.3 Metering spec)
>
> Thanks all (Miguel, Sean or anyone else, please update this if i forgot
> anything)
>
> [1] https://wiki.openstack.org/wiki/Meetings/QoS
> [2] https://review.openstack.org/#/c/88599/
> [3] https://review.openstack.org/#/c/136760/

Re: [openstack-dev] [neutron] Mechanism drivers and Neutron server forking?

2015-05-08 Thread Salvatore Orlando

Just like the Neutron plugin manager, also ML2 driver manager ensure
drivers are loaded only once regardless of the number of workers.
What Kevin did proves that drivers are correctly loaded before forking (I
reckon).

However, forking is something to be careful about especially when using
eventlet. For the plugin my team maintains we were creating a periodic task
during plugin initialisation.
This lead to an interesting condition where API workers were hanging [1].
This situation was fixed with a rather pedestrian fix - by adding a delay.

Generally speaking I would find useful to have a way to "identify" an API
worker in order to designate a specific one for processing that should not
be made redundant.
On the other hand I self-object to the above statement by saying that API
workers are not supposed to do this kind of processing, which should be
deferred to some other helper process.

Salvatore

[1] https://bugs.launchpad.net/vmware-nsx/+bug/1420278

On 8 May 2015 at 09:43, Kevin Benton  wrote:

> I'm not sure I understand the behavior you are seeing. When your mechanism
> driver gets initialized and kicks off processing, all of that should be
> happening in the parent PID. I don't know why your child processes start
> executing code that wasn't invoked. Can you provide a pointer to the code
> or give a sample that reproduces the issue?
>
> I modified the linuxbridge mech driver to try to reproduce it:
> http://paste.openstack.org/show/216859/
>
> In the output, I never received any of the init code output I added more
> than once, including the function spawned using eventlet.
>
> The only time I ever saw anything executed by a child process was actual
> API requests (e.g. the create_port method).
>
>
> On Thu, May 7, 2015 at 6:08 AM, Neil Jerram 
> wrote:
>
>> Is there a design for how ML2 mechanism drivers are supposed to cope with
>> the Neutron server forking?
>>
>> What I'm currently seeing, with api_workers = 2, is:
>>
>> - my mechanism driver gets instantiated and initialized, and immediately
>> kicks off some processing that involves communicating over the network
>>
>> - the Neutron server process then forks into multiple copies
>>
>> - multiple copies of my driver's network processing then continue, and
>> interfere badly with each other :-)
>>
>> I think what I should do is:
>>
>> - wait until any forking has happened
>>
>> - then decide (somehow) which mechanism driver is going to kick off that
>> processing, and do that.
>>
>> But how can a mechanism driver know when the Neutron server forking has
>> happened?
>>
>> Thanks,
>> Neil
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Kevin Benton
>
> __
> 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][api] Extensions out, Micro-versions in

2015-05-06 Thread Salvatore Orlando

Thanks Bob.

Two answers/comments below.

On 6 May 2015 at 14:59, Bob Melander (bmelande)  wrote:

>  Hi Salvatore,
>
>  Two questions/remarks below.
>
>   From: Salvatore Orlando 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: onsdag 6 maj 2015 00:13
> To: OpenStack Development Mailing List 
> Subject: [openstack-dev] [neutron][api] Extensions out, Micro-versions in
>
>   #5 Plugin/Vendor specific APIs
>
>  Neutron is without doubt the project with the highest number of 3rd
> party (OSS and commercial) integration. After all it was mostly vendors who
> started this project.
> Vendors [4] use the extension mechanism to expose features in their
> products not covered by the Neutron API or to provide some sort of
> value-added service.
> The current proposal still allows 3rd parties to attach extensions to the
> neutron API, provided that:
> - they're not considered part of the Neutron API, in terms of versioning,
> documentation, and client support
>
>  BOB> There are today vendor specific commands in the Neutron CLI client.
> Such commands are prepended with the name of the vendor, like
> cisco_ and nec_.
> I think that makes it quite visible to the user that the command is
> specific to a vendor feature and not part of neutron core. Would it be
> possible to allow for that also going forward? I would think that from a
> user perspective it can be convenient to be able to access vendor add-on
> features using a single CLI client.
>

In a nutshell no, but maybe.
Vendor extensions are not part of the Neutron API, but if the community
decides to support them in the official client anyway, you will still be
able to run vendor-specific CLI commands. Otherwise vendors will have to
provide their own client tools, which is feasible as well.
Personally, I would be against having vendor-specific CLI commands in
python-neutronclient. To me it will be tantamount to saying: yes please do
versioning, but don't take extensions away from us.
However the developer, user, and operator community might have a different
opinion, and as usual the decision will derive from community consensus.

>
>- they do not redefine resources defined by the Neutron API.
>
>  BOB> Does “redefine" here include extending a resource with additional
> attributes?
>

In my opinion yes. But I do not have a very strong point here. Also,
enforcing this will require many vendors to do backward incompatible
changes in the API, and therefore we would need a deprecation cycle. So
let's say that ideally modifying the shape of neutron resource by adding
attributes, might be considered a "discouraged, but not forbidden"
practice. For instance if you want to attach a qos profile to a port rather
then adding a 'vendor_qos_profile' to the port resource you might add a
vendor_port_info resource with a reference to the vendor_qos_profile_id and
the neutron port_id.

>- they do not live in the neutron source tree
> The aim of the provisions above is to minimize the impact of such
> extensions on API portability.
>
>  Thanks for reading and thanks in advance for your feedback,
>  Salvatore
>
>  The title of this post has been inspired by [2]  (the message in the
> banner may be unintelligible to readers not fluent in european football)
>
>  [1] https://review.openstack.org/#/c/136760/
> [2]
> http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc
> [3]
> http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
> [4] By "vendor" here we refer either to a cloud provider or a company
> providing Neutron integration for their products.
>
> __
> 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][api] Extensions out, Micro-versions in

Thanks Kevin,

answers inline.

On 6 May 2015 at 00:28, Fox, Kevin M  wrote:

>  so... as an operator looking at #3, If I need to support lbaas, I'm
> getting pushed to run more and more services, like octavia, plus a
> neutron-lbaas service, plus neutron? This seems like an operator
> scalability issue... What benifit does splitting out the advanced services
> into their own services have?
>

You have a valid point here. In the past I was keen on insisting that
neutron was supposed to be a management layer only service for most
networking services.
However, the consensus seems to move toward a microservices-style
architecture. It would be interesting to get some feedback regarding the
additional operational burden of managing a plethora of services, even if
it is worth noting that when one deploys neutron with its reference
architecture there are already plenty of moving parts.

Regardless, I need to slaps your hand because this discussion is not really
pertinent to this thread, which is specifically about having a strategy for
the Neutron API.
I would be happy to have a separate thread for defining a strategy for
neutron services. I'm pretty sure Doug will be more than happy to slap your
hands too.


> Thanks,
> Kevin
>  ------
> *From:* Salvatore Orlando [sorla...@nicira.com]
> *Sent:* Tuesday, May 05, 2015 3:13 PM
> *To:* OpenStack Development Mailing List
> *Subject:* [openstack-dev] [neutron][api] Extensions out, Micro-versions
> in
>
>   There have now been a few iterations on the specification for Neutron
> micro-versioning [1].
> It seems that no-one in the community opposes introducing versioning. In
> particular API micro-versioning as implemented by Nova and Ironic seems a
> decent way to evolve the API incrementally.
>
>  What the developer community seems not yet convinced about is moving
> away from extensions. It seems everybody realises the flaws of evolving the
> API through extensions, but there are understandable concerns regarding
> impact on plugins/drivers as well as the ability to differentiate, which is
> something quite dear to several neutron teams. I tried to consider all
> those concerns and feedback received; hopefully everything has been
> captured in a satisfactory way in the latest revision of [1].
> With this ML post I also seek feedback from the API-wg concerning the
> current proposal, whose salient points can be summarised as follows:
>
>  #1 extensions are not part anymore of the neutron API.
>
>  Evolution of the API will now be handled through versioning. Once
> microversions are introduced:
>- current extensions will be progressively moved into the Neutron
> "unified" API
>- no more extension will be accepted as part of the Neutron API
>
>  #2 Introduction of "features" for addressing diversity in Neutron plugins
>
>  It is possible that the combination of neutron plugins chosen by the
> operator won't be able to support the whole Neutron API. For this reason a
> concept of "feature" is included. What features are provided depends on the
> plugins loaded. The list of features is hardcoded as strictly dependent on
> the Neutron API version implemented by the server. The specification also
> mandates a minimum set of features every neutron deployment must provide
> (those would be the minimum set of features needed for integrating Neutron
> with Nova).
>
>  #3 Advanced services are still extensions
>
>  This a temporary measure, as APIs for load balancing, VPN, and Edge
> Firewall are still served through neutron WSGI. As in the future this API
> will live independently it does not make sense to version them with Neutron
> APIs.
>
>  #4 Experimenting in the API
>
>  One thing that has plagued Neutron in the past is the impossibility of
> getting people to reach any sort of agreement over the shape of certain
> APIs. With the proposed plan we encourage developers to submit experimental
> APIs. Experimental APIs are unversioned and no guarantee is made regarding
> deprecation or backward compatibility. Also they're optional, as a deployer
> can turn them off. While there are caveats, like forever-experimental APIs,
> this will enable developer to address user feedback during the APIs'
> experimental phase. The Neutron community and the API-wg can provide plenty
> of useful feeback, but ultimately is user feedback which determines whether
> an API proved successful or not. Please note that the current proposal goes
> in a direction different from that approved in Nova when it comes to
> experimental APIs [3]
>
>  #5 Plugin/Vendor specific APIs
>
>  Neutron is without doubt the project with the highest number of 3rd
> party (OSS and commercial) integrati

Re: [openstack-dev] [neutron] How should edge services APIs integrate into Neutron?

I think Paul is correctly scoping this discussion in terms of APIs and
management layer.
For instance, it is true that dynamic routing support, and BGP support
might be a prerequisite for BGP VPNs, but it should be possible to have at
least an idea of how user and admin APIs for this VPN use case should look
like.

In particular the discussion on service chaining is a bit out of scope
here. I'd just note that [1] seems to have a lot of overlap with
group-based-policies [2], and that it appears to be a service that consumes
Neutron rather than an extension to it.

The current VPN service was conceived to be fairly generic. IPSEC VPN is
the only implemented one, but SSL VPN and BGP VPN were on the map as far as
I recall.
Personally having a lot of different VPN APIs is not ideal for users. As a
user, I probably don't even care about configuring a VPN. What is important
for me is to get L2 or L3 access to a network in the cloud; therefore I
would seek for common abstractions that might allow a user for configuring
a VPN service using the same APIs. Obviously then there will be parameters
which will be specific for the particular class of VPN being created.

I listened to several contributors in the area in the past, and there are
plenty of opinions across a spectrum which goes from total abstraction
(just expose "edges" at the API layer) to what could be tantamount to a
RESTful configuration of a VPN appliance. I am not in a position such to
prescribe what direction the community should take; so, for instance, if
the people working on XXX VPN believe the best way forward for them is to
start a new project, so be it.

The other approach would obviously to build onto the current APIs. The only
way the Neutron API layer provides to do that is to extend and extension.
This sounds terrible, and it is indeed terrible. There is a proposal for
moving toward versioned APIs [3], but until that proposal is approved and
implemented extensions are the only thing we have.
>From an API perspective the mechanism would be simpler:
1 - declare the extension, and implement get_required_extension to put
'vpnaas' as a requirement
2 - implement a DB mixin for it providing basic CRUD operations
3 - add it to the VPN service plugin and add its alias to
'supported_extensions_aliases' (step 2 and 3 can be merged if you wish not
to have a mixin)

What might be a bit more challenging is defining how this reflects onto
VPN. Ideally you would have a driver for every VPN type you support, and
then have a little dispatcher to route the API call to the appropriate
driver according to the VPN type.

Salvatore

[1]
https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining
[2] https://wiki.openstack.org/wiki/GroupBasedPolicy
[3] https://review.openstack.org/#/c/136760

On 6 May 2015 at 07:14, Vikram Choudhary 
wrote:

>  Hi Paul,
>
>
>
> Thanks for starting this mail thread.  We are also eyeing for supporting
> MPBGP in neutron and will like to actively participate in this discussion.
>
> Please let me know about the IRC channels which we will be following for
> this discussion.
>
>
>
> Currently, I am following below BP’s for this work.
>
> https://blueprints.launchpad.net/neutron/+spec/edge-vpn
>
> https://blueprints.launchpad.net/neutron/+spec/bgp-dynamic-routing
>
> https://blueprints.launchpad.net/neutron/+spec/dynamic-routing-framework
>
>
> https://blueprints.launchpad.net/neutron/+spec/prefix-clashing-issue-with-dynamic-routing-protocol
>
>
>
> Moreover, a similar kind of work is being headed by Cathy for defining an
> intent framework which can extended for various use case. Currently it will
> be leveraged for SFC but I feel the same can be used for providing intend
> VPN use case.
>
>
> https://blueprints.launchpad.net/neutron/+spec/intent-based-service-chaining
>
>
>
> Thanks
>
> Vikram
>
>
>
> *From:* Paul Michali [mailto:p...@michali.net]
> *Sent:* 06 May 2015 01:38
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* [openstack-dev] [neutron] How should edge services APIs
> integrate into Neutron?
>
>
>
> There's been talk in VPN land about new services, like BGP VPN and DM VPN.
> I suspect there are similar things in other Advanced Services. I talked to
> Salvatore today, and he suggested starting a ML thread on this...
>
>
>
> Can someone elaborate on how we should integrate these API extensions into
> Neutron, both today, and in the future, assuming the proposal that
> Salvatore has is adopted?
>
>
>
> I could see two cases. The first, and simplest, is when a feature has an
> entirely new API that doesn't leverage off of an existing API.
>
>
>
> The other case would be when the feature's API would dovetail into the
> existing service API. For example, one may use the existing vpn_service API
> to create the service, but then create BGP VPN or DM VPN connections for
> that service, instead of the IPSec connections we have today.
>
>
>
> If there are examples already of how to exte

[openstack-dev] [neutron][api] Extensions out, Micro-versions in

There have now been a few iterations on the specification for Neutron
micro-versioning [1].
It seems that no-one in the community opposes introducing versioning. In
particular API micro-versioning as implemented by Nova and Ironic seems a
decent way to evolve the API incrementally.

What the developer community seems not yet convinced about is moving away
from extensions. It seems everybody realises the flaws of evolving the API
through extensions, but there are understandable concerns regarding impact
on plugins/drivers as well as the ability to differentiate, which is
something quite dear to several neutron teams. I tried to consider all
those concerns and feedback received; hopefully everything has been
captured in a satisfactory way in the latest revision of [1].
With this ML post I also seek feedback from the API-wg concerning the
current proposal, whose salient points can be summarised as follows:

#1 extensions are not part anymore of the neutron API.

Evolution of the API will now be handled through versioning. Once
microversions are introduced:
- current extensions will be progressively moved into the Neutron
"unified" API
- no more extension will be accepted as part of the Neutron API

#2 Introduction of "features" for addressing diversity in Neutron plugins

It is possible that the combination of neutron plugins chosen by the
operator won't be able to support the whole Neutron API. For this reason a
concept of "feature" is included. What features are provided depends on the
plugins loaded. The list of features is hardcoded as strictly dependent on
the Neutron API version implemented by the server. The specification also
mandates a minimum set of features every neutron deployment must provide
(those would be the minimum set of features needed for integrating Neutron
with Nova).

#3 Advanced services are still extensions

This a temporary measure, as APIs for load balancing, VPN, and Edge
Firewall are still served through neutron WSGI. As in the future this API
will live independently it does not make sense to version them with Neutron
APIs.

#4 Experimenting in the API

One thing that has plagued Neutron in the past is the impossibility of
getting people to reach any sort of agreement over the shape of certain
APIs. With the proposed plan we encourage developers to submit experimental
APIs. Experimental APIs are unversioned and no guarantee is made regarding
deprecation or backward compatibility. Also they're optional, as a deployer
can turn them off. While there are caveats, like forever-experimental APIs,
this will enable developer to address user feedback during the APIs'
experimental phase. The Neutron community and the API-wg can provide plenty
of useful feeback, but ultimately is user feedback which determines whether
an API proved successful or not. Please note that the current proposal goes
in a direction different from that approved in Nova when it comes to
experimental APIs [3]

#5 Plugin/Vendor specific APIs

Neutron is without doubt the project with the highest number of 3rd party
(OSS and commercial) integration. After all it was mostly vendors who
started this project.
Vendors [4] use the extension mechanism to expose features in their
products not covered by the Neutron API or to provide some sort of
value-added service.
The current proposal still allows 3rd parties to attach extensions to the
neutron API, provided that:
- they're not considered part of the Neutron API, in terms of versioning,
documentation, and client support
- they do not redefine resources defined by the Neutron API.
- they do not live in the neutron source tree
The aim of the provisions above is to minimize the impact of such
extensions on API portability.

Thanks for reading and thanks in advance for your feedback,
Salvatore

The title of this post has been inspired by [2] (the message in the banner
may be unintelligible to readers not fluent in european football)

[1] https://review.openstack.org/#/c/136760/
[2]
http://a.espncdn.com/combiner/i/?img=/photo/2015/0502/fc-banner-jd-1296x729.jpg&w=738&site=espnfc
[3]
http://specs.openstack.org/openstack/nova-specs/specs/kilo/implemented/api-microversions.html
[4] By "vendor" here we refer either to a cloud provider or a company
providing Neutron integration for their products.
__
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][IPAM] Do we need migrate script for neutron IPAM now?