Open Stack

Hi, Sylvain&other Nova guys,

Our team has also argued about this deeply, and no consensus was reached.

if instance.az is designed just for a reflect of the instance at boot
time, then it doesn't make any sense after the vm is live-migrated
with specified destination for several times, right?
Then, how could user get the exact az information for that vm? The
workaround I can think of is, user can query the host that vm is
running on, then query az that the host belongs to, is this the
recommended way?

On Wed, Sep 23, 2015 at 4:49 PM, Zhenyu Zheng <zhengzhenyulixi at gmail.com> wrote:
> Hi,
>
> 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
> instance.az, 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?
>
> BR,
>
> Zheng
>
> On Wed, Sep 23, 2015 at 4:30 PM, Sylvain Bauza <sbauza at redhat.com> wrote:
>>
>>
>>
>> Le 23/09/2015 05:24, Zhenyu Zheng a écrit :
>>
>> Hi, all
>>
>> I have a question about availability zones when performing live-migration.
>>
>> Currently, when performing live-migration the AZ of the instance didn't
>> update. In usecase like this:
>> 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.
>>
>>
>> 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,
>> instance.az is set once forever by taking the --az hint from the API request
>> and persisting it in DB.
>>
>> 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).
>>
>> 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".
>>
>> 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.
>>
>> That said, if you *don't specify a destination*, then the scheduler will
>> be called and will enforce the instance.az field with regards to the host
>> AZ. That should still work (again, depending on whether you explicitly set
>> an AZ at the boot time)
>>
>> 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.
>>
>>
>>
>> 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?
>>
>>
>> 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.
>>
>>
>> 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
>> https://review.openstack.org/#/c/223802/
>>
>> -Sylvain
>>
>> Thanks,
>>
>> Best Regards,
>>
>> Zheng
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
-----------------------------------
Lingxian Kong