| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-25 | |||
| 20:41:44 | mriedem | i was under the impression zuulv3 handled that for us | |
| 20:42:07 | mriedem | but maybe that's only if it's in required_projects in zuul.yaml | |
| 20:43:01 | mriedem | pip freeze is showing a tag rather than a git hash though http://logs.openstack.org/68/654468/6/check/openstack-tox-py36/6c5ead4/tox/py36-4.log | |
| 20:43:05 | mriedem | oslo.config==6.8.1 | |
| 20:44:33 | melwitt | yeah that was my concern | |
| 20:45:08 | mriedem | not sure what this is about "cannot set the recursion limit to 10 at the recursion depth 55: the limit is too low" | |
| 20:45:20 | mriedem | the python docs don't say anything about a lower bound | |
| 20:46:34 | melwitt | where are you seeing that? | |
| 20:46:41 | mriedem | http://logs.openstack.org/68/654468/6/check/openstack-tox-py36/6c5ead4/testr_results.html.gz | |
| 20:47:19 | melwitt | oh different job | |
| 20:48:19 | mriedem | yeah the bug only hits on py36 for some reason | |
| 20:49:05 | fungi | mriedem: melwitt: yes, a repository will only be checked out alongside if it's in the required-projects list | |
| 20:49:24 | mriedem | ack, ok, that's easily fixable in this hack patch | |
| 20:49:59 | fungi | otherwise depends-on means "don't merge until this other change merges" | |
| 20:50:45 | fungi | (which also applies to a required project, but an rp will also be tested in conjunction with your change) | |
| 20:51:14 | melwitt | mriedem: I guess the doc does say "Changed in version 3.5.1: A RecursionError exception is now raised if the new limit is too low at the current recursion depth." https://docs.python.org/3/library/sys.html#sys.setrecursionlimit | |
| 20:51:26 | melwitt | so it has to be at least 55? | |
| 20:51:32 | melwitt | based on the error message it put | |
| 20:52:07 | mriedem | hmm | |
| 20:52:07 | mriedem | b'RecursionError: cannot set the recursion limit to 56 at the recursion depth 55: the limit is too low' | |
| 20:52:22 | melwitt | lol, what are we supposed to | |
| 20:52:27 | melwitt | do | |
| 20:53:50 | melwitt | I guess that means at that moment, the depth is 55 | |
| 20:54:03 | mriedem | yeah | |
| 20:54:09 | mriedem | i bumped to 100 and then it passed | |
| 20:54:09 | melwitt | so the limit has to be some headroom above that to allow for more | |
| 20:54:16 | melwitt | ok, cool | |
| 20:54:29 | mriedem | it was 1000 in my local py3.6 | |
| 20:54:39 | mriedem | i mean the default or whatever | |
| 20:54:41 | mriedem | which is a bionic node | |
| 20:54:57 | melwitt | ok, I see | |
| 20:59:36 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: debug config opts infinite recursion https://review.opendev.org/654468 | |
| 20:59:41 | mriedem | fungi: melwitt: ^ hopefully that does it | |
| 21:00:25 | mriedem | nova meeting | |
| 21:00:39 | melwitt | good call excluding all the other jobs too | |
| 21:27:02 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Move legacy-grenade-dsvm-neutron-multinode-live-migration in-tree https://review.opendev.org/640207 | |
| 21:28:49 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove deprecated 'default_flavor' config option https://review.opendev.org/645476 | |
| 21:29:32 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Fix cleaning up console tokens https://review.opendev.org/637716 | |
| 21:31:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Fix nova-grenade-live-migration run book for opendev migration https://review.opendev.org/655800 | |
| 21:38:10 | efried | mriedem: thanks for running that. | |
| 21:38:18 | mriedem | np | |
| 21:47:28 | efried | melwitt: tinyurl pointing to the charts for the project update | |
| 21:47:35 | efried | melwitt: since there's all those links on 'em | |
| 21:48:10 | melwitt | oh, the slides. yeah, that's fine | |
| 21:49:50 | mriedem | dansmith: i think the multi-cell job has yielded it's first victim | |
| 21:50:00 | dansmith | in a good way? | |
| 21:50:08 | mriedem | if latent bugs are a good thing | |
| 21:51:37 | mriedem | apparently in this addFloatingIP code, we fetch the instance from the cell at the top and pass down the targeted context for that instance, | |
| 21:51:46 | mriedem | and if the floating IP is associated with another instance we fetch that https://github.com/openstack/nova/blob/a991980863f056323c1ee9fd6a46dbc4cb899eca/nova/network/neutronv2/api.py#L2390 | |
| 21:51:59 | mriedem | but if that instance is in another cell, bingo bango you've got yourself a 404 mister | |
| 21:52:12 | mriedem | shits the bed right here https://github.com/openstack/nova/blob/a991980863f056323c1ee9fd6a46dbc4cb899eca/nova/network/neutronv2/api.py#L2400 | |
| 21:52:38 | dansmith | mriedem: pretty sure you're over your bingo bango quota for the week | |
| 21:53:05 | mriedem | umm, actually one of the cells was down and now i have no quota limit | |
| 21:53:37 | mriedem | you get to experience that kind of dry wit and more in person next week | |
| 21:54:28 | dansmith | looking forward to the "and more" there | |
| 21:54:52 | mriedem | you'll have to pay for the full riderman experience | |
| 21:55:16 | dansmith | so...many...nws...things....to...say | |
| 21:57:32 | efried | mriedem, melwitt: As soon as I can figure out how to fixture the sdk (see https://storyboard.openstack.org/#!/story/2005475) we could actually do clouds.yaml immediately. | |
| 21:57:32 | efried | Beyond that, yes, the long-term benefit is cutting the python-*client packages out of the picture, removing that tech debt. That relationship is brittle and causes us to either fear changing it or break things when we do. | |
| 21:59:28 | efried | ...immediately. Because the sdk proxies are Adapter subclasses, so we can just swap them seamlessly for the ksa adapter's we're hacking up today. Then cut the actual client libs out at our leisure. | |
| 21:59:30 | mriedem | but then we'll have (1) old style config for cinder (2) normalized ksa config for all the other non-sdk clients we use and (3) sdk clouds.yaml thing | |
| 21:59:50 | efried | deprecation period for oslo.config stuff obviously. | |
| 21:59:52 | mriedem | seems like a configuration mess until everyting is cut over | |
| 22:00:17 | efried | And operators already have clouds.yaml for the most part, so they'll have very little to do. | |
| 22:00:50 | efried | (by "already" I mean, if they're running stein+) | |
| 22:01:03 | mriedem | "That relationship is brittle and causes us to either fear changing it or break things when we do." as the recent ironicclient stuff can tell i suppose, | |
| 22:01:08 | efried | exactly | |
| 22:01:12 | dansmith | efried: which is like nobody right? | |
| 22:01:17 | mriedem | but i imagine we'll hit a new class of weird bugs once we start using the sdk | |
| 22:01:18 | efried | though I didn't want to bring that up | |
| 22:01:28 | efried | because I broke it by introducing the ksa config... | |
| 22:01:37 | mriedem | i'm not sure how much damage we get from glance/neutron/cinder client | |
| 22:02:13 | mriedem | what's being used for nova/cyborg in that series? just ksa? | |
| 22:02:16 | mriedem | or the sdk? | |
| 22:02:23 | efried | dansmith: Right, this is setting up for a future time when people are actually using the releases we're working on and we've got new jobs and don't care anymore. | |
| 22:02:35 | efried | I've been pushing Sundar to use sdk | |
| 22:03:03 | efried | I gave him the placement code for the cyborg side of his demo and set it up to use sdk | |
| 22:03:09 | mriedem | so if we did the sdk thing, cyborg integration could be the guinea pig, and then i'd think cinder since we haven't ksa'd our cinder stuff yet | |
| 22:04:14 | efried | I was going to do placement first, because it would be a transparent swap under the covers - we don't have a placementclient, so we would just set up SchedulerReportClient._client as the Connection.placement proxy (which is an Adapter subclass) instead of the raw Adapter. | |
| 22:04:25 | efried | get/put/etc primitives come along for free. | |
| 22:04:59 | efried | I PoC'd this already and it works seamlessly in tempest. It just blows up all the unit and functional tests until I figure out fixtures (see above) | |
| 22:05:21 | mriedem | ok | |
| 22:05:49 | efried | ...and then ironicclient, because we have lots of support for that from the ironic team, and dtantsur|afk is a sdk core who can help to some extent | |
| 22:06:26 | efried | and I have a guy coming on board (hi dustinc) who's trying to be involved in ironic who has started looking at it. | |
| 22:07:07 | efried | but yeah, could look into tackling cinder early, I see the benefit since it got left behind with ksa. | |
| 22:07:16 | efried | never could figure that f'in thing out. | |
| 22:15:06 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Correct signature on fake_get_availability_zones https://review.opendev.org/655806 | |
| 22:21:29 | mriedem | dansmith: so i'm going to rev this multi-cell job patch to disable the failing test here until there is a bug fix - while doing that, what do you think about just making the job non-voting in the check queue for a bit until we're happy with it through the ptg? | |
| 22:21:57 | dansmith | mriedem: I'm good with whatever, but it seems like non-voting to collect data is what we would normally do | |
| 22:28:02 | mriedem | ack | |
| 22:28:03 | mriedem | done | |
| 22:28:20 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add nova-multi-cell job https://review.opendev.org/655222 | |
| 22:28:21 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Enable n-novnc in nova-multi-cell job https://review.opendev.org/655711 | |
| 22:52:24 | openstackgerrit | melanie witt proposed openstack/nova master: Use futurist.ThreadPoolExecutor in scatter_gather_cells https://review.opendev.org/650172 | |
| 23:06:40 | efried | o/ see y'all tomorrow | |
| 23:41:19 | artom | ||
| 23:56:51 | rm_work | so, is it possible to run nova unit tests with tox on OSX? anyone manage this? or is it just impossible (seems that pyinotify is not compatible with osx so the env build just fails) | |
| #openstack-nova - 2019-04-26 | |||
| 01:23:34 | mriedem | dims: didn't you used to run nova unit tests in osx? ^ | |
| 01:50:53 | mnaser | I usually run them.. I haven't had troubles | |
| 01:51:10 | mnaser | i.. don't usually run the whole suite tho | |