Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-24 Thread Christopher Yeoh 

Hi Doug,
On Thu, 19 Mar 2015 10:01:54 -0600
Doug Wiegley  wrote:

> Hi Gary,
> 
> First I’m seeing these, but I don’t see that they’re required on
> input, unless I’m mis-reading those reviews.  Additional of new
> output fields to a json object, or adding optional inputs, is not
> generally considered to be backwards incompatible behavior in an API.
> Does OpenStack have a stricter standard on that?

So speaking from a Nova (and more general) API point of view where
we're probably a bit longer along the extensions/microversioning path,
I think even with backwards compatibility it is still an issue. For
example, without some sort of co-operative and strong input validation
are you going to detect when someone sends a new parameter that is
simply mispelled and all the other extensions assume that someone will
look after it and return an appropriate rather than let it just through.

Over time we've found a few examples even in our api request samples
typos (which feeds into the docs) which are not detected just because
of this situation.

Chris

> 
> Thanks,
> doug
> 
> 
> > On Mar 19, 2015, at 6:37 AM, Gary Kotton  wrote:
> > 
> > Hi,
> > Changed the subject so that it may draw a little attention.
> > There were 2 patches approved that kind of break the API (in my
> > humble opinion): https://review.openstack.org/#/c/154921
> > / and
> > https://review.openstack.org/#/c/158420
> > / In both of these two new
> > fields were added to the base attributes – mtu and
> > vlan_transparency Reverts for them are:
> > https://review.openstack.org/165801
> >  (mtu) and
> > https://review.openstack.org/165776
> >  (vlan transparency). In my
> > opinion these should be added as separate extensions. Thanks Gary
> > 
> > From: Gary Kotton mailto:gkot...@vmware.com>>
> > Reply-To: OpenStack List  > > Date: Thursday, March
> > 19, 2015 at 2:32 PM To: OpenStack List
> >  > > Subject: Re:
> > [openstack-dev] [Neutron] VLAN transparency support
> > 
> > Hi,
> > This patch has the same addition too -
> > https://review.openstack.org/#/c/154921
> > /. We should also revert
> > that one. Thanks Gary
> > 
> > From: Gary Kotton mailto:gkot...@vmware.com>>
> > Reply-To: OpenStack List  > > Date: Thursday, March
> > 19, 2015 at 1:14 PM To: OpenStack List
> >  > > Subject:
> > [openstack-dev] [Neutron] VLAN transparency support
> > 
> > Hi,
> > It appears that https://review.openstack.org/#/c/158420
> > / update the base
> > attributes for the networks. Is there any reason why this was not
> > added as a separate extension like all others. I do not think that
> > this is the correct way to go and we should do this as all other
> > extensions have been maintained. I have posted a revert
> > (https://review.openstack.org/#/c/165776
> > /) – please feel free to
> > knack if it is invalid. Thanks Gary
> > __
> > 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] Neutron extenstions

2015-03-22 Thread Gary Kotton 
Hi,
Regarding setting the MTU on the API level: this was my bad. This is a read 
only value. The MTU is learnt from the plugin.
Thanks
Gary

From: Salvatore Orlando mailto:sorla...@nicira.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Saturday, March 21, 2015 at 12:49 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

It's good to have trackers for "cleaning up" the implementation of these 
features. I hope we might be able soon to provide more details concerning what 
cleaning up activities should happen here.

Core vs extension is often incorrectly misunderstood for "essential" vs 
"optional". I believe this classification is wrong, in my opinion. Indeed I 
believe that there will be a lot of people who consider the network entity 
optional (why not just create subnets?), whereas there are a lot of people who 
consider the floating IP concept essential (ever tried to run any sort of app 
on OpenStack clouds without them?).
The API extensions serve two purposes: flexibility and evolution of the API. 
While they've been successful at the former (even too much), they've been a bit 
of failure at the latter. This is why, as Akihiro suggested, we would like to 
move away from extensions as a mechanisms for evolving the API, through a 
process which starts with condensing a lot of them into a "super-core" or 
"unified API".
On the other hand, it is also important to note that this plan has not been 
approved anywhere, so reviewers, in theory should stick to the "everything is 
an extension" model.

Now everything I wrote in the last paragraphs is of little to no importance in 
the present situation.
I think the answers we want are:
1) Does it make sense to present these attributes to *all* users?
2) If the answer to #1 is yes, what should be the correct behaviour for plugins 
which are unable to understand these new attributes?


I think this is probably a good point to separate the discussion between the 
MTU extension and the vlan_transparent one.

The MTU issue has been a long-standing problem for neutron users. What this 
extension is doing is simply, in my opinion, enabling API control over an 
aspect users were dealing with previously through custom made scripts.
It solves a fundamental issue, and it seems like it does that in a reasonable 
way. The implementation is also "complete", in the sense that there is a 
component shipped with neutron which supports it - the DHCP agent. It's not 
merely a management layer change that then somehow something will implement.

My personal opinion is that I welcome an appropriate MTU management. Is not 
exposing details of the backend technology as it's the tenant network MTU we 
are talking about.
If a plugin does not support specifically setting the MTU parameter, I would 
raise a 500 NotImplemented error. This will probably create a precedent, but as 
I also stated in the past, I tend to believe this might actually be better than 
the hide & seek game we do with extension.

The vlan_transparent feature serves a specific purpose of a class of 
applications - NFV apps.
The requirement is well understood, and the goal of these feature is to support 
exactly this; It has been speculated during the review process whether this was 
actually a "provider network" attribute. In theory it is something that 
characterises how the network should be implemented in the backend. However it 
was not possible to make this ad "admin" attribute because also non-admins 
might require a vlan_transparent network. Proper RBAC might allow us to expose 
this attribute only to a specific class of users, but Neutron does not yet have 
RBAC [1]

Because of its nature vlan_transparent is an attribute that probably several 
plugins will not be able to understand. Regardless of what the community 
decides regardless extensions vs non-extension, the code as it is implies that 
this flag is present in every request - defaulting to False. This can lead to 
somewhat confusing situation, because users can set it to True, and a get a 200 
response. As a user, I would think that Neutron has prepared for me a nice 
network which is vlan transparent... but if Neutron is running any plugin which 
does not support this extension I would be in a for a huge disappointment when 
I discover my network is not vlan transparent at all!
Users need feedback, and need consistency between the desired state they 
express in the API and the actual state which is implemented in the control 
plane. I think this is something which should be fixed in the "cleanup 
activities".
I reckon that perhaps, as a short term measure, the configuration flag Armando 
mentioned might be used to obscure completely the API attribute if a deployer 
chooses not to support vlan tr

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-20 Thread Ian Wells 
On 20 March 2015 at 15:49, Salvatore Orlando  wrote:

