google-api-client 0.30.1 → 0.30.2

data/generated/google/apis/logging_v2/service.rb

@@ -22,7 +22,10 @@ module Google
     module LoggingV2
       # Stackdriver Logging API
       #
-      # Writes log entries and manages your Logging configuration.
+      # Writes log entries and manages your Stackdriver Logging configuration. The
+      #  table entries below are presented in alphabetical order, not in order of
+      #  common use. For explanations of the concepts found in the table entries, read
+      #  the Stackdriver Logging documentation.
       #
       # @example
       #    require 'google/apis/logging_v2'

data/generated/google/apis/ml_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/ml/
     module MlV1
       VERSION = 'V1'
-      REVISION = '20190524'
+      REVISION = '20190530'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

data/generated/google/apis/ml_v1/classes.rb

@@ -392,9 +392,9 @@ module Google
         # @return [String]
         attr_accessor :goal
       
-        # Optional. The Tensorflow summary tag name to use for optimizing trials. For
-        # current versions of Tensorflow, this tag name should exactly match what is
-        # shown in Tensorboard, including all scopes.  For versions of Tensorflow
+        # Optional. The TensorFlow summary tag name to use for optimizing trials. For
+        # current versions of TensorFlow, this tag name should exactly match what is
+        # shown in TensorBoard, including all scopes.  For versions of TensorFlow
         # prior to 0.12, this should be only the tag passed to tf.Summary.
         # By default, "training/hptuning/metric" will be used.
         # Corresponds to the JSON property `hyperparameterMetricTag`
@@ -1336,6 +1336,11 @@ module Google
         # @return [String]
         attr_accessor :master_type
       
+        # Optional. The maximum job running time. The default is 7 days.
+        # Corresponds to the JSON property `maxRunningTime`
+        # @return [String]
+        attr_accessor :max_running_time
+      
         # Required. The Google Cloud Storage location of the packages with
         # the training program and any additional dependencies.
         # The maximum number of package URIs is 100.
@@ -1449,6 +1454,7 @@ module Google
           @job_dir = args[:job_dir] if args.key?(:job_dir)
           @master_config = args[:master_config] if args.key?(:master_config)
           @master_type = args[:master_type] if args.key?(:master_type)
+          @max_running_time = args[:max_running_time] if args.key?(:max_running_time)
           @package_uris = args[:package_uris] if args.key?(:package_uris)
           @parameter_server_config = args[:parameter_server_config] if args.key?(:parameter_server_config)
           @parameter_server_count = args[:parameter_server_count] if args.key?(:parameter_server_count)
@@ -1484,6 +1490,15 @@ module Google
         # @return [Float]
         attr_accessor :consumed_ml_units
       
+        # The TensorFlow summary tag name used for optimizing hyperparameter tuning
+        # trials. See
+        # [`HyperparameterSpec.hyperparameterMetricTag`](#HyperparameterSpec.FIELDS.
+        # hyperparameter_metric_tag)
+        # for more information. Only set for hyperparameter tuning jobs.
+        # Corresponds to the JSON property `hyperparameterMetricTag`
+        # @return [String]
+        attr_accessor :hyperparameter_metric_tag
+      
         # Whether this job is a built-in Algorithm job.
         # Corresponds to the JSON property `isBuiltInAlgorithmJob`
         # @return [Boolean]
@@ -1511,6 +1526,7 @@ module Google
           @built_in_algorithm_output = args[:built_in_algorithm_output] if args.key?(:built_in_algorithm_output)
           @completed_trial_count = args[:completed_trial_count] if args.key?(:completed_trial_count)
           @consumed_ml_units = args[:consumed_ml_units] if args.key?(:consumed_ml_units)
+          @hyperparameter_metric_tag = args[:hyperparameter_metric_tag] if args.key?(:hyperparameter_metric_tag)
           @is_built_in_algorithm_job = args[:is_built_in_algorithm_job] if args.key?(:is_built_in_algorithm_job)
           @is_hyperparameter_tuning_job = args[:is_hyperparameter_tuning_job] if args.key?(:is_hyperparameter_tuning_job)
           @trials = args[:trials] if args.key?(:trials)
@@ -2148,43 +2164,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::MlV1::GoogleRpcStatus]
         attr_accessor :error
@@ -2251,43 +2234,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 GoogleRpcStatus
         include Google::Apis::Core::Hashable
       

data/generated/google/apis/ml_v1/representations.rb

@@ -551,6 +551,7 @@ module Google
           property :master_config, as: 'masterConfig', class: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig, decorator: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig::Representation
       
           property :master_type, as: 'masterType'
