On 19 April 2016 at 23:42, Michał Dulko <michal.du...@intel.com> wrote:
> On 04/18/2016 09:17 AM, Ramakrishna, Deepti wrote: > > Hi Michal, > > > > 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. > > > > 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. > > Good point, to make that a standard for Cinder API feature discovery we > would still need to make that more admin-friendly. This also implies > that probably no admin is actually caring about setting the set of > extensions correctly. > 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. > > 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? > > Yes, but I don't think you can run away from setting things manually. > For example CGs are supported only for certain backends. This set of > features should also be discoverable. Anyway I think the spec makes sense. > Volume type feature discovery is different (but related) to API feature discovery. This is unfortunately going against the recent efforts of standardizing > how OpenStack works between deployments. In Cinder we have API features > that may or may not be available in different installations. This > certainly isn't addressed by microversions efforts, which may seem > related. My feeling is that this goes beyond Cinder and hits a more > general topic of API discoverability. I think that we should seek the > API WG advice in that matter. Do we have other OpenStack project > suffering from similar issue? > > 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.
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
