Service broker can declare supported schema for parameters field #165

mattmcneeney · 2017-04-07T13:27:30Z

See issue #59.

cfdreddbot · 2017-04-07T13:27:31Z

Hey mattmcneeney!

Thanks for submitting this pull request! I'm here to inform the recipients of the pull request that you and the commit authors have already signed the CLA.

pmorie · 2017-04-10T14:54:55Z

spec.md

+| [schemas](#SObject) | object | Schema definitions for service instances and bindings for the plan. |
+
+
+##### Schema Object <a name="SObject"></a> #####


Markdown automatically creates anchors for you - do you still need this?

Nope; I was just being consistent with the current spec (I know there is an outstanding PR that addresses this). I'll fix in this branch!

duglin · 2017-05-04T12:32:27Z

rebase needed (and squash too)

mattmcneeney · 2017-05-04T12:58:50Z

@duglin how's this? Not sure if I missed any new RFC keywords.

Samze

JSON schema types must be lowercase

Samze · 2017-05-09T13:08:26Z

spec.md

+              "properties": {
+                "billing-account": {
+                  "description": "Billing account number used to charge use of shared fake server.",
+                  "type": "String"


"String" should be lowercase "string"

Samze · 2017-05-09T13:08:54Z

spec.md

+              "properties": {
+                "billing-account": {
+                  "description": "Billing account number used to charge use of shared fake server.",
+                  "type": "String"


"String" should be lowercase "string"

duglin · 2017-05-09T13:52:56Z

spec.md

-| bindable*  | boolean  | Specifies whether instances of the service can be bound to applications. This specifies the default for all plans of this service. Plans can override this field (see [Plan Object](#PObject)).  |
-| metadata  |  JSON object | An opaque object of metadata for a service offering. Controller treats this as a blob. Note that there are (conventions)[https://docs.cloudfoundry.org/services/catalog-metadata.html] in existing brokers and controllers for fields that aid in the display of catalog data. |
-| [dashboard_client](#DObject)  |  object |  Contains the data necessary to activate the Dashboard SSO feature for this service |
+|  bindable | boolean  |  Specifies whether instances of the service plan can be bound to applications. This field is OPTIONAL. If specified, this takes precedence over the `bindable` attribute of the service. If not specified, the default is derived from the service. |


Are we allowed to make this optional? Doesn't that break backwards compat?

... of the service. (3rd sentence) - did you mean "plan" instead of "service" here?

Not sure where this came from. Rebase mess up I think. Sorting now...

duglin · 2017-05-09T13:56:48Z

spec.md


 |  Response field | Type  | Description  |
 |---|---|---|
 | id*  | string  | An identifier used to correlate this plan in future requests to the broker. This MUST be globally unique within a platform marketplace. Using a GUID is RECOMMENDED.  |
 | name*  | string  | The CLI-friendly name of the plan. MUST be unique within the service. All lowercase, no spaces.  |
 | description*  | string  | A short description of the plan.  |
-|  metadata | JSON object  | An opaque object of metadata for a service plan. Controller treats this as a blob. Note that there are (conventions)[https://docs.cloudfoundry.org/services/catalog-metadata.html] in existing brokers and controllers for fields that aid in the display of catalog data. |
+|  metadata | object  | A list of metadata for a service plan.  |


Why drop the note? Perhaps we should move that note into the spec?

duglin · 2017-05-09T13:58:28Z

spec.md

@@ -568,7 +644,7 @@ the resource it creates.
 | plan_id*  | string  | ID of the plan from the catalog.  |
 | app_guid  | string  | Deprecated in favor of <code>bind\_resource.app\_guid</code>. GUID of an application associated with the binding to be created.  |
 | bind_resource  | JSON object  | A JSON object that contains data for platform resources associated with the binding to be created. Current valid values include <code>app\_guid</code> for [credentials](#types-of-binding) and <code>route</code> for [route services](#route_services).  |
-| parameters | JSON object  |  Configuration options for the service binding. An opaque object, controller treats this as a blob.  |   |
+| parameters | JSON object  |  Configuration options for the service binding. |   |


I think there's an extra | at the end - was there before too.

mattmcneeney · 2017-05-09T13:59:52Z

Yeah I've actually fixed that in another PR that should go in before this one! (Async bindings)

…

On Tue, 9 May 2017 at 14:58, Doug Davis ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In spec.md <#165 (comment)> : > @@ -568,7 +644,7 @@ the resource it creates. | plan_id* | string | ID of the plan from the catalog. | | app_guid | string | Deprecated in favor of <code>bind\_resource.app\_guid</code>. GUID of an application associated with the binding to be created. | | bind_resource | JSON object | A JSON object that contains data for platform resources associated with the binding to be created. Current valid values include <code>app\_guid</code> for [credentials](#types-of-binding) and <code>route</code> for [route services](#route_services). | -| parameters | JSON object | Configuration options for the service binding. An opaque object, controller treats this as a blob. | | +| parameters | JSON object | Configuration options for the service binding. | | I think there's an extra | at the end - was there before too. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#165 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG7UzL2asuzBQZ2oWDMl957CitMDKB1cks5r4HEFgaJpZM4M25U0> .

duglin · 2017-05-10T12:24:16Z

spec.md

 | free  | boolean  | When false, instances of this plan have a cost. The default is true  |
-|  bindable | boolean  |  Specifies whether instances of the service plan can be bound to applications. This field is OPTIONAL. If specified, this takes precedence over the <tt>bindable</tt> attribute of the service. If not specified, the default is derived from the service. |
+|  bindable | boolean  |  Specifies whether instances of the service plan can be bound to applications. This field is optional. If specified, this takes precedence over the `bindable` attribute of the service. If not specified, the default is derived from the service. |


s/optional/OPTIONAL/

I've removed this. It shouldn't have been added in this PR.

mattmcneeney · 2017-05-10T12:28:24Z

spec.md

 | free  | boolean  | When false, instances of this plan have a cost. The default is true  |
-|  bindable | boolean  |  Specifies whether instances of the service plan can be bound to applications. This field is OPTIONAL. If specified, this takes precedence over the <tt>bindable</tt> attribute of the service. If not specified, the default is derived from the service. |
+| bindable | boolean | Specifies whether instances of the service plan can be bound to applications. This field is OPTIONAL. If specified, this takes precedence over the `bindable` attribute of the service. If not specified, the default is derived from the service. |


This is left alone now @duglin

pmorie

Since this PR is not likely to be merged soon, I think we should move strictly formatting based changes (or as many as is easily feasible) into another PR. I think there are just a couple:

The name of the plan-object anchor changing
Changes to remove unneeded formatting for headers
Spacing changes

I could probably do this for you fairly easily (using git interactive staging with tig status) and give you a branch that has the transformation in it, if you're interested. I'm also happy to show you my git tricks.

As-is, it's not clear to me where the formatting changes stop and the changes in the spec begin. In general I think we should avoid formatting changes in proposal PRs because they will take much longer to merge than normal formatting changes. That said, I can fully appreciate how hard it can be to avoid mixing formatting changes in :)

pmorie · 2017-05-12T03:07:32Z

spec.md

@@ -568,7 +644,7 @@ the resource it creates.
 | plan_id*  | string  | ID of the plan from the catalog.  |
 | app_guid  | string  | Deprecated in favor of <code>bind\_resource.app\_guid</code>. GUID of an application associated with the binding to be created.  |
 | bind_resource  | JSON object  | A JSON object that contains data for platform resources associated with the binding to be created. Current valid values include <code>app\_guid</code> for [credentials](#types-of-binding) and <code>route</code> for [route services](#route_services).  |
-| parameters | JSON object  |  Configuration options for the service binding. An opaque object, controller treats this as a blob. Brokers SHOULD ensure that the client has provided valid configuration parameters and values for the operation. |   |
+| parameters | JSON object | Configuration options for the service binding. Brokers SHOULD ensure that the client has provided valid configuration parameters and values for the operation. |


Is this an editing/format change or related to this PR?

mattmcneeney · 2017-05-12T08:50:37Z

Totally agree @pmorie. I'll remove formatting changes from this now, and then we can hopefully merge #192 and then rebase this one with the fixed formatting.

mattmcneeney · 2017-05-22T17:06:36Z

This PR has been updated following last weeks' conversations. But we will need to add more to this surrounding the "meta schema" work.

angarg12 · 2017-05-23T06:19:34Z

Will you push the changes to this PR, or would you rather merge this one and start a new conversation in a follow up?

mattmcneeney · 2017-05-23T08:10:35Z

@angarg12 I think we can continue in this PR, it'll just need some more changes before we review

mattmcneeney · 2017-05-23T11:17:43Z

OK, so @Samze and @ablease have been doing some validation around the new schemas proposal and have some interesting feedback for us:

Resource-level schemas are:
- Good for UIs, as they are able to show all config parameters for a service or binding, including those that cannot be changed
- But makes validation very difficult
  - Validation libraries don't support meta-schems or the additional creatable and updateble flags
  - How do we deal with required on create but not required on update
Method-level schemas (original proposal) are:
- OK for UIs, but they have to be clever when prepopulating forms and can't easily show other resource information (unless we have a separate schema for that)
- Good for validation libraries (you just have to pass in the create or update schema with the parameters and any library will give you a valid/invalid response)

We know that there will be few UIs to many service brokers, so it's important to keep service brokers easy to implement. Resource-level schemas do not do this, as it makes validation tricky and means broker authors have to understand how to apply the meta-schema to their resource schemas. Method-level schemas are easy to implement, may have duplication (but we don't think this is an important issue), and make building UIs a bit harder, but there are workarounds that don't require super complex logic.

So, in conclusion, we think we should continue with the proposal that was in place before the face-to-face last week. We can talk about this on today's call but wanted to give you all the heads up in case you had time to think about this before the call. Thanks!

pmorie · 2017-05-27T18:46:03Z

@jwforres, what are your thoughts about the feedback here: #165 (comment)

jwforres · 2017-05-30T18:17:46Z

From our perspective we have the same validation concerns as a broker as far as client-side validation of JSON schema. If we try to combine create vs update into the same schema and distinguish between what is required then we are overcomplicating things. There are already great client-side JSON schema form builders and validators, we shouldn't unnecessarily re-invent things in that space. For that reason alone I would agree that sticking with method-level schema makes the most sense.

@mattmcneeney can you clarify what UI benefits you are thinking of that you get with resource-level schema instead. I could maybe see wanting to show parameters that were set during create as read-only fields during an update, which would require knowing which fields were there during create.

mattmcneeney · 2017-05-30T19:57:49Z

@jwforres There were two benefits that we could think of adding schemes at the resource level. The first is what you have mentioned; being able to 'easily' build a form that showed parameters that were set at create time but weren't updatable. The second was that other resource level fields could be added to the schema (i.e. dashboard URL).

However, our investigations showed that combining the schemes didn't make building forms easier for UI teams and made validation much more difficult. Since we want many brokers to add parameter validation (and platforms too) we believe we need to make life easy for broker authors, which we think is method attached schemes.

skaegi

LGTM

mattmcneeney · 2017-09-01T08:11:05Z

Alright, if everyone is happy, I think we can move this into review!
@duglin @shalako @pmorie @angarg12 @fmui @vaikas-google @avade

duglin · 2017-09-01T14:52:42Z

profile.md

+
+#### Cloud Foundry
+
+The following restrictions are enforced within a Cloud Foundry deployment:


hmm, these are requirements on brokers right? So, are we saying that a broker that wants to be used by both Kube and CF may need to have different schema? I guess I'm asking whether these CF requirements are really CF specific or if they should be true for all platforms/brokers?

I was hoping they wouldn't be clashing requirements - just additive things like fields that should be expressed (rather than "Broker authors must not do ...").

duglin · 2017-09-01T14:53:31Z

profile.md

+  ```
+  "type": "object"
+  ```
+- The `$schema` field MUST be included at the top level of any provided schema.


Didn't we talk about $schema being optional but then letting the platform pick a default? Or am I mixing up conversations?

We did, but in CF we really want to know the exact version so we can tell our validation library which version to validate against. I put this in profile.md to save having this requirement in the core spec, though I expect most broker authors to add the $schema key normally anyway.

Obviously happy to move both of these to the core spec if everyone agrees with them

@duglin do you have any further thoughts on this?

I'd prefer for it to be consistent between platforms otherwise we'll have an interop issue, and if we do that then we might as well just put it in the core spec, no?

I agree that we want to be consistent here and think we should consider making appropriate changes to the OSB spec...

After reflecting, the feedback I gave earlier around handling multiple spec versions by inference was ultimately not good. Leaving it up to the platform to infer the JSON Schema version is just not of sufficient value to special case in the spec; it only leads to unexpected behaviour. So... IF an author would like their parameters to be validated according to JSON Schema the contents of "parameters" MUST be a valid JSON Schema document (with a valid "$schema" property value that the platform understands) or else be empty.

Beyond stating that the document must be a valid JSON Schema document I would not stipulate "type": "object" on the schema as this requirement will vary with the schema version. e.g. in v4 only "type": "object" is permitted but in v6 the meta-scheme permits "type": "boolean, object", and who knows what future versions might say here. I would leave this detail up to the schema spec and not in OSB.

duglin · 2017-09-01T15:01:51Z

spec.md

+
+| Response field | Type | Description |
+| --- | --- | --- |
+| parameters | JSON schema object | The schema definition for the input parameters. Platforms MUST support at least [JSON Schema draft v4](http://json-schema.org/), but SHOULD be prepared to support multiple versions. If no schema version is provided by the broker author using `$schema`, platforms MUST minimally interpret definitions using [JSON Schema draft v4](http://json-schema.org/), and if unsuccessful, MAY try using later JSON Schema versions. Each input parameter is expressed as a property within a JSON object. |


I wonder if this statement about schema versions should be more globally stated and not hidden with this one field.

Maybe once we start using schemas for more than just parameters?

duglin · 2017-09-01T15:03:53Z

spec.md

@@ -557,7 +629,7 @@ It MUST be the ID a previously provisioned service instance.
 | context | object | Contextual data under which the service instance is created. |
 | service_id* | string | The ID of the service (from the catalog). MUST be globally unique. MUST be a non-empty string. |
 | plan_id | string | The ID of the plan (from the catalog) for which the service instance has been requested. MUST be unique within the service. If present, MUST be a non-empty string. If this field is not present in the request message, then the broker MUST NOT change the plan of the instance as a result of this request. |
-| parameters | JSON object | Configuration options for the service instance. An opaque object, controller treats this as a blob. Brokers SHOULD ensure that the client has provided valid configuration parameters and values for the operation. If this field is not present in the request message, then the broker MUST NOT change the parameters of the instance as a result of this request. |
+| parameters | JSON object | Configuration options for the service instance. Brokers SHOULD ensure that the client has provided valid configuration parameters and values for the operation. |


any reason you dropped the MUST NOT sentence?

Maybe, but it was so longer ago I can't remember the reason, so I'll put it back in!

avade · 2017-09-06T09:59:35Z

Ok, it seems like everyone has had a chance to review and give feedback.

I think this is now in a state that we can merge it into the spec and move forward with the 2.13 release.

LGTM

skaegi · 2017-09-06T17:57:07Z

profile.md

+  ```
+- The `$schema` field MUST be included at the top level of any provided schema.
+- No external references are allowed in schemas.
+- Schemas MUST be no larger than 64kB.


Is there some special reason why there is a 64kB restriction?

mattmcneeney · 2017-09-06T18:08:59Z

We limit to 64kB for security and performance reasons (we measured how long it took to register a broker with many services with many plans with many schemes). In reality, we don't think schemas will close to 64kB in size. I agree with your comments Simon. In my opinion, the important points the spec needs to detail are: 1. Platforms may want to support multiple versions of schema to support as many brokers as possible. 2. Platforms need to know what version of JSON schema a broker is using to correctly validate it (and possibly build a UI using it). 3. Platforms may want to offer different restrictions on schemas. I think we agree on 1 and 2, in which case I believe the PR as it stands (updated today) is sufficient. Brokers must have the $schema field and use at least v4 (the minimum platforms may support). The restrictions are interesting. I agree about type object, so we'd be happy to remove this as it is required in Schema v4 anyway. If the group agrees on the size limit and no external references (again for security reasons in our case) then I'd be happy to move these into the core spec and have no platform profiles section for schemas. What do you think?

…

On Wed, 6 Sep 2017 at 18:57, Simon Kaegi ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In profile.md <#165 (comment)> : > +Platforms MAY enforce restrictions on the JSON schemas service brokers can use +to describe the input parameters they accept (see [spec](spec.md#schema-object). +Each section below will describe any restrictions a Platform places on input +parameter schemas. + +#### Cloud Foundry + +The following restrictions are enforced within a Cloud Foundry deployment: + +- The `parameters` object MUST have a top-level field as follows: + ``` + "type": "object" + ``` +- The `$schema` field MUST be included at the top level of any provided schema. +- No external references are allowed in schemas. +- Schemas MUST be no larger than 64kB. Is there some special reason why there is a 64kB restriction? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#165 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG7UzAEG6xahcJxfj61yki55tJMuJsBoks5sftz3gaJpZM4M25U0> .

skaegi · 2017-09-06T18:24:54Z

No external references is reasonable. +1

I'm less comfortable with the size cap but admit that a 64kB schema seems unlikely at this point - most I have used in our platform are less than 1kB. Perhaps we could say that in a less restrictive way? If a schema is larger than 64kB a platform MAY refuse to register the broker...

mattmcneeney · 2017-09-06T18:33:32Z

Sure, I don't mind that, but if we want to make it easy for people to create platform agnostic brokers I think we should definite very clear rules that all platforms abide by. We can always change or remove restrictions in the future if a need arises.

…

On Wed, 6 Sep 2017 at 19:24, Simon Kaegi ***@***.***> wrote: No external references is reasonable. I'm less comfortable with the size cap but admit that a 64kB schema seems unlikely at this point - most I have used in our platform are less than 1kB. Could we say that in a less restrictive way? If a schema is larger than 64kB a platform MAY refuse to register the broker? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG7UzP1XN_XUzvlB0fOe2WGVFpXbY_QAks5sfuN4gaJpZM4M25U0> .

angarg12 · 2017-09-07T10:58:25Z

This is a big feature, so instead of trying to overengineer it beforehand I would prefer to get it out there and see how different brokers use it. If further requirements/restrictions arise in the future we can address them later.

So I'm in favor of moving the restrictions out of the profiles to the spec.

skaegi · 2017-09-07T17:56:08Z

spec.md

+
+| Response field | Type | Description |
+| --- | --- | --- |
+| parameters | JSON schema object | The schema definition for the input parameters. Platforms MUST support at least [JSON Schema draft v4](http://json-schema.org/), but SHOULD be prepared to support multiple versions. Broker auhtors MUST provide the version of JSON Schema they are using. Schemas MUST NOT contain any external references and MUST be no larger than 64kB. Each input parameter is expressed as a property within a JSON object. |


typo -- auhtors instead of authors

Thanks - fixed!

mattmcneeney · 2017-09-08T07:43:00Z

Looking for some LGTMs today! (Thanks for the feedback so far)
@angarg12 @duglin @pmorie @skaegi @shalako @vaikas-google @fmui @avade

angarg12 · 2017-09-08T08:56:10Z

LGTM

duglin · 2017-09-08T11:28:38Z

spec.md

@@ -228,10 +228,40 @@ how platforms might expose these values to their users.
 | metadata | JSON object | An opaque object of metadata for a service plan. Controller treats this as a blob. Note that there are [conventions](profile.md#service-metadata) in existing brokers and controllers for fields that aid in the display of catalog data. |
 | free | boolean | When false, service instances of this plan have a cost. The default is true. |
 | bindable | boolean | Specifies whether service instances of the service plan can be bound to applications. This field is OPTIONAL. If specified, this takes precedence over the `bindable` attribute of the service. If not specified, the default is derived from the service. |
+| [schemas](#schema-object) | object | Schema definitions for service instances and bindings for the plan. |


all of these objects, should they be JSON object to be consistent with what I above? e.g. metadata

yes it should be - thanks!

Wait - I'm not actually sure it should be. Elsewhere in the spec when the object definition is defined in the spec, we just use object, and use JSON object where the structure is not defined.

hmm I think you're right. That distinction was totally lost on me and I wonder whether its one worth keeping - after all, object is always a JSON object, right?

But that can be a different PR, if we want to change it

Yeah, I don't think there are any cases now in the spec where object != JSON object, but we can handle that elsewhere :)

duglin · 2017-09-08T11:43:02Z

spec.md

+
+| Response field | Type | Description |
+| --- | --- | --- |
+| parameters | JSON schema object | The schema definition for the input parameters. Platforms MUST support at least [JSON Schema draft v4](http://json-schema.org/), but SHOULD be prepared to support multiple versions. Broker authors MUST provide the version of JSON Schema they are using. Schemas MUST NOT contain any external references and MUST be no larger than 64kB. Each input parameter is expressed as a property within a JSON object. |


I'm ok with the requirements of this field. I'm just wondering whether it would read better if everything after the first sentence were moved to a non-tabular format. Meaning, put it in a paragraph/section right after this table so that we have more space to be more explicit. For example:

+++
While the presence of schema in the Plan is OPTIONAL, if it is present then the following applies:

Platforms MUST support at least JSON Schema draft v4.

Platforms SHOULD be prepared to support other versions of JSON Schema well.

The $schema keyword MUST be present in the schema with the version of the JSON Schema being used.

Schemas MUST NOT contain any external references (e.g. use the $ref keyword).

Schemas MUST NOT be larger than 64kB.

Each input parameter MUST be expressed as a child of the properties field in the schema.

+++

Just allows us to be a little more verbose and show the exact json entities we're talking about.

Did you want to mention that type is required? Or is that obvious?

We're leaving that up to the spec, since this changes in v6 schema.
Moving the text out of the table - check back in 2 mins!

duglin · 2017-09-08T11:45:49Z

spec.md

+              "type": "object",
+              "properties": {
+                "billing-account": {
+                  "description": "Billing account number used to charge use of shared fake server.",


Do we want (or need) to place any requirements on the set of fields used to describe the properties? I'm guessing no but wanted to ask to be sure.

duglin · 2017-09-08T13:36:56Z

LGTM

angarg12 · 2017-09-08T14:18:26Z

LGTM

skaegi · 2017-09-08T15:13:50Z

LGTM

avade · 2017-09-08T16:02:33Z

LGTM

vaikas · 2017-09-08T20:58:57Z

LGTM

mattmcneeney · 2017-09-08T21:39:22Z

Woohoo! Thanks all!

…

On Fri, 8 Sep 2017 at 22:30, Ville Aikas ***@***.***> wrote: Merged #165 <#165>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#165 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AG7UzC1_VosV664Pvjgm8hYqgpc2qFkhks5sgbILgaJpZM4M25U0> .

pmorie reviewed Apr 10, 2017

View reviewed changes

gberche-orange mentioned this pull request May 4, 2017

Generic Extensions (Actions) Proposal #114

Closed

Samze requested changes May 9, 2017

View reviewed changes

duglin reviewed May 9, 2017

View reviewed changes

mattmcneeney mentioned this pull request May 10, 2017

Fix formatting of links to CF conventions for metadata #191

Merged

duglin reviewed May 10, 2017

View reviewed changes

mattmcneeney commented May 10, 2017

View reviewed changes

pmorie reviewed May 12, 2017

View reviewed changes

pmorie mentioned this pull request May 20, 2017

Add support for OSB parameter schemas kubernetes-retired/service-catalog#822

Merged

mattmcneeney mentioned this pull request May 23, 2017

Add missing period #208

Merged

avade modified the milestone: 2.12 May 24, 2017

avade modified the milestones: 2.12, 2.13 May 26, 2017

mattmcneeney self-assigned this Aug 31, 2017

skaegi reviewed Sep 1, 2017

View reviewed changes

duglin reviewed Sep 1, 2017

View reviewed changes

skaegi reviewed Sep 6, 2017

View reviewed changes

skaegi reviewed Sep 7, 2017

View reviewed changes

duglin reviewed Sep 8, 2017

View reviewed changes

add method-attached schemas

478f920

vaikas merged commit 49ec60c into openservicebrokerapi:master Sep 8, 2017

mattmcneeney mentioned this pull request Sep 11, 2017

Service broker can declare supported schema for parameters field #59

Closed

mattmcneeney removed the 3 - reviewing PR label Sep 11, 2017

		\| [schemas](#SObject) \| object \| Schema definitions for service instances and bindings for the plan. \|


		##### Schema Object <a name="SObject"></a> #####


		#### Cloud Foundry

		The following restrictions are enforced within a Cloud Foundry deployment:

Service broker can declare supported schema for parameters field #165

Service broker can declare supported schema for parameters field #165

Conversation

mattmcneeney commented Apr 7, 2017

cfdreddbot commented Apr 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

duglin commented May 4, 2017

mattmcneeney commented May 4, 2017 • edited Loading

Samze left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattmcneeney commented May 9, 2017 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pmorie left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattmcneeney commented May 12, 2017

mattmcneeney commented May 22, 2017

angarg12 commented May 23, 2017

mattmcneeney commented May 23, 2017

mattmcneeney commented May 23, 2017 • edited Loading

pmorie commented May 27, 2017

jwforres commented May 30, 2017

mattmcneeney commented May 30, 2017

skaegi left a comment

Choose a reason for hiding this comment

mattmcneeney commented Sep 1, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

avade commented Sep 6, 2017 • edited by chipchilders Loading

Choose a reason for hiding this comment

mattmcneeney commented Sep 6, 2017 via email

skaegi commented Sep 6, 2017 • edited Loading

mattmcneeney commented Sep 6, 2017 via email

angarg12 commented Sep 7, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mattmcneeney commented Sep 8, 2017 • edited by chipchilders Loading

angarg12 commented Sep 8, 2017 • edited by chipchilders Loading

duglin Sep 8, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

duglin commented Sep 8, 2017 • edited by chipchilders Loading

angarg12 commented Sep 8, 2017 • edited by chipchilders Loading

skaegi commented Sep 8, 2017

avade commented Sep 8, 2017 • edited by chipchilders Loading

vaikas commented Sep 8, 2017 • edited by chipchilders Loading

mattmcneeney commented Sep 8, 2017 via email

mattmcneeney commented May 4, 2017 •

edited

Loading

pmorie left a comment •

edited

Loading

mattmcneeney commented May 23, 2017 •

edited

Loading

avade commented Sep 6, 2017 •

edited by chipchilders

Loading

skaegi commented Sep 6, 2017 •

edited

Loading

mattmcneeney commented Sep 8, 2017 •

edited by chipchilders

Loading

angarg12 commented Sep 8, 2017 •

edited by chipchilders

Loading

duglin Sep 8, 2017 •

edited

Loading

duglin commented Sep 8, 2017 •

edited by chipchilders

Loading

angarg12 commented Sep 8, 2017 •

edited by chipchilders

Loading

avade commented Sep 8, 2017 •

edited by chipchilders

Loading

vaikas commented Sep 8, 2017 •

edited by chipchilders

Loading