[ 
https://issues.apache.org/jira/browse/MINIFI-66?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16358865#comment-16358865
 ] 

Aldrin Piri commented on MINIFI-66:
-----------------------------------

Hey [~JPercivall],

Good thoughts and points and I'll do my best to address these items in how I 
think this is a good fit in context of the broader ecosystem.

My thought is that there will be a mechanism to do this through registry like 
functionality, but that does not exist as of yet.  To me the thought process is 
that a flow is runnable on any multitude of hardware or physical backings.  
There may be constraints on what it can run based on component availability but 
whether I choose in one environment to have volatile repos and another I am 
going persistent with archiving, each should collect/process/transmit data in 
the same manner as available.  To that end, the config transformer in some 
aspects is overloaded.  

I think what you are suggesting is definitely functionality we want, and to 
some extent, implemented and configurable in the C++ variant where nearly any 
property can be updated and changed on the fly.  So while these are feasible to 
do a warm redeploy in some aspects, there are some things in C++ that can 
actually be done in a hot deployment

I definitely understand minimizing user hassle, and to some extent, this is why 
I want the separation to occur.  What this change proposes is effectively 
establishing functionality akin to a Dataflow Administrator role in NiFi; there 
is no change to internal workings of the instance that may be across 
heterogeneous hardware in a cluster, but the user can be sure that they are all 
handling data in a certain way.  We have much work to do to streamline and make 
this process even more intuitive, but a minimum, a person having a similar role 
for MiNiFi instances could achieve a similar level of results.  Another set of 
resources/endpoints/etc would allow a role to actually make hardware changes.

While I think the functionality in MINIFI-434 is good and needed in the current 
context, it does not address larger, practical issues for deployments of 
multiple instances where all of these properties could likely be different 
especially depending on the environment that a given instance may run.

Let me know your thoughts!

> Migrate non-flow properties from config.yml to bootstrap
> --------------------------------------------------------
>
>                 Key: MINIFI-66
>                 URL: https://issues.apache.org/jira/browse/MINIFI-66
>             Project: Apache NiFi MiNiFi
>          Issue Type: Improvement
>          Components: Agent Configuration/Installation, Processing 
> Configuration
>    Affects Versions: 0.0.1
>            Reporter: Aldrin Piri
>            Assignee: Aldrin Piri
>            Priority: Major
>
> To facilitate greater ease in configuring instances, it would be helpful to 
> have the config.yml be a descriptor only of processing flow with the actual 
> instance process configuration (system properties, file locations, etc) being 
> migrated to something like bootstrap.conf.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to