Gateway Configuration
Dynamic Repositories can now be bootstrapped
- Eliminates the need for an apply after the Gateway is ready
- Limitations
- singleton configs (scheduledTasks that only run on one node + Outbound JMSDestinations) still need to be applied after the Gateway starts
- the encryptionPasshprase needs to be the same. We do not perform decryption and reencryption in during init
- Limitations
app:
repositoryReferenceBootstrap:
enabled: true
preferGit: false
Expanded Delete support
- Extended to non-statestore repository types
- local repositories are not included in this release
- disabling a repository will trigger a delete
- a new flag (repositoryReferenceDelete.reconcileReferences) has been introduced to mitigate the risk of dependency overlaps
- repo1 and 2 contain cwpX ==> repo1 is removed cwpX is removed ==> repo2 is automatically re-applied bringing the gateway back to desired state
- a new flag (repositoryReferenceDelete.reconcileReferences) has been introduced to mitigate the risk of dependency overlaps
- repositoryReference directory changes will trigger delete if resulting bundle removes entities
- delete mappings are automatically generated for new commits where entities are removed.
app:
repositoryReferenceDelete:
enabled: false <== disabled by default. The Operator will delete repositories from the Gateway when you disable them. Use with caution! Make sure you understand how your configuration is built.
reconcileReferences: true <== reconcile other repositories after a delete
reconcileDirectoryChanges: true <== reconcile changes to directories
includeEfs: false <== if you do not have a layer7 statestore this flag will enable use of the operators ephemeral filesystem. Not recommended for database backed gateways, use mappings instead.
More advanced fallback support
- Multiple sources checked when repositories aren't ready to apply
StateStore references
- statestore reconcile is more conservative to avoid egress charges in Cloud vendors
- new preferGit option for bootstrapping repositories
- statestore repositories do not have any state stored in Kubernetes secrets
Advanced directory support
- git repos can contain nested structures
- these are detected and can be built and combined individually in order
- omitting directories builds and combines everything. If there are multiple repository structures there is no determinate structure.
- if directories change, the delta between previous and new is built and applied
- http and local repository types do not have advanced directory support in this release
app:
repositoryReferences:
- name: combined-repo-v1
type: dynamic
enabled: true
directories:
- l7GWMyFramework <== ignores nested repos
- l7GWMyFramework/l7GWMyAPIs <== nested repo
- l7GWMySubscriptions
- l7GWMyAPIs
Repository Configuration
- The repository controller has expanded responsibility for building combined bundles.
StateStore Configuration
- Added SSL/TLS Support for Redis
Issues
#90 - Expanded directory support should facilitate defining one repository with one or selected directories in the repositoryReference.
#77 - This is now automatically set if left empty in Openshift.
#78 - This will be addressed in documentation and potentially added to a later release.