Hi,
I've incorporated this feedback into the proposal and renamed it
appropriately to "Lockable Connector Properties". This adds to the
proposal the ability to reset with a hook that can be executed on reset
to allow behavior before the properties are unlocked to clean things
up. It considers the reset lock a connector action for triggering as well.
https://issues.apache.org/jira/browse/NIP-36
Thanks again for the feedback to improve this proposal.
Sincerely,
Bob Paulin
On 7/24/2026 10:02 AM, Bob Paulin wrote:
David/Pierre,
Thank you for the prompt and thoughtful replies.
Reset Support/Semantics
I think lock/reset support could be considered and I would agree that
might shift the naming semantics. My original intent is that
immutable would be you set once and the connector would need to be
recreated to change. I feel what is proposed fits nicely with the
definition of immutable "unable to be changed, altered, or modified
over time". If we want to consider allowing this to be reset I would
modify my proposal to call this ConnectorPropertyDescriptor lockable
as David suggests.
.lockable(boolean isLockable)
From there we could document that setting lock to true would
implicitly mean it is locked if the connector ever reaches the RUNNING
stage. Then unlock could be considered a connector action to reset
the lock. The semantics in the ConnectorNode persistence could be
changed then to contain a list of locked properties
(say lockedConnectorProperties ) on the ConnectorNode which could be
added and removed individually or in bulk by API/Action.
The idea of allowing a lock to apply to different stages is
interesting but I would be hesitant to introduce that concept in the
initial go. For example what phases, currently represented by the
ConnectorState enum would we support? Perhaps "UPDATED" might be a
good fit. Then then api could be enhance to accept a list of
ConnectorStates that would trigger the lock.
.lockable(boolean isLockable, List<ConnectorState> triggerState)
Then we would need the persistence of the lockedConnectorProperties to
be updated when the connector state transitioned. So the current
design could evolve to either of these. However the other states are
transitional and don't seem to provide a lot of meeting over the life
of the connector (DRAINING, PURGING, TROUBLESHOOTING). So at this
point I think this might be too early for such a concept and we'd want
to defer that decision to later based on usage. Like what should
TROUBLESHOOTING state do? Should that implicitly unlock? I'm not
sure I have a good understanding of the usecases to tackle that
question yet.
I'm open to both suggestions but both are a bit beyond my original
intent as immutable means just that it is set once and never changed.
Although just going through this though experiment on locking leads me
to believe that the persistence proposed in the NIP should change
regardless to list out properties that are now set as immutable rather
than simply tracking hasBeenStarted on the ConnectorNode. But if we
want these additional features (lock/reset) then I would agree lets
tweak the semantics as mentioned above.
Sincerely,
Bob
On 7/23/2026 11:16 AM, David Handermann wrote:
Bob,
Thanks for initiating the discussion. Based on Pierre's comment, and
considering the general notion of Connector Properties, it would be
helpful to consider the naming semantics a bit more.
Immutable strongly connotes inability to change, whereas it seems the
more specific goal is to support a set-once strategy. Rather than
immutable, perhaps something more along the lines of a Property Status
would be helpful. The status could be LOCKED or UNLOCKED as a way to
communicate whether it could be changed. Those may not be the best
semantic names, so I'm open to ideas.
Another approach might be something like indicating the phase or stage
at which a property can be configured. Such as initialization versus
any.
The core concept certainly sounds useful, so I'm in favor of the goal,
but would like to see some iteration on the particulars before final
approval.
Regards,
David Handermann
On Thu, Jul 23, 2026 at 10:26 AM Pierre Villard
<[email protected]> wrote:
Hi Bob, thanks for the proposal.
I definitely do see the value of making sure some properties cannot be
changed after the connector starts. I guess that with this change we
would be saying that the connector has to be deleted and recreated to
make a configuration change for such properties. I imagine that in the
future we may want to expose a way to "reset" the connector so that it
does not need to be deleted. And, in this case, the connector could
have some code to take the appropriate actions in such a scenario.
Definitely a +1 for the NIP.
Thanks,
Pierre
Le jeu. 23 juil. 2026 à 14:56, Bob Paulin <[email protected]> a écrit :
Hi,
I'd like to raise a proposal to add an immutable option to
ConnectorPropertyDescriptor. I've included details in a JIRA [1] for
review by the community. If the proposal is of interest to the
PMC I'd
like to request a sponsor per [2] since I am neither PMC or a
committer
on the project. Thank you for your consideration!
Sincerely,
Bob Paulin
[1] https://issues.apache.org/jira/browse/NIP-36
[2]
https://cwiki.apache.org/confluence/spaces/NIFI/pages/318606579/NiFi+Improvement+Proposal+Process
