You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
The crc-cloud could be running with the local deployment, due there is no need to use the crc-cloud binary to spawn an instance for example on OpenStack cloud.
Let's assume, that someone would like to use the crc-cloud in theirs own cloud in the CI. In current version, the script
requires cloud credentials (for OpenStack) and it will:
create a container,
it will download a crcbundle with specified version,
it will create an instance by using extracted qcow2 image which needs to be uploaded (did not check if many times or just once),
it will deploy the CRC cluster,
on the end it will make steps to estabilish cluster
If someone is using the script for the CI, the step that the script is controlling or spawning instance is not needed.
The image can be provided by the cloud operator and what would be needed by the crc-cloud container is just simply:
CI is spawning an instance from the extracted qcow2 image,
create a podman container on the CRC node,
inside the new container it will start the OpenShift cluster (for example: crc-cloud --local)
on the end, CI will take care about the state of that VM
With that way, nobody needs to make many workarounds or take care for some leftovers after the CI will pass or fail.
@praveenkumar script works, with few workarounds that I did not port to the script.
In other words, if someone just want to use clustersetup.sh script, it will fail.
Hi,
The crc-cloud could be running with the local deployment, due there is no need to use the crc-cloud binary to spawn an instance for example on OpenStack cloud.
Let's assume, that someone would like to use the crc-cloud in theirs own cloud in the CI. In current version, the script
requires cloud credentials (for OpenStack) and it will:
If someone is using the script for the CI, the step that the script is controlling or spawning instance is not needed.
The image can be provided by the cloud operator and what would be needed by the crc-cloud container is just simply:
crc-cloud --local
)With that way, nobody needs to make many workarounds or take care for some leftovers after the CI will pass or fail.
NOTE: I created that issue, because the https://github.com/crc-org/crc-cloud/blob/main/pkg/bundle/setup/clustersetup.sh script does not deploy the instance properly (or maybe I'm wrong).
The text was updated successfully, but these errors were encountered: