Process Groups and StandardClassificationService

[James McMahon <js...@gmail.com>]

Good morning. My co-worker and I have independent Process Groups, PGA and
PGB. Both exist at the workflow level immediately under NiFi Flow. Each
process group does indeed appear to have its own unique identifier. However
as we each run our workflows we find that we are periodically being told by
NiFi to refresh because the other has made updates. I noticed that we have
each defined instances of StandardClassificationService. Could that be the
reason we were getting these refresh messages?

In general how should StandardClassificationService,
StandardHttpContextMap, and StandardSSLContextService be instantiated for
process groups? Should there only be one of each service and mapfor NiFi
Flow, shared by all process groups and processors under NiFi flow? Or
should each process group have its own instance, and - if so - why are we
experiencing these refresh messages that appear to be driven by changes in
the other independent process group?

Thank you in advance for your help. -Jim

Re: Process Groups and StandardClassificationService

[Joe Skora <js...@gmail.com>]

Thanks for clarifying!



On Mon, Mar 13, 2017 at 9:03 AM, Matt Gilman <ma...@gmail.com>
wrote:

> Jim, Joe,
>
> Just wanted to clarify. It sounds as though your running the 0.x baseline.
> In 0.x, a single revision is maintained for the entire flow. If another
> user makes a change, you will get a notification that you need to Refresh
> to realize their changes before you can make any changes.
>
> In 1.x the Refresh link your referring to has been removed. With a focus
> on multi-tenant usage, each component now maintains it's own revision.
> Additionally, as other users make changes, your UI will update and realize
> those changes automatically.
>
> Matt
>
> On Mon, Mar 13, 2017 at 8:04 AM, James McMahon <js...@gmail.com>
> wrote:
>
>> Joe what is considered best practice for StandardClassificationService,
>> StandardHttpContextMap, and StandardSSLContextService in different process
>> groups? Should a new instance of each be created that is specific for each
>> and every process group? Or are common instances of one or more of these
>> services typically shared across process groups?
>>
>> Regards,
>> Jim
>>
>> On Mon, Mar 13, 2017 at 7:47 AM, Joe Skora <js...@gmail.com> wrote:
>>
>>> James,
>>>
>>> I believe that even with multi-tenant isolation the graph is managed as
>>> a whole so any change bumps the version for the whole thing.
>>>
>>> Regards,
>>> Joe
>>>
>>> On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <js...@gmail.com>
>>> wrote:
>>>
>>>> Good morning. My co-worker and I have independent Process Groups, PGA
>>>> and PGB. Both exist at the workflow level immediately under NiFi Flow. Each
>>>> process group does indeed appear to have its own unique identifier. However
>>>> as we each run our workflows we find that we are periodically being told by
>>>> NiFi to refresh because the other has made updates. I noticed that we have
>>>> each defined instances of StandardClassificationService. Could that be the
>>>> reason we were getting these refresh messages?
>>>>
>>>> In general how should StandardClassificationService,
>>>> StandardHttpContextMap, and StandardSSLContextService be instantiated for
>>>> process groups? Should there only be one of each service and mapfor NiFi
>>>> Flow, shared by all process groups and processors under NiFi flow? Or
>>>> should each process group have its own instance, and - if so - why are we
>>>> experiencing these refresh messages that appear to be driven by changes in
>>>> the other independent process group?
>>>>
>>>> Thank you in advance for your help. -Jim
>>>>
>>>
>>>
>>
>

Re: Process Groups and StandardClassificationService

[James McMahon <js...@gmail.com>]

This is a big help indeed. I am all set, armed with this understanding.
Thank you very much Matt and Joe. -Jim

On Mon, Mar 13, 2017 at 9:43 AM, Joe Witt <jo...@gmail.com> wrote:

> Matt describes some of the powerful benefits of the 1.x release line
> that go well beyond what we could accomplish in 0.x.  To your specific
> examples let's look at each one does...
>
> StandardClassificationService:
>   I dont believe this is a part of Apache NiFi.  Probably a custom
> controller service you have.
>
> StandardHttpContextMap:
>   This is to hold the http context being used in a pair of
> request/response processes.  Unless one team handles the request and
> another handles the response I'd expect it to be within a fairly
> singular scoped process group.
>
> StandardSSLContextService:
>   This is to provide the necessary context to enable a range of TLS
> based connections including the key/trusts used.  This is a great
> candidate for a higher level and thus shared controller service so all
> can benefit from it.  If it is in a narrow scoped specific process
> group then it makes sense that it would be for something very specific
> to that group.
>
> Hopefully that helps a bit.
>
> Joe
>
>
> On Mon, Mar 13, 2017 at 8:36 AM, Matt Gilman <ma...@gmail.com>
> wrote:
> > In general, if the services share a common configuration and are
> accessible
> > to user's configuring the components in question they can be shared. In
> 1.x
> > we support Process Group scoped services because when the usage becomes
> so
> > broad users may not be permitted to modify all referencing components.
> This
> > flexibility supports the 'global' case where services are accessible to
> all
> > components on the canvas, and the fine-grained case where services are
> > defined within nested Process Groups.
> >
> > Matt
> >
> > On Mon, Mar 13, 2017 at 9:21 AM, James McMahon <js...@gmail.com>
> wrote:
> >>
> >> Thank you Matt. Can you tell me this: what is considered best practice
> for
> >> StandardClassificationService, StandardHttpContextMap, and
> >> StandardSSLContextService in different process groups? Should a new
> instance
> >> of each be created that is specific to each and every process group? Or
> are
> >> common instances of one or more of these services typically shared
> across
> >> process groups?
> >>
> >> Regards,
> >> Jim
> >>
> >> On Mon, Mar 13, 2017 at 9:03 AM, Matt Gilman <ma...@gmail.com>
> >> wrote:
> >>>
> >>> Jim, Joe,
> >>>
> >>> Just wanted to clarify. It sounds as though your running the 0.x
> >>> baseline. In 0.x, a single revision is maintained for the entire flow.
> If
> >>> another user makes a change, you will get a notification that you need
> to
> >>> Refresh to realize their changes before you can make any changes.
> >>>
> >>> In 1.x the Refresh link your referring to has been removed. With a
> focus
> >>> on multi-tenant usage, each component now maintains it's own revision.
> >>> Additionally, as other users make changes, your UI will update and
> realize
> >>> those changes automatically.
> >>>
> >>> Matt
> >>>
> >>> On Mon, Mar 13, 2017 at 8:04 AM, James McMahon <js...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Joe what is considered best practice for
> StandardClassificationService,
> >>>> StandardHttpContextMap, and StandardSSLContextService in different
> process
> >>>> groups? Should a new instance of each be created that is specific for
> each
> >>>> and every process group? Or are common instances of one or more of
> these
> >>>> services typically shared across process groups?
> >>>>
> >>>> Regards,
> >>>> Jim
> >>>>
> >>>> On Mon, Mar 13, 2017 at 7:47 AM, Joe Skora <js...@gmail.com> wrote:
> >>>>>
> >>>>> James,
> >>>>>
> >>>>> I believe that even with multi-tenant isolation the graph is managed
> as
> >>>>> a whole so any change bumps the version for the whole thing.
> >>>>>
> >>>>> Regards,
> >>>>> Joe
> >>>>>
> >>>>> On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <jsmcmahon3@gmail.com
> >
> >>>>> wrote:
> >>>>>>
> >>>>>> Good morning. My co-worker and I have independent Process Groups,
> PGA
> >>>>>> and PGB. Both exist at the workflow level immediately under NiFi
> Flow. Each
> >>>>>> process group does indeed appear to have its own unique identifier.
> However
> >>>>>> as we each run our workflows we find that we are periodically being
> told by
> >>>>>> NiFi to refresh because the other has made updates. I noticed that
> we have
> >>>>>> each defined instances of StandardClassificationService. Could that
> be the
> >>>>>> reason we were getting these refresh messages?
> >>>>>>
> >>>>>> In general how should StandardClassificationService,
> >>>>>> StandardHttpContextMap, and StandardSSLContextService be
> instantiated for
> >>>>>> process groups? Should there only be one of each service and mapfor
> NiFi
> >>>>>> Flow, shared by all process groups and processors under NiFi flow?
> Or should
> >>>>>> each process group have its own instance, and - if so - why are we
> >>>>>> experiencing these refresh messages that appear to be driven by
> changes in
> >>>>>> the other independent process group?
> >>>>>>
> >>>>>> Thank you in advance for your help. -Jim
> >>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>

