This repository has been archived by the owner on Jul 6, 2022. It is now read-only.
DocumentDB only provisions a Microsoft.DocumentDB/databaseAccounts #259
Assignees
Comments
|
Removed from the v0.10.0 milestone since we want to discuss this more before we decide if it's a thing we'll do. |
jeremyrickard
added a commit
to jeremyrickard/open-service-broker-azure
that referenced
this issue
Apr 25, 2018
This PR introduces the needed logic and changes to allow the user to provision the equivalent of an All-In-One CosmosDB instance: a database account and a database. This is functionally equivalent to what MASB did, but follows the OSBA pattern of not allowing the user to name things. Closes: Azure#259
jeremyrickard
added a commit
to jeremyrickard/open-service-broker-azure
that referenced
this issue
Apr 26, 2018
This PR introduces the needed logic and changes to allow the user to provision the equivalent of an All-In-One CosmosDB instance: a database account and a database. This is functionally equivalent to what MASB did, but follows the OSBA pattern of not allowing the user to name things. Closes: Azure#259
krancour
pushed a commit
that referenced
this issue
Apr 30, 2018
* WIP all in one * Adding ability to provision ComosDB SQL API database This PR introduces the needed logic and changes to allow the user to provision the equivalent of an All-In-One CosmosDB instance: a database account and a database. This is functionally equivalent to what MASB did, but follows the OSBA pattern of not allowing the user to name things. Closes: #259 * Lint fixes * Cleanup * Lint fix * Update cosmosdb_cases_test.go
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The current DocumentDB service only provisions a Microsoft.DocumentDB/databaseAccounts. I think we should apply the same sort of pattern that we are doing with MySQL, PostgreSQL and SQLDB to this one. We probably also need to include whatever the generated database name is in the binding when we create it so you can reliably connect to it. The Java SDK from the Azure Java team requires the URI (which can point to an instance with N databases), the key and the database name you want to use. The current experience kind of requires a step outside the broker to really make DocumentDB usable, either the app needs to know what it wants to go create or you need to create it manually via the portal or API.
It doesn't appear that this can be done via ARM, so we might need to do a hybrid approach of ARM + API calls via the go sdk.
The text was updated successfully, but these errors were encountered: