Github user mcgilman commented on the issue:
https://github.com/apache/nifi/pull/2509
Hey @zenfenan... So I just checked out the updated PR. Things seem to be
running as suggested, however, I'm wondering if it makes sense to improve it a
little and in the process reduce the complexity of some of that code.
Specifically, I'm referring to when we show the Execution drop down. I just
stood up a standalone instance. I dropped on two processors. One that had
`@PrimaryNodeOnly` and one that did not. For the processor that was marked
`@PrimaryNodeOnly` we showed the Execution drop down because it's configured
value was `Primary node`. This verifies the existing behavior but is a little
weird because previously the only way to get into this state was by having this
node be part of a cluster. Now with this PR, it is the default value even in a
standalone case. The other processor which was not marked with
`@PrimaryNodeOnly` we did not show the Execution drop down. I think this
distinction may be confusing to users since the context of this node previously
being part of a cluster is no longer the case.
I wanted to get your thoughts on taking a slightly different approach. What
if we always showed the Execution drop down and `Primary node` was always an
allowed option. We could either remove or disable the `All` option
conditionally based on the presence of the `@PrimaryNodeOnly` annotation. This
would allow us to remove the really confusing conditionals that drive the
visibility of the Execution field.
If we opted for this approach, we should probably update the tooltip/info
icon for this field to indicate that when clustered, this drives which node(s)
the processor will be scheduled on. The other benefit to this approach is that
it will allow for users to build a flow on a standalone instance (including the
appropriate execution nodes) before saving it to the Registry where the flow
may be imported into a cluster.
---
