| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-04-07 | |||
| 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 | |
| 19:41:46 | sdague | cdent: that turns out not to be true | |
| 19:41:52 | cdent | oh? | |
| 19:42:06 | sdague | because even though there is *very* little code in it, there is some | |
| 19:42:13 | sdague | like a module and function | |
| 19:42:22 | sdague | and, people change that stuff | |
| 19:42:32 | cdent | that ought to be a very limited interface, yes? | |
| 19:42:43 | sdague | because they didn't ever think they were signing up for that to be a contract interface | |
| 19:43:22 | sdague | or it turns out we need a fix, like the threading fix | |
| 19:43:37 | sdague | cdent: I get the theory, but the fact is we did used to do that hing | |
| 19:43:55 | sdague | and then it broke because people actually needed to make changes in even the trivial stubs | |
| 19:44:04 | cdent | the past is a pain | |
| 19:44:14 | cdent | but what we've got | |
| 19:44:31 | sdague | right, but given that we needed that before | |
| 19:44:49 | sdague | I don't think it's fair to say "we've solved it forever" now | |
| 19:46:58 | sdague | I do really wish that python packaging had more rich constructures for things like SHARE directory and CONFIG directory like perl packaging does | |
| 19:47:13 | sdague | because being in SHARE would be ideal | |
| 19:47:52 | mriedem | does go have all of the packaging issues solved? because if so, let's move to go. | |
| 19:48:05 | mriedem | i heard dependency management in go is great. | |
| 19:48:12 | thomasem | Lol | |
| 19:48:45 | thomasem | Coming along https://github.com/golang/dep | |
| 19:48:50 | mriedem | dansmith's toilets are all running on golang now | |
| 19:48:52 | mriedem | i heard | |
| 19:49:07 | mriedem | toilet apps i should say | |
| 19:49:25 | dansmith | as far as you know | |
| 19:49:27 | thomasem | I can just imagine the applications. | |
| 19:49:38 | mriedem | the toilet app in go wipes your ass in half the time | |
| 19:49:38 | thomasem | "I can't do that, Dave..." | |
| 19:49:53 | mriedem | *blistering* speed | |