Hi everyone, I'm trying to deploy lakeFS on an EC2 instance using AWS ECS. I've followed the ecs instructions found here https://docs.lakefs.io/deploy/aws.html#on-ecs and passed in the environment variables listed, and I can access the lakeFS login page. But there doesn't seem to be an easy way to specify the access key id or the secret access key when ecs makes the ec2 instance. Is there a way to configure these in ECS? Thanks for your help

Hi @Chris Weddle! Thanks for posting your question. Have you already did the initial lakeFS setup? (https://docs.lakefs.io/setup/create-repo.html)

Thanks for the quick response! I'm referring to the lakeFS credentials. When I try to do the initial setup, I just get an error that says "conflict". But ideally we wouldn't have to do the initial setup every time an ec2 instance is created, and we could start it with a pre-set Access Key ID and Secret Access Key

Where are you running your database? is it an RDS instance or you are running it on ecs?

@Tal Sofer the db is on RDS. I've been working a bit with @Chris Weddle on this issue. The key goal is so that after deploying a LakeFS Container we don't have to navigate to

http://<IP>:<Port>/setup

to do anything, but can instead go straight to

http://<IP>:Port>/auth/login

and login

Hi @Jesse Levitt! The reason I’m asking about you db is that it needs to be deployed on RDS so that your credentials survive if you restart your ecs deployment. In more details, running 

/setup

 creates an admin user with a set of credentials that are stored in the RDS instance. Every container that is configured to use that same database, shouldn’t have to call 

/setup

 again, but can simply login with the credentials provided on that initial setup call. Additionally, once logged in, you can create additional users that are also stored in the DB and should be able to login through any lakeFS container/instance that is configured with said DB.

That is interesting and informative. So as long as the RDS doesn't change, LakeFS never needs to be setup again?

That’s correct

I will likely have questions about how to best integrate that behavior with CI/CD and IaC paradigms, but those are somewhat future considerations at the moment as we do our POC

Hey Jesse, do you mean how would you use lakeFS as part of your CI/CD pipeline?

That will be appreciated. We're still scoping out some of the linkages in our overall data management system, currently connecting with diverse elements like geoserver, athena and others. But again starting points would be much appreciated

Hey Tal, Jesse, I'm able to log into lakefs through the ec2 instance using credentials that were previously used with

/setup

on a different instance but to connect to the same rds

Yes, did you lose the initial credentials?

We'll reach out when we get there

That’s an interesting point, I can suggest creating an additional admin user with the previous creds before rotating, but let us open an issue and see if there’s a better way of handling that. BTW if you’re using it just for testing, and assuming that the workload for the tests is low, why use an RDS instance? You could just as easily run a fresh postgres container with every lakeFS server, and simply destroy once done..

I would love to hear what you workout. Also, very true for testing with postgres containers and our local dev sandbox does deploy following that standard (lakefs/minio/postgres containers + python SDK). The place where we've hit the issue is on the transition to deployment, how to roll the setup from the local containers to aws with maximal symmetry (i.e. can everything than needs to be changed be handled solely by swapping out .env files and their moral equivalents - .lakefs.yaml/etc)

Hey @Jesse Levitt, created issue 2308 to track the key rotation feature request. Feel free to add any additional information to the issue.