Tommy's Feedback

[wojtczat]

Why Use Kubernetes Services in the Cloud

• [x] "Using cloud allows you to more easily scale your microservices and serve them in a high-availability setup." sounds mildly awkward

  What You'll Learn

• [x] "You will use helm to deploy these..." If you capitalize Kubernetes and Minikube and other technologies I would also capitalize Helm just like you are later in this sentence unless you are referring to a command
• [x] "then deploys and manages them as releases to your cluster" I would use in your cluster

  Creating a Kubernetes Cluster on IBM Cloud

• [x] "To create a Kubernetes cluster you need appropriate permission." comma needed after cluster

  Installing the Command Line Tools...

• [x] "After the script is finished running, login to IBM Cloud" login should be replaced with "log in" as you are using it as a verb.

  Provisioning a Cluster

• [x] Perhaps provide a time estimate in this section since provisioning the cluster is the time consuming part of the guide. Stating that the guide takes 4 hours when you really mean it takes 4 hours to provision the cluster is disingenuous. My cluster took ~27 minutes.

  Deploying Microservices...

  Building and containerizing...

• [ ] "The package goal automatically starts the dockerfile-maven:build goal. It runs during the package phase." Is this redundant?

  Pushing the Images to docker registry

• [x] docker tag system:1.0-SNAPSHOT us-south.icr.io/[your-namespace]/system:1.0-SNAPSHOT --> docker tag system:1.0-SNAPSHOT us.icr.io/[your-namespace]/system:1.0-SNAPSHOT same thing for inventory
• [x] docker push us-south.icr.io/[your-namespace]/system:1.0-SNAPSHOT --> docker push us.icr.io/[your-namespace]/system:1.0-SNAPSHOT same thing for inventory

  deploying the microservices

• [x] --set image.repository=us-south.icr.io/[your-namespace]/system \ --> --set image.repository=us.icr.io/[your-namespace]/system \ same thing for inventory
• [x] should the Parameters column in the table have back ticks?

  Finding the microservice's ip address and ports

• [x] output for finding public IP has poor formatting for each headers.

  Making requests to the microservices

• [x] One of the images would receive an unauthorized 401 error resulting in an ErrImgPull on the pod of the service that is failing. This can happen on either service but is fixed by running kubectl run [some name] --image=us.icr.io/[namespace]/[image]

  Testing Microservices that are running on IBM Cloud

• [x] should the properties table be back ticked?

  Deploying a new version of system microservice

• [x] docker tag system:2.0-SNAPSHOT us-south.icr.io/[your-namespace]/system:2.0-SNAPSHOT --> docker tag system:2.0-SNAPSHOT us.icr.io/[your-namespace]/system:2.0-SNAPSHOT
• [x] docker push us-south.icr.io/[your-namespace]/system:2.0-SNAPSHOT --> docker push us.icr.io/[your-namespace]/system:2.0-SNAPSHOT
• [x] --set image.repository=us-south.icr.io/[your-namespace]/system \ --> --set image.repository=us.icr.io/[your-namespace]/system \
• [ ] The snippet after kubectl get pods might not be accurate given newly discovered issue. Mine looks like this with the fix

  inventory-app-ibm-open-l-6bc9f668f6-knr2k   1/1     Running   0          40m
  system-669cb88bf5-d4t46                     1/1     Running   0          30m
  system-app-ibm-open-libe-77dc997cc8-hx2jl   1/1     Running   0          8m8s
  system2-64555bb9d4-vqt5w                    1/1     Running   0          34s

• [ ] Describing pod still shows Error: ImagePullBackOff

  Deploying to IBM Cloud Private

• [x] "those who must run their services running on infrastructure that is controlled by them." is a little awkward
• [ ] "a private cloud still provides benefit to developers so they don’t need to think about infrastructure" probably needs to be "a benefit" and comma after developers
• [ ] "developers can request what they need and" probably comma after "need" imo

  Where to next

• [x] This section is empty not sure if it should have another guide linked

  Tags

• [x] Guide should have tags for Kubernetes, Docker, and possibly Helm?

Besides that the guide was fine. There was one issue that took a while to resolve so it would be difficult to estimate a proper length, but I would guess that it shouldn't take longer than an hour if the cluster provisioned as quickly as mine. Everything else worked as expected.

[andrewdes]

@wojtczat I opened a PR addressing these issues here: #23.

The package goal automatically starts the dockerfile-maven:build goal. It runs during the package phase." Is this redundant?

I do not think so because it is simply saying that the package goal is going to trigger the dockerfile-maven:build goal. This goal will then be run during the package phase. Since the package goal and phase are two separate things, I don't think it is redundant.

One of the images would receive an unauthorized 401 error resulting in an ErrImgPull on the pod of the service that is failing. This can happen on either service but is fixed by running kubectl run [some name] --image=us.icr.io/[namespace]/[image]

The OL helm charts create their own service account on kubernetes (instead of using the default), so the pods didn't actually have access to the secret containing the docker credentials so it was unable to pull from the private repository. This is fixed by adding the --set image.pullSecret=default-us-icr-io flag during the helm commands.

[andrewdes]

@wojtczat all the feedback has been addressed and merged in #23, can I close this issue?