Enable ceate a volume on force host

Registered by Guangya Liu (Jay Lau) on 2013-11-02

Cinder scheduler will help select host for create request based on scheduler filters, but end user cannot create volume directly on a force host.

It is better that we add this feature to enable end user can create volumes on a force host.

Blueprint information

Status:
Complete
Approver:
John Griffith
Priority:
Not
Drafter:
None
Direction:
Needs approval
Assignee:
Guangya Liu (Jay Lau)
Definition:
Obsolete
Series goal:
Accepted for future
Implementation:
Not started
Milestone target:
None
Completed by
John Griffith on 2015-04-14

Related branches

Sprints

Whiteboard

Gerrit topic: https://review.openstack.org/#q,topic:bp/cinder-force-host,n,z

Addressed by: https://review.openstack.org/55076
    Enable create volume on force hosts

In many deployments, the provider does not in any way want users doing this, so the feature should be optional and easily disabled. - DuncanT

Yes, DuncanT. The feature is configurable. As I was using "--availability-zone az:force_host" to set force host. If admin using "--availability-zone az", then no force host. Thanks. --jay-lau-513

Avishay: Non-admin users in Cinder are not aware of hosts, and we (or at least I) are trying to keep it that way. Admins can create volume types where a specific host is specifide with volume_backend_name, and users can use that. If this addition is only for admins, then I am less against it, but again, admins can already do this with volume types.

Yes, this is only for admin, I will update the patch later. Though admin can do this via volume types, but it would be nice that if they can achieve this without any configuration but only one command. --jay-lau-513

<jdg>
Need to take a closer look at the value here and consider how to make this a clean and admin-only feature in Juno. Not worth trying to cleanup and fix to get in at the last minute for Icehouse

eharney: This blueprint appears to be dead? (14-April-2015)

@eharney
Agreed, "it's dead Jim"... and should be. There's no need for this IMO anyway, you can set a voume-type that points to the specific/desired backend and use that. Even if you have multiple backends of the same type, there's nothing preventing a third type that maps directly to a single backend and keeps the abstraction intact.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.