- Devel - oVirt List Archives

Feature: Fedora 21 Support
by Sandro Bonazzola 05 Dec '14

05 Dec '14

Hi all, Currently oVirt is is not supported on Fedora 21. This feature will add Fedora 21 support to oVirt project. You are more than welcome to review the feature page[1] [1] http://www.ovirt.org/Features/Fedora_21_Support -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[QA] [DOC] Troubleshooting NFS Storage Issues
by Sandro Bonazzola 05 Dec '14

05 Dec '14

Hi, while testing hosted engine with a plain export like "/NotBackedUp/hosted 0.0.0.0/0.0.0.0(rw)" I had some issues and was pointed to Troubleshooting NFS Storage Issues[1] wiki page. Can someone from storage team update / review it? I see things like: "The NFS server must support NFSv3. oVirt 3.0 does not support NFSv4, while oVirt 4.0 does support NFSv4" or suggesting to use "no_subtree_check" disabling subtree checking, which has mild security implications, but can improve reliability in some circumstances without proper description of why this is suggested. CC-ing all authors I managed to find looking at page history. [1] http://www.ovirt.org/Troubleshooting_NFS_Storage_Issues Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[QE][ACTION REQUIRED] oVirt 3.6.0 status
by Sandro Bonazzola 04 Dec '14

04 Dec '14

Hi, Release criteria discussion has been closed with last week oVirt sync meeting [1]. Release management for 3.6.0 [2] will soon be updated with the accepted changes in release criteria. The remaining key milestones for this release must now be scheduled. For reference, external project schedules we're tracking are: Fedora 21: 2014-12-09 Fedora 22: 2015-XX-XX GlusterFS 3.7: 2015-04-29 OpenStack Kilo: 2015-04-30 Two different proposals have been made about above scheduling [3]: 1) extend the cycle to 10 months for allowing to include a large feature set 2) reduce the cycle to less than 6 months and split features over 3.6 and 3.7 Feature proposed for 3.6.0 must now be collected in the 3.6 Google doc [4] and reviewed by maintainers. The tracker bug for 3.6.0 [5] currently shows no blockers. There are 453 bugs [6] targeted to 3.6.0. Excluding node and documentation bugs we have 430 bugs [7] targeted to 3.6.0. [1] http://resources.ovirt.org/meetings/ovirt/2014/ovirt.2014-11-26-15.07.log.h… [2] http://www.ovirt.org/OVirt_3.6_Release_Management [3] http://lists.ovirt.org/pipermail/users/2014-November/028875.html [4] http://goo.gl/9X3G49 [5] https://bugzilla.redhat.com/show_bug.cgi?id=1155425 [6] http://goo.gl/zwkF3r [7] http://goo.gl/ZbUiMc -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

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