15:30:54 <lalatenduM> #startmeeting StorageSIG
15:30:54 <centbot> Meeting started Fri Dec 12 15:30:54 2014 UTC.  The chair is lalatenduM. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:30:54 <centbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:30:56 <gwd> I'm trying to build the Fedora rawhide libvirt packages
15:31:00 <gwd> Ah, bad timing...
15:31:03 <lalatenduM> hi all
15:31:11 <kbsingh> hello
15:31:16 <alphacc> hi
15:31:20 <hchiramm_> Hi
15:31:45 <lalatenduM> I think we have scuttlemonkey billings too
15:31:46 <billings> Hello lalatenduM
15:31:50 <lalatenduM> :)
15:32:08 <lalatenduM> #chair kbsingh billings hchiramm alphacc lalatenduM
15:32:08 <centbot> Current chairs: alphacc billings hchiramm kbsingh lalatenduM
15:32:22 <lalatenduM> whom did I miss?
15:32:24 <Evolution> do we have someone from the scst folks?
15:32:45 <bart|2> Bart Van Assche (SCST co-maintainer)
15:32:55 <vlnb> Hi, this is Vlad from SCST. Bart should be here soon as well
15:32:56 <lalatenduM> bart|2, hey welcome
15:33:10 <lalatenduM> #chair vlnb bart|2 Evolution
15:33:10 <centbot> Current chairs: Evolution alphacc bart|2 billings hchiramm kbsingh lalatenduM vlnb
15:33:16 <kbsingh> ha.. bart is smoking a pipe!
15:33:17 <deason> hi all
15:33:26 <lsm5> alphacc: aah hmm, the bananas7 tag is an old habit :(
15:33:27 <lalatenduM> deason, hii
15:33:28 <Humble> kbsingh, may be 2 :)
15:33:39 <lalatenduM> #chair deason
15:33:39 <centbot> Current chairs: Evolution alphacc bart|2 billings deason hchiramm kbsingh lalatenduM vlnb
15:33:46 <alphacc> lsm5: let's talk about it after the sig meeting
15:33:56 <lsm5> ack
15:33:59 <lalatenduM> #topic Agenda
15:34:09 <lalatenduM> #info     Topic:        Status Updates
15:34:09 <lalatenduM> #info    Subtopic:   GlusterFS
15:34:09 <lalatenduM> #info    Subtopic:   OpenAFS
15:34:09 <lalatenduM> #info    Subtopic:   Ceph
15:34:09 <lalatenduM> #info    Subtopic:   SCST  in Storage SIG?
15:34:10 <lalatenduM> #info    Open Floor
15:34:35 <lalatenduM> #topic status
15:34:56 <lalatenduM> #topic glusterfs status
15:35:18 <lalatenduM> The pkgs are ready in the test repo
15:35:31 <lalatenduM> kbsingh, any update on the pkg signing infra?
15:35:49 <kbsingh> have been working on it
15:36:12 <Humble> lalatenduM, may be we can create more wikis on GlusterFS in centos space..
15:36:19 <kbsingh> we also have a general plan agreement from board
15:36:21 <lalatenduM> kbsingh, also the release process
15:36:35 <lalatenduM> Humble, sure
15:36:49 <kbsingh> need to work with alphacc on implementation
15:37:09 <lalatenduM> kbsingh, ok
15:37:30 <scuttlemonkey> kbsingh: who is the new czar of centos infra? Would be good to finally nail down automating the process of getting ceph stuff over
15:37:31 <lalatenduM> kbsingh, any idea when we can expect these things
15:37:35 <kbsingh> release process for now will likely be manual... longer term we can look at bodhi2 etc
15:37:48 <scuttlemonkey> ah
15:37:50 <alphacc> kbsingh, lalatenduM : let's try to prioritize this next week.
15:38:00 <lalatenduM> #chair alphacc
15:38:00 <centbot> Current chairs: Evolution alphacc bart|2 billings deason hchiramm kbsingh lalatenduM vlnb
15:38:06 <lalatenduM> alphacc, kbsingh ok
15:38:14 <lalatenduM> Humble, is you want to add something that would be nice
15:38:14 <kbsingh> alphacc: ok
15:38:38 <Humble> lalatenduM,  on GlusterFS space  ?
15:38:55 <lalatenduM> Humble, yes
15:39:10 <Humble> I see packages/rpms are on track
15:39:24 <lalatenduM> Humble, we have a quick start guide too
15:39:36 <Humble> other than that , I am thinking abt more how tos/wikis
15:39:51 <Humble> later we can think abt integration with other SIGs
15:39:59 <lalatenduM> Humble, yes agree
15:40:13 <lalatenduM> Humble, lets think abt it
15:40:17 <Humble> sure thing !
15:40:20 <scuttlemonkey> lalatenduM: since you guys are leading the way on this, it might be worth documenting the things you are doing
15:40:40 <lalatenduM> scuttlemonkey, yes
15:40:54 <scuttlemonkey> so that other folks joining storage sig later can have a roadmap
15:41:00 <Humble> true..
15:41:16 <lalatenduM> #actiion Humble lalatenduM to think more more how tos/wikis for gluster
15:41:23 <lalatenduM> the 1st AI :)
15:41:28 <scuttlemonkey> hehe
15:41:34 <Humble> \o/
15:41:48 <lalatenduM> anything else on gluster ?
15:41:54 <lalatenduM> ....
15:42:03 <lalatenduM> #topic OpenAFS status
15:42:07 <billings> Hi
15:42:21 <deason> I've been making some changes to the userspace spec over the past few days
15:42:27 <billings> I've got the packages building in Fedora COPR
15:42:32 <deason> on https://github.com/adeason/openafs-centos
15:43:23 <billings> deason: feel free to put a PR in on that
15:43:25 <deason> haven't gotten to do much with the kmod one yet or the client
15:43:43 <billings> although it might be worth moving all this to a CentOS git infrastructure...
15:43:44 <deason> yeah, I haven't synced yet because the client part broke a bit; it's not "done" yet
15:43:52 <deason> yes, I was wondering about that, too
15:44:07 <billings> I've made some changes to the openafs-kmod spec file to build DKMS packages too
15:44:07 <deason> should/could we be moving to git.c.o?
15:44:19 <lalatenduM> I think CentOS git infra is not ready , kbsingh alphacc ^^
15:44:22 <billings> I've been waiting to hear back from someone who has the ability to create those accounts.
15:44:43 <deason> okay, that's fine
15:44:50 <lalatenduM> #info https://github.com/adeason/openafs-centos
15:45:13 <deason> but for koji access, should we just ask on here? (not during a meeting :)
15:45:27 <lalatenduM> billings, deason however we can use cbs through src RPM
15:45:54 <Humble> lalatenduM, may be we will have a centos sig git repo  ?
15:45:58 <lalatenduM> billings, i think you are looking for http://wiki.centos.org/HowTos/CommunityBuildSystem
15:46:01 <Humble> does that make sense ?
15:46:13 <deason> I assume koji git builds are restrictied to git.c.o, so we can't host the git somewhere else and do that?
15:46:15 <Humble> storage sig I mean ^^^
15:46:29 <lalatenduM> Humble, yes we are going to have , but the infra for this not ready AFAIK
15:46:54 <Humble> so that all the storage bits can be part of one umbrella..
15:47:05 <billings> lalatenduM: ok, so we should requiest CBS accounts and start using that?
15:47:05 <Humble> later we can integrate different units with the same
15:47:15 <lalatenduM> billings, yes
15:47:24 <billings> Ok, I'd be happy to do that.
15:47:41 <lalatenduM> billings, alphacc or I can help u with that
15:47:56 <alphacc> billings: happy to create account
15:48:02 <billings> I have started to look at the patches deason have added
15:48:42 <lalatenduM> Humble, as of now we are mostly building from upstream , there is not much SIG specific stuff , so it ok. But I understand what you are saying
15:49:07 <lalatenduM> We can definitely put things in github till than
15:49:28 <lalatenduM> e.g. https://github.com/adeason/openafs-centos
15:49:42 <Humble> yeah, later may be we could think abt integrating with infras like "CI", ..etc
15:50:17 <lalatenduM> billings, deason any breakthrough automating the rebuilding kernel through koji?
15:50:27 <lalatenduM> may be not
15:50:29 <billings> I did some minor openafs-server testing with the packages I had created, which worked, and I'm currently using the openafs-client for my $HOME now
15:51:06 <billings> lalatenduM: at last with fedora COPR, it won't rebuild the same revision if it has already.  The only solution seems to be to delete the existing build and rebuild.
15:51:07 <lalatenduM> should I put a AI for you folks to build the same stuff through cbs?
15:51:13 <billings> yes
15:51:50 <lalatenduM> #action billings to build OpenAFS using koji
15:51:56 <deason> from what it looked like, that "find the version" script may just resort to different methods to grab the kernel version
15:52:03 <deason> if e.g. something works with koji but not in fedora etc
15:52:32 <lalatenduM> deason, billings yes, same version will not rebuild
15:52:47 <lalatenduM> we need to bump up the minor version
15:52:54 <lalatenduM> alphacc, ^^
15:53:03 <billings> then there's really no point in trying to make it automated, is there?
15:53:12 <billings> might as well hard code kversion
15:53:23 <lalatenduM> billings, hmm
15:53:27 <billings> I mean
15:53:53 <billings> the only reason I put the effort into making it automatically work was because we wanted to have kmod-openafs packages built against new kernels when they were released.
15:53:54 <lalatenduM> billings, we (storage sig) do not any control on core sig
15:54:07 <lalatenduM> so any updated kernel comes in core
15:54:14 <lalatenduM> sig users will get it too
15:54:16 <deason> wait, I'm confused by that comment
15:54:29 <billings> but if we have to bump a release every time a new kernel release comes out, I'll just toss out the magic script and hard-code a kernel release
15:54:34 <deason> it won't build for the same openafs revision even if there's a new kernel revision? do I understand you correctly?
15:54:42 <billings> that's correct
15:55:01 <billings> because as far as the build infrastructure is concerned, that version-rlease has already been built successfully
15:55:15 <billings> it has no understanding of the need to rebuild against updated dependencies
15:55:23 <deason> it's possible to automatically generate a new release number ('date +%s'), but that's also pretty awful :)
15:55:28 <lalatenduM> billings, correct
15:55:39 <alphacc> yes
15:56:05 <billings> deason: that's a possible solution, although we'll need to have something automatically build a new srpm every time a new kernel comes out
15:56:06 <gaurdro> and we can't have it put some kernel version into the kmod-version during build to get around it either correct?
15:56:24 <alphacc> I think we'll have to start witha side mock script
15:56:38 <lalatenduM> #chair gaurdro
15:56:38 <centbot> Current chairs: Evolution alphacc bart|2 billings deason gaurdro hchiramm kbsingh lalatenduM vlnb
15:56:40 <alphacc> and trigger it when new kernel arrivews
15:57:01 <billings> gaurdro: it doesn't know anything about kmod-version during the part where it evaluates whether it needs to rebuild
15:57:09 <alphacc> we couls use koji import if needed to keep track.
15:57:12 <billings> er, kversion
15:57:33 <lalatenduM> bart|2 vlnb also have similar requirements for SCST too right?
15:58:03 <billings> are they using symbols outside of the ABI whitelist?
15:59:06 <lalatenduM> not sure bart|2, vlnb ^^
15:59:24 <bart|2> At least the SRP target driver is using symbols that are outside the KABI
15:59:37 * billings nods
15:59:50 <bart|2> The entire RDMA API is outside the KABI unfortunately.
16:00:36 <deason> so you need to generate a module on every new kernel release, don't you?
16:00:38 <billings> So you'd probably also benefit from having some mechanism to build against new kernel releases
16:01:08 <gaurdro> I imagine there's a lot of projects that'd benefit from that infrastructure.
16:01:33 <bart|2> That's correct. BTW, "make rpm" is sufficient to build an SCST RPM.
16:02:31 <vlnb> We also need to apply a patch to the kernel
16:02:59 <billings> oh, wow.  so, you also release a new kernel-scst or something like that?
16:03:29 <deason> iirc something like that was still in the air to be decided; if it was going to be included in an existing kernel package or one specifically for scst or something
16:03:29 <bart|2> We have a script that downloads the latest CentOS kernel source code, patches it and rebuilds it as an RPM.
16:03:33 <deason> I may be remembering that wrong
16:03:40 <bart|2> At least for CentOS versions <= 6.
16:03:50 <vlnb> Although, this is not strictly required and needed only to support pass-through dev handlers (export of real SCSI devices)
16:03:53 <bart|2> I don't know where to download CentOS 7 source RPMs from ?
16:03:55 <deason> we could get to that during the scst topic, though :)
16:04:06 <billings> bart|2: vault.centos.org
16:04:15 * billings agrees
16:04:35 <lalatenduM> yeah
16:04:38 <lalatenduM> :)
16:04:46 <lalatenduM> #info OpenAFS needs some infrastructure/automation to automatically build a new srpm every time a new kernel comes out
16:04:56 <lalatenduM> do we need an AI too?
16:05:05 <kbsingh> ai ?
16:05:06 <billings> there's nothing the openafs people can do about that
16:05:08 <lalatenduM> if yes, what would be it :)
16:05:10 <billings> "action item"
16:05:11 <deason> actionitem
16:05:18 <kbsingh> ok
16:05:30 <deason> well, the ai could be for us to talk to core people, or something
16:05:32 <lalatenduM> agree
16:05:40 <deason> or just "think about how we can make it work"
16:06:11 <deason> maybe something is possible with existing infra; being able to play around with koji cbs may yield ideas
16:06:32 <lalatenduM> #action billings deason alphacc kbsingh to to brainstorm on some infrastructure/automation to automatically build a new srpm every time a new kernel comes out
16:06:42 <lalatenduM> is it fine?
16:06:52 <deason> looks fine to me
16:06:55 <billings> agreed
16:06:56 <lalatenduM> cool
16:07:04 <lalatenduM> lets move to scst
16:07:09 <deason> wait, one more thing
16:07:10 <lalatenduM> #topic SCST
16:07:14 <deason> briefly, before we get away from openafs
16:07:16 <deason> ah, too late
16:07:16 <lalatenduM> waiting..
16:07:27 <lalatenduM> deason, plz go ahead
16:07:33 <deason> well, one of my todos was to get the openafs servers to play nice with selinux
16:07:47 <deason> is there a... policy or guidance on packaging selinux rules, or something?
16:08:01 <deason> like, is getting that to work required before a package can be included, or it's just good to have?
16:08:13 <lalatenduM> deason, I bet there would be
16:08:13 <billings> in general, I've had the upstream policy fixed to address issues
16:08:17 <deason> and can we package a policy module, or do we need new rules included in the base selinux policy, etc
16:08:49 <billings> but I've also packaged a %{name}-selinux that contained simple rules that just ran semanage in the scripts section
16:09:13 <kbsingh> yeah, either of those works. short-term might have more control and faster implementation to run with our own sub package
16:09:16 <deason> yes, I just wasn't sure if one method was recommended or mandated by centos or fedora or whomever
16:09:40 <billings> I think the best thing to do would be to get the upstream policy fixed, but that's slower
16:09:46 <kbsingh> yeah
16:10:01 <deason> okay, carry on then, to scst
16:10:06 <gaurdro> +1 for subpackage for now.
16:10:29 <lalatenduM> yeah subpkg works for now +1
16:10:50 <lalatenduM> we can reach to SELinux community to find out more
16:11:35 <lalatenduM> #action lalatenduM will help deason to get  standard policy or guidance on packaging selinux rules
16:12:06 <lalatenduM> deason, have some SELinux contacts, wil try them
16:12:09 <lalatenduM> and let you know
16:12:28 <deason> ah, okay, thanks!
16:12:44 <lalatenduM> anything else on OpenAFS?
16:13:03 <lalatenduM> Ahh, Ceph next :) than SCST
16:13:11 <lalatenduM> #topic Ceph status update
16:13:14 <scuttlemonkey> hehe
16:13:20 <scuttlemonkey> been quite a while since I have been here :P
16:13:21 <lalatenduM> scuttlemonkey, florr is urs :)
16:13:24 <lalatenduM> floor*
16:13:32 <scuttlemonkey> the big items with ceph lately are:
16:13:33 <scuttlemonkey> * http://download.ceph.com infrastructure launched (currently building for centos 6.3, 6.4, 6.5)
16:13:33 <scuttlemonkey> * community build/test infrastructure coming soon (centos will be first guinea pig)
16:13:33 <scuttlemonkey> * el7 SRPMS still available (http://ceph.com/rpm-giant/el7/SRPMS/)
16:13:53 <scuttlemonkey> so first is I'm trying to get the guys to do packaged builds for download.ceph using centos 7
16:14:18 <scuttlemonkey> but our packaging is in a bit of flux as the personnel are shifted around
16:14:45 <lalatenduM> scuttlemonkey, ahh
16:14:55 <scuttlemonkey> will keep plugging on that though... in the meantime, kbsingh and I talked about getting better test coverage on centos
16:14:57 <kbsingh> maybe a good place to start might be to just downstream from the el7 srpms you already push
16:15:10 <scuttlemonkey> yeah
16:15:23 <kbsingh> the other side of the fence is that ceph client stack is going to be in 7.1 ( the beta announce highlighted it )
16:15:34 <scuttlemonkey> cool
16:15:37 <lalatenduM> cool
16:15:50 <scuttlemonkey> which is why I think it's so important that we get centos into the community build/test setup asap
16:15:58 <kbsingh> yup,
16:16:11 <scuttlemonkey> from the sounds of things the machine are almost all online
16:16:18 <scuttlemonkey> I expect to see reachable IPs next week
16:16:33 <scuttlemonkey> Sandon has been prepping our old lab stuff to shift it over
16:16:53 <scuttlemonkey> then I'll get with you guys to be the first through the grinder on getting access and making sure everything works
16:16:59 <scuttlemonkey> our "shakedown cruise" :)
16:17:03 <scuttlemonkey> who is going to handle that?
16:17:05 <kbsingh> ok, we might need a larger text piece on context and background here. is that something you could perpaps plumb in ?
16:17:13 <kbsingh> also, some details on where the conversations are taking place
16:17:23 <scuttlemonkey> kbsingh: absolutely
16:17:41 <scuttlemonkey> I'll write up all the moving pieces (how to use teuthology, pulpito, etc)
16:17:50 <kbsingh> sounds good.
16:18:10 <kbsingh> then i think we can try and find people ( some have offered already! ) to bootstrap the process for centos
16:18:37 <scuttlemonkey> kk
16:18:44 <lalatenduM> scuttlemonkey, kbsingh it seems it will take some more time maybe a week or two to get Ceph builds for storage sig
16:18:57 <scuttlemonkey> lalatenduM: perhaps
16:19:23 <lalatenduM> yeah may be till than you will get download.ceph ready in some shape
16:19:31 <scuttlemonkey> although the bits are there...and I could probably accellerate the process if I could find someone to do that packaging-for-sig 101 that I keep looking for
16:19:53 <lalatenduM> scuttlemonkey, I can help you with that
16:19:57 <scuttlemonkey> but if there is no rush I'm happy to let it happen organically as a result of all of our ongoing efforts
16:20:00 <scuttlemonkey> lalatenduM: cool
16:20:11 <scuttlemonkey> why don't we sit down next week sometime and go through that
16:20:12 <kbsingh> organic is good, we can dogfood this into the testing cycles as well
16:20:24 <lalatenduM> #info Ceph community is working on packaged builds for download.ceph using centos 7
16:20:36 <lalatenduM> scuttlemonkey, sure
16:21:13 <Humble> .
16:21:17 <lalatenduM> #action lalatenduM will help scuttlemonkey on 101 for building Ceph on cbs
16:21:53 <lalatenduM> ok we are running out of time :)
16:22:03 <scuttlemonkey> that's it from me really
16:22:03 <lalatenduM> anything more Ceph?
16:22:04 <Humble> :)
16:22:10 <lalatenduM> cool
16:22:16 <lalatenduM> #topic SCST
16:22:29 <lalatenduM> I think SCST is a welcome addition for stoarge SIG
16:22:39 <lalatenduM> anyone things otherwise ?
16:22:45 <lalatenduM> thinks*
16:22:58 <vlnb> Thanks
16:23:03 <lalatenduM> s/things/thinks/
16:23:05 <Evolution> nope. my only concern based on email as if it builds as a module or required a whole separate kernel
16:23:51 <bart|2> Rebuilding the kernel is only required to enable SCSI pass-through.Most users don't need SCSI pass-through and hence do not need a rebuilt kernel.
16:24:37 <kbsingh> this cant be done via a kmod ?
16:25:17 <bart|2> Is kmod an infrastructure for rebuilding kernel modules from source ? If so, that should be possible.
16:25:27 <kbsingh> bart|2: yeah, and cool.
16:25:51 <kbsingh> so apart from ths one feature, the rest of the code is all deliverable to run with the distro kernel on centos6/7 ?
16:26:51 <bart|2> Yes. The easiest way today to build and install SCST and all target drivers on CentOS is to type "make rpm" and to install the two generated RPMs (one for the kernel modules and one for scstadmin).
16:27:42 <bart|2> scstadmin is a tool for configuring SCST and for saving and restoring the entire configuration.
16:28:20 <lalatenduM> is that means we dont need to rebuild the whole kernel?
16:28:40 <lalatenduM> it is just SCST kernel modules and scstadmin
16:28:50 <bart|2> Correct - most functionality is available without rebuilding the kernel. Vlad, please correct me if I got something wrong or if I missed something.
16:29:25 <vlnb> Yes, everything is available, except pass-through functionality (more or less rarely used)
16:29:26 <bart|2> The only catch is that at least the SRP target driver is using symbols that are not in the kABI so at least in theory the SCST kernel modules have to be rebuilt after every kernel update.
16:29:26 <billings> you might need to adjust the build system so it can build the kmod packages from a spec file rather than having the makefile specificall build the rpm
16:29:49 <vlnb> So we can start without kernel rebuild
16:30:00 <bart|2> billings: We will indeed have to look into adding kmod support.
16:30:50 <bart|2> Are any pointers available to the kmod documentation ?
16:30:50 <kbsingh> since openafs and scst will need the same functionality, it might be good to collaborate on the solution
16:31:02 <lalatenduM> #info Most SCST functionality is available without rebuilding the kernel i.e.  except pass-through functionality
16:31:22 <billings> there is a script that's part of the RPM build packages (/usr/lib/rpm/redhat/kmodtool) that you can evaluate in your spec file and it'll automatically create a subpackage called kmod-%{name} with appropriate dependencies
16:31:36 <lalatenduM> kbsingh, who would be the contact point for that?
16:31:51 <billings> however, it needs to be executed in such a way that it is annoying to rpm specfile authors
16:32:59 <billings> (it expects you to supply the kernel version as a parameter)
16:33:39 <kbsingh> lalatenduM: we can likely talk about this on the centos-devel list and workout a solution there ( i guess this will also tie back into auto-triggers from new kernel builds )
16:33:53 <bart|2> We already have the following in the SCST spec file: %define kver %{expand:%%(echo ${KVER:-$(uname -r)})}
16:33:55 <deason> and openafs has a custom kmodtool for... reasons I forget
16:34:37 <lalatenduM> kbsingh, yeah , putting an action item on you for this :)
16:34:40 <deason> bart|2: yeah, but that will only build for the current running kernel; with systems like koji, mock, etc you may want to build for something else
16:34:47 <lalatenduM> #action kbsingh will start a discussion on "the build system should  build the kmod packages from a spec file rather than having the makefile specificall build the rpm" as openafs and scst will need the functionality
16:34:48 <billings> deason: there's a long history as far as I can tell, but I think the current kmodtool in rpmbuild assumes you're building kmod that use the kABI
16:34:59 <kbsingh> uname -r is going to be a problem.. sometimes the buildhost does not match target configs ( eg. c7 builds run on a c6 host )
16:35:37 <bart|2> Please note that that spec file statement checks the $KVER environment variable before executing $(uname -r)
16:35:37 <billings> using uname -r is almost always the wrong thing to do in a spec file, if you want to use koji
16:35:52 <kbsingh> apart from this kernel component that we can talk about / thrash out / find a fix for - what is the state of the rest of scst codebase in rpms
16:35:57 <bart|2> $(uname -r) is only executed if $KVER is empty.
16:36:01 <billings> and in the build environment *NOTHING* environment is set
16:36:06 <deason> yeah, but koji won't set that
16:36:14 <billings> you can't --define things either
16:36:44 <billings> the build environment runs inside a chrooted environment that has no environment variables that aren't set in the spec file
16:37:38 <deason> if you want to see what billings has for now for detecting the version to build, see https://github.com/jsbillings/openafs/blob/kmod/openafs-kmod/find-installed-kversion.sh, but if you use something else of course we'd like to see what others do
16:37:49 <billings> yeah, that's such a hack
16:38:00 <billings> and it literally only works in CentOS7
16:38:11 <bart|2> OK, we will have a look.
16:38:21 <deason> anyway, kbsingh had a question up there?
16:38:46 <lalatenduM> yeah
16:38:47 <lalatenduM> <kbsingh> apart from this kernel component that we can talk about / thrash out / find a fix for - what is the state of the rest of scst codebase in rpms
16:39:47 <lalatenduM> bart|2, vlnb you guys want to add anything here
16:40:34 <lalatenduM> Sorry I did not check , whatis the license of SCST?
16:40:38 <lalatenduM> GPL?
16:40:50 <vlnb> Yes, GPL
16:41:13 <lalatenduM> we are cool here , right kbsingh ?
16:41:30 <kbsingh> yeah, license is fine.
16:41:41 <vlnb> My question is that should we proceed with getting login?
16:41:53 <lalatenduM> vlnb, yes
16:41:54 <kbsingh> if we are at a stage were there are srpms around, we can likely get one of the guys koji access, and get some builds posted fairly quickly.
16:42:03 <lalatenduM> yup
16:42:08 <kbsingh> and then iterate over that till we get a good-enough solution to release
16:42:29 <lalatenduM> kbsingh, +1
16:42:36 <kbsingh> vlnb: i would say sync up with lalatenduM, and he can get you access to the buildsys ( by filing requests in bugs.c.o, but he can help with that )
16:42:48 <kbsingh> ideally, keep it to a small number of contributors initially, maybe max of 2
16:42:55 <vlnb> Agreed, looks like a good plan
16:43:07 <kbsingh> just so that all the builds need to be channele via a small set of folks ( and therefore, a small set of people have complete picture )
16:43:25 <lalatenduM> #action vlnb to sync with lalatenduM to get access of buildsys
16:43:44 <lalatenduM> anything on SCST?
16:43:50 <lalatenduM> 1..2..3
16:43:50 <vlnb> OK, thanks
16:43:51 <kbsingh> in the mean time, i would also say get lalatenduM to get your details ( about you, as people, and about you, as project ) into the wiki, then work on a quickstart wiki page like the gluster one, once we have an rpm or two
16:43:59 <vlnb> Nothing from my side
16:44:30 <bart|2> Forgot to mention: if you want the FCoE target driver to work reliably several libfc patches will have to be backported from kernel 3.13.
16:44:43 <kbsingh> bart|2: vlnb the key thing is that we try and stick with the fedora rpm packaging guidelines as much as possible. so if you need a plac to start or validate against, look there - then ask questions on centos-devel ( since we are not quite 1:1 with fedora on policy )
16:44:49 <lalatenduM> yes we need those from OpenAFS too, will send separate mails
16:45:40 <lalatenduM> bart|2, are you guys going to do the back porting ?
16:45:50 <lalatenduM> and for el6 and el7 both?
16:46:11 <bart|2> I will try to create a Red Hat bugzilla ticket and see how far I get.
16:47:22 <lalatenduM> bart|2, so you are expecting to get these patches in core kernel
16:47:31 <bart|2> The earliest kernel in which libfc works reliably is upstream kernel version 3.13.
16:47:41 <lalatenduM> so that storage sig does not have to backport
16:47:43 <bart|2> el6 and el7 are based on older kernels.
16:48:09 <lalatenduM> hmm
16:48:28 <lalatenduM> kbsingh, any thoughts
16:49:25 <lalatenduM> #info To get  the FCoE target driver to work reliably several libfc patches will have to be backported from kernel 3.13.
16:49:36 <lalatenduM> we are running out of time
16:49:40 <kbsingh> lalatenduM: yes, ququite a few thoughts
16:49:41 <scuttlemonkey> lalatenduM: I have another meeting starting in 10m that I need to snag a few things for. Gonna wander off, but I'll read backscroll
16:49:53 <lalatenduM> may be we can take this in next meeting
16:49:56 <kbsingh> scuttlemonkey: thanks for stopping by
16:50:09 <lalatenduM> scuttlemonkey, yeah , np :)
16:50:24 <bart|2> BTW, iSCSI, FC and SRP are more popular than FCoE.
16:50:47 <kbsingh> kernel features are a big thing, and there are dozens of ways to deliver that - we should workout what is the : (a) least painful for developers (2) easiest to consume for users (3) deliver a consistent story, so regardless of how people get the bits, the story is still the same and (4) avoid complexity at buildsys
16:51:01 <kbsingh> I'd say that 1..4 would be my personal priority order as well.
16:52:08 <vlnb> So, let's start from QLogic FC, iSCSI and SRT without pass-through dev handlers, so we don't need to patch kernel, then work on others feature by feature
16:52:21 <kbsingh> I'd vote for that.
16:52:23 <lalatenduM> vlnb, +1
16:52:41 <lalatenduM> #info SCST to start from QLogic FC, iSCSI and SRT without pass-through dev handlers, so we don't need to patch kernel, then work on others feature by feature
16:52:49 <kbsingh> lets build one ( or however many ) stories we can, without needing such complexity, and then once we get some traction, deliver the features as and when we can - organically.
16:52:50 <gaurdro> +1 aswell.  I'm happy to lend hands/eyes whenever I can.
16:53:08 <kbsingh> ok, everyone gaurdro just offered to do ALL the work!!!
16:53:16 <lalatenduM> :)
16:53:17 <kbsingh> let his excitement not go unpunished.
16:53:27 <kbsingh> :)
16:53:28 <gaurdro> :)
16:54:11 <lalatenduM> anything else on SCST?
16:54:20 <lalatenduM> 1.. 2 .. 3
16:54:24 <lalatenduM> moving on
16:54:30 <vlnb> Nothing from my side
16:54:52 <lalatenduM> #topic open floor
16:55:11 <vlnb> Thanks everybody!
16:55:19 <lalatenduM> anything for open floor
16:55:29 <lalatenduM> I dont have anything
16:55:34 <gaurdro> nothing here.
16:55:38 <lalatenduM> cool
16:55:48 <lalatenduM> 1..
16:55:53 <lalatenduM> 2 .. 3
16:55:56 <billings> when one files a bug to get a koji account, what project/category should we file it against?
16:56:33 <lalatenduM> billings, hmm dont remember let me check , alphacc might remember
16:56:45 <billings> (it'd just be nice to have this on record)
16:57:28 <kbsingh> billings: 'buildsys'
16:57:42 <kbsingh> there is a wiki page with details on what to put in the request as well
16:58:34 <lalatenduM> http://wiki.centos.org/HowTos/CommunityBuildSystem
16:58:36 <billings> yes, it doesn't say to use buildsys, and buildsys has half a dozen categories
16:59:09 <billings> I mean, I could just pick something at random and hope my ticket is addressed.
16:59:19 <kbsingh> alphacc: can you please add relevant info to the wiki page
16:59:20 <lalatenduM> billings, dont worry abt the categories much, alphacc or kbsingh can fix them :)
16:59:37 <kbsingh> billings: prolly wont, a few requests got lost since people filed against centos7
16:59:50 <lalatenduM> billings, I will give you link to the bug report i had raised
17:00:18 <lalatenduM> billings, http://bugs.centos.org/view.php?id=7469
17:00:19 <billings> ok
17:00:59 <lalatenduM> vlnb for you too
17:01:13 <lalatenduM> ok
17:01:16 <lalatenduM> anything else
17:01:22 <lalatenduM> ?
17:01:29 <deason> yeah, cbs is "community buildsys" so I assumed that category
17:02:42 <lalatenduM> deason, billings feel free to ping alphacc on this :)
17:02:55 <lalatenduM> going to end meeting :)
17:03:00 <lalatenduM> #endmeeting