Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-11-19
16:40:44 bauzas efried: https://review.opendev.org/#/c/670112/8/nova/cmd/manage.py@2867
16:41:10 bauzas context is that I used a wrong argument : 'microversion' instead of 'version'
16:41:39 bauzas so I could rather use utils.getargspec()
16:41:49 efried I understand, gimme sec.
16:41:53 bauzas I mean, in the PlacementFixture
16:42:45 bauzas efried: ie. something around there https://github.com/openstack/nova/blob/master/nova/tests/functional/fixtures.py#L103
16:43:43 efried oh, crap, yeah, I remember trying to unwind this _fake_* gorp a while back and back-burnering it because it turned out to be hard.
16:44:37 efried yeah, this is (still) awful to have in the way of the actual placement fixture
16:44:52 efried it will mask all kinds of problems, like the one you're running into.
16:45:58 efried egads, we should also be making self._client a sdk proxy now as well.
16:46:07 bauzas you know what ? I'll provide a separate change
16:46:11 bauzas efried: ^
16:46:15 efried not that it's hugely different
16:46:28 efried bauzas: Totally agree a separate change is in order.
16:46:34 bauzas k
16:47:08 efried If you can't completely kill the _fake_* methods, they should at least be avoiding massaging the args as much as possible.
16:47:21 gmann stephenfin: can you rebase this on top of slaweq patch to dropneutron-grenade from devstack (commented on review) - https://review.opendev.org/#/c/649097/10
16:48:30 stephenfin ack
16:51:20 openstackgerrit Merged openstack/nova stable/pike: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693236
16:52:23 stephenfin gmann: done
16:55:10 gmann stephenfin: thanks, only thing we need to care is neutron-grenade job which will not work on devstack-py3-default. slaweq has patches up to migrate its usage to grenade-py3 but not all are merged. so i am making neutron-greande explicitly say py2
16:56:03 stephenfin gmann: Makes sense. Do we need https://review.opendev.org/#/c/649097/ to depend on that so?
16:56:42 gmann stephenfin: yeah, i am pushing the neutron patch (neutron-grenade is in neutron repo) and ping you
16:58:11 gibi bauzas: tested your placement audit patch. The basic functionality seems to work with even bandwidth involved. But I think --delete is broken somehow. (See my comment in the review)
16:58:23 bauzas gibi: k, will look
16:58:37 bauzas gibi: and thanks :)
16:59:02 gibi np
16:59:34 bauzas gibi: I can't see your comment on delete ?
16:59:45 bauzas anyway, let's discuss this tomorrow
16:59:49 bauzas thanks gibi a lot
17:00:20 bauzas ah, nevermind
17:00:23 bauzas Ctrl-R
17:04:56 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'os-consoles' API https://review.opendev.org/687907
17:04:56 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'nova-console' service, 'console' RPC API https://review.opendev.org/687908
17:04:57 openstackgerrit Stephen Finucane proposed openstack/nova master: Remove 'nova-xvpvncproxy' https://review.opendev.org/687909
17:59:41 mriedem dansmith: you want to move this bottom cross-cell patch along? https://review.opendev.org/#/c/642591/ - you should already be familiar with this one
18:10:57 dansmith mriedem: yeah, sorry I need to re-find my way on those
18:13:50 mriedem bauzas: easy bug fix https://review.opendev.org/#/c/694756/
18:15:17 openstackgerrit Kashyap Chamarthy proposed openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Ussuri" https://review.opendev.org/695056
18:58:22 openstackgerrit Boris Bobrov proposed openstack/nova master: Also enable iommu for virtio controllers and video in libvirt https://review.opendev.org/684825
19:19:49 openstackgerrit Merged openstack/nova master: FUP to Ie1a0cbd82a617dbcc15729647218ac3e9cd0e5a9 https://review.opendev.org/694787
19:32:00 efried mriedem: Do you remember seeing/fixing this recently? https://zuul.opendev.org/t/openstack/build/ac433b3305ba454f845990f98a3bf481/log/logs/grenade.sh.txt.gz#38749
19:33:30 efried I don't see it in e-r
19:45:44 mriedem efried: weren't you hitting something like that with trying to get osc to gate on py3?
19:46:05 efried this is what I don't remember.
19:46:21 efried fwiw this is trying to see whether barbican will gate on py3
19:47:56 mriedem so it's probably installing py27 on the old side and then trying to upgrade to py3 on the new side and packages are getting mixed up
19:48:06 mriedem see https://review.opendev.org/#/c/694237/
19:48:19 mriedem and https://github.com/openstack/grenade/blob/master/playbooks/legacy/grenade-py3/run.yaml
19:49:23 mriedem do the same in https://github.com/openstack/barbican/blob/master/playbooks/legacy/grenade-devstack-barbican/run.yaml
19:49:30 mriedem to make your barbican py3 dreams come true
19:51:55 efried mriedem: "the same" meaning add
19:51:55 efried export DEVSTACK_GATE_USE_PYTHON3=True
19:51:55 efried ?
19:52:34 mriedem yeah
19:52:44 efried ack, trying, thanks.
19:59:20 dansmith let it be known gmann_afk is a gentleman and his word is his bond
20:21:28 openstackgerrit Matt Riedemann proposed openstack/nova master: Allow disabling cold migration to the same host https://review.opendev.org/676022
20:26:45 dustinc dansmith: If you have a minute, would you mind taking a peek at this real quick and offering your opinion? https://review.opendev.org/#/c/693414/
20:28:19 openstackgerrit Matt Riedemann proposed openstack/nova master: Allow disabling cold migration to the same host https://review.opendev.org/676022
20:30:06 openstackgerrit Eric Fried proposed openstack/nova-specs master: Spec: Ussuri: Encrypted Emulated Virtual TPM https://review.opendev.org/686804
20:30:44 efried dansmith: Updated per your comments, but some of them left more questions than answers. I could use some help, please, when you get a chance.
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 openstackgerrit Artom Lifshitz proposed openstack/nova master: NUMA LM: Add func test for bug 1845146 https://review.opendev.org/687404
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: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 dustinc: o look, a comment right at the top of ironic driver's update_provider_tree:
22:15:35 efried # nodename is the ironic node's UUID.
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 so, the load-up logic becomes simply:
22:23:56 efried if identifier in cfgs:
22:23:56 efried puke
22:23:56 efried cfgs[identifier] = cfg
22:23:56 efried And then when we're processing a node:

Earlier   Later