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.
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
