diff options
Diffstat (limited to 'doc')
13 files changed, 356 insertions, 15 deletions
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md index e3abed66d77..47e52e6005f 100644 --- a/doc/api/graphql/reference/index.md +++ b/doc/api/graphql/reference/index.md @@ -18993,6 +18993,7 @@ Represents a product analytics dashboard. | ---- | ---- | ----------- | | <a id="productanalyticsdashboarddescription"></a>`description` | [`String`](#string) | Description of the dashboard. | | <a id="productanalyticsdashboardpanels"></a>`panels` | [`ProductAnalyticsDashboardPanelConnection!`](#productanalyticsdashboardpanelconnection) | Panels shown on the dashboard. (see [Connections](#connections)) | +| <a id="productanalyticsdashboardslug"></a>`slug` | [`String!`](#string) | Slug of the dashboard. | | <a id="productanalyticsdashboardtitle"></a>`title` | [`String!`](#string) | Title of the dashboard. | ### `ProductAnalyticsDashboardPanel` diff --git a/doc/architecture/blueprints/database/clickhouse/clickhouse_dbwriter.png b/doc/architecture/blueprints/clickhouse_ingestion_pipeline/clickhouse_dbwriter.png Binary files differindex fc65830d3ee..fc65830d3ee 100644 --- a/doc/architecture/blueprints/database/clickhouse/clickhouse_dbwriter.png +++ b/doc/architecture/blueprints/clickhouse_ingestion_pipeline/clickhouse_dbwriter.png diff --git a/doc/architecture/blueprints/database/clickhouse/ingestion_pipeline.md b/doc/architecture/blueprints/clickhouse_ingestion_pipeline/index.md index 0fafc1bf524..94714e7b245 100644 --- a/doc/architecture/blueprints/database/clickhouse/ingestion_pipeline.md +++ b/doc/architecture/blueprints/clickhouse_ingestion_pipeline/index.md @@ -147,7 +147,7 @@ Having addressed the details of the two aformentioned problem-domains, we can mo The single, biggest challenge around introducing ClickHouse and related systems would be the ability to make it avaiable to our users running GitLab in self-managed environments. The intended goals of this proposal are intentionally kept within those constraints. It is also prudent to establish that what we're *proposing* here be applicable to applications consuming ClickHouse from inside self-managed environments. -There are ongoing efforts to streamline distribution and deployment of ClickHouse instances for managed environment within the larger scope of [ClickHouse Usage at GitLab](../../clickhouse_usage/index.md). A few other issues tackling parts of the aforementioned problem are: +There are ongoing efforts to streamline distribution and deployment of ClickHouse instances for managed environment within the larger scope of [ClickHouse Usage at GitLab](../clickhouse_usage/index.md). A few other issues tackling parts of the aforementioned problem are: - [Research and understand component costs and maintenance requirements of running a ClickHouse instance with GitLab](https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/14384) - [ClickHouse maintenance and cost research](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/116669) diff --git a/doc/architecture/blueprints/database/clickhouse/read_abstraction_layer.md b/doc/architecture/blueprints/clickhouse_read_abstraction_layer/index.md index 82470867a30..8290641b7a4 100644 --- a/doc/architecture/blueprints/database/clickhouse/read_abstraction_layer.md +++ b/doc/architecture/blueprints/clickhouse_read_abstraction_layer/index.md @@ -10,6 +10,17 @@ participating-stages: [] # Consider an abstraction layer to interact with ClickHouse or alternatives +## Table of Contents + +- [Summary](#summary) +- [Motivation](#motivation) +- [Goals](#goals) +- [Non-goals](#non-goals) +- [Possible solutions](#possible-solutions) + - [Recommended approach](#recommended-approach) + - [Overview of open source tools](#overview-of-open-source-tools) +- [Open Questions](#open-questions) + ## Summary Provide a solution standardizing read access to ClickHouse or its alternatives for GitLab installations that will not opt-in to install ClickHouse. After analyzing different [open-source tools](#overview-of-open-source-tools) and weighing them against an option to [build a solution internally](#recommended-approach). The current recommended approach proposes to use dedicated database-level drivers to connect to each data source. Additionally, it proposes the usage of [repository pattern](https://martinfowler.com/eaaCatalog/repository.html) to confine optionally database availability complexity to a single application layer. @@ -24,7 +35,7 @@ offering a unified interface for interactions with underlying data stores, to a ## Goals -- Limit the impact of optionally available data stores on the overall GitLab application codebase to [single abstraction layer](../../../../development/reusing_abstractions.md#abstractions) +- Limit the impact of optionally available data stores on the overall GitLab application codebase to [single abstraction layer](../../../development/reusing_abstractions.md#abstractions) - Support all data store specific features - Support communication for satellite services of the main GitLab application @@ -72,7 +83,7 @@ Following ClickHouse documentation there are the following drivers for Ruby and To keep the codebase well organized and limit coupling to any specific database engine it is important to encapsulate interactions, including querying data to a single application layer, that would present its interface to layers above in -similar vain to [ActiveRecord interface propagation through abstraction layers](../../../../development/reusing_abstractions.md) +similar vain to [ActiveRecord interface propagation through abstraction layers](../../../development/reusing_abstractions.md) Keeping underlying database engines encapsulated makes the recommended solution a good two-way door decision that keeps the opportunity to introduce other tools later on, while giving groups time to explore and understand their use cases. @@ -81,7 +92,7 @@ At the lowest abstraction layer, it can be expected that there will be a family following MVC pattern implemented by Rails should be classified as _Models_. Models-level abstraction builds well into existing patterns and guidelines but unfortunately does not solve the challenge of the optional availability of the ClickHouse database engine for self-managed instances. It is required to design a dedicated entity that will house responsibility of selecting best database to serve business logic request. -From the already mentioned existing abstraction [guidelines](../../../../development/reusing_abstractions.md) `Finders` seems to be the closest to the given requirements, due to the fact that `Finders` encapsulate database specific interaction behind their own public API, hiding database vendors detail from all layers above them. +From the already mentioned existing abstraction [guidelines](../../../development/reusing_abstractions.md) `Finders` seems to be the closest to the given requirements, due to the fact that `Finders` encapsulate database specific interaction behind their own public API, hiding database vendors detail from all layers above them. However, they are closely coupled to `ActiveRecord` ORM framework, and are bound by existing GitLab convention to return `ActiveRecord::Relation` objects, that might be used to compose even more complex queries. That coupling makes `Finders` unfit to deal with the optional availability of ClickHouse because returned data might come from two different databases, and might not be compatible with each other. @@ -138,7 +149,7 @@ In this section authors provide an overview of existing 3rd party open-source so 1. It focuses on the fact whether the proposed abstraction layer can support both ClickHouse and PostgreSQL (must have) 1. Additional consideration might be if more than the two must-have storages are supported -1. The solution must support the [minimum required versions](../../../../install/requirements.md#postgresql-requirements) for PostgreSQL +1. The solution must support the [minimum required versions](../../../install/requirements.md#postgresql-requirements) for PostgreSQL ##### 3. Protocol compatibility diff --git a/doc/architecture/blueprints/gitlab_ci_events/index.md b/doc/architecture/blueprints/gitlab_ci_events/index.md new file mode 100644 index 00000000000..7ce8fea9410 --- /dev/null +++ b/doc/architecture/blueprints/gitlab_ci_events/index.md @@ -0,0 +1,63 @@ +--- +status: proposed +creation-date: "2023-03-15" +authors: [ "@furkanayhan" ] +coach: "@grzesiek" +approvers: [ "@jreporter", "@cheryl.li" ] +owning-stage: "~devops::verify" +participating-stages: [ "~devops::package", "~devops::deploy" ] +--- + +# GitLab CI Events + +## Summary + +In order to unlock innovation and build more value, GitLab is expected to be +the center of automation related to DevSecOps processes. We want to transform +GitLab into a programming environment, that will make it possible for engineers +to model various workflows on top of CI/CD pipelines. Today, users must create +custom automation around webhooks or scheduled pipelines to build required +workflows. + +In order to make this automation easier for our users, we want to build a +powerful CI/CD eventing system, that will make it possible to run pipelines +whenever something happens inside or outside of GitLab. + +A typical use-case is to run a CI/CD job whenever someone creates an issue, +posts a comment, changes a merge request status from "draft" to "ready for +review" or adds a new member to a group. + +To build that new technology, we should: + +1. Emit many hierarchical events from within GitLab in a more advanced way than we do it today. +1. Make it affordable to run this automation, that will react to GitLab events, at scale. +1. Provide a set of conventions and libraries to make writing the automation easier. + +## Goals + +While ["GitLab Events Platform"](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/113700) +aims to build new abstractions around emitting events in GitLab, "GitLab CI +Events" blueprint is about making it possible to: + +1. Define a way in which users will configure when an event emitted will result in a CI pipeline being run. +1. Describe technology required to match subscriptions with events at GitLab.com scale and beyond. +1. Describe technology we could use to reduce the cost of running automation jobs significantly. + +## Proposals + +For now, we have technical 4 proposals; + +1. [Proposal 1: Using the `.gitlab-ci.yml` file](proposal-1-using-the-gitlab-ci-file.md) + Based on; + - [GitLab CI Workflows PoC](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91244) + - [PoC NPM CI events](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111693) +1. [Proposal 2: Using the `rules` keyword](proposal-2-using-the-rules-keyword.md) + Highly inefficient way. +1. [Proposal 3: Using the `.gitlab/ci/events` folder](proposal-3-using-the-gitlab-ci-events-folder.md) + Involves file reading for every event. +1. [Proposal 4: Creating events via CI files](proposal-4-creating-events-via-ci-files.md) + Combination of some proposals. + +Each of them has its pros and cons. There could be many more proposals and we +would like to discuss them all. We can combine the best part of those proposals +and create a new one. diff --git a/doc/architecture/blueprints/gitlab_ci_events/proposal-1-using-the-gitlab-ci-file.md b/doc/architecture/blueprints/gitlab_ci_events/proposal-1-using-the-gitlab-ci-file.md new file mode 100644 index 00000000000..7dfc3873ada --- /dev/null +++ b/doc/architecture/blueprints/gitlab_ci_events/proposal-1-using-the-gitlab-ci-file.md @@ -0,0 +1,60 @@ +--- +owning-stage: "~devops::verify" +description: 'GitLab CI Events Proposal 1: Using the .gitlab-ci.yml file' +--- + +# GitLab CI Events Proposal 1: Using the `.gitlab-ci.yml` file + +Currently, we have two proof-of-concept (POC) implementations: + +- [GitLab CI Workflows PoC](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/91244) +- [PoC NPM CI events](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111693) + +They both have similar ideas; + +1. Find a new CI Config syntax to define the pipeline events. + + Example 1: + + ```yaml + workflow: + events: + - events/package/published + + # or + + workflow: + on: + - events/package/published + ``` + + Example 2: + + ```yaml + spec: + on: + - events/package/published + - events/package/removed + # on: + # package: [published, removed] + --- + do_something: + script: echo "Hello World" + ``` + +1. Upsert an event to the database when creating a pipeline. +1. Create [EventStore subscriptions](../../../development/event_store.md) to handle the events. + +## Problems & Questions + +1. The CI config of a project can be anything; + - `.gitlab-ci.yml` by default + - another file in the project + - another file in another project + - completely a remote/external file + + How do we handle these cases? +1. Since we have these problems above, should we keep the events in its own file? (`.gitlab-ci-events.yml`) +1. Do we only accept the changes in the main branch? +1. We try to create event subscriptions every time a pipeline is created. +1. Can we move the existing workflows into the new CI events, for example, `merge_request_event`? diff --git a/doc/architecture/blueprints/gitlab_ci_events/proposal-2-using-the-rules-keyword.md b/doc/architecture/blueprints/gitlab_ci_events/proposal-2-using-the-rules-keyword.md new file mode 100644 index 00000000000..6f69a0f11f0 --- /dev/null +++ b/doc/architecture/blueprints/gitlab_ci_events/proposal-2-using-the-rules-keyword.md @@ -0,0 +1,38 @@ +--- +owning-stage: "~devops::verify" +description: 'GitLab CI Events Proposal 2: Using the rules keyword' +--- + +# GitLab CI Events Proposal 2: Using the `rules` keyword + +Can we do it with our current [`rules`](../../../ci/yaml/index.md#rules) system? + +```yaml +workflow: + rules: + - events: ["package/*"] + +test_package_published: + script: echo testing published package + rules: + - events: ["package/published"] + +test_package_removed: + script: echo testing removed package + rules: + - events: ["package/removed"] +``` + +1. We don't upsert anything to the database. +1. We'll have a single worker which subcribes to events +like `store.subscribe ::Ci::CreatePipelineFromEventWorker, to: ::Issues::CreatedEvent`. +1. The worker just runs `Ci::CreatePipelineService` with the correct parameters, the rest +will be handled by the `rules` system. Of course, we'll need modifications to the `rules` system to support `events`. + +## Problems & Questions + +1. For every defined event run, we need to enqueue a new `Ci::CreatePipelineFromEventWorker` job. +1. The worker will need to run `Ci::CreatePipelineService` for every event run. +This may be costly because we go through every cycle of `Ci::CreatePipelineService`. +1. This would be highly inefficient. +1. Can we move the existing workflows into the new CI events, for example, `merge_request_event`? diff --git a/doc/architecture/blueprints/gitlab_ci_events/proposal-3-using-the-gitlab-ci-events-folder.md b/doc/architecture/blueprints/gitlab_ci_events/proposal-3-using-the-gitlab-ci-events-folder.md new file mode 100644 index 00000000000..ad76b7f8dd4 --- /dev/null +++ b/doc/architecture/blueprints/gitlab_ci_events/proposal-3-using-the-gitlab-ci-events-folder.md @@ -0,0 +1,64 @@ +--- +owning-stage: "~devops::verify" +description: 'GitLab CI Events Proposal 3: Using the .gitlab/ci/events folder' +--- + +# GitLab CI Events Proposal 3: Using the `.gitlab/ci/events` folder + +We can also approach this problem by creating separate files for events. + +Let's say we'll have the `.gitlab/ci/events` folder (or `.gitlab/workflows/ci`). + +We can define events in the following format: + +```yaml +# .gitlab/ci/events/package-published.yml + +spec: + events: + - name: package/published + +--- + +include: + - local: .gitlab-ci.yml + with: + event: $[[ gitlab.event.name ]] +``` + +And in the `.gitlab-ci.yml` file, we can use the input; + +```yaml +# .gitlab-ci.yml + +spec: + inputs: + event: + default: push + +--- + +job1: + script: echo "Hello World" + +job2: + script: echo "Hello World" + +job-for-package-published: + script: echo "Hello World" + rules: + - if: $[[ inputs.event ]] == "package/published" +``` + +When an event happens; + +1. We'll enqueue a new job for the event. +1. The job will search for the event file in the `.gitlab/ci/events` folder. +1. The job will run `Ci::CreatePipelineService` for the event file. + +## Problems & Questions + +1. For every defined event run, we need to enqueue a new job. +1. Every event-job will need to search for files. +1. This would be only for the project-scope events. +1. This can be inefficient because of searching for files for the project for every event. diff --git a/doc/architecture/blueprints/gitlab_ci_events/proposal-4-creating-events-via-ci-files.md b/doc/architecture/blueprints/gitlab_ci_events/proposal-4-creating-events-via-ci-files.md new file mode 100644 index 00000000000..5f10ba1fbb2 --- /dev/null +++ b/doc/architecture/blueprints/gitlab_ci_events/proposal-4-creating-events-via-ci-files.md @@ -0,0 +1,73 @@ +--- +owning-stage: "~devops::verify" +description: 'GitLab CI Events Proposal 4: Creating events via CI files' +--- + +# GitLab CI Events Proposal 4: Creating events via CI files + +Each project can have its own event configuration file. Let's call it `.gitlab-ci-event.yml` for now. +In this file, we can define events in the following format: + +```yaml +events: + - package/published + - issue/created +``` + +When this file is changed in the project repository, it is parsed and the events are created, updated, or deleted. +This is highly similar to [Proposal 1](proposal-1-using-the-gitlab-ci-file.md) except that we don't need to +track pipeline creations every time. + +1. Upsert events to the database when `.gitlab-ci-event.yml` is updated. +1. Create [EventStore subscriptions](../../../development/event_store.md) to handle the events. + +## Filtering jobs + +We can filter jobs by using the `rules` keyword. For example: + +```yaml +test_package_published: + script: echo testing published package + rules: + - events: ["package/published"] + +test_package_removed: + script: echo testing removed package + rules: + - events: ["package/removed"] +``` + +Otherwise, we can make it work either a CI variable; + +```yaml +test_package_published: + script: echo testing published package + rules: + - if: $CI_EVENT == "package/published" + +test_package_removed: + script: echo testing removed package + rules: + - if: $CI_EVENT == "package/removed" +``` + +or an input like in the [Proposal 3](proposal-3-using-the-gitlab-ci-events-folder.md); + +```yaml +spec: + inputs: + event: + default: push + +--- + +test_package_published: + script: echo testing published package + rules: + - if: $[[ inputs.event ]] == "package/published" + +test_package_removed: + script: echo testing removed package + rules: + - if: $[[ inputs.event ]] == "package/removed" +``` diff --git a/doc/development/ai_features.md b/doc/development/ai_features.md index 8e2746276a1..d53b2027412 100644 --- a/doc/development/ai_features.md +++ b/doc/development/ai_features.md @@ -55,6 +55,8 @@ All AI features are experimental. ```ruby Feature.enable(:ai_related_settings) Feature.enable(:openai_experimentation) + Feature.enable(:tofa_experimentation_main_flag) + Feature.enable(:anthropic_experimentation) ``` 1. Simulate the GDK to [simulate SaaS](ee_features.md#simulate-a-saas-instance) and ensure the group you want to test has an Ultimate license @@ -87,31 +89,49 @@ To populate the embedding database for GitLab chat: 1. Open a rails console 1. Run [this script](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/10588#note_1373586079) to populate the embedding database -### Internal-Only GCP account access +### Configure GCP Vertex access In order to obtain a GCP service key for local development, please follow the steps below: - Create a sandbox GCP environment by visiting [this page](https://about.gitlab.com/handbook/infrastructure-standards/#individual-environment) and following the instructions - In the GCP console, go to `IAM & Admin` > `Service Accounts` and click on the "Create new service account" button - Name the service account something specific to what you're using it for. Select Create and Continue. Under `Grant this service account access to project`, select the role `Vertex AI User`. Select `Continue` then `Done` -- Select your new service account and `Manage keys` > `Add Key` > `Create new key`. This will download the **private** JSON credentials for your service account. -- In the rails console, you will use this by `Gitlab::CurrentSettings.update(tofa_credentials: File.read('/YOUR_FILE.json'))` +- Select your new service account and `Manage keys` > `Add Key` > `Create new key`. This will download the **private** JSON credentials for your service account. Your full settings should then be: + +```ruby +Gitlab::CurrentSettings.update(tofa_credentials: File.read('/YOUR_FILE.json')) + +# Note: These credential examples will not work locally for all models +Gitlab::CurrentSettings.update(tofa_host: "<root-domain>") # Example: us-central1-aiplatform.googleapis.com +Gitlab::CurrentSettings.update(tofa_url: "<full-api-endpoint>") # Example: https://ROOT-DOMAIN/v1/projects/MY-COOL-PROJECT/locations/us-central1/publishers/google/models/MY-SPECIAL-MODEL:predict +``` + +Internal team members can [use this snippet](https://gitlab.com/gitlab-com/gl-infra/production/-/snippets/2541742) for help configuring these endpoints. + +### Configure OpenAI access + +```ruby +Gitlab::CurrentSettings.update(openai_api_key: "<open-ai-key>") +``` + +### Configure Anthropic access + +```ruby +Feature.enable(:anthropic_experimentation) +Gitlab::CurrentSettings.update!(anthropic_api_key: <insert API key>) +``` ## Experimental REST API -Use the [experimental REST API endpoints](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/api/ai/experimentation/open_ai.rb) to quickly experiment and prototype AI features. +Use the [experimental REST API endpoints](https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/lib/api/ai/experimentation) to quickly experiment and prototype AI features. The endpoints are: - `https://gitlab.example.com/api/v4/ai/experimentation/openai/completions` - `https://gitlab.example.com/api/v4/ai/experimentation/openai/embeddings` - `https://gitlab.example.com/api/v4/ai/experimentation/openai/chat/completions` - -To use these endpoints locally, set the OpenAI API key in the application settings: - -```ruby -Gitlab::CurrentSettings.update(openai_api_key: "<open-ai-key>") -``` +- `https://gitlab.example.com/api/v4/ai/experimentation/anthropic/complete` +- `https://gitlab.example.com/api/v4/ai/experimentation/tofa/chat` These endpoints are only for prototyping, not for rolling features out to customers. The experimental endpoint is only available to GitLab team members on production. Use the diff --git a/doc/update/removals.md b/doc/update/removals.md index 475e4cc9ca2..3e1fb620fcd 100644 --- a/doc/update/removals.md +++ b/doc/update/removals.md @@ -217,6 +217,15 @@ In GitLab 16.0 and later, the GraphQL query for runners will no longer return th - `PAUSED` has been replaced with the field, `paused: true`. - `ACTIVE` has been replaced with the field, `paused: false`. +### Jira DVCS connector for Jira Cloud and Jira 8.13 and earlier + +WARNING: +This is a [breaking change](https://docs.gitlab.com/ee/development/deprecation_guidelines/). +Review the details carefully before upgrading. + +The [Jira DVCS connector](https://docs.gitlab.com/ee/integration/jira/dvcs/) for Jira Cloud was deprecated in GitLab 15.1 and has been removed in 16.0. Use the [GitLab for Jira Cloud app](https://docs.gitlab.com/ee/integration/jira/connect-app.html) instead. The Jira DVCS connector was also deprecated for Jira 8.13 and earlier. You can only use the Jira DVCS connector with Jira Data Center or Jira Server in Jira 8.14 and later. Upgrade your Jira instance to Jira 8.14 or later, and reconfigure the Jira integration in your GitLab instance. +If you cannot upgrade your Jira instance in time and are on GitLab self-managed version, we offer a workaround until GitLab 16.6. This breaking change is deployed in GitLab 16.0 behind a feature flag named `jira_dvcs_end_of_life_amnesty`. The flag is disabled by default, but you can ask an administrator to enable the flag at any time. For questions related to this announcement, see the [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/408185). + ### License-Check and the Policies tab on the License Compliance page WARNING: diff --git a/doc/user/admin_area/settings/rate_limit_on_projects_api.md b/doc/user/admin_area/settings/rate_limit_on_projects_api.md index e82e682b0bb..29e72daf579 100644 --- a/doc/user/admin_area/settings/rate_limit_on_projects_api.md +++ b/doc/user/admin_area/settings/rate_limit_on_projects_api.md @@ -10,6 +10,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w > - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/112283) in GitLab 15.10 with a [flag](../../../administration/feature_flags.md) named `rate_limit_for_unauthenticated_projects_api_access`. Disabled by default. > - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/391922) on May 08, 2023. > - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/119603) in GitLab 16.0 by default. +> - [Generally available](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/120445) in GitLab 16.0. Feature flag `rate_limit_for_unauthenticated_projects_api_access` removed. You can configure the rate limit per IP address for unauthenticated requests to the [list all projects API](../../../api/projects.md#list-all-projects). diff --git a/doc/user/project/integrations/webhook_events.md b/doc/user/project/integrations/webhook_events.md index 5585b0bf3e1..fda778aa167 100644 --- a/doc/user/project/integrations/webhook_events.md +++ b/doc/user/project/integrations/webhook_events.md @@ -271,6 +271,7 @@ Payload example: "human_time_estimate": null, "human_time_change": null, "weight": null, + "health_status": "at_risk", "iid": 23, "url": "http://example.com/diaspora/issues/23", "state": "opened", |
