[Engine-devel] static header only in VM dialog?
Tomas Jelinek
tjelinek at redhat.com
Fri May 31 12:41:13 UTC 2013
Adding also Omer because he is doing the BE of the instance types feature.
----- Original Message -----
> From: "Michal Skrivanek" <michal.skrivanek at redhat.com>
> To: "Einav Cohen" <ecohen at redhat.com>
> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Eldan
> Hildesheim" <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>, "Eldan Hildesheim" <ehildesh at redhat.com>
> Sent: Friday, May 31, 2013 2:10:39 PM
> Subject: Re: [Engine-devel] static header only in VM dialog?
>
>
> On 31 May 2013, at 13:44, Einav Cohen wrote:
>
> >> ----- Original Message -----
> >> From: "Tomas Jelinek" <tjelinek at redhat.com>
> >> Sent: Friday, May 31, 2013 2:22:57 AM
> >>
> >>
> >>
> >> ----- Original Message -----
> >>> From: "Malini Rao" <mrao at redhat.com>
> >>> To: "Einav Cohen" <ecohen at redhat.com>
> >>> Cc: "Daniel Erez" <derez at redhat.com>, "Eldan Hildesheim"
> >>> <info at eldanet.com>, "engine-devel" <engine-devel at ovirt.org>,
> >>> "Eldan Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
> >>> <tjelinek at redhat.com>
> >>> Sent: Thursday, May 30, 2013 5:56:59 PM
> >>> Subject: Re: [Engine-devel] static header only in VM dialog?
> >>>
> >>> Sorry to join the thread late. The long weekend was followed by a
> >>> conference
> >>> for the UX team and hence the delay. See comments below inline -
> >>>
> >>> ----- Original Message -----
> >>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>> To: "Daniel Erez" <derez at redhat.com>
> >>>> Cc: "Eldan Hildesheim" <info at eldanet.com>, "engine-devel"
> >>>> <engine-devel at ovirt.org>, "Eldan Hildesheim"
> >>>> <ehildesh at redhat.com>, "Malini Rao" <mrao at redhat.com>, "Tomas Jelinek"
> >>>> <tjelinek at redhat.com>
> >>>> Sent: Wednesday, May 29, 2013 8:21:30 AM
> >>>> Subject: Re: [Engine-devel] static header only in VM dialog?
> >>>>
> >>>>> ----- Original Message -----
> >>>>> From: "Daniel Erez" <derez at redhat.com>
> >>>>> Sent: Wednesday, May 29, 2013 1:36:03 AM
> >>>>>
> >>>>>
> >>>>>
> >>>>> ----- Original Message -----
> >>>>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>>>> To: "Daniel Erez" <derez at redhat.com>, "Malini Rao" <mrao at redhat.com>,
> >>>>>> "Eldan Hildesheim" <info at eldanet.com>, "Eldan
> >>>>>> Hildesheim" <ehildesh at redhat.com>, "Tomas Jelinek"
> >>>>>> <tjelinek at redhat.com>
> >>>>>> Cc: "engine-devel" <engine-devel at ovirt.org>
> >>>>>> Sent: Wednesday, May 29, 2013 2:30:09 AM
> >>>>>> Subject: Re: static header only in VM dialog?
> >>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>> From: "Daniel Erez" <derez at redhat.com>
> >>>>>>> Sent: Tuesday, May 28, 2013 6:18:20 PM
> >>>>>>>
> >>>>>>>
> >>>>>>> ----- Original Message -----
> >>>>>>>> From: "Einav Cohen" <ecohen at redhat.com>
> >>>>>>>> To: "Malini Rao" <mrao at redhat.com>, "Eldan Hildesheim"
> >>>>>>>> <info at eldanet.com>,
> >>>>>>>> "Eldan Hildesheim" <ehildesh at redhat.com>
> >>>>>>>> Cc: "Tomas Jelinek" <tjelinek at redhat.com>, derez at redhat.com,
> >>>>>>>> "engine-devel"
> >>>>>>>> <engine-devel at ovirt.org>
> >>>>>>>> Sent: Wednesday, May 29, 2013 12:53:47 AM
> >>>>>>>> Subject: static header only in VM dialog?
> >>>>>>>>
> >>>>>>>> when reviewing the code for the "redesign of vm related dialogs",
> >>>>>>>> Daniel
> >>>>>>>> has
> >>>>>>>> raised an interesting question: Why do we want the static header
> >>>>>>>> only
> >>>>>>>> in
> >>>>>>>> VM
> >>>>>>>> dialog?
> >>>>>>>>
> >>>>>>>> (I assume that he refers to the top section of the New VM dialog
> >>>>>>>> as
> >>>>>>>> seen
> >>>>>>>> in
> >>>>>>>> [1], which
> >>>>>>>> contains the DC/Cluster, Quota, etc information, and is "static",
> >>>>>>>> i.e.,
> >>>>>>>> it
> >>>>>>>> is
> >>>>>>>> always
> >>>>>>>> displayed, regardless of the selected side-tab within the dialog)
> >>>>>>>>
> >>>>>>>> I agree with what Daniel is implying here: for consistency, we
> >>>>>>>> would
> >>>>>>>> probably
> >>>>>>>> want to
> >>>>>>>> introduce this static header to other dialogs, at least to the
> >>>>>>>> ones
> >>>>>>>> that
> >>>>>>>> also
> >>>>>>>> contain
> >>>>>>>> side-tabs in which it makes sense to turn the "header" to static
> >>>>>>>> [e.g.
> >>>>>>>> "New Host" (which contains a DC + Cluster "header") - see
> >>>>>>>> http://oi39.tinypic.com/2z84xnp.jpg,
> >>>>>>>> "New Cluster" (which contains a DC "header") - see
> >>>>>>>> http://oi40.tinypic.com/2vmyj2x.jpg]
> >>>
> >>> MR: Consistency is important but we need to make only UIs with similar
> >>> purposes consistent and not aim for consistency where it will not serve a
> >>> real Usability goal or worse get in the way. See next comment for more on
> >>> UX
> >>> motivation for this static panel for new VM creation where it was
> >>> originally
> >>> proposed.
> >>>
> >>>
> >>>>>>>>
> >>>>>>>> [I assume, of course, that all the VM-like dialogs (e.g. New/Edit
> >>>>>>>> VM-Pool)
> >>>>>>>> will also have
> >>>>>>>> static headers - I don't know if the patch already takes care of
> >>>>>>>> that
> >>>>>>>> or
> >>>>>>>> not]
> >>>>>>>>
> >>>>>>>> Thoughts?
> >>>>>>>>
> >>>>>>>> [@Daniel - if you had something else in mind, and/or other
> >>>>>>>> dialogs
> >>>>>>>> in
> >>>>>>>> mind
> >>>>>>>> -
> >>>>>>>> please feel free
> >>>>>>>> to add/amend/etc]
> >>>
> >>> MR: Before we proliferate this UI paradigm into other areas, let us look
> >>> at
> >>> the list of dialogs where we are considering this against the primary UX
> >>> motivations with which this static panel was originally suggested. UX can
> >>> help with this exercise on where it makes sense to have the static panel.
> >>>
> >>>>>>>
> >>>>>>> Besides consistency matters, I wanted to understand what's the
> >>>>>>> motivation
> >>>>>>> of
> >>>>>>> keeping these widgets static. I.e. is it an essential preparation
> >>>>>>> for
> >>>>>>> the
> >>>>>>> new
> >>>>>>> instance type dialog or a new concept for tab based dialogs
> >>>>>>> (as DC/Cluster values aren't necessarily relevant for each tab in
> >>>>>>> the
> >>>>>>> dialog)
> >>>>>>
> >>>>>> [maybe Tomas/Eldan/Malini can help here as well]
> >>>
> >>>
> >>> MR: Here are the original motivations for this static panel.
> >>>
> >>> 1. Context for dependencies - In the create VM dialog and the
> >>> introduction
> >>> of
> >>> instance types and images, we came up with two core needs for the UI -
> >>> There
> >>> were some fields that were context-setting for other fields with
> >>> dependencies. So, changing these context setting field values would alter
> >>> the choices in other fields on one of the sub-tabs or eliminate or
> >>> populate
> >>> fields in these tabs. We wanted to ground the user with the context so
> >>> that
> >>> they can observe any changes that happen on a tab and determine what
> >>> caused
> >>> that change in the static panel.
> >>>
> >>> 2. Basic and mandatory - In the create VM dialog and the introduction of
> >>> instance types and images, we also had to represent different levels of
> >>> definition needed. For e.g, there were some basic and mandatory fields
> >>> that
> >>> were minimally needed for the definition of a VM irrespective of whether
> >>> the
> >>> user was basic or advanced. These fields were included in the static
> >>> panel
> >>> or at the most in the very first sub tab if they were not a context
> >>> setting
> >>> field for any other dependent field. This way the user does not have to
> >>> go
> >>> anywhere else to do a basic definition of the VM.
> >>>
> >>> Then we had another layer of permissioning where the fields you had
> >>> access
> >>> to
> >>> on various tabs depended on whether you were a basic or advanced user.
> >>> But
> >>> note, we did have scenarios where some advanced fields made it to the
> >>> static
> >>> panel because they were a context setter.
> >>>
> >>> So to summarize the motivation of why the static panel and what should go
> >>> into the static panel - You need a static panel ONLY if you have certain
> >>> fields (basic or advanced) that act as context setters for all or some of
> >>> the other fields in the other sub-tabs. Static panels can further
> >>> optionally
> >>> be extended to present all the fields that are needed for basic
> >>> definition
> >>> of an object. If there is no dependency and there is a dialog with
> >>> multiple
> >>> sub-tabs, then we SHOULD NOT just create a static panel for the basic
> >>> definition fields. These fields should populate the first sub tab. Let me
> >>> know if any further clarifications are needed.
> >>>
> >>>
> >>>
> >>>>>>
> >>>>>> these static widgets (as well as the type ahead list box [1], for
> >>>>>> example)
> >>>>>> are part of
> >>>>>> the instance types feature that had its design details published in
> >>>>>> [2]
> >>>>>> and
> >>>>>> [3], and the
> >>>>>> implementation was done according to this design. I don't see any
> >>>>>> reason
> >>>>>> to
> >>>>>> not utilize
> >>>>>> this newly-introduced concept in other side-tab-based dialogs as
> >>>>>> well,
> >>>>>> if
> >>>>>> it
> >>>>>> makes sense
> >>>>>> (ui consistency considerations are sufficient, IMO, but I could be
> >>>>>> wrong
> >>>>>> -
> >>>>>> maybe it is
> >>>>>> relevant/correct to introduce this new concept only in the VM-like
> >>>>>> dialogs).
> >>>
> >>>
> >>> MR: The UX motivations for the static panel are generalizable even though
> >>> they were designed for the New VM dialog. See above comment. But we need
> >>> to
> >>> gauge the reqs on each of the dialogs with subtabs against the core
> >>> motivation and see if we need the static panel on it or not.
> >>>
> >>>
> >>>>>>
> >>>>>> regarding the specific concern about the DC/Cluster values that
> >>>>>> aren't
> >>>>>> necessarily relevant
> >>>>>> for each side-tab in the dialog: I agree with that statement,
> >>>
> >>> MR: If any field recommended in the UX proposal is not useful as a
> >>> context
> >>> setter, then please let us know and we can move it to the first sub-tab.
> >>>
> >>>
> >>> however:
> >>>>>>
> >>>>>> - putting the "Instance Type" drop-down at the top static section is
> >>>>>> very
> >>>>>> useful (see [4]
> >>>>>> for explanation), and as the Instance Types list is derived from the
> >>>>>> selected
> >>>>>> DC, it makes
> >>>>>> sense (to me) to put the DC in that top static section as well.
> >>>
> >>> MR: Agree. That is probably why we ended up leaving the DC there.
> >>>
> >>>
> >>>>>>
> >>>>>> - the DC/Cluster are relevant for some of the tabs in the dialog
> >>>>>> (Host,
> >>>>>> Resource Allocation?)
> >>>>>
> >>>>> Only for Host.
> >>>>> Resource Allocation is directly affected by the selected template.
> >>>>> Therefore, it sounds very confusing to me...
> >>>>> Unless we add template to the static header as well?
> >>>
> >>>
> >>> MR: I think we incorporated the templates into the Image field and
> >>> denoted
> >>> it
> >>> with an icon preceding the drop down choice. So, the template is in the
> >>> static panel.
> >>
> >> Just a small note: the first patch we are talking about
> >> (http://gerrit.ovirt.org/#/c/14635)
> >> adds only Data Center, Cluster and Quota to the header.
> >> There is a second patch (http://gerrit.ovirt.org/#/c/15011/) which moves
> >> the
> >> OS type and
> >> template to the header.
> >> The Image and Instance Type fields are not implemented yet. The current
> >> patches just redesigns
> >> the current UX according to the mockups - the new entities will be
> >> integrated
> >> after we will have
> >> an agreement and this batch of patches will be merged.
> >
> > OK, that explains a lot... :) many thanks, Tomas, for the clarification.
> >
> > I understand now Daniels's concern; it indeed doesn't make much sense for
> > the
> > DC/Cluster and Quota fields to be the only fields in the top static
> > section.
> > However, as this is a preparation for the Instance Types fields patches, it
> > makes sense that we will first do the preparation work (i.e.
> > change/reorganize
> > the existing dialog layout), and then incorporate the Instance Types fields
> > into
> > it (given that it is being done *shortly* afterwards), or simply do
> > everything
> > altogether.
> >
> > @Tomas - ideally, the code that actually adds the Instance Types fields
> > should have
> > been part of this patch chain (either in more patches, or in "larger"
> > patches), as again -
> > I agree with Daniel that it makes no sense to having a static header in the
> > VM dialogs
> > with only DC/Cluster and Quota in them [1].
> > However, there is a chance that it would have been resulted in very large
> > patches / a
> > very long series of patches, which would have been even harder to
> > review/rebase/etc.
> >
> > how long will it take for you to have the patches that actually add the
> > Instance Types
> > fields ready (once the first batch is merged)? as long as it will be done
> > shortly afterwards,
> > then your approach seems ok (again - my main concern is [1]).
Adding Omer for his estimate as he is doing the backend part of the instance types. It is hard to estimate, but
I would say it will take a ~week to implement and an unpredictable time to review and merge (the first part
of this batch is in gerrit since may 10th and is far from being merged...).
> >
> > [1] my main concern is that this batch of patches (dialog reorg) will make
> > it into ovirt
> > 3.3, but the second batch (which will contain the actual Instance Types
> > fields) won't make
> > it in time [see the ovirt 3.3 schedule in:
> > http://www.ovirt.org/OVirt_3.3_release-management -
> > ovirt 3.3 feature freeze is today (?!)]; so I wouldn't want to see ovirt
> > 3.3 being released
> > with only the first patch batch merged into it. either both batches should
> > be there, or
> > both batches should not be there.
well, I don't see a problem having only the first part in. Given that the template = instance type + image
and the templates are added to the header in this batch, the reasoning behind having the instance types and
images in the header can be applied to having the templates in the header (which BTW will be true even after adding instance types and images)
Also, this batch of patches brings other values to the users like:
- type ahead combo boxes
- unifies new server/desktop to new vm (so can have server with more displays or soundcard etc)
- simplifies the VM dialogs (with show/hide advanced options button and system tab)
- adds the possibility to edit the NIC/network assignment directly from the VM dialog
- unifies the cluster and DC to one field so no need to select them one-by-one
This all are useful features which can bring some value to the user and make perfect sense without instance types.
To put it to wider context: the feature is called "Instance Types" but a more fitting name would be something like
"Simplify VM based entity management". The reason is that today it is quite hard to make a new VM or edit it etc. because
when you open a e.g. new VM dialog, you are flooded with tons of config options and you have no idea (if you open it first time) what
do you have to edit. And even you finally fill it, you still need to go to some subtabs for e.g. create a NIC and assign it a network.
Or, if you want to select a template to base your VM on, you have to first go to the templates tab and to find out which template is for what
(the current batch will show at least the description next to the template thanks to the type ahead combo which is already a big help).
The effort here is to simplify this. The already implemented patches are some steps which simplify the VM management. The instance types
will make next step in simplifying it. But I don't see a reason why not to go step-by-step.
Please also consider all the time and risk of regression which is carried by each rebase. And the longer the patch sits in gerrit, the bigger the risk is.
But anyway, I understand that the freeze is today so I don't see a way to make it in...
> There was a discussion about postponing it, but not much further it seems.
> In any case It may not be necessarily wrong to have dialog reorg in 3.3
> without insttypes as it will at least get people to get used to it and we
> can gather feedback. It's not that it removes any functionality, on the
> contrary, e.g. the type ahead feature even solves some of the bugs we
> already have.
>
> >
> >>>
> >>>
> >>>>
> >>>> The answer is yes, in a sense: Instance Types + Images are actually
> >>>> somewhat "replacing" Templates [the general approach is to move to
> >>>> basing VMs on Instance Types + Images, rather than on Templates;
> >>>> it allows more flexibility in combining hardware configuration + image
> >>>> configuration for the VM, without (necessarily) editing each VM field
> >>>> separately].
> >>>>
> >>>> So as I stated in my previous response: Having the "Instance Types"
> >>>> field (and "Image" field) in the top static section is very useful, as
> >>>> they affect the fields in most / a lot of the side-tabs.
> >>>>
> >>>> Based on the above:
> >>>>
> >>>> Do you agree that it makes sense to have a top static section in general
> >>>> [even only for the "Instance Types" field and "Image" field (again, as
> >>>> they affect most / a lot of side-tabs fields)]?
> >>>> If so: Do you think that it makes sense to include the DC field in that
> >>>> top static section as well (at least due to the fact that the "Instance
> >>>> Types" list and "Images" list are derived from the selected DC)?
> >>>
> >>> MR: Yes makes sense to include DC in static panel because some of the
> >>> other
> >>> fields in the static panel are dependent on it.
> >>>
> >>>
> >>>>
> >>>> [Tomas/Malini/Eldan - if there is additional/different reasoning for
> >>>> putting
> >>>> the DC/Cluster field on the top static section - please share]
> >>>>
> >>>>> (which will be odd for the other tabs).
> >>>>>
> >>>>> So I still don't get the motivation UX-wise.
> >>>>> E.g. it seems really weird to change the entire DC from Console tab
> >>>>> (or, as a matter of fact, from most other tabs).
> >>>
> >>> MR: Not sure I understand. You can change DC when you are on ANY sub tab
> >>> because the DC is a field in the static panel. The static panel is not
> >>> the
> >>> sub-tab.
> >>>
> >>>
> >>>>> In the new instance type dialog, which tabs could be directly affected
> >>>>> by
> >>>>> DC/Cluster?
> >>>>> IIUC, only Host? Do we really need a static header just for this tab?
> >>>
> >>> MR: Ideally, if we have only one sub-tab that has some dependencies with
> >>> some
> >>> basic fields, we should try to design the first sub-tab to have all those
> >>> fields and eliminate the static panel. But if it is weird to have those
> >>> additional fields on the very first sub-tab from a workflow perspective,
> >>> then we should have the static panel even if the dependency is only on
> >>> one
> >>> sub-tab. The rule we are going by then is that it doesn't hurt to have
> >>> context info on the top but it hurts more to not have that context info
> >>> when
> >>> needed.
> >>>
> >>>
> >>>>>
> >>>>>> so for consistency-within-the-dialog considerations, it is probably a
> >>>>>> good
> >>>>>> idea to simply
> >>>>>> always show these fields within this top static section.
> >>>>>>
> >>>>>> [there is a good chance that I am missing your point here - please
> >>>>>> correct
> >>>>>> me
> >>>>>> if necessary]
> >>>>>>
> >>>>>> [1] http://gerrit.ovirt.org/#/c/14936/
> >>>>>>
> >>>>>> [2] http://www.ovirt.org/Features/Instance_Types
> >>>>>>
> >>>>>> [3] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> >>>>>>
> >>>>>> [4] whenever changing the "Instance Type" value, you can
> >>>>>> automatically
> >>>>>> see
> >>>>>> how these changes
> >>>>>> affect the fields in the current tab on which you are standing (e.g.
> >>>>>> if
> >>>>>> you
> >>>>>> are standing on
> >>>>>> the "System" side-tab, you can change the "Instance Type" selected
> >>>>>> item
> >>>>>> and
> >>>>>> immediately see
> >>>>>> the changes within the "System" side-tab contents), and vice-versa:
> >>>>>> if
> >>>>>> you
> >>>>>> are changing a value
> >>>>>> that was originally propagated from the instance-type, you will see
> >>>>>> the
> >>>>>> instance-type automatically
> >>>>>> change to "custom"/"not applicable" as a result, so no need to "jump"
> >>>>>> between
> >>>>>> side-tabs in order
> >>>>>> to observe these changes.
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> ----
> >>>>>>>> Thanks,
> >>>>>>>> Einav
> >>>>>>>>
> >>>>>>>> [1] http://www.ovirt.org/images/9/9e/Instance_type.pdf
> >>>>>>>>
> >>>>>>>> ----- Original Message -----
> >>>>>>>>> From: derez at redhat.com
> >>>>>>>>> To: "Tomas Jelinek" <tjelinek at redhat.com>
> >>>>>>>>> Cc: "Vojtech Szocs" <vszocs at redhat.com>, "Einav Cohen"
> >>>>>>>>> <ecohen at redhat.com>,
> >>>>>>>>> "Frank Kobzik" <fkobzik at redhat.com>,
> >>>>>>>>> "Eldan Hildesheim" <info at eldanet.com>
> >>>>>>>>> Sent: Tuesday, May 28, 2013 5:05:38 PM
> >>>>>>>>> Subject: Change in ovirt-engine[master]: userportal,webadmin:
> >>>>>>>>> redesign
> >>>>>>>>> of
> >>>>>>>>> vm related dialogs
> >>>>>>>>>
> >>>>>>>>> Daniel Erez has posted comments on this change.
> >>>>>>>>>
> >>>>>>>>> Change subject: userportal,webadmin: redesign of vm related
> >>>>>>>>> dialogs
> >>>>>>>>> ......................................................................
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Patch Set 5: (1 inline comment)
> >>>>>>>>>
> >>>>>>>>> Code looks good.
> >>>>>>>>> A few questions regarding the design:
> >>>>>>>>> 1. Why do we want the static header only in VM dialog?
> >>>>>>>>> 2. DC/Host are really relevant for all tabs?
> >>>>>>>>> 3. Is it just a preparation for the final instance type dialog?
> >>>>>>>>> 4. If it's indeed merely preparation, shouldn't it be merged
> >>>>>>>>> only
> >>>>>>>>> once
> >>>>>>>>> we
> >>>>>>>>> have the full picture of the new dialog?
> >>>>>>>>>
> >>>>>>>>> ....................................................
> >>>>>>>>> File
> >>>>>>>>> frontend/webadmin/modules/gwt-common/src/main/java/org/ovirt/engine/ui/common/widget/dialog/tab/DialogTabPanel.ui.xml
> >>>>>>>>> Line 21:
> >>>>>>>>> Line 22: .header {
> >>>>>>>>> Line 23: background-color: #D3D3D3;
> >>>>>>>>> Line 24: border-bottom: 1px solid #CED8DF;
> >>>>>>>>> Line 25: margin-bottom: 15px;
> >>>>>>>>> is it supposed to be that large?
> >>>>>>>>> Line 26: padding-top: 6px;
> >>>>>>>>> Line 27: margin-top: 4px;
> >>>>>>>>> Line 28: margin-right: 3px;
> >>>>>>>>> Line 29: display: none;
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> To view, visit http://gerrit.ovirt.org/14635
> >>>>>>>>> To unsubscribe, visit http://gerrit.ovirt.org/settings
> >>>>>>>>>
> >>>>>>>>> Gerrit-MessageType: comment
> >>>>>>>>> Gerrit-Change-Id: Icad8098e286f821da25fac22fd0a840a42f105c9
> >>>>>>>>> Gerrit-PatchSet: 5
> >>>>>>>>> Gerrit-Project: ovirt-engine
> >>>>>>>>> Gerrit-Branch: master
> >>>>>>>>> Gerrit-Owner: Tomas Jelinek <tjelinek at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Daniel Erez <derez at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Einav Cohen <ecohen at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Eldan Hildesheim <info at eldanet.com>
> >>>>>>>>> Gerrit-Reviewer: Frank Kobzik <fkobzik at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Tomas Jelinek <tjelinek at redhat.com>
> >>>>>>>>> Gerrit-Reviewer: Vojtech Szocs <vszocs at redhat.com>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> Engine-devel mailing list
> >>>>> Engine-devel at ovirt.org
> >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
>
>
More information about the Engine-devel
mailing list