| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-20 | |||
| 13:16:24 | mriedem | bauzas: yeah, but that's kind of ... dumb, right? | |
| 13:16:30 | bauzas | mriedem: https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L692 | |
| 13:16:36 | mriedem | we could just not persist the damn field and then we wouldn't have to explicitly reset for every move operation | |
| 13:16:38 | bauzas | mriedem: yeah, this | |
| 13:17:09 | bauzas | mriedem: when alaski provided the persistence for the spec, his and me forgot to discuss about this :( | |
| 13:17:15 | bauzas | him* | |
| 13:17:22 | bauzas | so we created this method | |
| 13:18:21 | mriedem | ok but going forward, to avoid new ways of shooting off our toes, we could just stop persisting force_hosts/nodes and only rely on that method as a workaround for existing request specs | |
| 13:19:39 | mriedem | these are the fields i count that we've changed to not be persisted on the requestspec: ignore_hosts, requested_destination, retry, network_metadata, requested_resources | |
| 13:20:08 | mriedem | the latter 2 are newer and were not persisted since they were introduced, but the first 3 were all retroactive | |
| 13:20:39 | mriedem | oh and the instance_group members/hosts https://github.com/openstack/nova/blob/master/nova/objects/request_spec.py#L614 | |
| 13:21:20 | mriedem | which reminds me, if any stable core cares about pike and ocata https://review.opendev.org/#/q/topic:bug/1830747+status:open | |
| 13:21:37 | bauzas | mriedem: cool with this | |
| 13:22:10 | bauzas | mriedem: I was also thinking about some way to say which specific fields shouldn't be persisted | |
| 13:22:31 | bauzas | mriedem: and sure, will look at the stable changes | |
| 13:23:40 | mriedem | gibi: as for existing functional resize reschedule tests using az::node, i'd have to see the impacts to assess really | |
| 13:23:59 | bauzas | mriedem: efried_pto: btw. https://review.opendev.org/#/c/683327/ | |
| 13:24:02 | mriedem | but if we ignore the forced host/node to boot the server during resize scheduling, it seems we should allow rescheduling to alternates | |
| 13:26:12 | gibi | mriedem: sure. we will see when I managed to write the reproduction and reorder the populate_retry call | |
| 13:27:04 | mriedem | stephenfin: are you working on an admin guide docs patch for pcpu? | |
| 13:27:12 | stephenfin | mriedem: yup | |
| 13:27:16 | stephenfin | atm, in fact | |
| 13:27:39 | stephenfin | should have something ready to go before EOD | |
| 13:35:59 | mriedem | bauzas: notes on the prelude patch | |
| 13:36:06 | bauzas | cool | |
| 13:40:26 | mriedem | weee https://zuul.opendev.org/t/openstack/build/e3f767dbd32247ffa5aa7daa79e0e5af/log/job-output.txt#32748 | |
| 13:40:31 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Func test for migrate reschedule with pinned compute rpc https://review.opendev.org/683385 | |
| 13:41:21 | gibi | mriedem: reproduction for 1843090 ^^ | |
| 13:41:52 | gibi | mriedem: now I'm going to do the rebase of your fix on it | |
| 13:42:15 | mriedem | gibi: when you rebase you might as well strike whatever word efried_pto didn't like from my comment | |
| 13:42:23 | gibi | mriedem: sure thing | |
| 13:52:39 | mriedem | gibi: comments in your functional recreate patch | |
| 13:54:59 | gibi | mriedem: thanks. regarding the request_spec uglyness. I can cook up something that is test only. But sooner or later we (I) need to go back and fix this uglyness as it is now needed in two places (as noted) | |
| 13:55:50 | gibi | mriedem: the rest of your comments is valid and clear. | |
| 13:55:59 | mriedem | yeah i have no idea why that object is a problem b/c we pass request spec over rpc (select_destinations and such) all the time | |
| 13:56:09 | mriedem | in tests i mean | |
| 13:56:11 | gibi | mriedem: in the meantime I can tell you that your fix works according to the functional test | |
| 13:56:19 | mriedem | \o/ | |
| 13:56:45 | gibi | ... what a nice Friday it is | |
| 14:02:08 | mriedem | my kid is also staying home from school today claiming to be sick and i can't tell if she's playing opposum | |
| 14:02:17 | mriedem | i need to put her to work | |
| 14:05:20 | artom | How good is she with Python? Weren't we looking for interns for all the osc gaps? | |
| 14:05:28 | gibi | mriedem: Is there a change that we consider this https://review.opendev.org/#/c/672577/ as a bug and backport it to stable/pike? (yeah I have a bug day today) | |
| 14:05:58 | gibi | artom, mriedem: hm osc gaps, and osc bugfix backport ^^ | |
| 14:07:48 | mriedem | aspiers: you might want to talk to some suse developers downstream about their upstream "fix only on the branch i care about" practices https://review.opendev.org/#/c/676882/ | |
| 14:08:31 | mriedem | gibi: s/change/chance/ ? | |
| 14:08:37 | gibi | mriedem: yes, sorry | |
| 14:08:43 | mriedem | going to pike is probably going to be tough... | |
| 14:09:02 | mriedem | but, that fix should be compatible... | |
| 14:09:12 | gibi | mriedem: OK. I will look into that as well | |
| 14:09:14 | mriedem | it's clearly a bug if you're using >= 2.53 | |
| 14:09:25 | gibi | mriedem: or find somebody who has time | |
| 14:09:40 | mriedem | pike is in extended maintenance upstream so i'm not sure how much dtroyer is going to care about backporting it that far | |
| 14:09:46 | gibi | mriedem: yes, we have pike deployemnts out there using 2.53 and seeing openstack client fail | |
| 14:10:22 | mriedem | gibi: are they pinning the version to 2.latest or something? | |
| 14:10:50 | mriedem | or they are just pinning to 2.53 since that's the max in pike? | |
| 14:10:53 | gibi | mriedem: using 2.53 by default, but sure we can go back to olderin for this command as a workaround | |
| 14:11:06 | gibi | mriedem: 2.53 is used as that is max pike | |
| 14:11:42 | gibi | it seems I was able to hook in elod to do this client backports... | |
| 14:11:52 | mriedem | i started stein for you https://review.opendev.org/#/c/683394/1 | |
| 14:12:10 | gibi | mriedem: thanks, elod ^^ | |
| 14:12:27 | mriedem | gibi: btw, where do you get your packages? some upstream distro or do you build your own? | |
| 14:12:35 | mriedem | b/c for pike you might have to patch your osc package | |
| 14:13:00 | gibi | mriedem: packages come from Mirantis | |
| 14:13:43 | gibi | mriedem: so if I fail to do a clean thing upstream I will dump the "downstream" work there | |
| 14:15:52 | dtroyer | gibi, mriedem: that is enough of a bug it would be back-portable. OSC follows the same rules of working backwards through releases on backports. Of course, standard disclaimer of just using a modern OSC goes here, I understand that packagers don't do that, I wish they would/could… | |
| 14:16:12 | gibi | dtroyer: thanks | |
| 14:17:48 | mriedem | the biggest barrier to backporting osc fixes is if they rely on something in novaclient that's not in whatever stable branch you're targeting | |
| 14:17:55 | mriedem | it looks like in this case you might get lucky | |
| 14:36:57 | hemna | hey guys, any idea why I might be getting theses failures against stable/pike: http://paste.openstack.org/show/778056/ | |
| 14:37:26 | hemna | tox -epy27 against stable/pike gives about 6300 of those errors | |
| 14:42:59 | mriedem | oh hemna | |
| 14:43:11 | mriedem | hemna: KeithMnemonic1 must have some dirt on you | |
| 14:43:40 | KeithMnemonic1 | lol | |
| 14:45:03 | mriedem | hemna: so you're trying to figure out why these are failing https://storage.bhs1.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_6e4/683008/2/check/openstack-tox-py27/6e40a0c/testr_results.html.gz right? i'm not sure why you'd be hitting that weird db issue locally - should be using sqlite | |
| 14:45:33 | mriedem | hemna: i'd try cleaning pycs and rebuilding the venv: | |
| 14:45:42 | mriedem | find . -name *.pyc delete | |
| 14:45:45 | mriedem | tox -r -e py27 | |
| 14:46:35 | bauzas | mriedem: just to make it clear, you want me providing the links to https://releases.openstack.org/train/highlights.html#nova-compute-service in https://review.opendev.org/#/c/683327/1/releasenotes/notes/train-prelude-3db0f5f6a75cc57a.yaml ? | |
| 14:47:09 | mriedem | bauzas: in the commit message? | |
| 14:47:10 | mriedem | i would | |
| 14:47:27 | mriedem | wait no not the latter | |
| 14:47:30 | bauzas | mriedem: looks like you also want to have links in the release note | |
| 14:47:32 | mriedem | the etherpad and the published highlights doc | |
| 14:47:35 | mriedem | bauzas: no | |
| 14:47:49 | mriedem | i'm telling you, pull your content from the highlights, | |
| 14:48:02 | bauzas | oh, k | |
| 14:48:03 | mriedem | plus additional stuff not in the highlights that's in the etherpad, like nova-cells/consoleauth removal and xenapi driver deprecatoin | |
| 14:48:08 | bauzas | ok, understood | |
| 14:48:10 | mriedem | we intentionally didn't include ^ in highlights | |
| 14:48:14 | mriedem | b/c they aren't highlights | |
| 14:48:16 | bauzas | cool | |
| 14:48:21 | bauzas | will do it later | |
| 14:48:24 | mriedem | xenapi driver deprecatoin is a brown light | |
| 14:50:03 | hemna | ok I'll try that | |
| 14:50:21 | hemna | I'm not sure I'll be successfull with this conflict resolution on that patch | |
| 14:50:28 | hemna | since so much changed between pike and queens | |
| 14:51:26 | mriedem | i didn't do the tests for a reason | |
| 14:52:00 | mriedem | i could, but i'd need some incentive$$$ | |
| 14:52:56 | openstackgerrit | Walter A. Boring IV (hemna) proposed openstack/nova stable/pike: WIP: Avoid redundant initialize_connection on source post live migration https://review.opendev.org/683008 | |