15:00:01 <EmilienM> #startmeeting puppet-openstack
15:00:03 <openstack> Meeting started Tue Apr 21 15:00:01 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:06 <openstack> The meeting name has been set to 'puppet_openstack'
15:00:08 <spredzy> morning all
15:00:12 <EmilienM> #link https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150421
15:00:13 <sbadia> o/
15:00:16 <sbadia> hi
15:00:21 <EmilienM> who is here today?
15:00:24 <hogepodge> o/
15:00:25 <clayton> here
15:00:28 <jistr> o/
15:00:32 <dfisher> here
15:00:38 <crinkle> o/
15:00:40 <spredzy> here
15:00:44 <EmilienM> our agenda is *HUGE* - challenge accepted to make it
15:00:49 <EmilienM> #topic Review past action items
15:00:52 <mfisch> hi
15:01:03 <EmilienM> EmilienM to run a thread about Summit diner with Puppet OpenStack folks -> DONE
15:01:07 <gchamoul> o/
15:01:15 <EmilienM> EmilienM to run discussion about Puppet OpenStack naming
15:01:28 <EmilienM> #link http://lists.openstack.org/pipermail/openstack-dev/2015-April/061472.html
15:01:38 <EmilienM> we have an item later about naming
15:02:02 <EmilienM> well... I'm not going to show all past actions that are done
15:02:10 <EmilienM> we just want to know what is not done
15:02:20 <EmilienM> gchamoul: any follow-up for puppet-neutron to follow https://review.openstack.org/106144 for LB driver ?
15:02:22 <vinsh_> o/
15:02:50 <jpena> o/
15:02:57 <mgagne> o/
15:03:18 <gchamoul> EmilienM: I am on PTOs this week, wanted just to be here for the meeting! and will take care of it next week
15:03:24 <EmilienM> gchamoul: ack.
15:03:57 <EmilienM> #topic policy on when/why we will break the current release on master
15:04:16 <EmilienM> so we had a lot of discussion last week on IRC...
15:04:26 <mfisch> yes and on the ML
15:04:29 <EmilienM> yes
15:04:45 <EmilienM> so, spredzy and I are working on openstack-infra to provide a new feature
15:04:52 <EmilienM> #link https://review.openstack.org/#/c/175849/
15:05:00 <EmilienM> #link https://review.openstack.org/#/c/175850)
15:05:13 <EmilienM> the idea here is to perform the cherry-picks patches automatically
15:05:29 <mfisch> how would you keep stuff that breaks juno out?
15:05:42 <clayton> mfisch: I think the idea is to key it off of a commit tag
15:05:42 <EmilienM> we also had some inputs from crinkle about a new branch for staging. crinkle, wanna talk about it?
15:05:55 <crinkle> sure
15:06:30 <EmilienM> mfisch: if it breaks juno, well... don't backport it.
15:06:33 <crinkle> my friend pointed out to me that in other projects master should generally "work", and to that end some sort of "future" or "next" development branch could be created for kilo specific breaking changes
15:06:46 <mfisch> thats the whole point of deprecations
15:07:00 <mfisch> I mean thats why they deprecated those config options instead of just removing them like we did
15:07:48 <EmilienM> crinkle: the negative point of this is, we barely manage stable branches....
15:07:59 <crinkle> yes, branch management would be a little harder
15:08:18 <EmilienM> A good iteration for us would be to agree on a new policy of managing OS releases
15:08:48 <EmilienM> and I think that should be a spec
15:09:08 <mgagne> master is targeted at the next release, anyone relying on master to provision the latest stable branch shouldn't expect backward compatibility with previous stable branches. The only stability provided in with our interfaces (class parameters)
15:09:45 <EmilienM> mgagne: I do agree with you. The issue we have *now* is we aren't all agree
15:09:46 <mfisch> except that violates the whole point of deprecations in the other openstack projects
15:09:55 <clayton> this isn't just a master issue, it's also an issue moving between stable branches
15:10:02 <crinkle> I'm not saying provide backwards compatibility in master, I'm just saying someone should be able to check out master and run it without building special packages first
15:10:06 <mgagne> EmilienM: I think it has always been the case (that master targeted the next release)
15:10:16 <EmilienM> mgagne: it does.
15:10:27 <clayton> some of the deprecation issues could also be addressed by enhancements to the config file providers
15:10:45 <mgagne> clayton: sure but it was never meant to be that way
15:11:01 <mgagne> clayton: it's not "our process is broken", it's "wouldn't it be great if"
15:11:47 <EmilienM> mgagne: a blueprint (spec) would help here.
15:11:49 <mfisch> does any other openstack project intentionally break the current release on master?
15:12:02 <EmilienM> mfisch: not AFIK but it could happen
15:12:15 <crinkle> no other openstack project depends this much on distro packages that have this kind of release cycle
15:12:37 <clayton> mfisch: I'm not sure it's actually an issue for other projects per se.  I think the puppet modules are kind of unusual compared to existing projects.  I assume chef, ansible, etc would have similar issues
15:12:43 <mgagne> we have always been behind and always playing catch up. Now we are improving and making it earlier. I don't see why we should refrain ourselves from going forward with the latest release from master because someone expects to be able to install stable releases from master. It never was meant to be it.
15:12:57 <EmilienM> the thing is, if we don't upgrade master with new configuration updates, operators will have WARNINGs in logs everywhere
15:13:04 <mfisch> the cost tradeoff for that deprecation fix is not good for us
15:13:21 <mgagne> if we wish to change it, lets think about it. But I don't see master as "broken" if it can't install Juno.
15:13:27 <mfisch> it wasn't like that feature was required to make this work for Kilo
15:13:39 <mfisch> you traded a warning message on service startup for breaking Juno
15:13:42 <clayton> well, the problem right now is that master could easily be in a state where no one can install it other than vendors
15:13:45 <mgagne> mfisch: we are moving forward. Removing deprecation is part of the work to make it to kilo
15:14:11 <clayton> which is fine if you don't want anyone but vendors to do the work
15:14:12 <mfisch> so delay it 2 months and nobody would have a problem with it
15:14:26 <EmilienM> clayton: that's not the goal.
15:14:55 <mgagne> we are trying very hard to release it at the same time as the next release, not 2-3 months later like we did before
15:15:01 <Hunner> gerrit would have to test patches against multiple branches in this case
15:15:21 <mgagne> we have to stay ahead of the curve if we wish to stay relevant
15:15:28 <crinkle> the development branch would be able to keep those changes around and merged back at release time
15:15:45 <mgagne> master is the development branch.
15:16:00 <mgagne> if master is the "stable" branch, let's call it by what it is: stable
15:16:14 <clayton> for the time being, it might make more sense to see how much improvement we see with emiliens proposed change
15:16:21 <clayton> re: backports
15:16:33 <EmilienM> I would find a consensus that is consistent with OpenStack: follow deprecations & using master for current dev branch.
15:16:37 <EmilienM> clayton: do you like this idea?
15:16:41 <mgagne> people aren't happy with backports latency, we will have to figure out something else
15:16:54 <mgagne> or improve the situation somehow
15:17:00 <EmilienM> mgagne: well, the latency will be improved with what we are doing with yanis
15:17:44 <mfisch> I'd like to see if that helps
15:17:52 <EmilienM> are you guys ok if I start a blueprint and we continue the design/discussion on gerrit?
15:18:00 <clayton> EmilienM: makes sense to me
15:18:01 <mgagne> EmilienM: I was more or less suggesting making master compatible with (at least) one stable branch. If this is what people are expecting from master, we should consider it. But until it's done, we shouldn't revert stuff from master for that purpose.
15:18:04 <EmilienM> mfisch: me too, but without trying, who knows ?
15:18:18 <spredzy> good thing is that one can -1 the review until the commit message is happended for the backport thingy
15:18:29 <clayton> EmilienM: I think the backport stuff that's going on is potentialy a great improvement
15:18:37 <mfisch> agreed
15:18:39 <spredzy> this way it will be up to us as a community to enforce that a fix is backported
15:18:42 <EmilienM> cool, at least one positive thing here
15:18:56 <spredzy> fix/feature/whatever
15:19:00 <EmilienM> I have to deal with the timing. are you guys -1/+1 the blueprint idea?
15:19:07 <clayton> My only concern there is that people may forget to add the tag.  I'm not sure it's a good idea, but we may want to consider backport-potential tag mandatory.
15:19:10 <clayton> +1
15:19:47 <EmilienM> I'll bring-up an etherpad before to groom all our proposals
15:19:55 <mgagne> clayton: there is already a unique ID associated to each commit. When you cherry-pick, the Change id is kept. why not diffing master and stable branches and see what can be backported?
15:19:56 <Hunner> It may be odd getting a patch that can be applied cleanly to two branches...
15:20:14 <Hunner> Or will it just open another review if the patch is berged?
15:20:17 <mfisch> It will probably be better if we keep up with it
15:20:42 <clayton> mgagne: that'd probably be reasonable also, but we'll want to have some way to mark commits as evaluated for backport
15:21:13 <EmilienM> well, let's continue after the meeting with an etherpad + a blueprint.
15:21:24 <EmilienM> we need to go ahead in the agenda, I'm sorry.
15:21:29 <mfisch> ok
15:21:30 <nibalizer> o/
15:21:50 <EmilienM> #action EmilienM starts an etherpad (+ blueprint?) about deprecation/backport policy
15:22:02 <EmilienM> #topic modules style
15:22:04 <EmilienM> spredzy: o/
15:22:12 <EmilienM> #link https://etherpad.openstack.org/p/puppet_ensure_style_guide
15:22:25 <EmilienM> not sure yanis is still around
15:22:28 <spredzy> Yep, I wanted to expose a possible solutin ^
15:22:42 <spredzy> so it involes mgagne comment about making a puppet-lint-plugin per rule
15:22:55 <EmilienM> spredzy: can you raise the problem first ? :-)
15:23:00 <mgagne> spredzy: per rule? wth =)
15:23:12 <mgagne> spredzy: how about a generic plugin which our style like hacking?
15:23:18 <spredzy> Oops sorry. missing context
15:23:37 <spredzy> The initial idea was to provide an authoritaative document for style in our modules
15:23:49 <spredzy> so the same style is consistent across all of them
15:24:01 <mgagne> sure
15:24:01 <mfisch> I like the idea if we can phase it in
15:24:02 <clayton> The two proposals seem complementary.  The lint plugin could link to sections in the doc
15:24:09 <mfisch> +1
15:24:10 <mgagne> yep
15:24:13 <mgagne> +/
15:24:17 <mgagne> damn +1
15:24:17 <gchamoul> +1
15:24:19 <clayton> +1
15:24:25 <EmilienM> +1
15:24:33 <crinkle> +1
15:24:36 <sbadia> +1
15:24:39 <spredzy> so q1. Would you agree for rule to be reviewed as code ?
15:24:40 <jpena> +1
15:24:42 <EmilienM> sounds like a good proposal
15:24:47 <spredzy> so discussions can take place in a review
15:24:55 <gchamoul> ack
15:25:05 <EmilienM> spredzy: yes, would make sense to have it in specs I think
15:25:29 <spredzy> ok, since everyone seems to be ok with it we can move on
15:25:38 <EmilienM> spredzy: thanks
15:25:39 <spredzy> will try to provide a basic example soon
15:25:48 <EmilienM> #topic https://bugs.launchpad.net/puppet-nova/+bug/1274979
15:25:49 <EmilienM> mgagne: o/
15:25:50 <openstack> Launchpad bug 1274979 in puppet-swift "Introduce public_url, internal_url and admin_url parameters for endpoint configuration" [Undecided,New] - Assigned to David Moreau Simard (dmsimard)
15:26:05 <mgagne> yep, I would like people to reconsider that proposition
15:26:25 <mgagne> it's about removing the plethora of parameters in *::keystone::auth for more simple ones
15:26:34 <EmilienM> big +1 on this one
15:26:35 <mgagne> just like openstacklib kind of introduced
15:26:56 <mgagne> the big part is backport compatibility which I already addressed in my way
15:27:34 <EmilienM> as usual, we need to support backward compat for one release at lease
15:27:36 <mgagne> last time, the initiative got shutdown because people used the actual parameters to ease configuration of firewall and such
15:28:06 <mgagne> as they have to explicitly pass in port numbers and IP adresses which could be easily reused by other stuff
15:28:14 <clayton> so this is similar to the identity_uri changes that were already made?
15:28:32 <mgagne> clayton: no but yes
15:29:03 <mgagne> clayton: this part only concerns Puppet, it's not "forced" by a change in OpenStack itself
15:29:10 <clayton> nod
15:29:42 <clayton> I think it makes sense, my only concern is the work required by deployers to update, but I think it's worthwhile
15:29:52 <EmilienM> clayton: as usual I would say :)
15:29:57 <mgagne> it's feasable
15:30:09 <EmilienM> mgagne: with warnings (?)
15:30:11 <mgagne> yep
15:30:18 <EmilienM> ok
15:30:24 <EmilienM> any other thoughts on this one?
15:30:31 <mgagne> I already introduced a bunch of warnings in my origin changes
15:30:38 <clayton> +1 here
15:30:41 <mgagne> I'm more or less looking for objections
15:30:53 <EmilienM> mgagne: any patch as reference to put in #link ?
15:31:16 <mgagne> https://review.openstack.org/#/c/70411/
15:31:24 <EmilienM> #link https://review.openstack.org/#/c/70411/
15:31:38 <EmilienM> mgagne: perfect.
15:31:58 <EmilienM> it sounds like work will continue on gerrit if there are no thoughts
15:32:10 <EmilienM> mgagne: thx
15:32:13 <mgagne> np
15:32:18 <EmilienM> #topic project naming
15:32:20 <EmilienM> #link https://etherpad.openstack.org/p/puppet-openstack-naming
15:32:45 <EmilienM> well. I got an email last night from Puppetlabs folks - and they ask me to wait a bit to know if we can use PuppetOpenStack or not
15:32:57 <EmilienM> in the meantime, we voted for a name
15:33:00 <EmilienM> results are: http://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_783794d78bcd45ad
15:33:00 <crinkle> "Puppet Modules" is what we're debating about
15:33:18 <EmilienM> if we can't use Puppet in project name, winner will be "Marioneta"
15:33:34 <mfisch> +2!
15:33:43 <EmilienM> crinkle: yes, thx
15:33:49 <mgagne> looks like we have all we need to move forward
15:33:50 <EmilienM> no need to spend too much time on it
15:34:06 <EmilienM> later, there is TC meeting
15:34:25 <EmilienM> where they decide about Puppet OpenStack integration, I'll follow that and give them this same update
15:34:49 <EmilienM> #topic puppet-config-parameter-defaults
15:34:54 <EmilienM> #link https://etherpad.openstack.org/p/puppet-config-parameter-defaults
15:34:58 <EmilienM> clayton: o/
15:35:31 <clayton> Right now I feel like we're not very consistent about how we're handling config file values, and how parameters translate to config file contents
15:36:05 <mgagne> "we don't consistently ensure that they're removed when they're no longer managed" yep
15:36:07 <clayton> this is kind of a strawman document to cover how I understood the situation, and see what other people's thoughts are on it
15:36:20 <EmilienM> I've heard in the last meetings about a script that could check the default value in OpenStack ?
15:36:31 <EmilienM> is it still something we consider?
15:36:37 <mgagne> it was an idea to help us keep up with latest config changes
15:36:39 <clayton> I'm not proposing we go and update all existing modulkes with whatever we decide all at once, but if we could agree on an approach it'd go a long way
15:36:52 <mgagne> I'm not sure when we could make it possible
15:37:20 <EmilienM> clayton: I think this could be part of our best practices that spredzy is going to push in specs, does not?
15:37:41 <clayton> EmilienM: perhaps, it'd be hard to translate to a lint plugin, but I think we could document it as a policy
15:37:50 <mgagne> EmilienM: I think it's a subject more important than naming parameter consistently
15:38:37 <EmilienM> oh I'm talking about values
15:38:48 <EmilienM> clayton: doc would be a good start
15:39:01 <EmilienM> core-reviewers would take that in consideration until we have a tool
15:39:42 <EmilienM> clayton: how can we unblock the status quo ?
15:39:44 <clayton> EmilienM: I think they're related.  For example, if someone doesn't explicitly set a value, and the service has a reasonable default, I'd personally rather not have anything written in the config file.  That potentially means ensuring the value is absent, or turning on purging the config files
15:40:14 <clayton> EmilienM: I think we need some consensus on which of the two philosophies we want to adopt.  Right now we're kind of all over the place
15:40:44 <clayton> Personally I feel unless someone is going to do the tooling required by the more expressive config files, we should go the other route, since it's probably less work
15:40:55 <mgagne> It's a difficult subject because it could also mean that we could just refuse all changes introducing optional configs. People can already manage them with the config providers, why should we bother for ALL the configs?
15:40:56 <EmilienM> yes, it's what I'm worried
15:41:31 <EmilienM> mgagne: +1. Do you suggest any change in our config providers?
15:41:40 <mgagne> EmilienM: not yet :P
15:41:49 <clayton> mgagne: I think that's always a hard call to me, but my suggestion would be that even when we accept those, that they default to undef, i.e. not setting a value
15:41:49 <mgagne> EmilienM: I've been thinking about a new feature though
15:41:51 <clayton> instead of a default
15:41:59 <EmilienM> mgagne: shoot
15:42:01 <mgagne> EmilienM: like purge_if_undef => True
15:42:15 <mgagne> EmilienM: instead of having if else all over the place
15:42:16 <clayton> mgagne: nod, I think something like that might make it a lot easier
15:42:23 <EmilienM> wow, cool
15:42:39 <EmilienM> maybe some side-effect?
15:42:43 <mgagne> or we find a way to centralize all configs in a big manifest in a parsable format
15:42:48 <mgagne> so we only have one place to update
15:42:53 <mgagne> a bit like Chef attributes
15:43:11 <EmilienM> that is going to be a mess
15:43:17 <clayton> mgagne: my suggestion was to have similar behavior if the value was something magic, like 'absent'
15:43:40 <clayton> or probalby a better name, 'unmanaged'
15:43:51 <mgagne> clayton: magic values are no longer magic when you find out that the value magic is a valid config value
15:43:54 <EmilienM> I would rather see the "like purge_if_undef => True" thing that you can enable/disable for now
15:44:00 <clayton> yeap, that's the downside.
15:44:07 <mgagne> EmilienM: yep and disable it by default
15:44:21 <clayton> but if we went that route then the parameter default could be the magic value, something like '<unmanaged>' might be better
15:44:21 <mgagne> EmilienM: or find a way to make it not destroy everything
15:44:39 <mgagne> clayton: lets not introduce more magic =)
15:44:44 <EmilienM> clayton, mgagne: sounds like we start having something here. Can you use the etherpad to update the thoughts?
15:44:48 <EmilienM> I need to move on the agenda
15:44:56 <mgagne> sure
15:44:57 <clayton> do we want purge_if_undef or do we want unmanged_if_undef?
15:45:13 <EmilienM> mgagne, clayton: it will probably lead to a blueprint/specs later. sounds okay?
15:45:14 <clayton> we probably don't want to remove vendor provided options from stock config files
15:45:23 <mfisch> yes we dont ^
15:45:29 <mgagne> clayton: oh god =)
15:45:36 <mfisch> or no we dont, however you want to parse it
15:46:03 <clayton> mgagne: so you'd be ok with something more like unmanaged_if_undef?
15:46:14 <mgagne> clayton: I would like to explore the idea
15:46:27 <mgagne> clayton: see the feasability
15:46:38 <clayton> nod, sounds like we need to investigate a bit
15:46:46 <mgagne> sure
15:46:55 <EmilienM> cool
15:47:03 <EmilienM> mgagne, clayton: are we done for this one?
15:47:08 <mgagne> I think so
15:47:15 <clayton> I'm good
15:47:18 <EmilienM> I have some announcements
15:47:22 <EmilienM> #topic announcements
15:48:04 <EmilienM> #info Summit: collaborative day will be Tuesday - we will have a 50-100 people room for us - feel free to contribute to the agenda
15:48:17 <EmilienM> #link https://etherpad.openstack.org/p/liberty-summit-design-puppet
15:48:33 <EmilienM> #info Summit: Puppet/OPS will be on Wednesday morning
15:48:44 <EmilienM> #link https://etherpad.openstack.org/p/liberty-summit-ops-puppet
15:48:47 <mfisch> we have the whole day on Tuesday?
15:48:57 <EmilienM> mfisch: from 11am to 6pm Sir!
15:49:06 <mfisch> Okay
15:49:08 <mfisch> cool
15:49:21 <EmilienM> #info Puppet 4.0: jobs are created as non-voting - waiting for https://github.com/rodjek/rspec-puppet/pull/265
15:49:30 <EmilienM> Hunner: thx for the work BTW on rspec
15:49:51 <Hunner> It's green in travisci, but doing some last checking before merge
15:50:05 <EmilienM> #topic keystone v3
15:50:10 <EmilienM> richm: o/
15:50:25 <EmilienM> can you give us a *very quick* status & blockers ?
15:50:43 <richm> let me get the list of reviews for openstacklib
15:51:02 <EmilienM> richm: I dropped a comment, if we could have one single topic for all this work, that would help *a lot*
15:51:34 <richm> EmilienM: ok - gildub needs to fix his topics
15:51:37 <EmilienM> ok
15:51:46 <EmilienM> richm: without URLs, can you tell us what's up?
15:51:46 <clayton> I'd like to officially thank richm for answering all my stupid keystone v3 questions the other day :)
15:51:49 <richm> We would like to get https://review.openstack.org/173788 reviewed
15:51:54 <EmilienM> clayton: +1
15:52:07 <richm> We're waiting on this ^^^ openstacklib review
15:52:31 <EmilienM> #action please review https://review.openstack.org/173788
15:52:34 <richm> I've completed the core work to allow us to create multiple domains for multi-domain authentication
15:53:25 <richm> These are out for review
15:53:56 <richm> Based on this work, and on crinkle's conversion of glance to use the openstack provider, I'm using glance as a poc of using v3 with other modules
15:53:56 <EmilienM> richm: I would help you to test it in our gate with beaker, so we can make sure we don't break something. Please make sure we have right dependencies in all the patches
15:54:22 <richm> EmilienM: Is there anything I need to do other than make sure it is rebased to the latest master HEAD commit?
15:54:37 <EmilienM> richm: doings patches dependencies in gerrit
15:54:40 <EmilienM> we can take it offline
15:54:44 <EmilienM> after the meeting
15:54:44 <richm> ok
15:54:58 <EmilienM> richm: thx *a lot* for this work (with imcsk8 btw)
15:55:07 <EmilienM> I move on
15:55:11 <richm> gildub is working on converting the keystone_service and keystone_endpoint resources to use keystone v3
15:55:23 <richm> imcsk8 is converting packstack to use keystone v3
15:55:42 <EmilienM> so we have testing in packstack (which is a good use case), great
15:56:08 <richm> as soon as I complete my preliminary puppet-glance work, I will update the bp with what I've found
15:56:20 <EmilienM> richm: excepts 'need review' - do you need something else from us?
15:56:35 <richm> EmilienM: no
15:56:42 <richm> gildub will be working on v3 trusts
15:56:49 <EmilienM> richm: ok - i'll catch up with you after the meeting (for testing & dependencies)
15:57:00 <EmilienM> we have 4 min
15:57:02 <EmilienM> #topic Default database collation (ie. current utf8_unicode_ci)
15:57:10 <EmilienM> #link https://bugs.launchpad.net/puppet-ceilometer/+bug/1446375
15:57:10 <openstack> Launchpad bug 1446375 in puppet-tuskar "Default MySQL collate parameter is not the one from db_sync" [Critical,New] - Assigned to Emilien Macchi (emilienm)
15:57:33 <EmilienM> I expected from this meeting to agree at how we solve it
15:57:38 <EmilienM> should we change the default?
15:57:46 <mgagne> I know there is a problem but I didn't dig into it yet
15:57:49 <EmilienM> is it going to break some data ? (I don't think so)
15:57:54 <mgagne> we should make it consistent
15:58:04 <crinkle> +1 to changingthe default, but we should also figure out the underlying cause of the issue so that if someone did want to change the charset, they could
15:58:08 <clayton> EmilienM: I read up on this a little bit, it only effects sorting order for columns
15:58:23 <mgagne> clayton: that's what I thought
15:58:41 <clayton> the difference between the two is that the unicode collation does sorting properly
15:58:49 <mgagne> I can do some tests but someone will need to help me understand where the "wrong" collate comes from
15:58:52 <clayton> general takes shortcuts for performance reasons, but works on most languages
15:58:56 <EmilienM> ok so we change the default?
15:59:13 <clayton> From what I read, general was discourged, since the performance differences for most people now days are pretty minor
15:59:20 <mgagne> EmilienM: the current setting doesn't make sense and causes problem for me
15:59:21 <EmilienM> mgagne: yeah, we need to find out where it's changed (db_sync) ?
15:59:35 <EmilienM> ok, I'll change the defaults and send patches.
16:00:01 <mfisch> does it impact running dbs at all?
16:00:01 <EmilienM> I'm sorry to tell you we are approaching the end. For open discussion and bugs/patches, please move on #puppet-openstack, we are all here I think
16:00:18 <mfisch> sorry if I missed it before I got called away
16:00:25 <EmilienM> #action EmilienM changes defaults for https://bugs.launchpad.net/puppet-ceilometer/+bug/1446375
16:00:25 <openstack> Launchpad bug 1446375 in puppet-tuskar "Default MySQL collate parameter is not the one from db_sync" [Critical,New] - Assigned to Emilien Macchi (emilienm)
16:00:33 <EmilienM> I have to close guys, I'm sorry
16:00:38 <EmilienM> #endmeeting