Joe, The different scoping of Controller Services was part of the multi-tenant effort. The general idea was to establish points of limited availability to ensure the service usage does not become so broad that updating (including stopping and starting of all things that reference the service) is not possible. By allowing services to be defined at each level, we support any level of granularity that the users desire.
The services defined at the data flow level will inherit the policies of the parent process group unless explicitly overridden. These services will be available to any descendant components. The services that are defined at the Controller level will inherit the policies of the controller unless explicitly overridden. These services will be available to reporting tasks and other services at the Controller level. I agree that the UX here is not good enough. We do have existing JIRAs [1] for making this better. These JIRAs are things that we will help in the short term but may warrant additional design discussions long term. Matt [1] https://issues.apache.org/jira/browse/NIFI-3128 On Fri, Mar 3, 2017 at 8:04 AM, Joe Skora <jsk...@gmail.com> wrote: > Bryan, > > That makes sense, but I missed that subtly in the 0.x to 1.x changes. I > ran into some questions while trying to get it straight in my head. > > * How do the global controller services differ from those in the root > process group? > > * Are the global controller services only available to reporting tasks? > > * Are reporting tasks unable to use any process group controller services? > (I think you said they can't, just want to confirm.) > > * Can any user reference the global controller services or does that carry > a separate authorization policy? > > Regards, > Joe > > On Thu, Mar 2, 2017 at 4:11 PM, Bryan Bende <bbe...@gmail.com> wrote: > > > Hi Mark, > > > > Controller services from the global menu are only for use by reporting > > tasks that might use a controller service. For example, the > > SiteToSiteProvenanceReportingTask uses an optional SSLContextService, > > which would need to be defined at the global level. > > > > All controller services used by processors are created from context > > palette and are based on the process group you are in at the given > > time (the root canvas is the root process group). This is done for > > security purposes so that access to the controller services can be > > inherited by access to the process group if desired. > > > > Thanks, > > > > Bryan > > > > > > On Thu, Mar 2, 2017 at 3:56 PM, Mark Bean <mark.o.b...@gmail.com> wrote: > > > Can someone please clarify the difference between the Global Menu -> > > > Controller Settings -> Controller Services tab and Root Canvas -> > > > Configuration button from palette -> Controller Services tab? > > > > > > I would expect that a Controller Service added via the Global Menu > would > > be > > > available at all levels of the graph. However, this does not seem to be > > the > > > case. (It is the case for Controller Services added through the palette > > > Configuration button.) > > > > > > Thanks, > > > Mark > > >
