Open Stack

I'm not a lawyer either. I write docs and try to maintain them
sanely... so a comment below.

On Fri, Oct 26, 2012 at 11:31 AM, Monty Taylor <mordred at inaugust.com> wrote:
> IANAL
>
> On 10/26/2012 08:16 AM, Thierry Carrez wrote:
>> Christopher B Ferris wrote:
>>> Thanks for your thoughts. As for the EC2 v OpenStack APis, the EC2 API can be stripped out, leaving all functionality of nova
>>> unimpaired. If the same could be true of the AWS Cloud Formation structures, it would make the project easier to consume
>>> for those with persnickety legal departments.
>>
>> Indeed, Heat would basically be the first OpenStack project to adopt a
>> third-party API as its main API (rather than introducing an
>> OpenStack-specific API that lets us in control of the features we can
>> expose).
>>
>> The arguments of why we need an OpenStack Compute API rather than just
>> adopting the AWS EC2 API can probably be made just the same for Heat...
>>
>> I expect this to become a critical point in the discussion.
>
> I do too. I do think however that our initial concerns over license/use
> of the API (I was one of the vocal advocates of not touching Amazon APIs
> for fear of a crazy Bezos running amok - you can go find my blog
> argument with Shuttleworth on the subject) have been mitigated by recent
> court cases that found APIs are not copyrightable (thanks for stupidly
> suing Google, Oracle!)
>
> The concern about being able to deviate from the API is a good one, but
> honestly deviating from an API which already has tooling is the same
> question whether it's deciding that the Amazon API is deficient and we
> need to make changes or whether we're just revving our API ... both
> would result in client-side tool issues, and both would have to have the
> benefit of the API changes weighed against the cost of client disruption.
>
> In this case, since the desire to do something different from what's
> there is only theoretical, and this code is there, I would say that,
> sans legal concerns over Bezos and court cases, ANY api that comes in on
> version 1 of heat is going to be completely arbitrary and at some point
> in the future we might want to change it... so this one is no worse than
> any other.

I think there's a potential for slight worsening of the API docs
situation ... but I'd like to hear statements pro and con introducing
an API that we don't document into the OpenStack ecosystem. I really
do want to understand this better and it's important that I do
understand it from many perspectives, not just my "Anne from docland"
view.

About our API docs current state - there are about 30 bugs logged [1],
some of the docs are specs, some are not, and API docs constantly need
care and feeding, something we're not resourcing greatly. My
understanding is there are about 25 API writers at Amazon, and in our
open API world, no one is specifically tasked with documenting the
OpenStack APIs (that I know of). Many of my conversations about docs
are more with QA folks who want a spec to test against. Users of APIs,
they seem to be managing, but I'm sure they'd also like more docs.

So what I'd like to hear is not just that we need tests and
development for API additions, but docs as well. What do you all
envision as the doc plan for this type of API usage for OpenStack
deployers?

Thanks for indulging my quest.
Anne

[1] https://bugs.launchpad.net/openstack-api-site

>
> Please, everyone mark this down as the first time I have not argued
> _against_ using an Amazon API.

Noted!

>
> Monty
>
> _______________________________________________
> OpenStack-TC mailing list
> OpenStack-TC at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc