Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HCP Packer Support #144

Open
lucymhdavies opened this issue Jul 4, 2022 · 2 comments
Open

HCP Packer Support #144

lucymhdavies opened this issue Jul 4, 2022 · 2 comments

Comments

@lucymhdavies
Copy link

I'm currently making use of this plugin to generate Raspberry Pi images.
(which it does very well, by the way)

I'd like to be able to hook into HCP Packer, to keep track of image versions (which are stable, which I'm still testing, etc.)

My wise colleagues over in the HCP Packer team advise me this is usually relatively straightforward, and requires updating the Artifact metadata
https://www.packer.io/docs/plugins/hcp-support

I'm not entirely sure what such a metadata would look like in the context of this plugin, as (currently, as far as I can see) it just creates local disk images (and optionally flashes them), with the user running Packer responsible for copying those images somewhere.

But if you have thoughts as to how it could work, and would be happy accepting a PR, I'm up for experimenting with it.

@yuval-k
Copy link
Member

yuval-k commented Jul 10, 2022

Hi @lucymhdavies, I'm not very familiar with HCP, so I can't provide guidance on how it would work.. I am happy to accept PR related to it, as from the link you sent, it seems useful!

@lucymhdavies
Copy link
Author

Thanks. No ideas when I'd be able to get around to doing it, but I've had some initial thoughts on what it could look like. I'll experiment and let you know how it turns out.

Looking at the Image type...

    // ImageID is a unique reference identifier stored on the HCP Packer registry
    // that can be used to get back the built artifact of a builder or post-processor.
    ImageID string

As this plugin outputs directly to files, then just the filename would make sense here. It's not really a "unique" reference, but it's the best we've got for how this plugin works.

    // ProviderName represents the name of the top level cloud or service where the built artifact resides.
    // For example "aws, azure, docker, gcp, and vsphere".
    ProviderName string

Here, just arm-image or something like it makes sense to me.

    // ProviderRegion represents the location of the built artifact.
    // For cloud providers region usually maps to a cloud region or zone, but for things like the file builder,
    // S3 bucket or vsphere cluster region can represent a path on the upstream datastore, or cluster.
    ProviderRegion string

As the plugin isn't responsible for uploading the file anywhere in particular, I think we may be able to leave this blank. This plugin doesn't really have a concept of "region".

    // Labels represents additional details about an image that a builder or post-processor may with to provide for a given build.
    // Any additional metadata will be made available as build labels within a HCP Packer registry iteration.
    Labels map[string]string

Potentially a checksum of the image would be useful to add here. Unlike with plugins which build things like Amazon Machine Images, we don't really have a well defined concept of a unique ID for the created image.

    // SourceImageID is the cloud image id of the image that was used as the
    // source for this image. If set, the HCP Packer registry will be able
    // link the parent and child images for ancestry visualizations and
    // dependency tracking.
    SourceImageID string

We do have a well defined concept for this one.
iso_url can be used for this.

For comparison, here's what we see for an image I've built in AWS:

image

The "Build Labels" are metadata I've added myself, and the eu-west-* and ami-* metadata corresponds to Image ID and Provider region.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants