Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources
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 it's hard, but that's the value Neutron brings to the table. I think that everyone agrees with you on this point. Including me. The tricky part comes when the speed of neutron adding to the api bottlenecks other things, or when the abstractions just aren’t there yet, because the technology in question isn’t mature enough. Do we provide relief valves, knowing they will be abused as much as help, or do we hold a hard line? These tags are a relief valve. I’m in favor of them, and I’m in favor of holding to the abstraction. It seems there has to be a middle ground. Thanks, doug Just thinking out loud: Probably trying to stem the tie, would it make sense to block api calls outside neutron core/api to grab such tags, with a big warning: if you try to circunvent this, you will harm interoperability of openstack, and your plugin will be blocked in next neutron releases.. They could go directly via SQL, but at least, they'd know they're doing the wrong thing, and risking a plugin ban, if that's a reasonable measure from our side. I don't think it's worth the effort or complexity to work too hard at actively preventing it, but anything that helps make it clear to people that it's considered private data (to anything but the API and DB) would be nice. We should be thinking of the people that are intending to play nice, and make it so they don't accidentally use something we don't intend to be used. That's something we can hash out during code review or follow-up patches. -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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 the table. I think that everyone agrees with you on this point. Including me. The tricky part comes when the speed of neutron adding to the api bottlenecks other things, or when the abstractions just aren’t there yet, because the technology in question isn’t mature enough. Do we provide relief valves, knowing they will be abused as much as help, or do we hold a hard line? These tags are a relief valve. I’m in favor of them, and I’m in favor of holding to the abstraction. It seems there has to be a middle ground. Thanks, doug Just thinking out loud: Probably trying to stem the tie, would it make sense to block api calls outside neutron core/api to grab such tags, with a big warning: if you try to circunvent this, you will harm interoperability of openstack, and your plugin will be blocked in next neutron releases.. They could go directly via SQL, but at least, they'd know they're doing the wrong thing, and risking a plugin ban, if that's a reasonable measure from our side. On Aug 24, 2015, at 4:01 PM, Kevin Bentonblak...@gmail.com wrote: 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 metadata tags were available, they would be the new delivery vehicle of choice since they are much better than monkey-patching. The way to do that is to have it defined explicitly by Neutron and not punt. +1, but the concern was that having these data bags easily available will eliminate a lot of the incentive contributors had to work together to standardize what they were trying to do. 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 that everyone agrees with you on this point. It seems like Doug was just pointing out from the vendor perspective that it's very tempting to slap something together based on what is available, and now we will be providing a tool to make that route even easier. After thinking about it, an out-of-tree driver abusing tags is a much better place for us to be than monkey-patching code. At least with tags it's obvious that it's bolted on metadata rather than entirely different API behavior monkey-patched in. On Mon, Aug 24, 2015 at 2:43 PM, Russell Bryantrbry...@redhat.commailto: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 inch of its life regularly. The alternative is sometimes even worse than a vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. 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. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say. Interop really is a key part of this. If we look at this particular case, yes, I get that there are lots of LB algorithms out there and that it makes sense to expose that choice to users. However, I do think what's best for users is to define and document each of them very explicitly. The end user should know that if they choose algorithm BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The way to do that is to have it defined explicitly by Neutron and not punt. Maybe in practice the Neutron defined set is a subset of what's available overall, and the custom (vendor) ones can be clearly marked as such. In any case, I'm just trying to express what goal I think we should be striving for. In general, the fight in Neutron *has* to be about common definitions of networking primitives that can be potentially
Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources
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 provide if clouds stop using Neutron because it doesn't provide them the appropriate support or better yet start solving these problems in creative ways thats ends up missing the entire point of Neutron. (and then clouds stop using Neutron because they will blame it for the lack of interoperability) I think that this is a good enough middle solution and as Armando suggested in the patch it self, we should work in a separate task towards making the users/developers/operators understand (either with documentation or other methods) that the correct end goal would be to standardize things in the API. Implementing it like nova-tags seems to me like a good way to prevent too much abuse. And as i mentioned in the spec [1], there are important use cases for this feature in the API level that is transparent to the backend implementation (Multi site OpenStack and mixed environments (for example Kuryr)) To be clear, I support the feature as long as it's documented that it's opaque to Neutron backends. My argument is about the general idea of arbitrary pass-through to backends, which you don't seem to be proposing. -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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 or backend-specific features (e.g. tags that control QoS features, security isolation, or other network behaviors). However, there are many use cases that make these nice for the users of the API to help organize resources (e.g. external DNS names on floating IPs, PCI compliance status of security groups, an emoticon describing the seriousness of the things on that network, etc). I'm beginning to think that it might be worth it for the usefulness it brings to the end users. But with all of the third-party plugins out-of-tree, we essentially have no way to stop them from using the tags to control the networking backend as well. So I'm looking for feedback from the API working group as well as other projects that have gone down this path. Should we just take the pythonic we're all adults approach and try to encourage backends not to use them for network behavior? Or does this carry too much risk of being abused as a shortcut to avoid developing proper API enhancements by backend devs? 1. https://bugs.launchpad.net/neutron/+bug/1460222 2. https://bugs.launchpad.net/neutron/+bug/1483480 3. https://review.openstack.org/#/c/216021/ If this is clearly documented as being a API consumer thing only, then I'm OK with it. 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. The plugins may be out of tree, but the ones officially a part of Neutron still are under oversight of the Neutron PTL/team. Using this in a way it's explicitly documented as not to be used would be an example of a case where they should be asked to change. We can't control what backends not a part of Neutron do, but that's not new. One example of another project doing something similar is this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html Note this important line: The tag is an opaque string and is not intended to be interpreted or even read by the virt drivers. -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
+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 Bryant rbry...@redhat.com 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 leverage these tags to leak implementation details or backend-specific features (e.g. tags that control QoS features, security isolation, or other network behaviors). However, there are many use cases that make these nice for the users of the API to help organize resources (e.g. external DNS names on floating IPs, PCI compliance status of security groups, an emoticon describing the seriousness of the things on that network, etc). I'm beginning to think that it might be worth it for the usefulness it brings to the end users. But with all of the third-party plugins out-of-tree, we essentially have no way to stop them from using the tags to control the networking backend as well. So I'm looking for feedback from the API working group as well as other projects that have gone down this path. Should we just take the pythonic we're all adults approach and try to encourage backends not to use them for network behavior? Or does this carry too much risk of being abused as a shortcut to avoid developing proper API enhancements by backend devs? 1. https://bugs.launchpad.net/neutron/+bug/1460222 2. https://bugs.launchpad.net/neutron/+bug/1483480 3. https://review.openstack.org/#/c/216021/ If this is clearly documented as being a API consumer thing only, then I'm OK with it. 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. The plugins may be out of tree, but the ones officially a part of Neutron still are under oversight of the Neutron PTL/team. Using this in a way it's explicitly documented as not to be used would be an example of a case where they should be asked to change. We can't control what backends not a part of Neutron do, but that's not new. One example of another project doing something similar is this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html Note this important line: The tag is an opaque string and is not intended to be interpreted or even read by the virt drivers. -- Russell Bryant __ 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 -- Best Regards , The G. __ 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] - attaching arbitrary key/value pairs to resources
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 leverage these tags to leak implementation details or backend-specific features (e.g. tags that control QoS features, security isolation, or other network behaviors). However, there are many use cases that make these nice for the users of the API to help organize resources (e.g. external DNS names on floating IPs, PCI compliance status of security groups, an emoticon describing the seriousness of the things on that network, etc). I'm beginning to think that it might be worth it for the usefulness it brings to the end users. But with all of the third-party plugins out-of-tree, we essentially have no way to stop them from using the tags to control the networking backend as well. So I'm looking for feedback from the API working group as well as other projects that have gone down this path. Should we just take the pythonic we're all adults approach and try to encourage backends not to use them for network behavior? Or does this carry too much risk of being abused as a shortcut to avoid developing proper API enhancements by backend devs? 1. https://bugs.launchpad.net/neutron/+bug/1460222 2. https://bugs.launchpad.net/neutron/+bug/1483480 3. https://review.openstack.org/#/c/216021/ If this is clearly documented as being a API consumer thing only, then I'm OK with it. 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. The plugins may be out of tree, but the ones officially a part of Neutron still are under oversight of the Neutron PTL/team. Using this in a way it's explicitly documented as not to be used would be an example of a case where they should be asked to change. We can't control what backends not a part of Neutron do, but that's not new. One example of another project doing something similar is this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html Note this important line: The tag is an opaque string and is not intended to be interpreted or even read by the virt drivers. There's an updated version of that nova spec here: http://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/tag-instances.html -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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 extensions list that something non-standard is enabled. Patching code is currently pretty brittle and puts a lot of technical debt on a driver author's part so it's pretty obvious to the author that it's not the right way to go. Once we add these tags, they will be part of the API so they should be stable and will be tempting to use for lots of stuff. :) On Mon, Aug 24, 2015 at 6:35 AM, Russell Bryant rbry...@redhat.com 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 leverage these tags to leak implementation details or backend-specific features (e.g. tags that control QoS features, security isolation, or other network behaviors). However, there are many use cases that make these nice for the users of the API to help organize resources (e.g. external DNS names on floating IPs, PCI compliance status of security groups, an emoticon describing the seriousness of the things on that network, etc). I'm beginning to think that it might be worth it for the usefulness it brings to the end users. But with all of the third-party plugins out-of-tree, we essentially have no way to stop them from using the tags to control the networking backend as well. So I'm looking for feedback from the API working group as well as other projects that have gone down this path. Should we just take the pythonic we're all adults approach and try to encourage backends not to use them for network behavior? Or does this carry too much risk of being abused as a shortcut to avoid developing proper API enhancements by backend devs? 1. https://bugs.launchpad.net/neutron/+bug/1460222 2. https://bugs.launchpad.net/neutron/+bug/1483480 3. https://review.openstack.org/#/c/216021/ If this is clearly documented as being a API consumer thing only, then I'm OK with it. 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. The plugins may be out of tree, but the ones officially a part of Neutron still are under oversight of the Neutron PTL/team. Using this in a way it's explicitly documented as not to be used would be an example of a case where they should be asked to change. We can't control what backends not a part of Neutron do, but that's not new. One example of another project doing something similar is this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html Note this important line: The tag is an opaque string and is not intended to be interpreted or even read by the virt drivers. -- Russell Bryant __ 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
Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources
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 an extension, it's explicit in the API via the extensions list that something non-standard is enabled. Patching code is currently pretty brittle and puts a lot of technical debt on a driver author's part so it's pretty obvious to the author that it's not the right way to go. Once we add these tags, they will be part of the API so they should be stable and will be tempting to use for lots of stuff. :) Totally agreed ... though I'd also argue that vendor API extensions are harmful and shouldn't be allowed going forward, either. -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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 an extension, it's explicit in the API via the extensions list that something non-standard is enabled. Patching code is currently pretty brittle and puts a lot of technical debt on a driver author's part so it's pretty obvious to the author that it's not the right way to go. Once we add these tags, they will be part of the API so they should be stable and will be tempting to use for lots of stuff. :) As Russell mentions, my idea of simple string tagging is that it is entirely user-driven (ala Launchpad's tagging of bugs -- there is no systemic collation or curation of tags). If you need system-defined and protected attributes, you should use a separate resource on the network or port, ala the port binding profile, which to date has been (ab)used for the purpose of communicating backend-specific metadata. Best, -jay On Mon, Aug 24, 2015 at 6:35 AM, Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com 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 leverage these tags to leak implementation details or backend-specific features (e.g. tags that control QoS features, security isolation, or other network behaviors). However, there are many use cases that make these nice for the users of the API to help organize resources (e.g. external DNS names on floating IPs, PCI compliance status of security groups, an emoticon describing the seriousness of the things on that network, etc). I'm beginning to think that it might be worth it for the usefulness it brings to the end users. But with all of the third-party plugins out-of-tree, we essentially have no way to stop them from using the tags to control the networking backend as well. So I'm looking for feedback from the API working group as well as other projects that have gone down this path. Should we just take the pythonic we're all adults approach and try to encourage backends not to use them for network behavior? Or does this carry too much risk of being abused as a shortcut to avoid developing proper API enhancements by backend devs? 1. https://bugs.launchpad.net/neutron/+bug/1460222 2. https://bugs.launchpad.net/neutron/+bug/1483480 3. https://review.openstack.org/#/c/216021/ If this is clearly documented as being a API consumer thing only, then I'm OK with it. 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. The plugins may be out of tree, but the ones officially a part of Neutron still are under oversight of the Neutron PTL/team. Using this in a way it's explicitly documented as not to be used would be an example of a case where they should be asked to change. We can't control what backends not a part of Neutron do, but that's not new. One example of another project doing something similar is this: http://specs.openstack.org/openstack/nova-specs/specs/kilo/approved/tag-instances.html Note this important line: The tag is an opaque string and is not intended to be interpreted or even read by the virt drivers. -- Russell Bryant __ 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
Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources
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 backend-specific features are supposed to be done. With an extension, it's explicit in the API via the extensions list that something non-standard is enabled. Patching code is currently pretty brittle and puts a lot of technical debt on a driver author's part so it's pretty obvious to the author that it's not the right way to go. Once we add these tags, they will be part of the API so they should be stable and will be tempting to use for lots of stuff. :) As Russell mentions, my idea of simple string tagging is that it is entirely user-driven (ala Launchpad's tagging of bugs -- there is no systemic collation or curation of tags). If you need system-defined and protected attributes, you should use a separate resource on the network or port, ala the port binding profile, which to date has been (ab)used for the purpose of communicating backend-specific metadata. Yeah, I think the port binding profile is a good example of something not to repeat. I took advantage of it to prototype a feature here: http://docs.openstack.org/developer/networking-ovn/containers.html It let me implement a backend specific feature quickly and expose it through the Neutron API. It would be very easy to just call it done and move on. However, the right thing to do is to define a proper Neutron API to express what is needed, so that other backends can implement the same thing. Luckily, it's being covered by the following effort and once it's in place, I can remove this prototype hack. http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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 inch of its life regularly. The alternative is sometimes even worse than a vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. 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. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say. Interop really is a key part of this. If we look at this particular case, yes, I get that there are lots of LB algorithms out there and that it makes sense to expose that choice to users. However, I do think what's best for users is to define and document each of them very explicitly. The end user should know that if they choose algorithm BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The way to do that is to have it defined explicitly by Neutron and not punt. Maybe in practice the Neutron defined set is a subset of what's available overall, and the custom (vendor) ones can be clearly marked as such. In any case, I'm just trying to express what goal I think we should be striving for. 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 couldn't have summed it up better than your last paragraph Russell. :) -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say. Thanks, doug On Aug 24, 2015, at 12:26 PM, Russell Bryant rbry...@redhat.com wrote: 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 backend-specific features are supposed to be done. With an extension, it's explicit in the API via the extensions list that something non-standard is enabled. Patching code is currently pretty brittle and puts a lot of technical debt on a driver author's part so it's pretty obvious to the author that it's not the right way to go. Once we add these tags, they will be part of the API so they should be stable and will be tempting to use for lots of stuff. :) As Russell mentions, my idea of simple string tagging is that it is entirely user-driven (ala Launchpad's tagging of bugs -- there is no systemic collation or curation of tags). If you need system-defined and protected attributes, you should use a separate resource on the network or port, ala the port binding profile, which to date has been (ab)used for the purpose of communicating backend-specific metadata. Yeah, I think the port binding profile is a good example of something not to repeat. I took advantage of it to prototype a feature here: http://docs.openstack.org/developer/networking-ovn/containers.html It let me implement a backend specific feature quickly and expose it through the Neutron API. It would be very easy to just call it done and move on. However, the right thing to do is to define a proper Neutron API to express what is needed, so that other backends can implement the same thing. Luckily, it's being covered by the following effort and once it's in place, I can remove this prototype hack. http://specs.openstack.org/openstack/neutron-specs/specs/liberty/vlan-aware-vms.html -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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 vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. 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. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say. Interop really is a key part of this. If we look at this particular case, yes, I get that there are lots of LB algorithms out there and that it makes sense to expose that choice to users. However, I do think what's best for users is to define and document each of them very explicitly. The end user should know that if they choose algorithm BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The way to do that is to have it defined explicitly by Neutron and not punt. Maybe in practice the Neutron defined set is a subset of what's available overall, and the custom (vendor) ones can be clearly marked as such. In any case, I'm just trying to express what goal I think we should be striving for. 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. -- Russell Bryant __ 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] - attaching arbitrary key/value pairs to resources
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 metadata tags were available, they would be the new delivery vehicle of choice since they are much better than monkey-patching. The way to do that is to have it defined explicitly by Neutron and not punt. +1, but the concern was that having these data bags easily available will eliminate a lot of the incentive contributors had to work together to standardize what they were trying to do. 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 that everyone agrees with you on this point. It seems like Doug was just pointing out from the vendor perspective that it's very tempting to slap something together based on what is available, and now we will be providing a tool to make that route even easier. After thinking about it, an out-of-tree driver abusing tags is a much better place for us to be than monkey-patching code. At least with tags it's obvious that it's bolted on metadata rather than entirely different API behavior monkey-patched in. 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 inch of its life regularly. The alternative is sometimes even worse than a vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. 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. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say. Interop really is a key part of this. If we look at this particular case, yes, I get that there are lots of LB algorithms out there and that it makes sense to expose that choice to users. However, I do think what's best for users is to define and document each of them very explicitly. The end user should know that if they choose algorithm BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The way to do that is to have it defined explicitly by Neutron and not punt. Maybe in practice the Neutron defined set is a subset of what's available overall, and the custom (vendor) ones can be clearly marked as such. In any case, I'm just trying to express what goal I think we should be striving for. 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. -- Russell Bryant __ 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
Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources
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 that everyone agrees with you on this point. Including me. The tricky part comes when the speed of neutron adding to the api bottlenecks other things, or when the abstractions just aren’t there yet, because the technology in question isn’t mature enough. Do we provide relief valves, knowing they will be abused as much as help, or do we hold a hard line? These tags are a relief valve. I’m in favor of them, and I’m in favor of holding to the abstraction. It seems there has to be a middle ground. Thanks, doug On Aug 24, 2015, at 4:01 PM, Kevin Benton blak...@gmail.com wrote: 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 metadata tags were available, they would be the new delivery vehicle of choice since they are much better than monkey-patching. The way to do that is to have it defined explicitly by Neutron and not punt. +1, but the concern was that having these data bags easily available will eliminate a lot of the incentive contributors had to work together to standardize what they were trying to do. 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 that everyone agrees with you on this point. It seems like Doug was just pointing out from the vendor perspective that it's very tempting to slap something together based on what is available, and now we will be providing a tool to make that route even easier. After thinking about it, an out-of-tree driver abusing tags is a much better place for us to be than monkey-patching code. At least with tags it's obvious that it's bolted on metadata rather than entirely different API behavior monkey-patched in. On Mon, Aug 24, 2015 at 2:43 PM, Russell Bryant rbry...@redhat.com mailto: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 inch of its life regularly. The alternative is sometimes even worse than a vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. 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. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say. Interop really is a key part of this. If we look at this particular case, yes, I get that there are lots of LB algorithms out there and that it makes sense to expose that choice to users. However, I do think what's best for users is to define and document each of them very explicitly. The end user should know that if they choose algorithm BEST_LB_EVER, that it means the same thing on cloud A vs cloud B. The way to do that is to have it defined explicitly by Neutron and not punt. Maybe in practice the Neutron defined set is a subset of what's available overall, and the custom (vendor) ones can be clearly marked as such. In any case, I'm just trying to express what goal I think we should be striving for. 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. -- Russell Bryant __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources
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 doesn't provide them the appropriate support or better yet start solving these problems in creative ways thats ends up missing the entire point of Neutron. (and then clouds stop using Neutron because they will blame it for the lack of interoperability) I think that this is a good enough middle solution and as Armando suggested in the patch it self, we should work in a separate task towards making the users/developers/operators understand (either with documentation or other methods) that the correct end goal would be to standardize things in the API. Implementing it like nova-tags seems to me like a good way to prevent too much abuse. And as i mentioned in the spec [1], there are important use cases for this feature in the API level that is transparent to the backend implementation (Multi site OpenStack and mixed environments (for example Kuryr)) Thanks, Gal. [1] https://review.openstack.org/#/c/216021/ On Tue, Aug 25, 2015 at 1:19 AM, Doug Wiegley doug...@parksidesoftware.com 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 the table. I think that everyone agrees with you on this point. Including me. The tricky part comes when the speed of neutron adding to the api bottlenecks other things, or when the abstractions just aren’t there yet, because the technology in question isn’t mature enough. Do we provide relief valves, knowing they will be abused as much as help, or do we hold a hard line? These tags are a relief valve. I’m in favor of them, and I’m in favor of holding to the abstraction. It seems there has to be a middle ground. Thanks, doug On Aug 24, 2015, at 4:01 PM, Kevin Benton blak...@gmail.com wrote: 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 metadata tags were available, they would be the new delivery vehicle of choice since they are much better than monkey-patching. The way to do that is to have it defined explicitly by Neutron and not punt. +1, but the concern was that having these data bags easily available will eliminate a lot of the incentive contributors had to work together to standardize what they were trying to do. 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 that everyone agrees with you on this point. It seems like Doug was just pointing out from the vendor perspective that it's very tempting to slap something together based on what is available, and now we will be providing a tool to make that route even easier. After thinking about it, an out-of-tree driver abusing tags is a much better place for us to be than monkey-patching code. At least with tags it's obvious that it's bolted on metadata rather than entirely different API behavior monkey-patched in. 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 inch of its life regularly. The alternative is sometimes even worse than a vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from an interoperability standpoint, but in terms of extending code at the operators choosing, there are MUCH worse sins that are actively being committed. 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. Flavors covers this use case, but in a way that’s up to the operators to setup, and not as easy for devs to deal with. Whether the above sounds like it’s a bonus or a massive reason not to do this will entirely lie in the eye of the beholder, but the vendor extension use case WILL BE USED, no matter what we say.
Re: [openstack-dev] [neutron][api] - attaching arbitrary key/value pairs to resources
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 clear validators (but that raises other concerns). Simplicity in this case will be the winner. +1 for the transparent to the back end. Sent via mobile On Aug 24, 2015, at 22:00, Gal Sagie gal.sa...@gmail.com 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 provide if clouds stop using Neutron because it doesn't provide them the appropriate support or better yet start solving these problems in creative ways thats ends up missing the entire point of Neutron. (and then clouds stop using Neutron because they will blame it for the lack of interoperability) I think that this is a good enough middle solution and as Armando suggested in the patch it self, we should work in a separate task towards making the users/developers/operators understand (either with documentation or other methods) that the correct end goal would be to standardize things in the API. Implementing it like nova-tags seems to me like a good way to prevent too much abuse. And as i mentioned in the spec [1], there are important use cases for this feature in the API level that is transparent to the backend implementation (Multi site OpenStack and mixed environments (for example Kuryr)) Thanks, Gal. [1] https://review.openstack.org/#/c/216021/ On Tue, Aug 25, 2015 at 1:19 AM, Doug Wiegley doug...@parksidesoftware.com 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 the table. I think that everyone agrees with you on this point. Including me. The tricky part comes when the speed of neutron adding to the api bottlenecks other things, or when the abstractions just aren’t there yet, because the technology in question isn’t mature enough. Do we provide relief valves, knowing they will be abused as much as help, or do we hold a hard line? These tags are a relief valve. I’m in favor of them, and I’m in favor of holding to the abstraction. It seems there has to be a middle ground. Thanks, doug On Aug 24, 2015, at 4:01 PM, Kevin Benton blak...@gmail.com wrote: 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 metadata tags were available, they would be the new delivery vehicle of choice since they are much better than monkey-patching. The way to do that is to have it defined explicitly by Neutron and not punt. +1, but the concern was that having these data bags easily available will eliminate a lot of the incentive contributors had to work together to standardize what they were trying to do. 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 that everyone agrees with you on this point. It seems like Doug was just pointing out from the vendor perspective that it's very tempting to slap something together based on what is available, and now we will be providing a tool to make that route even easier. After thinking about it, an out-of-tree driver abusing tags is a much better place for us to be than monkey-patching code. At least with tags it's obvious that it's bolted on metadata rather than entirely different API behavior monkey-patched in. 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 inch of its life regularly. The alternative is sometimes even worse than a vendor extension or plugin. Take for example, wanting to add a new load balancing algorithm, like LEAST_MURDERED_KITTENS. The current list is hard-coded all over the dang place, so you end up shipping neutron patches or monkey patches. Opaque pass-through to the driver is evil from
