<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 18, 2016 at 9:45 PM, chenying <span dir="ltr"><<a href="mailto:chenyingkof@outlook.com" target="_blank">chenyingkof@outlook.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div dir="ltr">Hi all:<br> I want to know whether the backend-group concept have been discussed or have other recommendations to us?<br> The backend-group concept means can be regarded as a mechanism to manage same type cinder backends .<br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">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)</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr">(backend-group concept like nova Aggregate. The Falvor in Nova correspond to VolumeType in Cinder)<br>While backends are visible to users, backend-group are only visible to admin.<br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">So actually in Cinder backends are not visible to regular users. We abstract any/all devices from the user. Not quite sure I follow.</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr"> <br> We can use this mechanism dynamic to add/delete one backend form backend-group without restarting volume services.<br> <br> User case 1:<br> The backends in backend-group-1 have SSD disk, more memory . The backend-group-1 can provide higher performance to user.<br> The other backends in backend-group-2 have HHD disk, more capacity. The backend-group-2 can provide more storage space to user .<br></div></div></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">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.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline"></div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr"> User case 2:<br> The backend-group is set with specific metadata/extra-spec (capability), Each node can have multiple backend-group, each backend-group<br>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<br>the scheduler to enable advanced scheduling,<br> scheduler will select the backends from backend-group only.<br></div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace;display:inline">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).</div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="ltr"> <br> <br> <br> Thanks<br> </div></div>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div><div class="gmail_extra"><div class="gmail_default" style="font-family:monospace,monospace">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.</div><br></div></div>