Autogenerated update (2019-06-15)
Update: - cloudresourcemanager_v1 - file_v1 - monitoring_v3 - servicecontrol_v1 - servicemanagement_v1
This commit is contained in:
parent
81cf904032
commit
5a8f301209
|
@ -26,7 +26,7 @@ module Google
|
||||||
# @see https://cloud.google.com/resource-manager
|
# @see https://cloud.google.com/resource-manager
|
||||||
module CloudresourcemanagerV1
|
module CloudresourcemanagerV1
|
||||||
VERSION = 'V1'
|
VERSION = 'V1'
|
||||||
REVISION = '20190603'
|
REVISION = '20190610'
|
||||||
|
|
||||||
# View and manage your data across Google Cloud Platform services
|
# View and manage your data across Google Cloud Platform services
|
||||||
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
||||||
|
|
|
@ -1527,14 +1527,10 @@ module Google
|
||||||
# the response. Filter rules are case-insensitive.
|
# the response. Filter rules are case-insensitive.
|
||||||
# Organizations may be filtered by `owner.directoryCustomerId` or by
|
# Organizations may be filtered by `owner.directoryCustomerId` or by
|
||||||
# `domain`, where the domain is a G Suite domain, for example:
|
# `domain`, where the domain is a G Suite domain, for example:
|
||||||
# clang-format off
|
# * Filter `owner.directorycustomerid:123456789` returns Organization
|
||||||
# | Filter | Description |
|
# resources with `owner.directory_customer_id` equal to `123456789`.
|
||||||
# |-------------------------------------|----------------------------------|
|
# * Filter `domain:google.com` returns Organization resources corresponding
|
||||||
# | owner.directorycustomerid:123456789 | Organizations with `owner.
|
# to the domain `google.com`.
|
||||||
# directory_customer_id` equal to `123456789`.|
|
|
||||||
# | domain:google.com | Organizations corresponding to the
|
|
||||||
# domain `google.com`.|
|
|
||||||
# clang-format on
|
|
||||||
# This field is optional.
|
# This field is optional.
|
||||||
# Corresponds to the JSON property `filter`
|
# Corresponds to the JSON property `filter`
|
||||||
# @return [String]
|
# @return [String]
|
||||||
|
|
|
@ -25,7 +25,7 @@ module Google
|
||||||
# @see https://cloud.google.com/filestore/
|
# @see https://cloud.google.com/filestore/
|
||||||
module FileV1
|
module FileV1
|
||||||
VERSION = 'V1'
|
VERSION = 'V1'
|
||||||
REVISION = '20190605'
|
REVISION = '20190613'
|
||||||
|
|
||||||
# View and manage your data across Google Cloud Platform services
|
# View and manage your data across Google Cloud Platform services
|
||||||
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
||||||
|
|
|
@ -270,6 +270,14 @@ module Google
|
||||||
class GoogleCloudSaasacceleratorManagementProvidersV1MaintenanceSchedule
|
class GoogleCloudSaasacceleratorManagementProvidersV1MaintenanceSchedule
|
||||||
include Google::Apis::Core::Hashable
|
include Google::Apis::Core::Hashable
|
||||||
|
|
||||||
|
# Can this scheduled update be rescheduled?
|
||||||
|
# By default, it's true and API needs to do explicitly check whether it's
|
||||||
|
# set, if it's set as false explicitly, it's false
|
||||||
|
# Corresponds to the JSON property `canReschedule`
|
||||||
|
# @return [Boolean]
|
||||||
|
attr_accessor :can_reschedule
|
||||||
|
alias_method :can_reschedule?, :can_reschedule
|
||||||
|
|
||||||
# The scheduled end time for the maintenance.
|
# The scheduled end time for the maintenance.
|
||||||
# Corresponds to the JSON property `endTime`
|
# Corresponds to the JSON property `endTime`
|
||||||
# @return [String]
|
# @return [String]
|
||||||
|
@ -286,6 +294,7 @@ module Google
|
||||||
|
|
||||||
# Update properties of this object
|
# Update properties of this object
|
||||||
def update!(**args)
|
def update!(**args)
|
||||||
|
@can_reschedule = args[:can_reschedule] if args.key?(:can_reschedule)
|
||||||
@end_time = args[:end_time] if args.key?(:end_time)
|
@end_time = args[:end_time] if args.key?(:end_time)
|
||||||
@start_time = args[:start_time] if args.key?(:start_time)
|
@start_time = args[:start_time] if args.key?(:start_time)
|
||||||
end
|
end
|
||||||
|
@ -801,43 +810,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
# Corresponds to the JSON property `error`
|
# Corresponds to the JSON property `error`
|
||||||
# @return [Google::Apis::FileV1::Status]
|
# @return [Google::Apis::FileV1::Status]
|
||||||
attr_accessor :error
|
attr_accessor :error
|
||||||
|
@ -944,43 +920,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
class Status
|
class Status
|
||||||
include Google::Apis::Core::Hashable
|
include Google::Apis::Core::Hashable
|
||||||
|
|
||||||
|
|
|
@ -188,6 +188,7 @@ module Google
|
||||||
class GoogleCloudSaasacceleratorManagementProvidersV1MaintenanceSchedule
|
class GoogleCloudSaasacceleratorManagementProvidersV1MaintenanceSchedule
|
||||||
# @private
|
# @private
|
||||||
class Representation < Google::Apis::Core::JsonRepresentation
|
class Representation < Google::Apis::Core::JsonRepresentation
|
||||||
|
property :can_reschedule, as: 'canReschedule'
|
||||||
property :end_time, as: 'endTime'
|
property :end_time, as: 'endTime'
|
||||||
property :start_time, as: 'startTime'
|
property :start_time, as: 'startTime'
|
||||||
end
|
end
|
||||||
|
|
|
@ -30,7 +30,7 @@ module Google
|
||||||
# @see https://cloud.google.com/monitoring/api/
|
# @see https://cloud.google.com/monitoring/api/
|
||||||
module MonitoringV3
|
module MonitoringV3
|
||||||
VERSION = 'V3'
|
VERSION = 'V3'
|
||||||
REVISION = '20190604'
|
REVISION = '20190613'
|
||||||
|
|
||||||
# View and manage your data across Google Cloud Platform services
|
# View and manage your data across Google Cloud Platform services
|
||||||
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
||||||
|
|
|
@ -1972,7 +1972,7 @@ module Google
|
||||||
# the use of the labels "instance_id" and "zone" to identify particular VM
|
# the use of the labels "instance_id" and "zone" to identify particular VM
|
||||||
# instances.Different APIs can support different monitored resource types. APIs
|
# instances.Different APIs can support different monitored resource types. APIs
|
||||||
# generally provide a list method that returns the monitored resource
|
# generally provide a list method that returns the monitored resource
|
||||||
# descriptors used by the API.Next ID: 10
|
# descriptors used by the API.
|
||||||
class MonitoredResourceDescriptor
|
class MonitoredResourceDescriptor
|
||||||
include Google::Apis::Core::Hashable
|
include Google::Apis::Core::Hashable
|
||||||
|
|
||||||
|
|
|
@ -26,7 +26,7 @@ module Google
|
||||||
# @see https://cloud.google.com/service-control/
|
# @see https://cloud.google.com/service-control/
|
||||||
module ServicecontrolV1
|
module ServicecontrolV1
|
||||||
VERSION = 'V1'
|
VERSION = 'V1'
|
||||||
REVISION = '20190509'
|
REVISION = '20190607'
|
||||||
|
|
||||||
# View and manage your data across Google Cloud Platform services
|
# View and manage your data across Google Cloud Platform services
|
||||||
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
||||||
|
|
|
@ -224,43 +224,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
# Corresponds to the JSON property `status`
|
# Corresponds to the JSON property `status`
|
||||||
# @return [Google::Apis::ServicecontrolV1::Status]
|
# @return [Google::Apis::ServicecontrolV1::Status]
|
||||||
attr_accessor :status
|
attr_accessor :status
|
||||||
|
@ -486,43 +453,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
# Corresponds to the JSON property `status`
|
# Corresponds to the JSON property `status`
|
||||||
# @return [Google::Apis::ServicecontrolV1::Status]
|
# @return [Google::Apis::ServicecontrolV1::Status]
|
||||||
attr_accessor :status
|
attr_accessor :status
|
||||||
|
@ -1720,43 +1654,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
# Corresponds to the JSON property `status`
|
# Corresponds to the JSON property `status`
|
||||||
# @return [Google::Apis::ServicecontrolV1::Status]
|
# @return [Google::Apis::ServicecontrolV1::Status]
|
||||||
attr_accessor :status
|
attr_accessor :status
|
||||||
|
@ -2216,43 +2117,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
class Status
|
class Status
|
||||||
include Google::Apis::Core::Hashable
|
include Google::Apis::Core::Hashable
|
||||||
|
|
||||||
|
|
|
@ -27,7 +27,7 @@ module Google
|
||||||
# @see https://cloud.google.com/service-management/
|
# @see https://cloud.google.com/service-management/
|
||||||
module ServicemanagementV1
|
module ServicemanagementV1
|
||||||
VERSION = 'V1'
|
VERSION = 'V1'
|
||||||
REVISION = '20190510'
|
REVISION = '20190610'
|
||||||
|
|
||||||
# View and manage your data across Google Cloud Platform services
|
# View and manage your data across Google Cloud Platform services
|
||||||
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'
|
||||||
|
|
|
@ -2627,6 +2627,7 @@ module Google
|
||||||
# Different APIs can support different monitored resource types. APIs generally
|
# Different APIs can support different monitored resource types. APIs generally
|
||||||
# provide a `list` method that returns the monitored resource descriptors used
|
# provide a `list` method that returns the monitored resource descriptors used
|
||||||
# by the API.
|
# by the API.
|
||||||
|
# Next ID: 10
|
||||||
class MonitoredResourceDescriptor
|
class MonitoredResourceDescriptor
|
||||||
include Google::Apis::Core::Hashable
|
include Google::Apis::Core::Hashable
|
||||||
|
|
||||||
|
@ -2836,43 +2837,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
# Corresponds to the JSON property `error`
|
# Corresponds to the JSON property `error`
|
||||||
# @return [Google::Apis::ServicemanagementV1::Status]
|
# @return [Google::Apis::ServicemanagementV1::Status]
|
||||||
attr_accessor :error
|
attr_accessor :error
|
||||||
|
@ -3941,43 +3909,10 @@ module Google
|
||||||
|
|
||||||
# The `Status` type defines a logical error model that is suitable for
|
# The `Status` type defines a logical error model that is suitable for
|
||||||
# different programming environments, including REST APIs and RPC APIs. It is
|
# different programming environments, including REST APIs and RPC APIs. It is
|
||||||
# used by [gRPC](https://github.com/grpc). The error model is designed to be:
|
# used by [gRPC](https://github.com/grpc). Each `Status` message contains
|
||||||
# - Simple to use and understand for most users
|
# three pieces of data: error code, error message, and error details.
|
||||||
# - Flexible enough to meet unexpected needs
|
# You can find out more about this error model and how to work with it in the
|
||||||
# # Overview
|
# [API Design Guide](https://cloud.google.com/apis/design/errors).
|
||||||
# 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, 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.
|
|
||||||
class Status
|
class Status
|
||||||
include Google::Apis::Core::Hashable
|
include Google::Apis::Core::Hashable
|
||||||
|
|
||||||
|
|
|
@ -873,6 +873,13 @@ module Google
|
||||||
# The name of the service. See the [overview](/service-management/overview)
|
# The name of the service. See the [overview](/service-management/overview)
|
||||||
# for naming requirements. For example: `example.googleapis.com`.
|
# for naming requirements. For example: `example.googleapis.com`.
|
||||||
# @param [Google::Apis::ServicemanagementV1::Rollout] rollout_object
|
# @param [Google::Apis::ServicemanagementV1::Rollout] rollout_object
|
||||||
|
# @param [String] base_rollout_id
|
||||||
|
# Unimplemented. Do not use this feature until this comment is removed.
|
||||||
|
# The rollout id that rollout to be created based on.
|
||||||
|
# Rollout should be constructed based on current successful rollout, this
|
||||||
|
# field indicates the current successful rollout id that new rollout based on
|
||||||
|
# to construct, if current successful rollout changed when server receives
|
||||||
|
# the request, request will be rejected for safety.
|
||||||
# @param [String] fields
|
# @param [String] fields
|
||||||
# Selector specifying which fields to include in a partial response.
|
# Selector specifying which fields to include in a partial response.
|
||||||
# @param [String] quota_user
|
# @param [String] quota_user
|
||||||
|
@ -890,13 +897,14 @@ module Google
|
||||||
# @raise [Google::Apis::ServerError] An error occurred on the server and the request can be retried
|
# @raise [Google::Apis::ServerError] An error occurred on the server and the request can be retried
|
||||||
# @raise [Google::Apis::ClientError] The request is invalid and should not be retried without modification
|
# @raise [Google::Apis::ClientError] The request is invalid and should not be retried without modification
|
||||||
# @raise [Google::Apis::AuthorizationError] Authorization is required
|
# @raise [Google::Apis::AuthorizationError] Authorization is required
|
||||||
def create_service_rollout(service_name, rollout_object = nil, fields: nil, quota_user: nil, options: nil, &block)
|
def create_service_rollout(service_name, rollout_object = nil, base_rollout_id: nil, fields: nil, quota_user: nil, options: nil, &block)
|
||||||
command = make_simple_command(:post, 'v1/services/{serviceName}/rollouts', options)
|
command = make_simple_command(:post, 'v1/services/{serviceName}/rollouts', options)
|
||||||
command.request_representation = Google::Apis::ServicemanagementV1::Rollout::Representation
|
command.request_representation = Google::Apis::ServicemanagementV1::Rollout::Representation
|
||||||
command.request_object = rollout_object
|
command.request_object = rollout_object
|
||||||
command.response_representation = Google::Apis::ServicemanagementV1::Operation::Representation
|
command.response_representation = Google::Apis::ServicemanagementV1::Operation::Representation
|
||||||
command.response_class = Google::Apis::ServicemanagementV1::Operation
|
command.response_class = Google::Apis::ServicemanagementV1::Operation
|
||||||
command.params['serviceName'] = service_name unless service_name.nil?
|
command.params['serviceName'] = service_name unless service_name.nil?
|
||||||
|
command.query['baseRolloutId'] = base_rollout_id unless base_rollout_id.nil?
|
||||||
command.query['fields'] = fields unless fields.nil?
|
command.query['fields'] = fields unless fields.nil?
|
||||||
command.query['quotaUser'] = quota_user unless quota_user.nil?
|
command.query['quotaUser'] = quota_user unless quota_user.nil?
|
||||||
execute_or_queue_command(command, &block)
|
execute_or_queue_command(command, &block)
|
||||||
|
|
Loading…
Reference in New Issue