Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-02-19

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

All times shown according to UTC.

Time Nick Message
00:21 hagarth joined #gluster-dev
00:41 hagarth joined #gluster-dev
01:09 bala joined #gluster-dev
01:30 hagarth joined #gluster-dev
01:49 bala joined #gluster-dev
02:50 an joined #gluster-dev
02:58 bharata joined #gluster-dev
03:08 bulde joined #gluster-dev
03:09 overclk joined #gluster-dev
03:34 hagarth joined #gluster-dev
03:44 kshlm joined #gluster-dev
03:44 kshlm joined #gluster-dev
04:01 sripathi joined #gluster-dev
04:07 portante` joined #gluster-dev
04:24 sgowda joined #gluster-dev
04:29 sahina joined #gluster-dev
04:41 deepakcs joined #gluster-dev
04:45 vpshastry joined #gluster-dev
04:54 bala joined #gluster-dev
04:57 deepakcs bala, Hi
05:01 aravindavk joined #gluster-dev
05:02 deepakcs hagarth, hi
05:22 hagarth joined #gluster-dev
05:27 mohankumar joined #gluster-dev
05:41 bala joined #gluster-dev
05:41 bala deepakcs: hi
05:46 deepakcs bala, when one does "enable for virt. use" for a gluster volume, what vdsm verb gets called ?
05:46 deepakcs bala,  I am trying to understand it so that I can verify and/or use the same when someone create a gluster strg domain from engine
05:47 deepakcs bala, ideally as part of engine support for gluster strg domain, there should be a validaiton done (whether the volume is enabled for virt.use) , before domain iscreated
05:48 an joined #gluster-dev
05:56 bala deepakcs: no special verb available
05:56 bala deepakcs: need to use set option
05:57 bala deepakcs:  'storage.owner-uid' = 36,  'storage.owner-gid' = 36, 'group' = 'virt'
05:57 deepakcs bala, ok, how can i find what all 'set' options are  invoked by the engine. I still dont have a fully working engine setup for me to try and see
05:57 bala deepakcs: here uid 36 means vdsm, gid 36 mean kvm
05:57 deepakcs bala, right.. i understand that. storage. means the brick ?
05:58 bala deepakcs: no
05:58 bala deepakcs: 'storage' is set option
05:58 deepakcs bala, IIUC the brick dir should have 36:36 perms rite ?
05:59 deepakcs for vdsm / qemu to work
06:00 bala deepakcs: yes.  u can use storage.owner-uid and storage.owner-gid set option which take care of setting permission/owner/group to respective bricks
06:02 deepakcs bala, cool. what abt the selinux settings.. ideally either the selinux be disabled or appropriate selinux rules should be enabled for gluster to work from qemu...
06:02 deepakcs bala, i don't think that is taken care of as part of 'enable for virt. use' option
06:04 deepakcs bala, i was wondering if that should be taken care of.. as part of 'enable for virt.use' or it shud be part of vdsm bootsrap where it alreayd enables some selinux bools
06:04 deepakcs and we add more there for gluster
06:09 raghu joined #gluster-dev
06:22 bala deepakcs: there is an ui action called 'optimize for virt' when selecting gluster volume
06:22 bala deepakcs: this will do necessary set calls thru vdsm.gluster.cli
06:33 deepakcs bala, yes i know.. i was referring to that only till now :)
06:33 deepakcs bala, so all it does IIUC is set the uid, gid and group , as u mentioned above, rite ?
06:34 deepakcs bala, Q was.. whether ' optimize for virt'  should be extended to take care of selinux settings for the gluster volume as well  ?
07:07 bala deepakcs: selinux support in glusterfs is not yet available.  so its required to disable selinux
07:13 vpshastry left #gluster-dev
07:17 vpshastry joined #gluster-dev
07:28 hagarth joined #gluster-dev
07:39 bgpepi joined #gluster-dev
08:22 sghosh1 joined #gluster-dev
08:30 badone joined #gluster-dev
08:46 aravinda_ joined #gluster-dev
08:48 mohankumar joined #gluster-dev
08:56 gbrand_ joined #gluster-dev
09:00 sahina joined #gluster-dev
09:08 bala joined #gluster-dev
09:11 gbrand_ joined #gluster-dev
09:26 vpshastry joined #gluster-dev
09:39 puebele joined #gluster-dev
09:52 sripathi joined #gluster-dev
09:58 puebele joined #gluster-dev
10:02 aravindavk joined #gluster-dev
10:07 sripathi joined #gluster-dev
10:07 an joined #gluster-dev
10:16 hagarth joined #gluster-dev
10:32 mohankumar joined #gluster-dev
10:46 aravinda_ joined #gluster-dev
10:48 aravinda__ joined #gluster-dev
10:57 aravindavk joined #gluster-dev
11:11 hagarth joined #gluster-dev
11:14 sahina joined #gluster-dev
11:25 vpshastry joined #gluster-dev
12:00 jdarcy joined #gluster-dev
12:00 johnmark greetings!
12:00 johnmark #startmeeting
12:01 johnmark doh, no zodbot in here
12:01 johnmark maybe we should move to #gluster-meeting
12:02 jdarcy Damn, bugzilla is slow.
12:04 johnmark no shit :(
12:05 * jdarcy wonders if "engstats.redhat.com" has anything to do with it.
12:05 johnmark is that what firefox is hanging on?
12:06 jdarcy Seems to be featuring prominently while I wait for a page to finish loading.
12:08 johnmark *sigh*
12:12 jdarcy Awfully quiet in here.
12:14 jdarcy I'm really not convinced that the open-behind or synctask stuff should go into 3.4 at this point.
12:16 * johnmark was hoping we could hash that out here
12:16 johnmark hagarth_: you around?
12:16 hagarth joined #gluster-dev
12:16 johnmark hagarth: speak of the devil :)
12:16 * hagarth looks around ;)
12:16 johnmark hagarth: howdy
12:16 jdarcy (repeating) I'm really not convinced that the open-behind or synctask stuff should go into 3.4 at this point.
12:16 hagarth johnmark: doing good, how goes there?
12:17 johnmark I'm well - I'm in California, where it
12:17 johnmark 's 4:17 am.
12:17 johnmark I don't know what Avati's excuse it ;)
12:17 hagarth jdarcy: agree with you. I don't think the implementations have matured enough.
12:17 johnmark hagarth: ok
12:17 jdarcy hagarth: Also, we *know* that some of the synctask changes have triggered instability.
12:18 johnmark jdarcy: that's a point against
12:18 hagarth jdarcy: shall we disable open-behind by default in 3.4.0?
12:18 jdarcy I definitely think we should.
12:18 johnmark sounds like a consensus
12:18 johnmark what is the synctask stuff?
12:19 hagarth jdarcy: yeah, synctask is too intrusive a change. Don't know how we can minimize the side effects easily.
12:19 johnmark so I guess the question is, do we rebase on a more recent master?
12:19 jdarcy johnmark: A lot of the stuff in glusterd has been converted to do stuff using sync ops instead of the Old Way.  TBH I'm not sure why.
12:19 johnmark jdarcy: ok
12:20 hagarth jdarcy: any thoughts on how to mitigate synctask ?
12:21 jdarcy I don't think we should rebase.
12:22 jdarcy How large is the set of things we'll need to backport if we don't rebase?
12:23 hagarth not rebase the synctask changes to release-3.4?
12:23 kkeithley won't the things we care about merge cleanly — or mostly cleanly — at this point?
12:23 jdarcy I mean leave the 3.4 branch as it is, except for specifically backported patches - which, as Kaleb points out, should apply cleanly in most cases.
12:23 johnmark ok
12:24 hagarth jdarcy: yeah, that should happen mostly clean at this point.
12:24 hagarth my only concern is the synctask'd volume start
12:24 jdarcy The op-version/volgen changes should be in that set, along with the open-behind refactoring (but with the functionality disabled).
12:24 johnmark hagarth: is that currently in alpha?
12:24 hagarth it can have a detrimental effect upon a reboot
12:24 hagarth johnmark: yeah
12:25 johnmark ah, ok
12:25 hagarth the way synctask'd glusterd exists today, i think it is a scalability blocker
12:25 jdarcy I think there was also a set of changes in AFR that we should probably consider (fd-reopen stuff).
12:25 johnmark hagarth: is that easy to back out?
12:26 jdarcy hagarth: You mean it's a scalability blocker *with* synctask changes that are already in 3.4?
12:26 hagarth jdarcy: yeah!
12:26 jdarcy Crud.
12:26 hagarth since everything happens serially, our transaction would become O(n)
12:26 johnmark yikes
12:27 jdarcy Do we have specific changes on deck to ameliorate that, or would it be easier to back out?
12:27 hagarth we need to at least sort that out and avoid further synctasks getting into 3.4
12:27 hagarth let me check with kparthas on that, he had a plan to improve this serial behavior
12:27 johnmark hagarth: that raises the question of whether synctask'd volume start can be backed out or should continue
12:28 hagarth backing out might not be very straightforward as I understand, let me check that possibility nevertheless.
12:28 johnmark hagarth: ok
12:29 johnmark ok, so sounds like we've decided a couple of things
12:29 jdarcy So, starting position: 3.4 as is, plus op-version stuff, plus critical AFR fixes, plus or minus synctask stuff (according to what Vijay and Krishnan determine).
12:29 johnmark cool
12:29 jdarcy Oh, plus open-behind refactoring but not open-behind enabled.
12:29 hagarth jdarcy: rdma-cm too?
12:29 johnmark jdarcy: I'm really curious about the effects of open-behind
12:30 johnmark especially after reading Avati's red flags
12:30 jdarcy hagarth: That's the $64K question.  I kind of want to say we're too late, but there'll be howling from the users.
12:30 hagarth jdarcy: absolutely, I am concerned about that. Let us get it in and solicit feedback?
12:30 johnmark jdarcy: will there though?
12:30 jdarcy Is it safe to say that the RDMA-CM changes will only affect people who install the glusterfs-rdma RPM?
12:31 johnmark jdarcy: oh with RDMA-cm yes, you're right, there will be
12:31 jdarcy johnmark: If we don't show some signs of progress, then yes.  My sense is that RDMA users (or would-be users) are already very frustrated with us.
12:31 hagarth jdarcy: yeah
12:31 johnmark agreed
12:32 jdarcy hagarth: OK, so if we can get RDMA-CM to pass at least basic tests (who has that hardware BTW?) then would you say we can include it?
12:32 johnmark jdarcy: I thought shak's team has that hardware now
12:33 jdarcy Our starting point for RDMA is that users already think it's unusable.
12:33 hagarth jdarcy: my vote would be for that
12:33 johnmark jdarcy: so we can only go up fromhere :)
12:33 jdarcy johnmark: Exactly.  We wouldn't be doing any harm.
12:33 johnmark cool
12:33 hagarth i think we should be able to get some gear
12:33 johnmark hagarth: in BLR?
12:33 johnmark or Westford?
12:34 hagarth johnmark: yeah, there's some gear in BLR but I think it's now re-purposed to something else
12:34 jdarcy IIRC, Iowa and at least one other has semi-offered to help us test IB stuff.
12:34 johnmark hagarth: gah
12:34 johnmark jdarcy: yes they have. I can ask them
12:34 jdarcy That's sort of why I've spent so much time trying to keep Iowa happy BTW.
12:34 kkeithley we do have a little 4 node cluster with IB, and there's a melanox switch somewhere that we loaned out and should claw back.
12:34 hagarth johnmark: I can work on getting that freed up for a few days.
12:35 johnmark kkeithley: could you appropriate the 4-node cluster with IB whenever you want?
12:35 jdarcy Right, Harvard too, though James's departure might have put a spanner in that.
12:35 johnmark hagarth: cool
12:35 johnmark jdarcy: actually no. sjoeboo is helping
12:35 johnmark and Wisconsin has finally come through, so we may have multiple options
12:36 kkeithley the machines a gqaib01-04. The name suggests that QA owns them but I believe they're unused
12:36 kkeithley s/the machines a/the machines are/
12:36 hagarth my bigger concern is overall testing .. should we divide components amongst a bunch of volunteers and run regression for those components?
12:36 jdarcy Crud.  I never caught up with Remzi @ FAST.
12:37 johnmark jdarcy: bummer. that would have been nice, but you're only single-threaded ;)
12:37 jdarcy hagarth: I think we should.
12:37 johnmark hagarth: +1
12:37 johnmark we're at the stage in the process where we can set up a testing scripts page
12:37 hagarth I am in favour of getting glusterfs-tests to cover regression
12:37 johnmark and outline various scenarios to test against
12:37 jdarcy I feel a dev-summit hackathon coming on.
12:38 johnmark indeed
12:38 johnmark ok, so sounds like the beta release will wait on rdma-cm + some specific backports
12:38 johnmark and we'll wait to see about synctask'd vol start
12:39 johnmark when will the rdma-cm patches be applied?
12:39 hagarth glusterfs-tests + commit tests should give us good regression coverage going forward
12:39 johnmark ok
12:39 jdarcy How about if Vijay and Kaleb send me their specific lists (including back vs. forward decision for synctask) and I'll publish a combined result by EOD today?
12:39 johnmark jdarcy: awesome
12:40 hagarth johnmark: before the end of this week, we should get rdma-cm in.
12:40 kkeithley My specific lists?
12:40 jdarcy EOWD = End Of Westford Day
12:40 johnmark hagarth: cool. so realistically we could have a beta out early next week
12:40 johnmark jdarcy: heh
12:40 jdarcy kkeithley: Things you think should be backported to the 3.4 branch that aren't there already.
12:40 johnmark who wants to write up a summary and send to gluster-devel?
12:41 hagarth jdarcy: sure, I'll send out my list.
12:41 jdarcy johnmark: You.
12:41 johnmark I can do that as long as someone can check my info
12:41 johnmark jdarcy: heh
12:42 hagarth who will own the test coverage page for components?
12:42 johnmark jdarcy: happy to do that. I'd like to see your combined task list before I do that
12:42 johnmark er combined backport list
12:44 jdarcy hagarth: I nominate you or Kaleb, because either of you would do a 200% better job than I would.
12:44 johnmark hagarth: I can help with that
12:44 jdarcy Can we draft someone from QA?
12:44 johnmark jdarcy: for 3.3, someone from the RHEL team helped out
12:44 johnmark I'm trying to remember their name...
12:45 johnmark but yeah, that would make sense
12:45 hagarth johnmark: cool, let us at least put together a list of components
12:45 johnmark hagarth: ok
12:45 hagarth jdarcy: would be difficult to get somebody from QA
12:45 * johnmark grumbles
12:46 jdarcy Long term, we need to fix that (i.e. get someone from QA more involved in upstream).  Not today, I guess.
12:47 johnmark jdarcy: +1000
12:47 hagarth jdarcy: I would love to get more developer involvement in automated tests too
12:47 hagarth and community involvement as well
12:48 johnmark hagarth: this is something that hopefully some member companies will step up and provide assistance on
12:48 sgowda joined #gluster-dev
12:48 jdarcy hagarth: Yes, we really need a (nearly) full-time test-oriented developer.  I'd kind of be glad to do that myself, but I don't think that would really work because of other obligations.
12:49 hagarth jdarcy: likewise here.
12:49 johnmark hagarth: something we need to bring up with Rich
12:49 hagarth johnmark: absolutely
12:49 johnmark but yeah, putting together test plans and making it easier for "outsiders" to participate would be a great start
12:49 johnmark and that's part of my job
12:50 jdarcy OK, anything else we need to decide right here+now, or should we go execute?
12:50 hagarth johnmark: if users can provide test cases about what they'd like to see working in a release always, that would be a great win.
12:51 johnmark hagarth: agreed
12:51 hagarth jdarcy: looks good, let us keep the momentum going. I will take a 35 minute break before my next meeting ;)
12:51 johnmark hagarth: please do :)
12:51 johnmark jdarcy: yes, let us execute
12:52 johnmark adjourn?
12:52 jdarcy OK.
12:52 johnmark aight. until next week
12:53 hagarth johnmark: let us capture the AIs too
12:53 hagarth and circulate the minutes
12:53 johnmark hagarth: yup
12:53 johnmark I can circulate the minutes, but I want to see what jdarcy comes up with by EOWD
12:54 hagarth I will send out my list soon
12:54 johnmark jdarcy: so you're compiling list of backports and possible backouts
12:54 johnmark hagarth: you and kkeithley are sending in your lists to jdarcy
12:54 jdarcy johnmark: Correct.
12:55 johnmark and by tomorrow, we should be able to set a beta timeframe
12:55 hagarth johnmark: right
12:55 johnmark cool
12:55 kkeithley okay
12:56 johnmark and then I'll take all that and summarize for gluster-devel
12:56 kkeithley jdarcy: you still planning to come to the office today?
12:57 johnmark kkeithley: I think jdarcy has left the building
12:57 jdarcy kkeithley: Yep.
13:02 johnmark speaking of testing, I noticed this - http://review.gluster.org/#change,4537
13:03 johnmark a QEMU test, and there seems to be difficulty in implementing an automated test for that given our current setup
13:08 kkeithley is that because we don't have qemu/kvm bits installed on build.g.o?
13:14 johnmark kkeithley: I believe so, yes
13:14 johnmark and because our setup is Xen-based
13:15 overclk joined #gluster-dev
13:25 johnmark joined #gluster-dev
13:31 sgowda joined #gluster-dev
13:32 kkeithley hagarth: UFO priorities meeting!
13:32 hagarth kkeithley: joining in
14:00 vpshastry joined #gluster-dev
14:15 jdarcy joined #gluster-dev
15:06 bgpepi joined #gluster-dev
15:28 edward1 joined #gluster-dev
15:34 wushudoin joined #gluster-dev
15:42 bala joined #gluster-dev
15:49 jdarcy joined #gluster-dev
15:50 jbrooks joined #gluster-dev
15:58 vpshastry joined #gluster-dev
16:26 puebele joined #gluster-dev
16:48 hagarth joined #gluster-dev
17:47 hagarth joined #gluster-dev
18:27 gbrand__ joined #gluster-dev
19:02 jdarcy joined #gluster-dev
19:20 vpshastry joined #gluster-dev
19:42 _Bryan_ joined #gluster-dev
19:53 JoeJulian @later tell deepakcs I started that to be a library interface to the cli. Then the library interface was announced and I stalled on doing anything further.
19:53 glusterbot JoeJulian: The operation succeeded.
20:13 jdarcy joined #gluster-dev
20:14 gbrand_ joined #gluster-dev
20:23 hagarth joined #gluster-dev
21:07 jdarcy joined #gluster-dev
22:23 hagarth joined #gluster-dev
23:01 jbrooks joined #gluster-dev
23:23 sghosh joined #gluster-dev
23:36 gbrand_ joined #gluster-dev

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