[
https://issues.apache.org/jira/browse/NIFIREG-242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16811804#comment-16811804
]
Dennis Seiffert commented on NIFIREG-242:
-----------------------------------------
{code:java}
if (this.flowPersistenceProvider instanceof GitFlowPersistenceProvider){
deleteAllBucketsInMetaDatabase();
return createBucketsFromGitProvider();
}{code}
@Bryan Bende I refactored this code snippet a bit to be aligned with the idea
to have a synchronization behavior attached to each type of persistence
provider (git, file system, S3, etc.) by implementing the
ProviderSynchronization- interface. Each provider has to decide on his own, if
it is able to synchronize the data (canBeSynchronized returns true or false)
and how the data should be synchronized (may be very provider specific in most
cases).
Indeed our focus was to have this behavior at the GitFlowPersistenceProvider at
first. We are dealing with NiFi flows the same way as we do with ordinary
source code and therefore we are pretty happy to persist the flows with the git
provider. This way we are able to apply proved principles like development,
staging and production environments in order to verify our NiFi flows
(persisted in a develop branch in git, for instance) and bring it into
production (merge into master branch) with the need to keep the registry
metadata in sync with git. That was the key point for us implementing a sync
mechanism for the git provider.
As a side note: We would use two different registries (one registry for staging
with a coupled develop branch and another one for live environments) and
therefore we work around the 'missing' branching concept in the registry (not
sure if it is really missing).
If I get it right, the extension point should enable people to bring in their
own persistence provider more easily on the one hand. On the other hand the
registry could deal with more than one persistence provider?
The implementation we provided does not consider this because we assume that
there is only one provider existing at a time, so in particular the
deleteAllBucketsInMetaDatabase would delete all assets in the buckets
independent of whether the asset came in by a different provider or not. Is
there already a correlation of an asset and its origin provider to make it
possible to delete provider specific items ?
Thanks for the remark concerning NIFIREG- 228 because it will definitely help
us to solve the problem of changed registry urls in process groups.
> Two-way synchronization of git repository backed flows
> ------------------------------------------------------
>
> Key: NIFIREG-242
> URL: https://issues.apache.org/jira/browse/NIFIREG-242
> Project: NiFi Registry
> Issue Type: New Feature
> Affects Versions: 0.4.0
> Reporter: Dennis Seiffert
> Priority: Major
> Labels: git
>
> With this feature the NiFi user and developer's life using git as version
> control as a backend for the registry would be easier (especially in
> dockerized environments). As a conclusion the git repository would be the
> single source of truth in order to maintain NiFi flows. This feature contains
> the following abilities without affecting existing functionality:
> * synchronize remote git repository with local (nifi- registry) git
> repository in order to support multiple registries (imagine changing a flow
> in a test environment and update the flow in a productive environment via
> feature branches in git, etc. ) and third party systems (git changes not done
> by the registry, repair broken flow file because of changed registry url in
> flow xml)
> * initial import of git repository into registry's metadata database on
> startup (see open issue #NIFIREG-227)
> * ability to reset local git repository (including metadata database) to the
> state of the remote repository
> * get recent status of synchronization process
> * control synchronization via REST- endpoints (reset repository to initial
> state, pull latest changes from git remote repository
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
