Re: CoreOS vs Anaconda toolchain
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 ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: CoreOS vs Anaconda toolchain
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_coreos-2Dassembler_issues_91=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=7G9J0U8mTAU7eDMuir3ky8hsJEHjBhllLrpArag0ztw= > > Most importantly starting from > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreos-2Dassembler_issues_91-23issuecomment-2D422830233=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=ZmL0ktGZ4gBP1Cgpmz9QL3MbvKhOQLxZFTNj8ligiEQ= > > 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_machine-2Dconfig-2Doperator_=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=k-SXz0DOZeNsrdkDpZyg244dxo6akCX9r_RzkPHRIqY= > ) are built heavily upon it. > > > > ___ > > Anaconda-devel-list mailing list > > Anaconda-devel-list@redhat.com > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_anaconda-2Ddevel-2Dlist=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=hsNc4HvS01zWyo0UIHCxG87CGdpaMvaAlve6TA8iFeY= > > -- > Pat Riehecky > > Fermi National Accelerator Laboratory > www.fnal.gov > www.scientificlinux.org > > ___ > Anaconda-devel-list mailing list > Anaconda-devel-list@redhat.com > https://www.redhat.com/mailman/listinfo/anaconda-devel-list ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: CoreOS vs Anaconda toolchain
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. -- Matthew Miller Fedora Project Leader ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: CoreOS vs Anaconda toolchain
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_coreos-2Dassembler_issues_91=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=7G9J0U8mTAU7eDMuir3ky8hsJEHjBhllLrpArag0ztw= Most importantly starting from https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_coreos_coreos-2Dassembler_issues_91-23issuecomment-2D422830233=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=ZmL0ktGZ4gBP1Cgpmz9QL3MbvKhOQLxZFTNj8ligiEQ= 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_machine-2Dconfig-2Doperator_=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=k-SXz0DOZeNsrdkDpZyg244dxo6akCX9r_RzkPHRIqY= ) are built heavily upon it. ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailman_listinfo_anaconda-2Ddevel-2Dlist=DwICAg=gRgGjJ3BkIsb5y6s49QqsA=OAMtP0DWou0nlXG7Kmxo2enjXJfwb1DXS9fwcaESuTE=YqP9qr3liUKA6uMbUFVdpgGdPTtGp7tzGww8AahLxA8=hsNc4HvS01zWyo0UIHCxG87CGdpaMvaAlve6TA8iFeY= -- Pat Riehecky Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Re: CoreOS vs Anaconda toolchain
Oh hm, and I even posted about this here earlier and forgot: https://www.redhat.com/archives/anaconda-devel-list/2018-April/msg5.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. ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
