Earlier  
Posted Nick Remark
#openstack-nova - 2017-06-28
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/
15:54:30 openstack Launchpad bug 1615666 in OpenStack Compute (nova) "Nova config misses [cinder] insecure option" [Undecided,New]
15:54:30 sdague https://bugs.launchpad.net/nova/+bug/1615666
16:02:34 edleafe jaypipes: figured out the problem with the failing functional test in https://review.openstack.org/#/c/475448/
16:03:06 edleafe jaypipes: the DB fixture is wiping the database, but the internal _TRAITS_SYNCED flag is still True
16:03:23 edleafe jaypipes: So in subsequent tests, none of the standard traits are there
16:03:24 jaypipes edleafe: ah!.
16:03:29 jaypipes edleafe: great catch.
16:03:42 jaypipes edleafe: thank you!
16:03:43 edleafe I fixed it by adding a reset method to the Trait objects
16:03:48 edleafe object
16:03:59 edleafe and calling it from the db fixture
16:04:03 edleafe Does that sound OK?
16:04:06 jaypipes edleafe: ++
16:04:15 edleafe cool, will push in a few
16:04:19 jaypipes edleafe: ty sir!
16:04:42 jaypipes edleafe: if you feel like getting those parens style issues I missed that efried found, that would be cool too.
16:05:24 edleafe jaypipes: sure, why not?
16:05:33 jaypipes thanks!
16:05:37 edleafe jaypipes: anything to clean up that ugly style :;P
16:05:41 jaypipes :)
16:16:36 openstackgerrit Sean Dague proposed openstack/nova master: Clarify that vlan feature means nova-network support https://review.openstack.org/478551
16:23:52 cfriesen I'd welcome some more reviews of https://review.openstack.org/#/c/461456 It appears that Sahid and I are at a bit of an impasse as to what the semantics of "hw:cpu_realtime_mask" should be. I think it's confusing to have an implied "all-cpus-are-realtime" and that it should be treated as indicating which vCPUs are realtime rather than an exclusion mask indicating which vCPUs are not realtime
16:56:24 openstackgerrit Ed Leafe proposed openstack/nova master: Add a reset for traits DB sync https://review.openstack.org/478564
16:56:41 edleafe jaypipes: ^^ Made it a separate patch
16:57:25 edleafe jaypipes: I can rebase the series on that, or if you think it can merge fast, you can rebase the series on master later

Earlier   Later