Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-12
15:43:02 openstackgerrit Artom Lifshitz proposed openstack/nova: Libvirt support for tagged volume attachment https://review.openstack.org/418100
15:43:03 openstackgerrit Artom Lifshitz proposed openstack/nova: Libvirt support for tagged nic attachment https://review.openstack.org/415520
15:43:03 openstackgerrit Artom Lifshitz proposed openstack/nova: API support for tagged device attachment https://review.openstack.org/376021
15:43:57 mdbooth artom: Is the user able to see 'serial' as known to cinder?
15:44:29 artom mdbooth, it's the volume uuid
15:44:44 mdbooth Because if so, they can already find that that volume
15:45:02 mdbooth http://libvirt.org/formatdomain.html#elementsDevices
15:45:20 mdbooth If present, this specify serial number of virtual hard drive. For example, it may look like <serial>WD-WMAP9A966149</serial>. Not supported for scsi-block devices, that is those using disk type 'block' using device 'lun' on bus 'scsi'. Since 0.7.1
15:45:20 mdbooth serial
15:45:36 mdbooth Am I missing something?
15:46:22 mdbooth The user doesn't have to look up the hardware address in metadata, because they can just look for the disk with the given serial
15:46:39 artom mdbooth, heh, good point...
15:47:21 artom I don't have an answer for that, but I have another question - can we trust the device name to at least match between instance XML and block_device_mapping in the db?
15:47:37 mdbooth artom: That's what I've been looking at
15:48:11 mdbooth Short answer is no, we can't
15:48:21 artom The way our current Tempest test for that is written, we can
15:48:34 artom But the test definitely doens't cover all possible weird cases
15:48:54 artom And I know for volume attachment it didn't match
15:49:05 mdbooth e.g. I believe the following will bork it:
15:49:11 mdbooth Create instance with config disk
15:49:16 mdbooth attach volume
15:49:26 mdbooth reboot/migrate
15:49:54 mdbooth After reboot/migrate, xml will be rewritten and iirc config disk will be last again
15:50:00 mdbooth So volume name will have changed
15:51:13 artom That doesn't sound like it's fixable...
15:51:59 mdbooth In this patch we're entirely rewriting device_metadata if we attach a tagged volume, right?
15:52:19 artom mdbooth, yeah
15:52:45 mdbooth Any chance of not doing that?
15:52:47 artom You're thinking we just add the new bdm tag without recalculating everything?
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

Earlier   Later