15:04:00 <number80> #startmeeting RDO meeting (2015-11-25)
15:04:00 <zodbot> Meeting started Wed Nov 25 15:04:00 2015 UTC.  The chair is number80. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:04:00 <zodbot> The meeting name has been set to 'rdo_meeting_(2015-11-25)'
15:04:28 <number80> #chair apevec aortega chandankumar elmiko imcsk8 mrunge ibravo  dmsimard
15:04:28 <zodbot> Current chairs: aortega apevec chandankumar dmsimard elmiko ibravo imcsk8 mrunge number80
15:04:52 <number80> #topic roll call
15:05:00 <apevec> o/
15:05:01 <number80> agenda is here
15:05:03 <number80> https://etherpad.openstack.org/p/RDO-Packaging
15:05:05 <number80> o/
15:05:06 <jpena> o/
15:05:17 <apevec> #link https://etherpad.openstack.org/p/RDO-Packaging
15:05:26 <elmiko> o/
15:05:29 <chandankumar> o/
15:05:43 <number80> #chair jpena
15:05:43 <zodbot> Current chairs: aortega apevec chandankumar dmsimard elmiko ibravo imcsk8 jpena mrunge number80
15:05:47 <number80> rbowen: ?
15:06:18 <eggmaster> o/
15:06:31 <number80> #chair eggmaster
15:06:31 <zodbot> Current chairs: aortega apevec chandankumar dmsimard eggmaster elmiko ibravo imcsk8 jpena mrunge number80
15:06:38 <number80> I suggest we start
15:06:49 <number80> #topic 2014.2.4 last Juno update then EOL
15:07:08 <apevec> right, 2014.2.4 == juno-eol was released upstream
15:07:14 <imcsk8> o/
15:07:28 <apevec> so plan is to push this one last update to RDO Juno then move it to EOL/ folder
15:07:33 <apevec> after some delay
15:07:40 <rbowen> Oh, Yes, I'm here.
15:08:00 <apevec> this topic is mainly reminder for package owners to do rebases, or let me know if they're busy
15:08:02 <number80> #chair rbowen
15:08:02 <zodbot> Current chairs: aortega apevec chandankumar dmsimard eggmaster elmiko ibravo imcsk8 jpena mrunge number80 rbowen
15:08:28 <apevec> #info package owners to do 2014.1.2 rebases or let apevec otherwise
15:08:42 <number80> ack
15:08:48 <number80> next topic then
15:08:54 <number80> #topic 2015.1.2
15:09:00 <number80> #undo
15:09:00 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2f210a10>
15:09:05 <number80> #topic 2015.1.2 rebase
15:09:18 <apevec> rebases are all done and in testing repo
15:09:28 <apevec> status is in trello card https://trello.com/c/TjuWaTUw/91-kilo-2015-1-2-rebase
15:09:35 <number80> #info all rebases are done and in testing repository
15:09:37 <number80> ok
15:09:51 <apevec> I wanted to cleanup RDO Kilo repo before pushing to -release
15:09:52 <number80> apevec: could we move that card or is there any blocker yet?
15:09:59 <number80> ack
15:10:09 <apevec> FPO and SIG repo are out of sync
15:10:31 <apevec> no blocker, except me finally focus on finishing that
15:11:02 <EmilienM> I can't release puppet-manila because our CI is still broken for this package
15:11:10 <EmilienM> I'm still having EPEL issues with a dependency
15:11:17 <dmsimard> EmilienM: meeting
15:11:18 <apevec> EmilienM, is that liberty?
15:11:35 <EmilienM> if anyone is interested by looking: https://review.openstack.org/#/c/247401/
15:11:37 <EmilienM> apevec: yes
15:11:43 <number80> acl
15:11:48 <EmilienM> apevec: look the console.log
15:11:50 <apevec> number80, re. kilo - I'll action myself
15:12:00 <EmilienM> http://logs.openstack.org/01/247401/1/check/gate-puppet-manila-puppet-beaker-rspec-dsvm-centos7/2c8e92b/console.html#_2015-11-24_11_13_25_033
15:12:11 <EmilienM> am I in the middle of a meeting?
15:12:12 <apevec> #action apevec to push 2015.1.2 to -release today Nov 25
15:12:16 <number80> EmilienM: yes
15:12:17 <apevec> EmilienM, kind of :)
15:12:20 <EmilienM> I'm very sorry. AGAIN
15:12:25 <number80> EmilienM: np
15:12:51 <number80> Now, all things puppet :)
15:13:06 <number80> #topic Puppet4 EL7
15:13:25 <number80> who added that topic?
15:13:46 <number80> apevec?
15:13:57 <apevec> yeah, just to see if we can move it forward
15:14:08 <apevec> or is hopeless?
15:14:24 <number80> I guess we can, gchamoul is the maintainer :)
15:14:39 <number80> facter3 is another problem though
15:15:03 <number80> It will require rebuilding boost
15:15:13 <number80> or have a //-installable newer boost
15:15:15 <apevec> uhm, no way around that?
15:15:31 <number80> apevec: nope, it bundles a lib that requires boost.log
15:15:36 <apevec> we'll need up with glibc in RDO then...
15:15:55 <apevec> hold on
15:16:04 <apevec> facter3 has bundling exception??
15:16:10 <number80> nope
15:16:17 <apevec> what is "it" then?
15:16:25 <apevec> " it bundles a lib that requires boost.log"
15:16:38 <number80> it's a rewrite of facter that isn't packaged yet in fedora
15:16:57 <number80> but bundling rules have been relaxed in Fedora
15:16:58 <apevec> ah so upstream bundles it
15:17:09 <number80> It
15:17:19 <number80> 's ok to have this one, as it's an internal lib
15:17:35 <number80> *copylib
15:17:36 <apevec> ok, if bundled, couldn't we patch/mock out boost.log usage?
15:18:27 <number80> apevec: sadly, no, I even tried bundling boost.log but even that is not possible (requires newer features from metaprogramming lib)
15:18:32 <trown> o/
15:18:49 <apevec> wow, why is everything so complicated w/ puppet :)
15:19:00 <number80> #chair trown
15:19:00 <zodbot> Current chairs: aortega apevec chandankumar dmsimard eggmaster elmiko ibravo imcsk8 jpena mrunge number80 rbowen trown
15:19:01 <apevec> anyway too much details for a meeting
15:19:16 <apevec> let's discuss further in BZ or trello
15:19:30 <apevec> btw do we have trello card for puppet/facter update?
15:19:37 <number80> #agreed number80 open a trello card to upgrade puppet4/facter3
15:19:45 <number80> next topic
15:19:59 <number80> #topic Large scale issue: EPEL update of Hiera
15:20:11 <number80> ok, this one looks bad
15:20:12 <dmsimard> hi o/
15:20:15 <social> o/
15:20:23 <apevec> large scale?
15:20:32 <number80> social: ?
15:20:36 <number80> #chair social
15:20:36 <zodbot> Current chairs: aortega apevec chandankumar dmsimard eggmaster elmiko ibravo imcsk8 jpena mrunge number80 rbowen social trown
15:20:41 <dmsimard> #link https://bugzilla.redhat.com/show_bug.cgi?id=1284978
15:21:03 <dmsimard> So yesterday we got hit by an update to the hiera package in EPEL which went from 1.3.4 to 3.0.1
15:21:13 <apevec> packstack has fixes in testing repo, what is the fix for rdo-manager?
15:21:34 <dmsimard> Talked to the EPEL guys, I mean, eh, it's a volounteer project and they try not to break things. The update was iniated by a maintainer from CERN.
15:21:53 <number80> That was a quite aggressive update by EPEL standards
15:21:56 <apevec> yeah, EPEL has update policy
15:22:12 <dmsimard> A Ceph guy told me they will start testing against epel-testing rather than epel to try and see these changes coming
15:22:23 <number80> It's not even updated in F22 ...
15:22:26 <dmsimard> So we will have to consider doing something like that as well
15:22:33 <number80> dmsimard: makes sense
15:22:50 <apevec> yeah, although again please note RDO repos do not require EPEL
15:23:00 <trown> I was a bit surprised that packstack required EPEL
15:23:00 <dmsimard> trown had the same issues with RDO Manager around priorities, which it seems was already handled upstream by TripleO
15:23:02 <apevec> in SIG repos we rebuilt all deps from epel
15:23:10 <dmsimard> trown: it does not
15:23:11 <apevec> side-effect is that they lag behind
15:23:26 <trown> ya fix for rdo-manager was to make sure yum-plugin-priorities is installed
15:23:27 <dmsimard> RDO manager does seem to require EPEL, however, looking at docs
15:23:29 <dmsimard> #link https://repos.fedorapeople.org/repos/openstack-m/rdo-manager-docs/liberty/installation/installing.html
15:23:50 <apevec> yeah, we said to look at that after GA
15:23:52 <trown> dmsimard: if packstack does not require EPEL how can EPEL break packstack?
15:23:53 <dmsimard> To bring our CI back in shape, the fix was two fold for packstack
15:24:09 <trown> apevec: ya it moved way up on my priority list due to this issue
15:24:14 <dmsimard> trown: if an end user has EPEL enabled, it'll pick up a more up-to-date package
15:24:27 <trown> #action trown to audit EPEL requirement in rdo-manager
15:24:28 <apevec> dmsimard, trown, it's an old patch in packstack
15:24:30 <jpena> trown dmsimard: packstack used to enable EPEL when a package called rdo-release was installed (EPEL was a requirement a year ago, or so). We've just removed that today
15:24:36 <number80> dmsimard: not with yum-plugin-priorities
15:24:37 <apevec> which enables epel when rdo-release is installed
15:24:44 <apevec> this was required for rdo <= Juno
15:24:51 <dmsimard> jpena: oh so packstack actually INSTALLED epel ?
15:25:02 <apevec> yes
15:25:09 <apevec> when using rdo-release rpm
15:25:15 <apevec> i.e. Quickstart
15:25:18 <trown> ya, otherwise that bug would be NOTABUG dont use EPEL
15:25:23 <apevec> not when using SIG release rpm
15:25:24 <dmsimard> is it rdo-release rpm that installs EPEL, or is it packstack ?
15:25:34 <apevec> packstack conditionally
15:25:47 <dmsimard> ok.
15:25:51 <apevec> https://bugzilla.redhat.com/show_bug.cgi?id=1284978#c10
15:26:13 <dmsimard> Ok so, what's the real fix. Do we get packstack to install yum-plugin-priorities or do we include that in the docs
15:26:21 <imcsk8> dmsimard: there's an option to enable EPEL in packstack
15:26:34 <dmsimard> Or even better, packstack could have a Require: yum-plugin-priorities
15:26:36 <apevec> dmsimard, packstack doesn't need priorities, that's required for delorean
15:26:49 <dmsimard> apevec: ok
15:26:57 <apevec> but packstack should work with either epel enabled or disabled
15:27:04 * dmsimard nods
15:27:25 <apevec> but also not enable epel
15:27:43 <dmsimard> So when using delorean, yum-plugin-priorities should be installed. Where can we document that ?
15:28:11 <apevec> jpena, can you push packstack rebase with rdo-release conditional to f23 and master ?
15:28:23 <apevec> jpena, I only pushed this hier workaround fix as rpm patch today
15:28:30 <jpena> apevec: ok, I will
15:28:42 <jpena> #action jpena to push packstack rebase with rdo-release conditional to f23 and master
15:28:59 <apevec> dmsimard, good question, where do we document using delorean at all?
15:29:12 <dmsimard> apevec: I don't think we actually do. Do we ?
15:29:27 <dmsimard> I've never seen it if we do
15:29:37 <apevec> dmsimard, good place would be landing page http://trunk.rdoproject.org/
15:29:38 <jruzicka> wait, why do delorean require yum-plugin-priorities?
15:29:54 <apevec> jruzicka, b/c relying on generated NVR to win is fragile
15:30:04 <dmsimard> jruzicka: because packages are in both delorean and delorean-deps
15:30:12 <dmsimard> with different semver/nvr
15:30:20 <jruzicka> when it's not installed, what happens? breakage?
15:30:21 <apevec> Delorean generated Version-Release is not Fedora pre-release compliant
15:30:37 <dmsimard> jruzicka: you might pick up an older version from delorean-deps instead of delorean
15:30:38 <apevec> jruzicka, unexpected older version is installed
15:30:43 <jruzicka> that's horrible
15:30:47 <jruzicka> so that must be prevented
15:30:51 <jruzicka> strong dependency
15:30:59 <apevec> jruzicka, yum priorities prevent that
15:31:04 <apevec> jruzicka, strong dep?
15:31:06 <dmsimard> I'm still not sure I understand that, I tried to get number80 to explain to me
15:31:13 <number80> dmsimard: np
15:31:14 <jruzicka> I mean either make SURE yum-priorities are present
15:31:23 <jruzicka> or detect that and refuse to work
15:31:39 <jruzicka> installing other than intended packages is not cool thing to do
15:31:40 <apevec> jruzicka, yeah, that means release RPM for delorean
15:31:43 <dmsimard> jruzicka: it's only for delorean, I'm not sure how we can do that just for delorean
15:31:44 <jruzicka> exactly
15:31:50 <dmsimard> or that
15:31:54 <jruzicka> dmsimard, package ^
15:31:59 <jruzicka> that's where I was getting
15:32:18 <jruzicka> delorean is a big dude now and he deserves it's package
15:32:28 <jruzicka> it can be ultra-automagic or manually maintained
15:32:29 <dmsimard> jruzicka: so one rpm per mirror ?
15:32:33 <dmsimard> one rpm pre repo*
15:32:33 <number80> ok, I suggest that we move the discussion post-meeting?
15:32:35 <dmsimard> per*
15:32:39 <apevec> yeah
15:32:44 <dmsimard> ok
15:32:52 <apevec> just for info:
15:32:59 <apevec> #info Fedora pre-release versioning https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages
15:33:25 <apevec> and play with rpmdev-vercmp to compare Version-Release
15:33:56 <dmsimard> #action dmsimard figure out if consuming delorean is documented, if so, ensure yum-plugin-priorities is marked as required - otherwise create docs
15:34:23 <number80> dmsimard: good point
15:34:25 <number80> next topic
15:34:34 <number80> #topic Status of pymysql migration
15:34:38 <jpena> so that's me
15:34:57 <jpena> we're in the middle of the puppet-* updates, tracked at https://review.openstack.org/#/q/status:open+branch:master+topic:PyMySQL-driver,n,z
15:35:57 <number80> #info puppet modules are updated to use pymysql as default driver
15:36:10 <number80> https://review.openstack.org/#/q/status:open+branch:master+topic:PyMySQL-driver,n,z
15:36:14 <jpena> after reading apevec's comment regarding the pymysql package name (python2-PyMySQL at the time) I went on for an alternative in the puppet-neutron patch ->  https://review.openstack.org/245229, where we are not setting any package to be installed
15:36:27 <jpena> and rely on the python-oslo-db dependency
15:36:46 <apevec> looks like this approach now has +1 upstream?
15:36:58 <jpena> this way, we avoid future naming issues in RHEL, where the package will most likely be named python-PyMySQL
15:37:07 <number80> yup
15:37:16 <jpena> apevec: actually I was waiting for your +1 to extend this to every other patch :)
15:37:31 <apevec> ...combined w/ old Puppet where Provides do not work...
15:37:40 <apevec> jpena, oh
15:38:20 <jpena> I have convinced the puppet community, I just wanted to be sure the approach was also correct from the packaging point of view
15:38:21 <number80> apevec: we can push puppet4 this week
15:38:40 <ibravo> can we also talk about https://bugzilla.redhat.com/show_bug.cgi?id=1272572 in the meeting?
15:38:46 <apevec> jpena, ok, acked in gerrit
15:38:51 <rbowen> ibravo: Sure. Put it on the agenda.
15:38:58 <rbowen> ibravo: https://etherpad.openstack.org/p/RDO-Packaging
15:39:03 <jpena> cool then
15:39:09 <apevec> jpena, ideal solution would be to update puppet but meh
15:39:29 <jpena> apevec: yes, but the upstream modules still support earlier versions, so...
15:39:41 <number80> #action number80 push puppet4 in EPEL7/CBS
15:40:01 <apevec> number80, doesn't puppet4 required facter3 ?
15:40:19 <number80> apevec: nope, it's not a hard requirement
15:40:42 <number80> Fedora ships it without facter3
15:40:42 <trown> 584508
15:40:52 <number80> next?
15:41:02 <jpena> yes
15:41:05 <number80> #topic RDO Day
15:41:09 <rbowen> As I mentioned on rdo-list, we are 2 months from the RDO Day in FOSDEM
15:41:09 <number80> rbowen: the stage's yours
15:41:16 <rbowen> SO far we have 2 topic submissions
15:41:36 <rbowen> If there are topics that we should cover at that event, please submit them to the Google Form
15:41:38 <apevec> we need moar
15:41:54 <rbowen> So, right now we have one on bare metal and RDO Manager
15:41:58 <rbowen> And one on how to use Delorean
15:42:23 <rbowen> Note that if you suggest a topic, that doesn't mean you need to prepare a presentation, just that you're willing to facilitate discussion.
15:42:36 <rbowen> #link https://www.rdoproject.org/blog/2015/11/rdo-community-day-fosdem/
15:42:41 <dmsimard> yeah, I can try to think of something but I can't go
15:42:43 <trown> I will not be able to attend, but if someone wanted to do a demo of RDO-Manager quickstart (not demoable today :p) I would create the demo
15:42:49 <elmiko> i'm new to fosdem, should these topics be more developer focused or are end user stories welcome as well?
15:42:52 <Humbedooh> since this is FOSDEM and very programmer heavy, maybe a "how to contribute to..." thing?
15:42:52 <rbowen> Although, if you want to give a presentation, that's fine too.
15:42:58 <apevec> rbowen, shall I submit strategy one, like "Quo vadis RDO?"
15:43:18 <rbowen> Also, if you want to give a presentation to a larger audience, the IaaS devroom CFP is still open.
15:43:30 <number80> Humbedooh: that's not exactly the same audience (a lot of Sysadmins will be there)
15:43:44 <trown> +1 to how to contribute...
15:43:47 <rbowen> elmiko: User stories are welcome. I think we'd give preference to more tech content, but, at the moment, we don't have any of that. :-)
15:44:06 <Humbedooh> aren't we all devops these days anyway ;)
15:44:08 <elmiko> rbowen: ack, thanks. i'll give some thought to it
15:44:17 <apevec> dewops?
15:44:25 <number80> :)
15:44:38 <rbowen> The RDO Day is specifically for folks that are involved in the RDO community, so that's the audience. Most of them will be developers or OpenStack operators.
15:44:43 <trown> docs are contributions too
15:44:58 <Humbedooh> +1!
15:45:01 <rbowen> So, next week, I'm going to start tracking down individuals and twisting arms.
15:45:06 <rbowen> Beat the rush
15:45:08 <rbowen> That's all I have.
15:45:12 <number80> thanks
15:45:30 <number80> #topic CentOS Cloud SIG meeting
15:45:34 <rbowen> Reminder. CentOS Cloud Sig meeting tomorrow 15:00 UTC
15:45:35 <rbowen> #link https://etherpad.openstack.org/p/centos-cloud-sig
15:45:46 <rbowen> In #centos-devel IRC channel
15:45:46 <number80> #info CentOS Cloud Sig meeting tomorrow 15:00 UTC
15:45:49 <rbowen> EOL
15:46:01 <trown> that will probably be a light from the US attendance
15:46:14 <trown> s/be a/be a bit/
15:46:19 <rbowen> Yes, I'm sure it will. I will be eating too much turkey at the time.
15:46:35 <elmiko> rbowen: +1
15:47:06 <apevec> poor turkies
15:47:11 <rbowen> :-)
15:47:22 <number80> trown: we'll try to record the sessions
15:47:32 <rbowen> Yes, we plan to have a camera
15:47:36 <rbowen> Eliska is bringing one.
15:47:42 <number80> great
15:47:44 <rbowen> So we'll have video
15:47:45 <elmiko> apevec: https://en.wikipedia.org/wiki/Tofurkey
15:47:59 <number80> remains two topics and the hour is closing
15:48:09 <rbowen> Yes, I'm done.
15:48:11 <rbowen> EOL
15:48:12 <number80> #topic qemu-kvm vs qemu-kvm-rhev
15:48:19 <csim> elmiko: I am not sure, is it big data or pokemon ?
15:48:19 <dmsimard> So just wanted to put this out there.. I'm still a noob so forgive my ignorance but yesterday I learned that we should probably be shipping RDO with qemu-kvm-rhev instead of qemu-kvm as rhev supports additional features such as snapshotting or numa awareness.
15:48:28 <elmiko> csim: hahaha!
15:48:43 <apevec> there's qemu-kvm-ev from Virt SIG
15:48:43 <dmsimard> Packstack will definitely attempt to install rhev if it's available from the installed repositories but Packstack will not install the Centos Virt SIG in which rhev resides
15:49:01 <apevec> this was just mentioned on rdo-list
15:49:09 <dmsimard> oh, it was ? I'm not up to date
15:49:20 <apevec> question is do we want hard dep on -ev in openstack-nova
15:49:32 <apevec> or make it somehow soft-dep
15:49:37 <dmsimard> Well my question was more along the lines of
15:49:39 <apevec> e.g. packstack installs it if available?
15:49:40 <number80> apevec: what about having a centos-release-openstack-xxx depends on centos-release-virtsig as a first step?
15:49:45 <dmsimard> apevec: yes
15:49:51 <number80> apevec: I'd make it an hard dep on EL
15:49:52 <apevec> number80, that works too
15:49:55 <trown> if we make sure the package is available, hard dep seems reasonable
15:50:05 <dmsimard> apevec: https://github.com/openstack/packstack/blob/cbbf46e6af6e449a5a7c99e417750d45fb2ecef0/packstack/puppet/templates/nova_compute_libvirt.pp#L13-L19
15:50:28 <apevec> ah so that's trick
15:50:43 <apevec> ok, I'll update sig release rpm
15:51:02 <number80> #action apevec update sig release rpm to add dependency on virt SIG repo
15:51:03 <dmsimard> So my question was more along the lines of: I thought we had all the dependencies in our repositories. qemu-kvm definitely isn't in there. So do we pull rhev from sig virt or do we pull it in the RDO repo ?
15:51:05 <number80> thanks!
15:51:05 <apevec> #action apevec make centos-release-openstack RPM depend on virt sig
15:51:09 <apevec> #undo
15:51:09 <zodbot> Removing item from minutes: ACTION by apevec at 15:51:05 : apevec make centos-release-openstack RPM depend on virt sig
15:51:26 <dmsimard> So I guess the answer is we add a dependency on the virt sig repo
15:51:27 <apevec> dmsimard, virt sig
15:51:37 <number80> dmsimard: qemu-kvm is in base CentOS
15:51:44 <number80> qemu-kvm-ev isn't
15:51:46 <apevec> yeah, otherwise we'll end up w/ glibc in RDO repo
15:51:53 <dmsimard> apevec: so how do we get this in delorean ?
15:52:02 <apevec> add it to -deps
15:52:10 <dmsimard> so another #action ? :)
15:52:13 <apevec> yep
15:52:21 <apevec> #action apevec add virt sig to delorean-deps.repo
15:52:34 <number80> amen
15:52:35 <dmsimard> sgordon: well there you have it ^
15:52:41 <dmsimard> thanks that's it
15:52:55 <number80> #topic horizon bug
15:52:56 <number80> https://bugzilla.redhat.com/show_bug.cgi?id=1272572
15:52:58 <number80> trown:
15:53:04 <trown> it is actually a THT bug
15:53:13 <dmsimard> THT ?
15:53:15 <number80> #undo
15:53:15 <zodbot> Removing item from minutes: <MeetBot.items.Link object at 0x7f08c25868d0>
15:53:19 <number80> #undo
15:53:19 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0xe2a2bd0>
15:53:21 <trown> tripleo-heat-templates
15:53:33 <number80> #topic tripleo-heat-templates bug
15:53:36 <dmsimard> oh.
15:53:37 <number80> https://bugzilla.redhat.com/show_bug.cgi?id=1272572
15:53:48 <ibravo> I believe it needs to enter the public IP of the node.
15:54:03 <trown> I have a patch up for it... need to bug tripleo folks for feedback
15:54:26 <trown> ibravo: have you tried the workaround in the bug? or the patch linked there?
15:54:29 <trown> both work for me
15:54:39 <number80> #info trown has a patch ready, needs feedback from tripleo folks
15:54:53 <ibravo> yes. they do work. Just first install fails
15:55:01 <trown> #action trown bring up bz1272572 in tripleo meeting
15:55:15 <number80> thanks
15:55:19 <ibravo> thanks
15:55:27 <number80> then last but not least topic
15:55:32 <number80> #topic next week chair
15:55:41 <number80> who wants it?
15:55:42 <chandankumar> i would like to chair for next meeting.
15:55:48 <trown> nice
15:55:51 <trown> thanks chandankumar
15:55:53 <number80> #info chandankumar to chair next meeting
15:55:56 <number80> thanks chandankumar
15:56:13 <number80> Thanks gentlemen for attending, time to close the curtains
15:56:17 <number80> #endmeeting