| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-01 | |||
| 13:42:14 | dansmith | jaypipes: we got the host once at the beginning though | |
| 13:43:35 | jaypipes | dansmith: no... it was grabbed again on previous line 1215 in gibi's new _resize_and_check_allocations() | |
| 13:45:18 | jaypipes | dansmith: well, it wasn't "grabbed again"... just read again from the server dict. but the server dict is passed to the _wait_for_status() thing. perhaps that dict is modified? | |
| 13:45:30 | dansmith | jaypipes: that function wasn't there when Ilast pushed | |
| 13:45:44 | jaypipes | dansmith: I know, it was gibi's overnight refactor. | |
| 13:45:53 | jaypipes | but the basic premise remains. | |
| 13:46:18 | dansmith | jaypipes: I don't think it does, | |
| 13:46:36 | dansmith | because we pulled host, even saved it in original_host, | |
| 13:46:41 | dansmith | and used the provider uuids once | |
| 13:46:46 | dansmith | that was mriedem's early comment | |
| 13:46:55 | jaypipes | dansmith: no, I'm right. bingo. The server parameter to _wait_for_state_change() is modified **in-place** and replaced with the returned value from the GET call. | |
| 13:47:03 | jaypipes | dansmith: and that is why server['OS-EXT-SRV-ATTR:host'] changes value. | |
| 13:47:19 | jaypipes | while True: | |
| 13:47:19 | jaypipes | 225 server = admin_api.get_server(server['id']) | |
| 13:47:26 | dansmith | oh you're right, so I should just stop looking then eh? | |
| 13:47:43 | gibi | jaypipes: can it be that your refactring changed what host order we skip and what host order we test now? | |
| 13:47:47 | jaypipes | well, I need food and more caffeine. will tackle this further when returning. | |
| 13:48:23 | mriedem | dan's point was with the way the test was written about 16 hours ago, | |
| 13:48:29 | mriedem | everything was monolithic, | |
| 13:48:34 | mriedem | and we stored the source host right up front | |
| 13:48:43 | jaypipes | gibi: no, my refactoring removed the use of server['OS-EXT-SRV-ATTR:host'] to get the resource provider UUIDs. that server['OS-EXT-SRV-ATTR:host'] changes over the course of the migration resulting in the wrong compute host being returned | |
| 13:49:04 | dansmith | jaypipes: right and that change is wrong | |
| 13:49:20 | dansmith | assuming that the rp uuid of the host we asked for is where it actually is is assuming too much, IMHO | |
| 13:49:33 | mriedem | https://review.openstack.org/#/c/487958/14/nova/tests/functional/test_servers.py | |
| 13:49:34 | jaypipes | dansmith: huh? | |
| 13:49:39 | gibi | interestingly if I set dest_hostname to host1 in the confirm test it passes | |
| 13:49:53 | jaypipes | gibi: and that is incorrect. | |
| 13:49:58 | mriedem | https://review.openstack.org/#/c/487958/14/nova/tests/functional/test_servers.py@1168 | |
| 13:50:18 | openstackgerrit | Jacek Tomasiak proposed openstack/nova master: ironic: Use internal API endpoint https://review.openstack.org/489537 | |
| 13:50:19 | mriedem | as of last night (me and dan time), we got the source host once at the beginning | |
| 13:50:25 | dansmith | jaypipes: I left a comment. However, I'm wrong and you're right, so I'm getting coffee and a bagel | |
| 13:50:38 | jaypipes | dansmith: ditto. | |
| 13:51:10 | mriedem | don't make me quote rodney king | |
| 13:52:01 | sdague | mriedem: apparently not, I didn't see any -1s on it. | |
| 13:52:02 | cdent | I often, in cases like this, wish we had to write new commits each time we pushed to gerrit | |
| 13:54:59 | mriedem | bauzas: i'm not sure why this is pike-rc-potential https://bugs.launchpad.net/nova/+bug/1702454 | |
| 13:54:59 | openstack | Launchpad bug 1702454 in OpenStack Compute (nova) "Transforming the RequestSpec object into legacy dicts doesn't support the requested_destination field" [High,In progress] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 13:55:05 | mriedem | it's not a regression in master, it's a latent issue in stable right? | |
| 13:55:36 | bauzas | mriedem: yup, like I said "As a consequence, the feature to pass a destination for evacuation is not working in Newton and Ocata. " | |
| 13:55:56 | bauzas | mriedem: I'd love to see it merged for Pike so we could backport it 'til Newton | |
| 13:56:12 | bauzas | if not, it would be a bit difficult to backport it | |
| 13:56:20 | mriedem | why? | |
| 13:56:28 | mriedem | pike GA != newton phase 3 | |
| 13:56:51 | mriedem | bauzas: so how about writing a functional regression test for https://review.openstack.org/#/c/481116/ then ? | |
| 13:57:09 | mriedem | because anything involving the request spec getting passed around 3 different services should have a functional test | |
| 13:57:33 | bauzas | mriedem: for evacuating ? | |
| 13:57:43 | bauzas | mriedem: not sure it would work for a functional test | |
| 13:58:18 | mriedem | i've been wanting to write a functional test for evacuate for a long time, | |
| 13:58:22 | mriedem | i don't think it would be that hard | |
| 13:58:35 | bauzas | mriedem: about why Pike, because https://docs.openstack.org/project-team-guide/stable-branches.html#support-phases | |
| 13:58:38 | mriedem | you start 2 services, create server on one, force it down and evacuate | |
| 13:58:45 | bauzas | mriedem: I can try | |
| 13:59:04 | mriedem | https://releases.openstack.org/ | |
| 13:59:12 | mriedem | Phase III – Legacy release on 2017-10-09 | |
| 13:59:27 | mriedem | you have 5 weeks to make it happen :) | |
| 13:59:45 | bauzas | okay okay :) | |
| 14:00:08 | bauzas | mriedem: just remove the pike-potential tag and I'll try to provide a functional test | |
| 14:00:24 | bauzas | mriedem: but then, I'll harass you :p | |
| 14:00:38 | mriedem | except !jk | |
| 14:00:43 | gibi | bauzas: there is example evacuate test in the server_group functional test I think | |
| 14:01:10 | bauzas | gibi: maybe, I'll look :) | |
| 14:01:18 | mriedem | bauzas: keep in mind, the way we do the functional regression tests is a 2 patch process, | |
| 14:01:22 | gibi | bauzas: https://github.com/openstack/nova/blob/master/nova/tests/functional/test_server_group.py#L412 | |
| 14:01:22 | mriedem | the first writes the test recreating the bug, | |
| 14:01:26 | mriedem | asserting the failure, | |
| 14:01:29 | mriedem | the 2nd patch fixes the bug | |
| 14:01:34 | mriedem | and adjusts the test | |
| 14:01:34 | bauzas | the functional server groups tests just do a lot so I'm not remembering if it's also calling evacuate :p | |
| 14:01:45 | bauzas | mriedem: yup, I know, no worries | |
| 14:01:58 | bauzas | I did reviewed a few of you :p | |
| 14:02:18 | gibi | bauzas: also a notification sample test with evacuate is up on review https://review.openstack.org/#/c/482148/3/nova/tests/functional/notification_sample_tests/test_instance.py | |
| 14:02:18 | mriedem | i know, quotas things | |
| 14:02:38 | gibi | bauzas: this one is better as it uses force_down | |
| 14:03:11 | bauzas | thanks gibi :) | |
| 14:03:12 | mriedem | bauzas: i also don't think https://bugs.launchpad.net/nova/+bug/1678056 is pike-rc-potential | |
| 14:03:12 | openstack | Launchpad bug 1678056 in OpenStack Compute (nova) "RequestSpec records are never deleted when destroying an instance" [High,In progress] - Assigned to Sylvain Bauza (sylvain-bauza) | |
| 14:03:17 | mriedem | request specs not getting deleted is a latent issue | |
| 14:03:27 | bauzas | same problem | |
| 14:03:31 | bauzas | same situation | |
| 14:03:56 | bauzas | we have that since we persisted the Requestspec records | |
| 14:04:04 | mriedem | sure, but it's not a pike blocker | |
| 14:04:05 | bauzas | so that's not really a regression | |
| 14:04:06 | mriedem | it's latent | |
| 14:04:23 | bauzas | but AFAIK I thought RC1 was not only for regressions :) | |
| 14:04:29 | bauzas | RC2 and others yup so | |
| 14:04:37 | mriedem | pike-rc-potential is not your personal wishlist of bugs for review :) | |
| 14:05:12 | bauzas | anyway, seems I agreed to remove pike-rc-potential for the former, I'm okay to remove that tag for the latter :) | |
| 14:05:18 | mriedem | yup, done | |
| 14:05:28 | mriedem | i'm just working on my etherpad of stuff to do for rc1 | |
| 14:05:33 | mriedem | so that's why i'm being harsh on these tagged bugs | |
| 14:05:39 | bauzas | no worries | |
| 14:05:41 | mriedem | and as a result i'm taking it out on you | |
| 14:05:54 | bauzas | yup, I understand | |
| 14:05:57 | bauzas | no worries again | |
| 14:06:05 | bauzas | I just want to make sure we don't forget them | |
| 14:06:19 | mriedem | i could never forget the wasteland that is request spec bugs :) | |
| 14:06:22 | bauzas | and since we were working on features during last milestones, I'll ping a few of us during those weeks | |
| 14:06:46 | mriedem | ^ not sure what you mean there | |
| 14:07:06 | mriedem | you mean you held off on pinging people for bug reviews b/c of working on closing out features? | |
| 14:07:12 | bauzas | exacrlt | |