openlmis-deployment

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
OLMIS-6557 New TF config for uat and test and new stack for both servers
OLMIS-6557 New TF config for uat and test and new stack for both servers
OLMIS-6496 Stand up v3 reporting stack for Casper
OLMIS-6496 Stand up v3 reporting stack for Casper
changed notification service version to 4.1.2-SNAPSHOT
changed notification service version to 4.1.2-SNAPSHOT
I don't really know how to check this is working or review it properly, but looks fine to me.

I don't really know how to check this is working or review it properly, but looks fine to me.

OLMIS-6427 ETL pipeline automated deployment
OLMIS-6427 ETL pipeline automated deployment
OLMIS-6424 Get demo data automatically loaded into Casper v3 serverFix load data SQL error
OLMIS-6424 Get demo data automatically loaded into Casper v3 serverFix load data SQL error
This needs to be manually done, since demo data is loaded after refresh-db profile is run.

This needs to be manually done, since demo data is loaded after refresh-db profile is run.

The v3 server is pegged to 3.6, so this field still exists in the schema.

The v3 server is pegged to 3.6, so this field still exists in the schema.

The v3 instance should be read-only and should not be allowed to change data.

The v3 instance should be read-only and should not be allowed to change data.

Hacky; decided to do this after starting up v3, as it's the simplest approach, vs. trying to load demo data and figure out how to keep v3 from wiping it.

Hacky; decided to do this after starting up v3, as it's the simplest approach, vs. trying to load demo data and figure out how to keep v3 from wiping it.

OLMIS-5914 - Added installion Postgres extensions during RDS database setup using Terraform
OLMIS-5914 - Added installion Postgres extensions during RDS database setup using Terraform
There probably is a more robust way; I just did this as an incremental improvement.

There probably is a more robust way; I just did this as an incremental improvement.

This statement was necessary to go from 9.5.x to 9.6.x (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL.MajorVersion)...

This statement was necessary to go from 9.5.x to 9.6.x (https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.html#USER_UpgradeDBInstance.PostgreSQL.MajorVersion) It shouldn't upgrade to 10 or 11, since we specify engine version as 9.6.14. But if we did specify the engine version as 10 or 11, it might, based on the matrix in the link I posted. We do have PostGIS installed, so that would also affect what it gets upgraded to.

There may be a way to look up the group ID automatically? For instance the default_security_group_id attribute of aws_vpc?

There may be a way to look up the group ID automatically? For instance the default_security_group_id attribute of aws_vpc?