* ~~Explore and understand~~ [~~Cache Configuration~~](https://ignite.apache.org/docs/latest/configuring-caches/configuration-overview) ~~options within Ignite. Should we allow user to set any of these options themselves?~~
* Let's keep it simple for now. Do not want to overwhelm user with configuration options that most would not use.
* Can we optimize the run Transformer process into a simpler script?
* Instead of running `mvn clean install -DskipTests` then running `java -jar -Dspring.profiles.active=local osdu_gcz_transformer-\\\[VERSION\\\].jar` ... Is there any way we can make this happen in a succinct one-liner? - I am not as familiar with Java capabilities in this regard.
* This is possible with a batch script (ex: startup.bat). Let's create an issue for this.
* We should also inquire about OSDU installs and see how our tool could fit into that existing plan as an optional installation.
* Investigate best practices regarding authentication with OSDU and how we should be storing/accessing parameters like clientId, clientSecret, etc.
* Brian Gunter is investigating this from the AWS side
* We should at the very least revamp how we are reading auth parameters (client ID and client Secret) to use System Properties instead
* This would require more up-front config from user but is overall more secure
* Instead of running `mvn clean install -DskipTests` then running `java -jar -Dspring.profiles.active=local osdu_gcz_transformer-\\\\\\\[VERSION\\\\\\\].jar` ... Is there any way we can make this happen in a succinct one-liner? - I am not as familiar with Java capabilities in this regard.
* This is possible with a batch script (ex: startup.bat). Let's create an issue for this.
* We should also inquire about OSDU installs and see how our tool could fit into that existing plan as an optional installation.
*\~\~Investigate best practices regarding authentication with OSDU and how we should be storing/accessing parameters like clientId, clientSecret, etc.\~\~
*\~\~Brian Gunter is investigating this from the AWS side\~\~
*\~\~We should at the very least revamp how we are reading auth parameters (client ID and client Secret) to use System Properties instead\~\~
*\~\~This would require more up-front config from user but is overall more secure\~\~
* Investigate how we can separate configuration files (YAML) from the build files so that users can edit the config and restart the transformer without having to re-build it. User should not have to do this.
## Provider
...
...
@@ -28,7 +28,7 @@
* Consider spinning up a local Kubernetes environment using [Minikube](https://minikube.sigs.k8s.io/docs/start/) and testing a GCZ deployment within a controlled environment
* Putting together our own Kubernetes environment could be very worthwhile, but may be time-expensive
* Let's ask Brian Gunter about this task - if configuring our own environment is too heavy a lift, then we can discuss creating a virtual Kubernetes environment on one of our dev machines
* Expand Deployment/Ignite Knoweldge
* Expand Deployment/Ignite Knowledge
* When leveraging remote profile, user has ability to configure their own Ignite Cluster for use in the GCZ
* If Ignite Cluster has [persistence](https://ignite.apache.org/docs/latest/persistence/native-persistence) enabled, does the Transformer still work? How about when the Ignite cluster is restarted. Does the data populated by our Transformer persist? How much disk space is it taking up?
* This should be high priority and will aid us in being able to troubleshoot and support Ignite-related issues with GCZ deployment
