lab machines get provisioned with names like lab6... but the instructions use 0-prefixed numbers like lab06 had to debug this a few times during today's session

If the proxy instance already exists, you get

Error: Error creating instance: googleapi: Error 409: The resource 'projects/**********/zones/us-central1-b/instances/kots-field-labs-squid-proxy' already exists, alreadyExists
│ 
│   on main.tf line 67, in resource "google_compute_instance" "shared_squid_proxy":
│   67: resource "google_compute_instance" "shared_squid_proxy" {
│ 
╵
make[1]: *** [apply] Error 1
make: *** [instances] Error 2

This makes that if 2 users provision instances at the same time (for example 2 training sessions in parallel), we kinda hit this error.

Using make, it would be great to be able to destroy the terraform instances of a single user.
So instead of make tfdestroy (which removes all instances), we could use make tfdestroy [some_user].

Add CI to the repo for the go and terraform pieces. Including some initial automated tests for both.

When working through lab02-adding-analysers, I expected (as per the instructions) to find no errors after generating a support bundle. That’s not the case with my deployed lab environment. I get the following

This is most likely a case of newer analysers having been added that caught errors in the cluster lab setup.

From astorms: When you run the "save_lab_setup" the command just returns you to the normal shell prompt. It should provide the user some positive feedback that it worked. Such as "your lab environment has been successfully saved."

You have a duplicate word your on the line below. I think you meant to say on:

You can open the KOTS admin console your your node by navigating to https://$IP_ADDRESS:8800 in a browser. The password to your instance will be provided as part of the lab, or you can reset by SSHing the node and running

SE-Steve P Potter:: In lab 6: The example "HTTP_PROXY" is also syntactically incorrect (never mind it is an HTTPS call) because curl requires the http_proxy env variable to be lower case.

Right now the automation creates versions that don't look like version numbers. I think versions should look like version numbers, ideally semver.

https://github.com/replicatedhq/kots-field-labs/blob/main/instruqt/distributing-with-replicated/03-creating-a-release/assignment.md#creating-your-release

Noticed when going through the lab it makes mention of (it will be 2 if you haven't explored releasing a bit more)., whereas for a first time user of the lab that is just following the steps verbatim, there's only a single release at that point...

Do we want to add an extra comment, something like "having 1 release is fine", to ensure a first time user doesn't think they've missed a step somewhere?

Explain the Issue or Feedback

The lab introduces preflights by having the user build cpu and memory analyzers; one of which is expected to fail. But the language in the assignment switches focus to storage when there are no storage analyzers in what we've written.

Reproduction Steps (if applicable)

This seems like a sentence that seems unfinished?

I can't find the pod logs for the nginx pod in lab 2. The picture shows a dropdown which should include logs for the init containers, but I do not see those.

Explain the Issue or Feedback

The GUI-based manifest editor is very nice (didn't know that Instruqt could do that) but for some that might like to edit from the shell, would be nice to have vim installed as part of the environment. It looks like we don't have sudo installed so I wasn't able to use the package manager to do it myself.

Reproduction Steps (if applicable)

Proposed Solution

install some utilities or give the user access to sudo to DIY

In the "Moving Assets Into Place" step, under "Copying the Airgap Bundle to the Air-Gapped Host", the direction for copying the kURL bundle says

Let's copy the kURL bundle first. Take a look at the files in your current directory. There should be one (the name of your kURL bundle will be different, but it will include replicated-labs-com and end in -unstable.tar.gz).

The file in my directory does not contain replicated-labs-com: installing-in-an-air-gapped-environment-<my id>-unstable.tar.gz

This is a bit meta, but should we add to each of the labs instructions on how to come here to the github repo and add their own issues? I'd think we want to make it easy for participants to help us find errors and improve....

If we highlight the actual buttons they need to click on/the assets they need to download it removes doubt from anyone

When it states to create the License, it says to point it to the 'CustomFields' channel which is what we were going to use prior to using the Stable channel. Need to update the instructions to tell the user to use the Stable channel

Running through the labs, I've found the local users .kube folder is left with owner and group of root. While kubectl commands still return they aren't able to access their cache in .kube/cache due to the permissions causing slow responses and errors.

Reproduction Steps
Run through lab01 and install the provided cluster.

Check the .kube folder of the user that ran the command it will be owned by root. Try executing a command that benefits from cache kubectl get all -n default and you should see timeouts before the command eventually returns.

Chown the folder back to your user, repeat the command and everything should be fine.

I've fixed this on at least one other lab as well but unfortunately don't recall which one. Is was before lab05, but I filed a kURL bug thinking that was the cause. I have now confirmed kURL doesn't cause this it must be something about the lab setup process that's causing it.

That tiny save icon is easy to miss and someone just reading the instructions may easily not think about saving the change to the file

This lab currently does not support windows workstations, only mac or linux are supported.

From astorms: After the Hello World application is installed, the UI shows its called "App Name" and should likely show "Hello World" instead.

Skipped CI/CD in order to get the lab up and running. Need to add a Github action to build the image

After making a release and redeploying the latest version of the wordpress application, it was not obvious how to edit the application values. I figured it out eventually but having a screenshot or two to show learners how to do this would be helpful.

The opening screen for Challenge one takes 4 minutes to load. If we are asking folks to not multi task during labs, they can not stare at a blank screen for 4 minutes.

We should add the slides & description of the actual Assignment (Airgap Workflow) to this screen

And then make "assignment 2" the actual Assignment.

There are some folks that will stop at this prompt and wonder what is the right answer. Again, about making things super clear and removing doubt.

From storms: During the Hello World setup from the Instruqt track, the user is instructed to click "Open External Window". This opens a new browser window, which will be something like "http://kubernetes-vm.1z7qu0r9yl4m.instruqt.io:8800/secure-console".

Because this is not SSL, the browser halts the user from progressing. In Chrome, the user sees:

"The connection to kubernetes-vm.1z7qu0r9yl4m.instruqt.io is not secure

You are seeing this warning because this site does not support HTTPS. Learn more"

I may be the exception, as I have the Chrome option enabled to only use SSL. (BTW, this is slated to be the default setting in the future). Furthermore, many people run the EFF HTTPS Everywhere plugin which also enforces SSL on all the things. Plus, in general, it's a best practice to have SSL on all the things.

@kayleemchugh found a couple of typos in the Helm lab

An improvement to either the docs or the deployment code will be required. At the moment the HTTP server host is documented as being ${REPLICATED_APP}-kots-field-labs-squid-proxy:3128 which will resolve to int20220906-evans-kots-field-labs-squid-proxy:3128 in my case which was not reachable. NOTE that the hostname has my first name in it.

evans@int20220906-evans-lab06-proxy:~$ ping int20220906-evans-kots-field-labs-squid-proxy
ping: int20220906-evans-kots-field-labs-squid-proxy: Temporary failure in name resolution
evans@int20220906-evans-lab06-proxy:~$

The correct proxy hostname in this case was meant to be int20220906-kots-field-labs-squid-proxy. Notice that my first name is not in the hostname.

evans@int20220906-evans-lab06-proxy:~$ nc -v int20220906-kots-field-labs-squid-proxy 3128
Connection to int20220906-kots-field-labs-squid-proxy 3128 port [tcp/*] succeeded!

Until https://app.shortcut.com/replicated/story/47418/add-additional-guidance-to-support-requests-if-a-bundle-is-not-included is completed you can't confirm on Lab09 that you've correctly completed the exercise because the links don't work.

We can work around this two ways that I'm aware of.

1. When you add the new service remove the original link or never have it to start with. The link will work if there is only 1 link defined but fails if there are 2 or more.
2. Tell people how to manually change the url to point to http://<externalIP>:5000 and warn them that the link is not currently working.

If we did the 2nd one we would just remove the warning when the bug is fixed. If you did the 1st we would simply avoid the bug and not need any further updates.

There appear to be numerous (at least 8) broken image links in the README. They all appear to be sourced from GitHub's CDN.

The console reports these as type text/plain but the Accept request header is set to image types.

• Remove branch protection from current main. Needed?
• Rename main into heritage
• Rename instruqt into main --> this is breaking till the lambda/zap is updated
• Update lambda/zap to point to main and not Instruqt
• Test Hello World Track
• Add branch protection to main and make it the default (again?)
• Update all GH workflows so they point to main where needed
• Remove terraform from main branch
• Update Readme.md with new Instruqt instructions on how to get access, and maybe give an overview which tracks are available
• Cleanup vendor portal: Remove all accounts that are not in use anymore
• Cleanup vendor portal: Remove all rbac policies that are not in use anymore
• Cleanup vendor portal: Remove all apps that are using the heritage setup
• Update CONTRIBUTING.md with instructions on how to do a dev track

Shell container image needs CI/CD to stay up-to-date. In the rush to get to Instruqt I took on the debt of leaving it until later.

Explain the Issue or Feedback

Followed instructions to create harbor preflights file, but the check script fails validation:

replicant@shell:~$ kubectl preflight ./harbor-preflights.yaml
replicant@shell:~$ ls
empty-preflight-secret.yaml  empty-preflights.yaml  harbor  harbor-preflights.yaml  release
replicant@shell:~$ cd
replicant@shell:~$ mkdir harbor/templates/troubleshoot
replicant@shell:~$ helm template harbor | kubectl preflight - 
replicant@shell:~$ helm package harbor --destination ./release/
Successfully packaged chart and saved it to: release/harbor-16.8.0.tgz
replicant@shell:~$ cd harbor/templates/troubleshoot/
replicant@shell:~/harbor/templates/troubleshoot$ ls
preflights.yaml
replicant@shell:~/harbor/templates/troubleshoot$ cp preflights.yaml preflight.yaml  
replicant@shell:~/harbor/templates/troubleshoot$ ls
preflight.yaml  preflights.yaml
replicant@shell:~/harbor/templates/troubleshoot$ 

Feedback from Mark P:

Running through the CLI lesson now.

• Small note: Verifying manifests shows a different list of files than my shell does.
• Typo: updatea
• It says “To simplify for the lab, we’re going to copy in a file where we’ve already made the changes”, but then you use yq to modify a file, not copy a file.
• I love that we’re having you run the linter and fix it before pushing a release!
• You say “Make sure to change the version number (in my case, I’ll go from 0.0.1 to 0.0.2).“, but then the example actually uses [NEW VERSION] . Why not just put 0.0.2 in the command to be copied? None of the other labs change version numbers, so you happen to be safe here.
• It’s unclear what the relationship between 0.0.2 in the Unstable channel and the replicated-cli channel is, if any. Presumably it should also be 0.0.2, but you leave it unspecified.
• It’s unclear why the variables get lost in step 3. You say it’s a different shell from other challenges, but this is the same challenge, just different step in the challenge, right?
• All of the code blocks seem to have extra newlines.
• In run your install, I went ahead and run the commands right away before reading that we weren’t supposed to install Kots, nor do the install with that command.
• The use of kuard and the Kuard tab is confusing, since that’s the first time that word has been mentioned. Is it the name of the app?
• Side note, but you’re having them install the app fully from the CLI “to fill in the values that your customer would typically enter into the admin console”, but it’s unclear why. Perhaps just because you want to show an all CLI challenge, but unattended CLI installs seems to be someone uncommon, and certainly unrelated to a vendor using the CLI to lint and release. Valuable, but different. For that matter, if you’re going to do that, may as well include the skip port forwarding so it doesn’t message about localhost.
• Going to the Kuard link is … disturbing. Shows a big warning. It’s not obvious that this is actually success. (I had never seen this app before.)

https://github.com/replicatedhq/kots-field-labs/tree/main/labs/lab02-adding-analyzers#the-issue

Student working on lab2 notices that without some foreknowledge about how KOTS reports on pods/containers, it's very hard to know that you should be looking at this file cluster-resources/pods/default.json

One attendee ran out of time on the lab during the Replicon session

When working through Lab002 the application that is deployed does not match what's in the git repo. The point of the lab is to build a collector and the deployed application already has the collector deployed. This both gives away the answer and is very confusing for people who don't understand what they are suppose to do (b/c it's already there).

Just doing a new release and an upgrade of what's in the lab folders solves the problem so this has something to do with how the labs are being setup.

The CLI lab should use the same pattern as airgap to keep the shell open between challenges.

During Checkmarx training someone was logged out of Vendor Portal but did not have the credentials to log in. This happened during the Preflights lab