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

Platform Request: Akamai Connected Cloud (Linode) #1701

Open
nesv opened this issue Mar 27, 2024 · 5 comments
Open

Platform Request: Akamai Connected Cloud (Linode) #1701

nesv opened this issue Mar 27, 2024 · 5 comments

Comments

@nesv
Copy link

nesv commented Mar 27, 2024

Why is the platform important? Who uses it?

As a disclaimer, I currently work for Akamai. There has been some internal interest in making use of immutable Linux distributions, and this is part of an effort to introduce such a distribution into our existing infrastructure, and potentially offer it as a part of existing and future products.

I was asked to file this ticket to help track these efforts.

What is the official name of the platform? Is there a short name that's commonly used in client API implementations?

Historically, "Linode", given the client API implementations (e.g. https://pkg.go.dev/github.com/linode/linodego) predate Linode's acquisition by Akamai. However, Linode is slowly being rebranded to "Akamai Connected Cloud". akamai would be an appropriate short name, as it has been used when contributing to other projects.

How can the OS retrieve instance userdata? What happens if no userdata is provided?

In regions with Metadata Service availability, instance userdata can be retrieved by first issuing a request to retrieve an authorization token

TOKEN="$(curl -X PUT -H "Metadata-Token-Expiry-Seconds: 3600" http://169.254.169.254/v1/token)"

then using that token to make a subsequent request to http://169.254.169.254/v1/user-data

curl -H "Metadata-Token: ${TOKEN}" http://169.254.169.254/v1/user-data | base64 -d -

Attempting to use the Metadata Service in an unsupported region results in a connection timeout:

TOKEN="$(curl -X PUT -H "Metadata-Token-Expiry-Seconds: 3600" http://169.254.169.254/v1/token)"
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:--  0:02:09 --:--:--     0
curl: (28) Failed to connect to 169.254.169.254 port 80: Connection timed out

Does the platform provide a way to configure SSH keys for the instance? How can the OS retrieve them? What happens if none are provided?

Yes. SSH keys are managed in a user's profile. When creating a new Linode (virtual machine instance), the user has the ability to select which users' keys are added to the instance.

Linode accounts can have multiple users, and multiple users can be granted SSH access to an instance. However, there is currently no granularity when adding keys. All of a user's keys are added to the instance when a user is granted SSH access.

For Linode-provided instance images, there is a "helper" application that manages the SSH keys on an instance. All Linode-provided images have this helper pre-installed.

On select images (Debian 11, Ubuntu 20.04LTS, Ubuntu 22.04LTS), SSH keys may also be provided to instance via userdata. These images have cloud-init support through the Akamai data source.

If no SSH keys are provided, none will be automatically provisioned on the instance, and for instances in a region with the Metadata Service, the /v1/ssh-keys endpoint will return a (mostly) empty response. I believe the API will also require a root password be set (though there are ways around this, using instance configuration profiles).

How can the OS retrieve network configuration? Is DHCP sufficient, or is there some other network-accessible metadata service?

In regions with the Metadata Service, network configuration can be retrieved from the network data endpoint.

However, all Linode-provided images currently come with the network helper, which statically configures networking on an instance.

For images which do not have the network helper pre-installed (e.g. custom user images), IPv4 addresses can be assigned by DHCP, and IPv6 addresses are provided by SLAAC.

In particular, how can the OS retrieve the system hostname?

The network helper can statically configure an instance's hostname. Otherwise, a hostname can be chosen through instance metadata, using either the id, host_uuid, or label fields.

Does the platform require the OS to have a specific console configuration?

No.

Is there a mechanism for the OS to report to the platform that it has successfully booted? Is the mechanism required?

No, and no.

Does the platform have an agent that runs inside the instance? Is it required? What does it do? What language is it implemented in, and where is the source code repository?

There are several "helper" applications that provide network configuration, placing SSH keys, setting (and resetting) the root password, and backups. They are not required.

How are VM images uploaded to the platform and published to other users? Is there an API? What disk image format is expected?

Custom VM images can be uploaded to the platform. However, images uploaded by a user to their account cannot be shared to another account. Publishing images that can be used by all accounts is an internal process.

The API is documented at Images » Image Upload.

Currently, only RAW images are supported. Images must be gzip-compressed when uploaded. The maximum size of an image must be less-than 6GiB when uncompressed.

Are there any other platform quirks we should know about?

  • After uploading a gzip-compressed RAW image, the image is processed in the background. One of the processing steps decompresses the image. If the image is larger than 6GiB when decompressed, the image will not be visible from the API or cloud panel.
  • UEFI booting is not supported.
  • Images must have a DOS/MBR partition table, or a GPT partition table that supports "legacy" booting.
@travier
Copy link
Member

travier commented Mar 27, 2024

Wow, thanks for working on this and thanks for the detailed informations!

@dustymabe
Copy link
Member

Yes. The amount of information here is very useful!

@dustymabe dustymabe added the meeting topics for meetings label Mar 27, 2024
@nesv
Copy link
Author

nesv commented Mar 27, 2024

You're most welcome! If there is any other information I can provide, just let me know.

nesv added a commit to nesv/ignition that referenced this issue Mar 27, 2024
The "akamai" provider adds support for retrieving an ignition
configuration from Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][1].

