Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-04
19:51:14 rybridges okay one more thing
19:51:25 rybridges since in the python binding i have to pass all_tenants
19:51:32 rybridges whenever i want to filter by project id
19:51:52 rybridges does that mean that novaclient is actually pulling all of the instances for all tenants back, and then filtering based on project id on the front end?
19:52:01 rybridges we dont want that, because we have tens of thousands of instances
19:52:07 rybridges and filtering all of that on the front end would be very slow
19:52:26 mriedem rybridges: it is filtering server-side
19:52:33 rybridges okay
19:52:46 rybridges thank you ^.^
19:52:52 mriedem which release are you testing this on?
19:53:12 rybridges stable/ocata
19:53:31 mriedem is this penick's cluster?
19:53:46 rybridges heh yes, penick is our architect
19:53:52 mriedem he is our lord and savior
19:54:01 mriedem ignore that
19:54:03 rybridges yes he is my lord and savior as well
19:54:14 rybridges :)
19:54:25 jaypipes heh
19:54:40 jaypipes well, with penick, most people are always looking UP at him. :)
19:54:59 rybridges i am one of the few who does not have to look up
19:55:09 jaypipes rybridges: wow, lucky you :)
19:55:13 rybridges i have 6'7" so he is only a couple inches taller than me
19:55:18 jaypipes :)
19:55:18 rybridges i am**
19:56:07 jaypipes rybridges: basically, all of us nova cores have capitulated to all of penick's demands because we're all afraid he will crush us with his pinky finger if we give him any lip.
19:56:17 jaypipes rybridges: well, that and, you know, melwitt :)
19:56:42 rybridges bahahahaa
19:57:03 jaypipes rybridges: though melwitt could easily stomp on any of us with her boots :)
19:57:06 mriedem jaypipes: he doesn't have demands, because he know we can't fulfill anything for juno
19:57:17 jaypipes mriedem: lol, dig!
19:57:20 mriedem YES!
19:57:20 rybridges yea... freakin juno man
19:57:31 dansmith rybridges: that's what we call him
19:57:34 dansmith rybridges: "juno man"
19:57:41 dansmith like a superhero but...sadder
19:58:30 jaypipes edleafe: we ready on the alternate hosts/selection objects patches? just a rebase just now?
19:58:40 jaypipes edleafe: or blueprint changed...
20:02:02 edleafe jaypipes: I changed the structure of the Selection object to match the spec
20:02:10 jaypipes got it.
20:02:16 edleafe jaypipes: should be ready for review
20:02:32 edleafe jaypipes: working on the code that changes the return from select_destinations now
20:02:42 edleafe it's... involved :)
20:02:55 jaypipes indeed.
20:17:28 openstackgerrit Merged openstack/nova master: Fix inconsistency of 'NOTE:' description https://review.openstack.org/508074
20:22:46 melwitt clarkb: I think python-pastedeploy isn't being installed from the uca repo based on this http://logs.openstack.org/32/508432/1/check/gate-tempest-dsvm-full-devstack-plugin-ceph-ubuntu-xenial/575e932/logs/devstacklog.txt.gz#_2017-10-04_01_49_38_030 and trying installing it locally I'm able to do "from paste import deploy". so AFAICT the package isn't broken
20:24:15 dansmith jaypipes: edleafe: slap me if I missed something on any of these comments: https://review.openstack.org/#/c/486215
20:26:57 openstackgerrit Merged openstack/nova master: [placement] Update the placement deployment instructions https://review.openstack.org/469048
20:27:28 openstackgerrit Merged openstack/nova master: api-ref: remove redundant preserve_ephemeral mention from rebuild docs https://review.openstack.org/509273
20:27:56 openstackgerrit Merged openstack/nova master: api-ref: add note about rebuild not replacing volume-backed root disk https://review.openstack.org/509282
20:29:46 mriedem aha, found a bug in a test
20:32:10 penick Take that, stupid test
20:32:21 mriedem yeah!
20:34:39 melwitt does anyone know anything about wsgi_scripts in setup.cfg? I found that it's a directive for pbr to install scripts and they get installed to what setuptools considers to be the "install directory" and they end up in /usr/local/bin
20:34:59 melwitt is there any reason installing them that way would make it so they can't import modules that had been installed via apt-get?
20:37:07 mriedem sounds like a sdague question
20:38:15 sdague melwitt: import path will be determined by the python interpretter
20:38:26 sdague what's the execute line on it?
20:39:45 openstackgerrit Matt Riedemann proposed openstack/nova master: Avoid redundant BDM lookup in check_can_live_migrate_source https://review.openstack.org/509633
20:39:47 edleafe dansmith: tempting, but I think those are good points
20:40:10 dansmith edleafe: \o/
20:40:30 melwitt sdague: on the script? I'm not sure, it's generated by pbr from this https://github.com/openstack/keystone/blob/d20a3e971f5665604a739166987ed64e12c8de3d/keystone/server/wsgi.py#L36
20:40:38 sdague right
20:40:47 sdague on my devstack it's #!/usr/bin/python
20:41:13 sdague the only thing I can imagine is if it got a weird value during build
20:41:18 melwitt I'm trying to debug a ceph job failure so I don't have info like that for that env
20:41:35 sdague melwitt: url?
20:41:44 melwitt the only difference I see between it and normal gate jobs is paste deploy is being installed from apt-get instead of pip
20:42:10 sdague that shouldn't really matter, as long as we aren't talking about a venv
20:42:13 melwitt sdague: here's how keystone fails to start http://logs.openstack.org/32/508432/1/check/gate-tempest-dsvm-full-devstack-plugin-ceph-ubuntu-xenial/575e932/logs/screen-keystone.txt.gz
20:43:13 jaypipes dansmith: no, I think those are accurate issues you've identified.
20:43:21 melwitt sdague: I don't understand how it's not able to import paste deploy if paste deploy is installed (with apt-get)
20:43:52 melwitt and I don't think it's double installed with apt-get AND pip. I think the pip installs are skipped because it was already installed with apt-get
20:44:31 melwitt like this is it being skipped later http://logs.openstack.org/32/508432/1/check/gate-tempest-dsvm-full-devstack-plugin-ceph-ubuntu-xenial/575e932/logs/devstacklog.txt.gz#_2017-10-04_01_50_59_811
20:44:36 sdague melwitt: so... the more concerning thing is paste gets deployed again
20:44:51 sdague I think this is the python namespace issue
20:45:08 sdague paste & paste-deploy (which is really paste.deploy using a python namespace)
20:45:14 sdague end up being installed by apt
20:45:23 sdague then pip install new paste
20:45:27 sdague in /usr/local/lib
20:45:41 sdague which now means the search path for paste.* is in /usr/local/lib, the new one
20:45:59 sdague paste-deploy is not installed again, because the version looks the same to pip
20:46:08 sdague but it's in a different namespaced part of the tree
20:46:16 sdague so when you start importing it's not visible
20:46:17 melwitt oh, I see. damn
20:46:26 sdague this is why we got oslo to stop doing namespaces
20:46:33 melwitt I was focused only on paste.deploy
20:46:36 sdague yeh
20:46:59 sdague when I saw the upgrade of paste, that reminded me of this funky issue
20:47:17 sdague for this reason we try really hard to install very little python from system packages
20:47:23 sdague because you end up in exactly this situation
20:47:36 melwitt okay, so paste install wasn't skipped by pip for already existing because the version probably didn't satisfy
20:47:37 sdague I think the answer is to remove paste & paste-deploy from the dpkg list
20:47:44 sdague yes
20:47:48 sdague because of upper-constraints
20:47:49 melwitt guuhh
20:47:51 melwitt okay
20:48:14 clarkb isn't paste-deploy coming in transitively in the dpkg list though? that could get tricky to remove
20:48:23 melwitt it's coming in through ceph package
20:48:29 sdague http://logs.openstack.org/32/508432/1/check/gate-tempest-dsvm-full-devstack-plugin-ceph-ubuntu-xenial/575e932/logs/devstacklog.txt.gz#_2017-10-04_01_51_18_464
20:48:59 sdague melwitt: yeh, well that's going to be non compatible with the way we do things

Earlier   Later