[Spice-devel] govirt 0.30 plans

[Itamar Heim]

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 at 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 at 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 at 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 at 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 at 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
>
>
>