See: flatcar/Flatcar#1404
See: coreos/fedora-coreos-tracker#1701
Fixes: coreos#1508

[1]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
nesv added a commit to nesv/ignition that referenced this issue Mar 27, 2024
The "akamai" provider adds support for retrieving an ignition
configuration from Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][1].

See: flatcar/Flatcar#1404
See: coreos/fedora-coreos-tracker#1701
Fixes: coreos#1508

[1]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
@c4rt0
Copy link
Member

c4rt0 commented Mar 27, 2024

We discussed this today in the FCOS meeting.
We think that it is a good idea. We will reserve the akamai platform ID for the Akamai Connected Cloud (Linode) platform and support the contributors from Akamai on adding support for it.

@c4rt0 c4rt0 removed the meeting topics for meetings label Mar 27, 2024
@nesv
Copy link
Author

nesv commented Mar 27, 2024

Wonderful! Thank you very much, @c4rt0!

nesv added a commit to nesv/afterburn that referenced this issue Apr 1, 2024
The "akamai" provider adds support for retrieving an ignition
configuration from Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][metadata-service].

References: flatcar/Flatcar#1404
References: coreos/fedora-coreos-tracker#1701
References: coreos/ignition#1841

[metadata-service]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
nesv added a commit to nesv/afterburn that referenced this issue Apr 1, 2024
The "akamai" provider adds support for retrieving configuration from
Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][metadata-service].

References: flatcar/Flatcar#1404
References: coreos/fedora-coreos-tracker#1701
References: coreos/ignition#1841

[metadata-service]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
nesv added a commit to nesv/ignition that referenced this issue Apr 4, 2024
The "akamai" provider adds support for retrieving an ignition
configuration from Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][1].

See: flatcar/Flatcar#1404
See: coreos/fedora-coreos-tracker#1701
Fixes: coreos#1508

[1]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
nesv added a commit to nesv/ignition that referenced this issue Apr 5, 2024
The "akamai" provider adds support for retrieving an ignition
configuration from Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][1].

See: flatcar/Flatcar#1404
See: coreos/fedora-coreos-tracker#1701
Fixes: coreos#1508

[1]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
nesv added a commit to nesv/ignition that referenced this issue Apr 5, 2024
The "akamai" provider adds support for retrieving an ignition
configuration from Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][1].

See: flatcar/Flatcar#1404
See: coreos/fedora-coreos-tracker#1701
Fixes: coreos#1508

[1]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/

docs: Add Akamai/Linode provider to release notes
nesv added a commit to nesv/ignition that referenced this issue Apr 5, 2024
The "akamai" provider adds support for retrieving an ignition
configuration from Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][1].

See: flatcar/Flatcar#1404
See: coreos/fedora-coreos-tracker#1701
Fixes: coreos#1508

[1]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/

docs: Add Akamai/Linode provider to release notes
nesv added a commit to nesv/afterburn that referenced this issue Apr 10, 2024
The "akamai" provider adds support for retrieving configuration from
Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][metadata-service].

References: flatcar/Flatcar#1404
References: coreos/fedora-coreos-tracker#1701
References: coreos/ignition#1841

[metadata-service]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
nesv added a commit to nesv/afterburn that referenced this issue Apr 19, 2024
The "akamai" provider adds support for retrieving configuration from
Akamai Connected Cloud's (a.k.a. Linode) [Metadata
Service][metadata-service].

References: flatcar/Flatcar#1404
References: coreos/fedora-coreos-tracker#1701
References: coreos/ignition#1841

[metadata-service]: https://www.linode.com/docs/products/compute/compute-instances/guides/metadata/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants