[REC-73] Develop Test Case to Test Versions of Blueprint Sub-components Created: 19/Nov/19  Updated: 03/Jan/20

Status: To Do
Project: Radio Edge Cloud
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Medium
Reporter: Deepak Kataria Assignee: Naga Sugguna
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This test case will test versions supported in the blueprint for various sub-components such as (shown here as an example) THIS IS A CI/CD test requirement

Get specific versions from packages.yaml. In the absence of a specific version #, the latest version of that package is used (and should just be ignored as we are only testing for those specifically indicated.)

(some examples....

·        CentOS 7.6 with LTS Kernel 4.14

·        Docker 19.03.2

·        Kubernetes 1.16.0

·        DANM 4.0

·        Ceph 12.2

·        Helm 2.14.3

·        CPU-Pooler 0.3

·        Prometheus 2.11

·        Elasticsearch 6.7

·        Fluentd 1.6

·        Ironic 10.1.4

·        Keystone 13.0.2 )

 Comments   
Comment by Michael Hunter [ 02/Jan/20 ]

While that might work for the REC blueprint, it is not generic enough for all blueprints.
The “packages.yaml” file is something we would expect other blueprints to contain, and other blueprints don’t use RPM’s for deployment in most cases.
Are you aware where packages.yaml resides for the REC blueprint?

Comment by Naga Sugguna [ 02/Jan/20 ]

I could not make anything from above comment.

What I am expecting is
1) an absolute file path of a file which mentions component and version
2) structure of the file one example line is "python=3.6"

In that case BluVal automation can read that file and check for expected versions. Please understand all the blueprint owners supposed to use the same file location and structure, then only BluVal can really use this file.

 

 

Comment by Michael Hunter [ 02/Jan/20 ]

(per saku.chydenius):

Packages.yaml does not end up into the ISO image. Main reason is that the image itself contains more precise data of what packages, versions and dependencies were actually installed. Given file can be included easily via ta/manifest:product-manifest.spec if required:
• https://gerrit.akraino.org/r/gitweb?p=ta/manifest.git;a=blob;f=product-manifest.spec;hb=refs/heads/master

There is more precise list of all included packages per Jenkins build available here (but not included in the ISO nor in the inner QCOW2 image):
• https://logs.akraino.org/production/vex-yul-akraino-jenkins-prod-1/ta-ci-build-amd64/264/work/results/rpmlists/rpmdata.json

Comment by Michael Hunter [ 02/Dec/19 ]

Naga needs the following:

1) Name of yaml file containing the list and versioning of all require components: File name is: packages.ini

2) Location:

Talk to Nokia folks to see if packages.yaml end up in the ISO, otherwise, use version in Gerrit

 

Comment by Deepak Kataria [ 19/Nov/19 ]

I think we should confirm that the supported version in the blueprint is installed.

Comment by Naga Sugguna [ 19/Nov/19 ]

Do we strictly match for versions exactly matched here.

Eg. Docker 19.03.2, test makes sure that version 19~ or 19.03~ or strict 19.03.2?

Generated at Sat Feb 10 06:04:53 UTC 2024 using Jira 9.4.5#940005-sha1:e3094934eac4fd8653cf39da58f39364fb9cc7c1.