<div dir="ltr">Hi, <div><br></div><div>Thanks for the reply, one possible usecase is that user wants to live-migrate to az2 so he specified host2. As we didn't update the <a href="http://instance.az">instance.az</a>, if the user live-migrate again without specifiying destination host, the instance will migrate to az1 again, this might be different as the user expect. Any thought about this?</div><div><br></div><div>BR,</div><div><br></div><div>Zheng</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 23, 2015 at 4:30 PM, Sylvain Bauza <span dir="ltr"><<a href="mailto:sbauza@redhat.com" target="_blank">sbauza@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<br>
<br>
<div>Le 23/09/2015 05:24, Zhenyu Zheng a
écrit :<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi, all
<div><br>
</div>
<div>I have a question about availability zones when performing
live-migration.</div>
<div><br>
</div>
<div>Currently, when performing live-migration the AZ of the
instance didn't update. In usecase like this:</div>
<div>Instance_1 is in host1 which is in az1, we live-migrate it
to host2 (provide host2 in API request) which is in az2. The
operation will secusess but the availability zone data stored
in instance1 is still az1, this may cause inconsistency with
the az data stored in instance db and the actual az. I think
update the az information in instance using the host az can
solve this.</div>
<div><br>
</div>
</div>
</blockquote>
<br></span>
Well, no. Instance.AZ is only the reflect of what the user asked,
not what the current AZ is from the host the instance belongs to. In
other words, <a href="http://instance.az" target="_blank">instance.az</a> is set once forever by taking the --az hint
from the API request and persisting it in DB.<br>
<br>
That means that if you want to create a new VM without explicitly
specifying one AZ in the CLI, it will take the default value of
CONF.default_schedule_az which is None (unless you modify that
flag).<br>
<br>
Consequently, when it will go to the scheduler, the AZFilter will
not check the related AZs from any host because you didn't asked for
an AZ. That means that the instance is considered "AZ-free".<br>
<br>
Now, when live-migrating, *if you specify a destination*, you
totally bypass the scheduler and thus the AZFilter. By doing that,
you can put your instance to another host without really checking
the AZ.<br>
<br>
That said, if you *don't specify a destination*, then the scheduler
will be called and will enforce the <a href="http://instance.az" target="_blank">instance.az</a> field with regards
to the host AZ. That should still work (again, depending on whether
you explicitly set an AZ at the boot time)<br>
<br>
To be clear, there is no reason of updating that instance AZ field.
We can tho consider it's a new "request"' field and could be
potentially moved to the RequestSpec object, but for the moment,
this is a bit too early since we don't really use that new
RequestSpec object yet.<span class=""><br>
<br>
<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Also, I have heard from my collegue that in the future we
are planning to use host az information for instances. I
couldn't find informations about this, could anyone provide me
some information about it if thats true?</div>
<div><br>
</div>
</div>
</blockquote>
<br></span>
See my point above, I'd rather prefer to fix how live-migrations
check the scheduler (and not bypass it when specifying a
destination) and possibly move the instance AZ field to the
RequestSpec object once that object is persisted, but I don't think
we should check the host instead of the instance in the AZFilter.<br>
<br>
<br>
I assume all of that can be very confusing and mostly tribal
knowledge, that's why we need to document that properly and one
first shot is <a href="https://review.openstack.org/#/c/223802/" target="_blank">https://review.openstack.org/#/c/223802/</a><br>
<br>
-Sylvain<br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Thanks,</div>
<div><br>
</div>
<div>Best Regards,</div>
<div><br>
</div>
<div>Zheng</div>
</div><span class="">
<br>
<fieldset></fieldset>
<br>
<pre>__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</span></blockquote>
<br>
</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>