15:30:05 <lalatenduM> #startmeeting StorageSIG 15:30:05 <centbot> Meeting started Fri Feb 20 15:30:05 2015 UTC. The chair is lalatenduM. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:30:05 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 15:30:18 <lalatenduM> #topic rollcall 15:30:22 <lalatenduM> JustinClift, :) 15:30:34 <JustinClift> :) 15:30:37 <lalatenduM> who are all here for storage sig meeting? 15:30:48 <lalatenduM> #chair JustinClift 15:30:48 <centbot> Current chairs: JustinClift lalatenduM 15:30:48 <bvanassche> I'm present. 15:30:58 <lalatenduM> #chair bvanassche 15:30:58 <centbot> Current chairs: JustinClift bvanassche lalatenduM 15:31:20 <lalatenduM> looks like kbsingh is not around 15:31:52 <lalatenduM> #topic Action items from last meeting 15:32:06 <lalatenduM> lalatenduM to document the process of pkg building and moving them to storage sig repos 15:32:28 <lalatenduM> I have not done this .Will do this week 15:32:34 <lalatenduM> #action lalatenduM to document the process of pkg building and moving them to storage sig repos 15:32:35 <JustinClift> Side question: Is there an etherpad for this meeting? 15:32:56 <lalatenduM> JustinClift, nope 15:33:02 <JustinClift> bvanassche: Sorry I missed you FOSDEM :/ 15:33:09 <JustinClift> lalatenduM: np 15:33:31 <bvanassche> My fault - I missed FOSDEM ... 15:33:32 <lalatenduM> you can refer the meeting minutes from last meeting 15:33:36 <JustinClift> np 15:33:52 <lalatenduM> JustinClift, http://www.centos.org/minutes/2015/january/centos-devel.2015-01-23-15.31.txt 15:34:15 <lalatenduM> next action item 15:34:16 <lalatenduM> billings to try out reimzul's way of kmod building and yum priorities stuff for openafs repo 15:34:43 <lalatenduM> looks like billings are not around 15:34:50 <lalatenduM> s/are/is/ 15:35:02 <JustinClift> Tx :) 15:35:11 <lalatenduM> but I think he did try few things in cbs 15:35:27 <lalatenduM> lets carry it to next week 15:35:32 <lalatenduM> #action billings to try out reimzul's way of kmod building and yum priorities stuff for openafs repo 15:35:43 <lalatenduM> alphacc to validate the storage7 koji targets and setup new tags as needed for openafs 15:36:04 <lalatenduM> alphacc hey, are you around? 15:36:20 * kbsingh is here now 15:36:24 <lalatenduM> #action alphacc to validate the storage7 koji targets and setup new tags as needed for openafs 15:36:30 <lalatenduM> #chair kbsingh 15:36:30 <centbot> Current chairs: JustinClift bvanassche kbsingh lalatenduM 15:36:49 <lalatenduM> lalatenduM and billings will discuss about the current targets and tags for storage sig 15:36:59 <lalatenduM> have not done this too 15:37:04 <lalatenduM> #action lalatenduM and billings will discuss about the current targets and tags for storage sig 15:37:17 <lalatenduM> kbsingh to see if openafs is GPL compatible or not 15:37:44 <lalatenduM> kbsingh, do you have any update on this? 15:37:51 <kbsingh> there is an ongoing thread on that, its not been closed off at this point 15:38:08 <kbsingh> i believe the userland code is all ok - the management stuff as well, the issue seems to mostly be centered around the origin of the kernel modules 15:38:14 <lalatenduM> kbsingh, cool, should we carry it to next meeting? 15:38:54 <kbsingh> yup 15:39:04 <kbsingh> i might not make it for the next friday meeting, but lets keep this pending 15:39:15 <lalatenduM> kbsingh, yeah IMO "origin of the kernel modules" would be the area to look at 15:39:35 <lalatenduM> #action kbsingh to see if openafs is GPL compatible or not 15:39:55 <lalatenduM> #action lalatenduM will help deason to get standard policy or guidance on packaging selinux rules 15:40:30 <lalatenduM> I am waiting for deason , never got a chance to talk to him about it 15:40:58 <lalatenduM> moving to the next one 15:41:02 <lalatenduM> #alphacc to give cbs access to scuttlemonkey refer https://bugs.centos.org/view.php?id=8095 15:41:09 <kbsingh> can some of these things just goto the centos-devel list and get thrashed around there ? 15:41:23 <kbsingh> i suspect quite a few of these bits are going to have implications for other projects / sigs as well 15:42:00 <lalatenduM> kbsingh, selinux rules? 15:42:09 <kbsingh> yea 15:42:20 <lalatenduM> kbsingh, yeah make sense 15:42:54 <lalatenduM> #action lalatenduM to start a discussion in centos-devel around standard policy or guidance on packaging selinux rules 15:43:10 <lalatenduM> lalatenduM going to send a mail to centos devel and gluster MLs abt glusterfs test repo availability 15:43:15 <lalatenduM> this done 15:43:20 <lalatenduM> this is done* 15:43:40 <lalatenduM> #topic status-updates 15:43:52 <lalatenduM> #topic GlusterFS 15:44:14 <lalatenduM> we have builds in testing repos 15:44:35 <lalatenduM> we got community feedback also 15:44:50 <lalatenduM> like keeping the debug packages in the repo 15:45:05 <lalatenduM> kbsingh, any suggestion on fixing this 15:46:39 <lalatenduM> Also in devconf I met a RH engineer , who is interested to package glusterfs-hadoop plugin for storage SIG 15:47:02 <lalatenduM> as GlusterFS can act a replacement for HDFS 15:47:07 <kbsingh> the debugs should be easy, the script that scrapes up the repo from cbs and moves it to buildlogs can match debugs as well 15:47:26 <lalatenduM> kbsingh, cool 15:47:45 <kbsingh> it does not do this right now, but we can make it do that - the debug's typically have the same buildstamp as the srpm that is spit out from the rpmbuild process, so its not hard to match exact debugs even when multiple builds have taken place 15:48:10 <kbsingh> the user facing side of this is to get a <repo>-debug setup in the .repo's ( via the release file ) that then has the debug packages. 15:48:16 <kbsingh> i guess thats also easily done 15:48:51 <lalatenduM> kbsingh, both sound fine to me 15:49:02 <lalatenduM> JustinClift, bvanassche any suggestion ? 15:49:14 <lalatenduM> hchiramm, are you around? 15:49:36 <bvanassche> For SCST we will use DKMS. 15:49:56 <kbsingh> how would that gluserfs-hadoop thing work?is that just a srpm in addition to the gluster main one ? or will that just be a component that drops out of the existing gluster one 15:50:08 * JustinClift reads back 15:50:13 <JustinClift> Sorry, was doing admin stuff for Gluster 15:50:16 <kbsingh> bvanassche: kmod's not an option ? 15:50:20 <bvanassche> This means that only the source code is present in the RPM and that binary kernel modules are built every time a kernel version is booted that has not yet been booted before. 15:50:52 <bvanassche> Some SCST kernel modules (ib_srpt, the SRP target driver) uses the RDMA API. Unfortunately the RDMA API is not in the RHEL kABI. 15:51:29 <kbsingh> bvanassche: thats ok, you dont need to use the KABI, the kmod's can map to a specific kernel as needed 15:52:16 <bvanassche> Agreed. But then we would have to invent a system to automatically build new SCST RPMs every time a kernel update is released. 15:52:29 <kbsingh> only saying this as the dkms regime never caught on with the wider centos ecosystem - lots of people disliked having the gcc toolchain with all the build components on server nodes 15:52:33 <JustinClift> That should be scriptable shouldn't it? 15:52:42 <kbsingh> bvanassche: we are 'inventing' that already for openafs 15:52:47 <lalatenduM> JustinClift, yes 15:53:25 <lalatenduM> kbsingh, glusterfs-hadoop is another srpm in addition to the gluster main one 15:53:28 <bvanassche> If such an infrastructure is already being built for openafs then I think we could use that too. 15:53:47 <kbsingh> lalatenduM: cool, so then ask the person to request acces via the bugs.c.o interface, and you can add their name once they actually do something to the SIG wiki page 15:53:49 <bvanassche> It would be an advantage if users do not need gcc on every system. 15:53:58 * JustinClift nods 15:54:21 <JustinClift> "Remove compiler" is often a step of systems that get hardened 15:54:45 <kbsingh> bvanassche: there are 3 parts to the overall solution - (1) the kmod itself (2) isolating the user from getting a distro kernel while the scst kernel module isnt ready / tested (3) syncing delivery in a way that kmod's can coexist in kernel space, so if the user boots any of the installed kernels, they still get the functionality 15:55:25 <kbsingh> bvanassche: the (2) part is going to need some level of support from yum itself, and its the bit that is being designed / coded up 15:55:28 <bvanassche> An SCST kmod only contains kernel modules and no core kernel changes. 15:55:39 <JustinClift> kbsingh: yum plugiin? 15:55:44 <kbsingh> bvanassche: sure, assume : 15:56:08 <kbsingh> you can only have 1 rpm installed for one name : so if there is kmod-scst-1.2.3_3.10.el7 15:56:11 <bvanassche> So if we would embed the kernel version number in the RPM name or version number then SCST RPMs for different kernel versions could be installed next to each other. 15:56:34 <kbsingh> and the kernel is updated to 3.10.1.el7 - then the new kmod will replace this. but the older kernel ( upto 5 typically ) is still available as fall back. 15:56:45 <kbsingh> bvanassche: so what i want is to make sure that every kernel has the kmod with it 15:57:26 <kbsingh> bvanassche: using it in the name might be one way to do this - but then the user cant just yum install kmod-scst 15:57:37 <kbsingh> he will need to yum install kmod-scst-1.2.3-3.10.el7 15:57:44 <kbsingh> which will suck a bit :) 15:58:06 <kbsingh> even if the kmod's all provide: kmod-scst, yum cant really decide or map which one is most suiteable based on what kernel is installed at the moment 15:58:35 <kbsingh> bvanassche: so, a bit of work is needed in that space - its going to happen, and i think that effort could use another user story to complement the openafs problem space 15:58:40 <lalatenduM> I think we have kind of agreed to use yum priorities for scst and openafs kernel 15:59:01 <lalatenduM> as the core kernel update should not break sig kernel 15:59:15 <kbsingh> lalatenduM: lets say 'use something' rather than priorities, i dont think the priorities solution will cover it 15:59:32 <lalatenduM> kbsingh, yes if we have a better solution 15:59:37 <JustinClift> Yeah, doesn't sound like it. Sounds like a custom mapping thing 15:59:46 <kbsingh> i am sure we can work out something more comprehensive 15:59:52 <lalatenduM> cool 16:00:00 <JustinClift> Yum plugin? They're often written in Python 16:00:04 <kbsingh> guys, i need to rebase over to another call - but will catchup 16:00:08 <lalatenduM> kbsingh, Also ndevos and kkeithley_ interested to maintain nfs-ganesha in storage sig 16:00:08 <JustinClift> np 16:00:14 <lalatenduM> kbsingh, ok 16:00:17 <lalatenduM> np 16:00:56 <lalatenduM> #action lalatenduM to get ndevos kkeithley_ to request for cbs access via the bugs.c.o interface 16:01:30 <lalatenduM> lets move to ceph status 16:01:40 <lalatenduM> #topic ceph status 16:01:55 <lalatenduM> I dont thing we have anyone from Ceph here 16:02:04 <lalatenduM> s/thing/think/ 16:02:34 <lalatenduM> ok, lets move to SCST 16:02:46 <lalatenduM> #topic SCST status 16:03:17 <lalatenduM> bvanassche, anything else for the status 16:03:40 <bvanassche> The past two weeks I was busy preparing for LSF/MM. 16:04:06 <bvanassche> One of the LSF/MM topics is a discussion about unifying SCST and LIO target drivers. 16:04:18 <bvanassche> But that's off-topic for this meeting. 16:04:34 <bvanassche> Because of what has been discussed earlier in this meeting I will modify the SCST spec 16:04:42 <lalatenduM> bvanassche, cool 16:04:43 <bvanassche> such that the kernel version is embedded in the RPM name. 16:04:57 <bvanassche> That will allow users to install one SCST RPM per kernel version (update). 16:05:24 * JustinClift is excited 16:05:30 <JustinClift> Sounds like this is getting close :) 16:05:37 <bvanassche> Yes ... 16:05:44 <lalatenduM> bvanassche, do you have to change the kernel version in the spec file everytime for a new kernel? 16:06:09 <bvanassche> No - a rebuild should be sufficient. 16:06:16 <lalatenduM> bvanassche, awesome 16:06:22 <bvanassche> RPM macros are convenient for such tricks ... 16:06:40 <lalatenduM> bvanassche, do you want to put any action item on you for the next meeting 16:06:50 <lalatenduM> bvanassche, yes 16:07:31 <bvanassche> Regarding the action item: how about splitting the SCST spec into two spec files - one for DKMS (without kernel version in its name) and one for generating binary RPMs (with kernel version in the RPM name0 ? 16:07:54 <lalatenduM> bvanassche, sounds good :) 16:08:23 <lalatenduM> #action bvanassche to split the SCST spec into two spec files - one for DKMS (without kernel version in its name) and one for generating binary RPMs (with kernel version in the RPM name0) 16:08:45 <lalatenduM> bvanassche, however with the new infrastructure do you need spec with DKMS at all? 16:09:00 <lalatenduM> I mean for storage sig? 16:09:01 <bvanassche> That's right. 16:09:32 <lalatenduM> bvanassche, ok 16:09:37 <bvanassche> The RPM that uses DKMS would not be added to the CentOS build system 16:09:46 <lalatenduM> right 16:09:47 <bvanassche> but would just be made available for users who prefer that spec file. 16:10:14 <lalatenduM> ok 16:10:19 <lalatenduM> sounds good 16:10:43 <lalatenduM> anything else on scst? 16:10:57 <bvanassche> Not from my side ... 16:11:04 <lalatenduM> ok, moving to next one 16:11:14 <lalatenduM> #topic OpenAFS status 16:11:45 <lalatenduM> not sure if we have anyone for OpenAFS 16:11:57 <lalatenduM> s/for/from/ 16:12:03 <JustinClift> Doesn 16:12:06 <JustinClift> look like it 16:12:24 <lalatenduM> yeah 16:12:33 <lalatenduM> #topic open floor 16:12:42 <lalatenduM> I have a topic 16:12:58 <lalatenduM> #topic GSOC ideas for Storage SIG 16:13:29 <lalatenduM> JustinClift, GlusterFS is applying for a separate org this time right? 16:14:23 <lalatenduM> bvanassche, kbsingh has some ideas for SCST (for GSOC) 16:14:44 <bvanassche> I'm all ears ... 16:15:17 <JustinClift> lalatenduM: AFAIK we're not doing GSOC this year with GlusterFS 16:15:36 <JustinClift> lalatenduM: Kaushal was interested in getting it done, but no-one else really was nor had the time 16:15:40 <lalatenduM> bvanassche, lets catch kbsingh and discuss post this meeting. is it ok with you? 16:15:51 <bvanassche> OK. 16:15:56 <lalatenduM> JustinClift, ahh, who is admin then? 16:16:11 <lalatenduM> I mean GSOC admin for GlusterFS 16:16:34 <lalatenduM> JustinClift, ahh got it, we are not doing it 16:16:37 <JustinClift> Yeah 16:16:43 <lalatenduM> JustinClift, :( 16:16:49 <JustinClift> Confirm with Kaushal though, just to be certain 16:16:52 <lalatenduM> ok 16:16:58 <JustinClift> GSOC has a mixed reputation 16:17:20 <lalatenduM> JustinClift, hmm 16:17:21 <ndevos> JustinClift, lalatenduM: I thought Kaushal and spot had a discussion about that yesterday and finilized some more paperwork... 16:17:23 <JustinClift> Good results seems obtainable if a lot of effort is put in. If it's not put in, then it's up to luck 16:17:35 <JustinClift> ndevos: Ahhh. That's possible. 16:17:39 * JustinClift didn't hear about it 16:17:49 <lalatenduM> ndevos, cool. good to know :) 16:17:53 * ndevos read it in his IRC backlog 16:18:25 <lalatenduM> anyone have a a topic for open floor? 16:18:37 <lalatenduM> I dont have anything 16:18:57 <JustinClift> Nothing here. ;) 16:19:04 <JustinClift> Only came to watch. ;) 16:19:31 <lalatenduM> JustinClift, usually we get more participants , today was less 16:19:56 <lalatenduM> closing the meeting 16:20:00 <lalatenduM> #endmeeting