openstack-poc team mailing list archive

[Thierry Carrez <thierry@xxxxxxxxxxxxx>]

markmc's perspective on the issue was posted to the openstack ML, I
forward it here for the sake of completeness.

On the topic of the openstack-poc list being closed, one option we have
is to move the openstack-poc list to the mailman instance once it's set
up, then we can have subscribers that are not PPB members, and who can
participate to the discussion (indirectly through moderation).

-------- Message original --------
Sujet: Re: [Openstack] 3rd Party APIs
Date : Tue, 08 May 2012 15:58:45 +0100
De : Mark McLoughlin <markmc@xxxxxxxxxx>
Répondre à : Mark McLoughlin <markmc@xxxxxxxxxx>
Pour : openstack@xxxxxxxxxxxxxxxxxxx
Copie à : openstack-poc@xxxxxxxxxxxxxxxxxxx

Hey,

I just realised there's a thread on the openstack-poc list about how
OpenStack should view implementations of APIs other than the OpenStack
API:

  https://lists.launchpad.net/openstack-poc/msg00448.html

(PPB members - please note that other folks can't subscribe to the POC
list. If you want an open discussion on something, the openstack-poc
list isn't the place for it)


tl;dr - rather than actively discouraging folks from contributing native
API implementations, encourage them to resolve the current difficulties
with the EC2 API and their work as a test case for feature/subsystem
branch development process.


The discussion is fairly complex and seems to degenerate into an overly
general "what is and is not core" discussion. There also seems to be a
sense of urgency around finding a final solution here, which I don't
fully understand. The truth is we don't know the answer. We just need to
have some rough idea of what we're trying to achieve and figure out the
thing we want to try next. We'll likely have to try a bunch of stuff
before finding one that works.

What I'd like to see us get to is:

  Deep overlap between the OpenStack developer community and the
  community of folks drafting whatever IaaS standard(s) wind up being
  dominant.

  e.g. prominent, active Nova developers developers contributing to the
  CIMI or OCCI standards and bringing the needs of OpenStack to the
  standard and bringing ideas from the standards process to OpenStack.

This isn't a question of asking existing OpenStack developers to join
these standards bodies. It's about enabling members of those standards
bodies to become as much a part of OpenStack as any other developer.

How to do that? Encourage members the various standards communities to
actively contribute an implementation of their standard to OpenStack
and, more importantly, stick around to become an ongoing active member
of the OpenStack developer community.

If this worked out, OpenStack would gain new developers, new ideas and
would be seen as the best place to do new work around IaaS APIs.


AFAICT nova-core has two major concerns with the EC2 API - 1) currently
having to make a change once in the OpenStack API and again in the EC2
API and 2) the EC2 isn't maintenance isn't sufficiently active.

I think a lot of the urgency around this discussion is wanting to avoid
exacerbating the situation by adding another API. To me, the answer is
fairly simple. We cannot accept a new API until these concerns are
addressed:

  1) The amount of duplication between the OpenStack, EC2 and any
     proposed API needs to be significantly reduced

  2) The developers of any proposed new API need to demonstrate a
     commitment (through their work) to sticking around as active
     OpenStack developers maintaining the API (perhaps as a subsystem
     tree)

That's a high bar, and I expect only seriously committed contributors
would meet it. In the meantime, those contributors can work on their
APIs as feature branches and encourage others to give feedback.


Two alternatives to the above are on the table. Firstly, implementing
these APIs as deltacloud-like proxy servers and blessing these as
"official" OpenStack products. IMHO, proxies are architecturally less
than ideal. Perhaps with enough engineering effort (including OpenStack
API additions) we can get to where they are almost on-par with a native
API, but I'm sceptical.

The other option is to support these APIs with external plugins. For us
to get there, we need a stable library-like API that these plugins can
depend on. It's potentially an ideal solution, but I think we've a long
way to get there. A stepping stone is the re-factoring to reduce
duplication between APIs.


Cheers,
Mark.


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp