15:00:57 <EmilienM> #startmeeting puppet-openstack
15:00:58 <openstack> Meeting started Tue Jun  9 15:00:57 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:59 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:01:03 <openstack> The meeting name has been set to 'puppet_openstack'
15:01:15 <EmilienM> hello, how is here today?
15:01:25 <EmilienM> who is here, err
15:01:32 <crinkle> o/
15:01:34 <spredzy> hey
15:01:48 <clayton> here
15:02:07 <richm> here
15:02:13 <EmilienM> #topic review past actions
15:02:26 <EmilienM> spredzy submit a review in openstack-infra to integration the cookiecutter templates
15:02:34 <EmilienM> done: https://review.openstack.org/#/c/188929/ and https://review.openstack.org/#/c/189216/
15:02:59 <EmilienM> spredzy, clayton create a POC and send an email to the ML about parameter default policy
15:03:06 <spredzy> well second link is about msync
15:03:21 <EmilienM> spredzy: it comes together :-)
15:03:21 <spredzy> EmilienM, we haven't talk about it this week, need to postpone to next week
15:03:28 <EmilienM> oh ok
15:03:42 <EmilienM> clayton to investigate virtualenv support and possibly create a blueprint
15:04:02 <clayton> I won't be able to work on that until after we finish our kilo upgrades, probably a week or two
15:04:07 <EmilienM> ok
15:04:15 <EmilienM> clayton to help fix auth_uri issues in providers
15:04:30 <EmilienM> clayton: I've seen a patch, I think it's WIP, right?
15:04:34 <clayton> I think you've seen this one, I put up a review, but there is another one already
15:04:37 <mgagne> o/
15:04:40 <clayton> I'll likely end up abandoning mine
15:04:53 <EmilienM> #link https://review.openstack.org/#/c/186863/
15:05:02 <EmilienM> crinkle to propose review abandonment policy
15:05:08 <EmilienM> we have an agenda topic, ^
15:05:15 <EmilienM> and spredzy to request feedback on db_sync type on ml
15:05:19 <EmilienM> same, agenda topic ^
15:05:21 <EmilienM> so let's start
15:05:25 <EmilienM> #topic CI status
15:05:36 <EmilienM> #link https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit#gid=0
15:05:54 <EmilienM> beaker is in pretty good shape, we have coverage for most important modules
15:06:05 <EmilienM> thanks crinkle and sbadia for your help
15:06:24 <EmilienM> puppet4 now: sbadia, cody?
15:06:47 <EmilienM> cody has a patch WIP for neutron
15:07:00 <crinkle> _ody usually has conflicts with this meeting
15:07:09 <EmilienM> ok np, I'll catch-up with him
15:07:24 <EmilienM> and I talk on  behalf of sbadia (afk), he's doing swift atm
15:07:28 <EmilienM> anything else on CI ?
15:07:44 <EmilienM> #action cody to finish neutron patch
15:07:59 <EmilienM> #action sbadia to patch swift module for puppet4
15:08:13 <EmilienM> #topic Fix released bugs
15:08:23 <EmilienM> crinkle: o/
15:08:32 <crinkle> mfedosin: ^
15:08:34 <crinkle> mfisch:
15:08:37 <crinkle> sorry
15:08:52 <mgagne> has a new version been released/tagged?
15:09:01 <EmilienM> mgagne: not yet
15:09:01 <crinkle> not yet
15:09:32 <EmilienM> ok, mfisch is not here I think let's catch-up later in the release topic
15:09:35 <crinkle> mfisch: might be in standup, could move this to later in the meeting
15:09:48 <EmilienM> #topic Decision about Abandoned reviews policy
15:09:50 <EmilienM> crinkle: o/
15:10:05 <EmilienM> sounds like mailing list was useful
15:10:17 <crinkle> okay, so we started discussing it on the mailing list but i'm not sure we really got anywhere
15:10:21 <crinkle> lots of different opinions
15:10:25 <mgagne> true
15:10:28 <_ody> o/
15:10:32 <crinkle> o/
15:10:32 <mgagne> is there a common ground?
15:10:43 <mgagne> should we use the abandon change or not? (auto or manual)
15:11:40 <crinkle> my preference is to abandon as infrequently as possible
15:11:51 <crinkle> many other opinions shared were pro-abandonment
15:11:59 <EmilienM> I understand big projects have auto-abandon, but do we need that?
15:12:16 <crinkle> i don't think we have nearly enough traffic for that
15:12:18 <EmilienM> crinkle: though we have some very old patches sometimes. Do we really care?
15:12:20 <richm> probably best to be consistent with other openstack projects
15:12:35 <crinkle> there isn't an openstack-wide policy
15:12:39 <EmilienM> richm: first we would need to check if they all apply this policy.
15:12:42 <crinkle> so there's nothing t obe consistent with
15:12:50 <EmilienM> crinkle: good to know
15:12:51 <mgagne> should this one be abandoned? https://review.openstack.org/#/c/93990/
15:12:57 <mgagne> Updated May 17, 2014 10:58 AM
15:13:28 <EmilienM> I don't think so
15:13:28 <crinkle> it has no -1 or -2
15:13:31 <crinkle> it should be reviewed
15:13:37 <EmilienM> and rechecked against CI.
15:13:42 <crinkle> oh but for puppet-openstack
15:13:43 <mgagne> we deprecated puppet-openstack a long time ago
15:13:44 <EmilienM> and rebase
15:13:49 <EmilienM> oh true
15:13:51 <EmilienM> so yeah
15:14:26 <mgagne> IMO we shouldn't have any change older than a month or 2. Our policy should derivate from that requirement
15:14:55 <EmilienM> I'm also in favor of this, but it might be too strict for our community.
15:15:09 <mgagne> 1-2 months without update
15:15:14 <EmilienM> some patches are not landed just because nobody reviewed them
15:15:29 <mgagne> could be a comment to poke the original author
15:15:34 <crinkle> my concern is that it is hard for someone who is not core and not the author to restore an abandoned change, so we could lose work that might otherwise be valuable or someone could accidentally repeat someone else's work
15:15:41 <EmilienM> if the patch does not pass CI or has negative reviews, I'm in favor of abandon it
15:16:14 <mgagne> why can't anyone un-abandon a change?
15:16:29 <crinkle> mgagne: gerrit acls don't let them
15:16:33 <EmilienM> it's a policy in gerrit
15:16:35 <mgagne> crinkle: why not?
15:16:41 <EmilienM> crinkle: we could patch that.
15:16:46 <mgagne> crinkle: it's just an acl
15:16:54 <Hunner> This is why I think a human should be involved; we don't want them abandoned because it was never reviewed
15:17:02 <mgagne> crinkle: if there is an ack for a reason, I would like to know about it
15:17:02 <crinkle> mgagne: as fungi explained to me it's because it's attached to the same thing that lets them abandon other people's changes
15:17:16 <EmilienM> this topic was about to take a decision, I feel like we need more discussion each others and the mailing list would be useful to save our meeting
15:17:20 <mgagne> crinkle: oh, that makes sense then
15:17:40 <Hunner> Autoclose for not-passing or negative-reviews may be fine though
15:18:11 <crinkle> Hunner: but sometimes there's something with a -1 that's just nearly good enough, but the author moves on
15:18:13 <EmilienM> crinkle: indeed, that would be against our review policy
15:18:14 <fungi> right, the acl permission in gerrit for abandon and restore are the same setting
15:18:44 <Hunner> crinkle: At PL we still close those; we just don't have the bandwidth to deal with "nearly good enough" as much as I would like to :(
15:18:53 <EmilienM> crinkle: well, the author can also ask us to restore it...
15:18:54 <fungi> it's specifically because of the fact that it grants abandon control that we limit it to the change owner and core reviewers of the repo
15:19:20 <crinkle> EmilienM: that's true but if it's a weekend or they're new and don't know that's available then it's hard
15:19:34 <EmilienM> the question is: do we have the bandwidth to manage old patches ?
15:19:39 <fungi> in prior versions of gerrit it was limited to the change owner and not configurable, so the fact that we can now allow it for the core reviewers as well is a big improvement in usability
15:19:54 <EmilienM> automation could really help us
15:20:09 <crinkle> EmilienM: i think there are enough of us that we can, and having them around in the queue for a while while we wait for free time doesn't hurt anything
15:20:13 <EmilienM> fungi: good to know, thx
15:20:22 <crinkle> thank you fungi
15:20:26 <fungi> you're welcome!
15:20:43 <EmilienM> crinkle: ok. Let's start by your solution #2 and see how it works.
15:21:13 <EmilienM> crinkle: if we realize it does not work for us and we need automation, well... #3 with some communication to our community will be chosen
15:21:18 <EmilienM> what do you think?
15:21:21 <crinkle> wfm
15:21:28 <_ody> +1
15:21:47 <crinkle> i can send that to the mailing list
15:21:55 * EmilienM is waiting for mgagne's -1/+1
15:22:05 <_ody> We all around probably need to be more willing to pick up abandoned changes too and just get them merged.
15:22:14 <mgagne> sorry, got distracted
15:22:23 <mdorman> +1 on #2 and see how it goes.
15:22:24 <mgagne> tbh, I'm fine with the popular opinion
15:22:38 <EmilienM> ok
15:22:54 <EmilienM> #action crinkle to close this ML thread and explain our decision
15:22:59 <EmilienM> crinkle: anything else about that?
15:23:03 <crinkle> nope
15:23:18 <EmilienM> #topic releases
15:23:48 <EmilienM> first question: does anyone want to cherry-pick something or are we good now? ( crinkle did a lot of backports lately)
15:24:03 <mgagne> crinkle: tyvm for that great work
15:24:12 <EmilienM> yeah
15:24:12 <crinkle> i skipped a bunch that didn't cherry-pick cleanly
15:24:23 <EmilienM> crinkle: btw we broke keystone
15:24:31 <EmilienM> #link https://review.openstack.org/189742
15:24:38 <EmilienM> but out of context
15:24:44 <Hunner> crinkle++ for doing that
15:24:48 <crinkle> EmilienM: :(
15:24:53 <EmilienM> ok, if no more cherry picks, please review the patches from crinkle
15:25:11 <EmilienM> when everything is merged, we will hopefully make a Juno release
15:25:34 <EmilienM> for Kilo, we are waiting for keystone v3 only iirc
15:25:39 <EmilienM> richm: o/
15:26:10 <richm> yes
15:27:01 <EmilienM> crinkle, richm: do you think it's reasonable to wait until keystone v3 is merged before doing a kilo release?
15:27:23 <EmilienM> that means puppet-openstacklib,keystone (and also all provider?)
15:27:44 <_ody> Are we down to simple review or is what remains able to be split up among more people?
15:28:03 <richm> keystone v3 (for all modules) depends on 1) use openstack 2) use auth restructure code
15:28:22 <richm> the current patches do 1) and 2) for puppet-keystone only
15:28:34 <richm> there is a puppet-glance patch to do 1)
15:28:56 <EmilienM> richm: is it required to patch other modules or can it work without the patches for now?
15:29:18 <EmilienM> we have a lot of providers afik...
15:29:20 <richm> it "works" for some value of "works"
15:29:21 <crinkle> i think just openstacklib and keystone is fine
15:29:35 <richm> "works" == installs with basic defaults
15:29:45 <richm> "works" != every openstack component can use v3 auth everywhere
15:29:46 <EmilienM> crinkle: ok. So it won't break other modules providers, right?
15:29:51 <crinkle> no
15:29:54 <EmilienM> richm: ok
15:30:00 <EmilienM> lgtm for now
15:30:05 <EmilienM> for a first kilo release I mean
15:30:32 <EmilienM> so if you agree, we wait for keystone/openstacklib patches merged and we release our first Kilo
15:30:48 <richm> works for me
15:31:04 <EmilienM> just an highlight to people here, this is a huge feature useful for anyone. Reviews and testing are welcome :-)
15:31:42 <richm> I would also appreciate a review of the bp
15:31:52 <EmilienM> I consider silence as a yes :)
15:31:53 <mdorman> so tehse are any keystone v3 related reviews on openstacklib or keystone module, right?  are their multiples, or just one each?
15:31:53 <richm> I think it is ready
15:32:06 <_ody> We need the v3 support just to go production with our OpenStack deployment at PL.
15:32:07 <richm> openstacklib - one review
15:32:12 <EmilienM> mdorman: we have a lot of patches, defined in topics
15:32:19 <richm> openstack-specs - one review - bp
15:32:25 <richm> puppet-keystone - many, many reviews
15:32:28 <EmilienM> _ody: everyone does I think :)
15:32:30 <mdorman> kk
15:32:39 <richm> the topic for all of these is bp/api-v3-support
15:32:40 <EmilienM> ok let's move on
15:32:55 <EmilienM> anything else richm on v3 ?
15:33:07 <richm> EmilienM: no
15:33:17 <EmilienM> richm: thanks!
15:33:20 <EmilienM> #ŧopic openstacklib::db::sync proposal and decision
15:33:42 <EmilienM> spredzy: o/
15:34:13 <spredzy> So I'd like simply to open a vote there based on what I said on the ML
15:34:23 <spredzy> vote doesn't have to take place now, but rather in the ML
15:34:30 <EmilienM> #ŧopic openstacklib::db::sync
15:34:34 <spredzy> so we can move forward with that
15:34:41 <EmilienM> topic does not change anyway
15:35:12 <crinkle> hmm
15:35:38 <EmilienM> mgagne: don't you like what spredzy suggests, having the exec in openstacklib itself for consistency?
15:36:39 <mgagne> EmilienM: I think I explained myself on the ML: it adds little value for the amount of work required
15:36:52 <crinkle> i'm with mgagne, it doesn't provide a lot of value
15:37:01 <EmilienM> well, it adds consistency at least
15:37:03 <crinkle> an exec has a consistent interface on its own
15:37:10 <EmilienM> ok
15:37:20 <mgagne> unless you come up with an actual use case you can't realize with it, then I don't see why
15:37:23 <mfisch> sorry guys I'm here now
15:37:26 <spredzy> point is mainly not about the exec, but have a common resource across every module to do one thing
15:37:29 <mgagne> what crinkle said
15:37:34 <spredzy> I understand mgagne point here
15:38:18 <spredzy> but the idea is that if someone brings on a new module this person knows for the db sync action it will be openstacklib::db::sync, the same way it is for mysql (ie. openstackli::db::mysql)
15:38:25 <spredzy> for keystone, rabbitmq, etc...
15:38:34 <mgagne> and you still have to make the interface consistent across all modules anyway, even if you have a common one and update it, you will still have to update all the modules to benefit from it, it's not magic
15:38:44 <spredzy> just giving a common resource that does one thing and only onething acoss every module
15:39:30 <mgagne> isn't called an exec?
15:39:36 <spredzy> mgagne, that is correct, but again this is true for every openstacklib:: component
15:39:41 <mgagne> no
15:39:49 <mgagne> didn't you read my latest answer?
15:40:04 <mgagne> there is NO logic in db::sync, it's just rebranding an exec resource
15:40:21 <mgagne> for the sake of having common code
15:41:32 <spredzy> I don't deny that, but it is indeed for the sake of having common code so every module can rely on a meaning full classes name
15:41:43 <mgagne> we could argue that openstacklib::service::install would be a great idea too because we are installing stuff with package resource everywhere and have package_ensure too. so lets create openstacklib::service::install($package_name, $package_ensure) then
15:41:56 <spredzy> again if most of you thinksits not worth it we can go with #2
15:42:07 <EmilienM> mgagne: +1 with that
15:42:37 <spredzy> just moving everythin under CLASS::db::sync for the db_sync
15:42:44 <EmilienM> ok
15:42:56 <mgagne> yes, that would be a great change
15:43:11 <EmilienM> spredzy: can you close the thread with the decision and maybe send a patch as reference?
15:43:31 <spredzy> #action spredzy Send a patch as an implementation reference
15:43:47 <spredzy> #action Send an email on the ML to let community know the final word on that thread
15:43:48 <EmilienM> spredzy: thanks!
15:44:10 <EmilienM> well, I don't like final :-) but if it works now, let's go like this
15:44:19 <EmilienM> #topic move git repos under openstack
15:44:28 <EmilienM> w00t topic changed !!!
15:44:49 <EmilienM> the patch in project-config is here: https://review.openstack.org/#/c/176326/
15:44:51 <EmilienM> #link https://review.openstack.org/#/c/176326/
15:44:54 <mgagne> I have to go now, +1 for that change if redirections are put in place
15:45:01 <EmilienM> and the blueprint https://review.openstack.org/#/c/189388/
15:45:08 <EmilienM> mgagne: of course it will
15:45:12 <mgagne> cool, thanks
15:45:19 <EmilienM> #link https://review.openstack.org/#/c/189388/
15:45:26 <EmilienM> please review  https://review.openstack.org/#/c/189388/ before https://review.openstack.org/#/c/176326/
15:45:34 <EmilienM> we need to agree on "compliant" modules
15:46:09 <EmilienM> basically, the modules we test with beaker or/and tripleo + puppet-tripleo which is part of tripleo itself, so it makes sense to move it too
15:46:37 <EmilienM> after all of this, I'll make sure redirections work and also openstack/governance is updated.
15:46:54 <EmilienM> I'm also working on the blueprint that we discussed during the summit about "what is a compliant module"
15:47:28 <EmilienM> please don't hesitate to review these patches on Gerrit, that would be useful to move forward on this
15:47:41 <EmilienM> any thoughts about that?
15:48:16 <crinkle> the list looks reasonable to me
15:48:36 <EmilienM> ok. Let's move on then. We have mfisch here, let's re-open #Fix released bugs
15:48:42 <EmilienM> #topic Fix released bugs
15:48:44 <EmilienM> mfisch: o/
15:48:59 <mfisch> hey ok
15:49:16 <mfisch> so the first part is that we have a ton of bugs marked as FC (Fix Committed)
15:49:27 <mfisch> I went through and moved them to FR for a few projects
15:49:36 <mfisch> keystone, glance, and maybe cinder?
15:49:50 <mfisch> we might need to crowdsource the rest of that its pretty tedious
15:50:00 <mfisch> I typically mark them to a release
15:50:19 <mfisch> which is the 2nd part, we need a new release created in all the projects
15:50:36 <mfisch> not sure who does that maybe mgagne ?
15:50:51 <EmilienM> mfisch: he's afk now
15:51:00 <mfisch> I can follow-up on the ML
15:51:03 <EmilienM> yeah
15:51:17 <mfisch> I also marked invalid or incomplete a bunch of stuff
15:51:23 <EmilienM> before doing liberty target, we might want to release kilo, no?
15:51:37 <mfisch> if we're going to be welcoming to new members we need to watch the bugs
15:51:40 <EmilienM> mfisch: thanks a lot for that. I'll give a hand on this later this week
15:51:58 <mfisch> well we could add the L target whenever, I just wanted to find out who did it
15:52:03 <EmilienM> mfisch: it is supposed to be part of our tasks.
15:52:05 <mfisch> I'll write up a ML item about all this today
15:52:16 <EmilienM> mfisch: awesome
15:52:21 <crinkle> thanks for doing that mfisch
15:52:45 <EmilienM> mfisch: maybe in your email you can ask for help to the core group
15:52:55 <mfisch> some projects went from 30 bugs to 8
15:52:56 <mfisch> nice to see
15:53:02 <EmilienM> \o/
15:53:02 <crinkle> \o/
15:53:29 <EmilienM> I think we are done with the agenda
15:53:37 <EmilienM> #topic open discussion (no troll please)
15:53:49 <EmilienM> no troll because it's not Friday
15:54:00 <EmilienM> but feel free to share your patches/bugs/thoughts here
15:54:09 <EmilienM> we have 7 min left
15:54:48 <EmilienM> I have one, https://review.openstack.org/#/c/189742/ (a backport from crinkle that seems breaking keystone/juno)
15:55:08 <mfisch> whats the break?
15:55:35 <EmilienM> mfisch: keystone does not start, it can't find the file. see bug report
15:55:41 <EmilienM> #link https://launchpad.net/bugs/1463358
15:55:42 <openstack> Launchpad bug 1463358 in puppet-keystone "default value of paste_config breaks apache+wsgi on Ubuntu" [High,Confirmed]
15:56:02 <EmilienM> I think it's not only wsgi but all keystone
15:56:56 <dougwig> o/
15:57:21 <dougwig> any gslb folks here today?
15:57:31 <crinkle> EmilienM: time to end the meeting
15:57:36 <dougwig> oops, sorry
15:57:47 <mfisch> EmilienM: I'll look at it today
15:58:00 <EmilienM> #endmeeting