On 08/25/2015 03:01 AM, Miguel Angel Ajo wrote:
Doug Wiegley wrote:
In general, the fight in Neutron *has* to be about common
definitions of networking primitives that can be potentially
implemented by multiple backends whenever possible. That's the
entire point of Neutron. I get that
Doug Wiegley wrote:
In general, the fight in Neutron *has* to be about common definitions of
networking primitives that can be potentially implemented by multiple backends
whenever possible. That's the entire point of Neutron. I get that it's hard,
but that's the value Neutron brings to
On 08/25/2015 01:00 AM, Gal Sagie wrote:
I agree with Doug and Kevin, i think it is very hard for Neutron to keep
the pace in every area of Networking abstraction, and i prefer
this solution on code patching.
I agree with Russell on the definition of Neutron end goal, but what
good can it
On 08/24/2015 09:25 AM, Kevin Benton wrote:
Hi everybody!
In Neutron the idea of adding tags to resources has come up several
times this cycle alone.[1][2][3]
The general concern that has led to them being rejected is that backends
will leverage these tags to leak implementation details
+1
I will alter the proposed spec to indicate that this shouldn't be
consumed/used with backends specific
data (similar to the way Nova tags indicate it)
I see value (and described some use cases in the spec) for using this from
the API level
Gal.
On Mon, Aug 24, 2015 at 4:35 PM, Russell
Hi everybody!
In Neutron the idea of adding tags to resources has come up several times
this cycle alone.[1][2][3]
The general concern that has led to them being rejected is that backends
will leverage these tags to leak implementation details or backend-specific
features (e.g. tags that control
On 08/24/2015 09:35 AM, Russell Bryant wrote:
On 08/24/2015 09:25 AM, Kevin Benton wrote:
Hi everybody!
In Neutron the idea of adding tags to resources has come up several
times this cycle alone.[1][2][3]
The general concern that has led to them being rejected is that backends
will
Obviously it'll still be possible to be used by a backend, but it's also
possible to patch the code or provide arbitrary API extensions, too.
Right, but vendor API extensions are the way that backend-specific features
are supposed to be done. With an extension, it's explicit in the API via
the
On 08/24/2015 10:33 AM, Kevin Benton wrote:
Obviously it'll still be possible to be used by a backend, but it's
also possible to patch the code or provide arbitrary API extensions, too.
Right, but vendor API extensions are the way that backend-specific
features are supposed to be done. With
On 08/24/2015 07:33 AM, Kevin Benton wrote:
Obviously it'll still be possible to be used by a backend, but it's
also possible to patch the code or provide arbitrary API extensions, too.
Right, but vendor API extensions are the way that backend-specific
features are supposed to be done. With
On 08/24/2015 01:58 PM, Jay Pipes wrote:
On 08/24/2015 07:33 AM, Kevin Benton wrote:
Obviously it'll still be possible to be used by a backend, but it's
also possible to patch the code or provide arbitrary API extensions, too.
Right, but vendor API extensions are the way that
On Mon, Aug 24, 2015 at 2:43 PM, Russell Bryant rbry...@redhat.com wrote:
On 08/24/2015 05:25 PM, Doug Wiegley wrote:
I took advantage of it to prototype a feature her
That right there is the crux of the objections so far. Don’t get me
wrong, I’d love this, and would abuse it within an
I took advantage of it to prototype a feature her
That right there is the crux of the objections so far. Don’t get me wrong, I’d
love this, and would abuse it within an inch of its life regularly.
The alternative is sometimes even worse than a vendor extension or plugin.
Take for example,
On 08/24/2015 05:25 PM, Doug Wiegley wrote:
I took advantage of it to prototype a feature her
That right there is the crux of the objections so far. Don’t get me
wrong, I’d love this, and would abuse it within an inch of its life
regularly.
The alternative is sometimes even worse than a
I don't think even worse code makes this what's proposed here seem any better.
I'm not really sure what you're saying.
I think he's saying that as a vendor he is looking for ways to expose
things that aren't normally available and ends up doing terrible evil
things to achieve it. :) And if the
In general, the fight in Neutron *has* to be about common definitions of
networking primitives that can be potentially implemented by multiple
backends whenever possible. That's the entire point of Neutron. I get that
it's hard, but that's the value Neutron brings to the table.
I think
I agree with Doug and Kevin, i think it is very hard for Neutron to keep
the pace in every area of Networking abstraction, and i prefer
this solution on code patching.
I agree with Russell on the definition of Neutron end goal, but what good
can it provide if clouds stop using Neutron because
it
While I don't think it is a bad idea to allow the arbitrary k/v on resources
just be aware that the content gets a little wonky as you allow users to place
anything they want on resources.
I will also voice support for the tag model. The other option is a way to allow
the extra values to have
18 matches
Mail list logo
