On Fri, Mar 27, 2015 at 1:28 PM, Chris Friesen <chris.frie...@windriver.com> wrote:
> On 03/24/2015 11:10 AM, Chris Friesen wrote: > >> On 03/24/2015 07:42 AM, Sean Dague wrote: >> >>> On 03/24/2015 09:11 AM, Jeremy Stanley wrote: >>> >>>> On 2015-03-23 22:34:17 -0600 (-0600), Chris Friesen wrote: >>>> >>>>> How would that be expected to work for things where it's >>>>> fundamentally just a minor extension to an existing nova API? >>>>> (Exposing additional information as part of "nova show", for >>>>> example.) >>>>> >>>> >>>> Conversely, how do you recommend users of your environment reconcile >>>> the difference in nova show output compared to what they get from >>>> the other OpenStack environments they're using? How do you propose >>>> to address the need for client libraries to cater to your divergent >>>> API returning different numbers of parameters for certain methods? >>>> >>> >> We had been trying to control things properly via the extensions >> mechanism so >> that the changes could be documented/controlled. >> >> As for clients, if the properties in the response are named, then simply >> adding >> a new property to a response message body shouldn't be a problem--clients >> could >> just ignore properties that they don't understand. >> >> I think these conversations work better in the concrete than the >>> abstract. >>> >>> Chris, what additional attributes are you exposing on nova show which >>> are critical for your installation? Can we figure out a way to >>> generically support whatever that is? >>> >> >> In some cases it might be something that could conceivably go in >> upstream, but >> hasn't yet. This might be something as simple as having "nova show" >> display the >> server group that an instance is in, or it might be a bugfix that hasn't >> been >> merged upstream yet (like "https://review.openstack.org/#/c/16306"; for >> example) >> or it might be per-instance control over things that upstream currently >> only >> allows control over at the image/flavor level. Some of these might take a >> release or two to get merged (and there's no guarantee that they would >> ever be >> merged) but customers want the functionality in the meantime. >> >> In other cases the change is unlikely to ever be merged upstream, either >> because >> it's too domain-specific or the solution is messy or even proprietary. >> > > Haven't seen any responses to this. > > As I see it, nova is really pushing for interoperability, but what is a > vendor supposed to do when they have customers asking for extensions to the > existing behaviour, and they want it in a month rather than the 6-9 months > it might take to push upstream? (Assuming its something that upstream is > even interested in.) > > To quote John from an earlier email in this thread: Its worth noting, we do have the "experimental" flag: " The first header specifies the version number of the API which was executed. Experimental is only returned if the operator has made a modification to the API behaviour that is non standard. This is only intended to be a transitional mechanism while some functionality used by cloud operators is upstreamed and it will be removed within a small number of releases. " So if you have an extension that gets accepted upstream you can use the experimental flag until you migrate to the upstream version of the extension. > I think it would be better to have an explicit method of > declaring/versioning vendor-specific extensions (even if it's not used at > all by the core Nova API) than to have each vendor winging it on their own. > That way you would still get interoperability of the core Nova API > (allowing customers to use multiple cloud vendors as long as they stick to > the core API) while still giving a well-defined way to provide customized > behaviour. That is *not* what I would call interoperability, this is exactly what we do not want. > > > Chris > > __________________________________________________________________________ > 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
