20:30:11 <prometheanfire> #startmeeting requirements
20:30:12 <tonyb> dhellmann: +2+W
20:30:12 <openstack> Meeting started Wed Jun 27 20:30:11 2018 UTC and is due to finish in 60 minutes.  The chair is prometheanfire. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:30:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:30:15 <openstack> The meeting name has been set to 'requirements'
20:30:18 <prometheanfire> #topic rollcall
20:30:21 <prometheanfire> tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann
20:30:24 <prometheanfire> o/
20:30:26 <dhellmann> o/
20:31:32 <smcginnis> o/
20:31:45 <prometheanfire> #topic Any controversies in the Queue?
20:32:21 <smcginnis> We still have issues with networkx and the google API packages.
20:32:50 <prometheanfire> ya, I forget what was with the google-api packages
20:33:03 <prometheanfire> what was breaking from it (do you remember)?
20:33:15 <prometheanfire> networkx, kevko is helping, which is awesome
20:33:30 <smcginnis> The google one was something to do with package renames or something along those lines.
20:33:39 <prometheanfire> I'm in a constant wait state on these pycrypto reviews     https://review.openstack.org/#/c/575199/ https://review.openstack.org/#/c/575163/
20:33:52 <smcginnis> I think Gorka said he would take a look into it, but I know he's pretty busy.
20:33:57 <prometheanfire> smcginnis: oh, that's fun, but if it's just renames it's not so bad
20:34:18 <smcginnis> We may just need to keep it capped until we can deprecate and remove that backup driver if no one can step up to maintain it.
20:34:38 <smcginnis> There may be more to it than just a rename. I'm not really sure of the specifics.
20:34:44 <prometheanfire> ya
20:35:09 <smcginnis> But history is Google paid a consultant to add the driver, then was never seen from again.
20:35:32 <dhellmann> driver where?
20:35:32 <prometheanfire> lol, remove it, if they don't want to maintain it then too bad
20:35:54 <smcginnis> dhellmann: The only consumer of the Google API package in question that I know of is for a Cinder backup driver.
20:35:58 <dhellmann> ok
20:36:22 <prometheanfire> ya, I thought that was being looked at for review as well
20:37:15 <prometheanfire> review meaning possible removal
20:37:19 <smcginnis> I should poke jungleboyj on that and see what he would like to do.
20:37:47 <prometheanfire> yarp
20:37:50 <smcginnis> The only down side is I think there may be users of that driver, but we are otherwise pretty strict about our other driver types, so backup shouldn't be any different.
20:37:59 <prometheanfire> anything else?
20:38:52 <dhellmann> nothing from me
20:38:53 <tbarron> hi
20:39:29 <prometheanfire> tbarron: yo
20:39:36 <tbarron> are you already on open discussion?
20:39:42 * tbarron came in late
20:39:49 <prometheanfire> dhellmann: smcginnis what do you think should be done about getting reviews for https://review.openstack.org/#/c/575199/ https://review.openstack.org/#/c/575163/ ?
20:39:52 <prometheanfire> tbarron: soon
20:40:09 * tbarron goes back to fly-on-wall
20:40:23 <dhellmann> prometheanfire : have you talked to the PTL?
20:41:03 <dhellmann> I guess I should say, what have you already tried?
20:41:27 <smcginnis> Last I heard the team was small, so it may just take some time to get reviews.
20:41:41 <prometheanfire> dhellmann: mainly tried their channel and ML
20:41:59 <prometheanfire> I could try adding their ptl to the reviews and/or emailing them directly
20:42:08 <dhellmann> I would try emailing the PTL directly next
20:42:26 <prometheanfire> k
20:42:28 <prometheanfire> I'll do that
20:42:41 <dhellmann> as smcginnis says, it may take some time to get a review, but at least that way you may get a response about what's going on with the team
20:42:53 <smcginnis> ++
20:42:55 <prometheanfire> yep
20:43:02 <prometheanfire> ok, anything else before open floor?
20:43:14 <smcginnis> nope
20:43:28 <prometheanfire> #topic open floor
20:43:59 <tbarron> I was recently attempting a stable/pike backport issue in manila and
20:44:12 <tbarron> hit a devstack issue building libvirt-python
20:44:30 <tbarron> there's an incompatability with the libvirt in the version of CentOS that
20:44:32 <tbarron> is used
20:44:58 <tbarron> probably the OS gets updated (with libvirt) after stable requirements are known to work and fixed
20:45:06 <tbarron> so that then incompatabilities come in
20:45:18 <tbarron> anyways, raised https://bugs.launchpad.net/manila/+bug/1778971
20:45:18 <openstack> Launchpad bug 1778971 in OpenStack Global Requirements "stable/pike libvirt / python-libvirt incompatability" [Undecided,New]
20:45:41 <tbarron> this is of course more of an issue with long term releases
20:45:59 <tbarron> impacting need to maintain stable/* longer
20:46:07 <prometheanfire> tbarron: yep, we've seen this before iirc
20:46:11 <tbarron> that's it
20:46:33 <prometheanfire> tonyb: do you remember if we've had to update libvirt for stable branches, I think it's come up before and we've updated it
20:46:57 <smcginnis> This all seemed very familiar to me too, but couldn't remember any details.
20:47:01 <smcginnis> rev
20:47:06 <smcginnis> oops
20:47:17 <prometheanfire> :D
20:49:08 <tbarron> well I dunno if it happened on stable/* but it looks like ubuntu had a similar issue with libvirt and libvirt-python:
20:49:15 <prometheanfire> tbarron: I think we can update it, especially if it's breaking gate (centos gate in this case iirc).  I'd like to confirm that we've done it before (and think that we have) but I hope to have a final plan by next week/meeting
20:49:34 <tbarron> https://bugs.launchpad.net/devstack/+bug/1636567
20:49:36 <smcginnis> I see other attemptes: https://review.openstack.org/#/q/project:openstack/requirements+message:libvirt
20:49:37 <openstack> Launchpad bug 1636567 in openstack-ansible "devstack mitaka installation fails with error "Running setup.py bdist_wheel for libvirt-python: finished with status 'error'" in Ubuntu 16.10" [High,Fix released] - Assigned to Jesse Pretorius (jesse-pretorius)
20:50:31 <tbarron> prometheanfire: thanks, it's fine with me for upstream requirements to proceed deliberately, i've
20:50:31 <smcginnis> But I agree, for a supported stable release on it's tested platform, we should allow raising it since that platform apparently has.
20:51:01 <tonyb> prometheanfire: sorry we've never done this thing to my recollection
20:51:28 <tbarron> had to go on and propose the backport downstream to relieve some customer pain but I'm referencing the upstream (-1 workflow) review so that it will all eventually be consistent
20:51:44 <smcginnis> It seems past attempts to do this usually ended up with the stables branch no longer being supported.
20:52:02 <prometheanfire> smcginnis: heh, that's true
20:52:14 <prometheanfire> but now that we are going longer on LTS we don't have that to 'fall back on'
20:52:18 <dhellmann> we should only need to update the constraint, right?
20:52:27 <prometheanfire> yes
20:52:41 <dhellmann> why is that a problem?
20:52:59 <prometheanfire> I'm sure there's some libvirt sec bug we can use as an excuse to update it if we really want to stay in policy
20:53:20 <dhellmann> is libvirt special? or are we saying we don't update any constraints other than our own releases?
20:53:59 <dhellmann> because if we're going to encourage extended maintenance branches we're likely going to need to allow constraint updates like this, right?
20:53:59 <prometheanfire> we don't update other than our own releases
20:54:21 <dhellmann> hmm. ok. I thought we didn't update the others automatically. I didn't realize we never updated them at all.
20:54:32 <tbarron> one somewhat weird thing is that the constraint for stable/queens is libvirt-python>=3.5.0,!=4.1.0 and 3.10.0 (which works) is selected whereas
20:55:25 <tbarron> for stable/pike we have 'libvirt-python>=1.2.5' and libvirt-python===3.5.0 is selected
20:55:39 <dhellmann> I would expect an older version in an older branch
20:55:46 <prometheanfire> tbarron: it's just what libvirt was frozen at when we cut the release
20:55:51 <dhellmann> right
20:55:52 <tbarron> all possible given the constraints, but 3.5.0 would be legal in stable/queens in which case that would break too
20:56:04 <prometheanfire> I sent the freezer ptl email btw
20:56:13 <dhellmann> we don't update the requirements settings, but we should be able to accept changes to the constraints list
20:56:30 <prometheanfire> tbarron: queens didn't have lower constraint testing (testing the lower-bounds)
20:56:41 <tbarron> prometheanfire: ack
20:57:05 <dhellmann> can someone remind me why we freeze the constraints like that?
20:57:10 <tbarron> i'm just saying that it's somewhat accidental that stable/queens isn't also broken
20:57:11 <prometheanfire> dhellmann: ya, we may have to call it out as valid, but with *reasons* we can update
20:57:43 <dhellmann> prometheanfire : I don't understand why we are so strict in the first place. I understand why we don't take bot changes. I don't understand why we don't take human-proposed changes.
20:57:51 <tonyb> dhellmann: IIRC there is also a need to bump the minimum but I'm hazy on that
20:58:07 <prometheanfire> dhellmann: history
20:58:13 <tonyb> dhellmann: if it were just the constraint then I don't know that we'd be having this discussion
20:58:31 <dhellmann> prometheanfire : I think you're following rules that I didn't envision when we set up this team, so I'm just trying to understand what changed between then and now.
20:58:35 <prometheanfire> tonyb: you may be right, if the min doesn't work we'd need to change the min, if we change the min, that'd have to propigate out and cause knock-on releases
20:59:01 <prometheanfire> tonyb: dhellmann I'm fine with just the constraint
20:59:13 * prometheanfire thinks we are talking past eachother
20:59:39 <dhellmann> maybe
21:00:20 <smcginnis> I thought the history was newere outside libs could introduce problems, making stable releases not so stable.
21:00:21 <tonyb> dhellmann: constraints are frozen just because lots broke when we updated them we introduce bugs
21:00:27 <dhellmann> IIRC, we lock the requirements down because changing those implies incompatible updates and propagates requirements that distros update their packages. We do allow changes to the constraints because that's just our list of what we test with.
21:01:00 <prometheanfire> tonyb: dhellmann our process allows it already https://docs.openstack.org/project-team-guide/dependency-management.html#stable-branch-maintenance
21:01:14 <dhellmann> We don't let the *bot* make wholesale constraint changes because we don't want to keep up with that. We should allow people to propose individual (or small sets of) updates to make the CI system keep working.
21:01:23 <tonyb> prometheanfire: Sure I think I'm just confused due to multitasking
21:01:28 <dhellmann> ok
21:01:31 <prometheanfire> dhellmann: which is the policy
21:01:35 <prometheanfire> we all violently agree :P
21:01:38 <dhellmann> woo!
21:01:53 <tonyb> dhellmann: Oh yeah if $person wants to bump a constraint on a stable branch hat's fine
21:01:58 <smcginnis> Yeah, this appears totally fine within the rules described by that first bullet.
21:02:09 <prometheanfire> tbarron: what version did we need? 3.10.0?
21:02:10 <dhellmann> ok, I thought that's what was happening here, so I was confused about why it needed to be discussed. :-)
21:02:29 <prometheanfire> dhellmann: /me shrugs
21:02:34 <tbarron> prometheanfire: that's what I see working in stable/queens, just empirical
21:02:49 <tbarron> prometheanfire: with the same CentOS image and same libvirt package
21:03:41 <prometheanfire> tbarron: you want to propose that or want us to?  it'd need reasoning in the commit message
21:04:02 <tbarron> prometheanfire: I'd actually like someone experienced to do it and add me to the review so I can learn
21:04:02 <tonyb> There was some concern about bumping a major version (or 2) but libvirt doesn't semver so meh
21:04:25 <prometheanfire> tonyb: indeed
21:04:25 <tbarron> I'll be happy to help out with such stuff going forwards.
21:04:27 <prometheanfire> ok, I'll propose
21:04:33 <prometheanfire> anything else before I close this out?
21:05:00 <tonyb> nope
21:05:32 <tbarron> thanks folks
21:06:51 <prometheanfire> #endmeeting