> The MTU issue has been a long-standing problem for neutron users. What
> this extension is doing is simply, in my opinion, enabling API control over
> an aspect users were dealing with previously through custom made scripts.
>

Actually, version 1 is not even doing that; it's simply telling the user
what happened, which the user has never previously been able to tell, and
configuring the network consistently.  I don't think we implemented the
'choose an MTU' API, we're simply telling you the MTU you got.

Since this is frequently smaller than you think (there are some
non-standard features that mean you frequently *can* pass larger packets
than should really work, hiding the problem at the cost of a performance
penalty for doing it) and there was previously no way of getting any idea
of what it is, this is a big step forward.

And to reiterate, because this point is often missed: different networks in
Neutron have different MTUs.  My virtual networks might be 1450.  My
external network might be 1500.  The provider network to my NFS server
might be 9000.  There is *nothing* in today's Neutron that lets you do
anything about that, and - since Neutron routers and Neutron DHCP agents
have no means of dealing with different MTU networks - really strange
things happen if you try some sort of workaround.

If a plugin does not support specifically setting the MTU parameter, I
> would raise a 500 NotImplemented error. This will probably create a
> precedent, but as I also stated in the past, I tend to believe this might
> actually be better than the hide & seek game we do with extension.
>

I am totally happy with this, if we agree it's what we want to do, and it
makes plenty of sense for when you request an MTU.

The other half of the interface is when you don't request a specific MTU
but you'd like to know what MTU you got - the approach we have today is
that if the MTU can't be determined (either a plugin with no support or one
that's short on information) then the value on the network object is
unset.  I assume people are OK with that.


> The vlan_transparent feature serves a specific purpose of a class of
> applications - NFV apps.
>

To be pedantic - the uses for it are few and far between but I wouldn't
reduce it to 'NFV apps'.  http://virl.cisco.com/ I wrote on Openstack a
couple of years ago and it's network simulation but not actually NFV.
People implementing resold services (...aaS) in VMs would quite like VLANs
on their virtual networks too, and this has been discussed in at least 3
summits so far.  I'm sure other people can come up with creative reasons.

It has been speculated during the review process whether this was actually
> a "provider network" attribute.
>

Which it isn't, just for reference.


> In theory it is something that characterises how the network should be
> implemented in the backend.
>
However it was not possible to make this ad "admin" attribute because also
> non-admins might require a vlan_transparent network. Proper RBAC might
> allow us to expose this attribute only to a specific class of users, but
> Neutron does not yet have RBAC [1]
>

I think it's a little early to worry about restricting the flag.  The
default implementation pretty much returns a constant (and says if that
constant is true when you'd like it to be) - it's implemented as a call for
future expansion.

Because of its nature vlan_transparent is an attribute that probably
> several plugins will not be able to understand.
>

And again backward compatibility is documented, and actually pretty
horrible now I come to reread it, so if we wanted to go with a 500 as above
that's quite reasonable.


> Regardless of what the community decides regardless extensions vs
> non-extension, the code as it is implies that this flag is present in every
> request - defaulting to False.
>

Which is, in fact, not correct (or at least not the way it's supposed to
be, anyway; I need to check the code).

The original idea was that if it's not present in the request then you
can't assume the network you're returned is a VLAN trunk, but you also
can't assume it isn't - as in, it's the same as the current behaviour,
where the plugin does what it does and you get to put up with the results.
The difference is that the plugin now gets to tell you what it's done.


> This can lead to somewhat confusing situation, because users can set it to
> True, and a get a 200 response. As a user, I would think that Neutron has
> prepared for me a nice network which is vlan transparent... but if Neutron
> is running any plugin which does not support this extension I would be in a
> for a huge disappointment when I discover my network is not vlan
> transparent at all!
>

The spec has detail on how the user works this out, as I say.
Unfortunately it's not by return code

I reckon that perhaps, as a short term measure, the configuration flag
> Armando mentioned might be used to obscure completely

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-20 Thread Salvatore Orlando 
It's good to have trackers for "cleaning up" the implementation of these
features. I hope we might be able soon to provide more details concerning
what cleaning up activities should happen here.

Core vs extension is often incorrectly misunderstood for "essential" vs
"optional". I believe this classification is wrong, in my opinion. Indeed I
believe that there will be a lot of people who consider the network entity
optional (why not just create subnets?), whereas there are a lot of people
who consider the floating IP concept essential (ever tried to run any sort
of app on OpenStack clouds without them?).
The API extensions serve two purposes: flexibility and evolution of the
API. While they've been successful at the former (even too much), they've
been a bit of failure at the latter. This is why, as Akihiro suggested, we
would like to move away from extensions as a mechanisms for evolving the
API, through a process which starts with condensing a lot of them into a
"super-core" or "unified API".
On the other hand, it is also important to note that this plan has not been
approved anywhere, so reviewers, in theory should stick to the "everything
is an extension" model.

Now everything I wrote in the last paragraphs is of little to no importance
in the present situation.
I think the answers we want are:
1) Does it make sense to present these attributes to *all* users?
2) If the answer to #1 is yes, what should be the correct behaviour for
plugins which are unable to understand these new attributes?


I think this is probably a good point to separate the discussion between
the MTU extension and the vlan_transparent one.

The MTU issue has been a long-standing problem for neutron users. What this
extension is doing is simply, in my opinion, enabling API control over an
aspect users were dealing with previously through custom made scripts.
It solves a fundamental issue, and it seems like it does that in a
reasonable way. The implementation is also "complete", in the sense that
there is a component shipped with neutron which supports it - the DHCP
agent. It's not merely a management layer change that then somehow
something will implement.

My personal opinion is that I welcome an appropriate MTU management. Is not
exposing details of the backend technology as it's the tenant network MTU
we are talking about.
If a plugin does not support specifically setting the MTU parameter, I
would raise a 500 NotImplemented error. This will probably create a
precedent, but as I also stated in the past, I tend to believe this might
actually be better than the hide & seek game we do with extension.

