Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2014-12-12

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary

All times shown according to UTC.

Time Nick Message
00:11 tdasilva joined #gluster-dev
00:21 _Bryan_ joined #gluster-dev
01:16 bala joined #gluster-dev
01:17 lalatenduM joined #gluster-dev
02:38 soumya joined #gluster-dev
02:54 hagarth joined #gluster-dev
02:55 bala joined #gluster-dev
03:19 bala joined #gluster-dev
03:41 kshlm joined #gluster-dev
03:41 bharata-rao joined #gluster-dev
03:45 atinmu joined #gluster-dev
04:16 ppai joined #gluster-dev
04:18 nishanth joined #gluster-dev
04:33 ndarshan joined #gluster-dev
04:34 sachin joined #gluster-dev
04:37 itisravi joined #gluster-dev
04:39 hagarth joined #gluster-dev
04:42 kanagaraj joined #gluster-dev
04:47 rafi joined #gluster-dev
04:53 anoopcs joined #gluster-dev
04:54 shubhendu joined #gluster-dev
04:59 Gaurav_ joined #gluster-dev
05:04 bala joined #gluster-dev
05:07 atinmu joined #gluster-dev
05:12 anoopcs joined #gluster-dev
05:14 prasanth_ joined #gluster-dev
05:16 lalatenduM joined #gluster-dev
05:22 anoopcs joined #gluster-dev
05:27 jiffin joined #gluster-dev
05:31 bala joined #gluster-dev
05:32 kdhananjay joined #gluster-dev
05:45 atalur joined #gluster-dev
05:53 atinmu joined #gluster-dev
06:07 soumya joined #gluster-dev
06:12 raghu` joined #gluster-dev
06:15 badone joined #gluster-dev
06:30 bala joined #gluster-dev
06:31 badone joined #gluster-dev
06:37 itisravi_ joined #gluster-dev
06:45 atinmu joined #gluster-dev
06:53 atalur joined #gluster-dev
07:00 lalatenduM joined #gluster-dev
07:17 soumya joined #gluster-dev
07:46 rgustafs joined #gluster-dev
08:33 atalur joined #gluster-dev
08:38 kaushal_ joined #gluster-dev
08:45 shubhendu joined #gluster-dev
08:47 prasanth_ joined #gluster-dev
08:53 atinmu joined #gluster-dev
08:57 rafi1 joined #gluster-dev
08:58 hchiramm ndevos++
08:58 glusterbot hchiramm: ndevos's karma is now 67
09:01 overclk joined #gluster-dev
09:02 ndevos hchiramm++ nice to see that being done!
09:02 glusterbot ndevos: hchiramm's karma is now 10
09:03 badone joined #gluster-dev
09:03 ndevos (others will see an email about "that" shortly)
09:03 ndevos and atinmu++ for cracking the spurious regression test breakage :D
09:03 glusterbot ndevos: atinmu's karma is now 5
09:03 hchiramm \o.
09:04 atinmu ndevos, thanks
09:35 vimal joined #gluster-dev
09:41 atinmu joined #gluster-dev
09:43 shubhendu joined #gluster-dev
09:47 kshlm joined #gluster-dev
10:01 rafi joined #gluster-dev
10:04 hagarth joined #gluster-dev
10:18 ianbrown joined #gluster-dev
10:21 anoopcs joined #gluster-dev
10:30 anoopcs joined #gluster-dev
10:44 badone joined #gluster-dev
10:46 ndarshan joined #gluster-dev
10:56 atalur joined #gluster-dev
11:14 badone joined #gluster-dev
11:17 nkhare joined #gluster-dev
11:49 badone joined #gluster-dev
11:55 anoopcs joined #gluster-dev
11:58 soumya joined #gluster-dev
12:02 kkeithley joined #gluster-dev
12:26 hagarth joined #gluster-dev
12:35 lalatenduM ndevos, regrading https://bugzilla.redhat.co​m/show_bug.cgi?id=1169005
12:35 glusterbot Bug 1169005: high, high, ---, ndevos, MODIFIED , RPM building of glusterfs-3.6.1-3.fc22 src RPM on el5 is failing
12:35 ndevos lalatenduM: yes?
12:35 lalatenduM ndevos, as I understand now the hook scripts will not install when geo-rep is enabled compile time
12:36 lalatenduM ndevos, the last changes I did to spec file , will those cause any issue if geo-rep is enabled during compile time
12:36 lalatenduM for e.g. el5
12:36 lalatenduM ndevos, e.g. rm -rf  %{buildroot}%{_datadir}/glu​sterfs/scripts/get-gfid.sh or %exclude %{_datadir}/glusterfs/scri​pts/generate-gfid-file.sh
12:37 ndevos lalatenduM: those changes should not be neededm, those files should not exist in the 1st place
12:38 ndevos lalatenduM: I do not think it breaks anything to have them, but it would be cleaner to not have those changes
12:38 lalatenduM ndevos, nope, for el6 and 7 when geo-rep is enabled , still the geo-rep scripts will come from regression rpm
12:38 lalatenduM unless i exclude them
12:38 lalatenduM though the rm -rf change can be removed now
12:39 lalatenduM I mean likes of "rm -rf  %{buildroot}%{_datadir}/glu​sterfs/scripts/get-gfid.sh"
12:39 ndevos lalatenduM: those files should be listed in the geo-replication subpackage %files section, right?
12:40 ndevos that subpackage does not exist when geo-replication is disabled, the files should also not get installed when geo-rep is disabled
12:41 ndevos I tested http://review.gluster.org/9221 and build rpms for EL5, that worked fine
12:41 ndevos that was using the community glusterfs.spec file, I do not remember if I checked for manual (in the .spec) installation of those scripts
12:42 lalatenduM ndevos, yes, they are under the geo-rep files section , but in regression-tests files section we have "%{_prefix}/share/glusterfs/*"
12:43 lalatenduM thats what I had discussed with kkeithley
12:43 lalatenduM too
12:44 bala joined #gluster-dev
12:45 ndevos lalatenduM: I'd say the regression-tests package should include only the files it needs, not '*'
12:45 ndevos well, and subdirectories with the tests
12:46 lalatenduM ndevos, i agree with you :)
12:47 ndevos lalatenduM: you'll send a patch for that? you can even use bug 1169005 for it then :)
12:47 glusterbot Bug https://bugzilla.redhat.com:​443/show_bug.cgi?id=1169005 high, high, ---, ndevos, MODIFIED , RPM building of glusterfs-3.6.1-3.fc22 src RPM on el5 is failing
12:51 lalatenduM ndevos, ok will do that .. we need to fix the fedora spec file when patches are merged to 3.6 branch
12:52 lalatenduM ndevos, can you plz take care of that
12:53 lalatenduM ndevos, ahh http://review.gluster.org/9248 is merged in 3.6 , we ned to fix the fedora dist git
12:54 ndevos lalatenduM: hmmm, I just build rpms from the master branch against el5, that works just fine?
12:54 lalatenduM ndevos, yeah it will work fine , you should build for el6 and then do rpm -qf for geo-rep scripts
12:55 lalatenduM ndevos, make sure you build regression tests too for el6
12:55 ndevos the el5 regression-test rpm contains these weird files though: /usr/share/glusterfs/scripts/po​st-upgrade-script-for-quota.sh /usr/share/glusterfs/scripts/p​re-upgrade-script-for-quota.sh
12:55 * ndevos rebuilds for el6
12:56 lalatenduM ndevos, did not get issue with quota scripts, they should n't be thr for el5?
12:56 pcaruana joined #gluster-dev
12:57 ndevos lalatenduM: theye should not be in the regression-tests package, but probably in glusterfs-server?
12:57 lalatenduM ndevos, ohh, another bug then
12:57 ndevos yeah...
12:57 lalatenduM all because of "%{_prefix}/share/glusterfs/*"
12:58 lalatenduM may be we need another bug to clean it up
12:58 ndevos yes, and when you send a fix for that, we'll catch other issues like these earlier
12:58 ndevos lalatenduM: or do you want me to send a fix for it?
12:59 lalatenduM ndevos, anything works for me
13:00 ndevos lalatenduM: for me too!
13:01 lalatenduM ndevos, I consider your time is imp, unless it is not wasting much of your time , you can go ahead :)
13:02 ndevos lalatenduM: I'll quickly post a patch for upstream, you can then sync it with Fedora?
13:02 lalatenduM ndevos, ok
13:09 lalatenduM ndevos, I think kkeithley's old patches to sync fedora and upstream specfiles needs a rebase now
13:10 lalatenduM hchiramm, ^^
13:10 ndevos lalatenduM: were there still some open?
13:10 lalatenduM ndevos, yes
13:11 lalatenduM ndevos, hchiramm http://review.gluster.org/#/c/8853/1/glusterfs.spec.in
13:11 kkeithley maybe I should abandon those and start over once you're done
13:12 lalatenduM kkeithley, yeah thats an option
13:12 lalatenduM kkeithley, ndevos I dont know what to do with http://review.gluster.org/#/c/7199/ too
13:13 lalatenduM should we abandon it
13:13 lalatenduM brb
13:17 ndevos lalatenduM: http://review.gluster.org/#/c/7199/ is still something that needs to be addressed
13:19 edward1 joined #gluster-dev
13:19 ndevos lalatenduM: http://review.gluster.org/9272 is the patch that corrects the regression test package
13:24 kkeithley joined #gluster-dev
13:26 lalatenduM ndevos, lets discuss http://review.gluster.org/#/c/7199/ some may be early next week
13:27 ndevos lalatenduM: sure, works for me
13:27 * ndevos need to have some lunch, and will be back later (and next week)
13:28 lalatenduM ndevos, regrading 9272 , why do we need %dir %{_datadir}/glusterfs/scripts
13:28 ndevos lalatenduM: so that removing the package will also remove the directory
13:29 ndevos we might need additional entries like that for other shared directories... its something we should probably try out one day
13:32 lalatenduM ndevos, one silly question, when we mention "%{_datadir}/glusterfs/scripts/p​ost-upgrade-script-for-quota.sh"
13:33 lalatenduM ndevos, the scripts dir will be automatically creaed?
13:33 lalatenduM bcz we dont create these dirs separately
13:37 ndevos lalatenduM: yes, directories get automatically created, but they do not automatically belong to a package
13:38 ndevos lalatenduM: the Fedora Packaging Policy states that packages should remove all of their contents when they are uninstalled - we should try to follow that :)
13:38 lalatenduM ndevos, yes I agree
13:38 * ndevos <- back later
13:45 rgustafs joined #gluster-dev
13:56 rgustafs joined #gluster-dev
14:04 tdasilva joined #gluster-dev
14:13 deepakcs joined #gluster-dev
14:25 shyam joined #gluster-dev
14:37 ndevos hey shyam! how do you feel about having a gfapi call to set/get a POSIX ACL?
14:37 ndevos like, passing/retrieving a structure that is provided by libacl?
14:39 ndevos 'man 5 acl' for some more details - it would be nice to have this for nfs-ganesha
14:39 ndevos otherwise, I'll look at implementing it in nfs-ganesha directly
14:40 ndevos (standard libacl calls need either a path or file-descriptor, we dont have either with gfapi)
14:42 * ndevos will be back in a bit again, need to unsee his screen for a while
15:07 wushudoin joined #gluster-dev
15:16 wushudoin joined #gluster-dev
15:34 shyam ndevos: Would the set/getxattrs not provide the functionality that you are seeking? Which would mean upper layers formatting the information and writing it into these attrs (ie Ganesha), providing the APIs would mean gfapi providing the encoding for them, I think
15:38 ndevos shyam: yes, that would be the workaround - but I think samba or others would need to implement the same setxattr and getxattr conversions
15:39 ndevos shyam: gfapi could be used to convert a standard acl_t structure into binary format, and use setxattr to write it to the bricks
15:39 ndevos if that is too much detail for gfapi, I'll have to put it in ganesha - which is fine with me too
15:40 shyam ndevos: Got the idea, just thinking how this encoding should differ based on which system is using it etc.
15:41 shyam I do not think it is too much detail for gfapi, just that, who else utilizes this data, and if we can arrive at a format that is constant to all
15:42 shyam If gfapi encodes it, can FUSE mount use it to enforce the same permissions? The answer would be 'yes' I guess, which means, we encode this as it is done on Linux
15:42 ndevos shyam: well, libacl is pretty standard, and that would make it possible to keep the xattrs the same for fuse mounts and the ACL checks on the bricks (by the VFS)
15:42 ndevos indeed, that would be the goal
15:42 shyam Yes, any chance *BSD or other platform variants needs this differently? Just curious
15:42 shyam ... and unsure
15:43 ndevos I think libacl originates from some BSD
15:43 ndevos but, the format in the xattr may be different
15:43 ndevos I've already got a patch for libacl that makes it possible to do the conversion from acl_t to the binary format (and back)
15:44 shyam Well I guess till now, if we focus on FUSE clients, then the client decides the encoding and just calls setxattr, if the encoding is different on different platforms, then the same mount viewed from a different _platform_ FUSE _like_ client would have issues, right?
15:45 ndevos well, as fallback, the conversion could be  done by setting the ACL to some local tmp file, and reading the binary data with getfattr (but thats a little ugly)
15:45 * shyam is thinking...
15:45 ndevos oh, indeed, yes, if the format of the xattr is different between platforms, we already have an issue
15:47 ndevos in fact, libacl is the current available standard, in future librichacl would need a similar treatment
15:49 jobewan joined #gluster-dev
15:49 shyam yup... So I am thinking what is the format that gfapi provides? Meaning, assuming platform1 uses format1 (and the same for 2), and a customer is purely on platform1 then the volume is safe, in this situation, if we bring in gfapi format (which would/should be Linux specific format), then if its format varies from platform1 we would be in trouble, as they could have NFS clients on platform1 and FUSE clients on platform1 as well
15:49 shyam ndevos: All this is theoritical, let me read up some more, and see if we can narrow down on a single format, and if that is good enough
15:50 shyam In which case gfapi providing this interface is feasible, else we maybe better leaving it out, and it kinda becomes NFS Ganesha Gluster FSAL problem, where the problem really does not go away for us.
15:51 shyam IOW, I think we need to decide on a format, or make that configurable in case there are _other_ formats out there
15:51 ndevos hmm, yeah, I dont know if *BSD uses the same xattr name and binary representation of the ACLs
15:52 ndevos if they dont, we would need an RPC calls to get/set ACLs, and use a GlusterFS/ACL format which then can be converted to/from any client platform and brick
15:54 shyam ndevos: did not get the RPC part?
15:54 shyam RPC calls, meaning gfapi?
15:57 ndevos shyam: well, if there is no common format between platforms, we need to invent an ACL format that we can setfacl/getfacl on the bricks, and convert back to any client
15:58 shyam ndevos: rigth
15:58 shyam I mean right, agreed
15:59 ndevos shyam: so, the client would get a setfacl, something translates that to a Gluster/ACL, gets sent to the brick, and the brick decodes and writes the platform specific ACL
16:02 shyam ndevos: Direction seems right, transform a Gluster-ACL xattr to a brick platform specific ACL. transform a gluster-ACL xattr to a client specific xattr on the clients
16:03 shyam ndevos: I think needs changes in posix xlator, and (either) all client protocol end points, or something in between on the client stack (but I think we need to look at this before _maybe_ over-engineering it :) )
16:03 shyam ndevos: If we have this, then providing a gfapi for the same is very much understandable, and makes things easier for API consumers without bothering about other semantics
16:05 ndevos shyam: yeah, I (possibly incorrectly) assumed that the libacl binary format would always be used, I'll try to figure out what other non-Linux platforms use
16:06 shyam ndevos: Cool, I will try as well, either way, I think this maybe something to consider outside of gfapi as well, where different platform gluster client is accessing the same volume
16:33 hagarth joined #gluster-dev
16:36 * ndevos cant find any details and decided to install a FreeBSD system
16:50 hagarth joined #gluster-dev
16:52 vimal joined #gluster-dev
17:03 _Bryan_ joined #gluster-dev
17:31 hagarth joined #gluster-dev
17:35 shyam joined #gluster-dev
17:37 ndevos hey shyam, just posted an email about ACLs to the -devel list with you on CC :)
17:38 * ndevos will now start his weekend, tty next week again!
17:45 shubhendu joined #gluster-dev
17:49 soumya joined #gluster-dev
18:43 edward1 joined #gluster-dev
18:45 lalatenduM joined #gluster-dev
19:18 shyam joined #gluster-dev
19:42 tdasilva joined #gluster-dev
20:28 tdasilva joined #gluster-dev
21:06 badone joined #gluster-dev
22:50 badone joined #gluster-dev

| Channels | #gluster-dev index | Today | | Search | Google Search | Plain-Text | summary