12:00:41 <dims> #startmeeting requirements
12:00:42 <openstack> Meeting started Wed May 25 12:00:41 2016 UTC and is due to finish in 60 minutes.  The chair is dims. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:43 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:45 <openstack> The meeting name has been set to 'requirements'
12:00:54 <coolsvap> Hello
12:00:56 <number80> o/
12:00:59 <tonyb> o/
12:01:30 <coreycb> o/
12:01:35 <prometheanfire> ugh
12:02:18 <dims> #topic - Any controversies in the Queue?
12:02:21 <dims> #link - https://review.openstack.org/#/q/status:open+project:%255E.*requirements.*+branch:master,n,z
12:03:03 * tonyb has one that's liberty ....
12:03:32 <tonyb> https://review.openstack.org/#/c/317942/
12:03:40 <tonyb> Bump cliff to 2.0.0
12:03:59 <prometheanfire> cliff?
12:03:59 <number80> that's huge for liberty, I agree ...
12:04:00 <coolsvap> #link https://review.openstack.org/#/c/317942/
12:04:01 <prometheanfire> ya
12:04:17 <tonyb> I've dropped my feedback on the review and invited jd__ to this meetiing to help work out how to progress this
12:04:41 <dims> jd__ : around?
12:05:08 <tonyb> The actual change (using cliff 2.0.0) is ok, but it's indicative of a bigger question about how managed and non-managed projects work together
12:05:25 <dims> tonyb : we should just get rid of telemetry project from g-r in liberty just like master
12:05:38 <dims> tonyb : my patience has worn out
12:05:40 <tonyb> dims: that wont help ...
12:06:27 <dims> tonyb : help who? it certainly does not stop us from landing updates to requirements liberty branch
12:06:33 <tonyb> dims: it's happening because ceilometer (liberty) pulls in a bunch of things form master that meet the g-r BUT are not in u-c
12:06:40 <tonyb> IIUC
12:06:45 <dims> tonyb : it's their headache, not ours
12:07:13 <tonyb> hmmm expect there isn't a way to opt out of constarints in dsvm jobs
12:07:17 <dims> tonyb : they should figure out how to live in the infrastructure jobs and not be constrained
12:07:27 <dims> tonyb : yep. not our problem
12:08:12 <dims> tonyb : -2
12:08:19 <prometheanfire> if they don't use UC, then they don't get an opinion
12:08:42 <dims> prometheanfire : yep
12:09:18 <number80> *nods*
12:09:22 <dims> Bunch of oslo libs landed yesterday and the sniff tests looks good - https://review.openstack.org/#/q/status:open+branch:master+topic:dims/test/constraints
12:09:56 <toabctl> hi
12:10:04 <dims> toabctl : hi
12:10:14 <coolsvap> I think we should think about better sync of the proposal bot patches and ones submitted by dhellmann
12:10:18 <tonyb> dims: have any of the u-c bumps landed?
12:10:37 <prometheanfire> coolsvap: ya, I think they should be botted, not under his name
12:10:41 <dims> tonyb : nope. i hold them off so we could run sniff tests
12:10:51 <dims> dhellmann : around?
12:10:56 <coolsvap> prometheanfire, not really that
12:10:57 <prometheanfire> it'd help me note them for what they are
12:11:02 <coolsvap> its mostly duplicate effort
12:11:35 * coolsvap has no problem with name
12:11:41 <prometheanfire> you mean delay a day?
12:11:43 <dims> coolsvap : can you take an action to talk to dhellmann later?
12:11:50 <coolsvap> dims sure
12:11:55 <dims> thanks coolsvap
12:12:29 <dims> #topic Tasks from etherpad
12:12:32 <dims> #link https://etherpad.openstack.org/p/requirements-tasks
12:12:41 <coolsvap> #action coolsvap to talk to dhellmann about the u-c release patches
12:12:46 <dims> has anyone picked up any work from etherpad list of things to do?
12:12:52 <dims> #action coolsvap to talk to dhellmann about the u-c release patches
12:13:27 <dims> coolsvap : was not sure if the bot would pick up your #action, so i triggered it too
12:13:41 <coolsvap> dims, np
12:14:03 <coolsvap> dims, i have done one very very very small task
12:14:12 * coolsvap still figuring out where to start
12:14:59 <dims> coolsvap : ack
12:15:06 <tonyb> coolsvap: I think the 3.9 was a good thing (apart from reviews)
12:15:17 <dims> i guess we did take a stab at cleaning up things from g-r
12:15:52 <tonyb> dims: Yeah a reaonably successful stab I think:)
12:15:56 <dims> coolsvap : go for it - " verifies that the versions listed are available for download from PyPi "
12:16:11 <dims> tonyb :)
12:16:12 <coolsvap> dims, sure i can start with that effort this week
12:16:51 <tonyb> dims: I think that's done with your py27-with-contstraint job isn't it?
12:17:42 <dims> tonyb : don't know if what i have in there is enough
12:17:55 <dims> coolsvap : tonyb : we should add a py34-with-constraints too
12:18:03 <dims> that should be an easy one
12:18:07 <tonyb> dims: ok.  Yeah that's a good point
12:18:51 <dims> #topic pyldap - plans to converge on one ldap client
12:18:54 <dims> #link http://markmail.org/message/7pktmarvrtaos72r
12:19:05 <dims> Any of the packagers have concerns?
12:19:35 <prometheanfire> sec
12:19:37 <prometheanfire> reading
12:20:16 <prometheanfire> no concerns, I thought this was somewhat discussed in the last couple of ldap related patches to -requirements already
12:20:40 <dirk> dims: sort of
12:20:41 <dims> prometheanfire : ack, just making sure folks read that thread if anything is lingering :)
12:20:48 <dims> dirk : you have the floor
12:20:54 <dirk> dims: we have quite some packages that require python-ldap outside openstack and that need to be ported somehow
12:20:58 <dirk> so its not an easy task
12:21:00 <coreycb> dims, hi, I brought that up on the ml
12:21:26 <prometheanfire> ah, here we have both
12:21:38 <dirk> dims: of course openstack shouldn't be slowed down by non-openstack projects, so its more a downstream issue to take care of
12:21:49 <dims> dirk : agree
12:21:51 <dirk> just saying that those are the more interuptive things that got merged fairly quickly (to my surprise)
12:22:06 <number80> well, if it is backward compatible, then no problem to have it in newton (w/ my RDO hat)
12:22:29 <dirk> number80: right. I don't know enough about it to be sure of that
12:22:37 <dirk> the readme says that "as much as possible backwards compatible"
12:22:40 <dirk> which could mean anything
12:22:41 <dims> dirk : until m1 we can be a bit loose as folks are experimenting esp python3
12:23:10 <tonyb> Aren;t they in different namespaces so apart from the issue ubuntu has with main/universe why can't you just have both?
12:23:19 <dims> ok so action item for all of you concerned to continue on coreycb 's ML thread :)
12:23:38 <toabctl> tonyb, python-ldap and pyldap use the same namespace iirc
12:23:55 <tonyb> toabctl: Oh.
12:24:05 <dirk> tonyb: no, they install into the same place
12:24:16 <dirk> dims: agreed
12:24:17 <toabctl> tonyb, pyldap is a fork of python-ldap with py3 support
12:24:24 <coreycb> pyldap is a it's a drop in replacement I believe for python-ldap
12:24:33 <coreycb> w/ py3 support
12:25:00 <prometheanfire> RDEPEND+=" !dev-python/pyldap"
12:25:06 <prometheanfire> RDEPEND+=" !dev-python/python-ldap"
12:25:16 <prometheanfire> we disallow their installation with eachother
12:25:22 <dims> sorry network drop
12:25:35 <prometheanfire> is how we 'fix' it, so something to keep in mind maybe?
12:25:51 <number80> we can't ship both at the same time, and drop-in replacement w/o strong compatibility guarantees mean it could break other stuff
12:26:05 <dirk> number80: right
12:26:23 <dirk> number80: I guess the intention of the project is to be backwards compatible, but as you know, the devil is in the details
12:26:33 <number80> especially w/ ldap
12:26:46 <coreycb> and beyond python-ldap/pyldap, we have ldap3 vs pyldap.  it'd be nice to just converge on one across projects.
12:26:55 <coreycb> nice for me at least :)
12:27:17 <dirk> yep
12:27:25 <number80> I agree that we have to converge and push for a py3 compatible requirement for ldap
12:27:27 <dims> hello
12:27:29 <dims> sorry network dropped
12:27:33 <dims> number80 : ++
12:27:58 <dims> #topic Go
12:28:02 <dims> #link http://markmail.org/message/fsvoxpc7p3jygr6n
12:28:03 <prometheanfire> coreycb: nice for packagers too tbh
12:28:21 <coreycb> prometheanfire, yeah that's my perspective, I do packaging
12:28:28 <prometheanfire> ah
12:28:42 <prometheanfire> as for go, we (gentoo) shouldn't have a problem there either
12:28:43 <dims> If "Go" were allowed, what would we have to do for requirements?
12:29:04 <number80> My feedback about Go is that we need to be careful w/ deps, most go libraries are poorly maintained and have no proper versioning
12:29:14 <dims> what versions of "Go" do folks have?
12:29:21 <prometheanfire> as for reqs... the way I understand go's dep model means we are in for a ride
12:29:22 <dims> number80 : ack
12:29:25 <prometheanfire> number80++
12:29:49 <prometheanfire> gentoo -      Available versions:  1.6-r2(0/1.6) 1.6.1(0/1.6.1) ~1.6.2(0/1.6.2) **9999(0/9999) {gccgo}
12:29:51 <dirk> dims: good question, the go library "packaging" is interesting
12:29:54 <number80> dims: we can push fairly recent versions in CentOS, but lemme check in RHEL
12:30:27 <dirk> dims: we have 1.6.1 on the SUSE side of the universe
12:30:27 <number80> RHEL 7.3 will have 1.6.2
12:30:45 <number80> consensus seems to build around 1.6.x
12:31:43 <dims> does anyone have experience with NOT doing vendoring? (i.e. not keeping local copies of libs used in the repos themselves)
12:32:25 <dims> docker, kubernetes all have copies of the libraries they use
12:32:25 <number80> dims: we do but it's hard
12:32:25 * dhellmann shows up late and reads scrollback
12:32:42 <number80> basically, we ship go libraries as source code
12:32:43 <tonyb> dims: I thought vendoring was the go way
12:33:01 <dims> tonyb : i believe there are alternatives
12:33:05 <prometheanfire> no, that's the way go works as far as I know
12:33:19 <prometheanfire> we (gentoo) do seem to have some unvendoring done though
12:33:19 <dhellmann> dims : the infra team is researching tools that let golang projects manage deps https://etherpad.openstack.org/p/golang-infra-issues-to-solve
12:33:46 <tonyb> #linnk https://etherpad.openstack.org/p/golang-infra-issues-to-solve
12:33:47 <dhellmann> most of them let you point to a specific sha or version or something like that of an upstream dependency
12:34:07 <jroll> well, godep and friends don't force you to check in the vendored code itself, rather a list of deps with shas (like doug said)
12:34:28 <jroll> they pull code into a vendor dir at build time, but it's assumed you would ignore that in git
12:34:44 <dhellmann> ok, that's good, that wasn't actually clear to me from reading
12:34:52 <number80> another go packaging issue => go imports relies on some weird url-based invocations, and many go devs uses url redirector
12:34:55 <dims> tonyb dhellmann : thanks for the pointers
12:35:13 <number80> sometimes, we get the same libraries packaged twice under different names
12:35:49 <dims> number80 : interesting
12:36:02 <number80> we should emphasize that we use the same import for the same library everywhere
12:36:13 <dims> so, do we sign up to maintain a list of SHA(s)? :)
12:36:22 * tonyb needs to read about go and run-time linking ... if that's a thing
12:36:32 <number80> wfm, until we find a better way to support it
12:36:39 <jroll> dhellmann: urgh, maybe I read wrong :( godep themselves vendor their libs https://github.com/tools/godep/tree/master/Godeps/_workspace
12:36:41 <dims> import statements and SHA(s) i guess
12:36:50 * jroll totally read that wrong
12:36:58 <dhellmann> jroll : do what I say, not what I do? ;-)
12:37:07 <jroll> :)
12:37:21 <dims> dhellmann : LOL
12:37:24 <dhellmann> dims : I'm not sure a list of global requirements is necessary for go projects
12:37:36 <dhellmann> they all basically have their own in-tree constraint list, and build a static binary
12:38:10 <dhellmann> someone needs to vet those dependencies for license compatibility, but we don't need a global list for that
12:38:26 <tonyb> It'll be a majpr headache for infra if they endup needing to "mirror" everything in use in any project :(
12:38:39 <prometheanfire> huh, ya, that's true
12:38:43 <dims> dhellmann : less work the better :)
12:38:49 <dhellmann> yeah, infra is addressing the build-related issues
12:38:57 <dims> tonyb : y, i remember mordred talking about mirroring specific SHA(s) we use
12:39:00 <prometheanfire> packaging wise it'll still be a pain though
12:39:25 <number80> oh yeah ...
12:39:28 <dims> just to reduce relying in github etc outside our control
12:39:32 <dhellmann> dims : the "technology divergence" aspect will be harder to control, too, but *shrug*
12:40:14 <dims> ok. i threw this is so folks start thinking :) if at all we end up picking up Go
12:40:20 <dims> #topic Open Discussion
12:40:39 <prometheanfire> can I go back to sleep?
12:40:48 <dims> may i have volunteers to run the next few meetings?
12:40:51 <coolsvap> dhellmann, hi i had the action item but since we have time
12:41:02 <dhellmann> coolsvap : sure, what's up?
12:41:27 <coolsvap> regarding the u-c new-release change requests
12:41:36 * dims looks at dirk tonyb coolsvap and others
12:41:45 <coolsvap> dims i can help
12:41:56 * tonyb looks back ;P
12:42:00 <coolsvap> dhellmann, i think its a duplicate effort
12:42:04 <dhellmann> ok, those patches are coming for a couple of reasons
12:42:17 <dims> tonyb : you are on for next week, coolsvap the one after that. ok?
12:42:18 <prometheanfire> I'll be out next week at least
12:42:26 <dhellmann> (1) we want to test that each new lib works in isolation, so if we see a failure in the tests we know which lib caused it
12:42:33 <tonyb> dims: sure.
12:42:38 <jroll> dhellmann: going back, looks like glide can do what we want
12:42:39 <dhellmann> (2) we do not want to wait 24 hrs for the bot to introduce the new lib into the dev environments
12:42:49 <dims> prometheanfire : cool. we can do 2 weeks at a time :)
12:42:51 <coolsvap> dims ack
12:43:11 <dhellmann> as constraint updates for existing dependencies, they can be approved by a single reviewer under our existing policy
12:43:13 <prometheanfire> lol
12:43:44 <dhellmann> jroll : cool. you might want to talk to the infra folks about the concerns so that input goes into picking a tool
12:43:55 <dims> dhellmann : i have been tending to wait for the morning sniff tests results (https://review.openstack.org/#/q/status:open+branch:master+topic:dims/test/constraints)
12:44:13 <dims> dhellmann : so do we +2A the individual ones or the bulk one?
12:44:17 <dims> or both
12:44:33 <jroll> dhellmann: sure
12:44:47 <dhellmann> dims : these automatically proposed changes replace the ones we asked release liaisons to submit by hand, and are meant to be processed the same way
12:45:19 <notmorgan> o/
12:45:21 <dims> dhellmann : so if you are ok with abandoning the individual ones then we are good
12:45:31 <notmorgan> just woke up, i was pinged in the other channel?
12:45:39 <dims> hey notmorgan we talked a bit about the pyldap a bit
12:45:47 <dhellmann> dims : if we're just going to abandon them, I can change the script to stop submitting them. but then we need another way to ensure that new releases go into the dev environment asap
12:45:56 <notmorgan> anything i need to know?
12:46:11 <tonyb> notmorgan: you're fixing everything :)
12:46:19 <coolsvap> dhellmann, thats what i also wanted to highlight, abandoning is a different thing
12:46:31 <notmorgan> tonyb: oh. uh...
12:46:34 <dims> notmorgan : action item to follow up on ML :)
12:46:37 <dhellmann> coolsvap : yeah, I don't want them to be abandoned, I want them to be approved :-)
12:46:41 <coolsvap> we need a sync between your patches and bot
12:47:03 <dhellmann> coolsvap : I don't understand
12:47:09 <tonyb> or run the bot less often
12:47:12 <coolsvap> or we just allow the bot to submit individual patches
12:47:20 <dhellmann> what problem are we trying to solve?
12:47:35 <coolsvap> dhellmann, we have 2 set of patches submitted
12:47:43 <tonyb> dhellmann: I *think* the thing is that take oslo as an exmaple
12:47:49 <prometheanfire> dims: I think it's having the same thing submitted twice
12:47:50 <dhellmann> ideally the individual patches would all be approved before the bot runs.
12:48:12 <tonyb> dhellmann: if we land a few (any?) of yhe new-rlease changes the bot's change will fail to merge
12:48:14 <dhellmann> is that's not realistic, we might as well wait for the bot
12:48:16 <coolsvap> prometheanfire, yes
12:48:34 <dhellmann> tonyb : ok, now I get that there are merge conflicts
12:48:48 <notmorgan> dims: ok i'm going back to sleep then.
12:48:49 <coolsvap> dhellmann, the individual patches and bot patch confligts
12:48:53 <dhellmann> ok, I'll change the script to not submit the individual patches and we'll just rely on the bot to update things
12:49:21 <dims> coolsvap : maybe the bot checks what was filed and throws a "Depends-On" those in addition to things that were not filed?
12:49:26 <tonyb> So I *like* the new-release changes
12:49:31 <dims> dhellmann : currently the bot proposes an update as it sees versions in pypi, it does not check what reviews are currently filed under "new-release" topic
12:49:44 <dhellmann> yeah, I don't think we need to make the bot a lot smarter
12:49:45 <dims> dhellmann : so if we make sure that the bot proposed update does not duplicate the ones in progress, that would work
12:49:49 <coolsvap> dims, can be done this way
12:49:50 <tonyb> they have meta-data which makes the review much easier than the bot generated one IMO
12:50:00 <coolsvap> what i feel is checking individual changes is good
12:50:22 <coolsvap> it helps isolate issue to single package update
12:50:28 <dims> coolsvap : maybe the bot checks what was filed and throws a "Depends-On" those in addition to things that were not filed?
12:50:28 <dims> dhellmann : currently the bot proposes an update as it sees versions in pypi, it does not check what reviews are currently filed under "new-release" topic
12:50:34 <dims> dhellmann : so if we make sure that the bot proposed update does not duplicate the ones in progress, that would work
12:50:58 <coolsvap> dims, if the bot can propose individual changes
12:51:02 <coolsvap> dhellmann, ^^
12:51:05 <prometheanfire> that's what I'd like to see as well, I like the new way
12:51:09 <dhellmann> if we're only doing bulk releases like this early in the week, how many bot updates are actually in conflict?
12:51:35 <dhellmann> we can't have the bot propose individual changes, that doesn't make sense. It's updating everything all at once. Some updates may depend on others.
12:51:59 <tonyb> and if it does conflict wont it just regenerate in 24hours?
12:52:10 <dhellmann> it will
12:52:30 <tonyb> right so I think that we shoudl stick with what we have now
12:52:46 <dims> i am ok with what we have now
12:52:53 <tonyb> focus on getting the new-rleases changes in *early* and see if the bot thing causes major pain
12:53:09 <tonyb> the new-release stuff is pretty new and IMO helpful
12:53:21 <coolsvap> so we approve the individual patches and let bot regenerate changes in 24 hrs
12:53:22 <tonyb> that's just my $0.02
12:53:35 <tonyb> coolsvap: that's my suggestion
12:53:46 <prometheanfire> we could get into a loop where the bot's always behind though
12:54:05 <dims> coolsvap : i think we should wait for sniff tests then let individual ones in and merge the bot update last in the day
12:54:08 <tonyb> prometheanfire: if that happens we can manually sync up
12:54:12 <dhellmann> we won't, though, because we don't do releases on thurs/fri so we have several opportunities for a monday bot update to be good
12:54:18 <dims> (before the next regeneration)
12:54:35 <tonyb> dhellmann: ... and merged :)
12:54:38 <dhellmann> and I'm trying not to do bulk releases like oslo too late in the week too often
12:54:48 <dims> ++ dhellmann
12:54:54 <coolsvap> dims, dhellmann tonyb i am fine with testing this strategy
12:54:58 <prometheanfire> ya, oslo...
12:55:12 <dhellmann> good, let's give it a couple of weeks and then see how it goes?
12:55:21 <dhellmann> I have to run, sorry, local interruption
12:55:34 <tonyb> dhellmann: o/
12:55:44 <prometheanfire> ya, meeting is almost over
12:56:04 <dims> anything else? we can talk over on our channel :)
12:56:09 <dims> thanks everyone
12:56:11 <dims> #endmeeting