On Thu, Dec 12, 2013 at 3:17 PM, Mike Perez <[email protected]> wrote:
> On 10:06 Thu 12 Dec , Christopher Yeoh wrote: > > On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann > > <[email protected]>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
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
