<tt><font size=2>Philipp</font></tt><font size=2 face="sans-serif">,</font>
<br>
<br><font size=2 face="sans-serif">Thanks for the feedback, below if my
view, and I would like to hear what others think.</font>
<br>
<br><font size=2 face="sans-serif">I would typically expect the </font><tt><font size=2>"replication_partners"</font></tt><font size=2 face="sans-serif">
to be created/computed by the driver from the underlaying replication mechanism.</font>
<br><font size=2 face="sans-serif">I assume DRBD know with whom he is current
enabled for replication - I don't think this should be kept in the Cinder
DB (in the extra specs of the volume-type).</font>
<br>
<br><font size=2 face="sans-serif">In the extra specs we may find "replica_volume_backend_name",
but I expect it to be a short list.</font>
<br>
<br><font size=2>As for the case of multiple "appropriate" replication
targets, the current plan is to choose the 1st eligible , but we can change
it to be a random entry from the list, if you think that is appropriate.</font>
<br>
<br><font size=2>Regarding actual </font><tt><font size=2>"replication_rpo_range"</font></tt><font size=2>
and network bandwidth, I think the current suggestion is a reasonable 1st
step.</font>
<br><font size=2>Multiple considerations will of course impact the actual
RPO, but I think this is outside the scope of this 1st revision - I would
like to see this mechanism enhanced in the next revision.</font>
<br>
<br><font size=2 face="sans-serif">Ronen,</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:      
 </font><font size=1 face="sans-serif">Philipp Marek <philipp.marek@linbit.com></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:      
 </font><font size=1 face="sans-serif">openstack-dev@lists.openstack.org,
</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:      
 </font><font size=1 face="sans-serif">Ronen Kat/Haifa/IBM@IBMIL</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:      
 </font><font size=1 face="sans-serif">11/07/2014 04:10 PM</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:    
   </font><font size=1 face="sans-serif">[openstack-dev][cinder][replication-api]
extra_specs too constant</font>
<br>
<hr noshade>
<br>
<br>
<br><tt><font size=2>I think that "extra_specs" in the database
is too static, too hard to <br>
change.<br>
<br>
<br>
In the case of eg. DRBD, where many nodes may provide some storage space,
the <br>
list "replication_partners" is likely to change often, even if
only newly <br>
added nodes have to be done[1]<br>
<br>
This means that<br>
  a) the admin has to add each node "manually"<br>
  b) volume_type_extra_specs:value is a VARCHAR(255), which can only
provide <br>
                
 a few host names. (With FQDN even more so.)<br>
<br>
What if the list of hosts would be matched by each one saying "I'm
product XYZ <br>
version compat N-M" (eg. via get_volume_stats), and all nodes that
report <br>
the same product with an overlapping version range are considered eligible
<br>
for replication?<br>
<br>
<br>
Furthermore, "replication_rpo_range" might depend on other circumstances
<br>
too... if the network connection to the second site is heavily loaded,
the <br>
RPO will vary, too - from a few seconds to a few hours.<br>
<br>
So, should we announce a range of (0,7200)?<br>
<br>
<br>
Ad 1: because Openstack sees by itself which nodes are available.<br>
<br>
<br>
-- <br>
: Ing. Philipp Marek<br>
: LINBIT | Your Way to High Availability<br>
: DRBD/HA support and consulting            
    </font></tt><a href=http://www.linbit.com/><tt><font size=2>http://www.linbit.com</font></tt></a><tt><font size=2>
:<br>
<br>
DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.<br>
<br>
</font></tt>
<br>