The vlan_transparent feature serves a specific purpose of a class of
applications - NFV apps.
The requirement is well understood, and the goal of these feature is to
support exactly this; It has been speculated during the review process
whether this was actually a "provider network" attribute. In theory it is
something that characterises how the network should be implemented in the
backend. However it was not possible to make this ad "admin" attribute
because also non-admins might require a vlan_transparent network. Proper
RBAC might allow us to expose this attribute only to a specific class of
users, but Neutron does not yet have RBAC [1]

Because of its nature vlan_transparent is an attribute that probably
several plugins will not be able to understand. Regardless of what the
community decides regardless extensions vs non-extension, the code as it is
implies that this flag is present in every request - defaulting to False.
This can lead to somewhat confusing situation, because users can set it to
True, and a get a 200 response. As a user, I would think that Neutron has
prepared for me a nice network which is vlan transparent... but if Neutron
is running any plugin which does not support this extension I would be in a
for a huge disappointment when I discover my network is not vlan
transparent at all!
Users need feedback, and need consistency between the desired state they
express in the API and the actual state which is implemented in the control
plane. I think this is something which should be fixed in the "cleanup
activities".
I reckon that perhaps, as a short term measure, the configuration flag
Armando mentioned might be used to obscure completely the API attribute if
a deployer chooses not to support vlan transparent networks.
Anyway, since I did not follow the review of the implementation I'll leave
to the authors and reviewers any comment pertaining implementation.

One more thing I do not see is how a transparent VLAN is implemented. Going
back to the spec history it is unclear whether this was at all in the scope
of this spec.
Indeed it seems this feature simply gives a ML2 driver a solution to
specify whether it support transparent networks or not, and then inform the
user in a fairly backend-agnostic way.
Indeed, quoting comment in the spec review [2]:

"there's no change to the implementation of the networking because we

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-20 Thread Armando M. 
In order to track this, and for Kyle's sanity, I have created these two RC1
bugs:

- https://bugs.launchpad.net/neutron/+bug/1434667
- https://bugs.launchpad.net/neutron/+bug/1434671

Please, let's make sure that whatever approach we decide on, the resulting
code fix targets those two bugs.

Thanks,
Armando

On 20 March 2015 at 09:51, Armando M.  wrote:

>
>
> On 19 March 2015 at 23:59, Akihiro Motoki  wrote:
>
>> Forwarding my reply to the other thread too...
>>
>> Multiple threads on the same topic is confusing.
>> Can we use this thread if we continue the discussion?
>> (The title of this thread looks approapriate)
>>
>> 
>> API extension is the only way that users know which features are
>> available unitl we support API microversioning (v2.1 or something).
>> I believe VLAN transparency support should be implemented as an
>> extension, not by changing the core resources attribute directly.
>> Otherwise users (including Horizon) cannot know we field is available or
>> not.
>>
>> Even though VLAN transparency and MTU suppotrs are basic features, it
>> is better to be implemented as an extension.
>> Configuration does not help from API perspective as it is not visible
>> through the API.
>>
>
> I was only suggesting the configuration-based approach because it was
> simpler and it didn't lead to the evil mixin business. Granted it does not
> help from the API perspective, but we can hardly claim good discoverability
> of the API capabilities anyway :)
>
> That said, I'd be ok with moving one or both of these attributes to the
> extension framework. I thought that consensus on having them as core
> resources had been reached at the time the spec proposal.
>
>
>>
>> We are discussing moving away from extension attributes as Armando
>> commented,
>> but I think it is discussed about resources/attributes which are
>> already used well and required.
>> It looks natural to me that new resources/attributes are implemented
>> via an extension.
>> The situation may be changed once we have support of API microversioning.
>> (It is being discussed in the context of Nova API microvesioning in
>> the dev list started by Jay Pipes.)
>>
>> In my understanding, the case of IPv6 two mode is an exception.
>> From the initial design we would like to have fully support of IPv6 in
>> subnet resource,
>> but through the discussion of IPv6 support it turns out some more
>> modes are required,
>> and we decided to change the subnet "core" resource. It is the exception.
>>
>> Thanks,
>> Akihiro
>>
>> 2015-03-20 8:23 GMT+09:00 Armando M. :
>> > Forwarding my reply to the other thread here:
>> >
>> > 
>> >
>> > If my memory does not fail me, changes to the API (new resources, new
>> > resource attributes or new operations allowed to resources) have always
>> been
>> > done according to these criteria:
>> >
>> > an opt-in approach: this means we know the expected behavior of the
>> plugin
>> > as someone has coded the plugin in such a way that the API change is
>> > supported;
>> > an opt-out approach: if the API change does not require explicit backend
>> > support, and hence can be deemed supported by all plugins.
>> > a 'core' extension (ones available in neutron/extensions) should be
>> > implemented at least by the reference implementation;
>> >
>> > Now, there might have been examples in the past where criteria were not
>> met,
>> > but these should be seen as exceptions rather than the rule, and as
>> such,
>> > fixed as defects so that an attribute/resource/operation that is
>> > accidentally exposed to a plugin will either be honored as expected or
>> an
>> > appropriate failure is propagated to the user. Bottom line, the server
>> must
>> > avoid to fail silently, because failing silently is bad for the user.
>> >
>> > Now both features [1] and [2] violated the opt-in criterion above: they
>> > introduced resources attributes in the core models, forcing an
>> undetermined
>> > behavior on plugins.
>> >
>> > I think that keeping [3,4] as is can lead to a poor user experience; IMO
>> > it's unacceptable to let a user specify the attribute, and see that
>> > ultimately the plugin does not support it. I'd be fine if this was an
>> > accident, but doing this by design is a bit evil. So, I'd suggest the
>> > following, in order to keep the features in Kilo:
>> >
>> > Patches [3, 4] did introduce config flags to control the plugin
>> behavior,
>> > but it looks like they were not applied correctly; for instance, the
>> > vlan_transparent case was only applied to ML2. Similarly the MTU config
>> flag
>> > was not processed server side to ensure that plugins that do not support
>> > advertisement do not fail silently. This needs to be rectified.
>> > As for VLAN transparency, we'd need to implement work item 5 (of 6) of
>> spec
>> > [2], as this extension without at least a backend able to let tagged
>> traffic
>> > pass doesn't seem right.
>> > Ensure we sort out the API tests so that we know how the features
>> behave.
>>

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-20 Thread Armando M. 
On 19 March 2015 at 23:59, Akihiro Motoki  wrote:

