Birthday provisioning followup

Development
1

Hey,

I was on PTO during the birthday party and I could not join in (no internet), thanks for organizing. There’s been a lot of provisioning talk during Greg’s talk so I would like to chip in.

First of, let me say that I am not surprised by high numbers, as Greg said we live in container/serverless/sass/cloud world however the key understanding is knowing that somebody must deploy and maintain those clusters. Most, if not all, technologies have their own way of deployments but until everything matures, I think this is our chance to jump in and acquire some new users because many organizations are trying out various projects and products and POCs where Foreman could help. Specifically bare-metal and/or virtualization provisioning capabilities.

There’s also another perspective why I think it’s good timing and that is support for UEFI HTTP Boot which was finally added in 2.0 and 2.1. Booting from network has always been the best option for mass provisioning and the clunky TFTP protocol was often a blocker for some. This is changing now, UEFI HTTP boot process is faster, more robust, reliable and secure. I expect quick adoption of this for both bare-metal and virtualization environments. Let’s make sure we break up the bare-metal options into TFTP and HTTP for the next survey. Perhaps the overall option should be named “network booting” and then we can break it up into subcategories like “BIOS TFTP, UEFI TFTP, iPXE, HTTP UEFI, bootdisk or discovery-pxeless or other”.

One of the strongest feature of Foreman is in my opinion provisioning flexibility. We have features that nobody else have under one roof: bootdisk (full or network boot), discovery (network, local pxe-less), tftp, http, ipxe. We also support grub, grub2, pxelinux or petiteboot on both BIOS and UEFI. The sky is the limit.

Another observation: Bare metal provisioning has more use than all cloud providers combined together (76% vs 50%) or even including all “other” methods (76% vs 64%). And it makes sense, we talked about this on the last ATIX event with Timo and others - there are better tools like Ansible or Terraform (and many others) to do cloud provisioning in a declarative or imperative way. And if you need to do “ad-hoc” cloud provisioning the native cloud API/CLI/UI are much better option than limited Foreman capabilities.

Why I am saying this is that I see resources being thrown into cloud compute resources (GCE, Azure) while those community numbers say otherwise. Maybe the reason is these CRs are new, however if you look on EC2, the biggest IaaS cloud in the world, it’s very much the same story. Discovery needs an overhaul (based on SSH, more options, more workflows, better flexibility), discovery provisioning needs also better flexibility (rules are static, network cannot be reconfigured), TFTP/HTTPBOOT file naming convention and cleanup needs more work, IPAM and Redfish (both contributed by our community) need reviews and more support. There’s a lot to be done, I wish there were more of us focusing these important areas.

There was a discussion about discovery, I am glad we are touching this topic. The plugin has a lot of code from the initial Greg’s “hack” and it is pretty clear it’s great feature. We need to merge discovery into core. We need to get rid of STI. We need to improve fact parser. We need to redesign communication pattern (SSH) and the image itself (updating and building is lengthy process). I was working on a bug this week in smart proxy discovery image plugin which provides an API (reboot/kexec) and I noticed I wish the discovery image was minimal, much more than we have it today - clean (minimized) system only with SSH and some bootstrap (authentication) code Timo talked in the other thread - everything else would be done over SSH.

What still surprises me is high adoption of libvirt provider, everytime I see a bugreport I drop a note that I do recommend oVirt/RHEV/VMWare instead of libvirt as it usually works for single-node installations (multi-node features like migrations can be done but everything must be done manually). Users do not listen, it looks like a single hypervisor with many CPU cores, memory and disk arrays is probably still a thing. And I get it, one node is always easier to maintain than a cluster.

My key takeaway is we should focus on the most important features:

  • core (kernel) features (Ruby on Rails, React, UI, taxonomy, permissions)
  • good plugin API (including documentation, tutorials, examples)
  • bare-metal provisioning (DHCP, DNS)
  • virtualization provisioning (including libvirt which did not get much love in last years)
  • discovery improvements (and maybe merging it into core)
  • fast and reliable inventory (common facts, reports, good performance)
  • integration (webhooks)
  • good platform for configuration management plugins
  • good platform for content management plugin

I also think that extracting puppet into plugin is a great step in achieving the primary goal: Foreman as the provisioning and inventory tool with good integration for plugins and 3rd party systems.

7 Likes
2

Well said, I fully agree on all the topics mentioned above. Foreman is a datacenter tool and that’s a good thing. If you use Foreman to manage your cloud, you’re doing cloud wrong in my opinion. The only reason where Foreman might make sense is if if you’re doing a lift-and-shift approach. But that’s usually making another mistake in my opinion.

I’d like to add one more thing to the list, that is motivated by making all the existing features easier to consume: I believe the Foreman community needs a terraform provider that allows a user to describe an Application-Infrastructure on an IaaS-Level as code, so users can provision and manage a set of hosts using IaaS and without “clicking” a gazillion times.

3 Likes
3

In general I agree with everything that was said, there was just one point I would like to disagree about:

Until very recently, GCP and Azure were completely broken for a long time. Even now, our support for the big-three cloud providers is nowhere near on-par with the support for vmware or ovirt. In fact, GCP was only restored in 1.22 (release June 19), and Azure in 1.24 (released December 19)

I believe that the low numbers in the community survey reflect this fact. People who were considering using Foreman with their cloud machines in the past years mostly had a bad experience and gave up on it. To be honest, I’m surprised there were actually people who replied on the survey that they use resources which have only been functional for less than half a year when the survey came out.

If a user is fully cloud based on a single cloud, indeed Foreman doesn’t provide them with much advantage wrt to provisioning - the cloud provider’s interface will likely be much a better experience for them. However, the same is true for a full vmware shop.
We will never be able (and shouldn’t try) to be better then a dedicated interface for a specific provider.
We should aim, in my opinion, to provide easy provisioning support for the most common cases across all providers, while leaving the more complex cases to the providers themselves.
The benefit of Foreman obviously becomes more visible if you are a hybrid cloud shop and don’t have a single inventory source.

Our added value, besides the unified inventory that is only relevant in hybrid setups, is the additional integrations with other tools such as REX or configuration management. But for that to be worthwhile, we should have an easy way of importing an existing setup into Foreman (which I think the new registration workflows will greatly help with) and make Foreman itself easier to set up (which we still have a lot of work to do on).

1 Like
4

Just for googlers and the record, there are two providers at the moment, one seems to be abandoned and the other is still quite WIP:

5

I had an impression these were new compute resources. In this light, it’s not much an argument. Keeping them in a good shape is a reasonable thing to do.