[Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
by Greg Sheremeta
Has anyone else noticed that GWT Dev Mode is unbearably slow for WebAdmin? On my machine, it's to the point where I might as well rebuild the entire application for every change and not bother with Dev Mode. Pages take 4 or 5 minutes to render. Sometimes after 5 minutes, I just give up, close everything, and rebuild the app.
For now, I want to see if others have this issue. If we confirm that it's widespread, we can discuss ways to mitigate.
Greg Sheremeta
Red Hat, Inc.
Sr. Software Engineer, RHEV
Cell: 919-807-1086
gshereme(a)redhat.com
10 years, 8 months
[Engine-devel] Small suggestions for engine-log-collector
by Vojtech Szocs
Hi guys,
based on my testing during last week's oVirt 3.4 RC test day [1],
I have a couple of small suggestions for engine-log-collector:
1, in /etc/ovirt-engine/logcollector.conf - I think there's typo:
#key-file=/etc/pki/engine/keys/engine_id_rsa
should be:
#key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa
2, to force password-based ssh auth, one has to do this:
engine-log-collector -k ""
because running this:
engine-log-collector -k
returns error message:
error: -k option requires an argument
however, help for -k option mentions *supplying* the argument:
If a identity file is not supplied the program will prompt for a password.
so either the help text should mention empty string,
or -k option should allow missing argument (this was
my initial understanding according to help text)
Since these are just small things, I'm wondering if I should
create RFE or if Keith/others can say if they are relevant.
Thanks,
Vojtech
[1] http://etherpad.ovirt.org/p/3.4-testday-3
10 years, 8 months
Re: [Engine-devel] [Users] centralized Logging engine and hypervisor
by Sven Kieske
Am 20.03.2014 11:04, schrieb Martin Perina:
>
>
>
> I didn't try it, but some info can be found in this thread:
>
> http://stackoverflow.com/questions/10400263/jboss-as-7-configure-logging-...
Thanks for the link, for documentation purposes, I'll post my findings
here to, so if someone needs this in the future, feel free to use it:
Here is a custom implemented syslog handler for jboss 7.1:
http://randomtekkstuff.blogspot.de/2013/03/jboss-as-7-syslog-handler.html
I will test this out, once I found the jboss module directory..
In the meantime:
Would ovirt-devs consider it save to "sideload" my own
jboss module?
I know this will get painful to maintain once I want to upgrade
so I'm already asking:
Is there a chance as a first step to include a custom
syslog handler jboss module into ovirt (for jboss < 7.2) ?
Later this could get expanded to easily allow to use syslog..
--
Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator
Mittwald CM Service GmbH & Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
10 years, 8 months
[Engine-devel] hosted engine in 3.4
by Jiri Moskovcak
Hi,
I was testing the hosted-engine in 3.4 and ran into some troubles, so
I'm going to share the results to get some help (or ideas how to fix
those problems)
Minor:
1. You need to have some MAC address with static ip and FQDN, otherwise
you have to change /etc/hosts at least for the first part of the setup
- I think the setup wizard should be improved to do this workaround
automatically
2. When the VM install is complete I would expect the setup wizard to
install the engine to the VM automatically - which at least in my case -
doesn't happen
- I found a mallformed fedora-virt-prerelease.repoo file on the
installed vm, which might be the cause:
https://bugzilla.redhat.com/show_bug.cgi?id=1075963
Major:
1. once I managed to install the engine to the vm it tried to add the
host it was running on to the engine and it failed with a message "Host
compatibility version doesn't match the cluster compatibility version",
and then it marked the host as non operational which killed the vm with
the engine, so the engine actually committed suicide...
- the host and the engine were installed from the same repo, so I guess
the incompatibility was caused by the CPU family, and even if I made the
mistake I think the engine should be a bit more clever and not kill itself
--Jirka
10 years, 8 months
[Engine-devel] [ANN] oVirt 3.4.0 Second Release Candidate is now available
by Sandro Bonazzola
The oVirt team is pleased to announce that the 3.4.0 Second Release Candidate is now available for testing.
Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1].
Please ensure to follow install instruction from release notes if you're going to test it.
The existing repository ovirt-3.4.0-prerelease has been updated for delivering this release candidate and future refreshes until final release.
An oVirt Node iso will also be available soon.
We decided to postpone Final Release by one week in order to properly test the bugs fixed since last Release Candidate.
Help us make this the best release ever, testing it yourself!
[1] http://www.ovirt.org/OVirt_3.4.0_release_notes
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
10 years, 8 months
[Engine-devel] Vms search issue
by Moti Asayag
Hi,
As a result of patch "core : Search VMs based on MAC address" [1]
The same vm is returned by the search query as the number of its nics.
I'd suggest to revert this patch and not introduce a join between
vnics to vm_static vms: first, it won't return the expected result when
a vm has more than a signle nic, second due to adding great impact on that view.
As an alternative, I'd suggest utilizing the join in the search-engine
with vm_interface_view. See SearchObjectAutoCompleter:
// vms - vm network interface
addJoin(SearchObjects.VM_OBJ_NAME, "vm_guid", SearchObjects.VM_NETWORK_INTERFACE_OBJ_NAME, "vm_guid");
So the query will look like: "vms: vnic.MAC = 'xx:xx:xx:xx:xx:xx'"
[1] http://gerrit.ovirt.org/#/c/25805
Regards,
Moti
10 years, 8 months
[Engine-devel] migration of VM, which protocol actually works?
by aditya mamidwar
i wanted to learn about the modules so that i could understand how the
engine POSTS and sends data to the backend sql database and other scripts
to perform various options.
for e.g i need to know which code actually collects the storage path for
the ISO s during ISCSI storage domain setup.
also how the hosts, clusters and data centers are made and stored at the
backend.
if i want to add a new UI that bypasses some of these complicated tasks
(again for personal understanding), will I be able to do that.
Also i would like to mention that am working on making a little changes to
how the ISCSI protocol works..
My another doubt is:
when are the NFS/ISCSI/FC protocols actually used in ovirt. like what part
of the VM running state?
are their purpose limited to just copying the ISO from the storage center
to the path required by the Host.
Are the protocols them self responsible for sending and getting data during
VM execution on a node.
The concept of node and migration has left me a little confused.
since each node can run multiple VMs , so during the running/execution of
the VM , do the network protocols actully work, if not , then how is that
achieved.
if yes, again my question arises, which module should i focus on regarding
this issue.
thanks
--
-Aditya Mamidwar
10 years, 8 months
Re: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
by Doron Fediuck
----- Original Message -----
> From: "Yedidyah Bar David" <didi(a)redhat.com>
> To: "Doron Fediuck" <dfediuck(a)redhat.com>
> Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "Jiri Moskovcak" <jmoskovc(a)redhat.com>
> Sent: Sunday, March 16, 2014 12:28:27 PM
> Subject: Re: Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
>
> Might be better to discuss this on bugzilla.
>
Bugzilla is not a mailing list. Moving to engine-devel.
> ----- Original Message -----
> > From: "Doron Fediuck" <dfediuck(a)redhat.com>
> > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com>
> > Cc: "Yedidyah Bar David" <didi(a)redhat.com>, "Jiri Moskovcak"
> > <jmoskovc(a)redhat.com>
> > Sent: Sunday, March 16, 2014 12:01:51 PM
> > Subject: Bug 1076530 – engine shouldn't kill the vds running the VM with
> > the hosted engine
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1076530
> >
> > Sandro,
> > I think this would be solved by a better validation during setup /
> > deployment.
>
> This can't be done during Validation in the otopi sense of the word.
> At that point the engine does not exist yet and so we can't know what
> versions it supports etc.
>
Why not?
You have the vdsm supported versions in a file (dsaversion IIRC)
and you should be able to get the relevant engine info before or
after deploying the DB.
> It might be possible (didn't check) to check the versions right before
> trying to add the host to the cluster. This means we do not want to
> abort (as we can do during Validation if something does not pass it).
> What can we do? Perhaps offer a few options:
> 1. Do abort (will do mostly what happens today)
> 2. Let the user try to manually fix, probably by trying to change
> the compatibility version of the cluster, and then try adding the
> host again
> 3. Try to fix ourselves (same) and try adding again
> 4. Best would be to someone upgrade libvirt and reconfigure vdsm.
> Not sure that's easy or even possible at this stage, where VM is
> running and we do not want to loose it.
>
> Thinking about this again, I am not sure the current behavior is that
> bad. "Fixing" by re-installing with the correct versions is probably
> way simpler than fixing after installation is (mostly) complete.
>
> >
> > I'm not keen on adding hosted-engine logic into the engine code.
>
> Not sure about that. Not that it would help much, because the root
> problem will still have to be solved, but in principle it might be
> a good thing if the engine knows that killing some host will kill itself,
> and so try harder to not do that and just leave it in some zombie,
> requires-manual-action state. This is obviously more important during
> normal operation than during installation.
> --
> Didi
>
10 years, 8 months
[Engine-devel] Source code unerstanding
by aditya mamidwar
Hey,
is there a simpler way to know which code is responsible for which module
of the engine.
is there a documentation maintained. or how can identify the files which
are important for me.
--
-Aditya Mamidwar
10 years, 8 months
[Engine-devel] adding scripts
by aditya mamidwar
I want to commit changes to the engine by adding some bash scripts.
the scripts should be invoked once a button or tab is selected in the
webadmin portal by the user.
can someone guide on achieving this.
--
-Aditya Mamidwar
10 years, 8 months