> Forwarding my reply to the other thread too...
>
> Multiple threads on the same topic is confusing.
> Can we use this thread if we continue the discussion?
> (The title of this thread looks approapriate)
>
> 
> API extension is the only way that users know which features are
> available unitl we support API microversioning (v2.1 or something).
> I believe VLAN transparency support should be implemented as an
> extension, not by changing the core resources attribute directly.
> Otherwise users (including Horizon) cannot know we field is available or
> not.
>
> Even though VLAN transparency and MTU suppotrs are basic features, it
> is better to be implemented as an extension.
> Configuration does not help from API perspective as it is not visible
> through the API.
>

I was only suggesting the configuration-based approach because it was
simpler and it didn't lead to the evil mixin business. Granted it does not
help from the API perspective, but we can hardly claim good discoverability
of the API capabilities anyway :)

That said, I'd be ok with moving one or both of these attributes to the
extension framework. I thought that consensus on having them as core
resources had been reached at the time the spec proposal.


>
> We are discussing moving away from extension attributes as Armando
> commented,
> but I think it is discussed about resources/attributes which are
> already used well and required.
> It looks natural to me that new resources/attributes are implemented
> via an extension.
> The situation may be changed once we have support of API microversioning.
> (It is being discussed in the context of Nova API microvesioning in
> the dev list started by Jay Pipes.)
>
> In my understanding, the case of IPv6 two mode is an exception.
> From the initial design we would like to have fully support of IPv6 in
> subnet resource,
> but through the discussion of IPv6 support it turns out some more
> modes are required,
> and we decided to change the subnet "core" resource. It is the exception.
>
> Thanks,
> Akihiro
>
> 2015-03-20 8:23 GMT+09:00 Armando M. :
> > Forwarding my reply to the other thread here:
> >
> > 
> >
> > If my memory does not fail me, changes to the API (new resources, new
> > resource attributes or new operations allowed to resources) have always
> been
> > done according to these criteria:
> >
> > an opt-in approach: this means we know the expected behavior of the
> plugin
> > as someone has coded the plugin in such a way that the API change is
> > supported;
> > an opt-out approach: if the API change does not require explicit backend
> > support, and hence can be deemed supported by all plugins.
> > a 'core' extension (ones available in neutron/extensions) should be
> > implemented at least by the reference implementation;
> >
> > Now, there might have been examples in the past where criteria were not
> met,
> > but these should be seen as exceptions rather than the rule, and as such,
> > fixed as defects so that an attribute/resource/operation that is
> > accidentally exposed to a plugin will either be honored as expected or an
> > appropriate failure is propagated to the user. Bottom line, the server
> must
> > avoid to fail silently, because failing silently is bad for the user.
> >
> > Now both features [1] and [2] violated the opt-in criterion above: they
> > introduced resources attributes in the core models, forcing an
> undetermined
> > behavior on plugins.
> >
> > I think that keeping [3,4] as is can lead to a poor user experience; IMO
> > it's unacceptable to let a user specify the attribute, and see that
> > ultimately the plugin does not support it. I'd be fine if this was an
> > accident, but doing this by design is a bit evil. So, I'd suggest the
> > following, in order to keep the features in Kilo:
> >
> > Patches [3, 4] did introduce config flags to control the plugin behavior,
> > but it looks like they were not applied correctly; for instance, the
> > vlan_transparent case was only applied to ML2. Similarly the MTU config
> flag
> > was not processed server side to ensure that plugins that do not support
> > advertisement do not fail silently. This needs to be rectified.
> > As for VLAN transparency, we'd need to implement work item 5 (of 6) of
> spec
> > [2], as this extension without at least a backend able to let tagged
> traffic
> > pass doesn't seem right.
> > Ensure we sort out the API tests so that we know how the features behave.
> >
> > Now granted that controlling the API via config flags is not the best
> > solution, as this was always handled through the extension mechanism, but
> > since we've been talking about moving away from extension attributes with
> > [5], it does sound like a reasonable stop-gap solution.
> >
> > Thoughts?
> > Armando
> >
> > [1]
> >
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html
> > [2]
> >
> http://specs.openstack.org/opens

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-20 Thread Ian Wells 
I agree with a lot of your desires, but not your reasoning as to why the
changes are problematic.  Also, your statements about API changes are
pretty reasonable and probably want writing down somewhere so that future
specs are evaluated against them.

Firstly, if we add to the core Neutron interface it's clear that old
plugins have to behave sensibly.  If we add an MTU attribute or a VLAN
attribute and we allow the user to tinker with it (in the case of MTU
that's a future plan, but in the VLAN case that's true now) then there has
to be a backward compatibility plan - we can't have plugins appearing as if
they support the functionality when they actually ignored the request.  The
specs are quite explicit about that and how to make sure it doesn't work
that way, so your criticism about not correctly implementing the opt-in
approach does not apply.  They're not aiming for an opt-in approach but an
opt-out one; they're aiming to add an attribute and ensure that unaware,
unchanged plugins respect the proposed API behaviour.

That being the case, neither the MTU plugin not the VLAN plugin require
support from the driver or plugin to work.  If the current patches do not
implement the model, and in particular if they work as you describe, then
they are indeed broken (not to spec, specifically) and need to be fixed.
The specs are quite clear about what should happen in those cases, and what
you're describing is a bug in the code, not a flaw in the proposed design -
I'll get someone to take a look, but can you file it so that it doesn't get
lost, along with a way to trigger it?

I think that, in these circumstances, the intended behaviour is logical and
in line with what you want to see.  If you are still interested in either
or both of them being extensions rather than core attributes, then that's
fine and something we should discuss further, but I don't think what you've
said here is justification.
-- 
Ian.

On 19 March 2015 at 16:23, Armando M.  wrote:

