Re: Is there a way to prohibit auto-termination...

[Michal Klempa]

Hi Russell,
what about checking the flow.xml prior to deploying it into production
use. Search for you particular processors and the
success
pattern.
One can integrate such QA checks into CI/CD pipeline as we do using Jenkins.

Hope that helps.
Michal

On Fri, Mar 24, 2017 at 10:50 PM, Russell Bateman  wrote:
> Thanks, Joe.
>
> (Sorry.)
>
> Yes, it seems overly big-brotherish. I mean, it's a tool, after all. It's
> our down-streamer manager that asked if we could prohibit this possibility
> for certain processors whose auto-termination has proved especially
> dangerous. I'm exercising due diligence by asking. I may or may not
> experiment with Aldrin's suggestion. I could emit a warning at least.
>
> Thanks to both of you.
>
>
> On 03/24/2017 03:05 PM, Joe Witt wrote:
>>
>> Russell
>>
>> There is no way to block that while still allowing someone to have the
>> ability to alter the flow.  That said, you could certainly have a
>> reporting task or script that runs over the provenance events to find
>> any such cases.  There would be a drop event and its details would
>> tell you it was auto terminated.  So you can't block them from doing
>> it at present but you can make a naughty list and go talk to them
>> afterward.
>>
>> I'm not sure I'd be a big fan of restricting it personally.
>>
>> Thanks
>> Joe
>>
>> On Fri, Mar 24, 2017 at 4:55 PM, Russell Bateman 
>> wrote:
>>>
>>> ...of a relationship?
>>>
>>> In some of our custom processors, we'd like to remove the possibility
>>> from
>>> our user of ever auto-terminating, in particular, selected processors'
>>> failure relationships. (I realize that the user can "drain" the failures
>>> away into paths that amount to auto-termination, but that should be
>>> explicit.)
>>>
>>> Or does the community consider this to be purely a question of
>>> self-discipline?
>>>
>>> Thanks.
>
>

Re: Is there a way to prohibit auto-termination...

[Russell Bateman]

Thanks, Joe.

(Sorry.)

Yes, it seems overly big-brotherish. I mean, it's a tool, after all. 
It's our down-streamer manager that asked if we could prohibit this 
possibility for certain processors whose auto-termination has proved 
especially dangerous. I'm exercising due diligence by asking. I may or 
may not experiment with Aldrin's suggestion. I could emit a warning at 
least.


Thanks to both of you.

On 03/24/2017 03:05 PM, Joe Witt wrote:

Russell

There is no way to block that while still allowing someone to have the
ability to alter the flow.  That said, you could certainly have a
reporting task or script that runs over the provenance events to find
any such cases.  There would be a drop event and its details would
tell you it was auto terminated.  So you can't block them from doing
it at present but you can make a naughty list and go talk to them
afterward.

I'm not sure I'd be a big fan of restricting it personally.

Thanks
Joe

On Fri, Mar 24, 2017 at 4:55 PM, Russell Bateman  wrote:

...of a relationship?

In some of our custom processors, we'd like to remove the possibility from
our user of ever auto-terminating, in particular, selected processors'
failure relationships. (I realize that the user can "drain" the failures
away into paths that amount to auto-termination, but that should be
explicit.)

Or does the community consider this to be purely a question of
self-discipline?

Thanks.

Re: Is there a way to prohibit auto-termination...

[Aldrin Piri]

Will also cast a vote as feeling a bit off to me but it did get the wheels
turning.

Being a bit nefarious, I suppose you could accomplish this via a
#customValidate and performing an inspection of the processor relationships
to ensure they are not auto-terminated.

Have not actually tested, but in pseudocode-y goodness:

getRelationships().stream().filter(r -> r.isAutoTerminated() &&
r.equals(REL_FAILURE)).count() > 0


or something similar for a collection of relationships would give that
function and you could build a validation result around it... or at least I
think.

On Fri, Mar 24, 2017 at 5:05 PM, Joe Witt  wrote:

> Russell
>
> There is no way to block that while still allowing someone to have the
> ability to alter the flow.  That said, you could certainly have a
> reporting task or script that runs over the provenance events to find
> any such cases.  There would be a drop event and its details would
> tell you it was auto terminated.  So you can't block them from doing
> it at present but you can make a naughty list and go talk to them
> afterward.
>
> I'm not sure I'd be a big fan of restricting it personally.
>
> Thanks
> Joe
>
> On Fri, Mar 24, 2017 at 4:55 PM, Russell Bateman 
> wrote:
> > ...of a relationship?
> >
> > In some of our custom processors, we'd like to remove the possibility
> from
> > our user of ever auto-terminating, in particular, selected processors'
> > failure relationships. (I realize that the user can "drain" the failures
> > away into paths that amount to auto-termination, but that should be
> > explicit.)
> >
> > Or does the community consider this to be purely a question of
> > self-discipline?
> >
> > Thanks.
>

Re: Is there a way to prohibit auto-termination...

[Joe Witt]

Russell

There is no way to block that while still allowing someone to have the
ability to alter the flow.  That said, you could certainly have a
reporting task or script that runs over the provenance events to find
any such cases.  There would be a drop event and its details would
tell you it was auto terminated.  So you can't block them from doing
it at present but you can make a naughty list and go talk to them
afterward.

I'm not sure I'd be a big fan of restricting it personally.

Thanks
Joe

On Fri, Mar 24, 2017 at 4:55 PM, Russell Bateman  wrote:
> ...of a relationship?
>
> In some of our custom processors, we'd like to remove the possibility from
> our user of ever auto-terminating, in particular, selected processors'
> failure relationships. (I realize that the user can "drain" the failures
> away into paths that amount to auto-termination, but that should be
> explicit.)
>
> Or does the community consider this to be purely a question of
> self-discipline?
>
> Thanks.