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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
