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