Category: Modularity

All articles in this category are related to the Modularity Working Group in the Fedora Project. https://fedoraproject.org/wiki/Modularity

Fedora Docker Layered image build service now available

Announcing: Fedora Docker Layered Image Build Service is GO!

It is with great pleasure that the Fedora Project Announces the availability of the Fedora Docker Layered Image Build Service to the Fedora Contributor Community!

With this announcement we open the availability of the Docker Layered Image Build Service for the Docker Layered Images. The Fedora Cloud WG has been the primary maintainers of this project on GitHub. But now the service is available in dist-git as official components of Fedora. From there we will extend an invitation to all Fedora Contributors to maintain Docker Layered Image Containers for official release by the Fedora Project. Currently this effort is to enable the Fedora Cloud/Atomic Working Group goals of targeting Fedora Atomic Host as a primary deliverable to power the future of Cloud. This is also to enable the Fedora Modularity work be delivered as Containers in the future as Fedora becomes fundamentally more modular in nature.

Continue reading

Base Runtime and the Generational Core

A Quick Primer on Modularity

lego_chicago_city_view_2001Modularity (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.

Continue reading

What does Factory 2.0 mean for Modularity?

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.

Continue reading

What are Personas and why should you care?

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.

Benefits of personas

Some benefits a team can see with personas include:

Continue reading

Modularity Infrastructure Design

Co-authored by Courtney Pacheco and Ralph Bean

Note: This article is a follow-up to Introduction to Modularity.


Introduction

The purpose of our Modularity initiative is to support the building, maintaining, and shipping of modular things. So, in order to ensure these three requirements are met, we need to design a framework for building and composing the distribution.

In terms of the framework, in general, we are concerned about the possibility of creating an exponential number of component combinations with independent lifecycles. That is, when the number of component combinations becomes too large, we will not be able to manage them. So that we don’t accidentally make our lives worse, we must limit the number of supported modules with a policy and provide infrastructure automation to reduce the amount of manual work required.
Continue reading

Copyright © 2017 Fedora Community Blog

Theme by Anders NorenUp ↑