search

vrk-kpa / xroad-joint-development

Unmaintained repository. Development moved to: https://github.com/nordic-institute/X-Road-development
19 stars 8 forks source link

As X-Road Product Owner I want that the global configuration schema can be changed so that the change does not break the backwards compatibility #69

Closed hanhaka closed 7 years ago

hanhaka commented 8 years ago

Affected components: Global configuration Affected documentation: - Estimated delivery: Autumn 2016 External reference: https://jira.csc.fi/browse/PVAYLADEV-474

Problem Currently it is not possible to change the global configuration schema without breaking the backwards compatibility. By adding to or removing something from the schema, Central Server and Security Servers cannot communicate together if the Global Conf XML schema is not compatible. This will be causing a big break in X-Road communication when upgrading the new X-Road sw version.

There will be new features in global configuration now and then and that's it is needed to a general way to manage this kind of situation.

Acceptance criteria

hanhaka commented 8 years ago

Agreed on 18th of August that work on this issue can be started (done by VRK side).

PriitParmakson commented 8 years ago

What do we mean by "backwards compatibility"? It has to be defined or explained. Currently the only extension mechanism provided by "PR-GCONF X-Road: Protocol for Downloading Configuration" (v2.1) is that "X-Road implementations are free to define additional types of configuration parts" (section 2.5) (in addtion to PRIVATE-PARAMETERS and SHARED-PARAMETERS XML-files). That means that global configuration can contain other files than PRIVATE-PARAMETERS and SHARED-PARAMETERS files. These two files, however, have inflexible schemas (as far as I can decide). PRIVATE-PARAMETERS and SHARED-PARAMETERS files contain no XML "any" elements. The files also do not contain version numbers.

We should define the backwards compatibility use case(s) first.

"Global configuration provider introduces a new version of global configuration (say 2.1). The new version is backwards compatible in the sense that user can process it by skipping new elements; elements present in version 2.0 are preserved, including the semantics."

Could this be the use case?

Let me note that we need to develop a similar mechanism for Estonian document exchange XML capsule format.

PriitParmakson commented 8 years ago

Designing Schemas for Backward and Forward Compatibility http://www.xfront.com/backward-forward-compatibility/ looks important. If you know other sources for the theme, please drop here.

petkivim commented 8 years ago

One alternative would be to define configuration parameters as key value pairs, e.g.:

<m:paramSet>
    <m:stringparam>
        <m:name>param1</m:name>
        <m:value>valueq</m:value>
    </m:stringparam>
    <m:paramSet>
        <m:name>systemparams</m:name>
        <m:stringparam>
            <m:name>param2</m:name>
            <m:value>value2</m:value>
        </m:stringparam>
        <m:numericparam>
            <m:name>param3</m:name>
            <m:value>10</m:value>
        </m:numericparam>
        <m:boolparam>
            <m:name>param4</m:name>
            <m:value>true</m:value>
        </m:boolparam>
    </m:paramSet>     
</m:paramSet>

In this way new parameters can be added without changing the schema.

hanhaka commented 8 years ago

@PriitParmakson This issue was originally raised due to findings in 6.8.4 pull request that Global Configuration was changed in a way that v. 6.8.4 is not anymore compatible with previous sw versions (in v.6.8.4 the ‘identifierDecoder’ –element has been replaced with ‘certificateProfileInfo’ –element and the type of element has also changed => these two changes are breaking the schema).

We need some general way to do the schema changes now and in the future, and at the same time preserve the compatibility. For example that link provided by you, Designing Schemas for Backward and Forward Compatibility, is a very good starting point for designing the valid schema for X-road.

The ultimate goal of this issue #69 is to find a good solution and document it properly (not only internally but to public documentation => 'pr-gconf_x-road_protocol_for_downloading_configuration_x.doc'). Our developers will look at different solutions and hopefully they will find the best choice for our purposes. The one proposed by Petteri (above) is also one alternative how it could be done.

And yes, I think that your use case definition above for backward compatibility is the one we need: "Global configuration provider introduces a new version of global configuration (say 2.1). The new version is backwards compatible in the sense that user can process it by skipping new elements; elements present in version 2.0 are preserved, including the semantics."

PriitParmakson commented 8 years ago

Also of interest may be:

PriitParmakson commented 8 years ago

Ilkka a.o, Re: options A, B, and C (in the proposal):

hvainsalu commented 7 years ago

It is WIP?

hanhaka commented 7 years ago

Yes it is. We started the implementation during the current Sprint. (I just updated the WIP label to this issue.)

Implementation should be ready after the next Sprint (after two weeks).

hanhaka commented 7 years ago

New estimate for the code changes to be ready: after two next Sprints (after four weeks). Still some changes to be made to Configuration Proxy and Security Server side to support several versions of global configuration scheme.

hanhaka commented 7 years ago

Commited to XM/develop (finnish-6.9.0 pull request). Will be available with 6.9 release.