env-and-stacks May 2015

env-and-stacks@lists.fedoraproject.org

9 participants
11 discussions

Council Engineering update
by Josh Boyer 13 Jul '15

13 Jul '15

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

4 5

Agenda for Env-and-Stacks WG meeting (2015-05-28)
by Honza Horak 28 May '15

28 May '15

WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Continue discussion about Fedora Rings -- how to gather feedback from users? who are our users? (https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-May/000783.ht…) * Council Engineering update (https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-May/000786.ht…) * RHSCL Docker images compatibility with Fedora/Atomic use cases (are SCL images as developed under https://github.com/sclorg/rhscl2dockerfile/ usable in fedora/atomic or do we search for something different?) * Open Floor

1 1

Agenda for Env-and-Stacks WG meeting (2015-05-21)
by Honza Horak 22 May '15

22 May '15

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

1 1

Fwd: Re: fedora-cloud/Fedora-dockerfiles GitHub
by Petr Hracek 21 May '15

21 May '15

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

1 0

Install only packages to prevent 3rd party app breakage
by Vít Ondruch 19 May '15

19 May '15

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

1 0

Agenda for Env-and-Stacks WG meeting (2015-05-14)
by Honza Horak 14 May '15

14 May '15

WG meeting will be at 17:00 UTC (13:00 EST, 19:00 Brno, 13:00 Boston, 2:00+1d Tokyo, 3:00+1d Brisbane) in #fedora-meeting-2 on Freenode. = Topics = * Anything related to yesterday's meeting about Fedora Project Planning Tools http://meetbot.fedoraproject.org/fedora-meeting/2015-05-13/infra-releng-cro… * Continue discussion about Fedora Rings -- how to make Fedora more modular * Docker images tips from SCL vs. OpenShift discussions * Open Floor

2 2

RFE: Stackable namespaced repositories
by Orion Poplawski 14 May '15

14 May '15

I've been working on trying to package python virtual environments with rpm (outline here: http://orionlibre.blogspot.com/2015/05/deploying-scientific-python-environm…). 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

1 0

Pulp-for-language-specific-repositories status update
by Nick Coghlan 12 May '15

12 May '15

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

2 1

Fedora Projects Tooling Meeting
by Adam Miller 08 May '15

08 May '15

Hello all, As a result from the WhenIsGood I sent out[0], the meeting to discuss Fedora Projects Tooling has been set for 2015-05-13 at 14:00 UTC https://apps.fedoraproject.org/calendar/infrastructure/2015/5/13/?tzone=UTC… Hope to see everyone there! -AdamM [0] - https://lists.fedoraproject.org/pipermail/env-and-stacks/2015-May/000777.ht…

1 0

Agenda for Env-and-Stacks WG meeting (2015-05-07)
by Honza Horak 07 May '15

07 May '15

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

env-and-stacks May 2015