chiu
/
google-api-ruby-client
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Autogenerated update (2019-06-15) 

Update:
- cloudresourcemanager_v1
- file_v1
- monitoring_v3
- servicecontrol_v1
- servicemanagement_v1
This commit is contained in:
Google APIs 2019-06-15 00:37:48 +00:00
parent 81cf904032
commit 5a8f301209
12 changed files with 62 additions and 311 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
generated/google/apis/cloudresourcemanager_v1.rb
View File

@ -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'

12
generated/google/apis/cloudresourcemanager_v1/classes.rb
View File

@ -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]

2
generated/google/apis/file_v1.rb
View File

@ -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'

91
generated/google/apis/file_v1/classes.rb
View File

@ -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

1
generated/google/apis/file_v1/representations.rb
View File

@ -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

2
generated/google/apis/monitoring_v3.rb
View File

@ -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'

2
generated/google/apis/monitoring_v3/classes.rb
View File

@ -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

2
generated/google/apis/servicecontrol_v1.rb
View File

@ -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'

164
generated/google/apis/servicecontrol_v1/classes.rb
View File

@ -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

2
generated/google/apis/servicemanagement_v1.rb
View File

@ -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'

83
generated/google/apis/servicemanagement_v1/classes.rb
View File

@ -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

10
generated/google/apis/servicemanagement_v1/service.rb
View File

@ -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)