reporting and removing unmanaged networks after deprecating org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
6:21 a.m.
Hi,
I'd like to discuss how to properly report unmanaged networks and how to ask for their
removal after
org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
is removed.
We thought about several possibilities and so far the best one is following one.
Reporting unmanaged networks on specific nic:
———————————————————————————————————————————————
We'd like to return new collection under:
GET http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks
returning (reporting) unmanaged networks like this:
<unmanaged_networks>
<unmanaged_network>
<nic_name>...</nic_name>
<unmanaged_network_name>...</unmanaged_network_name>
<vland_id>...</vland_id>
</unmanaged_network>
<unmanaged_network>
...
</unmanaged_network>
</unmanaged_networks>
Removing unmanagedNetworks:
—————————————————————————————
DELETE
http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks/{unmanag...
=======================
any ideas, hints, complaints, recommendations, confirmations are welcomed.
Martin.
7:19 a.m.
On 02/02/15 14:21, Martin Mucha wrote:
Hi,
I'd like to discuss how to properly report unmanaged networks and how to ask for
their removal after
org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
is removed.
We don't actually have to remove the command, but I'd prefer not to
support two APIs at once (reminding that we'll be introducing new host
networking API in 3.6).
If I'm not mistaken, removing unmanaged networks is the only operation
the current design of the new API doesn't take care of... Right Moti?
We thought about several possibilities and so far the best one is following one.
Reporting unmanaged networks on specific nic:
———————————————————————————————————————————————
We'd like to return new collection under:
GET http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks
In my opinion it might be more convenient at part of
/api/hosts/{id}/unmanagednteworks - maybe going deeper isn't necessary.
returning (reporting) unmanaged networks like this:
<unmanaged_networks>
<unmanaged_network>
<nic_name>...</nic_name>
<unmanaged_network_name>...</unmanaged_network_name>
<vland_id>...</vland_id>
</unmanaged_network>
<unmanaged_network>
...
</unmanaged_network>
</unmanaged_networks>
Removing unmanagedNetworks:
—————————————————————————————
DELETE
http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks/{unmanag...
=======================
any ideas, hints, complaints, recommendations, confirmations are welcomed.
Martin.
7:57 a.m.
----- Original Message -----
From: "Lior Vernia" <lvernia(a)redhat.com>
To: "Martin Mucha" <mmucha(a)redhat.com>
Cc: devel(a)ovirt.org, Users(a)ovirt.org, "Moti Asayag" <masayag(a)redhat.com>,
"Juan Antonio Hernandez Fernandez"
<jhernand(a)redhat.com>
Sent: Monday, February 2, 2015 3:19:13 PM
Subject: Re: reporting and removing unmanaged networks after deprecating
org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
On 02/02/15 14:21, Martin Mucha wrote:
> Hi,
>
> I'd like to discuss how to properly report unmanaged networks and how to
> ask for their removal after
> org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
> is removed.
We don't actually have to remove the command, but I'd prefer not to
support two APIs at once (reminding that we'll be introducing new host
networking API in 3.6).
If I'm not mistaken, removing unmanaged networks is the only operation
the current design of the new API doesn't take care of... Right Moti?
The proposed design for the new host networking api is consistent with the
vdsm api, as long as a network can be identified by its id (uuid).
The only case which isn't supported is performing an action for a network
which cannot be identified by its id, i.e. unmanaged networks.
This also requires from the engine to manage the relevant unmanaged networks
entries when 'getVdsCaps' is called, and network configuration is persisted.
But this goes more into the detailed design section.
>
> We thought about several possibilities and so far the best one is following
> one.
>
> Reporting unmanaged networks on specific nic:
> ———————————————————————————————————————————————
>
> We'd like to return new collection under:
> GET http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks
In my opinion it might be more convenient at part of
/api/hosts/{id}/unmanagednteworks - maybe going deeper isn't necessary.
+1, also there is a case where a network is not attached to any nic (nicless
network)
also add:
GET
http://localhost:8080/api/hosts/{id}/unmanagednetworks/{unmanaged_network...
>
> returning (reporting) unmanaged networks like this:
>
> <unmanaged_networks>
> <unmanaged_network>
> <nic_name>...</nic_name>
I'd define this element as an optional and would replace it with <host_nic>
which
represents either nic_name or nic_id.
>
<unmanaged_network_name>...</unmanaged_network_name>
I'd replace this simply by name, which should also be the unique identifier of the
network on a single host.
> <vland_id>...</vland_id>
I'm not sure if we should maintain any further information about that network.
All we care of is removing it.
> </unmanaged_network>
>
> <unmanaged_network>
> ...
> </unmanaged_network>
> </unmanaged_networks>
>
>
> Removing unmanagedNetworks:
> —————————————————————————————
>
> DELETE
>
http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks/{unmanag...
respectively replace with:
DELETE
http://localhost:8080/api/hosts/{id}/unmanagednetworks/{unmanaged_network...
>
>
> =======================
>
> any ideas, hints, complaints, recommendations, confirmations are welcomed.
> Martin.
>
3367
days inactive
3368
days old
2 comments
3 participants
participants (3)
-
Lior Vernia -
Martin Mucha -
Moti Asayag