Thanks for the replies. I understand now. I strongly support NIFI-3128 and its subtasks to avoid confusion.
On Fri, Mar 3, 2017 at 8:54 AM, Matt Gilman <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 > > > > > >
