Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[QG 4] Clarify Chart testing #122

Closed
SebastianBezold opened this issue Aug 15, 2023 · 8 comments
Closed

[QG 4] Clarify Chart testing #122

SebastianBezold opened this issue Aug 15, 2023 · 8 comments

Comments

@SebastianBezold
Copy link
Contributor

Description

Looking at the runs for Lint and Test Charts, you can see, that all of the runs are failing. The only successful runs skip "Run chart-testing" and "Run helm upgrade".

Looking at the workflow itself, I can also see some copy/paste of PVC manifests that I cannot see a reason for.

Also, wenn installing the latest Chart (version 1.0.0), it's running in a crash loop. Installed via:

helm install dpp tractusx-dev/digital-product-pass --version 1.0.0 --namespace dpp --create-namespace

Results in a couple of restarts, but ending in Errors containing this hing:

 [The following configuration properties have incompatible values: [[org.eclipse.tractusx.productpass.services.DataTransferService.checkEdcConsumerConnection]

If this is a malformed sample value, I think the default should be replace by a correctly formatted value. If it is a startup check, that could also be done on runtime (reachability test of remote service), then I would suggest to change this test to a runtime evaluation. The TRG 5.01 Description does point out, that Charts should be installable without any config and at least start without issues.

This should be clarified, before the QG 4 check #108 is marked as passed

@matbmoser
Copy link
Contributor

matbmoser commented Aug 15, 2023

Hi @SebastianBezold,

We basically used the workflow provided by the TRGs.
We added security checks so that our backend application can run. We are able to deploy the application but if you dont configure any value and not have a valid EDC configuration the backend will not be useful. Is deployable but not useful.

The EDC consumer should be working and we check for this if the configuration is correct.
And in the configuration we add a dummy edc url

@matbmoser
Copy link
Contributor

About the PVC:

For running the Container in the Github workflows we need a PV instance. Therefore we copy and paste the PV inside the workflow file system to enable it to work. If you would run it in local or in another environment the PV would not be needed.

@matbmoser
Copy link
Contributor

Finally the helm tests work. https://github.com/eclipse-tractusx/digital-product-pass/actions/runs/5868393507
The condition was set to false in the default values configuration:

security:
check:
enabled: false
bpn: false
edc: false

@SebastianBezold
Copy link
Contributor Author

Hi @matbmoser,

the original issue seems to be fixed, but the app is still not starting due to other startup config evaluation it seems:

run via:

install dpp tractusx-dev/digital-product-pass --version 1.0.0-rc3 --namespace dpp --create-namespace

Error:

org.eclipse.tractusx.productpass.exceptions.ServiceException: [org.eclipse.tractusx.productpass.services.CatenaXService.start] It was not possible to get the discovery endpoints, [org.eclipse.tractusx.productpass.services.CatenaXService.getDiscoveryEndpoints] It was not possible to retrieve the discovery finder!, [org.eclipse.tractusx.productpass.services.AuthenticationService.getToken] It was not possible to retrieve the token!, [utils.HttpUtil] It was not possible to do POST request to https://<keycloak.url>/auth/realms/<realm>/protocol/openid-connect/token, Could not create URI object: Illegal character in authority at index 8: https://<keycloak.url>/auth/realms/%3Crealm%3E/protocol/openid-connect/token

@matbmoser
Copy link
Contributor

matbmoser commented Aug 16, 2023

To call the Discovery Service after the correct startup is an achitecture requirement for us to get the endpoint of the BPN Discovery and the EDC Discovery.

The same way that the EDC breaks if you have not added a correct configuration. And there is no problem with that.

@matbmoser
Copy link
Contributor

The requirement is documented here:

If the `configuration.dtr.central` is disabled the backend will also make a call to the `Discovery Finder` service to find the `BPN Discovey` and `EDC Discovey` services.

@matbmoser
Copy link
Contributor

Ok @SebastianBezold the issue with the dash tool has been resolved and the images have been published.

The new v1.0.0 version created from the release candidate rc4 contains the fix for this issue.

@SebastianBezold
Copy link
Contributor Author

1.0.0-rc4 and 1.0.0 running fine now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants