Why Modularity?

[Terry Bowling]

Hello Fedora Community!

I would like to start a dedicated thread to focus on the “why” and use case
contexts to help clarify past and future decision making related to
Application Streams and Modularity.  As I follow some of the Fedora mailing
list threads and Pagure issues, I have noticed a recent trend of requests
to understand better “why” certain decisions were made, including use
cases, user stories, or other constraints.  I would like to ask that we
keep this thread focused on better understanding end user needs and
problems rather than delving into various reasons for not liking particular
decisions or implementation details.  Warning - there is a lot of reading
required for participation ;)

For those of you who are not familiar with me, I am a long time Fedora user
having started with Red Hat Linux 7 on DEC Alpha workstation in 2000 and am
now on the Product Management team for RHEL.  I joined the team near the
end of 2016 when modularity was already started but still being defined.
You can find me on IRC (tmoney) in a handful of Fedora channels.

First, I would like to challenge all of you with some background reading to
better understand some user personas.  I learned that Fedora had completed
some research starting in 2013 that is still relevant and is very similar
to research that we did for Red Hat Enterprise Linux, though there are many
differences as well.  You can read some of the user personas and use cases
in the Product Requirements Documents for Fedora Server [1] and Workstation
[2] circa 2013-2015.  Additionally, some of the background context was
explained in Fedora Classroom Session: Fedora Modularity 101 [3] which is
also a great read before you continue here.

Lastly before we dive in, I want to highlight a theme we’ll be revisiting:
Users.  There are many. They are diverse.  They have different and
sometimes conflicting needs. They are awesome.  Red Hat wants more of
them.  From what I have observed in communications from Fedora’s Council
and Project Leader, Fedora wants more of them too.  Again, Users are
awesome.  They are the reason we are doing this.  How can we empower them
to benefit from Fedora and be an answer to their problems and goals?
Without them, what are we doing all of this for?

Okay, let’s dive in.  Everything below is paraphrased from many documents
and discussions over the past few years.  Hopefully I did not miss
anything.  From the personas above, as well as what we have learned from
other research activities and countless conversations with end users, we
have a number of takeaways:

   1.

   Fedora has a diverse spectrum of end users to satisfy.
   2.

   Fedora has multiple personas of Developers:  Two in particular being
   Fedora distribution developers/maintainers and non-distro developers who
   use the tools, languages, and applications to solve other goals.  I
   emphasize this because these developer personas often have conflicting but
   equally valid needs.
   3.

   The “Too Fast / Too Slow” problem and demand for access to select
   content provided with different life cycles.
   4.

   Third party repositories, as great as they may be, sometimes introduce
   incompatibilities as they are not inherently built and tested as a part of
   the distribution.  This applies to Copr as well.  Some Users worry that
   using content not curated and tested as part of this distribution will
   cause them future headaches.  Other users embrace this and want to play
   with the latest versions with less concern of breakage.
   5.

   Drastic, incompatible changes can be extremely disruptive to many users.


RHEL adds to this a few nuances based on user feedback:

   1.

   Users mostly care about their business needs, usually in the form of
   their important workload application or managing their environment.  In the
   end, most don’t care about the novel technology solutions.  What they care
   about is:  “Does it make the workload app that I care about faster, more
   stable, or more manageable?”  At the end of the day, all of our technical
   shenanigans are irrelevant.  Only their workload applications, and making
   their workload infrastructure more manageable, matters to them.
   2.

   Average users have trouble finding and staying current on many different
   content sources (repositories).  RHEL had Extras, Optional, Supplementary,
   and many more when factoring in layered products such as OpenStack and
   similar.  Anything not in the default repositories were confusing or
   non-intuitive to find.
   3.

   Users wanted more options provided as a vendor curated and tested
   content set.  Third party sources are often not trusted to maintain
   compatibility over time.
   4.

   Users had trouble understanding the life cycle of upstream software
   compared to RHEL’s 10 year life cycle and support.
   5.

   Most organizations or users may fit multiple personas at the same time,
   according to different needs that they have.
   6.

   Feedba

Re: RHEL 9 and modularity

[Terry Bowling]

On Tue, Jun 23, 2020 at 2:33 PM clime  wrote:

>
> So I don't really get even after almost five years where modularity is
> going or what it wants to achieve. I don't understand its use-case for
> any of Fedora, RHEL, and CentOS because disabling
> parallel-installability to allow parallel availability is imho not
> really an option. But yeah...maybe I am missing some angle. In that
> case, please, explain it to me because I would really like to
> understand...
>
> clime
>

clime,
I just started a new thread where I try to share some background history
and context.  Hopefully it helps.  It should direct you to all of the other
documentation that explains most of your questions.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/SHMBYIGHHQYMNYD4HL2LV45BVZVZ3I5B/
___
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

Feedback on Application Streams and modularity

[Terry Bowling]

Hello Fedora friends!

I would like to follow up and collect your input on Application Streams and
modularity after all of the discussions over the past month.  We have been
listening and brainstorming on how to proceed with both the tooling, user
experience, and communicating better upstream for this process.

The team working on modularity in Fedora posted some revisions to the Fedora
modularity documentation .
Additionally, I described the end user experience expectations in this
thread
,
essentially describing why fully automated stream switching cannot occur
for a sane distro environment- at least at our current level of
understanding and tooling.  While my description was certainly focused on
the RHEL user perspective, as a long time Fedora user I will say this is
equally true for many Fedora users.

That said, I am hoping you could share your collective wisdom and provide
us feedback on the following:

1.  Have we better communicated the current features and goals of
Application Streams and modularity, primarily focused on end users?

2.  Does this help developers better understand the current limiting state
and challenges for both stream and other tooling limitations?


3. What can you share from commercial ISV and/or community developer
perspectives, and with respect to the user experience and stable distro
goals previously described for Application Streams, do you have
recommendations or requests for specific behaviors or tooling needed to
benefit the Fedora and RHEL ecosystems?  Such as but not limited :


a. How to provide the ability to switch streams without breaking a user's
choice or need for a different AppStream in the dependency chain.


b. What feature or tooling gaps still exist for creating community or
commercial products for RHEL & Fedora?

c. Anything I did not think to ask?


Thank you for your feedback!
-Terry
___
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

Feedback on Application Streams and modularity

[Terry Bowling]

Hello Fedora friends!

I would like to follow up and collect your input on Application Streams and
modularity after all of the discussions over the past month.  We have been
listening and brainstorming on how to proceed with both the tooling, user
experience, and communicating better upstream for this process.

The team working on modularity in Fedora posted some revisions to the Fedora
modularity documentation <https://docs.fedoraproject.org/en-US/modularity/>.
Additionally, I described the end user experience expectations in this
thread
<https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/FDWXVDV2GFAZGKLE34B4UBOONGFW5HZ5/>,
essentially describing why fully automated stream switching cannot occur
for a sane distro environment- at least at our current level of
understanding and tooling.  While my description was certainly focused on
the RHEL user perspective, as a long time Fedora user I will say this is
equally true for many Fedora users.

That said, I am hoping you could share your collective wisdom and provide
us feedback on the following:

 1.  Have we better communicated the current features and goals of
Application Streams and modularity, primarily focused on end users?

 2.  Does this help developers better understand the current limiting
state and challenges for both stream and other tooling limitations?

 3. What can you share from commercial ISV and/or community developer
perspectives, and with respect to the user experience and stable distro
goals previously described for Application Streams, do you have
recommendations or requests for specific behaviors or tooling needed to
benefit the Fedora and RHEL ecosystems?  Such as but not limited :

  a. How to provide the ability to switch streams without breaking
a user's choice or need for a different AppStream in the dependency chain.

  b. What feature or tooling gaps still exist for creating
community or commercial products for RHEL & Fedora?

  c. Anything I did not think to ask?

Thank you for your feedback!
---
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.
___
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

Re: Modularity vs. libgit

[Terry Bowling]

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  wrote:

> On Mon, Jun 17, 2019 at 2:29 PM Colin Walters  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 

