*** amrith is now known as _amrith_ | 00:05 | |
*** sdake_ is now known as sdake | 00:19 | |
*** beekhof has quit IRC | 00:42 | |
*** beekhof has joined #openstack-meeting-cp | 00:48 | |
*** sheel has joined #openstack-meeting-cp | 01:28 | |
*** Niham has joined #openstack-meeting-cp | 01:31 | |
*** Niham has quit IRC | 01:32 | |
*** Niham has joined #openstack-meeting-cp | 01:33 | |
*** sdake has quit IRC | 01:49 | |
*** Niham has quit IRC | 02:10 | |
*** sdake has joined #openstack-meeting-cp | 02:16 | |
*** sdake has quit IRC | 02:18 | |
*** itisha has quit IRC | 02:30 | |
*** tyr_ has quit IRC | 03:15 | |
*** Niham has joined #openstack-meeting-cp | 04:09 | |
*** Niham has quit IRC | 04:10 | |
*** Niham has joined #openstack-meeting-cp | 04:11 | |
*** Niham has quit IRC | 04:57 | |
*** Niham has joined #openstack-meeting-cp | 05:06 | |
*** tyr_ has joined #openstack-meeting-cp | 05:16 | |
*** tyr_ has quit IRC | 05:20 | |
*** Niham has quit IRC | 05:46 | |
*** tyr_ has joined #openstack-meeting-cp | 06:17 | |
*** tyr_ has quit IRC | 06:21 | |
*** coolsvap_ has joined #openstack-meeting-cp | 06:44 | |
*** Niham has joined #openstack-meeting-cp | 06:51 | |
*** Niham has quit IRC | 06:57 | |
*** sdake has joined #openstack-meeting-cp | 06:57 | |
*** coolsvap_ has quit IRC | 07:13 | |
*** coolsvap_ has joined #openstack-meeting-cp | 07:15 | |
*** tyr_ has joined #openstack-meeting-cp | 07:18 | |
*** tyr_ has quit IRC | 07:22 | |
*** sdake has quit IRC | 07:39 | |
*** coolsvap_ has quit IRC | 07:59 | |
*** tyr_ has joined #openstack-meeting-cp | 08:18 | |
*** Niham has joined #openstack-meeting-cp | 08:19 | |
*** tyr_ has quit IRC | 08:23 | |
*** markvoelker has quit IRC | 08:29 | |
*** markvoelker has joined #openstack-meeting-cp | 08:30 | |
*** sdake has joined #openstack-meeting-cp | 09:13 | |
*** tyr_ has joined #openstack-meeting-cp | 09:19 | |
*** tyr_ has quit IRC | 09:24 | |
*** _amrith_ is now known as amrith | 09:37 | |
*** sdake has quit IRC | 09:40 | |
*** tyr_ has joined #openstack-meeting-cp | 10:21 | |
*** Niham has quit IRC | 10:22 | |
*** Niham has joined #openstack-meeting-cp | 10:24 | |
*** tyr_ has quit IRC | 10:25 | |
*** amrith is now known as _amrith_ | 10:40 | |
*** sdague has joined #openstack-meeting-cp | 10:46 | |
*** tyr_ has joined #openstack-meeting-cp | 11:22 | |
*** tyr_ has quit IRC | 11:26 | |
*** _amrith_ is now known as amrith | 11:52 | |
*** tyr_ has joined #openstack-meeting-cp | 12:23 | |
*** tyr_ has quit IRC | 12:27 | |
*** Niham has quit IRC | 12:45 | |
*** amrith is now known as _amrith_ | 13:00 | |
*** _amrith_ is now known as amrith | 13:09 | |
*** xyang1 has joined #openstack-meeting-cp | 13:31 | |
*** Niham has joined #openstack-meeting-cp | 13:37 | |
*** Niham has quit IRC | 13:38 | |
*** bswartz has quit IRC | 14:27 | |
*** david-lyle has joined #openstack-meeting-cp | 14:44 | |
*** bswartz has joined #openstack-meeting-cp | 14:51 | |
*** amrith is now known as _amrith_ | 15:02 | |
*** ildikov has quit IRC | 15:07 | |
*** patrickeast has quit IRC | 15:08 | |
*** _amrith_ is now known as amrith | 15:08 | |
*** ildikov has joined #openstack-meeting-cp | 15:09 | |
*** patrickeast has joined #openstack-meeting-cp | 15:09 | |
*** amrith is now known as _amrith_ | 15:09 | |
*** _amrith_ is now known as amrith | 15:14 | |
*** hemnafk is now known as hemna | 15:23 | |
*** breton_ is now known as breton | 16:13 | |
*** david-lyle has quit IRC | 16:24 | |
*** sdake has joined #openstack-meeting-cp | 16:44 | |
*** mriedem has joined #openstack-meeting-cp | 17:00 | |
ildikov | #startmeeting cinder-nova-api-changes | 17:00 |
---|---|---|
openstack | Meeting started Thu Jun 2 17:00:22 2016 UTC and is due to finish in 60 minutes. The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
*** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 17:00 | |
openstack | The meeting name has been set to 'cinder_nova_api_changes' | 17:00 |
ildikov | scottda DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo gsilvis | 17:00 |
scottda | hi | 17:00 |
mriedem | o/ | 17:00 |
jgriffith | o/ | 17:00 |
*** andrearosa has joined #openstack-meeting-cp | 17:01 | |
patrickeast | hey | 17:01 |
andrearosa | o/ | 17:01 |
ildikov | hi everyone | 17:01 |
hemna | hey | 17:01 |
ildikov | we have our etherpad #link https://etherpad.openstack.org/p/cinder-nova-api-changes more or less up to date | 17:02 |
hemna | shameless plug....I'm still looking for a job. :P | 17:02 |
hemna | so I'm able to get BFV 'working' | 17:03 |
hemna | with reserve_volume | 17:03 |
ildikov | hemna should I add it to the etherpad as well? | 17:03 |
ildikov | :) | 17:03 |
ildikov | hemna: that's good news! | 17:03 |
hemna | but I'm having an issue reporting the an exception back up the stack when the volume is already in use. | 17:03 |
hemna | I'm working on that | 17:03 |
hemna | InvalidInput(u'Invalid input received: Invalid volume: Volume status must be available to reserve. | 17:04 |
ildikov | hemna: did you remove the second check_attach? | 17:04 |
hemna | not sure why I'm getting recursive messages as the exception message at this point | 17:04 |
hemna | but at least I have the http response code correct | 17:04 |
hemna | so it's not a nova api change (other than a message change) | 17:04 |
hemna | ildikov, kinda | 17:04 |
hemna | I just blindly removed the check_attach call | 17:05 |
hemna | :P | 17:05 |
mriedem | hemna: that won't work | 17:05 |
jgriffith | hemna: is there a bug for what you're working on? | 17:05 |
hemna | mriedem, ok | 17:05 |
mriedem | hemna: when you get to the compute in BFV | 17:05 |
mriedem | it's a cast by then | 17:05 |
mriedem | so you've lost the api response to the user | 17:05 |
ildikov | jgriffith: there are a few race condition type of bug reports, this should help in those | 17:05 |
hemna | ? | 17:05 |
mriedem | so you'd basically fail and the instance would go into error state | 17:05 |
hemna | I'm not following | 17:05 |
hemna | the API response isn't different to the user as it is now | 17:05 |
hemna | other than the text of the message | 17:06 |
jgriffith | ildikov: well, I'm looking specifically to understand what is being discussed without taking up meeting time :) | 17:06 |
mriedem | i guess i'm confused on where you're calling reserve_volume in that flow | 17:06 |
mriedem | hemna: from the API or from the compute? | 17:06 |
hemna | mriedem, API | 17:06 |
ildikov | hemna: you have the reserve call, where the first check_attach was in validate_bdm? | 17:06 |
hemna | I'll post up the patch today | 17:06 |
mriedem | hemna: oh, in that case, nevermind | 17:06 |
hemna | I'm replacing the existing check_attach call in the API | 17:06 |
hemna | with reserve_volume | 17:06 |
mriedem | there are some wrappers on the reserve method in the nova.volume.cinder api method | 17:06 |
mriedem | to handle errors | 17:07 |
ildikov | jgriffith: with hemna we're aiming at removing the check_attach calls from Nova as a first step on our journey to refactor | 17:07 |
mriedem | maybe something missing in those error decorators | 17:07 |
*** coolsvap_ has joined #openstack-meeting-cp | 17:07 | |
hemna | and detecting the case when the volume is 'in-use' and raising the same exception as it does today, just with a different message. | 17:07 |
hemna | I can put up a gist | 17:07 |
hemna | it's total hack code at this point | 17:07 |
ildikov | if you replaced that API check_attach that should be the right direction | 17:08 |
jgriffith | ildikov: ok... just curious as to why | 17:08 |
hemna | https://gist.github.com/WaltHP/12d86a9edf7c21b50d2aff443056dfc6 | 17:08 |
hemna | that's on top of my existing patch | 17:08 |
ildikov | jgriffith: the check_attach call is unnecessary for Nova, it's kind of a left over from old times | 17:08 |
ildikov | jgriffith: but it's a change that can be handled in a reasonable timeframe, therefore it seems worth starting with | 17:09 |
hemna | jgriffith, the existing nova/volume/cinder.py check_attach looks at the internal state of the cinder volume | 17:09 |
jgriffith | ildikov: okie-dokie | 17:09 |
hemna | trying to eliminate that | 17:09 |
hemna | and just rely on Cinder to do the check that already exists in os-reserve | 17:09 |
hemna | it's the same check | 17:09 |
jgriffith | ildikov: do we have an agenda today or is it open-discussion? | 17:09 |
ildikov | jgriffith: so basically we're trying the baby steps approach to have some progress, while discussing more radical changes, like the new API calls you're working on | 17:10 |
hemna | ok I'm done if we want to move on | 17:10 |
hemna | I just wanted to give a status | 17:10 |
mriedem | for the multiattach spec, | 17:10 |
mriedem | johnthetubaguy: is +2 on it, | 17:10 |
mriedem | i got back to the world <48 hours ago | 17:11 |
ildikov | jgriffith: the agenda is to discuss the ongoing items, like the one hemna brought up, bring up your work item, plus get the multi-attach spec in Nova accepted by mriedem | 17:11 |
mriedem | i will get through the spec today | 17:11 |
*** coolsvap_ has quit IRC | 17:11 | |
jgriffith | link 2 spec? | 17:11 |
mriedem | https://review.openstack.org/#/c/304681/ | 17:11 |
jgriffith | mriedem: gracias | 17:11 |
ildikov | hemna: cool, tnx, it looks good | 17:12 |
ildikov | mriedem: the spec is aiming at capturing what we need to deal with and points at the etherpad as well | 17:13 |
ildikov | mriedem: I tried not to add too many details about the dependencies there | 17:13 |
ildikov | if nothing for the spec, I think we can move to what jgriffith is working | 17:14 |
jgriffith | ildikov: ok, I guess I'll just chat about some things | 17:16 |
ildikov | here is the link to the review: https://review.openstack.org/#/c/323571/ | 17:16 |
jgriffith | I have 3 different approaches going on currently: | 17:16 |
jgriffith | 1. Just massage the existing flow and calls: https://review.openstack.org/#/c/320721 | 17:16 |
jgriffith | Ugly hacky stuff | 17:16 |
jgriffith | 2. Introduce some new calls: https://review.openstack.org/#/c/323571/ but leverage all the old stuff (helps with unit tests and back compat) | 17:17 |
jgriffith | 3. Write new stuff: https://github.com/j-griffith/cinder/commit/4feabd244e755dd02f930c1efa2c4d59f89b0c2e | 17:17 |
jgriffith | 3 is my favorite :) I'm also working on Nova changes as POC to go with it. Basically want to have a full working solution with multi-attach using option 3 in another week | 17:18 |
jgriffith | I can work on all, none or one of these | 17:19 |
jgriffith | obviously they're not complete, nor functional as they are right now. Like the copy/paste of _get_connection_count etc | 17:20 |
ildikov | 2 contains parts from 3, right? | 17:20 |
ildikov | or at least the concept of the new calls is going to that direction, IIUC | 17:20 |
jgriffith | ildikov: yes... they're all related | 17:20 |
ildikov | ok, cool | 17:20 |
jgriffith | ildikov: but the more time I spend looking at the attach/detach code in Cinder, the more I realize it's become a bit of a train wreck | 17:21 |
* hemna is a fan of 3 | 17:21 | |
ildikov | I like that we're trying to simplify the interaction between Cinder and Nova as much as possible so having one call as opposed to three or more | 17:21 |
scottda | jgriffith: Will you be pushing #3 up to gerrit ? | 17:21 |
jgriffith | and taking the opportunity to do something like 3 (while it may be scary to some) eliminates the issues folks have with race-conditions etc | 17:21 |
jgriffith | scottda: nope, I refuse :) | 17:21 |
jgriffith | scottda: of course | 17:21 |
scottda | haha | 17:21 |
hemna | :) | 17:22 |
jgriffith | scottda: but it's got a ways to go before being even WIP status in Gerrit IMO | 17:22 |
mriedem | from a nova perspective, they are all bound by microversions so not sure i have an opinion | 17:22 |
scottda | cool | 17:22 |
jgriffith | and I didn't want to bombard everybody with yet another gerrit patch yet | 17:22 |
ildikov | jgriffith: sure, that I completely get, I'm wondering about the amount of changes in NOva and the timeframe we would need to introduce them | 17:22 |
mriedem | and really would start as only calling those if nova is given a multiattach volume (i think) | 17:22 |
jgriffith | mriedem: so that's a possibility if preferred | 17:23 |
jgriffith | mriedem: I do plan to provide a nova patch to go with it FWIW | 17:23 |
jgriffith | mriedem: although it will surely not be up to standards with unit tests and some of the versioning stuff | 17:23 |
jgriffith | mriedem: I at least wanted to take a swag at a proof of concept | 17:23 |
mriedem | sure | 17:24 |
mriedem | that's fine | 17:24 |
jgriffith | mriedem: my question to you though would be... out of the choices, what has a chance of landing in N | 17:24 |
mriedem | well those 3 are all cinder changes | 17:24 |
ildikov | with smaller or larger Nova impacts | 17:25 |
jgriffith | mriedem: hehe.. yeah, but they will all require something on the Nova side to utilize them | 17:25 |
mriedem | so #1 is existing APIs but new behavior, right? | 17:25 |
jgriffith | mriedem: in other words, I want to finish and release multi-attach in N and get past all of this | 17:25 |
ildikov | #3 is the rethinking of the attach concept | 17:25 |
patrickeast | jgriffith: whats the scale difference as far as nova changes required between 1, 2 and 3? | 17:25 |
jgriffith | mriedem: pretty much, yes... but it's super ugly in terms of "optional" args/params (I think it's more trouble than it's worth) | 17:26 |
mriedem | so, a thing that might suck on the nova side is if volume['multiattach'], and we have to call a different API - however, that can all be abstracted | 17:26 |
jgriffith | mriedem: I'd suggest we don't do that if possible | 17:26 |
mriedem | yeah | 17:26 |
mriedem | so i'm not opposed to new apis that are better | 17:26 |
jgriffith | mriedem: I've been looking at just replacing the nova calls with the new calls in option-3 | 17:26 |
ildikov | mriedem: in my understanding these new API calls are not for multiattach | 17:27 |
jgriffith | patrickeast: they're in ascending order in terms of amount of change in Nova | 17:27 |
mriedem | e.g. cinder provides new api in microversion 2.6 which is the preferred way to do this, and consider attach/detach deprecated at that point | 17:27 |
mriedem | so clients would start moving | 17:27 |
jgriffith | mriedem: ok... that's certainly fair | 17:27 |
patrickeast | jgriffith: yea, but like... from 2 to 3 are we talking incremental amount of differences... or like 10x? | 17:27 |
ildikov | mriedem: I mean they would be prepared to handle multiattach as well, but it's about to remove the reserve, initialize_connection, attach chain in my understanding | 17:27 |
jgriffith | mriedem: I was more concerned that we were just already too late in the cycle for this sort of thing | 17:27 |
mriedem | my preference is to take the time to do the right thing for the long-term, whatever that is | 17:28 |
jgriffith | mriedem: and YES, exactly my plan would be to add the deprecation marker to reserve, initialize_connection and attach etc | 17:28 |
patrickeast | mriedem: +1 | 17:28 |
mriedem | if that's using new better cleaner APIs in cinder, i think we do that regarldess of schedule | 17:28 |
jgriffith | mriedem: ok, that's the best answer I could hope fo | 17:28 |
jgriffith | for | 17:28 |
mriedem | because i don't want to shoehorn #1 and introduce more tech debt | 17:29 |
hemna | I think the long term thing is option #3 | 17:29 |
jgriffith | mriedem: yes, that's the sort of thing that created the mess we have now to begin with | 17:29 |
hemna | I'd like to remove the check_attach stuff short term and rely on reserve_volume | 17:29 |
jgriffith | It's unfortunate I didn't recognize some of this sooner or as it was happening | 17:29 |
hemna | that should make it easier to migrate to #3, since it's all cinder side checks | 17:29 |
ildikov | mriedem: the regardless of schedule means being able to merge changes in Nova regardless of schedule? | 17:30 |
ildikov | mriedem: also totally agree on the long term thinking | 17:30 |
jgriffith | ildikov: hehe.. I think it means, "do the right thing even if it takes another cycle" | 17:30 |
hemna | jgriffith, +1 | 17:30 |
mriedem | what jgriffith said | 17:30 |
ildikov | jgriffith: if it's only one... | 17:30 |
hemna | ildikov, it's never one | 17:30 |
ildikov | do we have any incremental choice here? | 17:31 |
jgriffith | ildikov: I tihnk incremental in this case is bad | 17:31 |
mriedem | +1 | 17:31 |
mriedem | the problem with incremental is you bake in the badness, and then it's hard to move | 17:31 |
jgriffith | ildikov: I also think that #3 is incremental.. because to start it's mostly wrapping existing cinder calls | 17:31 |
mriedem | not only technically, but because people don't want to do it | 17:32 |
jgriffith | mriedem: +1 | 17:32 |
ildikov | sure, I'm not saying I'm against the good things, I'm just sometimes invited to customer meetings... :S | 17:33 |
hemna | ok so anyway, what is the plan then? | 17:34 |
hemna | I vote for #3 | 17:34 |
jgriffith | I'd propose I finish up POC's of #3 for nova and cinder and post them within the next week | 17:35 |
ildikov | should we do a vote? | 17:35 |
jgriffith | does that work? | 17:35 |
jgriffith | ildikov: oh.. yeah... we can vote :) | 17:35 |
ildikov | jgriffith: what is the aim from the POC? | 17:35 |
ildikov | jgriffith: is it about whether this works or more about how hard to get it work? | 17:35 |
jgriffith | ildikov: ummm... Proof Of Concept? | 17:35 |
jgriffith | ildikov: yes, see if people vomit all over it, or if it's acceptable and we all pitch in to finish/merge it | 17:36 |
mriedem | point is to see what the changes look like and see if there are red flags | 17:36 |
mriedem | that make it a non-starter | 17:36 |
ildikov | jgriffith: I know the term :) | 17:36 |
jgriffith | mriedem: +1 | 17:36 |
jgriffith | ildikov: sorry... mriedem 's answer was better | 17:36 |
ildikov | ok, let's see the PoC then | 17:37 |
mriedem | fwiw if the nova spec is generic enough to know we're playing with new things here, | 17:38 |
ildikov | jgriffith: is there any work item where either of us could join? | 17:38 |
mriedem | i'm fine with getting that in today - just need the time to look at it | 17:38 |
mriedem | ildikov: testing probably | 17:38 |
ildikov | mriedem: the plan was to have it that generic, so I referred to having new Cinder API microversion as we cannot avoid that | 17:39 |
jgriffith | ildikov: Give me til towards end of next week to get patches up. Then yes, testing | 17:39 |
ildikov | mriedem: the rest is supposed to be on us | 17:39 |
ildikov | jgriffith: ok | 17:39 |
hemna | coolio | 17:41 |
ildikov | should we continue with trying to remove check_attach, etc? | 17:41 |
ildikov | just to maintain a plan B if #3 would not work out for any reason | 17:42 |
mriedem | removing check_attach still applies for those that aren't at the microversion required to use the new stuff | 17:43 |
mriedem | so seems worthwhile | 17:43 |
hemna | ildikov, I think the removal of the check_attach stuff is a bug fix IMHO. | 17:43 |
ildikov | ok, cool | 17:43 |
hemna | BFV currently doesn't even call reserve_volume | 17:43 |
hemna | :( | 17:43 |
ildikov | yeah, don't even remind me, I checked it zillion times as I was sure I'm not able to debug properly... | 17:44 |
ildikov | ok, do we have anything else for today to discuss? | 17:46 |
ildikov | so as a quick summary we have the check_attach removal and the #3 prototyping activity ongoing | 17:47 |
ildikov | there was also an item about testing Cinder migrate | 17:48 |
mriedem | yeah are there any updates on that testing? | 17:48 |
ildikov | although for the above two that does not seem to be a direct requirement | 17:48 |
mriedem | umm | 17:49 |
mriedem | swap_volume uses check_attach right? | 17:49 |
ildikov | mriedem: that checks everything before check_attach TBH | 17:49 |
mriedem | so, it would be good to have some kind of integration test coverage before changing all that, but it could be tested manually too | 17:49 |
hemna | yah I'd like to have that testing in place | 17:50 |
mriedem | ok, i do seem to remember a bunch of checks in the compute api for swap_volume | 17:50 |
ildikov | scottda: do you have any news about testing? | 17:50 |
scottda | Sorry had to run afk... | 17:50 |
scottda | I'm making progress. | 17:50 |
ildikov | mriedem: I tried to refactor that when I touched check_attach for multi-attach, I partially failed due to the order of checks there... | 17:51 |
scottda | I need to add plumbing to have cinder tests do Nova create and volume attach. | 17:51 |
scottda | Hopefully that's not took painful. | 17:51 |
mriedem | scottda: it should be a scenario test | 17:52 |
mriedem | not a tempest api test | 17:52 |
scottda | S/took/too | 17:52 |
mriedem | scenario tests extend a base manager that does a lot of that kind of stuff for you | 17:52 |
scottda | mriedem: OK. I'll have a look. | 17:52 |
mriedem | hemna: ildikov: btw, i think i see where BFV with source=volume calls check_attach, but we can talk after the meeting | 17:54 |
*** andrearosa has left #openstack-meeting-cp | 17:54 | |
ildikov | mriedem: it calls it two times if I;m not mistaken | 17:54 |
mriedem | oh nvm, it calls check_attach but not reserve | 17:55 |
hemna | do_check_attach defaults to true | 17:55 |
hemna | mriedem, correct | 17:55 |
hemna | that's what I want to change | 17:55 |
ildikov | mriedem: yeah, no reserve | 17:55 |
hemna | and in the process eventually remove check_attach completely. | 17:55 |
hemna | if possible. | 17:55 |
ildikov | it should be, having two separate modules maintaining one single state machine is really not ideal | 17:56 |
ildikov | just to state the obvious :) | 17:56 |
ildikov | ok, we're almost out of time | 17:57 |
ildikov | we have the next meeting on Monday, I think it would be good to briefly sync up and get back to the normal schedule | 17:57 |
ildikov | any other last minute items for the meeting? | 17:58 |
mriedem | nope | 17:59 |
ildikov | ok, then thanks everyone, we had a good chat | 17:59 |
scottda | Thanks | 17:59 |
ildikov | and talk to you on Monday! | 17:59 |
ildikov | or earlier on either channel to address implementation details :) | 18:00 |
ildikov | #endmeeting | 18:00 |
*** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 18:00 | |
openstack | Meeting ended Thu Jun 2 18:00:15 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:00 |
openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-06-02-17.00.html | 18:00 |
openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-06-02-17.00.txt | 18:00 |
openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-06-02-17.00.log.html | 18:00 |
*** mriedem has left #openstack-meeting-cp | 18:00 | |
*** david-lyle has joined #openstack-meeting-cp | 18:09 | |
*** Guest35638 is now known as cFouts | 18:21 | |
*** david-lyle has quit IRC | 18:35 | |
*** harlowja has quit IRC | 18:44 | |
*** david-lyle has joined #openstack-meeting-cp | 19:24 | |
*** sdake has quit IRC | 19:35 | |
*** sdake has joined #openstack-meeting-cp | 19:38 | |
*** openstack has joined #openstack-meeting-cp | 19:40 | |
*** ChanServ sets mode: +o openstack | 19:40 | |
*** sdake has quit IRC | 19:43 | |
*** david-lyle has quit IRC | 19:57 | |
*** amrith is now known as _amrith_ | 20:07 | |
*** harlowja has joined #openstack-meeting-cp | 20:24 | |
*** piet_ has joined #openstack-meeting-cp | 20:34 | |
*** sheel has quit IRC | 20:35 | |
*** _amrith_ is now known as amrith | 21:30 | |
*** markvoelker has quit IRC | 21:58 | |
*** xyang1 has quit IRC | 21:59 | |
*** markvoelker has joined #openstack-meeting-cp | 22:58 | |
*** markvoelker has quit IRC | 23:03 | |
*** david-lyle has joined #openstack-meeting-cp | 23:20 | |
*** sdake has joined #openstack-meeting-cp | 23:54 | |
*** sdake_ has quit IRC | 23:56 | |
*** sdake has quit IRC | 23:57 | |
*** sdake has joined #openstack-meeting-cp | 23:57 | |
*** sdague has quit IRC | 23:58 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!