| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-19 | |||
| 20:31:17 | efried | jroll: ^ might come down to "are we dead in the water if we simply can't support shelve-offload (and possibly others)?" | |
| 20:31:44 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: Functional tests for NUMA live migration https://review.opendev.org/672595 | |
| 20:31:46 | openstack | bug 1845146 in OpenStack Compute (nova) train "NUMA aware live migration failed when vCPU pin set" [High,Fix committed] https://launchpad.net/bugs/1845146 - Assigned to Dan Smith (danms) | |
| 20:31:46 | openstackgerrit | Artom Lifshitz proposed openstack/nova master: NUMA LM: Add func test for bug 1845146 https://review.opendev.org/687404 | |
| 20:34:45 | dansmith | dustinc: my opinion on what? whether it's fundamentally okay? | |
| 20:36:57 | dustinc | dansmith: Yes, efried suggested an alternative and I wanted help figuring out what makes more sense | |
| 20:39:17 | efried | dansmith: Trying to address what happens when the same node appears more than once in provider configs. Due to e.g. ironic rebalance we can't just fail, because the "conflict" might not appear until we're already running. So we have to set some kind of precedence rules for ``$COMPUTE_NODE`` vs explicit uuid and name | |
| 20:40:21 | dansmith | ohh, I clicked on the wrong link | |
| 20:40:39 | efried | In practice, I think this could only possibly be an issue at runtime in an ironic deployment when a rebalance happens, I think. At which point a new node will "appear" and we have to decide whether it has a provider config. | |
| 20:40:49 | dansmith | I have to run an errand, so I should probably not try to squeeze in a quick read of that before I go. | |
| 20:41:19 | efried | If we commit to this only being an issue in that ^ scenario, then I *think* the fact that ironic node RP name == uuid (doesn't it?) would let us hardcode an unambiguous solution pretty easily. | |
| 20:41:44 | efried | I need to food and then school run, will check back on this later. | |
| 20:41:58 | dansmith | I would punt to mriedem on that as I think he has the most ironic RP stuff in his head | |
| 20:42:03 | dansmith | but yeah, will leave this open for later | |
| 20:45:55 | openstackgerrit | Matt Riedemann proposed openstack/os-traits master: Add COMPUTE_SAME_HOST_COLD_MIGRATE trait https://review.opendev.org/666604 | |
| 20:47:36 | openstackgerrit | Merged openstack/nova master: Fix driver tests on Windows https://review.opendev.org/518525 | |
| 20:50:43 | mriedem | "ironic node RP name == uuid (doesn't it?)" yes | |
| 20:51:03 | mriedem | ironic node RP name/uuid == compute node hypervisor_hostname and uuid == ironic node id | |
| 21:18:51 | dansmith | efried: dustinc I don't understand.. you can just use ironic node uuid and be properly unique and specific no? | |
| 21:25:26 | dustinc | dansmith: well we need to make sure that whoever put it in the file did so correctly...the original spec required that if two different entries referenced the same provider, it would cause nova to fail to init, but since we realized that we cannot be sure if a specific uuid and $COMPUTE_NODE reference the same provider until _after_ init, we need to not fail so had to come up with another plan | |
| 21:32:19 | dansmith | dustinc: I think it's expected that "whoever put" anything in the file did so correctly | |
| 21:32:49 | dansmith | IMHO, the solution is to use the ironic uuid there, regardless of which compute host gets that node in the rebalance, I think that's fine | |
| 22:06:26 | dustinc | dansmith: Well the issue is that we need to decide what to do in the case the node is defined more than once in the configuration files. I proposed that we use the first entry that identifies the node and ignore the rest, but efried proposes that we use the $COMPUTE_NODE as a catch all and the specific uuid/name identification should take precedence if both exit (this makes sense the more I think about it) | |
| 22:06:37 | dustinc | the remaining issue we _might_ run into is what happens if the node is identified by name and uuid? | |
| 22:13:51 | efried | dustinc: let me go check whether the ironic node RP name and uuid are in fact the same in placement... | |
| 22:15:35 | efried | # nodename is the ironic node's UUID. | |
| 22:15:35 | efried | dustinc: o look, a comment right at the top of ironic driver's update_provider_tree: | |
| 22:16:26 | efried | dansmith: lacking a better idea, do you think "create a glance image for the virtual device file" is an acceptable (if unlovely) path forward? | |
| 22:17:09 | dustinc | ok so we can identify name/uuid identification conflicts before init with ironic...but what about nova? how can we be sure a name and uuid don't identify the same node? what should we do in the case that happens? | |
| 22:17:44 | efried | dustinc: that we should be able to determine the *first* time the RT hits this code, i.e. on startup. | |
| 22:18:31 | efried | for non-ironic, that is. Because we're looking at the compute node RP already. | |
| 22:19:41 | efried | To cover ironic, we just put an extra check that cfg1['name'] != cfg2['uuid'] for all (cfg1, cfg2). It's a tad specific, but it would be insanity for node[name] on one node to be the same as node[uuid] on another, so I don't feel awful about doing that. | |
| 22:21:21 | efried | btw, to anticipate (ironic) scaling issues, probably a good idea to index the configs by identifier. Which, since we're forbidding name/uuid conflicts, actually helps make ^ seem saner :P | |
| 22:23:56 | efried | if node.name in cfgs: | |
| 22:23:56 | efried | And then when we're processing a node: | |
| 22:23:56 | efried | cfgs[identifier] = cfg | |
| 22:23:56 | efried | puke | |
| 22:23:56 | efried | if identifier in cfgs: | |
| 22:23:56 | efried | so, the load-up logic becomes simply: | |
| 22:23:57 | efried | elif node.uuid in cfgs: | |
| 22:23:57 | efried | cfg = cfgs[node.name] | |
| 22:23:58 | efried | elif '$COMPUTE_NODE' in cfgs: | |
| 22:23:58 | efried | cfg = cfgs[node.uuid] | |
| 22:23:59 | efried | cfg = cfgs['$COMPUTE_NODE'] | |
| 22:24:00 | efried | else: | |
| 22:24:55 | efried | or more terser: | |
| 22:24:56 | efried | if cfg: ... | |
| 22:24:56 | efried | cfg = cfgs.get(node.uuid, cfgs.get(node.name, cfgs.get('$COMPUTE_NODE'))) | |
| 22:44:47 | efried | dansmith: procedurally, to get things moving, how would you feel about "resize/migration/shelve/others will be addressed in a subsequent spec"? | |
| 23:10:07 | efried | mriedem: Is grenade *supposed* to use py2 on the "old" side? | |
| 23:19:53 | melwitt | mriedem: new tempest test shenanigans you might have an opinion about https://review.opendev.org/693096 tl;dr is downstream we want to be able to test with the config_drive: True request param for POST /servers and one way to add it would result in dupe test coverage in the gate | |
| 23:22:48 | gmann | efried: for ussuri jobs no. py2->py3 does not work and required more fixes on pckg installation etc. it was decided to do py3->py3 in grenade ussuri jobs. | |
| 23:24:41 | melwitt | gmann: hey, could you hit up the unified limits spec again? john updated to address your latest comments | |
| 23:25:33 | efried | gmann: Gotcha. How do I make the "old" side run py3 then? | |
| 23:26:06 | gmann | melwitt: done. | |
| 23:26:13 | melwitt | thanks gmann | |
| 23:26:40 | efried | apparently isn't correct/sufficient. | |
| 23:26:40 | efried | export DEVSTACK_GATE_USE_PYTHON3=True | |
| 23:26:40 | efried | gmann: note that https://review.opendev.org/#/c/695052/ still failed with the old side running py2, so | |
| 23:27:07 | gmann | efried: is it, this should make use_python3=True on old node | |
| 23:27:40 | gmann | i did in all other patches also - https://review.opendev.org/#/q/topic:drop-py27-support-devstack-default-py3+(status:open+OR+status:merged) | |
| 23:27:49 | gmann | and grenade-py3 job is doing that only. | |
| 23:33:56 | gmann | for example, watcher patch is working fine - https://review.opendev.org/#/c/695097/1 | |
| 23:36:03 | gmann | from log it seems like DEVSTACK_GATE_USE_PYTHON3 is not set on d-g side | |
| 23:50:24 | efried | gmann: sorry, I didn't mean to bail on you there, I was trying to get to zuul.o.o/jobs and it crashed my machine. This has been happening for a while, I should learn. | |
| 23:50:47 | efried | Anyway, now I *do* need to bail. I'll try to catch up with you tomorrow about the grenade business. | |
| 23:51:14 | gmann | efried: sure. | |
| #openstack-nova - 2019-11-20 | |||
| 00:38:12 | openstackgerrit | sean mooney proposed openstack/nova master: add [libvirt]/max_queues config option https://review.opendev.org/695118 | |
| 01:35:18 | mriedem | melwitt: you're going to have to ping me earlier tomorrow about that tempest patch, it's too late for me to dig into that right now | |
| 01:35:24 | mriedem | but i'll star it | |
| 01:36:03 | melwitt | mriedem: ok, np. it's not urgent but something I thought you might have thoughts on. thanks | |
| 01:40:46 | mriedem | also, | |
| 01:41:00 | mriedem | your downstream ci people know they can just write tempest plugins for the tests they want to use right? | |
| 01:41:04 | mriedem | it doesn't need to be in the main repo | |
| 01:41:32 | mriedem | so i don't think it's a great pattern to set with like, "we'd like to test x which is 99% already covered elsewhere" | |
| 01:43:19 | melwitt | I didn't know how tempest plugins work | |
| 01:43:19 | mriedem | anyway, i've got to drop but i left that comment on there | |
| 01:43:26 | mriedem | cinder has one, check it out | |
| 01:43:36 | mriedem | like devstack plugins | |
| 01:43:41 | mriedem | https://github.com/openstack/cinder-tempest-plugin | |
| 01:43:59 | mriedem | anyway, o/ | |
| 01:44:01 | melwitt | ok | |
| 02:22:22 | mnaser | sean-k-mooney: something in your domain -- i was wondering if libvirt by default makes sure that vcpus for domains live inside the same numa node | |
| 02:22:50 | mnaser | i'm playing with new epyc rome hardware and seeing poor memory access times with sysbench, im wondering if the reasoning behind it is that cpu time is flopping back and forth between numa nodes | |
| 02:38:56 | alex_xu | melwitt: hellow, are you still here | |
| 02:39:12 | alex_xu | s/hellow/hello/ | |
| 02:55:30 | HagunKim | Hi, How can I see Nova version like 19.0.3, 20.0.1 on my nova-compute host? | |
| 03:58:29 | openstackgerrit | Merged openstack/nova master: Remove functional test specific nova code https://review.opendev.org/683609 | |
| 04:58:14 | openstackgerrit | Brin Zhang proposed openstack/nova-specs master: Add composable flavor properties https://review.opendev.org/663563 | |
| 06:13:13 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.opendev.org/694717 | |
| 07:57:51 | gibi | 20.1.0 | |
| 07:57:51 | gibi | HagunKim: $ nova-compute --version | |
| 07:58:48 | HagunKim | gibi: Thanks! | |
| 08:28:17 | bauzas | good morning Nova | |
| 08:31:17 | gibi | bauzas: good morning | |
| 08:31:46 | bauzas | gibi: just doing a few stuff now, but if you're OK, I'd like to discuss on the audit command in 30 mins | |
| 08:31:49 | bauzas | fine with you ? | |
| 08:31:58 | gibi | bauzas: sure, ping me | |
| 08:32:35 | bauzas | tl;dr: when calling --delete, you haven't use the --verbose also, so I don't see if we tried to delete the allocation | |
| 08:32:38 | bauzas | gibi: ^ | |