Open Stack

On Thu, Dec 12, 2013 at 3:17 PM, Mike Perez <thingee at gmail.com> wrote:

> On 10:06 Thu 12 Dec     , Christopher Yeoh wrote:
> > On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann
> > <doug.hellmann at dreamhost.com>wrote:
> >
> > So for compatibility testing I think what will probably happen is that
> > we'll be defining a minimum set (API_V3_CORE_EXTENSIONS)
> > that must be implemented and clients can rely on that always being
> present
> > on a compliant cloud. But clients can also then query through /extensions
> > what other functionality (which is backwards compatible with respect to
> > core) may also be present on that specific cloud.
>
> I'm worried by the discrepancies this will create among the programs. You
> mentioned maintainability being a plus for this. I don't think it'll be
> great
> from the deployers perspective when you have one program that thinks
> everything
> is an extension and some of them have to be enabled that the deployer has
> to be
> mindful of, while the rest of the programs consider all extensions to be
>

Just to be clear, the deployer doesn't have to enable these, they are
enabled automatically,
but it will complain if a deployer attempts to disable them. Also anything
not core has a
"os-" prefix, while core plugins don't so it is easy to distinguish between
them. But yes I'd agree
that from a deployers point of view its not useful to talk about extensions
which have
to be enabled.

Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131213/a1d19823/attachment.html>