On 11/02/2016 06:23 AM, Arne Wiebalck wrote: > 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)?
Not necessarily tied to share types, but we have this bug open w.r.t. showing only protocols that are available given available backends in the actual deployment: https://bugs.launchpad.net/manila-ui/+bug/1622732 -- Tom > > 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 >> <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 > __________________________________________________________________________ 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
