CoreOS vs Anaconda toolchain

[Colin Walters]

Hi, I wanted to link this here:

https://github.com/coreos/coreos-assembler/issues/91
Most importantly starting from
https://github.com/coreos/coreos-assembler/issues/91#issuecomment-422830233
and the most recent ones.

Would love to do some brainstorming about how we can share more code/ideas in general; I had some specific comments towards the end.

One thing not explicitly noted there is how key Ignition is to FCOS (and derivatives like RHCOS) - having a common language that works in both bare metal as well as e.g. AWS and Azure is a big deal - and today the OpenShift 4 installer and the [machine-config-operator](https://github.com/openshift/machine-config-operator/) are built heavily upon it.

[Colin Walters]

Oh hm, and I even posted about this here earlier and forgot:
https://www.redhat.com/archives/anaconda-devel-list/2018-April/msg00005.html

To be honest though at that time I didn't have a full grasp on Ignition, and certainly not how the OpenShift installer worked, etc.  It became clearer to me later how deeply it needed to be worked into the operating system.

[Pat Riehecky]

This does indeed sound interesting.

Anaconda is one of the more complex bits of software I've worked with.  
It does a lot various things with a fair bit of flexibility.

My thoughts after 20 seconds of reflection (aka, not thought through at 
all):

I wonder if it might make sense to converge on something driven by a 
more modern workflow and tooling?  From one perspective 
Anaconda/Ignition are system setup tools.  Might it make sense to begin 
leveraging some of the automation tools to do some of this setup?  Or to 
put another way: Could anaconda/ignition begin to transition into a well 
defined Ansible workflow where the UI sets parameters?  For as much as I 
love kickstart, a YAML formatted document might lend itself to templates 
and easier transition to/from cloud providers....

Pat

On 9/6/19 3:46 PM, Colin Walters wrote:
> Hi, I wanted to link this here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreo...
> Most importantly starting from
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreo...
> and the most recent ones.
>
> Would love to do some brainstorming about how we can share more code/ideas in general; I had some specific comments towards the end.
>
> One thing not explicitly noted there is how key Ignition is to FCOS (and derivatives like RHCOS) - having a common language that works in both bare metal as well as e.g. AWS and Azure is a big deal - and today the OpenShift 4 installer and the [machine-config-operator](https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openshift_ma... ) are built heavily upon it.
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_...

[Vendula Poncova]

On Mon, Sep 9, 2019 at 4:53 PM Pat Riehecky  wrote:
> This does indeed sound interesting.
>
> Anaconda is one of the more complex bits of software I've worked with.
> It does a lot various things with a fair bit of flexibility.
>
> My thoughts after 20 seconds of reflection (aka, not thought through at
> all):
>
> I wonder if it might make sense to converge on something driven by a
> more modern workflow and tooling?  From one perspective
> Anaconda/Ignition are system setup tools.  Might it make sense to begin
> leveraging some of the automation tools to do some of this setup?  Or to
> put another way: Could anaconda/ignition begin to transition into a well
> defined Ansible workflow where the UI sets parameters?  For as much as I
> love kickstart, a YAML formatted document might lend itself to templates
> and easier transition to/from cloud providers....

Hi Pat,

Lars was looking into that for the osbuild. The problem is that Ansible
doesn't have support for systems that are kind of dead (no running services
etc.). However, I think that it would be a great way of sharing code with
other system setup and system building tools.

Vendy
> Pat
>
> On 9/6/19 3:46 PM, Colin Walters wrote:
> > Hi, I wanted to link this here:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreo...
> > Most importantly starting from
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreo...
> > and the most recent ones.
> >
> > Would love to do some brainstorming about how we can share more
>
> code/ideas in general; I had some specific comments towards the end.
> > One thing not explicitly noted there is how key Ignition is to FCOS (and
>
> derivatives like RHCOS) - having a common language that works in both bare
> metal as well as e.g. AWS and Azure is a big deal - and today the OpenShift
> 4 installer and the [machine-config-operator](
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openshift_ma...
> ) are built heavily upon it.
> > Anaconda-devel-list mailing list
> > [e-mail]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_...
>
> --
> Pat Riehecky
>
> Fermi National Accelerator Laboratory
> www.fnal.gov
> www.scientificlinux.org
>
> Anaconda-devel-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Matthew Miller]

On Fri, Sep 06, 2019 at 04:46:59PM -0400, Colin Walters wrote:
> Would love to do some brainstorming about how we can share more code/ideas in general; I had some specific comments towards the end.

Thanks for bringing this up, Colin. I appreciate the work-together effort in
particular. In the github issue you note:

And now here's the thing - all of the current image-building
  tools in the Fedora ecosystem (ImageFactory, virt-install,
  and lorax-composer/LMC) end up being wrappers around running
  Anaconda in a VM.

... and I want to comment a bit on how we got there. Specifically, we
previously had, like, half-a-dozen different ways to create an OS image,
ranging from shells scripts wrapping yum to more complicated packages. We
were using one of these to create the cloud image, and it starting having
all sorts of complicated and weird bugs, and really had no maintainer (just
accumulated hacks from rel-eng).

So, we decided to standardize on _one code path_, and _the thing which has a
dedicated team behind it_.

Now, I appreciate that there is a team behind Ignition too, so things are
different in some respects, but I think the basic part remains: let's make
sure we have long term maintenance in mind whatever decisions are made. And
let's please not have too many different ways of doing the same thing.

On Mon, 2019-09-09 at 17:35 -0400, Matthew Miller wrote:
> On Fri, Sep 06, 2019 at 04:46:59PM -0400, Colin Walters wrote:
> > Would love to do some brainstorming about how we can share more
> > code/ideas in general; I had some specific comments towards the
> > end.
>
> Thanks for bringing this up, Colin. I appreciate the work-together
> effort in
> particular. In the github issue you note:
>
> And now here's the thing - all of the current image-building
>   tools in the Fedora ecosystem (ImageFactory, virt-install,
>   and lorax-composer/LMC) end up being wrappers around running
>   Anaconda in a VM.
>
> ... and I want to comment a bit on how we got there. Specifically, we
> previously had, like, half-a-dozen different ways to create an OS
> image,
> ranging from shells scripts wrapping yum to more complicated
> packages. We
> were using one of these to create the cloud image, and it starting
> having
> all sorts of complicated and weird bugs, and really had no maintainer
> (just
> accumulated hacks from rel-eng).
>
> So, we decided to standardize on _one code path_, and _the thing
> which has a
> dedicated team behind it_.
>
> Now, I appreciate that there is a team behind Ignition too, so things
> are
> different in some respects, but I think the basic part remains: let's
> make
> sure we have long term maintenance in mind whatever decisions are
> made. And
> let's please not have too many different ways of doing the same
> thing.

+1 for that. Your saying exactly what I'm thinking off.

I know that Ignition have a different UX than Anaconda so it have also
a different user base and knowledge requirements. What I think can
improve is better cooperation and code/libraries sharing.

For example libblockdev[0] is a great candidate, it's used by Anaconda
and it should be used by Ignition from my PoV.

Another great candidate would be to create a library to solve
bootloader setup and installation. We talked to bootloader developers
about this already and they are willing to maintain such a library. I
think that would be really valuable for us the same way as for
Ignition.

Also if there are storage related requirements Ignition want to
implement we could be able to help them. It should be possible to make
our storage module a standalone module which can be then used by them
so we can share the storage code between projects.

It would be great to meet and discuss these ideas. Are the developers
of the Ignition planning to go to DevConf.cz? It would be great to meet
there. What do you think?

[0]: https://github.com/storaged-project/libblockdev

Best Regards,
Jirka