Added new envs for Quantum Leap 0.8.0

[modularTaco]

• removed CRATE_DEFAULTDB env var as it's not listed in the configuration options from Quantum Leap (see https://github.com/orchestracities/ngsi-timeseries-api/blob/master/docs/manuals/admin/configuration.md)
• added new env vars for Quantum Leap 0.8.0 from here https://github.com/orchestracities/ngsi-timeseries-api/blob/master/docs/manuals/admin/configuration.md
• added all configuration options from values.yaml to Readme.md
• Switch to make the chart usable for work queue deployments too. Basically all we needed was a K8s command switch which changes the command if the chart gets used for a work queue deployment.
• Quoting of some env var values---this avoids errors with old k8s and QL versions
• On demand Postgres init container. The base values files will always put in a Postgres init container. A chart user may want to override this, but removing the init stanza from their own value file would have no effect. This PR adds an enable flag to the init stanza so chart users can decide whether or not they want to have the init container.
• Docs to explain how to use this chart to do a standalone or work queue deployment.

[chicco785]

thx @modularTaco for your contribution, i made two small related comments, have a look and let me know, then we can merge

[modularTaco]

Hey @chicco785, I've made the changes needed to run a QL version lower than 0.8.0 with this chart now clearly in the readme. Hope you agree

[chicco785]

Hey @chicco785, I've made the changes needed to run a QL version lower than 0.8.0 with this chart now clearly in the readme. Hope you agree

looks great! we only have one problem... travis ci has not yet reset the oss credits, so we cannot make the autobuild :/ are you in a hurry?

[modularTaco]

Hey @chicco785, I've made the changes needed to run a QL version lower than 0.8.0 with this chart now clearly in the readme. Hope you agree

looks great! we only have one problem... travis ci has not yet reset the oss credits, so we cannot make the autobuild :/ are you in a hurry?

okay, no problem
It's not urgent for me

[modularTaco]

Hey @chicco785, I've made the changes needed to run a QL version lower than 0.8.0 with this chart now clearly in the readme. Hope you agree

looks great! we only have one problem... travis ci has not yet reset the oss credits, so we cannot make the autobuild :/ are you in a hurry?

Hey @chicco785 , any news here?

[chicco785]

@modularTaco so issue is that credits from travis are blocked. we had the same issue on https://github.com/orchestracities/ngsi-timeseries-api and moved to circle-ci, it was quite some pain and we don't have yet there the same feature level we had before, but so far we are happy. so we will move tests also here to circle-ci in the next days

[modularTaco]

Hey @chicco785 , any news here?

[modularTaco]

@chicco785 Updated the Fork to support new envs of QL 0.8.2 and use orchestracities repos instead of smartsdk

[modularTaco]

@chicco785 any news here?

[chicco785]

@chicco785 any news here?

97 will fix the build mechanism, once merged, you should rebase if everything works fine, we will then merge ;)

[c0c0n3]

@modularTaco #97 just got merged, if you could please rebase on master, thanks alot!!

[c0c0n3]

@modularTaco we still need to work a bit on the work queue---pun intended :-) i'd like to keep this chart for work queue deployments too, but I still need to test a few things:

1. k8s command switch to start QL in work queue mode
2. helm release switch to be able to use the same chart both for the QL front end and the work queue backend

I'll implement (1) and (2) and contribute them to your branch. In the meantime, if you could please have a look at the review comments and rebase on master. Thanks a stack!!

[modularTaco]

Hi @c0c0n3 , i've implemented your suggested changes (totally made sense to me) and rebased the branch. Let me know if you need anything from me for your tests. But please keep in mind that i'm not using QL anymore, so i won't be able to do any testing of the chart.

[c0c0n3]

hi @modularTaco, excellent job, you're a star. don't worry about testing, I'm actually busy setting up a test env on my side to be able to test the work queue deployment too, so i'll have to test the chart in the process anyway :-)

if you still have some dev cycles you could throw at this PR, it'd be a great help if you could fix up the linter issues---marked in the files changed tab. the linter is moaning about some whitespace and case stuff...

[c0c0n3]

@modularTaco oh my goodness, you're the fastest gun in the west! (talking about the linter issues)

[c0c0n3]

@modularTaco can you please rebase on master? I've merged your other PR for Crate. Thanks alot!!

[c0c0n3]

@modularTaco so I've implemented the changes I mentioned earlier and opened a PR in your fork

• https://github.com/modularTaco/charts/pull/1

