15:00:07 <EmilienM> #startmeeting puppet-openstack
15:00:07 <openstack> Meeting started Tue Jun 30 15:00:07 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:09 <mfisch> yo
15:00:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:12 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:15 <EmilienM> who is here today?
15:00:19 <mdorman> o/
15:00:20 <dfisher> o/
15:00:22 <iurygregory> o/
15:00:27 <spredzy> o/
15:00:33 <dmsimard> o/
15:00:38 <clayton> here
15:00:42 <rodrigods> with iurygregory o/
15:00:44 <xarses> o/
15:00:58 <EmilienM> a lot of Puppeteers :-) - good. Let's go
15:01:07 <EmilienM> #link agenda: https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150630
15:01:23 <EmilienM> #link last meeting: http://eavesdrop.openstack.org/meetings/puppet_openstack/2015/puppet_openstack.2015-06-23-15.00.html
15:01:30 <EmilienM> #topic Actions from last meeting
15:01:53 <EmilienM> spredzy Send a patch as an implementation reference (dbsync exec)
15:02:01 <EmilienM> done: https://review.openstack.org/#/q/status:open+branch:master+topic:db_sync,n,z
15:02:03 <sbadia> o/
15:02:10 <EmilienM> #link dbsync exec patches: https://review.openstack.org/#/q/status:open+branch:master+topic:db_sync,n,z
15:02:26 <EmilienM> and the mail: http://lists.openstack.org/pipermail/openstack-dev/2015-June/067950.html
15:02:29 <EmilienM> spredzy: thanks!
15:02:34 <spredzy> yw
15:02:50 <EmilienM> _ody and EmilienM to figure out about a CI status page > https://review.openstack.org/#/c/192253/ http://spencerkrum.com/openstack/ci/#
15:03:05 <EmilienM> nibaliazer showed me that this week end ^
15:03:15 <richm> here
15:03:20 <EmilienM> and fungi highlighted me the blueprint
15:03:33 <EmilienM> mfisch ask to TomF about usage of tags in Operators ML
15:03:44 <EmilienM> mfisch: thanks for that btw
15:04:02 <EmilienM> mdorman: about oslo messaging/rabbit: we have a topic for that after
15:04:12 <mdorman> kk
15:04:18 <EmilienM> mfisch follows-up keystone.py issue on https://review.openstack.org/#/c/193679/ (merged now)
15:04:30 <EmilienM> EmilienM to investigate a new experimental job to test beaker against puppet4 -> not done
15:04:38 <EmilienM> and
15:04:45 <EmilienM> spredzy,claryton create a POC and send an email to the ML about parameter default policy
15:04:48 <gchamoul> o/
15:05:00 <EmilienM> spredzy, clayton: I think you're working on it afik
15:05:09 <spredzy> we talked about it and have something to ask you guys
15:05:10 <_ody> o/
15:05:14 <spredzy> wil  add that to items
15:05:19 <spredzy> will*
15:05:25 <spredzy> so we can talk about it later
15:05:33 <EmilienM> spredzy: please add an item for today's agenda, we should have time.
15:05:42 <EmilienM> #topic CI status
15:06:03 <EmilienM> beaker jobs were in a bad shape lately
15:06:26 <EmilienM> it should be better now but if you see anything weird with centos7 & epel timeout, please ping me
15:06:30 <EmilienM> because it should be fixed
15:06:53 <EmilienM> crinkle and I are working on upgrade job: https://review.openstack.org/#/c/196249/
15:07:19 <EmilienM> Hunner: please look at the patch
15:07:44 <EmilienM> Hunner: we're waiting for a PR in beaker & and a release. Please let us know when it could happen
15:08:01 <saneax> Hi folks
15:08:19 <EmilienM> I submitted a patch in project-config to change the syntax-future job
15:08:27 <EmilienM> #link syntaxt-future job change: https://review.openstack.org/#/c/196386/
15:08:41 <EmilienM> which was pretty useless since Puppet 4 release  :-)
15:09:13 <EmilienM> _ody: maybe you can have a look at his patch ^
15:09:13 <sbadia> EmilienM: do you have the link for the beaker pr ?
15:09:47 <EmilienM> #link beaker PR: https://github.com/puppetlabs/beaker-puppet_install_helper/pull/8
15:09:52 <sbadia> thx
15:10:20 <_ody> EmilienM: I will today.
15:10:21 <EmilienM> crinkle: do you have any update about your work on zuul cloner and such?
15:10:43 <crinkle> EmilienM: no i didnt' get a chance to work on it last week
15:10:47 <EmilienM> okay
15:10:49 <crinkle> going to look into it today
15:10:51 <EmilienM> anything else about CI ?
15:11:03 <EmilienM> ok let's move on
15:11:13 <EmilienM> #topic Blueprints
15:11:29 <EmilienM> #link Enable k2k federation: https://review.openstack.org/#/c/190361/
15:11:33 <EmilienM> iurygregory: o/
15:11:35 <iurygregory> me \o
15:11:38 <iurygregory> tks
15:11:54 <iurygregory> Hello people, I'm working with federation and i've worked a little with puppet.
15:12:06 <iurygregory> Here at Universidade Federal de Campina Grande we have a demand to make easier for cloud administrators to configure Federation.
15:12:24 <iurygregory> I have created the spec (https://review.openstack.org/#/c/190361/) and was thinking if the approach i'm considering is a good one, feedbacks are welcome.
15:12:25 <rodrigods> (there is a huge demand from other stakeholders like CERN, as well)
15:12:36 <iurygregory> thanks rodrigods ;)
15:12:56 <richm> we are quite interested in federation too
15:13:16 <richm> one problem I have with the bp is that it seems very shib centric
15:13:26 <rodrigods> richm, ++ agreed
15:13:28 <iurygregory> We can take this feature in te kilo release? I'm starting to code
15:13:35 <EmilienM> iurygregory: no
15:13:44 <EmilienM> iurygregory: you'll have to move the blueprint for next release
15:13:52 <EmilienM> iurygregory: we are close to release Kilo
15:13:53 <rodrigods> but *today* mod_shib is the one keystone advices to use
15:14:07 <richm> but mod_shib is not the only one that works with Keystone
15:14:12 <richm> mod_mellon as well
15:14:14 <iurygregory> yes richm the bp was considering shib but the spec i have change
15:14:23 <iurygregory> ok EmilienM
15:14:26 <rodrigods> true, this can be a starting point? richm
15:14:34 <richm> yes
15:14:49 <rodrigods> maybe the bp states that there are several SPs that can be used
15:14:51 <EmilienM> iurygregory: thanks for starting up this work. I guess we need a bit of design and the blueprint is a good start
15:15:25 <EmilienM> I propose we continue the discussion on Gerrit with iurygregory, richm, rodrigods, mfisch and everyone interested by this work
15:15:25 <richm> support for mod_shib is fine
15:15:42 <richm> I just don't want everyone thinking that federation == saml2 == mod_shib
15:15:42 <iurygregory> ok works for me =)
15:15:50 <EmilienM> richm: good point
15:15:53 <rodrigods> richm, ++
15:15:59 <EmilienM> richm: the design of this bp should be flexible
15:16:03 <iurygregory> richm, ++
15:16:07 <EmilienM> good
15:16:09 <richm> so I would like the design to have some room for other saml2/federation implementations
15:16:14 <richm> yes
15:16:21 <rodrigods> EmilienM, richm flexibility in bp, but with couple of specs to work with other software?
15:16:26 <richm> yes
15:16:32 <EmilienM> iurygregory: if you have any blocker/question, please raise your hand on IRC, we'll be happy to help
15:16:42 <iurygregory> ok ^^
15:16:54 <EmilienM> rodrigods: couple of specs?
15:17:07 <rodrigods> EmilienM, more than one spec to target the bp
15:17:08 <EmilienM> maybe it can be done in one spec. I don't think we need multiple specs
15:17:20 <richm> I did a poc of setting up keystone with mod_mellon + ipsilon + freeipa - https://github.com/richm/puppet-apache-auth-mods
15:17:22 <EmilienM> oh yeah
15:17:41 <EmilienM> rodrigods: I mean, keep enabling-k2k-federation for the single blueprint
15:17:57 <EmilienM> and adapt the design to work with multiple use-cases
15:18:15 <rodrigods> EmilienM, hmm so the mod_shib part, would be an example?
15:18:18 <rodrigods> (in the spec, I mean)
15:18:20 <EmilienM> yes
15:18:24 <rodrigods> good
15:18:27 <EmilienM> iurygregory: anything else?
15:18:32 <iurygregory> nothing
15:18:33 <richm> also, it's not really just k2k federation - it's just "federation", with a special case where another Keystone is an identity provider
15:18:36 <iurygregory> thanks o/
15:18:46 <rodrigods> richm, yes, we may update the bp :)
15:18:49 <richm> ok
15:18:52 <EmilienM> iurygregory: take this comment in consideration (rename?)
15:18:54 <richm> thanks
15:18:57 <iurygregory> yes
15:19:03 <iurygregory> i'll update today
15:19:05 <EmilienM> a lot of keystone experts around here, good
15:19:10 <EmilienM> iurygregory: cool
15:19:12 <rodrigods> thanks for the feedback guys
15:19:23 <EmilienM> #link Keystone v3 blueprint: https://review.openstack.org/#/c/150108/
15:19:27 <EmilienM> richm: o/
15:19:52 <richm> I'm rebasing now, and working on the beaker automation
15:20:07 <EmilienM> richm: the blueprint is ready I think
15:20:14 <richm> well
15:20:27 <richm> the bp talks about support for groups and trusts
15:20:41 <richm> the work has not even been started on those features yet
15:20:56 <crinkle> that can be added as a feature release later
15:21:00 <EmilienM> richm: ok so you think the design can change ?
15:21:00 <crinkle> imo
15:21:05 <richm> the bp also talks about making every single puppet module v3 capable
15:21:07 <EmilienM> crinkle: yeah
15:21:24 <richm> and only glance has been submitted for review so far
15:21:27 <EmilienM> richm: it's okay, we have the design in agreed during our Kilo cycle
15:21:57 <richm> ok - I'm fine with whatever you guys decide
15:22:04 <EmilienM> richm: worst case, we can iterate in the next release. But I think this is not going to change everything
15:22:13 <richm> ok
15:22:47 <crinkle> richm: are the blueprint and the related keystone patches ready to re-review?
15:23:06 <richm> crinkle: the bp is
15:23:15 <iurygregory> you can link the bp?
15:23:25 <EmilienM> https://review.openstack.org/#/c/150108/
15:23:29 <EmilienM> I did ^
15:23:31 <richm> I'm rebasing and fixing the patches for automation right now
15:23:38 <iurygregory> sorry ;X
15:23:58 <EmilienM> crinkle: we did some testing last night, and we should have fixed all known bugs we're spotted
15:24:03 <crinkle> richm: okay, let us know when we can review them
15:24:04 <crinkle> EmilienM: cool
15:24:06 <richm> yes
15:24:11 <EmilienM> richm: thanks
15:24:26 <EmilienM> #link Master branch policy blueprint: https://review.openstack.org/#/c/180141/
15:24:28 <richm> you'll see #puppet-openstack blow up in an hour or so . . .
15:24:52 <EmilienM> I had no feedback on this one, I tried to summarize what we said during the summit
15:25:53 * _ody reads real quick
15:25:57 <EmilienM> I think i'll wait a bit, while people finds time to review
15:26:24 <EmilienM> we're done with blueprints
15:26:51 <EmilienM> #topic oslo messaging version & default values
15:26:55 <EmilienM> mdorman: o/
15:27:04 <mdorman> yeah
15:27:23 <mdorman> i had summarized the situation in http://lists.openstack.org/pipermail/openstack-dev/2015-June/067821.html
15:27:27 <EmilienM> mdorman: can you summarize (again) the 2 proposals? so we can come up with a decision
15:28:13 <mdorman> sure.  1)  set rabbit_heartbeat_timeout_threshold default to 60 in the puppet module, which follows what teh default is in upstream kilo nova
15:28:52 <EmilienM> I'm about to run a vote
15:29:09 <EmilienM> people who vote, please read the context before :-)
15:29:18 <mdorman> 2) add a separate rabbit_enable_heartbeat parameter which much be set to true (default is false) to actually enable the feature, rather then relying solely on rabbit_heartbeat_timeout_threshold value to determine if it’s enabled or not
15:29:48 <mdorman> there are some implications on 1), due to the requirements.txt set on upstream nova.  but i think for the most part this should be a non-issue
15:30:46 <mdorman> for the 1) option, you would have to set rabbit_heartbeat_timeout_threshold to 0 to disable the feature
15:30:57 <EmilienM> or undef?
15:31:02 <EmilienM> and make sure it's absent
15:31:13 <mdorman> if it’s absent, the nova default is 60
15:31:21 <mdorman> so nova default is to enable the feature
15:31:40 <mdorman> at least in the current cut of kilo
15:31:47 <mfisch> what about other services?
15:31:49 <EmilienM> yeah I meant to let the default
15:32:30 <mdorman> mfisch:   the default value actually comes from oslo.messaging, not nova
15:33:10 <mdorman> so we would do the same setup for all modules/services.
15:33:10 <clayton> this seems related to what spredzy and I were talking about.
15:33:18 <mdorman> sorry i shoul have said the oslo.messaging default is 60, not nova default
15:33:46 <_ody> Ah.  Hard choice.  One is simpler but prone to easily getting out of sync from upstream defaults and the other could be confusing because you have two ways of disabling a thing.
15:34:04 <iurygregory> _ody, ++
15:34:10 <mdorman> yeah.  for sure we would want to reevaluate this come Liberty time
15:34:12 <mfisch> I think the option with the least side affects is to default it hard disabled
15:34:20 <mfisch> meaning you'd have to explicitly enable and set the value
15:34:23 <mdorman> b/c the default in later oslo.messagings even now is 0, not 60
15:34:25 <mfisch> its annoying but explicit
15:34:53 <mdorman> personally i dno’t think the two parameter method is that bad
15:35:03 <mfisch> if I came in and said "i really want this feature" I'd read the comments and figure it out
15:35:09 <mfisch> everyone else would not be surprised
15:35:19 <mdorman> i would opt for the 1) option for my own setup, but i think having the extra parameter, but having it be an explicit enabling of it, is a good trade off
15:35:25 <mdorman> yeah.
15:35:32 <EmilienM> we followed default values from day 1 I don't see why we should change today
15:35:52 <EmilienM> so if 60 is default in kilo, and 0 in liberty we have our answer
15:35:56 <mdorman> EmilienM:  problem is the default in upstream oslo.messaging changes
15:36:04 <EmilienM> yes, in liberty
15:36:05 <mfisch> the issue in the future is it would be hard to remove the extra parameter
15:36:10 <EmilienM> we are not supporting liberty today
15:36:14 <mdorman> mfisch: true
15:36:16 <mfisch> think in N or O when everyone wants it on all the time
15:36:32 <mdorman> yeah i guess the most likely thing would be the default changes at Liberty time
15:36:36 <EmilienM> having the parameter is good, people can change the value and disable the feature.
15:36:41 <EmilienM> yeah
15:36:44 <mfisch> thats my vote for now
15:36:46 <mdorman> but there are later releases of oslo.messaging now (which technically are kilo) where the default is different
15:36:47 <_ody> mfisch: Really good point.  Adding a parameter is a pretty apparent API change.
15:36:52 <EmilienM> I'm about to run the vote
15:37:00 <EmilienM> to run solution 1 (yes/no)
15:37:03 <EmilienM> #startvote set rabbit_heartbeat_timeout_threshold default to 60? yes, no
15:37:03 <openstack> Begin voting on: set rabbit_heartbeat_timeout_threshold default to 60? Valid vote options are yes, no.
15:37:04 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
15:37:21 <mfisch> _ody: what if we make the comment that says "This defaults to off or now, it will switch in L or M, you should make your selection explicit"
15:37:23 <EmilienM> #vote yes
15:37:30 <mdorman> #vote yes
15:37:32 <iurygregory> #vote yes
15:37:33 <gchamoul> #vote yes
15:37:34 <mfisch> #vote yes
15:37:39 <mdorman> yeah we could add some more comments in that should help with that
15:37:44 <_ody> #vote yes
15:38:07 <spredzy> #vote yes
15:38:30 <EmilienM> closing in 15 sec
15:38:57 <EmilienM> #endvote
15:38:57 <openstack> Voted on "set rabbit_heartbeat_timeout_threshold default to 60?" Results are
15:38:58 <openstack> yes (7): mfisch, _ody, iurygregory, EmilienM, mdorman, gchamoul, spredzy
15:39:11 <dims> not to side-track the vote, if there's anything better we can do oslo.messaging, please let us know
15:39:31 <EmilienM> dims: cool, maybe you can tell us what you think about our choice
15:39:51 <dims> EmilienM: ++
15:39:54 <EmilienM> cool
15:40:09 <EmilienM> mdorman: anything else?
15:40:35 <mfisch> wait a sec
15:40:38 <EmilienM> mdorman: please use the same topic when you'll patch all modules. Your patches will be included in Kilo release I think
15:40:46 <mdorman> i don’t think so.  were we going to vote on #2 or just assume #1 wins?  (i mean i don’t really care, i’m good with 1)
15:40:49 <mfisch> I thought we were voting for setting the default to 60 and also adding an explicit enablemebt>?
15:40:53 <mfisch> 2 votes
15:41:07 <mfisch> as in I thought first vote was just for a value
15:41:50 <EmilienM> we just voted for the default value
15:41:54 <EmilienM> and the proposal #1
15:42:39 <mdorman> should we re-vote and make options #1 or #2 instead?
15:42:40 <EmilienM> mfisch: the enable param was in #2 no?
15:42:57 <mfisch> sorry for the confusion, I though I was voting for the number 60 as the default and we'd also get to have the explicit disable :(
15:43:08 <EmilienM> mdorman: well, we can followup on ML
15:43:11 <EmilienM> time is running
15:43:16 <mfisch> ok
15:43:19 <mdorman> ok i will post o ML and ask people to vote
15:43:24 <EmilienM> #action people to follow-up oslo messaging discussion on ML
15:43:28 <EmilienM> mdorman: thx.
15:43:35 <EmilienM> #topic default values management
15:43:37 <mfisch> I'm an uninformed voter obvs.
15:43:42 <EmilienM> clayton, spredzy o/
15:43:49 <EmilienM> what's up?
15:43:55 <spredzy> clayton, you want to go ahead and explain what we talked about ?
15:44:16 <clayton> sure.  I think both of the things we talked about have been mentioned on irc before
15:44:48 <clayton> first one was the idea of making it easier to ensure config values are absent for at least some options if the end user didn't explicitly provide a value
15:45:41 <clayton> so what has been floated before was something like setting the default parameter to undef, and if the provider value parameter was undef, it would ensure absent, so like glance_config { 'DEFAULT/key': value => undef } would be the same thing as ensure absent
15:46:07 <clayton> spredzy has tried this, and I've tried similar things in the past, and my recollection is that the puppet 3.x api doesn't have a good way of passing in undef like this
15:46:16 <clayton> it's like the attribute wasn't specified at all
15:46:41 <EmilienM> clayton: do you mean to patch ini provider?
15:46:57 <clayton> we were hoping someone with more experience might be able to confirm that
15:47:00 <clayton> yes
15:47:26 <clayton> or better yet, create a new base ini provider in openstack lib that derives from the upstream one that all providers downstream of it could inherit from
15:47:38 <clayton> so if we add more local enhancements it wouldn't be necessary to change every module
15:47:43 <EmilienM> good idea
15:48:01 <EmilienM> clayton: have you asked to ML (our ML or puppet ML) ?
15:48:06 <mdorman> isn’t there a wa in the provider to recognize the undef/parameter not specificed at all situation?
15:48:43 <clayton> if we can't pass in undef, then the alternative would be one or more 'magic' values like '<UNDEF>', '<DEFAULT>' or '<UNSET>' that would act like absent
15:48:59 <crinkle> i would think if you pass value => undef and the default property value is nil then it should work?
15:49:13 <clayton> crinkle: perhaps, but isn't the value parameter required?
15:49:14 <spredzy> If a resource set first a value to 'x' and then to undef, the value will remain 'x'.
15:49:29 <spredzy> it's like it is not taking the change in account
15:49:50 <mdorman> right, but do like what crinkle said, make the default nil
15:49:51 <crinkle> spredzy: yes, but if we never set it to 'x' then it would be fine?
15:50:22 <mdorman> probably not solveable now, but seems like it *is* solveable
15:50:57 <clayton> if we can't do undef, then the alternative is a magic value, which is a little gross, but I think better than the if $value/else stuff that is the alternative
15:51:48 <spredzy> crinkle, I'll have to try. I haven't tried it this way
15:51:53 <spredzy> so not sur
15:51:57 <crinkle> spredzy: yeah me too
15:52:29 <EmilienM> spredzy, clayton: seems like you need more time to make more tests & discussion
15:52:39 <EmilienM> maybe we can follow-up when you guys decide
15:52:47 <clayton> nod, but I think we wanted to get some comments on the general approach
15:53:06 <clayton> and if undef doesn't work out, if people feel like the magic values would be tenable or too gross
15:53:12 <EmilienM> I don't like much the magic value thing
15:53:12 <spredzy> EmilienM, well we will do more test. But if this doesn't work, would the community agree on using a magic string and the user of an openstacklib/inifile provider
15:53:31 <EmilienM> if there is no other solution, why not
15:53:42 <clayton> EmilienM: nod, I don't think any of us *like* it :)
15:53:49 <crinkle> agreed with EmilienM, would prefer not but it's not the worst thing
15:53:54 <EmilienM> big +1 on openstacklib/inifile providerr
15:53:58 <mdorman> +1, don’t really like it, but i would agree to it if it’s the only option
15:54:06 <spredzy> #action spredzy make more test to not have to use a magic string for the purpose of parameter defaults
15:54:12 <EmilienM> thanks spredzy, clayton !
15:54:25 <clayton> we had another possible enhancement we discussed in the same context
15:54:34 <EmilienM> spredzy: I won't follow-up in the next meeting I let you guys bring the topic when you ready
15:54:44 <EmilienM> #topic Open Discussion, Bug and Review triage
15:55:10 <EmilienM> I would like to ask people if they have any blocker (except keystone v3) for a Kilo release
15:55:31 <mfisch> nope
15:55:42 <EmilienM> also, if there is any outstanding bug/review we need to see
15:56:37 <EmilienM> *silence*
15:56:38 <_ody> Might be a blocker, https://review.openstack.org/#/c/194097/
15:56:56 <EmilienM> _ody: indeed, nice catch
15:57:18 <EmilienM> _ody: the author is in my team, and currently in holidays. Can you takeover?
15:57:33 <_ody> yes...I was typing up the same suggestion.
15:57:39 <_ody> I'll work on the tests today.
15:57:45 <EmilienM> _ody: thanks
15:57:50 <EmilienM> anything else folks?
15:58:29 <EmilienM> http://goo.gl/7K6foy
15:58:35 <EmilienM> have a great day!
15:58:43 <iurygregory> bye o/
15:58:46 <EmilienM> #endmeeting