The Modularity Team was able to hold a session at Flock 2019 to gather feedback and discuss a few issues. The session was well attended and there was a bunch of great discussion.
We started out by spending 15 minutes, measured on a stopwatch(!) gathering the most pressing issues. The audience and the panel came up with quite a few ideas.
Continue readingCome and discuss Modularity at Flock! There are three sessions ready that will help you decide when to make a module, how to make them, and a discussion about making everything Modularity work better.
Are you a maintainer of packages in Fedora and can’t decide when to use modules? Well, this talk is right for you. In about 15 minutes it will cover a few specific use cases and demonstrate what Modularity solves and what it doesn’t. We’ll have about 30 minutes to discuss any other topics the audience comes up with.
If you decided you want to use modules, this might be a talk for you. Merlin will walk you through the steps of putting together a module, building it, testing it, and more! All of this in 25 minutes!
Making modules has not been always an easy process. The technology is very new and there are still some things to finish. Come and help us make it better! We’ll have half a day dedicated to discuss, design, make plans, hack, and more.
Fedora’s Modularity initiative aims to make it easy for packagers to create alternative versions of software and for users to consume those streams simply. We’ve been working on this for several years, resulting in the “Boltron” prototype this summer and the recent Fedora Modular Server beta. Feedback shows that these test releases didn’t meet the goal, and we’re incorporating that in a modified design which we think will. We plan to demo the new approach by DevConf.cz and FOSDEM.
Modularity (formerly, Modularization) is an ongoing initiative in Fedora to resolve the issue of divergent, occasionally conflicting lifecycles of different components. A module provides functionality (such as a web server) and includes well-integrated and well-tested components (such as Apache httpd and the libraries on which it depends). It can be deployed into production in various ways: as “classic” RPM packages or a container image, and is updated as a whole. Different modules can emphasize new features, stability, security, etc. differently.
Modules differ from traditional packaging in certain important ways. Perhaps most importantly, they allow us to separate internal implementation details from the exposed interfaces of the module. Historically in Fedora, if a packager wanted to deliver a new web application, that would also often mean that they needed to package and carry the framework or other libraries used by that application. This tended to be a double-edged sword: on the one hand, those libraries were now available for anyone to pick up and use in Fedora. However, in many cases, this meant that the primary maintainer of that package might actually have no specific knowledge or understanding of it except that its lack would mean their application didn’t work. This can be a problem if a person is carrying around a library for the use of a single helper function and don’t want to be responsible for issues in the rest of the library.
This blog now has a drop-down category called Modularity. But, many arteries of Modularity lead into a project called Factory 2.0. These two are, in fact, pretty much inseparable. In this post, we’ll talk about the 5 problems that need to be solved before Modularity can really live.
The Modularity working group is looking to flesh out a set of personas to help focus the work being done by the team. Personas are fictional characters created to represent the different user types that might interact with a “product” in different ways. They are not market segments but should be thought of as user archetypes.
Personas can be useful in considering the goals, desires, and limitations of users to guide decisions about a product. They should be based on user research and can include all types of information about that particular person. Our personas include information related to behavior patterns, goals, skills, pain points, attitudes and daily activities. If you want to learn more about personas and their use, I recommend your start here.
Some benefits a team can see with personas include:
Source: StaticFlicker
Modularity is an exciting, new initiative aimed at resolving the issue of diverging (and occasionally conflicting) lifecycles of different “components” within Fedora. A great example of a diverging and conflicting lifecycle is the Ruby on Rails (RoR) lifecycle, whereby Fedora stipulates that itself can only have one version of RoR at any point in time – but that doesn’t mean Fedora’s version of RoR won’t conflict with another version of RoR used in an application. Therefore, we want to avoid having “components”, like RoR, conflict with other existing components within Fedora.
Although RoR can be thought of as a component, the definition of “component” is actually a work-in-progress. In other words, another example of a component might be a “LAMP module”, where module is defined as a well-integrated and well-tested set of smaller components that provide functionality. The LAMP module would contain the necessary smaller components required to build and deploy a dynamic, high-performance Apache web server that utilizes MariaDB and PHP. Such a module would be completely independent of all other modules.
As a systems administrator, you generally worry about two things. First, the security of the systems you support. Second, that the applications you run work as designed. You would like to do those two things with as little effort as possible, however, you want to be aware of and balance the risk inherent in meeting those goals.
Enter Fedora. Fedora curates the libraries and applications that are available to install on your local system(s). Fedora makes the promise that as soon as possible after the release of a patch or a new version of a library or an application it will make it available to you as a system administrator. However it does this by ensuring the sanctity of individual libraries. Effort is also made to ensure that dependent applications are also verified which consume that library.
We will be writing a series of blog posts regarding the project to help the Modularity effort move forward. Some of the posts will be about “Why?” and some will be about “How?” As the first post in the series, this article is about “Why?”
The Rings Proposal and the Modularity Objective are both about big ideas and a long-term vision. And it should be all those things. Grand visions are how Fedora is what it is today.
The Fedora Council requests that the Objective Leads and top-level teams provide periodic updates to present status and progress towards the mission of Fedora. Recently, I presented the status of the Fedora Modularization Objective. If you would like to track future Council updates, follow this blog, or attend yourself! The schedule is normally posted on the Council Mailing List.
Please keep an eye on the Environments & Stacks Working Group mailing list for ongoing progress with the Modularization Objective.
Copyright © 2024 Fedora Community Blog
This work is licensed under a Creative Commons Attribution 4.0 International License.
Theme by Anders Noren — Up ↑
Recent Comments