| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 19:02:38 | mriedem | which one? the live migration job? | |
| 19:03:20 | sdague | mriedem: oh, you know what, maybe it isn't | |
| 19:03:21 | openstackgerrit | Eric Fried proposed openstack/nova master: PowerVM Driver: power_on/off and reboot https://review.openstack.org/427380 | |
| 19:03:24 | mriedem | sdague: right | |
| 19:03:29 | mriedem | so i pushed up the paused check | |
| 19:03:32 | mriedem | let's see what happens | |
| 19:04:39 | sdague | mriedem: ok, so the flake8-import-order completely is returning the wrong answers during my inbuffer file checking. Can I delete this thing. | |
| 19:05:09 | mriedem | i don't know what that means either | |
| 19:05:18 | mriedem | wrong answers, as in false negatives? | |
| 19:06:12 | sdague | yes | |
| 19:06:31 | sdague | it keeps saying nova needs to be before some other thing that it shouldn't be | |
| 19:06:35 | openstackgerrit | Sean Dague proposed openstack/nova master: remove flake8-import-order https://review.openstack.org/454853 | |
| 19:06:36 | openstackgerrit | Sean Dague proposed openstack/nova master: remove log translation tags from nova.cells https://review.openstack.org/454854 | |
| 19:08:04 | mriedem | do you have this change? https://github.com/openstack/nova/commit/07a042ba2c3355b4481ee976894834e819dc9710 | |
| 19:08:18 | sdague | yes, it's way after that change | |
| 19:08:28 | sdague | I don't know why it's giving me the entirely wrong answers, but it is | |
| 19:09:26 | openstackgerrit | Anusha Unnam proposed openstack/nova master: fix admin context scenarios for cinderclient https://review.openstack.org/384799 | |
| 19:17:02 | sdague | mriedem: https://dl.dropboxusercontent.com/1/view/wrhl4v895bc5rdr/Apps/Shutter/screenshot_368.png | |
| 19:17:15 | dansmith | MY EYES | |
| 19:17:20 | sdague | dansmith: :P | |
| 19:18:59 | mriedem | it's probably the import nova.conf | |
| 19:19:23 | mriedem | can't distinguish between from nova.* and import nova.*? | |
| 19:19:45 | mriedem | efried: comments in the 2nd patch | |
| 19:21:08 | sdague | mriedem: right, I don't know why it does it here, and not via tox runs | |
| 19:21:40 | cdent | sdague: is your in buffer stuff running out of the same venv? | |
| 19:21:46 | sdague | cdent: yep | |
| 19:21:49 | cdent | weird | |
| 19:22:29 | sdague | but, the whole point of doing pep8 things was to catch real errors and not make folks have to debug their local envs | |
| 19:22:36 | sdague | so I really want to get rid of this thing | |
| 19:22:49 | sdague | especially because we actually implemented that in hacking years ago, and deleted it | |
| 19:22:51 | cdent | yeah, how did it manage to show up? It's relatively new, yeah? | |
| 19:22:56 | sdague | it's new | |
| 19:25:42 | sdague | mriedem: it's not in test-requirements | |
| 19:25:44 | mriedem | sdague: cdent: while you're both here, | |
| 19:25:56 | mriedem | nova-api under httpd in devstack | |
| 19:26:11 | cdent | ah yes | |
| 19:26:20 | mriedem | sdague: i guess you're right https://github.com/openstack/nova/commit/a5d4adbd60291adc2eaaefdf76186edf74523ece | |
| 19:26:28 | cdent | that's on our lists | |
| 19:26:28 | mriedem | sdague: cdent: so at the ptg you guys said you'd help with that | |
| 19:26:36 | mriedem | my ass is grass come p1 | |
| 19:26:47 | mriedem | EmilienM is going to be all over me | |
| 19:27:00 | openstackgerrit | ayoung proposed openstack/nova master: Admin API Policy enforcement contingent on is_admin_project https://review.openstack.org/384148 | |
| 19:27:07 | EmilienM | I'm not here next week | |
| 19:27:11 | cdent | I can probalby do it next weeek then | |
| 19:27:12 | mriedem | whew | |
| 19:27:16 | sdague | mriedem: the first thing that actually should be done is get placement under uwsgi | |
| 19:27:24 | cdent | can probably do that too | |
| 19:27:38 | cdent | I'm fairly unscheduled for a very short while | |
| 19:27:47 | mriedem | i'm asking b/c i think this came up in the api subteam meeting a couple of weeks ago and i wasn't sure if there was a plan | |
| 19:28:03 | mriedem | and we still have that service version bug for the api | |
| 19:28:03 | cdent | i'm not aware of a plan, but I think we can probably make one quickly, and make it so | |
| 19:28:07 | sdague | cdent: we should really do this under uwsgi and not apache so that the systemd stuff is more useful | |
| 19:28:20 | mriedem | systemd systemd systemd | |
| 19:28:53 | mriedem | i was going to say, i thought placement was already running under apache in devstack so didn't think we cared about that one | |
| 19:29:03 | cdent | sdague: If you've got a list of hopes and dreams on this topic that you can write down somewhere (etherpad?) I can start looking into it for real on monday | |
| 19:29:26 | cdent | mriedem: we can probably move forward concurrently | |
| 19:29:36 | cdent | if we make it work under uwsgi it will also work under apache | |
| 19:29:45 | mriedem | sure | |
| 19:29:57 | mriedem | i think the release goal was either | |
| 19:29:59 | mriedem | but ok | |
| 19:30:28 | cdent | devstack likes uwsgi, puppet/tripleo likes mod_wsgi (is that still true?) | |
| 19:31:22 | sdague | https://etherpad.openstack.org/p/devstack-uwsgi | |
| 19:31:26 | cdent | it's pretty deep into my weekend already so I don't want to get too much into it right now, if possible, I'm just here for the giggles | |
| 19:31:27 | cdent | cool | |
| 19:31:29 | cdent | I'll watch that | |
| 19:31:36 | mtreinish | cdent: actually devstack by default uses mod_wsgi too | |
| 19:31:46 | mtreinish | that's how we deploy keystone (and placement too iirc) | |
| 19:31:56 | cdent | mtreinish: for now, sure, but the hope and dream is to change | |
| 19:31:56 | mtreinish | it supports uwsgi though, and that's a much better model | |
| 19:32:13 | cdent | mtreinish: above I should have said "devstack would like uwsgi..." | |
| 19:32:27 | cdent | but I'm a bad typer in the first place, and especially bad at the end of the week | |
| 19:33:01 | mtreinish | cdent: ah, I just misread that as 'devstack uses uwsgi' | |
| 19:33:32 | mtreinish | but from the goal perspective it doesn't actually matter, because as long as the wsgi_script entry point is in the setup.cfg that's enough for anyone to use either model | |
| 19:33:57 | sdague | yeh, I just don't want to be doing apache things in devstack because it really breaks the debug flow | |
| 19:33:58 | cdent | speaking of the wsgi_script entry point, I think that pbr puts that in $PREFIX/bin is a bug | |
| 19:34:24 | sdague | cdent: well, where things can be installed in python is ... limited | |
| 19:34:39 | cdent | it requires a <directory /usr/bin> that opens things up in an icky way | |
| 19:34:40 | mriedem | so steps are moving placement to uwsgi in devstack, | |
| 19:34:48 | mriedem | and then fixing the known service version bug for nova-api, | |
| 19:34:52 | sdague | yeh | |
| 19:34:56 | mriedem | and then calling out https://github.com/openstack/nova/blob/master/nova/wsgi/nova-api.py in nova's setup.cfg, | |
| 19:35:06 | mriedem | and then finally running nova-api under uwsgi? | |
| 19:35:15 | sdague | yeh, pretty much | |
| 19:36:22 | mriedem | now i have to find the bug again | |
| 19:36:41 | sdague | cdent: I do get the concern, we also just have the issue that what you can do in python packaging is kind of limited, and the previous approach was "leave as an exercise to the user" | |
| 19:37:10 | cdent | i suppose having it somewhere predictable on the filesystem leaves open the option to move it in a predictable fashion | |
| 19:37:38 | sdague | yeh, and more importantly that when you make changes, even in the default scenario it installs over the old default place | |
| 19:37:42 | sdague | that was the big issue before | |
| 19:37:59 | mriedem | dansmith: do you have the link to the service version bug for api under wsgi? | |
| 19:38:05 | sdague | there was a completely out of band "copy this file now" part of the process | |
| 19:38:57 | mriedem | ah i think this was it https://bugs.launchpad.net/nova/+bug/1661360 | |
| 19:38:57 | openstack | Launchpad bug 1661360 in OpenStack Compute (nova) "tempest test fails with "Instance not found" error" [Undecided,In progress] - Assigned to Dan Smith (danms) | |
| 19:39:02 | cdent | would it make any sense for the wsgi script handling to be a bit like the console-script handling which produces a wrapper file in the installed location that points into the relevant module in the package, such that there isn't any "real" code in the wsgi script? | |
| 19:39:54 | dansmith | mriedem: I don't know that I had one | |
| 19:39:55 | sdague | cdent: maybe, but, again it's completely out of bounds | |
| 19:40:10 | dansmith | mriedem: I guess that title is rather obscure for this issue | |
| 19:40:11 | cdent | "out of bounds" of what? | |
| 19:40:22 | sdague | python's idea of where it can install | |
| 19:41:30 | cdent | sdague: that's what I'm saying, if we are installing it in /usr/bin and someone moves it, as long as there's not much code in it, the problem of them forgetting to copy the new version into their custom location isn't one, because the "real" code is in site-packages | |
| 19:41:37 | mriedem | dansmith: updated the title | |