Re: Modularity vs. libgit

[Terry Bowling]

Oh, I forgot to add that related to parallel installations, when
conflicting modules are desired, generally containerization or
virtualization is the recommended solution.  However, this is from the RHEL
user persona perspective.  We realize that is a very different user persona
from say a developer working in Fedora Rawhide.

Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.



On Mon, Jun 17, 2019 at 4:04 PM Terry Bowling  wrote:

> 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 1

Re: LibreOffice packages

[Terry Bowling]

I appreciate and am empathetic to all of those carrying the burden of this
and the thousands of other RPM packages.  As a users of Fedora + RPM
Fusion + Cinnamon Desktop as my daily laptop driver since 2011, I love
Fedora and am a heavy user of Flatpacks.  So thank you all.

That said, I will point out that I have heard of at least 4
enterprise customers who use libreoffice as a headless file conversion
utility.  I have seen it used in customer facing production workflows, such
as a financial user support website to handle file uploads provided by end
users, as well as medical health records systems used by hospitals and
doctors offices.
https://www.libreofficehelp.com/batch-convert-writer-documents-pdf-libreoffice/

I am not asking for a change in strategy.  I understand our resource
challenges.  I only wanted to share this perspective.  Packaging the RPMS
in EPEL could alleviate the pain for these customers in the RHEL 10
timeframe, as well as a container image (maybe built from the rpms pulled
from EPEL?).

Hope this is helpful.  And again, THANK YOU!

Terry Bowling
Sr. Product Manager - RHEL Installation & Build Services Experience
Red Hat, Inc.




On Thu, Jun 1, 2023 at 2:31 PM Matthias Clasen  wrote:

> Hey,
>
> as you've probably seen, the LibreOffice RPMS have recently been orphaned,
> and I thought it would be good to explain the reasons
> behind this.
>
> The Red Hat Display Systems team (the team behind most of Red Hat’s
> desktop efforts) has maintained the LibreOffice packages in Fedora for
> years as part of our work to support LibreOffice for Red Hat Enterprise
> Linux. We are adjusting our engineering priorities for RHEL for
> Workstations and focusing on gaps in Wayland, building out HDR support,
> building out what’s needed for color-sensitive work, and a host of other
> refinements required by Workstation users. This is work that will improve
> the workstation experience for Fedora as well as RHEL users, and which, we
> hope, will be positively received by the entire Linux community.
>
> The tradeoff is that we are pivoting away from work we had been doing on
> desktop applications and will cease shipping LibreOffice as part of RHEL
> starting in a future RHEL version. This also limits our ability to maintain
> it in future versions of Fedora.
>
> We will continue to maintain LibreOffice in currently supported versions
> of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of
> those releases (as published on the Red Hat website). As part of that, the
> engineers doing that work will contribute some fixes upstream to ensure
> LibreOffice works better as a Flatpak, which we expect to be the way that
> most people consume LibreOffice in the long term.
>
> Any community member is of course free to take over maintenance, both for
> the RPMS in Fedora and the Fedora LibreOffice Flatpak, but be aware that
> this is a sizable block of packages and dependencies and a significant
> amount of work to keep up with.
>
> Matthias
> ___
> 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
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
___
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
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Proposed Modular Policy for Fedora ELN

[Terry Bowling]

On Thu, Aug 20, 2020 at 2:18 PM Stephen Gallagher 
wrote:

> On Thu, Aug 6, 2020 at 10:46 AM Miro Hrončok  wrote:
> >
> > On 05. 08. 20 21:36, Stephen Gallagher wrote:
>
... snip

> >
> > I sincerely don't understand the RHEL's need for default modular
> streams, but
> > when I tried to query the motivation behind this, the answers haven't
> made it
> > any better:
> >
> >
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YIUXL2AWY3GKITU4TBUSKL2IUHDUPB26/
> >
>
> Josh listed some of the key reasons behind default streams: that
> enterprise customers don't like to learn new commands. So default
> streams allowed us to package content with shorter-than-RHEL-lifetime
> and still `yum install foo` would install something the customer could
> use.
>

