monasca
Differences between upstream and monasca-docker
I recently noticed that there are some differences between version of some dependencies in this repo and upstream code (i.e. devstack for monasca-api).
For example, till now I've tracked that to:
| Dep | Here | Devstack | Updated | Note |
|---|---|---|---|---|
| InfluxDB | 1.3.3 | 1.3.3 | Upstream | |
| Kafka | 0.9.0.1-2.11 | 0.9.0.1-2.11 | Upstream | |
| Storm | 1.0.3 | 1.0.3 | Upstream | |
| Zookeeper | 3.4 | 3.4 | Local | |
| Grafana | SAP repo | Charter repo | --- | The difference is in both repositories and used branches |
Fujitsu would like to have that aligned, so the question is, where to bumb/downgrade. Another requirement I've been given is to match those versions also by the Openstack release (i.e. if stable/ocata featured InfluxDB 1.1.1, the same version should be used if we want to build monasca-docker's images for that particular release).
The question is, how to approach to keep my supervisors happy ;-) and your environment working + still having your requirements met.
Cheers, T
Ideally I think we'd like to use later versions wherever possible.
- InfluxDB: I believe we updated to 1.3.x to try out some new features, probably a worthwhile update anyway
- Kafka: we wanted to take advantage of the new automatic broker IDs in 0.9.x
- Storm: seemed like a simple enough update so I just grabbed it while making the Dockerfile
- Zookeeper: we can probably upgrade to 3.4 without any trouble
As for release versioning, we don't really have any solid plans for following OpenStack releases here, but I don't think I'd be opposed to e.g. having branches to track upstream releases. The CI scripts would need to be adjusted to support different branches since we're only working off master right now, but it shouldn't be very difficult to add.
Loosely related: I've had a to-do list item to actually document our thoughts on a tagging/versioning policy (#111) that I really need to take care of :smile:. We can extend that to include a release policy as well, which could cover snapshots for OpenStack releases.
Recently, bump to Influx 1.3.1 in upstream's been merged. Updated the table.
Ok, I've submitted some changes here and there to sync up the version for now. I will try to elaborate some way to have compatibility-matrix of some sort for the future.
Ok, updated the table once again. Now all that is left is to figure out the matrix.
all i see is blonde brunette redhead
@timothyb89 I noticed another difference. It is not about the versions though...it is far more tricky. The problem lies in grafana image and it goes down to the point that:
not to mention that devstack's is using keystone branch as written here, however the image is using master-keystone branch as written here
I will update the table above.
BTW: I will also feature newly upgraded InfluxDB version.
@roland-hochmuth @craigbr @mhoppal @mohamhab do you any input for that particular problem ?
In the mid-term we should look for another place for Grafana fork or find another solution how to implement Keystone authentication in Grafana. Both repos are not maintained at the moment.
In short-term, without knowing the details of implementation, I would say we should rebuild the image with the SAP repo. SAP has taken over the code from Charter after they had announced they are not able to maintain it anymore. Looking at the commits, SAP branch includes additionally to Charter a couple of bugfixes.
We can switch over to the newer repo easily enough with a quick change to GRAFANA_REPO/GRAFANA_BRANCH in build.yml.
@roland-hochmuth might know something about grafana keystone integration plans... there was something in the works but I don't know if that's still on the table.
I'd also had some ideas for integrating some basic keystone support into the monasca grafana plugin/app itself and avoiding the need to maintain a fork at all. Haven't had time to investigate fully, unfortunately.
If it possible to embed this inside the app and leave the fork behind I think I'd like that. On the other hand, not really sure if that fits into our requirements. @witekest ?
Yes, having authentication in the app would be nice. The only requirement I can think of is being able to reference the graph from outside of Grafana (e.g. Horizon) once authenticated. Can you think of any limitations of having authentication in the Grafana app?