| *** yamahata has quit IRC | 01:46 | |
| *** iyamahat has quit IRC | 01:46 | |
| *** nhelgeson has quit IRC | 02:14 | |
| *** gouthamr has joined #openstack-meeting-cp | 02:20 | |
| *** lbragstad has joined #openstack-meeting-cp | 03:00 | |
| *** lbragstad has quit IRC | 03:21 | |
| *** coolsvap has joined #openstack-meeting-cp | 03:37 | |
| *** yamahata has joined #openstack-meeting-cp | 03:50 | |
| *** iyamahat has joined #openstack-meeting-cp | 04:00 | |
| *** gouthamr has quit IRC | 04:12 | |
| *** Rockyg has joined #openstack-meeting-cp | 04:46 | |
| *** markvoelker has quit IRC | 05:16 | |
| *** iyamahat has quit IRC | 05:45 | |
| *** Rockyg has quit IRC | 06:03 | |
| *** iyamahat has joined #openstack-meeting-cp | 06:19 | |
| *** rarcea has joined #openstack-meeting-cp | 06:29 | |
| *** markvoelker has joined #openstack-meeting-cp | 07:18 | |
| *** iyamahat has quit IRC | 07:23 | |
| *** markvoelker has quit IRC | 07:52 | |
| *** markvoelker has joined #openstack-meeting-cp | 08:48 | |
| *** MarkBaker has joined #openstack-meeting-cp | 09:08 | |
| *** edmondsw has joined #openstack-meeting-cp | 09:15 | |
| *** edmondsw has quit IRC | 09:20 | |
| *** MarkBaker has quit IRC | 09:20 | |
| *** markvoelker has quit IRC | 09:21 | |
| *** MarkBaker has joined #openstack-meeting-cp | 09:32 | |
| *** markvoelker has joined #openstack-meeting-cp | 10:19 | |
| *** markvoelker has quit IRC | 10:52 | |
| *** MarkBaker has quit IRC | 11:20 | |
| *** MarkBaker has joined #openstack-meeting-cp | 11:22 | |
| *** sdague has joined #openstack-meeting-cp | 11:38 | |
| *** MarkBaker has quit IRC | 11:49 | |
| *** markvoelker has joined #openstack-meeting-cp | 11:49 | |
| *** markvoelker has quit IRC | 11:54 | |
| *** markvoelker has joined #openstack-meeting-cp | 11:56 | |
| *** MarkBaker has joined #openstack-meeting-cp | 12:02 | |
| *** yamahata has quit IRC | 12:12 | |
| *** edmondsw has joined #openstack-meeting-cp | 12:13 | |
| *** MarkBaker has quit IRC | 12:27 | |
| *** xyang1 has joined #openstack-meeting-cp | 12:51 | |
| *** MarkBaker has joined #openstack-meeting-cp | 13:16 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:26 | |
| *** coolsvap has quit IRC | 13:39 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 14:38 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 14:39 | |
| *** felipemonteiro has quit IRC | 14:43 | |
| *** felipemonteiro_ has quit IRC | 14:59 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 14:59 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 15:11 | |
| *** felipemonteiro_ has quit IRC | 15:13 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 15:24 | |
| *** iyamahat has joined #openstack-meeting-cp | 15:24 | |
| *** felipemonteiro has quit IRC | 15:27 | |
| *** iyamahat has quit IRC | 15:28 | |
| *** felipemonteiro_ has quit IRC | 15:32 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 15:33 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 15:34 | |
| *** felipemonteiro_ has quit IRC | 15:37 | |
| *** iyamahat has joined #openstack-meeting-cp | 15:43 | |
| *** mriedem has joined #openstack-meeting-cp | 15:48 | |
| *** felipemonteiro has quit IRC | 15:49 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 15:49 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 15:53 | |
| *** felipemonteiro_ has quit IRC | 15:56 | |
| ildikov | #startmeeting cinder-nova-api-changes | 16:00 |
|---|---|---|
| openstack | Meeting started Thu Sep 21 16:00:24 2017 UTC and is due to finish in 60 minutes. The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 16:00 | |
| openstack | The meeting name has been set to 'cinder_nova_api_changes' | 16:00 |
| ildikov | johnthetubaguy jaypipes e0ne jgriffith hemna mriedem patrickeast smcginnis diablo_rojo xyang1 raj_singh lyarwood jungleboyj stvnoyes | 16:00 |
| jungleboyj | @! | 16:00 |
| _pewp_ | jungleboyj ＼(-_- ) | 16:00 |
| stvnoyes | o/ | 16:00 |
| *** MarkBaker has quit IRC | 16:01 | |
| ildikov | let's wait a tiny bit, I guess people are slower joining after having the PTG last week :) | 16:01 |
| mriedem | o/ | 16:02 |
| smcginnis | o/ | 16:03 |
| jgriffith | o/ | 16:03 |
| ildikov | ok, let's start | 16:03 |
| jgriffith | pheww | 16:03 |
| ildikov | jgriffith: just in time :) | 16:03 |
| ildikov | so we agreed on a few things last week and are about to move forward | 16:03 |
| jungleboyj | jgriffith: Slides into home. | 16:03 |
| ildikov | I saw recent comments on the live_migration patch and test | 16:03 |
| ildikov | mriedem: there's only one service version check in the new attach patch that I'm aware of | 16:04 |
| stvnoyes | looks like i have a grenade issue there. | 16:04 |
| ildikov | mriedem: which is not supposed to make the Grenade test fail | 16:04 |
| mriedem | it could be a problem in the test, i'm not sure | 16:05 |
| stvnoyes | i'll look into to see why it's failing | 16:05 |
| mriedem | but yes, we shouldn't be using any new style attachments if any computes are not running the latest code | 16:05 |
| mriedem | so i'm not sure why grenade would have issues | 16:05 |
| stvnoyes | i am guessing it's a test issue | 16:05 |
| mriedem | maybe, i haven't grok'ed your tempest change | 16:05 |
| *** yamahata has joined #openstack-meeting-cp | 16:07 | |
| stvnoyes | while we're on the topic of tempest tests... | 16:07 |
| ildikov | the attach patch should be up to date with the compute service version | 16:07 |
| ildikov | but let me know if something went wrong there | 16:07 |
| stvnoyes | I've been working on debugging the migrate iscsi test. In my local env I am seeing very occasional detach timeouts - DeviceDetachFailed: Device detach failed for vdb: Unable to detach from guest transient domain. | 16:08 |
| stvnoyes | happened twice yesterday, but after a bunch of debug, hasn't happened yet today | 16:08 |
| stvnoyes | i've been updated this bug - https://bugs.launchpad.net/nova/+bug/1696125 | 16:09 |
| openstack | Launchpad bug 1696125 in OpenStack Compute (nova) "Detach interface failed - timeout waiting to detach tap device in linuxbridge job (pike)" [High,In progress] - Assigned to Matt Riedemann (mriedem) | 16:09 |
| stvnoyes | fyi | 16:09 |
| stvnoyes | seems to go down into libvirt and libvirt never responds with detach complete | 16:10 |
| jgriffith | stvnoyes I ran into that at one point a while back, but with the old code. Problem "went away" and I never got it back | 16:10 |
| jgriffith | stvnoyes and never figured out what it was doing either :( | 16:10 |
| *** nhelgeson has joined #openstack-meeting-cp | 16:10 | |
| mriedem | stvnoyes: are you using ovs or linuxbridge? | 16:10 |
| stvnoyes | ovs | 16:11 |
| mriedem | are you running latest nova? | 16:11 |
| mriedem | there was a recent change that went into that code not too long ago | 16:11 |
| stvnoyes | sorta, as of Aug 31, after the last change listed in that bug | 16:11 |
| mriedem | https://review.openstack.org/#/q/I8cd056fa17184a98c31547add0e9fb2d363d0908 | 16:12 |
| mriedem | ok you should have that then | 16:12 |
| mriedem | melwitt, mdbooth, lyarwood and kashyap are the people to ask about that weird persistent vs transient domain stuff | 16:13 |
| stvnoyes | ok thx. the persistent detach seems to work ok, it dies on the transient detach | 16:13 |
| stvnoyes | i am hoping to get a failure with my latest debug code, should learn more when that happens | 16:14 |
| stvnoyes | unless of course it changes things enough to prevent the failure | 16:14 |
| ildikov | stvnoyes: thanks for looking into it | 16:16 |
| ildikov | I didn't run into this one besides the Gerrit reviews | 16:16 |
| ildikov | is there anything else to add to this topic? | 16:17 |
| stvnoyes | all set here | 16:17 |
| ildikov | stvnoyes: cool, thanks | 16:18 |
| ildikov | so we're working on a couple of things to get the multi-attach prerequisites covered as well before merging the new attach patch | 16:18 |
| ildikov | the reason is to wait and have the latest microversion out so we don't need to deal with bumps later if possible | 16:18 |
| ildikov | we said we will have a uses_shared_connections flag | 16:19 |
| * johnthetubaguy hides in the back row | 16:19 | |
| ildikov | looking more into it the recent plans are to have that in the volume info | 16:19 |
| ildikov | as opposed to the attachment or the connection_info | 16:19 |
| ildikov | mriedem: johnthetubaguy: any objections to that? ^^ | 16:20 |
| ildikov | johnthetubaguy: glad you could join :) | 16:20 |
| jgriffith | johnthetubaguy mriedem for a little more detail, the idea being that you'd want *something* to use as a lock string even during attachment-reserve/create | 16:21 |
| johnthetubaguy | as long as when we do attachment_update and attachment_delete we have the info, I think it is fine | 16:21 |
| jgriffith | So the proposal is that we have a bool added in the volume that says "uses_shared_targets" | 16:21 |
| johnthetubaguy | jgriffith: why on reserve? | 16:21 |
| jgriffith | patrickeast raised a concern stating it needed to be there | 16:21 |
| johnthetubaguy | do we know why? | 16:21 |
| jgriffith | I'm not 100% convinced, but didn't feel like rat holing | 16:22 |
| ildikov | and as it is a capability it doesn't change over attachments, so it makes more sense as part of the volume info | 16:22 |
| johnthetubaguy | so a lock on reserve isn't really implementable in Nova right now | 16:22 |
| ildikov | jgriffith: didn't he say attachment_update? | 16:22 |
| jgriffith | ildikov +1 it made sense to associate it with the volume regardless | 16:22 |
| jgriffith | ildikov well, yes; the problem being that he'd need the info DURING the attachment_update | 16:22 |
| johnthetubaguy | yeah, in volume_info seems to make sense, from a data model POV | 16:22 |
| jgriffith | which means ideally he'd have it on the attachment_reserve | 16:22 |
| johnthetubaguy | I am guessing non-Nova users will appreciate it before attachment_create/reserve etc | 16:23 |
| ildikov | that would mean the return value from reserve the latest and not using it for reserve | 16:23 |
| jgriffith | So my proposal is to just put that flag in the volume, as well as the volume_backend_name which could then be used for the lock | 16:23 |
| ildikov | jgriffith: +1 | 16:23 |
| johnthetubaguy | yeah, we want it for attachment_update and _delete, I think that is the main bit | 16:24 |
| jgriffith | johnthetubaguy yeah, and this way you can have it for *all the things* if something comes up | 16:24 |
| ildikov | we retrieve the volume info before those calls I think in all cases, so it should be ok | 16:24 |
| jgriffith | logically it makes sense, and the testing so far looks bueno | 16:24 |
| ildikov | we could still save it in the BDM if we wanted to | 16:24 |
| jgriffith | hope to have it posted later this morning | 16:24 |
| mriedem | what happens if the volume is retyped? | 16:24 |
| mriedem | and the backend name changes | 16:25 |
| jgriffith | if I can figure out which Instance I had all the code on :) | 16:25 |
| johnthetubaguy | jgriffith: yeah, all sounds fine, my worry was there was something happening in reserve/create we don't understand | 16:25 |
| jgriffith | mriedem then that info gets updated if it's a backend migration | 16:25 |
| jgriffith | johnthetubaguy no, I don't think there is, it's more about when/how to get the info on the caller side | 16:25 |
| jungleboyj | jgriffith: That plan makes sense to me. | 16:26 |
| jgriffith | mriedem did that address our question? | 16:26 |
| mriedem | i don't really want to think about retyping a multi-attach volume | 16:26 |
| jgriffith | mriedem me neither :( | 16:26 |
| ildikov | the info makes even more sense on the volume level considering back end migration IMHO | 16:26 |
| jgriffith | There's a reason we used not allow retype of an in-use volume :) | 16:26 |
| ildikov | yeah, let's not ruin this nice morning with that thought... :/ | 16:26 |
| johnthetubaguy | jgriffith: cool | 16:26 |
| johnthetubaguy | mriedem +1 on that | 16:27 |
| jungleboyj | mriedem: One step at a time. :-) | 16:28 |
| ildikov | ok, it seems to me that we're on an agreement here | 16:28 |
| ildikov | so if anyone wants to rain in this parade please do it now | 16:29 |
| ildikov | or don't do it at all :) | 16:29 |
| mriedem | shared connections are backend specific, | 16:30 |
| mriedem | and the volume is typed per backend, | 16:30 |
| mriedem | so it makes sense to model that in the volume | 16:30 |
| mriedem | so +1 | 16:30 |
| ildikov | great, so we will add the info to the volume and do the microversion bumps accordingly | 16:31 |
| * johnthetubaguy nods | 16:32 | |
| ildikov | next update | 16:32 |
| johnthetubaguy | is there a spec to +1 around all that, I maybe missed the link? | 16:32 |
| ildikov | johnthetubaguy: I will add this to the multi-attach spec after the meeting | 16:32 |
| johnthetubaguy | OK | 16:33 |
| ildikov | johnthetubaguy: I added the info about the lock there, but wanted to get to an agreement on where we put the extra info before updating the spec again | 16:33 |
| johnthetubaguy | +1 | 16:33 |
| ildikov | johnthetubaguy: I also added a note there about the policies I believe where I will need some double checks and suggestions as well | 16:33 |
| johnthetubaguy | cool | 16:34 |
| ildikov | johnthetubaguy: so highly appreciated if you can check the spec once I update it again shortly | 16:34 |
| mriedem | you guys don't want a cinder spec for any of that? | 16:34 |
| johnthetubaguy | I think the policy should be mostly cinder side, but I should read through that | 16:34 |
| johnthetubaguy | mriedem: I was wondering that too | 16:34 |
| jgriffith | mriedem yeah, we do/will | 16:34 |
| jgriffith | I'll have it posted prior to proposing the changes | 16:34 |
| mriedem | nova was going to have a policy rule for multi-attach boot from volume i think | 16:34 |
| mriedem | cinder was going to have a policy rule for multi-attach in general | 16:35 |
| mriedem | it was in my nova/cinder ptg recap email | 16:35 |
| ildikov | covering that on both sides would be good, I agree | 16:35 |
| ildikov | I'm happy to type it up, but my knowledge on policies is fairly weak, so I'll need some help | 16:36 |
| johnthetubaguy | some of this could be called "configuration" depending on how you expose this in the API | 16:36 |
| johnthetubaguy | I guess I was meaning giving some control to the operators, however you feel is best | 16:37 |
| jungleboyj | mriedem: Yeah, we were going to have policies for mulit-attach, read-only and read/write | 16:37 |
| jgriffith | jungleboyj we have some discussing to do around some of that on the Cinder side FWIW | 16:39 |
| jgriffith | but anyway | 16:39 |
| ildikov | ok, so let's discuss what we need to before the next meeting | 16:40 |
| jungleboyj | jgriffith: Ok. | 16:40 |
| mriedem | stvnoyes: yay https://photos.app.goo.gl/Q8JdpjM0PZhAzsv32 | 16:40 |
| ildikov | I will update the Nova side spec and we can add a reference to any Cinder side document we will have | 16:40 |
| mriedem | required every time i review any live migration code | 16:40 |
| stvnoyes | nice, so simple :-) | 16:41 |
| ildikov | mriedem: nice! in the sense of existence | 16:42 |
| johnthetubaguy | mriedem: that first one is a cast depending on the microversion now | 16:42 |
| ildikov | we should have more of these honestly, I wish I wouldn't be that lazy to draw some when I go and re-understand these flows... | 16:42 |
| mriedem | johnthetubaguy: thats from the API, which is not in this diagram | 16:42 |
| mriedem | i'm starting at the conductor live migration task | 16:43 |
| johnthetubaguy | mriedem: good point | 16:43 |
| ildikov | ok | 16:44 |
| ildikov | further items | 16:44 |
| ildikov | I updated the new attach patch with removing the tiny race conditions by changing the order of attachment_delete and attachment_create | 16:45 |
| ildikov | to have create first | 16:45 |
| stvnoyes | +1 | 16:45 |
| ildikov | with jgriffith we're now in a smaller rabbit hole on tracking the volume and attachment state on the Cinder side | 16:45 |
| mriedem | that's this right? https://review.openstack.org/#/c/504467/ | 16:46 |
| jgriffith | mriedem yes | 16:46 |
| mriedem | i was confused how that played into the changes we needed on the nova side | 16:46 |
| mriedem | i guess they are separate issues? | 16:46 |
| jgriffith | partially | 16:46 |
| jgriffith | it's a multi-attach issue for the most part | 16:46 |
| jgriffith | But there's a problem with moving those things with making sure we have the right "states" on things | 16:47 |
| ildikov | mriedem: the problem by having create coming first is that it changes the volume state to 'reserved', which messes with delete, which then changes the volume state to 'available' which also doesn't work and that's not even multi-attach yet... | 16:47 |
| jgriffith | what I mean is not the enforcement/check of things, but at the end of actions, figuring out the disaster that is all the various states stashed here and there when you have multiple attachment records | 16:47 |
| jgriffith | and you don't treat them as the primary resource | 16:48 |
| mriedem | ok | 16:48 |
| mriedem | so if a volume is reserved or in-use because there is an existing attachment, | 16:48 |
| mriedem | and we create another attachment to keep it reserved, that changes the volume status from in-use to reserved? | 16:48 |
| jgriffith | mriedem correct | 16:48 |
| mriedem | rather than just leaving it in-use | 16:48 |
| mriedem | ok | 16:48 |
| jgriffith | oh... | 16:48 |
| jgriffith | no opposite | 16:48 |
| jgriffith | what happens currently is it will get updated to reserved | 16:49 |
| jgriffith | I don't think that's what we want | 16:49 |
| jgriffith | we want to keep the in-use status | 16:49 |
| mriedem | and once we delete the old attachment, it should leave the volume reserved, but not in-use if that remaining attachment doesn't have a connector | 16:49 |
| ildikov | mriedem: exactly | 16:49 |
| mriedem | something like that | 16:49 |
| jgriffith | mriedem the last one you pointed out yes | 16:49 |
| ildikov | mriedem: yes and right now if you delete an attachment it will change the volume state to 'available' blindly | 16:49 |
| mriedem | ok | 16:49 |
| jungleboyj | jgriffith: Agreed. Seems like in-use is the right status. | 16:49 |
| mriedem | jungleboyj: in-use depends on if the attachment has a connector | 16:50 |
| mriedem | from nova's pov, in-use or reserved are basically the same | 16:50 |
| ildikov | mriedem: +1 | 16:50 |
| jgriffith | https://review.openstack.org/#/c/504467/5/cinder/volume/api.py L#2048 | 16:50 |
| jgriffith | I'm open to suggestions/discussion if people think that ranking is incorrect | 16:50 |
| jungleboyj | mriedem: Right, but it shouldn't get switched to reserved if there is a connector and it is still in-use in at least one location. Right? | 16:51 |
| mriedem | jungleboyj: correct | 16:51 |
| mriedem | at least that's what i'd expect | 16:51 |
| ildikov | jgriffith: I couldn't finish my comments before the meeting, but will add them shortly | 16:51 |
| jungleboyj | mriedem: ++ | 16:51 |
| jgriffith | honestly I'd like to propose a complete rewrite of all of the status mess in Cinder, but I think that's a bigger problem and don't want to pause the Nova attachment changes any more than we have to | 16:51 |
| ildikov | mriedem: and more importantly we also want to get 'attaching' and 'detaching' statuses correctly would be my thinking | 16:51 |
| jungleboyj | mriedem: Granted I am new to this and trying to catch up. If I make no sense you can tell me to go away. ;-) | 16:51 |
| jgriffith | jungleboyj no!! You don't get to "go away" | 16:52 |
| *** iyamahat has quit IRC | 16:52 | |
| jungleboyj | jgriffith: Yeah, that would be a much larger effort and we should let this work finish and stabilize first. | 16:52 |
| jgriffith | and if something doesn't make sense, ping me or somebody else to figure it out | 16:52 |
| ildikov | jgriffith: that makes sense and as we don't want to introduce back status checking in Nova that much I would hope we can rewrite this later without any big mess | 16:52 |
| jungleboyj | We have made so much progress. | 16:52 |
| jungleboyj | awww jgriffith Wants me around! :-) | 16:52 |
| *** yamahata has quit IRC | 16:52 | |
| * jgriffith didn't say that | 16:52 | |
| mriedem | there is no attaching status right? | 16:52 |
| * jungleboyj laughs | 16:53 | |
| jgriffith | mriedem there is | 16:53 |
| mriedem | it's available, reserved, in-use, detaching, available | 16:53 |
| ildikov | jungleboyj: we're just eager to share the pain with as many fellow Stackers as possible ;) | 16:53 |
| jungleboyj | :-) | 16:53 |
| mriedem | ok, i'll just leave this alone... | 16:53 |
| ildikov | mriedem: attachment_update puts the volume in 'attaching' state | 16:53 |
| mriedem | well, tha'ts the attach_status yeah? | 16:54 |
| ildikov | and it's attachment_complete that moves it to 'in-use' | 16:54 |
| mriedem | there is status, and attach_status | 16:54 |
| mriedem | like vm and task state in nova | 16:54 |
| mriedem | a vm can be ACTIVE and 'migrating' | 16:54 |
| mriedem | anywho | 16:54 |
| ildikov | mriedem: ah, ok | 16:54 |
| mriedem | btw, | 16:55 |
| mriedem | i should not know this much about the internal state machine in cinder | 16:55 |
| jgriffith | mriedem and now you're asking for my 20 minute rant on how F'd up all of this is on the Cinder side :) | 16:55 |
| jgriffith | mriedem these are why I feel the whole thing is "broken" in Cinder and needs fixed | 16:55 |
| ildikov | mriedem: I wouldn't volunteer right now to write up all the possible variations of the 4 statuses we're having... | 16:55 |
| jgriffith | mriedem agreed | 16:55 |
| jgriffith | anyway... I do plan to "fix" it | 16:55 |
| jgriffith | just not before the nova attach changes | 16:56 |
| mriedem | ok, ill go back to reviewing steve's live migration change | 16:56 |
| ildikov | mriedem: correct, Nova shouldn't play on that field in an ideal world | 16:56 |
| jungleboyj | The fact that here is status and attach_status blew my mind when I realized it. | 16:56 |
| jgriffith | jungleboyj don't forget the attachment records (new and old) also has an independent attach_status column as well | 16:56 |
| ildikov | ok, so I think we all have homeworks that we can move forward with | 16:56 |
| jgriffith | we really want to make sure we record attach_status!! | 16:57 |
| ildikov | jgriffith: it's very important! :) | 16:57 |
| jgriffith | FWIW, my intent was that attach related statuses on the volume go away; and the attachment records are the only ones that matter | 16:57 |
| jgriffith | 1 source of truth | 16:58 |
| jungleboyj | jgriffith: ++ That sounds like the right goal. | 16:58 |
| jgriffith | anyway... we don't want to go into that right now probably | 16:58 |
| ildikov | nope | 16:58 |
| ildikov | we have 2 minutes left | 16:58 |
| ildikov | so I wonder whether we have any other topics we need to discuss this week and haven't yet? | 16:58 |
| ildikov | ok, it seems that was it for this week | 16:59 |
| ildikov | thank you all! | 16:59 |
| ildikov | let's continue the chats on the channel(s) | 17:00 |
| ildikov | see you here next week | 17:00 |
| ildikov | #endmeeting | 17:00 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 17:00 | |
| openstack | Meeting ended Thu Sep 21 17:00:28 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:00 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-09-21-16.00.html | 17:00 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-09-21-16.00.txt | 17:00 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2017/cinder_nova_api_changes.2017-09-21-16.00.log.html | 17:00 |
| jungleboyj | Thanks! | 17:00 |
| *** aselius has joined #openstack-meeting-cp | 17:02 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 17:22 | |
| *** felipemonteiro has quit IRC | 17:22 | |
| *** rarcea has quit IRC | 17:24 | |
| *** felipemonteiro has joined #openstack-meeting-cp | 17:25 | |
| *** mriedem has left #openstack-meeting-cp | 17:28 | |
| *** felipemonteiro_ has quit IRC | 17:28 | |
| *** iyamahat has joined #openstack-meeting-cp | 17:36 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 17:53 | |
| *** diablo_rojo has quit IRC | 17:57 | |
| *** diablo_rojo has joined #openstack-meeting-cp | 17:57 | |
| *** yamahata has joined #openstack-meeting-cp | 18:36 | |
| *** xyang1 has quit IRC | 19:26 | |
| *** xyang1 has joined #openstack-meeting-cp | 19:37 | |
| *** gouthamr has quit IRC | 20:28 | |
| *** edmondsw has quit IRC | 20:51 | |
| *** edmondsw has joined #openstack-meeting-cp | 20:57 | |
| *** edmondsw has quit IRC | 21:01 | |
| *** felipemonteiro has quit IRC | 21:16 | |
| *** felipemonteiro_ has joined #openstack-meeting-cp | 21:18 | |
| *** felipemonteiro__ has joined #openstack-meeting-cp | 21:19 | |
| *** felipemonteiro_ has quit IRC | 21:23 | |
| *** felipemonteiro__ has quit IRC | 21:59 | |
| *** felipemonteiro__ has joined #openstack-meeting-cp | 22:00 | |
| *** iyamahat_ has joined #openstack-meeting-cp | 22:02 | |
| *** iyamahat has quit IRC | 22:02 | |
| *** felipemonteiro__ has quit IRC | 22:06 | |
| *** iyamahat_ has quit IRC | 22:23 | |
| *** iyamahat has joined #openstack-meeting-cp | 22:24 | |
| *** kbyrne has quit IRC | 22:33 | |
| *** sdague has quit IRC | 22:34 | |
| *** xyang1 has quit IRC | 22:38 | |
| *** edmondsw has joined #openstack-meeting-cp | 22:58 | |
| *** edmondsw has quit IRC | 23:02 | |
| *** iyamahat has quit IRC | 23:03 | |
| *** iyamahat_ has joined #openstack-meeting-cp | 23:03 | |
| *** MarkBaker has joined #openstack-meeting-cp | 23:34 | |
| *** gouthamr has joined #openstack-meeting-cp | 23:40 | |
| *** markvoelker has quit IRC | 23:40 | |
| *** MarkBaker has quit IRC | 23:45 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!