search

sassoftware / viya4-deployment

This project contains Ansible code that creates a baseline in an existing Kubernetes environment for use with the SAS Viya Platform, generates the manifest for an order, and then can also deploy that order into the Kubernetes environment specified.
Apache License 2.0
71 stars 64 forks source link

feat: (IAC-701) Add support for crunchy-storage-transformer and configuration vars, update postgres-storage-transfomer #329

Closed dhoucgitter closed 1 year ago

dhoucgitter commented 2 years ago

Changes

Add support for applying the updated crunchy storage transformer and configuring that transformer via postgres server map variables. Add documentation to CONFIG-VARS for postgres PVC related server map variables.

Add change allowing the storage class specified in the v4 postgres-storage-transformer to take effect by adding the required storage-type to v4 postgres-storage-transformer

Tests

See internal ticket for a link to development testing verification information.

dhoucgitter commented 1 year ago

These changes look good to support changing the target storage class and the PVC values for each database created. Are we looking at adding in the creation of an actual storage class if needed in this issue or is that tracked somewhere else?

No where else yet. I just updated IAC-701 to specify that it did not include creation of an actual storage class in this ticket. Do you think that we have sufficient information from the postgres team to be able to do that now?

thpang commented 1 year ago

Yeah I shared the information from Christian but am adding it here as well. If we need another PR for that work I am fine with that.

Here is the provided information:

[11:24 AM] Thomas Pangborn Hi David Houck talked with Christian yesterday and he provided the following information regarding what to look for in the cluster to see if crunchy v4 is there:

--- Christian's comment:

I recommend looking for a k8s deployment named "sas-crunchy-data-postgres-operator". It is specific to v4 and gets pruned automatically (with our kubectl apply -l sas.com/admin=namespace --prune command) if you apply a release with v5

--- My input as to how we leverage existing items in the cluster to remove the need for the flag:

With this information we will not need the new/update flag we can look for that deployment in the cluster and if its there we do not create the storage class but simply use whatever the customer supplies as they had one in play already. If that deployment is not there we create a cluster wide Storage class that ALL Crunchy database transformers will use by default unless the user sets that value.