You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by mcgilman <gi...@git.apache.org> on 2018/04/30 18:47:37 UTC

[GitHub] nifi issue #2509: NIFI-543 Added annotation to indicate processor should run...

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.


---