added storage namespace validation on non-readonly bare repo creation

[tkalir]

Closes #3165

Background

Currently bare repo creation doesn't check if namesapce storage is writable \ if a lakefs repo already exists there

Bug Fix

In Controller.go\CreateRepository, previously the code was -

1. if bare repo, create and return
2. if non-readonly repo, do namespace validation
   I only switched them places, so namespace validation happens also for non-readonly bare repos. nothing else is supposed to change. (but that does mean that bare repos create a dummy object at namespace root now, like other repos - see Controller.go\ensureStorageNamespace)

Testing Details

I added a system test to check that creating a bare repo in same namespace as existing repo returns an error. we can remove the test if it's unnecessary, but it will help to check the code.

Contact Details

tkalir@gmail.com \ Tamar Kalir on slack

[N-o-Z]

Hi @tkalir great job!

Though this is a small PR I'm requesting changes for the test as this is your first PR and I think this can be a good learning experience going into the lakeFS code.

[N-o-Z]

That's a great test - but note you could have reused the code of "use same storage namespace twice" and parameterize the test.
Look at the example of catalog_test.go:564 as reference

[tkalir]

cool, thanks for the feedback. I did that and added the parameter (isBareRepo=true\false) into the subtest name, thought it might be helpful.

[arielshaqed]

Thanks @tkalir for this contribution! You have clearly given much thought to how to perform this change.

Unfortunately I am blocking this as I have second thoughts about the issue. In brief, the intent behind this change is to prevent some ways to use a plumbing command. I believe that this will prevent users from pursuing some perfectly reasonable flows.

Fortunately the core team is meeting 🥳 this week (hi, @N-o-Z)! So we will discuss it and resolve one way or another. In the meanwhile, I apologize for inducing delay.

[arielshaqed]

Okaaaaayyyy.... Obviously it's the simplest things that take the most discussions. Sorry about the time this took After discussing with other stakeholders, I am removing my objections to this feature. Let's continue!

I think @N-o-Z is still blocking for relevant reasons. so over to you, N!

[N-o-Z]

@tkalir Thanks!
Need to merge latest master from repository and resolve conflicts before we can continue to merge this back.
For future reference - please avoid from amending commits (and pushing force) or rebasing during the review process. It makes it much harder to track the changes this way.
The best way is to add additional changes in new commits.

[N-o-Z]

Note that the unit test is failing

[N-o-Z]

@tkalir hi, please let us know if you still intend to work on this. In order to merge it you'll first need to resolve the conflicts

[tkalir]

@N-o-Z hi, sorry for the delay, I will work on it soon. I understand that I need to resolve the conflicts and update the failing unit test according to the change I made.
I encountered some issues with running the tests locally (with "make test", not running individual tests) so it also took some time to try and resolve that. I will ask on slack if I need further help. Thanks for the follow up.