To expand on this a bit further, the product requirements for RHEL 8
Application Streams were to provide new software version options that were
not disruptive to the end user and did not present a jarring experience
during first impressions of RHEL 8.  This included, but not limited to,
examples such as:

 - As a SysAdmin, I need my kickstart file to work on the next release so
that I can easily test and evaluate using my org's standard configuration.
This is an important reality to improve adoption of RHEL 8.  We had
received much feedback from users in the past that "if my kickstart file
does not work, I don't know when I'll find to troubleshoot why; I'll just
set it aside for another day" [paraphrased].  So the request was that if
they kickstart file listed "mariadb-server" the compatibility was there for
the default to just work, with minimal edits to the config file.  A user
*could* specify a modular version with @mariadb:10.3/server if they *chose*
to be that specific.  But we needed a default mechanism to not break user
experience.

- As a SysAdmin, I need my automation scripts to work on the next release
so that I can easily incorporate it into our environment.
Roughly the same as kickstart.  Our customers are more dependent on
automation than ever before, whether that's shell scripts or ansible.

And similar example scenarios.  So in a nutshell, the idea was to not
*force* the user to care about modularity unless they *wanted* to care.  If
they just wanted to treat it like the RHEL 7 experience relying on our
recommended defaults, provide that experience.  If they cared about
different app versions, they had a native mechanism to enable that without
figuring out a myriad maze of different repositories.  That is the User
Experience we (PM) requested.  Default modules were the implementation
solution that engineering recommended considering all other constraints.

To be fair, we are biased towards the enterprise user/customer experience
(note: that is a different persona than a package or distro maintainer).
Without these users, we all have a major problem.  And we know that RHEL 7
faced serious adoption resistance that we still receive negative feedback
on even today.  We wanted RHEL 8 adoption to be much smoother and easier
for our users.  Unfortunately, for the developer and maintainer personas it
has been more painful.  I hope we have expressed well enough that we are
listening to all of our developers and working to resolve that.

Hope that helps provide more clarity.

Thank you,
Terry Bowling
Sr. Product Manager - RHEL Automation & Management
Red Hat, Inc.
___
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

Re: [EPEL-devel] Re: Ansible in EL7

[Terry Bowling]

Hopefully I can help provide some clarity on this topic, though there is no
easy answer to all aspects.  We worked with the Ansible product team to
bundle the Ansible Engine product with the RHEL Subscription.  This wording
is important to address the following which we have learned over the past
year are critically important.

   - Ansible Engine is a distinct and separate product, with *separate
   channel / repo*, lifecycle, release cadence, and support policies.
   - Make AE ubiquitous and easily accessible - full support comes with a
  subscription
   - As a separate product bundled with RHEL, it is *not* RHEL official
   content and can go back into EPEL (which was very important).
   - The version of Ansible previously provided in RHEL Extras is now
   officially deprecated

Changing the package name in one channel does not make all of the problems
go away.  There are still Require and Provides metadata tags that would
inevitably cause future conflicts.  And probably other issues that I cannot
think of at the moment.

So if a user decides to enable the AE & EPEL channels, then I guess they
could use repo priorities to decide which version is more important to
them.  If we decide for them, we will be wrong 50% of the time.

If they are comfortable with EPEL content, I would assume they would simply
not enable the AE channel and problem is solved.  At least we are not
making them choose between Extras and EPEL now.  With that said, is this
still a problem?


Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.


On Wed, Apr 11, 2018 at 6:13 PM, Nico Kadel-Garcia  wrote:

