Update set-up-a-local-knative-environment-with-kind.md

[xtaje]

Fix borked instructions to latest (Updated kind install, apiVersion string, kourier.yaml instructions)

Fixes #4880

Proposed Changes

• Updates kind install version
• Updates version string for compatibility with kind CLI
• Update for changes to kourier yaml
• Update output of hello service

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

For more information, open the CLA check for this pull request.

[netlify]

✅ Deploy Preview for knative ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	3bf6f34
🔍 Latest deploy log	https://app.netlify.com/sites/knative/deploys/626b1a357764fa00099a3291
😎 Deploy Preview	https://deploy-preview-4945--knative.netlify.app/blog/articles/set-up-a-local-knative-environment-with-kind
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site settings.

[knative-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: xtaje
To complete the pull request process, please assign macruzbar after the PR has been reviewed.
You can assign the PR to them by writing /assign @macruzbar in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• blog/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[knative-prow]

Hi @xtaje. Thanks for your PR.

I'm waiting for a knative member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[psschwei]

/ok-to-test

[psschwei]

@csantanapr Since we have the quickstart plugin, do we still want to maintain this blog post?

[xtaje]

@csantanapr Since we have the quickstart plugin, do we still want to maintain this blog post?

I found it to be useful in getting a kind instance working with locally loaded images. That could be helpful since it will be a common use case for a lot of people.

[csantanapr]

@xtaje I would preferred folks to use Knative kn quickstart is there something we can add to the plugin that we can retire the blog?

[csantanapr]

Re-reading the blog the “kn quickstart kind” does the same setup with kind and kourier

[xtaje]

@xtaje I would preferred folks to use Knative kn quickstart is there something we can add to the plugin that we can retire the blog?

If you replaced this blog with one on how to setup locally loaded images or local registries with kind or minikube, I think that would be good. I don't think there's an easy way to make that a kn quickstart command though.

[csantanapr]

@xtaje can you elaborate what you mean by local images?

This blog post doesn't mention or teach the user about the kind command to load images it just teach the user on how to install knative on kind the cluster.

The kn quickstart does the same that this blog does

Are you referring to the kind node image already preloaded you can use the flag in kn quickstart

You are talking about loading images with kind command you can do that even with ko and kind.local

Setting up a docker registry with locally with cover and use by kind cluster you can also do and this blog doesn't teach you how but we can add docs to kn quickstart.

I just want to get better understand what this blog says that we can't get with kn quickstart kind even if we don't do it for minikube

[csantanapr]

Kn quickstart can even work with an existing kind cluster that you setup with your specific config and just installs knative

[xtaje]

I just want to get better understand what this blog says that we can't get with kn quickstart kind even if we don't do it for minikube

Disabling the tag to digest resolution is not obvious, and is necessary to make a locally loaded image work with a kn service. This is going to be a very common thing to do for people who are trying to learn knative, and I don't believe it's safe to assume that they'll all be familiar with kind already.

It also doesn't seem appropriate to build the registries-skipping-tag-resolution into the quickstart either.

I've almost got a separate blog post ready that demonstrates how to do it using the cluster created by kn quickstart and can replace this PR with that one.

[csantanapr]

Great feedback

Did you know that there is no need to disable tag resolution if you use the container image location server kind.local or dev.local?

This was my thinking to document or blog that tell folks about doing a rocker build like “docker build -t kind.local/myapp .” then do a a “kind load docker-image kind.local/myapp”

They deploy Knative service no need to disable tag resolution.
“kn service create myapp --image kind.local/myapp”

[xtaje]

Great feedback

Did you know that there is no need to disable tag resolution if you use the container image location server kind.local or dev.local?

This was my thinking to document or blog that tell folks about doing a rocker build like “docker build -t kind.local/myapp .” then do a a “kind load docker-image kind.local/myapp”

They deploy Knative service no need to disable tag resolution. “kn service create myapp --image kind.local/myapp”

I've put in a PR for a tutorial: #4948. I probably should add a section about kind.local.

I think there's benefit to demonstrating the tag resolution, because the question people will immediately have is, "How do I try this without re-naming all my images?". Or they may have some kind of CI process where changing all the image names is a big hassle.

[xtaje]

Great feedback

Did you know that there is no need to disable tag resolution if you use the container image location server kind.local or dev.local?
...

They deploy Knative service no need to disable tag resolution. “kn service create myapp --image kind.local/myapp”

I'm finding that this still gets stuck waiting for a Revision to become ready because:

• it still gets stuck in the tag-to-digest resolution stage
• there's currently no way to specify the imagePullPolicy with kn (There may have been a commit that adds this, but am not sure where it is.)

[psschwei]

* there's currently no way to specify the imagePullPolicy with kn (There may have been a commit that adds this, but am not sure where it is.)

Client v1.4 has support for pull policy

[xtaje]

Closing as no longer necessary.