Open Stack

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
>