[Users] ovirt VM custom properties

[Brown, Chris (GE Healthcare)]

I was thinking about the vdsm hook scenario myself but I was stuck in
the thinking that hooks could only be invoked via custom properties or
before/after vdsm invocation.
Thank you for the heads up on that as that could definitely work. That
gives me an option down that route for now as well.

The other thought I had was to modify the existing GWT code for the user
portal.
I would just want to recompile/build an rpm for just the user portal
which seems to come from ovirt-engine-userportal-<version>.fc16.x86_64
I think I found where the code would need to be altered.

*Note in advance Hardware/OS guy attempting to code* Please excuse poor
form ;)

-->
ovirt-engine/frontend/webadmin/modules/userportal/src/main/java/org/ovir
t/engine/ui/userportal/client/modalpanels
--> file: NewVmModalPanel.java
--> lines 76 - 84
--> add: TabButton customPropertiesTabButton;
--> lines 100 - 108
--> add: customPropertiesTabButton = new TabButton("Custom Properties",
new CustomPropertiesTabPane());
--> lines 622 - 632
--> GWT code to constuct CustomPropertiesTabPane is already there.

This should be it unless there is something else I missed.
>From there I think I would just need to rebuild the
ovirt-engine-userportal RPM with just those changes.

I have a FC16 build env set up per:
http://www.ovirt.org/wiki/Building_Ovirt_Engine
Any helpful hints to just rebuild only the userportal with just those
changes?
Build output should ultimately be:
ovirt-engine-userportal-<version>.fc16.x86_64.rpm
In that manner I can rpm -U ovirt-engine-userportal on the target
system.

- Chris


-----Original Message-----
From: Itamar Heim [mailto:iheim at redhat.com] 
Sent: Wednesday, February 15, 2012 1:46 PM
To: Brown, Chris (GE Healthcare)
Cc: Andrew Cathrow; users; lpeer >> Livnat Peer
Subject: Re: [Users] ovirt VM custom properties

On 02/15/2012 05:34 PM, Brown, Chris (GE Healthcare) wrote:
> I assume the code for the Admin portal and PUP are shared (w/o 
> looking) in regards to editing VM settings.
> Thus if I understand what you are saying, is that given proper 
> permissions a power user would be able to view/edit the "custom 
> properties".
> Any thoughts on a way now short of code changes to work around this 
> (this is really a killer for our use cases)?
> An initial thought I had was to develop something perhaps a custom 
> page (for now) leveraging the API to allow such changes.

you may have noticed the API allows this, but is limited to admins...
you could create a role of admin with limited permissions just like a
power user role, and give it to these users.
only different from power user portal would be look and feel and the
fact they could see VMs of others (and the rest of the entities in the
system).
my view is the solution to this is to add a feature of permissions to
custom properties, which requires making them entities, rather than a
string, etc.

>
> Ultimately I see three core solutions to this issue:
> - The spice input/mouse interaction issues are resolved for all guests

> (old and new)
> - The UI allows for changes to the type of input device
> - Power users also have access to custom properties and can just use 
> the vdsm hook instead.

as a temporary solution, would it hurt your new guests if you make the
hook always enable the device? any other field in the vm you could base
the decision on by the hook as an interim solution (it can go as hacky
as vmname has X in it - hooks don't have to be based on custom
properties).

>
> Let me know your thoughts.