search

bcgov / aries-vcr-issuer-controller

indy-catalyst-agent
Apache License 2.0
8 stars 31 forks source link

Separate local and openshift configurations. #56

Closed Jsyro closed 3 years ago

Jsyro commented 3 years ago

Add behaviour/template to separate local development configuration from a 'realistic' production configuration.

Locally we want to issue registrations, then issue 'permit' VC's to those registrations, but in the example case. We want to connect permits to existing registrations, issued by BC Registries.

Add comments explaining what gets replaced by the read-schema.py generated files.

Changing the config_root environment variable redirects all config loading to use the new configuration. Signed-off-by: Jason Sy jasyrotuck@gmail.com

ianco commented 3 years ago

@esune where are the openshift versions of the schema and services yml files maintained? They should be version controlled in github right?

Per wade's comment re duplication, doesn't this also duplicate the configs?

esune commented 3 years ago

@esune where are the openshift versions of the schema and services yml files maintained? They should be version controlled in github right?

Per wade's comment re duplication, doesn't this also duplicate the configs?

Yes, they are versioned in GitHub and "duplicated" for OpenShift use. They could be stored in a repository specific to configurations (as we do for von-bc-registries-agent - which is based on this project) or in the team's fork - being careful not to PR them back to the upstream repo.

Another project we have used this pattern for is issuer-kit: the main repo contains the application code and sample OpenShift configurations (That I will eventually move out of there), while configuration-specific repositories such as essential-services-delivery hold the build/deployment configurations and the deployment-specific files to be injected at runtime.

I just feel like this pattern helps keeping the base project cleaner and free of assumptions to be made on where to place things and when, since there only is one spot that gets overlayed when necessary.

ianco commented 3 years ago

OK @esune that makes sense. I don't think there is any danger of PR'ing into the upstream repo, since issuers typically copy rather than fork this repo. (The forked/copied repo changes all the schema and services configuration so should never be merged up once changed).

@Jsyro based on the @esune and @WadeBarnes comments does this meet your deployment requirements? let's move the discussion to RC if you have any questions

Jsyro commented 3 years ago

Thanks for the thoughtful feedback guys. Totally understand it doesn't quite fit in to the model you guys are going for. We think our setup is going to get us through this POC. If we update our pattern we can circle back.