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

[RFE] OVHcloud documentation #1453

Closed
1 of 2 tasks
tormath1 opened this issue May 22, 2024 · 14 comments · Fixed by flatcar/flatcar-terraform#27
Closed
1 of 2 tasks

[RFE] OVHcloud documentation #1453

tormath1 opened this issue May 22, 2024 · 14 comments · Fixed by flatcar/flatcar-terraform#27
Labels
good first issue Get started with Flatcar contribution with this issue. kind/docs kind/feature A feature request platform/new-platform linked to new platform addition (cloud provider, image type, architecture, etc.)

Comments

@tormath1
Copy link
Contributor

tormath1 commented May 22, 2024

Current situation

OVHcloud is powered by OpenStack (for the virtual machines) but there is no documentation to show how to import and use Flatcar OpenStack images on OVH.

Impact

It's "hard" to get Flatcar running on OVH.

Ideal future situation

Additional information

Some notes I wrote during initial tests:

  • SSH keys injection works (afterburn)
  • coreos-metadata works (afterburn)
  • import the image with --property image_original_user=core and hw_qemu_guest_agent=yes
  • user-data (Ignition) can be added with Post-installation script from the portal
@tormath1 tormath1 added kind/feature A feature request kind/docs platform/new-platform linked to new platform addition (cloud provider, image type, architecture, etc.) labels May 22, 2024
@chewi
Copy link
Contributor

chewi commented May 22, 2024

FYI @sbraz

@tormath1 tormath1 added the good first issue Get started with Flatcar contribution with this issue. label May 22, 2024
@till
Copy link

till commented May 22, 2024

@tormath1 What is the additional property for?

I ran a couple tests the other week, and it seemed to work without it on OVH.

Haven't tested any specific OVH tooling, but I was able to start VMs with some internal code based on gophercloud.

@tormath1
Copy link
Contributor Author

@till the additional property (image_original_user=core) is used by the UI to generate the right ssh command (core@INSTANCE-IP). The instance will work without it of course but it's more convenient if you use the UI.
One additional property that can be set is hw_qemu_guest_agent=yes.

@till
Copy link

till commented May 22, 2024

Yeah, I set the agent in all openstack clouds I use. Still works as advertised! 🥳

@tormath1
Copy link
Contributor Author

Documentation PR has been opened: flatcar/flatcar-website#334. For now it shows how to import / deploy Flatcar on OVH Cloud.
@till @sbraz if you want to provide some feedback on the PR that would be great. 😍

@tormath1 tormath1 changed the title [RFE] OVHCloud documentation [RFE] OVHcloud documentation May 30, 2024
@tormath1
Copy link
Contributor Author

tormath1 commented Jun 4, 2024

Documentation has been merged. Thanks @till @sbraz for the review / feedback! It's here: https://www.flatcar.org/docs/latest/installing/community-platforms/ovhcloud/ . On the engineering/documentation side, we should now implement a few Terraform examples to deploy something with Flatcar on OVH.
Examples:

@tormath1 tormath1 moved this from 📝 Needs Triage to ⚒️ In Progress in Flatcar tactical, release planning, and roadmap Jun 4, 2024
@sbraz
Copy link

sbraz commented Jun 4, 2024

Do you also want to look into deploying it on OVHcloud bare metal? We have a terraform provider and we also support cloud-init: https://help.ovhcloud.com/csm/en-dedicated-servers-bringyourownimage?id=kb_article_view&sysparm_article=KB0043281

@tormath1
Copy link
Contributor Author

tormath1 commented Jun 4, 2024

@sbraz yes, we can give a try. I was curious about testing the BYOI feature. For the user-data, I think we would need to implement an Ignition provider to fetch them.

@sbraz
Copy link

sbraz commented Jun 4, 2024

If I understand correctly, Ignition is some kind of cloud-init alternative?

In that case, yes, you'd need to implement something to fetch data from cloud-init's Config Drive (we use v2 with an ISO 9660 partition labelled config-2).
FYI, @bapt implemented something similar in Lua for FreeBSD and called it nuageinit.

@tormath1
Copy link
Contributor Author

tormath1 commented Jun 5, 2024

@sbraz that's right, Ignition is a one-time provisioning software that runs from the initramfs. For OVHcloud it relies on OpenStack metadata service / config-drive. Maybe we can have it to work in a similar way on bare-metal.

@spnngl
Copy link

spnngl commented Jul 30, 2024

Hi, we use flatcar+terraform on OVH for quite some time.

Here our implementation working in production

resource "openstack_images_image_v2" "flatcar" {
  for_each = var.os_image

  name             = "Flatcar ${each.value["arch"]} - ${each.value["version"]} ${each.value["release_channel"]}"
  region           = var.region
  image_source_url = "https://${each.value["release_channel"]}.release.flatcar-linux.net/${each.value["arch"]}-usr/${each.value["version"]}/flatcar_production_openstack_image.img.gz"
  # XXX do not use it, OVH openstack seems to not handle this well :(
  # web_download      = false
  verify_checksum  = true
  decompress       = true
  container_format = "bare"
  disk_format      = "qcow2"
  protected        = false
  hidden     = false
  visibility = "private"

  # See: https://docs.openstack.org/glance/stein/admin/useful-image-properties.html
  # See: https://wiki.openstack.org/wiki/VirtDriverImageProperties
  properties = {
    architecture              = each.value["arch"] == "amd64" ? "x86_64" : each.value["arch"]
    image_original_user       = "core"
    distro_family             = "gentoo"
    os_distro                 = "gentoo"
    os_version                = each.value["version"]
    os_release_channel        = each.value["release_channel"]
    os_arch                   = each.value["arch"]
    os_type                   = "linux"
    hw_disk_bus               = "scsi"
    hw_scsi_model             = "virtio-scsi"
    hypervisor_type           = "qemu"
    hw_qemu_guest_agent       = true
    hw_vif_model              = "virtio"
    hw_vif_multiqueue_enabled = true
    hw_time_hpet              = true
  }

  timeouts {
    create = "5m"
  }
}

The for_each is used to get different versions running

  os_image = {
    main = {
      distro          = "flatcar"
      arch            = "amd64"
      release_channel = "stable"
      version         = "3815.2.5"
    }
    canary = {
      distro          = "flatcar"
      arch            = "amd64"
      release_channel = "beta"
      version         = "current"
    }
  }

@tormath1
Copy link
Contributor Author

@spnngl thanks for sharing this and kudos to your team to run Beta nodes. If you have a moment, would you consider upstreaming this example here: https://github.com/flatcar/flatcar-terraform? It will be referenced from the OVH documentation: https://www.flatcar.org/docs/latest/installing/community-platforms/ovhcloud/ as it can provide a good foundation for users who want to start on OVH with Flatcar.

We still need to check on the bare metal offer too what we can do.

@spnngl
Copy link

spnngl commented Jul 30, 2024

@tormath1 I'll do it later
We do not have that much beta nodes, we just want to check flatcar upgrades on them before the whole cluster. We had some bad surprises before 😬

We use baremetal byoi with flatcar too but not with their MAAS offer. We use their API to do it, no terraform.

@spnngl
Copy link

spnngl commented Aug 1, 2024

@tormath1 Added example here: flatcar/flatcar-terraform#27

Do you prefer a separate openstack-ovhcloud folder ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Get started with Flatcar contribution with this issue. kind/docs kind/feature A feature request platform/new-platform linked to new platform addition (cloud provider, image type, architecture, etc.)
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants