| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-01-16 | |||
| 15:49:31 | mriedem | once the bdm.device_name is originally set, i also don't think it will change. _prep_block_device in the compute manager calls _add_missing_dev_names but that noops if a bdm already has a device_name set | |
| 15:50:06 | artom | mriedem, well, if we want to really be sure, could we add some tagged devices to rally tests? | |
| 15:50:42 | artom | Or grenade? What's the thing that does upgrades in the gate? | |
| 15:51:36 | dansmith | heh | |
| 15:51:39 | dansmith | grenade | |
| 15:51:42 | dansmith | oopsie | |
| 15:51:59 | dansmith | guess I never dropped my cape | |
| 15:53:29 | mriedem | artom: grenade does attach a volume on the old side before the upgrade, but it doesn't tag it - and even if it did, to verify the guest can read the tag properly on the new side (via tempest) would require running a test that does that ssh into the guest, which wouldn't be a "smoke" test and those are the only kinds of tests that grenade jobs run | |
| 15:53:31 | mriedem | plus, | |
| 15:53:46 | mriedem | the chances of the device name changing when you only have one volume attached is pretty slim | |
| 15:53:55 | mriedem | since i think it'd just be vda or vdb in that case | |
| 15:54:30 | mriedem | anyway, if the root answer is "the device naming schema is unchanged, but fixed to allow more than 26 names" then i tihnk we're ok | |
| 15:54:36 | mriedem | i.e. consistent naming schema, but unbounded | |
| 15:54:56 | mriedem | i think that's what the commit message in https://review.openstack.org/#/c/573066/ is saying | |
| 15:55:01 | dansmith | mriedem: just ensure the first 26 are the same pattern after the change, right? | |
| 15:55:12 | dansmith | only the 27th should be different and then you're probably fine yeah? | |
| 15:55:30 | artom | mriedem, I thought the question was "does the new schema retroactively get applied to existing devices?" | |
| 15:56:10 | mriedem | i think the real question is, why am i worrying about this and wasting my time on it | |
| 15:56:40 | artom | And actually not even that - "does the new schema retroactively get applied to *only* the database or *only* the XML?" | |
| 15:57:16 | artom | mriedem, when experiencing bouts of existential nihilism I usually turn to alcohol | |
| 15:57:30 | mriedem | if anything it would be only the xml | |
| 15:57:37 | mriedem | pretty sure we don't change bdm device_name once set | |
| 15:57:48 | mriedem | b/c that hoses up some db constraints and stuff we passed to cinder during the attach | |
| 15:58:07 | artom | Err, then we actually might have a problem :( | |
| 15:58:45 | mriedem | like dan said, if the old pattern and new pattern are the same for the first 26 then we're fine | |
| 15:59:33 | artom | Yeah, screw those people with more than 26 disks, what were they thinking anyways | |
| 15:59:54 | sean-k-mooney | artom: you could not have more then 26 disks before | |
| 16:00:09 | artom | sean-k-mooney, ohhhh, hah! | |
| 16:00:12 | artom | Yeah, we're fine then | |
| 16:00:56 | artom | And maybe mriedem's right, fix that bug if/when it comes up | |
| 16:01:09 | artom | Seems like a pretty edgy case | |
| 16:01:27 | artom | (So maybe get dansmith to fix it </internal red hat joke>) | |
| 16:02:09 | artom | Not my fault you've shacked up with 1/4 U2 | |
| 16:03:05 | mriedem | i think it's fine, i ran the old scheme and the new scheme over 26 in a loop and it's the same, | |
| 16:03:07 | mriedem | just a-z | |
| 16:03:51 | mriedem | the edge is a generational ground breaking guitarist for the greatest band out of ireland and dansmith is at no fault for following them on tour | |
| 16:04:08 | dansmith | oh the jokes are endless | |
| 16:04:15 | mriedem | https://www.youtube.com/watch?v=UJXqnYCWW7Y | |
| 16:04:32 | dansmith | as are the "how southpark has already modeled this bit of reality" quotes from mriedem | |
| 16:05:07 | mriedem | hey the show has been on a long time | |
| 16:05:41 | artom | Pretty soon they'll run out of reality and have to start making their own | |
| 16:05:48 | artom | Ooohhh, is that how the matrix started? | |
| 16:13:44 | mriedem | maciejjozefczyk: one question in https://review.openstack.org/#/c/591607/ | |
| 16:17:30 | kashyap | mriedem: While linking I feel the itch to clean up necessary misinfomration, missing details | |
| 16:17:42 | mriedem | kashyap: scratch that itch in a separate change | |
| 16:18:16 | kashyap | mriedem: It's a small, one-sentence related addition in the "block migration" section. | |
| 16:18:35 | maciejjozefczyk | mriedem: checking | |
| 16:18:40 | kashyap | (But don't worry, I'm with your implicit point: "one logical change per commit".) | |
| 16:21:21 | maciejjozefczyk | mriedem: the same as you already noticed, could be a set and if - needs to changed globally | |
| 16:23:12 | mriedem | maciejjozefczyk: ack | |
| 16:32:29 | mriedem | stephenfin: jaypipes: looks like the max_count limit isn't being honored in this online data migration https://review.openstack.org/#/c/614167/ | |
| 16:32:33 | mriedem | i mean it is, but per cell | |
| 16:33:23 | mriedem | so cern could end up migrating 1K+ instances across 70+ cells even though the default max limit is 50 | |
| 16:46:20 | melwitt | cdent, edleafe: your API SIGgy opinions are wanted on this change where we're talking about a status code of 403 vs 409 for a TooManyDiskDevices attached error https://review.openstack.org/#/c/616777/8//COMMIT_MSG@14 | |
| 16:46:42 | cdent | looking | |
| 16:46:43 | edleafe | melwitt: ack. In meeting hell today, but will get to it soon. | |
| 16:46:55 | melwitt | thanks y'all | |
| 16:58:24 | cdent | melwitt: responded, probably not super helpfully as I can't decide | |
| 16:59:11 | melwitt | cdent: cool, thank you | |
| 17:01:23 | kashyap | (Goes to make a TODO to clearly defin it, and then consistently use it across the board.) | |
| 17:01:43 | openstackgerrit | Merged openstack/nova master: docs: Secure live migration with QEMU-native TLS https://review.openstack.org/629627 | |
| 17:04:23 | yan0s | Hi all, I have a question about quota classes | |
| 17:04:34 | yan0s | how do I associate them with a user? | |
| 17:10:30 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365 | |
| 17:10:30 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add free for claimed, allocated devices https://review.openstack.org/616120 | |
| 17:10:31 | openstackgerrit | Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115 | |
| 17:10:31 | openstackgerrit | Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929 | |
| 17:15:14 | stephenfin | melwitt: Think this is something that could be put through? https://review.openstack.org/#/c/608279/ | |
| 17:18:30 | stephenfin | sean-k-mooney: Guess this should be looked at? https://review.openstack.org/#/c/629025/ | |
| 17:19:29 | sean-k-mooney | we fixed that already | |
| 17:20:30 | sean-k-mooney | or maybe its another bug | |
| 17:20:36 | sean-k-mooney | ill take a look soon. | |
| 17:25:19 | sean-k-mooney | stephenfin: we should open a propper os-vif bug for this | |
| 17:25:38 | sean-k-mooney | stephenfin: also i would like to know why we are not seeing this in our ci. | |
| 17:25:53 | sean-k-mooney | e.g. why is this apprently only happening with triplo | |
| 17:25:53 | stephenfin | sean-k-mooney: Presumably because we don't have a Windows CI? | |
| 17:25:55 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: A few miscellaneous items related to "native TLS" https://review.openstack.org/630980 | |
| 17:25:56 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: docs: Update references to "QEMU-native TLS" document https://review.openstack.org/631283 | |
| 17:26:05 | stephenfin | actually, that wouldn't be it | |
| 17:26:26 | sean-k-mooney | right since triplo only works on centos/rhel/fedora? | |
| 17:26:38 | kashyap | mriedem: As promised: https://review.openstack.org/631283 ("docs: Update references to "QEMU-native TLS" document") | |
| 17:28:05 | stephenfin | sean-k-mooney: We're not seeing them because we don't test the privsep stuff | |
| 17:28:41 | stephenfin | Instead we call the function directly | |
| 17:28:56 | edleafe | bauzas: are you free to jump on the hangout for a few minutes? | |
| 17:29:12 | mriedem | bauzas: can you confirm that you tested, in the lab with read hardware, being able to reshape vgpus with libvirt? | |
| 17:29:33 | stephenfin | sean-k-mooney: and I'm guessing we don't have a function test that calls any of this code https://review.openstack.org/#/c/629025/2/os_vif/tests/functional/internal/command/ip/test_impl_pyroute2.py | |
| 17:31:37 | sean-k-mooney | stephenfin: be we should be seeing this erro in the os-vif-ovs tempest jobs | |
| 17:31:52 | openstackgerrit | Merged openstack/os-traits master: Update hacking version to latest https://review.openstack.org/628604 | |
| 17:32:53 | sean-k-mooney | we are not running the tempest senairo network basic ops tests | |
| 17:33:53 | sean-k-mooney | we should stil have test coverage on this is we are ever booting a vm however.... im going to add extra tests to that job | |
| 17:34:14 | sean-k-mooney | oh we are tempest.scenario.test_network_basic_ops.TestNetworkBasicOps | |
| 18:11:08 | openstackgerrit | Rodolfo Alonso Hernandez proposed openstack/os-vif master: Import IP implementation modules outside privsep context https://review.openstack.org/629025 | |
| 18:21:30 | openstackgerrit | Matthew Booth proposed openstack/nova master: Add functional test for bug 1550919 https://review.openstack.org/631294 | |
| 18:21:30 | openstackgerrit | Matthew Booth proposed openstack/nova master: libvirt: Don't delete disks on shared storage during evacuate https://review.openstack.org/578846 | |
| 18:21:32 | openstack | bug 1550919 in OpenStack Compute (nova) "[Libvirt]Evacuate fail may cause disk image be deleted" [Medium,In progress] https://launchpad.net/bugs/1550919 - Assigned to Matthew Booth (mbooth-9) | |
| 18:57:26 | melwitt | stephenfin: https://review.openstack.org/#/c/608279 looks ok to me but it's dependent on another change that has no review yet | |
| 18:57:33 | openstackgerrit | Eric Fried proposed openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677 | |
| 18:57:34 | openstackgerrit | Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695 | |
| 18:57:35 | openstackgerrit | Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042 | |
| 18:57:35 | openstackgerrit | Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705 | |