Re: Process Groups and StandardClassificationService

[Joe Witt <jo...@gmail.com>]

Matt describes some of the powerful benefits of the 1.x release line
that go well beyond what we could accomplish in 0.x.  To your specific
examples let's look at each one does...

StandardClassificationService:
  I dont believe this is a part of Apache NiFi.  Probably a custom
controller service you have.

StandardHttpContextMap:
  This is to hold the http context being used in a pair of
request/response processes.  Unless one team handles the request and
another handles the response I'd expect it to be within a fairly
singular scoped process group.

StandardSSLContextService:
  This is to provide the necessary context to enable a range of TLS
based connections including the key/trusts used.  This is a great
candidate for a higher level and thus shared controller service so all
can benefit from it.  If it is in a narrow scoped specific process
group then it makes sense that it would be for something very specific
to that group.

Hopefully that helps a bit.

Joe


On Mon, Mar 13, 2017 at 8:36 AM, Matt Gilman <ma...@gmail.com> wrote:
> In general, if the services share a common configuration and are accessible
> to user's configuring the components in question they can be shared. In 1.x
> we support Process Group scoped services because when the usage becomes so
> broad users may not be permitted to modify all referencing components. This
> flexibility supports the 'global' case where services are accessible to all
> components on the canvas, and the fine-grained case where services are
> defined within nested Process Groups.
>
> Matt
>
> On Mon, Mar 13, 2017 at 9:21 AM, James McMahon <js...@gmail.com> wrote:
>>
>> Thank you Matt. Can you tell me this: what is considered best practice for
>> StandardClassificationService, StandardHttpContextMap, and
>> StandardSSLContextService in different process groups? Should a new instance
>> of each be created that is specific to each and every process group? Or are
>> common instances of one or more of these services typically shared across
>> process groups?
>>
>> Regards,
>> Jim
>>
>> On Mon, Mar 13, 2017 at 9:03 AM, Matt Gilman <ma...@gmail.com>
>> wrote:
>>>
>>> Jim, Joe,
>>>
>>> Just wanted to clarify. It sounds as though your running the 0.x
>>> baseline. In 0.x, a single revision is maintained for the entire flow. If
>>> another user makes a change, you will get a notification that you need to
>>> Refresh to realize their changes before you can make any changes.
>>>
>>> In 1.x the Refresh link your referring to has been removed. With a focus
>>> on multi-tenant usage, each component now maintains it's own revision.
>>> Additionally, as other users make changes, your UI will update and realize
>>> those changes automatically.
>>>
>>> Matt
>>>
>>> On Mon, Mar 13, 2017 at 8:04 AM, James McMahon <js...@gmail.com>
>>> wrote:
>>>>
>>>> Joe what is considered best practice for StandardClassificationService,
>>>> StandardHttpContextMap, and StandardSSLContextService in different process
>>>> groups? Should a new instance of each be created that is specific for each
>>>> and every process group? Or are common instances of one or more of these
>>>> services typically shared across process groups?
>>>>
>>>> Regards,
>>>> Jim
>>>>
>>>> On Mon, Mar 13, 2017 at 7:47 AM, Joe Skora <js...@gmail.com> wrote:
>>>>>
>>>>> James,
>>>>>
>>>>> I believe that even with multi-tenant isolation the graph is managed as
>>>>> a whole so any change bumps the version for the whole thing.
>>>>>
>>>>> Regards,
>>>>> Joe
>>>>>
>>>>> On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <js...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> Good morning. My co-worker and I have independent Process Groups, PGA
>>>>>> and PGB. Both exist at the workflow level immediately under NiFi Flow. Each
>>>>>> process group does indeed appear to have its own unique identifier. However
>>>>>> as we each run our workflows we find that we are periodically being told by
>>>>>> NiFi to refresh because the other has made updates. I noticed that we have
>>>>>> each defined instances of StandardClassificationService. Could that be the
>>>>>> reason we were getting these refresh messages?
>>>>>>
>>>>>> In general how should StandardClassificationService,
>>>>>> StandardHttpContextMap, and StandardSSLContextService be instantiated for
>>>>>> process groups? Should there only be one of each service and mapfor NiFi
>>>>>> Flow, shared by all process groups and processors under NiFi flow? Or should
>>>>>> each process group have its own instance, and - if so - why are we
>>>>>> experiencing these refresh messages that appear to be driven by changes in
>>>>>> the other independent process group?
>>>>>>
>>>>>> Thank you in advance for your help. -Jim
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Process Groups and StandardClassificationService

