Christopher, I agree that a feature that is generically applicable to all implementations should be in the core API. I also agree that we should be having debates at proposal time rather than merge time -- which is one of the benefits of having a separate spec -- we can debate the spec before we spend time implementing the feature.
That said, just because a feature isn't in core, doesn't mean that the feature isn't useful. There may be useful features that are applicable to a particular vendor (pricing), or that not all backends can support (Xen vs KVM), or that if they were included in the core would set the bar for a standard deployment very high because it relies on dependencies with other services (backup schedules). So it makes sense for there to be a slim core API that you know you can count on no matter what -- and this API should cover all the basics (create, delete, reboot, etc), and if there are other goodies available by the deployment a client should be able to detect them. At least that's how I see things. -jOrGe W. On Aug 22, 2011, at 8:19 PM, Christopher MacGown wrote: The fundamental problem with throwing all new API features into ext/ is that support for core features ends up being a political football that the various vendors can play with each other. A user of OpenStack shouldn't have to check whether each feature within core is supported at the API level by their provider. By accepting code into trunk, we as *-core are generally asserting that a feature is generically useful across all implementations of OpenStack. Blueprints for which there is some controversy around API exposure or feature correctness should be vigorously debated at proposal, not at merge. And in my opinion, if a feature isn't useful enough to expose through the API, why are we including it in trunk? Christopher MacGown Piston Cloud Computing, Inc. w: (650) 24-CLOUD m: (415) 300-0944 ch...@pistoncloud.com<mailto:ch...@pistoncloud.com> On Aug 22, 2011, at 4:59 PM, Jorge Williams wrote: Hi Vish, I don't have a problem moving the spec out of docs manuals and into another project even the nova repo. But, I do have a number of issues with the approach that you're proposing. First, I think that fundamentally there should be a decoupling of the spec and the implementation. If you have the spec generated from the code than essentially the spec is whatever the code does. It's very difficult to interoperate with specs that are generated this way as the specs tend to be very brittle and opaque (since you have to study the code). If you introduce a bug in the code that bug filters it's way all the way to the spec (this was a big problem with SOAP and CORBA). It's difficult to detect errors because you cant validate. By keeping the implementation and the spec separate you can validate one against the other. Second, I don't think that the core OpenStack API should change with every OpenStack release. There are a number of efforts to provide multiple implementation of an existing OpenStack API. We should encourage this, but it becomes difficult if the core spec is in constant flux. Certainly you can use the extension mechanism to bring functionality out to market quickly, but the process of deciding what goes into the core should be more deliberate. Really good specs, shouldn't need to change very often, think HTTP, X11, SMTP, etc. We need to encourage clients to write support for our spec and we need to also encourage other implementors to write implementations for it. These efforts become very difficult if the spec is in constant flux. -jOrGe W. On Aug 22, 2011, at 5:43 PM, Vishvananda Ishaya wrote: Hey Everyone, We discussed at the Diablo design summit having API spec changes be proposed along with code changes and reviewed according to the merge process that we use for code. This has been impossible up until now because the canonical spec has been in the openstack-manuals project. My suggestion is that we move the openstack-compute spec into the nova source tree. During a six-month release we can propose changes to the spec by proposing along with the code that changes it. In the final freeze for the release, we can increment the spec version number and copy the current version of the spec into openstack-manuals and that will be the locked down spec for that release. This means that openstack 1.1 will be the official spec for diablo, at which point we will start working on a new api (we can call it 1.2 but it might be best to use a temporary name like 'latest') during the essex release cycle, then at essex release we lock the spec down and it becomes the new version of the openstack api. Ultimately I would like the spec to be generated from the code, but as a first pass, we should at least be able to edit the future version of the spec as we make changes. I've proposed the current version of the spec here: https://code.launchpad.net/~vishvananda/nova/add-api-docs/+merge/72506 Are there any issues with this approach? Vish 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<mailto:openstack@lists.launchpad.net> Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp 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
