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

provide component provision status endpoint #678

Open
stitakis opened this issue Mar 9, 2021 · 3 comments
Open

provide component provision status endpoint #678

stitakis opened this issue Mar 9, 2021 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@stitakis
Copy link
Member

stitakis commented Mar 9, 2021

Currently when an component is being provisioned if no error happens a successful response is sent back to the client (front end or endpoint consumer).

However this successful answer just means that the provisioning app was able to process the request and triggered successfully the corresponding jenkins pipeline.

The whole provisioning process is asynchronous. The provisioning app just place a task in jenkins.

Endpoint consumers miss in this way to get the end result of the quickstarter jenkins pipeline.

To allow further orchestration of provisioning processes in a corporate environment a new endpoint is needed.

In this context, the provisioning app also need to provide an endpoint that could be used to return the status of the quickstarter jenkinsline.

A solution for this is to use the current provision app connection to openshift and query the result of the corresponding triggered pipeline.

@stitakis stitakis added the enhancement New feature or request label Mar 9, 2021
@stitakis stitakis self-assigned this Mar 9, 2021
@stitakis
Copy link
Member Author

stitakis commented Mar 9, 2021

@metmajer @michaelsauter this enhancement needs to be implemented to satisfy the corporate needs

@michaelsauter
Copy link
Member

Agree that this is a long-standing pain point.

An alternative to querying the pipeline would be to call an prov app endpoint from the pipeline when it is done. However, I think querying (as you suggest) is the better way because that should be more reliable in the face of errors.

That said, it tightens the prov app <-> OpenShift connection further, which has been introduced a bit ad-hoc and clear responsibilities have not been assigned yet. It would be good to further think about and clarify the role the prov app should play when it comes to OpenShift. Do you have something in mind where the boundaries should be?

@stitakis
Copy link
Member Author

moved to ODS 4.1.0

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

No branches or pull requests

2 participants