Re: [openstack-dev] [neutron] API models [was: PTL candidacy]
>This is why it should be easy to do. The easier it is, the more Neutron work you'll have time for, in fact. I agree that writing them should be easy. But I don't want to enable operators to just tweak config files to alter APIs. So +1000 to developer productivity. I just don't want it to circumvent sane API reviews. >You have a team of core devs that can examine those proposed APIs - which are in a simple DSL - and decide if they should be added to a repository, which you can look at as an approval step when you decide they're worthy. This sounds good. What I want to ensure is that step of review between the experimentation bit and operators using it bit. >Making it hard to write an API is putting a barrier to entry and experimentation in the way. Making it hard to standardise that API - by, for instance, putting technical requirements on it that it be supportable and maintainable, generally usable and of no impact to people who don't use it - that's far more useful. Agree. >You refer to it as 'configuration defined' but the API description is not a configuration language to be changed on a whim by the end user - it's a DSL, it's code (of a sort), it's a part of the thing you ship. It's configuration defined in the sense that two people using gluon source from different YAML configurations can end up with APIs that are completely different and incompatible. That's problematic from an API user's perspective because "this operator uses gluon" is sort of a useless statement for understanding how to interact with the system. >Again, I agree with this. But again - one way of making standards is to have a documented standard and two independent implementations. We don't see that today because that would be a huge effort. Requiring two implementations is definitely something I don't want to require. I would rather agree upon and accept experimental APIs that only have one implementation than have a vendor do it on their own. It's usually pretty easy to recognize when things are getting too vendor-specific even if you don't have the implementation to test with. On Wed, Jan 25, 2017 at 7:22 PM, Ian Wells wrote: > On 25 January 2017 at 18:07, Kevin Benton wrote: > >> >Setting aside all the above talk about how we might do things for a >> moment: to take one specific feature example, it actually took several >> /years/ to add VLAN-aware ports to OpenStack. This is an example of a >> feature that doesn't affect or interest the vast majority of the user >> community >> >> Now that it has been standardized on, other services can actually use it >> to build things (e.g. Kuryr, Octavia). If each vendor just went and wrote >> up their own extension for this, no project could reliably build anything >> on top of it that would work with multiple backend vendors. >> > > In the weirdest way, I think we're agreeing. The point is that the API > definition is what matters and the API definition is what we have to > agree. That means that we should make it easy to develop the API > definition so that we can standardise it promptly, and it also means that > we would like to have the opportunity to agree that extensions are > 'standard' (versus today - write an extension attribute that works for you, > call the job done). It certainly doesn't remove that standardisation step, > which is why I say that governance, here is key - choosing wisely the > things we agree are standards. > > To draw an IETF parallel for a moment, it's easy to write and implement a > networking protocol - you need no help or permission - and easy to submit a > draft that describes that protocol. It's considerably harder to turn that > draft into an accepted standard. > > >and perhaps we need a governance model around ensuring that they are sane >> and resuable. >> >Gluon, specifically, is about solving exclusively the technical question >> of how to introduce independent APIs >> >> Doesn't that make Gluon support the opposite of having a governance model >> and standardization for APIs? >> > > No. If you want an in-house API then off you go, write your own. If you > want to experiment in code, off you go, experimentation is good. This is > why it should be easy to do. The easier it is, the more Neutron work > you'll have time for, in fact. > > But I can't unilaterally make something standard by saying it is, and > that's where the community can and should get involved. You have a team of > core devs that can examine those proposed APIs - which are in a simple DSL > - and decide if they should be added to a repository, which you can look at > as an approval step when you decide they're worthy. > > Making it hard to write an API is putting a barrier to entry and > experimentation in the way. Making it hard to standardise that API - by, > for instance, putting technical requirements on it that it be supportable > and maintainable, generally usable and of no impact to people who don't use > it - that's far more useful. > > We can't s
Re: [openstack-dev] [neutron] API models [was: PTL candidacy]
On 25 January 2017 at 18:07, Kevin Benton wrote: > >Setting aside all the above talk about how we might do things for a > moment: to take one specific feature example, it actually took several > /years/ to add VLAN-aware ports to OpenStack. This is an example of a > feature that doesn't affect or interest the vast majority of the user > community > > Now that it has been standardized on, other services can actually use it > to build things (e.g. Kuryr, Octavia). If each vendor just went and wrote > up their own extension for this, no project could reliably build anything > on top of it that would work with multiple backend vendors. > In the weirdest way, I think we're agreeing. The point is that the API definition is what matters and the API definition is what we have to agree. That means that we should make it easy to develop the API definition so that we can standardise it promptly, and it also means that we would like to have the opportunity to agree that extensions are 'standard' (versus today - write an extension attribute that works for you, call the job done). It certainly doesn't remove that standardisation step, which is why I say that governance, here is key - choosing wisely the things we agree are standards. To draw an IETF parallel for a moment, it's easy to write and implement a networking protocol - you need no help or permission - and easy to submit a draft that describes that protocol. It's considerably harder to turn that draft into an accepted standard. >and perhaps we need a governance model around ensuring that they are sane > and resuable. > >Gluon, specifically, is about solving exclusively the technical question > of how to introduce independent APIs > > Doesn't that make Gluon support the opposite of having a governance model > and standardization for APIs? > No. If you want an in-house API then off you go, write your own. If you want to experiment in code, off you go, experimentation is good. This is why it should be easy to do. The easier it is, the more Neutron work you'll have time for, in fact. But I can't unilaterally make something standard by saying it is, and that's where the community can and should get involved. You have a team of core devs that can examine those proposed APIs - which are in a simple DSL - and decide if they should be added to a repository, which you can look at as an approval step when you decide they're worthy. Making it hard to write an API is putting a barrier to entry and experimentation in the way. Making it hard to standardise that API - by, for instance, putting technical requirements on it that it be supportable and maintainable, generally usable and of no impact to people who don't use it - that's far more useful. We can't stop people writing bad APIs. What we have in place today doesn't stop that, as made by the Contrail point previously. But that has no relevance to the difficulty of writing APIs, which slows down both good and bad implementations equally. > >I do not care if we make Neutron extensible in some different way to > permit this, if we start a new project or whatever, I just want it to > happen. > > I would like to promote experimentation with APIs with Neutron as well, > but I don't think it's ever going to be as flexible as the > configuration-defined behavior Gluon allows. > You refer to it as 'configuration defined' but the API description is not a configuration language to be changed on a whim by the end user - it's a DSL, it's code (of a sort), it's a part of the thing you ship. > My goal is getting new features that extend beyond one backend and without > some community agreement on new APIs, I don't see how that's possible. > Again, I agree with this. But again - one way of making standards is to have a documented standard and two independent implementations. We don't see that today because that would be a huge effort. -- 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] API models [was: PTL candidacy]
>Obviously this is close to my interests, and I see Kevin's raised Gluon as the bogeyman (which it isn't trying to be). No, I was pointing out that it's not what I want Neutron to become. It's entire purpose is to make defining new APIs as simple as writing YAML (i.e. networking APIs as a service). I suspect there will always be deployments where features need to be redefined at runtime for solving very specific use cases, but I don't want that to be the default model of networking in OpenStack. >Setting aside all the above talk about how we might do things for a moment: to take one specific feature example, it actually took several /years/ to add VLAN-aware ports to OpenStack. This is an example of a feature that doesn't affect or interest the vast majority of the user community Now that it has been standardized on, other services can actually use it to build things (e.g. Kuryr, Octavia). If each vendor just went and wrote up their own extension for this, no project could reliably build anything on top of it that would work with multiple backend vendors. >and perhaps we need a governance model around ensuring that they are sane and resuable. >Gluon, specifically, is about solving exclusively the technical question of how to introduce independent APIs Doesn't that make Gluon support the opposite of having a governance model and standardization for APIs? >I do not care if we make Neutron extensible in some different way to permit this, if we start a new project or whatever, I just want it to happen. I would like to promote experimentation with APIs with Neutron as well, but I don't think it's ever going to be as flexible as the configuration-defined behavior Gluon allows. My goal is getting new features that extend beyond one backend and without some community agreement on new APIs, I don't see how that's possible. On Jan 25, 2017 12:44, "Ian Wells" wrote: I would certainly be interested in dicussing this, though I'm not currently signed up for the PTG. Obviously this is close to my interests, and I see Kevin's raised Gluon as the bogeyman (which it isn't trying to be). Setting aside all the above talk about how we might do things for a moment: to take one specific feature example, it actually took several /years/ to add VLAN-aware ports to OpenStack. This is an example of a feature that doesn't affect or interest the vast majority of the user community, and which is almost certainly not installed in the cloud you're currently working on, and you probably have no intention of ever programming, and which even had cross-vendor support. It's useful and there are times that you can't do without it; there were people ready to write the code. So why was it so very hard? I hope we will all agree on these points: - Neutron's current API of networks, subnets and ports is fine for what it does. We like it, we write apps using it, it doesn't need to change - The backward compatibility and common understanding of Neutron's API is paramount - applications should work everywhere, and should continue to work as Neutron evolves - Some people want to do different things with networks, and that doesn't make them bad people - What is important about APIs is that they are *not* tied to an implementation or reinvented by every backend provider, but commonly agreed This says we find pragmatic ways to introduce sane, consumable APIs for any new thing we want to do, and perhaps we need a governance model around ensuring that they are sane and resuable. None of this says that every API should fit neatly into the network/port/subnet model we have - it was designed for, and is good at describing, L2 broadcast domains. (Gluon, specifically, is about solving exclusively the technical question of how to introduce independent APIs, and not the governance one of how to avoid proliferation.) For any new feature, I would suggest that we fold it in to the current API if it's widely useful and closely compatible with the current model. There are clearly cases where changing the current API in complex ways to serve 1% of the audience is not necessary and not helpful, and I think this is where our problems arise. And by 'the current API' I mean the existing network/port/subnet model that is currently the only way to describe how traffic moves from one port to another. I do not mean 'we must start another project' or 'we must have another endpoint'. However, we should have a way to avoid affecting this API if it makes no sense to put it there. We should find a way of offering new forwarding features without finding increasingly odd ways of making networks, ports and subnets serve the purpose. They were created to describe L2 overlays, which is still mostly what they are used to do - to the point that the most widely used plugin by far is the modular *L2* plugin. It's hardly a surprise that these APIs don't map to every possible networking setup in the world. My argument is that it's *sane* to want to invent quit
Re: [openstack-dev] [neutron] API models [was: PTL candidacy]
I would certainly be interested in dicussing this, though I'm not currently signed up for the PTG. Obviously this is close to my interests, and I see Kevin's raised Gluon as the bogeyman (which it isn't trying to be). Setting aside all the above talk about how we might do things for a moment: to take one specific feature example, it actually took several /years/ to add VLAN-aware ports to OpenStack. This is an example of a feature that doesn't affect or interest the vast majority of the user community, and which is almost certainly not installed in the cloud you're currently working on, and you probably have no intention of ever programming, and which even had cross-vendor support. It's useful and there are times that you can't do without it; there were people ready to write the code. So why was it so very hard? I hope we will all agree on these points: - Neutron's current API of networks, subnets and ports is fine for what it does. We like it, we write apps using it, it doesn't need to change - The backward compatibility and common understanding of Neutron's API is paramount - applications should work everywhere, and should continue to work as Neutron evolves - Some people want to do different things with networks, and that doesn't make them bad people - What is important about APIs is that they are *not* tied to an implementation or reinvented by every backend provider, but commonly agreed This says we find pragmatic ways to introduce sane, consumable APIs for any new thing we want to do, and perhaps we need a governance model around ensuring that they are sane and resuable. None of this says that every API should fit neatly into the network/port/subnet model we have - it was designed for, and is good at describing, L2 broadcast domains. (Gluon, specifically, is about solving exclusively the technical question of how to introduce independent APIs, and not the governance one of how to avoid proliferation.) For any new feature, I would suggest that we fold it in to the current API if it's widely useful and closely compatible with the current model. There are clearly cases where changing the current API in complex ways to serve 1% of the audience is not necessary and not helpful, and I think this is where our problems arise. And by 'the current API' I mean the existing network/port/subnet model that is currently the only way to describe how traffic moves from one port to another. I do not mean 'we must start another project' or 'we must have another endpoint'. However, we should have a way to avoid affecting this API if it makes no sense to put it there. We should find a way of offering new forwarding features without finding increasingly odd ways of making networks, ports and subnets serve the purpose. They were created to describe L2 overlays, which is still mostly what they are used to do - to the point that the most widely used plugin by far is the modular *L2* plugin. It's hardly a surprise that these APIs don't map to every possible networking setup in the world. My argument is that it's *sane* to want to invent quite different APIs, it's not competition or dilution, and should we choose to do so it's even a reasonable thing to do within Neutron's current framework. I do not care if we make Neutron extensible in some different way to permit this, if we start a new project or whatever, I just want it to happen. If you think that the Gluon approach to this is the wrong way to make it happen, and I'm seeing general consensus here that this could be done within Neutron, then I welcome alternative suggestions. But I do honestly believe that we make our own pain by insisting on one API that must be ridigly backward- and cross-compatible and simultaneously insisting that all novel ideas be folded into it. -- Ian. On 25 January 2017 at 10:19, Sukhdev Kapur wrote: > Folks, > > This thread has gotten too long and hard to follow. > It is clear that we should discuss/address this. > My suggestion is that we organize a session in Atlanta PTG meeting and > discuss this. > > I am going to add this on the Neutron etherpad - should this be included > in any other session as well? > > -Sukhdev > > > > > On Tue, Jan 24, 2017 at 12:33 AM, Ihar Hrachyshka > wrote: > >> Hi team, >> >> I would like to propose my PTL candidacy for Pike. >> >> Some of you already know me. If not, here is my brief OpenStack bio. I >> joined the community back in Havana, and managed to stick around till >> now. During the time, I fit several project roles like serving as a >> Neutron liaison of different kinds (stable, oslo, release), fulfilling >> my Neutron core reviewer duties, taking part in delivering some >> longstanding features, leading QoS and upgrades subteams, as well as >> being part of Neutron Drivers team. I also took part in miscellaneous >> cross project efforts. >> >> I think my experience gives me broad perspective on how the OpenStack >> community and more specifically Networking works, and what i
