The reason I love Foreman, is because it loves all my stuff. There are not many things it does not support in one or the other way; even more, all these things get modelled nice and neat.
It gives me a good and clear and accurate view of my entire resource pool.
Now, as was discussed this week during CfgMgtmCamp, it was presented that 71 variables need to be provided on a vanilla installation of foreman (so without any additional plugins), a high number! Even worse, it might make user adoption a bit slower as well.
With all this in mind, I started dreaming and I believe we have a very big opportunity available at our feet:
a concept most easily described as “Blueprints” (I’m not a MaaS user, but from reading and seeing demos, maybe I could also call it “JuJu on steroids”?)
In my dreams, a Foreman Blueprint would probably look something like this (still rough around the edges perhaps):
name: kubernetes-cluster
description: this blueprint will create a high-available K8S cluster, with 3 masters and 5 nodes
foundation:
operating_systems:
- name: WindowsServer2019Standard
cfgmgmt:
ansible_playbooks:
- xabre.kubernetes_master
- xabre.kubernetes_slave
- xabre.some_k8s_deployment_role
resources:
- cpu: 4
ram: 16000
hdd: 32000
count: 8
name: standard_computer
stages:
stage_0:
- provision: standard_computer
count: 8
os: Windows Server 2019
stage_1:
- commission: standard_computer
ansible_playbooks:
- xabre.kubernetes_master
count: 3
- commission: standard_computer
ansible_playbooks:
- xabre.kubernetes_slave
stage_2:
- commission: standard_computer
has_ansible_playbooks:
- xabre.some_k8s_deployment_role
select: any
the “foundation” bit is where validation is done for availability of the set of resources, operatings systems and configuration scripts, basically our tools available in foreman right now. In the beginning, a user might just see a descriptive error message stating that these will have to be made available before it can proceed, but in a later stage this might try to overcome issues by creating an operating system if it’s not available (e.g. if it were an open-source OS like ubuntu, this would probably be fairly trivial to create an operating system in foreman using some safe defaults?).
An interesting addition here, would be the resources, in which the user would be asked to give a list of compute resources and/or bare metal systems (adhering to the requirement of 4 CPU threads, 16GB RAM, etc…) that can be used for this deployment.
After this, the “stages” can be constructed. To go to the next stage, all sub-steps would need to be ready before it can continue to the next stage. In this example, the first stage would provision 8 systems with “windows server 2019”, the next stage would install kubernetes_master on 3 of them and kubernetes_slave on the remainder. Finally, something could actually be deployed to this cluster.
To make another interesting case, IMO, it should also be possible to create, for instance, an oVirt cluster and deploy a set of VMs as well.
This could all go to an “architect”-service (kinda what galaxy is for roles) where all these blueprints could be made freely available for everyone to use and share!
I think the benefits are:
- Simple! no programming skills required, it’s YAML!
- builds on the abstraction foreman provides
- could probably already be build as an external tool which consumes the API
- concise package, one file to rule them all, one file to bind them all
- could enhance user experience by a great deal (could greatly reduce 71 parameters)
- easy user adaption
- an answer to Juju? (or just a stepping stone?)
Okay, I know I’m probably pushing this list a bit, but I hope I could make a case for this one. Really, really, really looking forward to some feedback on this topic and curious what your views are on such a topic? Are there perhaps already efforts or brainstorms being done on this subject?
Enjoy reading my midnight “snack”