Major dependencies updates:
* Spring Boot 3
* Spring Framework 6
* Spring Cloud Open Service Broker 4.0.0-SNAPSHOT
* Java 17
* Gradle 7.6
Dockerfile:
* Update to Ubuntu Jammy
* Bump to OpenJDK 17
* Remove usage of deprecated `apt-key` tool
* Bump all other tools to latest versions (bosh, bbl, credhub etc.)
ATs:
* Pass required java buildpack env var to use Java 17 on CF
* Update `cf login` invocation to work with cf-cli v8
Small improvements:
* Reliable datetime comparison in `InMemoryServiceInstanceStateRepositoryTest`
* Update `.editorconfig` to match existing style
* Add `.sdkmanrc`
State field was deprecated in CAPI and starting from CFJC 5.3 marked as nullable, since it won't be sent by CAPI versions 3.91+.
App Broker should use status field instead.
Updating compatibility matrix with SCOSB and OSBAPI versions
Updating default buildpack to empty String. Nulls are not allowed by operations and the only way to enable autodiscovery is by passing and empty list, passing an empty String will trigget that behaviour. Updating tests to document the default buildpack
The update service flow is now:
1. pre-update backing applications
2. update backing services
3. update backing applications
The Cloud Foundry implementation has a pre-update step which applies
backing application environment updates. This allows the following
backing services update step to read the updated app environment, which
is required for correct operation of some services where a rebind is
performed on update. The final update backing applications step performs
a rolling redeployment as before to ensure both environment changes and
any credential updates resulting from a rebind are propagated to the
backing apps.
#396
* Make just about everything API scope, apart from commons-text
* Also use Spring Boot BOM to manage Spring Framework and Reactor
versions in core subproject
Currently App Broker allows users to specify mutually exclusive
manifest properties - specifically `routes` along with any combination
of the deprecated `host`, `hosts`, `domain` and `domains`. This change
makes `routes` take precedence if specified.
To keep the behavior consisten, also updated delete flow to delete backing
services that the backing app are actually bound to.
As part of making the new AT pass, moved delete backing services step to
before deleting backing app.
Connects to #293
* Configurable API polling duration to support async backing services
By default cf-java-client will set a default completion timeout of 5 Mins.
The api-polling-timeout property now enables a configureable value
applied in create/update/delete service instance CF API calls for
backing services.
* Refine Configurable API polling duration to support async backing services
- now fetches the polling duration in app properties as documented, then defaults to global properties, then defaults to constant
- cleaned up comments
* Fix missing javadoc as reported by checkstyle
- Add PMD checks and resolve failing rules
- Apply Spring Checkstyle rules based on Spring Framework
- Rearrange imports to be more consistent
- Format whitespace
This property is supported by CAPI and `domain` is just a configuration
shortcut. However for compatibility reasons existing `domain` property
can't be removed, instead new `domains` property is added. When both are
provided in the request, `domains` will take priority.
Before only error message was dispalyed in logs providing no
information, like exception details or stacktrace. Now error message is
logged together with exception, including stacktrace.
When the backing applications and services are in created in a separate space, the space can get deleted before we get into the delete backing service instance step.
Ideally, the deletion of the space should be handled after the backing apps and backing service instanes are deleted.
Connected to https://github.com/spring-cloud/spring-cloud-app-broker/issues/267
Before every update-service call would upgrade the backing application.
This changes will only create a new application package when the flag upgrade is provided.
When using the space per service instance strategy, currently the OAuth
client requires `cloud_controller.admin` privileges to deploy apps and
services to a new space. This commit adds support for dynamically granting
the space developer role to a client which has the org manager role but not
admin privileges.
Resolves#203
Requiring client credentials to run ATs
- `CloudFoundryOperationUtils` was accessing the default org
to get operations, which in some cases wasn't correct, e.g.
when getting a service instance not created in the default org.
To solve this problem, we're now exposing a new method `getOperationsForOrgAndSpace`,
which gets the operations in the organization and space specified.
