monasca / monasca-docker

Docker files and setup for Monasca
Apache License 2.0
24 stars 47 forks source link

Differences between upstream and monasca-docker #135

Open kornicameister opened 7 years ago

kornicameister commented 7 years ago

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

timothyb89 commented 7 years ago

Ideally I think we'd like to use later versions wherever possible.

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.

kornicameister commented 7 years ago

Recently, bump to Influx 1.3.1 in upstream's been merged. Updated the table.

kornicameister commented 7 years ago

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.

kornicameister commented 7 years ago

Ok, updated the table once again. Now all that is left is to figure out the matrix.

all i see is blonde brunette redhead

kornicameister commented 7 years ago

@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 ?

kornicameister commented 7 years ago

@timothyb89 @witekest ?

witekest commented 7 years ago

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.

timothyb89 commented 7 years ago

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.

kornicameister commented 7 years ago

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 ?

witekest commented 7 years ago

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?