On 04/30/2013 07:37 AM, Deepak C Shetty wrote:
On 04/21/2013 02:40 AM, Itamar Heim wrote:
On 03/22/2013 06:42 AM, Deepak C Shetty wrote:
On 03/21/2013 04:07 PM, Vinzenz Feenstra wrote:
On 03/21/2013 10:32 AM, Deepak C Shetty wrote:
On 03/21/2013 01:11 PM, Dan Kenigsberg wrote:
On Thu, Mar 21, 2013 at 10:42:27AM +0530, Deepak C Shetty wrote:
I am trying to validate GlusterFS domain engine patches,
VDSM. GlusterFS domain is enabled for 3.3 only
So when i try to add my VDSM as a new host to engine, it doesn't
allow me to do so since clusterLevels (returned by VDSM as part of
engine calling getCap) doesn't have 3.3
I hacked VDSM's dsaversion.py to return 3.3 as well as part of
getCap and now I am able to add my VDSM host as a new host from
engine for DC of type GLUSTERFS_DOMAIN.
Is this the right way to test a 3.3. feature, if yes, should I send
a vdsm patch to add 3.3 in dsaversion.py ?
You are right - it's time to expose this clusterLevel.
Shouldn't the supportedENGINEs value also be updated to 3.2 and 3.3? I
am a bit confused that this one stays at 3.0 and 3.1
I am really not sure whats the use of supportedENGINEs. I changed
clusterLevels bcos doing that allowed me to add my VDSM host to a 3.3
cluster. Can someone throw more light on what is supportedENGINEs used
engine also has "supported vdsm versions".
if vdsm version isn't in that list, vdsm can declare to engine the
vdsm can work with that version of the engine - it was meant to make
sure only tested/supported versions of vdsm work with tested versions
of engine, etc.
Hmm... but vdsm having supportedENGINEs as 3.0 and 3.1 did work with
Engine 3.2 and 3.2 !
So does that mean engine is not honoring this field now ?
i assume you engine had the vdsm version listed as supported in its config
vdsm-devel mailing list