- Devel - oVirt List Archives

Frontend - please avoid putting business logic into Views
by Vojtech Szocs 03 Dec '14

03 Dec '14

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

1 0

Important change in UI plugins REST API integration
by Vojtech Szocs 03 Dec '14

03 Dec '14

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

5 7

Re: [ovirt-devel] hosted-engine setup/migration features for 3.6
by Yedidyah Bar David 03 Dec '14

03 Dec '14

----- 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

1 1

Re: [ovirt-devel] hosted-engine setup/migration features for 3.6
by Bob Doolittle 03 Dec '14

03 Dec '14

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 >> > >

1 0

ioprocess 0.14.0 released
by Saggi Mizrahi 03 Dec '14

03 Dec '14

ioprocess 0.14.0 has been tagged and released. The changelog includes: - python-bindings: IOProcess objects can be collected by the GC - python-bindings: Slave processes can optionally be collected by zombie reaper It's recommended that everyone upgrade to the latest version. Please test and give karma: https://admin.fedoraproject.org/updates/search/ioprocess-0.14.0 Good day.

3 5

[QE][ACTION REQUIRED] oVirt 3.5.1 RC status
by Sandro Bonazzola 03 Dec '14

03 Dec '14

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

1 0

Some ideas on oVirt Java SDK
by Vojtech Szocs 03 Dec '14

03 Dec '14

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

3 9

REST API CSRF protection header name
by Vojtech Szocs 03 Dec '14

03 Dec '14

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

2 1

hosted-engine setup/migration features for 3.6
by Yedidyah Bar David 03 Dec '14

03 Dec '14

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

1 0

[QE][ACTION REQUIRED] oVirt 3.5.1 RC status - postponed
by Sandro Bonazzola 02 Dec '14

02 Dec '14

Hi, We were supposed to start composing oVirt 3.5.1 RC today *2014-12-02 08:00 UTC* from 3.5 branch. We have still blockers for oVirt 3.5.1 RC release so we need to postpone it untill they'll be fixed. The new tentative date for 3.5.1 RC composition is set to *2014-12-09 08:00 UTC The bug tracker [1] shows 2 open blocker: Bug ID Whiteboard Status Summary 1168689 infra ASSIGNED Upgrading from 3.4.4 to 3.5.1 snapshot the vdsm rpm throw an exception 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. There are still 69 bugs [2] targeted to 3.5.1. Excluding node and documentation bugs we still have 46 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

2 1