Open Stack

I was not trying to say those documents have all the answers, just that 
it is not quite the wild west with PTLs doing whatever they feel like 
and making incompatible changes either. The main thrust was that if I am 
creating a service/application that uses OpenStack APIs correctly to 
control cloud resources, then my application should continue to work 
even if the operator of one of my clouds upgrades to a new OpenStack 
release. There are gray areas around cases where the existing API is 
totally broken and some of these examples are mentioned in the document. 
Adding extensions would not run afoul of this criteria but has its own 
issues as Jorge observed. I think we have to consider separately two 
uses of extensions:

1. A PTL wants to enhance the function of an API in a way that is 
incompatible (breaks existing apps) and uses an "official" extension to 
get around that instead of bumping the version.

2. A provider extends a core API with their own extensions which may 
conflict with others.

Ideally all the APIs would have methods for discovering available apis 
but I think that is spotty now and definitely not
uniform across projects.

  -David

On 2/6/2013 8:30 PM, Mellquist, Peter wrote:
> Hi David,
>
> I think the links you point out are good but also quite general. Of course we want "API stability" but...
> * tell me in detail what the rules are for when to create an API extension verses not?
> * do all Openstack APIs have a required way to express versioning?
> * how does a service advertise a version and allow a client to negotiate a version?
> * etc...
>
> Many of the new projects pick up the latest Nova or Keystone specs and try to emulate these areas but do we assume that Nova or Keystone API specs are the 'API blueprint' for all?
>
>
> Good Discussion,
> Peter.
>
>
> -----Original Message-----
> From: David Kranz [mailto:david.kranz at qrclab.com]
> Sent: Wednesday, February 06, 2013 5:16 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] "Changing" an API
>
> On 2/6/2013 8:03 PM, Mellquist, Peter wrote:
>> Hi Gabriel,
>>
>> I 100% agree that changes which are totally backward compatible should be allowed rather than bifurcate the APIs with extensions which cause the clients and language bindings grief. Backward compatible changes with a minor version bump is the logical thing to do.
>>
>> The more general problem is lack of any real API guidelines across all APIs, including versioning as you point out. There exists a relatively small set of guidelines which would solve much of the API mess. My feeling is that all API related decisions are totally up to the PTLs who can do whatever they like. And they do. So we have some API patterns which are good, some bad, and some totally different. In the past there has been push back on creating common API guidelines so I guess I am not totally surprised of what we are seeing.
>>
>> Peter.
>>
> This is not entirely true. See
>
> http://wiki.openstack.org/Governance/Approved/APIStability
>
> and
>
> http://wiki.openstack.org/APIChangeGuidelines
>
> There are still gray areas and judgment calls to be made, but the intent
> of these documents was to try to provide exactly the kinds of guidelines
> you say are lacking. It is an expressed goal of Tempest to catch
> user-detectable API changes so they can be dealt with appropriately.
>
>    -David
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev