15:00:02 <EmilienM> #startmeeting puppet-openstack
15:00:03 <openstack> Meeting started Tue Apr 28 15:00:02 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:10 <EmilienM> #link https://etherpad.openstack.org/p/puppet-openstack-weekly-meeting-20150428
15:00:23 <EmilienM> #topic Review past action items
15:00:38 <EmilienM> gchamoul: o/
15:00:45 <richm> hello
15:00:48 <gchamoul> o/
15:00:48 <EmilienM> so you send a patch in https://review.openstack.org/106144 about Neutron/Linuxbridge
15:01:00 <gchamoul> EmilienM: yes!
15:01:00 <crinkle> o/
15:01:03 <EmilienM> thanks for that; I'll let people to have a look :-)
15:01:23 <gchamoul> not finished, I got some remarks from Lukas ...
15:01:30 <EmilienM> gchamoul: ok
15:01:32 <EmilienM> about deprecation/backport policy, I created https://etherpad.openstack.org/p/puppet-openstack-master-policy
15:01:49 <EmilienM> and last action so far, we fixed https://bugs.launchpad.net/puppet-ceilometer/+bug/1446375
15:01:49 <openstack> Launchpad bug 1446375 in puppet-designate "Default MySQL collate parameter is not the one from db_sync" [Critical,New]
15:01:58 <EmilienM> #topic CI
15:02:08 <EmilienM> sbadia: o/ can we have  Puppet 4.0 status?
15:02:15 <EmilienM> #link https://docs.google.com/spreadsheets/d/1i2z5QyvukHCWU_JjkWrTpn-PexPBnt3bWPlQfiDGsj8/edit#gid=0
15:02:46 <sbadia> EmilienM: as said in my email, it remain only nova, neutron and swift
15:02:56 <sbadia> the big part :)
15:02:58 <EmilienM> sbadia: w00t, awesome ! Thanks for this work
15:03:03 <sbadia> but it's in progress
15:03:05 <EmilienM> sbadia: do you have blockers, need some help ?
15:03:12 <sbadia> np :-)
15:03:18 <sbadia> for the moment it's ok
15:03:23 <EmilienM> Hunner: can you make sure to have a look at the patches and -1/+1 them ?
15:03:28 <mfisch> +1 on this spreadsheet
15:03:45 <EmilienM> mfisch: I thought it would help :)
15:03:56 <Hunner> Sure
15:04:05 <EmilienM> Hunner, sbadia: thx guys
15:04:10 <EmilienM> Beaker status:
15:04:18 <EmilienM> I'm moving forward to support all modules
15:04:19 <sbadia> Hunner: thx!
15:04:24 <EmilienM> preparing centos support: https://review.openstack.org/175434
15:04:29 <EmilienM> #link https://review.openstack.org/175434
15:04:53 <EmilienM> mmagr is proposing https://review.openstack.org/#/c/178134 - I'll let crinkle and nibalizer dropping a quick general comment/review on this one, to make sure we agree with that
15:05:24 <EmilienM> TripleO/Puppet CI status
15:05:34 <EmilienM> we are gating more modules now (ceilometer, glance, keystone, nova, neutron, swift, openstacklib, heat, cinder)
15:06:00 <EmilienM> jobs are non-voting, but I would ask reviewers to consider the job important
15:06:16 <EmilienM> if it's red, it really means something (except if TripleO CI is broken)
15:06:49 <EmilienM> same thing for beaker. crinkle proposed we don't put the jobs as voting for now, but I still ask for people to keep an eye at the job status
15:07:24 <EmilienM> also, we are facing too much rubygems downtime issues so I proposed to create a mirror in OpenStack infra
15:07:35 <EmilienM> #link https://review.openstack.org/#/c/178026/
15:07:47 <EmilienM> anything else on CI? Someone?
15:07:59 <mgagne> EmilienM: I'm looking forward for ideas regarding that rubygems mirror
15:08:08 <mgagne> EmilienM: existing solutions aren't great
15:08:30 <vinsh> Don't the tripleo infra guys already have a ruby mirror?
15:08:32 <mgagne> EmilienM: they often require to mirror the whole damn site
15:08:34 <EmilienM> mgagne: my solution you mean?
15:08:41 <mgagne> EmilienM: any
15:08:58 <EmilienM> mgagne: well, if our mirror is more stable that public server, isn't it our solution?
15:09:06 <EmilienM> vinsh: not AFIK
15:09:10 <mgagne> EmilienM: I guess you didn't read my comment
15:09:15 <EmilienM> mgagne: not yet, sorry
15:09:57 <EmilienM> mgagne: which one?
15:10:03 <mgagne> EmilienM: mirroring often require to mirror ALL gems and all their versions which consumes a LOT of space
15:10:31 <mfisch> clayton: what are we doing for mirrors here?
15:10:40 <EmilienM> mgagne: what would you suggest?
15:10:41 <vinsh> BTW, what does the tripleo-ci do for puppet anyway?
15:10:53 <clayton> we should mirror rubygems, but we don't.  I've looked into it, but the tools suck, and for our use, we'd need to version them also
15:10:58 <mgagne> EmilienM: I suggest nothing except that I'm curious how we will find a solution to this challenge
15:11:07 <EmilienM> vinsh: https://wiki.openstack.org/wiki/TripleOPuppetCI
15:11:11 <mgagne> EmilienM: what clayton said
15:11:20 <Hunner> Yeah, I don't know of an automated way to mirror only some of rubygems :/. We have a tool that can push bundles of gems up to our mirror at PL, but it's manual
15:11:28 <EmilienM> clayton, mgagne: I'm working on this, feel free to bring your thoughts on Gerrit patch
15:11:30 <clayton> It might be easier to build a limited rubygems mirror that only has the gems we'd need
15:11:39 <mgagne> clayton: yep
15:11:47 <mgagne> clayton: why not using squid instead
15:11:51 <clayton> Hunner: you could probably build them locally using bundler then shove them into a local index
15:11:53 <jistr> mgagne: +1
15:12:04 <Hunner> Using https://github.com/copiousfreetime/stickler
15:12:21 <clayton> squid might work, you'd have to be careful about how to handle refreshing the cache
15:12:34 <Hunner> clayton: True, though it would be hard to track specific versions
15:12:45 <Hunner> (for the bundler ideo)
15:12:52 <clayton> I don't think rubygems has nearly as big of a problem as pypi does with gems disappearing
15:12:54 <mgagne> unless we always need the latest and greatest version of gems, I don't see it as a problem
15:13:43 <mgagne> anyway, lets move on. my point was: I'm curious
15:14:14 <EmilienM> mgagne: this is a good discussion, let's continue offline with Hunner & clayton (ML or whatever)
15:14:23 <clayton> one last thing, last time I looked, rubygems mirror size on disk space I believe was a lot smaller than pypi
15:14:40 <clayton> but that's just my recollection, not an authoritative statement
15:14:53 <mgagne> clayton: omg
15:14:57 <EmilienM> clayton: this is what I've seen last night too.
15:15:02 <EmilienM> I created a mirror on my laptop
15:15:19 <EmilienM> ok, let's move on and keep the topic on track
15:15:19 <mgagne> alright, if rubygems < pypi, forget what I said :D
15:15:30 <clayton> mgagne: istr like 10-20GB vs >100G
15:15:40 <EmilienM> mgagne, clayton : are we done?
15:15:52 <clayton> yeap, sorry :)
15:15:56 <mgagne> go
15:15:57 <EmilienM> np :)
15:15:58 <EmilienM> #topic Master policy
15:16:05 <EmilienM> #link https://etherpad.openstack.org/p/puppet-openstack-master-policy
15:16:20 <EmilienM> mgagne, mfisch, clayton o/
15:16:32 <clayton> EmilienM: what is the status on the tool for doing backports?
15:16:44 <EmilienM> spredzy_ knows
15:16:52 <EmilienM> the patch is under review and making progress
15:17:07 <mfisch> good progress then
15:17:11 <EmilienM> #link https://review.openstack.org/175849
15:17:41 <EmilienM> mgagne, mfisch, clayton: I would like a consensus (maybe we can discuss it during the summit) about what we do *now* with ongoing work/patches
15:17:45 <spredzy_> need to ping openstack-infra guy to find out how to test in in close-to-real conditions
15:17:46 <mgagne> here is my statement: master is targeted to next release and always has been. blocking development (and reverting stuff) because someone thought it was targeted at previous stable version is wrong.
15:17:52 <clayton> As I mentioned before, I don't think we're going to completely solve this before kilo release.  I'd like to avoid making config changes solely to avoid deprecations for the time being, but it seems like it makes sense to make breaking changes for kilo when needd
15:17:54 <EmilienM> the question is: are we breaking juno support in master ?
15:18:13 <mgagne> EmilienM: I still don't understand how we ended up with this situation
15:18:18 <mfisch> yes what clayton said
15:18:28 <mfisch> (sorry /me is also doing prod system recabling this morning)
15:18:33 <clayton> I'd like to discuss this in person at the summit and explore the options more, and then we can summarize back to the list what options are brought up
15:18:35 <EmilienM> mgagne: which situation?
15:18:44 <mgagne> EmilienM: reverting stuff in master to support juno
15:18:59 <EmilienM> what I propose is: we break master for Juno, but we work during Liberty on our provider to offer more flexibility for Kilo/Liberty
15:19:07 <EmilienM> mgagne: well...
15:19:21 <EmilienM> mgagne: we will Revert: Revert: XX :(
15:19:46 <EmilienM> clayton, mgagne, mfisch: what do you think about that solution?
15:19:52 <clayton> I believe the only revert was to specifically remove a change that broke juno for a deprecation.  I think that's a grey area
15:20:29 <mgagne> clayton: it's not. it creates a precedent
15:20:40 <mgagne> not sure how to translate that in englih
15:20:43 <mgagne> english*
15:20:54 <mgagne> it sets a precedent, there
15:20:55 <mfisch> precedent is right
15:21:27 <mfisch> I still dont like the change that went in, its not like if you didnt have it you cant run Kilo
15:21:29 <clayton> I'd prefer to avoid making changes to the master branch that break juno solely to avoid deprecation warnings, at least for this release.  If that sets a precdent, then I'm fine with it.
15:21:45 <mfisch> we're all speaking about theory here but that change could have waited, thats the reality of that change, not a good trade-off
15:21:52 <clayton> if other people disagree and I lose that argument, then I'll live with that also
15:22:28 <mgagne> There are technical solutions that people can use to still support juno with master branch.
15:23:25 <EmilienM> mgagne: like? backports?
15:23:28 <clayton> mgagne: yeap, and we've done that also.  I'd like to discuss at some point whether or not that's something we should integrate.  My primary concern here isn't about whether or not we stay on master or not, but if there is anything we can to do make upgrades go more smoothly.
15:23:51 <mgagne> EmilienM: https://github.com/michaeltchapman/puppet-openstacklib/blob/master/manifests/compat/nova.pp
15:23:56 <EmilienM> mgagne: +1
15:24:07 <EmilienM> clayton: are you doing the same thing for OpenStack code (nova, etc) ?
15:24:20 <mgagne> clayton: sure but lets not influence evolution of master because someone is using it to run/install juno
15:24:39 <clayton> That's the sort of thing that we'd be very comfortable contributing to, if there was interest
15:25:00 <EmilienM> clayton: if not, why doing that for Puppet ?
15:25:29 <clayton> EmilienM: we're actually exploring doing that for core services also, that's why we're looking to move away from packages entirely.
15:25:48 <clayton> we'd like to be able to have juno and kilo services installed on the same node, and switch between them easily to make upgrades faster.
15:25:48 <mgagne> clayton: if we wish to support previous stable and next in master, so be it. But I'm against reverting stuff until a clear solution is found. master was never (officially) meant to be used that way
15:26:12 <mgagne> clayton: I wish that too and I'm looking forward to it
15:26:29 <clayton> mgagne: personaly that's what I'd like in an ideal world, but I'm not seriously suggesting it at this point.  I'd like to talk through what would actually be needed to even do that.
15:27:21 <EmilienM> mgagne: fair enough, your statement is true but it seems we don't have it written somewhere. That's why I proposed to write a blueprint and find a consensus
15:27:53 <EmilienM> we are not really making progress here
15:28:17 <clayton> EmilienM: I'm fine with sticking with the existing (undocumented?) policy for the master branch.
15:28:30 <EmilienM> mfisch, clayton: for what I'm seeing now, is that you are the only ones using master for kilo right now
15:28:36 <mgagne> I can be pedantic in my times and setting a precedent like that one irritates me. Because it looks like we implicitly changed on unwritten policy regarding master
15:28:37 <clayton> Godaddy is also
15:28:55 <clayton> in fact, we were following their lead when we did that
15:28:56 <mgagne> our*
15:29:12 <mfisch> godaddy is on vacation still I think
15:29:18 <bodepd> EmilienM: I plan on using master to mean openstack master (or at least kilo) ASAP
15:29:33 <bodepd> EmilienM: that is actually what I'm working on this week
15:29:45 <EmilienM> mgagne: I'll write an official blueprint that contains these statements
15:29:50 <EmilienM> and people will just vote
15:29:54 <clayton> I don't have any interest in holding up kilo work on master
15:30:00 <mfisch> me either
15:30:05 <mfisch> if its truly needed
15:30:30 <clayton> I don't think it's practical to make a decision on what we want master or any other branch to be long term before the summit, but I think the summit would be a good time to talk through some of the possibilities
15:30:56 <EmilienM> mgagne: do you have enough bandwidth to initiate the blueprint?
15:31:13 <EmilienM> clayton: "initiate", so we can come up with better thoughts
15:31:21 <clayton> breaking changes to master won't break us, we just won't pull them in until we're working on kilo upgrade
15:31:25 <EmilienM> we won't take the decision *before* the summit.
15:31:41 <EmilienM> it's happening soon, so we can wait a bit.
15:31:49 <EmilienM> are we ok with that ?
15:32:06 <clayton> +1
15:32:19 <EmilienM> mgagne: ?
15:32:35 <mgagne> as long as we don't revert *new* stuff until we have that policy written down
15:32:37 <mgagne> I'm fine
15:32:39 <jpena> EmilienM: does it mean that any update for Kilo that may break Juno will need to be on hold until the summit?
15:32:51 <clayton> jpena: the opposite I believe
15:32:53 <EmilienM> mgagne: and to initiate the BP ?
15:32:55 <mgagne> jpena: I'm more or less concerned about those use cases
15:33:09 <mgagne> EmilienM: I would be dishonest if I said I had the bandwidth
15:33:17 <EmilienM> mgagne: I'll do it then.
15:33:25 <crinkle> i don't think we should avoid reverting things in master
15:33:36 <crinkle> i think it's fine to revert something until we've had more discussion on it
15:33:41 <crinkle> i think tripleo does it all the time
15:33:43 <mgagne> EmilienM: pre-summit month is always the busiest
15:33:49 <EmilienM> crinkle: +1
15:34:21 <bodepd> to clarify, master is not intened to be kilo then?
15:34:33 <mgagne> bodepd: hehe
15:34:40 <EmilienM> for now, master stays Juno + Kilo
15:34:45 <bodepd> or its just that you want to avoid backwards breaking changes
15:34:52 <bodepd> great. thanks for the clarification
15:35:05 <EmilienM> #action EmilienM to initiate a blueprint about Master policy
15:35:19 <EmilienM> so, until the summit, we keep Juno working on master
15:35:27 <bodepd> what was wrong with the old policy?
15:35:36 <EmilienM> we continue to groom on etherpad/gerrit (when i'll write the blueprint)
15:35:47 <bodepd> (sorry, I know I've been away, but it's hard not to comment on everything :) )
15:35:50 <EmilienM> lol
15:36:19 <EmilienM> bodepd: TL;DR, we used to break master for stable releases while people deploying stable with master
15:36:37 <EmilienM> bodepd: https://etherpad.openstack.org/p/puppet-openstack-master-policy
15:36:44 <bodepd> oh, maybe I mean the old-old policy then :)
15:37:00 <mgagne> bodepd: we didn't change anything yet
15:37:24 <mgagne> bodepd: this change triggered the discussion: https://review.openstack.org/#/c/173495/
15:37:42 <EmilienM> can we go ahead in the agenda? mgagne, clayton, mfisch, bodepd, are we done for this one?
15:37:48 <clayton> wfm
15:37:59 <mfisch> yes, sorry Im not able to focus very well atm
15:38:14 <EmilienM> #topic project naming
15:38:21 <bodepd> I'd like to make one more comment
15:38:29 <EmilienM> bodepd: go ahead.
15:38:52 <bodepd> I rememer a long time ago, we tried not to have any backwards incompat changes in master, and deprecated things across 2 releases
15:39:04 <bodepd> I guess that policy went away, and the question is it things should go back to it?
15:39:06 <mgagne> bodepd: this was for OUR public interface (class parameters)
15:39:16 <mgagne> bodepd: and we are still doing it
15:39:32 <crinkle> bodepd: it's not backwards incompatible changes we're worried about, it's changes that specifically affect how we deploy juno versus kilo, e.g. config parameter names or package names
15:39:33 <bodepd> mgagne: thanks for the clarification
15:39:37 <EmilienM> bodepd: true. But in the meantime (you were away), we had new contributors having new use-cases, so we may re-think our way to backport things
15:39:58 <bodepd> thanks
15:39:58 <EmilienM> bodepd: we keep this policy for now, don't worry :)
15:40:34 <EmilienM> bodepd: do you want to add some thoughts?
15:41:15 <EmilienM> seems like not :)
15:41:25 <EmilienM> so about naming...
15:41:25 <EmilienM> Legal agreement between Puppet and the OpenStack foundation still pending for name "Puppet Modules". There is already consensus agreement, just working out final details. Will update when have more information. (Richard Raseley)
15:41:42 <mfisch> I dont quite parse that
15:41:43 <bodepd> EmilienM: oh great, so we may just keep the name?
15:41:47 <mfisch> does that mean we can use the name?
15:41:48 <EmilienM> sorry for people who found crazy names :-P
15:42:05 <EmilienM> for now, yes, I'm waiting for final decision (it's not in my hand)
15:42:13 <EmilienM> OpenStack foundation <-> Puppetlabs
15:42:32 <bodepd> wow! thanks for both orgs then for being completely reasonable ;)
15:42:44 <EmilienM> mfisch: I think "Puppet Modules" will be our project name
15:42:46 <bodepd> (or at least trying)
15:42:50 <mfisch> ok
15:42:59 <mfisch> as long as its not Puppies I'm happy :0
15:43:03 <EmilienM> #topic keystone v3
15:43:08 <EmilienM> richm: o/
15:43:22 <EmilienM> can we have a status and an idea of your blockers right now ?
15:43:48 <richm> Not much progress - working with gildub on getting the base code for the keystone providers
15:44:12 <EmilienM> is there anyone in our community willing to help in that work?
15:44:15 <richm> I've started on puppet-glance to see what changes are needed - I posted a review for puppet-glance
15:44:22 <imcsk8> i can
15:44:32 <EmilienM> imcsk8: you're already with richm ;-)
15:44:38 <richm> imcsk8 has been working on deploying the patches with packstack
15:44:49 <bodepd> why would that require changes to the core providers? I though it woudl just work with openstackclient?
15:44:52 <EmilienM> richm: do you have specific patches that need our attention ?
15:44:55 <richm> gildub and I need to nail down the puppet-keystone provider code
15:46:02 <richm> bodepd: 1) need to provide the correct --os-identity-api-version and auth url suffix "/v3" 2) the command line arguments and order has changed going from v2 to v3 e.g. service create $name in v2 vs. service create $type --name $name in v3 3) the output is different with v2 vs v3
15:46:33 <bodepd> richm: thanks, that makes sense
15:46:37 <richm> EmilienM: no patches need attention yet - I need to work with gildub to produce final "reviewable" patches
15:46:52 <EmilienM> richm: did you amend the blueprint? do you need some reviews ?
15:47:12 <richm> gildub imcsk8 and I have been meeting every night - we will have a meeting tonight to finalize plans, one way or another
15:47:22 <richm> EmilienM: The blueprint is far from complete
15:47:37 <richm> The blueprint still needs to have all of the changes required to all of the puppet modules
15:48:20 <richm> 1) Convert each module to use openstackclient + v3 in the providers 2) convert each module to be able to do server to server keystone auth using the keystone_authconfig configuration for keystonemiddleware
15:48:39 <richm> Then there's modules like heat which already use some v3 features
15:49:05 <richm> so we are still quite a way from having a reviewable blueprint
15:49:07 <EmilienM> right, but in the wrong way (without provider)
15:49:28 <richm> EmilienM: right, so heat will need to be converted to use openstackclient
15:49:49 <EmilienM> ok
15:49:51 <EmilienM> richm: thanks !
15:49:55 <EmilienM> richm: anything else?
15:49:58 <richm> not to mention other v3 features such as groups and trusts which so far have been ignored
15:50:28 <EmilienM> richm: it's a big work. I'll see what can I do to help
15:50:42 <richm> ok - I should know more after our meeting tonight
15:51:06 <EmilienM> richm: I'll participate too, thx
15:51:13 <EmilienM> richm: can we go ahead ?
15:51:26 <richm> yes, please proceed
15:51:36 <EmilienM> #topic moving from stackforge to openstack
15:51:39 <EmilienM> #link https://review.openstack.org/176326
15:51:56 <EmilienM> I'm wondering about the 'when'
15:52:17 <EmilienM> any thoughts?
15:52:26 <crinkle> after the summit
15:52:34 <mgagne> EmilienM: is there anything an operator should know/do about this move?
15:52:44 <EmilienM> I think so
15:52:54 <EmilienM> stackforge will be synced I think
15:52:57 <EmilienM> for some time?
15:53:05 <mgagne> stackforge?
15:53:17 <EmilienM> stackforge repo will remain a while maybe
15:53:20 <mgagne> the repository is moved, not copied AFAIK
15:53:26 <EmilienM> mgagne: not forked?
15:53:30 <mgagne> EmilienM: no
15:53:34 <EmilienM> well, os-infra told me all is possible
15:53:46 <mgagne> EmilienM: github redirects on rename
15:53:48 <EmilienM> so I agree with crinkle and we should discuss about tha during our summit day
15:54:16 <mgagne> EmilienM: unless people are cloning from git.o.o, there shouldn't be any problem. github will redirect for you
15:54:39 <EmilienM> mgagne: yes, but we don't know who pull from git.o.o
15:54:47 <mgagne> EmilienM: or we ask infra to create a symlink from stackforge to openstack on the server
15:54:57 <mgagne> EmilienM: git.o.o that is
15:55:05 <EmilienM> https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Upcoming_Project_Renames
15:55:43 <EmilienM> mistral is moving right now
15:55:59 <EmilienM> but we will wait Vancouver, anyone against this idea?
15:56:23 <EmilienM> seems like not
15:56:23 <mgagne> no opinion, we can wait
15:56:32 <mfisch> okay with waiting
15:56:35 <EmilienM> #topic Open Discussion, Bug and Review triage
15:56:45 <EmilienM> #link https://review.openstack.org/#/c/177037/
15:56:46 <mfisch> I think we're out of time for triage
15:56:50 <EmilienM> from vinsh
15:56:53 <crinkle> I have something quick for open discussion
15:57:00 <EmilienM> crinkle: shoot
15:57:12 <vinsh> Yeah, Id just like eyes on that puppet-swift change.. its a big one. But adds a lot of value IMO
15:57:32 <crinkle> today is my last day at puppet labs, i just want to make sure you guys know that Hunner and _morgan are modules people who are around to help out, and RichardRaseley is another point of contact for puppet labs if needed
15:57:53 <crinkle> that is all
15:57:55 <EmilienM> crinkle: it's good to know, thanks
15:58:18 <mfisch> thanks crinkle
15:58:36 <crinkle> oh, also i've passed on the puppet forge password to EmilienM and Hunner
15:58:36 <EmilienM> anyone else? anything else? 1 minute left :-)
15:58:46 <mgagne> crinkle: thank you very much for the work you have done. It was greatly appreciated!
15:58:52 <crinkle> mgagne: :)
15:59:04 <EmilienM> mgagne: well, she's staying on Puppet OpenStack (I hope) :-P
15:59:15 <EmilienM> thanks everyone!
15:59:24 <crinkle> i will still be around, i just can't merge things on puppetlabs-rabbitmq anymore :)
15:59:30 <EmilienM> lol
15:59:33 <EmilienM> spredzy_|afk: sorry ^
15:59:39 <xarses> lol, we need those fixes though
16:00:03 <EmilienM> if nothing else, I close the meeting. Thanks for your reviews & participations !
16:00:06 <EmilienM> #endmeeting