On 07/03/2013 07:42 PM, Malini Rao wrote: > ----- Original Message ----- >> From: "Livnat Peer" <lp...@redhat.com> >> To: "Malini Rao" <m...@redhat.com> >> Cc: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" >> <oma...@redhat.com>, "Eldan Hildesheim" >> <ehild...@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? >
correct x2 >> >> **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? > correct again :) > >> >> >>> 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. I am saying it is something that Ofri should consider, although I personally don't think there is an added value in having a pre-defined VNIC Qos. > but not VNIC profiles because what is gold for a 10G Ehternet is different > from gold for a 1G Ethernet? VNIC profile is associated with a specific Network, so technically we can't have pre-defined profiles as we don't have predefined Networks. Well, we do have the management network (which is predefined) and for that we do need to create a predefined profile - Thanks. This point out another behavior we should document, when removing the VM-network role from a network we need to remove the profiles associated with that network. (Moti, can you capture this in the VNIC profile wiki as well) > But even if they are different, can the VNIC profiles not also be auto > generated based on the Hardware and the VNIC Qos Entities? > I lost you here, can you please elaborate. >> >>> >>> 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" <lp...@redhat.com> >>> To: "engine-devel" <engine-devel@ovirt.org>, "Ofri Masad" >>> <oma...@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@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> > _______________________________________________ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
