15:00:18 <EmilienM> #startmeeting puppet-openstack
15:00:19 <openstack> Meeting started Tue Jul  7 15:00:18 2015 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:23 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:25 <EmilienM> #topic rollcall
15:00:30 <EmilienM> who is here today ?
15:00:34 <crinkle> o/
15:00:39 <iurygregory> o/
15:00:40 <mwhahaha> o/
15:00:40 <sbadia> o/
15:00:46 <mdorman> .
15:00:52 <spredzy> o/
15:01:00 <EmilienM> #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150707
15:01:14 <xarses> hi
15:01:16 <EmilienM> let's go!
15:01:19 <EmilienM> #topic Actions from last meeting
15:01:33 <EmilienM> mdorman: we followup oslo/messaging in a separated topic
15:01:51 <EmilienM> spredzy: we postpone your action, like it's written in the etherpad
15:01:57 <EmilienM> spredzy: any blocker though?
15:02:14 <EmilienM> "spredzy make more test to not have to use a magic string for the purpose of parameter defaults"
15:02:28 <mdorman> so based on sileht’s post on the ML, I think we have consensus that the default rabbit_heartbeat_timeout_threshold value for Kilo should be 0
15:02:43 <EmilienM> mdorman: please later
15:02:43 <mdorman> i was confused about some later versions of oslo.messaging having a different default value
15:02:52 <spredzy> Nop just not working as expected, need to make more investigation, couldn't spend a lot of time on this item this week
15:02:53 <EmilienM> mdorman: I created a topic for that
15:02:58 <mdorman> ah gottcha, sorry.
15:03:03 <EmilienM> mdorman: np :)
15:03:10 <EmilienM> spredzy: ack
15:03:19 <EmilienM> #topic CI status
15:03:33 <EmilienM> there is a new wiki page
15:03:40 <EmilienM> #link new wiki page about CI jobs: https://wiki.openstack.org/wiki/Puppet/CI
15:03:47 <EmilienM> please review/comment/improve
15:04:14 <EmilienM> crinkle: I let you announce your new feature about zuul-cloner?
15:04:53 <_ody> o/...yawn
15:04:57 <crinkle> we added a Puppetfile and a shell script to the puppet-openstack-integration repo and we're using it in keystone's beaker tests
15:05:22 <crinkle> it uses zuul-cloner so that we can clone dependent changes if there are any
15:05:33 <EmilienM> so Depends-On works on puppet-keystone
15:06:02 <crinkle> we also spotted and fixed a bug in it yesterday
15:06:13 <crinkle> so i'll work on pushing it out to the rest of the modules today
15:06:43 <EmilienM> #action crinkle on pushing zuul-cloner changes to all modules
15:07:05 <EmilienM> on my side, I'm doing some tests with tempest integration: https://review.openstack.org/#/c/198561/
15:07:23 <EmilienM> if you look at the job logs, you can see Tempest ran at the end. It's really PoC but please review and give feedback
15:08:00 <sbadia> cool \o/
15:08:13 <EmilienM> and also I'm trying to have OpenStack service log files in beaker jobs (see https://review.openstack.org/#/c/198802/ )
15:08:37 <crinkle> EmilienM: what's the status of the upgrade job?
15:08:48 <EmilienM> crinkle: I haven't worked on it lately
15:08:58 <EmilienM> it looks stable to me, except if I missed something
15:09:22 <EmilienM> it used to fail yesterday, I  have not found the reason yet
15:09:43 <EmilienM> do we have anything else about CI ?
15:10:18 <EmilienM> ok let's move on
15:10:22 <EmilienM> #topic midcycle
15:10:27 <sbadia> seems no, thanks for the great work!
15:10:43 <EmilienM> #link midcycle doodle: http://doodle.com/xk2sfgu4xsi4y6n4
15:10:51 <EmilienM> sorry for the wrong link I sent first :(
15:10:59 <iurygregory> no problem
15:11:21 <EmilienM> #link midcycle etherpad: https://etherpad.openstack.org/p/puppet-liberty-mid-cycle
15:11:28 <EmilienM> please make sure we have some topics we can work on
15:12:24 <EmilienM> any question about our first sprint?
15:12:47 <EmilienM> mgagne: I count on your presence, we have to represent Quebec :-P
15:13:14 <mgagne> will make the request to my boss =)
15:13:20 <EmilienM> cool!
15:13:25 <EmilienM> let's move on
15:13:28 <EmilienM> #topic oslo.messaging/RMQ heartbeating follow-up
15:13:32 <EmilienM> mdorman: o/
15:13:59 <mdorman> yup
15:14:06 <mdorman> so based on sileht’s post on the ML, I think we have consensus that the default rabbit_heartbeat_timeout_threshold value for Kilo should be 0
15:14:09 <EmilienM> sileht gave us good insights. He also told me we might need to follow default values in upstream, like usual
15:14:14 <EmilienM> yeah
15:14:19 <mdorman> i was confused about some later versions of oslo.messaging having a different default value
15:14:21 <EmilienM> so disabled
15:14:24 <mdorman> yup.
15:14:38 <mdorman> so in summary i think we should set the default in puppet modules to 0, which will match kilo oslo.messaging
15:14:58 <EmilienM> mdorman: do we need to vote?
15:15:04 <mdorman> i think it’s pretty much a non-issue now.  i’ll update all the patches and folks can review
15:15:11 <EmilienM> is anyone against that? (ie: following what upstream does)
15:15:20 <mdorman> yeah i see no reason to vote
15:15:28 <xarses> I think we should document why you might want it
15:15:46 <EmilienM> xarses: in the manifest yes
15:15:49 <mdorman> i can add some details to the comments on the parameter
15:15:51 <xarses> we use it heavily, and is one of the few ways to improve rabbit ha
15:16:16 <EmilienM> xarses: hopefully, you'll be able to change the value. We're just talking about default values here
15:16:23 <xarses> but leaving it on, when your rabbit is not configured to send heartbeats will result in you constantly dropping the connection
15:16:32 <xarses> so a default of 0 is correct
15:16:40 <mdorman> yup.
15:17:13 <EmilienM> #action mdorman to update all oslo/messaging/heartbeat patches to disable it by default and provide good doc about it
15:17:19 <mdorman> cool
15:17:20 <EmilienM> mdorman: anything else? any blocker?
15:17:22 <mdorman> nope
15:17:48 <EmilienM> #topic keystone v3
15:17:59 <EmilienM> I created the topic before the meeting because I have some questions
15:18:15 <EmilienM> richm and I figured out something weird:
15:18:30 <EmilienM> when you want backward compatibility with keystone v2, you need a default domain
15:18:34 <EmilienM> so you need to:
15:19:10 <EmilienM> 1/ start keystone 2/ create the domain 3/ query the domain to get the domain_id 4/ put this id in keystone.conf 5/ restart keystone
15:19:34 <EmilienM> #link keystone feature request: https://bugs.launchpad.net/keystone/+bug/1472285
15:19:34 <openstack> Launchpad bug 1472285 in Keystone "set default domain dynamically" [Undecided,New]
15:19:43 <EmilienM> richm submitted that ^ to have it dynamically one day
15:19:43 <xarses> erm
15:19:48 <EmilienM> but in the meantime, we have to deal with that
15:19:54 <xarses> is that something we should kick upstream about
15:20:17 <EmilienM> so in the meantime, I need to restart keystone service in the provider, if the ID has changed
15:20:20 <mwhahaha> shouldn't updating the config trigger a restart anyway? (not that this flow seems very good anyway)
15:20:37 <EmilienM> mwhahaha: no because keystone needs to be run before to create the domain
15:20:53 <mwhahaha> oh right for initial configurations
15:20:54 <EmilienM> and in one catalog, you can't restart a service two times without ugly things I think
15:20:58 <richm> https://bugs.launchpad.net/keystone/+bug/1472285
15:20:58 <openstack> Launchpad bug 1472285 in Keystone "set default domain dynamically" [Undecided,New]
15:21:07 <EmilienM> richm: yep, already written
15:21:34 <EmilienM> I'm looking at a way to get the keystone service name from the catalog in the provider
15:21:41 <EmilienM> I've seen https://ask.puppetlabs.com/question/2366/how-can-i-get-the-catalog-object-from-within-a-provider-class/
15:21:47 <EmilienM> does anyone here has a better option?
15:22:14 <xarses> get the keystone guys to work out something better
15:22:27 <EmilienM> xarses: please be productive here
15:22:50 <EmilienM> xarses: we already submitted the bug. We need to work on an alternative now
15:22:50 <xarses> I'm serious, this seems like something they need to help with
15:23:23 <EmilienM> xarses: we are close to cut stable/kilo, we need this feature before.
15:23:24 <richm> They will likely say "it's not our problem, go fix puppet"
15:23:36 <EmilienM> so we won't wait for a patch merged/backported/packaged
15:23:44 <EmilienM> yeah
15:23:48 <crinkle> "they will likely say" isn't a good reason not to ask them
15:23:54 <richm> we did ask them
15:24:04 <crinkle> okay then
15:24:05 <richm> I'm just anticipating the most likely response
15:24:25 <EmilienM> crinkle: richm and I will follow-up with them to make sure our request is in their backlog
15:24:48 <EmilienM> crinkle: I saw your patch on rabbitmq with erlang_cookie and service name
15:24:56 <EmilienM> should we add a new param in the type for service name?
15:25:07 <EmilienM> or query catalog in the prefetch
15:25:19 <iurygregory> the keystone meeting is today, maybe discuss if they have space in the agenda
15:25:28 <EmilienM> like Adrien is explaining here: https://ask.puppetlabs.com/question/2366/how-can-i-get-the-catalog-object-from-within-a-provider-class/
15:26:14 <crinkle> so what happens if they're not managing the keystone service with puppet, or if they're using httpd instead?
15:26:30 <EmilienM> crinkle: that's why I want to query the catalog to get the service name
15:26:42 <EmilienM> because the service_name is httpd/keystone aware
15:27:24 <crinkle> EmilienM: so you mean get the $service_name class parameter from the catalog?
15:27:33 <EmilienM> crinkle: yes, in the provider
15:27:45 <_ody> I think I'd seriously probably just use and exec to patch this up until keystone fixes the actual problem.
15:28:03 <EmilienM> ok
15:28:03 <_ody> In the provider feels like more magic than I lik.e
15:28:10 <crinkle> yes ^
15:28:20 <EmilienM> so I do an exec?
15:28:54 <crinkle> i +1 an exec, it makes it less magic and we could allow the user to disable it if they want
15:28:58 <EmilienM> ok
15:29:04 <EmilienM> thanks
15:29:20 <EmilienM> we are done with topics
15:29:37 <EmilienM> #topic open discussion / bug / patch triage
15:30:08 <mwhahaha> Hey all, i just have a question about https://review.openstack.org/#/c/198133/ - what should be the next steps to get this merged? Should I update the parameter docs to reference the other places that are also used to specify region?
15:30:36 <EmilienM> mwhahaha: I think your patch is okay even though something is broken in neutron config...
15:31:02 <mwhahaha> yea i'm not sure the region stuff is consistent across all projects anyway :/
15:31:32 <mwhahaha> i just want to make sure everything is covered and i'm not missing anything
15:32:25 <EmilienM> I think it's okay
15:32:33 <mwhahaha> ok, thanks
15:32:45 <EmilienM> does anyone else have outstanding reviews / bugs we could discuss?
15:33:17 <EmilienM> xarses: you might want to merge https://review.openstack.org/197332
15:33:35 <delatte> emilienm: https://review.openstack.org/#/c/197572/ I mad a comment about the acceptance tests for not class modules.
15:33:40 <iurygregory> i only have my spec, but we have discuss in the last meeting, when i have some code for review maybe we can discuss =)
15:33:50 <EmilienM> mfisch: can you review again https://review.openstack.org/#/c/198572/ ? i updated commit message
15:34:03 <xarses> EmilienM: I thought I saw it passing w/o it
15:34:47 <EmilienM> delatte: fair enough for acceptance, there is no tests for other Exec, do not worry
15:34:57 <EmilienM> delatte: though the patch was not idempotent (I tested it)
15:35:26 <delatte> emilienm:  nod.  I am going to move it back to WIP.  got a unless I am working through for the exec
15:35:26 <EmilienM> delatte: currently, your Exec runs all the time
15:35:35 <EmilienM> delatte: yes or onlyif
15:35:37 <EmilienM> whatever
15:36:31 <EmilienM> if nothing else, I'll close the meeting in 1 min
15:36:49 <xarses> EmilienM: ya, it's passing w/o 197332
15:37:13 <xarses> should we just merge for consistency then?
15:37:48 <EmilienM> xarses: no wait
15:37:55 <EmilienM> xarses: it does not pass upgrade flow
15:38:05 <EmilienM> xarses: I'll try to find time to look
15:38:10 <EmilienM> xarses: or you can go ahead
15:38:13 <xarses> it started passing in other CR's after this
15:38:21 <xarses> if we recheck it should pass
15:38:39 <EmilienM> xarses: go ahead!
15:38:43 <EmilienM> thanks everyone
15:38:47 <EmilienM> have a great day/evening!
15:38:57 <iurygregory> thanks o/
15:39:05 <EmilienM> #endmeeting