Transformer
-
Explore and understand Cache Configuration 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~~
- 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
- 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?
- 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 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 Knowledge
- When leveraging remote profile, user has ability to configure their own Ignite Cluster for use in the GCZ
- If Ignite Cluster has 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
Administration
- Mock up or outline a user experience for configuring both the Transformer and Provider
- Transformer
- Walkthrough and provide Form that lets user create, review, or edit their configuration
- Handle faulty values
- Provider - Guide user through a Layer Definition Configuration process
- Walkthrough and provide Form that lets user create, review, or edit their configuration
- One nice-to-have feature here would be...
- Once user has entered Ignite connection details and geometry type, etc... construct a NodeJS thin client on the backend that connects to that cache and if it is running.. provide back a list of all possible Fields that are able to be pulled down. From there the user could individually select fields and provide their own custom labels, geometry types, etc.