What we're after: Tenants can easily provision SQS capability for hosted apps
Benefits/why:
Enable migration of queue-dependent apps to cloud.gov
Reduce burden on bespoke provisioning of AWS resources outside cloud.gov.
As this one is pretty isolated, we're going to try micropurchase.18f.gov as an experiment to see if we can get it done that way. If it works out, we'll do more micropurchase auctions for cloud.gov in future.
Story-form description: As a user of cloud.gov, I want to use an AWS SQS service in my application with as little hassle as possible, so I want to the ability to self-provision it without depending on the actions of others.
Context: Cloud.gov is a deployment and hosting platform for government digital services. Cloud.gov uses brokers to manage the lifecycle of services for its users. Cloud.gov invokes the AWS broker using the CloudFoundry Service Broker API to manage various AWS services for use by applications deployed to cloud.gov. This issue seeks to enable the AWS broker to also manage Amazon Simple Queue Service (SQS) service instances.
Implementation can be done with any AWS account; no access to existing 18F AWS infrastructure is needed to develop or demo it.
Cloud.gov should allow users to request and view the options available for an SQS service, create an SQS service instance for their Cloud Foundry space, and associate/disassociate the SQS service instance with one or more apps. When the Cloud Foundry service instance is deleted, the SQS service that was instantiated upon service creation and any credentials issued for bind operations should be deleted as well. No demonstration of operation inside cloud.gov should be needed… The behavior can be demonstrated via exercise of the AWS broker’s REST APIs.
Language/Framework: Go (the project is in Go already), REST APIs
Acceptance Criteria
This is a guide to how to demonstrate and validate the submitted work. The acceptance criteria here are specified using Gherkin, aka BDD. Actual BDD step implementation to validate the behavior and increase test coverage would be great, but is not necessary for the work to be accepted.
Background:
Given the AWS Broker is running
And the broker is configured to offer an SQS service
Scenario: Request is made to view SQS options
Given there is one service plan for the SQS service
When a request is being made to view the broker’s catalog
Then the response should include the SQS service
And the response should include the name of the SQS service plan
And the response should include a description of the service plan
And the response should include the pricing associated with each SQS service plan
And the response should be in [JSON] format.
Scenario: New service instance with SQS is created
Given there is one SQS plan
When a new service instance is provisioned with a specified SQS opti
Then a new service instance is created for that plan
And an SQS queue is created and associated with that instance
Scenario: An app gets valid credentials when bound to the SQS service instance
Given there is an SQS service instance
When an app id is bound to the instance
Then new IAM user credentials are returned for that app
And that IAM user has access to the queue associated with the instance
Scenario: An app id’s credentials are invalidated when unbound to the SQS service instance
Given there is an SQS service instance
And an app id that is bound to the instance
When the app id is unbound from the instance
Then the app id’s IAM user credentials no longer have access to the queue associated with the instance
Scenario: Removing service instance with results in deletion of associated SQS queue and IAMs
Given there is an SQS service instance
And there is an app id bound to the service instance
When the service instance is removed
Then the associated SQS queue is deleted
And any IAM credentials issued for that queue are revoked
What we're after: Tenants can easily provision SQS capability for hosted apps
Benefits/why:
As this one is pretty isolated, we're going to try micropurchase.18f.gov as an experiment to see if we can get it done that way. If it works out, we'll do more micropurchase auctions for cloud.gov in future.
Micropurchase link: https://micropurchase.18f.gov/auctions/24
Description for potential bidders
Story-form description: As a user of cloud.gov, I want to use an AWS SQS service in my application with as little hassle as possible, so I want to the ability to self-provision it without depending on the actions of others.
Context: Cloud.gov is a deployment and hosting platform for government digital services. Cloud.gov uses brokers to manage the lifecycle of services for its users. Cloud.gov invokes the AWS broker using the CloudFoundry Service Broker API to manage various AWS services for use by applications deployed to cloud.gov. This issue seeks to enable the AWS broker to also manage Amazon Simple Queue Service (SQS) service instances.
Implementation can be done with any AWS account; no access to existing 18F AWS infrastructure is needed to develop or demo it.
Cloud.gov should allow users to request and view the options available for an SQS service, create an SQS service instance for their Cloud Foundry space, and associate/disassociate the SQS service instance with one or more apps. When the Cloud Foundry service instance is deleted, the SQS service that was instantiated upon service creation and any credentials issued for bind operations should be deleted as well. No demonstration of operation inside cloud.gov should be needed… The behavior can be demonstrated via exercise of the AWS broker’s REST APIs.
Main repository to create Pull Request: https://github.com/18f/aws-broker
Language/Framework: Go (the project is in Go already), REST APIs
Acceptance Criteria
This is a guide to how to demonstrate and validate the submitted work. The acceptance criteria here are specified using Gherkin, aka BDD. Actual BDD step implementation to validate the behavior and increase test coverage would be great, but is not necessary for the work to be accepted.
Background:
Scenario: Request is made to view SQS options
Scenario: New service instance with SQS is created
Scenario: An app gets valid credentials when bound to the SQS service instance
Scenario: An app id’s credentials are invalidated when unbound to the SQS service instance
Scenario: Removing service instance with results in deletion of associated SQS queue and IAMs