Re: [openstack-dev] [nova] About availability zones

[Lingxian Kong]

Hi, Sylvain 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  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  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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
---
Lingxian Kong

__

Re: [openstack-dev] [nova] About availability zones

[Feodor Tersin]

Hi.

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.
Since a host can be included into different AZs, you probably need to allow a 
caller optionally to specify a target AZ. And as i understand the same problem 
occurs for resize, evacuate and other similar operations, doesn't it?

  __
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] About availability zones

[Zhenyu Zheng]

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  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-requ...@lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] About availability zones

[Sylvain Bauza]

Le 23/09/2015 08:56, Feodor Tersin a écrit :

Hi.

/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./


Since a host can be included into different AZs, you probably need to 
allow a caller optionally to specify a target AZ. And as i understand 
the same problem occurs for resize, evacuate and other similar 
operations, doesn't it?


No, an host can't be in two different AZs. It can be in two or more 
aggregates, but then only one of those aggregates can be having an AZ 
metadata key.

https://github.com/openstack/nova/blob/1df8248b6ad7982174c417abf80070107eac8909/nova/compute/api.py#L3645-L3670

FWIW, I provided a devref change for explaining that : 
https://review.openstack.org/#/c/223802/


-Sylvain





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [nova] About availability zones

[Sylvain Bauza]

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [nova] About availability zones

[Zhenyu Zheng]

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.

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?

Thanks,

Best Regards,

Zheng
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev