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