This is actually a very interesting discussion to be had. . . So, at this point I believe that similar to other states of the component (i.e., RUNNING), the DISABLED state is what is constituted as runtime-state and therefore should NOT be stored into NOR expected to be restored from the template. Template IMHO should only be used to store flow definitions. That said, I do see how someone may also treat/expect that DISABLED state is a special state and as such does not represent the runtime state, rather the intention of the author at the time of template export.
So let’s duke it out here and summarize it in JIRA before we decide if any action needs to be taken. Cheers Oleg > On Nov 7, 2016, at 10:20 AM, Joe Witt <[email protected]> wrote: > > Chris, > > I can see why we're not automatically starting processors when they're > placed on the graph but I do share your view that disabled processor status > should be honored and retained. I think a JIRA for this is reasonable and > at the very least will get some good discussion and/or doc changes. > > Thanks > JOe > > On Mon, Nov 7, 2016 at 10:12 AM, McDermott, Chris Kevin (MSDU - > STaTS/StorefrontRemote) <[email protected]> wrote: > >> If I create a template from a flow that has some disabled components, when >> I download and import that template into a different NiFi instance, the >> disabled state of those components is lost (they are no longer disabled.) >> I’m not sure when this information is being lost (is it saved in the >> template?) >> >> >> >> This makes using a template for deployment somewhat difficult. Unless I’m >> missing something I am planning of entering a JIRA, but I wanted to check >> with the community first in case I am missing something. >> >> >> >> >> >> Thanks, >> >> >> >> Chris McDermott >> >> >> >> Remote Business Analytics >> >> STaTS/StoreFront Remote >> >> HPE Storage >> >> Hewlett Packard Enterprise >> >> Mobile: +1 978-697-5315 >> >> >> >>
