capactio / capact

Simple way to manage applications and infrastructure.
https://capact.io
Apache License 2.0
80 stars 19 forks source link

Add human-readable property to identify TypeInstance #579

Open mszostok opened 2 years ago

mszostok commented 2 years ago

Description

Currently, TypeInstance has:

Unfortunately, it's hard to select a proper TypeInstance based only on those values. For example, Capact Upgrade requires multiple input TypeInstance of Type cap.type.helm.chart.release Without looking into TypeInstance details (value.name) it's hard to determine for which release it was created. Looking into value property is also not generic approach as each Type stored different data there.

Screenshot 2021-12-12 at 14 20 44

NOTE: In case of Upgrade Action, probably we should change the input and require only the capact.config TI. The Helm releases TI should be taken from the relation property. The problem will still persist as e.g. the create-user Action for PostgreSQL also consumes the psql-config and we may have a lot of psql-config registered in our system.

We need to have a generic approach to identify TypeInstance easily by our users. It must work both for manually created TypeInstances (e.g. via CLI/GraphQL Console) and automatically created (e.g. via Capact Action)

Reason

We are not able to select a proper TypeInstance based only on ID.

Use cases

Possible solutions

Currently, we require the alias property when you want to create a relation between TypeInstances. For example,

typeInstances:
  - alias: parent # required when submitting more than one TypeInstance
    attributes: # optional
      - path: cap.attribute.cloud.provider.aws
        revision: 0.1.0
    typeRef: # required
      path: cap.type.aws.auth.credentials
      revision: 0.1.0
    value: # required
      accessKeyID: fake-123
      secretAccessKey: fake-456

usesRelations: # optional
  - from: parent
    to: 123-4313 # ID of already existing TypeInstance, or TypeInstance alias from a given request

This property can be required always, and we can add it to the created TypeInstance on Hub side. Only the ID + alias pair is unique. As a result, we don't need to introduce a new property in our API. In Action workflows this property is already populated (maybe we will need to adjust our naming pattern a bit), together with createdBy property it should give enough information to identify a given TypeInstance.