Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-27
12:04:27 kashyap efried: There are cases, but I'll double-check w/ the libvirt dev who meditates on this
12:05:01 efried cool. /me watches from a safe distance
12:05:04 kashyap Heh
12:06:26 openstackgerrit Stephen Finucane proposed openstack/python-novaclient master: Stop silently ignoring invalid 'nova boot --hint' options https://review.opendev.org/684762
12:08:36 kashyap efried: Completely unrelated - I wonder if all the 'no-reply' emails can be directed to another 'openstack-releases' list
12:08:51 kashyap Otherwise the noise feels just too much.
12:08:56 kashyap Maybe I should ask it on the list
12:09:22 kashyap I know that the point of it is to give a heads-up to devs that a new release came out.
12:09:29 efried kashyap: respond to http://lists.openstack.org/pipermail/openstack-discuss/2019-September/009744.html
12:09:59 kashyap Ah, will do
12:10:03 kashyap Thanks for the pointer
12:10:50 efried yahyoubetcha. I didn't care enough to respond; I'm happy to hit [Delete] a couple dozen times twice a year.
12:11:54 kashyap My gripe is, the mailing list archives turn into a toilet
12:12:10 kashyap It just becomes so polluted that the signal is drowned in that noise.
12:12:34 kashyap And it shoos away those who're reading the list to ignore it. I'll respond on that thread. :D
12:22:13 zigo Is Nova really broken with cryptography 2.6 ?
12:22:27 zigo That's kind of annoying me to require 2.7, because the Debian package isn't realy.
12:22:33 zigo (and I'm not the maintainer of that one...)
12:45:00 zigo bauzas: ^ Do you know ?
12:46:08 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13) https://review.opendev.org/576020
12:46:16 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14) https://review.opendev.org/576027
12:46:30 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15) https://review.opendev.org/576031
12:46:40 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16) https://review.opendev.org/576299
12:46:51 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17) https://review.opendev.org/576344
12:47:02 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18) https://review.opendev.org/576673
12:47:14 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19) https://review.opendev.org/576676
12:47:23 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20) https://review.opendev.org/576689
12:47:31 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.opendev.org/576709
12:47:42 openstackgerrit Merged openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.opendev.org/576712
13:04:06 gibi stephenfin: regarding https://bugs.launchpad.net/python-novaclient/+bug/1845322 I think the same bug exists in openstackclient as well
13:04:06 openstack Launchpad bug 1845322 in python-novaclient "'--hint' argument to 'nova boot ' should be a key-value pair" [Low,In progress] - Assigned to Stephen Finucane (stephenfinucane)
13:09:47 gibi stephenfin: opened a story for it https://storyboard.openstack.org/#!/story/2006628
13:18:10 openstackgerrit Takashi NATSUME proposed openstack/nova master: Add TODO note for mox removal https://review.opendev.org/576758
13:22:49 openstackgerrit Walter A. Boring IV (hemna) proposed openstack/nova stable/pike: Avoid redundant initialize_connection on source post live migration https://review.opendev.org/683008
13:27:34 efried stephenfin: Is your nova-net removal series
13:27:43 efried ... "done"? Like, at least proposed all the way up?
13:27:47 efried (I haven't looked)
13:28:13 efried curious whether we could just do away with https://review.opendev.org/#/c/576758/ and/or do the actual removal on top of your series.
13:30:14 efried ...looks like just the test bits are proposed at this point.
13:45:44 stephenfin gibi: Yeah, I pushed patches for that
13:46:08 stephenfin Was trying to figure out why I couldn't file against openstackclient on launchpad. That would be why,heh
13:46:45 stephenfin efried: Yeah, just the functional test piece pushed so far. I'm working on the rest of it slowly
13:47:06 stephenfin Trying to avoid a mega "remove all the things" patch
13:47:20 efried stephenfin: as for cellsv1, good approach.
13:48:11 stephenfin efried: And the ec2 cleanup...which isn't actually merged yet (I thought it was). Would you mind looking at them if/when you have a chance? https://review.opendev.org/#/q/topic:ec2-cleanup+(status:open+OR+status:merged)
13:48:12 gibi stephenfin: cool reading the openstackclient patch now
13:51:34 dansmith mriedem: I think I'm +2 on all the +2able things in stein
13:51:42 dansmith mriedem: (re: your mention from the meeting yesterday)
13:51:55 openstackgerrit melanie witt proposed openstack/nova master: Reduce scope of 'path' query parameter to noVNC consoles https://review.opendev.org/685194
13:52:22 mriedem dansmith: ack
13:53:11 mriedem lyarwood: if you're about can you hit these? https://review.opendev.org/#/q/project:openstack/nova+branch:stable/stein+status:open+label:Code-Review=2
13:55:13 mriedem dansmith: can you hit https://review.opendev.org/#/c/680871/ and https://review.opendev.org/#/c/676498/ for rocky?
13:55:27 artom mriedem, you saw ya.wang's review on that NUMA fix?
13:55:34 dansmith I've got the rocky set up right now, are those two more important?
13:56:07 mriedem more important?
13:56:28 mriedem the former is a long-standing issue for baremetal instances, the latter is an lxc thing which is low priority
13:56:33 mriedem lxc+py3
13:56:38 mriedem artom: not yet
13:56:41 dansmith mriedem: meaning you pointed me at two rocky reviews, just wondering if I can hit those when I get to them in the rocky queue or if I should do those first for some reason
13:56:42 mriedem artom: does it work?
13:56:48 artom mriedem, yeah, tl;dr, he's +1
13:56:51 mriedem dansmith: oh, they're just ready
13:56:53 dansmith mriedem: or were you just spoon-feeding me?
13:56:54 mriedem meaning already merged in stein
13:57:07 mriedem yes, pureed stable food
13:57:37 mriedem artom: +2
13:57:46 mriedem yaawang: thanks for testing https://review.opendev.org/#/c/684409/
13:57:57 artom yaawang, yep, much appreciated :)
14:05:20 efried stephenfin: done. Do you have any paste savvy?
14:05:35 efried dansmith: or you?
14:05:37 stephenfin very little, unfortunately
14:05:43 dansmith not really, no
14:05:50 dansmith I'm always mystified by that stuff
14:06:12 efried damn and blast
14:07:12 dansmith what is the question?
14:07:16 efried google seems clueless as well
14:07:29 efried dansmith: this https://review.opendev.org/#/c/685181/
14:08:03 dansmith is this a thing we want to do?
14:08:15 efried tldr version discovery endpoints shouldn't require auth, but I don't know how to make /v2.1 use a different paste composite from /v2.1/$everything_else without enumerating $everything_else
14:08:25 dansmith like, should I be able to probe vexxhost to figure out what version it's running with no credentials?
14:08:31 efried absolutely
14:08:49 efried the root discovery documents (everywhere) are already unauth'd
14:09:22 efried but at least nova, cinder, and neutron are broken in this same way, requiring auth for the versioned discovery docs (which are simply subsets of the root one)
14:09:35 dansmith sure, but the microversion available indicates what level of code is running
14:10:31 efried The version discovery process that ksa uses (currently) assumes you can probe both the root and the versioned discovery URIs without auth.
14:11:27 dansmith ack, it just seems like getting into actual details of the system should require auth, but I'm not an expert obviously
14:11:37 efried yeah, it's not really details of the system
14:11:55 efried In theory I agree it would seem as though that process could just rely on the root discovery doc, since it's just a superset of the versioned ones.
14:12:08 efried but I think perhaps the problem is that the service catalog is set up with the versioned endpoint
14:12:08 dansmith available microversion is totally details of the system
14:12:37 efried okay, point is we've already decided that's okay to expose, because it's in the root discovery doc (I think, /me confirms...)
14:13:18 efried yeah:
14:13:18 efried curl http://192.168.218.28/compute/
14:13:18 efried <snip> "version": "2.79" <snip>
14:13:56 efried "perhaps the problem is that the service catalog is set up with the versioned endpoint" shouldn't actually be a problem, which is the point.
14:14:45 efried mordred is working on a hacked up workaround for this in ksa and/or sdk to bridge the gap, but we (nova and the other services running afoul of this) really need to fix it in our APIs.
14:27:51 openstackgerrit Stephen Finucane proposed openstack/nova master: ec2: Move ec2utils functions to their callers https://review.opendev.org/662505
14:27:52 openstackgerrit Stephen Finucane proposed openstack/nova master: api: Remove 'Debug' middleware https://review.opendev.org/662506
14:38:31 efried kashyap: thank you for the thorough response on the ML ++
14:39:54 kashyap efried: No problem. I'll let Manuel file the bug

Earlier   Later