You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/dyn/servicemanagement_v1.services.rollouts.html
+3-3Lines changed: 3 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -106,7 +106,7 @@ <h3>Method Details</h3>
106
106
107
107
{ # A rollout resource that defines how service configuration versions are pushed to control plane systems. Typically, you create a new version of the service config, and then create a Rollout to push the service config.
108
108
"createTime": "A String", # Creation time of the rollout. Readonly.
109
-
"createdBy": "A String", # This field is deprecated and will be deleted. Please remove usage of this field.
109
+
"createdBy": "A String", # The user who created the Rollout. Readonly.
110
110
"deleteServiceStrategy": { # Strategy used to delete a service. This strategy is a placeholder only used by the system generated rollout to delete a service. # The strategy associated with a rollout to delete a `ManagedService`. Readonly.
111
111
},
112
112
"rolloutId": "A String", # Optional. Unique identifier of this Rollout. Must be no longer than 63 characters and only lower case letters, digits, '.', '_' and '-' are allowed. If not specified by client, the server will generate one. The generated id will have the form of , where "date" is the create date in ISO 8601 format. "revision number" is a monotonically increasing positive number that is reset every day for each service. An example of the generated rollout_id is '2016-02-16r1'
@@ -165,7 +165,7 @@ <h3>Method Details</h3>
165
165
166
166
{ # A rollout resource that defines how service configuration versions are pushed to control plane systems. Typically, you create a new version of the service config, and then create a Rollout to push the service config.
167
167
"createTime": "A String", # Creation time of the rollout. Readonly.
168
-
"createdBy": "A String", # This field is deprecated and will be deleted. Please remove usage of this field.
168
+
"createdBy": "A String", # The user who created the Rollout. Readonly.
169
169
"deleteServiceStrategy": { # Strategy used to delete a service. This strategy is a placeholder only used by the system generated rollout to delete a service. # The strategy associated with a rollout to delete a `ManagedService`. Readonly.
170
170
},
171
171
"rolloutId": "A String", # Optional. Unique identifier of this Rollout. Must be no longer than 63 characters and only lower case letters, digits, '.', '_' and '-' are allowed. If not specified by client, the server will generate one. The generated id will have the form of , where "date" is the create date in ISO 8601 format. "revision number" is a monotonically increasing positive number that is reset every day for each service. An example of the generated rollout_id is '2016-02-16r1'
@@ -201,7 +201,7 @@ <h3>Method Details</h3>
201
201
"rollouts": [ # The list of rollout resources.
202
202
{ # A rollout resource that defines how service configuration versions are pushed to control plane systems. Typically, you create a new version of the service config, and then create a Rollout to push the service config.
203
203
"createTime": "A String", # Creation time of the rollout. Readonly.
204
-
"createdBy": "A String", # This field is deprecated and will be deleted. Please remove usage of this field.
204
+
"createdBy": "A String", # The user who created the Rollout. Readonly.
205
205
"deleteServiceStrategy": { # Strategy used to delete a service. This strategy is a placeholder only used by the system generated rollout to delete a service. # The strategy associated with a rollout to delete a `ManagedService`. Readonly.
206
206
},
207
207
"rolloutId": "A String", # Optional. Unique identifier of this Rollout. Must be no longer than 63 characters and only lower case letters, digits, '.', '_' and '-' are allowed. If not specified by client, the server will generate one. The generated id will have the form of , where "date" is the create date in ISO 8601 format. "revision number" is a monotonically increasing positive number that is reset every day for each service. An example of the generated rollout_id is '2016-02-16r1'
"description": "Operation payload for EnableService method.",
1487
-
"id": "EnableServiceResponse",
1488
-
"properties": {},
1489
-
"type": "object"
1490
-
},
1491
1485
"Endpoint": {
1492
1486
"description": "`Endpoint` describes a network address of a service that serves a set of APIs. It is commonly known as a service endpoint. A service may expose any number of service endpoints, and all service endpoints share the same service definition, such as quota limits and monitoring metrics. Example: type: google.api.Service name: library-example.googleapis.com endpoints: # Declares network address `https://library-example.googleapis.com` # for service `library-example.googleapis.com`. The `https` scheme # is implicit for all service endpoints. Other schemes may be # supported in the future. - name: library-example.googleapis.com allow_cors: false - name: content-staging-library-example.googleapis.com # Allows HTTP OPTIONS calls to be passed to the API frontend, for it # to decide whether the subsequent cross-origin request is allowed # to proceed. allow_cors: true",
1493
1487
"id": "Endpoint",
@@ -2643,7 +2637,7 @@
2643
2637
"type": "string"
2644
2638
},
2645
2639
"createdBy": {
2646
-
"description": "This field is deprecated and will be deleted. Please remove usage of this field.",
2640
+
"description": "The user who created the Rollout. Readonly.",
0 commit comments