Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add human-readable property to identify TypeInstance #579

Open
mszostok opened this issue Dec 12, 2021 · 0 comments
Open

Add human-readable property to identify TypeInstance #579

mszostok opened this issue Dec 12, 2021 · 0 comments
Labels
area/cli Relates to CLI area/dashboard Relates to Dashboard area/engine Relates to Engine area/gateway Relates to Gateway area/hub Relates to Hub area/hub-manifests Relates to Hub manifests area/ocf Relates to Open Capability Format enhancement New feature or request needs-triage Relates to issues that should be refined

Comments

@mszostok
Copy link
Member

mszostok commented Dec 12, 2021

Description

Currently, TypeInstance has:
- ID
- createdBy (optional)
- lockedBy

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

  • System User - I want to have an option to identify created TypeInstance without checking the implementation details (value property). This gives an option to select proper input TypeInstance both from CLI and UI.

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.

@mszostok mszostok added enhancement New feature or request area/engine Relates to Engine area/hub Relates to Hub area/cli Relates to CLI area/gateway Relates to Gateway area/ocf Relates to Open Capability Format area/hub-manifests Relates to Hub manifests needs-triage Relates to issues that should be refined labels Dec 12, 2021
@mszostok mszostok added the area/dashboard Relates to Dashboard label Dec 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/cli Relates to CLI area/dashboard Relates to Dashboard area/engine Relates to Engine area/gateway Relates to Gateway area/hub Relates to Hub area/hub-manifests Relates to Hub manifests area/ocf Relates to Open Capability Format enhancement New feature or request needs-triage Relates to issues that should be refined
Projects
None yet
Development

No branches or pull requests

1 participant