15:13:53 #startmeeting Gluster Community Meeting 15:13:53 Meeting started Wed Jun 21 15:13:53 2017 UTC. The chair is kkeithley. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:13:53 Useful Commands: #action #agreed #halp #info #idea #link #topic. 15:13:53 The meeting name has been set to 'gluster_community_meeting' 15:14:12 #topic roll call 15:14:16 who is here 15:14:47 here 15:15:20 * kkeithley wonders where ndevos went 15:15:49 oh, yes! I'm here 15:16:08 here 15:16:31 * kkeithley wonders where amye is 15:17:12 hmm, with this turnout I wonder if it's really worth continuing 15:17:41 amar has an item on the agenda, but he's missing too? 15:18:22 indeed 15:18:54 maybe we can just go through the AI's that are listed? 15:19:21 #topic AIs from last meeting 15:19:27 ndevos will check with Eric Harney about the Openstack Gluster efforts 15:19:30 * shyam is here now! 15:20:07 oh, yes, that is still a todo - but more about finding a community member that would be willing to setup the test jobs 15:20:18 and JoeJulian will share his conversations with Eric Harney 15:20:24 he did! 15:20:55 oh, okay 15:21:23 how about jdarcy will work with nigelb to make the infra for reverts easier 15:21:24 I cant find the email in the archives though :-( 15:21:50 no idea, is nigelb still around? 15:22:16 rightl 15:22:44 and certainly no joy for nigelb will document kkeithley’s build process for glusterfs packages 15:23:57 hmm :-/ 15:24:26 okay, well, we'll leave all those AIs open for next week then. 15:24:45 yeah, I guess so... 15:25:12 Is anyone here to talk about Test cases contribution from community 15:25:15 ? 15:25:29 I guess that's more of the Eric Harney stuff? 15:25:53 not sure, there are little details about it in the agenda 15:26:36 the Eric Harney topic is for OpenStack Cinder test cases, I would expect this to be broader 15:26:53 shyam: any status on 4.0 or 3.12? 15:27:08 Nothing new other than what is in the page 15:27:19 I will send out a nag for feature status as soon as 3.11.1 is tagged 15:27:55 ndevos: If I had even the slightest idea what was needed wrt the cinder topic I could decide whether or not I had the time to donate to that need. 15:28:06 EH won't answer. 15:29:10 JoeJulian: we'll need ot hook-up Jenkins with the openstack cinder Gerrit, so that each patch can get tested (with some Tempest configuration that uses a Gluster backend) 15:30:16 That doesn't sound too hard. Are there enough gluster owned resources for that? 15:31:10 JoeJulian: we can run it in the CentOS CI, that should have more than enough resources - its just people's time that is missing 15:32:57 I'll try to find some more links and details about it later this week or the next (just got back from 3 weeks travelling) 15:33:08 anything else to say on this topic? 15:33:22 I dont think so 15:33:56 #topic related projects 15:34:17 nfs-ganesha 2.5.0 GA'd last week or so 15:34:23 anything else of note? 15:34:58 gluster-swift is still a tough project to get in upstream distributions :-/ 15:35:45 because? 15:36:24 because it has a lot of OpenStack dependencies that are not part of Fedora or can easily be consumed by repositories in the CentOS Storage SIG 15:37:22 OpenStack is a very fast moving target, too fast for Fedora, it also makes maintaining gluster-swift a recurring excersise 15:38:16 not providing a good upstreamable project makes it more difficult to get adoption in the Gluster community (or elsewhere) 15:39:06 the recurring suggestions to look into other projects are Ceph RGW and Scalidity s3-server 15:39:14 what ever happened to the idea of getting a good pluggable framework that would minimize what gluster-swift would need to add? 15:39:25 (and I'm not even alone anymore in suggesting the 1st :D) 15:40:08 What about the Minio S3 server that FreeNAS uses? 15:40:09 There's also Harsha's project, minio. 15:40:46 it seems that OpenStack Swift does not like dropping all of its functionality to be replaced by gluster-swift - and the Swift3 layer on top of OpenStack Swift is not easily extendable either 15:41:05 Wow, you make it sound so foreign, kkeithley. :D 15:41:27 really? o_O 15:41:31 yes, FreeNAS seems to use minio, but that does not have many features that we're looking for 15:41:47 ndevos: i'm curious :D what problems are you running with swift? 15:42:05 what features do we need that Minio doesn't support? 15:42:45 kkeithley: minio does not do multi-tenancy, it needs different servers for each tenant (from what people tell me) 15:42:59 Minio is AB and Harsha. I'm sure some Gluster love exists there that could be expanded upon. 15:43:49 tdasilva: I understood that user/group management is different in Swift vs S3, and that Swift3 can not handle it without issues 15:44:40 tdasilva: there are also other features that Swift does not provide but S3 users expect, something with bucket verioning and lifecycle stuff iirc 15:45:00 *bucket versioning 15:45:34 ndevos: user/group mgmt is typically handled by auth mechanism, no? like keystone? I think bucket versioning is on the plans, lifecycle is a lot more difficult :/ 15:46:09 minio was definitely one of the projects that some of us looked at, but it was deemed too far away from the features that we've got asked to provide 15:46:10 ndevos: swift recently added a new bucket versioning mode to more closely match with S3s, so now the work needs to be done on the swift3 side 15:47:16 what's the best guess for when that would get done? 15:47:44 tdasilva: Ram/Venkata has been trying to get in touch with the swift3 developers, but he was not very successfull... not sure how well swift3 is maintained 15:47:54 kkeithley: honestly, I don't know... 15:48:11 ndevos: #openstack-swift is a good place to find them 15:48:19 look for timburke and kota 15:48:38 tdasilva: I expect he tried there, but I'll pass it along, thanks! 15:48:40 and I'd be glad to help too :) 15:48:59 heh, of course, and ppai is assisting too 15:49:21 We could also invite harsha to the next community meeting to see if there's any thing he can add regarding minio. 15:49:43 would you like an AI for that? 15:49:46 Sure 15:49:52 kkeithley: https://review.openstack.org/#/q/status:open+project:openstack/swift3,n,z 15:50:11 I'll have to check who was looking at minio and see if they got in touch with the developers 15:50:18 kkeithley: there's definetely versioning work going on, bunch of patches that needs reviews... 15:50:21 #action JoeJulian to invite Harsha to next community meeting to discuss Minio 15:50:49 #info https://review.openstack.org/#/q/status:open+project:openstack/swift3,n,z 15:50:57 #info there's definetely versioning work going on, bunch of patches that needs reviews... 15:51:00 kkeithley: The infra for reverts is done btw. 15:51:10 (sorry, I forgot we had a meeting today) 15:51:30 #info The infra for simplified reverts is done btw. 15:52:06 any other thoughts on S3/Swift? 15:52:36 not from me, not at the moment at least :) 15:52:38 nigelb: any other infra updates? 15:53:06 we're planning for a gerrit upgrade on Monday. 15:53:10 Minor version upgrade 15:53:16 2.12.2 -> 2.12.7 15:53:29 Not expected to cause major problems. 15:54:32 #topic open floor 15:54:38 anything else on anyone's mind? 15:54:49 This has been bouncing around in my head for a bit. 15:55:01 I wanted to get 3.8.13 released today, but I'll do it tomorrow 15:55:14 It's probably going to be controvertial, but I recommend we move all our docs to reference Centos as our preferred deployment platform. 15:55:28 Considering Fedora's release cycles, nobody is expected to run a production glusterfs setup on it. 15:55:39 Thoughts? 15:55:59 I wasn't aware that we recommended anything at all about anything. 15:56:26 I.e. it's free software, no warrantee, etc. 15:56:36 I was wondering about that too, I didnt think we recommended a certain distribution at all? 15:56:42 We sort of do. 15:56:44 And we sort of don't. 15:56:59 Our docs often refer to a mix of Fedora and CentOS. 15:57:18 Which looks a bit problematic because we refer to Fedora 18 in some places. 15:57:27 lol 15:57:42 great way to make the documentation go out of date in 6 months :) 15:57:43 maybe we have examples that say "this is how you do it on Fedora" 15:57:44 much of the docs is out-of-date... 15:57:55 Yes, there's an effort to fix that. 15:58:06 I thought we had an effort underway to scrub the downstream docs and use them instead? 15:58:13 I sort of want to introduce this idea as a step in direction. 15:58:21 That's just for the admin guide. 15:58:27 (I believe) 15:58:49 But we'll still be ahead of the downstream docs in terms of features 15:59:13 I'm just a little biased, but I dont object to see pointers to the CentOS Storage SIG packages *everywhere* :D 15:59:21 Anyway, the point I'm trying to make is - By actually basing our docs on CentOS, we have a distinct advantage. 15:59:30 We run glusto tests agianst centos. 15:59:32 We know it works. 15:59:40 +1 for CentOS as the recommendation or possibly the prime platform for testing etc. (which it already is) 15:59:51 So if the tests break, we know the docs need fixing. 16:00:07 at least the bits that are tested can be continually updated. 16:00:16 CentOs Storage SIG for the packages not so much, considering the delay in packages appearing there... (sorry ndevos :) ) 16:00:21 IMO (IMHO) we need to be careful to avoid the appearance of recommending anything 16:00:38 I have a solution for the delay in packages, but I need some time to prep before I give you hope of that, ndevos 16:00:50 (I could just run glusto against the SIG pre-release packages) 16:01:15 kkeithley: The problem with that is we're in a state where our docs sort of don't work on anything. 16:01:35 If we say, we're going to make sure it works on one platform, at least we can consistently give a good UX. 16:01:35 yeah, if there are some automated tests against the packages, I'm happy to mark them for release quicker - now testing is only manual, and mainly by me whenever I have time 16:01:36 kkeithley: Well yes, but used in all the examples in our documentation (this is how you would do X if it was CentOS and find a way in your favorite distro.) 16:02:23 right, we can say things like "this is how to configure, e.g. for sytemd on CentOS. 16:02:30 Yes ^^^^ 16:02:37 Exactly, what I'm trying to say. 16:02:42 No, "We prefer you use CentOS" 16:02:44 But don't say "we recommend CentOS (because it's what we use here)" 16:02:53 "recommend" is probably too strong, just using CentOS in all examples would be good - and still allow contributors to extend the docs for other distributions 16:02:56 "We're using CentOS as our example" 16:03:02 kkeithley: agreed 16:03:23 at the very least, everything we claim in our docs should work on CentOS. 16:03:34 Write instructions for what you know. If the community wants more, the community should provide. 16:03:36 nigelb. Yes, that's fine 16:04:12 My primary motivation is so we can write tests that match our doc expectation. 16:04:34 sounds good to me 16:06:07 okay, we're over the hour. (even though we started 15 minutes late) 16:06:13 anything else? 16:06:43 * ndevos does not have more 16:06:49 motion to adjourn? 16:06:54 going once? 16:07:02 going twice? 16:07:14 #endmeeting