[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-API] assert_can_migrate regression


  • To: Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>
  • From: Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
  • Date: Fri, 29 Jun 2012 12:31:16 +0100
  • Accept-language: en-US
  • Acceptlanguage: en-US
  • Cc: "xen-api@xxxxxxxxxxxxx" <xen-api@xxxxxxxxxxxxx>
  • Delivery-date: Fri, 29 Jun 2012 11:31:25 +0000
  • List-id: User and development list for XCP and XAPI <xen-api.lists.xen.org>
  • Thread-index: Ac1V6rJ2JNAHSPNsQDGKkbvL124B4g==
  • Thread-topic: [Xen-API] assert_can_migrate regression

Hi,

Yes I think so-- IIRC all you can do with the xenops handler is the 
migrate-related stuff so it should be safe. It's just a pity it's mixed up with 
the other /services stuff since some of these should remain POOL_*

-- 
Dave Scott
XenServer System Architect

On Jun 29, 2012, at 12:11 PM, "Thomas Gazagnaire" <thomas@xxxxxxxxxxxxxx> wrote:

>> I think we could add "/services/xenops" as a first-class handler in the web 
>> server rather than overload the "/services" one.
>> 
>> In general I think it was a mistake to use 2 levels of dispatch: one using a 
>> prefix trie in the web server and the other in the pattern match. We should 
>> just use the prefix trie throughout.
>> 
>> Will that help fix your issue?
> 
> I'm not sure to understand. If it becomes a first-class handler, then you 
> mean it is safe to change the RBAC permission for this service (to allow VM 
> admins to use it) ?
> 
> --
> Thomas
> 
>> 
>> -- 
>> Dave Scott
>> XenServer System Architect
>> 
>> On Jun 29, 2012, at 11:49 AM, "Thomas Gazagnaire" <thomas@xxxxxxxxxxxxxx> 
>> wrote:
>> 
>>> Hi,
>>> 
>>> I found an other regression: only pool admins are now allowed to migrate 
>>> VMs. This is because the new migrate codepath is now using the 
>>> /services/xenops url (to communicate between xenops deamons) which can be 
>>> used by pool admins only, whereas migration was previously using the 
>>> /migrate url, which can be used by all VM admins.
>>> 
>>> So I can think of two possibles fixes for that regression:
>>> * either allow services/xenops to VM admins (this can lead to some security 
>>> issues if not done correctly)
>>> * or use the old /migrate url for VM migrations (this can be quite 
>>> intrusive I guess, as we need to check that every xenops client done by 
>>> xenops use this codepath)
>>> 
>>> What do you advice ?
>>> 
>>> --
>>> Thomas
>>> 
>>> On Jun 27, 2012, at 6:06 PM, Dave Scott wrote:
>>> 
>>>> Hi Thomas,
>>>> 
>>>> That sounds like an oversight. I think it would be good to add it back in 
>>>> migrate_send.
>>>> 
>>>> Cheers,
>>>> Dave
>>>>> -----Original Message-----
>>>>> From: xen-api-bounces@xxxxxxxxxxxxx [mailto:xen-api-
>>>>> bounces@xxxxxxxxxxxxx] On Behalf Of Thomas Gazagnaire
>>>>> Sent: 27 June 2012 16:54
>>>>> To: xen-api@xxxxxxxxxxxxx
>>>>> Subject: [Xen-API] assert_can_migrate regression
>>>>> 
>>>>> Hi all,
>>>>> 
>>>>> It seems that xapi/Xapi_vm_migrate.assert_can_migrate is not called
>>>>> anymore before the migration process.
>>>>> 
>>>>> I guess we should add it again somewhere in the body of migrate_send
>>>>> for instance. Does it make sense or did I miss something obvious here ?
>>>>> 
>>>>> --
>>>>> Thomas
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Xen-api mailing list
>>>>> Xen-api@xxxxxxxxxxxxx
>>>>> http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>>> 
> 

_______________________________________________
Xen-api mailing list
Xen-api@xxxxxxxxxxxxx
http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.