Open Stack

On Wed, May 18, 2016 at 9:45 PM, chenying <chenyingkof at outlook.com> wrote:

> Hi all:
>         I want to know whether the backend-group concept  have been
> discussed or have other recommendations to us?
>         The backend-group concept means can be regarded as a mechanism to
> manage same type cinder backends .
>

​Sorry, I'm not quite following the analogy here.  Cinder allows multiple
backends and always has (similar to compute nodes in Nova) and we also
allow you to run them on a single node (particularly for cases like
external storage backends, no need to deploy a node to configure them)
​


> (backend-group  concept  like nova  Aggregate. The Falvor in Nova
> correspond to VolumeType  in Cinder)
> While backends are visible to users, backend-group are only visible to
> admin.
>

​So actually in Cinder backends are not visible to regular users.  We
abstract any/all devices from the user.  Not quite sure I follow.​


>
>         We can use this mechanism dynamic  to add/delete one backend
> form  backend-group without restarting volume services.
>
>        User case 1:
>        The  backends in backend-group-1 have SSD disk, more memory . The
> backend-group-1 can provide higher performance to user.
>           The other  backends  in  backend-group-2 have HHD disk, more
> capacity. The backend-group-2 can provide more storage space to user .
>
​Not sure, but we sort of do some of this already via the filter
scheduler.  An Admin can define various types (they may be set up based on
performance, ssd, spinning-rust etc).  Those types are then given arbitrary
definitions via a type (again details hidden from end user) and he/she can
create volumes of a specific type.
​


>        User case 2:
>          The backend-group is set with specific metadata/extra-spec
> (capability), Each node can have multiple backend-group, each backend-group
> can have multiple key-value pairs, and the same key-value pair can be
> assigned to multiple backend-group. This information can be used in
> the scheduler to enable advanced scheduling,
>          scheduler will select the backends from backend-group only.
>

​We have the capability to do this already, at least to an extent.  Perhaps
if you provide more details in this use case I can better understand.  It
is possible today to group multiple backends into a single Volume Type.  So
for example you could say "I want all backends with capability XYZ" and the
filter scheduler will handle that for you already (well, there are some
details on what those capabilities are currently).​


>
>
>
>     Thanks
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
​I'd be interested in hearing more about what you're thinking.  The concept
of dynamically adding/removing backends I think I kinda get, the risk there
is dealing with the ​existing data (volumes) on the backend when you remove
it.  We could do a migration, but that gets kinda ugly sometimes.  One
thing I have always wanted to see is a way to dynamically add/remove
backends, by dynamically I mean without restarting the c-vol services.  I'm
not sure there's a great use case or need for it though so I've never
really spent much time on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160518/3307495f/attachment.html>