| *** sdake has joined #openstack-meeting-cp | 00:06 | |
| *** sdake_ has joined #openstack-meeting-cp | 00:22 | |
| *** sdake has quit IRC | 00:23 | |
| *** vilobhmm11 has quit IRC | 00:48 | |
| *** rpjr_ has quit IRC | 00:49 | |
| *** sdake_ has quit IRC | 00:58 | |
| *** rpjr_ has joined #openstack-meeting-cp | 01:12 | |
| *** _amrith_ is now known as amrith | 01:26 | |
| *** rpjr_ has quit IRC | 01:44 | |
| *** rpjr_ has joined #openstack-meeting-cp | 01:54 | |
| *** Rockyg has quit IRC | 01:56 | |
| *** askb has joined #openstack-meeting-cp | 02:03 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 02:26 | |
| *** sdake has joined #openstack-meeting-cp | 02:32 | |
| *** sdake has quit IRC | 02:32 | |
| *** sdake has joined #openstack-meeting-cp | 02:32 | |
| *** sdake_ has joined #openstack-meeting-cp | 02:42 | |
| *** sdake has quit IRC | 02:45 | |
| *** vilobhmm11 has quit IRC | 02:57 | |
| *** sdake_ is now known as sdkae | 03:05 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 03:39 | |
| *** nikhil_k has joined #openstack-meeting-cp | 03:56 | |
| *** nikhil has quit IRC | 04:00 | |
| *** beekhof has quit IRC | 04:30 | |
| *** beekhof has joined #openstack-meeting-cp | 05:11 | |
| *** ninag has joined #openstack-meeting-cp | 05:15 | |
| *** mestery has quit IRC | 05:17 | |
| *** ninag has quit IRC | 05:19 | |
| *** mestery has joined #openstack-meeting-cp | 05:23 | |
| *** amrith is now known as _amrith_ | 06:02 | |
| *** _amrith_ is now known as amrith | 06:04 | |
| *** sdkae is now known as sdake | 06:12 | |
| *** vilobhmm11 has quit IRC | 07:29 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 07:32 | |
| *** sdake_ has joined #openstack-meeting-cp | 07:46 | |
| *** sdake has quit IRC | 07:49 | |
| *** sdake_ is now known as sdake | 07:50 | |
| *** rpjr_ has quit IRC | 08:10 | |
| *** persia has quit IRC | 09:04 | |
| *** persia has joined #openstack-meeting-cp | 09:06 | |
| *** mestery_ has joined #openstack-meeting-cp | 09:40 | |
| *** tristanC_ has joined #openstack-meeting-cp | 09:43 | |
| *** mestery has quit IRC | 09:47 | |
| *** tristanC has quit IRC | 09:47 | |
| *** jklare_ has quit IRC | 09:47 | |
| *** sballe_ has quit IRC | 09:47 | |
| *** fungi has quit IRC | 09:47 | |
| *** cFouts has quit IRC | 09:47 | |
| *** russellb has quit IRC | 09:47 | |
| *** mestery_ is now known as mestery | 09:47 | |
| *** gnarld_ has joined #openstack-meeting-cp | 09:48 | |
| *** jklare has joined #openstack-meeting-cp | 09:48 | |
| *** russellb has joined #openstack-meeting-cp | 09:50 | |
| *** sballe_ has joined #openstack-meeting-cp | 09:52 | |
| *** fungi has joined #openstack-meeting-cp | 09:53 | |
| *** sdague has joined #openstack-meeting-cp | 10:04 | |
| *** rpjr_ has joined #openstack-meeting-cp | 10:10 | |
| *** ninag has joined #openstack-meeting-cp | 10:15 | |
| *** rpjr_ has quit IRC | 10:15 | |
| *** ninag has quit IRC | 10:19 | |
| *** sdake_ has joined #openstack-meeting-cp | 10:20 | |
| *** vilobhmm11 has quit IRC | 10:21 | |
| *** sdake has quit IRC | 10:22 | |
| *** nikhil has joined #openstack-meeting-cp | 10:30 | |
| *** nikhil_k has quit IRC | 10:32 | |
| *** openstackstatus has quit IRC | 10:32 | |
| *** dims has quit IRC | 10:33 | |
| *** openstack has joined #openstack-meeting-cp | 11:15 | |
| *** ChanServ sets mode: +o openstack | 11:15 | |
| *** openstack has quit IRC | 11:16 | |
| *** openstack has joined #openstack-meeting-cp | 11:31 | |
| *** ChanServ sets mode: +o openstack | 11:31 | |
| *** tjcocozz has quit IRC | 11:35 | |
| *** EmilienM has quit IRC | 11:36 | |
| *** sdague has quit IRC | 11:37 | |
| *** askb has quit IRC | 11:37 | |
| *** bswartz has quit IRC | 11:37 | |
| *** tjcocozz has joined #openstack-meeting-cp | 11:42 | |
| *** tristanC_ is now known as tristanC | 11:42 | |
| *** Guest38251 has joined #openstack-meeting-cp | 11:46 | |
| *** askb has joined #openstack-meeting-cp | 11:50 | |
| *** sdague has joined #openstack-meeting-cp | 11:51 | |
| *** sdake is now known as sdake_busy_webin | 11:51 | |
| *** Guest38251 has quit IRC | 11:51 | |
| *** _amrith_ is now known as amrith | 11:56 | |
| *** sheel has joined #openstack-meeting-cp | 11:57 | |
| *** EmilienM has joined #openstack-meeting-cp | 12:10 | |
| *** EmilienM is now known as Guest50220 | 12:11 | |
| *** Guest50220 has quit IRC | 12:11 | |
| *** Guest50220 has joined #openstack-meeting-cp | 12:11 | |
| *** Guest50220 is now known as EmilienM | 12:11 | |
| *** automagically has joined #openstack-meeting-cp | 12:16 | |
| *** automagically has quit IRC | 12:21 | |
| *** raildo-afk is now known as raildo | 12:23 | |
| *** xyang1 has joined #openstack-meeting-cp | 12:27 | |
| *** bswartz has joined #openstack-meeting-cp | 12:34 | |
| *** ninag has joined #openstack-meeting-cp | 12:35 | |
| *** amrith is now known as _amrith_ | 12:42 | |
| *** rpjr_ has joined #openstack-meeting-cp | 13:08 | |
| *** sdake has joined #openstack-meeting-cp | 13:10 | |
| *** sdake_busy_webin has quit IRC | 13:12 | |
| *** sdake_ has joined #openstack-meeting-cp | 13:13 | |
| *** sdake has quit IRC | 13:15 | |
| *** sdake_ is now known as sdake | 13:18 | |
| *** sdake is now known as sdake_busy | 13:18 | |
| *** rpjr__ has joined #openstack-meeting-cp | 13:21 | |
| *** rpjr_ has quit IRC | 13:24 | |
| *** automagically has joined #openstack-meeting-cp | 13:28 | |
| *** askb_ has joined #openstack-meeting-cp | 13:30 | |
| *** automagically has left #openstack-meeting-cp | 13:30 | |
| *** vgridnev_ has joined #openstack-meeting-cp | 13:34 | |
| *** sheeprine_ has joined #openstack-meeting-cp | 13:35 | |
| *** ninag has quit IRC | 13:37 | |
| *** ninag has joined #openstack-meeting-cp | 13:38 | |
| *** vgridnev_ has quit IRC | 13:38 | |
| *** ninag_ has joined #openstack-meeting-cp | 13:39 | |
| *** ninag__ has joined #openstack-meeting-cp | 13:40 | |
| *** ninag has quit IRC | 13:42 | |
| *** jklare_ has joined #openstack-meeting-cp | 13:43 | |
| *** dims_ has joined #openstack-meeting-cp | 13:43 | |
| *** askb has quit IRC | 13:43 | |
| *** vgridnev has quit IRC | 13:43 | |
| *** dims has quit IRC | 13:43 | |
| *** jklare has quit IRC | 13:43 | |
| *** sheeprine has quit IRC | 13:43 | |
| *** ninag_ has quit IRC | 13:44 | |
| *** vgridnev has joined #openstack-meeting-cp | 13:44 | |
| *** ninag__ has quit IRC | 13:44 | |
| *** _amrith_ is now known as amrith | 13:44 | |
| *** sigmavirus24_awa is now known as sigmavirus24 | 13:51 | |
| *** sheeprine_ is now known as sheeprine | 13:51 | |
| *** sheeprine has quit IRC | 13:51 | |
| *** sheeprine has joined #openstack-meeting-cp | 13:51 | |
| *** persia has quit IRC | 14:02 | |
| *** sheel has quit IRC | 14:17 | |
| *** rpjr__ has quit IRC | 14:37 | |
| *** rpjr_ has joined #openstack-meeting-cp | 14:38 | |
| *** dims_ has quit IRC | 14:38 | |
| *** dims has joined #openstack-meeting-cp | 14:41 | |
| *** sheel has joined #openstack-meeting-cp | 14:43 | |
| *** jungleboyj has joined #openstack-meeting-cp | 14:50 | |
| *** amrith is now known as _amrith_ | 14:59 | |
| *** sdake_busy has quit IRC | 15:08 | |
| *** sdake has joined #openstack-meeting-cp | 15:17 | |
| *** nikhil has quit IRC | 15:18 | |
| *** nikhil has joined #openstack-meeting-cp | 15:28 | |
| *** nikhil has quit IRC | 15:38 | |
| *** nikhil has joined #openstack-meeting-cp | 15:38 | |
| *** openstack has joined #openstack-meeting-cp | 15:51 | |
| *** ChanServ sets mode: +o openstack | 15:51 | |
| *** sballe_ has joined #openstack-meeting-cp | 15:53 | |
| *** openstack has joined #openstack-meeting-cp | 15:54 | |
| *** ChanServ sets mode: +o openstack | 15:54 | |
| *** ninag has joined #openstack-meeting-cp | 15:54 | |
| *** ninag has quit IRC | 15:55 | |
| *** ninag has joined #openstack-meeting-cp | 15:55 | |
| *** Rocky_g has joined #openstack-meeting-cp | 15:57 | |
| *** Rockyg has quit IRC | 15:57 | |
| *** Rocky_g has quit IRC | 15:58 | |
| *** Rocky_g has joined #openstack-meeting-cp | 15:58 | |
| *** openstack has joined #openstack-meeting-cp | 16:08 | |
| *** ChanServ sets mode: +o openstack | 16:08 | |
| *** sdake_ has joined #openstack-meeting-cp | 16:09 | |
| *** sdake has quit IRC | 16:11 | |
| *** sdake has joined #openstack-meeting-cp | 16:15 | |
| *** sdake_ has quit IRC | 16:17 | |
| *** ninag has joined #openstack-meeting-cp | 16:17 | |
| *** ninag has quit IRC | 16:21 | |
| *** ninag has joined #openstack-meeting-cp | 16:29 | |
| *** _amrith_ is now known as amrith | 16:30 | |
| *** ninag has quit IRC | 16:34 | |
| *** ninag has joined #openstack-meeting-cp | 16:43 | |
| *** ninag has quit IRC | 16:45 | |
| *** thingee has quit IRC | 16:46 | |
| *** ninag has joined #openstack-meeting-cp | 16:46 | |
| *** ninag has quit IRC | 16:46 | |
| *** ninag has joined #openstack-meeting-cp | 16:47 | |
| *** sdake has quit IRC | 16:49 | |
| *** ninag has quit IRC | 16:50 | |
| *** ninag has joined #openstack-meeting-cp | 16:50 | |
| *** ninag has quit IRC | 17:01 | |
| *** ninag has joined #openstack-meeting-cp | 17:12 | |
| *** ninag has quit IRC | 17:13 | |
| *** ninag has joined #openstack-meeting-cp | 17:13 | |
| *** ninag has quit IRC | 17:24 | |
| *** ninag has joined #openstack-meeting-cp | 17:27 | |
| *** ninag_ has joined #openstack-meeting-cp | 17:28 | |
| *** Rockyg has joined #openstack-meeting-cp | 17:28 | |
| *** Rockyg has quit IRC | 17:30 | |
| *** ninag has quit IRC | 17:31 | |
| *** Rockyg has joined #openstack-meeting-cp | 17:31 | |
| *** Rocky_g has quit IRC | 17:31 | |
| *** ninag_ has quit IRC | 17:32 | |
| *** Rocky_g has joined #openstack-meeting-cp | 17:41 | |
| *** Rockyg has quit IRC | 17:45 | |
| *** sheel has quit IRC | 17:54 | |
| *** Rocky_g has quit IRC | 17:55 | |
| *** sdake has joined #openstack-meeting-cp | 17:55 | |
| *** Rockyg has joined #openstack-meeting-cp | 17:56 | |
| *** ildikov has quit IRC | 18:02 | |
| *** persia has joined #openstack-meeting-cp | 18:07 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 18:22 | |
| *** vilobhmm11 has quit IRC | 18:23 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 18:23 | |
| *** Rockyg has quit IRC | 18:26 | |
| *** Rockyg has joined #openstack-meeting-cp | 18:27 | |
| *** vilobhmm11 has quit IRC | 18:27 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 18:28 | |
| *** rpjr has joined #openstack-meeting-cp | 18:38 | |
| *** flaper87 has quit IRC | 18:38 | |
| *** gnarld_ is now known as nug | 18:39 | |
| *** rpjr_ has quit IRC | 18:39 | |
| *** nug is now known as Guest6633 | 18:39 | |
| *** amrith has quit IRC | 18:39 | |
| *** DuncanT has quit IRC | 18:41 | |
| *** ninag has joined #openstack-meeting-cp | 18:42 | |
| *** amrith has joined #openstack-meeting-cp | 18:43 | |
| *** Rockyg has quit IRC | 18:44 | |
| *** Rockyg has joined #openstack-meeting-cp | 18:44 | |
| *** Guest6633 is now known as cFouts | 18:45 | |
| *** ninag_ has joined #openstack-meeting-cp | 18:45 | |
| *** flaper87 has joined #openstack-meeting-cp | 18:45 | |
| *** vilobhmm11 has quit IRC | 18:45 | |
| *** ninag_ has quit IRC | 18:45 | |
| *** ninag_ has joined #openstack-meeting-cp | 18:46 | |
| *** ninag has quit IRC | 18:47 | |
| *** automagically has joined #openstack-meeting-cp | 18:48 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 18:48 | |
| *** ninag_ has quit IRC | 18:48 | |
| *** ninag has joined #openstack-meeting-cp | 18:48 | |
| *** sdake_ has joined #openstack-meeting-cp | 19:01 | |
| *** vilobhmm11 has quit IRC | 19:03 | |
| *** sdake has quit IRC | 19:03 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 19:04 | |
| *** DuncanT has joined #openstack-meeting-cp | 19:04 | |
| *** ildikov has joined #openstack-meeting-cp | 19:13 | |
| *** sdague_ is now known as sdague | 19:42 | |
| *** sdake_ has quit IRC | 19:48 | |
| *** beekhof has quit IRC | 19:48 | |
| *** markvoelker has quit IRC | 19:48 | |
| *** david-lyle has quit IRC | 19:48 | |
| *** redrobot has quit IRC | 19:48 | |
| *** homerp has quit IRC | 19:48 | |
| *** dansmith has quit IRC | 19:48 | |
| *** jokke_ has quit IRC | 19:48 | |
| *** dansmith has joined #openstack-meeting-cp | 19:53 | |
| *** sdake_ has joined #openstack-meeting-cp | 19:58 | |
| *** beekhof has joined #openstack-meeting-cp | 19:58 | |
| *** markvoelker has joined #openstack-meeting-cp | 19:58 | |
| *** david-lyle has joined #openstack-meeting-cp | 19:58 | |
| *** redrobot has joined #openstack-meeting-cp | 19:58 | |
| *** homerp has joined #openstack-meeting-cp | 19:58 | |
| *** jokke_ has joined #openstack-meeting-cp | 19:58 | |
| *** homerp_ has joined #openstack-meeting-cp | 20:02 | |
| *** sdake_ has quit IRC | 20:04 | |
| *** beekhof has quit IRC | 20:04 | |
| *** markvoelker has quit IRC | 20:04 | |
| *** david-lyle has quit IRC | 20:04 | |
| *** redrobot has quit IRC | 20:04 | |
| *** homerp has quit IRC | 20:04 | |
| *** jokke_ has quit IRC | 20:04 | |
| *** david-lyle has joined #openstack-meeting-cp | 20:05 | |
| *** amrith is now known as _amrith_ | 20:09 | |
| *** sdake_ has joined #openstack-meeting-cp | 20:11 | |
| *** beekhof has joined #openstack-meeting-cp | 20:11 | |
| *** markvoelker has joined #openstack-meeting-cp | 20:11 | |
| *** redrobot has joined #openstack-meeting-cp | 20:11 | |
| *** jokke_ has joined #openstack-meeting-cp | 20:11 | |
| *** tyr_ has joined #openstack-meeting-cp | 20:12 | |
| *** sdake has joined #openstack-meeting-cp | 20:12 | |
| *** markvoelker_ has joined #openstack-meeting-cp | 20:14 | |
| *** beekhof has quit IRC | 20:15 | |
| *** markvoelker has quit IRC | 20:15 | |
| *** redrobot has quit IRC | 20:15 | |
| *** jokke_ has quit IRC | 20:15 | |
| *** sdake_ has quit IRC | 20:16 | |
| *** Rockyg has quit IRC | 20:17 | |
| *** jokke_ has joined #openstack-meeting-cp | 20:17 | |
| *** Rockyg has joined #openstack-meeting-cp | 20:17 | |
| *** automagically has quit IRC | 20:23 | |
| *** redrobot has joined #openstack-meeting-cp | 20:23 | |
| *** redrobot is now known as Guest78786 | 20:24 | |
| *** ninag has quit IRC | 20:34 | |
| *** ninag has joined #openstack-meeting-cp | 20:35 | |
| *** ninag_ has joined #openstack-meeting-cp | 20:37 | |
| *** odyssey4me_ has joined #openstack-meeting-cp | 20:38 | |
| *** _amrith_ is now known as amrith | 20:38 | |
| *** ninag has quit IRC | 20:40 | |
| *** tonyb_ has joined #openstack-meeting-cp | 20:41 | |
| *** ninag_ has quit IRC | 20:41 | |
| *** rpjr has quit IRC | 20:42 | |
| *** markvoelker has joined #openstack-meeting-cp | 20:42 | |
| *** hemna_ has joined #openstack-meeting-cp | 20:42 | |
| *** Guest78786 is now known as redrobot | 20:43 | |
| *** lbragstad_ has joined #openstack-meeting-cp | 20:44 | |
| *** jokke_ has quit IRC | 20:47 | |
| *** markvoelker_ has quit IRC | 20:47 | |
| *** jungleboyj has quit IRC | 20:47 | |
| *** russellb has quit IRC | 20:47 | |
| *** harlowja has quit IRC | 20:47 | |
| *** odyssey4me has quit IRC | 20:47 | |
| *** lbragstad has quit IRC | 20:47 | |
| *** hemna has quit IRC | 20:47 | |
| *** tonyb has quit IRC | 20:47 | |
| *** russellb has joined #openstack-meeting-cp | 20:48 | |
| *** jokke_ has joined #openstack-meeting-cp | 20:49 | |
| *** rpjr has joined #openstack-meeting-cp | 20:53 | |
| *** mriedem has joined #openstack-meeting-cp | 20:54 | |
| *** andrearosa_web has joined #openstack-meeting-cp | 20:57 | |
| ildikov | #startmeeting cinder-nova-api-changes | 21:00 |
|---|---|---|
| openstack | Meeting started Wed Apr 13 21:00:06 2016 UTC and is due to finish in 60 minutes. The chair is ildikov. Information about MeetBot at http://wiki.debian.org/MeetBot. | 21:00 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 21:00 |
| *** openstack changes topic to " (Meeting topic: cinder-nova-api-changes)" | 21:00 | |
| openstack | The meeting name has been set to 'cinder_nova_api_changes' | 21:00 |
| mriedem | o/ | 21:00 |
| ildikov | scottda ildikov DuncanT ameade cFouts johnthetubaguy jaypipes takashin alaski e0ne jgriffith tbarron andrearosa hemna erlon mriedem gouthamr ebalduf patrickeast smcginnis diablo_rojo | 21:00 |
| smcginnis | o/ | 21:00 |
| scottda | hi | 21:00 |
| andrearosa_web | hi | 21:00 |
| ildikov | hi | 21:00 |
| *** ninag has joined #openstack-meeting-cp | 21:01 | |
| mriedem | #link etherpad https://etherpad.openstack.org/p/cinder-nova-api-changes | 21:01 |
| hemna_ | hey | 21:01 |
| *** ninag has quit IRC | 21:01 | |
| scottda | if jgriffith Does not show up we shall pile a bunch of work on his plate. | 21:02 |
| ildikov | beyond the topics on the agenda I wonder whether we want to have meeting next week as well | 21:02 |
| *** tyr__ has joined #openstack-meeting-cp | 21:02 | |
| alaski | o/ | 21:02 |
| hemna_ | fwiw, I finished the attach, detach and live migration sequence diagrams | 21:02 |
| scottda | hemna_: Those are great. | 21:02 |
| hemna_ | I also exported them to draw.io editable 'xml' files | 21:02 |
| ildikov | either case maybe we should spend a few seconds on whether we need to prepare with more things than what we already have | 21:02 |
| ildikov | hemna_: diagrams are awesome! | 21:03 |
| hemna_ | so we can edit them as needed later. my gliffy.com account expires in 6 days | 21:03 |
| scottda | hemna_: Did you see my question in Cinder? I'm wondering where we need an update_connector API? | 21:03 |
| hemna_ | yah I saw that | 21:03 |
| hemna_ | I'm not sure honestly | 21:03 |
| scottda | hemna_: It looks to me like we create a new connector from new_host, and delete old one from old_host. | 21:03 |
| hemna_ | the live migration process was always the need for it | 21:03 |
| hemna_ | as the attachment entry is being moved from host-1 to host-2 | 21:04 |
| hemna_ | and hence the connector and hostname would change | 21:04 |
| mriedem | i've got a high level question, | 21:04 |
| scottda | So it is the attachment entry only that needs an update? That makes sense... | 21:04 |
| mriedem | do the connector issues need to be ironed out for the live migration stuff as a prerequisite for multiattach? | 21:04 |
| hemna_ | scottda, yah I think so, and only for making sure the connector and host were updated for force detach. | 21:05 |
| hemna_ | mriedem, I think they are all connected | 21:05 |
| *** angdraug has joined #openstack-meeting-cp | 21:05 | |
| *** tyr_ has quit IRC | 21:05 | |
| *** amrith is now known as _amrith_ | 21:05 | |
| hemna_ | we need to make sure we support getting the correct attachment in initialize_connection for multi-attach | 21:05 |
| ildikov | mriedem: the issue is when you get two attachments on the same host by migrating an instance | 21:05 |
| ildikov | mriedem: in other cases this data is not critical | 21:06 |
| hemna_ | do we need a diagram for swap volume as well ? :( | 21:06 |
| scottda | hemna_: Well, while you are at it.... | 21:06 |
| hemna_ | *sigh* | 21:06 |
| mriedem | so is volume-backed live migration broken today? | 21:06 |
| mriedem | w/o multiattach | 21:06 |
| ildikov | scottda: good answer :) | 21:06 |
| hemna_ | mriedem, for single attach, it's working afaik. | 21:06 |
| mriedem | ok, it should be, we have a gate job for it | 21:07 |
| mriedem | which fails anywhere from 25-75% of the time | 21:07 |
| ildikov | not nice, but I think it's working | 21:07 |
| scottda | mriedem: I couldn't find any bugs associated with live migration and single attach. | 21:07 |
| mriedem | but that's besides the point | 21:07 |
| hemna_ | heh | 21:07 |
| smcginnis | Yeah, other than maybe some specific backend errors, I haven't heard of live migration problems. | 21:07 |
| smcginnis | IIRC, our test team here has done it. | 21:07 |
| hemna_ | I noticed a bunch of bugs related to encrypted volumes :( | 21:07 |
| mriedem | ok, i was trying to see if there was some latent bug with volume-backed live migration which is why it kept coming up | 21:08 |
| hemna_ | but that's another topic.... | 21:08 |
| mriedem | so there are the 4 (really 3) alternatives in the etherpad, | 21:08 |
| *** sdake has quit IRC | 21:08 | |
| mriedem | and it sounds like that's really just 2 and 4 | 21:08 |
| mriedem | they are similar, | 21:08 |
| hemna_ | yah they are | 21:08 |
| ildikov | and the current winner is #2 | 21:09 |
| mriedem | and john would prefer 2 becaues he doesn't want to change reserve_volume to create the attachment in the cinder db | 21:09 |
| mriedem | is that right? | 21:09 |
| ildikov | if no objections from this group either | 21:09 |
| hemna_ | the only thing I an unsure about is how initialize_connection finds the correct attachment | 21:09 |
| hemna_ | for the multi-attach case | 21:09 |
| scottda | mriedem: Yes, that is why he likes #2 over #4 | 21:09 |
| ildikov | hemna_: in same host case or in every? | 21:10 |
| mriedem | so for initialize_connection today we just have the volume id and connector | 21:10 |
| hemna_ | it looks like his changes in initialize_connection he always calls db.volume_attach | 21:11 |
| hemna_ | which creates a new volume_attachment DB table entry | 21:11 |
| hemna_ | :( | 21:11 |
| hemna_ | this is one of the reasons I liked os-reserve returning an attachment_id. | 21:11 |
| mriedem | and with option 4, reserve volume creates the attachment, and nova passes that attachment id to initialize_connection, right? | 21:11 |
| hemna_ | then nova can call initialize_connection with the attachment_id | 21:11 |
| hemna_ | and it's explicit | 21:11 |
| mriedem | and unreserve would delete the attachment? | 21:11 |
| hemna_ | mriedem, yes | 21:12 |
| mriedem | in case attach fails | 21:12 |
| mriedem | what does initialize_connection need to do with the attachment? store the connector info in the vol attachment table? | 21:12 |
| hemna_ | if initialize_connection took attachment_id, then it could also act as an 'update' | 21:12 |
| hemna_ | mriedem, yes | 21:12 |
| hemna_ | it should/needs to store the host and the connector | 21:13 |
| jgriffith | mriedem: well... initialize connection does a lot | 21:13 |
| scottda | hemna_: Yes, that's what i asked about the spec I posted for update_attachment..is it needed if we can use initialize_connection for that.. | 21:13 |
| mriedem | hemna_: the host info is in the connector dict isn't it? | 21:13 |
| hemna_ | mriedem, yah | 21:13 |
| hemna_ | it is | 21:13 |
| hemna_ | scottda, yes | 21:13 |
| hemna_ | sonus, I think w/o multi-attach in the picture, the WIP will have issues w/ live migration | 21:14 |
| mriedem | so let's say we go with #2 and init_connection creates the attachment, what deletes it on failure? | 21:14 |
| scottda | hemna_: yes as in "I hear what you are saying" or yes as in "new api is needed even if initialize_.... can update" | 21:14 |
| *** rpjr_ has joined #openstack-meeting-cp | 21:14 | |
| hemna_ | I hear what you are saying | 21:15 |
| hemna_ | I'm not sure we need the update if we can get update to work inside of initialize_connection | 21:15 |
| scottda | hemna_: Cool. I like that. | 21:15 |
| hemna_ | crap | 21:16 |
| *** jungleboyj has joined #openstack-meeting-cp | 21:16 | |
| hemna_ | so...I left out one thing on the live migration diagram that I have to add in | 21:16 |
| hemna_ | my bad | 21:16 |
| hemna_ | post_live_migration calls initialize_connection, prior to calling terminate_connection. | 21:16 |
| hemna_ | to make sure it has the correct connection_info of the volume on the source n-cpu host. | 21:17 |
| hemna_ | because the bdm has the connection_info for the destination n-cpu host then. | 21:17 |
| *** rpjr has quit IRC | 21:17 | |
| hemna_ | I'll add that in to the diagram. sorry about missing that. | 21:17 |
| hemna_ | it's the one time that nova calls initialize_connection with the intention of only fetching the up to date connection_info for an existing attach | 21:18 |
| mriedem | so what rolls back the attachment that's created in the case that the attach fails? | 21:18 |
| mriedem | for options 2 and 4? | 21:18 |
| hemna_ | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L6831 | 21:18 |
| hemna_ | there | 21:18 |
| scottda | mriedem: Today, there is no rollback | 21:19 |
| hemna_ | correct | 21:19 |
| hemna_ | there is no rollback | 21:19 |
| mriedem | is this the force detach issue? | 21:19 |
| ildikov | hemna_: which still looks weird, but at least we have a diagram to capture that now | 21:19 |
| jgriffith | mriedem: can you describe a failure case? | 21:19 |
| scottda | mriedem: Yes, this is | 21:19 |
| jgriffith | mriedem: *where/when* is the failure you're considering? | 21:19 |
| mriedem | jgriffith: os-attach fails (cinder is down), or nova times out waiting during boot from volume | 21:19 |
| mriedem | let me find the compute manager code quick | 21:20 |
| mriedem | https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L4735 | 21:20 |
| hemna_ | heh if cinder is down, not much we can do | 21:20 |
| mriedem | yeah... | 21:20 |
| mriedem | so ^ is just making the volume available again | 21:20 |
| mriedem | i think | 21:20 |
| hemna_ | yah I think that resets the state | 21:21 |
| jgriffith | mriedem: hemna_ yes it does | 21:21 |
| *** lbragstad_ is now known as lbragstad | 21:21 | |
| jgriffith | hemna_: mriedem except :) | 21:21 |
| jgriffith | your volume is in an error state | 21:21 |
| hemna_ | https://github.com/openstack/cinder/blob/master/cinder/volume/api.py#L581-L588 | 21:21 |
| scottda | and perhaps export to compute host still exists. | 21:22 |
| mriedem | i guess we call terminate_connection before that https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L287 | 21:22 |
| jgriffith | I guess I'm unclear why any of the existing calls would go away? | 21:22 |
| jgriffith | mriedem: exactly | 21:22 |
| jgriffith | mriedem: add a call to terminate | 21:22 |
| mriedem | so if initialize_connection creates the attachment, terminate_connection could delete it | 21:22 |
| mriedem | well, | 21:23 |
| mriedem | nvm that | 21:23 |
| mriedem | you'd have to only delete the attachment on a failure... | 21:23 |
| mriedem | not sure how to signal that | 21:23 |
| hemna_ | terminate_connection should update that attachment and set the volume state to either 'in-use' or 'available' | 21:23 |
| hemna_ | which I think it does | 21:23 |
| scottda | yeah, terminate_conn calls unreserve() | 21:24 |
| mriedem | ok, i guess i was thinking we (nova) could get confused if we needed to check the list of attachments on a volume and there are > 1 but one is actually not attached | 21:24 |
| jgriffith | mriedem: what if you store the attachment ID though? | 21:25 |
| jgriffith | mriedem: ie, dump it in the bdm table | 21:25 |
| mriedem | that was another question, i guess that's a new proposal | 21:25 |
| jgriffith | mriedem: it's actually the "nova" side of the wip I put up | 21:25 |
| ildikov | I wish I would not need to touch bdm | 21:25 |
| hemna_ | jgriffith, +1 | 21:25 |
| mriedem | couldn't the connection_info that's returned from initialize_connection have the attachment id in it? | 21:25 |
| jgriffith | mriedem: it does :) | 21:26 |
| mriedem | the connection_info is already stored in the bdm | 21:26 |
| jgriffith | mriedem: that's my proposal :) | 21:26 |
| ildikov | mriedem: does Nova store connection_info as is? | 21:27 |
| mriedem | and the bdm should be 1:1 with the volume id and instance uuid, which is the same for the attachment right? | 21:27 |
| mriedem | ildikov: yes | 21:28 |
| mriedem | ildikov: https://github.com/openstack/nova/blob/master/nova/virt/block_device.py#L289 | 21:28 |
| hemna_ | mriedem, yes | 21:28 |
| ildikov | mriedem: cool, tnx | 21:28 |
| *** hemna_ is now known as hemna | 21:29 | |
| scottda | mriedem: How's that connection info stored? If we add attachment_id, does the DB table need to change? | 21:29 |
| mriedem | ok, so what does nova do with the attachment id in the bdm.connection_info? | 21:29 |
| mriedem | scottda: nope, just a json blob | 21:29 |
| scottda | cool | 21:29 |
| hemna | mriedem, pass it with terminate_connection | 21:29 |
| mriedem | it's unversioned...which kind of sucks | 21:29 |
| hemna | mriedem, and hopefully with a call to initialize_connection if it has it. | 21:29 |
| jgriffith | mriedem: so that's the thing I would need to figure out next | 21:29 |
| hemna | re: live-migration | 21:30 |
| mriedem | ok, so nova will need to have conditional logic for handling this if it's talking to a new enough cinder to provide the attachment id | 21:30 |
| jgriffith | mriedem: where/how that's stored and mapped to a volume | 21:30 |
| mriedem | and if it's in there, nova can pass it back | 21:30 |
| mriedem | https://github.com/openstack/nova/blob/master/nova/objects/block_device.py#L85 | 21:30 |
| scottda | mriedem: Yes. Some plumbing needed, probably involving the microversion the cinder api supports. | 21:30 |
| mriedem | that's the object field | 21:30 |
| mriedem | ok, so what does the client side check for nova look like wrt nova and new enough cinder? does nova fail if it's asked to attach a multiattach volume but cinder isn't new enough to provide the attachment id from initialize_connection? | 21:31 |
| mriedem | fwiw, nova today can already get the attachment id given the volume id and instance uuid, i think that's what ildikov's code already does | 21:32 |
| jgriffith | mriedem: Yes, IMO | 21:32 |
| scottda | mriedem: Yes, I agree. WE can just say multi-attach will only work with newton+ Cinder and newton+ Nova | 21:32 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 21:32 | |
| mriedem | but w/o checking if cinder is new enough, i guess we don't know that the internal plumbing is new enough to handle the multi-detach on the same host? | 21:32 |
| *** sigmavirus24_awa is now known as sigmavirus24 | 21:32 | |
| ildikov | mriedem: for detach Nova gets the attachment_id from the volume info from Cinder | 21:32 |
| hemna | so the attachment_id has been around for a few releases now with Cinder | 21:33 |
| mriedem | ildikov: yeah but it filters the attachment list from that volume based on the instance uuid | 21:33 |
| mriedem | right? | 21:33 |
| hemna | since I put the multi-attach code in cinder, which was...Kilo ? | 21:33 |
| smcginnis | hemna: Yep | 21:34 |
| ildikov | mriedem: yeap, that's correct | 21:34 |
| scottda | But passing in both instance_uuid and host are not plumbed for Cinder, so cinder would need to be Newton+ for this to work anyway | 21:34 |
| mriedem | scottda: passing in to which cinder API? | 21:34 |
| mriedem | attach? | 21:34 |
| smcginnis | scottda: Well, did we ever revert that change. I think it might still. | 21:34 |
| scottda | initialize_connection | 21:34 |
| mriedem | we pass the connector which has the host... | 21:34 |
| ildikov | mriedem: yes, attach fails with having both in the request | 21:34 |
| jgriffith | scottda: we don't need it though | 21:34 |
| jgriffith | scottda: we already have it on initialize connection, that's been my point all along | 21:35 |
| scottda | jgriffith: We don't need it with your Alt#2, that is correct. | 21:35 |
| jgriffith | scottda: we have it, but we don't do it with anything | 21:35 |
| mriedem | jgriffith: b/c of the connector dict has the host right? | 21:35 |
| jgriffith | mriedem: yes, correct | 21:35 |
| hemna | the connector has always had the host afaik | 21:35 |
| scottda | I'm just saying that, no matter what, Cinder will have to be Newton+ | 21:35 |
| jgriffith | mriedem: the whole thing is kinda silly... we actually have all of the info we just weren't storing it | 21:35 |
| ildikov | scottda: +1 | 21:35 |
| jgriffith | mriedem: then we got into passing it all again in another later call | 21:35 |
| mriedem | jgriffith: and that's why we need to chekc that cinder is newton+ ? | 21:35 |
| scottda | There is no controversy that Newton+ Nova with older Cinder won't have multi-attach. It simply will not work. | 21:35 |
| hemna | I'm just not sure how we find the right attachment in initialize_connection | 21:35 |
| jgriffith | mriedem: yes, that would be the requirement | 21:36 |
| mriedem | jgriffith: ok, i'm finally starting to understand :) | 21:36 |
| smcginnis | scottda: I think it's completely fair to require N+ | 21:36 |
| hemna | because we don't have the instance_uuid at initialize_connection time. | 21:36 |
| ildikov | scottda: attach would work and detach too if it's not same host same target case, but we need to block the happy scenarios too | 21:36 |
| jgriffith | hemna: well... we don't actually have multi-attach yet anyway, so I'd hack some code for that | 21:36 |
| jgriffith | hemna: but, that being said | 21:36 |
| jgriffith | hemna: if you already have a plan/solution I'm happy to turn it over to you | 21:37 |
| hemna | jgriffith, but if we had the attachment_id being passed in to initialize_connection, we would always be able to find the right attachment | 21:37 |
| jgriffith | hemna: ok | 21:37 |
| jgriffith | hemna: go for it | 21:37 |
| ildikov | are going for alternative #4 now? | 21:37 |
| mriedem | hold up, | 21:37 |
| jgriffith | ildikov: looks like it :) | 21:37 |
| hemna | that would work for single attach and multi | 21:37 |
| mriedem | so one issue on the nova side with #4 is, | 21:37 |
| jgriffith | I'm just tired of beating my head against this wall for no reason :) | 21:38 |
| mriedem | nova would have to store the attachment_id in the bdm before we have the connection_info, | 21:38 |
| mriedem | that means a schema change to the nova db | 21:38 |
| jgriffith | mriedem: yes | 21:38 |
| jgriffith | mriedem: and it completely deviates from the purpose of the reserve call | 21:38 |
| hemna | jgriffith, I don't think it's for no reason, we are trying to make sure any changes we make work for single attaches and multi-attach. at least that's what I'm assuming. | 21:38 |
| jgriffith | hemna: I mean no reason from my personal side and usage of time | 21:38 |
| jgriffith | hemna: I believe I can address your concerns, but I don't care enough to continue arguing | 21:39 |
| jgriffith | hemna: if you have code and a proposal that works I say go for it | 21:39 |
| smcginnis | I think mriedem makes a good point. | 21:39 |
| smcginnis | If we can avoid that, it would be good. | 21:39 |
| mriedem | ok, so from a nova perspective, i'm not sure why we need the attachment id when we reserve the volume | 21:39 |
| jgriffith | mriedem: and my point last week was that's *impossible* to do | 21:39 |
| ildikov | smcginnis: I hear ya | 21:39 |
| smcginnis | mriedem: You're saying #2 would be better from the Nova perspective? | 21:39 |
| hemna | mriedem, could fake the connection_info at reserve time (/me shudders) | 21:39 |
| mriedem | smcginnis: it seems cleaner, i'm just thinking it out | 21:40 |
| smcginnis | Yeah, I think so too. | 21:40 |
| mriedem | i'm hearing that nova only needs the attachment id at initialize_connection time to pass it in to that API | 21:40 |
| mriedem | but we could avoid that with just initialize_connection creating the attachment and returning that id in connection_info | 21:40 |
| mriedem | which is then stored in the nova bdm | 21:40 |
| hemna | the attachment_id at initialize_connection time is so cinder can find the right attachment to operate on | 21:40 |
| mriedem | and we can use to pass to cinder terminate_connection | 21:40 |
| mriedem | hemna: but if initialize_connection creates the attachment at that time, then it knows | 21:41 |
| jgriffith | mriedem: you are correct in your statements | 21:41 |
| mriedem | because it just created it | 21:41 |
| smcginnis | hemna: So the issue is that intialize_connection is called repeatedly? | 21:41 |
| hemna | mriedem, but there are calls to initialize_connection that are for existing attachments (re: live-migration) | 21:41 |
| hemna | smcginnis, yes | 21:41 |
| smcginnis | So we only return it if we know we created a new one? | 21:41 |
| hemna | live migration calls initialize_connection again right before it calls terminate_connection | 21:41 |
| smcginnis | mriedem: Or can nova pass it in on subsequent calls? | 21:42 |
| hemna | because the connection_info in the BDM is for the destination n-cpu host and is wrong. | 21:42 |
| ildikov | hemna: can we pass attachment_id to Cinder only these cases? | 21:42 |
| ildikov | hemna: I mean Nova | 21:42 |
| mriedem | ok, so creating the attachment at init_connection doesn't work for when we need to 'update' the original attachment for live migration | 21:42 |
| hemna | but in this case | 21:42 |
| jgriffith | we could fix the live migration code to behave differently once it has attachment ID's | 21:42 |
| hemna | we don't want cinder to update the attachment | 21:42 |
| jgriffith | seems easier than building a house of cards and replumbing every API call | 21:43 |
| hemna | because it will be updating it to the source n-cpu host, which will shortly be detached. | 21:43 |
| mriedem | rather than update the old attachment from the source host, why not create a new attachment table entry for the new host, and then when we're done, delete the old attachment? | 21:43 |
| mriedem | so we don't update, we just create a 2nd and delete the 1st? | 21:43 |
| jgriffith | mriedem: +1 | 21:43 |
| hemna | mriedem, yah I think that's what I was going to suggest | 21:43 |
| hemna | is that we have 2 attachments | 21:43 |
| jgriffith | mriedem: which in fact is what we discussed at the mid-cycles | 21:43 |
| hemna | for live migration | 21:43 |
| smcginnis | mriedem: +1 | 21:44 |
| mriedem | ok, so that seems better from a nova pov | 21:44 |
| mriedem | and is option #2 right? | 21:44 |
| jgriffith | mriedem: hemna my proposal was and is that we treat live-migration as a special case of multi-attach | 21:44 |
| hemna | jgriffith, +1 | 21:44 |
| smcginnis | Because it is multiattached briefly. | 21:44 |
| hemna | yah we had chewed on that in the past | 21:44 |
| hemna | smcginnis, yah it is | 21:44 |
| ildikov | yeah, I remember some stories as well | 21:44 |
| hemna | I'll get the live migration diagram up to date | 21:45 |
| mriedem | i mean, we could do really hacky stuff and pass the instance uuid in the connector dict to initialize_connection if we needed too... | 21:45 |
| mriedem | but i'd like to avoid that if possible | 21:45 |
| hemna | it'll show 2 calls to initialize_connection | 21:45 |
| * jgriffith gathers everybody around the camp fire to tell a tale | 21:45 | |
| hemna | ew yah | 21:45 |
| jgriffith | mriedem: please don't... we'll pay a price later | 21:45 |
| mriedem | just saying :) | 21:45 |
| smcginnis | jgriffith: Got smores? | 21:45 |
| jgriffith | smcginnis: of courrse! | 21:45 |
| mriedem | honestly that doesn't sound different from init_connection adding the attachment id to the connection_info that's returned | 21:45 |
| mriedem | but ok | 21:45 |
| jgriffith | mriedem: wait.... | 21:46 |
| jgriffith | mriedem: let me think about that for a second | 21:46 |
| mriedem | alaski: you might enjoy this part... | 21:46 |
| mriedem | alaski: this is why we have unversioned port details dicts with neutron probably, it opens us up to all sorts of fun hacks :) | 21:47 |
| jgriffith | mriedem: so, it wouldn't be that terrible as a kwarg or something. I'm still not completely sure it's necessary though | 21:47 |
| mriedem | jgriffith: i think cinder would microversion the init_connection response to add the attachment id | 21:47 |
| scottda | mriedem: Yes | 21:47 |
| mriedem | something like that, but nova needs to check the microversion | 21:47 |
| mriedem | ok | 21:47 |
| mriedem | that makes it less of a hack because it signals that there is a new thing in the connection_info response | 21:48 |
| hemna | yah that sounds good | 21:48 |
| mriedem | note that nova can still find the attachment id to pass to terminate connection if it's needed w/o it being stored in the bdm.connection_info | 21:49 |
| jgriffith | mriedem: so circling back to your other statement... | 21:49 |
| jgriffith | mriedem: easy fix, add the instance-id to the connector that we already get | 21:49 |
| jgriffith | mriedem: actually... I think that's already there in some cases | 21:49 |
| mriedem | it might be for vmware i think | 21:49 |
| hemna | ah | 21:50 |
| mriedem | yup https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/volumeops.py#L302 | 21:50 |
| hemna | if we had the instance_uuid in the connector, we can get the correct attachment inside of initialize_connection. | 21:50 |
| mriedem | connector is just another unversioned dict that we pass around | 21:50 |
| jgriffith | mriedem: :) | 21:50 |
| mriedem | hemna: yup | 21:50 |
| hemna | problem solved. | 21:50 |
| scottda | So what problems are left? | 21:51 |
| mriedem | sdague: we're not gauranteed to be able to tell what microversion the volume endpoint is at right? | 21:51 |
| mriedem | because some deployments disable that? | 21:51 |
| mriedem | guaranteed even | 21:51 |
| alaski | mriedem: oh boy. let's please not add unversioned things here | 21:52 |
| scottda | mriedem: you can hit http://<vol_endpoint>:8776/ and get it if cinder is mitaka+ | 21:52 |
| scottda | That's a new Cinder API think in mitaka | 21:52 |
| mriedem | scottda: i think version discovery can be disabled though | 21:52 |
| mriedem | via policy | 21:52 |
| mriedem | we found that out the hard way in adding microversion support to nova client | 21:53 |
| mriedem | b/c rackspace and others had it disabled | 21:53 |
| ildikov | alaski: not adding new things so far | 21:53 |
| scottda | true, I think you are right. | 21:53 |
| alaski | ildikov: okay. I'm trying to catch up here | 21:53 |
| mriedem | so... | 21:54 |
| scottda | So, if you cannot discover Cinder version, you cannot use any new stuffs. I don't think there's any way around that. | 21:54 |
| ildikov | alaski: we are playing with already existing ones in theory atm | 21:54 |
| mriedem | we can avoid unversioned things if cinder adds a microversion to the terminate_connection api such that it takes a new parameter | 21:54 |
| hemna | scottda, but then you always assume the lowest API version no? | 21:54 |
| scottda | Other than ugly try: | 21:54 |
| hemna | mriedem, terminate_connection needs new things? I believe it already supports attachment_id | 21:55 |
| scottda | hemna: You just assume you are on /v2 (and /v3 at version 3.0 is the equivalent) | 21:55 |
| jgriffith | hemna: nah... it gets a connector, but not an AID | 21:55 |
| mriedem | hemna: it does? https://github.com/openstack/python-cinderclient/blob/master/cinderclient/v2/volumes.py#L73 | 21:56 |
| hemna | huh | 21:56 |
| hemna | yah you are right | 21:56 |
| hemna | nm | 21:56 |
| hemna | ignore me. | 21:56 |
| mriedem | so do we need initialize_connection to return the attachment id? i'm not sure that it does | 21:57 |
| mriedem | nova can figure that out by filtering the volume attachments list by instance uuid, | 21:57 |
| hemna | mriedem, I think jgriffith's proposal is that it will, inside the connection_info dict it's already returning. | 21:57 |
| mriedem | or just pass the instance uuid to terminate_connection with a microversion that takes instance uuid as a 3rd parameter | 21:57 |
| mriedem | hemna: but we don't need it, i don't think | 21:58 |
| mriedem | unless it's purely about signaling that we're talking to a version of cinder that has that behavior | 21:58 |
| jgriffith | mriedem: I think either is doable, I had planned to return it | 21:58 |
| mriedem | in which case, that works for me | 21:58 |
| mriedem | if it's not there and multiattach, nova fails | 21:58 |
| *** andrearosa_web has quit IRC | 21:59 | |
| mriedem | it would be nice if the nova api could detect this support earlier in the process though | 21:59 |
| mriedem | which i guess is the version discovery api | 21:59 |
| jgriffith | mriedem: the trick is as you mention the versioning to know if things are actually *in* the table or not. If you solve that via micro-v then so beit | 21:59 |
| jgriffith | mriedem: I'll write an API method "discover-api-version" for you | 21:59 |
| mriedem | #action mriedem to talk to sdague about version discovery | 21:59 |
| mriedem | we've worked around some of this with neutron via their extension list | 22:00 |
| scottda | mriedem: Please keep me in the loop on that conversation | 22:00 |
| jgriffith | honestly it would probably be useful to have said call anyway | 22:00 |
| mriedem | nova checks the neutron extension list to see if we can do a new thing | 22:00 |
| scottda | Since My next cinderclient patch is automatic version discovery. | 22:00 |
| scottda | Yeah, but isn't that because Neutron doesn't have microversions? | 22:01 |
| smcginnis | Gotta run, thanks everyone. | 22:01 |
| mriedem | i think so yeah | 22:01 |
| scottda | I mean, this is the point of microversions. | 22:01 |
| mriedem | i have to head out soon too, | 22:01 |
| scottda | I need to head as well. | 22:01 |
| mriedem | so are we in soft agreement on option 2 | 22:01 |
| mriedem | init connection returns the attachment id in the connection_info | 22:01 |
| mriedem | nova passes the instance uuid or attachment id to terminate_connection | 22:01 |
| scottda | ildikov: I think we might as well keep open a meeting for next week. Just for discussing details and other items. | 22:02 |
| mriedem | and we have a todo to talk to sdague about version discovery | 22:02 |
| mriedem | ^ sound good? | 22:02 |
| *** sigmavirus24 is now known as sigmavirus24_awa | 22:02 | |
| ildikov | scottda: sure, I'll check back on Monday and send out a reminder mail as well if we feel the need | 22:02 |
| smcginnis | +1 | 22:02 |
| scottda | mriedem: yes | 22:02 |
| hemna | mriedem, nova pass the instance_uuid to initialize_connection as well ? | 22:02 |
| ildikov | mriedem: +1 | 22:02 |
| *** sdake has joined #openstack-meeting-cp | 22:02 | |
| hemna | so cinder can find the right attachment | 22:02 |
| hemna | (for multi-attach) | 22:02 |
| mriedem | hemna: not sure that is needed | 22:02 |
| hemna | it is | 22:02 |
| mriedem | then sure :) | 22:03 |
| hemna | ok | 22:03 |
| hemna | +A | 22:03 |
| mriedem | i'll assume you guys are updating the etherpad | 22:03 |
| mriedem | and gals | 22:03 |
| scottda | #action scottda update etherpad with this meeting's conclusions | 22:04 |
| mriedem | if we pass a new parameter to initialize_connection and it explodes, we'll know we're not talking to a new enough cinder | 22:04 |
| mriedem | ^ in the case that we can't detect the version ahead of time | 22:04 |
| hemna | #action hemna updates the live-migration sequence diagram to include the initialize_connection call in post_live_migration() time. | 22:04 |
| scottda | mriedem: True enough. or if we don't detect the version, just don't try and assume old behaviour, which is no multi-attcach and don't pass it in. | 22:05 |
| mriedem | yeah, fast fail in the api | 22:05 |
| scottda | OK, I need to run as well. Thanks everyone | 22:05 |
| mriedem | yup, thanks | 22:05 |
| ildikov | thanks guys | 22:05 |
| *** mriedem has quit IRC | 22:06 | |
| ildikov | #endmeeting | 22:06 |
| *** openstack changes topic to "OpenStack Meetings || https://wiki.openstack.org/wiki/Meetings" | 22:06 | |
| openstack | Meeting ended Wed Apr 13 22:06:38 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 22:06 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-04-13-21.00.html | 22:06 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-04-13-21.00.txt | 22:06 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/cinder_nova_api_changes/2016/cinder_nova_api_changes.2016-04-13-21.00.log.html | 22:06 |
| *** harlowja has joined #openstack-meeting-cp | 22:07 | |
| *** mriedem1 has joined #openstack-meeting-cp | 22:12 | |
| *** vilobhmm11 has quit IRC | 22:14 | |
| *** vilobhmm11 has joined #openstack-meeting-cp | 22:14 | |
| *** mriedem1 has quit IRC | 22:18 | |
| *** raildo is now known as raildo-afk | 22:19 | |
| *** hemna is now known as hemnafk | 22:30 | |
| *** tonyb_ is now known as tonyb | 22:30 | |
| *** vilobhmm111 has joined #openstack-meeting-cp | 22:42 | |
| *** vilobhmm11 has quit IRC | 22:44 | |
| *** sdake has quit IRC | 22:48 | |
| *** jungleboyj has quit IRC | 22:52 | |
| *** sdake has joined #openstack-meeting-cp | 23:00 | |
| *** angdraug has quit IRC | 23:12 | |
| *** xyang1 has quit IRC | 23:13 | |
| *** angdraug has joined #openstack-meeting-cp | 23:25 | |
| *** sdague has quit IRC | 23:25 | |
| *** angdraug has quit IRC | 23:27 | |
| *** tyr__ has quit IRC | 23:55 | |
| *** rpjr has joined #openstack-meeting-cp | 23:55 | |
| *** rpjr_ has quit IRC | 23:57 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!