Closed JeppeBylov closed 3 years ago
Dear @JeppeBylov ,
Look like ContainerHelper is trying to create a MultiTenant image looking at the logs:
2020-10-09T12:09:51.4586217Z Restoring CRONUS Demo Database
2020-10-09T12:10:07.2727977Z Exporting Application to CRONUS
2020-10-09T12:12:55.1471163Z Removing Application from tenant
Not sure why it's doing that, the default in ContainerHelper for creating Sandbox environments with Multitenant default was changed a couple of months ago, which seems to translate to the created images. My guess at the moment is you'll need to create containers from this Image also as Multi-Tenant. Starting a Multi-Tenant image as a regular one would explain the error, because the NST would be mounted on a database without the proper tables.
Pretty sure this is outside the scope of what ALOps can do, but we'll definitely give it a try and setup a replica on our servers to figure it out.
Kind regards,
And how would one do that? I can try ASAP, but I'm unsure of how to specify multi-tenant on the Docker Create step.
If you can specify multi-tenant: true, can you also specify multi-tenant: false - maybe that could work as well?
Dear @JeppeBylov ,
We where able to replica the behavior, the issue starts with BcContainerHelper "1.0.8" which was released yesterday. From that version the "New-BcImage" creates Sandbox images by-default in MultiTenant, it also manipulates the imagename supplied as a parameter.
BcContainerHelper v1.0.7
New-BCImage -artifactUrl "https://bcartifacts.azureedge.net/sandbox/17.0.17126.17504/dk"
=> Successfully tagged myimage:sandbox-17.0.17126.17504-dk
BcContainerHelper v1.0.8
New-BCImage -artifactUrl "https://bcartifacts.azureedge.net/sandbox/17.0.17126.17504/dk"
=> Successfully tagged myimage:sandbox-17.0.17126.17504-dk-mt
From our perspective, it does not make sense creating the image in MultiTenant by default (no way back). With a regular image you can still choose to create a Multi-Tenant container from it, it will do the Multi-Tenant setup on the fly, hence the image could be used for both cases.
We'll make changes to ALOps to counter this behavior, so you pipeline will work as before without any changes required from you side. Together with this we'll add additional parameters on the ALOpsDockerCreate task for when Multi-Tenant is explicity required and cope with the image-name manipulation.
ALOps v1.435 is scheduled for release this weekend, we'll make sure to get the enhancement for this included. Will keep you posted on this.
Kind regards,
We get the same errors - do you have any timeline when the new release will be out?
Dear @JeppeBylov , @dNsl9r ,
We just released v1.435.1856 which should tackle this issue. Please note it could take a couple of pipeline runs for DevOps to pickup the new version.
Kind regards,
Can confirm that the pipelines are running successfully once again, without making changes.
Thanks for very fast feedback! Appreciate all the help..
Describe the bug I have a very simple pipeline creating a container, publishing one app and removing the container again. This morning the pipeline started to fail with the error:
This means that the ALOpsLicenseImport step fails with:
the used yaml please provide the yaml that you used. It helps you put the yaml like this:
the output Also the complete output is necessary for us to see what is going on. Also use backtics:
Expected behavior Hopefully the container would be created successfully has it has been in the past.