[Engine-devel] Introducing virt / gluster flags at cluster level
Hi, In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true. We plan to make following changes as part of the patch: 1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false => What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql 2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods 3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper. 4) Modify the DAO JUnit test class to take care of these new fields, if required. 5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these. => One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful? 6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now. 7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now. => Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest? Inputs / comments / suggestions welcome. -- Thanks, Shireesh
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Can we allow both to be true for folks to play with this mode and see if there are issues worth making it exclusive only if there are too many issues yet to be resolved making this a pit hole?
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set. JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments /
Keep in mind that all sp parameters should start with "v_"
variables in save and update methods
Aren't those columns need to be added to relevant views in create_views.sql ???
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set.
JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 03/04/2012 12:20 PM, Moti Asayag wrote:
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed). +1 on enum idea. Even if mixture of services is allowed, we can still use this enum.
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set.
JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and routine refactoring to our DAL. Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of is a cluster with VIRT(1) and FUTURE(4) capabilities
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set.
JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
----- Original Message -----
From: "Moti Asayag" <masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and routine refactoring to our DAL. Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of is a cluster with VIRT(1) and FUTURE(4) capabilities
I agree about the columns being inflexible but personally I don't like enums. What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships? Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary. And it's annoying to support BC of the numbers once things change.
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set.
JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 03/04/2012 03:22 PM, Ayal Baron wrote:
----- Original Message -----
----- Original Message -----
From: "Moti Asayag"<masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and routine refactoring to our DAL. Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of is a cluster with VIRT(1) and FUTURE(4) capabilities
I agree about the columns being inflexible but personally I don't like enums. What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships? Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary. And it's annoying to support BC of the numbers once things change.
enums are an issue, since we want to share them. i agree services table seems the right approach, but actually, booleans are used here exactly because it seems services is the right long term approach, but we there is a lot of ground to cover before we know how they would look like. so boolean flags for the first few services, learning from these, designing the bigger service models, and upgrading to it from the cluster-with-flags seems (to me) the right path to take.
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set.
JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Ayal Baron" <abaron@redhat.com> Cc: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 8:08:52 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/04/2012 03:22 PM, Ayal Baron wrote:
----- Original Message -----
----- Original Message -----
From: "Moti Asayag"<masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and routine refactoring to our DAL. Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of is a cluster with VIRT(1) and FUTURE(4) capabilities
I agree about the columns being inflexible but personally I don't like enums. What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships? Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary. And it's annoying to support BC of the numbers once things change.
enums are an issue, since we want to share them. i agree services table seems the right approach, but actually, booleans are used here exactly because it seems services is the right long term approach, but we there is a lot of ground to cover before we know how they would look like. so boolean flags for the first few services, learning from these, designing the bigger service models, and upgrading to it from the cluster-with-flags seems (to me) the right path to take.
+1
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set.
JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
On 03/04/2012 03:22 PM, Ayal Baron wrote:
----- Original Message -----
----- Original Message -----
From: "Moti Asayag"<masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and routine refactoring to our DAL. Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of is a cluster with VIRT(1) and FUTURE(4) capabilities
I agree about the columns being inflexible but personally I don't like enums. What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships? Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary. And it's annoying to support BC of the numbers once things change.
enums are an issue, since we want to share them. i agree services table seems the right approach, but actually, booleans are used here exactly because it seems services is the right long term approach, but we there is a lot of ground to cover before we know how they would look like. so boolean flags for the first few services, learning from these, designing the bigger service models, and upgrading to it from the cluster-with-flags seems (to me) the right path to take.
db scheme should be something that doesn't change every major, minor and z-stream version. It means we're doing something wrong. Having a 'gluster service' boolean column means that by definition we will be changing the db scheme for the next service we want to add or even for the same service but when we'll need some more info. To start with, we can just rely on the hosts themselves reporting capabilities and we can cache this info if we want it to display quickly next time we load. This would be similar to supported cpu types. If we have limitations on combining services then the first service utilized wins.
We plan to make following changes as part of the patch:
1) Introduce an upgrade script for adding following columns to the table "vds_groups" - virt_service - boolean - NOT_NULL - default value true - gluster_service - boolean - NOT_NULL - default value false
=> What is the naming convention for naming the upgrade script? Is it <major-version>_<minor-version>_<running-sequence-with-step-10>_script_description.sql ? By that logic, the name of our script will be something like 03_01_0560_add_service_columns_to_vds_groups.sql
Correct. Make sure to verify script sequence uniqueness (under ovirt-engine/backend/manager/dbscripts/upgrade) before pushing, since there is no enforcement for that.
2) Modify vds_groups_sp.sql to introduce these arguments / variables in save and update methods
3) Modify the DAO interface and implementation to introduce these arguments / variables in the save/update methods and VdsGroupRawMapper.
4) Modify the DAO JUnit test class to take care of these new fields, if required.
As part of DAO unit-test you should add the new columns and possible data to ovirt-engine/backend/manager/modules/dal/src/test/resources/fixtures.xml
5) Modify class VDSGroup to introduce the two new boolean variables virtService and glusterService and modify the methods equals and hashCode to use these.
=> One question here. Most of the attributes of class VDSGroup have annotations like @XmlElement and @Column. I think these are related to jaxb and JPA. Are these annotations really required? If yes, how are they useful?
@XmlElement annotations could be deleted from that file as a prior patch to the patch-set.
JPA annotations could be ignored as not fully supported nor maintained.
6) REST API : Default populate these variables (virtService = true, glusterService = false) before invoking the BLL command (AddVdsGroupCommand / UpdateVdsGroupCommand). This makes sure that the existing API won't break. No change in api.xsd for now.
7) webadmin create cluster code: Default populate the new variables, same as above. No change in UI screen for now.
=> Alternatively, the variable declaration on VDSGroup itself can initialize these variables with default values, so that changes to UI / REST API code (points 6 and 7) may not be required immediately. What do you suggest?
Inputs / comments / suggestions welcome.
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
On 03/04/2012 11:42 PM, Ayal Baron wrote:
----- Original Message -----
On 03/04/2012 03:22 PM, Ayal Baron wrote:
----- Original Message -----
----- Original Message -----
From: "Moti Asayag"<masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote:
Hi,
In order to identify whether a cluster exposes Gluster / Virtualization capabilities, we plan to introduce two boolean columns - virt_service and gluster_service in the vds_groups table. As per immediate plans, it is intended to support only one service per cluster, meaning only one of these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and routine refactoring to our DAL. Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of is a cluster with VIRT(1) and FUTURE(4) capabilities
I agree about the columns being inflexible but personally I don't like enums. What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships? Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary. And it's annoying to support BC of the numbers once things change.
enums are an issue, since we want to share them. i agree services table seems the right approach, but actually, booleans are used here exactly because it seems services is the right long term approach, but we there is a lot of ground to cover before we know how they would look like. so boolean flags for the first few services, learning from these, designing the bigger service models, and upgrading to it from the cluster-with-flags seems (to me) the right path to take.
db scheme should be something that doesn't change every major, minor and z-stream version. It means we're doing something wrong. Having a 'gluster service' boolean column means that by definition we will be changing the db scheme for the next service we want to add or even for the same service but when we'll need some more info. To start with, we can just rely on the hosts themselves reporting capabilities and we can cache this info if we want it to display quickly next time we load. This would be similar to supported cpu types. If we have limitations on combining services then the first service utilized wins.
we can't rely on hosts providing this info, as we want to provision them, and need to know what to provision them with / monitor for. i don't see the db scheme not changing between versions (not even sure we defined a concept of major or minor versions, we just said we'll have a version every 6 months). as for backports of bug fixes to released versions, that's the only thing we managed to avoid in the past (i.e., so far, we didn't change db scheme when backporting patches, since dealing with upgrade is a nightmare in that case - but that doesn't mean distributions of ovirt will not stabilize on a version which is a mix of an upstream version and a few more patches/features, which may include a db change, and will have to maintain the upgrade from that.
----- Original Message -----
On 03/04/2012 11:42 PM, Ayal Baron wrote:
----- Original Message -----
On 03/04/2012 03:22 PM, Ayal Baron wrote:
----- Original Message -----
----- Original Message -----
From: "Moti Asayag"<masayag@redhat.com> To: engine-devel@ovirt.org Sent: Sunday, March 4, 2012 12:20:43 PM Subject: Re: [Engine-devel] Introducing virt / gluster flags at cluster level
On 03/01/2012 12:54 PM, Shireesh Anjal wrote: > Hi, > > In order to identify whether a cluster exposes Gluster / > Virtualization > capabilities, we plan to introduce two boolean columns - > virt_service > and gluster_service in the vds_groups table. As per immediate > plans, it > is intended to support only one service per cluster, meaning > only > one of > these two values can be true.
Couldn't there be additional future services in the future ? In that case perhaps worth considering enum for services, to be stored in a single service column, its values are: virt, gluster,...) instead of extending the vds_group table consistently when introducing new services (under the assumption no mix of services is allowed).
+1 for an Enum insteand of boolean columns. we have too much of that already and eventually we see long records and routine refactoring to our DAL. Also to make mixed configuration we can embrace bit fields which interacts very nice with Enums e.g a 5 value of is a cluster with VIRT(1) and FUTURE(4) capabilities
I agree about the columns being inflexible but personally I don't like enums. What if we need to support finer grained services? e.g. different topologies (active/passive, active/active etc) or other types of intricate relationships? Not to mention that looking at the raw data you don't undetstand what it means without holding a dictionary. And it's annoying to support BC of the numbers once things change.
enums are an issue, since we want to share them. i agree services table seems the right approach, but actually, booleans are used here exactly because it seems services is the right long term approach, but we there is a lot of ground to cover before we know how they would look like. so boolean flags for the first few services, learning from these, designing the bigger service models, and upgrading to it from the cluster-with-flags seems (to me) the right path to take.
db scheme should be something that doesn't change every major, minor and z-stream version. It means we're doing something wrong. Having a 'gluster service' boolean column means that by definition we will be changing the db scheme for the next service we want to add or even for the same service but when we'll need some more info. To start with, we can just rely on the hosts themselves reporting capabilities and we can cache this info if we want it to display quickly next time we load. This would be similar to supported cpu types. If we have limitations on combining services then the first service utilized wins.
we can't rely on hosts providing this info, as we want to provision them, and need to know what to provision them with / monitor for. i don't see the db scheme not changing between versions (not even
I think therein lies the problem. But at least changes should be incremental and not deprecate things every version... So as I mentioned on the patch, you could have a table which has 'clusterId, serviceType' and according to the serviceType(s) that this cluster is associated with dynamically provision whatever is required. By the way, what services would be enabled on the default cluster? What would ovirt-node register as?
sure we defined a concept of major or minor versions, we just said we'll have a version every 6 months). as for backports of bug fixes to released versions, that's the only thing we managed to avoid in the past (i.e., so far, we didn't change db scheme when backporting patches, since dealing with upgrade is a nightmare in that case - but that doesn't mean distributions of ovirt will not stabilize on a version which is a mix of an upstream version and a few more patches/features, which may include a db change, and will have to maintain the upgrade from that.
participants (8)
-
Ayal Baron -
Eli Mesika -
Itamar Heim -
Moti Asayag -
Omer Frenkel -
Roy Golan -
Shireesh Anjal -
Yair Zaslavsky