Mark, Loading templates from the file system on startup is a new feature in 1.0.0, right? I've been using the same API deployment Dan describes in 0.x.
Thanks, James On Wed, Sep 14, 2016 at 12:22 PM, Mark Payne <marka...@hotmail.com> wrote: > Dan, > > Yes, you should be able to pre-deploy templates. When NiFi starts up, it > looks in the conf/templates > directory (by default - this directory can be changed in the > nifi.properties file). It looks for any file that > has a suffix of ".template" or ".xml" so you need to be sure that you are > naming the files properly. Also, if you > are starting a cluster, you need to ensure that all nodes in the cluster > have the templates or they will > not show up. > > Thanks > -Mark > > > On Sep 14, 2016, at 3:15 PM, Dan Morris <dgmorri...@gmail.com> wrote: > > James, > > Related to this question, is there a way to pre-deploy templates to the > template directory and have nifi recognize them? I recently tried this and > nifi would not recognize the template until after I manually uploaded it > through the UI. > > I did this with nifi 0.7.0. > > I'd like to be able to use tools like salt or puppet to pre-position > templates. > > Thanks, > > Dan > M: 443-992-2848 > GV: 410-861-0206 > > On Sep 14, 2016, at 3:02 PM, James Wing <jvw...@gmail.com> wrote: > > Manish, you are absolutely right to back up your flow.xml.gz and conf > files. But I would carefully distinguish between using these backups to > recreate an equivalent new NiFi, versus attempting to reset the state of > your existing NiFi. The difference is the live data in your flow, in the > provenance repository, in state variables, etc. Restoring a flow > definition that no longer matches your content and provenance data may have > unexpected results for you, and for systems connecting with NiFi. NiFi > does try hard to handle these changes smoothly, but it isn't a magic time > machine. > > Deploying flow.xml.gz can work, especially when deployed with conf files > that reference IDs in the flow (like authorizations.xml), or the > nifi.sensitive.props.key setting, etc. But if you overwrite a running > flow, you still have the data migration problem. > > Templates are the current recommended best practice for deployment. As I > understand it, templates provide: > > 1.) Concise packaging for deployment > 2.) Separation between site-specific configuration like authorizations > from the flow logic > 3.) Workflow that allows, encourages, forces the administrator to address > migration from the existing flow to incorporate the new template > > Personally, I think it centers on acceptance or rejection of the > command-and-control model, which is controversial and different from most > other systems. Templates fit within command-and-control, overwriting > flow.xml.gz suggests a different model. > > I know there are many other opinions on this. > > Thanks, > > James > > On Tue, Sep 13, 2016 at 1:30 PM, Manish Gupta 8 <mgupt...@sapient.com> > wrote: > >> Hello Everyone, >> >> >> >> Is there a best practice for keeping a backup of all the data flows we >> are developing in NiFi? >> >> >> >> Currently we take a copy of flow.xml.gz every hour and keep it in backup >> folder (also in our source control). Also, we keep a copy of all Config >> files in source control. >> >> >> >> · We are assuming that using flow.xml.gz and Config files, we >> will be able to restore the NiFi in case of any failure or if someone makes >> some mistake. Is this assumption correct? Is there a better way to deal >> with this? >> >> · When we move to production (or some other environment), will >> it be as simple as dropping flow.xml.gz in a new NiFi installation on NCM >> along with making some environment related changes? Or, should we use >> templates on Dev, and import on Prod? >> >> >> >> Thanks, >> >> Manish >> >> >> > > >
