Hi Alona,
I reviewed the DD of wired/unwired and I have a few questions/comments -
1. update vnic while the VM is running should be limited to cluster 3.2
(except for plug/unplug)
2. RunVM - why do we need to pass the 'linkState' property to VDSM? I
think that if the link is down we should pass none as the network and if
the link is up we should pass the network name, like we did so far. the
link-state is internal implementation detail in the engine.
3. looking on the VDSM API -
* why do we need 'type' ?
* why do we need 'device'?
* why do we need 'alias'?
* As I wrote I think we don't need 'linkState'
4. I am missing the error handling description when the user performs -
Update Vnic while changing the type for example. What is the behavior if
we succeed to unplug but not plug after that, etc.
5. Updated APIs section -This section is based on the fact that we pass
linkstate to vdsm which is not needed IMO, so if we change that this
section should be updated accordingly.
6. The EVENT section is empty, what events should be issued to audit log?
I think we should have an even for update vnic and if plug/unplug is
required a second event should be issued.
7. why does link state is varchar in DB? you expect to support other
option in addition to up/Down (which can be represented by 1 bit), maybe
n/a status?
8. About the open issues-
* About deprecation of ActivateDeactivateVmNic command - I think that
we should remove this command from the backend to avoid duplicate flows
and bugs etc. for Backwards compatibility we should update the clients
to use the new UpdateVmNetworkInterface. the down side for that is we
have to make the can do action validation more complicated (according to
cluster level etc.)
* If we remove ActivateDeactivateVmNic there is no need to rename it ;)
Thanks, Livnat