-
Notifications
You must be signed in to change notification settings - Fork 3
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
feat: AIP-128 – Declarative-friendly interfaces #32
Open
lukesneeringer
wants to merge
2
commits into
main
Choose a base branch
from
aip-128
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,116 @@ | ||
# Declarative-friendly interfaces | ||
|
||
Many services need to interact with common DevOps tools, particularly those | ||
that create and manage network-addressible resources (such as virtual machines, | ||
load balancers, database instances, and so on). These tools revolve around the | ||
principle of "configuration as code": the user specifies the complete intended | ||
landscape, and tooling is responsible for making whatever changes are necessary | ||
to achieve the user's specification. | ||
|
||
These tools are **declarative**: rather than specifying specific _actions_ to | ||
take, they specify the desired _outcome_, with the actions being derived based | ||
on the differences between the current landscape and the intended one. | ||
|
||
Furthermore, there are numerous popular DevOps tools, with more being | ||
introduced each year. Integrating hundreds of resource types with multiple | ||
tools requires strong consistency, so that integration can be automated. | ||
|
||
## Guidance | ||
|
||
Services **should** clearly delineate between "control plane" operations and | ||
"data plane" operations, ideally through the use of distinct services with | ||
their own interface definition documents. | ||
|
||
- Control plane operations are responsible for managing the _lifecycle_ of | ||
resources. | ||
- Data plane operations are responsible for managing the _content_ of | ||
resources. | ||
|
||
The same resource **may** have both control plane operations and data plane | ||
operations associated with it. For example, a database API would have | ||
operations to create or delete database tables (control plane) as well as | ||
operations to write and read rows to that table (data plane). | ||
|
||
### Resources | ||
|
||
Resources that are declarative-friendly **must** use only strongly-consistent | ||
standard methods for managing resource lifecycle, which allows tools to support | ||
these resources generically, as well as conforming to other | ||
declarative-friendly guidance (see [further reading](#further-reading)). | ||
|
||
Declarative-friendly resources **should** designate that they follow the | ||
declarative-friendly style: | ||
|
||
{% tab proto %} | ||
|
||
{% sample 'declarative_friendly.proto', 'message Book' %} | ||
|
||
{% tab oas %} | ||
|
||
{% sample 'declarative_friendly.oas.yaml', 'schema' %} | ||
|
||
{% endtabs %} | ||
|
||
### Annotations | ||
|
||
Declarative-friendly resources **must** include a `annotations` field to allow | ||
clients to store small amounts of arbitrary data: | ||
|
||
```typescript | ||
// A representation of a single book. | ||
interface Book { | ||
// The name of the book. | ||
// Format: publishers/{publisher}/books/{book} | ||
name: string; | ||
|
||
// Other fields... | ||
|
||
// A dictionary of key-value pairs. | ||
// This has no effect on the service's behavior, but clients may use it | ||
// to persistently store small amounts of information related to this | ||
// resource. | ||
annotations: { [key: string]: string }; | ||
} | ||
``` | ||
|
||
The `annotations` field **must** use the [Kubernetes limits][] to maintain wire | ||
compatibility, and **should** require dot-namespaced annotation keys to prevent | ||
tools from trampling over one another. | ||
|
||
**Note:** Annotations are distinct from various forms of labels. Labels can be | ||
used by server-side policies, such as IAM conditions. Annotations exist to | ||
allow client tools to store their own state information without requiring a | ||
database. | ||
|
||
<!-- prettier-ignore --> | ||
[kubernetes limits]: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/#syntax-and-character-set | ||
|
||
### Reconciliation | ||
|
||
If a resource takes time (more than a few seconds) for updates to be realized, | ||
the resource **should** include a `bool reconciling` field to disclose that | ||
changes are in flight. This field **must** be output only. | ||
|
||
A resource **must** set the `reconciling` field to `true` if the current state | ||
of the resource does not match the user's intended state, and the system is | ||
working to reconcile them. This is regardless of whether the root cause of | ||
going into reconciliation was user or system action. | ||
|
||
**Note:** Services responding to a `GET` request **must** return the resource's | ||
current state (not the intended state). | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. subject to preconditions (e.g. etags) presumably |
||
|
||
## Further reading | ||
|
||
A significant amount of guidance is more strict for declarative-friendly | ||
interfaces, due to the focus on automation on top of these resources. This list | ||
is a comprehensive reference to declarative-friendly guidance in other AIPs: | ||
|
||
- Resources **must** use user-settable resource IDs: see AIP-133. | ||
- Resources **must** permit "create or update": see AIP-134. | ||
- Resources **should** permit "delete if existing": see AIP-135. | ||
- Resources **should not** employ custom methods: see AIP-136. | ||
- Resources **must** use the `Update` method for repeated fields: see AIP-144. | ||
- Resources **must** include certain standard fields: see AIP-148. | ||
- Resources **must** have an `etag` field: see AIP-154. | ||
- Resources **must** provide change validation: see AIP-163. | ||
- Resources **should** support soft delete: see AIP-164. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
--- | ||
id: 128 | ||
state: approved | ||
created: 2020-10-06 | ||
placement: | ||
category: resource-design | ||
order: 65 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
--- | ||
openapi: 3.0.3 | ||
info: | ||
title: Library | ||
version: 1.0.0 | ||
paths: {} | ||
components: | ||
schemas: | ||
Book: | ||
description: A representation of a single book. | ||
properties: | ||
name: | ||
type: string | ||
description: | | ||
The name of the book. | ||
Format: publishers/{publisher}/books/{book} | ||
|
||
annotations: | ||
description: | | ||
A dictionary of key-value pairs. | ||
This has no effect on the service's behavior, but clients may use it | ||
to persistently store small amounts of information related to this | ||
resource. | ||
additionalProperties: | ||
type: string | ||
|
||
# Additional fields... |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,32 @@ | ||
// Copyright 2020 Google LLC | ||
// | ||
// Licensed under the Apache License, Version 2.0 (the "License"); | ||
// you may not use this file except in compliance with the License. | ||
// You may obtain a copy of the License at | ||
// | ||
// https://www.apache.org/licenses/LICENSE-2.0 | ||
// | ||
// Unless required by applicable law or agreed to in writing, software | ||
// distributed under the License is distributed on an "AS IS" BASIS, | ||
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
syntax = "proto3"; | ||
|
||
import "google/api/resource.proto"; | ||
|
||
// A representation of a book. | ||
message Book { | ||
option (google.api.resource) = { | ||
type: "library.googleapis.com/Book" | ||
pattern: "publishers/{publisher}/books/{book}" | ||
style: DECLARATIVE_FRIENDLY | ||
}; | ||
|
||
// The name of the book. | ||
// Format: publishers/{publisher}/books/{book} | ||
string name = 1; | ||
|
||
// Other fields... | ||
} |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I missing something here.... are you suggesting these types of declarations will precipitate standard operations (e.g. POST/PUT/GET/DELETE/PATCH?) Or are you suggesting something more like JMX with an introspection capability? Or something totally different and I'm just not getting it?