Hi Valeriy, I wasn’t aware, thanks!
So, if each driver exposes the storage_protocols it supports, would it be sensible to have manila-ui check the extra_specs for this key and limit the protocol choice for a given share type to the supported protocols (in order to avoid that the user tries to create incompatible type/protocol combinations)? Thanks again! Arne On 02 Nov 2016, at 10:00, Valeriy Ponomaryov <vponomar...@mirantis.com<mailto:vponomar...@mirantis.com>> wrote: Hello, Arne Each share driver has capability called "storage_protocol". So, for case you describe, you should just define such extra spec in your share type that will match value reported by desired backend[s]. It is the purpose of extra specs in share types, you (as cloud admin) define its connection yourself, either it is strong or not. Valeriy On Wed, Nov 2, 2016 at 9:51 AM, Arne Wiebalck <arne.wieba...@cern.ch<mailto:arne.wieba...@cern.ch>> wrote: Hi, We’re preparing the use of Manila in production and noticed that there seems to be no strong connection between share types and share protocols. I would think that not all backends will support all protocols. If that’s true, wouldn’t it be sensible to establish a stronger relation and have supported protocols defined per type, for instance as extra_specs (which, as one example, could then be used by the Manila UI to limit the choice to supported protocols for a given share type, rather than maintaining two independent and hard-coded tuples)? Thanks! Arne -- Arne Wiebalck CERN IT __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Kind Regards Valeriy Ponomaryov www.mirantis.com<http://www.mirantis.com/> vponomar...@mirantis.com<mailto:vponomar...@mirantis.com> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org<mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Arne Wiebalck CERN IT
__________________________________________________________________________ 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