15:00:29 <beekneemech> #startmeeting oslo
15:00:30 <openstack> Meeting started Mon Jun 11 15:00:29 2018 UTC and is due to finish in 60 minutes.  The chair is beekneemech. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:31 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:33 <openstack> The meeting name has been set to 'oslo'
15:00:40 <bnemec> courtesy ping for amotoki, amrith, ansmith, bnemec, dansmith, dhellmann, dims
15:00:40 <bnemec> courtesy ping for dougwig, e0ne, electrocucaracha, flaper87, garyk, gcb, haypo
15:00:40 <bnemec> courtesy ping for jd__, johnsom, jungleboyj, kgiusti, kragniz, lhx_, raildo
15:00:40 <bnemec> courtesy ping for redrobot, sileht, spamaps, sreshetnyak, stephenfin, stevemar, therve
15:00:40 <bnemec> courtesy ping for thinrichs, toabctl, zhiyan, zxy, zzzeek
15:01:00 <kgiusti> o/
15:01:01 <redrobot> o/
15:01:04 <ansmith> o/
15:01:10 <dhellmann> o/
15:01:51 <jungleboyj> o/
15:02:22 <bnemec> #topic Red flags for/from liaisons
15:03:08 <jungleboyj> Nothing from Cinder.
15:04:03 <bnemec> The bot didn't update the topic.  Must be a case of the Mondays. :-)
15:04:22 <bnemec> I can't think of anything from the Oslo side.
15:04:28 <jungleboyj> That makes two of us.
15:04:57 <bnemec> Actually, there was one thing.
15:05:25 <bnemec> It probably doesn't affect anyone here, but it was a kind of significant change that may have broken something.
15:05:35 <dhellmann> bnemec : you're not the chair, beekneemech is
15:05:38 <bnemec> We reverted a Windows-related patch in pbr.
15:05:57 <bnemec> Oh, shoot.
15:06:08 <beekneemech> Guess that means it's Friday again. :-)
15:06:21 <dhellmann> you can #chair your other nick if  you want to switch back
15:06:21 <jungleboyj> Yay!
15:06:25 <smcginnis> You can - #chair bnemec and switch back I think.
15:06:32 <dhellmann> although I could use a short week, so...
15:06:37 <smcginnis> ;)
15:06:40 <beekneemech> Okay, thanks.
15:06:43 <beekneemech> #chair bnemec
15:06:43 <openstack> Warning: Nick not in channel: bnemec
15:06:44 <openstack> Current chairs: beekneemech bnemec
15:07:06 <bnemec> #topic Red flags for/from liaisons
15:07:26 <jungleboyj> That was weird.
15:07:33 <bnemec> So, on that note, this was the red flag I was talking about:
15:07:34 <bnemec> #link #topic Red flags for/from liaisons
15:07:44 * bnemec is not having a great start to the week
15:07:48 <bnemec> #link https://review.openstack.org/#/c/571503/
15:08:23 <bnemec> I'm not sure exactly what that breaks, but it probably breaks something.
15:08:51 <bnemec> I don't know that anyone in this meeting is running pbr on Windows though, so I doubt there's much more to discuss.
15:09:32 <bnemec> #topic Releases
15:09:51 <bnemec> Business as usual.
15:10:00 <bnemec> We did release that pbr change so it's out in the wild.
15:10:35 <bnemec> #topic Action items from last meeting
15:10:46 <bnemec> "kgiusti to sync up with Heat team on heat-tempest-plugin incompatibility with stable gabbi"
15:10:58 <bnemec> I saw a mailing list thread.
15:11:12 <kgiusti> bnemec: yah
15:11:33 <bnemec> #link http://lists.openstack.org/pipermail/openstack-dev/2018-June/131170.html
15:11:53 <kgiusti> bnemec: I've tried to run heat through the gate but: https://review.openstack.org/#/c/573437/
15:12:22 <kgiusti> bnemec: so if I did that correctly, heat doesn't attempt to run those plugins either
15:12:48 <bnemec> kgiusti: You may need to change code to trigger the jobs.
15:12:59 <kgiusti> bnemec: I'll try that.
15:13:05 <bnemec> Some projects don't run all jobs on doc-only changes.
15:13:48 <kgiusti> bnemec: Is ceilometer still a thing - I seem to recall it was being phased out
15:13:55 <bnemec> kgiusti: That was just to verify Heat has the same problem, right?
15:14:07 <kgiusti> bnemec: right - see if it worked on queens
15:14:25 <kgiusti> bnemec: to be honest these telemetry tests in oslo.messaging have been a PITA for awhile now
15:14:31 <bnemec> Yeah, ceilometer has been deprecated for a while.
15:14:47 <bnemec> Off the top of my head I don't know what the support status is for it.
15:15:15 <kgiusti> bnemec: Ideally oslo.messaging would just leverage a "telemetry" test defined in another project.
15:15:39 <kgiusti> bnemec: the current tests were mooched from heat I think, with mooched === cut and pasted
15:16:38 <bnemec> Huh, there's still quite a bit going on in ceilometer: https://docs.openstack.org/releasenotes/ceilometer/unreleased.html
15:17:32 <bnemec> Maybe only the parts that overlapped with gnocchi were deprecated.
15:18:25 <kgiusti> bnemec: the purpose of the tests are to ensure we don't break anything "telemetry"-ish, but I'm not certain we're actually testing against the proper projects
15:18:52 <kgiusti> bnemec: In other words - what does "telemetry" mean in the context of Openstack?  Heat, aodh?
15:18:56 <bnemec> kgiusti: Do we know why these were added?  Has telemetry historically been something we break a lot?
15:19:00 * kgiusti confused
15:20:26 <kgiusti> bnemec: I'm not certain why they were added.  It hasn't worked for hybrid for awhile now
15:20:46 <kgiusti> with hybrid == dual rabbitmq's (1 for notifications, one for rpc)
15:21:02 <kgiusti> and I've spend far, far too much time trying to root cause that
15:21:05 <bnemec> Telemetry according to https://docs.openstack.org/queens/projects.html is ceilometer, but stuff like gnocchi lives outside OpenStack now.
15:21:38 <dhellmann> ceilometer was a heavy user of messaging and added some APIs, so maybe we added the tests around then?
15:21:50 <dhellmann> sileht and jd used to be contributors to messaging, too
15:22:08 <kgiusti> dhellmann: that makes the most sense.
15:22:21 <dhellmann> if the tests are failing and we can't work out why and they don't seem related to messaging and we don't have support from the telemetry team maybe we should drop the tests
15:23:10 <kgiusti> dhellmann: I'll reach out directly to them
15:23:16 <bnemec> Maybe ask for someone to look at them and if no one does we start the process of removing the jobs.
15:23:25 <kgiusti> bnemec: +1
15:23:39 <dhellmann> ++
15:23:49 <bnemec> #action kgiusti to reach out to the telemetry team about their oslo.messaging test jobs
15:24:17 <bnemec> Okay, we have a way forward on that.
15:24:21 <bnemec> "bnemec to remove cliff from Oslo review list"
15:24:24 <bnemec> Done.
15:24:59 <bnemec> And that was it for action items.
15:25:10 <bnemec> #topic networkx uncap in taskflow
15:25:50 <bnemec> We need to be able to move forward with networkx, but unfortunately their 2.0 is very incompatible with the previous versions.
15:26:43 <bnemec> Unfortunately we merged the requirements change without fixing the code.
15:27:13 <bnemec> I've proposed a revert since currently the taskflow requirements are wrong, but I've gotten pushback for reasons I don't fully understand.
15:27:15 <bnemec> #link https://review.openstack.org/#/c/573752/
15:28:26 <stephenfin> I thought upper-constraints managed that for us?
15:28:41 <stephenfin> which is currently constraining to 1.11 https://github.com/openstack/requirements/blob/master/upper-constraints.txt#L82
15:29:15 <bnemec> It does, and I think the uncap patch was related to moving that up.
15:29:18 <dhellmann> bnemec : we need to start a mailing list thread explaining that we need someone to do that work
15:29:51 <stephenfin> bnemec: So if that's the case, the patch _is_ correct but we've to make sure the global requirements change doesn't go in
15:29:58 <prometheanfire> hi
15:30:02 <stephenfin> I don't really know how that would work
15:30:16 <bnemec> dhellmann: Yeah, that was actually why I initially added this topic to the meeting, and then the requirements patch merged which kind of changed the focus.
15:30:22 <dhellmann> prometheanfire : we have some concerns about the fact that someone is trying to move networkx to a new version, but taskflow doesn't support it
15:30:38 <dhellmann> and we have no one to do that work in taskflow
15:31:18 <dhellmann> is taskflow in the list of projects that are tested against upper-constraints changes?
15:31:37 <dhellmann> maybe we can add that, at least until the networkx change is done?
15:31:51 <bnemec> I think it's used by cinder, so it's probably covered.
15:31:54 <dhellmann> that would prevent someone from updating the constraint until taskflow also worked with it
15:33:25 <dhellmann> bnemec : maybe? I wonder if any of those tests are mocking networkx.
15:34:00 <prometheanfire> dhellmann: a bunch of projects don't support the new version iirc
15:34:02 <bnemec> dhellmann: Don't we run a devstack integration job?
15:34:12 <dhellmann> bnemec : ah, yes, right
15:34:16 <prometheanfire> requirements is uncapped so that projects can start working on it
15:34:20 <prometheanfire> but no one is
15:34:37 <prometheanfire> if they are not willing to update they should stop using it imo
15:35:03 <bnemec> I don't think we're saying we won't update, just that we're not there yet.
15:35:14 <dhellmann> well, and we don't have anyone to work on it
15:35:29 <dhellmann> and I'm not sure I buy the argument that we must always update past every API-breaking change of every dependency, either.
15:35:31 <smcginnis> Is there a patch out there showing the failure(s) caused by the newer networkx?
15:35:49 <smcginnis> dhellmann: ++
15:35:54 <bnemec> smcginnis: No, because upper-constraints prevents networkx 2.0 from being used in the gate.
15:36:08 <smcginnis> Unless there are other necessary fixes included in the newer API-breaking change.
15:36:11 <bnemec> To figure out it was broken I ran it locally without u-c.
15:36:17 <smcginnis> bnemec: Ah, OK.
15:36:29 <dhellmann> bnemec : we can propose a constraint update and then propose a change to taskflow that depends on the uc update to see what would break
15:36:54 <prometheanfire> in that case we'd be back to capping things and becoming out of date
15:36:59 <dhellmann> prometheanfire : who is pushing to have the requirements opened?
15:37:02 <bnemec> dhellmann: Can we?  tox.ini directly references the latest git version.
15:37:13 <prometheanfire> me
15:37:19 <dhellmann> bnemec : that value is overridden to the local filesystem in the gate
15:37:27 <dhellmann> prometheanfire : so you're working on updating the projects, then?
15:37:31 <bnemec> Ah, okay.
15:37:34 <prometheanfire> as I can
15:37:36 <dhellmann> ok
15:37:50 <prometheanfire> but only because distros are going to drop the old version
15:38:13 <dhellmann> maybe when they do that, they'll come help with the upgrade, then
15:38:25 <prometheanfire> lol, I think you know that
15:38:39 <smcginnis> We don't want to be in the state where a critical security issue is resolved in 2.0+ but we are still on 1.11 with no one having looked at what it would take to move forward.
15:39:03 <smcginnis> But yeah, the work can also be done at the time it's needed.
15:39:13 <dhellmann> networkx builds graphs of data relationships in memory, so it doesn't strike me as high on the security list, but I do get your point
15:39:34 <smcginnis> Yeah, maybe not for this lib, but in general.
15:39:35 <dhellmann> was there a mailing list thread about this already?
15:39:54 <prometheanfire> I did send a message a while ago
15:39:57 <dhellmann> ok
15:40:26 <dhellmann> maybe it's time to follow-up and indicate that now that the requirements are uncapped it would be good to have some help updating?
15:40:52 <dhellmann> and then maybe we can find one or two people to volunteer
15:40:54 <bnemec> How hard is it to become 2.0 compatible?
15:41:10 <bnemec> Is this something where we could try to leverage the typo-fixing community?
15:41:20 <prometheanfire> from what I've seen it's not bad, but not trivial either.
15:42:37 <prometheanfire> clarkb: hi
15:42:42 <prometheanfire> clarkb: we are talking about it here too
15:42:47 <clarkb> ok
15:43:05 <prometheanfire> dhellmann: correct me if I'm wrong, but projects need to support 1.x and 2.x at the same time in order for us to update right?
15:43:35 <dhellmann> prometheanfire : yes, because we can't land 1 patch to update everything at once, we need support for both versions
15:43:54 <prometheanfire> dhellmann: that's been the sticking point from what I've seen
15:44:07 <dhellmann> bnemec : that's exactly what I was thinking.
15:44:38 <dhellmann> the APIs are different enough that it's hard to support both versions?
15:44:52 <clarkb> in the case of dib if its tests aren't blocking anyone but dib itself I'd say just merge it and dib will "catch up" but sounds like dib is at least part of the test blockign?
15:45:24 <bnemec> clarkb: For Oslo we have a problem with taskflow too.
15:45:38 <clarkb> dhellmann: https://review.openstack.org/#/c/506524/7/diskimage_builder/block_device/config.py looking at that its not too terrible just have to check if dg hasattr node and nodes and then use the right name
15:46:40 <dhellmann> that doesn't sound too bad
15:46:47 <bnemec> That is a really obnoxious api change.
15:47:08 <dhellmann> maybe we could convince the networkx folks to take a compatibility fix upstream?
15:47:10 <bnemec> They couldn't just leave node as an alias of nodes?
15:47:16 <dhellmann> even if it emits a warning
15:47:20 <dhellmann> right
15:47:38 <dhellmann> prometheanfire : do you want to try that? ^^
15:48:02 <bnemec> That would make it much less painful to support both versions.
15:48:41 <dhellmann> right, and the warnings would motivate folks to update to the new API
15:48:49 <dhellmann> and we could require 2.0.1 or whatever as a minimum
15:49:03 <prometheanfire> that would be nice
15:49:05 <bnemec> The other change seems to be that a function call now returns a generator instead of a list, which isn't so bad.
15:49:18 <dhellmann> yeah, those we can deal with
15:52:56 <prometheanfire> so, just make an issue upstream for the node=nodes thing?
15:53:31 <clarkb> it is possible other projects like taskflow have other api incompatibilities. Not sure how representative dib is
15:53:32 <dhellmann> maybe even a patch?
15:53:42 <dhellmann> clarkb : good point
15:53:50 <dhellmann> we should keep investigating
15:53:52 <prometheanfire> clarkb: that's what I was wondering
15:54:02 <dhellmann> but this one seems like it would be easy enough to shim, and we're going to want to make separate patches anyway
15:54:06 <bnemec> That's true, I don't think nodes was the missing attribute I saw in taskflow.
15:55:07 * bnemec doorbell
15:56:22 <bnemec> AttributeError: 'OrderedDiGraph' object has no attribute 'nodes_iter'
15:56:57 <bnemec> I wonder if nodes is the iterator now in 2.0.
15:57:07 <dhellmann> probably
15:57:24 <prometheanfire> depend on https://review.openstack.org/531902
15:58:15 <dhellmann> prometheanfire : thanks
15:58:24 <bnemec> Okay, so we're almost out of time for the meeting.  It seems like we need to start collecting this information in the mailing list thread.
15:59:09 <dhellmann> ++
16:00:51 <bnemec> Okay, it looks like this is the thread:
16:00:54 <bnemec> #link http://lists.openstack.org/pipermail/openstack-dev/2017-December/125791.html
16:01:13 <bnemec> And Josh actually commented on the iterator thing in http://lists.openstack.org/pipermail/openstack-dev/2017-December/125826.html
16:01:45 <bnemec> #action collect details about uncapping networkx in the mailing list thread
16:02:01 <bnemec> And we're out of time.  Thanks for joining everyone.
16:02:04 <bnemec> #endmeeting