Open Stack

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