NMS-20365: Plugin Management page - #8897
Open
joseanesONMS wants to merge 9 commits into
Open
joseanesONMS wants to merge 9 commits into
joseanesONMS wants to merge 9 commits into
Conversation
Uploads a plugin KAR, checks it before anything is written (archive structure, entries confined to repository/ and META-INF/, features file, bundles, package imports against what the container exports, Java requirement, duplicate name), stages it into deploy/ with a featuresBoot.d boot file, lists the plugins known to the page and those found in deploy/, and unloads one by removing both files. A restart is still needed for the extender to read the boot file, so the page says so and shows how. The container is reached through the bundle context Karaf already hands the webapp, with the feature and KAR services looked up by name since their packages are not exported to the webapp class space. Every action is written with user, address, checksum and outcome to plugin-management.log. Admin only, in the security rules and in every handler.
Karaf installs a staged KAR's features within seconds unless its manifest says Karaf-Feature-Start: false, so only those, and unloads, now flag a restart; a plugin whose features did not start after a boot is shown as failed instead of staged forever. Optional package imports no longer fail the compatibility check, the size limit is enforced before the upload is read, unload also removes any boot-file line waiting for the KAR so the extender cannot hang at startup, the boot file and registry are written before the KAR moves so a partial failure leaves nothing unrecorded, and audit lines strip control characters. Only exact .kar names count, as in Karaf, and a name must start with a letter or digit since the extender skips dot files.
CXF refuses multipart attachments above 50 MB by default with an empty 413, below the service's own 512 MB check.
Core features that merely depend on the integration API were listed as plugins. A feature now counts only when its repository is not one of the boot repositories from org.apache.karaf.features.cfg and not an OpenNMS Karaf artifact, and the response says which repository each came from.
The inspector no longer treats Maven metadata or empty XML files inside the KAR as feature repositories, which refused a locally built plugin that was otherwise compatible; only files named as features files or rooted in <features> count, and a broken XML that is not one is a warning. The help moves from an expanding panel to the Info button and dialog used on the other admin pages. The activity log is a parsed table with search, plugin, action and outcome filters, a line count up to the log endpoint's limit, failed entries marked, and a download of the whole file. Statuses read Loaded, Load pending restart, Unload pending restart, Unloaded, Failed to start and Not managed here, and the banner counts loads and unloads.
The primary way to load a plugin is now its official repository: a shipped catalog names the OpenNMS plugins and their GitHub repositories, the server reads the releases, and on request downloads the chosen KAR itself and runs the same checks as for an upload before the usual load. Downloads are https only and limited to GitHub's hosts unless an allowlist property says otherwise, every redirect is re-validated, sizes are bounded and hashed while streaming. Release lists are cached for fifteen minutes and an optional token property lifts GitHub's anonymous limit. Every network failure reaches the page as a short message that says what to check and that a file upload still works. The temporary area now cleans itself: a scheduled sweep every fifteen minutes drops uploads and downloads older than an hour that are not deployed, strays at once, and keeps the area under two gigabytes with in-flight transfers reserved, refusing a transfer that would not fit. The file tab stays as the second way to load, the table shows each plugin's source, and the audit log records fetches with their URL.
httpclient's transparent gunzip fails on GitHub's gzip plus chunked release lists with a malformed-chunk error; identity encoding avoids it and GitHub then sends a Content-Length.
Loading wrote every top-level feature of a KAR to the boot file, which for ALEC meant starting its standalone, distributed and Sentinel modes at once. The check now suggests the features to start, from the catalog for known plugins or from the KAR when it has one obvious candidate, the page lets the user tick them, and the boot file lists exactly those. A KAR that declares no features fails its check with a note that it is probably a build stub. Plugins loaded by hand appear with the features named in any boot file that waits for them, or the KAR's own, and their live state, marked as loaded by hand; managed rows follow their boot file too, so an edited file is reflected instead of reported as a failure.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a Plugin Management page under Administration that loads a plugin KAR through the UI or the REST API, checks it first, and unloads it again, replacing the copy-to-deploy and edit-featuresBoot.d procedure.
The container is reached through the bundle context Karaf already hands the webapp, so nothing new is exposed and the checks compare the plugin against the running server rather than against assumptions.
repository/andMETA-INF/, features file, bundles, package import ranges against the container's exports, Java requirement, duplicate name; a failure refuses the load, a warning must be acknowledged.deploy/and writes thefeaturesBoot.dboot file; Karaf starts it within seconds unless the manifest opts out, in which case the page flags the restart and shows how to do it.plugin-management.log, shown on the page; the endpoints are admin-only in the security rules and in every handler.External References