> Forwarding my reply to the other thread here:
>
> 
>
> If my memory does not fail me, changes to the API (new resources, new
> resource attributes or new operations allowed to resources) have always
> been done according to these criteria:
>
>- an opt-in approach: this means we know the expected behavior of the
>plugin as someone has coded the plugin in such a way that the API change is
>supported;
>- an opt-out approach: if the API change does not require explicit
>backend support, and hence can be deemed supported by all plugins.
>- a 'core' extension (ones available in neutron/extensions) should be
>implemented at least by the reference implementation;
>
> Now, there might have been examples in the past where criteria were not
> met, but these should be seen as exceptions rather than the rule, and as
> such, fixed as defects so that an attribute/resource/operation that is
> accidentally exposed to a plugin will either be honored as expected or an
> appropriate failure is propagated to the user. Bottom line, the server must
> avoid to fail silently, because failing silently is bad for the user.
>
> Now both features [1] and [2] violated the opt-in criterion above: they
> introduced resources attributes in the core models, forcing an undetermined
> behavior on plugins.
>
> I think that keeping [3,4] as is can lead to a poor user experience; IMO
> it's unacceptable to let a user specify the attribute, and see that
> ultimately the plugin does not support it. I'd be fine if this was an
> accident, but doing this by design is a bit evil. So, I'd suggest the
> following, in order to keep the features in Kilo:
>
>- Patches [3, 4] did introduce config flags to control the plugin
>behavior, but it looks like they were not applied correctly; for instance,
>the vlan_transparent case was only applied to ML2. Similarly the MTU config
>flag was not processed server side to ensure that plugins that do not
>support advertisement do not fail silently. This needs to be rectified.
>- As for VLAN transparency, we'd need to implement work item 5 (of 6)
>of spec [2], as this extension without at least a backend able to let
>tagged traffic pass doesn't seem right.
>- Ensure we sort out the API tests so that we know how the features
>behave.
>
> Now granted that controlling the API via config flags is not the best
> solution, as this was always handled through the extension mechanism, but
> since we've been talking about moving away from extension attributes with
> [5], it does sound like a reasonable stop-gap solution.
>
> Thoughts?
> Armando
>
> [1]
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html
> [3]
> https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z
> [4]
> https://review.openstack.org/#/q/project

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-20 Thread Rob Pothier (rpothier) 

The MTU values are derived from the config values only.
If the tenant tries to set the MTU directly, that is rejected.

Rob

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 3:01 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

With regards to the MTU can you please point me to where we validate that the 
MTU defined by the tenant is actually <= the supported MTU on the network. I 
did not see this in the code (maybe I missed something).


From: Ian Wells mailto:ijw.ubu...@cack.org.uk>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 8:44 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Per the other discussion on attributes, I believe the change walks in 
historical footsteps and it's a matter of project policy choice.  That aside, 
you raised a couple of other issues on IRC:

- backward compatibility with plugins that haven't adapted their API - this is 
addressed in the spec, which should have been implemented in the patches 
(otherwise I will downvote the patch myself) - behaviour should be as before 
with the additional feature that you can now tell more about what the plugin is 
thinking
- whether they should be core or an extension - this is a more personal 
opinion, but on the grounds that all networks are either trunks or not, and all 
networks have MTUs, I think they do want to be core.  I would like to see 
plugin developers strongly encouraged to consider what they can do on both 
elements, whereas an extension tends to sideline functionality from view so 
that plugin writers don't even know it's there for consideration.

