Regarding to a few of the questions about why modularity was created in the
first place (paraphrased), I can offer the following background. Note, I
was not on the team at the very beginning but have been very involved for
the last ~2 years.
Do not consider the following to be formal answers, guidance, or laws of
nature. I'm only trying to help share some perspective.
>From the RHEL Product Management (PM) side, we observed the following
customer+market problems. Note this is not a perfect list but a rough,
paraphrased, quick brain dump:
- Customers think we had too many repos. It is hard to find what they
need.
- optional, supplementary, extras, software collections, and more...
- Customers need more options that are fully supported to meet their
production workload requirements.
- 1. "I need as little change as possible. I will stick with the
version of DB provided with X.0 release for the next 10 years."
- 2. "I need newer versions of xyz to benefit from some features."
- 3. A few states in between 1 & 2.
- "Software Collections are helpful and provide us more choices, but the
user experience is awkward and most of the time we only install 1 version
at a time, with the exception of a few programming language environments
(multiple python, gcc, and so forth)." And it's a different repo and a
non-native software management workflow.
- RH need the distinction to provide realistic life cycles that matched
the true upstream life cycle. 5 year life cycles of DB's are a good
example, as well as the python 2 reaching its end of life. Application
Stream modules help with defining this, as well as enabling customers to
block access to versions that have reached the end of their life cycle.
Thus, RHEL PM asked for a method so solve these problems above. PM
objectives ideally should not dictate the technical implementation but
rather focus on addressing the customer/market problems, user experience,
supportability, and things like that. My understanding was that
package-name-versioning could have been acceptable to PM, but there were a
number of support and engineering challenges which led to the modularity
design.
That said, some of the internal guidance was that:
- Only select modules are parallel installable, primarily programming
languages such as python.
- while modularity could help with some traditional repository
challenges, it does not solve all, nor does it make RPM dependency problems
go away. Therefore only select things in Appstream should be modularized,
usually when collections of rpms serve a common use case, such as databases
or Identity Management.
- The RHEL distribution ensures a sane state of compatibility to
ensure a good user experience. So the analogy of conflicts with many
different repos does not magically go away.
- Disciplined distribution content management policies and
compatibility are still required as if they were different repos.
- Default stream versions defined so that if a user wants a simple RHEL
7 like experience, they have it. They are not forced to use modularity
unless they want to or their workload dictates different modules.
- Changing streams is a manual process, at least until modularity
matures. If a customer chooses a stream for their workload, we cannot
break that customer's workload. Though shalt do no harm. Therefore
auto-stream switching is off-limits in RHEL. At least for now until we
further understand customer demand and the risk impact as Appstream grows
to include more modules.
That's all I can think of right now and I might have missed some things.
Again, it does NOT answer many of the questions in this thread and we know
we have future work to do. I would be happy to consult with, but not
dictate to, Fedora members on defining their own policy guidelines if
desired.
Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.
On Mon, Jun 17, 2019 at 2:52 PM Neal Gompa <ngomp...@gmail.com> wrote:
> On Mon, Jun 17, 2019 at 2:29 PM Colin Walters <walt...@verbum.org> wrote:
> >
> > On Mon, Jun 17, 2019, at 4:47 AM, Michael Schroeder wrote:
> > > On Fri, Jun 14, 2019 at 12:12:01PM -0400, Neal Gompa wrote:
> > > > I would actually really like to see rpm's multiversioning
> capabilities
> > > > extended to support this.
> > >
> > > I'd actually prefer to drop the multiversion mode for the kernel and
> > > instead add the version to the kernel package name.
> >
> > FWIW in rpm-ostree we go to some lengths to explicitly undo the libdnf
> default of multiple versions for the kernel, because the ostree side of
> things effectively multi-versions all of userspace as well. We're always
> creating a new root, so there's no concern about removing modules from the
> running kernel (any more than there is a similar concern for userspace
> components). An ostree deployment includes a (kernel+initramfs,userspace)
> as a pair; two deployments can happen to share a kernel, or not. A bit
> more info in
> > https://github.com/projectatomic/rpm-ostree/pull/1346
>
> RPM-OSTree is functionally irrelevant in this discussion, since it has
> its own behavior patterns and eschews compatibility with the greater
> ecosystem anyway. It doesn't even support modules, so this whole
> discussion doesn't even matter for systems built on RPM-OSTree.
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
