[
https://issues.apache.org/jira/browse/NIFI-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131324#comment-18131324
]
Vincenzo Lombardo commented on NIFI-16502:
------------------------------------------
[~scottyaslan] [~rfellows] I'd appreciate your feedback on the preferred
approach before starting the implementation: the UI-only snapshot described
above, or extending the references endpoint to accept a set of candidate
components. I'm happy to work on either.
> Restore previous state of referencing components when re-enabling a
> Controller Service
> --------------------------------------------------------------------------------------
>
> Key: NIFI-16502
> URL: https://issues.apache.org/jira/browse/NIFI-16502
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
> Reporter: Vincenzo Lombardo
> Priority: Minor
>
> h3. Proposal
> Keep a snapshot of the referencing component states in the UI when a
> Controller Service is disabled, and offer an additional enable scope that
> restores it.
> * *Snapshot*: when the disable request is submitted, the dialog already has
> the full referencing component tree with the current state of each component.
> The UI stores the identifier, reference type and state of each referencing
> component in browser storage, keyed by the Controller Service identifier,
> using the existing StorageService with an expiration.
> * *Enable scope*: when a snapshot exists for the Controller Service, the
> Enable dialog offers a new scope such as _Service and previously active
> components_, showing when the snapshot was taken. Without a snapshot the
> dialog is unchanged.
> * *Restore*: the {{PUT /controller-services/\{id\}/references}} endpoint
> always updates all referencing components, so the restore uses the existing
> per-component endpoints instead:
> ** referencing Controller Services that were ENABLED are enabled with {{PUT
> /controller-services/\{id\}/run-status}}, waiting for each level to be
> enabled before the services that depend on it;
> ** referencing Processors and Reporting Tasks that were RUNNING are started
> with {{PUT /processors/\{id\}/run-status}} and {{PUT
> /reporting-tasks/\{id\}/run-status}}.
> * Components removed since the snapshot are skipped, and components added
> since the snapshot are left unchanged. The snapshot is removed once the
> restore completes, and the dialog reports which components could not be
> started.
> This requires no framework or REST API changes and keeps the current behavior
> when no snapshot is available.
> h3. Limitations
> * The snapshot only exists in the browser where the service was disabled. A
> service disabled by another user, from another browser or through the REST
> API has no snapshot, so the new scope is not offered.
> * Restoring N components takes N requests instead of a single request to the
> references endpoint.
> h3. Alternative
> A server-side option would be to let the references endpoint update only a
> given set of components, reusing the {{candidates}} support that
> {{StandardControllerServiceProvider.scheduleReferencingComponents()}} already
> has (introduced for NIFI-6748). The UI snapshot would then only choose the
> candidates, and the restore would remain a single request. Feedback on the
> preferred approach is welcome before implementation.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
