search

medic / helm-charts

GNU Affero General Public License v3.0
0 stars 0 forks source link

Update cht-user-management chart #19

Closed paulpascal closed 3 days ago

paulpascal commented 2 months ago

This ticket is related to the changes brought from move contact feature which add a new image and have three services (web app, worker, and redis) now instead of one.

To accommodate these changes, we need to bring some update to the cht-user-management helm chart by:

We'll want to make sure the service names of the worker are reachable to the main pushed to prod instead of just one (main).

cc: @Hareet @mrjones-plip

paulpascal commented 2 months ago

Hello @Hareet, is there please an update on this ? Thanks 🙏

PhilipNgari commented 2 months ago

Hello @Hareet Kindly help unblock us here. cc @medic/site-reliability-engineering

henokgetachew commented 2 months ago

I'm going to be handling this this week. I will reach out if I need more information

mrjones-plip commented 2 months ago

in case it's relevant to pushing newer versions with move contact live to any of the 4 production instances of the tool, there's a pending PR to update how pushes are done.

freddieptf commented 1 month ago

@henokgetachew any update on this?

Hareet commented 1 week ago

@freddieptf This will be ready this week. I found a few mistakes in my work from last week that I need to finish refactoring before this PR is ready:

Where can I test this new helm chart and deployment? I don't see any deploys in the dev-eks cluster. Can you message me configuration settings and environment variables for me to test the new containers?

mrjones-plip commented 1 week ago

@Hareet - I would recommend spinning up a public dev instance of CHT Core (hareet.dev.mm.org - oh or user-man-test.dev.mm.org !), use cht-conf to push the correct config and then spin up a user man instance in dev context using the deploy steps which match the config you just pushed. Choose one of the 4 known configurations to match CHT Core <> CHT User Man Tool (eg users-chis-tg <> togo config)

I've set up local dev instances with docker - so I'd be happy to pair with you tomorrow if @freddieptf is busy!

Hareet commented 1 week ago

@mrjones-plip Thanks! matching config is a key step for me here.

I've set up local dev instances with docker - so I'd be happy to pair with you tomorrow

Unfortunately, since we are testing the production deployment process (helm charts), we can't use local-dev compose. We would want to do local k3s and then test the helm chart. I'll see whether that's easier or do it in EKS.

paulpascal commented 1 week ago

HI @Hareet,

Thanks for looking into, this I am messaging you configuration settings and environment variables to test the new containers. I would also be glad to pair with you, or @mrjones-plip if needed, just let me know.

Thanks

cc: @mrjones-plip @freddieptf @ernestoteo

mrjones-plip commented 1 week ago 
I've set up local dev instances with docker - so I'd be happy to pair with you tomorrow

Unfortunately, since we are testing the production deployment process (helm charts), we can't use local-dev compose. We would want to do local k3s and then test the helm chart. I'll see whether that's easier or do it in EKS.

Oh - sorry! I should have said, "I've helped architect the local docker development environment as well as deployed to prod with helm quite a bit - I think I could be a big help since you don't have any first hand experience deploying this".

I suspect it's easiest to use EKS per my suggestion above vs k3s.

lemme know if you wanna hand!

Hareet commented 5 days ago

@paulpascal @freddieptf I have a WIP PR request up to add these services to the helm chart. While I am wrapping that up, we can use my WIP branch to deploy these updates to live projects. Please validate the testing scenario below first.

One question before that though:

Logs from user-man container relating to auth request:

[04:18:16.317] INFO (18): incoming request
    reqId: "req-69"
    req: {
      "method": "POST",
      "url": "/authenticate",
      "hostname": "hareet-test-users.dev.medicmobile.org",
      "remoteAddress": "10.71.2.198",
      "remotePort": 1406
    }
[04:18:16.381] INFO (18): request completed
    reqId: "req-69"
    res: {
      "statusCode": 200
    }
    responseTime: 64.18450164794922

Image

freddieptf commented 5 days ago

The development instance is usually a locally running CHT instance used for testing during development, you can configure the URL via the CHT_DEV_URL_PORT env variable. I tried logging in to MoH Togo Dev and it worked fine

paulpascal commented 5 days ago

Thanks @freddieptf !

@Hareet , moreover I have checked your values.yaml and and noticed that you have already correctly set the CHT_DEV_URL_PORT:

env: 
    NODE_ENV: dev
    CHT_DEV_HTTP: true
    CHT_DEV_URL_PORT: hareet-test.dev.medicmobile.org
    CONFIG_NAME: chis-tg

The issue you are experiencing is due to the CHT_DEV_HTTP: true setting. This option should only be set to true for HTTP connections and to false for HTTPS connections.

In my case, I was able to log in to MoH Togo Dev without any issues. I also successfully moved a CHW post from one village to another. Image