15:00:43 #startmeeting puppet-openstack 15:00:43 Meeting started Tue Mar 22 15:00:43 2016 UTC and is due to finish in 60 minutes. The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:46 The meeting name has been set to 'puppet_openstack' 15:00:47 hi 15:00:51 #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160322 15:00:51 hey EmilienM :-) 15:00:52 o/ 15:00:54 o/ 15:00:54 o/ 15:00:57 hi 15:00:58 o/ 15:01:15 o/ 15:01:17 hi 15:02:02 #topic Review past actions items 15:02:13 mfisch to create openstack_extras::repo::tesora 15:02:19 <_ody> o/ 15:02:19 mfisch: should we postpone it? 15:02:19 hey 15:02:36 yes this is like a "sometime this year" activity, I just wanted to get opinions 15:02:54 ah cool 15:03:10 chem move normalize_ip_for_uri to puppetlabs-stdlib and support array <- done by EmilienM in puppet-stdlib 15:03:25 I don't think stdlib got a release recently, so we still need to use openstacklib 15:03:37 https://github.com/puppetlabs/puppetlabs-stdlib/releases 15:03:47 hum .... so we should backport this one 15:03:54 Hunner, _ody: do you guys know if stdlib plan to release soon? 15:04:04 chem: backport what? 15:04:16 and where? 15:04:25 <_ody> EmilienM: I'll find out. I do know the release schedule off the top of my head. 15:04:37 EmilienM: the patch you've included in stdlib foripv6 (I'm looking) 15:04:43 _ody: cool, thanks! not really urgent, just a nice to have 15:04:55 chem: we'll likely do it in Newton 15:05:04 but no backport I think 15:05:22 EmilienM to write release notes with reno for our modules -> DONE 15:05:30 EmilienM to follow-up on ML about reno & releases -> postponed after release 15:05:45 EmilienM: so I'm talking about https://github.com/puppetlabs/puppetlabs-stdlib/commit/0378336f9cefea65675d03f1d7107c75cb950fb6 15:05:55 EmilienM: in openstack_lib 15:06:14 puppet-openstacklib 15:06:20 chem: right, once stdlib got a release in Puppetlabs, we'll update openstacklib in Newton 15:06:34 but I don't see a need of backporting it to mitaka 15:07:16 we'll need to update metadata.json in puppet-nova and puppet-glance, maybe more and our Puppetfile in openstack-integration 15:07:34 EmilienM: oki, so we keep normalize_ip_for_uri but I should change the interface to have array as well 15:07:48 EmilienM: to ease the transition afterward 15:08:03 chem: yeah, if you plan to fix it, please patch both repos 15:08:15 so we ensure a good transition 15:08:20 stdlib one is supporting array already 15:08:29 sorry nope ... 15:08:52 chem: let's catchup later 15:08:54 ack 15:09:09 #action EmilienM & chem work on normalize_ip_for_uri function 15:09:24 #topic Austin Summit 15:09:34 #link austin summit etherpad https://etherpad.openstack.org/p/newton-design-puppet 15:10:13 I started this etherpad, please add your name if you plan to attend it 15:10:22 I also initiated 3 topics, but feel free to add more 15:10:35 it can be blueprints, discussions, etc. It's really open 15:11:03 is someone interested to lead Community session? we have half-day for that 15:11:19 I remember Puppetlabs helping in the past 15:12:01 something like that 15:12:24 <_ody> happy to lead something if slots are needed 15:12:47 _ody: great, we can use this etherpad to gather topics from our community 15:12:54 _ody: the audience is usually more users/operators 15:13:05 _ody: so you might want to start a thread on operators mailing list 15:13:45 I would be happy to see operators coming and ask for features, reporting issues or just asking for informations 15:13:57 _ody: we can follow-up on that together if you want 15:14:47 any questions about summit or feedback? 15:14:54 <_ody> Sounds good. 15:14:57 great 15:15:18 #action _ody to initiate email on operators mailing list about Austin summit 15:15:28 #topic release status 15:15:55 so I finished the release notes last week, thanks a lot to degorenko and mwhahaha (+ others) for their reviews 15:16:02 this week I'm doing branching 15:16:27 I already released puppet-openstack_spec_helper 15:16:43 today I'm trying to release puppet-aodh so this week I can continue with other modules 15:16:59 we bumped our CI today, to latest Mitaka, and all runs fine 15:17:17 +1 15:17:26 so we should release Mitaka the same day as other projects 15:17:34 if nothing breaks in the meantime :-) 15:17:37 great :) 15:17:40 thats pretty awesome, we've never done that before 15:17:52 I've 2 things to mention : 15:18:20 1/ please do not merge critical patches this week and if any doubt, please ask on irc 15:18:25 :) 15:18:50 2/ to core reviewers and others: please use release notes when you can. I told it to mfisch for his recent patches but we need to spread the word 15:19:11 I won't -1 someone who miss it but gently let a comment for next time 15:19:26 openstack/nova is doing a great job at it 15:19:49 and I think release notes will really help our operators, specially when they upgrade 15:19:59 I think the relnotes are a good idea 15:20:04 the error messages from jenkins suck however 15:20:11 <_ody> I'd actually prefer a -1. It is a new habit and I pay attention most to -1 and prodding in IRC. 15:20:15 that's true, sphinx is not helping 15:20:24 I'm okay with -1 for no relnotes 15:20:30 _ody: I would like educational -1 15:20:43 we don't want to frustrate our contributors 15:21:05 but rather help them to write better patches 15:21:05 <_ody> Core -1 core? 15:21:12 I would -1 a core 15:21:12 well the cores could help them write the notes or point at examples? 15:21:17 is it documented somewhere? the link could help 15:21:17 but I won't -1 someone not core 15:21:33 #link help about reno http://docs.openstack.org/developer/reno/usage.html 15:21:39 thanks 15:21:51 do we agree on -1 each others (between core) if reno is missing? 15:22:03 +1 15:22:08 and not -1 contribors not core, so we don't frustrate them, and rather educate them 15:22:14 sure 15:22:43 <_ody> Yeah. 15:22:45 cool 15:22:56 I'll send an email this week about it 15:23:14 #action EmilienM to send email about release notes (postponed action from last week) 15:23:35 any question/feedback about mitaka release? 15:24:03 #topic Prefecting user and user_roles resources with domain-specific 15:24:09 degorenko, chem: o/ 15:24:30 hey :) 15:24:34 well this problem has been recurring since age and I think we should tackle it onec and for all 15:24:44 +1 15:25:21 this consist in disabling prefetching in user and keystone_user_role 15:25:32 as it seems the best course of action 15:25:44 I'd like to also point out the performance issue / failures when using prefetch with a LDAP provider that may have thousands or tens of thousands of users 15:25:45 and using some kind of caching for keystone_user_role 15:25:55 disabling prefetching and moving this functionaly to exists? for example 15:26:05 functionality* 15:26:13 yep, that seems like the only way to support ldap AD 15:26:37 and other ldap's besides AD 15:26:50 at least AD supports paging, I just found out some dont 15:27:03 yeah, from exists? we can use all passed to provider properties (including specified domain) 15:27:25 from exists we query only one specific user 15:27:41 if it exists 15:27:47 so no problem, and we use caching to avoid too many queries 15:28:15 yes, and cache data will be updated on create/destroy/update actions 15:28:34 the patch would be two things: setup an ldap server in the beaker test and add the necessary code 15:29:34 <_ody> Skipping beaker and going directly to puppet-openstack-integration scenarios is probably find too. 15:29:35 I can throw in a first review for it before next week and see from there 15:29:41 which module? https://github.com/puppetlabs/puppetlabs-ldap ? 15:30:07 https://github.com/camptocamp/puppet-openldap sounds better 15:30:29 not sure which one, didn't review any yet 15:30:32 ok 15:30:34 <_ody> puppetlabs-ldap is only client, not required for keystone. 15:30:59 i'm not sure why we need to test ldap on beaker, we can easily create two testing domains and that's it 15:31:11 I suggest we first fix the case where ldap is not run 15:31:12 degorenko: right 15:31:27 we can add ldap later, in the next iteration 15:31:31 oki 15:31:52 thats what I was thinking 15:32:03 +1 for ldap in next iteration 15:32:14 just that this "failing test" is recurring as well and I though two birds with one stone, but you're rigth, let's not mix them 15:32:42 you can create additional domain in beaker and then create user for them 15:33:04 and i guess, will be better, if user for additional domain will be present in default domain 15:33:10 degorenko: yes, let's do it 15:33:16 in such way we will be sure that everything works fine 15:33:25 and after that: ldap 15:33:34 :) 15:33:38 degorenko: we already have multiple domain but same backend, no ? 15:33:40 we could have beaker coverage, as usual but also scenario00X testing ldap too 15:33:56 chem, i thought yes 15:34:14 so multiple domaind and mulitple backend is the thing to add 15:34:15 our mfisch third party CI will be very happy to see ldap testing in our scenarios :-P 15:34:38 can we add another mysql backend ? 15:35:03 we can add just another backend 15:35:08 * Hunner is late. I'll get a stdlib release scheduled 15:35:31 Hunner: please ping me when it's done so we update our modules 15:35:50 If it's not ldap it's sql, so we have to have "two backends" in one mysql ? 15:36:16 it sounds very tricky 15:36:31 anyway let's continue this discussion in #puppet-openstack :) 15:36:33 hm, yes, sounds tricky 15:37:03 ldap :) 15:37:23 ok 15:37:27 EmilienM: lol 15:37:34 (not that I'm found of it , hé ) 15:37:42 #action degorenko / chem to follow-up domain-specific testing with multi backends 15:37:43 you could do 2 mysql backends 15:37:59 on one mysql instance ? 15:38:27 the support is for only one mysql i think 15:39:01 I think test shouldn't be corner use case ... let's use the "normal" use case 15:39:39 maybe we can fix https://bugs.launchpad.net/puppet-keystone/+bug/1554555 first 15:39:40 Launchpad bug 1554555 in puppet-keystone "openstack cli provider needs to pass domain in v3 calls" [Undecided,In progress] - Assigned to Matthew J Black (mjblack) 15:40:01 and look at testing afterwards? 15:40:18 sounds reasonable 15:40:27 I'm not sure having multiple mysql backends is what we want, but I might be wrong 15:40:58 can we follow-up later? 15:41:01 yep 15:41:08 #topic Backports to stable/mitaka branch 15:41:11 iberezovskiy: o/ 15:41:14 hey 15:41:23 so we should get stable/mitaka branches soon and I wannt to clarify several realted questions. 15:41:27 first one is: what's actual criteria for backporting patches to stable/mitaka? 15:41:31 e.g. if patch is fixing a bug, what priority should have a bug to be allowed for backport? 15:41:48 until now, we never had strong criteria 15:42:02 we use to backport bugfixes all the time 15:42:38 for features, it depends, if you don't touch break backward compatibility, that should be fine 15:42:42 and what about patches like this https://review.openstack.org/#/c/293524/ (just an example) 15:42:44 also CI needs to pass 15:42:48 It supports Mitaka functionaltiy. the patches like this are really important but it's huge enough :) how should we deal with them? 15:43:00 this one is huge 15:43:11 it's an experimental thing in Glance 15:43:11 yep, but it's important for Mitaka 15:43:19 there is nothing backward incompatible 15:43:25 just fyi :D 15:43:29 but looking at it, it does not break anything in existing manifests 15:43:55 this is new things so yeah, why not 15:44:08 so, one of the *requirements* is do not break backward compatibility? 15:44:12 in case of glare, as long functional tests pass, that's ok 15:44:28 cool, I don't expect new patches like this 15:44:33 but who knows :) 15:44:33 iberezovskiy: yeah, stable branches need to stay stable, so no interface change, etc 15:44:40 for glare we just need fixed openstack-glance package in RDO :) it's akready fixed, waiting for reop 15:44:43 repo* 15:44:56 degorenko: do we need to promote again? 15:45:10 EmilienM, hm, i don't now actually 15:45:10 degorenko: i'll take care of it 15:45:23 EmilienM, here is commit https://github.com/openstack-packages/glance/commit/e12615dc970760ed9ecd8b2455673139648b7beb 15:45:25 #action EmilienM to promote RDO repos to have Glance Glare fixed 15:45:32 degorenko: will do today 15:45:32 it's about ~6 hours ago 15:45:38 thanks a lot :) 15:45:46 yeah? we promoted today already 15:45:57 degorenko: I rebased your patch 15:46:00 to see if it pass now 15:46:00 sooo, i can recheck \o/ 15:46:06 #undo 15:46:06 ok, good :) 15:46:07 Removing item from minutes: 15:46:27 maybe we need more documentation about backports 15:46:39 I'll create a wiki page and anyone in our group will be able to contribute 15:46:46 good idea 15:46:55 i guess, also we need coordinate with rdo team for such changes. I found similar bug yesterday, but they didn't add me review :( and i found one more bug today, with same error :D 15:46:57 #action EmilienM to create Wiki page for Puppet backports 15:47:24 #topic Puppet4 15:47:27 thanks, it'll be really useful 15:47:29 _ody: o/ 15:47:51 _ody wrote me in PM, he's afk now. so I'll update from what I know 15:48:15 <_ody> I am back for a moment. I'll need to step away soon. 15:48:21 #link puppet4 patches https://review.openstack.org/#/q/status:open+branch:master+topic:puppet4 15:48:32 we might want to land https://review.openstack.org/#/c/294838/ 15:48:50 so we don't have to rebase patches that aim to fix puppet4 stuffs 15:49:06 _ody is currently working on fixing puppet-nova for puppet4: https://review.openstack.org/#/c/294841/ 15:49:17 _ody: do we have more blockers for puppet4? 15:49:22 <_ody> Thank you mjblack for catching other module issues on puppet4 15:49:44 and another blocker for puppet-keystone: https://review.openstack.org/#/c/293551/ 15:49:54 are we aware about more issues? 15:50:17 I'll kick of a CI run with both patches this week and continue the debug 15:50:32 _ody: np, just reporting back issues that I see :) 15:50:36 _ody: if you know more, please let us know and kick off patches in Gerrit so we know 15:50:49 <_ody> Catalog run order and containment changed in puppet 4, I am going through puppet-openstack-integration scenarios one by one to identify the issues. 15:51:16 mhh 15:51:24 that's very tough for backward compatibility 15:51:47 <_ody> It just means we have to be very strict about various dependencies. 15:52:00 <_ody> Default run order changed it all, relationships still work the same. 15:52:46 Does that mean explicit ordering? 15:53:07 Class[things1] -> Class[thing2] etc? 15:53:11 <_ody> bkero: It means explicit ordering is more important because we are supporting both Puppet 3 and 4. 15:53:13 _ody: can we list blockers here ? https://etherpad.openstack.org/p/puppet4 15:53:31 <_ody> Sure. 15:53:41 <_ody> Ok. Need to help kid again. afk. 15:54:05 #link puppet4 blockers https://etherpad.openstack.org/p/puppet4 15:54:09 _ody: cool. 15:54:34 #topic Open Discussion, Bug and Review triage (submit modules to triage here) 15:54:53 we have 5 min, so please go ahead if you have any feedback/question/bug/review/joke to share 15:56:33 I'll close the meeting in 30s if nothing comes up :-) 15:57:22 have a good week folks! 15:57:25 #endmeeting