we would like to limit a user as much as possible and give him only
actions that he needs with his VM. If we disallow a user the right in
system|configure system|manipulate permissions), we give the user, in
user portal, only basic mode. But then three is no option to attach a cd
in the basic user portal. In basic mode user interface there is no
chance in attaching a cd (as this is a basic operation a solution to
this would be a button attaching a cd when starting a vm).
If we allow the user to manipulate permissions, we get the extended menu
back and the user is limited, but we found unacceptable when he is
adding permission to the VM, he sees all the users (name, surname,
email!) in the ovirt authentication mechanism? A solution to this would
be authenticating to the directory service as a user an not as ovirt
admin user - meaning that the user will see only users that we allowed
he sees in the ldap directory.
We are working to rewrite the current installer to something more portable and flexible.
Currently two milestones had been reached:
1. Ability to install almost fully functioning ovirt-engine at $HOME for development environment.
2. Porting ovirt-engine to run on different distribution, Gentoo.
We will be glad to receive feedback on either.
Code is located at github for now, at otopi branch.
Instructions for setting up development environment are available.
Gentoo overlay for live ebuilds is available, the following packages are valid:
Why Gentoo first? because source based distributions demands the highest level of customization, solving the complex issue ease to continue porting to binary based distributions.
Please remember that this is work in progress, and not guarantee to be stable or even work... The installer was re-written from scratch so expect issues at this point.
Any feedback is welcomed, we are focusing first in providing the functionality of the existing installer to be able to replace it entirely before going into new adventures.
 Alex Lourie, Sandro Bonazzola, Alon Bar-Lev
The proposed feature will make it possible to run a VM which was reverted to live snapshot
or created from live snapshot with the same memory state as it was at the moment the live
snapshot was taken.
All feedback is welcome!
Hello all ovirt-engine developers,
When I first joined the ovirt project, it took me about two weeks to setup a development environment, I needed to work on a bug related to host-deploy so I needed an environment that could use the ssh, PKI, vdsm-bootstrap and communicate with vdsm using SSL, this was virtually impossible to do so without tweaking the product in a way that it is so different from production use, that I cannot guarantee that whatever tested in development will actually work in production.
I peeked at the installation script in a hope that I can create partial environment similar to production, but I found that the packaging implementation makes to much assumption and is very difficult to adopt. The fact that I do not use fedora/rhel for my development made it even worse.
I had no other option than to create rpms after each of my changes and test each in real production like setup.
It was obvious to me that the manual customization of developers to achieve working product will eventually break as product grow and move away from being developer friendly to production friendly. For example, product defaults cannot be these which serve developers, but these which serve production the best, or having a valid PKI setup cannot be optional any more as components do need to use it. Same for location of files and configuration, for example, if we write a pluggable infrastructure for branding, we cannot damage the interface just because developers runs the product in their own manual customization.
I took the opportunity handed to me to port the ovirt-engine to other distributions in order to provide a development environment that is similar to production setup. Together with Sandro Bonazzola and Alex Lourie we re-wrote the whole installation of the product which can also be used to setup the desired development environment.
Within this environment the product is set up using the same tools and configuration as in production, while the process does not require special privileges nor changes the state of the developer machine.
A complete documentation is available, I preferred to use README within the source tree as wiki tend to quickly become obsolete, while documentation within source tree can be modified by the commit that introduces a change. I will redirect to this file from the current wiki once the site will be up.
In a nut shell, after installing prerequisites, build and install the product using:
$ make clean install-dev PREFIX=$HOME/ovirt-engine
This will run maven and create product installation at $HOME/ovirt-engine
Next, a setup phase is required just like in production, to initialize configuration and database:
You have now fully functional product, including PKI, SSL, host-deploy, tools.
No manual database updates are required, no lose of functionality.
All that is left is to start the engine service:
$ $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine.py start
Access to application:
Debugging port is opened at port 8787.
Farther information exists in the documentation.
There are several inherit benefits of the new environment, the major one is the ability to manage several environments in parallel on the same host. For example, if we develop two separate features on two branches we can install the product into $HOME/ovirt-engine-feature1 and $HOME/ovirt-engine-feature-2 and have a separate database for each, if we modify the ports jboss is listening to we can run two instances of engine at the same time!
We will be happy to work with all developers to assist in porting into the new development environment, the simplest is to create a new database for this effort. Moti has a sequence of converting the existing database owned by postgres to be owned by the engine, Moti, can you please share that?
We are sure there are missing bits, we will be happy to know these so we can improve.
I am aware that developers (especially java) are conservative, but I ask you to give us a chance, so that we make it easy for developers to join the project, and to allow us to drop the parallel effort of packaging to production and fixing the broken development environment.
A special thanks to developers who took the time to test and provide feedback before the merged:
- Yaniv Bronheim
- Moti Asayag
- Limor Gavish
- Sharad Mishra
- Ofer Schreiber
We are hoping that after migration you will be find this environment useful and friendly,
I'm working on a patch to support custom device properties in ovirt-engine.
I would like that custom device properties format can be set using engine-config
command in a similar way as UserDefinedVMProperties. What is needed to be done
to support this?
just a quick update, recently we fixed an issue  with UI Plugin REST API integration trying to keep-alive the current REST API session, which was causing repeated "User logged in" events in GUI, along with new REST API session created each time the heartbeat request was fired. Please refer to commit message for more details on this issue.
There are some things to be aware of with regard to UI Plugin REST API integration:
- all plugins still receive a single session ID based on WebAdmin user credentials, i.e. keep the current "single-admin-session-for-all-plugins" behavior
- session timeout is set to 6 hours --> 2x more than default REST API session timeout
- WebAdmin will *not* try to keep-alive the session via periodic heartbeat requests, i.e. break the current "keep-session-alive-while-user-stays-authenticated" behavior
In practice, this means that after a user logs into WebAdmin, if no plugin interacts with the REST API session via provided ID for more than 6 hours, the session will time-out eventually. Unfortunately, for now, we can't support the session keep-alive mechanism due to issues with HTTP 'Authorization' header handling in web browsers, but with RFE  it would be possible to re-implement the session keep-alive mechanism.
On the other hand, we'll most likely revisit the current "single-admin-session-for-all-plugins" behavior in future, i.e. have special Engine users created for use with UI Plugin REST API integration, with permissions of such users under control by the admin. This would change the current behavior to something like "separate-user-session-for-each-plugin", with individual plugins able to create their own REST API session on demand.
Content-Type: text/plain; charset=utf-8
I would like to have your opinions on which inheritance type to use in the DB.
We are adding an "external provider" entity to the system which will be able to provide various resources (networks, hosts, etc).
These providers will be distinguishable by "type".
The basic definition of a provider contains:
Some providers might need additional properties such as:
In Java this is easily represented by inheritance.
In the DB however, there are 3 approaches that we can take:
1. No inheritance. This means that each type will wit in his own table, with no relation or re-use.
2. Single table inheritance. All types sit in a single table, and each has his corresponding columns.
3. Multiple table inheritance. Each type sists in his own table, where the PK is FK for the most basic table (providers).
Pros for each approach:
1. None that I can think of.
2. No joins: Better performance Easier for developer to see the DB info Facilitate column reuse
3. Constraints can be set on each column
Cons for each approach:
1. No reuse of DB entities + no compliance for column types Most cumbersome to query all providers
2. Can't put some constraints on non-base columns (esp. not null)
3. Joins are needed - opposite of the pros of 2.
>From personal experience, I find #2 to be better and easier to work with & maintain.
What are your thoughts?
Content-Type: text/html; charset=utf-8
<html><body><div style=3D"font-family: times new roman, new york, times, se=
rif; font-size: 12pt; color: #000000"><div>Hi All,<br></div><div><br></div>=
<div>I would like to have your opinions on which inheritance type to use in=
the DB.<br></div><div>We are adding an "external provider" entity to the s=
ystem which will be able to provide various resources (networks, hosts, etc=
).<br></div><div><br></div><div>These providers will be distinguishable by =
"type".<br></div><div>The basic definition of a provider contains:</div><di=
Some providers might need additional properties such as:<br></div><div><ul>=
<li>user<br></li><li>password<br></li></ul><div>In Java this is easily repr=
esented by inheritance.<br></div><div><br></div><div>In the DB however, the=
re are 3 approaches that we can take:<br></div><div><ol><li>No inheritance.=
<br>This means that each type will wit in his own table, with no relation o=
r re-use.<br></li><li>Single table inheritance.<br>All types sit in a singl=
e table, and each has his corresponding columns.<br></li><li>Multiple table=
inheritance.<br>Each type sists in his own table, where the PK is FK for t=
he most basic table (providers).<br></li></ol><div><br></div><div>Pros for =
each approach:<br></div><div><ol><li>None that I can think of.<br></li><li>=
No joins:<br> Better performance<br> &nbs=
p; Easier for developer to see the DB info<br> =
Facilitate column reuse<br></li><li>Constraints can be set on each column<b=
r></li></ol></div></div></div></div><div>Cons for each approach:<br></div><=
div><ol><li>No reuse of DB entities + no compliance for column types<br>Mos=
t cumbersome to query all providers<br></li><li>Can't put some constraints =
on non-base columns (esp. not null)<br></li><li>Joins are needed - opposite=
of the pros of 2.<br></li></ol><div>From personal experience, I find #2 to=
be better and easier to work with & maintain.<br></div><div><br></div>=
<div>What are your thoughts?<br></div></div><div><br></div><div><span name=