Bug 1418664 - [RFE] Divide Vm/Template/Instance_type entities or reconstruct hierarchy
Summary: [RFE] Divide Vm/Template/Instance_type entities or reconstruct hierarchy
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: bugs@ovirt.org
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-02 12:59 UTC by sefi litmanovich
Modified: 2018-11-14 11:25 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-14 11:24:14 UTC
oVirt Team: Virt
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

Description sefi litmanovich 2017-02-02 12:59:40 UTC
Description of problem:
Currently the Vm, Instance type, and templates entities are of the same type and are created on top of each other the following manner:

VmBase - root type
|\
| \
|  \
Vm  Template
       |
       |
       |
     Instance type


Where e.g Vm and Template share also nics/watchdogs/cdroms and maybe other attributes I'm missing at the moment, and instance_type has no unique attributes of it's own.
In practice, if we even need the instance type entity, it is meant to serve as the most basic type which includes basic HW configurations and no nics/disks or other unique configurations or DC specific (as they are system wide entities). Templates provide additional configurations which are more specific and detailed and are a part of a certain DC, and Vms are naturally the unique entities which represent the actual machine configuration we want to run and should inherit it's configuration from the instance type and template it is based on.

Considering the practical usage of these entities, it seems to me  that they should be either totally separate or build on top of each other in the natural way as I see it which is: Instance type -> Template -> Vm.

It would be great to hear what other people think of this issue, especially developers of the product, and to understand if this kind of change is applicable at this point, could there be any practical benefits to it in terms of design of future features, might it fix existing issues that might be caused by the current design and so on.

Comment 1 Martin Tessun 2017-03-06 09:43:57 UTC
Just thinking about possible setups.
Overall this sounds reasonable, but you can create a VM without an instance type.
A Template on the other side does also not necessarily need an instance type.

I believe that the whole concept needs to be redesigned, as some settings from Instance Types do clash with Templates.

Overall I would try something like the following for differentiation between Templates and Instance Types:

- Instance Types should describe the hardware setup and placement options, including disks (no images, just sizes and SD to place them)
- Several instance Types can be connected to one or more Templates. (n:m relationship)
- The Template can "replace" the disks from the instance types by having image disks defined
  - A Template should not be able to change any other hardware from the instances.
  - Maybe also introducing "Images" that can be attached to the Templates
- a VM is built by choosing a Template (and then choosing one of the attached Instance Types).
- The VM can be adjusted in case it is allowed.
- Having some wizards that can do an Instance-Template pair in one dialogue setup.

Currently I think that Templates and Instances have too much in common and it is not clear when to use what.
It should also be possible to create a Template directly without the need of creating a VM first. With an "Imaging-service" it would also be possible to provide external images (e.g. via upload) directly (or use images provided by glance e.g.)

Comment 2 Ryan Barry 2018-11-14 11:24:14 UTC
This will not make it in a reasonable time. Please re-open if you still feel this should be fixed


Note You need to log in before you can comment on or make changes to this bug.