Bug 817793 - REST API: an Empty <usage/> element shouldn't be displayed
REST API: an Empty <usage/> element shouldn't be displayed
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi (Show other bugs)
3.0.0
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Mike Kolesnik
Yaniv Kaul
network
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-01 06:23 EDT by Avi Tal
Modified: 2016-04-22 01:00 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-26 07:26:41 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Avi Tal 2012-05-01 06:23:51 EDT
Description of problem:
Logical network element shouldn't display an empty <usage/> element.
          <network href="/api/networks/b3f8dc81-7ae5-4d65-91e1-3ac03c43a27c" id="b3f8dc81-7ae5-4d65-91e1-3ac03c43a27c">
                    <name>sw2</name>
                    <description>my desc</description>
                    <data_center href="/api/datacenters/d1a3aa09-15d4-4131-9dc6-6575925c8177" id="d1a3aa09-15d4-4131-9dc6-6575925c8177"/>
                    <stp>false</stp>
                    <status>
                            <state>non_operational</state>
                    </status>
                    <mtu>900</mtu>
                    <usages/>
                    <required>false</required>
            </network>
Comment 2 Simon Grinberg 2012-08-26 05:25:45 EDT
What I fail to understand is what does 'Empty' stands for in the first place.
Does it mean bridge-less non display network? 

In any case a network always has a usage - if no usage is provided then it should be clearly stated: Maybe General-Purpose is a good term

What is the default value if this field is not sent during creation? This should be VM-network if you want to preserve backward compatibility with 3.0.
Comment 3 lpeer 2012-08-26 06:32:16 EDT
After discussing with QE we think the best approach is:

- If the user does not specify 'usages' in: 
 * update (PUT) we leave the values unchanged
 * new (Post) we use defaults (VM network, non display)

- If the user sends empty xml element (<usages/>) for both update and new we use NON-VM non display network.


This is the current behaviour, please reopen if you think this behaviour is problematic/ not intuitive to our users.
Comment 4 Simon Grinberg 2012-08-26 07:03:38 EDT
(In reply to comment #3)
> - If the user sends empty xml element (<usages/>) for both update and new we
> use NON-VM non display network.

So 'Empty' ==  "NON-VM non display network".
And in the future? Non-VM, non-Storage, non-migration, non display, non-something else?

Some more questions:
1. If he does not send this at all what does it defaults too?
2. Is management network (rhevm) also a usage?
3. Is this field mandatory? - If so then yes this is confusing, to send empty to indicate no specific usage. I don't think it's done anywhere except for actions.

Reopening to keep discussion going.
Comment 5 Simon Grinberg 2012-08-26 07:26:41 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > - If the user sends empty xml element (<usages/>) for both update and new we
> > use NON-VM non display network.
> 
Answering my own questions since I misunderstood the response on comment #3

> So 'Empty' ==  "NON-VM non display network".
> And in the future? Non-VM, non-Storage, non-migration, non display,
> non-something else?

Yes.
 
> Some more questions:
> 1. If he does not send this at all what does it defaults too?

(VM network, non display) On POST, No-Change on PUT

> 2. Is management network (rhevm) also a usage?

No, but should be in the future.

> 3. Is this field mandatory? - If so then yes this is confusing, to send
> empty to indicate no specific usage. I don't think it's done anywhere except
> for actions.

No.

> 
> Reopening to keep discussion going.

I'm still not happy with that but it makes sense not to change it for the near version. I would say that we probably need to explicitly state 'None'. In the future when more meaningful usages be available (like storage, it may the indication of a network that is managed by the engine but has from any reason has no specific usage by the RHEV system.

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