+          property :max_running_time, as: 'maxRunningTime'
           collection :package_uris, as: 'packageUris'
           property :parameter_server_config, as: 'parameterServerConfig', class: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig, decorator: Google::Apis::MlV1::GoogleCloudMlV1ReplicaConfig::Representation
       
@@ -575,6 +576,7 @@ module Google
       
           property :completed_trial_count, :numeric_string => true, as: 'completedTrialCount'
           property :consumed_ml_units, as: 'consumedMLUnits'
+          property :hyperparameter_metric_tag, as: 'hyperparameterMetricTag'
           property :is_built_in_algorithm_job, as: 'isBuiltInAlgorithmJob'
           property :is_hyperparameter_tuning_job, as: 'isHyperparameterTuningJob'
           collection :trials, as: 'trials', class: Google::Apis::MlV1::GoogleCloudMlV1HyperparameterOutput, decorator: Google::Apis::MlV1::GoogleCloudMlV1HyperparameterOutput::Representation

data/generated/google/apis/monitoring_v3.rb

@@ -22,12 +22,15 @@ module Google
     #
     # Manages your Stackdriver Monitoring data and configurations. Most projects
     # must be associated with a Stackdriver account, with a few exceptions as noted
-    # on the individual method pages.
+    # on the individual method pages. The table entries below are presented in
+    # alphabetical order, not in order of common use. For explanations of the
+    # concepts found in the table entries, read the Stackdriver Monitoring
+    # documentation.
     #
     # @see https://cloud.google.com/monitoring/api/
     module MonitoringV3
       VERSION = 'V3'
-      REVISION = '20190526'
+      REVISION = '20190604'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

data/generated/google/apis/monitoring_v3/classes.rb

@@ -344,38 +344,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 needsOverviewThe 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 mappingThe 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 usesThe 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.
+        # (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::MonitoringV3::Status]
         attr_accessor :error
@@ -442,38 +414,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 needsOverviewThe 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 mappingThe 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 usesThe 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.
+        # (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::MonitoringV3::Status]
         attr_accessor :error
@@ -2028,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.
+      # descriptors used by the API.Next ID: 10
       class MonitoredResourceDescriptor
         include Google::Apis::Core::Hashable
       
@@ -2482,38 +2426,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 needsOverviewThe 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 mappingThe 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 usesThe 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.
+      # (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
       

data/generated/google/apis/monitoring_v3/service.rb

@@ -24,7 +24,10 @@ module Google
       #
       # Manages your Stackdriver Monitoring data and configurations. Most projects
       #  must be associated with a Stackdriver account, with a few exceptions as noted
-      #  on the individual method pages.
+      #  on the individual method pages. The table entries below are presented in
+      #  alphabetical order, not in order of common use. For explanations of the
+      #  concepts found in the table entries, read the Stackdriver Monitoring
+      #  documentation.
       #
       # @example
       #    require 'google/apis/monitoring_v3'

data/generated/google/apis/redis_v1.rb

@@ -25,7 +25,7 @@ module Google
     # @see https://cloud.google.com/memorystore/docs/redis/
     module RedisV1
       VERSION = 'V1'
-      REVISION = '20190531'
+      REVISION = '20190607'
 
       # View and manage your data across Google Cloud Platform services
       AUTH_CLOUD_PLATFORM = 'https://www.googleapis.com/auth/cloud-platform'

data/generated/google/apis/redis_v1/classes.rb

@@ -80,7 +80,7 @@ module Google
         end
       end
       
-      # The GCS location for the output content
+      # The Cloud Storage location for the output content
       class GcsDestination
         include Google::Apis::Core::Hashable
       
@@ -100,7 +100,7 @@ module Google
         end
       end
       
-      # The GCS location for the input content
+      # The Cloud Storage location for the input content
       class GcsSource
         include Google::Apis::Core::Hashable
       
@@ -237,7 +237,7 @@ module Google
       class InputConfig
         include Google::Apis::Core::Hashable
       
-        # The GCS location for the input content
+        # The Cloud Storage location for the input content
         # Corresponds to the JSON property `gcsSource`
         # @return [Google::Apis::RedisV1::GcsSource]
         attr_accessor :gcs_source
@@ -563,43 +563,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::RedisV1::Status]
         attr_accessor :error
@@ -657,7 +624,7 @@ module Google
       class OutputConfig
         include Google::Apis::Core::Hashable
       
-        # The GCS location for the output content
+        # The Cloud Storage location for the output content
         # Corresponds to the JSON property `gcsDestination`
         # @return [Google::Apis::RedisV1::GcsDestination]
         attr_accessor :gcs_destination
@@ -674,43 +641,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