Pattern of releaseNumber to support draft releases

[openBackhaul]

Lately, we discussed collecting testing results while running the test case collection over an application. History of testing shall be available for analysis. Storing files or recording testing results in an application was considered.

In parallel, we attempt to sort the release numbering. (e.g. if the tag of the relevant specification would be 1.0.1_spec, then tag of some implementation should be 1.0.1-b_impl, or something similar.)

Yesterday, I was testing the MDIP at http://10.118.125.211:3013/ Some bug in the headers was already fixed.

Today, I was testing the MDIP at http://10.118.127.11:3013/ The same bug wasn’t fixed.

If results would be stored without information about detailed information about the releaseNumber of the draft releases, it would not be feasible to see from the collected test results, whether the issue is already fixed, or not.

So recording of testing results for analyzing history is wasted, if it is not feasible to read the releases of the implementation and the test case collection from the stored result.

(1) Updating the release number in the CONFIGfile of the implementation before instantiating in the SDN laboratory would be required.

(2) Pattern of the release number needs to be adapted in the ApplicationPattern and the RegistryOffice (maybe more applications affected).

[PrathibaJee]

As you mentioned , modifying the release number pattern will impact many Individual APIs like bequeath-your-data-and-die , subscription services like “/v1/notify-device-alarm”.

Until we provide a permanent solution(modifying the release-number pattern) as mentioned in the above comment , Kindly please consider the following proposal as a temporary solution ,

1. When a new version of the implementation is released for example , 1.1.0.a_impl(pre-release) , 1.1.0_impl(final release) ,1.1.0-hotfix-1_impl(hotfix)
2. Before deploying the application as a container , in the CICD pipeline a string profile shall be included to the configuration file with the correct version of the implementation. For example ,

     {
         "uuid": "mwdi-1-1-0-string-p-100",
         "profile-name": "string-profile-1-0:PROFILE_NAME_TYPE_STRING_PROFILE",
         "string-profile-1-0:string-profile-pac": {
           "string-profile-capability": {
   +              "string-name": "versionOfTheImplementation"
           },
           "string-profile-configuration": {
   +              "string-value": "1.1.0.a_impl"
           }
         }
       } 

   This version information documented in the string profile shall be used to identify the current version of the implementation. Please let me know your views. Many thanks.

[openBackhaul]

Hmm, naja, would require several temporary changes (CI/CD pipeline, test case collection) and information would have to be retrieved via OaM paths that are often not included into the specification.

[PrathibaJee]

Yes , 'string-profile' OAM paths are not available in all the applications. But, since oneOf the property of core-model-1-4:profile in all the applications has string-profile , this included information in the 'string profile' shall be retrieved from the OaM paths,

1. /core-model-1-4:control-construct
2. /core-model-1-4:control-construct/profile-collection/profile={uuid}

---

It's just an idea to manage the problem temporarily with the existing ApplicationPattern. Kindly please ignore this proposal if its not required for now. Many Thanks.