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

feat: first API draft and generation #315

Merged
merged 21 commits into from
Nov 20, 2020
Merged
Show file tree
Hide file tree
Changes from 7 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 28 additions & 3 deletions Makefile
Original file line number Diff line number Diff line change
Expand Up @@ -64,6 +64,31 @@ docker: deps
rm keto
packr clean

.PHONY: gen-protobuf
gen-protobuf:
protoc --go_out=. --go_opt=paths=source_relative --go-grpc_out=. --go-grpc_opt=paths=source_relative relationtuple/*.proto
#
# Generate APIs and client stubs from the definitions
#
.PHONY: buf-gen
buf-gen:
buf generate \
--config buf/api/buf.yaml \
--template buf/api/buf.gen.yaml \
&& \
echo "TODO: generate gapic client at ./client" \
&& \
echo "All code was generated successfully!"

#
# Lint API definitions
#
.PHONY: buf-lint
buf-lint:
buf check lint \
--config buf/api/buf.yaml \
&& \
echo "All lint checks passed successfully!"

#
# Generate after linting succeeded
#
.PHONY: buf
buf: buf-lint buf-gen
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please always add the newlines in the end of files 😉

218 changes: 218 additions & 0 deletions api/google/api/client.pb.go

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

99 changes: 99 additions & 0 deletions api/google/api/client.proto
Original file line number Diff line number Diff line change
@@ -0,0 +1,99 @@
// Copyright 2020 Google LLC
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of this file? I could not find any documentation in GAPIC that would explain the need for this. Also, the Copyright Google is probably a copy/paste error?
If this is required for gapic, I'd prefer adding it together with gapic client generation in one PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'll remove and put it back for gapic PR then.

//
// 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
//
// http://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";

package google.api;

import "google/protobuf/descriptor.proto";

option go_package = "google.golang.org/genproto/googleapis/api/annotations;annotations";
option java_multiple_files = true;
option java_outer_classname = "ClientProto";
option java_package = "com.google.api";
option objc_class_prefix = "GAPI";

extend google.protobuf.MethodOptions {
// A definition of a client library method signature.
//
// In client libraries, each proto RPC corresponds to one or more methods
// which the end user is able to call, and calls the underlying RPC.
// Normally, this method receives a single argument (a struct or instance
// corresponding to the RPC request object). Defining this field will
// add one or more overloads providing flattened or simpler method signatures
// in some languages.
//
// The fields on the method signature are provided as a comma-separated
// string.
//
// For example, the proto RPC and annotation:
//
// rpc CreateSubscription(CreateSubscriptionRequest)
// returns (Subscription) {
// option (google.api.method_signature) = "name,topic";
// }
//
// Would add the following Java overload (in addition to the method accepting
// the request object):
//
// public final Subscription createSubscription(String name, String topic)
//
// The following backwards-compatibility guidelines apply:
//
// * Adding this annotation to an unannotated method is backwards
// compatible.
// * Adding this annotation to a method which already has existing
// method signature annotations is backwards compatible if and only if
// the new method signature annotation is last in the sequence.
// * Modifying or removing an existing method signature annotation is
// a breaking change.
// * Re-ordering existing method signature annotations is a breaking
// change.
repeated string method_signature = 1051;
}

extend google.protobuf.ServiceOptions {
// The hostname for this service.
// This should be specified with no prefix or protocol.
//
// Example:
//
// service Foo {
// option (google.api.default_host) = "foo.googleapi.com";
// ...
// }
string default_host = 1049;

// OAuth scopes needed for the client.
//
// Example:
//
// service Foo {
// option (google.api.oauth_scopes) = \
// "https://www.googleapis.com/auth/cloud-platform";
// ...
// }
//
// If there is more than one scope, use a comma-separated string:
//
// Example:
//
// service Foo {
// option (google.api.oauth_scopes) = \
// "https://www.googleapis.com/auth/cloud-platform,"
// "https://www.googleapis.com/auth/monitoring";
// ...
// }
string oauth_scopes = 1050;
}
37 changes: 37 additions & 0 deletions api/keto/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
# Notes

> ORY Keto is still a `sandbox` project.
This makes the included api version `v1` subject
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we maybe make this v0 instead? The first alpha and beta releases of keto will also be v0.x.x

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I wasn't sure whether we release next gen keto with a stable v1 directly, but this is not how it goes, since users will be using the service very early I guess.

In protobuf we can use v1alpha1, the first alpha of v1, then v1beta1 and then eventually v1 for stable definitions.

If we go that path we will always need to write version mappings of the messages versions on server side (map v1alpha1 -> v1beta1 -> v1), deprecate old versions and eventually remove the support at some point.

Sure, we can do this!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it be possible to go with v0 that can have breaking changes and then move on to v1 once we release Keto v1.x.x? Otherwise, v1alpha and v1beta are good 👍

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would remove support for old versions immediately and guarantee compatibility only at a point where we are confident that not much will change.

Copy link
Contributor Author

@robinbraemer robinbraemer Nov 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It depends on how long we have the alpha/beta versions public and how many clients are using an older version before we should remove them. Generally the goal is to reach v1 as soon as possible.

This is how versioning is usually seen for ProtoBuf APIs:

  • v1alpha - Highly subject to breaking changes, very early stage
  • v1beta - Pretty reliable, may change. Should have a long evaluation time before going v1
  • v1 - Stable, API (RPCs, fields, messages) can only be added without breaking existing functionality
  • ...perhaps a new v2... cycle when needing to break v1, still v1 has loooong time support

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, that's what I think as well. So we just start with v1alpha and move on when we think it is appropriate.

to have breaking changes until the `v1.0.0` release of Keto!

This directory contains the ProtoBuf & gRPC definitions
for the Access Control APIs.

This includes:
- ACL
- Soon:
- RBAC
- ABAC

**ACL is the flexible and scalable "base system"
where all other access control schemes built upon.**

## Directory layout

```shell script
keto
└── acl / rbac / abac
   ├── node
   │   └── v1 - Intercommunication API (cluster internal)
   ├── admin
   │   └── v1 - Admin API definitions
   └── v1 - "Base" API definitions
```

- `admin` - API for critical administrative tasks
- namespace config management
- retrieval of cluster system statistics / analysis
- etc.
- `base/v1` - Base APIs / models
- read/write/watch/... services
- `node` - Intercommunication of cluster nodes
2 changes: 2 additions & 0 deletions api/keto/abac/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
# coming soon
Built upon [ACL](../acl).
Loading