set image

[deitch]

This does a few things:

• solves the need for an actual tag on the image in kustomize. Unfortunately, it must be in the file itself, and kustomize has no way of composing files, so it cannot be generated on the fly with a single file outside of git.
• restructures the kustomize dir without changing anything material, to make it easier to see what there is: the release/ overlay, the managerless/ overlay, and the resources/ that apply to them
• fixes some minor variable dependencies in Makefile
• restores templates/metadata-template.yaml to template format
• generates a test/metadata.yaml file for usage in tests, applying the correct versions
• documents how to do a release in docs/RELEASE.md

[deitch]

I need to rebase this, will take care of it.

[deitch]

Separately, @gianarb , please look at the release doc, and see if you see a better way? Maybe we should not use git tags at all, and just have a single version file (maybe it is metadata.yaml itself but not as a template) and we use that to generate everything else?

[deitch]

OK, rebase done. The open questions are:

• review by @gianarb
• design of release options?

[gianarb]

That's amazing! Thank you for clarifying the process, I have to be honest it was hard to understand. So many things to generate and background to know.

I like the idea to bump the version in a single place. And I think if we use a file like VERSION that contains v0.3.0 or v0.4.0... The release flow can look at it and if it changes the GitHub action can create the release itself... So we will get to a point where only 1 change is required to cut a release. It sounds appealing to me.

[deitch]

So you want to do it in a file, and skip the git tags for now?

I am wondering how we would tell GH Actions to know that something is a release? For now, the event is "tag was added". I don't know that it will know how to tell, "a file has changed". Well, I guess we can do some git magic?

Or, we can continue to use tags, but use them as an after stage:

1. change the file and merge
2. add the git tag

And then maybe later get rid of the tag entirely? Or perhaps we have the tag added automatically by gh actions?

[gianarb]

Yeah I have your same unknowns. I am sure can add a step in our ci that gets triggered only when the VERSION file changes on master. But I don't know how to do it yet.

I think we have to agree on "the best workflow" we see for this.

1. I like the fact that it is atomic, one single way to say: "there is a new release"

I think the unique one for us to get there is via file bump, because of kustomize as you said. If we can figure out how to watch a change on a file via gh action that will be ideal because if t hat happens we can trigger what we already do to create a release in .github/workflows/release.yaml

[deitch]

OK, will change it for that then.

[deitch]

Look at it now. The logic is explained in the docs/RELEASE.md file. We still need to update the GH actions to utilize it, but this is good enough for a review.

[gianarb]

There is already a release file
https://github.com/packethost/cluster-api-provider-packet/blob/master/docs/contribution/release.md

[gianarb]

I think I do not understand. I thought about something totally different here. I thought we were speaking about the release of our project. But you were speaking about the cluster-api version our provider supports.

If we use this method with the APIVERSION how do we support more cluster-api versions? In theory we should be able to support v1alpha3, v2alpha3, v1alpha7, and so on. All the supported versions have to be listed in the metadata.yaml file. If I am well understanding now.

[deitch]

Merged the release.md files

[deitch]

If we use this method with the APIVERSION how do we support more cluster-api versions? In theory we should be able to support v1alpha3, v2alpha3, v1alpha7, and so on. All the supported versions have to be listed in the metadata.yaml file. If I am well understanding now.

You are right. We need to think about this some more.

[deitch]

The solution doesn't quite work. The releasing part does, but capturing the version does not.

[gianarb]

I think you have to help me clarify what we are solving. I have questions:

1. is the metadata yaml meant to contain information about what the provider supports from cluster-api? If so, why do we have to generate it?
2. Are we trying to solve the release problem here? With release I mean how do we tag and release a valid version of our provider, with the right docker images, with the right yaml file loaded as artifacts

I feel like the release process is solved, we can successfully create docker images, tag a release, and upload the yaml files we need.

We have to write down the process of supporting the cluster-api versions and the metadata.yaml in practice. I am not convinced about the fact that it has to be automated/generated.

[deitch]

If we use this method with the APIVERSION how do we support more cluster-api versions? In theory we should be able to support v1alpha3, v2alpha3, v1alpha7, and so on. All the supported versions have to be listed in the metadata.yaml file. If I am well understanding now

is the metadata yaml meant to contain information about what the provider supports from cluster-api? If so, why do we have to generate it?

You are right, this messed it up. metadata.yaml is about more than this release, it is about every release, it is a list of mappings, rather than just one. I will have to change some of this. It also means, as you correctly point out, that it cannot be a template, but a fixed file.

Hang tight here, and nice catch.

[deitch]

I updated it. Take a look.