On 8/26/11 1:19 PM, "Devin Carlen" <devin.car...@gmail.com> wrote:
>There have been a lot of efforts lately to bring the feature set of the >OpenStack API in line with the EC2 API, and this is admirable. But this >has NOT been happening at the architect level. This has been happening >at the developer level, and it is being done with API "extensions" which >make it sound like the feature is somehow not complete or not supported >fully, because it's not part of the core API. I think you are hitting on a perception problem around extensions that might be solvable by taking some steps to make the intent clear. I propose two things: always keep the next version of the API in play and improve the classification of the extensions. Developers have to choose to contribute in a way that either works with the current APIs or not. Mixing these is bad, and fortunately unnecessary. The two tracks should probably have different tech leads. How about this as classification system for extensions: temporary extension accepted for addition to core api in the next backwards compatible version uprev backport extension ‹ accepted for addition to core api in the next non-backwards compatible version uprev default extension viewed as standard, but not incorporated into the core to allow opt-out by an operator common extension ‹ viewed as the preferred solution, but must be an opt-in by an operator candidate extension ‹ an extension viewed as trying to prove itself worthy for a higher level private extension ‹ an extension not offered or not accepted for a higher level Thoughts? This email may include confidential information. If you received it in error, please delete it. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp