[Engine-devel] Using REST API in web UI - review call summary
by Vojtech Szocs
Hi guys,
this is a summary of yesterday's review call, I'll try to highlight important Q/A and things we agreed on. Feel free to add anything in case I've missed something.
--
Q: Why don't we simply try to use existing Java SDK and adapt it for GWT apps? (asked by Michael & Gilad)
A: This might be a viable option to consider if we wanted to skip JavaScript-based SDK altogether and target Java/GWT code directly; we could simply take Java SDK and customize its abstractions where necessary, i.e. using HTTP transport layer implementation that works with GWT. In any case, this would mean coupling ourselves to Java SDK (which has its own release cycle) and I think this would complicate things for us.
As proposed on the meeting, I think it's best to aim for JavaScript SDK as the lowest common denominator for *any* web application that wants to work with REST API. oVirt GWT-based UI can simply bind to JavaScript SDK, i.e. Java/GWT code that just overlays objects and functions provided by JavaScript SDK. Another reason is ease of maintenance - I'd rather see JavaScript SDK's code generation process to be independent of any other SDK (people responsible for maintaining JavaScript SDK should have full control over generated code).
--
Q: What about functionality currently used by oVirt UI but not supported by REST API? (asked by Einav)
[For example, fetching VM entity over GWT RPC also returns related data such as Cluster name.]
A: Based on discussion I've had with other colleagues after yesterday's review call, I don't think that separate support-like backend layer is a good idea. Instead, this is the kind of functionality that could be placed in oVirt.js library. Logical operations like "get VMs and related data" would be exposed through oVirt.js (callback-based) API and ultimately realized as multiple physical requests to REST API via JavaScript Binding.
oVirt.js client would be completely oblivious to the fact that multiple physical requests are dispatched. In fact, since HTTP communication is asynchronous in nature, oVirt.js client wouldn't even notice any difference in terms of API consumption. This assumes JavaScript SDK would use callback-based (non-blocking) API instead of blocking one - after all, blocking API on top of non-blocking implementation sounds pretty much like leaky abstraction [1].
For example:
sdk.getVmsWithExtraData(
callbackToGetExtraDataForGivenVm, // might cause extra physical requests to REST API
callbackFiredWhenAllDataIsReady // update client only when all data is ready
)
[1] http://en.wikipedia.org/wiki/Leaky_abstraction
--
Last but not least, where to maintain JavaScript SDK projects: low-level JavaScript Binding + high-level oVirt.js library.
I agree that conceptually both above mentioned projects should go into dedicated "ovirt-engine-sdk-js" git repository and have their own build/release process. However, for now, we're just making baby steps so let's keep things simple and prototype these projects as part of "ovirt-engine" git repository.
... we can complicate things anytime, but we should know that any complex system that works has inevitably evolved from simple system that works ... (quote from http://en.wikipedia.org/wiki/Gall%27s_law)
Regards,
Vojtech
10 years, 10 months
[Engine-devel] [ovirt-testday] Fake PPC Support - Feedback
by Vinzenz Feenstra
This is a multi-part message in MIME format.
--------------070509070905070907070200
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi,
On the test day I was testing the Fake PPC support. I managed to
register the Fake PPC host into the engine. However when I tried to run
the VM it failed with libvirt responding:
*
libvirtError: internal error: process exited while connecting to
monitor: "kvm" accelerator does not exist.**
**No accelerator found!**
**KVM not supported for this target**
***
Which does not make much sense though. Since it should not try to use
'kvm'. And I am not really sure why it does.
Please let me know if there's anything else I would need to provide you
so you can figure out what is going on. Right now the server is still in
the same state. But I eventually will have to use it for something else.
Here's the part of the log which prints the generated DomainXML:
Thread-77::DEBUG::2014-01-23 15:43:46,834::vm::3130::vm.Vm::(_run)
vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::<?xml version="1.0"
encoding="utf-8"?>
<domain type="kvm" xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
<name>asdfasd</name>
<uuid>a5409fe7-8054-46ce-91c2-2d565e7edc5b</uuid>
<memory>524288</memory>
<currentMemory>524288</currentMemory>
<vcpu current="1">1</vcpu>
<memtune>
<min_guarantee>524288</min_guarantee>
</memtune>
<devices>
<channel type="unix">
<target name="com.redhat.rhevm.vdsm"
type="virtio"/>
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.com.redhat.rhevm.vdsm"/>
</channel>
<channel type="unix">
<target name="org.qemu.guest_agent.0"
type="virtio"/>
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.org.qemu.guest_agent.0"/>
</channel>
<input bus="usb" type="tablet"/>
<graphics autoport="yes" keymap="en-us" listen="0"
passwd="*****" passwdValidTo="1970-01-01T00:00:01" port="-1" type="vnc"/>
<emulator>/usr/bin/qemu-system-ppc64</emulator>
<memballoon model="virtio"/>
<controller index="0" type="scsi">
<address type="spapr-vio"/>
</controller>
<controller index="1" model="virtio-scsi" type="scsi"/>
<video>
<model heads="1" type="vga" vram="32768"/>
</video>
<interface type="bridge">
<mac address="00:1a:4a:65:ca:b2"/>
<model type="virtio"/>
<source bridge="ovirtmgmt"/>
<filterref filter="vdsm-no-mac-spoofing"/>
<link state="up"/>
</interface>
<disk device="cdrom" snapshot="no" type="file">
<address bus="0" controller="0" target="0"
type="drive" unit="0"/>
<source file="" startupPolicy="optional"/>
<target bus="scsi" dev="sda"/>
<readonly/>
<serial/>
</disk>
<disk device="disk" snapshot="no" type="file">
<source
file="/rhev/data-center/mnt/str-02.rhev.lab.eng.brq.redhat.com:_mnt_export_nfs_150_nfs04/efd2a9ce-6417-44e9-ac59-bb577f22bbc3/images/4f6be340-f7b1-4b78-9aa3-7390ffd6bec8/e4f6d99b-c94c-4ae9-8bd6-5212a1d4e9df"/>
<target bus="virtio" dev="vda"/>
<serial>4f6be340-f7b1-4b78-9aa3-7390ffd6bec8</serial>
<boot order="1"/>
<driver cache="none" error_policy="stop"
io="threads" name="qemu" type="raw"/>
</disk>
</devices>
<os>
<type arch="ppc64" machine="pseries">hvm</type>
</os>
<clock adjustment="0" offset="variable">
<timer name="rtc" tickpolicy="catchup"/>
</clock>
<cpu>
<topology cores="1" sockets="1" threads="1"/>
</cpu>
<qemu:commandline>
<qemu:arg value="-usbdevice"/>
<qemu:arg value="keyboard"/>
</qemu:commandline>
</domain>
Thread-77::DEBUG::2014-01-23
15:43:47,566::libvirtconnection::124::root::(wrapper) Unknown
libvirterror: ecode: 1 edom: 10 level: 2 message: internal error:
process exited while connecting to monitor: "kvm" accelerator does not
exist.
No accelerator found!
KVM not supported for this target
Thread-77::DEBUG::2014-01-23
15:43:47,567::vm::2247::vm.Vm::(_startUnderlyingVm)
vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::_ongoingCreations released
Thread-77::ERROR::2014-01-23
15:43:47,567::vm::2273::vm.Vm::(_startUnderlyingVm)
vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::The vm start process failed
Traceback (most recent call last):
File "/usr/share/vdsm/vm.py", line 2233, in _startUnderlyingVm
self._run()
File "/usr/share/vdsm/vm.py", line 3164, in _run
self._connection.createXML(domxml, flags),
File "/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py",
line 92, in wrapper
ret = f(*args, **kwargs)
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2920, in
createXML
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)
libvirtError: internal error: process exited while connecting to
monitor: "kvm" accelerator does not exist.
No accelerator found!
KVM not supported for this target
Extraction of the capabilities related to this:
<guest>
<os_type>hvm</os_type>
<arch name='ppc'>
<wordsize>32</wordsize>
<emulator>/usr/bin/qemu-system-ppc</emulator>
<machine>g3beige</machine>
<machine>prep</machine>
<machine>mpc8544ds</machine>
<machine>mac99</machine>
<machine>ppce500</machine>
<machine>virtex-ml507</machine>
<machine>bamboo</machine>
<machine>taihu</machine>
<machine>ref405ep</machine>
<machine>none</machine>
<domain type='qemu'>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
</features>
</guest>
<guest>
<os_type>hvm</os_type>
<arch name='ppc64'>
<wordsize>64</wordsize>
<emulator>/usr/bin/qemu-system-ppc64</emulator>
<machine>mac99</machine>
<machine>prep</machine>
<machine>mpc8544ds</machine>
<machine>g3beige</machine>
<machine>ppce500</machine>
<machine>virtex-ml507</machine>
<machine>pseries</machine>
<machine>bamboo</machine>
<machine>taihu</machine>
<machine>ref405ep</machine>
<machine>none</machine>
<domain type='qemu'>
</domain>
</arch>
<features>
<cpuselection/>
<deviceboot/>
</features>
</guest>
--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
--------------070509070905070907070200
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hi,<br>
<br>
On the test day I was testing the Fake PPC support. I managed to
register the Fake PPC host into the engine. However when I tried to
run the VM it failed with libvirt responding:<br>
<b><br>
libvirtError: internal error: process exited while connecting to
monitor: "kvm" accelerator does not exist.</b><b><br>
</b><b>
No accelerator found!</b><b><br>
</b><b>
KVM not supported for this target</b><b><br>
</b><b>
</b><br>
Which does not make much sense though. Since it should not try to
use 'kvm'. And I am not really sure why it does.<br>
Please let me know if there's anything else I would need to provide
you so you can figure out what is going on. Right now the server is
still in the same state. But I eventually will have to use it for
something else.<br>
<br>
Here's the part of the log which prints the generated DomainXML:<br>
<br>
Thread-77::DEBUG::2014-01-23 15:43:46,834::vm::3130::vm.Vm::(_run)
vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::<?xml version="1.0"
encoding="utf-8"?><br>
<domain type="kvm"
xmlns:qemu=<a class="moz-txt-link-rfc2396E" href="http://libvirt.org/schemas/domain/qemu/1.0">"http://libvirt.org/schemas/domain/qemu/1.0"</a>><br>
<name>asdfasd</name><br>
<uuid>a5409fe7-8054-46ce-91c2-2d565e7edc5b</uuid><br>
<memory>524288</memory><br>
<currentMemory>524288</currentMemory><br>
<vcpu current="1">1</vcpu><br>
<memtune><br>
<min_guarantee>524288</min_guarantee><br>
</memtune><br>
<devices><br>
<channel type="unix"><br>
<target name="com.redhat.rhevm.vdsm"
type="virtio"/><br>
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.com.redhat.rhevm.vdsm"/><br>
</channel><br>
<channel type="unix"><br>
<target name="org.qemu.guest_agent.0"
type="virtio"/><br>
<source mode="bind"
path="/var/lib/libvirt/qemu/channels/a5409fe7-8054-46ce-91c2-2d565e7edc5b.org.qemu.guest_agent.0"/><br>
</channel><br>
<input bus="usb" type="tablet"/><br>
<graphics autoport="yes" keymap="en-us"
listen="0" passwd="*****" passwdValidTo="1970-01-01T00:00:01"
port="-1" type="vnc"/><br>
<emulator>/usr/bin/qemu-system-ppc64</emulator><br>
<memballoon model="virtio"/><br>
<controller index="0" type="scsi"><br>
<address type="spapr-vio"/><br>
</controller><br>
<controller index="1" model="virtio-scsi"
type="scsi"/><br>
<video><br>
<model heads="1" type="vga"
vram="32768"/><br>
</video><br>
<interface type="bridge"><br>
<mac address="00:1a:4a:65:ca:b2"/><br>
<model type="virtio"/><br>
<source bridge="ovirtmgmt"/><br>
<filterref
filter="vdsm-no-mac-spoofing"/><br>
<link state="up"/><br>
</interface><br>
<disk device="cdrom" snapshot="no"
type="file"><br>
<address bus="0" controller="0"
target="0" type="drive" unit="0"/><br>
<source file=""
startupPolicy="optional"/><br>
<target bus="scsi" dev="sda"/><br>
<readonly/><br>
<serial/><br>
</disk><br>
<disk device="disk" snapshot="no" type="file"><br>
<source
file="/rhev/data-center/mnt/str-02.rhev.lab.eng.brq.redhat.com:_mnt_export_nfs_150_nfs04/efd2a9ce-6417-44e9-ac59-bb577f22bbc3/images/4f6be340-f7b1-4b78-9aa3-7390ffd6bec8/e4f6d99b-c94c-4ae9-8bd6-5212a1d4e9df"/><br>
<target bus="virtio" dev="vda"/><br>
<serial>4f6be340-f7b1-4b78-9aa3-7390ffd6bec8</serial><br>
<boot order="1"/><br>
<driver cache="none" error_policy="stop"
io="threads" name="qemu" type="raw"/><br>
</disk><br>
</devices><br>
<os><br>
<type arch="ppc64"
machine="pseries">hvm</type><br>
</os><br>
<clock adjustment="0" offset="variable"><br>
<timer name="rtc" tickpolicy="catchup"/><br>
</clock><br>
<cpu><br>
<topology cores="1" sockets="1" threads="1"/><br>
</cpu><br>
<qemu:commandline><br>
<qemu:arg value="-usbdevice"/><br>
<qemu:arg value="keyboard"/><br>
</qemu:commandline><br>
</domain><br>
<br>
Thread-77::DEBUG::2014-01-23
15:43:47,566::libvirtconnection::124::root::(wrapper) Unknown
libvirterror: ecode: 1 edom: 10 level: 2 message: internal error:
process exited while connecting to monitor: "kvm" accelerator does
not exist.<br>
No accelerator found!<br>
KVM not supported for this target<br>
<br>
Thread-77::DEBUG::2014-01-23
15:43:47,567::vm::2247::vm.Vm::(_startUnderlyingVm)
vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::_ongoingCreations
released<br>
Thread-77::ERROR::2014-01-23
15:43:47,567::vm::2273::vm.Vm::(_startUnderlyingVm)
vmId=`a5409fe7-8054-46ce-91c2-2d565e7edc5b`::The vm start process
failed<br>
Traceback (most recent call last):<br>
File "/usr/share/vdsm/vm.py", line 2233, in _startUnderlyingVm<br>
self._run()<br>
File "/usr/share/vdsm/vm.py", line 3164, in _run<br>
self._connection.createXML(domxml, flags),<br>
File
"/usr/lib64/python2.7/site-packages/vdsm/libvirtconnection.py", line
92, in wrapper<br>
ret = f(*args, **kwargs)<br>
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 2920,
in createXML<br>
if ret is None:raise libvirtError('virDomainCreateXML() failed',
conn=self)<br>
libvirtError: internal error: process exited while connecting to
monitor: "kvm" accelerator does not exist.<br>
No accelerator found!<br>
KVM not supported for this target<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
Extraction of the capabilities related to this:<br>
<br>
<guest><br>
<os_type>hvm</os_type><br>
<arch name='ppc'><br>
<wordsize>32</wordsize><br>
<emulator>/usr/bin/qemu-system-ppc</emulator><br>
<machine>g3beige</machine><br>
<machine>prep</machine><br>
<machine>mpc8544ds</machine><br>
<machine>mac99</machine><br>
<machine>ppce500</machine><br>
<machine>virtex-ml507</machine><br>
<machine>bamboo</machine><br>
<machine>taihu</machine><br>
<machine>ref405ep</machine><br>
<machine>none</machine><br>
<domain type='qemu'><br>
</domain><br>
</arch><br>
<features><br>
<cpuselection/><br>
<deviceboot/><br>
</features><br>
</guest><br>
<br>
<guest><br>
<os_type>hvm</os_type><br>
<arch name='ppc64'><br>
<wordsize>64</wordsize><br>
<emulator>/usr/bin/qemu-system-ppc64</emulator><br>
<machine>mac99</machine><br>
<machine>prep</machine><br>
<machine>mpc8544ds</machine><br>
<machine>g3beige</machine><br>
<machine>ppce500</machine><br>
<machine>virtex-ml507</machine><br>
<machine>pseries</machine><br>
<machine>bamboo</machine><br>
<machine>taihu</machine><br>
<machine>ref405ep</machine><br>
<machine>none</machine><br>
<domain type='qemu'><br>
</domain><br>
</arch><br>
<features><br>
<cpuselection/><br>
<deviceboot/><br>
</features><br>
</guest><br>
<br>
<pre class="moz-signature" cols="72">--
Regards,
Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R & D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com</pre>
</body>
</html>
--------------070509070905070907070200--
10 years, 10 months
[Engine-devel] ovirt-engine build segfault on Fedora 20
by Greg Sheremeta
Caution on upgrading your dev machine to Fedora 20. GWT compilation of "safari" (for Chrome) causes a segfault during the build. Strangely, the build appears to work, so I'm not sure what the net effect of the segfault is.
If you only compile for gecko (Firefox) [the default], you won't see the segfault.
In other words,
make clean install-dev PREFIX=$HOME/ovirt-engine DEV_EXTRA_BUILD_FLAGS_GWT_DEFAULTS="-Dgwt.userAgent=gecko1_8,safari"
causes the segfault
But
make install-dev PREFIX="$HOME/ovirt-engine"
works just fine.
I've duplicated this with with both OpenJDK and Oracle JDK.
If you'd like to duplicate, simple install a fresh F20 VM, and then run these commands:
1 sudo yum install nano
2 sudo nano /etc/hostname #set the hostname
3 sudo nano /etc/hosts #set the hostname
5 sudo yum install http://ovirt.org/releases/ovirt-release-fedora.noarch.rpm
6 sudo yum install git java-devel maven openssl postgresql-server m2crypto python-psycopg2 python-cheetah python-daemon libxml2-python jboss-as unzip otopi
7 mkdir projects
8 cd projects/
9 git clone git://gerrit.ovirt.org/ovirt-engine
10 cd ovirt-engine/
11 make install-dev PREFIX="$HOME/ovirt-engine"
Greg Sheremeta
Red Hat, Inc.
Sr. Software Engineer, RHEV
Cell: 919-807-1086
gshereme(a)redhat.com
10 years, 10 months
[Engine-devel] New gerrit flags behavior
by David Caro
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--uBNWC8njJPiGVqbVGpsO04mklfCaCVaix
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Hi everyone!
With the latest gerrit upgrade it has become easier to add the propagatio=
n of
the Code Review and Verified flags when doing a trivial rebase or when no=
code
was changed, so I've enabled those features for all the projects!
The change should become effective right away, so let me know if you have=
any
issues.
Enjoy!
--=20
David Caro
Red Hat S.L.
Continuous Integration Engineer - EMEA ENG Virtualization R&D
Email: dcaro(a)redhat.com
Web: www.redhat.com
RHT Global #: 82-62605
--uBNWC8njJPiGVqbVGpsO04mklfCaCVaix
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJS6PjbAAoJEEBxx+HSYmnD8V4IAIBrbYSMUPTtqrCqg3A46p10
OQfOvb/hm8dGQ4AQ1kP/7GmNYwzk7GjJxVCKZkXfsAaxu3yFSByfjiS9Y/UVF6C+
qWxyBZrifUFFZFBrCEZWlcu+7DbeZaJpu4F2lMwloD/RbydqVm31iHc3X+N6WkUs
IglFQkXIWiCJANA3BAdtG0/vIzlOpU7thmBnJVdWUOdxpG0yYMWJwU96M1sxBcqm
sDPbVOlk7UHIs1sSSmQDoQOV+U0o3HtskM8wD4lm62ecPrpqYXQqd4W7TmjXGtcy
UYwVR5VRa2xnJp6UjxJnaTu2ibYpbBs0L+p5RLf7uNUy7aEmqhc9RysHQpD6CpY=
=91bd
-----END PGP SIGNATURE-----
--uBNWC8njJPiGVqbVGpsO04mklfCaCVaix--
10 years, 10 months
[Engine-devel] Can not debug GWT with chrom
by Eli Mesika
Hi
I am trying to debug GWT with google-chrome-stable-32.0.1700.77-1.x86_64 on F19 and getting the following exception
onModuleLoad() threw an exception
Exception while loading module com.google.gwt.useragent.client.UserAgentAsserter. See Development Mode for details.
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.google.gwt.dev.shell.ModuleSpace.onLoad(ModuleSpace.java:406)
at com.google.gwt.dev.shell.OophmSessionHandler.loadModule(OophmSessionHandler.java:200)
at com.google.gwt.dev.shell.BrowserChannelServer.processConnection(BrowserChannelServer.java:526)
at com.google.gwt.dev.shell.BrowserChannelServer.run(BrowserChannelServer.java:364)
at java.lang.Thread.run(Thread.java:744)
Caused by: java.lang.RuntimeException: Deferred binding failed for 'com.google.gwt.useragent.client.UserAgentAsserter$UserAgentProperty' (did you forget to inherit a required module?)
at com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:53)
at com.google.gwt.core.shared.GWT.create(GWT.java:57)
at com.google.gwt.core.client.GWT.create(GWT.java:85)
at com.google.gwt.useragent.client.UserAgentAsserter.onModuleLoad(UserAgentAsserter.java:66)
... 9 more
Caused by: com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
at com.google.gwt.dev.shell.ModuleSpace.rebind(ModuleSpace.java:605)
at com.google.gwt.dev.shell.ModuleSpace.rebindAndCreate(ModuleSpace.java:465)
at com.google.gwt.dev.shell.GWTBridgeImpl.create(GWTBridgeImpl.java:49)
... 12 more
any ideas ???
10 years, 11 months
[Engine-devel] AppErrors properties
by Michal Skrivanek
Hi,
while trying to add a new message I couldn't help notice some ugliness in the code regarding our error messages in UI
- why do we have @DefaultStringValue in frontend/webadmin/modules/frontend/src/main/java/org/ovirt/engine/ui/frontend/AppErrors.java ? All strings are defined in individual properties anyway.
- so we have individual properties files….3 of them
REST - backend/manager/modules/dal/src/main/resources/bundles/AppErrors.properties
UP - frontend/webadmin/modules/frontend/src/main/java/org/ovirt/engine/ui/frontend/AppErrors.java
WA - frontend/webadmin/modules/userportal-gwtp/src/main/resources/org/ovirt/engine/ui/frontend/AppErrors.properties
funnily enough it's not that there are more messages in WA than UP, no, it's just full of random omissions, typos and discrepancies which do not make any logical sense
Can't we get rid of the defaults in the interface (useless) and have just one property containing all the messages and use the sam file in all 3 places. And only if there is intentionally a different message in e.g. UP than in WA we can have an override/additional property file there (just by briefly going through most of the differences there's not a single case)
Thanks,
michal
10 years, 11 months
[Engine-devel] proposing Arik Hadas as a maintainer of engine core
by Michal Skrivanek
Dear engine-core maintainers,
I'd like to propose Arik Hadas as a maintainer of oVirt engine backend
Since he started with oVirt project in October 2012 he was working in various areas in engine core, demonstrated his abilities with more than 200 patches merged to engine master alone. Tons of migration related fixes, refactoring of legacy code, but also new complex features including complementary patches in UI, REST and VDSM code (e.g. Live Snapshots with RAM, locking improvements for VM&Template operations)
Thanks in advance for your response.
Thanks,
michal
10 years, 11 months
