Earlier  
Posted Nick Remark
#openstack-nova - 2017-06-28
14:05:28 dansmith sdague: is that why we haven't removed the old one? because that'd be super confusing to our users, hence the above couple hours of debug :)
14:06:18 sdague yes, that's why the current stuff wasn't removed
14:06:41 sdague https://review.openstack.org/#/c/457715/
14:06:45 dansmith okay well, the current one probably needs an even bigger, louder comment about the "the other one"
14:07:01 dansmith ack
14:07:16 dansmith ebbex: I assume you're swapping out to the other one to report back here right?
14:07:54 ebbex dansmith: yessir ;)
14:08:32 dansmith sdague: so I thought that we told tripleo to go ahead and swap back to apache mode because we had this running in our gate now.. I guess I missed something
14:09:02 dansmith I'll ask mriedem when/if he pops up
14:11:35 sdague dansmith: I don't know if anyone told tripleo that
14:11:47 dansmith sdague: mriedem definitely did
14:12:04 sdague so, if they use the new scripts, they should be fine
14:12:18 sdague I guess that was miscommunicated
14:12:49 dansmith they should, and we'd have heard about problems I'm sure, but I think it was under the assumption that we were testing it ourselves too
14:14:02 ebbex dansmith: that did the trick in registering the services.
14:14:45 ebbex dansmith: and the 404 race-condition thing :)
14:15:12 dansmith sdague: I guess he qualified it enough: [13:07:25] <mriedem> EmilienM: so kick the tires, but don't come screaming if there are issues :)
14:15:44 dansmith sdague: that was in may and the conversation definitely made it sound like we'd be running it before July or whenever this is likely to merge at this point :)
14:15:56 dansmith ebbex: good
14:16:17 EmilienM what's up?
14:16:19 dansmith sdague: anyway, I'll put another comment in the old file to try to reduce further confusion on the old one
14:16:24 sdague dansmith: sure
14:16:30 dansmith EmilienM: nothing, just quoting ancient history, carry on :)
14:16:36 EmilienM what did I do again? :P
14:16:43 sdague cdent did ask me to take a look while he was out, I'm rebasing now, we'll see what the tests look like
14:16:51 dansmith sdague: k
14:17:09 ebbex jaypipes, dansmith, sdague : thank you for all your assistance! :D
14:18:24 jaypipes ebbex: solved the problem?
14:20:30 ebbex jaypipes: Yes indeedy :)
14:20:42 jaypipes w00t. hats off to dansmith
14:21:45 openstackgerrit Dan Smith proposed openstack/nova master: Strengthen the warning on the old broken WSGI script https://review.openstack.org/478521
14:21:46 dansmith jaypipes: sdague ebbex ^
14:22:29 sdague dansmith: actually, you don't run the other thing instead
14:22:46 dansmith sdague: eh?
14:22:49 sdague you need to run the command that's built and put in /usr/local/bin with the pbr scripts
14:23:09 sdague nova-api-wsgi
14:23:30 sdague https://github.com/openstack/nova/blob/d5634769b47f7879892e34db0ad05483bf4b0652/setup.cfg#L69-L72
14:23:36 dansmith sdague: if you've installed it on your system, yeah
14:24:09 dansmith sdague: are you saying you want me to update my comment to refer to the installed command instead of the place in the tree?
14:24:15 sdague yes
14:24:23 sdague because the thing in tree is just a function
14:24:47 openstackgerrit Dan Smith proposed openstack/nova master: Strengthen the warning on the old broken WSGI script https://review.openstack.org/478521
14:24:50 dansmith there ^
14:24:59 sdague you still need wsgi scaffolding otherwise it won't work
14:25:31 dansmith sdague: you can specify the entry point in your mod_wsgi config I think, but sure
14:26:17 sdague and, the pbr wrapper script has the locking initialization bits that are needed otherwise apache mod_wsgi can race crash on itself
14:26:59 dansmith sdague: can you show me a rendered one of those?
14:27:10 sdague http://paste.openstack.org/show/613938/
14:27:12 dansmith seems unfortunate to have that kind of setup be non-obvious
14:27:40 dansmith oh I see, I thought you meant something else
14:28:26 sdague we did it at the pbr layer because that fix is needed everywhere, then there is a semantic definition of this is a wsgi script in setup.cfg
14:28:39 sdague which is potentially useful information to people as well
14:29:41 dansmith sdague: where is that actually defined though?
14:30:27 sdague setup.cfg
14:30:49 sdague wsgi_scripts entry point
14:31:37 dansmith sdague: no, I mean where is the wrapper stuff defined
14:31:41 dansmith sdague: is that in pbr itself?
14:31:43 sdague yes
14:31:55 dansmith okay
14:32:05 sdague as are console_scripts
14:32:19 dansmith well anyway, I thought you mean oslo lock setup or something like that, not just this for the init call
14:32:25 dansmith *meant
14:32:45 sdague https://github.com/openstack-dev/pbr/blob/823165d068a77642db9e907e465db91f841ab424/pbr/packaging.py#L276-L330
14:32:53 sdague ah, no, sorry
14:33:28 sdague it's just this race about how in some mod_wsgi daemon configs you are running in shared memory space
14:33:51 sdague and oslo.config parsing doesn't expect multiple concurrent parses
14:34:04 sdague so it errors out some of the workers if they hit at exactly the same time
14:34:13 sdague iirc
14:34:48 sdague if it's not quite that problem, it's a very related one with similar symptoms
14:35:19 sdague and only calling init once addresses it
14:36:08 sdague ok, https://review.openstack.org/#/c/457715 is rebased, (the real new wsgi direction)
14:36:21 sdague if it passes tests, will get it merged
14:38:46 dansmith cool
14:39:04 sdague dansmith: honestly, you could stack a delete of those files as a depends-on for that
14:39:12 sdague then we can not even bother with the warning message
14:39:42 dansmith sdague: come on, I want to land my warning message
14:39:55 sdague the real issue that ends up happening with those old wsgi.py scripts is that people manually copy them to /var/www
14:40:04 sdague so they never get updates
14:42:59 jaypipes sdague: wait... deployers manually copy files without looking at them? no!
14:45:02 sdague jaypipes: well... more importantly they did that in liberty
14:45:08 sdague and then never again
14:45:16 sdague so any fixes we have ... never get to them
14:45:22 sdague because it was outside of the python install path
14:45:38 jaypipes sdague: I was being facetious :)
14:45:40 sdague :)
14:45:48 sdague that's fine, I was being specific :)
14:47:11 openstackgerrit Lucian Petrut proposed openstack/nova master: Raise MigrationPreCheckError if instance location is unavailable https://review.openstack.org/469779
14:50:59 sdague you forgot the sudo
15:02:11 sfinucan sdague: It's https://specs.openstack.org/openstack/docs-specs/specs/pike/os-manuals-migration.html
15:02:46 sfinucan So I guess I should use 'os-manuals-migration', even though the spec says to use 'doc-rework' as the topic
15:03:57 sdague sfinucan: ok, but that's not the blueprint
15:04:16 sdague the blueprint: .... only works if that is the short name of the blueprint
15:04:28 avanko_ i'm looking for somebody who can help to solve issue with Openstack-Neutron. our team is processing cluster stress test on OPNFV FDS, OStack-ODL-FDSio-HA, when running the test, we have a blocker, at some stage, the nova stops adding ports to VM
15:05:16 avanko_ is there anybody to help us with this? please contact me on avanko@cisco.com, so we can set up a brief call and go through the discovered issue in more detail. currently we are blocked by this issue
15:09:30 openstackgerrit Takashi NATSUME proposed openstack/nova master: Stop using mox stubs in test_remote_consoles.py https://review.openstack.org/478423
15:20:21 openstackgerrit Ildiko Vancsa proposed openstack/nova master: WIP/POC Implement new attach Cinder flow https://review.openstack.org/330285
15:26:12 cfriesen someone just pointed out that after you boot up an instance with neutron ports it's possible to delete the ports in neutron. Does this seem odd to anyone else?
15:41:06 openstackgerrit Ildiko Vancsa proposed openstack/nova master: Remove check_detach https://review.openstack.org/446671
15:54:21 sdague sfinucan / johnthetubaguy - on the config guide side, how are we feeling about adding all the pass through keystone auth options?
15:54:22 sdague https://review.openstack.org/#/c/358701/

Earlier   Later