Toivo, The concept of some sort of named resources is understandable. In general though the distinction of production versus test is something that is very blurry in the world of dataflow. Our context for dataflow here is highly sensor driven continuous automated flows of information from sensors/datasources, to processing/analysis systems, to repositories. In that world the idea of production vs test is 'data you can't lose' versus 'data you can tolerate to lose'. Bringing that to your example one way to think of this is the 'dev' database and the 'production' database are delivered data from the same NiFI . There wouldn't be a 'production' nifi and a 'test' nifi. It would be the dataflow cluster. And it would serve development and production activities equally. It is designed for just that.
Ultimately the idea of production versus test often means fairly large protracted cycles from idea to production outcome. NiFi is tuned to make execution of idea to production as fast as possible by enabling live iterative improvements with immediate feedback. This is really a core value proposition of NiFi. You can edit the live flow in fine grained ways adding production destinations, development destinations, and each of them gets an appropriate quality of service. You won't need named resources to represent TEST vs PRODUCTION because those destinations live on the graph. When you're test flow is ready to go live you click and drag the flow of data over to production and there you go. I'd be happy to do explain it further over a google hangout or whatever. This is really getting to the heart of our dataflow philosophy and it is rather different than traditional ETL or messaging approaches. Thanks Joe On Sun, Feb 22, 2015 at 10:53 AM, Toivo Adams <[email protected]> wrote: > Often there are strictly separate environments: > Test environment > Production environment > > Let's assume we have 10+ flow templates which describes different processes. > Each of them contain connections to database, connections to JMS broker and > to remote servers. > > A test environment should be as close to production as possible. > Often it is not allowed to do any testing in production environment. > This means that templates should be exactly same for test and production > environments. > Only database, JMS broker and remote servers are different. > > It would be extremely helpful to have some kind of named resources. > For example template contains only reference to named resource DATABASE. > > When we use template in test environment, DATABASE will be mapped to test > database. > And when we move template to production environment, template will use live > database instead. > > This way we can easily test, modify and deploy without changing > configuration in each template when switching between test and live. > And not to worry possible little mistakes and differences in configuration. > > Thanks > toivo > > > > > -- > View this message in context: > http://apache-nifi-incubating-developer-list.39713.n7.nabble.com/Great-question-on-nifi-IRC-room-today-NiFi-BPM-sharing-configuration-tp787p799.html > Sent from the Apache NiFi (incubating) Developer List mailing list archive at > Nabble.com.
