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 <jaypi...@gmail.com
<mailto:jaypi...@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@lists.openstack.__org
<mailto:OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to