inconsistent names/paths in node creation after chroot

[igor47]

here's what i'm trying:

irb(main):009:0> zk = Zookeeper.new('localhost:2181/test/service')
... lots of output ...
irb(main):010:0> zk.create(:path => 'a', :ephemeral => true, :sequence => true)
=> {:req_id=>0, :rc=>0, :path=>"0000000006"}
irb(main):011:0> zk.create(:path => '/', :ephemeral => true, :sequence => true)
=> {:req_id=>1, :rc=>0, :path=>"0000000007"}
irb(main):012:0> zk.create(:path => 'b', :ephemeral => true, :sequence => true)
=> {:req_id=>2, :rc=>0, :path=>"0000000008"}
irb(main):013:0> zk.create(:path => 'bc', :ephemeral => true, :sequence => true)
=> {:req_id=>3, :rc=>0, :path=>"bc0000000009"}
irb(main):014:0> zk.create(:path => '', :ephemeral => true, :sequence => true)
=> {:req_id=>4, :rc=>0, :path=>"0000000010"}

before i start, here is the state in zkCli:

[zk: localhost:2181(CONNECTED) 24] ls /test
[service]
[zk: localhost:2181(CONNECTED) 25] ls /test/service
[]

i expect that after i'm done, i should contain a state like this:

[zk: localhost:2181(CONNECTED) 24] ls /test
[service]
[zk: localhost:2181(CONNECTED) 25] ls /test/service
[a0000000006, 0000000007, b0000000008, bc0000000009, 0000000010]

in other words, because I chrooted, i should have all my nodes created under /test/service and the characters i put into the :path argument should be pre-pended to the sequential key name.

instead, here is what i get:

[zk: localhost:2181(CONNECTED) 28] ls /test
[service, servicebc0000000009, service0000000008, service0000000007, service0000000010, service0000000006]
[zk: localhost:2181(CONNECTED) 30] ls /test/service
[]

none of my nodes got created under /test/service; additionally, if i just use a single character as a path, that character disappears (like a and b but not bc).

on the other hand, if i set a path like /a, then i get the right behavior, with a node under /test/service called a00000000001.

am i doing something wrong? i reported a this bug also under zk-ruby/zk#77 but maybe it belongs even further upstream?

[slyphon]

I think you may be a little confused about how zookeeper in general thinks about things. When you provide a prefix for sequential nodes to be created, you are giving a znode path, and the last element acts as a prefix for the nodes being created. (I use ZK for stuff like this, since it's a little nicer to work with.)

1.9.3p429 > zk = ZK.new('localhost:2181')
 => #<ZK::Client::Threaded:70205828966460 zk_session_id=0x14414aa554b0005 ...>
1.9.3p429 > zk.mkdir_p('/foo/bar')
 => "/foo/bar"
1.9.3p429 > p = zk.create('/foo/bar/file', :ephemeral => true, :sequential => true)
 => "/foo/bar/file0000000001"

This is so you could have multiple different file-prefix-names under a given path (this is used in the shared locking implementation, with read/write locks using different prefixes).

You created ephemeral sequential keys, which can't have children (if I'm reading you right, I think you were attempting to do that).

Honestly, i've never used zookeeper like what you're describing. The use case for chroot, in my mind at least, was always isolating different environments or apps from one another, but not single paths. The use case I always imagined was:

/ns/${app}/${environment}/${task}/${sequental_nodes}

('ns' just being some kind of namespacing root for the company, or signifying that this is where service discovery is going to happen)

so for the app "dingus" running in staging, its cluster members working on frobbing widgets...

# an administrator would set up the path

/ns/dingus/staging/frobbers

and when you started up the app, each frobber would do the following:

zk = ZK.new('service-discovery:2181/ns/dingus/staging')
my_node = zk.create('/frobbers/announce', "some kind of important data", :sequential => true, :ephemeral => true)

This would create an ephemeral sequential path under the global root like /ns/dingus/staging/frobbers/announce000000000, and other nodes with the same zk connection string (i.e. service-discovery:2181/ns/dingus/staging) would see these at /frobbers.

TBH it all depends on what you're trying to do with zk.

[igor47]

i was pointing out was that omitting the prefix before creating a sequential node doesn't work. in fact, even a single-character prefix does not work. in other words:

my_node = zk.create('/a', 'data', :sequential => true)

should create a node like /a00000000 but instead creates a node like 000000000.

i tested this only when chrooted; perhaps the path 000000 does not make sense outside of a chroot, but inside one, the 00000 simply gets appended to the chroot path. in other words, if i do

zk = ZK.new('zk.boxes:2181/chroot')
my_node = zk.create('/a', 'data', :sequential => true)

i end up with node /chroot000000 on my zk server, where what i should have gotten was node /chroot/a000000 -- notice the missing /a.

[slyphon]

I'm not sure :/

I'm going to be on vacation for the next week, so I won't have time to look
into this. Does zkCli display this behavior when creating sequential nodes?

Can you use a prefix with more than one character as a workaround in the
meantime?

On Tue, Feb 11, 2014 at 6:41 PM, Igor Serebryany
[email protected]:

i was pointing out was that omitting the prefix before creating a
sequential node doesn't work. in fact, even a single-character prefix does
not work. in other words:

my_node = zk.create('/a', 'data', :sequential => true)

should create a node like /a00000000 but instead creates a node like
000000000.

i tested this only when chrooted; perhaps the path 000000 does not make
sense outside of a chroot, but inside one, the 00000 simply gets appended
to the chroot path. in other words, if i do

zk = ZK.new('zk.boxes:2181/chroot')
my_node = zk.create('/a', 'data', :sequential => true)

i end up with node /chroot000000 on my zk server, where what i _should_have gotten was node
chroot/a000000 -- notice the missing /a.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/58#issuecomment-34822602
.