RFC: Bare Metal Provisioning with M2 in Foreman

[lzap]

@stbenjam

The project’s origins are to support “elastic” bare metal

Yeah, after reading the paper it’s all clear. I made wrong assumption that M2 is another imaging tool. It’s a diskless approach via iPXE-iSCSI-Ceph, it’s good to have open-source solution with common API for that. Everytime I worked with a diskless setup, it was always custom made with many quirks and workarounds. Mostly workstations, as the paper says.

@stbenjam

My concern about this is that compute resource is heavily coupled with the concept of virtual machines, I’m not sure how much work it’d be to decouple that, but it’s certainly a possibility. @lzap, what would you envision the M2 process being, does a user select “Bare Metal” from the “Deploy On” menu, or would M2 be a compute resource of it’s own, with a list of images like you would get from a vmware or oVirt resource?

We recently added support for Anaconda image-based provisioning for oVirt/RHEV, it’s just a template but I was not aware that Anaconda can do that (grab an image, write to disk, run post scripts, done). Long term, it would make lot of sense to have a common imaging API.

It’s indeed coupled to Compute Resource, but not much. An image has OS installed and architecture, both associations make sense. Username, password and userdata are all relevant too - this allows Foreman to customize an image. What’s not relevant is IMHO: uuid, iam_role and compute resource association - this could be extracted into M:N association easily tho.

However, after understanding what M2 really is, I think it makes more sense to have simply another Compute Resource. I think M2 is good fit to be a regular CR, there are images which can be associated, servers (not VMs) can be cloned, started, stopped and images have credentials. User-data is not relevant although technically possible, Foreman can use finish scripts to inform itself about end of provisioning process.

I think we can use Compute Resources just fine, but the name of the CR should indicate this is also bare-metal. I’d suggest something like “M2 Bare Metal”, so this name shows up in the “Deploy on” drop down next to OpenStack or Bare Metal. By the way, we should replace this term with something more correct like “PXE Host” because you select “Bare Metal” obviously when you want to PXE boot a VM via Foreman. That’s not correct, let’s discuss separately: RFC: Rename Bare Metal in Deploy on menu

Scratch my ideas around generic imaging, that’s not on the table now.

@stbenjam

I think @iballou looked into grub2 and it didn’t have any obvious sanboot functionality.

Going forward, our plan is to focus on UEFI HTTPS Boot capability as an alternative to iPXE which is used by Foreman users to avoid TFTP in PXE. This can enable more hardware to use iPXE in UEFI mode.