monasca
keystone-init integration path
Requirements:
- [x] support password lookup from secrets (in case of lost keystone)
- [x] support password changing with lost secrets (in case of lost k8s)
- [x] support secret replacement when fields change/update
- [x] support creating endpoints and services
- [ ] remove preload.py from base keystone container
- [ ] include keystone-init in monasca-docker
- [ ] include keystone-init in monasca-helm
Bonus points:
- convert to python 3 (following example from mysql-users-init)
- move kubernetes.py to a dedicated kubernetes-simple pypi package
- shared utils.py for k8s secret management in keystone-init, mysql-users-init, etc
@timothyb89 will this one feature going back to keystone-init ? Personally I liked the idea of separate container much more. Simply because with it we could rely on keystone deployed elsewhere and use all else the way it it.
Right, that's exactly what we want to support. keystone-init is a separate container and can create all our Monasca users and projects in any target keystone instance (or really any any keystone resources for any purpose). This issue is to track the work that's still needed before we can switch over to using it here and in monasca-helm.
Once the preloading logic is separate from the keystone container it should be easy to just turn our keystone off and use an external one. This is definitely the best scenario for a production deployment anyway, since our own keystone container is really only acceptable for dev purposes.
