16:00:42 #startmeeting ironic_bfv 16:00:42 Meeting started Thu Mar 23 16:00:42 2017 UTC and is due to finish in 60 minutes. The chair is TheJulia. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:45 o/ 16:00:45 The meeting name has been set to 'ironic_bfv' 16:00:46 o/ 16:00:52 o/ 16:00:53 Good morning everyone 16:00:57 \o 16:01:45 Our agenda for this week, which is minimal (You folks know your welcome to edit it right?) :) 16:01:47 #link https://wiki.openstack.org/wiki/Meetings/Ironic-BFV 16:01:49 o/ 16:02:29 #topic Announcements/Reminders 16:02:45 As mentioned last week, I created an etherpad for tracking the items related to BFV. 16:03:07 #link https://etherpad.openstack.org/p/Ironic-BFV 16:03:28 Any other items for announcement? 16:03:30 thank Julia! it made things easier 16:03:34 o/ 16:04:00 please make sure the etherpad is linked from the main whiteboard 16:04:41 #action TheJulia to check/update links for etherpads 16:04:48 dtantsur: I think I already had, but just in case ^^^ :) 16:04:59 Moving on.... 16:05:23 #topic Current Status 16:05:53 dtantsur, TheJulia : it is in subtem status section under BFV 16:06:21 Looks like joanna has updated the cinder common interface revision, but hit an unrelated ci failure. 16:06:33 Yes, I requested recheck. 16:06:57 haven't had a lot of time this week to investigate devstack this week :( but planning to make time for it this week, so don't have much of a status 16:07:13 Depending patches will need to be updated too, probably it will take some time due to similar issue in tests as in cinder api 16:07:14 mjturek: Awesome, thank you 16:07:34 joanna: sorry :( 16:08:05 hshiina: Have you had time to look into moving connection document logic out of nova, due in part to the need for the ip address? 16:08:50 i read nova code. it seems difficult to move all logic to ironic. 16:08:50 TheJulia: no problem at all, don't worry 16:09:00 #info mjturek will try to look at devstack stuffs next week. 16:09:23 hshiina: Seems like we should take that topic to discussion then. 16:09:51 now, i updated nova patch to get ip address in nova side by calling vif attach API before creating connection information. 16:09:58 joanna: Are you going to begin updating the dependent patches? If you already said you were going to, I didn't pick up on it 16:10:10 I will :) 16:10:23 hshiina: That... might... just... work 16:10:35 I just wanted to give everyone heads up that it won't be within next couple of hours :) 16:10:46 #info joanna to continue to update the ironic in-tree revisions. 16:10:50 joanna: Awesome 16:11:04 So shall we move on? 16:11:52 + 16:12:03 sure 16:12:20 #topic Planning/Priorities 16:13:03 I don't think we have anything to really discuss here, so if anyone has anything then awesome, otherwise, I'll just move us onward to discussion 16:14:09 * TheJulia hears crickets 16:14:44 #topic Discussion 16:15:37 I have one item. Mario left a review yesterday with a question on what is a desired/best behavior in attach_volumes if one attachment fails 16:16:25 joanna: imho, attachment should fail, power-on should be prevented 16:16:37 currently it will raise an exception and leave the cleanup responsibility to the caller (which is fine as detach_volumes can take the same list as a param) 16:17:42 his concern was, if we're attaching 10 volumes and only 1 fails... I think that it's good to fail, since we shouldn't deliver half-desired outcome 16:17:44 I think it is fine for the caller to do the clean-up, is the thought to have the common code handle all of the failure cleanup? 16:18:25 hshiina: It looks like your uploaded patchset doesn't merge, perhaps time to rebase the nova patchset? 16:18:53 TheJulia: you said the move of connection document logic was only in part needed for the IP problem (which if I'm understanding, was solved by hshiina's current solution?). What else was it required for? 16:19:05 TheJulia: no, caller already does that in other patch, I answered that to Mario in my reply. The thing was rather about failing all attachments in case of 1 failure 16:19:27 mjturek: Mac addresses, although I'm not sure that is a hard requirement. 16:19:31 i guess the nova conflict is caused by Depend-on: ironic api patch, which has a conflict. 16:19:32 given examples where failing volume is a 1st one and a 10th one. But detach will handle both cases. 16:19:36 ahh 16:19:57 mjturek: possibly worth digging into the the common cinder drivers to see what they "really" want for their connection parameters 16:20:13 TheJulia: It looks like we agree on that. I will leave it as-is, with excepion being raised no matter which volume failed 16:20:17 TheJulia: yeah sounds like a good path 16:20:57 Anyone want to volunteer to skim the cinder drivers to see if they care about/want a mac address? 16:21:13 o/ 16:21:24 sounds interesting to me 16:21:44 #info mjturek volunteers to skim through the cinder drivers to validate if they want/need mac addresses in their connection information. 16:21:51 mjturek: awesome 16:21:55 thanks TheJulia 16:22:05 hshiina: going back to the depends-on, that would do it. 16:22:34 So there is only one other item in my head right now. If there are no objections, I'm just going merge discussion/open discussion on the agenda. 16:23:01 yeah sounds good 16:23:11 i agree 16:23:33 Awesome! 16:23:42 Anything else this week? 16:24:52 i'm good 16:25:03 i'm good too :) 16:25:18 i'm good 16:25:20 Excellent! Thank you everyone! 16:25:30 Have a wonderful rest of the week and talk to you next week! 16:25:39 #endmeeting