Using Ignition to boot other systems (CentOS, RHEL)

[Vytis Valentinavičius]

Reasoning

I have a need to create automated boot-time provisioning for bare-metal servers.

Currently I am using Ansible pre-configured static iPXE + kickstart configurations to launch servers into semi-functioning state, which has to be further semi-manually provisioned to a working role (i.e. kubernetes node or nova node).

I want to migrate away from kickstart to ignition because I wish to have a fluent switch to CoreOS Container OS if I manage to defend that idea later on the road. To do that I figured I need to start with ignition based CentOS (or RHEL on some cases).

Problem

I need high level guidance on how to achieve this "uniform" installation procedure.

My current understanding of boot problem is a bit naive, I apologise if my rough plan is completely wrong.
1. I intend to create/find/reuse same step by step installation as in CoreOS:
 - boot temporary system to discover configuration for hardware node (ip, network, disks(raid), root users)

 - (?) configure next boot script to copy OS filesystem from network source to local filesystem, prepare and chain remaining role acquisition scripts/execs via systemd.
 - reboot

 - perform first boot provisioning with whatever exists in current systemd exec chain, at the end of it -- reboot to working role.

2. I have altered matchbox to support larger scale deployments with above task in mind.
3. I want to create a high level controller on top of those two processes to manage large groups of nodes. I.e. control an etcd key which defines user access rules to specific nodes, key would be watched by a small daemon in all nodes to perform required changes (similar to existing coreos update mechanics).

In my perspective there is a bunch of problems with my plan:

1. I have no idea where CoreOS/RedHat is moving and what you are doing.

2. I may have to reimplement existing software without actually understanding mistakes done in previous iterations (i.e. why there are different automated install mechanisms: ignition, kickstart/anaconda, debootstrap, fai-project.org)
3. A lot of functions I aim for have at least partial support in current OpenStack ecosystem, which is also an issue, since I am working with that ecosystem too and having two tools for the same task seems redundant.


So, in short -- who would be interested in discussing this in more detail and either guide me a bit or simply stop me from wasting a large portion of my time on this?

[Colin Walters]

Hi Vytis,

On Tue, Jun 19, 2018, at 10:21 AM, Vytis Valentinavičius wrote:

> I want to migrate away from kickstart to ignition because I wish to have a
> fluent switch to CoreOS Container OS if I manage to defend that idea later
> on the road. To do that I figured I need to start with ignition based
> CentOS (or RHEL on some cases).

We are in fact working on this as part of the merger of CoreOS Container Linux
with Fedora/RHEL/Atomic! See for example:

https://www.redhat.com/archives/anaconda-devel-list/2018-April/msg00005.html

Ongoing work is scattered, but here are some more links:

https://bugzilla.redhat.com/show_bug.cgi?id=1576879
https://github.com/dustymabe/bootengine

Outstanding work is things like SELinux, handling systemd presets, etc. Stay
tuned for announcements soon and initial test OS builds!

[Vytis Valentinavičius]

Hey Colin,

How can I help?

Because just staying and waiting does not fit my timeframe :)

From the information you pasted in, I figure I could help with fleshing out initramfs and initial boot sequence for arbitrary OS'es.

I could help by testing out existing features on physical hardware at my disposal or by gathering feedback on administration routine from my team.

Parallel to that I will continue working on Matchbox, I have few more ideas which I like to implement in addition to https://github.com/coreos/matchbox/issues/710