> On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen 
> wrote:
> > On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
> >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy 
> wrote:
> >>
> >>> I'm not in Ansible engineering or product management so take this with
> a
> >>> grain of salt. My understanding is that cadence of Ansible releases and
> >>> its aggressiveness in API changes makes it a bit less suitable to
> follow
> >>> a traditional RHEL 7 release cadence. A separate product channel allows
> >>> them to update packages at own cadence.
> >>>
> >>> I wonder how re-packaging for CentOS targets could happen with this
> >>> approach and probably moving it back to EPEL7 is indeed something that
> >>> makes more sense.
> >>
> >> Wouldn't a separate RHEL channel for a separate product, such as
> >> ansible, mean a separate channel for CentOS to avoid precisely this
> >> confusion? Mixing it into EPEL and having it on a separate RHEL
> >> channel would be *bad* for anyone who activates that separate channel.
> >> They'd have to filter it out of EPEL to ensure that the streams don't
> >> get crossed on any updates from Red Hat. I understand that this is one
> >> of the main reasons EPEL never carries packages that overlap with RHEL
> >> published software.
> >
> > It is a lot more nuanced than that. EPEL builds packages that do not
> > overlap with the following channels:
> >
> >
> > rhel-7-server-extras-rpms/
> > rhel-7-server-optional-rpms/
> > rhel-7-server-rpms/
> > rhel-ha-for-rhel-7-server-rpms/
> > rhel-server-rhscl-7-rpms/
> >
> > These are chosen because they were the base set originally and other
> > channels which might be available can have items which conflict with
> > each other. This means that EPEL can conflict with somethings inside
> > of "RHEL" but so can things are in "RHEL".
>
> EPEL is a default, critical requirement for many tools, including Chef
> and mock. Many environments running RHEL or CentOS 6 could not be used
> without EPEL's plethora of useful tools. RHEL channels can conflict
> with each other because they are enabled on an individual host, case
> by case basis. I think, from old experiences, that having *anything*
> in EPEL that overlaps with any RHEL published channel is begging for
> pain.
>
> It may cause pain to current RHEL ansible users, but I think that the
> EPEL package needs to be renamed to something like "ansible25" to
> avoid conflicts with the RHEL channel.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [EPEL-devel] Re: Ansible in EL7

[Terry Bowling]

Re-adding epel-devel as I was previously not a member and received a
rejection notice.

Thank you,
Terry Bowling
Sr. Technical Product Manager - RHEL Systems Mgmt
Red Hat, Inc.


On Sat, Apr 14, 2018 at 6:58 AM, Terry Bowling  wrote:

