* 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?
* ~~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.
* 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
* Familiarize with the Provider codebase
*`ignite-provider/src/model.js` and `ignite-provider/lib/ignite-client.js` are the key files to review
* How can we implement logging in the Provider?
* Review Popular NodeJS Logging libraries like winston and pino
* Can we add logs to the Provider at vulnerable/error points, and log all requests processed by Koop?
* Can we setup a nodejs package.json script for running the Provider and consecutively running ngrok without the user having to open command prompt and do it themselves?
* There is an [npm package](https://www.npmjs.com/package/ngrok) for `ngrok`
* We would have to store some ngrok auth info in a config file
* Let's create an issue for this.
* ~~Can we setup a nodejs package.json script for running the Provider and consecutively running ngrok without the user having to open command prompt and do it themselves?~~
* We are not strictly recommending any one method for exposing a Feature Service - that will be entirely left to user - so we should not build-in any pre-configured scripts for launching an HTTP tunneler
## CSP
* Support IBM
* Investigate what it would take to configure an Ignite Cluster and have it accessible by Ignite Thick Clients (like our Transformer) in a Kubernetes environment (Cluster on one Pod and Thick Client in another pod)
* 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
* 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
