[Engine-devel] [engine-devel] instance type as top-level entity
Hey all, I have started to work on the instance types[1] again and hit an issue. Since the instance types are supposed to be top-level entities (e.g. without the connection to DC/Cluster) but they are modeled as templates it is not possible to store them to DB since the DB constraints violation on vm_static table (e.g. the vds_group_id has to be unique and point to an existing vds_group). So, I see 4 options: 1: drop the constraints on the vm_static.vds_group_id (the vds_groups_vm_static constraint) (most simple approach but would open the door to some issues which are now guard on the DB level) 2: do the same magic [well, hacks :) ] as with the "blank" template which is in the same situation (not exactly a nice solution to have the instance types wired to one specific cluster just to satisfy the constraint but return them all the time) 3: do not store this data in vm_static but create some new table called e.g. instance_type which would contain all of the fields from vm_static which are needed by it (actually the best approach AFAIK but to do it correctly it would require some more refactoring to do some hierarchy of tables and not copy the fields from table to table) 4: make the instance types not top-level (e.g. bound to specific DC/Cluster) (would bring some issues for example with the default instance types which should be present for all the DC/Clusters) Thoughts? Thank you, Tomas [1]: http://www.ovirt.org/Features/Instance_Types
----- Original Message -----
From: "Tomas Jelinek" <tjelinek@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Omer Frenkel" <ofrenkel@redhat.com> Sent: Wednesday, December 4, 2013 2:14:06 PM Subject: [engine-devel] instance type as top-level entity
Hey all,
I have started to work on the instance types[1] again and hit an issue. Since the instance types are supposed to be top-level entities (e.g. without the connection to DC/Cluster) but they are modeled as templates it is not possible to store them to DB since the DB constraints violation on vm_static table (e.g. the vds_group_id has to be unique and point to an existing vds_group).
So, I see 4 options:
1: drop the constraints on the vm_static.vds_group_id (the vds_groups_vm_static constraint) (most simple approach but would open the door to some issues which are now guard on the DB level)
2: do the same magic [well, hacks :) ] as with the "blank" template which is in the same situation (not exactly a nice solution to have the instance types wired to one specific cluster just to satisfy the constraint but return them all the time)
3: do not store this data in vm_static but create some new table called e.g. instance_type which would contain all of the fields from vm_static which are needed by it (actually the best approach AFAIK but to do it correctly it would require some more refactoring to do some hierarchy of tables and not copy the fields from table to table)
4: make the instance types not top-level (e.g. bound to specific DC/Cluster) (would bring some issues for example with the default instance types which should be present for all the DC/Clusters)
Thoughts?
Thank you, Tomas
according to the wiki (and discussions we had) instance type is bounded to a cluster (even if only as a changeable default) so i dont think there is an issue..
On 12/04/2013 02:17 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Tomas Jelinek" <tjelinek@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Omer Frenkel" <ofrenkel@redhat.com> Sent: Wednesday, December 4, 2013 2:14:06 PM Subject: [engine-devel] instance type as top-level entity
Hey all,
I have started to work on the instance types[1] again and hit an issue. Since the instance types are supposed to be top-level entities (e.g. without the connection to DC/Cluster) but they are modeled as templates it is not possible to store them to DB since the DB constraints violation on vm_static table (e.g. the vds_group_id has to be unique and point to an existing vds_group).
So, I see 4 options:
1: drop the constraints on the vm_static.vds_group_id (the vds_groups_vm_static constraint) (most simple approach but would open the door to some issues which are now guard on the DB level)
2: do the same magic [well, hacks :) ] as with the "blank" template which is in the same situation (not exactly a nice solution to have the instance types wired to one specific cluster just to satisfy the constraint but return them all the time)
3: do not store this data in vm_static but create some new table called e.g. instance_type which would contain all of the fields from vm_static which are needed by it (actually the best approach AFAIK but to do it correctly it would require some more refactoring to do some hierarchy of tables and not copy the fields from table to table)
4: make the instance types not top-level (e.g. bound to specific DC/Cluster) (would bring some issues for example with the default instance types which should be present for all the DC/Clusters)
Thoughts?
Thank you, Tomas
according to the wiki (and discussions we had) instance type is bounded to a cluster (even if only as a changeable default) so i dont think there is an issue..
where in the wiki please? the way i read the wiki its DC level, just like templates?
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com>, "Tomas Jelinek" <tjelinek@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 4, 2013 5:29:57 PM Subject: Re: [Engine-devel] [engine-devel] instance type as top-level entity
On 12/04/2013 02:17 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Tomas Jelinek" <tjelinek@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Omer Frenkel" <ofrenkel@redhat.com> Sent: Wednesday, December 4, 2013 2:14:06 PM Subject: [engine-devel] instance type as top-level entity
Hey all,
I have started to work on the instance types[1] again and hit an issue. Since the instance types are supposed to be top-level entities (e.g. without the connection to DC/Cluster) but they are modeled as templates it is not possible to store them to DB since the DB constraints violation on vm_static table (e.g. the vds_group_id has to be unique and point to an existing vds_group).
So, I see 4 options:
1: drop the constraints on the vm_static.vds_group_id (the vds_groups_vm_static constraint) (most simple approach but would open the door to some issues which are now guard on the DB level)
2: do the same magic [well, hacks :) ] as with the "blank" template which is in the same situation (not exactly a nice solution to have the instance types wired to one specific cluster just to satisfy the constraint but return them all the time)
3: do not store this data in vm_static but create some new table called e.g. instance_type which would contain all of the fields from vm_static which are needed by it (actually the best approach AFAIK but to do it correctly it would require some more refactoring to do some hierarchy of tables and not copy the fields from table to table)
4: make the instance types not top-level (e.g. bound to specific DC/Cluster) (would bring some issues for example with the default instance types which should be present for all the DC/Clusters)
Thoughts?
Thank you, Tomas
according to the wiki (and discussions we had) instance type is bounded to a cluster (even if only as a changeable default) so i dont think there is an issue..
where in the wiki please? the way i read the wiki its DC level, just like templates?
OK, it seems I have not asked the question correctly. Let me rephrase it: Since we are going to provide default (predefined) instance types which the user is not allowed to delete I assume this instance types should be available for the whole system (not only for the default cluster) just like blank template. This brings up a question if all the other instance types are going to be also system level and if yes, how are we going to solve it technically. We still have the option to implement the instance types as templates and the default instance types as blank template, but the question is if this is what makes most sense. The wiki currently says that the instance type is connected to cluster using vds_group_id field but as I have started some implementation this question popped up in my mind (not yet documented on wiki - will be according to the result of this discussion). BTW the question if the instance types are top level or not leads us to a different question - where to put them in GUI? - If the instance type is a top level entity the best place to have it is the configure dialog (top right corner) - If the instance type is not a top level entity the best place to have it is possibly a main tab (or part of the template main tab)
On 12/05/2013 09:40 AM, Tomas Jelinek wrote:
----- Original Message -----
From: "Itamar Heim" <iheim@redhat.com> To: "Omer Frenkel" <ofrenkel@redhat.com>, "Tomas Jelinek" <tjelinek@redhat.com> Cc: "engine-devel" <engine-devel@ovirt.org> Sent: Wednesday, December 4, 2013 5:29:57 PM Subject: Re: [Engine-devel] [engine-devel] instance type as top-level entity
On 12/04/2013 02:17 PM, Omer Frenkel wrote:
----- Original Message -----
From: "Tomas Jelinek" <tjelinek@redhat.com> To: "engine-devel" <engine-devel@ovirt.org> Cc: "Omer Frenkel" <ofrenkel@redhat.com> Sent: Wednesday, December 4, 2013 2:14:06 PM Subject: [engine-devel] instance type as top-level entity
Hey all,
I have started to work on the instance types[1] again and hit an issue. Since the instance types are supposed to be top-level entities (e.g. without the connection to DC/Cluster) but they are modeled as templates it is not possible to store them to DB since the DB constraints violation on vm_static table (e.g. the vds_group_id has to be unique and point to an existing vds_group).
So, I see 4 options:
1: drop the constraints on the vm_static.vds_group_id (the vds_groups_vm_static constraint) (most simple approach but would open the door to some issues which are now guard on the DB level)
2: do the same magic [well, hacks :) ] as with the "blank" template which is in the same situation (not exactly a nice solution to have the instance types wired to one specific cluster just to satisfy the constraint but return them all the time)
3: do not store this data in vm_static but create some new table called e.g. instance_type which would contain all of the fields from vm_static which are needed by it (actually the best approach AFAIK but to do it correctly it would require some more refactoring to do some hierarchy of tables and not copy the fields from table to table)
4: make the instance types not top-level (e.g. bound to specific DC/Cluster) (would bring some issues for example with the default instance types which should be present for all the DC/Clusters)
Thoughts?
Thank you, Tomas
according to the wiki (and discussions we had) instance type is bounded to a cluster (even if only as a changeable default) so i dont think there is an issue..
where in the wiki please? the way i read the wiki its DC level, just like templates?
OK, it seems I have not asked the question correctly. Let me rephrase it: Since we are going to provide default (predefined) instance types which the user is not allowed to delete I assume this instance types should be available for the whole system (not only for the default cluster) just like blank template.
I think it makes sense to allow instance type (both default and custom ones) at system level. would be nice to allow them at cluster level as well of course.
This brings up a question if all the other instance types are going to be also system level and if yes, how are we going to solve it technically. We still have the option to implement the instance types as templates and the default instance types as blank template, but the question is if this is what makes most sense.
if anything, i think everyone would appreciate if we remove the relation of Blank template to the default cluster so they can delete the default cluster...
The wiki currently says that the instance type is connected to cluster using vds_group_id field but as I have started some implementation this question popped up in my mind (not yet documented on wiki - will be according to the result of this discussion).
it does say so, but i think you are right and we should allow system level as well. cc-ing andrew who authored this page for his thoughts?
BTW the question if the instance types are top level or not leads us to a different question - where to put them in GUI? - If the instance type is a top level entity the best place to have it is the configure dialog (top right corner) - If the instance type is not a top level entity the best place to have it is possibly a main tab (or part of the template main tab)
well, the question is should we allow only system level (then configure is appropriate), or both system and cluster level, in which case a sub tab is more appropriate. i could live with: - only allow to configure instance types via configure (since its a rare operation, like configuring a role is). - allow to set default enable/disable for an instance type. - allow to set enable/disable override at cluster level, in which case, a subtab or a dialog at cluster level would do. as a side note, i think 'configure' dialogs should be moved from the configure button to a new tree node, and appear as tab panes when standing on this new configure node in the tree.
participants (3)
-
Itamar Heim -
Omer Frenkel -
Tomas Jelinek