[jira] [Updated] (MINIFI-424) Expose bootstrap properties in the ConfigTransformer

["Joseph Percivall (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/MINIFI-424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joseph Percivall updated MINIFI-424:
------------------------------------
    Description: 
The ConfigTransformer takes in the config.yml and creates the nifi.properties and flow.xml. In order to better support customizations on a per MiNiFi instance for things that aren't able to reference EL, we could expose the properties listed in the bootstrap.conf. 

As an example, the bootstrap conf could have properties identifying the S2S URL and port UUID to use. Then when MiNiFi pulls down the new config.yml it would translate the keys to their proper values as identified in the bootstrap.conf.

The main unknown is what the "escape" identifiers would be. In EL it is "${ ..... }" (not sure why Jira is formatting this with new lines). This would need to be specific enough that it doesn't collide with anything that'd be in the config.yml.

Much further down the line, this could eventually evolve to expose ENV variables, key/values stored in a file, and maybe even basic functions as needed. Essentially a basic version of EL but I hesitate to call it that b/c I don't want users to expect all of that functionality. This should really be for things that can't be done via EL.

  was:
The ConfigTransformer takes in the config.yml and creates the nifi.properties and flow.xml. In order to better support customizations on a per MiNiFi instance for things that aren't able to reference EL, we could expose the properties listed in the bootstrap.conf. 

As an example, the bootstrap conf could have properties identifying the S2S URL and port UUID to use. Then when MiNiFi pulls down the new config.yml it would translate the keys to their proper values as identified in the bootstrap.conf.

The main unknown is what the "escape" identifiers would be. In EL it is "${ ..... }". This would need to be specific enough that it doesn't collide with anything that'd be in the config.yml.

Much further down the line, this could eventually evolve to expose ENV variables, key/values stored in a file, and maybe even basic functions as needed. Essentially a basic version of EL but I hesitate to call it that b/c I don't want users to expect all of that functionality. This should really be for things that can't be done via EL.


> Expose bootstrap properties in the ConfigTransformer
> ----------------------------------------------------
>
>                 Key: MINIFI-424
>                 URL: https://issues.apache.org/jira/browse/MINIFI-424
>             Project: Apache NiFi MiNiFi
>          Issue Type: New Feature
>            Reporter: Joseph Percivall
>            Assignee: Joseph Percivall
>
> The ConfigTransformer takes in the config.yml and creates the nifi.properties and flow.xml. In order to better support customizations on a per MiNiFi instance for things that aren't able to reference EL, we could expose the properties listed in the bootstrap.conf. 
> As an example, the bootstrap conf could have properties identifying the S2S URL and port UUID to use. Then when MiNiFi pulls down the new config.yml it would translate the keys to their proper values as identified in the bootstrap.conf.
> The main unknown is what the "escape" identifiers would be. In EL it is "${ ..... }" (not sure why Jira is formatting this with new lines). This would need to be specific enough that it doesn't collide with anything that'd be in the config.yml.
> Much further down the line, this could eventually evolve to expose ENV variables, key/values stored in a file, and maybe even basic functions as needed. Essentially a basic version of EL but I hesitate to call it that b/c I don't want users to expect all of that functionality. This should really be for things that can't be done via EL.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)