*** dviroel has quit IRC | 00:10 | |
*** k_mouza has quit IRC | 00:46 | |
*** slaweq_ has joined #openstack-meeting-4 | 01:11 | |
*** Liang__ has joined #openstack-meeting-4 | 01:12 | |
*** michael-beaver has quit IRC | 01:13 | |
*** slaweq_ has quit IRC | 01:16 | |
*** dwalt has quit IRC | 01:27 | |
*** vesper has joined #openstack-meeting-4 | 01:38 | |
*** vesper11 has quit IRC | 01:39 | |
*** igordc has joined #openstack-meeting-4 | 01:52 | |
*** Liang__ has quit IRC | 02:04 | |
*** vishalmanchanda has joined #openstack-meeting-4 | 02:10 | |
*** roman_g has quit IRC | 02:33 | |
*** k_mouza has joined #openstack-meeting-4 | 02:46 | |
*** senrique__ has quit IRC | 02:46 | |
*** enriquetaso has joined #openstack-meeting-4 | 02:47 | |
*** k_mouza has quit IRC | 02:51 | |
*** enriquetaso has quit IRC | 02:52 | |
*** slaweq_ has joined #openstack-meeting-4 | 03:11 | |
*** slaweq_ has quit IRC | 03:16 | |
*** links has joined #openstack-meeting-4 | 04:43 | |
*** bnemec has joined #openstack-meeting-4 | 04:53 | |
*** hongbin has joined #openstack-meeting-4 | 04:55 | |
*** igordc has quit IRC | 04:59 | |
*** slaweq_ has joined #openstack-meeting-4 | 05:11 | |
*** slaweq_ has quit IRC | 05:15 | |
*** hongbin has quit IRC | 05:28 | |
*** evrardjp has quit IRC | 05:33 | |
*** evrardjp has joined #openstack-meeting-4 | 05:34 | |
*** Liang__ has joined #openstack-meeting-4 | 06:05 | |
*** Liang__ has quit IRC | 06:16 | |
*** roman_g has joined #openstack-meeting-4 | 07:00 | |
*** slaweq_ has joined #openstack-meeting-4 | 07:11 | |
*** slaweq_ has quit IRC | 07:16 | |
*** slaweq_ has joined #openstack-meeting-4 | 08:00 | |
*** slaweq__ has joined #openstack-meeting-4 | 08:09 | |
*** slaweq_ has quit IRC | 08:10 | |
*** slaweq has joined #openstack-meeting-4 | 08:14 | |
*** k_mouza has joined #openstack-meeting-4 | 08:15 | |
*** slaweq__ has quit IRC | 08:16 | |
*** k_mouza has quit IRC | 08:20 | |
*** ralonsoh has joined #openstack-meeting-4 | 08:42 | |
*** slaweq_ has joined #openstack-meeting-4 | 08:48 | |
*** slaweq has quit IRC | 08:48 | |
*** slaweq__ has joined #openstack-meeting-4 | 09:06 | |
*** slaweq_ has quit IRC | 09:07 | |
*** k_mouza has joined #openstack-meeting-4 | 09:19 | |
*** slaweq__ is now known as slaweq | 09:25 | |
*** gcheresh has joined #openstack-meeting-4 | 09:27 | |
*** gcheresh_ has joined #openstack-meeting-4 | 09:38 | |
*** gcheresh has quit IRC | 09:39 | |
*** k_mouza has quit IRC | 09:59 | |
*** k_mouza has joined #openstack-meeting-4 | 09:59 | |
*** k_mouza_ has joined #openstack-meeting-4 | 10:00 | |
*** k_mouza has quit IRC | 10:04 | |
*** gcheresh_ has quit IRC | 10:35 | |
*** slaweq_ has joined #openstack-meeting-4 | 10:40 | |
*** gcheresh_ has joined #openstack-meeting-4 | 10:41 | |
*** slaweq has quit IRC | 10:42 | |
*** e0ne has joined #openstack-meeting-4 | 10:57 | |
*** slaweq__ has joined #openstack-meeting-4 | 11:01 | |
*** slaweq_ has quit IRC | 11:03 | |
*** lkoranda has joined #openstack-meeting-4 | 11:05 | |
*** bobmel has joined #openstack-meeting-4 | 11:17 | |
*** psachin has joined #openstack-meeting-4 | 11:30 | |
*** dviroel has joined #openstack-meeting-4 | 11:32 | |
*** pcaruana has quit IRC | 11:37 | |
*** e0ne has quit IRC | 11:42 | |
*** pcaruana has joined #openstack-meeting-4 | 11:50 | |
*** Liang__ has joined #openstack-meeting-4 | 12:19 | |
*** slaweq__ has quit IRC | 12:19 | |
*** slaweq__ has joined #openstack-meeting-4 | 12:23 | |
*** e0ne has joined #openstack-meeting-4 | 12:27 | |
*** e0ne has quit IRC | 12:53 | |
*** enriquetaso has joined #openstack-meeting-4 | 13:02 | |
*** e0ne has joined #openstack-meeting-4 | 13:05 | |
*** slaweq has joined #openstack-meeting-4 | 13:11 | |
*** slaweq__ has quit IRC | 13:13 | |
*** smcginnis|FOSDEM is now known as smcginnis | 13:19 | |
*** lpetrut has joined #openstack-meeting-4 | 13:24 | |
*** anastzhyr has joined #openstack-meeting-4 | 13:42 | |
*** tosky has joined #openstack-meeting-4 | 13:45 | |
*** whoami-rajat__ has joined #openstack-meeting-4 | 13:50 | |
*** liuyulong has joined #openstack-meeting-4 | 13:58 | |
*** lkoranda has quit IRC | 13:58 | |
*** bobmel has quit IRC | 13:58 | |
*** Liang__ is now known as LiangFang | 14:00 | |
whoami-rajat | ping jungleboyj rosmaita smcginnis tosky whoami-rajat m5z e0ne geguileo eharney walshh_ jbernard | 14:00 |
---|---|---|
whoami-rajat | #startmeeting cinder | 14:00 |
openstack | Meeting started Wed Feb 5 14:00:38 2020 UTC and is due to finish in 60 minutes. The chair is whoami-rajat. Information about MeetBot at http://wiki.debian.org/MeetBot. | 14:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 14:00 |
*** openstack changes topic to " (Meeting topic: cinder)" | 14:00 | |
openstack | The meeting name has been set to 'cinder' | 14:00 |
m5z | hi :) | 14:00 |
e0ne | hi | 14:00 |
whoami-rajat | #topic roll call | 14:00 |
*** openstack changes topic to "roll call (Meeting topic: cinder)" | 14:00 | |
enriquetaso | hi | 14:00 |
LiangFang | hi | 14:01 |
smcginnis | o/ | 14:01 |
*** eharney has joined #openstack-meeting-4 | 14:01 | |
eharney | hi | 14:01 |
whoami-rajat | #link https://etherpad.openstack.org/p/cinder-ussuri-meetings | 14:01 |
jungleboyj | o/ | 14:02 |
anastzhyr | Hi | 14:03 |
tosky | hi | 14:03 |
whoami-rajat | will wait for 2 more minutes before the announcements | 14:03 |
whoami-rajat | i think we can move to announcements now | 14:04 |
whoami-rajat | #topic Announcements | 14:04 |
*** openstack changes topic to "Announcements (Meeting topic: cinder)" | 14:04 | |
whoami-rajat | Ussuri milestone-2 is next week Feb 10 - Feb 14 (specifically 13 February 2020 (23:59 UTC)) | 14:04 |
whoami-rajat | that implies deadline for a new driver or a target driver | 14:04 |
whoami-rajat | requirements for a driver to be complete is working code and unit tests merged into cinder repo + working third party CI | 14:04 |
whoami-rajat | additional info in the mail | 14:04 |
whoami-rajat | #link http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012055.html | 14:04 |
whoami-rajat | any additional comments regarding this are welcome :) | 14:05 |
whoami-rajat | okay, so moving on to the next announcement | 14:06 |
whoami-rajat | code review policy for py2->py3 transition | 14:06 |
whoami-rajat | #link https://review.opendev.org/#/c/703709/ | 14:07 |
whoami-rajat | The main concern here is regarding backports | 14:07 |
whoami-rajat | we need to have certain guidelines for code to work when backported to stable branches | 14:07 |
whoami-rajat | this includes guidelines for features as well as bug fixes | 14:07 |
whoami-rajat | let me know if i'm going too fast but seems like no discussion is needed around this too | 14:09 |
whoami-rajat | so moving on | 14:10 |
*** lkoranda has joined #openstack-meeting-4 | 14:11 | |
*** rosmaita has joined #openstack-meeting-4 | 14:11 | |
whoami-rajat | update to driver removal policy | 14:11 |
whoami-rajat | #link https://review.opendev.org/#/c/704906/ | 14:11 |
whoami-rajat | with some discussions around this topic from past few weeks, we've finally decided to keep | 14:11 |
whoami-rajat | unsupported drivers in-tree until they cause major disturbance in cinder gate then they will be removed (given they have completed the deprecation cycle) | 14:11 |
whoami-rajat | additional info is again mentioned in the patch | 14:11 |
jungleboyj | Think you are doing fine whoami-rajat :-) | 14:11 |
rosmaita | o/ | 14:11 |
whoami-rajat | jungleboyj, thanks :D | 14:11 |
whoami-rajat | rosmaita, yay! | 14:12 |
rosmaita | thanks for getting the meeting going | 14:12 |
jungleboyj | Looks like I need to look at the driver removal patch again. | 14:12 |
jungleboyj | Will do that. | 14:12 |
whoami-rajat | so we've some review requests for the final announcement | 14:12 |
whoami-rajat | rosmaita, np | 14:12 |
whoami-rajat | https://review.opendev.org/#/c/704425/ - fix a unit test blocking sqlalchemy upgrade to 1.3.13 | 14:12 |
whoami-rajat | you want to elaborate on this rosmaita ? | 14:13 |
rosmaita | no, just that we need to merge it soon, it's blocking all of openstack from upgrading sqlalchemy | 14:13 |
rosmaita | looks like the problem was with one of our tests, not a real problem | 14:13 |
whoami-rajat | ok | 14:14 |
whoami-rajat | so one more review request | 14:14 |
whoami-rajat | https://review.opendev.org/#/c/705362/ - open specs repo for Victoria | 14:14 |
whoami-rajat | but this is approved | 14:14 |
whoami-rajat | so nevermind | 14:15 |
rosmaita | ok, thanks | 14:15 |
rosmaita | just read through the scrollback, you covered everything i wanted to say | 14:15 |
rosmaita | thanks whoami-rajat | 14:15 |
whoami-rajat | so i think with the last announcement i can hand over to rosmaita | 14:15 |
whoami-rajat | Spec freeze exception granted to "support volume-local-cache" | 14:15 |
rajinir | o/ | 14:15 |
whoami-rajat | rosmaita, i was afraid if you had more elaborate notes and i may have missed some things, but glad to hear that, feww | 14:16 |
rosmaita | some questions came up on the spec last week before the freeze deadline | 14:16 |
rosmaita | so i wanted to carry it over before we said yes or no | 14:16 |
rosmaita | which brings us to our next topic | 14:17 |
rosmaita | #topic volume-local-cache spec | 14:17 |
*** pcaruana has quit IRC | 14:17 | |
*** knomura has joined #openstack-meeting-4 | 14:17 | |
LiangFang | one Nova engineer thinks they are moving volumes to mount directly by qemu | 14:17 |
LiangFang | not mount to host os first | 14:18 |
rosmaita | #link http://lists.openstack.org/pipermail/openstack-discuss/2020-January/012279.html | 14:18 |
rosmaita | also, here's a link to the latest draft of the spec: | 14:18 |
rosmaita | #link https://review.opendev.org/#/c/684556/ | 14:18 |
rosmaita | so the issue is, if nova is planning to mount volumes directly by qemu, then that would completely bypass the cache in this spec, is that correct? | 14:19 |
eharney | as i understand it, consuming cinder volumes via qemu instead of attaching them to the host is still blocked by the fact that qemu doesn't support multipath | 14:19 |
eharney | but it has been a goal for a bit | 14:19 |
LiangFang | rosmaita: yes | 14:19 |
smcginnis | I know they've been pushing for that for a long time, but last I looked, there were multiple reasons NOT to go with direct QEMU mounting of volumes. | 14:20 |
rosmaita | so it may not be as much of a done deal as is implied in that email? | 14:21 |
eharney | i think everyone agrees it would be a better way to do things | 14:21 |
rosmaita | multipath support is kind of a big deal, though | 14:21 |
eharney | right | 14:21 |
LiangFang | currently only rbd and sheepdog is mounting directly by qemu | 14:22 |
rosmaita | and sheepdog is no more | 14:22 |
smcginnis | I don't think it supported FC either. | 14:22 |
smcginnis | "The storage protocol that won't die" | 14:23 |
rosmaita | ok, so my reason in putting this on the agenda is to ask: is this a reason to hold up Liang's spec? | 14:23 |
eharney | either way, i noted a handful of concerns on this spec that are generally around the theme that there are lot of things you have to account for when getting into the data path of cinder volumes that don't seem to be sorted out thoroughly yet | 14:23 |
eharney | the encryption layering one being one of the biggest issues in my mind | 14:23 |
rosmaita | yes, it is definitely important to get that right | 14:24 |
rosmaita | eharney: did you see the update yet? does it address your concerns? | 14:24 |
eharney | i haven't looked at it yet | 14:24 |
rosmaita | ok | 14:24 |
*** psachin has quit IRC | 14:25 | |
rosmaita | i think other than encryption, the major concern is migration? | 14:25 |
eharney | yes, it's not been clear to me whether migration actually works, one of the nova folks pointed out that you have to have a mechanism to flush the cache during migration | 14:26 |
smcginnis | Seems important. | 14:26 |
eharney | otherwise you leave a bunch of data in the cache on the source host during migration that doesn't show up on the destination host | 14:27 |
eharney | which would not work at all | 14:27 |
rosmaita | which would be a bummer indeed | 14:27 |
LiangFang | write-back mode is working like this | 14:28 |
rosmaita | my feeling is that these major issues need to be understood at the spec stage, we probably shouldn't try to work them out in the implementation phase | 14:28 |
LiangFang | write-through mode will not :) | 14:28 |
rosmaita | so the "safe modes" should migrate OK? | 14:29 |
LiangFang | yes | 14:29 |
LiangFang | not dirty data in cache in write-through mode | 14:29 |
rosmaita | ok, and the current proposal is that we would only support "safe modes" | 14:29 |
eharney | the same issue crops up with consistency groups | 14:29 |
whoami-rajat | flushing shouldn't be necessary in write-through right? | 14:29 |
LiangFang | yes | 14:29 |
LiangFang | no need flush for write-through | 14:30 |
eharney | and snapshots "work" but may surprise users | 14:30 |
eharney | (all for the same reason) | 14:30 |
rosmaita | just to make sure i understand | 14:31 |
LiangFang | in write-through/safe mode, every write io will go to backend | 14:31 |
rosmaita | in the "safe modes", snapshots should be OK, right? | 14:31 |
eharney | yes all of this would work normally in write-through mode | 14:31 |
LiangFang | in safe modes, cache just like read only cache | 14:31 |
rosmaita | ok, just wanted to be clear | 14:31 |
rosmaita | so the problem is that to get the best benefit from the cache, all sorts of stuff could break | 14:32 |
rosmaita | migrations, snapshots | 14:32 |
rosmaita | is restricting to safe caching modes too big a restriction? | 14:32 |
rosmaita | what i mean is | 14:32 |
eharney | migrations would break, snapshots would succeed but have older data in them than you expected | 14:32 |
rosmaita | right, and across a group, wouldn't necessarily be consistent any more | 14:33 |
eharney | right | 14:33 |
rosmaita | good thing we just call them "groups" now :) | 14:33 |
eharney | well that's a separate thing | 14:33 |
rosmaita | yeah, that was a bad joke | 14:34 |
jungleboyj | This is sounding concerning. | 14:34 |
LiangFang | eharney: I still don't understand why older data than expected | 14:34 |
LiangFang | no newer data in cache in any moment | 14:34 |
eharney | because snapshots are performed on the backend, and a snapshot will be created for the volume with the data that was written there but data in the cache (which the user of the instance thinks has been written there) won't be in the snap (when in write-back mode) | 14:35 |
*** hemna has joined #openstack-meeting-4 | 14:36 | |
LiangFang | write-back mode yes, safe-mode will not | 14:36 |
eharney | right | 14:36 |
LiangFang | :) | 14:36 |
whoami-rajat | also i couldn't find any usecase regarding the write-back cache in the spec | 14:36 |
LiangFang | will not support write-back mode | 14:36 |
rosmaita | i asked LiangFang to remove it because we aren't supporting it any more | 14:36 |
LiangFang | ceph support client side read only cache | 14:37 |
*** bobmel has joined #openstack-meeting-4 | 14:37 | |
whoami-rajat | oh ok | 14:37 |
LiangFang | but it is using DRAM as cache | 14:37 |
LiangFang | volume local cache is just something like read-only cache | 14:37 |
LiangFang | but using persistent memory or fast ssd | 14:38 |
LiangFang | I know ceph read only cache is a new feature just developed | 14:38 |
rosmaita | here's a question: could we support the "unsafe" modes later on by, for example, making sure cache is flushed before a snapshot, or would that start to get too complicated? what i mean is, is there a theoretical reason other than complexity for why this couldn't be done reliably? | 14:39 |
eharney | it definitely could be done, we just need hooks to request cache flushes in the right places | 14:39 |
rosmaita | so it could be possible to implement this in phases | 14:40 |
jungleboyj | Is there a reason for the urgency here if there is a safer way to get this done? | 14:40 |
rosmaita | becasuse i think operators and users are going to want to use the unsafe caching modes | 14:40 |
eharney | would be interesting to know how widely used writeback caching is in Nova now | 14:40 |
rosmaita | jungleboyj: mainly that we have to coordinate with nova to get it to actually work | 14:41 |
jungleboyj | Ok. Then we need to make sure to implement it so that they don't shoot themselves in the foot in the process. :-) | 14:41 |
rosmaita | so nova doesn't want to approve changes unless we have approved it on our side | 14:41 |
smcginnis | Sounds like we may need some cross-team meetings to work through all the intracasies like we had to do with multiattach. | 14:41 |
rosmaita | smcginnis: ++ | 14:42 |
jungleboyj | smcginnis: ++ | 14:42 |
LiangFang | ok | 14:42 |
LiangFang | ++ | 14:42 |
rosmaita | ok, i think this is worth pursuing during this cycle? anyone disagree? | 14:43 |
eharney | seems worthwhile | 14:44 |
rosmaita | what i mean is, having the discussions, not waiting for the PTG | 14:44 |
jungleboyj | Seems worthwhile if we can do it in a safe manner. | 14:44 |
eharney | i would be much happier if we also had another reference implementation like dm-cache to test along with it, but that's probably dreaming too much :) | 14:44 |
rosmaita | ok, i think the next move is to have a bluejeans conference | 14:44 |
LiangFang | eharney: dan from Nova mentioned dm-crypt not working | 14:45 |
rosmaita | could i get names of people who definitely would want to attend and their time zones | 14:45 |
rosmaita | will help me offer some choices on a poll | 14:45 |
rosmaita | for meeting day/time | 14:46 |
eharney | i can (EST) | 14:46 |
LiangFang | eharney: main issue is: the backend volume should not containing any metadata | 14:46 |
whoami-rajat | IST +05:30 UTC | 14:46 |
rosmaita | EST | 14:46 |
LiangFang | UTC+8 | 14:46 |
eharney | i think encrypted volumes already don't follow that, but we can figure it out later | 14:47 |
LiangFang | ok | 14:48 |
rosmaita | ok, i'll look on the nova spec and see who's commented | 14:48 |
LiangFang | thanks | 14:48 |
rosmaita | i'll get a poll out later today or early tomorrow | 14:48 |
rosmaita | #topic resource_filters response is inaccurate | 14:49 |
rosmaita | this was implemented before i started working on cinder | 14:49 |
rosmaita | context for this is whoami-rajat's patch fixing a problem in the volume-transfers API | 14:50 |
rosmaita | what i noticed is this | 14:50 |
*** links has quit IRC | 14:50 | |
rosmaita | #link https://docs.openstack.org/api-ref/block-storage/v3/?expanded=list-resource-filters-detail#resource-filters | 14:50 |
whoami-rajat | #link https://review.opendev.org/#/c/703658/ | 14:50 |
rosmaita | that's what our resource_filters response gives you | 14:50 |
rosmaita | and actually, what most people would see is really this: | 14:51 |
rosmaita | #link https://opendev.org/openstack/cinder/src/branch/master/etc/cinder/resource_filters.json | 14:51 |
rosmaita | because it was designed to be operator-configurable | 14:51 |
rosmaita | according to the api-ref, the value of the "resource" element is supposed to be "Resource which the filters will be applied to" | 14:51 |
rosmaita | the problem is that all resources mentioned in our API URIs are plural ("volumes", "snapshots", "backups") whereas all the resources in the file are singular ("volume", "snapshot", "backup") | 14:52 |
rosmaita | in some ways, this is a minor point | 14:52 |
rosmaita | but i also noticed that the volume-transfers API doesn't implement the resource_filters framework that (most) of the other list-resource calls do | 14:52 |
rosmaita | so, we should get the volume_transfers into that resource_filters response | 14:53 |
rosmaita | which brings up the question: "volume-transfer" or "volume-transfers" | 14:53 |
rosmaita | (yes, it's a hyphen '-', not an underscore | 14:53 |
rosmaita | ) | 14:53 |
rosmaita | one issue is, how can we change the resource_filters response? | 14:54 |
rosmaita | but, my take is that since it was designed to be configurable, the response doesn't have to be microversioned | 14:54 |
rosmaita | that is, whether it's available or not can be microversioned (i think it may be) | 14:55 |
rosmaita | but we can correct the response without a new mv | 14:55 |
whoami-rajat | i feel we should remove the plural 's', that makes more sense, volume name vs volumes name | 14:55 |
rosmaita | (sorry, i kind of obsess over API issues) | 14:55 |
rosmaita | well, the URL paths are all plural | 14:56 |
hemna | I'm not sure what value we would get out of a change like that | 14:56 |
rosmaita | and the question is, what does the filter apply to? | 14:56 |
hemna | it's been that way forever | 14:56 |
hemna | for better or worse | 14:56 |
rosmaita | it's just kind of weird that we're giving a list of filters you can use, but there's no actual resource with that name | 14:57 |
rosmaita | but i can live with it if it doesn't bother anyone else | 14:57 |
eharney | i would agree it doesn't need to be microversioned, but tempest definitely disagreed with me the last time i went down a similar path | 14:57 |
eharney | it is odd | 14:57 |
hemna | wouldn't that change break a lot of clients expecting volumes vs volume ? | 14:57 |
eharney | wouldn't those clients already break if you just removed the config for volume now? | 14:58 |
rosmaita | so the change is to what shows up in the resource_filters response, not the API path | 14:58 |
rosmaita | i think programmatically, what you would want to do is match the resource in the URL to the resource listed in the response | 14:58 |
eharney | i don't think the API says it must contain any particular field like "volume" | 14:58 |
rosmaita | right now, you have to know to remove the 's' to find it | 14:58 |
hemna | right, but they would be expecting the key volumes in the response and if we changed it to volume, that would break their app/client/call/expectation | 14:58 |
smcginnis | 1 minute | 14:59 |
rosmaita | hemna: the other way around, but i get your point | 14:59 |
rosmaita | ok, we can continue this later, looks like some pro, some con | 14:59 |
rosmaita | will have to be worked out | 14:59 |
rosmaita | and i have prevented open discussion again | 15:00 |
whoami-rajat | Thanks rosmaita | 15:00 |
rosmaita | anyone with other issues, please move over to cinder channel | 15:00 |
rosmaita | whoami-rajat: i think you need to end the meeting | 15:00 |
whoami-rajat | oh ok | 15:00 |
whoami-rajat | #endmeeting | 15:00 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings/" | 15:00 | |
openstack | Meeting ended Wed Feb 5 15:00:49 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 15:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder/2020/cinder.2020-02-05-14.00.html | 15:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder/2020/cinder.2020-02-05-14.00.txt | 15:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/cinder/2020/cinder.2020-02-05-14.00.log.html | 15:00 |
*** lkoranda has quit IRC | 15:01 | |
*** tosky has left #openstack-meeting-4 | 15:01 | |
*** eharney has quit IRC | 15:13 | |
*** e0ne has quit IRC | 15:15 | |
*** dwalt has joined #openstack-meeting-4 | 15:16 | |
*** knomura has quit IRC | 15:20 | |
*** lpetrut has quit IRC | 15:28 | |
*** pcaruana has joined #openstack-meeting-4 | 15:49 | |
*** e0ne has joined #openstack-meeting-4 | 15:53 | |
*** gcheresh_ has quit IRC | 16:00 | |
*** bobmel has quit IRC | 16:04 | |
*** bobmel has joined #openstack-meeting-4 | 16:05 | |
*** rosmaita has left #openstack-meeting-4 | 16:07 | |
*** bobmel has quit IRC | 16:10 | |
*** e0ne has quit IRC | 16:17 | |
*** slaweq_ has joined #openstack-meeting-4 | 16:23 | |
*** slaweq has quit IRC | 16:25 | |
*** psachin has joined #openstack-meeting-4 | 16:38 | |
*** e0ne has joined #openstack-meeting-4 | 16:56 | |
*** psachin has quit IRC | 16:58 | |
*** e0ne has quit IRC | 17:05 | |
*** e0ne has joined #openstack-meeting-4 | 17:09 | |
*** evrardjp has quit IRC | 17:33 | |
*** evrardjp has joined #openstack-meeting-4 | 17:34 | |
*** igordc has joined #openstack-meeting-4 | 17:34 | |
*** k_mouza_ has quit IRC | 17:35 | |
*** anastzhyr has quit IRC | 17:42 | |
*** whoami-rajat__ has quit IRC | 17:52 | |
*** addyess has joined #openstack-meeting-4 | 18:00 | |
*** johnsom has quit IRC | 18:03 | |
*** johnsom has joined #openstack-meeting-4 | 18:03 | |
*** lathiat has quit IRC | 18:22 | |
*** lathiat has joined #openstack-meeting-4 | 18:22 | |
*** e0ne has quit IRC | 18:27 | |
*** niedbalski has quit IRC | 18:32 | |
*** niedbalski has joined #openstack-meeting-4 | 18:33 | |
*** ralonsoh has quit IRC | 18:54 | |
*** jamespage has quit IRC | 18:56 | |
*** jamespage has joined #openstack-meeting-4 | 18:56 | |
*** gcheresh_ has joined #openstack-meeting-4 | 19:10 | |
*** gcheresh_ has quit IRC | 19:32 | |
*** anastzhyr has joined #openstack-meeting-4 | 19:35 | |
*** LiangFang has quit IRC | 19:36 | |
*** niedbalski has quit IRC | 19:37 | |
*** lathiat has quit IRC | 19:38 | |
*** jamespage has quit IRC | 19:39 | |
*** johnsom has quit IRC | 19:40 | |
*** bobmel has joined #openstack-meeting-4 | 19:45 | |
*** enriquetaso has quit IRC | 19:57 | |
*** e0ne has joined #openstack-meeting-4 | 20:36 | |
*** e0ne has quit IRC | 20:44 | |
*** slaweq_ has quit IRC | 20:44 | |
*** slaweq_ has joined #openstack-meeting-4 | 20:47 | |
*** slaweq_ has quit IRC | 21:15 | |
*** gcheresh_ has joined #openstack-meeting-4 | 21:24 | |
*** liuyulong has quit IRC | 21:41 | |
*** bobmel has quit IRC | 21:47 | |
*** gcheresh_ has quit IRC | 21:58 | |
*** k_mouza has joined #openstack-meeting-4 | 22:29 | |
*** k_mouza has quit IRC | 22:30 | |
*** anastzhyr has quit IRC | 22:32 | |
*** bobmel has joined #openstack-meeting-4 | 22:55 | |
*** lathiat has joined #openstack-meeting-4 | 23:00 | |
*** niedbalski has joined #openstack-meeting-4 | 23:00 | |
*** jamespage has joined #openstack-meeting-4 | 23:01 | |
*** johnsom has joined #openstack-meeting-4 | 23:02 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!