[Configuration Service] Provider vs Service config

[ochurlaud]

The Configuration service defines service level configurations and provider level configurations. It is unclear, throughout the whole interface, how a provider may mix different configurations (i.e. two service level configurations, or a provider level configuration with a service level one).

We have chosen in our implementation to forbid such a mix as this would raise difficult questions in some cases.

As a result, activating a service level configuration of a provider automatically deactivates a previous service level configuration, even if it concerned another service of the provider.

Is this correct? The specification should be clearer on the topic

[SamCooper]

The intention is that a service provider has a set of services that it supports, each of those services it supports (possibly) has a configuration. You can switch the configuration of each of those service individually using a ServiceConfiguration or as a set using a ProviderConfiguration.

So for example my implementation: ProviderA -> ServiceImplB (Service X) -> ServiceImplC (Service Y)

I can reconfigure it by submitting a provider configuration that includes configurations for both services, or one of the services individually by just a configuration that has one service.

Does this make sense?

[lacourte]

When i try to answer you I realized that I have oversimplified my proposal. There is a problem in the specification, but not as extreme as it justifies a single service level configuration active.

The problem lies in mixing provider level configurations with service level configurations. It shows when you consider the expected result of a call to getCurrent after any mix of activations.

I will detail the issue with one ProviderConfiguration object (P1), and two ServiceConfiguration objects for the service X (X1, X2) and one for the service Y (Y1).

1. activate X1 1.a - getCurrent(X) -> X1 1.b - getCurrent(Y) -> UNKNOWN 1.c - getCurrent(P) -> INVALID
2. activate Y1 (you are right, this should be possible without removing X configuration) 2.a - getCurrent(X) -> X1 2.b - getCurrent(Y) -> Y1
3. activate P1 3.a - getCurrent(P) -> P1 3.b - getCurrent(X) -> INVALID (even if the actual content for X in P1 is X1) 3.c - getCurrent(Y) -> INVALID (even if there is no actual content for Y in P1, which looks possible)
4. activate X2 4.a - getCurrent(P) -> INVALID 4.b - getCurrent(X) -> X2 4.c - getCurrent(Y) -> UNKNOWN (there is not necessarily a ServiceConfiguration object for the Y part of the P1 configuration, and even if there is we cannot know it)

In this example provider level configurations and service level configurations are mutually exclusive. We could consider a more interesting behaviour in declaring a ProviderConfiguration object as a list of ServiceConfiguration objects, but this would change a lot the specifications. In that case we could mix different levels of configuration. The provider level operations would be seen as a grouping of service level operations. The only remaing issue would be the 1.c and 4.a requests. Should we still return INVALID, or dynamically create a ProviderConfiguration for this particular mix, or even change the return value of getCurrent as a list of ServiceConfiguration objects ?

[SamCooper]

But a ProviderConfiguration is a list of ServiceConfiguration objects

[lacourte]

Where do you read that a ProviderConfiguration is a list of ServiceConfiguration objects?

[SamCooper]

In "2.5 Types of Configuration":

It also defines two levels of Configuration as a Provider may support multiple different services: – Service Configuration: the configuration of a single service in a provider including all the attribute values of its definition objects. – Provider Configuration: the set of ‘Service Configurations’ of a single provider, so it will include zero to many Service Configurations.

[lacourte]

Well this is true. I regret this has not been translated into code underneath.

3.4.3.b) The ProviderConfiguration COM object related link shall link to the ConfigurationObjects COM object that contains the objects that form the provider configuration.

3.4.3.e) The ServiceConfiguration COM object related link shall link to the ConfigurationObjects COM object that contains the objects that form the service configuration.

The body does not help. It is just an identifier.

As you can see the link between ProviderConfiguration and ServiceConfiguration has been lost in the implementation.

[SamCooper]

It is unfortunate but it is a side effect of the COM model (only one part for the body and only one related link).

This feels like there should be some more requirements to be added to the COM object requirements section to make this clear. Should I also add some extra text to the overview part of the Configuration service to reaffirm this?

[lacourte]

I would like you to go back to my detailed example above. I detail what would be the result of the "mutually exclusive" option. As I understand your answer, this option does not satisfy you. Can you confirm ?

So if you want to get a better result, can you detail the answers that should be returned by the call listed there? For example I assume that you would like to get "X1" as a result of call 3.b.

From that on we can check what changes are required to make it possible. I am not sure that mere changes in the object requirements section will be enough. We need to retrieve the link between ProviderConfiguration and ServiceConfigurations. This implys a change in structures.

There may be another way, which is not to make the ProviderConfiguration a COM object. It could be a simple MAL object structure, referring to the ServiceConfiguration objects.

[SamCooper]

Yes, I think you have hit on a real confusion in the specification currently. It is because we can activate at different levels and call "getCurrent" at different levels.

As I see it there are two ways of going from here, either we change it such that you cannot get your self into the mutually exclusive options, by either restricting what level the activate or get can works on.

Or, we make it such that activate stays the same but getCurrent, when requesting at provider level, returns a provider configuration if it can (no service level activations) or a list of service configurations if there has been a service level activation. It could even return the provider config followed by a set of changed service configs.

Does that make sense?

[lacourte]

Yes it does. I think this can be implemented. The result of the getCurrent would become an ordered list of configurations, possibly starting by a ProviderConfiguration.

[SamCooper]

Done