Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-25
15:30:18 kashyap efried: Thursday is the first day, right?
15:30:21 efried yes
15:30:21 stephenfin jaypipes: \o/
15:30:38 stephenfin jaypipes: Thanks for taking the time to look through that
15:30:41 kashyap efried: I might need to be elsewhere. But we've discussed it also in Dublin, and people agreed it is something we want.
15:30:56 kashyap efried: So even if I miss it, it should be OK?
15:31:06 efried kashyap: If Saturday is better, I'll leave it there. Just had an opening.
15:31:20 jaypipes stephenfin: np, that *you* for having the energy to keep it going.
15:31:51 efried kashyap: But even better, if it's something we don't need to discuss, I can just strike it.
15:31:58 kashyap efried: You know what, maybe just put it on Thurs 14:00. I'll work it out to be there
15:32:05 efried okay
15:32:06 stephenfin jaypipes: Also, fwiw, I'd love to deprecate those options and would like to do so at some point in the future. Just need to figure out how to deprecate these things that are essentially unversioned APIs
15:32:08 stephenfin Baby steps
15:32:34 kashyap efried: It should be a quick thing. No elaborate discussion needed
15:34:46 mriedem stephenfin: do you know what might have changed in our tox setup such that if you specify a target that doesn't exist, it used to fail fast but now it doesn't
15:34:55 mriedem i.e. tox -e foo
15:35:33 mriedem pretty sure i've fat-fingered some target to see it pass when the actual thing would have failed a test
15:36:04 mriedem yeah heh i ran tox -e fast7
15:36:23 mriedem and tox -e api-samles
15:36:35 stephenfin mriedem: I've spotted that and I don't know, unfortunately.
15:36:35 stephenfin mriedem: Hmm
15:36:41 stephenfin ERROR: unknown environment 'fast7'
15:36:41 stephenfin $ tox -e fast7
15:36:52 stephenfin ^ I still see that on my machine (TM)
15:36:54 mriedem which version of tox do you have?
15:37:04 stephenfin 3.4.0
15:37:04 stephenfin $ tox --version
15:37:50 openstackgerrit Adam Spiers proposed openstack/nova master: Add new "supports_amd_sev" capability to libvirt driver https://review.opendev.org/638680
15:40:06 mriedem 3.7.0 imported from /usr/local/lib/python2.7/dist-packages/tox/__init__.pyc
15:40:06 mriedem $ tox --version
15:40:19 stephenfin mriedem: https://tox.readthedocs.io/en/latest/changelog.html#v3-8-0-2019-03-27
15:40:24 stephenfin "Fix missing error for tox -e unknown when tox.ini declares envlist. - by @medmunds #1160"
15:40:31 stephenfin Looks like a bug in 3.7.0
15:40:41 mriedem ah https://github.com/tox-dev/tox/issues/1160
15:41:19 mriedem Successfully installed tox-3.8.0
15:41:20 mriedem ERROR: unknown environment 'foo'
15:41:20 mriedem osboxes@osboxes:~/git/nova$ tox -e foo
15:41:22 mriedem hot diggity damn
15:41:24 mriedem thanks stephenfin
15:41:30 stephenfin no problemo
15:44:10 efried wow
15:44:22 efried note to self: Ctrl+Alt+C does *not* open the calculator
15:44:50 melwitt mriedem: grafana shenanigans proposed here https://review.opendev.org/655591 wondering if I should add stable branch panels to it too
15:45:25 aspiers efried: lol
15:46:01 mriedem melwitt: ah it was the per-project thing that was busted, maybe that's what i talked about with corvus before
15:46:05 mriedem thanks for fixing that
15:50:45 lajoskatona mriedem: Hi, regardig https://review.opendev.org/640600 & https://review.opendev.org/640601 (tempest schema validation for nova v2.70 & 2.71) if you need help to push them I am happy to help you out
15:54:35 mriedem lyarwood: fyi https://graphite.opendev.org/render/?width=1231&height=593&_salt=1556207646.49&from=-8weeks&target=stats_counts.zuul.tenant.openstack.pipeline.check.project.opendev_org.openstack_nova.master.job.tempest-full-py3.FAILURE&target=stats_counts.zuul.tenant.openstack.pipeline.check.project.opendev_org.openstack_nova.master.job.devstack-plugin-ceph-tempest.FAILURE
15:54:39 mriedem you can get the graph from graphite
15:55:06 mriedem lajoskatona: go ahead, i'm not working on those
15:55:42 mriedem melwitt: nice catch on the tempest-full-py3 vs devstack-plugin-ceph-tempest (not py3) in the nova case, we should probably change nova to run against the devstack-plugin-ceph-tempest-py3 job instead
15:55:56 lajoskatona mriedem: ok, do I need any special thing to test in devstack?
15:56:21 melwitt mriedem: yeah, I was wondering that too
15:56:56 mriedem melwitt: that will throw the graph data off, but we could switch now, make your graph change depend on that and then revisit in a couple of weeks to compare stability
15:57:08 mriedem or just do that in a follow up, whatever
15:57:14 mriedem lajoskatona: i'm not sure i understand the question
16:00:23 lajoskatona mriedem: never mind, I try to to push, and come back if I have questions :-)
16:00:42 mriedem lajoskatona: ack and thanks
16:01:48 lajoskatona mriedem: :-)
16:11:11 openstackgerrit Dan Smith proposed openstack/nova master: Add vmware driver image type capabilities https://review.opendev.org/655730
16:11:11 openstackgerrit Dan Smith proposed openstack/nova master: Add ironic driver image type capabilities https://review.opendev.org/655729
16:11:12 openstackgerrit Dan Smith proposed openstack/nova master: Add zvm driver image type capabilities https://review.opendev.org/655732
16:11:12 openstackgerrit Dan Smith proposed openstack/nova master: Add xenapi driver image type capabilities https://review.opendev.org/655731
16:12:05 dansmith I dunno who to tag on the zvm one for review
16:12:12 dansmith but I'm pretty sure they only support raw
16:13:17 melwitt mriedem: I dunno if you saw, they did hit the eventlet monkey patching issue in ubuntu, last comment https://review.opendev.org/647310
16:16:57 openstackgerrit Matt Riedemann proposed openstack/nova master: Always pass HostAPI to get_availability_zones https://review.opendev.org/655583
16:35:35 mriedem melwitt: yeah i saw
16:35:44 mriedem coreycb didn't +1 it though...
16:35:57 mriedem dansmith: i suppose add jichenjc
16:38:50 melwitt I guess I took his comment on the review to be in support. but yeah, coreycb if you could +1 https://review.opendev.org/647310 if you are in support of backporting it
16:40:38 imacdonn somewhat of a tangent, I suppose ... but I think we need to figure out what to do about the eventlet monkey_patching vs. WSGI issue ... it's blocking me from upgrading to Stein
16:42:54 melwitt afaik there's not a clear thing we should do to address the problem, or did I miss it? eventlet monkey patching is not something I understand well
16:44:35 imacdonn same here
16:45:19 imacdonn the nova docs rather strongly suggest moving to WSGI, but maybe my only option is to go back to running nova-api the old way :/
16:46:22 imacdonn alternative interim may be to hack the monkey-patching out, but I don't understand the implications of that well enough ...
16:46:42 dansmith yeah I don't think you can just remove it
16:47:00 imacdonn I don't have it in my Rocky deployments, though
16:47:20 dansmith don't have what? the problem or the monkeypatching?
16:47:25 imacdonn both ;)
16:48:11 dansmith hrm, I'm trying to think about what the api service does that might continue to work without being patched
16:48:36 dansmith if we use all the regular primitives, then it might just work with regular threading, but I expect there are some subtle behavior assumptions
16:48:38 imacdonn it was added here: https://github.com/openstack/nova/commit/23ba1c690652832c655d57476630f02c268c87ae
16:48:40 dansmith locks we don't hold
16:48:45 melwitt I have a patch series that is going on the route to removing eventlet dependency for nova-api https://review.opendev.org/650172 but it needs a follow up patch that makes the executor type configurable (or outright changes it away from green threads)
16:49:32 dansmith imacdonn: right, but it was added because we didn't realize that we weren't patching when the wsgi stuff was split out from service originally, IIRC
16:49:55 melwitt I'm not sure if there are other reasons aside from scatter-gather that eventlet is a dependency in nova-api
16:50:20 imacdonn dansmith: right, and presumably someone decided that it was, infact, needed, with WSGI
16:50:48 imacdonn dansmith: there's mention of multiple cells (which I don't have (other than cell0)) ... but dunno if there are other cases where it's "needed"
16:50:56 dansmith melwitt: that'd be the big one, but any other spawn we do in some layer that can be called from api and other services
16:51:01 dansmith imacdonn: right but even with cell0 you're affected by that
16:51:21 coreycb melwitt: mriedem: added my +1
16:52:04 dansmith I've been a bit disconnected.. is the problem that seems to be introduced the amq heartbeat thing?
16:53:04 mriedem imacdonn: i thought https://review.opendev.org/#/c/647310/ was in response to https://github.com/openstack/nova/commit/23ba1c690652832c655d57476630f02c268c87ae in a way, but you said that fix doesn't help you right?
16:54:32 imacdonn mriedem: that just changes where monkey-patching gets inserted ... I have my problem either way
16:57:01 mriedem i guess you could try exporting OS_NOVA_DISABLE_EVENTLET_PATCHING=1 but that's likely not something you want to run with
16:59:35 imacdonn yeah
16:59:39 mriedem dansmith: there are only 4 places we use the long_rpc_timeout heartbeat stuff and they'd all be calls from either conductor or compute neither of which are wsgi so i'm not sure how that would be involved, unless it was the moving of the monkey patch location in https://github.com/openstack/nova/commit/23ba1c690652832c655d57476630f02c268c87ae
17:00:25 dansmith mriedem: I think the long rpc stuff all uses regular threading primitives so it should work regardless of if you're patched or not right?
17:00:45 mriedem idk, i've never looked at the oslo.messaging implementation

Earlier   Later