Open Stack

On Wed, Sep 3, 2014 at 10:20 AM, Waines, Greg <Greg.Waines at windriver.com>
wrote:

>  Thanks Anne.
>
>
>
> But the individual APIs, say Compute API, are not up-versioned every
> OpenStack Release.
>
>
>
> However the individual APIs, say Compute API V2, (I believe) are extended
> every OpenStack Release … possibly new requests, possibly new parameters
> for requests, possibly new attributes in responses.
>
>
>

Yes, this is correct, extension only happens in extensions though for v2. I
cannot say v2 itself changes, it does not. Extensions may be added or
removed however. A cloud provider then choses what to put into production
for their customers.


>  So there are going to be IceHouse(say)-specific changes in (say) Compute
> API V2 … correct ?
>
>
>

Yes. Those are mostly tracked with blueprints if you want to know what
actually changed in a given release, such as:
https://blueprints.launchpad.net/nova/icehouse




>  But it sounds like there is no tag or commit that represents an
> ‘up-to-Havana only’ version of Compute API V2 … correct ?
>
>
>

Not for the docs. I've been trying to figure out how you could figure it
out from the code itself but not really finding a way even after reading
lots of specs about microversions.

The API docs also are not complete any given release, sad to say. The
mechanism for adding a new extension should include a "DocImpact" flag in
the commit, which then adds a doc bug automatically. I know we try to
quantify and track -- there are 32 bugs outstanding for Compute API for
example:

https://bugs.launchpad.net/openstack-api-site/+bugs/?field.tag=nova

If you have ideas for how we can improve, I'd be happy to hear them. We
didn't get traction on a "registry" idea back in 2012. We also haven't seen
much compliance on doc requirements on extensions themselves. It's
certainly a worthwhile pursuit, but mostly the cloud providers are
documenting their own clouds. OpenStack upstream should document the
standard more than the release is my current thinking.
Anne


>
>
> Greg.
>
>
>
>
>
>
>
>
>
>
>
> *From:* annegentle at justwriteclick.com [mailto:
> annegentle at justwriteclick.com] *On Behalf Of *Anne Gentle
> *Sent:* Tuesday, September 02, 2014 11:36 PM
> *To:* Waines, Greg
> *Cc:* openstack-docs at lists.openstack.org
> *Subject:* Re: [Openstack-docs] 2013.2 tag seems broken ?
>
>
>
>
>
>  < SNIP >
>
>
>
>
>
> We have had this discussion in the past, read it at
> http://lists.openstack.org/pipermail/openstack-docs/2014-April/004337.html.
> The basic problem with tagging API docs is that there's not a map from say,
> havana, to API versions. The deployers choices for that particular release
> would look something like this:
>
>
>
> Block Storage API v1 or v2
>
> Compute API v2
>
> Identity API v2.0 or v3
>
> Image Service v1, v1.1, or v2
>
> (not Database service, they weren't integrated then)
>
> Networking API v2.0
>
> Object Storage v1
>
> Orchestration v1
>
> Telemetry v2
>
>
>
> So I think there are  3*2*3*4*2*2*2*2 = 1152 possibilities of combining
> API versions a cloud provider offers for Havana, where you can choose not
> to deploy an API endpoint at all. We can't dictate to the provider "you
> must run these API versions when running havana" so I've avoided tagging
> the docs for overhead and maintenance and explanatory reasons. :)
>
>
>
> Hopefully these explanations makes sense to you, sounds like you've
> guessed right all along. I certainly want our docs to be re-used and
> they're licensed completely for re-use, but I'm pretty sure I can't
> accurately say which API calls go with a particular release. I definitely
> want to hear ideas though!
>
> Thanks for asking -
>
> Anne
>
>
>
>
>
>
>
>
>
> thanks in advance,
>
> Greg.
>
>
>
>
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140904/0c0a4e5f/attachment-0001.html>