Discuss: extend schemas for context

[lyubo1]

Defining schemas for parameters communicate with the platform availability of features and knobs. In some cases, certain context items could be deemed mandatory for the broker, like platform_id, etc. Having these requirements in the schema can be useful?

Because context schemas do not exist in the spec as is (only extended to parameters), I wonder what people think of extending this?

Thanks

[Samze]

@lyubo1 Just so I understand are you talking about allowing schemas for https://github.com/openservicebrokerapi/servicebroker/blob/master/profile.md ?

Is the idea that the broker could use the schema to inform platforms what context data it requires? Do you imagine the platform would change it's behaviour based on the schema?

[lyubo1]

Yes, I was referring to the Context Object.

Is the idea that the broker could use the schema to inform platforms what context data it requires?

Something like that yes. Though if more deterministic context is required it can be established through parameters. In the case of a single broker implementation which caters to different platforms, it could be useful for the broker to advertise what is absolutely necessary.

In turn it could be useful for the platform to know this and adjust, providing a more self-service approach rather than tight coupling between platform/broker.

I keep on going back and forth between lose schema or no schema.

[fmui]

In our brokers, we added an array field supported_platforms to the plan meta data, which indicates where this plan can be used. The Service Manager makes sure that the plan is only visible to platforms of these types. The brokers can then assume that the context object contains what is documented in the profile document (or elsewhere). I think, just making sure that a field like platform_id is part of the context object is not sufficient. The semantics are important too and cannot be expressed with a schema.

[lyubo1]

Thanks Florian, yea that's one way of doing it. We use Broker instances to which we can eventually tie service offerings and plan.

[lyubo1]

I'm going to close the issue, thanks for the feedback folks