[
https://issues.apache.org/jira/browse/NIFI-14159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17913325#comment-17913325
]
Joe Witt commented on NIFI-14159:
---------------------------------
There are a wide range of elements in here. Perhaps better as a discussion
thread or something first rather than a JIRA but regardless thanks for
documenting your thoughts.
One key thing to keep in mind is the separation of church (versions) and state
(state of things).
When you store into version control code you don't expect an API to/through
that to also check on the state of that code such as the value of
variables/etc.. And this is similar. We do have to contend with the
difference between the running state of a thing as true in an actual deployment
and we have to consider that while wanting to manipulate a running flow there
are realities that have to be dealt with related to data sitting in queues and
when versions are changed does the data in the queue get lost? Have its same
semantics in the new graph?
Net net there is a lot to all this and we'd need to hone in on more precise
examples/cases to discuss how to achieve the headless mode you're describing.
It is quite common but yes you end up needing good tooling around it to make
things like upgrades hands-off.
Thanks
> NIFI flexible Version Control
> -----------------------------
>
> Key: NIFI-14159
> URL: https://issues.apache.org/jira/browse/NIFI-14159
> Project: Apache NiFi
> Issue Type: Wish
> Components: Flow Versioning
> Affects Versions: 2.1.0
> Reporter: David Pfingst
> Priority: Major
> Labels: gitlab, nifi, versioning
>
> As a NiFi User / Admin I want to run Nifi with a complete deployment via
> GitLab Pipeline so that it's not necessary to login into UI for bringing
> changes into production environment. I want to use NiFi mostly headless with
> a single admin user for service and other users only for monitoring purposes.
> At the moment I'm using the NiFi REST API in a Pipeline script to achieve the
> functions that aren't integrated into NiFi Version Control itself (deployment
> of the new version) but there are restrictions that would be too complicated
> to solve with the API. For an example the running state of the single
> processors should be possible to get via version control. When I change the
> state of a processor on my developement environment (local NiFi) this state
> should be set on the production server as well when I deploy the new version.
> My wishes for a flexible Version Control:
> * Select per process group what should be versioned (checkbox for services,
> running states, etc.)
> * Version Control of Parameter providers (maybe passwords fillable with
> CI/CD Variables from GitLab?)
> * Position of the Processor in canvas (could help with automatic deployment
> via GitLab)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
