You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

1. Purpose

This page will capture design ideas for creating an Apache NiFi registry for extensions and templates, allowing them to be easily pulled into a NiFi instance, and thus reducing the amount of bundles distributed with an Apache NiFi release.

2. Requirements

  • Ability to upload a NAR or template
  • Ability to search for a NAR or template
  • Ability to add a NAR or template from the registry to a NiFi instance

3. Registry Examples

This section will describe how some other projects are tackling the same type of problem.

Spark-Packages

  • Requires authentication with a GitHub account.
  • Registering a package requires pointing to a public GitHub repo owned by the given user, with a LICENSE and README. 
  • A name and description are also provided during registration.
  • There is a command line tool to help start new packages and publish them.
  • The web site lets a user search for packages and view details of each package.
  • The details of a package show how to use the given package with various tools such as the spark-shell, sbt, and/or Maven, see example. 
  • For Maven it shows a dependency and repository snippet that could be added to a pom, and there seems to be a repository.
  • Packages can also be voted on and tagged.

4. NiFi Registry Design

 

5. Implementation Considerations

  • A NAR will need to be able to specify the minimum and maximum versions of the nifi-api that the NAR can work against
  • If a NAR has a "Parent NAR", it will need to be able to specify the minimum and maximum versions of the Parent NAR that it can work against
  • NARs and Templates will be uploaded from non-Apache sources, so they should provide some mechanism of indicating the vendor name/contact info, as well as the URL for an Issue Tracking System
  • No labels