16:00:47 #startmeeting cinder 16:00:48 Meeting started Wed Mar 13 16:00:47 2019 UTC and is due to finish in 60 minutes. The chair is jungleboyj. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:51 The meeting name has been set to 'cinder' 16:00:57 hi! o/ 16:01:11 hi o/ 16:01:14 hey o/ 16:01:16 courtesy ping: jungleboyj diablo_rojo, diablo_rojo_phon, rajinir tbarron xyang xyang1 e0ne gouthamr thingee erlon tpsilva ganso patrickeast tommylikehu eharney geguileo smcginnis lhx_ lhx__ aspiers jgriffith moshele hwalsh felipemonteiro lpetrut lseki _alastor_ whoami-rajat yikun rosmaita enriquetaso hemna _hemna 16:01:18 hello. 16:01:21 \o 16:01:22 doink 16:01:24 hi 16:01:25 Hi 16:01:29 o/ 16:01:35 @! 16:01:35 <_pewp_> jungleboyj (¬_¬)ノ 16:01:36 o/ 16:02:20 Hi 16:03:52 Ok. Looks like we are getting a good crowd here. 16:04:05 #topic announcements 16:04:50 #link https://etherpad.openstack.org/p/cinder-stein-meetings 16:04:52 We have passed Milestone-3 for Stein so we should now be focusing on testing Stein and fixing bugs. 16:05:00 rosmaita: Thank you. 16:06:22 Any questions about that? 16:07:06 Also, I did submit my candidacy for PTL again. 16:07:20 \o/ 16:07:27 :-) 16:07:52 Didn't look like anyone else submitted a nomination. 16:08:02 So, thanks for the continued vote of confidence? 16:08:13 jungleboyj: congratulations. :) 16:08:26 jungleboyj: thanks for your hard work 16:09:04 You are welcome. Doing my best. 16:09:44 Ok, so I think we can move on from that. 16:10:38 #topic Cinder RSD driver status update 16:10:43 davidsha: 16:10:53 #link https://review.openstack.org/621465 16:11:59 Hi, We have had the CI running for almost a month now and it appears to be stable, we were wondering were there any additional requirements we need to meet before submissions are accepted again? 16:13:18 are we trying to merge the rsd driver for this release? 16:13:19 or next? 16:13:23 Just looking at the CI results. 16:13:25 seems a bit late ? 16:13:25 Train 16:13:26 hemna_: Next. 16:13:30 ok 16:13:38 The test results look good I think. 16:13:57 Will need eharney to verify eventually but he is not here. 16:14:47 Need to have smcginnis add your CI to the list of CIs we are monitoring. 16:15:31 ack 16:15:46 So, I think all-in-all we are looking good to merge early in Train. 16:15:55 Need to do a review of it still. 16:16:54 As far as the merge date is concerned it can merge once we have done the RC for Stein and have opened Train for development. 16:17:29 perfect! 16:18:00 Thank you for your patience and for the update. 16:18:48 no prob, thanks for reviews (past and future). 16:18:59 davidsha: Welcome. Anything else? 16:19:12 Nope, thanks! 16:19:33 davidsha: Are you able to stick around? We have a discussion on os-brick that may impact you. 16:19:43 Ya, sure 16:19:49 Cool. Thanks. 16:20:25 #topic cinder - os-brick (driver-connector) gaps 16:20:31 whoami-rajat: All your's. 16:21:40 Just wanted to bring to everyone's awareness that we merged a rebranding patch of scaleio -> vxflexos in os-brick but it's dependent patches for nova and cinder were blocked due to feature freeze 16:22:30 whoami-rajat: But we are reverting those patches so we shouldn't have a gap there anymore. Correct? 16:23:02 the discussion regarding this led to the conclusion that driver name changes doesn't need change in protocol or connection_properties (simply no change required in os-brick) 16:23:11 jungleboyj: right. 16:24:02 also i feel like to mention the sync should be maintained so as to avoid these type of reverts in future IMHO. 16:24:32 whoami-rajat: Yes, agreed. I think this has been an learning experience for all of us. 16:24:55 Now that hemna_ has been more active again he was able to come in and catch our mistake. 16:25:08 I'm kinda here 16:25:13 jungleboyj: may i query my concern regarding RSD driver? 16:25:44 hemna_: all thanks for fixing it so quickly :) 16:25:49 So, first, I just want to make sure that we have the issues with scaleio resolved. 16:25:55 there are lots of problems associated with rebranding the protocol string 16:26:16 whoami-rajat: Has the patch for Nova been updated as well? 16:26:19 jungleboyj: https://review.openstack.org/#/c/643092/1 just this one is remaining. 16:26:44 jungleboyj: unrelated to rebranding but during revert we also reverted this fix. 16:27:10 jungleboyj: checking 16:27:18 whoami-rajat: Ok. Thanks for pointing that out. So we also need to get that merged before we cut a new release. 16:27:46 jungleboyj: i think this needs to be abandoned https://review.openstack.org/#/c/634866/ . 16:27:59 but hemna_ already left a comment there regarding the same so its good. 16:28:27 yah that nova patch shouldn't land 16:29:22 Ok. Good. 16:29:34 So, I think we can move on to the questions about the RSD Connector. 16:30:17 #topic Concerns with the RSD connector 16:30:33 hemna_: since you abandoned your change regarding removing the nvmeof connector name, why are we still keeping it? 16:30:51 url? 16:31:16 https://review.openstack.org/#/c/642860/ 16:31:19 why are we keeping what? 16:31:35 I'm not clear what you are asking sorry 16:31:36 whoami-rajat: That was abandoned. 16:31:49 I abandoned that one yesterday 16:31:53 initiator name* 16:32:05 so there is some confusion here 16:32:32 Right. 16:32:33 the protocol name returned by initialize_connection calls is how nova looks up which connector to use in os-brcik 16:32:57 the nova nvmeof libvirt volume driver had hard coded to use the nvme connector in os-brick 16:33:06 because there wasn't one for nvmeof 16:33:23 right 16:33:28 so the patch to add the nvmeof support in os-brick is actually ok 16:33:44 but we should eventually update nova to use the nvmeof connector in os-brick 16:34:00 the problem is that we have 2 protocols pointing to the same connector 16:34:09 hemna_: but there isn't a connector for nvmeof 16:34:11 which creates confusion from an os-brick side of things 16:34:19 correct 16:34:41 so I think we need to put some comments about it in code to explain. it sux0rs 16:34:50 I'm not sure we can remove the nvme protocol mapping 16:35:09 once a protocol is in os-brick I don't think it can ever be removed safely 16:35:21 hemna_: so we can update nova to use protocol name (that is nvmeof returned by cinder) rather than hardcoded NVME initiator name then we can rename the connector in os-brick? 16:35:33 re: detaching a volume that's been attached would fail 16:35:45 whoami-rajat:yah 16:35:59 whoami-rajat: But can we rename the connector in os-brick? 16:36:11 Don't we have to keep nvme and nvmeof now. 16:36:16 sure, as long as the mapping is updated too 16:36:23 the mapping has to stay 16:36:41 Oh, but we can change the connector and just update the mapping. 16:37:08 and by mapping, I mean this: https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connector.py#L122-L125 16:37:31 #link https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connector.py#L122-L125 16:37:44 would there ever be a reason to have nvme vs nvmeof connectors? 16:37:50 * hemna_ is nvme illiterate 16:38:04 * jungleboyj looks at davidsha 16:38:10 Do you guys know more here or e0ne 16:38:37 just so I'm clear, this is updating the nvme connector to nvmeof and also keeping nvme to support backwards compatibility? 16:38:44 honestly, I don't remember why do we have two connectors 16:38:46 if all we are doing is renaming NVMeConnector to NVMeOFConnector, then I'm not sure what the point of that would be 16:39:05 hemna_: nvmeof is the cloud version of nvme protocol i think. same as SCSI and iSCSI 16:39:15 err 16:39:29 SCSI and iSCSI are 2 totally different things, not sure that's a good analogy 16:39:40 anyway, os-brick actually only has 1 connector 16:39:49 that supports both the nvme and nvmeof protocol mappings 16:39:55 so I don't think os-brick needs to change 16:40:19 what is confusing is that cinder drivers are returning 'nvmeof' to nova (initialize_connection) 16:40:29 and nova says....hey, I'll use nvme connector in os-brick 16:40:35 because nvmeof doesn't exist....or didn't. 16:40:57 so, shit os-brick with the mapping as is 16:41:19 hemna_: i meant the relation between SCSI and iSCSI. 16:41:21 then next release, update nova to use the initiator.NVMEOF constant when constructing the connector. 16:41:23 that's it. 16:41:44 or not, either way it works 16:41:47 Oh, ship os-brick as is. 16:41:49 it's just confusing 16:42:01 * jungleboyj was trying to process that. 16:42:03 Oh, thats meant to be ship 16:42:08 jungleboyj:yah I don't see the point in renaming the connector object itself 16:42:29 davidsha: Yes. I thought he was just really pissed about os-brick's state. 16:42:31 unless we are simply trying to align everything with nvmeof 16:42:51 Do we have anyone who is an nvmeof expert? 16:43:28 jungleboyj: I'll ask Intel and Mellanox team who worked on nvmeof 16:44:16 So, actually, as I am looking around here, I don't know that whoami-rajat 's analogy is wrong. 16:44:53 NVME is the name for the protocol to talk to the hardware while NVMEoF is like iSCSI where it can be accessed remotely over the network. 16:45:04 #link https://storpool.com/blog/demystifying-what-is-nvmeof 16:45:23 So, we really should never have let the NVME protocol patch merge. 16:46:14 We can't fix that though, because it has been out in the wild for some time now. 16:46:16 we've got SPDK drivere with: pool["storage_protocol"] = 'NVMe-oF' 16:46:39 NVMe was developed for SSD's since AHCI was too slow for them, so we have NVMeoF as a TCP/IP alternative of iSCSI. 16:46:54 whoami-rajat: Right. 16:47:33 So, to be truly correct the NVME drivers should use NVMEoF for the connector. 16:47:41 so the protocol that I'm talking about is what is returned as part of initialize_connection 16:47:56 the protocol is actually the contents of the driver_volume_type 16:47:58 https://github.com/openstack/cinder/blob/master/cinder/volume/targets/nvmeof.py#L63 16:48:22 not the capabilities as being reported by get_volume_stats() 16:48:24 #link https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/spdk.py#L109 16:48:26 hemna_: And that is correct. 16:48:40 2 completely different unrelated things 16:49:11 the driver_volume_type field is sent to nova/os-brick to lookup the correct connector object to handle the connect/disconnect calls for a volume 16:50:13 hemna_: oh, yeah different context. 16:50:38 So, it would seem to me that what you are saying hemna_ is right. Really os-brick should changed to have an NVMeoFConnector and the mappings should be updated and we will have to leave the NVME mapping for backwards compatibility. 16:51:15 I can rename the connector if so desired 16:51:17 that's easy 16:51:22 but not sure the value of it 16:51:28 So nvme would be removed for the V or X release then? 16:51:33 other than consistency in the code 16:51:38 davidsha:no 16:51:41 we can't remove it 16:51:41 In the future when new protocols come along we should better understand them before merging. 16:51:54 kk, understood 16:52:06 the mapping from nvme will have to exist forever 16:52:08 hemna_: i think lack of consistency created a lot of confusion currently. 16:52:14 but it'll just point to the nvmeof connector 16:52:21 whoami-rajat:yah I agree 16:52:45 whoami-rajat: ++ 16:52:51 ok, so I'll put up a review to rename the NVMeConnector to NVMeOFConnector 16:53:09 And we should add a note here https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connector.py#L122-L125 16:53:14 Explaining why the two mappings. 16:53:20 sure 16:53:30 hemna_: That, however doesn't need to go in to os-brick 2.8.1 . 16:53:45 yah, it's not a critical change 16:53:50 it works as is now 16:54:03 once the nova code is changed, we can remove the NVME initiator right? 16:54:05 Ok. Good. I feel I better understand the situation now. 16:54:14 whoami-rajat: No. 16:54:32 nova isn't the only service that uses os-brick 16:54:37 cinder does too 16:54:54 whoami-rajat: We can't be guaranteed that some other consumer isn't using NVME. 16:55:07 as does the cinderclient with the brick extension (for bare metal attaches) 16:55:07 hemna_: and we're using NVME initiator in spdk only? 16:55:28 spdk uses nvmeof protocol afaik 16:55:52 hemna_: for copy_image_to_volume and copy_volume_to_image 16:55:57 also, it's possible that we can have an old nova (using nvme) with a newer os-brick 16:56:08 #action hemna_ To update NVMeConnector to NVMeOFConnector and add notes on why there are two mappings. 16:56:54 So, I think we should wrap this up and can finish discussion in channel if necessary. 16:57:00 hemna_: could you ask Nova to put a cap on the version of os-brick it uses in the stable branches? 16:57:09 coolio, now that everyone is completely confused :) 16:57:13 geguileo: Also wanted to cover a topic. 16:57:24 hemna_: I think we are less confused? 16:57:43 are you sure you are not confused about being confused? 16:57:54 :P 16:57:54 hemna_: :-p 16:57:55 hemna_: lol 16:58:06 geguileo: Are you around? 16:58:10 jungleboyj: yup 16:58:21 #topic cinderlib update 16:58:26 You have 2 minutes. 16:58:36 Next week is the RC1 target week, and for Cinderlib we need to add the publish-to-pypi job 16:58:38 #link https://review.openstack.org/643013 16:59:02 I've also found some bugs in cinderlib 16:59:13 It would be great to these 4 fixes in the repo: 16:59:14 #link https://review.openstack.org/643015 16:59:16 #link https://review.openstack.org/643016 16:59:18 #link https://review.openstack.org/643017 16:59:20 #link https://review.openstack.org/643018 16:59:28 And less urgent would be the devstack patch, that will allow us to add cinderlib's functional tests to Cinder jobs: 16:59:29 #link https://review.openstack.org/643014 16:59:39 Ok. 16:59:43 Aaaan we have 20 seconds left 16:59:45 XD 16:59:51 Yay! 17:00:07 Ok. Thanks for the update. Will take a look at your patches. 17:00:12 thanks! 17:00:18 And time is up. 17:00:37 I will be watching the os-brick patches and pushing up a new release as soon as everything has merged. 17:00:46 sweet 17:00:49 Sorry for the mess there and thanks to everyone for the help. 17:01:13 If there are more items to discuss. Lets talk in the CInder channel. 17:01:16 Thanks! 17:01:20 thanks ! 17:01:22 #endmeeting