[Engine-devel] oVirt Engine GUI: builders infrastructure - meeting minutes

Gilad Chaplik gchaplik at redhat.com
Wed Mar 6 09:12:48 UTC 2013


----- Original Message -----
> From: "Einav Cohen" <ecohen at redhat.com>
> To: "Tomas Jelinek" <tjelinek at redhat.com>, "engine-devel" <engine-devel at ovirt.org>
> Cc: "Alona Kaplan" <alkaplan at redhat.com>, "Daniel Erez" <derez at redhat.com>, "Gilad Chaplik" <gchaplik at redhat.com>,
> "Vojtech Szocs" <vszocs at redhat.com>
> Sent: Tuesday, March 5, 2013 7:17:59 PM
> Subject: oVirt Engine GUI: builders infrastructure - meeting minutes
> 
> 
> - Problem and proposed solution in a nutshell:
> 
>    * we have a lot of duplication in the GUI code that can be
>    eliminated
> using the builders infrastructure, which attempts to solve the
> problem by breaking
> down the logic to "atomic" particles, which can be (re)used as
> necessary.
> 
>    * Tomas came up with the solution when planning the implementation
>    of the GUI code
> for the new Instance Types and Images [1] business entities (which
> are VM-related
> business entities, and the VM-related GUI code already have a lot of
> code
> duplication), when he realized that additional code duplication would
> have
> to be introduced unless some kind of new infrastructure/refactoring
> will be done.
> 
> - Inheritance?
> 
>    * Code duplication exists across the entire GUI code, not only in
>    the VM-related
> parts of it. It seems that an inheritance solution in the Networking
> code has already
> been introduced by Alona, and is possibly applicable to VM-related
> code as well.
> 
>    * Tomas has already tried the inheritance approach, however the
>    result hasn't
> introduced a significant improvement to the current state of the
> code.
> 
>    * Derez/Alona will help Tomas with trying to figure out the most
> "correct" way to solve the code-duplication problem by inheritance.
> 
>    * If it will be concluded that an inheritance solution is not
>    feasible, we will
> think of an alternative (builders, something else, stay with code
> duplication(???)),
> but we would really like to try and utilize the code inheritance, as
> it is already
> successfully used in other parts of the GUI code that had similar
> problems.
> 
> - Need to keep in mind potential future plans for the GUI code:
> 
>    * moving to REST API business entities and REST API in general
>    [Java(script?) SDK]
> 
>    * eliminating some entity models, and binding the view directly to
>    the REST API
> business entities (possibly using decorators?). Need to keep in mind
> that a lot
> of the models will still need to be retained, e.g. since they are
> stateful (e.g. list model
> holds selected item(s)).

small note: I think that stateless won't be a big deal (there are places in the code that we
consider list model as stateless).

> 
>    * grouping several queries together, allowing to load data into a
>    dialog, for
> example, in a single "bulk", rather than calling 20 different queries
> (New VM dialog
> and alike are the most painful - can take a lot of time to load,
> especially on WAN).

I think that all other issues are insignificant comparing to this one.
If we invest the resources to refactor this area, this should be our primary goal.
different approaches may lead us to have the same talk/cycle in the near future.

I think that each of the items you've mentioned here is more than enough to postpone/delay/rethink
the solution for this issue; maybe propose a quick POC instead of investing time in sth that could/may
change soon.

[FYI: I think that inheritance is the way to go, but on the servlet side... 
we should call a single query to fill out the entire dialog]

Great discussion! and thanks you Tomas :-)

Gilad.

> 
> - I would like to thank:
> 
>    * Tomas for his excellent presentation of the problem and the
> builders infrastructure solution (slides attached).
> 
>    * All other participants in the meeting for taking the time
> to listen, express their opinion and helping Tomas in this issue.
> 
> [Participants: feel free to add to/amend the above as necessary]
> 
> ----
> Best Regards,
> Einav
> 
> 
> [1] http://www.ovirt.org/Features/Instance_Types
> 
> ----- Original Message -----
> > From: "Tomas Jelinek" <tjelinek at redhat.com>
> > To: ecohen at redhat.com, engine-devel at ovirt.org
> > Sent: Tuesday, March 5, 2013 9:21:27 AM
> > Subject: [Engine-devel] oVirt Engine GUI: builders infrastructure
> > feedback (conf: 712 886 7405#)
> > 
> > attaching the slides
> > 
> > ----- Original Message -----
> > > The following is a new meeting request:
> > > 
> > > Subject: oVirt Engine GUI: builders infrastructure feedback
> > > (conf:
> > > 712 886 7405#)
> > > Organizer: "Einav Cohen" <ecohen at redhat.com>
> > > 
> > > Location: Intercall conf code: 712 886 7405#
> > > Time: Tuesday, March 5, 2013, 9:30:00 AM - 11:00:00 AM GMT -05:00
> > > US/Canada Eastern
> > >  
> > > Invitees: tjelinek at redhat.com; engine-devel at ovirt.org
> > > 
> > > 
> > > *~*~*~*~*~*~*~*~*~*
> > > 
> > > Following the correspondence in the builders infrastructure patch
> > > [1]
> > > and engine-devel thread [2]:
> > > In the first part of the meeting, Tomas Jelinek
> > > <tjelinek at redhat.com>
> > > will present his builders infrastructure solution.
> > > In the second part of the meeting, we will hear feedback about
> > > this
> > > solution from the other parties and try to converge to a final,
> > > unanimous decision.
> > > 
> > > 
> > > conference call details:
> > > ========================
> > > Intercall dial-in numbers:
> > > https://www.intercallonline.com/listNumbersByCode.action?confCode=7128867405
> > > 
> > > Intercall conf code:
> > > 712 886 7405#
> > > 
> > > 
> > > elluminate session:
> > > ===================
> > > https://sas.elluminate.com/m.jnlp?sid=819&password=M.A7793C4C197B25A20229D725900B25
> > > 
> > > ----
> > > 
> > > [1] http://gerrit.ovirt.org/#/c/10874/
> > > 
> > > [2]
> > > http://lists.ovirt.org/pipermail/engine-devel/2013-January/003528.html
> > > 
> > 
> > _______________________________________________
> > 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