| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-04 | |||
| 19:47:49 | rybridges | i have tried with project_id and i get the same behavior | |
| 19:48:11 | mriedem | ok probably because of search_opts['project_id'] = context.project_id | |
| 19:48:21 | mriedem | it overwrites the requested project_id filter with the one in the token | |
| 19:48:23 | mriedem | which is your admin project | |
| 19:48:26 | rybridges | okay i see now | |
| 19:48:29 | mriedem | so yeah you have to specify all_tenants | |
| 19:48:31 | rybridges | this is working: nova.servers.list(detailed=True, search_opts={'project_id': '9dfb1c98d6224351b55ca6dd8e4246c6', 'all_tenants': True}) | |
| 19:48:39 | rybridges | oof that sucks =( | |
| 19:48:40 | mriedem | yeah, we need to note this in the docs | |
| 19:48:58 | mriedem | i can push a patch in a bit | |
| 19:49:06 | mriedem | for the docs, not the actual api behavior | |
| 19:49:12 | rybridges | ok | |
| 19:49:18 | rybridges | that would be great | |
| 19:49:35 | melwitt | I think it used to be that all_tenants had to be passed to the CLI too but someone added automagic to do it if --tenant was passed since it's required for --tenant to work | |
| 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 | rybridges | i am** | |
| 19:55:18 | jaypipes | :) | |
| 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 | rybridges | yea... freakin juno man | |
| 19:57:20 | mriedem | YES! | |
| 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 | |