Common types

• 1:
• 2:
• 3:

1 -

Proto package goten.types

goten.types Shared Messages

Here is the list of goten.types shared messages:

• LabelSelector message
• LabelSelectorRequirement message
• Lifecycle message
• Memo message
• Meta message
• MultiRegionPolicy message
• MultiRegionPolicy.CriteriaForDisabledSync message
• OwnerReference message
• ServicesInfo message
• SyncingMeta message

LabelSelector Message

A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all objects. A null label selector matches no objects.

LabelSelectorRequirement Message

A label selector requirement is a selector that contains values, a key, and an operator that relates the key and values.

Lifecycle Message

Memo Message

Memo

Meta Message

Metadata

MultiRegionPolicy Message

MultiRegionPolicy is an object defining relation between service in multi-region environment and resource holding this policy (as one of its fields). Policy ought to be used for high-level resources like “Project” or “Organization” which form top elements in scopes. Policy then, attached to such a high level resource defines syncing policies for all kid resources and limits their geographical belonging (kid resources can belong only to the region allowed by a policy). Note: While policy governs all resources under policy holder resource, policy holder resource itself is not subject to this policy. This rule allows information about policy spread properly across regions and enables routing.

MultiRegionPolicy.CriteriaForDisabledSync Message

CriteriaForDisabledSync is a rule preventing data synchronization. By default, everything within Policy scope is synced (unless schema tells otherwise). However, within single scope to which this policy is attached, it is possible to blacklist synchronization for specific criteria. Examples: { resource_type_name: “devices.service.com/Device”, sourceRegion: “france” } -> will make Devices in France private { resource_type_name: “devices.service.com/Device”, destRegion: “hongkong” } -> will prevent from syncing Devices INTO HongKong region { resource_type_name: “devices.service.com/Device”, sourceRegion: “germany”, destRegion: “hongkong” } -> Will block syncing of Devices from Germany to HongKong. { resource_type_name: “devices.service.com/Pod” } -> will make Pods in all regions private { region: “japan” } -> will make all resources in Japan private

OwnerReference Message

OwnerReference contains enough information to let you identify an owning object. An owning object must be in the same namespace as the dependent, or be cluster-scoped, so there is no namespace field.

ServicesInfo Message

ServicesInfo contains information about resource ownership/access in terms of service. As goten is a multi-service framework, it is possible for a resource in one service to be “owned” by another one. Owning service may also need to regulate access to other services via allowed services field. It should be note that Goten does not provide authorization layer of its own, ServicesInfo is provided for convenience, but actual restriction should be implemented by actual services.

SyncingMeta Message

SyncingMeta is a helper object associated with each resource that is either regional or is governed by Policy object. This object is used for internal purposes like Sync controller which ensures data synchronization of all resources across multiple regions.

goten.types Shared Enumerations

Here is the list of goten.types shared enumerations:

• Lifecycle.State enumeration
• View enumeration
• WatchType enumeration

Lifecycle.State Enumeration

current resource state

View Enumeration

View defines list of fields of the resource that will be obtained in servers response.

WatchType Enumeration

WatchType defines how client wants to subscribe for real-time updates when making Watch request.

2 -

Proto package ntt.api

ntt.api Shared Messages

Here is the list of ntt.api shared messages:

• Account message
• DeviceFileCheck message
• DeviceFileCheck.FileTypeOneOf message
• DeviceIdentity message
• DeviceIdentity.AttestationParams message
• ExecCheck message
• GRPCCheck message
• HTTPGetCheck message
• HTTPGetCheck.HTTPHeader message
• HTTPGetCheck.HTTPUrl message
• HealthCheckSpec message
• ICMPCheck message
• IdentityChallenge message
• IdentityChallengeResponse message
• IdentityChallengeResponse.Quote message
• PCR message
• ServiceAccount message
• TCPCheck message
• User message

Account Message

DeviceFileCheck Message

DeviceFileCheck.FileTypeOneOf Message

DeviceIdentity Message

DeviceIdentity.AttestationParams Message

ExecCheck Message

ExecCheck describes a “run in container” action.

GRPCCheck Message

HTTPGetCheck Message

HTTPGetCheck describes health check based on HTTP Get requests.

HTTPGetCheck.HTTPHeader Message

HTTPHeader describes a custom header to be used in HTTP HealthChecks

HTTPGetCheck.HTTPUrl Message

HealthCheckSpec Message

HealthCheck describes a health check to be performed in the context of a device or a container. Only the exec check can be truly executed inside a container. All the other checks are run on the host device. When run for device health check, host/IP address is mandatory for connectivity checks. For container health checks, host/IP is optional and would default to IP address of the container. It is important to note that a health check for https://endpoint.com/api defined for a container would be run from the host device and not from withthin the container

ICMPCheck Message

IdentityChallenge Message

One of IDevID or LDevID is mandatory for IdentityChallenge to succeed DevID keys can be either signing or decrypt With GlobalSign + Compulab, we use decrypt keys, but other vendors like Dell may be using signing keys instead, so api should allow both

IdentityChallengeResponse Message

IdentityChallengeResponse.Quote Message

PCR Message

ServiceAccount Message

TCPCheck Message

TCPCheck performs a TCP connect check. Only TCP handshake is performed. No data is sent

User Message

ntt.api Shared Enumerations

Here is the list of ntt.api shared enumerations:

• DeviceIdentity.ChallengeFormat enumeration
• DigestAlg enumeration
• LaunchStage enumeration
• TpmVersion enumeration

DeviceIdentity.ChallengeFormat Enumeration

DigestAlg Enumeration

LaunchStage Enumeration

The launch stage as defined by Google Cloud Platform Launch Stages.

TpmVersion Enumeration

3 -

Proto package ntt.rpc

ntt.rpc Shared Messages

Here is the list of ntt.rpc shared messages:

• Status message

Status Message

The Status type defines a logical error model that is suitable for different programming environments, including REST APIs and RPC APIs. It is used by gRPC. The error model is designed to be:

• Simple to use and understand for most users
• Flexible enough to meet unexpected needs

Overview

The Status message contains three pieces of data: error code, error message, and error details. The error code should be an enum value of [google.rpc.Code][google.rpc.Code], but it may accept additional error codes if needed. The error message should be a developer-facing English message that helps developers understand and resolve the error. If a localized user-facing error message is needed, put the localized message in the error details or localize it in the client. The optional error details may contain arbitrary information about the error. There is a predefined set of error detail types in the package google.rpc that can be used for common error conditions.

Language mapping

The Status message is the logical representation of the error model, but it is not necessarily the actual wire format. When the Status message is exposed in different client libraries and different wire protocols, it can be mapped differently. For example, it will likely be mapped to some exceptions in Java, but more likely mapped to some error codes in C.

Other uses

The error model and the Status message can be used in a variety of environments, either with or without APIs, to provide a consistent developer experience across different environments.

Example uses of this error model include:

• Partial errors. If a service needs to return partial errors to the client, it may embed the Status in the normal response to indicate the partial errors.

• Workflow errors. A typical workflow has multiple steps. Each step may have a Status message for error reporting.

• Batch operations. If a client uses batch request and batch response, the Status message should be used directly inside batch response, one for each error sub-response.

• Asynchronous operations. If an API call embeds asynchronous operation results in its response, the status of those operations should be represented directly using the Status message.

• Logging. If some API errors are stored in logs, the message Status could be used directly after any stripping needed for security/privacy reasons.