{"id":13564603,"url":"https://github.com/sentry-kubernetes/charts","last_synced_at":"2026-02-07T15:30:09.722Z","repository":{"id":37086697,"uuid":"235453730","full_name":"sentry-kubernetes/charts","owner":"sentry-kubernetes","description":"Easily deploy Sentry on your Kubernetes Cluster","archived":false,"fork":false,"pushed_at":"2024-10-29T12:53:17.000Z","size":143715,"stargazers_count":1085,"open_issues_count":34,"forks_count":513,"subscribers_count":21,"default_branch":"develop","last_synced_at":"2024-10-29T15:19:44.425Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Smarty","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sentry-kubernetes.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2020-01-21T22:25:51.000Z","updated_at":"2024-10-28T08:15:23.000Z","dependencies_parsed_at":"2023-02-16T21:30:39.869Z","dependency_job_id":"43d3eb87-1c0d-40c9-b97b-3a2a4ed0841b","html_url":"https://github.com/sentry-kubernetes/charts","commit_stats":null,"previous_names":[],"tags_count":173,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sentry-kubernetes%2Fcharts","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sentry-kubernetes%2Fcharts/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sentry-kubernetes%2Fcharts/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sentry-kubernetes%2Fcharts/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sentry-kubernetes","download_url":"https://codeload.github.com/sentry-kubernetes/charts/tar.gz/refs/heads/develop","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247083178,"owners_count":20880791,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-08-01T13:01:33.513Z","updated_at":"2026-02-07T15:30:09.704Z","avatar_url":"https://github.com/sentry-kubernetes.png","language":"Smarty","funding_links":[],"categories":["Mustache","others"],"sub_categories":[],"readme":"# Sentry helm charts\n\nSentry is a cross-platform crash reporting and aggregation platform.\n\nThis repository aims to support Sentry \u003e=10 and move out from the deprecated Helm charts official repo.\n\nBig thanks to the maintainers of the [deprecated chart](https://github.com/helm/charts/tree/master/stable/sentry). This work has been partly inspired by it.\n\n## How this chart works\n\n```\nhelm repo add sentry https://sentry-kubernetes.github.io/charts\nhelm repo update\nhelm install my-sentry sentry/sentry --wait --timeout=1000s\n```\n\n## Values\n\nEach chart has its own `README.md` in its directory with values and configuration instructions (for example `charts/sentry/README.md`).\nThe changelog below refers to the main `sentry` chart only.\n\n## Upgrading to Chart 29.x.x\n\n- Routing is now **opt-in**: all routing options are **disabled by default**. Choose and enable **exactly one** of `ingress.enabled`, `route.main.enabled`, `traefikIngressRoute.enabled`, or `nginx.enabled`.\n- When you use Kubernetes Ingress / Gateway API / Traefik, traffic is routed directly to `web`/`relay` to avoid an extra proxy hop and improve throughput.\n- Optional in-cluster NGINX service support is available via the CloudPirates `nginx` chart dependency. Enable it with `nginx.enabled=true` when you need a single service endpoint or nginx-specific routing snippets. Do not run another router in front of it.\n\nMigration guidance:\n\n- If you **do not** want an in-cluster nginx proxy, keep `nginx.enabled=false` and enable exactly one of `ingress.enabled`, `route.main.enabled`, or `traefikIngressRoute.enabled`.\n- If you **do** want an in-cluster nginx proxy, set `nginx.enabled=true` and keep `ingress.enabled`, `route.main.enabled`, and `traefikIngressRoute.enabled` disabled. Expose the `*-nginx` service directly (for example with `nginx.service.type=LoadBalancer`).\n- `ingress.alb.httpRedirect` was removed. For ALB HTTP→HTTPS redirect, set `alb.ingress.kubernetes.io/listen-ports` and `alb.ingress.kubernetes.io/ssl-redirect` in `ingress.annotations`.\n- Ingress templates now assume the stable `networking.k8s.io/v1` API.\n- Subpath routing options were removed (`route.main.path`, `traefikIngressRoute.path`); Sentry must be served at `/`.\n- If you previously relied on `nginx.extraLocationSnippet`, either keep using it with `nginx.enabled=true` or move the logic to ingress/controller configuration (annotations, controller ConfigMap) or dedicated routing objects via `extraManifests`.\n\nNginx Ingress, Traefik Ingress, GCE and AWS ALB are currently supported, pull requests for other controllers are welcome!\n\nRouting changes: see the [routing section](charts/sentry/README.md#routing) for the supported modes and configuration details.\n\n### External ClickHouse\n\nRemoved bundled ClickHouse. Use an external ClickHouse deployment and follow the [External ClickHouse guide](charts/sentry/docs/external-clickhouse.md).\n\n### Memcached chart switch\n\nThis release replaces the Bitnami Memcached dependency with the CloudPirates Memcached chart (`oci://registry-1.docker.io/cloudpirates/memcached`). Values have changed accordingly:\n\n- `memcached.args` and `memcached.extraEnvVarsCM` were removed.\n- `memcached.memoryLimit` is now `memcached.config.memoryLimit` (value in MB).\n- `memcached.maxItemSize` must be configured via `memcached.config.extraArgs` using the `-I` flag.\n\nExample:\n\n```yaml\nmemcached:\n  config:\n    memoryLimit: 2048\n    extraArgs:\n      - \"-I\"\n      - \"26214400\"\n```\n\n## Upgrading to Chart 28.x.x\n\n### Storage Configuration Changes\n\nThis release introduces significant changes to how Sentry handles storage for `nodestore` (raw events) and `profiling`. We strongly recommend using an external S3-compatible storage provider (e.g., AWS S3, Google Cloud Storage, MinIO) for these components to ensure performance and scalability, however, `nodestore` can be very write heavy (if you have tons of throughput), so take this into consideration (cloud bills).\n\n- **Nodestore**: You can now configure S3-based node storage via `nodestore.s3`.\n- **Profiles**: The `filestore.profiles` section now supports an S3 backend. Using the `filesystem` backend is discouraged for production environments.\n\nIf you require a self-hosted S3-compatible storage solution, we recommend [SeaweedFS](https://github.com/seaweedfs/seaweedfs/tree/master/k8s/charts/seaweedfs), which can be deployed using its official Helm chart.\n\n### Clickhouse\n\nThis release necessitates ClickHouse features introduced in v24.8. As this chart will henceforth require users to manage their own services, the bundled ClickHouse version is no longer compatible. You must provision your own cluster and migrate your data from the old one prior to upgrading. We recommend using the Altinity Kubernetes Operator: https://altinity.com/kubernetes-operator/\n\n### RabbitMQ Removed\n\nThe RabbitMQ dependency has been removed in favor of a new task broker architecture. Please review the `taskBroker` and `taskWorker` sections in `values.yaml`.\n\n## Upgrading from 26.x.x Version of This Chart to 27.x.x\n\nMake sure to upgrade to chart version 26.22.0 before upgrading to 27.x.x. There is a hard stop on the Sentry version.\n\n## Upgrading from 25.x.x Version of This Chart to 26.x.x\n\nMake sure to upgrade to chart version 25.20.0 (Sentry 24.8.0) before upgrading to 26.x.x.\n\n## Upgrading from 23.x.x Version of This Chart to 24.x.x/25.x.x\n\nMake sure to revert the changes on Clickhouse replica counts if the change doesn't suit you.\n\n## Upgrading from 22.x.x Version of This Chart to 23.x.x\n\nThis version introduces changes to definitions of ingest-consumers and workers. These changes allow to balance\ningestion pipeline with more granularity.\n\n### Major Changes\n\n- **Ingest consumers**: Templates for Deployment and HPA manifests are now separate for ingest-consumer-events,\n  ingest-consumer-attachments, and ingest-consumer-transactions.\n- **Workers**: Templates for two additional worker Deployments added, each of them with its own HPA. By default, they're\n  configured for error- and transaction-related tasks processing, but queues to consume can be redefined for both.\n\n### Migration Guide\n\nSince labels are immutable in Kubernetes Deployments, `helm upgrade --force` should be used to recreate ingest-consumer Deployments.\nAs an alternative, existing ingest-consumer Deployments can be removed manually with `kubectl delete` before upgrading the Helm release.\n\n## Upgrading from 21.x.x Version of This Chart to 22.x.x\n\nThis version introduces a significant change by dropping support for Kafka Zookeeper and transitioning to Kafka Kraft\nmode. This change requires action on your part to ensure a smooth upgrade.\n\n### Major Changes\n\n- **Kafka Upgrade**: We have upgraded from Kafka `23.0.7` to `27.1.2`. This involves moving from Zookeeper to Kraft,\n  requiring a fresh setup of Kafka.\n\n### Migration Guide\n\n1. **Backup Your Data**: Ensure all your data is backed up before starting the migration process.\n2. **Retrieve the Cluster ID from Zookeeper** by executing:\n\n   ```shell\n   kubectl exec -it \u003cyour-zookeeper-pod\u003e -- zkCli.sh get /cluster/id\n   ```\n\n3. **Deploy at least one Kraft controller-only** in your deployment with `zookeeperMigrationMode=true`. The Kraft\n   controllers will migrate the data from your Kafka ZkBroker to Kraft mode.\n\n   To do this, add the following values to your Zookeeper deployment when upgrading:\n\n   ```yaml\n   controller:\n     replicaCount: 1\n     controllerOnly: true\n     zookeeperMigrationMode: true\n   broker:\n     zookeeperMigrationMode: true\n   kraft:\n     enabled: true\n     clusterId: \"\u003cyour_cluster_id\u003e\"\n   ```\n\n4. **Wait until all brokers are ready.** You should see the following log in the broker logs:\n\n   ```shell\n   INFO [KafkaServer id=100] Finished catching up on KRaft metadata log, requesting that the KRaft controller unfence this broker (kafka.server.KafkaServer)\n   INFO [BrokerLifecycleManager id=100 isZkBroker=true] The broker has been unfenced. Transitioning from RECOVERY to RUNNING. (kafka.server.BrokerLifecycleManager)\n   ```\n\n   In the controllers, the following message should show up:\n\n   ```shell\n   Transitioning ZK migration state from PRE_MIGRATION to MIGRATION (org.apache.kafka.controller.FeatureControlManager)\n   ```\n\n5. **Once all brokers have been successfully migrated,** set **`broker.zookeeperMigrationMode=false`** to fully migrate them.\n\n   ```yaml\n   broker:\n     zookeeperMigrationMode: false\n   ```\n\n6. **To conclude the migration**, switch off migration mode on controllers and stop Zookeeper:\n\n   ```yaml\n   controller:\n     zookeeperMigrationMode: false\n   zookeeper:\n     enabled: false\n   ```\n\n   After the migration is complete, you should see the following message in your controllers:\n\n   ```shell\n   [2023-07-13 13:07:45,226] INFO [QuorumController id=1] Transitioning ZK migration state from MIGRATION to POST_MIGRATION (org.apache.kafka.controller.FeatureControlManager)\n   ```\n\n7. **(Optional)** If you would like to switch to a non-dedicated cluster, set **`controller.controllerOnly=false`**. This will cause controller-only nodes to switch to controller+broker nodes.\n\n   At this point, you could manually decommission broker-only nodes by reassigning its partitions to controller-eligible nodes.\n\n   For more information about decommissioning a Kafka broker, check the official documentation.\n\n## Upgrading from 20.x.x version of this Chart to 21.x.x\n\nBumped dependencies:\n\n- memcached \u003e 6.5.9\n- kafka \u003e 23.0.7 - This is a major update, but only kafka version is updated. See [bitnami charts' update note](https://github.com/bitnami/charts/tree/main/bitnami/kafka#to-2300)\n- clickhouse \u003e 3.7.0 - Supports `priorityClassName` and `max_suspicious_broken_parts` config.\n- zookeeper \u003e 11.4.11 - 2 Major updates from v9 to v11. See [To v10 upgrade notes](https://github.com/bitnami/charts/tree/main/bitnami/zookeeper#to-1000) and [To v11 upgrade notes](https://github.com/bitnami/charts/tree/main/bitnami/zookeeper#to-1100)\n- rabbitmq \u003e 11.16.2\n\n## Upgrading from 19.x.x version of this Chart to 20.x.x\n\nBumped dependencies:\n\n- kafka \u003e 22.1.3 - now supports Kraft. Note that the upgrade is breaking and that you have to start a new Kafka from scratch to use it.\n\nExample:\n\n```yaml\nkafka:\n  zookeeper:\n    enabled: false\n  kraft:\n    enabled: true\n```\n\n## Upgrading from 18.x.x version of this Chart to 19.x.x\n\nChart dependencies have been upgraded because of Sentry requirements.\nChanges:\n\n- The minimum required version of PostgreSQL is 14.5 (works with 15.x too)\n\nBumped dependencies:\n\n- postgresql \u003e 12.5.1 - latest version of chart with postgres 15\n\n## Upgrading from 17.x.x version of this Chart to 18.x.x\n\nIf Kafka is complaining about unknown or missing topic, please connect to `kafka-0` and run\n\n```shell\n/opt/bitnami/kafka/bin/kafka-topics.sh --create --topic ingest-replay-recordings --bootstrap-server localhost:9092\n```\n\n## Upgrading from 16.x.x version of this Chart to 17.x.x\n\nSentry version from 22.10.0 onwards should be using chart 17.x.x\n\n- post process forwarder events and transactions topics are split in Sentry 22.10.0\n\nYou can delete the deployment \"sentry-post-process-forward\" as it's no longer needed.\n\n`sentry-worker` may fail to start by [#774](https://github.com/sentry-kubernetes/charts/issues/774).\nIf you encountered this issue, please reset `counters-0`, `triggers-0` queues.\n\n## Upgrading from 15.x.x version of this Chart to 16.x.x\n\n`system.secret-key` is removed\n\nSee https://github.com/sentry-kubernetes/charts/tree/develop/sentry#sentry-secret-key\n\n## Upgrading from 14.x.x version of this Chart to 15.x.x\n\nChart dependencies have been upgraded because of bitnami charts removal.\nChanges:\n\n- `nginx.service.port: 80` \u003e `nginx.service.ports.http: 80`\n- `kafka.service.port` \u003e `kafka.service.ports.client`\n\nBumped dependencies:\n\n- redis \u003e 16.12.1 - latest version of chart\n- kafka \u003e 16.3.2 - chart aligned with zookeeper dependency, upgraded Kafka to 3.11\n- rabbit \u003e 8.32.2 - latest 3.9.\\* image version of chart\n- postgresql \u003e 10.16.2 - latest version of chart with postgres 11\n- nginx \u003e 12.0.4 - latest version of chart\n\n## Upgrading from 13.x.x version of this Chart to 14.0.0\n\nClickHouse was reconfigured with sharding and replication in mind. If you are using external ClickHouse, you don't need to do anything.\n\n**WARNING**: You will lose current event data\u003cbr\u003e\nOtherwise, you should delete the old ClickHouse volumes in order to upgrade to this version.\n\n## Upgrading from 12.x.x version of this Chart to 13.0.0\n\nThe service annotations have been moved from the `service` section to the respective service's service sub-section. So what was:\n\n```yaml\nservice:\n  annotations:\n    alb.ingress.kubernetes.io/healthcheck-path: /_health/\n    alb.ingress.kubernetes.io/healthcheck-port: traffic-port\n```\n\nwill now be set per service:\n\n```yaml\nsentry:\n  web:\n    service:\n      annotations:\n        alb.ingress.kubernetes.io/healthcheck-path: /_health/\n        alb.ingress.kubernetes.io/healthcheck-port: traffic-port\n\nrelay:\n  service:\n    annotations:\n      alb.ingress.kubernetes.io/healthcheck-path: /api/relay/healthcheck/ready/\n      alb.ingress.kubernetes.io/healthcheck-port: traffic-port\n```\n\n## Upgrading from 10.x.x version of this Chart to 11.0.0\n\nIf you were using ClickHouse Tabix externally, we disabled it by default.\n\n## Upgrading from 9.x.x version of this Chart to 10.0.0\n\nIf you were using ClickHouse ImagePullSecrets, [we unified](https://github.com/sentry-kubernetes/charts/commit/573ca29d03bf2c044004c1aa387f652a36ada23a) the way it's used.\n\n## Upgrading from 8.x.x version of this Chart to 9.0.0\n\nTo simplify first-time installations, the backup value on ClickHouse has been changed to false.\n\n`clickhouse.clickhouse.configmap.remote_servers.replica.backup`\n\n## Upgrading from 7.x.x version of this Chart to 8.0.0\n\n- the default value of `features.orgSubdomains` is now \"false\"\n\n## Upgrading from 6.x.x version of this Chart to 7.0.0\n\n- the default mode of relay is now \"proxy\". You can change it through the `values.yaml` file\n- we removed the `githubSso` variable for the OAuth GitHub configuration. It was using the old environment variable, that doesn't work with Sentry anymore. Just use the common `github.xxxx` configuration for both OAuth \u0026 the application integration.\n\n## Upgrading from 5.x.x version of this Chart to 6.0.0\n\n- The `sentry.configYml` value is now in a real YAML format\n- If you were previously using `relay.asHook`, the value is now `asHook`\n\n## Upgrading from 4.x.x version of this Chart to 5.0.0\n\nAs Relay is now part of this chart, you need to make sure you enable either Nginx or the Ingress. Please read the next paragraph for more information.\n\nIf you are using an ingress gateway (like Istio), you have to change your inbound path from `sentry-web` to `nginx`.\n\n## NGINX and/or Ingress\n\nBy default, NGINX is enabled to allow sending the incoming requests to [Sentry Relay](https://getsentry.github.io/relay/) or the Django backend depending on the path. When Sentry is meant to be exposed outside of the Kubernetes cluster, it is recommended to disable NGINX and let the Ingress do the same. It's recommended to go with the go-to Ingress Controller, [NGINX Ingress](https://kubernetes.github.io/ingress-nginx/), but others should work as well.\n\nNote: if you are using NGINX Ingress, please set this annotation on your ingress: `nginx.ingress.kubernetes.io/use-regex: \"true\"`.\nIf you are using `additionalHostNames`, the `nginx.ingress.kubernetes.io/upstream-vhost` annotation might also come in handy.\nIt sets the `Host` header to the value you provide to avoid CSRF issues.\n\n### Letsencrypt on NGINX Ingress Controller\n\n```yaml\nnginx:\n  ingress:\n    annotations:\n      cert-manager.io/cluster-issuer: \"letsencrypt-prod\"\n    enabled: true\n    hostname: fqdn\n    ingressClassName: \"nginx\"\n    tls: true\n```\n\n## ClickHouse warning\n\nSnuba only supports a UTC timezone for ClickHouse. Please keep the initial value!\n\n## Upgrading from 3.1.0 version of this Chart to 4.0.0\n\nFollowing Helm Chart best practices, the new version introduces some breaking changes. All configuration for external\nresources moved to separate config branches: `externalClickhouse`, `externalKafka`, `externalRedis`, `externalPostgresql`.\n\nHere is a mapping table of old values and new values:\n\n| Before                          | After                         |\n| ------------------------------- | ----------------------------- |\n| `postgresql.postgresqlHost`     | `externalPostgresql.host`     |\n| `postgresql.postgresqlPort`     | `externalPostgresql.port`     |\n| `postgresql.postgresqlUsername` | `externalPostgresql.username` |\n| `postgresql.postgresqlPassword` | `externalPostgresql.password` |\n| `postgresql.postgresqlDatabase` | `externalPostgresql.database` |\n| `postgresql.postgresSslMode`    | `externalPostgresql.sslMode`  |\n| `redis.host`                    | `externalRedis.host`          |\n| `redis.port`                    | `externalRedis.port`          |\n| `redis.password`                | `externalRedis.password`      |\n\n## Upgrading from deprecated 9.0 -\u003e 10.0 Chart\n\nAs this chart runs in Helm 3 and also tries its best to follow on from the original Sentry chart. There are some steps that need to be taken in order to correctly upgrade.\n\nFrom the previous upgrade, make sure to get the following from your previous installation:\n\n- Redis Password (If Redis auth was enabled)\n- PostgreSQL Password\n  Both should be in the `secrets` of your original 9.0 release. Make a note of both of these values.\n\n#### Upgrade Steps\n\nDue to an issue where transferring from Helm 2 to 3. StatefulSets that use the following: `heritage: {{ .Release.Service }}` in the metadata field will error out with a `Forbidden` error during the upgrade. The only workaround is to delete the existing StatefulSets (Don't worry, PVC will be retained):\n\n\u003e `kubectl delete --all sts -n \u003cSentry Namespace\u003e`\n\nOnce the StatefulSets are deleted. Next steps is to convert the Helm release from version 2 to 3 using the Helm 3 plugin:\n\n\u003e `helm3 2to3 convert \u003cSentry Release Name\u003e`\n\nFinally, it's just a case of upgrading and ensuring the correct params are used:\n\nIf Redis auth enabled:\n\n\u003e `helm upgrade -n \u003cSentry namespace\u003e \u003cSentry Release\u003e . --set redis.usePassword=true --set redis.password=\u003cRedis Password\u003e --set postgresql.postgresqlPassword=\u003cPostgresql Password\u003e`\n\nIf Redis auth is disabled:\n\n\u003e `helm upgrade -n \u003cSentry namespace\u003e \u003cSentry Release\u003e . --set postgresql.postgresqlPassword=\u003cPostgresql Password\u003e`\n\nPlease also follow the steps for Major version 3 to 4 migration\n\n## PostgreSQL\n\nBy default, PostgreSQL is installed as part of the chart. To use an external PostgreSQL server set `postgresql.enabled` to `false` and then set `postgresql.postgresHost` and `postgresql.postgresqlPassword`. The other options (`postgresql.postgresqlDatabase`, `postgresql.postgresqlUsername` and `postgresql.postgresqlPort`) may also want changing from their default values.\n\nTo avoid issues when upgrade this chart, provide `postgresql.postgresqlPassword` for subsequent upgrades. This is due to an issue in the PostgreSQL chart where password will be overwritten with randomly generated passwords otherwise. See https://github.com/helm/charts/tree/master/stable/postgresql#upgrade for more detail.\n\n## Persistence\n\nThis chart is capable of mounting the sentry-data PV in the Sentry worker and cron pods. This feature is disabled by default, but is needed for some advanced features such as private sourcemaps.\n\nYou may enable mounting of the sentry-data PV across worker and cron pods by changing filestore.filesystem.persistence.persistentWorkers to true. If you plan on deploying Sentry containers across multiple nodes, you may need to change your PVC's access mode to ReadWriteMany and check that your PV supports mounting across multiple nodes.\n\n## Roadmap\n\n- [x] Lint in Pull requests\n- [x] Public availability through Github Pages\n- [x] Automatic deployment through Github Actions\n- [ ] Symbolicator deployment\n- [x] Testing the chart in a production environment\n- [ ] Improving the README\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsentry-kubernetes%2Fcharts","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsentry-kubernetes%2Fcharts","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsentry-kubernetes%2Fcharts/lists"}