search

ceph / cephmetrics

ceph metric collectors with collectd integration
GNU Lesser General Public License v3.0
64 stars 32 forks source link

Nonstandard Grafana plugin paths in packages #52

Open zmc opened 7 years ago

zmc commented 7 years ago

We need to tweak some CSS in the vonage plugin, but in packaged versions, we're using nonstandard names. Is that necessary?

b-ranto commented 7 years ago

The idea there is not to override files users might have installed on their own -- to avoid collisions. I can add the sed call to the %build section of the spec file. We should not modify the installed files (other than configs) anyway.

b-ranto commented 7 years ago

The PR: https://github.com/ceph/cephmetrics/pull/54

btw: The ansible line would not update the path even with standard paths (it is run only in devel mode only).

pcuzner commented 7 years ago

I can appreciate the intent, but this is a 'dedicated' grafana instance, and changing the names of projects that we depend on doesn't seem appropriate.

b-ranto commented 7 years ago

It does not really change the names of the projects, just their locations in /var/lib/grafna/plugins directory to avoid potential file collisions between packages and to make it a bit more clear what installed the plugins. The projects are still identified by the same name (the name is defined in the package.json and I did not touch that), version, etc.

zmc commented 7 years ago

@b-ranto I don't see the advantage of using nonstandard paths, especially if the name is still stored the same way. What would the plugins conflict with - different versions of themselves? Am I missing something?

b-ranto commented 7 years ago

We are bundling the plugins instead of providing them in separate packages, we also do make some changes to them with the sed call. Generally, the bundled files should not override the default locations since there is no way for package manager to handle that situation. If we did ship them in separate packages, we could (and should) use the default paths but if we are bundling them (and modifying them), we should definitely go for non-standard paths.

EDIT: All in all, if we want to ship them in the default locations then we should stop bundling them and start providing them in the separate packages.

zmc commented 7 years ago

Perhaps in a future update we'll want to split the plugins into their own packages, and use their standard paths