<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<br>
<div class="moz-cite-prefix">Le 24/09/2015 09:04, Duncan Thomas a
écrit :<br>
</div>
<blockquote
cite="mid:CAOyZ2aEu3238K-ETutR0Acrsf+_C0XXTYTDFY9kiKD6kqPUo6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">Hi</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">I thought I was late on this thread,
but looking at the time stamps, it is just something that
escalated very quickly. I am honestly surprised an
cross-project interaction option went from 'we don't seem to
understand this' to 'deprecation merged' in 4 hours, with only
a 12 hour discussion on the mailing list, right at the end of
a cycle when we're supposed to be stabilising features. </div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
<br>
So, I agree it was maybe a bit too quick hence the revert. That
said, Nova master is now Mitaka, which means that the deprecation
change was provided for the next cycle, not the one currently
stabilising.<br>
<br>
Anyway, I'm really all up with discussing why Cinder needs to know
the Nova AZs.<br>
<br>
<blockquote
cite="mid:CAOyZ2aEu3238K-ETutR0Acrsf+_C0XXTYTDFY9kiKD6kqPUo6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">I proposed a session at the Tokyo
summit for a discussion of Cinder AZs, since there was clear
confusion about what they are intended for and how they should
be configured. </div>
</div>
</blockquote>
<br>
Cool, count me in from the Nova standpoint.<br>
<br>
<blockquote
cite="mid:CAOyZ2aEu3238K-ETutR0Acrsf+_C0XXTYTDFY9kiKD6kqPUo6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">Since then I've reached out to and
gotten good feedback from, a number of operators. There are
two distinct configurations for AZ behaviour in cinder, and
both sort-of worked until very recently.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">1) No AZs in cinder</div>
<div class="gmail_extra">This is the config where a single
'blob' of storage (most of the operators who responded so far
are using Ceph, though that isn't required). The storage takes
care of availability concerns, and any AZ info from nova
should just be ignored.</div>
<div class="gmail_extra"><br>
</div>
<div class="gmail_extra">2) Cinder AZs map to Nova AZs</div>
<div class="gmail_extra">In this case, some combination of
storage / networking / etc couples storage to nova AZs. It is
may be that an AZ is used as a unit of scaling, or it could be
a real storage failure domain. Eitehr way, there are a number
of operators who have this configuration and want to keep it.
Storage can certainly have a failure domain, and limiting the
scalability problem of storage to a single cmpute AZ can have
definite advantages in failure scenarios. These people do not
want cross-az attach.</div>
<div class="gmail_extra"><br>
</div>
</div>
</blockquote>
<br>
Ahem, Nova AZs are not failure domains - I mean the current
implementation, in the sense of many people understand what is a
failure domain, ie. a physical unit of machines (a bay, a room, a
floor, a datacenter).<br>
All the AZs in Nova share the same controlplane with the same
message queue and database, which means that one failure can be
propagated to the other AZ.<br>
<br>
To be honest, there is one very specific usecase where AZs *are*
failure domains : when cells exact match with AZs (ie. one AZ
grouping all the hosts behind one cell). That's the very specific
usecase that Sam is mentioning in his email, and I certainly
understand we need to keep that.<br>
<br>
What are AZs in Nova is pretty well explained in a quite old
blogpost :
<a class="moz-txt-link-freetext" href="http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/">http://blog.russellbryant.net/2013/05/21/availability-zones-and-host-aggregates-in-openstack-compute-nova/</a><br>
<br>
We also added a few comments in our developer doc here
<a class="moz-txt-link-freetext" href="http://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs">http://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs</a><br>
<br>
tl;dr: AZs are aggregate metadata that makes those aggregates of
compute nodes visible to the users. Nothing more than that, no magic
sauce. That's just a logical abstraction that can be mapping your
physical deployment, but like I said, which would share the same bus
and DB.<br>
Of course, you could still provide networks distinct between AZs but
that just gives you the L2 isolation, not the real failure domain in
a Business Continuity Plan way.<br>
<br>
What puzzles me is how Cinder is managing a datacenter-level of
isolation given there is no cells concept AFAIK. I assume that
cinder-volumes are belonging to a specific datacenter but how is
managed the controlplane of it ? I can certainly understand the need
of affinity placement between physical units, but I'm missing that
piece, and consequently I wonder why Nova need to provide AZs to
Cinder on a general case.<br>
<br>
<br>
<br>
<blockquote
cite="mid:CAOyZ2aEu3238K-ETutR0Acrsf+_C0XXTYTDFY9kiKD6kqPUo6g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">My hope at the summit session was to
agree these two configurations, discuss any scenarios not
covered by these two configuration, and nail down the changes
we need to get these to work properly. There's definitely been
interest and activity in the operator community in making nova
and cinder AZs interact, and every desired interaction I've
gotten details about so far matches one of the above models.</div>
</div>
<br>
</blockquote>
<br>
I'm all with you about providing a way for users to get volume
affinity for Nova. That's a long story I'm trying to consider and we
are constantly trying to improve the nova scheduler interfaces so
that other projects could provide resources to the nova scheduler
for decision making. I just want to consider whether AZs are the
best concept for that or we should do thing by other ways (again,
because AZs are not what people expect).<br>
<br>
Again, count me in for the Cinder session, and just lemme know when
the session is planned so I could attend it.<br>
<br>
-Sylvain<br>
<br>
<br>
<blockquote
cite="mid:CAOyZ2aEu3238K-ETutR0Acrsf+_C0XXTYTDFY9kiKD6kqPUo6g@mail.gmail.com"
type="cite">
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>