Council Engineering update
by Josh Boyer
Hi Env&Stacks WG,
As part of the on-going Council updates, I'm organizing a Fedora
Engineering update. This includes the various WGs, rel-eng,
infrastructure, and a few others. The idea behind this is to give a
brief update of the work your group is doing towards the F23 and F24
releases. Think of this as a 5-10 minute "lightning talk" of the
highlights you want to see in those releases.
The meeting is July 7th. It would be excellent if you could have a
volunteer present the update for your group and stay around to answer
any questions. Worst case, please gather the information and send it
to me and I can do the overview, but representation from the group is
clearly preferred.
If you have questions, please let me know. The idea and format are
somewhat new, so we'll work through this as best we can.
josh
8 years, 9 months
Agenda for Env-and-Stacks WG meeting (2015-05-21)
by Honza Horak
WG meeting will be at 12:00 UTC (9:00 EST, 14:00 Brno, 8:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting-2 on Freenode.
= Topics =
* Follow-ups, if any progress has been made
* Install only packages to prevent 3rd party app breakage (see ML for
more info)
* Council Engineering update (see ML for more info)
* https://fedorahosted.org/council/ticket/26 -- gathering feedback from
users
* Env & Stacks Elections after F22
* Open Floor
I'll need to leave during the meeting for approx. 30 min. but I guess
I'm not necessary to be present whole time, there seem to be enough to
be discussed today.
Honza
8 years, 11 months
Fwd: Re: fedora-cloud/Fedora-dockerfiles GitHub
by Petr Hracek
Conversion between Scott and me regarding
Fedora_dockerfiles.
-------- Forwarded Message --------
Subject: Re: fedora-cloud/Fedora-dockerfiles GitHub
Date: Thu, 14 May 2015 10:02:21 -0500
From: Scott Collier <scollier(a)redhat.com>
To: Petr Hracek <phracek(a)redhat.com>
CC: Honza Horak <hhorak(a)redhat.com>, langdon(a)redhat.com, Václav Pavlín
<vpavlin(a)redhat.com>
On 05/14/2015 09:50 AM, Petr Hracek wrote:
> Hi Scott,
>
> first of all I would like to thank you for collecting
> Fedora-dockerfiles which are really useful for Fedora.
> My question is, we would like to update a bit more docker files and
> update them to the latest version
> and of course improve them?
This is music to my ears. Happy to have all the help I can get.
>
> Nowadays we will create pull requests so that you are able to track
> them and of course check them.
ack. Excellent.
>
> We would like to also add a test suite based on behave. What do you
> think about it?
Hmm. I need more information here. Are you saying you'd like to set up
some CI for Fedora-Dockerfiles using behave / jenkins as the framework
to accomplish this? If so, internal jenkins or creating something with
the Fedora Project? If not, please explain further.
> Would it be possible to add some of our colleagues as a co-maintainer?
Last week on the cloud-sig meeting I asked for co-maintainers. To my
surprise, many people stepped up to say they would help review PRs,
address issues, etc...
I would like to have it set up where each PR requires at least 2 LGTMs
to be merged. So if you have someone who can work in that capacity,
let's do it.
> How do you like this idea?
>
--
-Scott
Systems Design and Engineering
Follow Us: https://twitter.com/RedHatRefArch
Plus Us: https://plus.google.com/u/0/b/114152126783830728030/
Like Us: https://www.facebook.com/rhrefarch
8 years, 11 months
Install only packages to prevent 3rd party app breakage
by Vít Ondruch
Hello,
For a long time, I have the dream that RPM/YUM/DNF can native support
parallel installation of various versions of libraries side by side.
While this is quite complex problem, because you would need to be able
to define the upgrade path, the first approximation could be my proposal
to update installonlypkgs when release changes [1].
There is already long discussion in the ticket, but there is probably
missing one additional goal. Since Ruby applications are using Bundler
and the Rails applications tends to hardcode the exact version of Rails
which was used during the development, we typically freeze Rails updates
when Fedora stable is released and backport only security fixes, to
avoid breakage of Rails applications during Fedora lifetime.
Nevertheless, when the system is updated (e.g. F21 -> F22), the user
application is broken anyway and we don't have any chance to fix it.
My proposal fixes the issue at least a bit, since it leaves the old
packages installed. The package is updated only when the release
changes, this is either to fix packaging error or security issue. When
new version of that package is released, the old version is kept on the
system and new version will be installed side by side.
Of course this cannot be enabled for every package on the system, but
for packages such as rubygems- (which are non-conflicting between
versions), this would save some users gray hairs and motivate our users
to use the packaged version of Rails more. I believe that other package
management systems for other dynamic languages today allows to install
more versions of the same package on the system as well.
Thoughts?
Vít
[1] https://bugzilla.redhat.com/show_bug.cgi?id=845247
8 years, 11 months
RFE: Stackable namespaced repositories
by Orion Poplawski
I've been working on trying to package python virtual environments with
rpm (outline here:
http://orionlibre.blogspot.com/2015/05/deploying-scientific-python-enviro...).
While this particular project is python based, the same basic concept can be
applied to anything else that allows manipulating the load path - which is
pretty much everything (PATH, LD_LIBRARY_PATH, PERLINC, etc). I'm most
familiar with the HPC world which does this a lot - providing different
versions of various packages in a hierarchy and using environment modules to
allow users to load the desired stack at runtime. This is also essentially
the same thing that SCLs do, though SCLs are more isolated from the base system.
The big problem that this exposes in rpm packaging is "namespacing" the
rpms: rpms in the "stacked" repo can depend on packages in the system repos,
but not vice-versa. So we need to put them into a different namespace
manually (I'm using a %{?pyvenv_name_prefix} macro, SCLs use %{scl_prefix}).
Complicating this is that one needs to add the prefix to the names of other
packages in the repository when specifying requirements - which may not be
known ahead of time. It would be very nice if this could be handled
automatically.
What I think would work is if a repository could be marked as a "stacked"
repository and given a namespace - essentially a prefix to the names in the
repository. For example, my pyvenv-nwra repo could be given that prefix - and
marked as such - say with pyvenv-nwra:. Then when depsolving dnf would allow
dependencies in the pyvenv-nwra repo to be satisfied by packages in base
repositories but not allow the reverse. Installed packages/depnames would be
given the pyvenv-nwra: prefix to keep them separate from the system resources.
This strikes me as a complicated technical challenge, so I really would
like to hear back from the packaging ecosystem folks their thoughts about it.
But I really think this could move us into the model of providing software
stacks targeting different applications with different package/version
requirements that build upon a stable OS core while still allowing for the
tracking and deployment benefits of using rpm packages. And by having
pre-populated buildroots that make any needed macro changes (say %_prefix),
many packages could be built unmodified from the Fedora git repos as opposed
to having to hack in the namespace prefixes into the spec files.
- Orion
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
8 years, 11 months
Pulp-for-language-specific-repositories status update
by Nick Coghlan
As I mentioned at last week's E&S meeting, Randy Barlow, the author of
the pulp-python plugin, was at PyCon last month to present a poster on
his plugin, and Slavek and I both had a chance to have some good
conversations with him.
>From a Language Specific Repositories point of view, the two main
missing features were support for uploading wheel files (i.e. the
Python-specific format for prebuilt binaries) and for lazy mirroring
(i.e. acting as a caching proxy for PyPI, rather than as a full local
mirror).
Randy's amenable to adding the first to the plugin (we were far from
the only folks at the conference that raised that as a requirement),
while for the latter, the Pulp team are interested in pursuing that as
a general purpose capability offered by the plugin framework, rather
than it being specific to the Python plugin.
No ETA on either feature yet, though, so it makes sense to continue
with devpi for the pilot, and then look at Pulp again if we decide we
want to expand beyond Python.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia
8 years, 11 months
Agenda for Env-and-Stacks WG meeting (2015-05-07)
by Honza Horak
WG meeting will be at 12:00 UTC (9:00 EST, 14:00 Brno, 8:00 Boston,
21:00 Tokyo, 22:00 Brisbane) in #fedora-meeting-2 on Freenode.
= Topics =
* Follow-ups, if any progress has been made
* Docker images building within Fedora
* Containers-Testing-Framework
* Open Floor
8 years, 11 months
