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

Importer pre-flight checks #98

Open
ctron opened this issue Jul 5, 2024 · 6 comments
Open

Importer pre-flight checks #98

ctron opened this issue Jul 5, 2024 · 6 comments

Comments

@ctron
Copy link
Contributor

ctron commented Jul 5, 2024

This is something for the future, just adding the thought here to not forget about it.

When creating or editing an importer in the UI, it would be cool to have some "pre-flight" checks, to see if the source and settings are valid. I could imagine some backend endpoint, which does a quick check (depending on the source), and returning some quick to discover metadata.

@gildub
Copy link
Contributor

gildub commented Jul 5, 2024

@ctron,

From experience, the UI will proved a better experience if the back-end could support any type of checks and handle that though importers states.
That would mean creating an importer "asynchronously" by adding its source along the related settings, then the back-end to validate the importer once created.
An importer would go from "Created" to "Ready" then it could be "Enabled/Disabled".
What do you think ?

@ctron
Copy link
Contributor Author

ctron commented Jul 5, 2024

I think that such a pre-flight check should ensure that we're not creating anything unless we know it works. Adding such a record and a state machine would make it quite complex. A simple call to a "check" endpoint, which does some quick checks and then returns a result, with some helpful message, might be a less invasive option.

@gildub
Copy link
Contributor

gildub commented Jul 5, 2024

What type of checks do you think about ?

We can and should validate the URL of a source is valid.

Beyond that experience (Konveyor/tackle2-ui) has shown it's better to handle definitions related to cronjobs on the back-end. For example, at creation time a source might work but it might fail later on, the back-end takes care of checking the source anyway and updates the status of the importer. The UI only has to reflect the state of an importer and not handle its logic.

@ctron
Copy link
Contributor Author

ctron commented Jul 5, 2024

Well for CSAF we could try to detect the provider metadata. That's a quick check, and if that doesn't work, then most likely something is wrong and creating a new importer doesn't make sense.

Sure it can fail in the future too, and that is already being handled, but instead of letting the user run into such a problem, I think it would be helpful to detect some easy-to-detect errors right upfront.

@gildub
Copy link
Contributor

gildub commented Jul 5, 2024

No doubt informing the user as soon as possible makes a better experience.
If the back-end already handles those checks then how can the UI rely on it ?

@ctron
Copy link
Contributor Author

ctron commented Jul 5, 2024

Today it doesn't. That's why I added this tracking issue as a reminder for the future.

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