----- Original Message -----
From: "Livnat Peer" <lpeer(a)redhat.com>
To: "Malini Rao" <mrao(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad"
<omasad(a)redhat.com>, "Eldan Hildesheim"
<ehildesh(a)redhat.com>
Sent: Tuesday, July 2, 2013 2:00:03 AM
Subject: Re: [Engine-devel] VNIC profiles
On 07/01/2013 09:22 PM, Malini Rao wrote:
> Hi Livnat,
>
> My name is Malini Rao and I am the lead interaction designer dedicated to
> RHEV/Ovirt UX from Red Hat and we have another interaction designer Eldan
> Hildeshiem who is also focused on RHEV UX.
Hi Malini - nice to e-meet you :)
> I went over your feature page and in general, the GUI proposals look great.
> I do have some quick feedback comments -
Just a small credit correction - the feature page is Ofri's feature
page, I added some feedback of my own :)
Sorry about that! Ofri, I look forward to collaborating with you and I hope we can
contribute to this feature from the UX/ usability perspective.
>
> Will there be any predefined profiles available to the users out of the box
> in RHEV? Or will they have to define their own?
If you start with a clean install setup there are no predefined vNICs
profiles.
Profiles can be generated in two flows, a user can explicitly generate a
profile or when admin network creates a new network he can mark create a
profile for this network** in a single action.
A VNIC profile is the link between the abstract network entity and the
VM which consumes this network.
If you upgrade existing setup, in the upgrade process profiles will be
created per network and will be attached to the VNICs that are currently
using the network.
So you are saying any VNIC profiles created and the associations with VMS that already
exist will be preserved during Upgrades... correct? But none of these need to be
pre-defined ( as in something that was available to the user automatically and not via
user action)... correct?
**This is not accurate, the user would be able to check all relevant
VNIC-QoS-entities and for each one we need to create a profile.
So there are two concepts here - VNIC-QoS-entities and VNIC Profiles?
> I am wondering if there are any common standard QoS levels that can be
> predefined and the users can get a heeadstart and use or tweak instead of
> defining from scratch.
That's a very good point.
The wiki page is not fully up to date, I think.
Ofri wanted to add an entity of VNIC QoS which would be linked from
within the VNIC profile.
The VNIC QoS entity is located in the entities hierarchy under Data Center.
The point you made, I think, is will we have predefined VNIC QoS entities.
The Qos entity is tight to the hardware you have in your DC. If you have
10G or 1G Ethernet links the QoS entities would look very different, so
I'm not sure what predefined values would look like.
So are you saying that we can have pre-defined VNIC Qos Entities like Gold, silver etc.
but not VNIC profiles because what is gold for a 10G Ehternet is different from gold for a
1G Ethernet? But even if they are different, can the VNIC profiles not also be auto
generated based on the Hardware and the VNIC Qos Entities?
>
> VNIC level QoS dialog
>
> 1. Will the Outbound and inbound values come with some defaults? Or will
> they be empty? Is there a need for any spinners or drop downs for
> frequently used values or is it ok to just have fields to type in the
> numeric values? Also I am assuming there is some kind of validation to
> ensure only numbers an be entered in these fields.
>
> 2. For custom properties, why do we have a drop down? Can custom properties
> defined elsewhere be accessed here and applied? If not, then I am assuming
> this will have to be a text field. Correct? Also, I am guessing if there
> is only one custom property field, the [-] icon will be disabled.
>
> Edit Network Interface Dialog
> 1. It will be awesome if under the Profile Field value, you can present a
> short summary of the profile in gray text. alternately, there can be a
> little info icon which will present this info on hover. This will help
> people who pick Gold know what that means vs silver or any other profile.
>
> Besides these specific feedback, I am wondering if any of the VM dialogs
> are affected by this? Will a VNIC profile field now show up on those
> dialogs as well?
>
> I see you have identified a bunch of open issues to work out and we will be
> more than happy to help you with the GUI for these flows as needed. Please
> feel free to reach out to Eldan and me and we can post back to the group
> with our work.
>
Thank you Malini for the above feedback, I think these are good questions.
Ofri - can you comment on the above ?
Looking forward to some of the answers to the questions above.
Livnat
> Thanks
> Malini
>
>
>
>
> ----- Original Message -----
> From: "Livnat Peer" <lpeer(a)redhat.com>
> To: "engine-devel" <engine-devel(a)ovirt.org>, "Ofri Masad"
> <omasad(a)redhat.com>
> Sent: Sunday, June 30, 2013 8:59:37 AM
> Subject: [Engine-devel] VNIC profiles
>
> Hi,
>
> We are working on adding VNIC profiles as part of the work to add VNIC QoS.
>
>
http://www.ovirt.org/Features/Network_QoS#VNIC_Profiles
>
> We need to define some of the system behavior followed by this change,
> here is my take -
>
> Editing a profile -
> --------------------
> A user should be able to edit the profile properties (including profile
> name) while VMs are attached and are using this Profile (reference
> should be done by id).
>
> Changing the network though is a bit more tricky as long as we don't
> have a way to distinguish between running and current configurations I
> think it could be very confusing to the user. Especially since we
> support dynamic wiring so the behavior IMO is unpredictable.
> I think it should be blocked at this point.
>
>
> Edit a VNIC / change a VNIC profile -
> ------------------------------------
> Changing the profile a VM is using while the VM is running should behave
> like dynamic wiring (changing the VM network while it is running).
>
>
> Remove a Profile -
> -------------------
> Is only valid if all VMs that are using this profile are in status down.
> It should update all VMs to point to no profile which should behave like
> none network today.
>
> I see no reason to support a profile on a none network at this point.
>
> The above is also relevant for upgrade flow (upgrading none network to
> point to no profile)
>
>
> Removing a Network -
> ----------------------
> should remove all profiles on that network
>
>
> VM snapshot/import/export -
> --------------------------
> We should handle VMs that are pointing to a network directly for b/w
> compatibility.
> we need to select first profile that is on that network that the user
> has permissions on.
>
>
> I assume there are more, comments are welcome
>
> Thanks, Livnat
>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
>
http://lists.ovirt.org/mailman/listinfo/engine-devel
>