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

KOTS reporting to replicated-app #4202

Merged

Conversation

FourSigma
Copy link
Contributor

@FourSigma FourSigma commented Dec 5, 2023

What this PR does / why we need it:

Injects relevant header metadata when KOTS reaches out to Replicated.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Steps to reproduce

Does this PR introduce a user-facing change?

NONE

Does this PR require documentation?

@CLAassistant
Copy link

CLAassistant commented Dec 5, 2023

CLA assistant check
All committers have signed the CLA.

}

if l != nil {
reportingInfo := reporting.GetReportingInfoByAppSlug(l.Spec.AppSlug)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The app slug is generated and won't always match the one in the license. I think you will need to use ListInstalledApps and then GetLatestLicenseForApp and then just call GetReportingInfo with the right app ID

@FourSigma FourSigma force-pushed the siva/sc-93559/wrong-data-in-field-customer-last-active branch from 6923957 to 730cfeb Compare December 6, 2023 15:44
@FourSigma
Copy link
Contributor Author

@sgalsaleh or @cbodonnell Would love you thoughts on how to globally mock a store.Store for failing unit test. I can't find a good pathway to dependency injection neatly.

Basically, the test is failing because of a callstore.GetStore() which is nil.

@@ -149,6 +180,14 @@ func getApplicationMetadataFromHost(host string, endpoint string, upstream *url.
return nil, errors.Wrap(err, "failed to call newrequest")
}

appID, err := store.GetStore().GetAppIDFromSlug(r.AppSlug)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like store.GetStore() is returning nil here as well based on the failing e2e jobs. This function is called in the context of the KOTS CLI, which is why it does not have direct access to the store.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So store.GetStore(), might not be returning nil here as I had thought above, but this would get called at a time where rqlite has not yet been deployed by KOTS and is the cause of the failing tests. Looking at the CI jobs, the kots install fails before any of the components are deployed. My suggestion would be to remove reporting from the metadata request here since it happens before a license is even installed. This initial metadata request is unauthenticated and is just used to apply branding to the initial screens.

@cbodonnell
Copy link
Contributor

@sgalsaleh or @cbodonnell Would love you thoughts on how to globally mock a store.Store for failing unit test. I can't find a good pathway to dependency injection neatly.

Basically, the test is failing because of a callstore.GetStore() which is nil.

In the SDK, we have this function, which allows setting the global store. Something like that would allow you to set and defer unset. In general, we've run into this issue a lot wrt the store dependency and it often requires a bit of refactoring to have functions accept the store.Store interface so we can unit test appropriately.

@FourSigma FourSigma added the type::feature New feature or request label Dec 15, 2023
@FourSigma FourSigma force-pushed the siva/sc-93559/wrong-data-in-field-customer-last-active branch 2 times, most recently from 19dcd62 to f1c319c Compare December 15, 2023 18:08
@FourSigma
Copy link
Contributor Author

FourSigma commented Dec 15, 2023

@sgalsaleh or @cbodonnell Would love you thoughts on how to globally mock a store.Store for failing unit test. I can't find a good pathway to dependency injection neatly.
Basically, the test is failing because of a callstore.GetStore() which is nil.

In the SDK, we have this function, which allows setting the global store. Something like that would allow you to set and defer unset. In general, we've run into this issue a lot wrt the store dependency and it often requires a bit of refactoring to have functions accept the store.Store interface so we can unit test appropriately.

@cbodonnell
Fixed this issue and the ci-test passes.

However, a large number of integration tests are failing with the error error connecting to rqlite: url specified is impossibly short. What the remediation for this particular error case?

@FourSigma FourSigma requested a review from cbodonnell December 15, 2023 19:44
@cbodonnell
Copy link
Contributor

@sgalsaleh or @cbodonnell Would love you thoughts on how to globally mock a store.Store for failing unit test. I can't find a good pathway to dependency injection neatly.
Basically, the test is failing because of a callstore.GetStore() which is nil.

In the SDK, we have this function, which allows setting the global store. Something like that would allow you to set and defer unset. In general, we've run into this issue a lot wrt the store dependency and it often requires a bit of refactoring to have functions accept the store.Store interface so we can unit test appropriately.

@cbodonnell Fixed this issue and the ci-test passes.

However, a large number of integration tests are failing with the error error connecting to rqlite: url specified is impossibly short. What the remediation for this particular error case?

@FourSigma I just left a follow-up comment here with my thoughts. Hopefully that is all that is causing the tests to trip up since the panic originates from the call to getApplicationMetadataFromHost (link).

@FourSigma
Copy link
Contributor Author

@sgalsaleh or @cbodonnell Would love you thoughts on how to globally mock a store.Store for failing unit test. I can't find a good pathway to dependency injection neatly.
Basically, the test is failing because of a callstore.GetStore() which is nil.

In the SDK, we have this function, which allows setting the global store. Something like that would allow you to set and defer unset. In general, we've run into this issue a lot wrt the store dependency and it often requires a bit of refactoring to have functions accept the store.Store interface so we can unit test appropriately.

@cbodonnell Fixed this issue and the ci-test passes.
However, a large number of integration tests are failing with the error error connecting to rqlite: url specified is impossibly short. What the remediation for this particular error case?

@FourSigma I just left a follow-up comment here with my thoughts. Hopefully that is all that is causing the tests to trip up since the panic originates from the call to getApplicationMetadataFromHost (link).

Makes sense @cbodonnell . I will make the change.

@FourSigma
Copy link
Contributor Author

@cbodonnell Happy Monday. Looks like we have some failures on validate-kots-pull. Since you are bit more familiar with this pathway, do you have some suggestions to get these test passing without too much refactoring?

@cbodonnell
Copy link
Contributor

cbodonnell commented Dec 18, 2023

@cbodonnell Happy Monday. Looks like we have some failures on validate-kots-pull. Since you are bit more familiar with this pathway, do you have some suggestions to get these test passing without too much refactoring?

the kots pull command also runs from the CLI before any resources are deployed, so the underlying failure reason is the same as what we saw for kots install. if we need to avoid refactoring, one possibility could be to log (maybe just at the debug level) and move on without attempting to add headers if the database call fails. this way it can still function if we do have a database context available, but will not if it's running from the CLI only. thoughts?

@FourSigma
Copy link
Contributor Author

@cbodonnell Happy Monday. Looks like we have some failures on validate-kots-pull. Since you are bit more familiar with this pathway, do you have some suggestions to get these test passing without too much refactoring?

the kots pull command also runs from the CLI before any resources are deployed, so the underlying failure reason is the same as what we saw for kots install. if we need to avoid refactoring, one possibility could be to log (maybe just at the debug level) and move on without attempting to add headers if the database call fails. this way it can still function if we do have a database context available, but will not if it's running from the CLI only. thoughts?

I would be okay for this approach esp. if it just limited to the reporting portion of KOTS.

@FourSigma FourSigma force-pushed the siva/sc-93559/wrong-data-in-field-customer-last-active branch 3 times, most recently from 1160566 to b1263f4 Compare December 18, 2023 22:42
@FourSigma
Copy link
Contributor Author

@cbodonnell Looks like there is a validate-gitops (kind, v1.28.0) failure. Do you have some additional context on this test?

@cbodonnell
Copy link
Contributor

@cbodonnell Looks like there is a validate-gitops (kind, v1.28.0) failure. Do you have some additional context on this test?

@FourSigma It looks like the testim branch was out-of-date since that test was added somewhat recently. I've merged in changes from the base branch and re-run the test.

@FourSigma FourSigma force-pushed the siva/sc-93559/wrong-data-in-field-customer-last-active branch from b1263f4 to b29c25b Compare December 19, 2023 18:57
@FourSigma
Copy link
Contributor Author

@cbodonnell Looks like we are now failing on the following tests:

build-test / validate-smoke-test (aks, 1.25, alpha) (pull_request)
build-test / validate-backup-and-restore (eks, 1.27, stable) (pull_request)

@cbodonnell cbodonnell merged commit 950a658 into main Dec 20, 2023
175 checks passed
@cbodonnell cbodonnell deleted the siva/sc-93559/wrong-data-in-field-customer-last-active branch December 20, 2023 13:40
@cbodonnell
Copy link
Contributor

@cbodonnell Looks like we are now failing on the following tests:

build-test / validate-smoke-test (aks, 1.25, alpha) (pull_request) build-test / validate-backup-and-restore (eks, 1.27, stable) (pull_request)

@FourSigma those both looked to be flaky failures since a re-run passed. Merged this one.

@FourSigma
Copy link
Contributor Author

@cbodonnell Looks like we are now failing on the following tests:
build-test / validate-smoke-test (aks, 1.25, alpha) (pull_request) build-test / validate-backup-and-restore (eks, 1.27, stable) (pull_request)

@FourSigma those both looked to be flaky failures since a re-run passed. Merged this one.

Thanks @cbodonnell!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type::feature New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants