| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-12 | |||
| 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 | |
| 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 | |