[DOC] Update Model/Connector API

[b4sjoo]

What do you want to do?

• [ ] Request a change to existing documentation
• [X] Add new documentation
• [ ] Report a technical problem with the documentation
• [ ] Other

Tell us about your request. Provide a summary of the request and all versions that are affected.

Currently, the model and connector APIs have endpoints for create and delete only. If a user wants to change the definition of a model or connector, they must delete it and re-create the object manually with the desired changes. Now, the team is introducing an updateConnector and updateModel API endpoint to allow for updating the model or connector in place.

Architecture

UpdateConnector

Note that the connector is stored as a JSON object with fields for parameters, actions (defines request that will be sent to the connector based on corresponding model call), credentials, and other metadata. Note that connectors use the ML Commons access control design, which includes a security plugin permission for accessing connectors and in addition each connector / model specifies which backend roles can be used to access it.

When calling the updateConnector API:

• only the fields being updated or introduced need to be supplied
• it is possible to remove fields by specifying an existing field name and the value as null
• only actions, parameters, and credentials can be updated (not name, description, etc)
• the owner should not be modifiable by someone other than the existing owner (TBD if the owner can be modified at all)
• only callers with the connector permission in the Security Plugin AND are a member of a backend role allowed by the specific connector can successfully authZ
• if any model which uses the connector is currently being used, calls to the connector API will fail
• no calls to the models which currently use the connector are needed in order to use the updated connector
• all validations done for createConnector should also be done for updateConnector. This includes:
• SSRF checks (on the URL provided)
• IAM passRole check (for the role ARN provided which has permissions to access to the endpoint)
• HTTP verb input validation (only POST and GET requests should be supported)
• the credentials object with all necessary keys and values must be passed for each call to the updateConnector API as an additional method of authZ (TBD for the service team to confirm they will use this approach)

UpdateModel

Note that the model is also stored as a JSON object. The model contains metadata and may point to a local model file, a connector id, or contain an inline connector definition. Note that models also use the ML Commons access control design, which includes a security plugin permission for accessing models and in addition each model specifies which backend roles can be used to access it.

When calling the updateModel API:

• the general approach is the same as updateConnector regarding access control, etc
• there are restrictions on which fields can be modified for the model and only the following fields should be modified via the updateModel API:
• model name
• config
• description
• connector_id
• model_group_id
• note that the updateModel API will do authZ checks on the associated connector as needed (if the connector_id changes or if the model has an inline connector definition)
• note that built-in models content cannot be updated through this workflow (like Kmeans, etc.), only text_embedding models as well as remote models (those based on connectors)

What other resources are available? Provide links to related issues, POCs, steps for testing, etc.

[hdhalter]

Hi @b4sjoo - Can you please provide more information about this issue, for instance, in what version was it (will it be) released? And are there any dev issues related to this update? Thanks!