Aside from that, I'd like to emphasise the value of these patches, so hopefully 
we can find a way to get them in in some form in this cycle.  I admit I'm 
interested in them because they make it easier to do NFV.  But they also help 
normal cloud users and operators, who otherwise have to do some really strange 
things [1].  I think it's maybe a little unfair to post reversion patches 
before discussion, particularly when the patch works, passes tests and 
implements an approved spec correctly.
--
Ian.
[1] 
https://bugzilla.redhat.com/show_bug.cgi?id=1138958
 (admittedly first link I found, but there's no shortage of them)

On 19 March 2015 at 05:32, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:
Hi,
This patch has the same addition too - 
https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base 
attributes for the networks. Is there any reason why this was not added as a 
separate extension like all others.
I do not think that this is the correct way to go and we should do this as all 
other extensions have been maintained. I have posted a revert 
(https://review.openstack.org/#/c/165776/) – please feel free to knack if it is 
invalid.
Thanks
Gary

__
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] Neutron extenstions

2015-03-20 Thread Akihiro Motoki 
Forwarding my reply to the other thread too...

Multiple threads on the same topic is confusing.
Can we use this thread if we continue the discussion?
(The title of this thread looks approapriate)


API extension is the only way that users know which features are
available unitl we support API microversioning (v2.1 or something).
I believe VLAN transparency support should be implemented as an
extension, not by changing the core resources attribute directly.
Otherwise users (including Horizon) cannot know we field is available or not.

Even though VLAN transparency and MTU suppotrs are basic features, it
is better to be implemented as an extension.
Configuration does not help from API perspective as it is not visible
through the API.

We are discussing moving away from extension attributes as Armando commented,
but I think it is discussed about resources/attributes which are
already used well and required.
It looks natural to me that new resources/attributes are implemented
via an extension.
The situation may be changed once we have support of API microversioning.
(It is being discussed in the context of Nova API microvesioning in
the dev list started by Jay Pipes.)

In my understanding, the case of IPv6 two mode is an exception.
>From the initial design we would like to have fully support of IPv6 in
subnet resource,
but through the discussion of IPv6 support it turns out some more
modes are required,
and we decided to change the subnet "core" resource. It is the exception.

Thanks,
Akihiro

2015-03-20 8:23 GMT+09:00 Armando M. :
> Forwarding my reply to the other thread here:
>
> 
>
> If my memory does not fail me, changes to the API (new resources, new
> resource attributes or new operations allowed to resources) have always been
> done according to these criteria:
>
> an opt-in approach: this means we know the expected behavior of the plugin
> as someone has coded the plugin in such a way that the API change is
> supported;
> an opt-out approach: if the API change does not require explicit backend
> support, and hence can be deemed supported by all plugins.
> a 'core' extension (ones available in neutron/extensions) should be
> implemented at least by the reference implementation;
>
> Now, there might have been examples in the past where criteria were not met,
> but these should be seen as exceptions rather than the rule, and as such,
> fixed as defects so that an attribute/resource/operation that is
> accidentally exposed to a plugin will either be honored as expected or an
> appropriate failure is propagated to the user. Bottom line, the server must
> avoid to fail silently, because failing silently is bad for the user.
>
> Now both features [1] and [2] violated the opt-in criterion above: they
> introduced resources attributes in the core models, forcing an undetermined
> behavior on plugins.
>
> I think that keeping [3,4] as is can lead to a poor user experience; IMO
> it's unacceptable to let a user specify the attribute, and see that
> ultimately the plugin does not support it. I'd be fine if this was an
> accident, but doing this by design is a bit evil. So, I'd suggest the
> following, in order to keep the features in Kilo:
>
> Patches [3, 4] did introduce config flags to control the plugin behavior,
> but it looks like they were not applied correctly; for instance, the
> vlan_transparent case was only applied to ML2. Similarly the MTU config flag
> was not processed server side to ensure that plugins that do not support
> advertisement do not fail silently. This needs to be rectified.
> As for VLAN transparency, we'd need to implement work item 5 (of 6) of spec
> [2], as this extension without at least a backend able to let tagged traffic
> pass doesn't seem right.
> Ensure we sort out the API tests so that we know how the features behave.
>
> Now granted that controlling the API via config flags is not the best
> solution, as this was always handled through the extension mechanism, but
> since we've been talking about moving away from extension attributes with
> [5], it does sound like a reasonable stop-gap solution.
>
> Thoughts?
> Armando
>
> [1]
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html
> [2]
> http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html
> [3]
> https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z
> [4]
> https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z
> [5] https://review.openstack.org/#/c/136760/
>
> On 19 March 2015 at 14:56, Ian Wells  wrote:
>>
>> On 19 March 2015 at 11:44, Gary Kotton  wrote:
>>>
>>> Hi,
>>> Just the fact that we did this does not make it right. But I guess that
>>> we
>>> are starting to bend the rules. I think that we really need to be far
>>> more
>>> diligent about this kind of stuff. Having said that we decided the
>>> following on IRC:
>>> 1.

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-19 Thread Armando M. 
Forwarding my reply to the other thread here:



If my memory does not fail me, changes to the API (new resources, new
resource attributes or new operations allowed to resources) have always
been done according to these criteria:

   - an opt-in approach: this means we know the expected behavior of the
   plugin as someone has coded the plugin in such a way that the API change is
   supported;
   - an opt-out approach: if the API change does not require explicit
   backend support, and hence can be deemed supported by all plugins.
   - a 'core' extension (ones available in neutron/extensions) should be
   implemented at least by the reference implementation;

Now, there might have been examples in the past where criteria were not
met, but these should be seen as exceptions rather than the rule, and as
such, fixed as defects so that an attribute/resource/operation that is
accidentally exposed to a plugin will either be honored as expected or an
appropriate failure is propagated to the user. Bottom line, the server must
avoid to fail silently, because failing silently is bad for the user.

Now both features [1] and [2] violated the opt-in criterion above: they
introduced resources attributes in the core models, forcing an undetermined
behavior on plugins.

I think that keeping [3,4] as is can lead to a poor user experience; IMO
it's unacceptable to let a user specify the attribute, and see that
ultimately the plugin does not support it. I'd be fine if this was an
accident, but doing this by design is a bit evil. So, I'd suggest the
following, in order to keep the features in Kilo:

   - Patches [3, 4] did introduce config flags to control the plugin
   behavior, but it looks like they were not applied correctly; for instance,
   the vlan_transparent case was only applied to ML2. Similarly the MTU config
   flag was not processed server side to ensure that plugins that do not
   support advertisement do not fail silently. This needs to be rectified.
   - As for VLAN transparency, we'd need to implement work item 5 (of 6) of
   spec [2], as this extension without at least a backend able to let tagged
   traffic pass doesn't seem right.
   - Ensure we sort out the API tests so that we know how the features
   behave.

Now granted that controlling the API via config flags is not the best
solution, as this was always handled through the extension mechanism, but
since we've been talking about moving away from extension attributes with
[5], it does sound like a reasonable stop-gap solution.

Thoughts?
Armando

[1]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/mtu-selection-and-advertisement.html
[2]
http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html
[3]
https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/mtu-selection-and-advertisement,n,z
[4]
https://review.openstack.org/#/q/project:openstack/neutron+branch:master+topic:bp/nfv-vlan-trunks,n,z
[5] https://review.openstack.org/#/c/136760/

On 19 March 2015 at 14:56, Ian Wells  wrote:

> On 19 March 2015 at 11:44, Gary Kotton  wrote:
>
>> Hi,
>> Just the fact that we did this does not make it right. But I guess that we
>> are starting to bend the rules. I think that we really need to be far more
>> diligent about this kind of stuff. Having said that we decided the
>> following on IRC:
>> 1. Mtu will be left in the core (all plugins should be aware of this and
>> treat it if necessary)
>> 2. Vlan-transparency will be moved to an extension. Pritesh is working on
>> this.
>>
>
> The spec started out as an extension, and in its public review people
> requested that it not be an extension and that it should instead be core.
> I accept that we can change our minds, but I believe there should be a good
> reason for doing so.  You haven't given that reason here and you haven't
> even said who the 'we' is that decided this.  Also, as the spec author, I
> had a conversation with you all but there was no decision at the end of it
> (I presume that came afterward) and I feel that I have a reasonable right
> to be involved.  Could you at least summarise your reasoning here?
>
> I admit that I prefer this to be in core, but I'm not terribly choosy and
> that's not why I'm asking.  I'm more concerned that this is changing our
> mind at literally the last moment, and in turn wasting a developer's time,
> when there was a perfectly good process to debate this before coding was
> begun, and again when the code was up for review, both of which apparently
> failed.  I'd like to understand how we avoid getting here again in the
> future.  I'd also like to be certain we are not simply reversing a choice
> on a whim.
> --
> Ian.
>
> __
> 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-de

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-19 Thread Ian Wells 
On 19 March 2015 at 11:44, Gary Kotton  wrote:

> Hi,
> Just the fact that we did this does not make it right. But I guess that we
> are starting to bend the rules. I think that we really need to be far more
> diligent about this kind of stuff. Having said that we decided the
> following on IRC:
> 1. Mtu will be left in the core (all plugins should be aware of this and
> treat it if necessary)
> 2. Vlan-transparency will be moved to an extension. Pritesh is working on
> this.
>

The spec started out as an extension, and in its public review people
requested that it not be an extension and that it should instead be core.
I accept that we can change our minds, but I believe there should be a good
reason for doing so.  You haven't given that reason here and you haven't
even said who the 'we' is that decided this.  Also, as the spec author, I
had a conversation with you all but there was no decision at the end of it
(I presume that came afterward) and I feel that I have a reasonable right
to be involved.  Could you at least summarise your reasoning here?

I admit that I prefer this to be in core, but I'm not terribly choosy and
that's not why I'm asking.  I'm more concerned that this is changing our
mind at literally the last moment, and in turn wasting a developer's time,
when there was a perfectly good process to debate this before coding was
begun, and again when the code was up for review, both of which apparently
failed.  I'd like to understand how we avoid getting here again in the
future.  I'd also like to be certain we are not simply reversing a choice
on a whim.
-- 
Ian.
__
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] Neutron extenstions

