2019-03-29

[limnh]

Where I left off yesterday:

• I changed the ubuntu version from 18.04 to 26.04 on barry's recommendation. I found the packer.json file for tfw-builder-image, but I kept getting various 400-level errors. I realized that the URL present in that file is out-of-date, went to the Ubuntu site, and found the correct URL. This resolved the errors I was seeing.
• Megan helped me diagnose an issue with my preseed.cfg file, as the original file did not have a step to set up an SSH daemon. This explained why I wasn't able to connect to the VM, and the process was actually failing on the SSH handshake.
• Megan and I paired over Slack to get her access to the remote server to get a closer look at the error.
  • She led me on getting a VNC client set up to see what's actually happening within the server instead of needing to guess what the problem is.
  • Turns out that the script was working as intended but was timing out on waiting for SSH to become available. With VNC, I was able to see that things were still installing up until the timeout, which led me to update the ssh_wait_timeout from 30m to 2h. 2h also proved to not be enough, so it's been bumped up to 24 hours. I'll reduce this time once I have a better understanding of how long the SSH handshake needs to complete.
• For some reason the build began failing for a code 255 due to an error with the post-processors portion of the Packer config file. The error was * Command, Inline, Script and Scripts options cannot all be empty. On megan's suggestion, I removed the awscli portion from the packer config file and put it back into shell.sh. This allowed me to get more insight into what the error actually was (formatting within the Packer config file).
• On the next run after moving the awscli portion to the shell script, I received an error stating that the ENV VARs being pass from Circle to the remote server were not working. This particular build errored out due to CIRCLE_BUILD_NUM not being present and thus not being able to uniquely name the file.

Issues/Questions:

1. Why aren't my environment variables working anymore?

2. The actual Packer image is named packer-qemu due to the default naming scheme of Packer, so how do I name things uniquely?

3. How to I pass in my AWS credentials securely without having them print to the console on Circle?

4. Should a new user be created in AWS (and thus a new key pair) specifically for this work?

Solutions:

1. I tried to find a different method of passing in environment variables, which led me to Circle's documentation on utilizing $BASH_ENV. I attempted to see if this would work but ran into issues with formatting (having the correct number of backslashes). I paired with Josh, and we went over the Circle config file and packer.json files. He gave some helpful tips on formatting and improving readability of my code. I was able to locate the error with the SSH command that's exporting the environment variables.

   • When adding the new code to pass these environment variables, I ran into the issue that * The job has no executor type specified. The job should have one of the following keys specified: "machine", "docker", "macos". I solved this by removing the job and adding the steps to the existing build_image job in Circle.

2. I looked through the Packer qemu documentation and found that the default naming scheme for images is packer-BUILDNAME, which explains why it was named packer-qemu. I want to name things uniquely, so I added vm_name to the packer.json file utilizing the environment variable $CIRCLE_BUILD_NUM.

   • I am currently running a version without the AWS key environment variables to verify whether or not the output is printed to Circle. I don't want my credentials just floating out there.

3. This issue was solved by solution 1, cleaning up the SSH command.

4. Yes, a new user should be created solely for this work. It will solely have access to the specific s3 bucket that the images are being sent to. I will update the key pair with a newly created set when this user's creation is completed.

[limnh]

The building of the actual image takes over an hour. I've been testing smaller pieces locally, but I feel confident and am running the process from creation to destruction.

[limnh]

There's some disconnect between how productive I feel and how much work others feel like I'm doing. In my 1:1 with andrew, concerns were brought up about my trajectory not being where it needs to be to make engineer 1 by my year-mark. I have taken feedback from my review and found actionable ways to improve, but that sentiment is not shared. I would like more insight into those specific concerns and help finding actionable ways to make improvements.

I feel like I've done pretty well with this project, but post 1:1 it feels like that may not be the case.