Open Stack

On Wed, Mar 25, 2015 at 4:24 PM, Deepak Shetty <dpkshetty at gmail.com> wrote:

>
>
> On Wed, Mar 25, 2015 at 4:20 PM, Deepak Shetty <dpkshetty at gmail.com>
> wrote:
>
>>
>>
>> On Wed, Mar 25, 2015 at 3:58 PM, Sean Dague <sean at dague.net> wrote:
>>
>>> On 03/25/2015 03:16 AM, Deepak Shetty wrote:
>>> >
>>> >
>>> > On Wed, Mar 25, 2015 at 11:29 AM, Deepak Shetty <dpkshetty at gmail.com
>>> > <mailto:dpkshetty at gmail.com>> wrote:
>>> >
>>> >
>>> >
>>> >     On Wed, Mar 25, 2015 at 12:58 AM, Ian Wienand <iwienand at redhat.com
>>> >     <mailto:iwienand at redhat.com>> wrote:
>>> >
>>> >         On 03/24/2015 03:17 PM, Deepak Shetty wrote:
>>> >         > For eg: Look at [1]
>>> >         > [1]
>>> https://github.com/stackforge/devstack-plugin-glusterfs/blob/master/devstack/settings
>>> >
>>> >         > I would like ability to change these while I use the
>>> enable_plugin
>>> >         > apporach to setup devstack w/ GlusterFS per my local
>>> glusterfs setup
>>> >
>>> >         So I think the plugin should do
>>> >
>>> >
>>>  CINDER_ENABLED_BACKENDS=${CINDER_ENABLED_BACKENDS:-glusterfs:glusterfs,lvm:lvm1}
>>> >
>>> >         i.e. provide a default only if the variable is unset.
>>> >
>>> >
>>> >     Bah! That was easy, i should have figured that myself :)
>>> >     Thanks for catching that
>>> >
>>> >
>>> >
>>> >         This seems like one of those "traps for new players" and is one
>>> >         concern I have with devstack plugins -- that authors keep
>>> having to
>>> >         find out lessons learned independently.  I have added a note
>>> on this
>>> >         to the documentation in [1].
>>> >
>>> >         -i
>>> >
>>> >         [1] https://review.openstack.org/#/c/167375/
>>> >
>>> >
>>> >     Great, i +1'ed it.
>>> >
>>> >     Also i posted patch to fix settings file @
>>> >     https://review.openstack.org/167494
>>> >
>>> >
>>> > Ian,
>>> >    Looks like usign bash default in settings file of plugin is not
>>> > working, in my patch it didn't use glusterfs driver, it used LVM
>>> (default)
>>> > I think whats happening here is that by the time settings file is
>>> > sourced, CINDER_ENABLED_BACKENDS is already set to lvm by lib/cinder
>>> > so settings file's default value is never taken
>>> >
>>> > IIUC there are 3 scenarios (taking CINDER_ENABLED_BACKENDS as example
>>> var) :
>>> >
>>> > 1) localrc doesn't have CINDER_ENABLED_BACKENDS and enable_plugin
>>> >     - Here we want the lib/cinder's default value to be taken
>>> >     - this should work fine
>>> >
>>> > 2) localrc doesn't have CINDER_ENABLED_BACKENDS but has enable_plugin
>>> > glusterfs
>>> >     - Here we want the plugin's default values to be taken, but its not
>>> > as lib/cinder already initialized CINDER_ENABLED_BACKENDS to use lvm
>>> backend
>>> >     - Thus broken
>>> >
>>> > 3) localrc has both CINDER_ENABLED_BACKENDS and enable_plugin glusterfs
>>> > specified
>>> >     - Here we want CINDER_ENABLED_BACKENDS present in my localrc to be
>>> > chosen
>>> >     - This will work as by the time settings file is sourced
>>> > CINDER_ENABLED_BACKENDS is already initialised to my value in localrc
>>> >
>>> > So #2 scenario would need some changes in stack.sh handling of plugin
>>> code ?
>>>
>>> Right, so this code runs late enough that you don't get to change the
>>> defaults. I think that's ok.
>>>
>>> I would instead do the following:
>>>
>>> 1) CINDER_ENABLED_BACKENDS+=,glusterfs:glusterfs
>>>
>>> or
>>>
>>> 2) CINDER_ENABLED_BACKENDS=glusterfs:glusterfs
>>>
>>> in the plugin.
>>>
>>> Clearly, if you've enabled the plugin, you want glusterfs. I think that
>>> in most cases you probably only want glusterfs as your backend, so
>>> option #2 seems sensible.
>>>
>>
>>
>> #1 is needed for multi-backend testing
>> #2 is needed for single-backend testing
>>
>> #2 is what we currently, we blindly override the var, but that forces the
>> devstack user to
>> use the config given in the plugin, I wanted a way to either use plugin
>> config or override it
>>
>> I think #1 is better, since it gives the power in localrc to do:
>>
>> 1) CINDER_ENABLED_BACKENDS=
>> This will ensure lib/cinder doesn't populate it and plugin adds
>> glusterfs:glusterfs for single backend
>>
>
> My bad here, lib/cinder uses :- which IIUC means empty or unset, use
> default
> so with #1 or #2 there isn't a way to provide ability to use plugin config
> or override it , both ?
>
> back to square one.
>

Sorry, hit send before i could complete
back to square one (unless we modify lib/cinder to *not* use default for
CINDER_ENABLED_BACKENDS
if 'CINDER_ENABLED_BACKENDS=' specified in localrc)

thanx,
deepak


>
> thanx,
> deepak
>
>
>>
>> 2) No mention of CINDER_ENABLED_BACKENDS in localrc
>> This will make it CINDER_ENABLED_BACKENDS=lvm:lvm-driver1,
>> glusterfs:glusterfs for multi-backend
>>
>> Also for vars in settings file that are backend specific (hence not
>> touched by lib/cinder):
>>
>> GLUSTERFS_LOOPBACK_DISK_SIZE & CINDER_GLUSTERFS_SHARES
>>
>> They can remain as :
>> GLUSTERFS_LOOPBACK_DISK_SIZE=${GLUSTERFS_LOOPBACK_DISK_SIZE:-8G}
>>
>> CINDER_GLUSTERFS_SHARES=${CINDER_GLUSTERFS_SHARES:-"127.0.0.1:
>> /vol1;127.0.0.1:/vol2"}
>>
>> (as mentioned in the patch @
>> https://review.openstack.org/#/c/167494/1/devstack/settings)
>>
>> This will give the end user the ability to change loopback size and/or
>> gluster server IPs
>> based on the needs of his/her local setup
>>
>> Agree ?
>>
>> If yes, then we must mention this in the plugin.rst in a nice way for
>> other plugin writers to
>> understand properly :) ?
>>
>> thanx,
>> deepak
>>
>>
>>>
>>>
>>>         -Sean
>>>
>>> --
>>> Sean Dague
>>> http://dague.net
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150325/4eb96496/attachment.html>