-
Notifications
You must be signed in to change notification settings - Fork 42
Recent updates to recipes break the build on Centos 7 #26
Comments
I have an update on this issue. I hit this error while building images over and over, the first build worked, and the other builds failed with platform error. For the moment, I bypassed the unknown platform of "$PLATFORM" error, by removing the if statements about redhat and suse in the Dockerfile, and adding at the top of the copy statements, where my post_deploy_redhat.sh has |
What command arguments are you providing to build.sh? |
@Collinux , this happened out of the box with the default command and default Dockerfile and "auth-demo". Then it happened again, once I used "auth-demo ide-jupyter-python3" in combination with adding extra steps, like installing R to the Dockerfile. |
I hit this same problem in any OS I try to use, centOS, openSUSE and Ubuntu. Is there any workaround? |
HI, I just pulled down the latest code from the master branch and at the moment I cannot recreate this. I will give pulling the zip down and see if that is the cause.
|
I tried with the zip file and was not able to recreate this either
As for the initial report, I am not sure how PLATFORM is not getting set. We set the ARG and ENV, https://github.com/sassoftware/sas-container-recipes/blob/master/util/programming-only-single/Dockerfile#L28, so it should be coming through and not complaining about it not being set. We have seen in the past where older versions of Docker did not work with the BUILD_ARGs and so values would not get passed in. I will try to go back to the June 11 version of the code and see if I can recreate the original issue. |
Some help from here. Gonna forward the log
And the build Log
|
@pinduzera, thanks. It looks like maybe something is different with the orchestration package or that I overlooked something. I will clean up my system to make sure I am getting the correct -orchestration version and will try again. It is this call that appears to be failing for you:
|
@pinduzera , can you try running the following and confirm that it works:
Then inside the container
|
This is the output:
|
Well, good that we can replicate on a smaller set of actions. What do you get for version of sas-orchestration
Also, lets make sure we are dealing with the same base image:
|
Didn't mean to close this...mouse took over when I wasn't looking. |
Doesn't seem find it inside the container neither outside of it:
About the image, it looks the same.
|
It has to be in the container. The instructions I gave will get you into the container and once you leave it will kill it and remove it. So if you run the container again you will need to re run the following commands
To make it a daemon change the docker run command to
then exec into it
when done just run |
Rebuilt everything and got the exact same error. Looks like the orchestration is not running, or not being properly installed somewhere. |
I talked with the guys that run the orchestration and they indicated that based on where the error is happening it maybe be an issue with the entitlements. You may want to reach out to SAS Tech Support to see if we can make sure there are no issues there. If you have the docker container still running, you should be able to exec and navigate into the /tmp/ghissue26 directory and see that sas-orchestration is installed. From there if you can run the version option, just so we can confirm that we are both running the same one, that would be helpful in eliminating the options. |
Bingo, made it work. Just needed the "./", sorry for the rookie mistake
|
I came back to this after a while, now I even got myself a RHEL and still have the same broken problem. |
@Juan4SAS can you share the util/programming-only-single/Dockerfile Indeed I wonder if you edited this file Thanks ! |
@frayos , I edited this file exactly as you suggested in #54 the build command is also as I shared, except I changed the mirror from localhost to the IP:
Thank you! |
Can you try to add to this command : Let me know if this helps ! |
Thank you @frayos . Unfortunately I have got the same response. It was worth the try according to the message. I tried and failed :) |
@Juan4SAS Can you replace and let me know if this helps ? |
Thank you @frayos , I will give it a try and let you know. Do you know why the $PLATFORM variable is returning an empty string/array? That should not be the case, correct? |
@frayos , unfortunately that made no difference. Exactly the same error. |
@frayos I think I identified the culprit.
So I have run one for my local repo and one towards the SAS repo, to ensure my repo is OK: LOCAL SAS Both gave me similar results: and In my local repo in the SAS repo: Any ideas? Edited - |
Any chance this might be related to a bad order / shipping week number? |
Juan thanks ! This issue is usually caused by a bad Orchestration CLI (not in sync with Order) Please confirm the version of sas-orchestration and where you downloaded it from |
Thanks for your reply Younes. Yes, I am aware, but in this case the logic does not make sense :) Let em explain. According to the documentation: you get your SAS_Viya_deployment_data.zip, you download the current version from the SAS Orchestration CLI download site and you are all set, correct? So, no, for this output I assumed nothing and downloaded the latest version of the orchestration tool. The version is 1.2.44, running it outside from any container. |
You need a CLI in 3.5, Let me know |
You do have a point, I downloaded indeed Shame on me :) Did not notice the version in the URL. I will test and keep you posted |
And there you go. Perhaps my local repo is wrong. While the orchestration tool ended successfully for ses.sas.download, when queriyng my local repo gives me this: Younes, should we move this question to a SAS TS track? I assume this is supported by SAS Technical Support? And does not seem to be linked (at this point) to the recipes. |
So, all in all, it seems to me the PLATFORM issue comes from a bad parameter / mirror configuration. Once resolved those 2, it works just fine. |
Describe the bug
Doing auth-demo build on current sas-container-recipes zip (Downloading, not cloned) does not work. Older versions work as they used to.
Error No2: Unknown Platform, encountered when using SAS repos for the build
Snippet of the logs:
2019/06/11 16:29:36 Finished pulling base container image 'centos:7'
2019/06/11 16:29:36 Skipping adding file to single-programming-only Docker context: addons/auth-demo/Dockerfile
2019/06/11 16:29:36 Skipping adding file to single-programming-only Docker context: addons/auth-demo/addon_config.yml
2019/06/11 16:29:36 Starting 1 build process ... (this may take several minutes)
2019/06/11 16:29:36 [TIP] System resource utilization can be seen by using the
docker stats
command.2019/06/11 16:29:36 Starting Docker build: sas-viya-single-programming-only:19.05.0-20190611112921-no-git-sha ...
2019/06/11 16:33:16 single-programming-only: container build [ERROR] single-programming-only: map[code:6 message:The command '/bin/sh -c set -e; if [ "$PLATFORM" = "redhat" ]; then rpm --rebuilddb; curl --silent --output ${TINI_RPM_NAME} --location ${TINI_URL}/${TINI_RPM_NAME}; yum install --assumeyes ${TINI_RPM_NAME}; rm --verbose ${TINI_RPM_NAME}; yum clean all; rm --verbose --recursive --force /root/.cache /var/cache/yum; elif [ "$PLATFORM" = "suse" ]; then zypper install -y curl ; curl --silent --output ${TINI_RPM_NAME} --location ${TINI_URL}/${TINI_RPM_NAME}; rpm -i ${TINI_RPM_NAME}; rm --verbose ${TINI_RPM_NAME}; zypper clean ; rm --verbose --recursive --force /var/cache/zypp; else echo; echo "####### [ERROR] : Unknown platform of "$PLATFORM" passed in"; echo; exit 1; fi' returned a non-zero code: 6]
Error No.1: Unknown error here - encountered when trying to use our mirror-url (it's possible the mirror url is not setup correctly - we did see a TLS warning on our mirror url)
2019/06/11 16:10:51 [TIP] System resource utilization can be seen by using the
docker stats
command.2019/06/11 16:10:51 Starting Docker build: sas-viya-single-programming-only:19.05.0-20190611111036-no-git-sha ...
2019/06/11 16:15:33 single-programming-only: container build [ERROR] single-programming-only: map[code:1 message:The command '/bin/sh -c set -e; echo; echo "####### Run the Ansible playbook to create the main layer"; echo; if [ "$PLATFORM" = "redhat" ]; then rpm --rebuilddb; echo; echo "####### Add the packages to support running the Ansible playbook"; echo; yum install --assumeyes https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm ; yum install --assumeyes python-setuptools python-devel openssl-devel; yum install --assumeyes python-pip gcc wget tree automake python-six; pip install --upgrade pip setuptools; pip install ansible==${ANSIBLE_VERSION}; yum install --assumeyes python iproute openssh-clients initscripts sudo; elif [ "$PLATFORM" = "suse" ]; then zypper --non-interactive install -y python-setuptools python-pyOpenSSL python-devel; zypper --non-interactive install -y openssh sudo; easy_install pip; zypper remove -y python-cryptography ; pip install ansible==${ANSIBLE_VERSION}; fi;' returned a non-zero code: 1]
Debugging: builds/single-2019-06-11-16-10-40/sas-viya-single-programming-only/log.txt
exit status 1
To Reproduce
Run a build with today's (06/11/19) recipes folder. I have older zips on a different machine and I tried those and auth-demo built in just over an hour.
Expected behavior
The build should proceed for about an hour, but instead fails after just few minutes.
Environment (please complete the applicable information):
uname -r
3.10.0-957.12.2.el7.x86_64
docker --version
Docker version 18.09.6, build 481bc77156
The text was updated successfully, but these errors were encountered: