Perl 6 - the future is here, just unevenly distributed

IRC log for #gluster-dev, 2014-02-16

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

All times shown according to UTC.

Time Nick Message
00:02 badone__ joined #gluster-dev
00:46 jclift_ Hmmm, a lot of regression tests on build.gluster.org seem to be failing the rpm.t stuff.
01:14 mohankumar__ joined #gluster-dev
01:19 mohankumar__ joined #gluster-dev
01:27 mohankumar__ joined #gluster-dev
02:01 mohankumar__ joined #gluster-dev
04:01 badone__ joined #gluster-dev
05:55 mohankumar__ joined #gluster-dev
06:01 mohankumar__ joined #gluster-dev
06:10 badone__ joined #gluster-dev
06:13 mohankumar__ joined #gluster-dev
06:31 mohankumar__ joined #gluster-dev
06:42 mohankumar__ joined #gluster-dev
06:55 mohankumar__ joined #gluster-dev
07:08 mohankumar__ joined #gluster-dev
07:09 badone__ joined #gluster-dev
07:33 mohankumar__ joined #gluster-dev
10:08 hagarth joined #gluster-dev
10:29 ndevos jclift_: which changeset(s) would that be?
10:48 bala joined #gluster-dev
11:46 surabhi joined #gluster-dev
12:26 mohankumar__ joined #gluster-dev
13:49 ton31 joined #gluster-dev
14:08 ton31 I'm trying to use glusterfs, but 15% of my servers stuck in listing mounted glusterfs directory
14:08 ton31 After 1-2 minutes it returns the content, but why it's so slow
14:08 ton31 any ideas?
14:20 jclift_ ndevos: Pretty much anything running last night
14:24 jclift_ ndevos: eg: http://build.gluster.org/job/regression/3552/, http://build.gluster.org/job/regression/3553/, http://build.gluster.org/job/regression/3554/, etc.
14:26 jclift_ However, latest regression tests seems to be going ok again, so hopefully it's a transient problem that's gone away.
14:30 mohankumar joined #gluster-dev
14:31 jclift_ Hmmm, something's wrong with the Fedora OpenID application.  It's not letting me auth to review.gluster.org.  Ugh.
14:32 ndevos jclift_: 3552 isnt a rpm.t failure, the others are, not sure why they would fail though...
14:32 jclift_ ndevos: Good point about the changelog entry I'd forgotten to add when updating the .spec.in file.  I'll do that.
14:33 jclift_ ndevos: I suspect something wrong host side at the time, rather than code related.
14:33 jclift_ There's some evidence of prob on the regression hosting side on gluster-devel from the 14th.
14:33 ndevos jclift_: for fedora openid, you may want to ping puiterwijk in some fedora-* channel
14:33 jclift_ I've emailed hagarth to find out what's needed for hosting, etc, to see what's needed.
14:34 jclift_ ndevos: Ahh, tx.  I'll go find him/her and see if that helps
14:34 ndevos it's a him ;)
14:34 * jclift_ also suspects if we put a "We need regression test hosts for Gluster" call out on the front page of gluster.org or something, we might have some good luck.  And possibly reaching out to the board org's.
14:35 jclift_ :)
14:35 jclift_ ndevos: With the thought about how we should handle packaging for glupy.py and it's related __init__.py, should we bring it up on gluster-devel mailing list?
14:36 ndevos I think we should first have a fully automated way of testing, including scratch VMs so that the tests are always run from a clean state
14:36 jclift_ ndevos: That's a good idea
14:36 jclift_ Puppet or Chef or Ansible [etc] based or something
14:36 * jclift_ would personally pick Ansible, due to Python base
14:37 ndevos I dont care much how, as long as it is an extremely simple and reproducible environment, hopefully supporting different hypervisors
14:37 jclift_ Good point
14:38 ndevos jclift_: and, I dont think we should send something for the packaging to gluster-devel yet, first come up with a proposal :)
14:40 mohankumar joined #gluster-dev
14:41 jclift_ ndevos: k.  Well, thinking this through... when I was learning how to get python stuff placed into specific directories and stuff over fri/sat, one of the first things I did was look for other Python code in the gluster base to see how it's Makefiles and similar work
14:42 jclift_ The geo-replication syncdaemon and the gfapi.py stuff were the main two
14:42 ndevos jclift_: any idea how big the storage for the regression tests should be? I still have a plan to create a virt-builder VM for easy testing, maybe something like that can be used as a basis for a regression test framework too
14:43 jclift_ ndevos: No idea at all.  hagarth should be able to clue us in though.  a virt-builder vm like that sounds interesting.
14:43 ndevos jclift_: I've done the gfapi.py packaging bits into -api, geo-replication is moving to glusterfs-server atm
14:43 jclift_ That could turn out to be extremely useful
14:43 jclift_ ndevos: Yeah, I looked at your gfapi.py packaging stuff, because it really helped me mentally figure out what's doing what.
14:44 jclift_ ndevos: I had to adjust it a bit on the way through, after Luis pointed out that it's only installing properly for generated rpms, and not for manually built stuff with --prefix.
14:45 ndevos jclift_: ah, okay, patches for improvements welcome :)
14:45 jclift_ ndevos: That turned out to be because of using EXTRA_DIST, instead of <something>_PYTHON + defining a target directory for the files to go into.
14:45 ndevos jclift_: any suggestion where to package .../site-packages/gluster/__init__.py ?
14:46 jclift_ ndevos: Yeah, fixed that with my patch set for both the gfapi.py stuff and mine
14:46 jclift_ ndevos: Yeah, but "it depends". :)
14:47 ndevos jclift_: currently its in -api, which makes sense because only gfapi.py is available
14:47 jclift_ ndevos: If we're looking to really remove Python from the list of base glusterfs package dependencies, then all of the python stuff will have to move.
14:47 jclift_ Yeah
14:47 jclift_ ndevos: That's ok though, since geo-rep syncdaemon and gfapi are already moving
14:48 jclift_ Both are optional
14:48 ndevos yes, the problem is that glusterfs{,-libs,-api} get installed on any system that has qemu, and those systems do not all need python
14:49 jclift_ ndevos: Should we move gfapi + glupy into a different package altogether?
14:49 ndevos putting it in -api was okay, but people complained about fedora-devel about that too :-/
14:49 jclift_ glusterfs-python?
14:49 ndevos python-glusterfs if any, but yes
14:50 jclift_ eg "If you want to use Python for Gluster development, install the glusterfs-python" package?
14:50 ndevos gfapi.py will be dropped from the glusterfs package anyway, and it'll have its own packaging and all
14:50 jclift_ yeah, I looked at the separate libgfapi-python project too.  It's not ready yet.
14:51 ndevos would there be a problem to include Glupy in python-glusterfs ?
14:51 jclift_ Their packaging is not in good shape atm.  It'll take a few days of mucking around with it to fix.
14:51 jclift_ Interesting thought
14:52 jclift_ Hmmm, why naming of "python-glusterfs" instead of "glusterfs-python"?  Asking because the other rpm generated packages are glusterfs-*.
14:52 ndevos otherwise, python-glusterfs would only have the __init__.py file, and we'll have to create a glusterfs-extra-xlators package for Glupy and other non-standard xlators
14:53 ndevos the fedora naming conventions are python-*, we do not need to keep to that, but I think its better to do so, easier for users
14:53 jclift_ k
14:53 * jclift_ isn't that stressed, was more curious :)
14:54 ndevos and, we have a 'provides: python-glusterfs' already, iirc
14:54 jclift_ np
14:54 jclift_ For including glupy.py into the other libgfapi project (the external one)
14:55 jclift_ It could probably be done.  The project would need to be renamed to python-glusterfs for simplicity / laco-of-confusion though.
14:55 jclift_ s/laco/lack/
14:56 jclift_ Next thought, do we want to do this for 3.5 timeframe or 3.6 timeframe?
14:56 jclift_ The important points being that we need _some_ kind of fix for 3.5, as Glupy is broken as is in 3.5.
14:56 jclift_ (needs a rename at minimum)
14:56 ndevos jclift_: or have glupy completely in its own project/package? glusterfs-glupy ?
14:57 ndevos glusterfs-xlator-glupy?
14:57 jclift_ Meh
14:57 jclift_ Breaking it out at this stage sounds like more trouble than it's worth
14:57 ndevos would it not also get some additional tools of some kind, to enable loading of customer xlators more easily?
14:57 jclift_ Prob best to have all the Python development enabling things for Gluster in one place
14:58 jclift_ And yeah, we can add in tooling for "easy additional of 3rd party translators" too.
14:58 ndevos well, glupy or gfapi.py are pretty different, and so is geo-replication
14:58 ndevos no need to keep those together imho
14:59 jclift_ glupy and gfapi are both enablers for "Develop Gluster using Python"
14:59 jclift_ The geo-replication syncdaemon in a different beast.  I don't know if it has a dependency on either gfapi or glupy though
14:59 ndevos but in a completely different way, gfapi does not change the behavior of the xlator stack
14:59 jclift_ Sure
15:00 jclift_ Glupy doesn't either just from being present
15:00 ndevos geo-rep does not have a dependency on gfapi, neither does glupy
15:00 jclift_ Glupy has to be explicitly added into the graph for it to be used
15:00 jclift_ So, like gfapi it can happily be installed and just sit there without hurting anything
15:00 ndevos gfapi is for non-glusterfs developers, like Swift, qemu, samba
15:01 jclift_ The way I'm looking at it is like this...
15:01 ndevos whereas glupy is for glusterfs devs...
15:01 jclift_ "Lets try and keep it simple for the moment, and if something gets really strong uptake we can move it into it's own package"
15:02 jclift_ Because for every extra package created, there's a shitload of overhead.
15:02 jclift_ eg in bodhi, reviewing, packaging, etc
15:02 jclift_ Ahem, glupy _is not_ for glusterfs dev's
15:02 jclift_ :)
15:03 jclift_ Oh, I know where you're coming from when you say that, don't get me wrong.
15:03 jclift_ But the point of Glupy is for glusterfs-devs to create translators that _other people_ (non-dev's) can use without needing to be a dev
15:03 jclift_ So, sure, rapid dev of translator
15:03 ndevos I don't know for sure, but without knowing a little of glusterfs internals, I dont think you can write anything with Glupy?
15:04 jclift_ But it still needs to be rolled out to external non-devs to be of wide real world usage
15:04 jclift_ [hint] stop looking at it from the "writing" side
15:04 jclift_ From this perspective...
15:04 ndevos yes, of course, if glupy would be for devs only, it would be in the glusterfs-devel package :D
15:04 jclift_ :)
15:05 jclift_ So, yeah, lets say some of us write some nifty functionality in glupy
15:05 jclift_ But we want Gluster users to be able to use that
15:05 jclift_ Those users have to install the glupy package too
15:05 jclift_ So there's the two aspects, like with most software
15:05 jclift_ Dev aspect, and user aspect
15:05 jclift_ Glupy isn't just catering to the dev aspect
15:06 ndevos sure, but I dont care about the dev aspect, I only care where it should get packaged
15:06 jclift_ It's what's users need as well for the stuff they install to work (if they install 3rd party translators)
15:06 jclift_ Sure
15:06 jclift_ I'm just saying both gfapi and glupy could happily be in a python-glusterfs package together
15:06 jclift_ They both for devs + users :)
15:08 ndevos no, not really, python-glusterfs should be able to get installed on a client (libgfapi) system, without installing to much unneeded bits
15:09 ndevos glupy will not be used in the majority of the cases (like OpenStack SWIFT), it does not need to be installed there
15:10 jclift_ Meh, I agree with the "will not be used in major of cases"
15:10 ndevos glupy also is not only written in python, the xlator-bindings need to be somewhere too...
15:10 jclift_ That's a good point
15:10 jclift_ I'm really not a fan of breaking things out into their own packages before their time though
15:11 jclift_ It just creates a bunch of overhead and contributes to project failure :(
15:11 jclift_ And I don't want Glupy to fail
15:12 ndevos but we also dont want existing users (people that install qemu) complain again about dependencies that glusterfs pulls in
15:20 jclift_ Sure
15:21 jclift_ Mmmm, raison toast :)
15:30 ndevos jclift_: so, we'll create a glusterfs-extra-xlators package and put glupy, rot-13 and whatnot in there?
15:30 ndevos gfapi.py and __init__.y
15:31 ndevos ^W __init__.py stay where they are for now, causing the unfortunate side-effect that glusterfs-extra-xlators depends on glusterfs-api
15:31 ndevos (for the __init__.py)
15:39 jclift_ Why don't we just put them all in glusterfs-api?
15:39 jclift_ Who will pull in glusterfs-api, and care about the others being in there?
15:39 jclift_ glusterfs-api is still going to have the dependency on glusterfs + Python
15:40 ndevos glusterfs-api has a dependency on python for now, but that will be gone with 3.6 when gfapi.py has its own package
15:40 jclift_ k
15:41 ndevos I'd rather have some ideas how to do it cleanly now, and have fewer changes in future
15:41 jclift_ For 3.5, we might as well just have glupy keep in the same package it's already in (main glusterfs rpm)
15:41 jclift_ For 3.6 we can break out gfapi and glupy at the same time?
15:42 jclift_ In 3.6 the glusterfs-api package will just be the C gfapi then?
15:42 ndevos hmm, right, I thought we did not provide glupy in the rpms, but it seems we do?!
15:42 jclift_ Yeah, we already do
15:42 ndevos yes, glusterfs-api will only have the C interface
15:42 jclift_ And it's broken at the moment due to name conflict, which is the real problem I'm trying to gix
15:42 jclift_ fix
15:42 jclift_ :)
15:43 jclift_ The simplest fix would be to just mv gluster.py glupy.py
15:43 ndevos this is so tricky to get right :-/
15:43 jclift_ Meh
15:44 jclift_ I'd be ok to do minimal change for 3.5 (just the mv), and then do the fuller adjustment for 3.6
15:44 jclift_ We just need _something_ that works for 3.5
15:44 jclift_ :)
15:44 jclift_ Anyway, I'll go and update the changelog entry thing now.  New patch set coming up.
15:44 jclift_ Might as well test it on F19 too, just to be sure...
15:45 * jclift_ tested on CentOS 6.5 yesterday
15:45 ndevos if we put it in glusterfs, it will get a dependency on glusterfs-api, which is ugly because -api depends on glusterfs too already
15:45 jclift_ It's already there
15:45 ndevos what? glusterfs depends on glusterfs-api?
15:45 ndevos the other way yes, that is expected
15:45 jclift_ No, I mean glupy is already in main glusterfs
15:46 jclift_ There's no "if we put it in glusterfs".  It's already that way. ;)
15:46 ndevos well, yes, I mean "if we merge your patch"
15:46 jclift_ ???
15:47 jclift_ Regardless of my patch, it's already in glusterfs
15:47 jclift_ Now with my patch, I supposed I can adjust the spec file a bit differently so it goes into glusterfs-api though
15:47 ndevos yes, but with your patch, the glusterfs package needs to depend on glusterfs-api (for the __init__.py)
15:47 jclift_ That should be pretty simple
15:47 jclift_ Should I do that?
15:48 ndevos no, I think it's better to have it in glusterfs for now... eventhough I don't really like that...
15:48 jclift_ Heh
15:48 jclift_ I'll go update the change set with new changelog patch now...
15:49 ndevos currently the main glusterfs package does not depend on python, and that is a major plus
15:49 ndevos jclift_: maybe you should move it to glusterfs-api after all, just to keep the python deps constrained to that package
15:50 jclift_ k
15:50 jclift_ I'll give that a shot, and see if it turns out to be as simple as I'm thinking after all
15:50 jclift_ That'll move the __init__.py into there as well
15:50 jclift_ Which kind of keeps things neat
15:51 ndevos it'll still bother the fedora devs that complain about the python deps, but they have that now too, because glusterfs-api depends on python, so it's not a regression in a sense
15:51 ndevos we just make the python dependency a little stronger...
15:52 jclift_ And we can deal with it in a more fuller sense for 3.6 timeframe
15:53 jclift_ sync
15:53 jclift_ clear
15:53 jclift_ ls -la
15:54 jclift_ heh
15:55 ndevos ^L does a 'clear' too ;)
15:55 foster joined #gluster-dev
15:55 jclift_ Deeply ingrained muscle memory :)
15:58 mohankumar joined #gluster-dev
16:03 ndevos fwiw, bug 1065383 now has a tested patch too :)
16:03 glusterbot Bug https://bugzilla.redhat.com:443/show_bug.cgi?id=1065383 unspecified, unspecified, ---, ndevos, POST , rpm: glusterfs-server pulls in glusterfs-geo-replication, merge them into one
17:00 overclk_ joined #gluster-dev
17:03 mohankumar__ joined #gluster-dev
18:10 edward1 joined #gluster-dev
18:18 jclift_ ndevos: Have you ever heard of "make glusterrpms" failing on the Openssl-devel install check, when it passes the normal ./configure ?
18:22 ndevos jclift_: yes, that seems to happen on epel-7 for me... it looks as of AC_CHECK_LIB() is not working as expected
19:47 jclift_ ndevos: Weirdly it's happening in one of my F19 vm's, but I'm pretty sure it wasn't happening n my laptop.
19:47 ndevos jclift_: can you check if there was a autoconf update?
19:47 jclift_ CentOS 6.5 seems to be ok with it.  Haven't tried EL7 yet.
20:21 jclift_ Interesting, now it's failing on my f19laptop as well.
20:21 * jclift_ looks at last updates
20:32 jclift_ Nope, nothing obvious there.
20:44 jclift_ Doesn't seem like a recent change in glusterfs code did it
20:45 badone joined #gluster-dev
21:14 jclift_ Interesting.  The release-3.5 branch works.
21:23 jobewan joined #gluster-dev
21:54 jclift_ ndevos: Found the change that's breaking the rpm compile: http://review.gluster.org/6957
21:55 jclift_ ndevos: If you reset the code in git to the one before it (8eb83e6d9a91c813275f1cbc8e0dc5423fb1ccc0), it's all good.
22:06 edward1 joined #gluster-dev

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