nifi-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [nifi] bbende commented on issue #3492: NIFI-6164 - Added CLI commands related to NiFi Registry extension bun…
Date Thu, 13 Jun 2019 14:50:27 GMT
bbende commented on issue #3492: NIFI-6164 - Added CLI commands related to NiFi Registry extension
bun…
URL: https://github.com/apache/nifi/pull/3492#issuecomment-501736731
 
 
   @kevdoran thanks for the review! Here are my thoughts on the comments...
   
   - I definitely agree that we may want to be consistent with the bucket id. In Registry's
REST API there are basically two different ways to navigate the bundle stuff:
   
       - The "extension repository" end points which were meant to act kind of like Nexus.
These end points have the following paths:
       ```
       /extension-repository/ (returns buckets)
       /extension-repository/{bucket-name} (returns groups)
       /extension-repository/{bucket-name}/{group-id} (returns artifacts)
       /extension-repository/{bucket-name}/{group-id}/{artifact-id} (returns versions)
       /extension-repository/{bucket-name}/{group-id}/{artifact-id}/{version}/content 
       ```
       -  The end points that use ids which are more similar to the flow end-points:
       ```
       /buckets/{bucketId}/bundles
       /bundles
       /bundles/{bundle-id}
       /bundles/{bundle-id}/versions
       /bundles/{bundle-id}/versions/{version}/content
       ```
       So right now the list commands are basically just following the extension repo end-points,
so it    would be similar to navigating those links in your browser. We can switch to the
others if we think it makes more sense, but not sure that both can easily be supported through
the same command since the params are different.
   
   - Ironically I originally had a list end point exactly like you described, but then decided
to change to the idea of navigating the extension repo end points above. The issue with the
list end point is that if you don't know what to filter on, then it just returns this crazy
long list of everything. For example, there are 103 NARs in NiFi currently, so you get rows
= 103 * versions per NAR.  We could maybe add it back but require at least a group id?
   
   - I think the way the upload commands evolved I had implemented `upload-bundle` first which
could be used for any type, then I just wanted an easy way to upload everything from NIFI
without having to worry about understanding the bundleType parameter. So I figured we would
just add another command for `upload-minifi-bundles`, but I see your point that really a single
`upload-bundles` command could work for any type, so I can work on that change.
   
   - You are probably right that there is limited use for the tag commands from the CLI perspective,
but I guess I was thinking that we might not have a UX on NiFi side for a while, so this is
another way to search for extensions rather than using the Registry REST API. From an automation
perspective, really only the upload and download commands actually make sense. The rest of
the stuff is more for interactive use. I think the ideas you had about how to change the tag
commands make sense, I'll work on that. 

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message