| *** ducttape_ has joined #openstack-meeting-cp | 00:08 | |
| *** ducttape_ has quit IRC | 00:52 | |
| *** ducttape_ has joined #openstack-meeting-cp | 01:04 | |
| *** ducttape_ has quit IRC | 01:15 | |
| *** ducttape_ has joined #openstack-meeting-cp | 01:29 | |
| *** ducttape_ has quit IRC | 01:50 | |
| *** ducttape_ has joined #openstack-meeting-cp | 02:12 | |
| *** ducttape_ has quit IRC | 02:37 | |
| *** ducttape_ has joined #openstack-meeting-cp | 02:37 | |
| *** ducttape_ has quit IRC | 02:52 | |
| *** gouthamr has joined #openstack-meeting-cp | 02:56 | |
| *** ediardo has quit IRC | 03:09 | |
| *** gouthamr has quit IRC | 03:11 | |
| *** ediardo has joined #openstack-meeting-cp | 03:11 | |
| *** noama has quit IRC | 03:12 | |
| *** noama has joined #openstack-meeting-cp | 03:12 | |
| *** ducttape_ has joined #openstack-meeting-cp | 03:15 | |
| *** ducttape_ has quit IRC | 03:26 | |
| *** coolsvap has joined #openstack-meeting-cp | 03:59 | |
| *** ducttape_ has joined #openstack-meeting-cp | 04:26 | |
| *** ducttape_ has quit IRC | 04:31 | |
| *** prateek has joined #openstack-meeting-cp | 04:49 | |
| *** ducttape_ has joined #openstack-meeting-cp | 05:00 | |
| *** ducttape_ has quit IRC | 05:39 | |
| *** ducttape_ has joined #openstack-meeting-cp | 06:57 | |
| *** ducttape_ has quit IRC | 07:02 | |
| *** ducttape_ has joined #openstack-meeting-cp | 08:28 | |
| *** MarkBaker has quit IRC | 08:30 | |
| *** ducttape_ has quit IRC | 08:33 | |
| *** noama has quit IRC | 08:48 | |
| *** MarkBaker has joined #openstack-meeting-cp | 09:13 | |
| *** ducttape_ has joined #openstack-meeting-cp | 09:58 | |
| *** ducttape_ has quit IRC | 10:03 | |
| *** MarkBaker has quit IRC | 10:05 | |
| *** MarkBaker has joined #openstack-meeting-cp | 10:07 | |
| *** MarkBaker has quit IRC | 10:17 | |
| *** ducttape_ has joined #openstack-meeting-cp | 11:03 | |
| *** MarkBaker has joined #openstack-meeting-cp | 11:16 | |
| *** ducttape_ has quit IRC | 11:21 | |
| *** cebreidian has joined #openstack-meeting-cp | 11:29 | |
| *** ducttape_ has joined #openstack-meeting-cp | 11:33 | |
| *** sdague has joined #openstack-meeting-cp | 11:33 | |
| *** ducttape_ has quit IRC | 11:49 | |
| *** prateek has quit IRC | 12:24 | |
| *** ducttape_ has joined #openstack-meeting-cp | 12:49 | |
| *** ducttape_ has quit IRC | 12:54 | |
| *** lamt has quit IRC | 13:12 | |
| *** gouthamr has joined #openstack-meeting-cp | 13:26 | |
| *** prateek has joined #openstack-meeting-cp | 13:31 | |
| *** noama has joined #openstack-meeting-cp | 13:37 | |
| *** noama has left #openstack-meeting-cp | 13:39 | |
| *** ducttape_ has joined #openstack-meeting-cp | 13:50 | |
| *** ducttape_ has quit IRC | 13:55 | |
| *** xyang1 has joined #openstack-meeting-cp | 14:11 | |
| *** lamt has joined #openstack-meeting-cp | 14:11 | |
| *** sdague_ has joined #openstack-meeting-cp | 14:21 | |
| *** sdague has quit IRC | 14:24 | |
| *** sdague_ is now known as sdague | 14:27 | |
| *** ducttape_ has joined #openstack-meeting-cp | 14:32 | |
| *** ducttape_ has quit IRC | 14:42 | |
| *** prateek has quit IRC | 14:46 | |
| *** prateek has joined #openstack-meeting-cp | 14:51 | |
| *** ducttape_ has joined #openstack-meeting-cp | 15:17 | |
| *** jaugustine has joined #openstack-meeting-cp | 15:22 | |
| *** prateek has quit IRC | 15:44 | |
| *** TheJulia has joined #openstack-meeting-cp | 15:59 | |
| *** _ducttape_ has joined #openstack-meeting-cp | 16:00 | |
| *** ducttape_ has quit IRC | 16:04 | |
| *** sdague has quit IRC | 16:06 | |
| *** jlopezgu has quit IRC | 16:07 | |
| *** jlopezgu has joined #openstack-meeting-cp | 16:12 | |
| *** _ducttape_ has quit IRC | 16:27 | |
| *** ducttape_ has joined #openstack-meeting-cp | 16:28 | |
| *** mriedem has joined #openstack-meeting-cp | 16:46 | |
| ildikov | #startmeeting cinder-nova-api-changes | 17:00 |
|---|---|---|
| openstack | Meeting started Mon Dec 19 17:00:42 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 xyang1 raj_singh lyarwood | 17:01 |
| mriedem | o/ | 17:01 |
| scottda | hey | 17:01 |
| ildikov | hi :) | 17:01 |
| hemna | tough | 17:01 |
| johnthetubaguy | o/ | 17:02 |
| ildikov | let's wait one more minute and then we can start | 17:02 |
| ildikov | on Cinder side we have the dependency of the new API patch merged, so hopefully jgriffith is busy with the API patch atm | 17:04 |
| ildikov | johnthetubaguy: did you have a chance to go through the comments on the Nova side patch? | 17:04 |
| * johnthetubaguy hides in the naughty corner | 17:04 | |
| * ildikov does not know what to say on the year's last meeting to this :) | 17:05 | |
| johnthetubaguy | heh | 17:05 |
| ildikov | johnthetubaguy: we discussed it briefly and the main comment from mriedem was to not initiate any volume state changes in Cinder from Nova | 17:05 |
| ildikov | johnthetubaguy: so far everyone agreed to remove that direction form your spec | 17:06 |
| johnthetubaguy | OK, I am not sure I know what that means | 17:07 |
| ildikov | johnthetubaguy: but we can discuss it further today if you feel the need | 17:07 |
| mriedem | johnthetubaguy: yeah the main issue i had was there are several parts that rely on nova setting a vol attachment resource status to error in cinder when we hit a problem, and i thought nova would just delete the vol attachment | 17:07 |
| johnthetubaguy | ah, delete vs update into an error state | 17:07 |
| mriedem | similar to nova rolling back and calling os-terminate_connection today on a failed attach | 17:07 |
| mriedem | yeah i don't like nova controlling resource state in cinder | 17:07 |
| mriedem | i don't think anyone does | 17:08 |
| *** _ducttape_ has joined #openstack-meeting-cp | 17:08 | |
| johnthetubaguy | I think I wanted a "tombstone" for an operator to do checks/cleanup | 17:08 |
| mriedem | i think you were doing it in part for evacuate making queries for attachments in error state, | 17:08 |
| ildikov | it also gives more items to clean up later which is not that fortunate either | 17:08 |
| mriedem | but there are probably other ways to handle that | 17:08 |
| johnthetubaguy | ah, yeah, evacute | 17:08 |
| johnthetubaguy | what was the replacement for evacuate? | 17:09 |
| * smcginnis strolls in but stays at the back of the room | 17:09 | |
| mriedem | it's been a couple of weeks since i left comments so they are in there | 17:09 |
| mriedem | i had some questions about evacuate related to the error state thing, but don't remember what they were now | 17:09 |
| mriedem | but was thinking there were alternatives, or just not needing the error thing | 17:09 |
| johnthetubaguy | oh, use the migration object instead | 17:09 |
| mriedem | not sure what you mean by replacement for evacuate, but yeah we use the migration object to track state for evacuate now | 17:10 |
| mriedem | i think i thought about that at one point too, we could store some data in the migration object | 17:10 |
| mriedem | like we have old/new instance type in the migration object | 17:10 |
| mriedem | if we needed, we could have old/new vol attachment in there too | 17:10 |
| *** ducttape_ has quit IRC | 17:11 | |
| johnthetubaguy | so I should go through that, and undo the error state stuff | 17:11 |
| johnthetubaguy | so tomorrow is my last day before next year | 17:12 |
| johnthetubaguy | I should try get that done tomorrow | 17:12 |
| johnthetubaguy | but been pushing on neutron v2 refactoring instead | 17:12 |
| ildikov | johnthetubaguy: the pretty high level Cinder spec: http://specs.openstack.org/openstack/cinder-specs/specs/ocata/add-new-attach-apis.html | 17:13 |
| mriedem | johnthetubaguy: i'd say if you have thoughts, just make a note in the spec review as a reminder for when you get back, but keep trucking on the neutronv2 conductor stuff | 17:13 |
| ildikov | johnthetubaguy: just in case you would need to double check what calls we ended up with finally | 17:14 |
| mriedem | because that's actually in plan for ocata | 17:14 |
| johnthetubaguy | mriedem: yeah, I think thats probably the better approach | 17:14 |
| johnthetubaguy | I can't think of why delete the attachment wouldn't be enough | 17:15 |
| johnthetubaguy | I think I was worrying too much about cinder knowing about all the state changes on the Nova side | 17:15 |
| mriedem | which we don't want cinder to know about | 17:16 |
| smcginnis | mriedem: +1 | 17:16 |
| ildikov | I'm more of a fan of single responsibility as much as we can achieve that here | 17:16 |
| mriedem | from what i remember i think the only case that it maybe made some kind of sense we evacuate cleanup, but again, it's been 2 weeks and i think we have alternatives | 17:16 |
| ildikov | so what mriedem says :) | 17:16 |
| smcginnis | I think Cinder should have minimal awareness of what's happening with consumers. | 17:16 |
| mriedem | s/we/was/ | 17:16 |
| ildikov | mriedem: having alternatives sounds good, we can go into details if needed on the next meeting in Jan | 17:18 |
| johnthetubaguy | I think I don't really understand the failure modes around disconnect that well at this point | 17:18 |
| johnthetubaguy | I guess if its not detached, we leave it attached, if it is detatched, we detach it | 17:19 |
| johnthetubaguy | anyways, simpler sounds like a better starting point | 17:20 |
| ildikov | johnthetubaguy: +1 | 17:20 |
| ildikov | johnthetubaguy: when we'll have the Cinder API merged or close to that state we can also do some PoC, like what jgriffith started earlier | 17:21 |
| johnthetubaguy | the tricky bit, I think, is going to be the smooth transition to the new API | 17:22 |
| ildikov | you mean from the point of view of the already created volumes? | 17:23 |
| smcginnis | johnthetubaguy: Or just all the changes required on the nova side, microversions, etc.? | 17:24 |
| johnthetubaguy | yeah, already created volumes | 17:25 |
| johnthetubaguy | and when to use the new API part way through operations like live-migration | 17:25 |
| johnthetubaguy | we have a mix of old a new compute nodes out there, etc | 17:26 |
| johnthetubaguy | we have patterns to follow, its just tricky | 17:27 |
| ildikov | we can switch to the new API, when all the computes are upgraded | 17:27 |
| mriedem | johnthetubaguy: we can globally lock that out based on minimum nova-compute service version in the deployment if needed | 17:27 |
| ildikov | that should be doable | 17:27 |
| ildikov | mriedem: yep, that's what I meant too | 17:27 |
| mriedem | we can also check per-compute service versions if we want to be fancy, but that's probably a more complicated dance | 17:27 |
| johnthetubaguy | mriedem: yeah, we might have to do that per operation though | 17:27 |
| johnthetubaguy | well, I mean at the start of long running operations, like live-migrate | 17:28 |
| johnthetubaguy | so we don't swap half way through | 17:28 |
| ildikov | old volumes should have attachment_id already, it's a question what other info we would need for live migrate for instance as we will create a new attachment for the new host anyhow | 17:28 |
| johnthetubaguy | but the BDM pattern I proposed in the spec should do that | 17:28 |
| ildikov | so the question here is removing the old one I guess | 17:28 |
| johnthetubaguy | apparently, not all old volumes have an attachment id already | 17:29 |
| mriedem | johnthetubaguy: do you mean attachment id in nova or cinder? | 17:29 |
| johnthetubaguy | if they were attached before we created attachment ids | 17:29 |
| johnthetubaguy | in cinder I mean | 17:29 |
| mriedem | johnthetubaguy: i think we're talking about different things | 17:29 |
| mriedem | i've been told in previous meetings that each volume attached has something in the cinder volume_attachments table already | 17:30 |
| johnthetubaguy | only past a certain point in time, I believe | 17:30 |
| ildikov | I don't remember when that got introduced, but should be there for a while now | 17:30 |
| mriedem | is havana old enough? | 17:30 |
| ildikov | it is for me! | 17:30 |
| mriedem | hemna wrote the schema migration so he'd know | 17:30 |
| hemna | hey | 17:31 |
| hemna | sorry guys, been on multiple meetings at once | 17:31 |
| hemna | ok correct. | 17:32 |
| johnthetubaguy | according to the user survey, 16% of users in October 2015 were on Havana, 12% are on older releases | 17:32 |
| mriedem | johnthetubaguy: so for old volume attachments / BDMs we know we'll need to 'upgrade' those to the new model somehow | 17:32 |
| hemna | each attachment is supposed to have a volume_attachment entry | 17:32 |
| johnthetubaguy | mriedem: yeah, basically | 17:32 |
| hemna | and all the original cinder volume table information was migrated when the volume_attachment table was created. | 17:32 |
| johnthetubaguy | mriedem: I think we previously agreed a cinder-manage cmd to fix that up | 17:33 |
| mriedem | johnthetubaguy: i left some comments on that in the spec too i believe | 17:33 |
| mriedem | johnthetubaguy: i was hoping for something more automatic | 17:33 |
| mriedem | i.e. online data migration | 17:33 |
| johnthetubaguy | mriedem: we can call all that from the online data migrations stuff | 17:33 |
| mriedem | because the spec says something about a nova-manage command calling a cinder-manager command, and that seems bad to me | 17:33 |
| johnthetubaguy | so the trade off was vs adding an API thats just for the upgrade hump | 17:33 |
| mriedem | i think we can migrate old attachments on (1) first access after rolling new code or (2) a periodic task in the computes for vols attached to instances on that upgraded compute | 17:34 |
| mriedem | then maybe after n-2 or whatever we drop that compat code | 17:34 |
| *** SergeyLukjanov__ has quit IRC | 17:34 | |
| johnthetubaguy | yeah, I am thinking the same, except its nova-manage cmds to match the DB work | 17:35 |
| mriedem | if nova-manage has to cast to the compute it's not going to be fun | 17:35 |
| mriedem | *rpc call to the compute | 17:35 |
| mriedem | when i was reading the spec i thought there was some reason we'd need to call to the compute - to get the volume connector from brick | 17:35 |
| johnthetubaguy | mriedem: true, its really about staggering the system load on upgrade | 17:35 |
| *** SergeyLukjanov has joined #openstack-meeting-cp | 17:35 | |
| mriedem | which is needed in the update attachment for existing attachments | 17:35 |
| mriedem | we do'nt have the connector from nova-manage, and you can only git it off the compute | 17:36 |
| johnthetubaguy | yeah | 17:36 |
| mriedem | so you're talking about adding an rpc call from nova-manage to compute i think | 17:36 |
| mriedem | which is why i was talking about doing something more automatic | 17:36 |
| johnthetubaguy | yeah, thats a "bit" evil :( | 17:36 |
| mriedem | or background tasks | 17:36 |
| mriedem | right | 17:36 |
| johnthetubaguy | anyways, we can work through that | 17:36 |
| mriedem | yeah it's all in the spec :) | 17:37 |
| ildikov | :) | 17:37 |
| mriedem | my wedding gift to you | 17:37 |
| johnthetubaguy | mriedem: :) | 17:37 |
| scottda | ha. That's right congratulations johnthetubaguy | 17:37 |
| johnthetubaguy | actually just got the usb stick with all the photos on today, so thats some fun for tonight | 17:38 |
| ildikov | johnthetubaguy: I guess you're asking me now to cut the meeting short :) | 17:38 |
| johnthetubaguy | I can't go in the living room right now, apparently, all I can here is present wrapping noises, and the odd bit of singing | 17:39 |
| johnthetubaguy | so I am good for now | 17:39 |
| hemna | :) | 17:39 |
| ildikov | :) | 17:39 |
| johnthetubaguy | anyways, we derailed fast there :) | 17:39 |
| ildikov | is there anything for the Nova spec we can/should discuss now? | 17:39 |
| johnthetubaguy | cinder cmd vs cinder API? | 17:40 |
| ildikov | *anything else | 17:40 |
| johnthetubaguy | vs cinder lib | 17:40 |
| johnthetubaguy | for that transition bit | 17:40 |
| *** _ducttape_ has quit IRC | 17:40 | |
| johnthetubaguy | maybe its such a mess if there is no API to "upgrade" an attachment, we should just allow us to call update? | 17:40 |
| *** ducttape_ has joined #openstack-meeting-cp | 17:41 | |
| johnthetubaguy | (and we ignore the case where there is no attachment_id) | 17:41 |
| ildikov | my guess here is that it's either update or create a new attachment and remove the old | 17:42 |
| johnthetubaguy | oh... create a new one | 17:42 |
| ildikov | I'm slightly unsure at this point what update will do with an old attachment | 17:42 |
| hemna | I think the idea was to just call update | 17:42 |
| ildikov | I can clarify this with jgriffith later | 17:43 |
| ildikov | but I think the API should be able to cover this | 17:43 |
| jgriffith | sorry... late :( | 17:44 |
| ildikov | I wonder what the load will be during an upgrade and whether that can cause any issues | 17:44 |
| jgriffith | been trying to deploy OpenStack | 17:44 |
| jgriffith | I weep for our users | 17:44 |
| scottda | ha | 17:44 |
| jgriffith | johnthetubaguy update is basically a "finalize" and make the actual connection | 17:44 |
| ildikov | jgriffith: now that you mentioned users I might accept this as an excuse :) | 17:45 |
| jgriffith | create *can* do that at the same time if you like | 17:45 |
| mriedem | i have to drop - sev1 in prod, ttyl | 17:45 |
| jgriffith | but that doesn't work for Nova | 17:45 |
| ildikov | mriedem: thanks for joining, ttyl | 17:45 |
| ildikov | jgriffith: we are agonizing on an upgrade process | 17:46 |
| jgriffith | ildikov how come? | 17:46 |
| ildikov | jgriffith: in the sense of switching to the new Cinder API and get old volume attachments updated | 17:46 |
| jgriffith | should be ok with a manage script | 17:47 |
| jgriffith | we've minimized the differences between the two | 17:47 |
| jgriffith | in terms of what's in the DB etc | 17:47 |
| ildikov | jgriffith: you mean on the Nova or the Cinder side? | 17:47 |
| jgriffith | remember a while back we had this whole rework to try and make them compatible | 17:47 |
| jgriffith | ildikov Cinder side, Nova was a bit uglier (ie nova --> cinder OR cinder-1) | 17:48 |
| johnthetubaguy | there are concerns on Nova having to directly call cinder-manage | 17:48 |
| jgriffith | johnthetubaguy I wouldn't have Nova do that if it were me | 17:48 |
| johnthetubaguy | basically because we need to get the connector from the specific nova-compute node | 17:48 |
| *** sdague has joined #openstack-meeting-cp | 17:48 | |
| jgriffith | johnthetubaguy what i'm saying is that Nova should just check which version of the API cinder supports and use the latest call | 17:49 |
| johnthetubaguy | I am ok with nova-manage doing nasty things, but we can't really cheat here | 17:49 |
| jgriffith | as far as existing attachments and things like the stored attachment id... for that you do a get-attachments and find it | 17:49 |
| johnthetubaguy | jgriffith: this is about all the existing volumes, and trying to move them so we only use the new API version | 17:49 |
| johnthetubaguy | then drop the support in Nova for the old API | 17:49 |
| johnthetubaguy | right, the connector isn't stored today | 17:50 |
| jgriffith | johnthetubaguy sure | 17:50 |
| johnthetubaguy | so that needs pushing up | 17:50 |
| johnthetubaguy | and connection_info I guess | 17:50 |
| jgriffith | johnthetubaguy all you need to do after an upgrade (like nova-migrate) is call cinder "attachments_get_all_by_volume" | 17:50 |
| jgriffith | johnthetubaguy that will give you the connector info and everything that you would get if you were using the "new" API calls | 17:50 |
| johnthetubaguy | but cinder doesn't have the info from os-brick? | 17:50 |
| jgriffith | johnthetubaguy Oh! Yeah... that case | 17:51 |
| jgriffith | johnthetubaguy so that's doable | 17:51 |
| johnthetubaguy | yeah, we just haven't agreed on how yet | 17:51 |
| jgriffith | johnthetubaguy we use the old call for detach etc, and just make sure we use all new calls for attach creation | 17:52 |
| jgriffith | johnthetubaguy I had some code that did this... it even worked :p | 17:52 |
| johnthetubaguy | I think thats what ildikov was suggesting, that seems possible | 17:52 |
| jgriffith | johnthetubaguy I do think we can make this work, I'll need to get the latest update to Cinder done, and get a running cloud again to move forward | 17:53 |
| ildikov | johnthetubaguy: partially as I was thinking about how to update and I think it's not what jgriffith meant | 17:53 |
| jgriffith | ildikov very hard to say "what I meant". even for me :) | 17:54 |
| johnthetubaguy | I like the delete/create approach though | 17:54 |
| johnthetubaguy | means we do it via the API | 17:54 |
| johnthetubaguy | but its not APIs just created for upgrade | 17:54 |
| ildikov | jgriffith: hmm, good opportunity for me to plant ideas in your head now it seems :) | 17:54 |
| johnthetubaguy | its probably a create/delete, but thats a detail for later | 17:55 |
| jgriffith | johnthetubaguy I think we can solve this with the cinder api calls | 17:55 |
| ildikov | I think Cinder API calls as a target is good in general | 17:55 |
| jgriffith | johnthetubaguy it's annoying for a couple releases to support both but I think it's certainly possible | 17:55 |
| ildikov | jgriffith: as we have users still on Havana I wonder how many is that "couple"... :( | 17:56 |
| ildikov | jgriffith: it does not make it impossible of course, it was just a note | 17:56 |
| johnthetubaguy | well, maybe they just don't need the delete, because the attachment doesn't exist | 17:56 |
| johnthetubaguy | it looked like > 20% users where on havana or earlier in December 2015 user server | 17:57 |
| johnthetubaguy | so its very likely they still have volumes attached | 17:57 |
| johnthetubaguy | and want to upgrade at some point | 17:57 |
| jgriffith | johnthetubaguy they can't upgrade H-->O anyway | 17:57 |
| johnthetubaguy | totally | 17:57 |
| jgriffith | johnthetubaguy I can barely upgrade M-->N | 17:57 |
| johnthetubaguy | its just more, folks are using that thing in production | 17:58 |
| johnthetubaguy | jgriffith: well, I kinda think people should use OpenStack as a service, but I would say that | 17:58 |
| jgriffith | johnthetubaguy well, I do think it's completely doable, and it will work a hell of a lot better than things like Keystone V3 and Glance and ....... | 17:59 |
| johnthetubaguy | jgriffith: totally agreed, its totally doable | 17:59 |
| jgriffith | johnthetubaguy after this lab move and redeploy I would agree with you! | 17:59 |
| jgriffith | We've built something that requires PS to deploy at this point | 18:00 |
| johnthetubaguy | well, there are many competing deploy solutions, I guess | 18:00 |
| johnthetubaguy | doing it yourself is crazy hard | 18:01 |
| johnthetubaguy | anyways, at some point we should discuss private cloud deploy optimizations, but anyways | 18:02 |
| ildikov | johnthetubaguy: sounds a bit like discussing what to do with global warming at this point to me | 18:03 |
| johnthetubaguy | I guess we are out of time | 18:03 |
| ildikov | johnthetubaguy: and that too :) | 18:03 |
| jgriffith | and lucky me... I get to go to a meeting on Open Source contribution policy :) | 18:03 |
| johnthetubaguy | ildikov: yeah, thats true | 18:03 |
| ildikov | does anyone here would like to have the first meeting on the 2nd? | 18:04 |
| johnthetubaguy | jgriffith: I am sorry | 18:04 |
| ildikov | or the 9th sounds just fine? | 18:04 |
| johnthetubaguy | thats a public holiday for most folks right? | 18:04 |
| ildikov | jgriffith: should I create a reason for you to miss that? :) | 18:04 |
| scottda | I think the 9th | 18:05 |
| scottda | Not much will be changed by the 2nd | 18:05 |
| ildikov | jgriffith: unless you're the one holding it :) | 18:05 |
| johnthetubaguy | scottda: a very good point | 18:05 |
| ildikov | scottda: yeap, my thought exactly, just wanted to give a chance for objection if there would happen to be any :) | 18:05 |
| johnthetubaguy | happy holidays, when that happens for folks | 18:06 |
| ildikov | Happy Holidays everyone! | 18:06 |
| ildikov | Talk to you on the 9th the latest! | 18:06 |
| scottda | yup, have a good one all | 18:07 |
| ildikov | Thanks for all your efforts this year and have some well deserved fun and rest in the upcoming two weeks! :) | 18:07 |
| ildikov | #endmeeting | 18:08 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 18:08 | |
| openstack | Meeting ended Mon Dec 19 18:08:26 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 18:08 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-12-19-17.00.html | 18:08 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-12-19-17.00.txt | 18:08 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-12-19-17.00.log.html | 18:08 |
| *** MarkBaker has quit IRC | 18:14 | |
| *** stvnoyes has quit IRC | 19:06 | |
| *** david-lyle_ has joined #openstack-meeting-cp | 19:13 | |
| *** jamespag` has joined #openstack-meeting-cp | 19:13 | |
| *** jamespag` has quit IRC | 19:13 | |
| *** jamespag` has joined #openstack-meeting-cp | 19:13 | |
| *** david-lyle has quit IRC | 19:13 | |
| *** jamespage has quit IRC | 19:13 | |
| *** openstack has joined #openstack-meeting-cp | 19:14 | |
| *** ChanServ sets mode: +o openstack | 19:14 | |
| *** ducttape_ has quit IRC | 19:37 | |
| *** breton_ is now known as breton | 20:04 | |
| *** ducttape_ has joined #openstack-meeting-cp | 20:05 | |
| *** stvnoyes has joined #openstack-meeting-cp | 20:35 | |
| *** mriedem has left #openstack-meeting-cp | 20:46 | |
| *** rockyg has joined #openstack-meeting-cp | 21:02 | |
| *** gouthamr has quit IRC | 21:17 | |
| *** _ducttape_ has joined #openstack-meeting-cp | 21:29 | |
| *** ducttape_ has quit IRC | 21:33 | |
| *** _ducttape_ has quit IRC | 21:34 | |
| *** xyang1 has quit IRC | 22:53 | |
| *** rockyg has quit IRC | 23:05 | |
| *** ducttape_ has joined #openstack-meeting-cp | 23:31 | |
| *** lamt has quit IRC | 23:32 | |
| *** ducttape_ has quit IRC | 23:34 | |
| *** ducttape_ has joined #openstack-meeting-cp | 23:35 | |
| *** jaugustine has quit IRC | 23:36 | |
| *** ducttape_ has quit IRC | 23:39 | |
| *** sdague has quit IRC | 23:44 | |
| *** ducttape_ has joined #openstack-meeting-cp | 23:55 | |
| *** gouthamr has joined #openstack-meeting-cp | 23:58 | |
| *** ducttape_ has quit IRC | 23:59 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!