> Hopefully I can help provide some clarity on this topic, though there is
> no easy answer to all aspects.  We worked with the Ansible product team to
> bundle the Ansible Engine product with the RHEL Subscription.  This wording
> is important to address the following which we have learned over the past
> year are critically important.
>
>- Ansible Engine is a distinct and separate product, with *separate
>channel / repo*, lifecycle, release cadence, and support policies.
>- Make AE ubiquitous and easily accessible - full support comes with a
>   subscription
>- As a separate product bundled with RHEL, it is *not* RHEL official
>content and can go back into EPEL (which was very important).
>- The version of Ansible previously provided in RHEL Extras is now
>officially deprecated
>
> Changing the package name in one channel does not make all of the problems
> go away.  There are still Require and Provides metadata tags that would
> inevitably cause future conflicts.  And probably other issues that I cannot
> think of at the moment.
>
> So if a user decides to enable the AE & EPEL channels, then I guess they
> could use repo priorities to decide which version is more important to
> them.  If we decide for them, we will be wrong 50% of the time.
>
> If they are comfortable with EPEL content, I would assume they would
> simply not enable the AE channel and problem is solved.  At least we are
> not making them choose between Extras and EPEL now.  With that said, is
> this still a problem?
>
>
> Thank you,
> Terry Bowling
> Sr. Technical Product Manager - RHEL Systems Mgmt
> Red Hat, Inc.
>
>
> On Wed, Apr 11, 2018 at 6:13 PM, Nico Kadel-Garcia 
> wrote:
>
>> On Wed, Apr 11, 2018 at 11:07 AM, Stephen John Smoogen 
>> wrote:
>> > On 11 April 2018 at 10:02, Nico Kadel-Garcia  wrote:
>> >> On Wed, Apr 11, 2018 at 4:43 AM, Alexander Bokovoy <
>> aboko...@redhat.com> wrote:
>> >>
>> >>> I'm not in Ansible engineering or product management so take this
>> with a
>> >>> grain of salt. My understanding is that cadence of Ansible releases
>> and
>> >>> its aggressiveness in API changes makes it a bit less suitable to
>> follow
>> >>> a traditional RHEL 7 release cadence. A separate product channel
>> allows
>> >>> them to update packages at own cadence.
>> >>>
>> >>> I wonder how re-packaging for CentOS targets could happen with this
>> >>> approach and probably moving it back to EPEL7 is indeed something that
>> >>> makes more sense.
>> >>
>> >> Wouldn't a separate RHEL channel for a separate product, such as
>> >> ansible, mean a separate channel for CentOS to avoid precisely this
>> >> confusion? Mixing it into EPEL and having it on a separate RHEL
>> >> channel would be *bad* for anyone who activates that separate channel.
>> >> They'd have to filter it out of EPEL to ensure that the streams don't
>> >> get crossed on any updates from Red Hat. I understand that this is one
>> >> of the main reasons EPEL never carries packages that overlap with RHEL
>> >> published software.
>> >
>> > It is a lot more nuanced than that. EPEL builds packages that do not
>> > overlap with the following channels:
>> >
>> >
>> > rhel-7-server-extras-rpms/
>> > rhel-7-server-optional-rpms/
>> > rhel-7-server-rpms/
>> > rhel-ha-for-rhel-7-server-rpms/
>> > rhel-server-rhscl-7-rpms/
>> >
>> > These are chosen because they were the base set originally and other
>> > channels which might be available can have items which conflict with
>> > each other. This means that EPEL can conflict with somethings inside
>> > of "RHEL" but so can things are in "RHEL".
>>
>> EPEL is a default, critical requirement for many tools, including Chef
>> and mock. Many environments running RHEL or CentOS 6 could not be used
>> without EPEL's plethora of useful tools. RHEL channels can conflict
>> with each other because they are enabled on an individual host, case
>> by case basis. I think, from old experiences, that having *anything*
>> in EPEL that overlaps with any RHEL published channel is begging for
>> pain.
>>
>> It may cause pain to current RHEL ansible users, but I think that the
>> EPEL package needs to be renamed to something like "ansible25" to
>> avoid conflicts with the RHEL channel.
>> ___
>> devel mailing list -- devel@lists.fedoraproject.org
>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>>
>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: dnf history - change in how rpmdb checksum is computed

[Terry Bowling]

Regarding these two questions:

Are there any concerns about such change?
>> I believe that >90% users wouldn't notice anything as it's related to the
>> history database only.
>
>

> On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko <
> ignatenkobr...@fedoraproject.org> wrote:
> Since we've changed the database entirely, what's the point of keeping
> same algorithm for calculating checksum?


On Wed, Jul 18, 2018 at 9:34 AM Daniel P. Berrangé 
> wrote:
> What's the benefit in changing to be compatible with YUM as opposed
> to stickin with current alogorithm ?
>
> Surely if we don't change it, even fewer users will notice that DNF's
> behaviour is different from YUM's, since DNF has been the default for
> many releases now.
>
> I could understand the motiviation to stay compatible with YUM if we
> were only just about to switch Fedora from YUM to DNF, but time is
> way in the past now. Shouldn't we optimize for the fact that DNF is
> the more widely deployed & used tool, and thus not worry about
> YUM compatibility in respect of the history DB ?


It is true that going forward in the Fedora world it matters less.  It is
more of an impact for yum-3 compatibility as yum4/dnf is being considered
in the RHEL7/CentOS7 userspace environments as described at
https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/

Currently yum version 3 and what the proof-of-concept project is calling
yum4 work very well together side by side.  Users can safely switch back
and forth.  The major problem is yum/dnf histories being different and the
rpmdb checksum difference is a blocker for resolving the history
compatibility.

So think of this as an effort to bring package management parity between
Fedora, RHEL 7, & CentOS7, as the latter two still have a long life ahead
of them.

Hope that helps,
Terry
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WP7IKLV2WYNMZBECWPOQL4VOEW4ZV3PL/