Modeling variability within USDL

[jorge-cardoso]

In our work with the University of Stuttgart we have face the following situation. We have modeled SurgarCRM as a service offering. Customers can select one from four configurations: Professional, Corporate, Enterprise, and Ultimate. Once a customer selects a configuration, it is sent to the TOSCA deployment manager which will install SugarCRM in a PaaS platform (e.g. Amazon EC2). The problem is how can a customer change some of the properties of a configuration? For example, a SugarCRM installation requires a name, the selection of an image for a logo, and support for mobile access. How can USDL indicate that these are three configuration points? Configuration points enable users to specify a value for a specific property which can be customized.

One possible solution would be to define certain properties as "fixed"/"read-only", "user defined"/"read-write" and "required"/"optional".

If we decide not to include variability modeling in usdl:core, where could it be modeled? A customization file in the flavor of an SLA agreement? But even in this case, the SL manager needs to know which properties or parameters can be negotiated.

[jorge-cardoso]

At this point, USDL should not model variability since:

1. USDL should be kept simple
2. No use case has justified its modeling

While USDL+TOSCA shows the need for it, it may be possible in the future that another specification maybe designed to handle the variability (i.e. configuration) of a service.

[drleidig]

Things like Professional, Corporate, Enterprise, and Ultimate are currently to be modeled as ServiceLevelProfiles. ServiceLevelProfiles are used with the ServiceOffering. However, it would be possible to attach the ServiceLevelProfiles also to directly to the Service.

ServiceLevelProfiles are in the SLA module. Do we additionally need options in the core vocabulary? The I would call this a ServiceProfile, which just enumerates concrete properties of the service.

The ServiceLevel descriptions within a ServiceLevelProfile have to be simplified anyway.

[drleidig]

Another possibility would be to (re)introduce the concept of options.
How can this look like?