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

Implement gRPC delegation in Local Hub #645

Closed
8 tasks done
mszostok opened this issue Feb 24, 2022 · 1 comment
Closed
8 tasks done

Implement gRPC delegation in Local Hub #645

mszostok opened this issue Feb 24, 2022 · 1 comment
Assignees
Labels
area/engine Relates to Engine area/hub Relates to Hub enhancement New feature or request
Milestone

Comments

@mszostok
Copy link
Member

mszostok commented Feb 24, 2022

Description

After Investigate existing solutions to speed up Local Hub rewrite task, we decided to give up with Local Hub rewrite. Instead, we will implement our delegated storage in separate Go service and use gRPC in Local Hub to delegate values resolution.

The initial protobufs were defined in #644

Steps

  • Distinguish if backend is built-in or not:
    • if external, execute gRPC call to save/lock/unlock/update/delete a given value. (for now context is ignored, will be done in Handle multiple backends for the TypeInstance upload from workflow #634)
    • ensure that transaction is aborted in case of any error
    • store returned TypeInstance.backend.context if not empty

      Q: what is the contract here? should delegated storage always return context, even if not modified or not?

  • Refactor Local Hub structure to enable its extensibility.
  • Refactor the createTypeInstance mutation to use the createTypeInstances. If not possible, remove it and adjust all its usage.
  • Refactor Local Hub and extract logic for backend resolution:
    // Backend
    WITH *
    CALL apoc.do.when(
    $in.backend.id IS NOT NULL,
    '
    WITH false as abstract
    RETURN $in.backend.id as id, abstract
    ',
    '
    // TODO(storage): this should be resolved by Local Hub server during the insertion, not in cypher.
    WITH true as abstract
    MATCH (backend:TypeInstance)-[:OF_TYPE]->(typeRef {path: "cap.core.type.hub.storage.neo4j"})
    RETURN backend.id as id, abstract
    ',
    {in: $in}
    ) YIELD value as backend
  • Refactor Local Hub and store value only for built-in storage backends
  • Execute gRPC call to:
    • create
    • lock/unlock
    • update
    • delete

Additional

  • Update Local Hub GraphQL mutations and queries with backend.context property. It should be of type Any!. For example:

    • Mutation
      mutation CreateTypeInstances {
        createTypeInstances(
          in: {
           typeInstances: [
            {
              alias: "helm-release"
              typeRef: { path: "cap.type.helm.chart.release", revision: "0.1.0" }
              value: {
                key: "test" # same as it was
              }
              backend: {
                id: "123" # it's like that already.
                context: { # new property of type `Any!`
                  name: "release-name",
                  namespace: "release-namespace",
                }
              }
            }
          ]
        }
        ) {
          id
          alias
        }
      }
    • Query
      query GetTypeInstance($typeInstanceID: ID!) {
        typeInstance(id: $typeInstanceID) {
          id
          typeRef {
            path
            revision
          }
          backend { # current backend entry
            id
            abstract
          }    
          lockedBy
          latestResourceVersion {
              resourceVersion
              createdBy
              metadata {
                attributes {
                  path
                  revision
                }
              }
              spec {
                value
              }
              backend {
                context { # new property of type `Any!`
                  name
                  namespace
                }
              }
          }
        }
      }
  • Validate Storage TypeInstance value - Stretch, if not possible, extract to dedicated task. - extracted to: Add Storage TypeInstance related validation #656

  • Integration tests are out of scope

Related issues

See epic #604 for reason and use cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/engine Relates to Engine area/hub Relates to Hub enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant