<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 19 April 2016 at 23:42, Michał Dulko <span dir="ltr"><<a href="mailto:michal.dulko@intel.com" target="_blank">michal.dulko@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote:<br>
> Hi Michal,<br>
><br>
> This seemed like a good idea when I first read it. What more, the server code for extension listing [1] does not do any authorization, so it can be used for any logged in user.<br>
><br>
> However, I don't know if requiring the admin to manually disable an extension is practical. First, admins can always forget to do that. Second, even if they wanted to, it is not clear how they could disable specific extensions. I assume they would need to edit the cinder.conf file. This file currently lists the set of extensions to load as cinder.api.contrib.standard_extensions. The server code [2] implements this by walking the cinder/api/contrib directory and loading all discovered extensions. How is it possible to subtract just one extension from the "standard extensions"? Also, system capabilities and extensions may not have a 1:1 relationship in general.<br>
<br>
</span>Good point, to make that a standard for Cinder API feature discovery we<br>
would still need to make that more admin-friendly. This also implies<br>
that probably no admin is actually caring about setting the set of<br>
extensions correctly.<br></blockquote><div><br></div><div>Certainly no no admins - the HP public cloud disabled a bunch of extensions on the public endpoint for example - but it isn't something we can rely on.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="">
> Having a new extension API (as proposed by me in [3]) for returning the available services/functionality does not have the above problems. It will dynamically check the existence of the cinder-backup service, so it does not need manual action from admin. I have published a BP [4] related to this. Can you please comment on that?<br>
<br>
</span>Yes, but I don't think you can run away from setting things manually.<br>
For example CGs are supported only for certain backends. This set of<br>
features should also be discoverable. Anyway I think the spec makes sense.<br>
<span class=""></span></blockquote><div><br>Volume type feature discovery is different (but related) to API feature discovery. <br><span class=""></span><br><span class=""></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
</span>This is unfortunately going against the recent efforts of standardizing<br>
how OpenStack works between deployments. In Cinder we have API features<br>
that may or may not be available in different installations. This<br>
certainly isn't addressed by microversions efforts, which may seem<br>
related. My feeling is that this goes beyond Cinder and hits a more<br>
general topic of API discoverability. I think that we should seek the<br>
API WG advice in that matter. Do we have other OpenStack project<br>
suffering from similar issue?<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>It's a nice aim to have clouds be entirely consistent, but then you're left with the lowest common denominator. Replication and CG support in cinder are both valuable to a subset of users, and extremely difficult to make universal (I'm still hoping somebody can tell me why CGs at the hypervisor are impossible to get right FWIW). Neutron is likely to be the largest example of differentiated features, and manilla has some too.<br></div><div> </div></div><br></div></div>