-
Notifications
You must be signed in to change notification settings - Fork 360
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
Add ability to specify Access Key ID and Secret Key in setup endpoint #908
Comments
Could you expand on the use-case, please? I'm curious because I am not aware of many systems that allow injecting secrets into new users. E.g. with AWS I usually face a similar difficulty: either use pre-existing credentials or create new ones, extract those and use them. We actually have code that does something similar in lakeFS. It runs as part of our system test "nessie". |
The way our CI is set up is to create database resources (postgres, ... ) first, then running tests in parallel later. All created database instances are bounded to a build, which is independent to each other. We also make sure all tests in a build are independent, stateless and should not rely on any initialization system, so configurations and credentials should be pre-determined. Other databases we are using (postgres, redis, ...) support some API to setup an account with pre-determined credential, while lakeFS does not. Of course I can use a hack to inject a key to lakeFS's postgres directly, but it is nice to have a higher level API instead. |
Thanks for the clearly explaining a use-case! I usually think of it as an S3-like system, which does not offer this ability. |
@keimoon also if you would prefer a more chat-based discussion format for questions that may come up, please join our community Slack. (Of course issues are a great way to ask for new features!) |
Makes writing some integrations much easier. Fixes #908.
We need this for integrating lakeFS with CI: an instance of lakeFS will be created before a build is run and be destroyed after that. Every time lakeFS is set up, it will create different set up Access Key ID / Secret Key so it is hard to inject those values to the test.
The text was updated successfully, but these errors were encountered: