Bug 1376487 - Instance type nics behaviour in webadmin is inconsistent with API
Summary: Instance type nics behaviour in webadmin is inconsistent with API
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt
Version: 4.0.4.1
Hardware: Unspecified
OS: Unspecified
unspecified
low vote
Target Milestone: ---
: ---
Assignee: Michal Skrivanek
QA Contact: meital avital
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-15 14:40 UTC by sefi litmanovich
Modified: 2022-06-30 08:03 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-14 14:05:14 UTC
oVirt Team: Virt
sbonazzo: ovirt-4.2-


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-46758 0 None None None 2022-06-30 08:03:09 UTC

Description sefi litmanovich 2016-09-15 14:40:28 UTC
Description of problem:

In webadmin in create/edit There's an option to add a nic based on a vnic profile.
the description of the option: 'Instantiate VM network interfaces by picking a vNIC profile.'
In practice the behaviour of this option is not consistent with the API and not sure that it's working as it was designed to work.

1. Upon instance type creation the vnic_profile drop down list contains only EMPTY vnic_profile, while there are several vnic profiles in the system in practice. Creating the 'EMPTY' nic will result with a nic with the default values and cannot be edited in UI.
In the API there's no problem to add nics to the instance type with any vnic_profile existing in the system.

2. Edit instance type menu seems to block the option to add a new nic or chance the profile of the old one, again this doesn't reflect the behaviour of the API and furthermore the actual edit box of the profile name isn't greyed out and one can write anything in it (although it won't be saved anywhere).

Not sure what to expect from this option, either it should be limited and to such and such constraints and in that case it should be reflected in API, or the other way around and the webadmin behaviour should be aligned with that of the API.

Possible reason: a vnic profile will always be coupled with a certain network, which will always belong to a certain data center. An instance type has no data-center/cluster and so the list is empty because it probably searches in DC= None (didn't look at code yet, doesn't seem too crucial). 

In the API on the other hand I was free to add a nic to the instance type with any vnic_profile I wanted from any data center, this makes more sense for a system level component
and the system also knows how to dill with it when creating a vm from that instance type, it will show the nic that was created with the vnic pofile outside the vm's datacenter, but the profile is set to 'EMPTY', so the filter works in vm level.

Version-Release number of selected component (if applicable):
rhevm-4.0.4.2-0.1.el7ev.noarch

How reproducible:
always

No useful messages was found in the logs.

Comment 1 Tomas Jelinek 2016-09-21 07:14:15 UTC
The instance type should be responsible only for the parts which are not bound to system (like num of CPUs or memory size etc). Mostly hardware but not only.
For nics, it should be only the definition of the nics, not the binding of the nics to profiles (that is why only the <Empty> is there).

So, I see the following issues here:
- the API allows to set other than <Empty> profiles (should be fixed by validation on the engine)
- the edit instance type should allow the editing of the profiles

Comment 2 Tomas Jelinek 2017-08-14 14:05:14 UTC
Instance types are not really used and the consequence is not important.

Closing due to capacity - please feel free to reopen if you disagree.


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