https://lakefs.io/ logo
Join Slack
Powered by
Hi, I thought I should ask the question here befor...
# help
c
Hi, I thought I should ask the question here before I open an issue. When I try to create a policy that already exists, a new policy gets created successfully (updated 
creation_date
and status 
201
). I am using same id and policy statement. This happens both when using the 
lakectl
api 
0.55.0
, the Golang api 
v0.89.0
, and 
curl
. I expected to get a 
409
status code, as described in the API. Is this intended behaviour? Thanks!
e
Hi @Cristian Caloian I remember coming across this issue a while back Give me a moment to look for it
lakefs 1
@Cristian Caloian I'm sorry for the delayed response I found several related issues (most recent) and took some time to read through them and parse all the related changes as well as try to repro the issue locally
When trying this locally using 
curl
, I get an HTTP status 409 with an "Already exists" message in the body, which would be the expected behavior
Copy code
$ curl -v '<http://127.0.0.1:8000/api/v1/auth/policies>' \                                                                                                                                                             
  -H 'Cookie: XXXX' \
  -H 'accept: application/json' \
  -H 'content-type: application/json' \
  --data-raw '{"statement":[{"action":["fs:List*","fs:Read*"],"effect":"allow","resource":"*"}],"id":"test"}' \
  --compressed
*   Trying 127.0.0.1:8000...
* Connected to 127.0.0.1 (127.0.0.1) port 8000 (#0)
> POST /api/v1/auth/policies HTTP/1.1
> Host: 127.0.0.1:8000
> User-Agent: curl/7.79.1
> Accept-Encoding: deflate, gzip
> Cookie: XXXX
> accept: application/json
> content-type: application/json
> Content-Length: 94
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 409 Conflict
< Content-Type: application/json
< X-Content-Type-Options: nosniff
< X-Request-Id: f38f22b0-d6d8-4905-8d66-a33ecc4ba136
< Date: Mon, 30 Jan 2023 16:44:20 GMT
< Content-Length: 29
<
{"message":"Already exists"}
lakeFS 
0.89.0
was released recently I'd suspect maybe the version of 
lakectl
doesn't support the separation between endpoints for create/update, but if you're seeing the same behavior with using 
curl
directly, that probably rules that out
Are you able to share details re your specific setup and perhaps the 
curl
command you tried so I can further investigate?
c
Hi @Elad Lachmi I am using a similar 
curl
command as you pasted above. Do you think I get this behaviour because our version of LakeFS is 
0.61.0
?
e
Hi Oh, you're on version 
0.61.0
? For some reason I thought you wrote you were on version 
0.89.0
Let me check when that was released vs. when the fix commit was done One moment
Sorry for the confusion
c
It was the LakeFS Golang API that was on version 
0.89.0
. It is my bad, I should’ve make it clear. The deployed LakeFS server is 
0.61.0
.
e
Yeah, so 
0.61.0
was released before this fix
The fix was first included in 
0.83.3
dancing lakefs 1
c
Okay, that explains it. I am looking at the code for that version now and it seems that it was the intended behaviour.
Okay. In this case I am handling it manually by checking if the policy exists. I will test it out on the new deployment, but it seems that it will work as expected (fail with Conflict status code if policy exists).
I have one more question regarding the Golang API. I see there are two directories 
api
and 
auth
. But 
api
contains all the functionality for 
/auth
endpoints. Is it okay to use only code from 
api
?
e
I think that's the logical behavior I feel that's what I'd expect the result to be, once create and update were separated, while having create and update on the same endpoint and HTTP verb is looking for trouble 🙂
I believe using 
api
is the way to go, but I'm not in all of the details of this area of the code base, so let me check that for you I'll reach out to a colleague, so it may take a few minutes I'll let you know as soon as I have an update
👍 1
c
Here are the specifications I am talking about, just in case.
e
Ok, so the 
auth
spec is for use with an external API It only defines the contract and leaves to the API all of the implementation details - would be very hard to implement an API that will provide the built-in functionality The mirrored endpoints in the lakeFS spec are what's implemented inside of lakeFS, so that would probably be the way to go
c
Great! Thanks for clarification!
e
Sure, np Feel free to reach out if you have any other questions
🙌 1
Open in Slack
PreviousNext
Powered by