2015-03-19 Thread Gary Kotton 
Hi,
Just the fact that we did this does not make it right. But I guess that we
are starting to bend the rules. I think that we really need to be far more
diligent about this kind of stuff. Having said that we decided the
following on IRC:
1. Mtu will be left in the core (all plugins should be aware of this and
treat it if necessary)
2. Vlan-transparency will be moved to an extension. Pritesh is working on
this.
Thanks
Gary

On 3/19/15, 8:30 PM, "Sean M. Collins"  wrote:

>On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote:
>> There are precedents for this.  For example, the attributes that
>>currently
>> exist for IPv6 advertisement are very similar:
>
>
>I'll also note that the API changes landed in Icehouse, but the
>implementation missed the Icehouse deadline and was landed in Juno, so
>for a time the attributes were hidden from users.
>
>https://review.openstack.org/#/c/85869/
>-- 
>Sean M. Collins
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-19 Thread Sean M. Collins 
On Thu, Mar 19, 2015 at 11:24:16AM PDT, Ian Wells wrote:
> There are precedents for this.  For example, the attributes that currently
> exist for IPv6 advertisement are very similar:


I'll also note that the API changes landed in Icehouse, but the
implementation missed the Icehouse deadline and was landed in Juno, so
for a time the attributes were hidden from users.

https://review.openstack.org/#/c/85869/
-- 
Sean M. Collins

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

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-19 Thread Ian Wells 
There are precedents for this.  For example, the attributes that currently
exist for IPv6 advertisement are very similar:

- added during the run of a stable Neutron API
- properties added on a Neutron object (MTU and VLAN affect network, but
IPv6 affects subnet - same principle though)
- settable, but with defaults so they're optional
- turn up in output when the subnet information is fetched

With the one caveat (write your code to ignore properties you don't
understand) this seems to address backward compatibility in both the IPv6
and the MTU/VLAN attribute changes - if you completely ignore the attribute
behaviour is enough the way it used to be that your app won't break.

Now, it may be that no-one noticed the ipv6 changes as they went through,
but given the long debate about what the attributes should look like at the
time they did get reasonable attention.  Do we want to change the rules for
future API changes?
-- 
Ian.


On 19 March 2015 at 10:07, Gary Kotton  wrote:

>  Hi,
> Until now all changes to the API’s have been made in separate extensions
> and not in the base. These should actually be on the provider networks
> extension.
> First this code is not supported by any of the plugins other than the ML2
> (I am not sure if this break things – it certain broke the unit tests).
> Secondly these two changes do not have open source reference
> implementations (but that is digressing from the problem).
> I really think that we need to revert these and have the extensions done
> in the standard fasion.
> Thanks
> Gary
>
>
>   From: Brandon Logan 
> Reply-To: OpenStack List 
> Date: Thursday, March 19, 2015 at 6:20 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron] Neutron extenstions
>
>   ​Isn't this argument as to whether those fields should be turned
> off/on, versus just always being on?  Are there any guidelines as to what
> fields are allowed to be added in that base resource attr map?  If ML2
> needs these and other fields, should they just always be on?
>
>
>  Thanks,
>
> Brandon
>  --
> *From:* Doug Wiegley 
> *Sent:* Thursday, March 19, 2015 11:01 AM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] Neutron extenstions
>
>  Hi Gary,
>
>  First I’m seeing these, but I don’t see that they’re required on input,
> unless I’m mis-reading those reviews.  Additional of new output fields to a
> json object, or adding optional inputs, is not generally considered to be
> backwards incompatible behavior in an API. Does OpenStack have a stricter
> standard on that?
>
>  Thanks,
> doug
>
>
>   On Mar 19, 2015, at 6:37 AM, Gary Kotton  wrote:
>
>  Hi,
> Changed the subject so that it may draw a little attention.
> There were 2 patches approved that kind of break the API (in my humble
> opinion):
> https://review.openstack.org/#/c/154921/ and
> https://review.openstack.org/#/c/158420/
> In both of these two new fields were added to the base attributes – mtu
> and vlan_transparency
> Reverts for them are:
> https://review.openstack.org/165801 (mtu) and
> https://review.openstack.org/165776 (vlan transparency).
> In my opinion these should be added as separate extensions.
> Thanks
> Gary
>
>   From: Gary Kotton 
> Reply-To: OpenStack List 
> Date: Thursday, March 19, 2015 at 2:32 PM
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron] VLAN transparency support
>
>   Hi,
> This patch has the same addition too -
> https://review.openstack.org/#/c/154921/. We should also revert that one.
> Thanks
> Gary
>
>   From: Gary Kotton 
> Reply-To: OpenStack List 
> Date: Thursday, March 19, 2015 at 1:14 PM
> To: OpenStack List 
> Subject: [openstack-dev] [Neutron] VLAN transparency support
>
>   Hi,
> It appears that https://review.openstack.org/#/c/158420/ update the base
> attributes for the networks. Is there any reason why this was not added as
> a separate extension like all others.
> I do not think that this is the correct way to go and we should do this as
> all other extensions have been maintained. I have posted a revert (
> https://review.openstack.org/#/c/165776/) – please feel free to knack if
> it is invalid.
> Thanks
> Gary
>
> __
> 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)
> Unsubscr

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-19 Thread Gary Kotton 
Hi,
Until now all changes to the API’s have been made in separate extensions and 
not in the base. These should actually be on the provider networks extension.
First this code is not supported by any of the plugins other than the ML2 (I am 
not sure if this break things – it certain broke the unit tests). Secondly 
these two changes do not have open source reference implementations (but that 
is digressing from the problem).
I really think that we need to revert these and have the extensions done in the 
standard fasion.
Thanks
Gary


From: Brandon Logan 
mailto:brandon.lo...@rackspace.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 6:20 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions


​Isn't this argument as to whether those fields should be turned off/on, versus 
just always being on?  Are there any guidelines as to what fields are allowed 
to be added in that base resource attr map?  If ML2 needs these and other 
fields, should they just always be on?


Thanks,

Brandon


From: Doug Wiegley 
mailto:doug...@parksidesoftware.com>>
Sent: Thursday, March 19, 2015 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary,

First I’m seeing these, but I don’t see that they’re required on input, unless 
I’m mis-reading those reviews.  Additional of new output fields to a json 
object, or adding optional inputs, is not generally considered to be backwards 
incompatible behavior in an API. Does OpenStack have a stricter standard on 
that?

Thanks,
doug


On Mar 19, 2015, at 6:37 AM, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and 
https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes – mtu and 
vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and 
https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - 
https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base 
attributes for the networks. Is there any reason why this was not added as a 
separate extension like all others.
I do not think that this is the correct way to go and we should do this as all 
other extensions have been maintained. I have posted a revert 
(https://review.openstack.org/#/c/165776/) – please feel free to knack if it is 
invalid.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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] Neutron extenstions

2015-03-19 Thread Brandon Logan 
?Isn't this argument as to whether those fields should be turned off/on, versus 
just always being on?  Are there any guidelines as to what fields are allowed 
to be added in that base resource attr map?  If ML2 needs these and other 
fields, should they just always be on?


Thanks,

Brandon


From: Doug Wiegley 
Sent: Thursday, March 19, 2015 11:01 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Neutron extenstions

Hi Gary,

First I'm seeing these, but I don't see that they're required on input, unless 
I'm mis-reading those reviews.  Additional of new output fields to a json 
object, or adding optional inputs, is not generally considered to be backwards 
incompatible behavior in an API. Does OpenStack have a stricter standard on 
that?

Thanks,
doug


On Mar 19, 2015, at 6:37 AM, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:

Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and 
https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes - mtu and 
vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and 
https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - 
https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base 
attributes for the networks. Is there any reason why this was not added as a 
separate extension like all others.
I do not think that this is the correct way to go and we should do this as all 
other extensions have been maintained. I have posted a revert 
(https://review.openstack.org/#/c/165776/) - please feel free to knack if it is 
invalid.
Thanks
Gary
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org<mailto: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] Neutron extenstions

2015-03-19 Thread Doug Wiegley 
Hi Gary,

First I’m seeing these, but I don’t see that they’re required on input, unless 
I’m mis-reading those reviews.  Additional of new output fields to a json 
object, or adding optional inputs, is not generally considered to be backwards 
incompatible behavior in an API. Does OpenStack have a stricter standard on 
that?

Thanks,
doug


> On Mar 19, 2015, at 6:37 AM, Gary Kotton  wrote:
> 
> Hi,
> Changed the subject so that it may draw a little attention.
> There were 2 patches approved that kind of break the API (in my humble 
> opinion):
> https://review.openstack.org/#/c/154921 
> / and 
> https://review.openstack.org/#/c/158420 
> / 
> In both of these two new fields were added to the base attributes – mtu and 
> vlan_transparency
> Reverts for them are:
> https://review.openstack.org/165801  
> (mtu) and https://review.openstack.org/165776 
>  (vlan transparency).
> In my opinion these should be added as separate extensions.
> Thanks
> Gary
> 
> From: Gary Kotton mailto:gkot...@vmware.com>>
> Reply-To: OpenStack List  >
> Date: Thursday, March 19, 2015 at 2:32 PM
> To: OpenStack List  >
> Subject: Re: [openstack-dev] [Neutron] VLAN transparency support
> 
> Hi,
> This patch has the same addition too - 
> https://review.openstack.org/#/c/154921 
> /. We should also revert that one.
> Thanks
> Gary
> 
> From: Gary Kotton mailto:gkot...@vmware.com>>
> Reply-To: OpenStack List  >
> Date: Thursday, March 19, 2015 at 1:14 PM
> To: OpenStack List  >
> Subject: [openstack-dev] [Neutron] VLAN transparency support
> 
> Hi,
> It appears that https://review.openstack.org/#/c/158420 
> / update the base attributes for the 
> networks. Is there any reason why this was not added as a separate extension 
> like all others.
> I do not think that this is the correct way to go and we should do this as 
> all other extensions have been maintained. I have posted a revert 
> (https://review.openstack.org/#/c/165776 
> /) – please feel free to knack if it 
> is invalid.
> Thanks
> Gary
> __
> 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] Neutron extenstions

2015-03-19 Thread Sean M. Collins 
On Thu, Mar 19, 2015 at 05:37:59AM PDT, Gary Kotton wrote:
> In my opinion these should be added as separate extensions.

The spec that was approved for these patches does list the new attribute as 
being
added to the Network object.

http://specs.openstack.org/openstack/neutron-specs/specs/kilo/nfv-vlan-trunks.html#rest-api-impact

-- 
Sean M. Collins

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

Re: [openstack-dev] [Neutron] Neutron extenstions

2015-03-19 Thread Gary Kotton 
Hi,
Changed the subject so that it may draw a little attention.
There were 2 patches approved that kind of break the API (in my humble opinion):
https://review.openstack.org/#/c/154921/ and 
https://review.openstack.org/#/c/158420/
In both of these two new fields were added to the base attributes - mtu and 
vlan_transparency
Reverts for them are:
https://review.openstack.org/165801 (mtu) and 
https://review.openstack.org/165776 (vlan transparency).
In my opinion these should be added as separate extensions.
Thanks
Gary

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 2:32 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] VLAN transparency support

Hi,
This patch has the same addition too - 
https://review.openstack.org/#/c/154921/. We should also revert that one.
Thanks
Gary

From: Gary Kotton mailto:gkot...@vmware.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, March 19, 2015 at 1:14 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: [openstack-dev] [Neutron] VLAN transparency support

Hi,
It appears that https://review.openstack.org/#/c/158420/ update the base 
attributes for the networks. Is there any reason why this was not added as a 
separate extension like all others.
I do not think that this is the correct way to go and we should do this as all 
other extensions have been maintained. I have posted a revert 
(https://review.openstack.org/#/c/165776/) - please feel free to knack if it is 
invalid.
Thanks
Gary
__
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