Hi, I am trying to validate GlusterFS domain engine patches, against 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 ? If not, then what is the right process to follow here ?
thanx, deepak
On Thu, Mar 21, 2013 at 10:42:27AM +0530, Deepak C Shetty wrote:
Hi, I am trying to validate GlusterFS domain engine patches, against 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.
If not, then what is the right process to follow here ?
thanx, deepak
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
On 03/21/2013 01:11 PM, Dan Kenigsberg wrote:
On Thu, Mar 21, 2013 at 10:42:27AM +0530, Deepak C Shetty wrote:
Hi, I am trying to validate GlusterFS domain engine patches, against 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.
I sent the patch @ http://gerrit.ovirt.org/#/c/13236/
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:
Hi, I am trying to validate GlusterFS domain engine patches, against 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 sent the patch @ http://gerrit.ovirt.org/#/c/13236/
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
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:
Hi, I am trying to validate GlusterFS domain engine patches, against 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 for ?
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:
Hi, I am trying to validate GlusterFS domain engine patches, against 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 for ?
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
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.
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:
Hi, I am trying to validate GlusterFS domain engine patches, against 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 for ?
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 ?
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: > Hi, > I am trying to validate GlusterFS domain engine patches, > against > 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 for ?
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
On 04/30/2013 12:12 PM, Itamar Heim wrote:
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: >> Hi, >> I am trying to validate GlusterFS domain engine patches, >> against >> 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 for ?
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
Okay, so this is the one you meant ?
engine-config -g BootstrapMinimalVdsmVersion BootstrapMinimalVdsmVersion: 4.9 version: general
On 04/30/2013 11:08 AM, Deepak C Shetty wrote:
On 04/30/2013 12:12 PM, Itamar Heim wrote:
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: >>> Hi, >>> I am trying to validate GlusterFS domain engine patches, >>> against >>> 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 for ?
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
Okay, so this is the one you meant ?
engine-config -g BootstrapMinimalVdsmVersion BootstrapMinimalVdsmVersion: 4.9 version: general
actually: SupportedVDSMVersions
vdsm-devel mailing list vdsm-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel
vdsm-devel@lists.fedorahosted.org