[Matt Gilman <ma...@gmail.com>]

In general, if the services share a common configuration and are accessible
to user's configuring the components in question they can be shared. In 1.x
we support Process Group scoped services because when the usage becomes so
broad users may not be permitted to modify all referencing components. This
flexibility supports the 'global' case where services are accessible to all
components on the canvas, and the fine-grained case where services are
defined within nested Process Groups.

Matt

On Mon, Mar 13, 2017 at 9:21 AM, James McMahon <js...@gmail.com> wrote:

> Thank you Matt. Can you tell me this: what is considered best practice for
> StandardClassificationService, StandardHttpContextMap, and
> StandardSSLContextService in different process groups? Should a new
> instance of each be created that is specific to each and every process
> group? Or are common instances of one or more of these services typically
> shared across process groups?
>
> Regards,
> Jim
>
> On Mon, Mar 13, 2017 at 9:03 AM, Matt Gilman <ma...@gmail.com>
> wrote:
>
>> Jim, Joe,
>>
>> Just wanted to clarify. It sounds as though your running the 0.x
>> baseline. In 0.x, a single revision is maintained for the entire flow. If
>> another user makes a change, you will get a notification that you need to
>> Refresh to realize their changes before you can make any changes.
>>
>> In 1.x the Refresh link your referring to has been removed. With a focus
>> on multi-tenant usage, each component now maintains it's own revision.
>> Additionally, as other users make changes, your UI will update and realize
>> those changes automatically.
>>
>> Matt
>>
>> On Mon, Mar 13, 2017 at 8:04 AM, James McMahon <js...@gmail.com>
>> wrote:
>>
>>> Joe what is considered best practice for StandardClassificationService,
>>> StandardHttpContextMap, and StandardSSLContextService in different process
>>> groups? Should a new instance of each be created that is specific for each
>>> and every process group? Or are common instances of one or more of these
>>> services typically shared across process groups?
>>>
>>> Regards,
>>> Jim
>>>
>>> On Mon, Mar 13, 2017 at 7:47 AM, Joe Skora <js...@gmail.com> wrote:
>>>
>>>> James,
>>>>
>>>> I believe that even with multi-tenant isolation the graph is managed as
>>>> a whole so any change bumps the version for the whole thing.
>>>>
>>>> Regards,
>>>> Joe
>>>>
>>>> On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <js...@gmail.com>
>>>> wrote:
>>>>
>>>>> Good morning. My co-worker and I have independent Process Groups, PGA
>>>>> and PGB. Both exist at the workflow level immediately under NiFi Flow. Each
>>>>> process group does indeed appear to have its own unique identifier. However
>>>>> as we each run our workflows we find that we are periodically being told by
>>>>> NiFi to refresh because the other has made updates. I noticed that we have
>>>>> each defined instances of StandardClassificationService. Could that be the
>>>>> reason we were getting these refresh messages?
>>>>>
>>>>> In general how should StandardClassificationService,
>>>>> StandardHttpContextMap, and StandardSSLContextService be instantiated for
>>>>> process groups? Should there only be one of each service and mapfor NiFi
>>>>> Flow, shared by all process groups and processors under NiFi flow? Or
>>>>> should each process group have its own instance, and - if so - why are we
>>>>> experiencing these refresh messages that appear to be driven by changes in
>>>>> the other independent process group?
>>>>>
>>>>> Thank you in advance for your help. -Jim
>>>>>
>>>>
>>>>
>>>
>>
>

Re: Process Groups and StandardClassificationService

[James McMahon <js...@gmail.com>]

Thank you Matt. Can you tell me this: what is considered best practice for
StandardClassificationService, StandardHttpContextMap, and
StandardSSLContextService in different process groups? Should a new
instance of each be created that is specific to each and every process
group? Or are common instances of one or more of these services typically
shared across process groups?

Regards,
Jim

On Mon, Mar 13, 2017 at 9:03 AM, Matt Gilman <ma...@gmail.com>
wrote:

> Jim, Joe,
>
> Just wanted to clarify. It sounds as though your running the 0.x baseline.
> In 0.x, a single revision is maintained for the entire flow. If another
> user makes a change, you will get a notification that you need to Refresh
> to realize their changes before you can make any changes.
>
> In 1.x the Refresh link your referring to has been removed. With a focus
> on multi-tenant usage, each component now maintains it's own revision.
> Additionally, as other users make changes, your UI will update and realize
> those changes automatically.
>
> Matt
>
> On Mon, Mar 13, 2017 at 8:04 AM, James McMahon <js...@gmail.com>
> wrote:
>
>> Joe what is considered best practice for StandardClassificationService,
>> StandardHttpContextMap, and StandardSSLContextService in different process
>> groups? Should a new instance of each be created that is specific for each
>> and every process group? Or are common instances of one or more of these
>> services typically shared across process groups?
>>
>> Regards,
>> Jim
>>
>> On Mon, Mar 13, 2017 at 7:47 AM, Joe Skora <js...@gmail.com> wrote:
>>
>>> James,
>>>
>>> I believe that even with multi-tenant isolation the graph is managed as
>>> a whole so any change bumps the version for the whole thing.
>>>
>>> Regards,
>>> Joe
>>>
>>> On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <js...@gmail.com>
>>> wrote:
>>>
>>>> Good morning. My co-worker and I have independent Process Groups, PGA
>>>> and PGB. Both exist at the workflow level immediately under NiFi Flow. Each
>>>> process group does indeed appear to have its own unique identifier. However
>>>> as we each run our workflows we find that we are periodically being told by
>>>> NiFi to refresh because the other has made updates. I noticed that we have
>>>> each defined instances of StandardClassificationService. Could that be the
>>>> reason we were getting these refresh messages?
>>>>
>>>> In general how should StandardClassificationService,
>>>> StandardHttpContextMap, and StandardSSLContextService be instantiated for
>>>> process groups? Should there only be one of each service and mapfor NiFi
>>>> Flow, shared by all process groups and processors under NiFi flow? Or
>>>> should each process group have its own instance, and - if so - why are we
>>>> experiencing these refresh messages that appear to be driven by changes in
>>>> the other independent process group?
>>>>
>>>> Thank you in advance for your help. -Jim
>>>>
>>>
>>>
>>
>

Re: Process Groups and StandardClassificationService

[Matt Gilman <ma...@gmail.com>]

Jim, Joe,

Just wanted to clarify. It sounds as though your running the 0.x baseline.
In 0.x, a single revision is maintained for the entire flow. If another
user makes a change, you will get a notification that you need to Refresh
to realize their changes before you can make any changes.

In 1.x the Refresh link your referring to has been removed. With a focus on
multi-tenant usage, each component now maintains it's own revision.
Additionally, as other users make changes, your UI will update and realize
those changes automatically.

Matt

On Mon, Mar 13, 2017 at 8:04 AM, James McMahon <js...@gmail.com> wrote:

