Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-07-12
14:08:29 openstackgerrit Radoslav Gerganov proposed openstack/nova master: VMware: ensure that live migration attaches to correct interface https://review.openstack.org/478797
14:08:47 gibi mriedem: sure that could work
14:10:02 stephenfin mriedem: Sounds good. Lemme give that a shot
14:34:05 openstackgerrit Merged openstack/nova master: Add policy to InstanceGroup object https://review.openstack.org/563375
14:45:55 stephenfin mriedem: RE: [1], NUMACell.network_metadata is not nullable. However, that means I need to update everything that uses NUMACell to set something for that field, right? [1] https://review.openstack.org/#/c/564439/13/nova/objects/numa.py@58
14:46:15 stephenfin That's a _lot_ of changes, if so
14:47:32 dansmith stephenfin: it can be unset regardless of the nullability
14:47:47 dansmith I think his point was that you should just not set it instead of always forcing it to None
14:49:11 stephenfin dansmith: That makes sense, but I found a piece I'd missed here https://github.com/openstack/nova/blob/master/nova/virt/hardware.py#L1692-L1695
14:49:41 stephenfin (that was where I was seeing the "setting in the initializer vs. setting as an attribute issue, btw)
14:50:24 stephenfin If I'm assuming network_metadata is always set in production and it's a bug if not, then I need to update any unit test which calls the function
14:50:45 dansmith I'm not sure what you mean
14:51:32 stephenfin dansmith: I need http://paste.openstack.org/show/725721/
14:52:13 dansmith sounds like you need to conditionally set it
14:52:17 dansmith like:
14:52:37 dansmith if "network_metadata" in hostcell: newcell.network_metadata = hostcell.network_metadata
14:52:38 dansmith right?
14:53:09 stephenfin Indeed, and that's what I had done but I saw the aforementioned issue
14:53:49 dansmith you never really told me what you saw.. I'm assuming you meant that setting it after initialization seemed not to stick?
14:53:59 dansmith that would, of course, be strange behavior we'd want to nail down
14:54:07 dansmith because _obviously_ you should be able to do that r:)
14:56:05 mriedem stephenfin: dansmith: the issue i pointed out later in the series once i got to the api part, was that if the user explicitly specifies networks='none' it means network_metadata will be None,
14:56:21 mriedem so we can't blindly set that on the RequestSpec in the api because it will blow up if the field is not nullable,
14:56:30 mriedem so we just need to be conscious of that,
14:56:33 stephenfin Yeah, I was just concerned that even with that, we'd have the potential to hide some bugs so it wouldn't be acceptable
14:56:44 stephenfin i.e. if, for some reason, we weren't setting the attribute somewhere when we should be
14:56:45 mriedem but it also means the consuming code in the scheduler filter (and hardware.py) needs to be aware the field might not be set
14:56:49 mriedem which hardware.py is already doing i believe
14:56:51 dansmith mriedem: if there is a valid case where it should be None, then it should be nullable=true, however, we shouldn't ever set it to None when we don't know the value
14:57:07 stephenfin mriedem: I don't think that's an issue - we always set NetworkMetadata but the physnets/tunneled attributes might not be set
14:57:12 mriedem networks='none' is the case where we know it should be None
14:57:23 mriedem stephenfin: bzzt,
14:57:26 mriedem let me link you
14:57:33 mriedem (to your code)
14:57:58 dansmith mriedem: should that be network_metadata=None, or just physnets=[],tunneled=False ?
14:58:03 mriedem https://review.openstack.org/#/c/564444/14/nova/network/neutronv2/api.py@1633
14:58:11 mriedem that depends on ^
14:58:43 mriedem i have a whole buttload of comments in https://review.openstack.org/#/c/564452/ related to this
14:58:55 mriedem https://review.openstack.org/#/c/564452/17/nova/compute/api.py@889
14:59:02 stephenfin mriedem: Sorry, you said RequestSpec and I read NUMACell https://review.openstack.org/#/c/564441/21/nova/virt/libvirt/driver.py@6338
15:00:04 stephenfin mriedem: Yeah, I should just be setting that to NetworkMetadata(physnets=set(), tunneled=False)
15:01:08 mriedem well also see https://review.openstack.org/#/c/564444/14/nova/tests/unit/network/test_neutronv2.py@4963
15:01:11 mriedem similar concern
15:01:44 mriedem anyway, you have options
15:02:34 mriedem either use an 'empty' NetworkMetadata object, or support None, or handle unset
15:02:59 mriedem at this point i kind of think nullable=True makes sense for when we know we don't have networking
15:03:19 mriedem but it's like a 5% "makes sense"
15:04:15 stephenfin heh
15:04:23 stephenfin OK, I'll explore that
15:04:36 stephenfin and try to push something to demonstrate this possible o.vo bug
15:09:44 mriedem anyone have any idea why we wouldn't cache the host az here? https://github.com/openstack/nova/blob/da16690f4db6172659ffa4f804296100b5ba24d6/nova/availability_zones.py#L93
15:10:04 mriedem we do it when getting the az for an instance that has a host set https://github.com/openstack/nova/blob/da16690f4db6172659ffa4f804296100b5ba24d6/nova/availability_zones.py#L194
15:12:41 mriedem dansmith: i think i have a fix for the cinder/cross_az_attach=False up-call issue
15:12:44 mriedem 1 line fix
15:13:03 jmlowe dansmith: do you happen to know off the top of your head where the ceph free space is queried?
15:13:20 mriedem jmlowe: should be down in libvirt driver update_available_resource
15:13:30 mriedem get_available_resource?
15:13:42 jmlowe those are grepable, thanks
15:13:45 mriedem yeah _get_local_gb_info
15:13:53 mriedem elif CONF.libvirt.images_type == 'rbd':
15:13:53 mriedem info = LibvirtDriver._get_rbd_driver().get_pool_info()
15:20:02 mriedem https://bugs.launchpad.net/nova/+bug/1781421
15:20:03 openstack Launchpad bug 1781421 in OpenStack Compute (nova) "CantStartEngineError due to host aggregate up-call when boot from volume and [cinder]/cross_az_attach=False" [Medium,Triaged]
15:20:16 mriedem - if not host:
15:20:16 mriedem + if not host or (host and instance.availability_zone):
15:20:17 mriedem fixed!
15:25:59 openstackgerrit Matt Riedemann proposed openstack/nova master: Mention osc-placement for managing traits in docs https://review.openstack.org/582173
15:28:43 melwitt jmlowe: and here's a proposal for another way to query free space that I've not fixed up with tests yet https://review.openstack.org/#/c/556692/1/nova/virt/libvirt/storage/rbd_utils.py
15:31:51 dansmith note that in placement, we don't report free space, but infer it from total - (allocated + reserved)
15:32:42 melwitt oh, okay
15:32:58 mriedem melwitt: you were +2 on this before jaypipes pointed out that we couldn't actually update consumer project/user info in placement, but that bug is fixed now and his -2 is gone, and i've added a functional test so can you review this again? https://review.openstack.org/#/c/574488/ - it's the heal_allocations thing for healing incomplete consumers
15:33:02 mriedem and would close out that bp
15:33:29 melwitt mriedem: ah yup, thanks for the heads up
15:33:32 melwitt will revisit that
15:39:55 stephenfin Pro tip #1: 'tox -e py27 -- --failing' runs all the tests that failed on a previous iteration
15:40:29 stephenfin Pro tip #2: 'tox -e py27 -- -n nova/tests/unit/virt/test_hardware.py' let's you run tests without needing to convert to a Python path
15:42:20 mriedem efried: alex_xu: arvindn05: karimull: on its way to the gate of horrors https://review.openstack.org/#/c/569498/ - i'll do a follow up for my comments
15:42:35 efried mriedem: cool mon
15:42:54 mriedem pass the dutchie
15:43:15 mriedem melwitt: ^ means another runway slot will be open today
15:43:16 melwitt that means we get to close out a bp right? woo
15:43:26 melwitt noyce. good news
15:44:45 melwitt stephenfin: protip #2 I didn't know about, thanks
15:46:13 efried I tend to use stestr run directly from the venv so I don't have to wait an extra 45 seconds for tox to do... whatever it does in "preparation".
15:47:15 melwitt I do too when I'm iterating on running tests
15:47:49 stephenfin efried: I think we discussed this before, but doesn't 'touch nova.egg_info' fix that for you?
15:48:50 efried stephenfin: That does sound familiar. Not sure. But I know this works :)
15:49:05 stephenfin Fair :)
15:49:07 efried stephenfin: I've got it in a bash function so I can kick it off easily
15:50:08 stephenfin I really need to figure out what's going on with tox there. It seems pretty useless, given how often I need to recreate stuff when dependencies change
15:51:11 efried i.e. very rarely, yah?
15:52:06 stephenfin Ever :) If it's doing a dependency check based on the timestamp of .egg_info, that check should be failing because dependencies have changed
15:52:07 efried Assuming it's dependency checks that are slow, if there was a tox --no-dep-check flag that let you bypass all that stuff, that would be coolness.
15:52:23 stephenfin If it's not failing, you'd have to wonder what the "dependency check" _is_ doing
15:52:24 efried oh, or that, if it's actually a bug that should just be fixed :)
15:52:52 efried well, occasionally tox does rebuild my venv. I assume it does that based on figuring out that something is out of date.
15:53:23 stephenfin Yeah, I'd rather some way to just disable it, personally. The gate will catch the rare case where a local version mismatch causes issues
15:53:44 stephenfin The only time I see a full rebuild is when tox.ini changes
15:53:45 melwitt mine never auto rebuilds the venv for me. I do it manually if I hit "no module X found" errors when things change
15:53:54 stephenfin (assuming you mean recreate)

Earlier   Later