Re: Unable to modify flow when one of the nodes in a cluster is disconnected

[Mark Payne]

Purushotham,

If the node is disconnected and then attempts to reconnect, flow election does 
not occur. Rather, the node obtains a copy of the flow
from the cluster, determines whether or not it matches, and if so rejoins. If 
the flow does not match, it disconnects and stops trying to
reconnect.

There are a few reasons that the node doesn't just inherit the cluster's flow 
blindly. Firstly, if a user were to delete a connection, and the
re-joining node had data in that connection, it would lose the data. This is 
probably the most important reason - we never want to
design for data loss.

Secondly, when a node is disconnected from the cluster, the user is able to 
make changes. There are times when users will disconnect a
particular node from the cluster and make some changes to the dataflow for 
diagnostic purposes. For example, they may want to temporarily
send data to a new endpoint for sampling. When this happens, we don't want to 
just blindly lose those changes, because the user may not
have wanted those changes lost. And if an admin is managing several systems, 
it's possible that they could accidentally configure the node
to point to the wrong cluster, in which case it could potentially lose the 
entire dataflow. Perhaps not a problem if the dataflow exists on other
nodes, but if this is a standalone node being converted into cluster, it could 
be devastating for the user.

Now, there are some changes that we do allow, and the node will still re-join. 
For instance, if the positions of elements change, elements are started
or stopped, etc. In these cases, the new node will just inherit the flow from 
the cluster and take on those changes.

I think it would probably be advantageous to allow the node to back up its own 
flow before inheriting from the cluster, and then apply any changes from
the cluster that do not result in data loss (i.e., if any connection is removed 
and the node has data in that connection, then fail, else inherit). The big down
side there, honestly, is that it's just a huge amount of effort that would be 
required in order to make that work properly.

So to make a long story short: there are reasons that we don't just inherit the 
flow, but we could work around those problems. There are definitely
areas where we could improve, but it's just not been taken on yet by anyone in 
the community.

Thanks
-Mark


On Jun 27, 2019, at 3:37 AM, Purushotham Pushpavanthar 
mailto:pushpavant...@gmail.com>> wrote:

Hi,

I'm having a 3 nodes( ver 1.9.2) cluster running in production. As infra is 
unreliable due to various factors, our nodes go down often. We don't have 
distinction between dev and prod cluster. We modify, deploy, test in the same 
cluster. However, when one of the node goes down NiFi restricts us to modify 
the state of the flow by throwing warning window in the attachment.

I 
read
 that if a node in the cluster is disconnected and comes back again, flow 
election happens. I would like to understand the motivation for not allowing 
the change of flow in the above scenario.
I was thinking why can't the latest node joining to the cluster pull a most 
elected flow.xml.gz from the cluster and apply it to itself?

Regards,
Purushotham Pushpavanth

Re: [DISCUSS] Apache NiFi MiNiFi C++ 0.6.1

[Aldrin Piri]

I agree with 786 for sure.  I apologize, I may have interpreted your
initial response a bit literally with regards to the "feature bearing"
JIRAs.  Just wanted to clarify that new features would not be in scope for
a fix version release, but in terms of adjusting the expected
functionality, totally onboard with that.

On Thu, Jun 27, 2019 at 8:47 AM Jeremy Dyer  wrote:

