opensearch-project / flow-framework

OpenSearch plugin that enables builders to innovate AI apps on OpenSearch
Apache License 2.0
27 stars 25 forks source link

[FEATURE] Support editing of certain workflow fields on a provisioned workflow #749

Closed ohltyler closed 16 hours ago

ohltyler commented 2 weeks ago

Currently, the update API will not execute on a workflow that is not in NOT_STARTED state (has been provisioned, failed during provision, is currently provisioning, etc.). This prevents losing track of created resources, and enforcing deprovision will work as expected.

The current logic is simplified, and blanket denies any proposed update, even for trivial fields like name or ui_metadata. This prevents users from updating these things on a provisioned workflow, even if their goal is to not change the critical parts of the workflow template.

Additionally, on the frontend, a desired capability is updating a frontend configuration (which may be incomplete or in-progress) on some provisioned workflow, as a "lightweight" save. _All of the frontend configuration is stored under ui_metadata_. This may be done manually by the users, and/or in a scheduled way, such as autosaving. These save scenarios we want to be able to do at any point, without disrupting what may be currently deployed. Only when users want to run actual functionalities against the workflow (ingest/search/export) do we want to update the underlying template and perform the deeper deprovision/reprovision.

One proposal is allowing specific fields in the workflow schema to be allowed to be updated, at the REST level of the update API. I could see a few options for how the interface may look:

Option 1. Using the existing update API and passing in the entire workflow configuration, and letting the backend perform a diff and determine that based on the changed fields and the state of the workflow, if the update is allowed or not

PUT /_plugins/_flow_framework/workflow/my-workflow-id
{
    "name": "my-new-name",
    "description": "my existing description",
    "workflows": {
        "provision": { <some-unchanged-provision-flows> }
    },
    ...,
}

Option 2. Allowing users to only specify the fields they want to update in the API body, something like:

PUT /_plugins/_flow_framework/workflow/my-workflow-id
{
    "name": "my-new-name"
}
dbwiddis commented 2 weeks ago

The Update Document API easily allows key-by-key replacement. Or we can just upsert the whole document after parsing it ourselves as I did in #631.

dbwiddis commented 1 day ago

PR #757 adds these fields:

/** Fields which may be updated in the template even if provisioned */
private static final Set<String> UPDATE_FIELD_ALLOWLIST = Set.of(
    NAME_FIELD,
    DESCRIPTION_FIELD,
    USE_CASE_FIELD,
    VERSION_FIELD,
    UI_METADATA_FIELD
);

This is essentially the whole Template except for the Workflow field and the auto-generated timestamps, and none of these fields impact the provisioning.

minalsha commented 1 day ago

@dbwiddis can you please share doc issue created for this feature?

ohltyler commented 1 day ago

It is linked in the linked PR #757 : https://github.com/opensearch-project/documentation-website/pull/7632

minalsha commented 1 day ago

ahh my bad. thank you

minalsha commented 1 day ago

we need to first create a doc issue for the same and link it to it. That's how doc team track. Just FYI

dbwiddis commented 1 day ago

Ah, haven't done that for any of the earlier features, will take care of that.