carvel-dev / docker-image

Source for ghcr.io/vmware-tanzu/carvel-docker-image:latest that includes various Carvel tools
Apache License 2.0
8 stars 4 forks source link

Images/Version Tagging for Individual Carvel Tools #2

Open danielhelfand opened 3 years ago

danielhelfand commented 3 years ago

Currently, Carvel tools are offered in a single image without much provided into what versions of tools are available in each tag. Additionally, there are not unique images for each tool. When trying to use Carvel tools with a tool like Tekton, which allows users to specify what image(s) to run CI/CD steps in, it can be challenging to figure out how to use specific tools/versions of tools in the process.

I am wondering if there have been discussions about supporting images for individual tools and having tagging that corresponds to tool versions (k14s/ytt:v0.30.0). Additionally, it would be helpful to provide more clarity around what versions of individual tools are part of the image that supports all the Carvel tools.

cppforlife commented 3 years ago

I am wondering if there have been discussions about supporting images for individual tools and having tagging that corresponds to tool versions

there hasnt been any discussion around this topic afaik. current state is driven by existing use cases where multiple tools are used together (ytt + kapp, or kbld + kapp, etc.). would like to hear more about workflows that will benefit from a dedicated image that contains one tools vs just all of them.

Additionally, it would be helpful to provide more clarity around what versions of individual tools are part of the image that supports all the Carvel tools.

what kind of "interface" you are imaging for that? may be in release notes for each time new image is released.

danielhelfand commented 3 years ago

there hasnt been any discussion around this topic afaik. current state is driven by existing use cases where multiple tools are used together (ytt + kapp, or kbld + kapp, etc.). would like to hear more about workflows that will benefit from a dedicated image that contains one tools vs just all of them.

kapp on it's own I think would make sense to support with a separate image corresponding with a specific version tag.

My original example of ytt by itself is maybe not perfect, but an image with it along with kubectl I believe would have a lot of use cases. Maybe it would make sense to wait to see if others come forward with this as well though.

what kind of "interface" you are imaging for that? may be in release notes for each time new image is released.

Release notes would be really great as a starting point. I am also wondering if there would be a non verbose way to tag the images for users that makes it simple for users to declare what versions of each tool are used. Which versions to release together and how frequently I think would need to be further refined.

ChristianCiach commented 11 months ago

I have pretty much the same use-case, as I've desribed here before I saw this issue:

current state is driven by existing use cases where multiple tools are used together (ytt + kapp, or kbld + kapp, etc.).

We, too, use kapp and kbld together. While I would be happy to see separate images for each of these tools where the image-tags conform to the tool version, this is probably not really necessary anymore since kapp-controller is a thing.

The image ghcr.io/carvel-dev/kapp-controller is probably a good replacement for the docker image built by this project, since it also contains all of the binaries. I only wish ghcr.io/carvel-dev/kapp-controller would have proper image tags that follow the versions of kapp-controller. The current image tags make it hard to use tooling such as renovate for automatic update management:

$ skopeo list-tags docker://ghcr.io/carvel-dev/kapp-controller
{
    "Repository": "ghcr.io/carvel-dev/kapp-controller",
    "Tags": [
        "rand-1675057777567790718-46346116232-kapp-controller",
        "rand-1675058931368617744-1271351746218-kapp-controller",
        "rand-1675163778348920726-812368450122-kapp-controller",
        "rand-1675193814572979956-253282113186-kapp-controller",
        "rand-1675244127333236169-10210068214167-kapp-controller",
        "rand-1675245774317316042-2464820015738-kapp-controller",
        "kbld-rand-1675401201382102428-62255187123160",
        "kbld-rand-1675402840339791567-23310489178160",
        "kbld-rand-1675407352309901886-7717417023141",
        "kbld-rand-1675439880404786302-1241851372172",
        "kbld-rand-1675452368289632941-17711916793109",
        "rand-1675781866138377603-621713572123-kapp-controller",
        "rand-1675792914553031285-55133160193248-kapp-controller",
        "rand-1678460282626099075-13914813387188-kapp-controller",
        "rand-1680590094810685620-2483821750128-kapp-controller",
        "rand-1680592068259360587-2923224245119-kapp-controller",
        "rand-1681926566974979929-20313523818122-kapp-controller",
        "rand-1683901464977327408-1796785129221-kapp-controller",
        "rand-1686140184663267382-180232123394-kapp-controller",
        "rand-1686726827567580141-452638127244-kapp-controller",
        "rand-1686727096520192185-229118199458-kapp-controller",
        "rand-1686728436715212662-1451085142-kapp-controller",
        "rand-1687286425569287071-23911111561217-kapp-controller",
        "rand-1687287211927885042-24712624661102-kapp-controller",
        "rand-1689069528378621476-8918624717676-kapp-controller",
        "rand-1692209005806725957-24418352143201-kapp-controller",
        "rand-1692289561907427951-191219866131-kapp-controller",
        "rand-1692290847083382201-9613217015964-kapp-controller",
        "rand-1692291184261679450-149351989157-kapp-controller",
        "rand-1692863946420967110-245564812994-kapp-controller"
    ]
}

It's impossible to see which version of kapp-controller is included just by reading the tags.