openstack team mailing list archive

[Michael J Fork <mjfork@xxxxxxxxxx>]

+1 - this is important for both incubated projects and vendor
implementations.  I seem to recall one of the sessions talking about gating
commits to passing an upgrade test from the previous stable release and
these interfaces are an obvious candidate.  Identifying the specific
interfaces will take some work, but the plugin points (e.g. scheduler, rpc,
etc) are a good starting point.

Michael

-------------------------------------------------
Michael Fork
Cloud Architect, Emerging Solutions
IBM Systems & Technology Group



From:	Justin Santa Barbara <justin@xxxxxxxxxxxx>
To:	Eric Windisch <eric@xxxxxxxxxxxxxxxx>,
Cc:	openstack <openstack@xxxxxxxxxxxxxxxxxxx>
Date:	04/23/2012 05:43 PM
Subject:	Re: [Openstack] Canonical AWSOME
Sent by:	openstack-bounces+mjfork=us.ibm.com@xxxxxxxxxxxxxxxxxxx




On Mon, Apr 23, 2012 at 12:31 PM, Eric Windisch <eric@xxxxxxxxxxxxxxxx>
wrote:
  There seemed to be a strong agreement at the summit regarding the need
  for contracts on those "private" apis. This is because those APIs are no
  longer really private, they're shared amongst incubated projects.
  Furthermore, it seems this may be required to support version
  heterogeneity during upgrades with versioned RPC calls.

  The incubated projects could use REST APIs, but we're talking of
  introducing artificial scaling and reliability constraints to do that.
  It seems far better to me, if we can have contracts on those internal
  APIs and use them between the incubated projects.  There is a strong
  enough push to maintain these versions *anyway*.

Ah - thanks for explaining that.  I'm all for locking down these internal
interfaces.  I didn't realize people were willing to do so.
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp