From 5a8f301209e3eb2dc25d3c78df85f70ce2d7a9e4 Mon Sep 17 00:00:00 2001 From: Google APIs Date: Sat, 15 Jun 2019 00:37:48 +0000 Subject: [PATCH] Autogenerated update (2019-06-15) Update: - cloudresourcemanager_v1 - file_v1 - monitoring_v3 - servicecontrol_v1 - servicemanagement_v1 --- .../google/apis/cloudresourcemanager_v1.rb | 2 +- .../apis/cloudresourcemanager_v1/classes.rb | 12 +- generated/google/apis/file_v1.rb | 2 +- generated/google/apis/file_v1/classes.rb | 91 ++-------- .../google/apis/file_v1/representations.rb | 1 + generated/google/apis/monitoring_v3.rb | 2 +- .../google/apis/monitoring_v3/classes.rb | 2 +- generated/google/apis/servicecontrol_v1.rb | 2 +- .../google/apis/servicecontrol_v1/classes.rb | 164 ++---------------- generated/google/apis/servicemanagement_v1.rb | 2 +- .../apis/servicemanagement_v1/classes.rb | 83 +-------- .../apis/servicemanagement_v1/service.rb | 10 +- 12 files changed, 62 insertions(+), 311 deletions(-) diff --git a/generated/google/apis/cloudresourcemanager_v1.rb b/generated/google/apis/cloudresourcemanager_v1.rb index 3902328de..cc44a3cdf 100644 --- a/generated/google/apis/cloudresourcemanager_v1.rb +++ b/generated/google/apis/cloudresourcemanager_v1.rb @@ -26,7 +26,7 @@ module Google # @see https://cloud.google.com/resource-manager module CloudresourcemanagerV1 VERSION = 'V1' - REVISION = '20190603' + REVISION = '20190610' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/cloudresourcemanager_v1/classes.rb b/generated/google/apis/cloudresourcemanager_v1/classes.rb index 998d6b438..3c0a475c0 100644 --- a/generated/google/apis/cloudresourcemanager_v1/classes.rb +++ b/generated/google/apis/cloudresourcemanager_v1/classes.rb @@ -1527,14 +1527,10 @@ module Google # the response. Filter rules are case-insensitive. # Organizations may be filtered by `owner.directoryCustomerId` or by # `domain`, where the domain is a G Suite domain, for example: - # clang-format off - # | Filter | Description | - # |-------------------------------------|----------------------------------| - # | owner.directorycustomerid:123456789 | Organizations with `owner. - # directory_customer_id` equal to `123456789`.| - # | domain:google.com | Organizations corresponding to the - # domain `google.com`.| - # clang-format on + # * Filter `owner.directorycustomerid:123456789` returns Organization + # resources with `owner.directory_customer_id` equal to `123456789`. + # * Filter `domain:google.com` returns Organization resources corresponding + # to the domain `google.com`. # This field is optional. # Corresponds to the JSON property `filter` # @return [String] diff --git a/generated/google/apis/file_v1.rb b/generated/google/apis/file_v1.rb index 2ab63acd0..c1e9c5519 100644 --- a/generated/google/apis/file_v1.rb +++ b/generated/google/apis/file_v1.rb @@ -25,7 +25,7 @@ module Google # @see https://cloud.google.com/filestore/ module FileV1 VERSION = 'V1' - REVISION = '20190605' + REVISION = '20190613' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/file_v1/classes.rb b/generated/google/apis/file_v1/classes.rb index e97adfa7a..c1d31af79 100644 --- a/generated/google/apis/file_v1/classes.rb +++ b/generated/google/apis/file_v1/classes.rb @@ -270,6 +270,14 @@ module Google class GoogleCloudSaasacceleratorManagementProvidersV1MaintenanceSchedule 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. # Corresponds to the JSON property `endTime` # @return [String] @@ -286,6 +294,7 @@ module Google # Update properties of this object def update!(**args) + @can_reschedule = args[:can_reschedule] if args.key?(:can_reschedule) @end_time = args[:end_time] if args.key?(:end_time) @start_time = args[:start_time] if args.key?(:start_time) end @@ -801,43 +810,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::FileV1::Status] attr_accessor :error @@ -944,43 +920,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/file_v1/representations.rb b/generated/google/apis/file_v1/representations.rb index bdd63c969..2135f6772 100644 --- a/generated/google/apis/file_v1/representations.rb +++ b/generated/google/apis/file_v1/representations.rb @@ -188,6 +188,7 @@ module Google class GoogleCloudSaasacceleratorManagementProvidersV1MaintenanceSchedule # @private class Representation < Google::Apis::Core::JsonRepresentation + property :can_reschedule, as: 'canReschedule' property :end_time, as: 'endTime' property :start_time, as: 'startTime' end diff --git a/generated/google/apis/monitoring_v3.rb b/generated/google/apis/monitoring_v3.rb index a041921f3..d15c45a57 100644 --- a/generated/google/apis/monitoring_v3.rb +++ b/generated/google/apis/monitoring_v3.rb @@ -30,7 +30,7 @@ module Google # @see https://cloud.google.com/monitoring/api/ module MonitoringV3 VERSION = 'V3' - REVISION = '20190604' + REVISION = '20190613' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/monitoring_v3/classes.rb b/generated/google/apis/monitoring_v3/classes.rb index 4cdcbe00e..f764309de 100644 --- a/generated/google/apis/monitoring_v3/classes.rb +++ b/generated/google/apis/monitoring_v3/classes.rb @@ -1972,7 +1972,7 @@ module Google # the use of the labels "instance_id" and "zone" to identify particular VM # instances.Different APIs can support different monitored resource types. APIs # 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 include Google::Apis::Core::Hashable diff --git a/generated/google/apis/servicecontrol_v1.rb b/generated/google/apis/servicecontrol_v1.rb index 65df8d623..02b0b10e5 100644 --- a/generated/google/apis/servicecontrol_v1.rb +++ b/generated/google/apis/servicecontrol_v1.rb @@ -26,7 +26,7 @@ module Google # @see https://cloud.google.com/service-control/ module ServicecontrolV1 VERSION = 'V1' - REVISION = '20190509' + REVISION = '20190607' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/servicecontrol_v1/classes.rb b/generated/google/apis/servicecontrol_v1/classes.rb index 9bdc8d466..934f154f5 100644 --- a/generated/google/apis/servicecontrol_v1/classes.rb +++ b/generated/google/apis/servicecontrol_v1/classes.rb @@ -224,43 +224,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `status` # @return [Google::Apis::ServicecontrolV1::Status] attr_accessor :status @@ -486,43 +453,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `status` # @return [Google::Apis::ServicecontrolV1::Status] attr_accessor :status @@ -1720,43 +1654,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `status` # @return [Google::Apis::ServicecontrolV1::Status] attr_accessor :status @@ -2216,43 +2117,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/servicemanagement_v1.rb b/generated/google/apis/servicemanagement_v1.rb index 9cbefe415..9313b6e29 100644 --- a/generated/google/apis/servicemanagement_v1.rb +++ b/generated/google/apis/servicemanagement_v1.rb @@ -27,7 +27,7 @@ module Google # @see https://cloud.google.com/service-management/ module ServicemanagementV1 VERSION = 'V1' - REVISION = '20190510' + REVISION = '20190610' # View and manage your data across Google Cloud Platform services AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform' diff --git a/generated/google/apis/servicemanagement_v1/classes.rb b/generated/google/apis/servicemanagement_v1/classes.rb index 0211803c9..38386f348 100644 --- a/generated/google/apis/servicemanagement_v1/classes.rb +++ b/generated/google/apis/servicemanagement_v1/classes.rb @@ -2627,6 +2627,7 @@ module Google # Different APIs can support different monitored resource types. APIs generally # provide a `list` method that returns the monitored resource descriptors used # by the API. + # Next ID: 10 class MonitoredResourceDescriptor include Google::Apis::Core::Hashable @@ -2836,43 +2837,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). # Corresponds to the JSON property `error` # @return [Google::Apis::ServicemanagementV1::Status] attr_accessor :error @@ -3941,43 +3909,10 @@ module Google # 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](https://github.com/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, 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. + # used by [gRPC](https://github.com/grpc). Each `Status` message contains + # three pieces of data: error code, error message, and error details. + # You can find out more about this error model and how to work with it in the + # [API Design Guide](https://cloud.google.com/apis/design/errors). class Status include Google::Apis::Core::Hashable diff --git a/generated/google/apis/servicemanagement_v1/service.rb b/generated/google/apis/servicemanagement_v1/service.rb index 80b13bf69..b0f0900b7 100644 --- a/generated/google/apis/servicemanagement_v1/service.rb +++ b/generated/google/apis/servicemanagement_v1/service.rb @@ -873,6 +873,13 @@ module Google # The name of the service. See the [overview](/service-management/overview) # for naming requirements. For example: `example.googleapis.com`. # @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 # Selector specifying which fields to include in a partial response. # @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::ClientError] The request is invalid and should not be retried without modification # @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.request_representation = Google::Apis::ServicemanagementV1::Rollout::Representation command.request_object = rollout_object command.response_representation = Google::Apis::ServicemanagementV1::Operation::Representation command.response_class = Google::Apis::ServicemanagementV1::Operation 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['quotaUser'] = quota_user unless quota_user.nil? execute_or_queue_command(command, &block)