Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

namespace prefix in KVS txn fails #1463

Closed
garlick opened this issue Apr 13, 2018 · 4 comments
Closed

namespace prefix in KVS txn fails #1463

garlick opened this issue Apr 13, 2018 · 4 comments
Assignees

Comments

@garlick
Copy link
Member

garlick commented Apr 13, 2018

I found that committing a transaction where each key contains an identical namespace prefix fails with EINVAL, e.g.

ns:job1/state
ns:job1/opts.tasks-per-node
ns:job1/walltime
ns:job1/ntasks
ns:job1/environ
ns:job1/cmdline
ns:job1/nnodes
ns:job1/input.config
ns:job1/ncores
ns:job1/cwd
ns:job1/create-time

I thought that was supposed to work.

Similarly, if lwj.0.0.1 -> ns:job1/., then the same list with that prefix fails, e.g.

lwj.0.0.1.state
lwj.0.0.1.jobs.tasks-per-node
...
@garlick
Copy link
Member Author

garlick commented Apr 13, 2018

Oh I think it's because the namespace in the commit request defaults to the primary namespace, and that doesn't match the one in the txn...

@garlick
Copy link
Member Author

garlick commented Apr 13, 2018

I think we need both of the above cases to work. If we need to explicitly set the namespace in the commit, then we have to know a priori what any symlinks along the path point to, and that sort of defeats the generality that we hoped to gain through the use of symlinks.

@chu11
Copy link
Member

chu11 commented Apr 13, 2018

this is supposed to work, and I thought I had a unit test for it. I'll see what's going on.

@chu11 chu11 self-assigned this Apr 13, 2018
@garlick
Copy link
Member Author

garlick commented Apr 13, 2018

I was confused on two counts when I opened this issue.

  1. the first case above actually works; I was confusing another failure in the logs with this one
  2. while the second case doesn't work, it's a case @chu11 and I had discussed earlier as possibly not needed for the near term at least.

Sorry!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants