Frontend - please avoid putting business logic into Views
by Vojtech Szocs
Hi guys,
our GWT frontend generally follows the Model-View-Presenter
design pattern via GWT-Platform MVP module [1].
[1] https://github.com/ArcBees/GWTP/wiki/Getting-started
Presenters/PresenterWidgets should be the ones containing
the business logic. Views should only contain simple logic
to perform necessary UI updates etc.
Consider the following example of imaginary "Foo" dialog:
// inside FooPopupView.java
@Override
public void edit(SomeModel model) {
// this is OK!
driver.edit(model);
// please DON'T do this!
model.getSomeAttribute().getEntityChangedEvent().addListener(...);
}
There are two main reasons why to avoid adding listeners
to given model (i.e. SomeModel) inside View.edit() method:
1, MVP pattern encourages putting business logic into
Presenter (reflecting Presenter's responsibility)
2, View.edit()'s responsibility is to populate UI from
model data, and can be potentially called multiple
times!
Following example shows the "correct" (MVP-ish) way:
// inside FooPopupPresenterWidget.java
public interface ViewDef extends ... {
// in your listener, you can use getView().doSomething()
void doSomething();
}
@Override
public void init(SomeModel model) {
// listeners are added only once, as they should!
model.getSomeAttribute().getEntityChangedEvent().addListener(...);
}
This applies to both PresenterWidgets (typically dialogs)
and "regular" Presenters (typically main/sub tabs etc).
Also, please avoid explicit View impl. type casts inside
Presenters/PresenterWidgets:
// inside FooPopupPresenterWidget.java
// please DON'T do this!
((FooPopupView) getView()).doSomething();
// you should use this!
getView().doSomething();
Just modify the ViewDef interface to contain methods you
need to invoke on the View. Please remember that ViewDef
is THE interface between Presenter and View. Please avoid
referencing specific View implementation inside Presenter.
Let me know if you have any questions.
Regards,
Vojtech
10 years
Important change in UI plugins REST API integration
by Vojtech Szocs
Hi guys,
an important change in UI plugins REST API integration landed
in both master [1] and 3.5 [2] branches of oVirt Engine repo.
[1] http://gerrit.ovirt.org/#/c/35185/
[2] http://gerrit.ovirt.org/#/c/35248/
Below is a short overview of this change and how it affects
existing UI plugins. Please refer to commit message for more
details.
Situation before
================
WebAdmin login caused two separate Engine user sessions to
be created: one for WebAdmin GUI itself, one for UI plugins
(using same credentials as entered in WebAdmin login form).
This resulted in two separate "user {user}@{domain} logged"
entries in Engine log.
REST session ID which maps to second Engine user session was
broadcasted to all UI plugins via "RestApiSessionAcquired"
event handler function.
Upon WebAdmin logout, the second Engine user session was not
closed; this was intentional so that any potential 3rd party
systems using above mentioned REST session ID would still work.
Situation after
===============
WebAdmin login causes one Engine user session to be created.
When acquiring REST session for UI plugins, existing Engine
user session is reused via OVIRT-INTERNAL-ENGINE-AUTH-TOKEN
header [3]. There is now only one "user {user}@{domain} logged"
entry in Engine log.
[3] http://gerrit.ovirt.org/#/c/35069/
Acquired REST session ID therefore maps to existing Engine
user session. "RestApiSessionAcquired" API still works as
expected.
The only (possibly breaking) change is that upon WebAdmin
logout, REST session ID previously passed to all UI plugins
(upon last login) will not work anymore. While the physical
session (REST webapp HttpSession) might still be active, the
logical session (Engine user / SessionDataContainer) will be
dead, therefore the physical REST session won't work after
WebAdmin logout.
In other words, usability of REST session ID is now strictly
scoped to GUI user being authenticated. If the user logs in,
(always) new REST session ID will be passed to all UI plugins.
If the user logs out, REST session ID will not work anymore.
This is in line with the general concept of UI plugins where
each plugin is "active" (receives API callbacks) *only* when
the GUI user is authenticated. See [4,5] for details.
[4] http://www.ovirt.org/Features/UIPlugins#Plugin_lifecycle
"Plugin invocation context starts when user logs into WebAdmin and ends when user logs out."
[5] http://www.ovirt.org/Features/UIPlugins#Application_event_reference
Let me know if you have any questions.
Regards,
Vojtech
10 years
Re: [ovirt-devel] hosted-engine setup/migration features for 3.6
by Yedidyah Bar David
----- Original Message -----
> From: "Bob Doolittle" <bob(a)doolittle.us.com>
> To: "Yedidyah Bar David" <didi(a)redhat.com>
> Sent: Wednesday, December 3, 2014 2:50:12 PM
> Subject: Re: [ovirt-devel] hosted-engine setup/migration features for 3.6
>
> Another issue with that page is that it assumes a remote database. I am not
> sure what percentage of cases have remote databases but clearly many
> (most?) do not, since that's not default behavior.
I agree.
> So that page definitely
> needs attention. See:
> https://bugzilla.redhat.com/show_bug.cgi?id=1099995
Indeed. Note that this isn't specific to hosted-engine, it's the same for
any migration using engine-backup to backup/restore, therefore there is
a link to its page in the top, where this is more detailed. We also have
a bug [3] to automate this.
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1064503
> https://bugzilla.redhat.com/show_bug.cgi?id=1099998
>
> Some of us have wanted to disable global maintenance upon bootup by adding
> a systemd service on Fedora 20 (since you must enable global maintenance to
> shut it down cleanly), and have found it impossible to create the necessary
> systemd dependencies. It seems that (at least with 3.4) hosted-engine
> --set-maintenance --mode=none will return an error for several seconds
> after all other services have started and it's not clear what can be waited
> upon in order to issue the command with assurance it will complete
> successfully. This isn't strictly a setup/migration issue but it is an
> issue with setting up a desired configuration with hosted-engine. The way
> to reproduce this is simply to wait until gdm-greeter displays the login
> prompt, ssh into the system and execute hosted-engine --set-maintenance
> --mode=none and observe the error. Or create a systemd service that depends
> upon (waits for) the latest-possible service, try executing the command
> there, and observe the error. Ideally there would be some external
> observable event which a systemd service could depend upon, when
> hosted-engine is ready to do its thing.
Adding Jiri for that. Do you have an open bug?
Thanks,
>
> Regards,
> Bob
>
>
> On Wed, Dec 3, 2014 at 2:59 AM, Yedidyah Bar David <didi(a)redhat.com> wrote:
>
> > Hi all,
> >
> > We already have quite a lot of open ovirt-hosted-engine-setup bugs for 3.6
> > [1].
> >
> > Yesterday I tried helping someone on irc who planned to migrate to
> > hosted-engine
> > manually, and without knowing (so it seems) that such a feature exists. He
> > had
> > an engine set up on a physical host, prepared a VM for it, and asked about
> > migrating
> > the engine to the VM. In principle this works, but the final result will
> > be a
> > hosted-engine, where the engine manages a VM the runs itself, without
> > knowing it,
> > and without HA.
> >
> > The current recommended migration flow is described in [2]. This page is
> > perhaps
> > a bit outdated, perhaps missing some details etc., but principally works.
> > The main
> > issue with it, AFAICT after discussing this a bit with few people, is that
> > it
> > requires a new clean host.
> >
> > I'd like to hear what people here think about such and similar flows.
> >
> > If you already had an engine and migrated to hosted-engine, what was good,
> > what
> > was bad, what would you like to change?
> >
> > If you plan such a migration, what do you find missing currently?
> >
> > [1] http://red.ht/1vle8Vv
> > [2] http://www.ovirt.org/Migrate_to_Hosted_Engine
> >
> > Best,
> > --
> > Didi
> > _______________________________________________
> > Devel mailing list
> > Devel(a)ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/devel
> >
>
--
Didi
10 years
Re: [ovirt-devel] hosted-engine setup/migration features for 3.6
by Bob Doolittle
Resending - inadvertently dropped CCs.
On Wed, Dec 3, 2014 at 7:50 AM, Bob Doolittle <bob(a)doolittle.us.com> wrote:
> Another issue with that page is that it assumes a remote database. I am
> not sure what percentage of cases have remote databases but clearly many
> (most?) do not, since that's not default behavior. So that page definitely
> needs attention. See:
> https://bugzilla.redhat.com/show_bug.cgi?id=1099995
> https://bugzilla.redhat.com/show_bug.cgi?id=1099998
>
> Some of us have wanted to disable global maintenance upon bootup by adding
> a systemd service on Fedora 20 (since you must enable global maintenance to
> shut it down cleanly), and have found it impossible to create the necessary
> systemd dependencies. It seems that (at least with 3.4) hosted-engine
> --set-maintenance --mode=none will return an error for several seconds
> after all other services have started and it's not clear what can be waited
> upon in order to issue the command with assurance it will complete
> successfully. This isn't strictly a setup/migration issue but it is an
> issue with setting up a desired configuration with hosted-engine. The way
> to reproduce this is simply to wait until gdm-greeter displays the login
> prompt, ssh into the system and execute hosted-engine --set-maintenance
> --mode=none and observe the error. Or create a systemd service that depends
> upon (waits for) the latest-possible service, try executing the command
> there, and observe the error. Ideally there would be some external
> observable event which a systemd service could depend upon, when
> hosted-engine is ready to do its thing.
>
> Regards,
> Bob
>
>
> On Wed, Dec 3, 2014 at 2:59 AM, Yedidyah Bar David <didi(a)redhat.com>
> wrote:
>
>> Hi all,
>>
>> We already have quite a lot of open ovirt-hosted-engine-setup bugs for
>> 3.6 [1].
>>
>> Yesterday I tried helping someone on irc who planned to migrate to
>> hosted-engine
>> manually, and without knowing (so it seems) that such a feature exists.
>> He had
>> an engine set up on a physical host, prepared a VM for it, and asked
>> about migrating
>> the engine to the VM. In principle this works, but the final result will
>> be a
>> hosted-engine, where the engine manages a VM the runs itself, without
>> knowing it,
>> and without HA.
>>
>> The current recommended migration flow is described in [2]. This page is
>> perhaps
>> a bit outdated, perhaps missing some details etc., but principally works.
>> The main
>> issue with it, AFAICT after discussing this a bit with few people, is
>> that it
>> requires a new clean host.
>>
>> I'd like to hear what people here think about such and similar flows.
>>
>> If you already had an engine and migrated to hosted-engine, what was
>> good, what
>> was bad, what would you like to change?
>>
>> If you plan such a migration, what do you find missing currently?
>>
>> [1] http://red.ht/1vle8Vv
>> [2] http://www.ovirt.org/Migrate_to_Hosted_Engine
>>
>> Best,
>> --
>> Didi
>> _______________________________________________
>> Devel mailing list
>> Devel(a)ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
10 years
[QE][ACTION REQUIRED] oVirt 3.5.1 RC status
by Sandro Bonazzola
Hi,
We're going to start composing oVirt 3.5.1 RC on *2014-12-09 08:00 UTC* from 3.5 branch.
In order to stabilize the release a new branch ovirt-engine-3.5.1 will be created from the same git hash used for composing the RC.
The bug tracker [1] shows 1 open blocker:
Bug ID Whiteboard Status Summary
1160846 sla NEW Can't add disk to VM without specifying disk profile when the storage domain has more than one disk profile
In order to stabilize the release a new branch ovirt-engine-3.5.1 will be created from the same git hash used for composing the RC.
Maintainers:
- Please be sure that 3.5 snapshot allow to create VMs before *2014-12-08 15:00 UTC*
- Please be sure that no pending patches are going to block the release before *2014-12-08 15:00 UTC*
- If any patch must block the RC release please raise the issue as soon as possible.
- Please provide an ETA for the pending blockers as soon as possible.
Infra:
- Please check Jenkins status for 3.5 jobs and sync with relevant maintainers if there are issues.
There are still 68 bugs [2] targeted to 3.5.1.
Excluding node and documentation bugs we still have 45 bugs [3] targeted to 3.5.1.
Maintainers / Assignee:
- Please add the bugs to the tracker if you think that 3.5.1 should not be released without them fixed.
- Please update the target to 3.5.2 or later for bugs that won't be in 3.5.1:
it will ease gathering the blocking bugs for next releases.
- Please fill release notes, the page has been created here [4]
Community:
- If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5]
[1] http://bugzilla.redhat.com/1155170
[2] http://goo.gl/7G0PDV
[3] http://goo.gl/6gUbVr
[4] http://www.ovirt.org/OVirt_3.5.1_Release_Notes
[5] http://www.ovirt.org/Testing/oVirt_3.5.1_Testing
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years
Some ideas on oVirt Java SDK
by Vojtech Szocs
Hi guys,
since the initial (small, working & well-tested) version of oVirtJS
JavaScript SDK is finished [*], I've started working on GWT wrapper
for oVirtJS.
While analyzing/reverse-engineering oVirt Java SDK, some thoughts
came to my mind, and I wanted to share them with you.
[*] TODO(vszocs) upload new patchset with all recent changes
First, the way XJC (JAXB binding compiler that generates Java beans
out of REST XSD schema) is invoked looks a bit weird to me, as Java
SDK's XsdCodegen does this:
Runtime.getRuntime().exec(command)
Why not simply use existing Maven plugins to invoke XJC?
- either: https://github.com/highsource/maven-jaxb2-plugin
- or: http://mojo.codehaus.org/jaxb2-maven-plugin/
Second, and most importantly, what's the point of having "group"
entities? I'll give an example - api.xsd contains this:
<xs:complexType name="DataCenters">
<xs:complexContent>
<xs:extension base="BaseResources">
<xs:sequence>
<xs:annotation>
<xs:appinfo>
<jaxb:property name="DataCenters"/>
</xs:appinfo>
</xs:annotation>
<xs:element ref="data_center" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
(Same as above for Hosts, Clusters, VMs, etc.)
This results in following (IMHO rather meaningless) Java class
being generated by XJC:
public class DataCenters extends BaseResources {
@XmlElement(name = "data_center")
protected List<DataCenter> dataCenters;
public List<DataCenter> getDataCenters() {
if (dataCenters == null) {
dataCenters = new ArrayList<DataCenter>();
}
return this.dataCenters;
}
public boolean isSetDataCenters() {
return ((this.dataCenters!= null)&&(!this.dataCenters.isEmpty()));
}
public void unsetDataCenters() {
this.dataCenters = null;
}
}
Instead, we could use @XmlElementWrapper as described in [1]
to avoid generating "group" entities altogether.
[1] https://github.com/dmak/jaxb-xew-plugin
The fact that Java SDK provides decorator for each specific
resource collection (like DataCenters), instead of having ONE
resource collection type, greatly complicates overall design
and code-gen aspect.
In oVirtJS GWT wrapper, we'll avoid above complication through
single resource collection type (having common methods like
get(id), list() etc) for all resources.
Regards,
Vojtech
10 years
REST API CSRF protection header name
by Vojtech Szocs
Hi,
since 3.5 the oVirt REST API features CSRF protection
mechanism via CSRFProtectionFilter, see [1] for details.
[1] http://gerrit.ovirt.org/#/c/29681/
I'd like to ask what's the motivation behind calling the
CSRF token header "JSESSIONID". I think the header name
should reflect its logical purpose to avoid confusion.
Could we rename this header to something more appropriate
like "OVIRT-REST-CSRF-TOKEN" or similar? It would better
reflect the purpose of this (CSRF protection) header.
In future, we can still have another request header with
name "JSESSIONID" for transmitting session ID from client
to server, however this potential new header would have
different purpose (transfer session ID vs. CSRF token).
Each header should have name reflecting its purpose.
(This is just a suggestion.)
Thanks,
Vojtech
10 years
hosted-engine setup/migration features for 3.6
by Yedidyah Bar David
Hi all,
We already have quite a lot of open ovirt-hosted-engine-setup bugs for 3.6 [1].
Yesterday I tried helping someone on irc who planned to migrate to hosted-engine
manually, and without knowing (so it seems) that such a feature exists. He had
an engine set up on a physical host, prepared a VM for it, and asked about migrating
the engine to the VM. In principle this works, but the final result will be a
hosted-engine, where the engine manages a VM the runs itself, without knowing it,
and without HA.
The current recommended migration flow is described in [2]. This page is perhaps
a bit outdated, perhaps missing some details etc., but principally works. The main
issue with it, AFAICT after discussing this a bit with few people, is that it
requires a new clean host.
I'd like to hear what people here think about such and similar flows.
If you already had an engine and migrated to hosted-engine, what was good, what
was bad, what would you like to change?
If you plan such a migration, what do you find missing currently?
[1] http://red.ht/1vle8Vv
[2] http://www.ovirt.org/Migrate_to_Hosted_Engine
Best,
--
Didi
10 years
