cephmetrics icon indicating copy to clipboard operation
cephmetrics copied to clipboard

Published 20 hours ago • verified publisher icon ceph

Nonstandard Grafana plugin paths in packages

Open zmc opened this issue 7 years ago • 7 comments

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

zmc avatar Jun 29 '17 23:06 zmc

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 avatar Jun 30 '17 08:06 b-ranto

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).

b-ranto avatar Jun 30 '17 08:06 b-ranto

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.

pcuzner avatar Jun 30 '17 09:06 pcuzner

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.

b-ranto avatar Jun 30 '17 10:06 b-ranto

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

zmc avatar Jun 30 '17 15:06 zmc

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.

b-ranto avatar Jun 30 '17 17:06 b-ranto

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

zmc avatar Jun 30 '17 17:06 zmc