GeoServer

Add configuration versioning information

Details

  • Type: Improvement Improvement
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.1.1
  • Fix Version/s: None
  • Component/s: Configuration
  • Labels:
    None
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

The configuration system does not provide version information.

This information could include a specification version and implementation version. The versions would be stored in two places - the code and the configuration store. Upon loading, the implementation would be responsible for upgrades. Alternatively, an upgrade could be completed later via a tool.

Updates to specific components that can provide reasonable defaults (a new property, etc.) do not need to concern themselves with this.

The goal would be to support potentially expensive upgrade operations and major changes.

The attached patch is an example of how this might work.

Issue Links

relates to

Improvement - An improvement or enhancement to an existing feature or task. GEOS-4702 Passwords stored in plain text

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment -

I'm confused as to what this can be used for?
Is it similar to the existing "update sequence" number?

Show
Andrea Aime added a comment - I'm confused as to what this can be used for? Is it similar to the existing "update sequence" number?
Hide
Permalink
Justin Deoliveira added a comment -

The intention here is to track when internally we make code changes that affect configuration format, whereas updateSequence is used to track changes that users make to configuration.

The classic example is a major version upgrade like we did for 1.7.x to 2.0.x. In that case we use the existence of the files catalog.xml/services.xml as the marker. But perhaps for 2.0.x to 3.0.x the marker wont be so obvious so a number to track I think is a good idea.

A few comments regarding the patch:

  1. It's not obvious what the difference between "implementation" and "specification" version mean... I guess the latter is the current version of geoserver configuration, and the former is the current version of the data directory?
  2. This scheme will require developers to remember to update that number when we make configuration changes.. so we need a policy for that. Defining what changes require an upgrade (for instance, maybe simple additions don't?)
  3. Ideally the "specification" version would just be the version of geoserver... 2.1.2, 2.1.3, etc...
  4. This change probably actually requires a GSIP... even though the patch itself is fairly core so I think getting more feedback among the core devs will be good
Show
Justin Deoliveira added a comment - The intention here is to track when internally we make code changes that affect configuration format, whereas updateSequence is used to track changes that users make to configuration. The classic example is a major version upgrade like we did for 1.7.x to 2.0.x. In that case we use the existence of the files catalog.xml/services.xml as the marker. But perhaps for 2.0.x to 3.0.x the marker wont be so obvious so a number to track I think is a good idea. A few comments regarding the patch: It's not obvious what the difference between "implementation" and "specification" version mean... I guess the latter is the current version of geoserver configuration, and the former is the current version of the data directory? This scheme will require developers to remember to update that number when we make configuration changes.. so we need a policy for that. Defining what changes require an upgrade (for instance, maybe simple additions don't?) Ideally the "specification" version would just be the version of geoserver... 2.1.2, 2.1.3, etc... This change probably actually requires a GSIP... even though the patch itself is fairly core so I think getting more feedback among the core devs will be good
Hide
Permalink
Andrea Aime added a comment -

Ok, so once we have a marker stating that the configuration somehow changed... how are we going to use it? Are extensions going to start to check that for some reason?
Is it restconfig? I'm still lost on where the usefulness of this is.

Show
Andrea Aime added a comment - Ok, so once we have a marker stating that the configuration somehow changed... how are we going to use it? Are extensions going to start to check that for some reason? Is it restconfig? I'm still lost on where the usefulness of this is.
Hide
Permalink
Justin Deoliveira added a comment -

Well in this case I think the use case is for the user password encryption stuff... to know if the user.properties should be updated or not. But I will let Ian comment on that.

But in general I can think of cases where it would be useful. Think about (and this is hypothetical) if we ever moved to a resource publishing split. In the branch I experimented on it was actually tricky to detect if the data directory had already been updated or not... having configuration version would have been useful.

Show
Justin Deoliveira added a comment - Well in this case I think the use case is for the user password encryption stuff... to know if the user.properties should be updated or not. But I will let Ian comment on that. But in general I can think of cases where it would be useful. Think about (and this is hypothetical) if we ever moved to a resource publishing split. In the branch I experimented on it was actually tricky to detect if the data directory had already been updated or not... having configuration version would have been useful.
Hide
Permalink
Ian Schneider added a comment -

Justin covered the basic ideas.
As for Justin's comments:

  1. specification would be tied to release functional specifications and implementation to the backend (if there ever is more than one)
  2. Indeed - if the changes can be applied automagically with reasonable defaults and no breakage they qualify as simple additions though it might be useful to track them anyway (just to know what is new).
  3. I thought about that, but they're actually separate and release versions would trigger changes even if there were none. Tying the release to a version makes more sense, e.g. 2.1.x now uses version 5.
  4. Sounds fair.

And Andrea's:
The reason I considered this was the plain text password upgrade. For a small setup (1 user, a dozen StoreInfo objects), constantly checking for upgrades is no big deal. For a larger setup, this incurs needless pain. Part of this is due to what the password upgrade has to do (scan each DataStore and discover 'password' fields), but I looking forward, other cases are on the horizon:

  1. alternate config backend (implementation version) changes
  2. config cloning
  3. future, unseen needs similar to password upgrade (the cumulative effect of all changes blindly scanning for markers would become a burden)

As for extensions, if there is config they might be concerned about (either direct or indirect), then yes. This of course implies some type of pub-sub mechanism that is not included here.

Show
Ian Schneider added a comment - Justin covered the basic ideas. As for Justin's comments: specification would be tied to release functional specifications and implementation to the backend (if there ever is more than one) Indeed - if the changes can be applied automagically with reasonable defaults and no breakage they qualify as simple additions though it might be useful to track them anyway (just to know what is new). I thought about that, but they're actually separate and release versions would trigger changes even if there were none. Tying the release to a version makes more sense, e.g. 2.1.x now uses version 5. Sounds fair. And Andrea's: The reason I considered this was the plain text password upgrade. For a small setup (1 user, a dozen StoreInfo objects), constantly checking for upgrades is no big deal. For a larger setup, this incurs needless pain. Part of this is due to what the password upgrade has to do (scan each DataStore and discover 'password' fields), but I looking forward, other cases are on the horizon: alternate config backend (implementation version) changes config cloning future, unseen needs similar to password upgrade (the cumulative effect of all changes blindly scanning for markers would become a burden) As for extensions, if there is config they might be concerned about (either direct or indirect), then yes. This of course implies some type of pub-sub mechanism that is not included here.
Hide
Permalink
Andrea Aime added a comment -

Cool, thanks for explaining

Show
Andrea Aime added a comment - Cool, thanks for explaining

People

  • Assignee:
    Justin Deoliveira
    Reporter:
    Ian Schneider
Vote (0)
Watch (1)

Dates

  • Created:
    Updated: