[
https://issues.apache.org/jira/browse/NIFIREG-162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16454369#comment-16454369
]
ASF GitHub Bot commented on NIFIREG-162:
----------------------------------------
Github user bbende commented on the issue:
https://github.com/apache/nifi-registry/pull/112
Been testing this and has been looking good so far...
I was doing a test where I configured to push to a remote, but I didn't
supply a username/password because I honestly wasn't sure if the push would
leverage my cached credentials at the OS level.
So the push failed with an exception like:
```
Caused by: org.eclipse.jgit.errors.TransportException:
https://github.com/bbende/nifi-versioned-flows.git: Authentication is required
but no CredentialsProvider has been registered
at
org.eclipse.jgit.transport.TransportHttp.connect(TransportHttp.java:522)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at
org.eclipse.jgit.transport.TransportHttp.openPush(TransportHttp.java:435)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at org.eclipse.jgit.transport.PushProcess.execute(PushProcess.java:160)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at org.eclipse.jgit.transport.Transport.push(Transport.java:1344)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
at org.eclipse.jgit.api.PushCommand.call(PushCommand.java:169)
~[org.eclipse.jgit-4.11.0.201803080745-r.jar:4.11.0.201803080745-r]
... 109 common frames omitted
```
This makes sense, but the result was that the flow was committed to the
local repo, but because of the error when pushing, the error was thrown out of
the REST layer and the response to NiFi indicated that starting version control
failed. So it was left in a weird state where NiFi now thinks the process group
is not under version control, but the local repo does have the first version
saved.
Do you think we should catch any exceptions around the push inside the
persistence provider and log them, but maybe not throw an error?
That would leave things in a more consistent state, but I'm kind of torn
because then it may not be obvious to users that the pushes are failing unless
they look in the registry logs.
> Add Git backed persistence provider
> -----------------------------------
>
> Key: NIFIREG-162
> URL: https://issues.apache.org/jira/browse/NIFIREG-162
> Project: NiFi Registry
> Issue Type: Improvement
> Reporter: Koji Kawamura
> Assignee: Koji Kawamura
> Priority: Major
>
> Currently, NiFi Registry provides FileSystemFlowPersistenceProvider, which
> stores Flow snapshot files into local file system. It simply manages snapshot
> versions by creating directories with version numbers.
> While it works, there are also demands for using Git as a version control and
> persistence mechanism.
> A Git backend persistence repository would be beneficial in following aspects:
> * Git is a SCM (Source Control Management) that manages commits, branches,
> file diffs, patches natively and provide ways to contribute and apply changes
> among users
> * Local and remote Git repositories can construct a distributed reliable
> storage
> * There are several Git repository services on the internet which can be used
> as remote Git repositories those can be used as backup storages
> There are few things with current NiFi Registry framework and existing
> FileSystemFlowPersistenceProvider those may not be Git friendly:
> * Bucket id and Flow id are UUID and not recognizable by human, if those
> files have human readable names, many Git commands and tools can be used
> easier.
> * Current serialized Flow snapshots are binary files having header bytes and
> XML encoded flow contents. If those are pure ASCII format, Git can provide
> better diffs among commits, that can provide better UX in terms of
> controlling Flow snapshot versions
> * NiFi Registry userid which can be used as author in Git commit is not
> available in FlowSnapshotContext
> Also, if we are going to add another Persistence Provider implementation, we
> also need to provide a way to migrate existing persisted files so that those
> can be used by new one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
