Mike,
Thanks for bringing that up. It's a good point that we need to keep in mind. As
mentioned,
the NAR Maven Plugin will be generating the info necessary and putting it into
the NAR. One
piece of information that it will gather is any Controller Service API's that
are provided by a given
implementation. So the registry will have this information. So the technical
details are not concerning.
We do, however, need to ensure that we provide a good User Experience for such
a thing. Perhaps
when you click to create a new Controller Service from a 'Configure' dialog we
should have a way to
jump to a 'remote registry browser' type of thing and download from there...
> On Nov 13, 2018, at 2:32 PM, Michael Moser wrote:
>
> I have thought about this in the past, too. Here's a scenario where I
> could never really lay down an approach I was happy with.
>
> Consider that a NiFi user searches the NiFi registry and finds the PutMongo
> processor. Registry knows the PutMongo processor is in the
> nifi-mongodb-nar, and through its Nar-Dependency-Id that it has a
> dependency on a controller service interface in
> nifi-mongodb-client-service-api-nar. Great, the user can then download and
> install those two nars. How would we then suggest that the user also needs
> a MongoDBClientService controller service implementation, such as that in
> the nifi-mongodb-services-nar?
>
> I'm not looking for an answer now, of course, but I just wanted to feed the
> discussion.
>
> Thanks,
> -- Mike
>
>
> On Tue, Nov 13, 2018 at 1:34 PM Bryan Bende wrote:
>
>> Mark,
>>
>> I think there are a couple of ways that could be solved, but
>> ultimately it would be up to how the users choose to setup/manage the
>> registry, or registries.
>>
>> The NiFi Registry security model is based around permissions to
>> buckets (read/write), and all versioned items belong to a bucket. So
>> you could think of each bucket as a mini extension repository for
>> which you can control access to specific users and groups, so there
>> could be a bucket of extensions for each of the NiFi instances in your
>> example. There can also be multiple registry instances registered with
>> a given NiFi so extensions can be pulled from multiple registries.
>>
>> The extensions an instance needs is based on the flows it is running,
>> the flows already have specific bundle coordinates for every component
>> in the flow. You can think of it similar to Maven where you declared a
>> dependency on library foo and the build goes out and gets it for you,
>> in this case it is a flow that declares a dependency on a bundle.
>>
>> Mike,
>>
>> Bundles would need to be uploaded to NiFi Registry (to a specific
>> bucket) as part of some TBD release process. At a minimum I was
>> envisioning NiFi CLI commands that can be pointed to a file or a
>> directory and upload the given bundles to registry. There could be
>> other options as well, possibly through a Maven plugin to release
>> directly into registry, or possibly to have a type of extension in
>> NiFi Registry that actually points to an external location, i.e. all
>> the NARs that end up in Maven central could somehow be imported into
>> NiFi Registry, but with pointers back to the content which actually
>> comes from Maven central. Lot of things to figure out here.
>>
>> -Bryan
>> On Tue, Nov 13, 2018 at 1:16 PM Joe Witt wrote:
>>>
>>> Group selection based on tag names for bundles could probably do that.
>>> Meaning it could be a sorting/filtering mechanism in the NiFi/Registry
>>> interface perhaps. Will be good to consider that UX as that
>>> progresses.
>>>
>>> As far as the different environments NiFi instances would certainly be
>>> able to load only referenced Nars for versioned flows so you'll get
>>> the optimal set (at runtime) automatically. Very powerful.
>>> On Tue, Nov 13, 2018 at 1:12 PM Mark Bean wrote:
Joe,
I envision the Registry being able to provide a subset of NARs
>> required for
a specific NiFi instance. The user may have a relatively small set of
>> NARs
required for a NiFi used for basic routing/distribution, and a
>> different
more extensive set of NARs required for a more robust NiFi instance
>> which
performs various forms of processing/transformations. The grouping I am
describing would be a way to select multiple NARs required for a
>> specific
NiFi instance.
Expanding the scenario a little farther, suppose an integration/test
environment defines the group. Then, the production environment can
>> use the
group definition to pull (or ensure it possesses) only the relevant
>> NARs
necessary.
-Mark
On Tue, Nov 13, 2018 at 1:00 PM Joe Witt wrote:
> Mark
>
> Can you describe your use case from the user perspective both for the
> entity that would upload the items and demarcate them as a group as
> well as the user that would consume those
