15:00:03 #startmeeting puppet-openstack 15:00:05 Meeting started Tue Apr 12 15:00:03 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:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:08 The meeting name has been set to 'puppet_openstack' 15:00:11 #link agenda https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20160412 15:00:13 o/ 15:00:14 o/ 15:00:15 o/ 15:00:17 hi 15:00:24 yo 15:00:29 hi2u 15:00:35 hi 15:00:46 hi 15:00:52 <_ody> o/ 15:01:04 \o/ 15:01:08 #topic Review past actions items 15:01:15 EmilienM & chem work on normalize_ip_for_uri function (postponed again) 15:01:28 EmilienM needs investigation about kilo support in our modules (postponed again) 15:01:53 regarding the last topic ^ I'm waiting for the Summit and see how it goes with release management 15:02:16 ok, let's start the meeting, we have 2 items and then open discussion 15:02:25 #topic CI status 15:02:45 an update about what is going on currently: 15:02:58 _ody and I are trying to deploy integration jobs with Puppet4 15:03:23 see https://review.openstack.org/#/c/296557/ and https://review.openstack.org/#/c/304571/3 for ongoing work 15:03:26 <_ody> They were green a week ago. We are working around a nodepool image issue now with locales being missing. 15:03:46 excellent 15:04:13 on my side, I'm working on some SElinux improvmments, to accelerate debug when we have SElinux alerts 15:04:30 some work here: https://review.openstack.org/304614 https://review.openstack.org/304345 and https://review.openstack.org/304338 15:04:53 yesterday, on IRC we discussed about huge console logs 15:05:08 yeah, hiera debug is useless 15:05:11 sometimes 8MB, which does not help to debug quickly 15:05:22 I submitted https://review.openstack.org/304331 to use -vt instead of --debug with puppet CLi 15:05:31 we should also add some headers to our test scripts so we can see what's upstream infra crud and what's our tests 15:05:40 I'm not sure -vt will bring enough feedback, when having bugs with providers & Exec. Any suggestion is welcome 15:05:41 hello 15:05:54 I would like to keep debug for puppet and remove hiera debug, is that possible ? 15:06:01 mwhahaha: like the services that we run? 15:06:06 is there something we where if we have those problems we could just raise the level for debuging? 15:06:14 chem: not possible. puppet overrides the log level in hiera 15:06:15 mwhahaha: ex: this job deploys nova/cinder/neutron, etc 15:06:17 o/ 15:06:29 EmilienM: also as a separator so we know where each test part is 15:06:42 then verbose for puppet is not that usefull ... 15:06:58 mwhahaha: can you send a PoC when you have time? 15:07:01 yea 15:07:13 maybe we can wrap the stuff around a script that remove hiera debug ? 15:07:33 I tested with -vt and logs file now take 800 kb, which is 10 times better 15:07:48 something like we use for fuel ci would be nice, https://ci.fuel-infra.org/job/master.fuel-library.pkgs.ubuntu.neutron_vlan_ha/8498/console 15:07:53 (and could we add color output, the bash code are there and jenkins can do it) 15:07:57 where we have like postbuild/cleanup/summary etc 15:08:14 -vt should show enough for most debugging problems 15:08:36 the providers would need debug but that's why i asked about being able to do something in a review to raise the level 15:08:40 mwhahaha: what should I see in fuel log? 15:09:04 mwhahaha: those are wayyyy nicer log, and you don't need 8Mb of web page download to see it +100 15:09:20 (and maybe color ...) 15:09:43 https://usercontent.irccloud-cdn.com/file/5OtQR9m2/Screen%20Shot%202016-04-12%20at%209.09.20%20AM.png 15:10:04 yeah, that would be awesome 15:10:06 some section headers 15:10:12 that's all, i'll work on a PoC 15:10:16 nice 15:10:31 so should we use -vt? 15:10:53 IMHO we should switch to -vt for now and selectively raise if necessary 15:10:55 I say yes, but we remove useless hiera debug by some mean 15:11:11 sorry no : I want debug. 15:11:19 hiera debug? 15:11:25 chem: puppet I guess 15:11:31 remove hiera debug, keep puppet debug 15:11:33 if its just the hiera debug, why not grep -v it? 15:11:55 mjblack: there are a lot of things to grep -v, not just one 15:12:03 sounds like we need to investigate more options 15:12:06 I tried last night and I had like 4 or 5 potiential occurences 15:12:20 ^ correct, let's grep out useless stuff 15:12:32 #action mwhahaha to propose a PoC in puppet-openstack-intragation to have section headers in console 15:12:36 EmilienM: I know but we can make the grep -v value a regex and add to it as needed 15:12:42 mjblack: right 15:12:51 who can/want to work on it? 15:12:56 mwhahaha: another nice thing to have are the /tmp/puppet_apply_*.pp manifest in the saved file 15:13:18 EmilienM: I'll take it on 15:13:20 well those are just sections from the acceptance tests 15:13:27 but we could probably grab them 15:13:51 #action mjblack to propose a PoC in puppet-openstack-intragation to filter Hiera debug and keep only Puppet debug 15:13:52 well it's better than having go back to the code, IMHO 15:14:08 chem: +1 15:14:26 +1 15:14:30 chem: you want fixtures manifest? 15:15:07 EmilienM: yes, as retrieving the exact rspec is sometime not that easy, so we can just go and look at the exact manifest in the logs directory 15:15:42 (we fetch the /tmp/puppet_apply_.pp and then open it, that's it, that's all) 15:15:49 mhh ok 15:15:54 yes, otherwise, I have to load run the baker test to get them 15:16:09 but that's for beaker, right? 15:16:13 right 15:16:32 oh right then! +1 15:16:50 I can take care of this, even If I don't know where to begin :) 15:16:50 chem: you take it? 15:16:58 yep 15:17:19 #action chem to investigate how to show puppet manifests for each beaker test 15:17:22 great 15:17:40 one last thing I wanted to share about CI is that i'm trying to disabling EPEL at all 15:17:47 it causes some conflicts with RDO packaging 15:17:53 so I'm working on it this week. 15:18:06 do we have questions / other feedback about CI? 15:18:44 let's move on 15:18:50 #topic summit 15:18:56 #link https://etherpad.openstack.org/p/newton-design-puppet 15:19:04 I sent an email last week about the schedule 15:19:48 so basically, we have 2x40 min in Fishbowl, where we'll give a general project update and try to gather some feedback about last cycle 15:20:12 I hope this session will help us to define our plans for Newton, even though we already have some ideas 15:20:27 after that, we have 3 workrooms sessions, where I put some topics but it might change. 15:21:10 we'll finish by a Community session 15:21:20 shared with Murano folks, (they did not have enough room) 15:21:31 _ody: are you still ok to lead the community session? 15:22:51 someone asked what times are meeting 15:22:58 there is a nice website about schedule, let me find link 15:23:08 https://www.openstack.org/summit/austin-2016/summit-schedule/global-search?t=Puppet%20OpenStack%3A 15:23:31 do we have questions / feedback about summit? 15:23:34 <_ody> EmilienM: Yeah. 15:23:39 _ody: thx 15:23:52 Nice schedule 15:24:19 #topic Open Discussion, Bug and Review triage 15:24:28 the app for the schedule is much better this year =) 15:24:34 do we have bugs or reviews to discuss? 15:24:52 would like some feedback about multi-domain patch 15:25:00 puppet-ceph ci stuff, https://review.openstack.org/#/c/304378/ 15:25:02 https://review.openstack.org/#/c/299301/ 15:25:16 mwhahaha: +2 15:25:32 neutron lbaas v2 https://review.openstack.org/#/c/301797/ 15:25:40 zuul was nice to me this time 15:25:44 chem i thought i posted the fuel failure, it's puking on an undef method call 15:25:53 chem: have you figured the issue with oslib yet? 15:26:16 EmilienM: no, It's going my end of the day labor 15:26:23 mjblack: excellent work here, +2 again 15:26:43 <_ody> EmilienM: By community session. You mean the the project update sessions, yes? 15:26:51 _ody: nope 15:27:08 _ody: on Friday, it's community session, where everyone (not only devs) use to join. 15:27:20 https://www.openstack.org/summit/austin-2016/summit-schedule/events/9432?goback=1 this one i think 15:27:27 <_ody> ah. Contributors meetup 15:27:35 it's usually a good time to talk with community about needs, gather general feedback and also continue the discussion we had during the week 15:27:38 yeah 15:27:48 <_ody> yep. np. 15:27:49 _ody: bad wording on my side, sorry 15:28:13 we have small discussion with degorenko : https://review.openstack.org/#/c/298687/7/manifests/db.pp 15:28:18 do we need to keep connection string validation in the modules? (e.g. I'm not sure that any module except ceilometer supports mongo currently) 15:28:44 also zaqar supports mongo 15:28:45 also for example sahara doesn't support sqlite 15:28:54 yea for that we should probably keep it there 15:28:59 so, my suggestion is keep validation for connection string 15:29:00 right, if specific, it's ok to keep it there 15:29:01 because it's a service specific limitation 15:29:03 but remove cases 15:29:08 good, let's keep 15:29:09 mwhahaha: ++ 15:29:23 so, I need to update nova module a bit :) 15:29:31 chem: no problem for oslib, I'll try to investigate too but not sure for today :) 15:29:49 this work on puppet-oslo is really cool 15:30:00 would it make sense to have a var in params for supported db backends for each module? 15:30:19 EmilienM: ack, it going to be a time looser, for sure :) 15:30:34 mjblack, not sure that we want to spawn params 15:30:36 chem: yeah, I'm trying to clear my backlog first 15:30:49 can I ask to unblock cookiecutter https://review.openstack.org/#/c/304596/? I wanna switch it to oslo as well :) 15:30:53 i think just having validate_re function is enough 15:30:58 and thanks chem again for research 15:31:04 degorenko: I was thinking more along the lines that validation of the connection string would be consistent across every module 15:31:14 iberezovskiy: np :) 15:31:44 iberezovskiy: +A 15:31:56 EmilienM, thanks 15:32:15 mjblack, it will not be consistent on every module. Some projects don't support some backends 15:32:39 but puppet-oslo have all possible backends 15:32:48 well we could have an array of supported backends and just pass it to oslo to formulate the re 15:33:04 seems overly complex for now, but might be something to look into in the future 15:33:34 lets just get the olso move in place and itterate on it after we complete all the modules 15:33:44 +1 15:33:46 mwhahaha, ++ 15:33:53 +1 15:34:11 +1 with mwhahaha too 15:34:30 ok folks, anything else? 15:34:54 just to clarify: it's ok to implement oslo::service::ssl define? 15:35:06 or oslo::service 15:35:15 I don't know enough about oslo.service 15:35:44 ok, I'll research 15:36:01 not sure that all components are using it 15:36:03 https://github.com/openstack/oslo.service/blob/master/oslo_service/_options.py 15:36:08 we have a bunch of options 15:36:19 just use oslo::service to support them all should be ok 15:36:25 ok 15:36:47 there is wsgi, ssl, service, periodic, eventlet_backdoor, etc 15:37:12 keep it simple maybe 15:37:19 anything else? 15:37:39 ok folks! thanks for your time, have fun and eat vegetables. 15:37:44 #endmeeting