spring-cloud / spring-cloud-app-broker Goto Github PK

Using a manifest, describe which components (Spring Beans) are used to perform the Provision workflow as described: https://github.com/openservicebrokerapi/servicebroker/blob/master/spec.md#provisioning

The current design within App Broker is that each Workflow within OSB is decomposed into a set of actions eg. Create Service Instance, GetLastOperation. Each of these actions will be further decomposed into a pipeline, made up of many steps that are chained together. Each step is a FunctionalInterface. An example step would be generateCredential.

App Broker will provide a default for each type of step, such as a deployApp that deploys to CF. Users will be able to override each individual step by providing a Spring Bean that implements the appropriate interface. An alternative way of configuring what steps are used would be to specify the @Bean class type within a manifest. An example of what this might look like is:

actions:
  - create-service-instance
     steps:
     - CustomCredentialsGenerator
     - NoOpParameterValidator

The order of the steps is fixed, so ordering of the manifest doesn't matter. If any of the expected steps are omitted then a default will be used

e.g. create mysql service instance and bind the deployed app

What is the best pattern for kicking off a reactive flow in a service broker operation (e.g. create service instance) to implement async behavior? Will it require the spring-cloud-open-service-broker service interfaces to return reactive types?

parent of #11, parent of #12

All service broker actions (create, delete, update instances; create, delete bindings) are no-ops.

parent of #44, parent of #43, parent of #41

GIVEN The application manifest contains:

spring:
  cloud:
    appbroker: 
      services: 
        apps:
        - name: my-app
          credentials-providers:
          - name: SpringSecurityBasicAuth

AND The application manifest contains an app named basic-auth-app
WHEN a service instance is created
THEN the application basic-auth-app has a SPRING_APPLICATION_JSON environment variable containing the values:

{"security.user.name": "ageneratedusername", "security.user.password": "ageneratedpassword"}

• Allow multiple applications to be deployed to back a service instance
• Applications should be deployed asynchronously, returning async:true to the OSB API and reporting status via the "get last operation" OSB API
• Allow the deployment options of each application to be configured (memory, disk, buildpack, health check timeout, etc)

parent of #7, parent of #9, parent of #50