> Completely agree but isn’t MINIFICPP-786 an issue we could include as part
> of that?
>
> On Wed, Jun 26, 2019 at 6:35 PM Aldrin Piri  wrote:
>
> > I think the intent is for this to be a fix release and wouldn’t include
> > any new features.
> >
> > > On Jun 26, 2019, at 17:47, Jeremy Dyer  wrote:
> > >
> > > +1 it’s time and lots of feature bearing JIRAs have been resolved
> > >
> > > I do agree with with Arpad however on the inclusion of MINIFICPP-786
> > >
> > >> On Wed, Jun 26, 2019 at 5:37 PM Arpad Boda  wrote:
> > >>
> > >> Happy to take RM roles as well.
> > >>
> > >>> On Wed, Jun 26, 2019 at 10:30 AM Arpad Boda 
> > wrote:
> > >>>
> > >>> +1.
> > >>>
> > >>>
> > >>>
> > >>> As this release seems to be a Windows-focused, I would also consider
> > >>> adding https://issues.apache.org/jira/browse/MINIFICPP-786
> > >>>
> > >>> On Tue, Jun 25, 2019 at 11:53 PM Marc Parisi 
> > >> wrote:
> > >>>
> >  Hi Everyone,
> > 
> >  I wanted to discuss releasing Apache NiFi MiNiFi C++ 0.6.1 with some
> >  important bug fixes. We've had a few issues that impact Windows
> users
> > >> and
> >  TLS with Raw Site To Site [1,2]. With these bugs addressed I think
> we
> >  should look to releasing 0.6.1.
> > 
> >  I would like to scope this bug fix release to only critical and
> > blocker
> >  tickets found after 0.6.0. Let me know what you think or if you
> think
> >  anything else should be included that is critical to user
> operations.
> > 
> >   My time is pretty fragmented but will try my best to take on RM
> > duties
> >  unless someone would like to try their hand at it.
> > 
> >    Thanks,
> >    Marc Parisi
> > 
> >  [1] https://issues.apache.org/jira/browse/MINIFICPP-933
> >  [2] https://issues.apache.org/jira/browse/MINIFICPP-919
> > 
> > >>>
> > >>
> >
>

Re: [DISCUSS] Apache NiFi MiNiFi C++ 0.6.1

[Jeremy Dyer]

Completely agree but isn’t MINIFICPP-786 an issue we could include as part
of that?

On Wed, Jun 26, 2019 at 6:35 PM Aldrin Piri  wrote:

> I think the intent is for this to be a fix release and wouldn’t include
> any new features.
>
> > On Jun 26, 2019, at 17:47, Jeremy Dyer  wrote:
> >
> > +1 it’s time and lots of feature bearing JIRAs have been resolved
> >
> > I do agree with with Arpad however on the inclusion of MINIFICPP-786
> >
> >> On Wed, Jun 26, 2019 at 5:37 PM Arpad Boda  wrote:
> >>
> >> Happy to take RM roles as well.
> >>
> >>> On Wed, Jun 26, 2019 at 10:30 AM Arpad Boda 
> wrote:
> >>>
> >>> +1.
> >>>
> >>>
> >>>
> >>> As this release seems to be a Windows-focused, I would also consider
> >>> adding https://issues.apache.org/jira/browse/MINIFICPP-786
> >>>
> >>> On Tue, Jun 25, 2019 at 11:53 PM Marc Parisi 
> >> wrote:
> >>>
>  Hi Everyone,
> 
>  I wanted to discuss releasing Apache NiFi MiNiFi C++ 0.6.1 with some
>  important bug fixes. We've had a few issues that impact Windows users
> >> and
>  TLS with Raw Site To Site [1,2]. With these bugs addressed I think we
>  should look to releasing 0.6.1.
> 
>  I would like to scope this bug fix release to only critical and
> blocker
>  tickets found after 0.6.0. Let me know what you think or if you think
>  anything else should be included that is critical to user operations.
> 
>   My time is pretty fragmented but will try my best to take on RM
> duties
>  unless someone would like to try their hand at it.
> 
>    Thanks,
>    Marc Parisi
> 
>  [1] https://issues.apache.org/jira/browse/MINIFICPP-933
>  [2] https://issues.apache.org/jira/browse/MINIFICPP-919
> 
> >>>
> >>
>

Unable to modify flow when one of the nodes in a cluster is disconnected

[Purushotham Pushpavanthar]

Hi,

I'm having a 3 nodes( ver 1.9.2) cluster running in production. As infra is
unreliable due to various factors, our nodes go down often. We don't have
distinction between dev and prod cluster. We modify, deploy, test in the
same cluster. However, when one of the node goes down NiFi restricts us to
modify the state of the flow by throwing warning window in the attachment.

I read

that if a node in the cluster is disconnected and comes back again, flow
election happens. I would like to understand the motivation for not
allowing the change of flow in the above scenario.
I was thinking why can't the latest node joining to the cluster pull a most
elected flow.xml.gz from the cluster and apply it to itself?

Regards,
Purushotham Pushpavanth