[Feature]: Add support to set instance config during creation.

[thomasjcf21]

Hi Guys,

I can't see a template for a feature / enhancement (I think it's broken according to github). So I'm sorry it's not following your expected format.

Description:

Please can we add the ability to set the instance config during packer initalization. When we are building packer images we are wanting to use GRUB2 as we would like to boot with your kernels during imaging, rather than Linode's. However, the Linode Packer integration does not allow you to set config specific variables.

As a result, we have to have a shell provisioner which runs before ansible, shuts down the instance and then reboots it. Instead, it would be much cleaner if we can get some (or all) of the linode config so that once it's booted we can get straight to work.

Use Case:

We build images, and run them, using the OS Kernel, not Linode's. This allows us to set it from boot instead of it being a post step. This is our last discrepency between Linode and AWS Image Building, which allows us to ensure that all image building works with both systems!

Thoughts:

I'm not sure if it would be best to make the config option a dictionary / object and just pass it straight through to the Linode API so it's always up to date, or if it's best to have specific config keys you would want to pass through.

You would need to launch the machine with it being powered off, change the config, and then power it on. Rather than trying to change the config once it had booted.

Many Thanks, Tom Franklin.

[zliang-akamai]

Hi @thomasjcf29, thanks for the feature request! In order to better understand the problem, can you tell us a little bit more about the situation you are facing?

So a basic Packer workflow is:

1. Packer initializes a machine with a private or public image.
2. Packer creates another private image with the machine it initialized above.
3. The Packer created private image is ready and being deployed to Linodes for production/development use.

Adding the Config support in Packer will only let you use GRUB2 kernel in the step 1.

If you are looking for using GRUB2 kernel in step 3 without doing explicit Config and Disks creation API calls, we will have to make a further feature request to other teams because a Linode kernel will still be used when the Linode is created with a private image (built by Packer), and Packer plugin alone can't support it as it's outside of the Packer run period.

May I know where you are looking for using the GRUB2 kernel? Maybe both?

And due to known limitations, if Packer allows you to create a explicit Config, then you will also have to define the explicit disks for the Linode used for building the image, which may be complicated.

It will be something like:

source "linode" "example" {
  instance_type     = "g6-nanode-1"
  region            = "us-mia"
  ssh_username      = "root"
  config {
    // other fields...
    sda {
      disk_label = "boot disk"
    }
  }
  disk {
    label = "boot disk"
    image = "your_image"
    size = 12345 // optional
    // other fields...
  }
}

May I know if that looks okay to you?

[thomasjcf21]

Hi @zliang-akamai thanks very much for getting back to me!

Yes, I'm looking to do it on the stage 1, so the image which has been launched by packer for the destination image to be created.

The use case for this is that we would like to confirm our golden images can be booted with how we expect them to be booted in production.

The config object makes sense to me, does it make sense to have defaults / use the default config created by Linode and then override where required rather than specifying defaults? Although if that's not possible I don't mind specifying defaults as it will be a common local block that I can share with all my images.

Ultimately, I just want to change the kernel before the packer image is launched (but after it's created), so having defautls would make sense. However, specifying other config objects is fine by me as well :))

Many Thanks, Tom Franklin.

[zliang-akamai]

@thomasjcf21 Thanks for the details and the suggestion! We will be considering all options and tracking this issue internally.