Skip to content

adding breaking change information for orca #504

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from
Closed

adding breaking change information for orca #504

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
cea204c
adding breaking change information for orca
shlomodaari Apr 3, 2025
3eb3f6c
Update 1.36.0-changelog.md
shlomodaari Apr 22, 2025
e37d56a
update(readme): refactor document based on reviewers comments
shlomodaari Apr 30, 2025
9f451c3
docs(changelog): adjust orca to front50 breaking change message
dbyron-sf May 5, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
47 changes: 42 additions & 5 deletions content/en/changelogs/1.36.0-changelog.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -7,10 +7,45 @@ version: 1.36.0

## Changelog

#### Breaking Changes

##### Orca to Front50 Timeout Configuration

Before [PR 4773](https://github.com/spinnaker/orca/pull/4773), these config properties and defaults controlled timeouts for orca to front50 communication (e.g. for saving a pipeline):
```yaml
ok-http-client:
connectTimeoutMs: 5000
readTimeoutMs: 120000
maxRequests: 100
maxRequestsPerHost: 100
connectionPool:
maxIdleConnections: 15
keepAliveDurationMs: 30000
```
After PR #4773, the config properties changed to:
```yaml
front50:
okhttp:
connectTimeoutMs: 10000
readTimeoutMs: 10000
writeTimeoutMs: 10000
```
There's no equivalent for ok-http-client.maxRequests, maxRequestsPerHost, nor the connection pool properties after PR 4773. The defaults in okhttp are:

- maxRequests: [64](https://github.com/square/okhttp/blob/parent-4.9.3/okhttp/src/main/kotlin/okhttp3/Dispatcher.kt#L46)
- maxRequestsPerHost: [5](https://github.com/square/okhttp/blob/parent-4.9.3/okhttp/src/main/kotlin/okhttp3/Dispatcher.kt#L65)
- maxIdleConnections: [5](https://github.com/square/okhttp/blob/parent-4.9.3/okhttp/src/main/kotlin/okhttp3/ConnectionPool.kt#L47)
- keepAliveDurationMs: [300000](https://github.com/square/okhttp/blob/parent-4.9.3/okhttp/src/main/kotlin/okhttp3/ConnectionPool.kt#L47)

and they're no longer configurable.

This is a behavior change, both for users who specified the ok-http-client properties, and those who relied on the defaults. To get the pre-1.36.0 timeouts, specify the front50.okhttp values as desired.
```

## Java upgrades
Java 17 is now the default source and target. Java 11 support has been removed entirely. Please note you may need to add the following JAVA_OPTS options:
```--add-exports=java.base/sun.security.x509=ALL-UNNAMED --add-exports=java.base/sun.security.pkcs=ALL-UNNAMED --add-exports=java.base/sun.security.rsa=ALL-UNNAMED```
to clouddriver if using GCP accounts due to credentials parsing of certificates. These can set in the [service-settings config](https://spinnaker.io/docs/reference/halyard/custom/#custom-service-settings). These configs are likely to be added to the defaults
to clouddriver if using GCP accounts due to credentials parsing of certificates. These can set in the [service-settings config](https://spinnaker.io/docs/reference/halyard/custom/#custom-service-settings). These configs are likely to be added to the defaults
in all future releases

## Kleat is deprecated
Expand Down Expand Up @@ -42,8 +77,10 @@ controller:
```

#### Orca

Updates Orca's SavePipelineTask to support bulk saves using the updated functionality in the front50 bulk save endpoint.


With https://github.com/spinnaker/orca/pull/4781, keys from the stage context's outputs section can now be removed (there by reducing the context size significantly).
At present the following tasks support this feature:
* PromoteManifestKatoOutputsTask
Expand Down Expand Up @@ -88,7 +125,7 @@ stages:
check-if-application-exists.enabled: true
resize-server-group-stage:
check-if-application-exists.enabled: true

# cluster stages
disable-cluster-stage:
check-if-application-exists.enabled: true
Expand Down Expand Up @@ -125,17 +162,17 @@ Configurable controls are added to decide whether cache should be refreshed whil
controller:
pipeline:
save:
refreshCacheOnDuplicatesCheck: false // default is true
refreshCacheOnDuplicatesCheck: false // default is true
```

Batch update call now responds with a status of succeeded and failed pipelines info. The response will be a map containing information in the following format:

```
```
[
"successful_pipelines_count" : <int>,
"successful_pipelines" : <List<String>>,
"failed_pipelines_count" : <int>,
"failed_pipelines" : <List<Map<String, Object>>>
"failed_pipelines" : <List<Map<String, Object>>>
]
```
Here the value for `successful_pipelines` is the list of successful pipeline names whereas the value for `failed_pipelines` is the list of failed pipelines expressed as maps.
Expand Down