| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-03-13 | |||
| 19:30:22 | EmilienM | tonyb: thanks! | |
| 19:31:09 | tonyb | EmilienM: I don't think I'll *fix* it but I can poke at least to see if it's a gap in our testing | |
| 19:35:11 | tonyb | mriedem: I thinkI'm okay backporting that. | |
| 19:35:18 | tonyb | mriedem: I'll reply on list | |
| 19:36:01 | mriedem | tonyb: ok thanks - bauzas is as well so wfm | |
| 19:36:33 | tonyb | mriedem: I need to check if any other data to those calls would cause a 400 status code | |
| 19:37:05 | tonyb | and I guess it will surprise operators that until now didn't nee to empty an aggregate to rename it | |
| 19:39:02 | mriedem | you can rename an aggregate, | |
| 19:39:04 | mriedem | just no the az | |
| 19:39:06 | mriedem | *not | |
| 19:39:52 | openstackgerrit | Kevin Rasmussen proposed openstack/nova master: created AggregateSubnetAvailabilityFilter https://review.openstack.org/633178 | |
| 19:39:55 | mriedem | if they are not surprised, they were probably dealing with fallout maybe without even knowing it, i.e. rename az, resize a server and now it's back in the old az - or novalidhost | |
| 19:40:49 | mriedem | dansmith: confirmed that revert resize az bug | |
| 19:40:56 | mriedem | got a test, will post with a bug shortly | |
| 19:40:57 | tonyb | Yeah okay. | |
| 19:41:06 | dansmith | mriedem: sweet | |
| 19:41:08 | dansmith | "sweet" | |
| 19:45:54 | mriedem | https://bugs.launchpad.net/nova/+bug/1819963 | |
| 19:45:54 | openstack | Launchpad bug 1819963 in OpenStack Compute (nova) "Reverting a resize does not update the instance.availability_zone value to the source az" [Low,Triaged] - Assigned to Matt Riedemann (mriedem) | |
| 19:46:20 | mriedem | my test shows that the api hides the incorrect instance.availability_zone value | |
| 19:46:25 | mriedem | because of https://github.com/openstack/nova/blob/482f4fed654f384e8fb277c504a14a6407ba2e7b/nova/availability_zones.py#L179-L194 | |
| 19:46:40 | mriedem | makes me wonder wtf we even have instance.availability_zone | |
| 19:47:38 | dansmith | do we have an az filter for listing instances? | |
| 19:47:45 | dansmith | we use it for metadata at least | |
| 19:48:59 | mriedem | yeah we have an az filter when listing instances | |
| 19:49:23 | dansmith | presumably we use that there? | |
| 19:49:50 | dansmith | obviously much of our model for everything has evolved since that was a thing though | |
| 19:51:23 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Use Ceph Jewel release for live migration testing https://review.openstack.org/643150 | |
| 19:52:42 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Use Ceph Jewel release for live migration testing https://review.openstack.org/643150 | |
| 19:55:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1819963 https://review.openstack.org/643151 | |
| 19:55:03 | openstack | bug 1819963 in OpenStack Compute (nova) "Reverting a resize does not update the instance.availability_zone value to the source az" [Low,Triaged] https://launchpad.net/bugs/1819963 - Assigned to Matt Riedemann (mriedem) | |
| 19:55:30 | mriedem | dansmith: so i built ^ on top of my live migration functional test with azs, which may or may not be a problem | |
| 19:55:36 | openstackgerrit | melanie witt proposed openstack/nova master: WIP Use Ceph Jewel release for live migration testing https://review.openstack.org/643150 | |
| 19:56:00 | mriedem | and yeah i assume the GET /servers?availability_zone=foo filtering uses the instance.availability_zone value in the DB | |
| 19:56:10 | mriedem | otherwise it would be crazy expensive to do that filtering in the API | |
| 19:56:55 | dansmith | yeah | |
| 19:59:40 | dansmith | mriedem: you should have been a lawyer | |
| 20:00:54 | dansmith | "Well, your honor, as you can see I have reproduced the crime in a functional test, exhibit A, which shows that the defendant obviously committed said crime. Once sentenced, we can remove this assertion, exhibit B" | |
| 20:01:42 | mriedem | i'd have to wear adult mens clothing then | |
| 20:01:45 | mriedem | no thanks | |
| 20:02:05 | dansmith | maybe not if you were a lawyer in california, although that would have other downsides | |
| 20:02:14 | dansmith | I hear they have silly magazine limits down there | |
| 20:05:15 | dansmith | heh | |
| 20:11:47 | mriedem | in all seriousness, being a lawyer in MN would allow me to accept gifts of bars and hotdish from my defendents | |
| 20:11:54 | mriedem | so it might be worth it | |
| 20:18:44 | melwitt | mriedem: what did you mean by ubuntu queens/bionic is using luminous? the version in the uca? | |
| 20:19:30 | mriedem | yeah i think that's what coreycb meant | |
| 20:19:39 | mriedem | when i asked him earlier today | |
| 20:19:39 | melwitt | bc I see luminous for queens xenial in the uca http://ubuntu-cloud.archive.canonical.com/ubuntu/dists/xenial-proposed/queens/main/binary-amd64/Packages | |
| 20:19:46 | melwitt | ok, cool | |
| 20:22:28 | coreycb | melwitt: yes and that's the same version that comes in bionic by default | |
| 20:22:37 | melwitt | coreycb: ah, thank you | |
| 20:23:02 | coreycb | np | |
| 20:23:08 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Update instance.availability_zone on revertResize https://review.openstack.org/643155 | |
| 20:23:20 | mriedem | dansmith: exhibit B ^ | |
| 20:23:43 | dansmith | that's an upcall no? | |
| 20:24:04 | dansmith | oh sorry | |
| 20:24:10 | dansmith | god I'm stupid, sorry | |
| 20:25:30 | mriedem | i can optimize this | |
| 20:25:36 | mriedem | left a comment | |
| 20:25:47 | dansmith | was about to call your typo | |
| 20:25:56 | mriedem | i know :) | |
| 20:26:01 | mriedem | i could feel it | |
| 20:26:37 | dansmith | so | |
| 20:26:47 | dansmith | talk me through this on your reqspec optimization | |
| 20:26:53 | dansmith | let's say... | |
| 20:27:00 | dansmith | I have an instance with no specific az, | |
| 20:27:09 | dansmith | I move it to another host, and it's mid-resize | |
| 20:27:18 | dansmith | or, waiting for confirm/revert I mean | |
| 20:27:33 | dansmith | the operator could change the az affiliation of that host in the middle right? | |
| 20:27:46 | mriedem | of the source? | |
| 20:27:50 | dansmith | of either | |
| 20:28:01 | mriedem | not the target, | |
| 20:28:02 | dansmith | it wouldn't be smart, but.. | |
| 20:28:08 | mriedem | because of avolkov's recent fix | |
| 20:28:15 | mriedem | but they could rename the az of the source yeah | |
| 20:28:45 | dansmith | barring the source change would be hard, looking up instances that still have residue on hosts | |
| 20:28:48 | dansmith | anyway, | |
| 20:28:54 | dansmith | seems like maybe not worth the optimization, | |
| 20:29:09 | dansmith | if it's still possible to be wrong but creates a much more obscure path to get there | |
| 20:30:07 | mriedem | right his change only deals with the az that contains the instance based on instance.host https://review.openstack.org/#/c/641351/1/nova/objects/instance.py | |
| 20:30:13 | mriedem | which would be the target at the time of the VERIFY_RESIZE status | |
| 20:30:23 | mriedem | i'm fine with not trying to optimize it | |
| 20:30:47 | mriedem | i could leave a comment to that effect as well if it's something we think we'll forget and care about in a year :) | |
| 20:31:31 | dansmith | I say just don't optimize it now, regardless of how you spin the comments | |
| 20:31:35 | mriedem | melwitt: you were +2 on this before https://review.openstack.org/#/c/567701/ if you can check it again, i think it was just rebased | |
| 20:32:00 | melwitt | mriedem: sure | |
| 20:32:16 | mriedem | dansmith: ok if you're ok with it as is i can just leave it alone, or fix the typo in the commit message | |
| 20:32:27 | dansmith | oh I'm not fine with the typo | |
| 20:32:29 | dansmith | you must fix that | |
| 20:32:33 | mriedem | ok then | |
| 20:32:49 | dansmith | there, made explicit | |
| 20:33:10 | dansmith | I'll also explain why no opt I gess | |
| 20:34:18 | mriedem | actually, | |
| 20:34:26 | mriedem | no, | |
| 20:34:33 | dansmith | mriedem: if I'm using default_availability_zone, I can change the target's affiliation with a restart right? | |
| 20:34:36 | mriedem | if RequestSpec.availability_zone is not None, the server *has* to migrate within the AZ, | |
| 20:34:56 | mriedem | meaning while the server is in VERIFY_RESIZE, it's in the same az on the dest host as the source host, so the admin can't rename the az | |
| 20:35:52 | mriedem | and if RequestSpec.availability_zone is None, then we'd end up updating the instance.availability_zone anyway | |
| 20:35:59 | mriedem | i mean with my optimization | |