> Joe what is considered best practice for StandardClassificationService,
> StandardHttpContextMap, and StandardSSLContextService in different process
> groups? Should a new instance of each be created that is specific for each
> and every process group? Or are common instances of one or more of these
> services typically shared across process groups?
>
> Regards,
> Jim
>
> On Mon, Mar 13, 2017 at 7:47 AM, Joe Skora <js...@gmail.com> wrote:
>
>> James,
>>
>> I believe that even with multi-tenant isolation the graph is managed as a
>> whole so any change bumps the version for the whole thing.
>>
>> Regards,
>> Joe
>>
>> On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <js...@gmail.com>
>> wrote:
>>
>>> Good morning. My co-worker and I have independent Process Groups, PGA
>>> and PGB. Both exist at the workflow level immediately under NiFi Flow. Each
>>> process group does indeed appear to have its own unique identifier. However
>>> as we each run our workflows we find that we are periodically being told by
>>> NiFi to refresh because the other has made updates. I noticed that we have
>>> each defined instances of StandardClassificationService. Could that be the
>>> reason we were getting these refresh messages?
>>>
>>> In general how should StandardClassificationService,
>>> StandardHttpContextMap, and StandardSSLContextService be instantiated for
>>> process groups? Should there only be one of each service and mapfor NiFi
>>> Flow, shared by all process groups and processors under NiFi flow? Or
>>> should each process group have its own instance, and - if so - why are we
>>> experiencing these refresh messages that appear to be driven by changes in
>>> the other independent process group?
>>>
>>> Thank you in advance for your help. -Jim
>>>
>>
>>
>

Re: Process Groups and StandardClassificationService

[James McMahon <js...@gmail.com>]

Joe what is considered best practice for StandardClassificationService,
StandardHttpContextMap, and StandardSSLContextService in different process
groups? Should a new instance of each be created that is specific for each
and every process group? Or are common instances of one or more of these
services typically shared across process groups?

Regards,
Jim

On Mon, Mar 13, 2017 at 7:47 AM, Joe Skora <js...@gmail.com> wrote:

> James,
>
> I believe that even with multi-tenant isolation the graph is managed as a
> whole so any change bumps the version for the whole thing.
>
> Regards,
> Joe
>
> On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <js...@gmail.com>
> wrote:
>
>> Good morning. My co-worker and I have independent Process Groups, PGA and
>> PGB. Both exist at the workflow level immediately under NiFi Flow. Each
>> process group does indeed appear to have its own unique identifier. However
>> as we each run our workflows we find that we are periodically being told by
>> NiFi to refresh because the other has made updates. I noticed that we have
>> each defined instances of StandardClassificationService. Could that be the
>> reason we were getting these refresh messages?
>>
>> In general how should StandardClassificationService,
>> StandardHttpContextMap, and StandardSSLContextService be instantiated for
>> process groups? Should there only be one of each service and mapfor NiFi
>> Flow, shared by all process groups and processors under NiFi flow? Or
>> should each process group have its own instance, and - if so - why are we
>> experiencing these refresh messages that appear to be driven by changes in
>> the other independent process group?
>>
>> Thank you in advance for your help. -Jim
>>
>
>

Re: Process Groups and StandardClassificationService

[Joe Skora <js...@gmail.com>]

James,

I believe that even with multi-tenant isolation the graph is managed as a
whole so any change bumps the version for the whole thing.

Regards,
Joe

On Mon, Mar 13, 2017 at 7:00 AM, James McMahon <js...@gmail.com> wrote:

> Good morning. My co-worker and I have independent Process Groups, PGA and
> PGB. Both exist at the workflow level immediately under NiFi Flow. Each
> process group does indeed appear to have its own unique identifier. However
> as we each run our workflows we find that we are periodically being told by
> NiFi to refresh because the other has made updates. I noticed that we have
> each defined instances of StandardClassificationService. Could that be the
> reason we were getting these refresh messages?
>
> In general how should StandardClassificationService,
> StandardHttpContextMap, and StandardSSLContextService be instantiated for
> process groups? Should there only be one of each service and mapfor NiFi
> Flow, shared by all process groups and processors under NiFi flow? Or
> should each process group have its own instance, and - if so - why are we
> experiencing these refresh messages that appear to be driven by changes in
> the other independent process group?
>
> Thank you in advance for your help. -Jim
>