Rename `helloworld-*` samples to `hellogcp-$1` about docs

[rgregg]

Yes, sorry I didn't give you credit there. Didn't mean to make it look like I was stating a new opinion.

I'll work on a PR for option 2 today. I'll also create a new issue for us to work towards option 3, since I agree that's the right long term answer.

[dewitt]

I agree with the goal here of making the samples not GCP-dependent.

But before we shard samples by provider at the directory level, which will create largely redundant work and end up being harder for a user to follow, what can we do about making the samples generic from the start, or perhaps inline provider-specific instructions?

AFAIK, the only gcp-isms in most of these are (a) turning up the cluster, and (b) building the containers. Can we make those sections provider-agnostic, yet still simple to follow?

Note that it's probably fine to also have provider-specific samples under provider-specific directories, but the helloworlds shouldn't be that, imo.

[scothis]

The dependency on GCP that I saw was for GCB and GCR. I assume this is to either to avoid a dependency on the Build CRD (which seems strange) or the desire to avoid repo sprawl (which I expect to be a common user concern).

Renaming the samples was the "easy" solution to the general reaction of seeing "The Google Cloud SDK is installed and initialized" as a prerequisite. I agree with your desire to avoid creating samples for each cloud platform.

[dewitt]

Totally agree. That's the wrong first thing for someone to see.

Do we have someone we can assign to try updating a version of these to work on say, PKS, without any GCP-isms? I'm not sure if it's reasonable to inline provider-specific instructions or not (might be messy, might be fine), but would be great to get someone to give generifying the docs a shot regardless.

[scothis]

The primary different between these new samples and the previous samples is where the source code lives. The previous samples either target a pre-built image, or use Build CRD and point to a git repo with only that function's source.

I see two primary options:

1. create a git repo for each sample (preferably open source, or deal with creds for pulling private repos until public)
2. add a Path property to the Build CRD to change the working directory for subsequent build stages

[rgregg]

Totally in agreement that the helloworld samples should be cloud neutral and not Google opinionated. We wrote them up that way to keep them simple and get a structure going for how to organize the sample.

There are a few easier vs. harder approaches here:

1. Rename the samples to be gcp-based and allow other samples for other clouds.
2. Switch the samples to do local build and push using docker, this way they're no longer using GCB/GCR and are applicable to other clouds, but the instructions and code stay mostly as-is.
3. Switch to using the Build CRD, but this makes the samples more complex -- we need to put each sample into it's own public repo, and add build instructions which complicates the service definition.

Option 1 means our samples will get crazy, so I want to avoid that.
Option 2 seems like the simplest approach as far as highlighting what serving can do
Option 3 seems like the right overall Knative story.

Any strong preferences between these?

[scothis]

The options I listed above were predicated on your Option 3 (using Build CRD).

I'd like to get to Option 3, but requires a bit of refactoring either in this repo or in the build repo. Option 2 is a good compromise.

[rgregg]

@scothis Here's a draft with the first sample, does this feel like the right approach for all of them to you?
https://github.com/rgregg/knative-docs/tree/change-samples/serving/samples/helloworld-csharp#building-and-deploying-the-sample

[scothis]

@rgregg 💯