| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-12 | |||
| 14:41:04 | artom | mdbooth, around? Feel like weighing in on a debate between vladikr and I? We're discussing what's the best way to match block devices between the BDM object (in the DB) and the instance XML in libvirt. It used to be done with device name, and I'm changing it to serial (aka volume uuid). Here's the review: https://review.openstack.org/#/c/418100/4 | |
| 14:41:31 | mdbooth | artom: Looking | |
| 14:50:50 | openstackgerrit | Maciej Szankin proposed openstack/nova: config options: remove libvirt imagecache https://review.openstack.org/378497 | |
| 14:57:13 | openstackgerrit | Istvan Imre proposed openstack/python-novaclient: Pass relevant parameters to Token based authentication https://review.openstack.org/419441 | |
| 15:02:09 | openstackgerrit | Radoslav Gerganov proposed openstack/nova: Update all instances when their AZ is renamed https://review.openstack.org/419502 | |
| 15:02:35 | mriedem | bauzas: thanks for running the meeting - i had to get my daughter ready for school so the 8am meeting always throws me off | |
| 15:02:50 | bauzas | mriedem: I have the exact same problem for the scheduler meeting | |
| 15:02:59 | bauzas | mriedem: so I understand you | |
| 15:03:37 | bauzas | my proposal to stop scholarizing my daughter unfortunately got a NACK from my wife :/ | |
| 15:03:46 | bauzas | don't understand why... | |
| 15:03:47 | mriedem | heh | |
| 15:04:10 | mriedem | just send her out during the day and let her learn the lessons of the wild | |
| 15:04:30 | bauzas | at 6, yeah | |
| 15:05:17 | edleafe | mriedem: drop her off early. That'll toughen her up in Minnesota winters! | |
| 15:05:30 | bauzas | I should have a dog by april, I'll teach my daughter how to dog sled | |
| 15:05:50 | mriedem | i had to walk to school at her age in the winter... | |
| 15:05:53 | mriedem | so back in my day... | |
| 15:06:25 | openstackgerrit | Stephen Finucane proposed openstack/nova: scheduler: Don't modify RequestSpec.numa_topology https://review.openstack.org/419479 | |
| 15:06:32 | jroll | she'll literally get buried trying to walk in the snow up there, that seems unwise | |
| 15:06:58 | openstackgerrit | Ed Leafe proposed openstack/nova: Add check for invalid allocation amounts https://review.openstack.org/416752 | |
| 15:06:58 | openstackgerrit | Ed Leafe proposed openstack/nova: Remove the Allocation.create() method. https://review.openstack.org/416751 | |
| 15:06:59 | openstackgerrit | Ed Leafe proposed openstack/nova: Fix missing RP generation update https://review.openstack.org/419137 | |
| 15:08:24 | mriedem | lyarwood: just fyi before you see it, i've got a series of backports for newton to make this pass https://review.openstack.org/#/c/416734/ | |
| 15:08:39 | mriedem | i.e. ironic in newton will fail if placement is enabled w/o that series of fixes | |
| 15:08:57 | mriedem | https://review.openstack.org/#/c/416762/ is the target fix, but there are several dependent patches before it to keep the diff sane | |
| 15:09:15 | mriedem | some aren't bug fixes, they are refactors, but not new features so shouldn't be too concerning | |
| 15:10:59 | mriedem | wznoinsk: the intel nfv ci job tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial seems to always fail on stable/newton changes - is there something we need to backport to fix that or is it even worth running that job on newton? | |
| 15:11:16 | mriedem | e.g. http://intel-openstack-ci-logs.ovh/25/408725/2/check/tempest-dsvm-multinode-ovsdpdk-nfv-networking-xenial/2aa0563/console.html | |
| 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: 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 | |