Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-12
15:52:51 mdbooth e.g. just updating it
15:52:52 mdbooth Yeah
15:53:08 mdbooth We only created it on line 1212, and we've still got the conf it was created from
15:53:26 mdbooth Do we really need to reparse the whole xml?
15:53:54 mdbooth Hmm, _prepare_device_bus reads assigned hw address...
15:54:00 mdbooth So I guess the answer is yes
15:54:17 artom Glad that worked out without me having to answer ;)
15:54:27 shaner in kilo, when performing a live-migration, it's not showing up when doing a 'migration-list'
15:54:44 shaner but, doesn't happen in mitaka
15:54:57 mdbooth However, in this specific case all we need to do is match a single device, which we just added, and parse its assigned hw address
15:55:51 artom mdbooth, would that actually solve the bdm <-> xml match problem though?
15:55:57 mdbooth I agree with vladikr that relying on the contents of connection_info is unpleasant, though
15:56:10 mdbooth Although in this case, if it's not set we do at least have the opportunity to set it
15:59:01 mdbooth artom: Still thinking. Will comment on the review
15:59:45 artom mdbooth, many thanks :) From what I'm gathering, we have two ways to perform that bdm <-> xml matching (serial and device name), and both won't work 100% of the time
16:00:00 artom So the question becomes, which one is easier to "fix"?
16:00:23 mriedem mnestratov: can someone from VZ fix up this comment quick? https://review.openstack.org/#/c/355805/18/nova/virt/libvirt/driver.py@684
16:00:36 mriedem mnestratov: otherwise i'm +2 on that change
16:01:43 mriedem mnestratov: nevermind, i'll just update that myself
16:08:19 mriedem +2 on https://review.openstack.org/#/c/355805/ now
16:08:21 mriedem needs another core
16:14:18 mriedem dansmith: done on https://review.openstack.org/#/c/409890/ - created a bug for the map_cell0 thing
16:14:43 dansmith mriedem: ack thanks
16:15:34 mriedem dansmith: are you going to make https://review.openstack.org/#/c/416585/ depend on https://review.openstack.org/#/c/418141/ ?
16:15:35 mriedem it seems it has to
16:15:47 mriedem if you're busy i can make that change
16:16:41 dansmith mriedem: no, I was just hoping we'd merge the nova change and then poke sdague
16:16:47 dansmith but I can if you want
16:16:56 sdague what's up?
16:17:03 mriedem i think we should use the depends-on
16:17:06 dansmith okay
16:17:51 dansmith it doesn't get us any testing and probably isn't in danger of merging without us noticing,
16:17:52 dansmith but .. done
16:18:27 dansmith sdague: this is ready and blocked on the nova change that is required for us to merge it: https://review.openstack.org/#/c/416585/
16:18:59 dansmith it has survived quite a bit of abuse thus far, so pretty confident :)
16:19:13 mriedem claudiub|2: unless you want to make a case for it, i'm going to defer https://blueprints.launchpad.net/nova/+spec/hyper-v-pci-passthrough to pike
16:19:14 sdague yeh, I had an old +2 on it
16:19:24 sdague how soon do we need a merge for it?
16:19:34 mriedem sdague: no rush i don't think
16:20:03 mriedem bauzas: i'm going to move https://blueprints.launchpad.net/nova/+spec/request-spec-use-by-compute to pike
16:20:10 sdague ok, mtreinish is on a plane to .au today, I'll see if other devstack folks pop up on it
16:20:22 dansmith mriedem: it's not like amazingly urgent,
16:20:26 dansmith but it certainly helps me get stuff done before I disappear
16:20:30 claudiub|2 mriedem: thati is what i'm currently testing at the moment. i'm setting up an environment for it, and i'll try to run the intel pci tempest tests
16:20:40 mriedem claudiub|2: ok, i'll hold off then
16:20:45 mriedem dansmith: ok
16:20:50 mriedem i think we could get it in by eod then
16:25:43 cmartin Hey could somebody unabandon this patch for me so I can work on it? https://review.openstack.org/#/c/342061/
16:25:58 mriedem cmartin: done
16:26:08 cmartin mriedem: thanks
16:28:19 openstackgerrit Christopher Martin proposed openstack/nova: Stop using mox in unit/virt/disk/test_api.py https://review.openstack.org/342061
16:30:02 mriedem sean-k-mooney: fyi that os-vif 1.4.0 breaks the nova unit tests, seen here https://review.openstack.org/#/c/418421/ : http://logs.openstack.org/21/418421/4/check/gate-cross-nova-python27-db-ubuntu-xenial/376a0f3/console.html#_2017-01-11_10_21_37_885392
16:31:00 mriedem looks like 'vif_name': u'nicdc065497-3c' is new
16:32:30 mriedem this https://review.openstack.org/#/c/390225/
16:34:31 mriedem hmmm, so the nova unit test is going to need to transform the object to it's known good version, which would be 1.0
16:39:01 mnestratov mriedem: hi
16:39:32 mnestratov mriedem: sorry, just saw your message
16:40:03 mriedem np
16:42:50 mnestratov mriedem: thanks for fixing the review for us )
16:47:01 mdbooth artom: It occurs to me that we don't call _build_device_metadata often enough
16:47:31 mdbooth We need to call it every time we regenerate libvirt domain xml, because all hw address will change every time we do that
16:52:52 openstackgerrit Matt Riedemann proposed openstack/nova: WIP: Make unit tests work with os-vif 1.4.0 https://review.openstack.org/419558
16:52:55 mriedem dansmith: jaypipes: i've got a problem with ^ because of http://paste.openstack.org/show/594736/
16:53:16 mriedem i'm backporting the VIFHostUser object to 1.0 but it's nested 'network' object isn't getting backported recursively
16:53:25 mriedem well, i think it's trying, but there is no rule for it
16:54:08 mriedem i do see this though https://github.com/openstack/os-vif/blob/1.4.0/os_vif/objects/network.py#L51
16:55:08 openstackgerrit Davanum Srinivas (dims) proposed openstack/nova: [WIP][py35] Trying to get cinder+rally working https://review.openstack.org/419476
16:57:39 dtp dansmith
16:58:48 dansmith dtp
16:59:10 dansmith mriedem: is it calling super in make compatible?
16:59:19 mriedem dansmith: yup
16:59:25 dtp do i understand your comment on https://review.openstack.org/#/c/418141 that instead of relying on the mapping being there, we need to rely instead on cells.enable setting?
16:59:29 mriedem looks like _obj_relationships_for doesn't have a manifest on the thing i'm backporting
16:59:34 dansmith mriedem: does the manifest call for the older version/
17:00:01 mriedem where does the manifest get set on the object?
17:00:19 mriedem oh i see it doesn't have a manifest
17:00:29 mriedem so it tries to use the old school self.obj_relationships[field]
17:00:33 dansmith dtp: which comment?
17:00:35 mriedem and we don't have a rule for it
17:00:45 dtp dansmith the commit message at the top
17:00:46 dansmith mriedem: yeah, manifest is just passed into the call, not stored anywhere
17:01:38 dansmith dtp: we need to ignore the fact that the mapping is in place, if we're still on cellsv1, so that we don't bypass the replication and go straight to the cell database, which might have not-yet-replicated stuff in it
17:01:59 dtp ok, thank you
17:02:19 mriedem ok so i need to call obj_make_compatible_from_manifest() instead and provide my own manifest on how to handle this nested field?
17:02:23 dansmith dtp: cells.enable is really cellsv1.enable
17:02:42 dtp yeah i have that burned to my brain roms :D
17:02:47 dtp +1!
17:02:59 dansmith mriedem: https://github.com/openstack/nova/blob/master/nova/tests/unit/objects/test_objects.py#L886-L956
17:03:14 mdbooth artom: Replied.
17:10:13 edleafe Can someone explain the failure here: http://logs.openstack.org/51/416751/6/check/gate-nova-tox-db-functional-ubuntu-xenial/fec7ddc/testr_results.html.gz
17:10:38 edleafe It seems all the tests passed, but the returncode was 1
17:11:41 mriedem edleafe: this looks odd http://logs.openstack.org/51/416751/6/check/gate-nova-tox-db-functional-ubuntu-xenial/fec7ddc/console.html#_2017-01-12_15_25_20_540113
17:11:47 mriedem 2017-01-12 15:25:20.506 4337 INFO nova.osapi_compute.wsgi.server [req-471b1e60-9717-479e-a053-06834d8fe63f fake fake - - -] (4337) wsgi exited, is_accepting=True
17:12:12 jaypipes mriedem: lookin...
17:13:31 edleafe mriedem: odd is a good word
17:18:30 jaypipes mriedem: ah, yeah... I ran into similar recently when trying to add a UUID field to the NUMACell object. Objects that had their versions changed but never got an obj_make_compatible() method run into this failure. To fix, you need to manually set the obj_relationships class attribute on the object in osvif :(
17:18:46 mriedem what's really crazy,
17:19:08 mriedem when this test was added to nova https://review.openstack.org/#/c/334048/11/nova/tests/unit/network/test_os_vif_util.py@575
17:19:13 jaypipes mriedem: we aren't yet sending osvif objects over the wire, though, so it may be we could do a hack of the object manifests with dansmith's help?
17:19:31 mriedem it's setting the vif_name which passed even though vif_name wasn't a field on that type in os-vif 1.3.0 which is what we were testing against

Earlier   Later