Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-12
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: Remove the Allocation.create() method. https://review.openstack.org/416751
15:06:58 openstackgerrit Ed Leafe proposed openstack/nova: Add check for invalid allocation amounts https://review.openstack.org/416752
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: 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

Earlier   Later