<div dir="ltr"><div>On 10:06 Thu 12 Dec , Christopher Yeoh wrote:</div><div>> On Thu, Dec 12, 2013 at 8:59 AM, Doug Hellmann</div><div>> <<a href="mailto:doug.hellmann@dreamhost.com">doug.hellmann@dreamhost.com</a>>wrote:</div>
<div>> </div><div>> ></div><div>> ></div><div>> ></div><div>> >> On Wed, Dec 11, 2013 at 3:41 PM, Ryan Petrello <</div><div>> >> <a href="mailto:ryan.petrello@dreamhost.com">ryan.petrello@dreamhost.com</a>> wrote:</div>
<div>> ></div><div>> >> Hello,</div><div>> >></div><div>> >> I’ve spent the past week experimenting with using Pecan for Nova’s API,</div><div>> >> and have opened an experimental review:</div>
<div>> >></div><div>> >> <a href="https://review.openstack.org/#/c/61303/6">https://review.openstack.org/#/c/61303/6</a></div><div>> >></div><div>> >> …which implements the `versions` v3 endpoint using pecan (and paves the</div>
<div>> >> way for other extensions to use pecan). This is a *potential* approach</div><div>> >> I've considered for gradually moving the V3 API, but I’m open to other</div><div>> >> suggestions (and feedback on this approach). I’ve also got a few open</div>
<div>> >> questions/general observations:</div><div>> >></div><div>> >> 1. It looks like the Nova v3 API is composed *entirely* of extensions</div><div>> >> (including “core” API calls), and that extensions and their routes are</div>
<div>> >> discoverable and extensible via installed software that registers itself</div><div>> >> via stevedore. This seems to lead to an API that’s composed of installed</div><div>> >> software, which in my opinion, makes it fairly hard to map out the API (as</div>
<div>> >> opposed to how routes are manually defined in other WSGI frameworks). I</div><div>> >> assume at this time, this design decision has already been solidified for</div><div>> >> v3?</div>
<div>> >></div><div>> ></div><div>> > Yeah, I brought this up at the summit. I am still having some trouble</div><div>> > understanding how we are going to express a stable core API for</div><div>
> > compatibility testing if the behavior of the API can be varied so</div><div>> > significantly by deployment decisions. Will we just list each "required"</div><div>> > extension, and forbid any extras for a compliant cloud?</div>
<div>> ></div><div>> </div><div>> > Maybe the issue is caused by me misunderstanding the term "extension,"</div><div>> > which (to me) implies an optional component but is perhaps reflecting a</div>
<div>> > technical implementation detail instead?</div><div>> ></div><div>> ></div><div>> Yes and no :-) As Ryan mentions, all API code is a plugin in the V3 API.</div><div>> However, some must be loaded or the V3 API</div>
<div>> refuses to start up. In nova/api/openstack/__init__.py we have</div><div>> API_V3_CORE_EXTENSIONS which hard codes</div><div>> which extensions must be loaded and there is no config option to override</div>
<div>> this (blacklisting a core plugin will result in the</div><div>> V3 API not starting up).</div><div>> </div><div>> So for compatibility testing I think what will probably happen is that</div><div>> we'll be defining a minimum set (API_V3_CORE_EXTENSIONS)</div>
<div>> that must be implemented and clients can rely on that always being present</div><div>> on a compliant cloud. But clients can also then query through /extensions</div><div>> what other functionality (which is backwards compatible with respect to</div>
<div>> core) may also be present on that specific cloud.</div><div><br></div><div>This really seems similar to the idea of having a router class, some</div><div>controllers and you map them. From my observation at the summit, calling</div>
<div>everything an extension creates confusion. An extension "extends" something.</div><div>For example, Chrome has extensions, and they extend the idea of the core</div><div>features of a browser. If you want to do more than back/forward, go to an</div>
<div>address, stop, etc, that's an extension. If you want it to play an audio clip</div><div>"stop, hammer time" after clicking the stop button, that's an example of an</div><div>extension.</div><div><br>
</div><div>In OpenStack, we use extensions to extend core. Core are the essential</div><div>feature(s) of the project. In Cinder for example, core is volume. In core you</div><div>can create a volume, delete a volume, attach a volume, detach a volume, etc. If</div>
<div>you want to go beyond that, that's an extension. If you want to do volume</div><div>encryption, that's an example of an extension.</div><div><br></div><div>I'm worried by the discrepancies this will create among the programs. You</div>
<div>mentioned maintainability being a plus for this. I don't think it'll be great</div><div>from the deployers perspective when you have one program that thinks everything</div><div>is an extension and some of them have to be enabled that the deployer has to be</div>
<div>mindful of, while the rest of the programs consider all extensions to be</div><div>optional.</div><div><br></div><div><br></div><div>Thanks,</div><div>Mike Perez</div></div>