search

BD2KGenomics / dcc-redwood-client

Apache License 2.0
2 stars 1 forks source link

prod/dev in downstream containers? #15

Open benjaminran opened 7 years ago

benjaminran commented 7 years ago

If this project is built with the prod maven profile, the development java truststore isn't used, instead using the default ubuntu truststore. Downstream clients (i.e. core-client) should pin the version of a prod build.

This hasn't caused errors running core-client against dev dcc-ops/redwood (serving the self-signed certificate trusted only by the dev truststore) because redwood-client:1.1.1 must have been released from a build that didn't use -P prod. There's still a problem - the two mistakes don't cancel.

Redwood-client could listen to an env var like _REDWOODPROFILE and somehow change it's ssl validation accordingly. Probably the best thing to do is to make note of the no_ssl_validation spring config profile on the storage clients (I think both have something like that). This might not even require a code change (just docs) if the profile is set via the SPRING_PROFILES_ACTIVE env var.

It could also use one or the other truststore accordingly (note: this would require modifying the icgc-storage-client and dcc-metadata-client bash code, even if we try to be clever with JAVA_OPTS). Otherwise, all downstreams clients will have to implement dev/prod mode distinctions to avoid their requests failing ssl validation on seeing the self-signed certificate not in their truststore.

This will get rid of the different maven build profiles, which will also solve the issue of having to remember to use -P prod when building releases.

benjaminran commented 7 years ago

org.icgc.dcc.storage.client.config.ClientProperties.SSLProperties is a way to do this.