11:26 a.m.
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(a)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(a)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
2:43 p.m.
New subject: [Users] [Spice-devel] govirt 0.30 plans
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(a)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.
8:36 a.m.
New subject: [Users] [Spice-devel] govirt 0.30 plans
--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--
3834
days inactive
3836
days old
2 comments
3 participants
participants (3)
-
Christophe Fergeau -
i iordanov -
Itamar Heim