Release 1.8

[planetf1]

Proposal to create Release 1.8 branch 2 June 2020, and then switch master to 2.0-SNAPSHOT

The 2.0 switch is due in part to the work (#1403 ) to switch to using https/ssl for all REST APis

• Create 1.x branch (PR not needed)
• Update master to 2.0-SNAPSHOT PR #3132 update to 2.0-SNAPSHOT #3138
• Update branch from 1.x-SNAPSHOT to 1.x PR RELEASE 1.8 - version/release note update #3142
• Remove release notes from branch PR RELEASE 1.8 - version/release note update #3142
• update release notes & rename (inc. for 2.x)
• Verify notebooks
• Check UI
• Run CTS
• Run FVTs (this is only FVTs automated in the build process)
• Check samples (only samples in the build)
• Check swagger doc
• Verify docker image/charts/compose
• Launch release pipeline
• Approve release
• Verify artifacts all on maven central (check for JCenter & other errors in release logs)
• Create GitHub release

[planetf1]

CTS (graph and inmem) complete with no errors

Profile results:

jonesn:release/ $ cat cts-inmem-profile.out                                                                                                                                                               [19:00:18]
0    0    Metadata sharing    The technology under test is able to share met...    MANDATORY_PROFILE    CONFORMANT_FULL_SUPPORT
1    1    Reference copies    The technology under test is able to save, loc...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
2    2    Metadata maintenance    The technology under test supports requests to...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
3    3    Dynamic types    The technology under test supports changes to ...    OPTIONAL_PROFILE    UNKNOWN_STATUS
4    4    Graph queries    The technology under test supports graph-like ...    OPTIONAL_PROFILE    CONFORMANT_PARTIAL_SUPPORT
5    5    Historical search    The technology under test supports search for ...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
6    6    Entity proxies    The technology under test is able to store stu...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
7    7    Soft-delete and restore    The technology under test allows an instance t...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
8    8    Undo an update    The technology under test is able to restore a...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
9    9    Reidentify instance    The technology under test supports the command...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
10    10    Retype instance    The technology under test supports the command...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
11    11    Rehome instance    The technology under test supports the command...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
12    12    Relationship search    The technology under test supports the ability...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
13    13    Entity advanced search    The technology under test supports the use of ...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
14    14    Relationship advanced search    The technology under test supports the use of ...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
jonesn:release/ $ cat cts-graph-profile.out                                                                                                                                                               [19:00:23]
    id    name    description    profilePriority    conformanceStatus
0    0    Metadata sharing    The technology under test is able to share met...    MANDATORY_PROFILE    CONFORMANT_FULL_SUPPORT
1    1    Reference copies    The technology under test is able to save, loc...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
2    2    Metadata maintenance    The technology under test supports requests to...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
3    3    Dynamic types    The technology under test supports changes to ...    OPTIONAL_PROFILE    UNKNOWN_STATUS
4    4    Graph queries    The technology under test supports graph-like ...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
5    5    Historical search    The technology under test supports search for ...    OPTIONAL_PROFILE    CONFORMANT_NO_SUPPORT
6    6    Entity proxies    The technology under test is able to store stu...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
7    7    Soft-delete and restore    The technolog7 under test allows an instance t...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
8    8    Undo an update    The technology under test is able to restore a...    OPTIONAL_PROFILE    CONFORMANT_NO_SUPPORT
9    9    Reidentify instance    The technology under test supports the command...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
10    10    Retype instance    The technology under test supports the command...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
11    11    Rehome instance    The technology under test supports the command...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
12    12    Relationship search    The technology under test supports the ability...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
13    13    Entity advanced search    The technology under test supports the use of ...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT
14    14    Relationship advanced search    The technology under test supports the use of ...    OPTIONAL_PROFILE    CONFORMANT_FULL_SUPPORT

[planetf1]

Testing the 'cohort' notebooks indicates some incomplete cohort registration. Not all servers are seeing all others.

Specifically cocoMDS4 is not reported as a remote member by any other members of the cohort. This is because cocoMDS4 does not have a metadata repository - and will not receive any federated queries.

This isn't a regression - but could be confusing and may need doc clarification. It may also be useful to be able to see all servers that have registered even if not a member of the cohort - for example so we can monitor those servers, and query configured services (such as OMASs) from a bootstrap entry point

cc: @mandy-chessell

[planetf1]

#2741 will look at improving the cohort registration process for members without a repo

[planetf1]

Potential issue in vdc helm chart

jonesn:charts/ (egeria-release-1.8*) $ helm install vdc odpi-egeria-vdc                                                                                                                 [11:25:15]
Error: ConfigMap in version "v1" cannot be handled as a ConfigMap: v1.ConfigMap.Data: ReadString: expects " or n, but found 1, error found in #10 byte of ...|VERSION":1.8,"GAIAN_|..., bigger context ...|yserver","EGERIA_USER":"myuser","EGERIA_VERSION":1.8,"GAIAN_HOST":"vdc-odpi-egeria-vdc-gaian-service|...

This error does not occur in master

The cause of this is due to the strings vs integers when parsing the template

In the dev build (ie master) we use '2.0-SNAPSHOT' which is interpreted as a string, whilst a simple '1.8' or '2.0' is not.

This then affects the template parsing when creating the config map.

[planetf1]

With testing completed I kicked off the build pipeline yesterday.

We're now on our third sync attempt (artifactory->bintray->jcenter->maven central) but maven central is seeing issues this week as per https://status.maven.org & is currently under maintainance.

[planetf1]

The following artifacts cannot be released:

• analytics-modeling-client (sources, javadoc) - but this is empty
• data-engine-proxy-services-server - odd? similar to rex-view
• rex-view - JCenter is complaining this is empty, even as a pom -- it is not.
• stewardship-engine-services-api - containts no code
• stewardship-engine-services-client - contains no code
• stewardship-engine-services-spring - contains no code

I have contacted JFrog support for rex-view (cc: @grahamwallis ) though since it's unlikely any egeria consumers would be dependent on this artifact - and it's only a packaging pom the impact is likely minor.

[grahamwallis]

Thanks for the heads-up @planetf1 re: rex-view. It sounds strange - it's just an implementation of a view service and should look very similar to glossary-author. I can't spot the difference yet. Quite soon tex-view is one the way, so it will be interesting to see if JCenter complains about that VS too.

[planetf1]

After looking at this more closely, I think the issue actually is that both rex-view & data-engine-proxy-services-server never got as far as bintray,. The former is not in JCenter since it's a new module, the latter is ... but this is not the problem in itself. Rather there is no built 1.8 version to stage.

I've gone through the release logs - and I can see rex-view being built, and indeed loaded into artifactory. The 'promotion' of repos is at a repo level so either all or none work. The sync to bintray is then a single jfrog cli command which succeeded - yet it seems as if this is where rex-view was 'lost'. No errors reported. This is a stage BEFORE where we've seen issues to-date which is in the bintray->JCente->maven central pipeline. With rex-view it never even made it that far

One of the challenges with this process is we only do it infrequently - in future perhaps publishing occasional snapshots through the same process would help flush out issues quicker. Also I don't have all the necessary credentials to clean things up. I will raise an issue at the LF to try and review the process and look at closing some of these gaps we have in place -- for example the jobs perhaps should do verification beyond checking the api succeeded by explicit checks

[planetf1]

For now I don't think the omission of these two artifacts will impact users. However I'll try and manually upload to bintray->JCenter.

I could rerun the full pipeline but will likely hit permission problems, and if not could spin another few days on the sync as the jobs aren't setup for small incremental updates. Given the nature of the omission this does not seem warranted.

[planetf1]

Summarised issues in #3194 - for future improvements in the reliability of this process

data-engine-proxy-services-server uploaded manually (already in JCenter) and synced to MC
Awaiting JCenter exclusion for rex-view

[planetf1]

rex-view now synced too.
All artifacts should now be complete on maven central.
Github release made.