GraphQL: staging - Deploy version v0.0.8.1

changed milestone to %GraphQL API

Could you explain a little more the impacts of the keycloak and cache settings, what is expected in term of configuration / role / etc... Is there any documentation available?

I checked in the commit history of graphql and it seems there is a typo in the expected configuration key: https://gitlab.softwareheritage.org/swh/devel/swh-graphql/-/blob/b8545190aa6d451bb1f325ec68bf2a992f419548/swh/graphql/config/staging.yml#L19

nice catch, it should be 'realm' indeed.

jay fixed it in swh/devel/swh-graphql@0ef467bf

Thanks, I have fixed the typo.

GraphQL is using the API tokens generated here as auth headers. Since we don't have a UI for generating tokens for just GraphQL, we are reusing swh-web client here. As of now it is not using any user roles, but used to identify the user is authenticated or anonymous. An authenticated used will be able to run bigger quries. I will be adding a new role for GraphQL in the future.

Auth tokens generated in keycloak are valid for several minutes. The cache is used only for persisting those. Hence the structure with cache inside the auth

auth:
  server: https://auth.softwareheritage.org/auth/
  realm: SoftwareHeritageStaging
  client: swh-web
  cache:
    url: memcached://localhost:11211

We are using memcached for the same purpose in swh-web. I hope we can re-use the same service. This cache is not expected to grow a lot in size.

I have plans to create another cache for nodes and that will be another config entry with different parameters.

added #4786 (closed) as child task

added #4787 (closed) as child task

added #4788 (closed) as child task

added #4789 (closed) as child task

@vsellier created the new tag after the typo fix (v0.0.8.2). Sorry that I forgot this yesterday.

Some more details I forgot to mention are,

All the keys in this cache are short lived and is using the same cache key as in swh-web. I hope this will help you in deciding whether to create a new namespace or not.

thanks, no problems, there is some adaptions to do on the deployment descriptors to add the new configuration keys.

Graphql is deployed in standalone in the new elastic infra so it will use a dedicated memcache instance, at least at the beginning.

btw, one note for later, is there any reason to use such version X.Y.Z.A? using the usual 3 levels semver versions should be enough ;)

mentioned in commit swh/infra/ci-cd/swh-charts@65cf7c34

mentioned in merge request swh/infra/ci-cd/swh-charts!30 (merged)

mentioned in commit swh/infra/ci-cd/swh-charts@428d0a38

mentioned in merge request swh/infra/ci-cd/swh-charts!31 (merged)

mentioned in commit swh/infra/ci-cd/swh-charts@9f18a481

mentioned in commit swh/infra/ci-cd/swh-charts@f9c0debf

assigned to @vsellier

mentioned in commit swh/infra/ci-cd/swh-charts@8da03bb4

mentioned in merge request swh/infra/ci-cd/swh-charts!32 (merged)

mentioned in commit swh/infra/ci-cd/swh-charts@0d49ddfe

mentioned in commit swh/infra/ci-cd/swh-charts@181c9882

mentioned in commit swh/infra/ci-cd/swh-charts@51d65a0b

mentioned in commit swh/infra/ci-cd/swh-charts@99bbb650

mentioned in commit swh/infra/ci-cd/swh-charts@132e933e

@jayeshv We have deployed the new version with a memcached and the auth configuration section but we don't see any item stored in memcached.

How can we check if the configuration is correct (logs or way to tests)?

We have tested with an unauthenticated user and with a user authenticated in the webapp.

The graphql configuration:

search:
  cls: remote
  url: http://search0.internal.staging.swh.network:5010
storage:
  cls: remote
  url: http://webapp.internal.staging.swh.network:5002

debug: true

introspection: true

max_query_cost:
  anonymous: 500

auth:
  server: https://auth.softwareheritage.org/auth/
  realm: SoftwareHeritageStaging
  client: swh-web
  cache:
    url: memcached://memcached:11211

grapqh container is able to correctly connect to memcached:11211

Thanks @vsellier. There is a small issue with the configuration.

max_query_cost should have two sub fields. anonymous and user see here

This is to set different max query limits depending on the user type. (In the future I might add one more type called GraphQL-user). Sorry for not explicitly mentioning this config change.

The current setup will cause an error when tested with an auth token.

To test this, the easiest way is using the explorer. Generate an API token and provide the following header.

{
  "Authorization": "Bearer <YOUR token>"
}

If the auth token is not avaialble, it will be treated as an anonymous user. An invalid or expired token will return an error.

If you wish, you can also test with curl or a script, eg here

I can test the cache only after this error is fixed.

Thanks, we missed it

We'll update the configuration accordingly.

~~For the record, the documentation to create an api token is available here: https://docs.softwareheritage.org/devel/swh-auth/cli.html#swh-auth-generate-token~~ the link you provided is way easier ;)

the configuration is updated, it looks ok, we are now seeing the tokens stored in memcached.

thanks

Thanks. I too tested that.

added state:wip label

mentioned in commit swh/infra/ci-cd/swh-charts@d9e01056

removed state:wip label

closed

GraphQL: staging - Deploy version v0.0.8.1

Designs

Child items ...

Activity