if you could please merge that PR into your ql080envs branch so we can then go ahead w/ merging this PR (#90) into this repo: https://github.com/orchestracities/charts

Sorry it's a bit of a roundabout way to contribute my changes, but I couldn't find an easier way. But I guess all you need to do is merge my PR into your repo.

[modularTaco]

Hi @c0c0n3 , merged master and your PR to my branch, hope everything is alright now

[c0c0n3]

Testing

We don't have an infra for automated end-to-end testing at the moment, so I tested manually. I've managed to do both a standalone and work queue deployment using this chart---read the docs added to this PR for the details.

Here's a log of the test session for the work queue deployment---my env: K8s 1.16.15, Helm 2.17.0. First off, I whipped together two values files, one for the frontend and the other for the work queue backend:

$ diff fe.values.yaml quantumleap/values.yaml

127c127
<     offloadWork: true
---
>     offloadWork: false

$ diff wq.values.yaml quantumleap/values.yaml

132c132
<     workers: 2  # 0 means disabled
---
>     workers: 0  # 0 means disabled

Then I used the chart to make a new Helm release for the frontend deployment

$ helm install quantumleap --name fe -f fe.values.yaml
NAME:   fe
LAST DEPLOYED: Thu Jul 21 15:12:33 2022
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME            READY  UP-TO-DATE  AVAILABLE  AGE
fe-quantumleap  0/2    0           0          0s

==> v1/Pod(related)
NAME                             READY  STATUS             RESTARTS  AGE
fe-quantumleap-65ff449d48-4x2cx  0/1    ContainerCreating  0         0s
fe-quantumleap-65ff449d48-spwjq  0/1    ContainerCreating  0         0s

==> v1/Service
NAME            TYPE       CLUSTER-IP  EXTERNAL-IP  PORT(S)  AGE
fe-quantumleap  ClusterIP  None        <none>       80/TCP   0s

NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app=quantumleap,release=fe" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:8668

Following that, I used the same chart again, with a different values file, to make a new Helm release for the work queue backend deployment:

$ helm install quantumleap --name wq -f wq.values.yaml
NAME:   wq
LAST DEPLOYED: Thu Jul 21 15:15:20 2022
NAMESPACE: default
STATUS: DEPLOYED

RESOURCES:
==> v1/Deployment
NAME            READY  UP-TO-DATE  AVAILABLE  AGE
wq-quantumleap  0/2    0           0          0s

==> v1/Pod(related)
NAME                             READY  STATUS             RESTARTS  AGE
fe-quantumleap-65ff449d48-4x2cx  1/1    Running            0         2m46s
fe-quantumleap-65ff449d48-spwjq  1/1    Running            0         2m46s
wq-quantumleap-7996dd767f-ffjl8  0/1    ContainerCreating  0         0s
wq-quantumleap-7996dd767f-sr686  0/1    ContainerCreating  0         0s

==> v1/Service
NAME            TYPE       CLUSTER-IP  EXTERNAL-IP  PORT(S)  AGE
wq-quantumleap  ClusterIP  None        <none>       80/TCP   0s

NOTES:
1. Get the application URL by running these commands:
  export POD_NAME=$(kubectl get pods --namespace default -l "app=quantumleap,release=wq" -o jsonpath="{.items[0].metadata.name}")
  echo "Visit http://127.0.0.1:8080 to use your application"
  kubectl port-forward $POD_NAME 8080:8668

At this point, as a sanity check I ran some smoke tests against all the QL pods (frontend and backend) in the K8s cluster and checked Helm was correctly tracking the two releases

$ helm list
NAME    REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
fe      1           Thu Jul 21 15:12:33 2022    DEPLOYED    quantumleap-0.1.20              default  
wq      1           Thu Jul 21 15:15:20 2022    DEPLOYED    quantumleap-0.1.20              default  

Finally, I zapped both releases

$ helm delete wq
release "wq" deleted

$ helm list
NAME    REVISION    UPDATED                     STATUS      CHART               APP VERSION NAMESPACE
fe      1           Thu Jul 21 15:12:33 2022    DEPLOYED    quantumleap-0.1.20              default  

$ helm delete fe
release "fe" deleted

[c0c0n3]

hi @modularTaco, just merged your PR, thanks again for the effort you put in, I appreciate that even more knowing you did this in your own time out of your kind heart :-)

[modularTaco]

hi @modularTaco, just merged your PR, thanks again for the effort you put in, I appreciate that even more knowing you did this in your own time out of your kind heart :-)

No problem. Better to invest free time instead of "loosing" the time needed to create these PRs last year 👍 Thanks for merging