[
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)
