Commandeer ignores LOCALSTACK_API_KEY for LS Pro (mostly)

[sfrooster]

I can get this to work, occasionally, but there is no rhyme or reason to how I do so. I run my own container out of docker-compose. I've set this as an environment variable in the localstack setup for this account. I have specified this key/value in the .env which docker-compose uses. I have been setting this env variable on the command line when I invoke docker-compose.

Again, occasionally I do something right and the commandeer UI recognizes this localstack setup as "Pro", but mostly it doesn't.

Definitely not how this should be working.

[bwship]

@sfrooster - The logic is that it checks for that key existing and then does a check against AppSync for it's status. LocalStack has just changed some of their statuses that used to be 'running' to now 'available'. We have a new fix for this in the next couple of days that should resolve this for you. We also have a few other fixes within LocalStack as it wasn't always finding the correct container to start. If you go to your browser and type in http://localhost:4566/health - any of those statuses that say available, we will have fixed for those.

[sfrooster]

Are those fixes supposed to be available in 2.3.4, because they don't seem to be. I tried creating a new account by importing a running container (which starts just fine using docker-compose), two different ways - both started the container using docker-compose, one with a .env file and one with the env variables hard-coded into the docker-compose.yml. In neither case did commandeer pick-up the env variables. Even trying to manually start the imported container and entering the env variables into commandeer was not successful. It really does seem like commandeer is the piece having the issues.

[bwship]

In the account settings, for LocalStack, are you selecting the already running container from the dropdown?

Cheers, Bob Wall

(703) 919-3750

On Sun, Oct 31, 2021 at 3:48 AM Michael Haan @.***> wrote:

Are those fixes supposed to be available in 2.3.4, because they don't seem to be. I tried creating a new account by importing a running container (which starts just fine using docker-compose), two different ways - both started the container using docker-compose, one with a .env file and one with the env variables hard-coded into the docker-compose.yml. In neither case did commandeer pick-up the env variables. Even trying to manually start the imported container and entering the env variables into commandeer was not successful. It really does seem like commandeer is the piece having the issues.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commandeer/open/issues/202#issuecomment-955653054, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKDYIQUSRQEQELALZ4B3UDUJTYERANCNFSM5GUKITBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[sfrooster]

I did, yes. Between localstack, serverless (and the plug-ins) and Commandeer, I really don't know where the problem lies. On Saturday evening I managed through various machinations to use commandeer, a locally running kafka cluster (running in its own docker containers via compose), and a version of https://github.com/commandeer/open/tree/development/sample-apps/serverless-localstack which I modified, to get a lambda running locally (in localstack/serverless, but deployed through commandeer) to use my kafka cluster as it's source.

That has all since fallen apart and I can't recreate it, but that doesn't surprise me since the first success felt like a minor miracle. Again, I don't know where all the pain originates - commandeer, localstack, serverless, or the integration of the three of them - but I've all but decided this isn't a tenable workflow.

On Mon, Nov 1, 2021 at 8:18 AM Bob Wall @.***> wrote:

In the account settings, for LocalStack, are you selecting the already running container from the dropdown?

Cheers, Bob Wall

(703) 919-3750

On Sun, Oct 31, 2021 at 3:48 AM Michael Haan @.***> wrote:

Are those fixes supposed to be available in 2.3.4, because they don't seem to be. I tried creating a new account by importing a running container (which starts just fine using docker-compose), two different ways - both started the container using docker-compose, one with a .env file and one with the env variables hard-coded into the docker-compose.yml. In neither case did commandeer pick-up the env variables. Even trying to manually start the imported container and entering the env variables into commandeer was not successful. It really does seem like commandeer is the piece having the issues.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/commandeer/open/issues/202#issuecomment-955653054, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAKDYIQUSRQEQELALZ4B3UDUJTYERANCNFSM5GUKITBQ

. Triage notifications on the go with GitHub Mobile for iOS < https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675

or Android < https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/commandeer/open/issues/202#issuecomment-956323646, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAX27FZFAMNWQGP4WS4XQE3UJ2VS5ANCNFSM5GUKITBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[bwship]

Yea, there does seem to be certain issues with LocalStack plus Serverless. We had one team switch to using STS - https://serverless-stack.com/ which means they basically only run stuff in the AWS ecosystem. It basically sets up a mocked web sockets environment for the Lambda's. You can then still use Commandeer with the access to AWS directly.