Hi Doug,
On Thu, 19 Mar 2015 10:01:54 -0600
Doug Wiegley doug...@parksidesoftware.com 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,
@lists.openstack.org
Date: Saturday, March 21, 2015 at 12:49 AM
To: OpenStack List
openstack-dev@lists.openstack.orgmailto: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
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
On 20 March 2015 at 15:49, Salvatore Orlando sorla...@nicira.com 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.
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 gkot...@vmware.commailto:gkot...@vmware.com
Reply-To: OpenStack Development Mailing List (not for usage questions)
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
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.
On 19 March 2015 at 23:59, Akihiro Motoki amot...@gmail.com 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
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
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
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
be on?
Thanks,
Brandon
--
*From:* Doug Wiegley 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
be on?
Thanks,
Brandon
From: Doug Wiegley
doug...@parksidesoftware.commailto: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
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
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
On 19 March 2015 at 11:44, Gary Kotton gkot...@vmware.com 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
From: Doug Wiegley 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
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
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.
19 matches
Mail list logo
