Tuesday, 2017-12-19

*** marst has quit IRC00:35
*** tuanla____ has joined #openstack-meeting-500:38
*** tuanla____ has quit IRC00:53
*** tuanla____ has joined #openstack-meeting-500:54
*** iyamahat has joined #openstack-meeting-501:17
*** zaneb has quit IRC01:27
*** tuanla____ has quit IRC02:20
*** tuanla____ has joined #openstack-meeting-502:21
*** yamahata has quit IRC03:12
*** yamahata has joined #openstack-meeting-503:17
*** markvoelker has joined #openstack-meeting-503:24
*** yamahata has quit IRC03:27
*** iyamahat has quit IRC03:27
*** iyamahat has joined #openstack-meeting-503:27
*** iyamahat has quit IRC03:35
*** markvoelker has quit IRC03:58
*** ricolin has joined #openstack-meeting-504:31
*** iyamahat has joined #openstack-meeting-504:42
*** tuanla____ has quit IRC04:54
*** tuanla____ has joined #openstack-meeting-504:55
*** markvoelker has joined #openstack-meeting-504:55
*** yamamoto has joined #openstack-meeting-504:57
*** yamamoto has quit IRC05:07
*** yamamoto has joined #openstack-meeting-505:08
*** yamamoto has quit IRC05:27
*** markvoelker has quit IRC05:28
*** yamamoto has joined #openstack-meeting-505:30
*** tuanla____ has quit IRC05:33
*** yamamoto has quit IRC05:36
*** iyamahat_ has joined #openstack-meeting-505:53
*** iyamahat has quit IRC05:53
*** tuanla____ has joined #openstack-meeting-505:58
*** markvoelker has joined #openstack-meeting-506:25
*** yamamoto has joined #openstack-meeting-506:35
*** yamamoto has quit IRC06:41
*** markvoelker has quit IRC06:59
*** roman_g has joined #openstack-meeting-507:17
*** yamamoto has joined #openstack-meeting-507:45
*** tuanla____ has quit IRC08:10
*** tuanla____ has joined #openstack-meeting-508:11
*** markvoelker has joined #openstack-meeting-508:56
*** markvoelker has quit IRC09:29
*** derekh has joined #openstack-meeting-509:36
*** markvoelker has joined #openstack-meeting-510:26
*** yamamoto has quit IRC10:55
*** yamamoto has joined #openstack-meeting-510:55
*** yamamoto has quit IRC10:56
*** yamamoto has joined #openstack-meeting-510:56
*** markvoelker has quit IRC11:00
*** yamamoto has quit IRC11:09
*** yamamoto has joined #openstack-meeting-511:13
*** yamamoto has quit IRC11:18
*** markvoelker has joined #openstack-meeting-511:57
*** yamamoto has joined #openstack-meeting-512:06
*** yamamoto has quit IRC12:10
*** markvoelker has quit IRC12:29
*** yamamoto has joined #openstack-meeting-512:38
*** yamamoto has quit IRC12:39
*** tuanla____ has quit IRC12:39
*** markvoelker has joined #openstack-meeting-513:27
*** markvoelker has quit IRC13:28
*** markvoelker has joined #openstack-meeting-513:29
*** yamamoto has joined #openstack-meeting-513:40
*** yamamoto has quit IRC13:48
*** makowals has joined #openstack-meeting-513:53
*** annp has joined #openstack-meeting-513:54
*** hoangcx_ has joined #openstack-meeting-513:55
*** felipemonteiro has joined #openstack-meeting-514:47
*** hoangcx_ has quit IRC14:52
*** tlam_ has joined #openstack-meeting-514:53
*** d|k has joined #openstack-meeting-514:57
*** d|k is now known as daveKormann14:58
*** gmmaha has joined #openstack-meeting-514:59
mattmceuen#startmeeting openstack-helm15:00
openstackMeeting started Tue Dec 19 15:00:44 2017 UTC and is due to finish in 60 minutes.  The chair is mattmceuen. Information about MeetBot at http://wiki.debian.org/MeetBot.15:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.15:00
*** openstack changes topic to " (Meeting topic: openstack-helm)"15:00
mattmceuen#topic rollcall15:00
*** raymaika has joined #openstack-meeting-515:00
openstackThe meeting name has been set to 'openstack_helm'15:00
*** openstack changes topic to "rollcall (Meeting topic: openstack-helm)"15:00
mattmceuenGM/GE all!15:01
raymaikao/15:01
portdirecto/15:01
daveKormannhihi!15:01
*** zaneb has joined #openstack-meeting-515:01
v1k0d3nhere.15:01
mattmceuenall your awesome agenda topics go here -> https://etherpad.openstack.org/p/openstack-helm-meeting-2017-12-1915:01
gmmahao/15:01
srwilkerso/15:01
alanmeadowso/15:02
mattmceuenNot bad for the week before christmas :)15:03
daveKormannit's next week that'll be the real litmus test.15:03
icolwello/15:04
mattmceuen#topic holistic etcd approach15:04
*** openstack changes topic to "holistic etcd approach (Meeting topic: openstack-helm)"15:04
mattmceuenThis was a holdover from last week, and I just wanted to make sure we rounded out the conversation and didn't leave any points hanging15:04
mattmceuenTo refresh our memory:15:05
mattmceuen    Various charts trying to use etcd, can we (and should we) unify an approach, or let etcds sprinkle the cloud?15:05
mattmceuen    e.g. https://review.openstack.org/#/c/525752/15:05
mattmceuen    Rabbit would likely follow in approach at some point15:05
mattmceuen    Calico ....15:05
mattmceuen    ...15:05
mattmceuen(there were general good feelings around this notion last week)15:05
portdirectwe need a real etcd chart15:06
portdirectthe one we have today is useful - but essentially a toy15:06
daveKormanndumb question: ceph doesn't currently make any use of etcd; would it make any sense for things like pool and topology things to go there?15:06
v1k0d3n++15:06
portdirectdaveKormann: I dont think there is a need for that15:07
daveKormannkk15:07
tlam_o/15:07
srwilkersa real etcd chart would be nice for things like mistral, where etcd can be used as a backend.  would be nice to have a standard approach for using etcd instead of just random disjoint etcds everywhere15:07
portdirectwe should be able to model that via values, and get the info we need from the lma stack15:07
daveKormannyah, was mostly thinking about the stuff that might change post-deployment15:07
daveKormannie, pools.15:07
portdirectthat should be a chart update really15:08
daveKormannbut yeah, probably unnecessary and fair point about chart updates.15:08
portdirectwe should also revisit the etcd operator15:08
v1k0d3n++ :)15:08
portdirectbefore embarking on 'building from sratch'15:09
mattmceuenwe probably need a good spec to gather ideas for said etcd, to ensure it's general enough to fit the bill for all interested consumers.15:09
v1k0d3netcd operator is actually pretty solid.15:09
portdirecti think it would make sense to do a spec here - were we can weigh the pros and cons?15:09
mattmceuen+115:09
v1k0d3n+115:09
mattmceuenand make sure we add the folks we know in the etcd chart consumer/creator world as reviewers15:10
mattmceuenvolunteer for the spec effort?15:10
*** marst has joined #openstack-meeting-515:10
*** kiennt26 has joined #openstack-meeting-515:11
portdirectI could strawman, but would not have time before mid jan to work on it in depth.15:11
mattmceuen#action team to create a spec for a general-purpose etcd chart, portdirect to put out a strawman to facilitate conversation15:11
mattmceuenthat would be awesome portdirect.  I think just having it out there is a good first step and we can build from there.  Maybe referencing out to prior etc art so folks can find it.15:12
mattmceuenAny other points on the etcd front before we move on?15:13
mattmceuen#topic RBAC rework (lamt)15:13
*** openstack changes topic to "RBAC rework (lamt) (Meeting topic: openstack-helm)"15:13
mattmceuenGo for it tlam_ !15:13
mattmceuen     https://review.openstack.org/#/c/526464/15:13
portdirectis tlam_ here?15:14
mattmceuenhe o/ 'd us15:14
v1k0d3ni see lamt15:14
tlam_I am here15:14
v1k0d3nlol15:14
tlam_on a smurf15:14
portdirectcan you give us a rundown of your rbac work?15:15
tlam_I would like some eyes on that patch set that does a few things15:15
tlam_portdirect,  sure15:15
tlam_1. it addresses the issue where some injected SA and its associated resources from lingering when the chart is deleted15:16
tlam_2. it now dynamically (don't like that word, but..) generate the role and binding in the proper namespaces15:17
tlam_as well as provide read only access to the resources it needs15:17
tlam_to enforce the concept of least-priv15:17
tlam_3. the PS also starts to move things from clusterrole -> role as part of the effort to remove naming collision15:18
portdirectthats awesome tin15:19
portdirectreally moves us forward there15:19
tlam_portdirect, thx, would really like feedback on that PS15:19
v1k0d3nyeah, great job.15:19
mattmceuenyeah that's fantastic - thanks for doing that work Tin, will take a look15:19
portdirectremoving the hack to mount a service account and then graning an amdin readonly role is a bit win :D15:19
portdirect*granting15:19
portdirecttlam_: dont worry - I'm hammering it right now ;)15:20
v1k0d3ntin, are you getting much feedback from sean and the team in CSO where you're at?15:20
v1k0d3ni'm looking forward to seeing their feedback on PS like this.15:20
v1k0d3ni'm discussing with Dan Solero too...just to make sure there are eyes there to help out.15:20
tlam_most of them are on vacation :)  I will send a note out though15:20
tlam_for all sec-related PS so they are aware15:21
v1k0d3nlol sounds like the team i know.15:21
v1k0d3nthat would be great. let me know if i can help?15:21
v1k0d3ni know the desire is there for sure.15:21
tlam_least priv is one of those things they like, so I am sure they'd like it15:21
portdirectthey are also involved in the design ;)15:22
mattmceuenSounds excellent - let's get some solid feedback on that PS guys15:22
mattmceuenThanks tlam_ !15:22
mattmceuen#topic Ceph pod-per-OSD/device support15:23
*** openstack changes topic to "Ceph pod-per-OSD/device support (Meeting topic: openstack-helm)"15:23
v1k0d3n+!15:23
daveKormannall right then.15:23
daveKormannso, gmmaha and i have been working on this.15:23
daveKormannwe had a previous patchset to support a ceph OSD device and pod-per-osd model15:24
daveKormannbut after feedback from portdirect we've rebooted.15:24
daveKormannthe patchset i put in the etherpad is the replacement:15:24
daveKormannhttps://review.openstack.org/#/c/527505/15:24
portdirectdaveKormann: can we align this with rootfs15:24
portdirectand the rest of the ceph-helm folks15:25
portdirectso that we can move to deprecate our ceph chart asap15:25
daveKormannyeah, definitely.  i went and looked at what ceph-helm had and when i looked it seemed to be approximately what the previous OSH patch had15:25
daveKormannwe're still very close to that in model, but i've reworked the scripts.  i'll pursue unifying the two15:25
portdirectthat would be awesome15:25
daveKormannmost of the work, though, is in the gate test stuff15:26
daveKormannwhich now has its own playbook15:26
portdirectI'm about to make a ps over there t remove helm-toolkit15:26
portdirectand simplify the chart, removing all openstack specific things15:26
daveKormannkewl15:26
gmmahaportdirect: that is awesome15:26
daveKormanni don't think we're QUITE ready for reviews on our new ps until we work to unify it with the ceph-helm side15:27
daveKormannbut it wouldn't hurt to have input particularly on the test design15:27
mattmceuendaveKorman - also, just to make sure you're looped in on the convo we had last week which also touched on the ceph long-term plan -- logs from last week http://eavesdrop.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-12-12-15.00.log.html  (search for ceph :)  )15:27
gmmahaportdirect: daveKormann: are we merging the two beforfe the patch or post?15:27
portdirectalso - do you peeps want a hand with getting a gate env up and running?15:27
gmmahaor we just align the patch so that it is easy to merge15:27
portdirectI think that depends on the ci/cd we can get in place15:27
*** kiennt26 has quit IRC15:27
gmmahaportdirect: i see. alright15:28
mattmceuen@gmmaha -15:28
mattmceuen15:44:15 <portdirect> 1) Split Keystone endpoint creation out of the ceph chart and into its own thing (that would live in OSH)15:28
mattmceuen15:44:15 <portdirect> 2) Merge the healthchecks from OSH into Ceph-Helm15:28
mattmceuen15:44:15 <portdirect> 3) Merge the luminous support from Ceph-Helm into OSH15:28
mattmceuen15:44:15 <portdirect> 4) Update the loopback device creation scripts from bash to ansible15:28
mattmceuen15:44:16 <portdirect> 5) Combine the disc targetting efforts from both OSH and Ceph-Helm into a single effort that brings the reliability of RH's approach with the OSD by bus-id from OSH15:28
mattmceuen15:44:16 <portdirect> 6) The Ceph-Helm chart will then be moved/mirrored to k8s/charts15:28
mattmceuen15:44:17 <portdirect> 7) At this point, add an OSH gates to experimentally use the Ceph-Helm chart15:28
mattmceuen15:44:17 <portdirect> 8) Once stabilised and we have confidence, depreciate the OSH ceph chart15:28
mattmceuen15:44:45 <portdirect> the order is obviously somewhat flexible - but as a general outline how does this seem?15:28
mattmceuen(from last week ^)15:28
daveKormannyeah, it would probably make sense for us to have a gate env.  most of the ridiculously high rev number on that patch is me wrestling with the differences between my ansible and the osh one15:28
portdirectcool - I'll prioritise that15:29
daveKormann4 i think is the bulk of what we've done here.15:29
gmmahamattmceuen: thanks.. (kicking myself for not reading it properly)15:29
*** felipemonteiro has quit IRC15:29
portdirectso we have some devices that survive a reboot in a vm :)15:29
mattmceuenno worries gmmaha :)15:29
daveKormannwe've definitely got that now, and i've rewritten the zap: support so it can be used again15:29
daveKormannpreviously, enabling "zap" broke pod/node restart.  now it does all kinds of sanity checking to only zap a foreign disk15:30
*** felipemonteiro has joined #openstack-meeting-515:30
daveKormannsounds like that's one of those things we need to work on merging with ceph-helm15:30
daveKormannis rootfs the best contact for that?15:31
portdirectdaveKormann: I'd say so15:31
daveKormanngreat.  i'll hit him up.15:32
gmmahathe current state of the PS will fail dev-deploy unless we add new flags for the ceph-osd to use a directory based backend. I am trying to hack the daemonset-osd to fllback to the current default directory based osd but my helm hackery is not that great (just yet). Wanted to get the pulse of the community here. We ok with adding new flags or would we prefer to stick to ceph-osd=enabled and have it all work under that15:32
gmmahathat is the one place i am sorta stuck at and trying to figure it out15:33
daveKormannthat's likely another place we should coordinate with ceph-helm, since presumably they also want a unified model for directories/device-backed OSDs15:34
gmmahadefinitely..15:35
gmmahai will take the general silence as we are alright eitheways as long as ceph-helm folks & us are unified ont hat15:36
gmmaha:)15:36
mattmceuen+1 on that :)15:36
portdirectsilence is tantamount to agreement on irc :D15:37
gmmaha:D15:37
mattmceuenNext topic:15:37
mattmceuen#topic roadmap to v 1.0 OSH15:37
*** openstack changes topic to "roadmap to v 1.0 OSH (Meeting topic: openstack-helm)"15:37
mattmceuenv1k0d3n it's all yours15:37
v1k0d3nhey all. from outside looking in, so many good things/improvements are being added.15:38
portdirectyou are a cor you know ;)15:38
portdirect*core15:38
v1k0d3nhaven't forgotten.15:38
v1k0d3nbut that's a sidenote? lol15:38
v1k0d3nwondering for community eyes on the project where we're defining completion for a v1.0.0 roadmap?15:39
v1k0d3nversion information targets, etc.15:39
mattmceuenOne convo from a couple months back had some criteria along those lines:  http://eavesdrop.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-10-31-15.00.log.html15:39
mattmceuen(search for newton)15:40
mattmceuen15:14:36 <portdirect> 1) support node/cluster reboot fully15:40
mattmceuen15:14:56 <portdirect> 2) get the charts in correct repos15:40
mattmceuen15:15:18 <portdirect> 3) get voting gates15:40
srwilkersyeah, i feel like we've revisited this topic more than a few times15:40
v1k0d3nwe have.15:40
v1k0d3nso should i give my leadership this link to evesdrop?15:41
srwilkersare you asking for a firm declaration of a date?15:41
v1k0d3nnot at all.15:41
portdirectI dont think the critieria have changed15:41
srwilkersbecause those three points above are still the requirements and have been discussed openly.  they represent the majority of the work that's been done lately15:41
v1k0d3nwhat version of kubernetes, etcd, etc?15:42
portdirectand we are moving full steam ahead to try and achive that15:42
v1k0d3nis this not a good idea to document in the repo somewhere?15:42
portdirectthats same as it always has been15:42
portdirectthe current release of k8s etc at the time of release15:42
mattmceuenv1k0d3n I agree it's a good thing to document outside of the etherpad15:42
portdirectso 1.9.0 here15:42
v1k0d3nnobody thinks it's a bit unclear for new-comers to the project?15:42
portdirectat the moment15:42
portdirectunless it takes us three months to get there15:42
srwilkersin a previous meeting, the versions we actively support for openstack-helm will be what's gated against15:42
mattmceuenIs this a good thing for a spec, or is this more a wiki type animal?15:42
portdirectin which case 1.10 ;)15:42
srwilkerssorry, we agreed in a previous meeting that the version we support will be what we gate against15:43
portdirecta wiki - as its flexible15:43
srwilkers^15:43
portdirecti think referenced in the docs is where to go15:43
portdirectand that should also be fully gated15:43
portdirectjust as we have done with the aio guide15:43
mattmceuenyeah, I think to v1k0d3n's point, this is less about making decisions, and more about communicating them15:43
v1k0d3ntarget? or current? there's a difference.15:43
portdirectwe need to gate all the docs15:43
v1k0d3nyes, communicating target for v1.15:43
portdirectthe target is the current release at the point of our release.15:44
v1k0d3nnot worried about current. since we don't have a branch/tagged release yet...giving users a guide is helpful. it also is a call to action.15:44
portdirectfor all upstream components, etcd, k8s etc15:44
srwilkersi dont see how listing a target of release versions equates to a call to action15:45
v1k0d3nwhat i'm referring to isn't uncommon at all. especially for a core to bring it up.15:46
v1k0d3ntargets give the community eyes on patterns of intent.15:46
v1k0d3nif there's no work done, but it's listed as a target...then they can help pick up that work.15:46
v1k0d3nhttps://github.com/kubernetes/kubernetes/milestones/15:46
v1k0d3n^^ great example of what other projects do, and what i'm referring to.15:46
srwilkersafter we cut a 1.0 release, that would be more feasible15:47
srwilkersi dont think setting arbitrary milestones before then is very helpful to getting us there15:47
mattmceuenI'm good with specifying the target versions of key dependencies, as long as they're malleable until the actual release, to reflect reality15:47
mattmceuenYeah, we tried the milestone approach early in OSH history, and I don't think it bought us all that much15:49
alanmeadowsI think we're getting bogged down in targets, the main takeaway I get from this is we've been missing a LP or whatever equivalent of https://github.com/kubernetes/kubernetes/milestones/15:49
alanmeadowsa "clear" march towards a cut, or whatever the next target may be15:50
portdirectmattmceuen: could you create a blueprint for the road to 1.0.0 ?15:50
portdirectwould that align with the above?15:50
mattmceuenportdirect was already going to volunteer :)15:50
v1k0d3nmilestones help other companies/users buy in. that's a powerful tool to get more users.15:50
srwilkersif it puts this issue to bed, i think that'd a good idea15:50
v1k0d3njust trying to help. i don't want to put a thorn in anyone's side.15:51
mattmceuenWe're all aligned on the need to document a 1.0, and I think there's still more thought to be had into how granular to make targets post 1.015:51
mattmceuen#action mattmceuen to take a stab at leadership- and community-communicable targets for the initial stable OSH release15:52
mattmceuenThanks for bringing it up v1k0d3n, I think it's a good thing to get down in a concise way.15:52
mattmceuenYou keep the floor!15:52
v1k0d3nlet me know if i can help. i can rally folks around it with targets.15:52
mattmceuen#topic blueprints in OSH15:52
*** openstack changes topic to "blueprints in OSH (Meeting topic: openstack-helm)"15:52
v1k0d3nsorry...not targets. milestones?15:53
mattmceuenthanks v1k0d3n will do :)15:53
v1k0d3njust reminder really to submit blueprints really.15:55
v1k0d3nwe submitted a blueprint for some work we hired ericsson to work on, but were told someone else had a lot of work towards the same chart.15:55
srwilkersid like to point out that blueprint was filed friday during kubecon15:56
v1k0d3nwith blueprints, it can really save overlap on work, etc.15:56
srwilkersonly after i had chatted about working on ODL in my spare time15:56
v1k0d3nright. giving enough time for anyone to submit their work.15:56
srwilkersand it was just happenstance that we both had been working on said chart with no blueprint filed for it15:56
v1k0d3nright.15:56
v1k0d3nso we submitted a blueprint so anyone could pick it up.15:57
mattmceuenv1k0d3n I don't think we've had a practice to submit blueprints, just specs, right?15:57
srwilkersthere's an assignee with a marked approver, and that blueprint was approved when i looked last15:57
srwilkersthat indicates someone had already been targeted for doing that work15:57
srwilkersbut the person who submitted the WIP wasnt the assignee15:57
mattmceuenRe specs, from http://eavesdrop.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-12-05-15.00.log.html15:57
mattmceuen15:05:49 <mattmceuen> 1. when a change impacts multiple charts15:57
mattmceuen15:06:09 <mattmceuen> 2. when a change needs design feedback from the larger team prior to implementation15:57
mattmceuen15:06:24 <mattmceuen> 3. when a change does something substantially new that'll be modeled in other charts later15:57
mattmceuen15:07:06 <mattmceuen> The gist being:  write specs as a means to drive common understanding (think: useful documentation) and common direction (think: everyone's aligned)15:57
srwilkersso this confuses me a bit15:57
v1k0d3nsorry, what confuses you srwilkers?15:58
mattmceuenexecutive decision15:59
mattmceuentabling this please.15:59
srwilkersyou claim you submitted a blueprint so anyone can pick up the work, but blueprint assignees  are expected to be the ones performing the work15:59
mattmceuenthis is good conversation, but for another venue.15:59
v1k0d3nthis is getting sideways. i thought there was an ask to submit blueprints.15:59
v1k0d3nwe didn't really want the overlap in work at all.16:00
portdirectsounds like v1k0d3n's point is spot on16:00
portdirectand before commencing on work a bp should be sumbitted16:00
mattmceuenYup I get it v1k0d3n, not saying blueprints are a bad topic16:00
mattmceuenjust a sore topic16:01
portdirectthe before is important..16:01
portdirectbut this should not be a hard req16:01
v1k0d3nin this case it could've save a lot of money. i would've much rather had srwilkers work quite honestly.16:01
v1k0d3nno. totally agree portdirect not a hard requirement.16:01
v1k0d3ni don't want process to be heavy at all16:01
srwilkersmeetings over, let's clear this out and take whatevers left to OSH16:02
mattmceuenwe will reconvene this topic16:02
mattmceuenOnly one last topic16:02
mattmceuenoops we're over time :)16:03
mattmceuen#endmeeting16:03
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/"16:03
openstackMeeting ended Tue Dec 19 16:03:12 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:03
openstackMinutes:        http://eavesdrop01.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-12-19-15.00.html16:03
openstackMinutes (text): http://eavesdrop01.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-12-19-15.00.txt16:03
openstackLog:            http://eavesdrop01.openstack.org/meetings/openstack_helm/2017/openstack_helm.2017-12-19-15.00.log.html16:03
mattmceuenThanks all16:03
*** gmmaha has left #openstack-meeting-516:04
*** daveKormann is now known as d|k16:05
*** d|k has left #openstack-meeting-516:05
*** raymaika has quit IRC16:08
*** ricolin has quit IRC16:19
*** tlam_ has quit IRC16:28
*** annp has quit IRC16:44
*** iyamahat_ has quit IRC17:04
*** derekh has quit IRC17:47
*** iyamahat has joined #openstack-meeting-518:40
*** ricolin has joined #openstack-meeting-519:11
*** iyamahat has quit IRC19:11
*** alanmeadows has quit IRC19:15
*** alanmeadows has joined #openstack-meeting-519:15
*** iyamahat has joined #openstack-meeting-519:28
*** ricolin_ has joined #openstack-meeting-519:38
*** ricolin has quit IRC19:40
*** openstack has joined #openstack-meeting-519:43
*** ChanServ sets mode: +o openstack19:43
*** yamahata has joined #openstack-meeting-519:47
*** tdasilva has quit IRC19:47
*** tdasilva has joined #openstack-meeting-519:47
*** ricolin_ has quit IRC19:53
*** mattmceuen_ has joined #openstack-meeting-520:57
*** mattmceuen_ has quit IRC20:58
*** mcnanci has quit IRC21:03
*** icolwell has quit IRC21:05
*** mcnanci has joined #openstack-meeting-521:07
*** nkp349 has quit IRC22:12
*** nkp349 has joined #openstack-meeting-522:16
*** marst has quit IRC22:41
*** felipemonteiro has quit IRC23:24
*** felipemonteiro has joined #openstack-meeting-523:24

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!