Josh Zamor

OLMIS-6192, add uat2 to terraform

    • -0
    • +24
    /provision/terraform/uat/uat2/main.tf
    • -0
    • +11
    /provision/terraform/uat/uat2/terraform.tfvars
    • -0
    • +39
    /provision/terraform/uat/uat2/variables.tf
OLMIS-6192, add missing import command.

Thanks Mateusz Kwiatkowski.
Thanks Mateusz Kwiatkowski, this was more tedious than I thought it might be, though it does still feel safer. Thanks for taking this on.

Thanks Mateusz Kwiatkowski, this was more tedious than I thought it might be, though it does still feel safer. Thanks for taking this on.

Mateusz Kwiatkowski: I'm not that familiar with this part of spring, though I don't like the warning - it makes me wonder if this setting effects Hibernate or Redis connection pools. I don't think ...

Mateusz Kwiatkowski: I'm not that familiar with this part of spring, though I don't like the warning - it makes me wonder if this setting effects Hibernate or Redis connection pools. I don't think it does, but I'd hate to hit another hard to detect threading bug. The alternative of just passing the locale in sounds safer.

As a side topic I think we need to examine how we've been using Async - a quick survey of the code suggests to me we've gone too far.

Looks good, thanks!

Looks good, thanks!

Agreed, thanks.

Agreed, thanks.

OLMIS-6183, configure nifi so it knows which host and port

Otherwise without the host port mapped we'll get CORS errors.

OLMIS-6183, add basic traefik

OLMIS-6183, add hosts note on running locally.

OLMIS-6183, change db host mount to data volume.

Using a host mount isn't generally a good docker practice. It should only really be expected to work on Linux, and even then it doesn't work if the container is deployed to a managed infrastructure.

OLMIS-6183, add a few intro notes on Kafka.

OLMIS-6183, remove unneeded host port binding.

Port bindings of nifi and superset should be unneeded with the reverse proxy.

OLMIS-6183, remove un-needed port declarations.

Unneeded as declaring them is useful for documentation IF they'll be mapped to the host, however these are quite unlikely to be mapped there.

OLMIS-6183, fix consul port

Not needed to move the consul port to 8501, didn't work anyhow (bug in that image), and undesirable given the rest of the services register with 8500.

I'll resolve and I'll add some comments to openlmis/dev that highlight why v5 has a newer version of Gradle than v5.2. I know someone will be confused by this in 6 months without it.

I'll resolve and I'll add some comments to openlmis/dev that highlight why v5 has a newer version of Gradle than v5.2. I know someone will be confused by this in 6 months without it.

When I say v5 of this, this == openlmis/dev

When I say v5 of this, this == openlmis/dev

Left a couple comments. Thanks Elias.

Left a couple comments. Thanks Elias.

With isPhysicalInventory() as well I wonder if it's time for an enum?

With isPhysicalInventory() as well I wonder if it's time for an enum?

This is checking if the kit as defined in the DTO from the client matches the Kit definition as it is from ReferenceData, right? If so maybe this validate method would be better named validateUnpac...

This is checking if the kit as defined in the DTO from the client matches the Kit definition as it is from ReferenceData, right? If so maybe this validate method would be better named validateUnpackedKitsMatchReferenceDefinition?

Does KIT_UNPACK_REASON_ID come from an env variable that we should see in https://github.com/OpenLMIS/openlmis-ref-distro/blob/master/settings-sample.env ?

Does KIT_UNPACK_REASON_ID come from an env variable that we should see in https://github.com/OpenLMIS/openlmis-ref-distro/blob/master/settings-sample.env ?

I'm a bit confused - v5 of this moved to Gradle 5, and then v5.2 bumped back to gradle 4. That seems very confusing. Do we intend to remove v5? Does anything work correctly with v5?

I'm a bit confused - v5 of this moved to Gradle 5, and then v5.2 bumped back to gradle 4. That seems very confusing. Do we intend to remove v5? Does anything work correctly with v5?

Hmm, it should either ignore or replace associations from what I remember ~2 years ago. Also without the RAML change that's still needed I'm assuming that it might be taking you to the create metho...

Hmm, it should either ignore or replace associations from what I remember ~2 years ago. Also without the RAML change that's still needed I'm assuming that it might be taking you to the create method rather than the update?

Er wait, let me walk that back. a PUT /api/resource/{id} should be an update - the URI has to exist. A PUT /api/resource should create, and may do so with a specific id, but the ID has to be in t...

Er wait, let me walk that back. a

PUT /api/resource/{id}

should be an update - the URI has to exist. A

PUT /api/resource

should create, and may do so with a specific id, but the ID has to be in the body of the request. I think our guideline is a little vague there.

Good catch and you're right. I'll see if I can get this in the airport tonight.

Good catch and you're right. I'll see if I can get this in the airport tonight.

I'm assuming it should as it used to when I first implemented this resource some ~2 years ago. It should in fact be the only way to create the ProgramOrderable association.

I'm assuming it should as it used to when I first implemented this resource some ~2 years ago. It should in fact be the only way to create the ProgramOrderable association.