Tuesday, 2014-05-20

*** emagana has quit IRC00:00
*** banix has joined #openstack-meeting-300:01
*** eghobo has joined #openstack-meeting-300:09
*** SumitNaiksatam has joined #openstack-meeting-300:10
*** eguz has quit IRC00:12
*** kenhui has quit IRC00:14
*** Sukhdev has joined #openstack-meeting-300:16
*** sarob has quit IRC00:17
*** sarob has joined #openstack-meeting-300:17
*** kenhui has joined #openstack-meeting-300:20
*** sarob has quit IRC00:22
*** TravT has quit IRC00:22
*** chuckC has joined #openstack-meeting-300:24
*** cjellick has quit IRC00:26
*** Sukhdev has quit IRC00:30
*** banix has quit IRC00:35
*** ttrifonov is now known as ttrifonov_zZzz00:42
*** MaxV has joined #openstack-meeting-301:00
*** krotscheck has quit IRC01:12
*** rgbkrk has quit IRC01:12
*** krotscheck has joined #openstack-meeting-301:15
*** kenhui has quit IRC01:22
*** nati_ueno has quit IRC01:27
*** safchain has quit IRC01:27
*** banix has joined #openstack-meeting-301:32
*** eghobo has quit IRC01:35
*** lcheng has joined #openstack-meeting-301:44
*** sankarshan is now known as sankarshan_away02:07
*** lcheng has quit IRC02:11
*** rgbkrk has joined #openstack-meeting-302:22
*** kenhui has joined #openstack-meeting-302:22
*** kenhui has quit IRC02:31
*** lcheng has joined #openstack-meeting-303:03
*** sankarshan_away is now known as sankarshan03:13
*** MaxV has quit IRC03:18
*** kenhui has joined #openstack-meeting-303:27
*** nati_ueno has joined #openstack-meeting-303:29
*** kenhui has quit IRC03:31
*** coolsvap|afk is now known as coolsvap03:37
*** lcheng has quit IRC03:40
*** rgbkrk has quit IRC03:44
*** nati_ueno has quit IRC03:55
*** kenhui has joined #openstack-meeting-303:58
*** Sukhdev has joined #openstack-meeting-303:59
*** eghobo has joined #openstack-meeting-304:00
*** banix has quit IRC04:00
*** kenhui has quit IRC04:02
*** nati_ueno has joined #openstack-meeting-304:05
*** kenhui has joined #openstack-meeting-304:12
*** kenhui has quit IRC04:31
*** nati_ueno has quit IRC04:49
*** nati_ueno has joined #openstack-meeting-304:50
*** lcheng has joined #openstack-meeting-304:50
*** MaxV has joined #openstack-meeting-305:04
*** MaxV has quit IRC05:09
*** mrunge has joined #openstack-meeting-305:39
*** mrunge has joined #openstack-meeting-305:39
*** nati_uen_ has joined #openstack-meeting-305:46
*** nati_ueno has quit IRC05:49
*** nati_uen_ has quit IRC05:52
*** nati_ueno has joined #openstack-meeting-305:53
*** Sukhdev has quit IRC05:59
*** kenhui has joined #openstack-meeting-306:06
*** kenhui has quit IRC06:11
*** nati_ueno has quit IRC06:45
*** jcoufal has joined #openstack-meeting-306:48
*** lcheng has quit IRC06:48
*** nati_ueno has joined #openstack-meeting-306:58
*** kenhui has joined #openstack-meeting-307:07
*** kenhui has quit IRC07:11
*** eghobo has quit IRC07:20
*** yamamoto has quit IRC07:23
*** nati_ueno has quit IRC07:56
*** nati_uen_ has joined #openstack-meeting-307:58
*** safchain has joined #openstack-meeting-308:05
*** kenhui has joined #openstack-meeting-308:07
*** MaxV has joined #openstack-meeting-308:09
*** kenhui has quit IRC08:12
*** MaxV has quit IRC08:13
*** yamamoto has joined #openstack-meeting-308:23
*** danpb has joined #openstack-meeting-308:26
*** jamie_h has joined #openstack-meeting-308:27
*** coolsvap is now known as coolsvap|afk08:32
*** yamamoto has quit IRC08:45
*** kenhui has joined #openstack-meeting-309:08
*** sankarshan is now known as sankarshan_away09:09
*** MaxV has joined #openstack-meeting-309:10
*** nati_uen_ has quit IRC09:10
*** kenhui has quit IRC09:12
*** MaxV has quit IRC09:15
*** coolsvap|afk is now known as coolsvap09:55
*** jtomasek has joined #openstack-meeting-310:01
*** jcoufal has quit IRC10:09
*** jcoufal has joined #openstack-meeting-310:09
*** overlayer has joined #openstack-meeting-310:31
*** kenhui has joined #openstack-meeting-310:32
*** overlayer has quit IRC10:34
*** overlayer has joined #openstack-meeting-310:35
*** kenhui has quit IRC10:36
*** mrunge has quit IRC10:46
*** sankarshan_away is now known as sankarshan11:02
*** kenhui has joined #openstack-meeting-311:32
*** overlayer has quit IRC11:35
*** igordcard has joined #openstack-meeting-311:35
*** kenhui has quit IRC11:37
*** nacim has quit IRC11:40
*** mrunge has joined #openstack-meeting-311:41
*** igordcard has quit IRC11:41
*** igordcard has joined #openstack-meeting-311:42
*** igordcard has quit IRC11:42
*** igordcard has joined #openstack-meeting-311:43
*** nacim has joined #openstack-meeting-311:53
*** HenryG has quit IRC11:53
*** banix has joined #openstack-meeting-312:01
*** banix has quit IRC12:04
*** mrunge has quit IRC12:12
*** dhellmann_ is now known as dhellmann12:16
*** coolsvap is now known as coolsvap|afk12:22
*** gcb has joined #openstack-meeting-312:29
*** kenhui has joined #openstack-meeting-312:33
*** kenhui has quit IRC12:38
*** nati_ueno has joined #openstack-meeting-312:55
*** julim has joined #openstack-meeting-312:58
*** lblanchard has joined #openstack-meeting-313:02
*** thimble has joined #openstack-meeting-313:03
*** nati_ueno has quit IRC13:04
*** gcb has quit IRC13:06
*** yamahata has joined #openstack-meeting-313:11
*** mwagner_lap has quit IRC13:11
*** nacim has quit IRC13:13
*** nati_ueno has joined #openstack-meeting-313:22
*** banix has joined #openstack-meeting-313:23
*** nacim has joined #openstack-meeting-313:26
*** dhellmann is now known as dhellmann_13:27
*** kenhui has joined #openstack-meeting-313:28
*** nati_ueno has quit IRC13:33
*** kenhui has quit IRC13:44
*** peristeri has joined #openstack-meeting-313:47
*** nati_ueno has joined #openstack-meeting-313:56
*** sahid has joined #openstack-meeting-313:58
*** dirk has joined #openstack-meeting-314:08
*** akrivoka has joined #openstack-meeting-314:12
*** rgbkrk has joined #openstack-meeting-314:16
*** gcb has joined #openstack-meeting-314:20
*** BobBall has joined #openstack-meeting-314:21
*** TravT has joined #openstack-meeting-314:32
*** nati_ueno has quit IRC14:32
*** jcoufal has quit IRC14:33
*** MaxV has joined #openstack-meeting-314:37
*** david-lyle has joined #openstack-meeting-314:40
*** s1rp has joined #openstack-meeting-314:42
*** sarob has joined #openstack-meeting-314:42
*** MaxV has quit IRC14:44
*** nelsnelson has joined #openstack-meeting-314:45
*** apmelton1 has joined #openstack-meeting-314:47
*** mwagner_lap has joined #openstack-meeting-314:48
*** MaxV has joined #openstack-meeting-314:50
*** MaxV has quit IRC14:50
*** nati_ueno has joined #openstack-meeting-314:51
*** TravT has quit IRC14:51
*** hallyn has joined #openstack-meeting-314:54
*** jpich has joined #openstack-meeting-314:54
*** thomasem has joined #openstack-meeting-314:56
*** sarob has quit IRC14:57
*** mfer has joined #openstack-meeting-314:57
*** sarob has joined #openstack-meeting-314:57
*** bauzas has joined #openstack-meeting-314:58
*** vladikr has joined #openstack-meeting-314:59
s1rpo/14:59
thomasemo/15:00
danpb#startmeeting libvirt15:00
openstackMeeting started Tue May 20 15:00:16 2014 UTC and is due to finish in 60 minutes.  The chair is danpb. 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: libvirt)"15:00
openstackThe meeting name has been set to 'libvirt'15:00
*** apmelton1 is now known as apmelton15:00
*** apmelton has quit IRC15:00
* kashyap waves hi as a bug traiger15:00
*** apmelton has joined #openstack-meeting-315:00
apmeltono/15:00
danpb#topic Intro15:00
*** openstack changes topic to "Intro (Meeting topic: libvirt)"15:00
vladikro/15:01
danpbHi folks, welcome to the first libvirt sub-team meeting !15:01
thomasemhey hey!15:01
dirkhurray!15:01
s1rphowdy!15:01
sahid:)15:01
* bauzas lurking...15:01
danpbagenda / place for taking live notes is https://etherpad.openstack.org/p/nova-libvirt-meeting-agenda15:01
*** berendt has joined #openstack-meeting-315:01
*** cjellick has joined #openstack-meeting-315:01
*** sarob has quit IRC15:01
thomasemOkay cool15:02
danpbjust so that we know each other, would folks just introduce their real name and area of interest15:02
s1rpRick Harris, improving LXC support in nova-libvirt15:03
danpbI'm Daniel Berrange, @ Red Hat, upstream libvirt maintainer & interested in anything libvirt/kvm/lxc related in nova15:03
apmeltonAndrew Melton, LXC in nova-libvirt15:03
*** cjellick has quit IRC15:03
BobBallBob Ball @ Citrix, interested in xen15:03
*** sew has joined #openstack-meeting-315:03
dirkDirk Mueller @ SUSE, working with BobBall on Xen/libvirt now15:03
thomasemI'm Thomas Maddox, @ Rackspace, interested in LibvirtLXC and nova-libvirt primarily15:03
*** cjellick has joined #openstack-meeting-315:03
bauzasSylvain Bauza @Red Hat, working on Scheduling aspects for HA, including libvirt capabilities15:03
vladikrI'm Vladik Romanovsky @ eNovance, interested in libvirt/kvm/lxc in Nova15:04
hallynSerge Hallyn @ ubuntu, packaging libvirt and qemu15:04
berendtChristian Berendt @ B1 Systems, primary interested in libvirt/xen15:04
*** ndipanov has joined #openstack-meeting-315:04
nelsnelsonNels Nelson @ Rackspace, security testing for libvirt-lxc applications15:04
thimbleAndre Naehring @ B1 Systems, interested in libvirt/xen15:04
*** JuanManuelOlle has joined #openstack-meeting-315:04
ndipanovare we doing names now?15:04
danpbndipanov: yep, just quickly introducing ourselves15:05
ndipanovk\15:05
danpbok, seems like we have critical mass of attendees for the topics in the agenda at least15:05
ndipanovNikola Dipanov - Red Hat engineer working on libvirt (among other things) - also Nova core reviewer15:05
kashyapI'm Kashyap Chamarthy, working for Red Hat, upstream tester for KVM/QEMU based virt-stack and OpenStack RDO community engineer.15:05
gcbI'm ChangBo Guo @easystack  interested in libvirt/kvm15:06
ndipanovs/libvirt/libvirt driver in my previous intro15:06
sahidSahid Orentino Ferdjaoui - Cloudwatt interested in libvirt/kvm15:06
danpb#topic Suitability of meeting time15:06
*** openstack changes topic to "Suitability of meeting time (Meeting topic: libvirt)"15:06
thomasemThis time actually works great for me.15:07
dirk+115:07
s1rp++, love this time15:07
danpbI picked this time slot to suit myself primarily :-)  is this slot practical for people ongoing15:07
BobBall+115:07
vladikr+115:07
sahid+115:07
berendt+115:07
apmelton+115:07
ndipanov+115:07
gcb+115:07
*** directxman12 has joined #openstack-meeting-315:07
danpbhehe, well that's nice to see15:07
thomasemhaha15:07
bauzasthere is a conflict with Nova scheduler meeting, so we need to discuss about a possible another stop for Gantt meetings15:07
BobBall+2 +A?15:07
thimble+115:07
*** n0ano has joined #openstack-meeting-315:08
kashyapSince I'm in a slightly weird tz than CET/EST/PST, /me is fine w/ 20:30 meeting once a week :-)15:08
danpbdo people think there is value in alternating timeslot every two weeks ?  eg have a Tuesday @0900  UTC timeslot15:08
danpbthis would exclude most of the  US, but make it easier for China/India/Japan15:08
* danpb notes that the people who would care about the alternate time probably aren't here to answer .... :-(15:09
BobBallI'd agree with alternate time slots - I think it works well for nova - although they go the other way with an evening slot that I can't typically attend15:09
kashyapMaybe start w/ once a month, if there's more folks from that region possibly could alternate. But that's just me15:09
s1rpshould we put that to a vote?15:09
danpbperhaps we should just send another message to  openstack-dev to ask if there is demand for an alternate slot15:10
ndipanovI'm fine with both - but danpb mentioned we'd be willing to do it on the email - let\s see if someone wants it first maybe15:10
*** MaxV has joined #openstack-meeting-315:10
kashyapYep15:10
berendtdanpb: +115:10
bauzasdanpb: I'm fine with the alternate timeslot, great to see it15:11
danpbok, so lets stick with this time slot for now, and check demand from mailing list before adding a 2nd option15:11
*** nati_ueno has quit IRC15:11
thomasemsounds good to me15:12
danpbmoving swiftly onto the more interesting items....15:12
danpb#topic HV driver support requirements15:12
*** openstack changes topic to "HV driver support requirements (Meeting topic: libvirt)"15:12
danpblooking at the mess we made of Xen and LXC support in Icehouse, it occurred to me that we don't have a clear idea of what nova requires from a libvirt driver15:13
danpbso I've started trying to clarify this on this page so we can identify gaps https://wiki.openstack.org/wiki/LibvirtDriverSupportMatrix15:13
*** vishy has joined #openstack-meeting-315:13
vishyo/15:13
danpbbesides APIs, i'm looking to add list of constants used with the APIs, and list of guest configuration options15:14
danpbif anyone wants to help out with fleshing out this page, it'd be appreciated15:14
s1rpawesome, can we do this programmatically?15:14
danpbs1rp: if by programmatically you mean 'grep' then yes :-)15:15
s1rpdanpb: yes exactly :)15:15
apmeltondanpb: how about flags as well. I know lxc doesn't support starting paused15:15
danpbapmelton: yeah that's what i mean by constants actually15:15
apmeltongotcha15:15
directxman12apmelton: yeah, that's a important bit15:15
*** absubram_ has joined #openstack-meeting-315:15
danpbat least that's the main bit which hurt us in Icehouse15:16
danpbso lets move onto Xen...15:16
BobBallI wonder if some of https://wiki.openstack.org/wiki/HypervisorSupportMatrix should be moved into it's own libvirt page15:16
directxman12BobBall: I was thinking that, and wondering if libvirt actually had anything similar15:17
directxman12if not, it really should15:17
BobBallwell - 4 of the columns in that table are libvirt15:17
danpbBobBall: hmm, i can see it both values15:17
danpbit is valuable to have a complete picture of all drivers in one page15:17
danpbif you just had a single Libvirt column, then you'd have to then look at a separate libvirt page to find out what your specific libvirt HV supported15:18
s1rpthe libvirt columns should be next to each other to make parity easier to check15:18
BobBallI agree - just raising it as an option15:18
berendts1rp: +115:18
*** lcheng has joined #openstack-meeting-315:18
danpbs1rp: yeah, we could move the Xen column over15:18
thomasem+115:18
BobBallOr have a different layout of the table - for example a libvirt column with the default being KVM then Q/X/L in the column as well if supported by the other drivers15:19
danpbBobBall: i think we could keep separate columns for now - unless the number of libvirt drivers really grows alot15:20
danpblets talk Xen now though15:20
danpb#topic Xen Driver Support15:20
*** openstack changes topic to "Xen Driver Support (Meeting topic: libvirt)"15:20
BobBallOK15:20
danpbberendt: this was your agenda item...15:21
berendtjust noted this entry. i think there are some more interested parties15:21
*** jtomasek has quit IRC15:21
berendtwe need libvirt/xen working and we would like to help building a CI environment15:22
BobBallWell I'm definitely an interested party - but don't have an update to share this week really15:22
dirkI'm also interested.. we're looking at setting up a CI for libvirt/xen atm15:22
dirkprobably expect some update within ~ 2 weeks15:22
danpbfrom my POV, I think it is important to keep Xen working well with Libvirt driver in Nova, but I don't have resource to spend on dev/CI myself -15:22
dirkfor now it would be great to have this not removed from the code so that we can start looking at the issues15:23
danpbi'd encourage those interested in the CI side of things to try to work together15:23
BobBallThen we should talk berendt :) I've got a 3rd party CI for XenServer set up running in RAX and it should be quite straight forward to update that (possibly to run in a different OS cloud) to run libvirt+xen15:23
berendtdirk: to you plan to involve other parties in the planned CI or is this SUSE cloud specific?15:23
berendtBobBall: yes15:24
dirkberendt: this is unrelated to SUSE Cloud15:24
dirkberendt: it is just about setting up testing with libvirt / xen backend for upstream reviews15:24
BobBallUsing SUSE as the OS running devstack + tempest would be interesting though15:25
danpbdirk: unless I've misjudged opinions of other core devs, we're not at imminent risk of being forced to remove Xen support from libvirt driver, but I think they'd like to see CI up & running in the near future15:25
dirkBobBall and I met at the summit and talked a bit about it, and we're now looking into the options15:25
BobBallparticularly becasue it'd be another env that devstack doesn't currently get tested in15:25
dirkdanpb: great, we're aligned then.15:25
berendtI would suggest to share efforts and to discuss about details in a separate meeting (dirk, BobBall)15:25
dirkdanpb: we'd also like to see the CI running so that we don't have to catch regressions downstream15:25
BobBallAgreed berendt - I'm happy to take this offline.15:26
*** mestery has quit IRC15:26
BobBallwell, not offline, but out of here so we can get progress / questions / etc to report here ;)15:26
danpbberendt: agreed, sounds like RAX & SUSE folks can co-ordinate and just report interesting progress as & when needed15:26
*** MaxV has quit IRC15:26
berendtand B1 Systems ;)15:26
danpbopp, yes, sorry :-)15:26
BobBall+115:26
*** mestery has joined #openstack-meeting-315:26
dirkwfm15:26
danpbso, besides CI testing, does anyone have other Xen related issues to raise today15:27
*** gcb has quit IRC15:28
berendtnot at the moment, I think a working CI environment is the primary task15:28
danpbyep, should give us a much better idea of what state we're in15:29
danpbso, lets move onto LXC15:30
danpb#topic  LXC Driver Support15:30
*** openstack changes topic to "LXC Driver Support (Meeting topic: libvirt)"15:30
danpbs1rp: do you want to start it off...15:30
s1rpwe should clean up the image/disk handling code :)15:31
apmelton+115:31
s1rpthat was mentioned quite a few times at the summit15:31
thomasem+115:31
*** gcb has joined #openstack-meeting-315:31
danpbassume you're specifically referring to the hacks we do with loopback and/or qemu-nbd for mounting the root filesystem15:31
s1rpthe disk-mount code is particularly hard to follow, so i was looking into using libvirts 'block' type to clean it up15:32
s1rpdanpb: yeah that's part of it15:32
thomasems1rp, There was some testing done by sew yesterday specifically regarding that, I think. I don't know if you caught that.15:32
thomasem(it was a bit after hours :)15:32
danpbyep, i added support to libvirt lxc for  type=file & type=block filesystems, specifically to let us remove this in nova15:32
thomasemoh neat15:33
s1rpthomasem: yeah, he mentioned that the 'block' type didn't work off the bat w/ uid-mapping enabled15:33
s1rpthomasem: so definitely need to look into why15:33
danpbthe problem with the usernamespace uid/gid mapping stuff15:33
thomasemYeah, and then he mentioned that using the nova-compute method he was able to get it... so let's get more detail on that.15:33
thomasemhmm?15:33
danpbis that we'd have todo a massive chown across the entire filesystem15:33
vishydanpb, s1rp is there any way we could avoid using nbd / lo at all?15:34
danpbsince presumably the user uploaded images will actually use  uid=015:34
danpband we'll need to remap that to uid=NNN instead, to match whatever uid nova configures for the root user15:34
danpbvishy: not if our filesystems are file based15:34
apmeltondanpb: unless users are aware they need to create images owned by NNN15:34
danpbapmelton: feels kind of dirty to require the end user to know that though15:35
apmeltonyes it does15:35
thomasemHow would we communicate that? Doesn't it pick from a range?15:35
* danpb wishes the kernel let you specify a uid/gid mapping for filesystem mounts15:35
apmeltonthomasem: the patch I have right now uses a static mapping15:35
thomasemoh15:35
thomasemokay15:35
*** MaxV has joined #openstack-meeting-315:35
danpba static mapping is sufficient to protect the kernel from the container processes15:35
hallynthe idea of a stackable fs to do that mapping has been floated for a few years :)  noone's done it yet though15:36
apmeltondanpb: so the way image import works at rackspace now is a async task in glance, perhaps the import process for lxc images would include chowning that image for the user15:36
*** MaxV has quit IRC15:36
danpbapmelton: yep, if we have a static mapping for all containers, ideally we'd only apply the chown once for image uploaded to glance, or at least to the base image cached by nova15:37
danpbcertainly want to try to avoid doing it for every instance start15:37
apmeltondanpb: so for the cached image by nova, that would mean each compute would need to chown at least once per image15:37
danpbapmelton: yeah15:38
apmeltondanpb: so, I'm going to be pushing up a spec for this today, if we wanna push this discussion onto the spec, that might save time here15:38
danpbhallyn: would it have to be a stacked FS - i can see that would be nice for dealing with bind mount approach15:38
apmeltonthis discussion being user namespaces in nova15:38
danpbhallyn: but if you're doing the first mount of a block device, feels like it'd be nice to be able to just pass a mapping straight to the kernel at first mount15:39
danpbapmelton: yep, doing it in the spec sounds like a good idea15:39
hallyndanpb: ouch, i'd have to think through it more.  it dpeneds on whether we could do it without separate inodes per file15:39
hallyn(per uid-shifted mount, i mean)15:40
hallynbut agreed, a property of a bind mount would be far nicer15:40
danpbhallyn: probably out of scope for us to solve here :-)15:41
hallynbut in scope to motivate here, so cool15:41
danpbapmelton: s1rp: so  env variables / init path15:42
danpbi agree it'd be good to be able to set those15:43
danpbenv variables i think is actually missing in libvirt itself too15:43
s1rpyeah, think you can hack it by setting them on the init_path15:43
apmeltonenv variables needs support in libvirt before we can expose it, but init path already works, it's just hard coded in nova15:43
danpbs1rp: hmm, if that works, it is by luck15:43
s1rpbut would be nice to support via an 'env' XML tag15:44
danpbbut i'm fairly sure libvirt is directly calling  execve() so the initpath must be a real path and nothing else15:44
thomasemYou're not kidding. Hard coded.15:44
s1rpdanpb: haven't confirmed it does, just looked like it'd be possible15:44
s1rpdanpb: but either way, we should support env variables, passing args, etc15:44
danpbthe way we expose these concepts in nova is probably something we should defer to the general containers sub-team, whose meeting is in 15 mins time15:45
s1rpso we also need a way to collect the return code15:45
danpbsince I know this is a wishlist item for Docker guys too15:45
s1rpyeah15:45
s1rplots of overlap15:45
danpbwe should at least maintain a list of what we want specificially for libvirt LXC though15:45
*** eghobo has joined #openstack-meeting-315:46
*** jackib has joined #openstack-meeting-315:46
danpbso those 3 things can we our starting point15:46
danpbso lets talk CI again15:46
danpbi recall from the summit several people wanted to help with CI15:47
s1rpRAX is interested in helping w/ LXC testing15:47
danpband (IIRC) jog0 said it could be part of the official CI, not a 3rd party CI15:47
apmeltonmikal: was also asking for lxc to be in the upstream gate I believe15:47
danpbpresumably though we'll need some interested people to make sure the CI stuff is actually working well enough for LXC before infra will be willing to enable it15:48
thomasemyeah15:48
thomasemWe have one person working on those tests at the moment15:49
danpbexcellent15:49
thomasemI'll catch up with him and see if we can get him coming to these meetings too.15:50
danpbso i suggest we just do same as with Xen CI -  RAX and other interested parties just go away and work on it, and report back progress and/or problems as needed15:50
thomasemMight be nice to have a regular update on that sort of progress15:50
danpbyep, again it'd be excellent if we can get something active during Juno15:51
*** tzumainn has joined #openstack-meeting-315:51
thomasemI agree15:51
thomasem=]15:51
danpbjust time for one last topic....15:51
danpb#topic Bug Triage15:52
*** openstack changes topic to "Bug Triage (Meeting topic: libvirt)"15:52
kashyapHi, currently there are 118 bugs tagged as 'libvirt'15:52
apmeltonis there a query I can use to see untriaged bugs?15:52
danpbanyone know what other virt driver sub-teams do for bug triage ?15:53
kashyapapmelton, All "New" Nova bugs are here -- https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New15:53
apmeltonthanks kashyap15:53
danpbie have they got a good practice we can/should follow15:53
kashyapdanpb, VMWare folks did it recenty15:53
*** santib has joined #openstack-meeting-315:53
kashyapThe process is outlined here -- https://wiki.openstack.org/wiki/BugTriage15:53
danpbah, i see15:53
directxman12kashyap: I've been trying to help out with triaging new bugs by following the above posted wiki page15:53
kashyapOnly thing is consistently applying it - (a) Go through list of Nova bugs periodically, tag relevant bugs as 'libvirt' appropriately (b) Root-cause analysis/poke reporters for bugs w/ less info, etc.15:54
danpbso I guess the real need here is to have a few people who actually have time to actively do bug triage ...15:54
danpband to draw attention to high priority issues15:55
vladikrI'll try to help on that15:55
kashyapI can volunteer15:55
*** clu_ has joined #openstack-meeting-315:55
kashyapdirectxman12, Likewise here too15:55
*** thimble has quit IRC15:55
kashyapAlso a lot of bugs I see are woefully short on info, so I wrote this page and post it as a gentle reminder where appropriate -- https://wiki.openstack.org/wiki/BugFilingRecommendations15:55
danpbso i'd say anyone interested just go off and do it, and if you see high priority bugs that need to be addressed, add them to the agenda for the weekly meeting and/or ping  relevant people on irc15:56
directxman12kashyap: for ones already tagging libvirt, I've been marking them as incomplete and asking for more info if they don't provide version information and logs of some sort15:56
kashyapdirectxman12, Yep, I just did that discreetly for a few bugs while this meeting is going on15:57
danpbit might be an idea to setup a wiki page describing the things we commonly need for troubleshooting libvirt related problems15:57
danpbeg on fedora we've got this  http://fedoraproject.org/wiki/How_to_debug_Virtualization_problems15:57
*** MaxV has joined #openstack-meeting-315:58
danpbthere's probably something we could do that's a bit more tailored to openstack's needs15:58
kashyapAh, true, I was about to just post that.15:58
*** nati_ueno has joined #openstack-meeting-315:58
*** crobertsrh has joined #openstack-meeting-315:58
kashyapYeah, nova debug/verbose logs enabling15:58
danpbwell looks like we're out of time here15:58
danpbthanks to everyone for coming along, and  see you all next week at same time !15:58
thomasemcheers!15:58
directxman12yeah, occaisonally people post pretty useless logs15:58
*** gary-smith has joined #openstack-meeting-315:58
vladikrthanks15:59
directxman12au revoir15:59
s1rpthanks all!15:59
*** hallyn has left #openstack-meeting-315:59
dirkthanks!15:59
*** directxman12 has left #openstack-meeting-315:59
*** thomasem has left #openstack-meeting-315:59
*** vladikr has left #openstack-meeting-315:59
*** apmelton has left #openstack-meeting-315:59
* s1rp off to the containers meeting15:59
*** nelsnelson has left #openstack-meeting-315:59
kashyapSee ya.15:59
danpb#endmeeting15:59
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"15:59
openstackMeeting ended Tue May 20 15:59:42 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:59
openstackMinutes:        http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-05-20-15.00.html15:59
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-05-20-15.00.txt15:59
openstackLog:            http://eavesdrop.openstack.org/meetings/libvirt/2014/libvirt.2014-05-20-15.00.log.html15:59
tzumainnhi guys!16:01
crobertsrhhowdy!16:01
clu_hi!16:01
lsmolahello16:01
*** MaxV has quit IRC16:01
*** jackib has quit IRC16:02
berendtbye16:02
*** doug-fish has joined #openstack-meeting-316:02
david-lyle#startmeeting Horizon16:02
openstackMeeting started Tue May 20 16:02:14 2014 UTC and is due to finish in 60 minutes.  The chair is david-lyle. Information about MeetBot at http://wiki.debian.org/MeetBot.16:02
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.16:02
*** openstack changes topic to " (Meeting topic: Horizon)"16:02
openstackThe meeting name has been set to 'horizon'16:02
david-lyleHello everyone, welcome back from the summit16:02
akrivokahi everyone16:02
gary-smithhello16:02
santibhi guys16:02
doug-fishHi all16:03
*** dirk has left #openstack-meeting-316:03
*** johnma has joined #openstack-meeting-316:03
jpichhello16:03
lblanchardhi all!16:04
lchenghello16:04
johnmaHello16:04
*** elmiko has joined #openstack-meeting-316:04
*** berendt has left #openstack-meeting-316:04
david-lyleI feel the key take aways from the summit for Horizon were, we need to improve the user experience and we want to accelerate client side development to accomplish that16:04
david-lylevery much a simplification, of course16:05
doug-fishagreed - that's a clear take away.16:05
*** jackib has joined #openstack-meeting-316:05
lblanchard+116:05
*** gcb has quit IRC16:06
david-lyleThere are other items for Juno that we did not discuss that we need to accomplish like Sahara support16:06
*** nacim has quit IRC16:06
jpichI think the improving error messages blueprint should definitely be on the roadmap as well16:07
crobertsrh+116:08
doug-fishmy take-aways are that there is general agreement accessibility is important, internationalization needs some fixes, and we should invest more in our horizon (non tempest) integration testing that is already started.16:08
lblanchardjpich: +1 I will get the work I've done around a suggestion for UI guidelines on Error Messaging up on the wiki today and share16:08
david-lyledoug-fish, agreed, I implicitly lumped the first two into user experience :)16:08
doug-fish:-)  sounds good.16:09
johnmafor those who werent able to attend the summit, is there a place where we can go to get a summary of the sessions or topics discussed?16:09
*** devlaps has joined #openstack-meeting-316:09
clu_yes the etherpads16:09
david-lylehttps://wiki.openstack.org/wiki/Summit/Juno/Etherpads#Horizon16:09
jpichjohnma: Looking through the etherpads should be a good initial first step, I think. I'm not sure anything more formal has been posted elsewhere16:09
*** nati_ueno has quit IRC16:09
jpichthough if someone has blogged about the sessions I'd love to read it :)16:10
santibhi guys, about improving the error messages, there are a bunch of cases where we are duplicating logic in horizon in order to show an appropriate error message to the users16:10
johnmajpich: Sure, sounds good. Thanks16:10
santibwas there any discussion about that? I mean duplicating logic in horizon16:10
doug-fishsantib:  are you talking about the fact that Horizon generally doesn't trust messages from the APIs?16:11
johnmaThanks clu_16:11
jpichsantib: I think in this case duplication is appropriate, if it's necessary to provide a better experience for the user16:11
santibnot a trust issue but a precision issue16:11
santibjpich: i would agree but what if the logic changed?16:12
jpichI don't think there's been a discussion per se or not recently, it just seems to be the status quo16:12
david-lyleThe status code on the response should not change meaning16:12
*** danpb has left #openstack-meeting-316:12
doug-fishsantib: I don't think we really got into the internal detail about _why_ the messages are they way they are.  (at least, not while I was paying attention!)16:12
doug-fishwe just agreed they needed improvement16:12
santibwe would have to be very careful to make sure that the change in the logic is appropriately propagated16:13
david-lylesantib: I'm still not following which logic?16:13
*** otherwiseguy has joined #openstack-meeting-316:13
*** MaxV has joined #openstack-meeting-316:13
david-lylearound showing message 'a' if 401 and 'b' if 409?16:14
santibexample....we are making sure that when the user extend a volume, the new size does not exceed the user quota16:14
santibthat check is done in horizon and in cinder as well16:14
doug-fishdavid-lyle:  IMO that isn't granular enough...the error codes show only what class of error occurred by any detail the API response might have included about why the error occured in lost16:15
santibwhat if cinder changes the way they validate that? what if they suddenly decide that users could extend the volume no matter what their quota is16:15
doug-fishat least as far as I've seen16:15
santibin that case we would have to propagate that logic change to horizon16:16
doug-fishIt would be ideal in santib 's case that we just trust the API response from cinder to tell us not only that there was a failure, but it happened because of a quota problem16:16
santibexactly16:16
clu_are the openstack community aware of the error messaging issue...?16:16
david-lyledoug-fish: without localized, user consumable error messages coming back from the services, this is difficult to do16:17
doug-fishdavid-lyle - agreed16:17
david-lylebecause you have to duplicate the laundry list of possible errors16:17
david-lylethis is something we need to work on cross-project16:17
doug-fishI guess my vision (half baked idea?) is that we go API call by API call, sort out which ones really need more detail, work with the API people, and then trust the message that comes back for that API call16:18
santibthere are a bunch of cases like this in horizon. We are duplicating logic from nova, cinder, glance, etc. I'm not against it but we need to be sure that we are consistent across modules16:18
david-lylesantib: advanced logic changes like that are going to be reactionary16:18
david-lylewe can monitor the services, but at some point they break us, and we make a fix16:18
*** yamahata has quit IRC16:18
david-lylehazard of being at the top of the stack16:18
doug-fishMaybe we can even get certain well defined error scenarios into tempest?16:19
doug-fishto make sure when we create certain failures we get a reliable message back?16:19
doug-fishunder penalty of not passing gate!16:19
david-lyleonce we have integration tests running in tempest yes, that would be a great use of them16:19
santibagree16:19
doug-fishNot sure we even need to test that through horizon16:19
david-lylewhich is why that's a high priority16:20
doug-fishwe could set that up with the related API calls16:20
doug-fishI though the Horizon integration tests could/would never be in Tempest?16:20
jpichThe long term goal is to merge them back16:21
jpichfor now we're trying to figure them out and make sure they're stable16:21
*** dkorn has joined #openstack-meeting-316:21
jpichthen the feedback from the Tempest folks was that they'd be open to considering it16:21
jpichalso we could have a separate job for the horizon integration tests that runs on all commits, possibly - but that's too be discussed when we have a larger, well honed test suite16:22
doug-fishyeah - that 2nd thing makes more sense to me16:22
jpichPeople interested in writing integration tests, feel free to add yourself to https://wiki.openstack.org/wiki/Horizon/Testing/UI#Test_areas_breakdown and start submitting patches :-)16:22
david-lylewe are in a unique position to test integration of all the clients, which IMO adds a lot of value across the stack16:23
doug-fishthe problem with putting UI tests in Tempest is that when the UI changes, the tests need to as well.  I'm not sure we can ever put out changes to the UI that would require an update to the Tempest tests16:23
doug-fishso we should all work on the stuff jpich linked!16:23
david-lylehow those integration tests get wired into the gate, is TBD16:23
doug-fishdavid-lyle  do you think it will happen?16:23
jpichdoug-fish: the page object pattern helps a lot with this. The "page" would still live in Horizon but the tests themselves could move into Tempest16:23
jpichdoug-fish: That's certainly one of my goals :)16:24
doug-fishjpich ah interesting.  Yeah, I could see that.16:24
*** MarkAtwood has joined #openstack-meeting-316:25
*** clu_ has quit IRC16:25
david-lyleopenstack does like CI testing, so I think there's a very good chance, if we approach it right16:25
*** clu_ has joined #openstack-meeting-316:25
*** BobBall has left #openstack-meeting-316:27
david-lyleThis week I will be going through the blueprints to create a tentative release plan for Juno.  So if there are items that you plan to work on, please assign yourself or ask a core to assign you16:27
david-lyleI don't add many items that don't have an assignee, due to odds of it getting done are low16:28
david-lylewe did have one agenda topic16:29
david-lyle#topic Drop Django 1.4 support? (kspear, in absentia)16:29
*** openstack changes topic to "Drop Django 1.4 support? (kspear, in absentia) (Meeting topic: Horizon)"16:29
david-lyleIcehouse is the last release supported by Ubuntu 12.04 LTS.16:30
david-lyleThis might mean less resistance to dropping Django 1.4 support in Juno.16:30
david-lyleIt would be good to reach a consensus at the meeting and then canvas the mailing lists for support.16:30
david-lylewas the text included16:30
*** TravT has joined #openstack-meeting-316:30
jpichIs Django 1.4 causing problems?16:30
david-lylethere are branches where we check for 1.516:30
david-lyleand greater16:31
jpichMy thinking would be that since it's supported upstream as a LTS it makes sense to try and keep supporting it for Horizon too, unless it's causing huge issues16:31
jpich( https://docs.djangoproject.com/en/dev/internals/release-process/#long-term-support-lts-releases )16:31
david-lylethe move to 1.6 was slowed by methods disappearing between 1.4 and 1.616:31
david-lylethere are issues, not overwhelming issues16:31
david-lylesince we won't be able to transition to 1.7 until the K cycle, I am ok with keeping 1.4 until that point16:32
david-lylehttps://docs.djangoproject.com/en/dev/releases/1.7/16:33
david-lyle1.7 requires python >= 2.716:33
*** otherwiseguy has quit IRC16:34
doug-fishDropping 1.4 support at K seems reasonable to me.  Is there some way that we share that plan so people can let us know if its going to cause a problem?16:34
doug-fishoh nevermind - canvas the mailing lists16:36
doug-fishgood plan.16:36
david-lylelike all things, we'll need to ping the mailing list16:36
jpichSounds reasonable to me16:37
jpichI dropped an email to Kieran to see if he could summarise his concerns about Django 1.4 on the list16:37
*** jpich has quit IRC16:37
*** jpich has joined #openstack-meeting-316:37
david-lylejpich, thanks16:37
david-lylewe'll come back to this next week then16:38
david-lyle#topic Open Discussion16:38
*** openstack changes topic to "Open Discussion (Meeting topic: Horizon)"16:38
jpichNp16:38
tzumainnI had a question - would people be interesting in looking at the tuskar-ui code to see if there are any divergences from the proper horizon way of doing things?16:38
tzumainner "interested"16:38
clu_tzumainn: sure!16:39
tzumainnthat would be awesome : )  Is there any sort of guidance the tuskar-ui folks could provide to help with that?16:39
jpichIdeally we should all get familiar with the code well ahead of it merging later, make the process as painless as possible :)16:39
tzumainnjpich, lol, yeah, I admit that fear was lurking in the back of my mind16:40
tzumainnwe also do a few things slightly differently - off the top of my head, we use mock instead of mox for tests, and we have a @handle_errors decorator for our api calls16:40
jpichDoes it give helpful error messages by default?16:40
jpich(helpful as in specific)16:41
tzumainnI am not entirely sure, but it does reduce code duplication16:41
*** pballand has joined #openstack-meeting-316:41
*** pballand has left #openstack-meeting-316:41
*** pballand has joined #openstack-meeting-316:42
jpichSounds like something we might want to borrow from you!16:42
tzumainnand doing it at the level of the api call means that it's less likely that potential error cases are less likely to get missed when writing the view code16:42
lsmolamock is the new recommended test framework right?16:42
david-lylelsmola, that sounds correct16:42
*** sew has left #openstack-meeting-316:42
jpichWe should cross-pollinate solutions and synergise our efforts across repo boundaries         (<-- do I win the bingo?)16:43
tzumainnbut yeah, overall, I'd be interested in ways to help making sure that tuskar-ui converges toward horizon rather than away16:43
tzumainnlol16:43
tzumainnalmost, except my card had 'synergize' instead of 'synergise'16:43
*** MaxV has quit IRC16:43
david-lyleI think support to mock frameworks may be a requirement going forward16:44
jpichI'm not clear on whether the mock vs mox3 debate was ever resolved but both sound good to me (I prefer mock personally) - don't think that'll be a problem16:44
david-lyles/to/two16:45
jpichah!16:46
*** jackib has quit IRC16:47
david-lyleany thing else, we just spent a week together, so ending early is just fine :)16:48
david-lylegoing twice...16:49
david-lyleHave a great week everyone. See you here next week.16:50
david-lyle#endmeeting16:50
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"16:50
*** gary-smith has left #openstack-meeting-316:50
openstackMeeting ended Tue May 20 16:50:52 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)16:50
jpichBye!16:50
openstackMinutes:        http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-05-20-16.02.html16:50
tzumainnthanks all!16:50
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-05-20-16.02.txt16:50
santibbye16:50
openstackLog:            http://eavesdrop.openstack.org/meetings/horizon/2014/horizon.2014-05-20-16.02.log.html16:50
lblanchardsee you all!16:51
*** doug-fish has left #openstack-meeting-316:51
*** johnma has left #openstack-meeting-316:51
lsmolathank you, goodbye everyone16:51
*** tzumainn has left #openstack-meeting-316:51
*** safchain has quit IRC16:52
*** otherwiseguy has joined #openstack-meeting-316:52
*** beyounn has joined #openstack-meeting-316:53
*** akrivoka has quit IRC16:53
*** pballand has quit IRC16:55
*** maurosr has joined #openstack-meeting-316:55
*** santib has left #openstack-meeting-316:56
*** absubram_ has quit IRC16:57
*** markmcclain has joined #openstack-meeting-316:59
*** baojg has joined #openstack-meeting-316:59
*** chuckC has quit IRC16:59
*** thinrichs has joined #openstack-meeting-317:00
*** pballand has joined #openstack-meeting-317:01
*** thinrichs has quit IRC17:01
pballandhi everyone17:02
*** jpich has left #openstack-meeting-317:02
*** thinrichs has joined #openstack-meeting-317:02
pballandanyone around for congress?17:02
*** lcheng has quit IRC17:02
*** crobertsrh has left #openstack-meeting-317:02
*** skn_ has joined #openstack-meeting-317:02
*** rgbkrk has quit IRC17:03
skn_Is this the Congress meeting?17:03
pballandyes, starting in one min17:03
skn_Great.  This is Susanta from Symantec17:04
pballand(thinrichs started in wrong room)17:04
thinrichs#startmeeting CongressTeamMeeting17:04
openstackMeeting started Tue May 20 17:04:28 2014 UTC and is due to finish in 60 minutes.  The chair is thinrichs. Information about MeetBot at http://wiki.debian.org/MeetBot.17:04
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.17:04
*** openstack changes topic to " (Meeting topic: CongressTeamMeeting)"17:04
openstackThe meeting name has been set to 'congressteammeeting'17:04
*** baojg has quit IRC17:04
pballandHi skn_ !17:04
thinrichsGlad to see people from the summit joining us!17:04
skn_Hi Peter and Tim17:04
*** sarob has joined #openstack-meeting-317:05
sarobI'm here17:05
pballandI heard from Rajdeep that he had a conflict and can’t meet this week17:05
pballandHi sarob !17:05
sarobpballand: hey17:05
pballandkudva also sends his regrets for this meeting17:05
skn_Hi peter, did you send out the group mail to share everyone’s id?17:06
pballandI have not yet - I was waiting for one more reply, but will send out after this meeting17:06
thinrichsI think we're all still recovering from the summit.17:06
*** rgbkrk has joined #openstack-meeting-317:06
skn_OK, great.17:06
skn_True17:06
sarobthinrichs: almost recovered17:07
thinrichssarob,skn: :)17:07
sarobthinrichs: Friday did me in17:07
skn_Who’s sarob?17:07
thinrichssarob: It was action packed for me too.17:07
sarobMe17:08
sarobSean roberts yahoo devant17:08
skn_Oh, ok, got it.17:08
thinrichsLet's quickly go over action items from last week.17:08
skn_Sorry Sean, didn’t know your IRC id17:08
sarobNp ;)17:08
thinrichsrajdeep was productive: he moved the datasources dir and wrote some unit tests.17:09
thinrichsHere are his unit tests from the data drivers.17:09
thinrichs https://review.openstack.org/#/c/94123/17:09
*** jcoufal has joined #openstack-meeting-317:09
thinrichsThe unit tests basically have some JSON objects and run the translator code on them to get the tables that Congress uses.17:10
thinrichsLet us know if any of you have comments, and we'll make sure rajdeep gets them.17:10
pballandI had 2 action items from the conference:17:10
pballand1 - email the list of participants who wanted to share contact info17:11
pballand2 - set up a blueprint process similar to nova-spec17:11
pballandon 1, I am going to send out the list after the meeting17:11
sarob#link  https://etherpad.openstack.org/p/juno-congress17:11
pballandsarob: thanks17:12
pballandfor 2: I wanted to propose placing the blueprints in the same tree as the source for now17:12
sarobYup17:12
skn_Thanks for the etherpad17:12
skn_Yes17:12
pballandconsiderations: we are a very small project, so managing multiple projets seems overkill17:12
sarobThe spec process nova and other are following17:12
pballandon the other side, confusing specs and src may be confusing17:13
pballandthoughts?17:13
sarobHey keep the specs as a separate repo17:13
sarobSpell chk is killing me17:13
sarob#link https://github.com/openstack/nova-specs17:13
pballandsarob: any particular reason (other than following what nova does)?17:14
sarobI guess it's to keep the rst and running of tox17:14
sarobAs simple as possible17:14
sarobI can ask Michael still why extra repo17:15
pballandsarob: so we would have stackforge/congress and stackforge/congress-spec ?17:15
sarobI assumed was to limit pollution17:15
sarobYup17:15
sarobMy understanding17:15
pballandI would appreciate that - I’d prefer to keep the specs together (in a specs subidr)17:15
sarobStart with subdir is easy to move later17:16
skn_I thought it would be a subdir17:16
skn_Yeah17:16
sarobIn case there's some higher reasoning17:16
pballandagreed, we can always break out to new repo later17:16
pballandwill create subdir17:16
pballand#action pballand to create subdir for specs in stackforge/congress17:16
pballandthat’s it for me17:17
sarobSubdir for Juno as well17:17
pballandsarob: yes17:17
sarobThe templates and format is straightforward17:17
sarobAre17:17
thinrichsWe should also put someone in charge of writing a first blueprint.17:17
* sarob hand up, at least to help17:18
skn_Didn’t we discuss that we’ll likely have multiple blueprints?17:18
thinrichsI can take that on unless someone else feels strongly.17:18
skn_I can help out Tim17:18
thinrichsskn_: We'll definitely have multiple blueprints.  But the first is often the hardest.17:18
sarobThe spec process should make few blueprints17:19
skn_And what do we want to focus on for the 1st one?17:19
thinrichsI'm going to need to read through that spec process.17:19
sarobReason nova started for quality verses quantity they have had17:19
thinrichsBefore I can figure out what the first blueprint should be.17:19
*** elmiko has left #openstack-meeting-317:19
sarobCan we discuss Juno user stories?17:20
sarobFrom the summit session17:20
thinrichsSo let's make sure all 3 of us peruse nova-spec to see what's going on and then we'll be in touch over email to work out blueprint details.17:20
skn_I thinks we should17:20
thinrichs#action thinrichs, sarob, skn_ will work on a nova-spec-like blueprint17:20
thinrichssarob, skn_: Definitely17:21
sarobUser stories brought up17:21
sarobTrusted pool17:21
*** devlaps has quit IRC17:21
sarobEvacuation17:21
sarobUpgrade17:21
*** devlaps has joined #openstack-meeting-317:22
sarobWorkload migration17:22
pballandproposal: let’s classify stories by openstack components they include17:22
sarobFine grained attributes17:22
sarobSmart17:23
skn_Agree with pballand17:23
sarobTrusted pool will prob get intel people involved17:23
sarobAnd evacuation17:23
sarobUpgrade will have broad interest17:24
*** nati_ueno has joined #openstack-meeting-317:24
sarobThose three are my favs17:24
pballandIf I recall correctly, we agreed at the summit that the stories go on the wiki17:24
skn_Let’s put them on the wiki first17:25
sarobRoger17:25
thinrichsThose 3 sound good to me too.17:25
pballandlets start with trusted pool:17:26
*** kenhui has joined #openstack-meeting-317:26
pballandit definitely involves nova, and a way to tak hypervisors17:26
pballands/tak/tag17:26
skn_for geotagging, etc17:26
sarobStart with that17:26
pballandquestion: how are hypervisors identified as trusted, and are any other components involved?17:26
thinrichsAre we hoping to have demos for each of the 3, or just tell the story around them?17:27
sarobFor Juno?17:27
thinrichssarob: yes, Juno.17:27
skn_TXT-based technology is Intel spoke about17:27
sarobskn_: yup17:27
skn_Something like vTPM too17:27
sarobskn_: when we have the spec up, I'll point the intel people17:28
pballandcan you help me understand how the TXT data gets to congress?17:28
sarobTo it17:28
pballand(from nova?)17:28
sarobpballand: filter17:28
sarobSep service monitoring txt17:28
skn_we should have one use case for a network security service (e.g. vuln scanning, DLP, etc)17:29
pballandI’d like each story to include at least two components17:29
pballand(data-source plugins in Congress-speak)17:29
sarobProb want API ext to front txt data17:29
sarobNova API ext17:29
*** eghobo has quit IRC17:29
skn_Why do we want API extn?17:30
sarobIDS could get symantec involved17:30
*** eghobo has joined #openstack-meeting-317:30
sarobMore17:30
skn_why not just data source17:30
pballandsarob: in that case, it sounds like the story just includes one component...17:30
thinrichsAny reason we can't integrate with the txt service directly?17:30
thinrichsskn_: agreed17:30
sarobthinrichs: could do that17:31
thinrichsGenerally speaking we don't want to be extending existing services to make our use case.17:31
sarobthinrichs: makes it specific to intel17:31
*** nati_ueno has quit IRC17:31
sarobGuess plugin could hold the flexibility17:31
thinrichsOr is the extension to the API already in existence?17:31
sarobDon't think so17:31
sarobHaven't checked17:31
* sarob blush17:32
skn_I think we’ll need to take a fresh look at what the updated TXT interfaces are17:32
thinrichssarob: part of what people seem to like is that we can use whatever services they have *without* changing services17:32
thinrichsAnd the system is designed to make that easy.17:32
skn_Yes17:32
skn_thinrichs: yes, that’s why data source is thw way to go17:32
sarobSo have the flexibility in the congress plugins rather the projects17:33
thinrichssarob: Yes.17:33
sarobOkey dokey17:33
pballandsarob: Could you add this to the wiki?17:33
*** natarajk has joined #openstack-meeting-317:34
pballandskn_: can you describe the story you had in mind for intrusion detection?17:34
sarobpballand: which?17:34
sarobTrusted pool17:35
skn_It would be like IDS service puts out data sources17:35
pballandyes17:35
*** natarajk has quit IRC17:35
skn_related to security issues17:35
sarob#action sarob add trusted pool user story to wiki17:35
skn_stuffs that are monitored and if there is something bad happening, we may need to take actions17:36
skn_intrusion might need to quarantine a VM, or a L2 segment, etc17:36
pballandskn_: this makes sense, but it would be great to nail down a specific integration, with nova or neutron, for example17:36
*** chuckC has joined #openstack-meeting-317:36
skn_Agreed, I can work on this use case17:36
sarobskn_: just nova network might be the best use case to start17:37
thinrichsGreat.  Someone dropped into pballand's office.17:37
skn_ok17:37
thinrichsOr use the Neutron network as well.  We already have a driver for that.17:37
sarobskn_: since very few running neutron17:37
thinrichsOr Nova Neutron.  Whatever works.17:38
skn_I think both nova and neutron17:38
thinrichsI don't know if we have the Nova network stuff integrated.  rajdeep knows but couldn't make it.17:38
skn_networks, I meant17:38
pballandsorry, back17:38
sarobJust thinking about real world use case17:38
sarobNeutron will not be as interesting at this moment17:39
sarobAfter Juno prob more17:39
pballandhow about a scheduler hint based on IDS?17:39
pballand(nova scheduler)17:39
skn_Like stop this VM?17:39
pballandactually, it’d be simpler if we can keep it as a monitoring case for now17:40
sarobGreylist17:40
skn_I think nova network should be simple17:40
skn_we can start with that17:40
skn_quarantining a host17:41
skn_I mean a VM17:41
thinrichsAre there Nova API calls we could execute that would be a reasonable response to IDS?17:41
sarobWhite and grey would be easier than black for Juno17:41
sarobFor IDS17:41
thinrichse.g. is there a quarantine API call, a black-list API call, etc.?17:41
pballandsarob: can you help me understand what you mean by gray-list?17:41
sarobThese VMs may have issues, ops should look at these17:42
pballand(all of these ideas make sense, but I don’t know how to map that in to existing constructs in Nova)17:42
sarobBlack would be automagically kill these17:42
sarobMore harder17:42
pballandMy trouble with graylist (as defined) is that it only involves the IDS (no cross-component integration)17:42
thinrichsSo both monitoring (for gray-list) and enforcement (black-list).  Right?17:43
skn_Yes, I want the IDS to integrate with another component17:43
sarobSimple start is good17:43
sarobNo?17:43
pballandI like the simpler “monitoring” use case, but would like to integrate it with another data source17:43
skn_like scheduler data source?17:43
skn_or the nova net?17:44
pballande.g. if IDS flags host AND nova says host <something> then flag17:44
*** jcoufal has quit IRC17:44
pballandmaybe nova-net says connected to intranet?17:44
sarobCould knock bad actor off lbaas17:44
sarobOr close ports17:44
sarobRather than kill vm17:45
pballandif we are doing enforcement, turning off the VM is easiest to impelment (as a first-delivered feature)17:45
sarobAgreed17:45
pballandor disconnect-network17:45
sarobBut to include another project17:45
sarobWas my comment17:46
*** clu_ has left #openstack-meeting-317:46
pballandmy thought is that we may want to keep enforcement out for the immediate term17:46
skn_pballand: Yes, for turning off VMs17:46
sarobAgreed17:46
thinrichsI think we should be able to get rudimentary actions/enforcement in place for Juno.17:46
skn_I think, thats what we can have as the first use case17:46
skn_easier to demo too17:46
pballandthinrichs: in that case, I have no objections to the story17:46
thinrichsMonitoring is a good first use case, for sure.  But I think actions/enforcement is reasonable in 6 months.17:47
thinrichsFor POC, of course.17:47
skn_thinrichs: agreed17:47
sarobSo IDS and nova services only to start for trusted pool user story17:47
pballandI was thinking this was a separate story17:48
skn_Yeah, me too17:48
skn_lets keep them separate17:48
sarobOkay17:48
skn_trusted pool and IDS17:48
sarobAh right17:48
pballand(trusted pool is nova + intel intetration, IDS is security + nova integration)17:48
sarobConflated17:48
pballandskn_: can you pick an enforcement action, and add the story to the wiki?17:48
skn_I can work on the IDS user story17:49
skn_I can do that pballand17:49
pballand#action skn_ to add IDS user story to wiki17:49
skn_The IDS story with monitoring and enforcement action17:49
sarob#action skn_ The IDS story with monitoring and enforcement action17:50
pballanddo we want to keep going with evacuation or upgrade use cases?17:50
pballand(10 minutes left)17:50
skn_Hey guys, I need to run, but I’ll work on the user story and likely share with you folks as I proceed17:50
pballandthanks skn_ !17:50
skn_Today I’m hosting a talk on OpenDaylight, so17:50
pballandI wanted to mention that we are trying to do the meeting every week now17:50
sarobExcellent17:50
skn_Yes, I’ll join every week17:50
skn_But only today I’ll run before time17:51
skn_sorry about that17:51
thinrichsNo problem.  Thanks for joining!17:51
skn_Bye pb, tim and sean17:51
*** skn_ has left #openstack-meeting-317:51
*** markmcclain has quit IRC17:51
thinrichsAnother action item we discussed at the summit was talking with Nova and Neutron folks.17:51
sarobBye17:52
*** markmcclain has joined #openstack-meeting-317:52
thinrichsskn_: bye17:52
thinrichsWe have contacts with Neutron, but who should we talk to in Nova?17:52
sarobI spoke with still17:52
sarobNova ptl17:52
sarobHe is ready when we are17:52
sarobI suggest getting both in the same meet to start17:53
sarobKyle, mark, micheal17:53
sarobBush17:53
sarobArrg17:53
sarobVish17:53
pballandsarob: Do you think we should have a separate meeting just for this, or do in IRC?17:54
*** kenhui has quit IRC17:54
sarobI'm good with irc17:54
pballand(not clear to me how to do this most efficiently)17:54
*** jtomasek has joined #openstack-meeting-317:54
sarobI think those guys will prefer irc too17:54
sarobDocumented17:55
thinrichsWould you suggest inviting them to this IRC or setting up a separate time?17:55
sarobHistory17:55
sarobVish is PDT17:55
sarobMark est17:55
sarobKyle cst17:55
sarobMicheal aus17:55
sarobI can ask Micheal17:56
sarobHe is the extreme17:56
thinrichsWhat are we trying to do in this meeting?  Tough to convey vision over IRC.17:56
thinrichsMaybe we should chat on the phone about what we're trying to do here and logistics?17:57
sarobI'd think discuss policy strategy17:57
sarobSure17:57
sarobDetails should be irc though17:57
thinrichsPolicy strategy across OS, yes?17:57
sarobAnd ODL17:57
sarobKyle can represent that side17:58
thinrichsAgreed--the phone conv just for higher-bandwidth clarification on stuff already discussed.17:58
sarobOnce we get going, bosh17:58
sarobJoshua can front that side17:58
sarobBut later17:59
sarobMe discuss time with still right?17:59
pballandsounds great18:00
pballandunfortunately we’re out of time this week18:00
sarob#action sarob get time for stategy call with nova ptl18:00
*** mrunge has joined #openstack-meeting-318:00
sarobRoger next week18:00
pballandthanks everyone for joining!18:00
sarob:)18:00
thinrichs#endmeeting18:00
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"18:00
openstackMeeting ended Tue May 20 18:00:51 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)18:00
openstackMinutes:        http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-05-20-17.04.html18:00
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-05-20-17.04.txt18:00
openstackLog:            http://eavesdrop.openstack.org/meetings/congressteammeeting/2014/congressteammeeting.2014-05-20-17.04.log.html18:00
*** sarob has quit IRC18:04
*** thinrichs has quit IRC18:04
*** jamie_h has quit IRC18:07
*** pballand has quit IRC18:07
*** coolsvap|afk has quit IRC18:16
*** rgbkrk has quit IRC18:16
*** coolsvap|afk has joined #openstack-meeting-318:19
*** mrunge has quit IRC18:27
*** rgbkrk has joined #openstack-meeting-318:28
*** kenhui has joined #openstack-meeting-318:29
*** otherwiseguy has quit IRC18:30
*** JuanManuelOlle has left #openstack-meeting-318:30
*** otherwiseguy has joined #openstack-meeting-318:31
*** kenhui1 has joined #openstack-meeting-318:31
*** nati_ueno has joined #openstack-meeting-318:32
*** kenhui has quit IRC18:33
*** sarob has joined #openstack-meeting-318:38
*** kenhui has joined #openstack-meeting-318:38
*** baojg has joined #openstack-meeting-318:38
*** rgbkrk has quit IRC18:41
*** kenhui1 has quit IRC18:41
*** kenhui2 has joined #openstack-meeting-318:41
*** sarob_ has joined #openstack-meeting-318:42
*** kenhui1 has joined #openstack-meeting-318:44
*** kenhui has quit IRC18:44
*** kenhui2 has quit IRC18:46
*** sarob_ has quit IRC18:48
*** sarob has quit IRC18:50
*** kenhui1 has quit IRC18:51
*** sarob has joined #openstack-meeting-318:51
*** briancurtin has joined #openstack-meeting-318:54
*** chuckC has quit IRC18:54
*** sarob has quit IRC18:55
*** dtroyer has joined #openstack-meeting-318:59
*** rgbkrk has joined #openstack-meeting-318:59
briancurtin#startmeeting python-openstacksdk19:00
openstackMeeting started Tue May 20 19:00:28 2014 UTC and is due to finish in 60 minutes.  The chair is briancurtin. Information about MeetBot at http://wiki.debian.org/MeetBot.19:00
openstackUseful Commands: #action #agreed #help #info #idea #link #topic #startvote.19:00
*** openstack changes topic to " (Meeting topic: python-openstacksdk)"19:00
openstackThe meeting name has been set to 'python_openstacksdk'19:00
briancurtinIf anyone's around for the sdk meeting, i threw together a small agenda, mostly just making sure to cover the outstanding reviews in teh way: https://wiki.openstack.org/wiki/Meetings/PythonOpenStackSDK#Agenda_for_2014-05-20_1900_UTC19:01
briancurtinand if you're here, roll call19:01
briancurtinBrian Curtin, Rackspace19:01
*** jamielennox has joined #openstack-meeting-319:02
*** Alex_Gaynor has joined #openstack-meeting-319:02
dtroyerantihistamine-soaked Dean Troyer, Nebula19:03
jamielennoxJamie Lennox, Red Hat19:05
dtroyerit's really quiet, right?  it isn't that I just can't see the text?  ok, good, I see jamie19:05
Alex_GaynorAlex Gaynor, Rackspace19:05
briancurtini'm guessing it'll be quiet as people probably catch up from last week, so maybe a quick meeting19:06
jamielennoxdtroyer: your message was the first thing i saw - i only assume we're doing the roll call from that19:06
dtroyeryes19:06
dtroyerI'm full of allergy drugs so a little slow today19:06
briancurtinmay as well get started19:07
Alex_GaynorThanks to everyone who came out to the session at the summit; it felt super productive and nice to sync with folks in person19:07
*** rockyg has joined #openstack-meeting-319:07
briancurtinnot really anything to discuss on this point, but i noticed coverage is broken, and we need a yet-to-be-released pbr to get it working19:07
Alex_GaynorWas that always broken?19:08
briancurtin(or you can change the name in setup.cfg to be "openstack" if you need)19:08
briancurtinAlex_Gaynor: i'm guessing it was, i only tried to run it last week or the week before19:08
Alex_Gaynork19:08
briancurtinpbr did some magic where if the name starts with python-, it strips that off and uses it, but our package is called openstack instead of openstacksdk, so it was testing nothing and collecting nothing19:08
briancurtinanyway19:08
*** Sukhdev has joined #openstack-meeting-319:08
briancurtinthere's an open review for example code which depends on the presentation layer, but it just needs to be rebased. seems probably uncontroversial: https://review.openstack.org/#/c/91448/19:09
briancurtinwhat it depends on, though, could use some love: https://review.openstack.org/#/c/90538/19:09
jamielennoxis there a decision on that either way? I don't know if we need presentation but what's the plan for right now?19:10
dtroyersigh…I don't care for the presentation layer, and if it would ever stop screwing around with Transport I could ignore it…19:11
jamielennoxi'd like to get passed this point - is the best way to +2 or -2 the presentation?19:12
dtroyerI just renewed my −1, but if that still doesn't get the point across I'm willing to be forceful about it19:12
Alex_GaynorI have very little opinion about the presentation stuff; I'll hapilly defer to folks who feel they are blocked on it19:13
*** rgbkrk has quit IRC19:14
jamielennoxok,  given that from dtroyer i'm going to ignore it for now and if it ever passes it can be hacked in19:14
*** terrylhowe has joined #openstack-meeting-319:14
Alex_GaynorSounsd good :-)19:14
*** jtomasek has quit IRC19:14
*** baojg has quit IRC19:15
briancurtinwith that being said, moving onto the auth change https://review.openstack.org/#/c/91889/19:15
briancurtinterry isn't here, but i know he had more work to do there, so i dont believe it's review ready19:15
dtroyerthat is also my understanding19:15
terrylhoweI have another patch on that, I'm almost ready to update19:15
briancurtinhe made a pass to address some of the early concerns, but still a TODO19:15
briancurtinoh, there he is - cool19:15
terrylhowesorry I'm late19:15
briancurtinno prob19:15
briancurtinand now that he's here, terrylhowe: not sure if you saw, but we just talked about the presentation layer change. it seems like it's probably going to sit for now19:17
*** otherwiseguy has quit IRC19:17
terrylhoweI'll look at the logs I guess19:17
terrylhoweThe biggest advantage of it is it cleaned up the resource class19:19
briancurtinquick summary - dean doesn't want it to muck with Transport, jamie wants to move on +2/-2 either way, alex deferred, i'm more with alex/jamie19:19
briancurtin(my +2 was that i'm somewhat fine with the change, strong on moving forward)19:20
*** rgbkrk has joined #openstack-meeting-319:20
briancurtinso i guess other than that, and whenever the updated auth change comes in - anything else at the moment to discuss?19:23
terrylhoweI'm a little confused on Dean's comment on JSON support being removed from transport since it is in there still19:24
terrylhoweNot sure if he realized I uploaded a new patch19:24
*** rgbkrk has quit IRC19:25
briancurtindtroyer^19:26
dtroyermoving it from Transport to PResentation now adds another requirement/dependency for Transport that I don't see any gain for.19:27
terrylhoweHow about I just put the decode code into transport as well?19:27
dtroyerI prefer to balance the JSON encoding/decoding in Trnasport as half of it is already in Requests19:27
terrylhoweFine, I just don't like it split over transport and resource19:28
*** glenc- has quit IRC19:29
dtroyerI don't see the split.  Right now Transport does both JSON encoding and decoding.19:29
dtroyerwhat am I missing?19:29
terrylhoweeverything the resource class does19:29
terrylhowehttps://review.openstack.org/#/c/90538/6/openstack/resource.py19:30
*** glenc- has joined #openstack-meeting-319:30
dtroyerthere is certainly noting to prevent there being another encoding/decoding layer higher up in the stack…the actual duplication would be small if they both use the same lib.   But I need it for things that are not resource-based.19:32
terrylhoweright, I moved the json encoding and decoding in transport19:33
dtroyerhow about this: don't change transport.py and I'll be able to let the rest go.19:33
dtroyerConceptually, something called Presentation should not be a dependency of something called Transport.  It's upside down19:34
*** rgbkrk has joined #openstack-meeting-319:35
*** jtomasek has joined #openstack-meeting-319:35
terrylhoweokay19:36
*** sarob has joined #openstack-meeting-319:37
*** glenc- has quit IRC19:37
*** glenc- has joined #openstack-meeting-319:40
briancurtinquestion: was looking at Resource.list and potentially making it a generator rather than list/marker (jamie's comment) - however, is there any general purpose way to do that? for example, swift's marker is a string container name, but i've seen others that are IDs19:41
briancurtiner, limit/marker, not list/marker19:41
terrylhowecontainer name is pretty much an id19:42
jamielennoxso i don't even remember what's currently in resource - if you want to switch it out then do it19:42
jamielennoxi had thought previously as to whether we could almost cache on a list call19:43
jamielennoxso return an object that was a generator that stored everything and could essentially be scrolled through19:43
briancurtinyep, i'll look further into that (i love generators, so the comment stuck out)19:43
terrylhowesounds good to me19:44
briancurtinanything else to cover with these last 15 minutes?19:44
jamielennoxthere has been some discussion on the server sides about u sing next/previous in the response for how to access more data so a generator makes sense there19:45
briancurtinjamielennox: that probably does make sense there, then i wouldn't have to worry about a marker at all, just give a limit, keep going with next, stop when there isn't one19:46
*** sarob has quit IRC19:47
*** sarob has joined #openstack-meeting-319:47
*** bauzas has quit IRC19:49
*** bauzas1 has joined #openstack-meeting-319:49
*** krotscheck has quit IRC19:49
*** krotscheck has joined #openstack-meeting-319:50
briancurtini take it that's probably the end. anything else in these last 10 min?19:50
*** sarob_ has joined #openstack-meeting-319:51
terrylhowenope19:51
briancurtin#endmeeting19:52
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings"19:52
openstackMeeting ended Tue May 20 19:52:20 2014 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)19:52
openstackMinutes:        http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-20-19.00.html19:52
openstackMinutes (text): http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-20-19.00.txt19:52
openstackLog:            http://eavesdrop.openstack.org/meetings/python_openstacksdk/2014/python_openstacksdk.2014-05-20-19.00.log.html19:52
briancurtinthanks all19:52
*** dtroyer has left #openstack-meeting-319:54
*** terrylhowe has left #openstack-meeting-319:54
jamielennoxthanks19:54
*** baojg has joined #openstack-meeting-319:55
*** jeblair has quit IRC19:55
*** sarob has quit IRC19:55
*** Alex_Gaynor has left #openstack-meeting-319:58
*** baojg has quit IRC20:00
*** jtomasek has quit IRC20:08
*** rgbkrk_ has joined #openstack-meeting-320:09
*** rgbkrk has quit IRC20:09
*** sarob_ has quit IRC20:15
*** baojg has joined #openstack-meeting-320:16
*** otherwiseguy has joined #openstack-meeting-320:18
*** jaypipes has quit IRC20:19
*** jaypipes has joined #openstack-meeting-320:20
*** julim has quit IRC20:25
*** sarob has joined #openstack-meeting-320:28
*** rgbkrk_ has quit IRC20:38
*** baojg has quit IRC20:42
*** lblanchard has quit IRC20:45
*** shakamunyi has joined #openstack-meeting-320:46
*** rgbkrk has joined #openstack-meeting-320:55
*** chuckC has joined #openstack-meeting-321:02
*** markmcclain has quit IRC21:07
*** Sukhdev has quit IRC21:08
*** sarob has quit IRC21:10
*** sarob has joined #openstack-meeting-321:11
*** dkorn has quit IRC21:12
*** sarob has quit IRC21:15
*** mwagner_lap has quit IRC21:19
*** peristeri has quit IRC21:23
*** lcheng_ has joined #openstack-meeting-321:35
*** mfer has quit IRC21:36
*** TravT has quit IRC21:37
*** Sukhdev has joined #openstack-meeting-321:38
*** nati_ueno has quit IRC21:46
*** briancurtin has left #openstack-meeting-321:51
*** nati_ueno has joined #openstack-meeting-321:56
*** ttrifonov_zZzz is now known as ttrifonov22:02
*** rockyg has quit IRC22:10
*** briancurtin has joined #openstack-meeting-322:11
*** sarob has joined #openstack-meeting-322:13
*** ttrifonov is now known as ttrifonov_zZzz22:19
*** ttrifonov_zZzz is now known as ttrifonov22:20
*** mwagner_lap has joined #openstack-meeting-322:26
*** sarob has quit IRC22:28
*** lcheng_ has quit IRC22:33
*** kenhui has joined #openstack-meeting-322:37
*** yamahata has joined #openstack-meeting-322:40
*** david-lyle has quit IRC22:43
*** rgbkrk has quit IRC22:43
*** pballand has joined #openstack-meeting-322:43
*** banix has quit IRC22:46
*** kenhui has quit IRC22:46
*** otherwiseguy has quit IRC22:49
*** sarob has joined #openstack-meeting-322:51
*** rgbkrk has joined #openstack-meeting-322:54
*** jaypipes has quit IRC22:54
*** nati_ueno has quit IRC22:54
*** sarob has quit IRC22:56
*** igordcard has quit IRC22:59
*** s1rp has left #openstack-meeting-323:04
*** rgbkrk has quit IRC23:07
*** MaxV_ has joined #openstack-meeting-323:09
*** MaxV_ has quit IRC23:12
*** eghobo has quit IRC23:12
*** nati_ueno has joined #openstack-meeting-323:14
*** sarob has joined #openstack-meeting-323:15
*** pballand has quit IRC23:17
*** pballand has joined #openstack-meeting-323:20
*** eghobo has joined #openstack-meeting-323:22
*** kenhui has joined #openstack-meeting-323:30
*** pballand has quit IRC23:31
*** MarkAtwood has quit IRC23:33
*** kenhui has quit IRC23:35
*** kenhui has joined #openstack-meeting-323:35
*** eguz has joined #openstack-meeting-323:35
*** eguz has quit IRC23:37
*** eguz has joined #openstack-meeting-323:37
*** Sukhdev has quit IRC23:38
*** eghobo has quit IRC23:39
*** yamahata has quit IRC23:43
*** kenhui has quit IRC23:49
*** nati_ueno has quit IRC23:50
*** chuckC has quit IRC23:50
*** nati_ueno has joined #openstack-meeting-323:51

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