| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-12 | |||
| 15:28:47 | mriedem | have to run to a meeting | |
| 15:29:20 | mriedem | dansmith: on the placement reconnect backport, there is a change beneath it too | |
| 15:29:29 | dansmith | mriedem: oh okay | |
| 15:37:52 | openstackgerrit | Dan Smith proposed openstack/nova: WIP Move instance creation to conductor https://review.openstack.org/319379 | |
| 15:42:00 | openstackgerrit | Maciej Szankin proposed openstack/nova: Add CPUWeigher https://review.openstack.org/379525 | |
| 15:43:01 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Plumbing for tagged nic attachment https://review.openstack.org/415622 | |
| 15:43:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Plumbing for tagged volume attachment https://review.openstack.org/391941 | |
| 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 | |