16:00:36 #startmeeting Cinder 16:00:37 Meeting started Wed May 31 16:00:36 2017 UTC and is due to finish in 60 minutes. The chair is smcginnis. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:38 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:41 The meeting name has been set to 'cinder' 16:00:53 ping dulek duncant eharney geguileo winston-d e0ne jungleboyj jgriffith thingee smcginnis hemna xyang1 tbarron scottda erlon rhedlind jbernard _alastor_ bluex karthikp_ patrickeast dongwenjuan JaniceLee cFouts Thelo vivekd adrianofr mtanino karlamrhein diablo_rojo jay.xu jgregor lhx_ baumann rajinir wilson-l reduxio wanghao thrawn01 chris_morrell watanabe.isao,tommylikehu mdovgal ildikov wxy 16:00:56 o/ 16:00:57 hi 16:00:59 viks ketonne abishop sivn breitz 16:00:59 Hi 16:01:00 hi 16:01:00 <_alastor_> \o 16:01:00 Hello :) 16:01:03 hi 16:01:04 o/ 16:01:17 .o/ 16:01:20 o/ 16:01:22 o/ 16:01:47 hi 16:01:47 Hey everyone 16:02:20 #topic Announcements 16:02:24 hi 16:02:28 hi 16:02:31 hi! 16:02:34 hola compadres 16:02:37 #info Pike-2 is next week 16:03:01 We have a few driver reviews out there and a few specs that need attention before the cutoff. 16:03:28 Please try to spend a little time on that if at all possible. 16:03:49 #topic DocImpact and docs bugs 16:04:04 Been seeing this a lot so I wanted to bring it up here. 16:04:23 Patches only need DocImpact tags if they need follow up documentation updates to openstack-manuals. 16:04:43 And it is up to the patch submitter to do that work or get it to the right person to make the docs change. 16:04:44 smcginnis: from my perspective, I prefer to assign these bugs to patch authors or close them 16:04:47 hi) 16:05:07 We have a bunch of open docs bugs that are autoamtically generated from commits of these DocImpact patches that are just sitting out there. 16:05:17 e0ne: Yep, that is how it should work 16:05:40 But for a lot of them, it doesn't appear the patch authors know or care to do anything with them. 16:05:53 :( 16:06:03 smcginnis: So, I assume we still need them for config changes right. 16:06:08 Which either means there wasn't really a DocImpact, or they think the magic documentation fairies will just take care of everything. 16:06:08 hi 16:06:10 Even if they come with a release note. 16:06:30 jungleboyj: If there is an additional change to documentation that is needed. 16:06:31 He he. Magic Documentation Fairies 16:06:38 smcginnis: Ok. 16:07:34 Most config options automatically get generated in the tables. So unless there is something more to document about them, there's not really a doc impact. 16:07:55 #link https://bugs.launchpad.net/cinder/+bugs?field.tag=doc 16:08:06 Would love to see those implemented or closed. ^ 16:08:35 #topic Additional options to NFS backend 16:08:36 smcginnis: in such case, we have to be attentive during review such patches 16:08:47 smcginnis: Ah, thank you. The info about them be auto generated is helpful. 16:08:54 jsuchome: Sorry, one second then it's all yours. :) 16:09:17 * jsuchome can wait :-) 16:09:19 e0ne: Attentive in what way? 16:09:28 smcginnis what about the config guide/docs? 16:09:48 smcginnis: to not add docimpact flag if only release notes are needed 16:09:57 e0ne: +1 16:10:10 e0ne: That was why I was asking. :-) 16:10:12 smcginnis for example. https://docs.openstack.org/mitaka/config-reference/block-storage/drivers/solidfire-volume-driver.html 16:10:19 I may have been an offender there. 16:10:52 jgriffith: The config pages that just list a table of the config options will be automatically updated. But if you want to add text describing how it should be used or any notes, then that should have the DocImpact and follow up docs submission. 16:10:56 :) 16:11:02 smcginnis: I will try to look through the list of docs bugs and see which ones can maybe just be closed or are easy fixes. 16:11:09 smcginnis excellent, thanks :) 16:11:12 * jungleboyj did say I would be the docs liaison 16:11:24 jsuchome: OK, sorry about that. The floor is yours. 16:11:29 I was unaware we got that automated now :) 16:11:38 jgriffith: +1 16:12:06 although... nope it's not. But I'll look at that offline 16:12:16 I basically wanted to ask, what's the correct way of providing extra NFS options to cinder backend - documentation seems to mention 2 ways 16:12:46 did you see the ML reply from eharney? 16:12:47 also the cinder code is using both (cinder.nfs_mount_options, option in the file cinder.nfs_shares_config) 16:12:51 which documentation are you looking at? i'd like to see if it looks correct 16:12:58 hello 16:13:22 oh, there was a reply? let me check 16:13:37 jsuchome: cinder.nfs_shares_config is only used if there isn't an IP of a nas server in cinder.conf . 16:13:43 I've linked the documentation links in my mail 16:14:24 is used, or is supposed to be used? 16:14:43 i'll look at updating the config-reference/block-storage docs, i think they need to be revamped a bit 16:14:47 this piece of code https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L163 takes whatever is written there and passes it further as the optiobns 16:14:50 for the nfs driver 16:15:19 eharney: Agreed. I don't thinks those were ever updated after I changed the way that nfs_shares_config is or is not used. 16:15:37 Speaking of NFS, CI jobs have been failing for awhile now. 16:15:57 eharney: ok, so you're saying putting options into nfs_shares_config config should be obsolere 16:15:59 smcginnis: :-( 16:16:03 but what about nova? 16:16:32 jsuchome: Nova will mount the export with the info that Cinder provides it, i believe 16:16:46 when volume is being attached, nova knows about the options that were in nfs_shares_config, but not about nfs_mount_options 16:17:08 exactly, but Cinder does not provide those from nfs_mount_options 16:17:12 at least not in my tests 16:17:19 so this might be a bug 16:17:37 nfs_mount_options should only be used if nfs_shares_config is not being used. 16:17:53 Let me look here. 16:18:06 well, there's definitely nothing in the code that prevents such usage 16:19:29 If I remember correctly, if nas_host and nas_share_path are specified it should not use nfs_shares_config . 16:19:36 correct 16:19:38 Then the nfs_mount_options will be used. 16:19:47 i'm not sure about that 16:20:07 eharney: I am pretty sure I have set that up. 16:20:09 there's nas_mount_options and nfs_mount_options -- i think that's true for nas_mount_options, not sure about the other 16:20:16 I don't think I used nas_mount_options 16:20:36 I would have to go try it again to be sure though. 16:20:37 at any rate it looks like we need to re-evaluate the config for this driver and polish it up a bit 16:20:55 eharney: ++ and make sure the documentation matches 16:21:01 eharney +1 16:21:39 And fix the CI problem. :) 16:22:01 * eharney looks to see what the CI problem is 16:22:02 jsuchome: Anything else? 16:22:07 In fact, I know the nas_host/nas_share_path isn't documented properly as I have gone and looked for that in the documentation and couldn't find it. 16:22:17 so should I file a bug report that nfs_mount_options are not passed to nova? 16:22:40 jsuchome: Can you make the bug more generic? 16:23:12 I thought nas_mount_options were preferred over using nfs_mount_options 16:23:18 smcginnis: oh, the compute service policy is still messed up 16:23:42 eharney: Oh, right. 16:23:43 jsuchome: NFS config options not documented/working as expected and indicate that the nfs_shares_config isn't used as documented and that it doesn't appear nfs_mount_options are passed along. 16:23:51 cFouts: i think so, but we can sort that out in a thorough review in the bug 16:23:53 I think I haven 16:24:06 eharney: and I can use it to get things cleaned up. 16:24:09 jungleboyj: ok, that sounds good, I'll do it 16:24:26 eharney: smcginnis Are you guys ok with that plan? 16:24:35 jungleboyj: +1 from me. 16:24:43 Coolio 16:24:45 sure, i'll help sort out what the end goal should be here and help figure out the details 16:25:07 we need to start issuing deprecation messages for nfs_shares_config if we aren't already, and aim at getting rid of it, this transition started quite a while ago 16:25:23 (but yes, nas options seem to have higher priority: https://github.com/openstack/cinder/blob/stable/newton/cinder/volume/drivers/nfs.py#L99 , not that it is relevant to my case) 16:25:41 jungleboyj, Coolio with his gangsta's paradise? :D 16:26:01 the nas_* options have higher priority because the goal was to have the same options for a handful of similar drivers called nas_* rather than having numerous duplicated options 16:26:40 * jungleboyj keeps spending most my life, Livin' in a gangsta's paradise 16:27:30 eharney: ++ 16:27:49 Sounds like we have a plan. Good to move on? 16:27:55 I'm good 16:28:00 Move along. Nothing to see here. 16:28:09 #action jungleboyj to work on bug report from jsuchome 16:28:14 #topic Recruiting awesome Block-Heads to help with fuxi-golang 16:28:27 jgriffith: fuxit 16:28:32 LOL 16:29:05 So not sure how many people are already aware... but fuxi is a kuryr project that has provided a means to plug Cinder into a Docker environment 16:29:07 smcginnis: That is fuxed up. 16:29:09 jgriffith: I don't know what is fuxi-golang, but I'm interesting in everything related to standalone 16:29:23 similar to the cinder-docker-volume-plugin stuff 16:29:29 it's pronounced Foo She 16:29:43 jgriffith: I'll be glad to help you with it 16:29:43 Not in my head. ;) 16:29:43 now, I know that there are several of us here that are doing Docker and K8's work on the side 16:29:48 smcginnis +1 :) 16:29:54 smcginnis: :D 16:30:09 With the foundation for stand-alone cinder and some other things going on 16:30:26 the idea is to consolidate the efforts just like in Neutron we did with Kuryr 16:30:40 (fuxi also enables manila shares to be accessible as Docker vols) 16:30:46 I am hoping it might be a good time to take another shot at building a community around some of this work, inparticular fooshi (I'll just spell it that way to keep jungleboyj under control) 16:30:56 children!! 16:31:04 jgriffith: Hey know. I can be good. 16:31:11 jgriffith, don't ruin our fun. 16:31:12 jungleboyj no you can't :) 16:31:26 jgriffith: Ok, you are right. 16:31:39 so there's efforts underway to make cinder and manilla usable as standalone components in K8s 16:32:11 jgriffith: isn't there already a cinder driver in K8s? 16:32:24 but there are also some base layers that we kinda need, like a cinder-volume-plugin and most importantly a version of os-brick that we can port to a golang pkg 16:32:27 xyang: you mean the cloud provider? 16:32:32 xyang yes as the cloud-provider 16:32:56 xyang work is also underway to make a standalone cinder and manila option as well 16:33:01 ie bare-metal with cinder/manila 16:33:16 apuimedo, jgriffith: ok, I didn't realize that's different from this effort 16:33:27 jgriffith: I was asked about golang version of os-brick from by k8s community too 16:33:32 anyway... what I'm trying to gauge is is there enough interest in Cinder members to help out with this? 16:33:33 xyang: the idea is to support baremetal as well, yes 16:33:42 side by side k8s and openstack is a big use case 16:33:52 apuimedo: ok, thanks 16:33:56 you're welcome 16:34:03 rather than continue to fragment, it would be kinda cool if we all pitched in a bit 16:34:04 e0ne: interesting 16:34:09 * dims peeks 16:34:09 hongbin: is starting gos-brick 16:34:12 it's really not that much work to be honest 16:34:18 'g' standing for golang 16:34:33 gos means dog in my language, so I approve of the anem 16:34:35 *name 16:34:42 but if everybody continues to do their own thing it just means more fragmentation 16:34:49 apuimedo: Hah! 16:34:54 jgriffith: +1 16:34:56 * jgriffith gives up 16:35:22 jgriffith: It wouyld be great to start this topic in openstack-dev@ too 16:35:30 so the goal would be to get a strong core team for the fuxi effort from cinder folks 16:35:32 e0ne can do 16:35:35 and to build this together 16:35:42 jgriffith: The repo is started for gos-brick. Once we start getting some code ported over there, I think that's a good first area folks can help contrubute to. 16:36:02 apuimedo: +1 16:36:03 so I'm curious... anybody here interested (I mean seriously interested, not just "oh that's neat")? 16:36:05 smcginnis, jgriffith: can you share a link, please? 16:36:21 jgriffith: I'm interesting in it 16:36:27 We already have a golang version of Cinder-volumem plugin here: https://github.com/j-griffith/cinder-docker-driver 16:36:39 e0ne: This repo was just created: https://github.com/openstack/gos-brick 16:36:40 just need to update, openstackify it and create a brick pkg 16:36:43 jgriffith: and even can find time for this activity :) 16:36:44 So no code yet. 16:36:58 smcginnis: thanks 16:37:12 honestly, shouldn't we have it all under a single repo and just seperate pkgs? 16:37:25 jgriffith: I think you mentioned as well to have the fuxi flavored options 16:37:31 smcginnis: does it mean that Foundation officially accept golang? 16:37:40 e0ne yes 16:37:47 I remember that mail thread bout goland and swift 16:37:51 e0ne : working towards it. yes. (TC not foundation) 16:37:57 Foundation was never the detracting opinion 16:37:58 TC 16:38:08 dims +1 16:38:09 jgriffith: The advantage I see in having it separate would be if there would end up being other go based projects needing to do something with it. 16:38:10 jgriffith: Yeah, having different repos seems more complicated. 16:38:10 dims, jgriffith: cool, thanks! 16:38:47 e0ne: https://governance.openstack.org/tc/resolutions/20170329-golang-use-case.html 16:38:56 smcginnis fair, TBH though go lets you stuff multiple pkgs in a single rep and pull just what you want, but I don't have a strong enough feeling on this to worry about it :) 16:39:24 jgriffith: True. I guess it's just a difference between go and python we're not really used ot. 16:39:27 *to 16:39:36 smcginnis ok... so forget that part, more important part here is level of interest from folks like _alastor_ patrickeast xyang e0ne geguileo etc 16:39:51 although xyang might have some political things around that 16:40:09 jgriffith: nothing political:) 16:40:11 :) 16:40:14 smcginnis I arleady have your vote :) 16:40:15 :) 16:40:16 jgriffith: I'd probably be interested if I had any time :-( 16:40:32 geguileo: You don't! :P 16:40:44 somebody create another clone of geguileo :) 16:41:06 :) 16:41:10 yes, please!! 16:41:22 jgriffith: I'm interested, just can't tell you how much time I can spend on it yet 16:41:29 So to be clear, we'd need some work on the fuxi parts, but more importantly IMO is starting to make sure we put some effort into the stand-alone cinder model 16:41:41 * jungleboyj creates a work item for geguileo cloning 16:41:47 geguileo: I'm waiting for your blog post about pros and cons on how to be cloned 16:41:48 rofl 16:41:55 jgriffith: Good point. There are a few efforts here that all need to come together. 16:42:04 smcginnis right 16:42:28 the big question is if there's enough interest from cinder team to get to the end result to begin with 16:42:30 jgriffith: can you expand on the 'stand-alone cinder model'? 16:42:56 if there is, I can start working on documenting/outlining the things I think are needed 16:43:05 jgriffith: I hope, the answer from the most of us will be 'yes' 16:43:12 jgriffith: So I think there's enough interest. For now, let's just try to do periodic updates in the Cinder meeting to keep the awareness up and folks can jump in when/where they can. 16:43:13 apuimedo are you familiar with stand-alone cinder? 16:43:21 or is that the question :) 16:43:25 jgriffith: feel free to ask me if anuy help is needed 16:43:28 I know we have interest. 16:43:36 jgriffith: isn't it just cinder without keystone? 16:43:38 jgriffith: +1 for documenting a plan. 16:43:40 smcginnis +1 16:43:50 apuimedo it's cinder with/without keystone and without nova 16:43:51 apuimedo: w/o keystone and w/o nova too 16:43:57 that's the bare-metal piece I mentioned 16:44:02 or triple-o 16:44:11 or *insert-your-consumer-here* 16:44:16 jgriffith: ok. Similar to what we do with Kuryr, just that we keep Keystone practically always 16:44:30 apuimedo yeah, there are good reasons to keep keystone :) 16:44:49 comfort being a big one 16:45:01 apuimedo: the main point of stanalone cinder was to make it work without nova 16:45:22 e0ne: then it is the same goal fuxi and kuryr have 16:45:32 (fuxi for cinder and manila, kuryr for neutron) 16:45:33 apuimedo: cool 16:45:43 we started with baremetal 16:45:49 ++ apuimedo 16:45:51 so I think there's a lot of value in this, not only for all of us with storage devices, but also for Cinder as a community and for customers 16:45:53 now we support also things like Pods inside VMs 16:46:07 jgriffith: +1 16:46:14 apuimedo +1 16:46:45 jgriffith: +1 16:47:08 so just to be clear, what this means is that anything that *works* in Cinder, works in container environments 16:47:26 and it's backed by the community, rather than a single vendor/company 16:47:39 Big +1 16:47:46 +2:) 16:47:48 How we do this in kuryr is that we have a repo for the base stuff and then we have repos for integrations. With Golang you'd probably 'vendor' the base component 16:48:16 apuimedo vendor as in glide or godeps you mean? 16:48:21 * jgriffith is confused 16:48:31 apuimedo OH! 16:48:37 No... cinder's different 16:48:43 godeps 16:48:57 we don't have external *things* with cinder 16:49:06 jgriffith: I meant things like gos-brick 16:49:13 apuimedo ahh! Yes, ok 16:49:45 and if we come up with subset functionality that can be used both by docker and by k8s integrations, it's also a candidate 16:50:09 alright, well at least we seem to have a few people here interested 16:50:18 (depends on whether people are interested in using the docker volume api for the k8s integration or prefer a more runtime agnostic approach really) 16:50:22 jgriffith: A good start. 16:50:26 maybe start some work and communications and get things rolling? 16:50:40 jgriffith: Sounds like a good plan to me. 16:50:58 late to the party, but im definitely interested... combines all my latest.. uh.. hobbies 16:51:20 patrickeast phewww... I needed at least you or _alastor_ before feeling warm and fuzzy 16:51:29 jgriffith: so, if I took my notes right, the action items are to send a message about this to the ML 16:51:30 :) 16:51:34 haha 16:51:40 and then coordinate with zengchen to make a core team 16:51:48 (and hongbin for the gos-brick) 16:52:31 apuimedo I suppose that's needed... or just start hacking and see where we go 16:52:38 earn core 16:52:54 jgriffith: we need a starting team with good CInder knowledge 16:53:06 otherwise I'll have to review too many things I'm not good at 16:53:09 apuimedo yep, we have myself, smcginnis patrickeast e0ne and maybe xyang 16:53:12 I wish I could be of more help, but my extent of storage knowledge ends at nfs and lvm 16:53:15 off to a pretty good start :) 16:53:15 xD 16:53:28 great! 16:53:33 apuimedo: That is all you need. ;-) 16:53:34 need to figure out if manila folks are interested or not 16:53:50 jgriffith: you are not afraid that I'll reject things for political reasons?:) 16:53:52 jungleboyj +1 16:53:58 xyang never! 16:53:59 :) 16:54:03 :) 16:54:05 jgriffith : smcginnis : apuimedo : please post the outline to -dev@ this sounds like great start 16:54:08 jgriffith: indeed. We should reach out as well. I know the huawei guys want manila since they already have it in 16:54:14 dims will do 16:54:20 I'll take that action item 16:54:26 but getting manila cores involved would be the best 16:54:31 thank jgriffith 16:54:32 thanks jgriffith 16:54:35 #action jgriffith outline plan/steps and send to ML 16:54:42 that trick never works 16:54:47 :-) 16:54:47 putting this on the manila weekly meeting agenda would make sense 16:54:50 jgriffith: Hah! 16:55:19 We have tbarron here - what more do we need? :) 16:55:29 OK, 5 minutes. Anything else? 16:55:41 I've got one - any thoughts on updating cinderclient so it defaults to API v3? 16:55:45 tbarron: :-) 16:55:56 #topic Open discussion 16:56:16 abishop: I thought we should wait at least another cycle. 16:56:56 Just to make sure v3 has a little more time to actually make it out there. 16:57:00 smcginnis, I thought v2 was reported as deprecated 16:57:04 What horrible thing is going on with iscsi? 16:57:19 abishop: Yes, as of Pike. 16:57:47 abishop: But the client is used for existing deployments too, so I think we're kind in a weird interim spot right now. 16:57:57 smcginnis, so if v2 is deprecated, not sure why cinderclient shouldn't move on to v3 16:58:24 abishop: Well, if you want go ahead and propose a change. We can see what other folks have to say about it. 16:58:32 I'm not really sure what the best answer is. 16:58:45 smcginnis, will do and see how it flies 16:58:54 abishop: Sounds good. :) 16:59:15 OK, thanks everyone. 16:59:22 #endmeeting