[
https://issues.apache.org/jira/browse/FINERACT-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17115015#comment-17115015
]
Yemdjih Kaze Nasser commented on FINERACT-990:
----------------------------------------------
Weird but this command($(head /dev/urandom | env LC_C TYPE=C tr -dc A-Za-z0-9 |
head -c 16)) doesn't seem to work on a linux environment either.
There should be a better compromise out there.
> Kubernetes set-up for development
> ---------------------------------
>
> Key: FINERACT-990
> URL: https://issues.apache.org/jira/browse/FINERACT-990
> Project: Apache Fineract
> Issue Type: Improvement
> Reporter: Petri Tuomola
> Priority: Minor
> Labels: kubernetes, technical
>
> The current Kubernetes scripts are not ideal for development purposes - the
> following three improvements could be made:
> * The script line in kubectl-startup to create a password does not work on
> MacOS (tr does not like the data it gets from urandom)
> * Kubernetes configuration was pulling in the latest apache/fineract image
> rather than using the one built by our docker-compose build
> * The MySQL password passed in during the initial run of Kubernetes seems to
> be getting stored on the PersistentVolume /mnt/data. Since we generate a new
> password every time we run kubectl-startup whereas the data on the volume is
> retained, at least for me this meant only the first startup worked. After
> that all the startups failed, as Fineract is not able to login to MySQL
> These can be fixed with:
> * kubectl create secret generic fineract-tenants-db-secret
> --from-literal=username=root --from-literal=password=$(head /dev/urandom |
> *env LC_C TYPE=C* tr -dc A-Za-z0-9 | head -c 16) to get the password
> generation to work on MacOS
> * Changing the image label to be the same across docker-compose.yml and
> fineract-server-deployment.yml
> * Added persistentVolumeReclaimPolicy: Recycle to the PersistentVolume spec
> in fineractmysql-deployment.yml. This way the volume gets wiped after each
> shutdown, allowing the new password to be used for MySQL. Of course also the
> data gets wiped, so a better option would probably be to keep the generated
> secret and reuse it from one startup to next.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
