search

HodorNV / ALOps

ALOps
59 stars 24 forks source link

ALOps Extension API does not respect configured timeout setting #565

Closed kasperdj closed 2 years ago

kasperdj commented 2 years ago

Describe the bug The ALOps Extension API is not respecting the configured parameters for: "Check Delay (Sec)" and "Max tries for status check" if the API at some point return the "Exception in BCConnector.GetAPIData: The remote server return an error: (503) Server unavailble.

I know that this is due to Microsofts crappy API that very often return this error, but it also means that my release will fail and when I manually redeploy it afterwards, it will in 99% of all cases be sucessfully deployed.

So, please stabalize "ALOps Extension API" to respect the two setting "Check Delay (Sec)" and "Max tries for status check" (we typically have these configured for 10 minutes of patience...), even though we might encounter the "Exception in BCConnector.GetAPIData..." so that we do not need manual actions for something that typically would fix it self, if the system was more patient

Screenshots attached - contact me for details or let's discuss this in Antwerpen :-)

the used yaml please provide the yaml that you used. It helps you put the yaml like this: 

youryaml

the output Also the complete output is necessary for us to see what is going on. Also use backtics:

your output log

Expected behavior A clear and concise description of what you expected to happen.

Screenshots image image image

Additional context Add any other context about the problem here.

Arthurvdv commented 2 years ago

My experience at a that a higher ‘Check Delay’ value, like 30 seconds, increases the succes rate of the release pipeline for SaaS.

On my request the default values has been changed for this particular issue, see detailed information here: https://github.com/HodorNV/ALOps/issues/526

kasperdj commented 2 years ago

@Arthurvdv this will not resolve my issue and it fails/errors out below defined timeout

waldo1001 commented 2 years ago

We'll make sure we don't error out on a 503 (it's a fatal now, but it needs to be handled as just another "try").

For the rest it does respect the delay and the retries.. .

kasperdj commented 2 years ago

We'll make sure we don't error out on a 503 (it's a fatal now, but it needs to be handled as just another "try").

For the rest it does respect the delay and the retries.. .

Fantastic, great solution proposed :-)

AdminHodor commented 2 years ago

Please check our latest release v1.453 for this feature.

kasperdj commented 2 years ago

Thx. tested with 15 cloud deployments without any errors, good work!