15:00:45 <amoralej> #startmeeting RDO meeting (2016-07-06)
15:00:45 <zodbot> Meeting started Wed Jul  6 15:00:45 2016 UTC.  The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:45 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:00:45 <zodbot> The meeting name has been set to 'rdo_meeting_(2016-07-06)'
15:00:45 <openstack> Meeting started Wed Jul  6 15:00:45 2016 UTC and is due to finish in 60 minutes.  The chair is amoralej. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:49 <openstack> The meeting name has been set to 'rdo_meeting__2016_07_06_'
15:01:03 <amoralej> dmsimard, we need to disable one of the bots
15:01:11 <trown> yep
15:01:38 <dmsimard> rhallisey: https://bugzilla.redhat.com/show_bug.cgi?id=1353227
15:01:44 <openstack> bugzilla.redhat.com bug 1353227 in openstack-selinux "openstack-designate AVCs when named/bind tries to read configuration out of /var/lib/designate" [Unspecified,New] - Assigned to lhh
15:01:52 <trown> amoralej: we are good to go now
15:01:53 <amoralej> here we go
15:02:02 <amoralej> #topic roll call
15:02:05 <trown> o/
15:02:05 <number80> thanks rbowen
15:02:06 <jschlueter> o/
15:02:06 <rbowen> Yo
15:02:08 <number80> o/
15:02:09 <eggmaster> o/
15:02:12 <dmsimard> \i
15:02:15 <jpena> o/
15:02:26 <amoralej> #chair trown number80 jschlueter rbowen number80 eggmaster dmsimard jpena
15:02:26 <zodbot> Current chairs: amoralej dmsimard eggmaster jpena jschlueter number80 rbowen trown
15:02:27 <openstack> Current chairs: amoralej dmsimard eggmaster jpena jschlueter number80 rbowen trown
15:02:38 <flepied> o/
15:02:49 <jjoyce> o/
15:02:50 <number80> please add your name in the sidepane so that we know who wrote what
15:02:54 <amoralej> #chair flepied jjoyce
15:02:55 <zodbot> Current chairs: amoralej dmsimard eggmaster flepied jjoyce jpena jschlueter number80 rbowen trown
15:02:56 <openstack> Current chairs: amoralej dmsimard eggmaster flepied jjoyce jpena jschlueter number80 rbowen trown
15:03:21 <amoralej> apevec, are you around, first topics are yours
15:03:39 <apevec> yeah, lemme reboot
15:04:08 <apevec> and o/
15:04:23 <amoralej> #chair apevec
15:04:23 <zodbot> Current chairs: amoralej apevec dmsimard eggmaster flepied jjoyce jpena jschlueter number80 rbowen trown
15:04:23 <openstack> Current chairs: amoralej apevec dmsimard eggmaster flepied jjoyce jpena jschlueter number80 rbowen trown
15:04:29 <imcsk8> o/
15:04:36 <amoralej> #chair imcsk8
15:04:37 <zodbot> Current chairs: amoralej apevec dmsimard eggmaster flepied imcsk8 jjoyce jpena jschlueter number80 rbowen trown
15:04:38 <openstack> Current chairs: amoralej apevec dmsimard eggmaster flepied imcsk8 jjoyce jpena jschlueter number80 rbowen trown
15:04:46 <amoralej> so, let's go with the first topic
15:04:49 <amoralej> #topic move all openstack-* logging to systemd journal only (apevec)
15:05:22 <apevec> tl;dr let's drop logging to  /var/log/PROJECT/...
15:05:40 <apevec> and configure by default oslo.log to use stderr
15:05:48 <amoralej> why?, just saving space of there is any other reason?
15:05:52 <jpena> apevec: why that?
15:05:55 <apevec> that is then captured by systemd and put in journal
15:06:07 <apevec> better integration with baseOS
15:06:17 <dmsimard> this is going to break a lot of user implementations
15:06:20 <apevec> there's also bug with logrotate
15:06:20 <dmsimard> probably
15:06:33 <number80> I'm fine with it but I'm curious about operators feedback on that topic
15:06:35 <apevec> dmsimard, where?
15:06:37 <jschlueter> is there good writeup on how to pull content from systemd/journal ?
15:06:48 <apevec> journalctl
15:06:50 <dmsimard> apevec: people expecting stuff to be in /var/log/<project>
15:06:52 <jpena> I always have trouble trying to filter content in journald, but that's probably me
15:06:58 <apevec> dmsimard, they can still configure it
15:07:01 <dmsimard> logstash, etc
15:07:01 <amoralej> my main concern is that many people will be using /var/log/ for monitoring and logs collection
15:07:02 <apevec> this is about package default
15:07:11 <apevec> e.g. puppet-* would still do whatever they do now
15:07:21 <dmsimard> apevec: how does an upgrade from mitaka to newton will work ? will it override anything ?
15:07:34 <apevec> rpm upgrades do not touch config files
15:07:49 <dmsimard> I'm curious if UCA will do something similar
15:07:57 <number80> amoralej: good point, we need to coordinate with optools folks
15:08:00 <apevec> but yeah, this topic was mainly to get it out and collect pushbacks :)
15:08:03 <dmsimard> I guess I'll ask zigo and jamespage, just curious
15:08:06 <amoralej> i'd think the oposite, let's leave rpms are they are and use puppet-* to modify it
15:08:07 <apevec> UCA ?
15:08:13 <dmsimard> Ubuntu Cloud Archive
15:08:21 <apevec> they will probably not
15:08:38 <dmsimard> I'll ask :p
15:08:49 <apevec> I'm pretty sure they don;t like Lennart ;)
15:09:07 <number80> well, systemd is default on both debian and ubuntu :)
15:09:26 <jschlueter> CI will need to be updated to collect logs from there instead of /var/log/XXX
15:09:30 <apevec> number80, yeah, resistence is futile
15:09:31 <number80> but changing to journald do impact operators
15:09:43 <dmsimard> operators and CI
15:09:50 <apevec> number80, again, they'll use their installer and configure loggin as they like
15:09:57 <number80> ack
15:10:04 <apevec> serious operators do not rely on package defaults do they?
15:10:25 <apevec> ok, so action, thread on rdo-list?
15:10:41 <number80> proposal: migrate packages to journald but give a deadline so that we can review/fix upstream/downstream CI
15:10:44 <apevec> #action apevec start thread about logging defaults in openstack RPMS
15:10:52 <number80> wfm
15:10:58 <dmsimard> apevec: do you want to finish this by the end of N ?
15:11:14 <amoralej> ok, let's move on to the next one
15:11:17 <jpena> ok, but my answer will be "let's wait a bit more until everyone is more comfortable with journald" :)
15:11:17 <number80> we have time to do that in time for Newton
15:11:17 <jschlueter> Milestone 3 or push to next cycle
15:11:20 <apevec> let's first see how discussion goes
15:11:30 <number80> ack
15:11:42 <apevec> jpena, it's been few years already :)
15:11:45 <apevec> but yeah
15:11:55 <amoralej> #topic packaging exception request: bundling JARs in sahara-tests https://bugzilla.redhat.com/show_bug.cgi?id=1318765#c13 (apevec)
15:11:56 <openstack> bugzilla.redhat.com bug 1318765 in Package Review "Review Request: openstack-sahara-tests - Sahara Scenario Test Framework" [Unspecified,New] - Assigned to apevec
15:12:07 <apevec> oh yes, fedora-review FTW
15:12:12 <number80> it's pure RDO package btw
15:12:19 <number80> (not in Fedora)
15:12:30 <number80> licensing-wise, it's ok
15:12:41 <apevec> yeah, but still RDO does follow fed pkg guidelines
15:13:01 <number80> I'm fine w/ giving this package an exception
15:13:01 <apevec> we can grant exception after discussion in this forum
15:13:23 <apevec> ok, I need still to confirm there are sources for all JARs included
15:13:48 <apevec> at least one is just JAR copied from apache
15:13:58 <number80> ouch
15:14:30 <apevec> we could also say these are just test fixtures
15:14:32 <jschlueter> ick, are the jar's used for tests or just an example?
15:14:36 <apevec> but that would be going to far
15:14:41 <number80> jschlueter: for testing
15:14:42 <apevec> tests
15:14:51 <jschlueter> actually used in testing...
15:14:52 <apevec> other option is to drop that
15:15:05 <apevec> I'll check w/ tosky about that
15:15:24 <number80> apevec: should we add a follow-up topic for next week?
15:15:33 <number80> or the one after?
15:15:35 <amoralej> #action apevec to check with tosky about jar files in sahara-tests
15:15:51 <apevec> let's keep it for next week
15:16:00 <number80> ack
15:16:35 <amoralej> ok, let's move on to the next topic
15:16:41 <amoralej> #topic puppet packaging status (hguemar)
15:17:00 <number80> ok
15:17:03 <number80> two changes
15:17:17 <number80> #info puppet 3.x packages in RDO enable allow_virtual by default
15:17:33 <number80> this should prevent any python2 side-effects in puppet modules
15:17:42 <number80> #info puppet 3.8.7 is in common-ending
15:17:53 <dmsimard> EmilienM: ^
15:18:06 <number80> I'd like people to test the latter more extensively so that we can release newton with it
15:18:26 <apevec> #undo
15:18:26 <zodbot> Removing item from minutes: INFO by number80 at 15:17:42 : puppet 3.8.7 is in common-ending
15:18:27 <openstack> Removing item from minutes: <ircmeeting.items.Info object at 0x7f2b369f5c90>
15:18:28 <apevec> #info puppet 3.8.7 is in common-pending
15:18:35 <number80> AFAIK, weirdo-generic jobs passed with puppet-3.8.7
15:18:35 <jpena> but this would only "fix" it for TripleO/Packstack, Puppet CI uses the puppetlabs rpm
15:18:54 <apevec> jpena, puppet CI has fix in their manifests
15:18:55 <EmilienM> right but we can change it
15:19:03 <EmilienM> we could use RDO rpms
15:19:09 <number80> jpena: well, we don't test against puppetlabs rpm
15:19:13 <EmilienM> I actually would prefer using your packages
15:19:25 <EmilienM> forget about puppetlabs rpm now, we can change it :)
15:19:31 <number80> if upstream CI uses our puppet packages, this would allow us to upgrade it more aggressively
15:19:34 <apevec> what about puppet4 ?
15:19:41 <EmilienM> next iteration?
15:19:41 <jpena> I'm ok with having allow_virtual=true by default (I think that's the way it should be), but we need to be aware that this is a deviation from the expected puppet behaviour
15:19:49 <apevec> do we want to plan upgrade that in Newton or later?
15:20:04 <EmilienM> puppet4 will require more work than you expect
15:20:05 <number80> jpena: I'll document it then
15:20:21 <apevec> I expect more work
15:20:27 <EmilienM> tripleo won't work with puppet4 I think, we'll  have to adjust some code
15:20:37 <number80> #action hguemar document RDO puppet 3.x package deviation from standard
15:20:42 <apevec> that's why I'd like we start planning that for Ocata
15:20:50 <EmilienM> let's switch upstream CI to use your puppet rpm
15:21:15 <apevec> EmilienM, but openstack-puppet CI has puppet4 jobs already?
15:21:16 <number80> EmilienM: wait that we push it in -testing though
15:21:24 <EmilienM> yes but we use puppetlabs also
15:21:36 <EmilienM> so let's first iterate by using RDO for puppet3
15:21:41 <apevec> ack
15:21:43 <EmilienM> and then we'll see for puppet4
15:22:00 <EmilienM> we need extensive testing around puppetCI/packstack/tripleo first
15:22:08 <number80> #info postpone puppet-4.x to Ocata release
15:22:15 <EmilienM> it's a good choice ^
15:22:16 <rdogerrit> Fabien Boucher created rdo_gating_scripts: Adapt gerritbot instructions for the new SF 2.2.2  http://review.rdoproject.org/r/1593
15:22:39 <EmilienM> after my composable roles work in tripleo, I'll focus on puppet4 migration
15:22:48 <number80> I'm happy that we're moving forward in that area
15:22:59 <EmilienM> me too, puppet4 is really cool
15:23:04 <number80> if nobody has anything else, I'm fine w/ next :)
15:23:25 <amoralej> ok,
15:23:29 <amoralej> #topic stable branch maintenance upcoming changes (hguemar)
15:23:43 <amoralej> #link https://trello.com/c/URAtrhLU/86-automate-stable-packages-releases
15:23:54 <number80> ok, we brainstormed w/ apevec, flepied a plan to automate stable packages releases
15:24:04 <number80> plan is in the link on the trello card sent by amoralej
15:24:13 <number80> s/on/to/
15:24:29 <number80> the plan is to empower anyone to do stable releases in RDO
15:24:39 <number80> albeit with a reviewing process :)
15:24:48 <EmilienM> number80, apevec: please ping me when I can download puppet3.x in RDO buildlogs or somewhere else
15:24:53 <number80> EmilienM: ack
15:24:55 <EmilienM> number80, apevec: I'll work on the transition.
15:25:03 <number80> any comments?
15:25:22 <apevec> let's just put tl;dr for meeting minutes:
15:25:30 <apevec> rpm-STABLE will be gone
15:25:42 <apevec> DLRN will build from STABLE-rdo branches
15:25:50 <apevec> both DLRN and CBS actually
15:26:05 <number80> #info DLRN will be building from STABLE-rdo branches (rpm-STABLE branches will be removed)
15:26:54 <amoralej> and will we automate reviews to STABLE-rdo when new point releases are tagged?
15:27:03 <apevec> that's next step
15:27:11 <amoralej> ok
15:27:40 <amoralej> currently we force STABLE-rdo branches for each release, right?
15:27:52 <jschlueter> has someone done audit for whats different between rpm-STABLE and STABLE-XXX branches to see where they have drifted apart?
15:27:52 <number80> yes, we fork them
15:27:59 <apevec> yes, those are regular "distgit" branches
15:28:08 <number80> jschlueter: that's what I'll be doing after I finish py3 migration
15:28:11 <apevec> i.e. each CBS build has corresponding commit on *-rdo
15:28:12 <amoralej> that means when a new version is released, we'll create NEXT-rdo for every project
15:28:31 * jschlueter nods to number80
15:28:51 <number80> amoralej: branch creation is still to be defined, but it will likely be semi-automated
15:28:55 <apevec> jschlueter, yes, branch sync is the first task in the checklist
15:28:55 <number80> s/be/remain
15:29:02 <jjoyce> Would there still be a master?
15:29:08 <number80> jjoyce: always
15:29:11 <apevec> rpm-master stays
15:29:16 <number80> rpm-master will be untouched
15:29:18 <apevec> this is for stable branches/DLRN only
15:29:46 <apevec> one side-effect is that there will be no more "lazy" rpm-RELEASE branching
15:29:59 <apevec> i.e. reusing rpm-master for stable releases where it still works
15:30:06 <number80> well, I think that people were a bit confused about it
15:30:08 <jjoyce> so we would not have a branch for each of the releaes? I am trying to get a picture in my mind.
15:30:17 <apevec> that means more backports to do but that can be automated
15:30:32 <apevec> and yes, it removes source of confusion
15:30:46 <apevec> jjoyce, we would
15:30:50 <apevec> end result:
15:31:01 <apevec> rpm-master => RDO Trunk master
15:31:15 <apevec> STABLE-rdo => RDO Trunk STABLE and CBS builds
15:31:34 <amoralej> #info rpm-master branch stays for DLRN only master packages (RDO Trunk master)
15:32:12 <jjoyce> apevec: Is there a sample package that has been changed to get a better view?
15:32:25 <number80> jjoyce: not yet
15:32:42 <number80> but you can just look at existing STABLE-rdo branches
15:32:45 <apevec> jjoyce, DLRN can work with *-rdo as is
15:32:58 <apevec> it replaces Version: Release: Source0: anyway
15:32:58 <jjoyce> number80: ack
15:32:59 <number80> thanks to jpena
15:33:12 <jjoyce> apevec: OK, I think I see it
15:33:26 <apevec> there was change in DLRN to drop %changelog
15:33:39 <apevec> b/c those entries do not make sense for trunk builds
15:34:08 <apevec> so we just need to sync branches and change rdoinfo
15:34:22 <amoralej> #info no changes are expected in DLRN to support new model
15:35:02 <amoralej> we want to do it asap or wait until newton GA?
15:35:18 <apevec> asap
15:35:42 <amoralej> ok, so actions
15:35:43 <apevec> it's already in progress
15:35:43 <number80> yes, just finished current migration
15:36:02 <number80> #action hguemar review, sync, fix rpm-STABLE/STABLE-rdo branches
15:36:04 <amoralej> implement some package as pilot?
15:36:28 <apevec> or test DLRN instance?
15:36:35 <apevec> with modified rdoinfo
15:36:53 <apevec> jpena, do we have resources ^
15:37:15 <amoralej> we still have the old dlrn server, it may be useful for tests
15:37:17 <jpena> right now we have available space, thanks to removing the kilo instance and cleaning fedora-master
15:37:30 <apevec> ah yes, could be on old server
15:37:32 <jpena> we could also use the old instance
15:37:45 <apevec> yes, let's make that staging playground
15:37:47 <jpena> yep, that sounds like a good solution
15:37:47 <number80> could you share here direct url ?
15:38:11 <jpena> it's http://trunk-primary-old.rdoproject.org
15:38:15 <apevec> let's not share it until old content is removed
15:38:17 <number80> ack
15:38:25 <apevec> it would be confusing
15:38:26 <jpena> but we should change the forced redirection to https :)
15:38:34 <apevec> right
15:38:47 <amoralej> #info old dlrn server will be used for tests (http://trunk-primary-old.rdoproject.org)
15:38:47 <number80> well, I have IP for many previous incarnations of the server so I wanted to check the right one
15:39:14 <apevec> jpena, amoralej please also mv old content so it is not served
15:39:24 <amoralej> #action amoralej remove https redirection from old server
15:39:26 <apevec> let's keep it around for a while before removing
15:39:37 <jpena> just removing the symlinks will do
15:39:49 <amoralej> #action amoralej remove symlinks from old dlrn server
15:40:33 <amoralej> ok, so i think we have the first list of tasks
15:41:00 <amoralej> anything else about this topic?
15:41:16 <apevec> rest of tasks are in the trello card
15:41:34 <amoralej> ok
15:41:42 <amoralej> so, move on to the next topic
15:41:48 <amoralej> #topic review.rdoproject.org platform upgrade
15:42:01 <amoralej> not sure who added this
15:42:03 <number80> #info upgrade is DONE
15:42:09 <number80> <- guilty
15:42:10 <apevec> nice!
15:42:22 <jpena> good job!
15:42:22 <amoralej> cool!
15:42:24 <number80> #action hguemar and fbo will migrate project replications to new method
15:42:49 <number80> #info thanks to Software Factory folks for helping us in the migration
15:42:57 <apevec> create project script will be adjusted?
15:42:58 <number80> they did a great job :)
15:43:02 <imcsk8> yeah!! number80
15:43:06 <number80> apevec: yes, that's follow-up
15:43:27 <rdobot> [sensu] NEW: master.monitoring.rdoproject.org - check-delorean-newton-current @ http://uchiwa.monitoring.rdoproject.org/#/client/rdo-monitoring/master.monitoring.rdoproject.org?check=check-delorean-newton-current |#| Build failure on centos7-master/current: sahara: http://trunk.rdoproject.org/centos7-master/report.html
15:43:36 <amoralej> ok, so this was short
15:43:39 <number80> tristanC++
15:43:40 <apevec> let's name those great folks :) fbo++ tristanC++ cschwede++
15:43:41 <zodbot> apevec: Karma for fbo changed to 1 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:43:42 <number80> fbo++
15:43:44 <zodbot> number80: Karma for fbo changed to 2 (for the f24 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
15:43:45 <number80> mhu++
15:43:49 <apevec> mhu++
15:43:56 <apevec> not in FAS? :)
15:44:13 <number80> yes, sadly but well intentions matters :)
15:44:28 <amoralej> :)
15:44:29 <rbowen> Clearly we need another bot to track karma.
15:44:52 <amoralej> let's move on or we'll get out of time
15:44:56 <amoralej> #topic ODL packages in RDO?
15:45:05 <rbowen> This is more a quick question than something that's happening.
15:45:15 <rbowen> The OpenDaylight folks are considering putting ODL packages in RDO.
15:45:20 <rbowen> The question is, are we ok with that kind of thing happening
15:45:21 <amoralej> #info pending MEAD in CBS discussion on centos-devel (for opstools SIG)
15:45:30 <rbowen> Something *outside* of OpenStack being packaged for RDO.
15:45:37 <rbowen> And having those packages live in our repos.
15:46:04 <apevec> rbowen, isn't there centos NFV SIG where this would fit?
15:46:12 <rbowen> Yes. That's the other option.
15:46:19 <apevec> on technical side, it's what I mentioned:
15:46:41 <apevec> it's Java monster, so let's first wait for discussion about MEAD in CBS
15:46:50 <apevec> so we can build it properly
15:46:53 <amoralej> are those packages only intended to be used with OpenStack? or can they be used standalone or with other tools?
15:46:54 <rbowen> So, it sounds like the conversation is already happening somewhere that I wasn't tracking it.
15:47:00 <apevec> I'm -1 to just wrap binaries from upstream in RPM
15:47:05 <rbowen> No, they are not intended only for use with OpenStack
15:47:18 <rbowen> But, then, they're also not only intended for OPNFV, apparently.
15:47:26 <number80> there's already OPNFV build in CBS but like apevec said -1 to warp upstream binaries in RPM
15:47:39 <rbowen> So wherever they go, it's not 100% the right place.
15:47:56 <number80> rbowen: alternative is to incubate it within Cloud SIG under a separate repo
15:47:56 <apevec> we had opstools incubating in our CBS tags
15:48:01 <apevec> but they'll move to their SIG
15:48:16 <rbowen> ok, so consensus seems to be that we're not keen on having these in the RDO repos. Thanks. That's what I wanted to know.
15:48:16 <apevec> and nfv already has CBS tags afaict
15:48:34 <apevec> we're keen to reusing other SIGs repos
15:48:42 <apevec> like we do with qemu-kvm-ev and  ceph
15:48:48 <number80> and there's discussion to merge NFV/Cloud SIG
15:49:17 <apevec> number80, that's fine, but still separate tags/repos right?
15:49:20 <number80> yes
15:49:21 <rbowen> Well, sure, but it seems we've been discussing that for a year.
15:49:44 <number80> rbowen: I plan to submit a proposal but needs to free some time
15:50:15 <number80> openstack team is the only active team within Cloud SIG, and NFV is looking for partnering with us
15:50:42 <number80> so let's reduce administrative churn and share a common SIG
15:50:50 <number80> with separate repo off course
15:50:55 <rbowen> Thanks. I will pass on this feedback in the conversation I've been copied on. That's all I had on this point.
15:51:22 <amoralej> #info RDO proposal is to share a SIG (Cloud SIG) but with different repos and tags for OpenStack and ODL
15:51:26 <amoralej> ^ is this ok?
15:51:30 <number80> yes
15:51:33 <rbowen> That sounds ideal to me. Yes.
15:51:44 <amoralej> sounds reasonable, yes
15:51:52 <amoralej> ok, so next topic
15:52:03 <amoralej> #topic Upcoming dates
15:52:05 <rbowen> Upcoming dates:
15:52:05 <rbowen> OpenStack Summit CFP closes July 15th
15:52:05 <rbowen> Newton M2 July 11-15
15:52:05 <rbowen> Newton M2 test day July 21-22 - https://www.rdoproject.org/testday/newton/milestone2
15:52:13 <rbowen> That's all. :-)
15:52:20 <amoralej> #info OpenStack Summit CFP closes July 15th
15:52:31 <amoralej> #info Newton M2 July 11-15
15:52:43 <trown> we should get a promote of Newton today, so looking good for M2
15:52:46 <amoralej> #info Newton M2 test day July 21-22 - https://www.rdoproject.org/testday/newton/milestone2
15:52:51 <number80> excellent
15:52:57 <EmilienM> w00t w00t
15:53:14 <amoralej> ok, so all proposed topics are done
15:53:23 <amoralej> #topic open floor
15:53:34 <number80> #action hguemar add test case to enable people testing puppet 3.8.7 for M2 test days
15:53:57 <amoralej> #undo
15:53:57 <zodbot> Removing item from minutes: ACTION by number80 at 15:53:34 : hguemar add test case to enable people testing puppet 3.8.7 for M2 test days
15:53:58 <openstack> Removing item from minutes: <ircmeeting.items.Action object at 0x7f2b366c2a50>
15:53:59 <amoralej> #undo
15:53:59 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1b5c0cd0>
15:53:59 <openstack> Removing item from minutes: <ircmeeting.items.Topic object at 0x7f2b366c2310>
15:54:06 <number80> #action hguemar add test case to enable people testing puppet 3.8.7 for M2 test days
15:54:16 <number80> now, you can re-roll new topic :)
15:54:29 <amoralej> thanks :)
15:54:29 <amoralej> #topic open floor
15:54:49 <amoralej> it's the time to arise any other topic...
15:54:53 <number80> I'm good, a lot of work piling up for me but no specific impediment
15:55:24 <amoralej> #topic chair for next meeting
15:55:27 * chandankumar is up for chairing for next meeting.
15:55:46 <apevec> grab the chair!
15:55:48 <amoralej> #info chandankumar to chair next meeting
15:55:57 <amoralej> thanks chandankumar!!
15:56:04 <amoralej> so i guess we can close
15:56:17 <EmilienM> thx amoralej !
15:56:19 <amoralej> #endmeeting