Currently the Deployer SPI provides non reactive signatures eg String deploy(AppDeploymentRequest request) (see [https://github.com/spring-cloud/spring-cloud-deployer/blob/master/spring-cloud-deployer-spi/src/main/java/org/springframework/cloud/deployer/spi/app/AppDeployer.java]

To use Deployer effectively within a multi-flow reactive pipeline, there would need to be alternative, reactive interfaces provided by the Deployer SPI, eg Mono<String> deploy(AppDeploymentRequest request)

It should be feasible to provide reactive alternatives to the default implementations of the Reactive SPI (Cloud Foundry, Kubernetes, Local)

cc @sabbyanandan

GIVEN that I specify a backing app with the name: mapping-app
WHEN cf create-service my-service -c '{"key": "value", "compoundKey": { "subkey1": "subvalue1", "subkey2": "subvalue2" }}'
THEN I can see the SPRING_APPLICATION_JSON environment variable for the backing app mapping-app containing the value:

"{"transformed.key": "value", "other.transformed.compoundKey"; { "subkey1": "subvalue1", "subkey2": "subvalue2" }}"

where the mapping of keys from the request parameters to backing app env is configurable by the implementing service broker

parent of #5, parent of #8

Where custom strategy implementation is provided by the service author.

parent of #45, parent of #60, parent of #61

Document how implementing a custom strategy would look like for a Service Broker author.

GIVEN The application manifest contains:

spring:
  cloud
    appbroker:
      services: 
        apps:
        - name: app-with-services
          services:
          - service-instance-name: my-db-service
            name: mysqldb
            plan: small
            parameters: 
              key: value
          - service-instance-name: my-messaging-service
            name: rabbitmq
            plan: medium
            parameters: 
              key: value

WHEN a service instance is created
THEN backing service instances with the given names and plans should be created (asynchronously if required by the service) and bound to the app-with-services app

parent of #16, parent of #17, parent of #18

Provide an adapter for persistence that allows developers to provide an implementation for persisting data within their service broker. Persistence hooks will be available for each defined phase in the Open Service Broker lifecycle, eg. create , update, deprovisionetc

By default App Broker will use an in-memory model with no persistence or JPA annotations on model classes. Developers will be free to reuse these model classes and optionally provide their own supplementary model classes.

Given catalog information is configured with one service definition and one plan
When a GET request to /v2/catalog is received
Then the catalog information is retrieved for one service with one plan

Given Environment secrets and credentials are available to the build
When When a build is triggered by a Pull Request in the open source project repository
Then The build uses a Cloud Foundry server to run acceptance tests against
And Does not expose any secrets in files or logs

When apps are deployed, App Broker should return immediately from the OSB "create service" interface call and report that the service instance creation is being done asynchronously. The current state of the deployment (in progress, success, failure) should be reported when the OSB "get last operation" interface call.

We had previously discounted Wiremock because of issues where a set of interactions span multiple requests. Using S-C-Contracts, it should be possible to run multiple stub servers, one for each CF service eg api.cf.., login.cf...` etc.

Using S-C-Contracts should be preferred as it is a Spring project! (So Hoverfly is maybe a stop gap solution)

see https://github.com/spring-cloud/spring-cloud-contract/tree/master/spring-cloud-contract-stub-runner

Provide an adapter for persistence that allows developers to provide an implementation for persisting data within their service broker. Persistence hooks will be available for each defined phase in the Open Service Broker lifecycle, eg. create , update, deprovisionetc

By default App Broker will use an in-memory model with no persistence or JPA annotations on model classes. Developers will be free to reuse these model classes and optionally provide their own supplementary model classes.

At the moment we can't see how many tests have been successfully run.

Parameters include memory, buildpack, disk, health-check type and timeout, environment variables, route, instance count, org and space.

NOTE: we might want to break these into separate stories.

Scenario Hoverfly is a test tool used to capture and playback HTTP requests. App Broker uses this tool to test the contract with our deployer and the cloud platform. Currently, a manual process is needed to generate the simulation.

Given A deployer performs a deployment operation, such as cf push
When a hoverfly process is configured to act as an intercepting proxy to capture the traffic
Then a simulation JSON file is exported and and automatically processed, as described in:
)

When running tests, logging is very noisy, should be set to INFO or WARN (or combination)

e.g. bind the deployed app to an existing mysql service instance

The named service should already exist, as a brokered or user-provided service.

eg. is an app started, stopped, errored

Building on #31, adding service instance creation and binding

GIVEN a description of service instances to deploy
WHEN the deployment is executed
THEN the apps are deployed as described
AND the service instances are deployed as described
AND service instances are bound to appropriate apps

e.g. bind the deployed app to an existing mysql AND an existing RabbitMQ service instances

The named services should already exist, as a brokered or user-provided service

GIVEN The application manifest contains:

spring:
  cloud:
    appbroker: 
      services: 
        apps:
        - name: my-app
          credentials-providers:
          - name: SpringSecurityOAuth2
            args: 
            - identity-zone-subdomain: my-identity-zone

WHEN a service instance is created
THEN the application my-app has a SPRING_APPLICATION_JSON environment variable containing the values:

{
"security.oauth2.client.access-token-uri: "https://my-identity-zone.uaa.example.com/oauth/token", 
"security.oauth2.client.client-id": "my-app-[SI GUID]", 
"security.oauth2.client.client-secret": "a-generated-secret"
}

AND a client with the ID and secret will be stored in UAA within the specified identity zone
AND the client will be deleted from UAA when the service instance is deleted

If the args: identity-zone-subdomain configuration property is omitted, then the client is created in the default UAA identity zone.

GIVEN that I specify a backing app with the name: mapping-app
AND I specify that I want it to be a discrete env variable
WHEN cf create-service my-service -c '{"key": "value" }'
THEN I can see the property "key=value" in the environment variable for the backing app mapping-app.

• Define API for app deployment abstraction layer
• Define initial app deployment workflow structure
• WebFlux support in Spring Cloud Open Service Broker
• Deploy an app via configuration

parent of #28, parent of #24, parent of #31, parent of #32, parent of #6

Initially plan to use Bamboo. We can move to concourse when we get more organized on that.

GIVEN a description of apps to deploy
WHEN the deployment is executed
THEN the apps are deployed as described

Parameters include memory, buildpack, disk, health-check type and timeout, environment variables, route, instance count, org and space.

NOTE: we might want to break these into separate stories.

Given a Spring Boot application packaged in a Jar file
When a PUT request to /v2/service_instances/:instance_id is received
And configuration parameters are specified for the deployment
And the deployer implementation is specified
Then the Spring Boot application is pushed to Cloud Foundry using the configured parameters
And the deployer returns information about the deployed application

parent of #20, parent of #22

Given a service broker application that uses app broker
When I deploy the service broker to the cloud platform
Then I am able to register the service broker with the platforms' marketplace