Bug 949524
| Summary: | [RFE] Template resource allocation property should be listed in API | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Ido Begun <ibegun> |
| Component: | ovirt-engine-restapi | Assignee: | Michal Skrivanek <michal.skrivanek> |
| Status: | CLOSED WONTFIX | QA Contact: | Shai Revivo <srevivo> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 3.2.0 | CC: | bazulay, bsettle, dfediuck, iheim, michal.skrivanek, oramraz, rbalakri, Rhev-m-bugs, sherold |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | Flags: | sherold:
Triaged+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | virt | ||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-11-17 16:00:43 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 926966 | ||
| Bug Blocks: | |||
actually I think this should be "sla". Not sure if we want to show anything more, Doron? I do not see templates have it in the UI as well. Can you be more specific on what information you want to provide? (In reply to Doron Fediuck from comment #5) > I do not see templates have it in the UI as well. > Can you be more specific on what information you want to provide? As for UI: https://bugzilla.redhat.com/show_bug.cgi?id=926966 I'd expect to be able to view and edit the memory guaranteed (which is not possible in UI/API) (In reply to Ido Begun from comment #6) > (In reply to Doron Fediuck from comment #5) > > I do not see templates have it in the UI as well. > > Can you be more specific on what information you want to provide? > > As for UI: https://bugzilla.redhat.com/show_bug.cgi?id=926966 > > I'd expect to be able to view and edit the memory guaranteed (which is not > possible in UI/API) Thanks Ido. So I have some insights on this one. First of all BZ name is about resource allocation, and guarantees are tunable related and not the actual allocation. This is something that I'd change specifically per VM and not as a general rule for the template, as in most cases it may be policy related. I think there's a good reason for not having this functionality in a template both in UI and in the API. Adding Andy to get his point of view- do we have a real use case for it? (In reply to Doron Fediuck from comment #7) > ... > > Thanks Ido. > So I have some insights on this one. > First of all BZ name is about resource allocation, and guarantees are > tunable related and not the actual allocation. > This is something that I'd change specifically per VM and not as a general > rule for the template, as in most cases it may be policy related. > > I think there's a good reason for not having this functionality in a > template both in UI and in the API. > Adding Andy to get his point of view- do we have a real use case for it? If that's the case, why do we even bother saving this property in DB? Currently, creating a template from a VM with specific resource allocation//guaranteed memory is inherited to the template (and in turn, to any VM derived from that template). This shouldn't be saved at all if that's something you'd want to change manually per VM. If this property is saved, then we should have access to it. (In reply to Ido Begun from comment #8) > (In reply to Doron Fediuck from comment #7) > > ... > > > > Thanks Ido. > > So I have some insights on this one. > > First of all BZ name is about resource allocation, and guarantees are > > tunable related and not the actual allocation. > > This is something that I'd change specifically per VM and not as a general > > rule for the template, as in most cases it may be policy related. > > > > I think there's a good reason for not having this functionality in a > > template both in UI and in the API. > > Adding Andy to get his point of view- do we have a real use case for it? > > If that's the case, why do we even bother saving this property in DB? > Currently, creating a template from a VM with specific resource > allocation//guaranteed memory is inherited to the template (and in turn, to > any VM derived from that template). > This shouldn't be saved at all if that's something you'd want to change > manually per VM. If this property is saved, then we should have access to it. I see a reason in keeping the original VM's properties, which is what the user expect to get when creating a VM from the template. Otherwise it looses consistency. As for changes, the user may modify it per VM as these are very specific attributes. So the simple way most users will use it are to create a template and then create a vm from the template, while adjusting specific tunables as needed. (In reply to Doron Fediuck from comment #9) > (In reply to Ido Begun from comment #8) > > (In reply to Doron Fediuck from comment #7) > > > ... > > > > > > Thanks Ido. > > > So I have some insights on this one. > > > First of all BZ name is about resource allocation, and guarantees are > > > tunable related and not the actual allocation. > > > This is something that I'd change specifically per VM and not as a general > > > rule for the template, as in most cases it may be policy related. > > > > > > I think there's a good reason for not having this functionality in a > > > template both in UI and in the API. > > > Adding Andy to get his point of view- do we have a real use case for it? > > > > If that's the case, why do we even bother saving this property in DB? > > Currently, creating a template from a VM with specific resource > > allocation//guaranteed memory is inherited to the template (and in turn, to > > any VM derived from that template). > > This shouldn't be saved at all if that's something you'd want to change > > manually per VM. If this property is saved, then we should have access to it. > > I see a reason in keeping the original VM's properties, which is what the > user expect to get when creating a VM from the template. Otherwise it looses > consistency. As for changes, the user may modify it per VM as these are very > specific attributes. So the simple way most users will use it are to create > a template and then create a vm from the template, while adjusting specific > tunables as needed. i think this approach a bit problematic, and not sure we want these properties in the template, take a placement_policy for interface, - one creating vm from the template and not aware of placement_policy/it's impacts, may end-up with all VMs attached to specific host without any ability to migrate, i.e no HA, disaster recovery will happen upon host failure, load balanicing issues will take place etc. - another aspect of this that should be considered is a permissions for these properties, i.e they will force admins to give extra permissions for users in order to be able creating vms, and i'm not sure we want that, as these are pure admin features (btw we will break APIs doing that ...) Moving to 3.4. Please consider the various results, such as loosing a license to some guests due to CPU changes. *** Bug 926966 has been marked as a duplicate of this bug. *** Nothing changed and I still support Michael's view as explained in comment 10. Closing this issue as we have no current plans to change it. |
Description of problem: Template resource allocation should be listed in API: <template> ... <memory_policy> <guaranteed>...</guaranteed> </memory_policy> ... </template> Version-Release number of selected component (if applicable): rhevm-3.2.0-10.18.beta2