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.