Re: [Users] [Spice-devel] govirt 0.30 plans
On 11/06/2013 11:15 PM, i iordanov wrote:
Hi Christophe,
This one may turn out to not be an actual issue.
I had gotten used to the functionality offered by oVirt Live 0.8 (I think it bundles oVirt 3.0) where I was able to attach as user "admin@internal" to virtual machines created in the Administrative Console (rather than in the User Console).
It appears that oVirt 3.2 and 3.3 either do not allow this anymore or something else is amiss. One may not attach to such machines despite them being reported at /api/vms.
To make a long story short, I made one of these machines a Template and created a VM based on it in the User Console of admin@internal. After that, I was able to connect!
Do you think there is still anything wrong? Should we be able to attach to those vms (e.g. win and winbak)?
(if you see a behavior change in ovirt, you an also ask/cc on users@ovirt.org) in 3.0 we only allowed admin access to the API. in 3.1 we added user level access. main difference is users only get entities they have permissions with User Role on. an user with admin role can ask to get 'all', or just "me as a user" - all VMs which that admin has a User Role to. to not break api backward compatibility, default mode of the API remained 'admin mode', so you need to pass to the API "filter=true" to behave as a user. (we don't like this, and will try to come up with a better solution). i assume from Christophe next reply govirt (sensibly, as its geared for user access) default to user mode api. so you have two options - move to admin mode in govirt, or easier (and probably more consistent if you are aiming your solution for users rather than admins), give admin@internal a UserRole on the VMs, not an Admin Role. HTH, ITamar
Cheers, iordan
On Wed, Nov 6, 2013 at 4:22 AM, Christophe Fergeau <cfergeau@redhat.com> wrote:
On Tue, Nov 05, 2013 at 06:03:21PM -0600, i iordanov wrote:
What I have done is manually navigated to https://FQDN/api/vms in order to attach the output I get there for you to see if you can spot why libgovirt fails to look up the VMs. The call failed with name set to both "win" and "winbak".
This code is happily parsed by the attached test program, so I'm not sure parsing is at fault. You can look at the REST calls by setting the REST_DEBUG env variable to 'proxy'
Christophe
Hi Itamar, Thanks for the explanations! I'll let Christophe confirm that govirt defaults to user-mode. On Sat, Nov 16, 2013 at 5:26 AM, Itamar Heim <iheim@redhat.com> wrote:
so you have two options - move to admin mode in govirt, or easier (and probably more consistent if you are aiming your solution for users rather than admins), give admin@internal a UserRole on the VMs, not an Admin Role.
The client will be aimed at users, so there is no real problem here, once I got over the initial hurdle of actually attaching to machines. Thanks! iordan -- The conscious mind has only one thread of execution.
--LvAn5G4Ewe70kJ1i Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Nov 16, 2013 at 08:43:16AM -0500, i iordanov wrote:
Hi Itamar, =20 Thanks for the explanations! I'll let Christophe confirm that govirt defaults to user-mode.
Yes it does, ovirt-proxy.c has: g_object_class_install_property(oclass, PROP_ADMIN, g_param_spec_boolean("admin", "admin", "Use REST API as a= n admin", FALSE, G_PARAM_READWRITE = | G_PARAM_STATIC_STRINGS)); "FALSE" is the default value for the OvirtProxy::admin property. Christophe --LvAn5G4Ewe70kJ1i Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlKJw3EACgkQJKRp+3pW946BSACfbQUIn24zwIMVwjuUCQ0xhIKV tY4AoKyKiqLL7M32V7ybFwYaknb1D1jG =r0sU -----END PGP SIGNATURE----- --LvAn5G4Ewe70kJ1i--
participants (3)
-
Christophe Fergeau -
i iordanov -
Itamar Heim