14:02:08 <EmilienM> #startmeeting puppet-openstack
14:02:09 <openstack> Meeting started Mon Feb  9 14:02:08 2015 UTC and is due to finish in 60 minutes.  The chair is EmilienM. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:10 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:02:12 <crinkle> er yes
14:02:12 <openstack> The meeting name has been set to 'puppet_openstack'
14:02:16 <EmilienM> #topic Review last week's Action items
14:02:23 <EmilienM> spredzy sent an email on the ML to communicate about the trello -> done
14:02:23 <EmilienM> crinkle to post puppet-openstack slides to the ML -> DONE (slides are shared)
14:02:23 <EmilienM> Core-team to review and reduce backlog - http://goo.gl/L6eDRe
14:02:23 <EmilienM> sbadia gardening in the launchpad bugs
14:02:23 <EmilienM> People should review https://review.openstack.org/#/c/150108/ - still WIP
14:02:57 <EmilienM> sbadia: all items have been addressed except the LP - any update?
14:03:09 <sbadia> for LP bugs, it's a wip, with matt)
14:03:18 <EmilienM> ok
14:03:19 <sbadia> matt was added to the bug team
14:03:24 <EmilienM> great thing
14:03:39 <EmilienM> crinkle: you can roll the next topic !
14:03:44 <sbadia> and for openstack LP team, I suggested to dan to give the owner bit to colleen
14:03:55 <crinkle> EmilienM: I think the chair has to #topic
14:03:59 <EmilienM> ok
14:04:04 <EmilienM> #topic keystone v3
14:04:24 <EmilienM> #link Blueprint WIP: https://review.openstack.org/#/c/150108/
14:04:37 <EmilienM> crinkle: any details?
14:04:50 <crinkle> it's still WIP from richm afaik
14:05:20 <crinkle> I left some questions on the blueprint patch
14:05:34 <crinkle> so far I think it's looking good
14:06:32 <EmilienM> great
14:06:54 <EmilienM> I think we can move forward
14:07:02 <crinkle> okay
14:07:12 <EmilienM> #topic summit
14:07:31 <EmilienM> dprince and I submitted a presentation about TripleO and Puppet
14:07:49 <EmilienM> that means we have 2 talks (registered) related to Puppet
14:07:57 <EmilienM> #link TripleO/Puppet #link https://etherpad.openstack.org/p/tripleo-puppet-vancouver-summit-proposal
14:08:27 <crinkle> I've submitted a talk on the puppet providers
14:08:35 <EmilienM> oh great
14:08:39 <EmilienM> crinkle: any link?
14:09:08 <crinkle> #link https://docs.google.com/document/d/1xQnfp2HAE7VKW3DzGhypDJOZiOWMVkkVxbiqLus5K-g/edit?usp=sharing
14:09:11 <crinkle> sorry it's in google
14:09:49 <EmilienM> looks cool
14:10:41 <sbadia> yup +1!
14:11:07 <crinkle> next?
14:11:48 <EmilienM> crinkle: I think it's early to start talking about design sessions
14:12:04 <EmilienM> so #summit is closed except if someone else wanted to say something
14:12:24 <EmilienM> crinkle: I don't have any other topic, we can start open discussion maybe
14:12:33 <crinkle> EmilienM: there are more topics in the wiki agenda
14:12:48 <EmilienM> oops
14:13:07 <EmilienM> indeed
14:13:12 <EmilienM> #topic  Future parser support
14:13:30 <crinkle> So puppet 4 is around the corner and I'd like the modules to be ready
14:13:53 <crinkle> so I added a card to the trello board for future parser support
14:14:20 <mdorman_> FYI I use the future parser extensively and for the most part things are fine I think
14:14:21 <crinkle> it would be good for someone to go through the modules with the future parser turned on and correct errors
14:14:25 <crinkle> oh good
14:14:26 <dvorak> this came up over the weekend, this might be worth doing as in intermediate step - http://www.camptocamp.com/actualite/getting-code-ready-puppet-4/
14:14:50 <dvorak> has lints to some puppet-lint extensions that check puppet4 compat items
14:14:55 <dvorak> err, links :)
14:15:31 <nibalizer> we could add a puppet future parser syntax validation test to jjb as well
14:16:09 <dvorak> I agree that's what we want to long term, just figured if there are a lot of failures, then the lint checks might be a way to break it up into smaller units of work
14:16:13 <EmilienM> nibalizer: maybe as non-voting to start
14:16:46 <nibalizer> are the dependecy modules (mysql, mongo, etc ) future compatible?
14:17:09 <crinkle> mysql/postgresql are, unsure about mongo/rabbitmq
14:17:52 <mdorman_> I can say that I'm pretty sure rabbit is good
14:18:00 <crinkle> cool
14:19:01 <EmilienM> crinkle: maybe we could ensure travis is testing it on dep modules before all
14:19:39 <crinkle> EmilienM: oh that reminds me why this is tricky
14:19:45 <crinkle> I think it requires rspec-puppet 2.0
14:19:54 <crinkle> so we need to fix our tests to run with rspec-puppet 2.0
14:19:58 <crinkle> and unpin it
14:20:01 <EmilienM> hehe
14:20:21 <sbadia> :-) (I'm working on it)
14:20:40 <crinkle> so work items are 1) fix rspec tests for new rspec-puppet, 2) add jenkins job to test on future parser
14:20:49 <crinkle> and if mdorman_ is right then there shouldn't be much work after that
14:21:07 <sbadia> agreed
14:21:15 <EmilienM> sbadia: any status/progress?
14:21:19 <crinkle> and I'll look into getting the puppetlabs modules on rspecpuppet 2.0 and testing on future parser
14:21:46 <EmilienM> sbadia: I see https://trello.com/c/eHXc1Ryd/4-investigate-the-necessary-change-to-be-rspec-puppet-2-0-0-compliant
14:22:03 <sbadia> EmilienM: I just finished ou composition layer, but it's not related to puppet-openstack team :)
14:22:10 <mdorman_> I can only speak for the mods I actually use, but if that subset is any indication I think the rest of them should be minor fixes
14:22:11 <EmilienM> crinkle: sounds like a good plan
14:22:21 <sbadia> EmilienM: I think I can finish this for this week
14:24:11 <EmilienM> crinkle: are we done with this topic? seems like we have a plan
14:24:19 <crinkle> #action sbadia to fix rspec-puppet tests
14:24:40 <crinkle> #action someone (nibalizer) to add jjb for future parser
14:24:43 <crinkle> okay done
14:24:59 <EmilienM> #topic Minor releases
14:25:14 <crinkle> I was wondering whether we should make minor releases
14:25:22 <crinkle> it's been kind of a while since 5.0
14:25:28 <crinkle> but I know we're still working on keystone v3 support
14:25:38 <crinkle> so should we wait for that or make releases soonish?
14:26:33 <dvorak> I'd say it depends on the number of backports there have been
14:27:26 <dvorak> Unfortunately I think it's hard to say without going through them and seeing if people might be effected, or if the backports are more cosmetic things like Gemfile fixups
14:28:24 <crinkle> for keystone there have been quite a bit of backports, for others there has been less development
14:28:33 <crinkle> so probably wait a bit then
14:28:49 <mfischer> Sorry I'm late
14:28:49 <dvorak> it's about halfway through the cycle, that seems like a reasonable time to start thinking about it though
14:28:51 <EmilienM> crinkle: I would wait until Kilo release
14:29:14 <crinkle> EmilienM: we don't want to never release minor releases
14:29:25 <EmilienM> crinkle: ah minor, indeed
14:29:36 <crinkle> sorry, yes minor
14:30:12 <EmilienM> I would go for it now
14:30:37 <EmilienM> there is no huge blocker
14:30:50 <EmilienM> crinkle: our modules are in good shape now, so why not?
14:31:25 <crinkle> well as dvorak pointed out there haven't been that many changes except in keystone
14:32:25 <EmilienM> ok so no minor release then..
14:32:36 <crinkle> i think wait a few more weeks
14:32:43 <EmilienM> ok
14:32:44 <EmilienM> crinkle: anything else?
14:32:54 <crinkle> #action revisit minor releases in a few weeks
14:32:57 <crinkle> EmilienM: not for me
14:33:03 <EmilienM> #topic Open Discussion
14:33:31 <dvorak> I'd like to get people's thoughts on non-vendor packaging.  What do people think about supporting tools like giftwrap, or virtual envs?
14:33:57 <EmilienM> dvorak: how is it related to Puppet/OpenStack ?
14:34:00 <dvorak> I realize it's potentially a mine field, since there are a million ways to do it, but I think there are a fair number of operators doing their own thing in this area
14:34:11 <dvorak> EmilienM: supporting different package names and such
14:34:32 <crinkle> EmilienM: supporting it in the puppet modules
14:35:03 <crinkle> I think that would be cool
14:35:07 <crinkle> adds a lot of complexity though
14:35:23 <dvorak> We have a need to our own packaging and don't want to just copy what Canonical has, so I'm going to be doing some work on probably making giftwrap work with the designate module.  I'm curious if it's worthwhile to bother trying to keep that in contributable form
14:35:58 <dvorak> Designate doesn't really have packaging for anything but Debian, so I think there is more utility for projects not yet fully baked
14:37:20 <dvorak> I don't know if this is an issue for other newer projects or not
14:37:36 <crinkle> I think the tempest module uses virtualenvs
14:38:35 <sbadia> yep tempest module can use packages or git/virtualenvs
14:38:38 <EmilienM> crinkle: that you can disable - I dit the patch, because we have a package
14:38:41 <EmilienM> did*
14:39:35 <EmilienM> is there any action to take, can we go ahead?
14:39:52 <crinkle> I think dvorak is still looking for opinions
14:40:09 <EmilienM> it's a good thing to have imo
14:40:37 <crinkle> +1 from me
14:40:52 <dvorak> That's basically all I was looking for, was whether or not it's acceptable in theory.  I realize a lot of it depends on the details
14:41:24 <EmilienM> dvorak: do you want to run/continue the discussion on the ML so people can be involved in that work - it seems like we agree to have something like this in our modules
14:41:32 <dvorak> We're planning to go down this path for all of our services, but Designate is what we're doing in the short term as a test case
14:41:51 <dvorak> EmilienM: That seems reasonable
14:41:57 <EmilienM> great
14:42:09 <spredzy> On a different note, I was wondering if modulesync could support gerrit? (else how feasible would it be) so we could handle the Gemfile and dependencies in a single place for every modules. Since stackforge/puppet-* is getting bigger and bigger.  < crinkle ?
14:42:22 <EmilienM> #action dvorak starts discussion on ML about custom packaging support in our Puppet modules
14:42:43 <crinkle> spredzy: I'd love to accept a pull request to support gerrit, but I'm not sure how feasible it is
14:42:44 <dvorak> spredzy: +1
14:42:45 <mfischer2> That sounds like a good idea spredzy
14:42:46 <EmilienM> spredzy: +1
14:43:07 <EmilienM> or a puppet-requirements repo
14:43:13 <EmilienM> like they have with Python modules
14:43:28 <EmilienM> so our modules could fetch this repo to build puppetfile + .fixtures.yaml
14:43:31 <dvorak> I'd actually like it for mostly internal use :)
14:43:40 <spredzy> I can take a first look at it and then we can asses how feasible it is. I mean I am thanksfull for sbadia this week and the pinning of rspec-core, but this can be made much better
14:43:59 <spredzy> EmilienM, it seems that the puppet community is going with modulesync as a best practice
14:43:59 <sbadia> crinkle: it's only a git+ssh url
14:44:11 <spredzy> from what I can read online, so might be a good idea to follow it imo
14:44:36 <crinkle> sbadia: but the process of doing a git-review is different than just git-push
14:44:42 <crinkle> so it's a little more complicated
14:45:08 <sbadia> indeed
14:45:14 <dvorak> crinkle: git review is actually just a fancy wrapper around git push
14:45:24 <dvorak> you can actually just push to a special ref to submit the review
14:45:32 <spredzy> I'll create a card, and people can put their finding there, until we get to a nice PR for crinkle to merge
14:45:41 <sbadia> we can use internal gerrit refs/for/<branch>
14:45:45 <sbadia> but yes
14:46:13 <sbadia> spredzy: thx!
14:46:23 <spredzy> #action spredzy take a first look at how to integrate modulesync with gerrit
14:46:51 <EmilienM> w00t a lot of things this week :)
14:46:58 <crinkle> :)
14:47:02 <EmilienM> my brain starts to crash
14:47:06 <sbadia> \o/
14:47:53 <EmilienM> seems like we are ending the meeting
14:47:59 <EmilienM> if there is anything else, rise your hand!
14:49:04 <EmilienM> crinkle: sbadia: can I close?
14:49:13 <crinkle> sure
14:49:15 <sbadia> for me yes :)
14:49:18 <EmilienM> #endmeeting