<div dir="ltr"><div class="gmail_default" style="font-family:courier new,monospace"><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 28, 2014 at 4:38 PM, David Gurtner <span dir="ltr"><<a href="mailto:aldavud@crimson.ch" target="_blank">aldavud@crimson.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi John<div><br></div><div>Of the two ideas you describe regarding replication I believe both have their unique merits and would allow for some fancy uses. The main difference I see is in who can define what level of replications are available, the consumer of the API, or the operator.</div>
<div>To me the second option is preferable, because the different drivers offer different kinds of replication (for example replication vs. erasure codes) and I am not sure a generic solution like the one suggested in the first option could offer the flexibility to optimally use the capabilities of the various drivers.</div>
</div></blockquote><div class="gmail_default" style="font-family:'courier new',monospace">Completely agree, and you've stated an easy summary of one of the questions I was hoping to get input on when starting this thread.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">
<div>On the other hand I don't think the two options are necessarily mutually exclusive, and maybe the first option could exist in addition and on top of the second one.</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">
Agreed, I'm a big fan of iterative development, and the concept of start small but think big :)</div><div class="gmail_default" style="font-family:'courier new',monospace"></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><br></div><div>At the same time I feel those are both advanced use-cases and the basic replication needs for a single site are already handled quite satisfactory by the current backend drivers. Therefore I believe the multi-site replication suggested by Gustavo would be the one thing where Cinder could really provide some added value on top of and independent of the backend drivers.</div>
<div>Yay Pony!</div></div></blockquote><div><br></div><div class="gmail_default" style="font-family:'courier new',monospace">For sure, this would be an ultimate goal. It is sort of a Pony or Unicorn for now, but at some point it would be the goal. For now though it seems independent from "which" impl to start with.</div>
<div class="gmail_default" style="font-family:'courier new',monospace"><br></div><div class="gmail_default" style="font-family:'courier new',monospace">Thanks for the feedback!!</div><div class="gmail_default" style="font-family:'courier new',monospace">
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Cheers,</div><div>David</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
<div><div>On Tue, Jul 29, 2014 at 12:06 AM, John Griffith <span dir="ltr"><<a href="mailto:john.griffith@solidfire.com" target="_blank">john.griffith@solidfire.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div style="font-family:courier new,monospace"><br></div><div class="gmail_extra">
<br><br><div class="gmail_quote"><div>On Mon, Jul 28, 2014 at 4:01 PM, gustavo panizzo (gfa) <span dir="ltr"><<a href="mailto:gfa@zumbi.com.ar" target="_blank">gfa@zumbi.com.ar</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 07/26/2014 11:28 AM, John Griffith wrote:<br>
> Hey OS-Operators,<br>
<div>><br>
> There are two features being worked on currently that I'd love to get<br>
> some feedback on:<br>
><br>
> 1. Replication<br>
<br>
</div>i would like to Cinder to be able to replicate data between different<br>
backend storages.<br>
<br>
sometimes your DR site does not have the same storage backend as your<br>
primary site, this is common when you rent the DR site.<br>
the usual workaround for this is restore from backup over the DR<br>
storage, which is painful and slow.<br>
<br>
ideally i would have a Fast dedicated storage on primary site and a<br>
bunch of lun(s) attached to a box with iscsi+lvm to provide volumes to<br>
compute nodes.<br>
<br>
if i have storage from the same 'vendor' on both sites that's great!<br>
cinder could offload data replication to vendor's appliance<br>
<br>
i know is a pony what i'm asking for, but i would really make a difference<br>
<span><font color="#888888"><br>
<br></font></span></blockquote><div><br></div></div><div style="font-family:'courier new',monospace">Thanks Gustavo!</div><div style="font-family:'courier new',monospace">
</div><div style="font-family:'courier new',monospace">I would really like that too, but the difficulties in doing that are exactly what I don't want to introduce, at least until we get a first pass with say "like storage systems" working. Definitely understand the need/desire here but at the same time I'm also not a fan of implementing a feature that's just slightly more than unusable.</div>
<div>
<div style="font-family:'courier new',monospace"><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span><font color="#888888">
--<br>
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333<br>
<br>
</font></span></blockquote></div></div><br></div></div>
<br></div></div><div>_______________________________________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div></div>