Closed rudolphpienaar closed 6 years ago
Hey @danmcp @ravisantoshgudimetla -- if OK with you, I'd like to merge this. Right now the automated e2e tests on the CUBE repo are failing because the current pman docker image is breaking on plugin runs.
so @ravisantoshgudimetla -- ok to squash and merge?
@rudolphpienaar I reviewed the parts for checking --json flag and LGTM. Do I need to review rest of the things, for example the debug.py deletion etc? If not, I need some more time.
Hi Ravi --
I've tested this using local container builds and all works fine. The deletion of the superfluous files is fine. So if you're good I'm going to squash and merge.
Sure, if that is the case, please squash and merge.
Plugin behavior changed in an out-of-band fashion. Previously, running a docker image of a plugin would return the JSON representation. Now, in line with future roadmap, running a plugin docker image results in a help/man page. To generate a JSON representation the docker image needs an entrypoint (typically by convention the plugin name, sans the 'pl-' and with a suffixed '.py', and a '--json'. This is not a fixed general rule!)
pman
used to run the docker image and parse the plugin representation to make possible substitutions in the exec string construct. This no longer works.The current fix is that the JSON passed from
pfcon
now has additional key/value pairs (taken fromcharm.py
):which, if present, are processed directly by
pman
. If these are not present,pman
reverts to a somewhat implicit (and fragile) fallback in which it attempts to run the docker image as a python entry with a '--json' arg. This fallback works for most of the core ChRIS plugins.