Camelia, the Perl 6 bug

IRC log for #gluster-dev, 2013-09-17

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

All times shown according to UTC.

Time Nick Message
00:06 awheeler joined #gluster-dev
00:08 awheeler_ joined #gluster-dev
00:19 awheeler joined #gluster-dev
02:40 lalatenduM joined #gluster-dev
02:48 vshankar joined #gluster-dev
03:10 bharata-rao joined #gluster-dev
03:11 kshlm joined #gluster-dev
03:17 shubhendu joined #gluster-dev
03:26 asias joined #gluster-dev
03:39 kshlm joined #gluster-dev
04:23 ppai joined #gluster-dev
04:27 itisravi joined #gluster-dev
04:55 aravindavk joined #gluster-dev
05:09 hagarth joined #gluster-dev
05:13 bala joined #gluster-dev
05:25 ndarshan joined #gluster-dev
05:38 ajha joined #gluster-dev
05:40 bulde joined #gluster-dev
05:44 kanagaraj joined #gluster-dev
05:53 raghu joined #gluster-dev
06:10 rgustafs joined #gluster-dev
06:13 sac`away` joined #gluster-dev
06:28 _ilbot joined #gluster-dev
06:28 Topic for #gluster-dev is now Gluster Development Channel - http://gluster.org | For general chat go to #gluster | Patches - http://review.gluster.org/ | Channel Logs - https://botbot.me/freenode/gluster-dev/ & http://irclog.perlgeek.de/gluster-dev/
06:46 mjrosenb so i've noticed for a while (since 3.1 at least) that building the server on freebsd with optimizations crashes reliably, but with debugging turned on, it has been pretty stable.
06:53 sac`away` joined #gluster-dev
06:53 ndarshan joined #gluster-dev
06:53 bulde1 joined #gluster-dev
06:53 lkoranda joined #gluster-dev
07:21 ndarshan joined #gluster-dev
08:46 ndarshan joined #gluster-dev
09:12 deepakcs joined #gluster-dev
09:23 hagarth joined #gluster-dev
09:36 ppai joined #gluster-dev
09:39 badone joined #gluster-dev
09:48 ppai joined #gluster-dev
09:59 hagarth joined #gluster-dev
10:25 ndarshan joined #gluster-dev
10:40 ababu joined #gluster-dev
10:41 edward1 joined #gluster-dev
11:18 hagarth joined #gluster-dev
12:03 hagarth joined #gluster-dev
12:45 awheeler joined #gluster-dev
12:46 awheeler_ joined #gluster-dev
13:28 jclift joined #gluster-dev
13:48 rgustafs joined #gluster-dev
14:19 jbautista- joined #gluster-dev
14:32 hagarth joined #gluster-dev
15:06 ababu joined #gluster-dev
15:22 jbautista- joined #gluster-dev
16:24 bulde joined #gluster-dev
16:26 kkeithley1 joined #gluster-dev
16:45 hagarth joined #gluster-dev
16:57 bala joined #gluster-dev
17:13 bala joined #gluster-dev
18:12 badone joined #gluster-dev
18:37 badone joined #gluster-dev
18:51 avati_ bfoster: foster: any comments on http://review.gluster.org/5770 ?
18:53 lkoranda joined #gluster-dev
18:56 foster avati_: will take a look...
19:00 avati_ foster: also wanted to touch base on qemu xlator.. now that it is merged in master, what next steps would be..
19:04 foster avati_: +1 incoming
19:04 foster avati_: yeah, meaning to catch up with you on the same topic actually
19:06 foster i have some code that enables basic clone support
19:07 avati_ ..
19:07 avati_ can you briefly describe what and how it works?
19:07 foster yeah...
19:08 foster - block-format is updated to take an optional "3rd parameter" that specifies a backing image
19:09 foster - this is passed into qemu as the backing image in a format that includes the gfid
19:10 foster - the qemu backend gluster driver basically redirects this I/O to the backing image via anonymous fds
19:10 foster the sticking point I have right now is I either have to pass in a gfid for the backing image
19:10 foster or require that the backing image is in the same directory so I can safely look it up and get the gfid
19:11 avati_ ok..
19:11 foster so basically a user can say: setfattr -n block-format -v "qcow2:1GB:baseimage" ./newimage
19:12 foster and new image starts out as a clone as baseimage
19:12 avati_ doesn't qemu allow for specifying a snapshot name in the backend file?
19:12 avati_ reason i ask:
19:13 avati_ imagine you have a running VM, and want to take a snapshot and create a clone (or just create a clone of the running image)
19:13 avati_ how does the sequence of operations look for this use case? (while the VM is running)
19:13 foster what I have so far doesn't cover that case
19:14 foster I'm actually not aware of something that would let me specify the snapshot as a base
19:14 avati_ the backing file can be raw/qcow2/qed/whatever right?
19:14 avati_ and is expected to be a read-only image?
19:14 foster I've only tested qcow2, but I think so
19:15 avati_ but this by itself is great progress
19:16 avati_ if the part you describe already works, it would be good to get it reviewed and merged.. it's a good progress indicator
19:17 foster ok, I was thinking of posting it but I was trying to figure out something better than passing in the gfid
19:17 foster the "filename in this dir" thing seems a bit more user friendly at least
19:18 avati_ seeing how btrfs API looks for creating a clone
19:18 foster it's an ioctl from the user perspective isn't it?
19:18 avati_ yes, but what the parameters are
19:19 avati_ OK, two file descriptors
19:19 avati_ one is the file desctiptor of the cloned file, the other of the base image
19:20 avati_ ioctl() performed on the clone file, base image fd passed as ioctl paramter
19:20 foster hmm, that would make it cleaner I suspect
19:21 avati_ wondering if we can trap the ioctl through fuse
19:21 avati_ and make cp --reflink just "work" on gluster mount
19:21 foster yeah, I took a look at that the other day actually and had the same thought
19:22 avati_ i recall fuse had some support for ioctl, not sure how comprehensive it is
19:23 foster it does, but I'd have to take a closer look at it
19:24 foster what is the underlying use case for "external snapshot?"
19:24 foster is it the clone of a snapshot use case?
19:25 avati_ yes, for making clones of running images
19:25 avati_ clone support in general
19:26 avati_ it is really up to us how we use external snapshot ability as a tool to build a workflow
19:26 avati_ i think thera are primiarly 2 use cases
19:26 avati_ 1. cp --reflink <file1> <file2> kind of use case
19:27 avati_ 2. cinder use case
19:27 foster heh, yeah
19:27 foster I'm not really sure what cinder has the expectation or capability to do
19:28 avati_ i image we would also need some minimal read-only enforcement of the backing image
19:29 avati_ wanted to share the cinder API link.. github is down :|
19:29 avati_ "major service outage" ... oops!
19:29 foster :P
19:29 foster ok, I mean I was thinking a bit about the "external snapshot" behavior using clones
19:30 foster but it seems rather cumbersome to try and manage
19:31 avati_ you mean clones using "external snapshot"?
19:32 avati_ the way i see it, external snapshot by itself is not a goal
19:32 avati_ clones are the goal
19:32 foster that's part of what I was asking
19:32 avati_ and the hope is qemu's external snapshots will get us closer to the goal
19:33 lpabon joined #gluster-dev
19:33 foster ok, by qemu external snapshot, you're talking about "backing image?"
19:33 avati_ yes, using backing images
19:34 foster ok, I was thinking the external snapshot behavior buys the clone of a snapshot functionality
19:35 avati_ i think it would, if we can specify the backing image as "file + snapshot_id"
19:35 avati_ that way we get a stable read-only base
19:35 avati_ if not the original file can get edited further by the user
19:35 foster but the flip side is that it seems a lot to build on top of a qemu translator
19:36 avati_ which do you refer to by "a lot"?
19:36 foster i.e., where to put the files? how would one clone a snap, if not "goto snap, clone?"
19:37 avati_ i was thinking of using the scheme described in the fiemap based snapshot writeup
19:37 avati_ with the approach described in that writeup, we don't need backing image to be "file + snapshot_id"
19:38 foster hrm, i thought that's what it was proposing
19:39 avati_ ah, ok..
19:39 foster take a snap, stick a new file on top..?
19:39 avati_ then, the internal snpashots would not be of much use if you want clones
19:39 avati_ i think internal snapshots and external snapshots might be for two different use cases
19:40 avati_ itnernal - for testing a change, and having a point to roll back to if things break
19:40 foster makes sense
19:40 avati_ external - for freezing the current state in order to make replicas/clones
19:41 avati_ the cinder API gives some perspective, it has calls like:
19:41 avati_ create_snapshot_in_volume()
19:41 avati_ create_clone_from_snapshot() etc.
19:41 avati_ for cinder use case, i don't think we would need internal snapshots at all
19:42 avati_ i may be wrong, but that was my impression
19:43 foster hmm, is create_clone_from_snapshot() really a clone+backing image relationship? or a copy?
19:44 foster i.e., "spin me up a new vm disk based on this source"
19:45 avati_ right..
19:45 avati_ you could do a copy as a trivial implementation
19:45 avati_ but you really need copy on write (i.e, backing image + delta file to absorb new writes)
19:46 avati_ https://github.com/openstack/cinder/​blob/master/cinder/volume/driver.py
19:47 avati_ create_volume(), create_volume_from_snapshot(), create_cloned_volume()
19:48 foster so the create_cloned_volume() thing makes sense
19:48 avati_ and within cinder there is also the use case for copy_image_to_volume() and copy_volume_to_image() [for server offloaded copying, which too might be achieved through COW]
19:49 foster that's the many vms off a single base image case, right?
19:49 avati_ many vms off a single base image = create_volume_from_snapshot() and create_cloned_volume()
19:50 foster ok, I'm not following the purpose of create_volume_from_snapshot()
19:50 avati_ i think the copy_[image,volume]_to_[volume,image] is for glance integration (image catalog service)
19:50 avati_ to copy data efficiently without involving the control node
19:51 avati_ lpabon: your help would be appreciated here :) hope i am not making things up :D
19:51 avati_ i think our interest is primarily the first three APIs
19:51 avati_ create_volume(), create_volume_from_snapshot(), create_cloned_volume()
19:52 avati_ oops, missed create_snapshot()
19:52 avati_ 4 actually
19:52 avati_ create_cloned_volume() can be decomposed into create_snapshot() + create_volume_from_snapshot()
19:52 lpabon lpabon: catching up
19:54 foster an example/existing implementation of those apis might be informative too
19:54 avati_ foster: if you image snapshot/clones to all originate from a single root of original (first base image), snapshot = intermediate (read-only) node, volume = leaf (read-write) node
19:54 avati_ snapshot by itself is not usable until you create a new leaf node with snapshot node as parent
19:55 avati_ let me try to create an example
19:56 avati_ disk1 = create_volume("rhel6");
19:56 avati_ install rhel6 on disk1
19:56 avati_ install apache on disk1
19:56 avati_ create_snapshot(disk1, "web-server")
19:57 avati_ disk2 = create_volume_from_snapshot("foo.com", "web-server");
19:57 avati_ disk3 = create_volume_from_snapshot("bar.com", "web-server");
19:58 lpabon finally cought up
19:58 foster ok, I'm thinking of that functionality as "base image"
19:58 foster so maybe it's just the terminology that confuses me
19:58 avati_ foster: base image is a necessary part
19:59 lpabon ok, at this stage: disk1 = create_volume("rhel6"); there is one file created on glusterfs
19:59 avati_ for example "web-server" would be a base image for all of "rhel6" "foo.com" and "bar.com"
19:59 lpabon then create_snapshot(disk1, "web-server"), keeps the old file X and any new write to 'disk1' go to a new file Y
20:00 lpabon Then disk2 = create_volume_from_snapshot("foo.com", "web-server"); has a base of X to a new delta file Z
20:00 avati_ foster: notice that create_snapshot(disk1, "web-server") spat out a new file which can be used as a base image for "foo.com" and "bar.com"
20:00 lpabon right?
20:00 avati_ lpabon: right!
20:00 lpabon i see the light :-D
20:01 lpabon the only thing is, I am not sure if this is now nescessary for Cinder, since it supports hypervisor assisted snapshots
20:01 lpabon maybe be good for many other use cases, but i think cinder may already have a solution in Havana
20:02 avati_ lpabon: hmm, is kvm the only hypervisor in openstack/havana?
20:02 foster ok, the behavior your describing makes sense
20:02 lpabon Ah good point, no
20:02 foster you're
20:02 foster but it sounds like this can all be done with clones..?
20:03 avati_ foster: sure it can.. what i meant was this:
20:03 lpabon Linux based:  xen, and virutalbox.. Also supports containers: lxc and docker
20:03 avati_ disk1 = create_image("rhel6");
20:03 avati_ install rhel6 on disk1
20:04 avati_ now if i do create_cloned_volume("foo.com", "rhel6"), you cannot use disk1 as the backing image
20:04 lpabon hmm, i wonder if hypervisor assisted also supports Xen, which is really the only other 'real' hypervisor on linux it supports
20:05 avati_ because disk1 is still a read-write "head" of "rhel6"
20:05 lpabon i'll take a look a the code
20:05 avati_ foster: does that make sense?
20:05 foster yeah
20:06 foster 15:52 < avati_> create_cloned_volume() can be decomposed into create_snapshot() + create_volume_from_snapshot()
20:07 foster so wouldn't you make disk1 a snapshot and create two new files?
20:07 lpabon foster: i think it is ... disk1 points to the new file Y which depends on the snapshot X which 'was' disk1
20:07 avati_ foster right.. so taking a snapshot now means convering current file into backing image and creating new 'head' file
20:08 avati_ foster: and not the internal snapshot which already works in the xlator
20:08 foster makes sense
20:08 lpabon seems that may require some type of Garbage collector
20:08 avati_ foster: unless we start allowing backing image = backing file + snapshot_id, and create a snapshot in the original file to be used as backign image
20:09 avati_ foster: i guess that is a distraction.. for now as long as we say snapshot = convert current file into a backing image, everything else can be built on top
20:09 avati_ lpabon: you mean garbage collection of intermediate backing files?
20:10 foster right, the potential need of an external snapshot in gluster is what I'm not following
20:10 lpabon yeah, if new files start being created, at some point, for example, file X and file Y may no longer have any references, and may need to be collapsed
20:11 avati_ foster: external snapshot == make current file a backing file, and use a new head file in place.. we clearly need this only for supporting clones
20:12 avati_ foster: there is little use of external snpashots by itself as a feature. it can be useful though, if we offer guarantee that backign file is enforced read-only
20:12 foster I was basically thinking of external snapshot as doing what the current snapshot implementation does, using qemu clones
20:13 avati_ i'm feeling we may be confusing terminology, do you think getting on a call would help?
20:13 foster sure
20:14 avati_ dial: 18004518679, meeting: 7244728284
20:14 avati_ lpabon: can you dial in too?
20:14 lpabon sure
20:17 avati_ we're in
20:17 avati_ lpabon: you joining?
20:18 lpabon lol, can't find my phone.. looking..
20:20 lpabon got it
20:38 lpabon http://titanpad.com/glusterfs-qemu
21:32 badone joined #gluster-dev
21:40 [o__o] left #gluster-dev
21:42 foster avati_: lpabon: good discussion, thanks!
21:42 [o__o] joined #gluster-dev
21:44 [o__o] joined #gluster-dev
22:39 wushudoin joined #gluster-dev

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