| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-12 | |||
| 15:12:14 | mriedem | johnthetubaguy: this is ready for you https://review.openstack.org/#/c/397399/ | |
| 15:12:35 | mriedem | raj_singh: i left a comment in https://review.openstack.org/#/c/410394/ but i'm not sure what, if anything, to do about testing that | |
| 15:13:19 | mriedem | raj_singh: it seems like we should at least have a unit test that sets send_service_user_token=True and makes the neutronclient non-admin connection | |
| 15:17:47 | lyarwood | mriedem: ack thanks, I'll try to get to them tomorrow if that's okay, currently stuck downstream fighting fires | |
| 15:18:09 | mriedem | lyarwood: yeah that's fine, just giving you a heads up | |
| 15:18:44 | lyarwood | mriedem: cheers, likewise there's a few from me with +2 from tonyb if you have a chance | |
| 15:19:09 | mriedem | ok | |
| 15:21:04 | raj_singh | mriedem: Ok, Let me look into that. Also the Glance patch I can split into 2, but service token change is just 1 line code change, so I figure to do it in just one patch. | |
| 15:22:19 | raj_singh | mriedem: https://review.openstack.org/#/c/412634/ | |
| 15:28:29 | dansmith | mriedem: I think bauzas wants you to +W this: https://review.openstack.org/#/c/409890/ | |
| 15:28:44 | mriedem | oy | |
| 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: Libvirt support for tagged volume attachment https://review.openstack.org/418100 | |
| 15:43:02 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Plumbing for tagged volume attachment https://review.openstack.org/391941 | |
| 15:43:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova: API support for tagged device attachment https://review.openstack.org/376021 | |
| 15:43:03 | openstackgerrit | Artom Lifshitz proposed openstack/nova: Libvirt support for tagged nic attachment https://review.openstack.org/415520 | |
| 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 | serial | |
| 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: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 | |