Open Stack

Thanks Alex and Jay Pipes.

@Alex, I want a common interface for all VM operations to get target host
list, seems only adding a new API 'confirm_before_migration' not enough to
handle this? ;-)

@Jay Pipes, I will try to see if we can export this in K or L via Gantt

Thanks.


2014-07-23 17:14 GMT+08:00 Alex Xu <xuhj at linux.vnet.ibm.com>:

> Maybe we can implement this goal by another way, adding new API
> 'confirm_before_migration' that's similar with 'confirm_resize'. This also
> can resolve Chris Friesen's concern.
>
>
> On 2014年07月23日 00:13, Jay Pipes wrote:
>
>> On 07/21/2014 11:16 PM, Jay Lau wrote:
>>
>>> Hi Jay,
>>>
>>> There are indeed some China customers want this feature because before
>>> they do some operations, they want to check the action plan, such as
>>> where the VM will be migrated or created, they want to use some
>>> interactive mode do some operations to make sure no errors.
>>>
>>
>> This isn't something that normal tenants should have access to, IMO. The
>> scheduler is not like a database optimizer that should give you a query
>> plan for a SQL statement. The information the scheduler is acting on
>> (compute node usage records, aggregate records, deployment configuration,
>> etc) are absolutely NOT something that should be exposed to end-users.
>>
>> I would certainly support a specification that intended to add detailed
>> log message output from the scheduler that recorded how it made its
>> decisions, so that an operator could evaluate the data and decision, but
>> I'm not in favour of exposing this information via a tenant-facing API.
>>
>> Best,
>> -jay
>>
>>  2014-07-22 10:23 GMT+08:00 Jay Pipes <jaypipes at gmail.com
>>> <mailto:jaypipes at gmail.com>>:
>>>
>>> On 07/21/2014 07:45 PM, Jay Lau wrote:
>>>
>>> There is one requirement that some customers want to get the
>>> possible
>>> host list when create/rebuild/migrate/__evacuate VM so as to
>>> create a
>>> resource plan for those operations, but currently
>>> select_destination is
>>> not a REST API, is it possible that we promote this API to be a
>>> REST API?
>>>
>>>
>>> Which "customers" want to get the possible host list?
>>>
>>> /me imagines someone asking Amazon for a REST API that returned all
>>> the possible servers that might be picked for placement... and what
>>> answer Amazon might give to the request.
>>>
>>> If by "customer", you are referring to something like IBM Smart
>>> Cloud Orchestrator, then I don't really see the point of supporting
>>> something like this. Such a customer would only need to "create a
>>> resource plan for those operations" if it was wholly supplanting
>>> large pieces of OpenStack infrastructure, including parts of Nova
>>> and much of Heat.
>>>
>>> Best,
>>> -jay
>>>
>>>
>>> _________________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.__org
>>> <mailto:OpenStack-dev at lists.openstack.org>
>>> http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
>>>
>>>
>>>
>>>
>>> --
>>> Thanks,
>>>
>>> Jay
>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,

Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/177e2f99/attachment.html>