1

When using DELETE /buckets/{bucketId}/flows/{flowId},

it cannot delete a flow which has version 0.

for example, something like the following flow cannot be deleted via the above http call.

{
    "bucketIdentifier": "6a0f624c-3163-496e-bb60-9ca4fe287654",
    "bucketName": "flow_bucket",
    "createdTimestamp": 1550243254914,
    "description": "A Versioned Flow from pyApi",
    "identifier": "d3738331-78b3-4dda-ab6b-a2975db762ff",
    "link": {
        "href": "buckets/6a0f624c-3163-496e-bb60-9ca4fe287654/flows/d3738331-78b3-4dda-ab6b-a2975db762ff",
        "params": {
            "rel": "self"
        }
    },
    "modifiedTimestamp": 1550243254914,
    "name": "test flow by pyApi",
    "permissions": {
        "canDelete": true,
        "canRead": true,
        "canWrite": true
    },
    "type": "Flow",
    "versionCount": 0
}

Is there any other way to delete such flow? This flow is created by nipyapi.versioning.save_flow_ver() given a different flow_name. Although it fails with 409, it still creates a flow in Nifi registry. The storage is git(gitlab specifically)

kevdoran
  • 703
  • 4
  • 11
Holm
  • 2,987
  • 3
  • 27
  • 48

2 Answers2

2

Seems unlikely.. Flows in NiFi-Registry start with version 1. If so, it's a bug. You should be able to delete it directly from the filesytem though. The flows are by default held under {NIFI_INSTALLATION_FOLDER}/flow_storage/{BUCKET_ID}/. Just remove the directory whose name is this flow id. This should fix it.

EDIT:

forgot to mention that you also need to edit the db file(H2) placed by default in {NIFI_INSTALLATION_FOLDER}/database

Ben Yaakobi
  • 1,620
  • 8
  • 22
  • I use gitlab as storage. will update it in the description – Holm Feb 19 '19 at 08:30
  • @AkiraSendoh should be the same.. Just delete it from your storage(should it be local or git) and remove it from your db as well – Ben Yaakobi Feb 19 '19 at 11:49
  • I see. that flow id does not exist in git. next time I will try to find it in the file system – Holm Feb 19 '19 at 12:00
2

I agree with Ben it is likely you are encountering a bug and not intended behavior. In addition to the suggestion to manually edit the H2 metadata database, you could also try adding a flow snapshot version (the versioned flow could be anything), to get version 1 saved for this flow, and then deleting the entire flow. That is:

POST /buckets/6a0f624c-3163-496e-bb60-9ca4fe287654/flows/d3738331-78b3-4dda-ab6b-a2975db762ff/versions/
DELETE /buckets/6a0f624c-3163-496e-bb60-9ca4fe287654/flows/d3738331-78b3-4dda-ab6b-a2975db762ff

I will open an Apache Jira issue to track fixing this bug.

kevdoran
  • 703
  • 4
  • 11
  • 1
    the situation happened when versioning a flow which is already versioned with a different `flow_name` using git as storage – Holm Feb 19 '19 at 08:48
  • thanks that is useful to reproduce. such a call should probably be treated as a transaction so that it cannot partially succeed. you can watch this Jira to track the fix: https://issues.apache.org/jira/browse/NIFIREG-228 – kevdoran Feb 19 '19 at 14:00
  • cool, I think it's partly resolved, because receiving 409 should not create an entry in the registry? it basically means the process group should not have the other versioned flow with a different versioned flow name, as it already has one versioned flow, or? – Holm Feb 20 '19 at 16:42