You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@knox.apache.org by "Sandor Molnar (Jira)" <ji...@apache.org> on 2020/01/08 08:42:00 UTC
[jira] [Updated] (KNOX-2160) Process
refreshable-service-parameters.xml in Knox
[ https://issues.apache.org/jira/browse/KNOX-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sandor Molnar updated KNOX-2160:
--------------------------------
Description:
It'd be beneficial if there was a way to update service parameters in a descriptor without using the Admin API/UI. The preferred approach is described as follows. I'd add 2 new configurations:
- {{refreshable.service.parameters.folder}} - optional configuration to indicate if Knox should monitor the given folder for service parameter changes. If it's {{null}} -> no monitoring is enabled.
- {{refreshable.service.parameters.folder.monitor.interval}} - indicates the time period Knox checks if any parameter changes were made; defaults to 60 seconds. This is relevant only if {{refreshable.service.parameters.folder}} is {{not null}}.
A new monitor would be implemented (triggered only if monitoring is enabled) as follows:
# checks {{refreshable-service-parameters.xml}} within the configured {{refreshable.service.parameters.folder}}. The relevant configuration's name is {{refreshable.service.parameters}}.
# if there is new content (based on file timestamp) -> parse the file and build a new parameter list -> trigger topology redeployment with the new parameter list by rewriting the appropriate descriptor file.
was:
It'd be beneficial if there was a way to update service parameters in a descriptor without using the Admin API/UI. The preferred approach is similar to {{gateway-reloadable.xml}} handling. I'd add 2 new configurations:
- {{refreshable.service.parameters.folder}} - optional configuration to indicate if Knox should monitor the given folder for service parameter changes. If it's {{null}} -> no monitoring is enabled.
- {{refreshable.service.parameters.folder.monitor.interval}} - indicates the time period Knox checks if any parameter changes were made; defaults to 60 seconds. This is relevant only if {{refreshable.service.parameters.folder}} is {{not null}}.
A new monitor would be implemented (triggered only if monitoring is enabled) as follows:
# checks {{refreshable-service-parameters.xml}} within the configured {{refreshable.service.parameters.folder}}. The relevant configuration's name is {{refreshable.service.parameters}}.
# if there is new content (based on file timestamp) -> parse the file and build a new parameter list -> trigger topology redeployment with the new parameter list by rewriting the appropriate descriptor file.
> Process refreshable-service-parameters.xml in Knox
> --------------------------------------------------
>
> Key: KNOX-2160
> URL: https://issues.apache.org/jira/browse/KNOX-2160
> Project: Apache Knox
> Issue Type: New Feature
> Components: Server
> Affects Versions: 1.1.0, 1.2.0, 1.3.0
> Reporter: Sandor Molnar
> Assignee: Sandor Molnar
> Priority: Major
> Fix For: 1.4.0
>
>
> It'd be beneficial if there was a way to update service parameters in a descriptor without using the Admin API/UI. The preferred approach is described as follows. I'd add 2 new configurations:
> - {{refreshable.service.parameters.folder}} - optional configuration to indicate if Knox should monitor the given folder for service parameter changes. If it's {{null}} -> no monitoring is enabled.
> - {{refreshable.service.parameters.folder.monitor.interval}} - indicates the time period Knox checks if any parameter changes were made; defaults to 60 seconds. This is relevant only if {{refreshable.service.parameters.folder}} is {{not null}}.
> A new monitor would be implemented (triggered only if monitoring is enabled) as follows:
> # checks {{refreshable-service-parameters.xml}} within the configured {{refreshable.service.parameters.folder}}. The relevant configuration's name is {{refreshable.service.parameters}}.
> # if there is new content (based on file timestamp) -> parse the file and build a new parameter list -> trigger topology redeployment with the new parameter list by rewriting the appropriate descriptor file.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)