15:00:37 <crinkle> #startmeeting puppet-openstack
15:00:37 <openstack> Meeting started Tue Jun  2 15:00:37 2015 UTC and is due to finish in 60 minutes.  The chair is crinkle. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:39 <Hunner> o/
15:00:42 <openstack> The meeting name has been set to 'puppet_openstack'
15:01:04 <crinkle> Emilien is still in the middle of canada so he asked me to run the meeting
15:01:25 <crinkle> #topic Review past action items
15:01:48 <mfisch> morning!
15:02:15 <crinkle> "sbadia asks on ML to get some help on rspec & puppet4 work" - sbadia isn't here but I know there's been some progress there
15:02:48 <Hunner> Sounds like _ody has volunteered
15:02:58 <Hunner> And he started working on it at the summit
15:03:07 <spredzy> thanks _ody for that !
15:03:12 <Hunner> (Cody Herriges, _ody on irc)
15:03:22 <crinkle> awesome
15:03:27 <mfisch> is _ody from Puppet Labs?
15:03:37 <crinkle> yes
15:04:05 <Hunner> mfisch: He has short red hair
15:04:09 <crinkle> "EmilienM push beaker tests to puppet-tripleo" - sounds like emilien will work on this when he gets back
15:04:11 <Hunner> You might have seen him at the summit
15:04:29 <crinkle> "mfisch to cleanup http://stackalytics.com Puppet groups" - that happened already
15:04:41 <mfisch> crinkle: yep thats been done, remove it from the actions for next week
15:04:52 <crinkle> "spredzy and sbadia work on the msync automatization" - spredzy why does it say postpone?
15:05:05 <spredzy> I just added it because we didnt have time to work on it
15:05:13 <spredzy> So I ll get the review ready for next week meeting
15:05:22 <crinkle> okay awesome
15:05:41 <spredzy> I am talking about the post-merge hook in openstack-infra
15:06:59 <crinkle> #topic summit recap
15:07:09 <crinkle> #link http://my1.fr/blog/puppet-openstack-plans-for-liberty/
15:07:17 <crinkle> Emilien wrote up a pretty good summary ^
15:07:28 <crinkle> there were some action items I want to follow up on
15:08:26 <crinkle> "ACTION [emilien]: get blessing from openstack to use openstack namespace available in puppetforge" - I'm sure he hasn't had time, and I wonder if we might also want to consider a different namespace
15:08:50 <mfisch> I'd like to get a firm yes/no before picking something else
15:09:08 <crinkle> that seems reasonable
15:09:15 <_ody> Had to skip shower, coffee, and breakfast to get kid to school in time to get back to my laptop...still 9 minutes late.
15:09:27 <crinkle> _ody: o/
15:10:24 <crinkle> "ACTION [hunner?]: what about redirecting stackforge namespaces?" - Hunner is that something that's within the realm of possibility?
15:11:07 <_ody> github?
15:11:17 <crinkle> _ody: no the puppet forge
15:11:24 <mfisch> I think he thought no, but was going to confirm
15:11:26 <Hunner> come back to me inna sec
15:11:30 <crinkle> k
15:11:32 <Hunner> in two meetings at once >_<
15:11:49 <crinkle> "ACTION (no assignee): see if we can get puppet-module-generate with skeleton working" - I think spredzy was going to work on that but it didn't get captured in the etherpad
15:11:56 <mfisch> yes that was hid
15:11:56 <mfisch> his
15:12:15 <spredzy> We did the work with sbadia and puppet-module-skeleton wasn't felxible enough for our needs
15:12:25 <spredzy> hence we turned to cookiecutter
15:12:59 <spredzy> A mail was sent to the ML to let the community know about the progress we've made, and that if we agree on a name we can push the project to stackforge
15:13:06 <crinkle> oh I see the email now
15:13:24 <spredzy> #link http://lists.openstack.org/pipermail/openstack-dev/2015-May/064608.html
15:13:43 <spredzy> So if we agree with EmilienM|off suggestion, I can mke the review on openstack-infra
15:13:54 <spredzy> keeping his suggestion as the name of the project
15:14:00 <mfisch> spredzy: I like Emilien's name better too
15:14:05 <crinkle> +1
15:14:28 <spredzy> #action spredzy submit a review in openstack-infra to integration the cookiecutter templates
15:14:37 <spredzy> erf s/integration/integrate
15:15:15 <crinkle> and the next action item was about msync which we can talk about next week
15:15:42 <spredzy> yep
15:15:48 <crinkle> "[ACTION] (no assignee) email openstack-dev with example code from at least one provide using the new pattern for parameter defaults" - I don't think I saw an email for this, did I miss it?
15:15:55 <crinkle> and I don't remember who was assigned
15:16:10 <clayton> I had volunteered to look into it before the summit
15:16:53 <spredzy> I had spent some time to work on the ini_file provider to consider undef as absent but haven't make breakthough there yet
15:17:43 <Hunner> crinkle: For my action, I'm asking again, but I have a feeling that redirects on the forge will not happen... dependencies and all that are hard. Also no update on if openstack can let us use the openstack forge namespace
15:18:13 <Hunner> I'm in another meeting that goes until 8:30; sorry
15:18:19 <crinkle> Hunner: that's my feeling too
15:18:25 <crinkle> Hunner: no problem
15:18:43 <_ody> Hunner: We can at least depricate/delete modules release there and manually redirect people.
15:18:44 <crinkle> clayton: spredzy can one of you take the #action to create a POC and submit it to the ml ?
15:19:11 <Hunner> _ody: yeah. Especially since OS people don't use the forge too often :)
15:19:23 * Hunner gets back on-topic
15:19:29 <spredzy> clayton, can we talk about that after the meeting so we know we are on the same line and send the email after ward ?
15:19:34 <clayton> spredzy: sure
15:20:06 <spredzy> #action spredzy,claryton create a POC and send an email to the ML about parameter default policy
15:20:06 <crinkle> #action spredzy and clayton to work on parameter resources
15:20:11 <crinkle> #undo
15:20:12 <clayton> spredzy: I think this also potentially includes specifying old parameter names to the inifile provider, so that we can ease between versions better.
15:20:12 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x91f4050>
15:21:04 <crinkle> last action item from the summit worth mentioning is "make a BP for virtualenv support" which I think belongs to clayton or mfisch
15:21:42 <clayton> I'm not convinced we should actually do it, but I plan to investigate it further after we get our kilo upgrade done
15:21:46 <clayton> so you can assign it to me
15:22:09 <crinkle> #action clayton to investigate virtualenv support and possibly create a blueprint
15:22:32 <crinkle> is there anything else from the summit that anyone wants to bring up?
15:24:09 <spredzy> nop
15:25:04 <crinkle> #topic releases
15:25:44 <crinkle> We went way too long without doing a minor juno release, so I want to make sure we do that before we do a kilo release
15:26:00 <crinkle> I've been working on going through commits and backporting bugfixes and backwards-compatible features
15:26:11 <mfisch> thanks for that
15:26:37 <spredzy> +1 thanks
15:26:38 <crinkle> I've skipped the ones that are just updating tests and most of the ones that wouldn't cleanly cherry-pick
15:26:51 <crinkle> and probably just accidentally missed others
15:26:59 <Hunner> crinkle++ nice
15:27:14 <crinkle> so if you've made backwards-compatible commits this cycle it would help if you went back and cherry-picked your own commit
15:28:48 <crinkle> #info please help cherry-pick important bugfixes and backwards-compatible features to stable/juno for releases
15:29:49 <crinkle> wrt the kilo release, at the summit we said we wanted to wait for keystone v3 support (so please help richm, gildub, and ivan with that effort), is there anything else blocking the kilo release?
15:31:22 <crinkle> other configuration changes that we need to update for?
15:32:01 <mfisch> I'm sure there's more deprecations
15:32:05 <mfisch> did we land all the rabbit ones?
15:32:32 <crinkle> no, I still have to "revert "revert"" patches in my queue
15:32:35 <crinkle> two*
15:32:45 <clayton> I don't know that it should block, but I recently discovered that the auth_uri changes at least for neutron are broken.  That said, it doesn't appear that auth_host, auth_port etc were actually deprecated in kilo
15:32:56 <clayton> I suspect we may have the same problem in other modules
15:33:45 <crinkle> yuck
15:34:04 <clayton> I have a patch up to fix neutron, it'd be easy to check the other modules and do similar work there
15:34:29 <clayton> the issue is that the underlying provider hadn't been updated to use auth_uri if it was in the config file, it still assumes auth_host/etc are there.
15:35:02 <crinkle> oh, I saw that was fixed in one module
15:35:22 <crinkle> https://review.openstack.org/#/c/160845/
15:35:52 <crinkle> so that should be easy enough to fix?
15:36:40 <crinkle> clayton: since you did the work for neutron can you take the action to work on the other modules?
15:36:40 <clayton> yes, it's not a hard fix, my neutron review is here - https://review.openstack.org/#/c/186863/
15:36:53 <clayton> I wanted to get the neutron change merged first ;)
15:37:21 <crinkle> okay :)
15:37:25 <crinkle> #link https://review.openstack.org/#/c/186863/
15:37:48 <crinkle> #action clayton to help fix auth_uri issues in providers
15:38:16 <crinkle> #topic What to do about abandoned changes?
15:38:20 <crinkle> _ody: was this you?
15:38:30 <mfisch> I think so
15:38:43 <_ody> Yep.
15:39:29 <mfisch> I assume that there's some overall community policy or best practice here
15:39:45 <mfisch> Personally I just remove myself from the review list if I feel its not going anywhere
15:39:57 <_ody> Having them just sitting there made it a little confusing as I re-enter active involvment.
15:40:12 <crinkle> I'm not sure there is an overall policy
15:40:13 <mfisch> crinkle: can you find out what the rest of the community does?
15:40:54 <crinkle> mfisch: I don't think the other groups have agreed on a policy
15:41:53 <crinkle> I think this is the closest there is to a policy https://wiki.openstack.org/wiki/Documentation/ReviewGuidelines#Abandoning_patches
15:41:55 <mfisch> crinkle: not a polcy but a practice
15:42:42 <_ody> What are similar policies in the wild?
15:42:55 <_ody> Hunner: Does module team have a policy on pull requests?
15:43:04 <mfisch> I've not heard of one, I figured crinkle would be the best to ask some colleagues
15:43:09 <crinkle> I think the two camps are 1) it's not hurting anyone to let it sit there so let it sit, and 2) cores can clean it up after X time
15:43:20 <crinkle> we should decide which is better for our group
15:43:30 <Hunner> _ody: We close after 1 month of waiting on the other person
15:43:31 <mfisch> I think I'm in camp 1.5, but after a year, I think abandoning it is fine. They can always restore
15:43:41 <Hunner> Unless it's a special case
15:43:43 <mfisch> or even 6 months, its unlikely to be mergable anymore
15:44:10 <_ody> I prefer the latter...old stales reviews makes a project look less active than it is.
15:44:41 <Hunner> Yeah that's the thing... they become unmergable within a very short amount of time, and we get a LOT of drive-byes
15:44:50 <clayton> I prefer autoclose after some number of months
15:44:54 <Hunner> And drive-bys won't rebase
15:44:57 <crinkle> it was mentioned yesterday that an auto-abandoned change might have contributed to the kerfluffle we had last week, where a change was abandoned and a newer contributor didn't know how to restore it to keep working on it
15:45:33 <_ody> crinkle: What was the basis for the auto-abandon?
15:45:58 <crinkle> _ody: back then patches would get auto-abandoned after having a -1 for one week
15:46:05 <_ody> ah.
15:46:09 <mfisch> -1 on that
15:46:15 <_ody> yeah, really.
15:47:42 <Hunner> I wouldn't base the abandon on +1/-1 etc. Just months of inactivity
15:47:52 <mfisch> I have no issue closing an unmergable change > 1 year old, but I might comment on it first and ask if they intend to work on it more
15:47:59 <mfisch> even 6 months is probably ok
15:48:30 <crinkle> do we want to agree on a timeline for that? 6 months?
15:48:31 <Hunner> Oh yeah, we comment asking for further action planned, and if > 1 month no response then we close
15:48:49 <spredzy> I tend to agree w/ 6 month (a cycle)
15:48:49 <_ody> I'd totally being willing to get you down to 3 months but would be ok with 6.
15:48:50 <Hunner> 6 months sounds good to start, and can shorten if there is no difference between 1 month or 6
15:48:58 <clayton> I agree with cody
15:49:08 <mfisch> wfm
15:49:12 <Hunner> or 3 or 6... I bet longer times won't actually make more than a 5% difference
15:49:17 <clayton> do we control the wording of the auto-abandon email they get?
15:49:32 <mfisch> I'd give 1 week for them to respond to the "Are you still working on this"
15:49:40 <crinkle> I don't think we should auto-abandon, we should manually abandon
15:49:49 <_ody> crinkle: Agreed.
15:49:58 <crinkle> so a human has to go through and send a message saying "are you still working on this?"
15:49:58 <mfisch> agree, we can alsways iterate on this
15:50:08 <clayton> ah, ok, I see.
15:50:24 <mfisch> so a little birdie just recommended this tool to me: https://github.com/openstack/nova/blob/master/tools/abandon_old_reviews.sh
15:50:37 <mfisch> could be tweaked ^
15:50:50 <Hunner> +1
15:51:47 <mfisch> can we move on?
15:52:01 <crinkle> I don't really think it's necessary to automate it, there aren't that many that need to be abandoned and it's more friendly if there's a custom message
15:52:35 <crinkle> I can write up an email to the ml to propose a policy and then formalize it in the wiki, sound good?
15:52:39 <mfisch> +1
15:52:47 <_ody> +1
15:52:58 <mfisch> #action crinkle to propose review abandonment policy
15:53:06 <crinkle> thanks
15:53:23 <crinkle> #topic Discussing the sync_db uniformization effort
15:53:33 <crinkle> #link https://review.openstack.org/#/c/185601/
15:53:44 <crinkle> was this spredzy ?
15:53:49 <spredzy> crinkle, yes
15:54:06 <spredzy> During the summit we mentioned that we should work toward a common user experience across all modules
15:54:20 <spredzy> And this sync_db is the first step I wanted to take
15:54:40 <spredzy> By having it the way it is, we can add the ::sync_db class in the composition layer
15:54:53 <spredzy> since they are now in their own classes
15:55:08 <spredzy> so 1. I wanted to have feedback from people
15:55:18 <spredzy> and 2. wnated to know the thought ofthe community about clayton review
15:55:51 <clayton> I don't feel strongly about the path issue, but it's something we may want to agree on separately
15:56:37 <spredzy> If you guys tend to agree with it could you review it so I can move on with the change in all subsequent reviews
15:57:09 <crinkle> I think mgagne had a concern that wrapping an exec in a defined type doesn't really accomplish that much, and I tend to agree
15:58:00 <spredzy> Well doing that if we need to change anything arund this exec you just do it in one spot
15:58:23 <spredzy> Dan mentioned refreshonly was useless then basicaly you just change it at a single spot
15:58:34 <spredzy> same thing if we want to add thing on top of it
15:58:57 <crinkle> spredzy: we're running out of time, could you email the list about this?
15:59:08 <clayton> crinkle: I do think having a type for it ends up with cleaner looking deps in the modules themselves.
15:59:24 <spredzy> crinkle, sure
15:59:29 <clayton> but clearly opinions on that can differ
15:59:31 <crinkle> we already have things like http://git.openstack.org/cgit/stackforge/puppet-keystone/tree/manifests/db/sync.pp
15:59:51 <crinkle> #action spredzy to request feedback on db_sync type on ml
16:00:04 <crinkle> #topic Fix release bugs
16:00:06 <spredzy> crinkle, look at https://github.com/stackforge/puppet-openstacklib/blob/master/manifests/db/postgresql.pp
16:00:20 <spredzy> so I thought it was the objective of openstacklib (will mail the ML)(
16:00:33 <crinkle> thanks spredzy
16:00:49 <mfisch> we're out of time
16:01:01 <mfisch> would like to cover bugs and milestones next week
16:01:09 <crinkle> okay
16:01:13 <crinkle> #endmeeting