Self-introduction & offer of assistance

Honza Horak hhorak at redhat.com
Mon Sep 15 12:43:54 UTC 2014


Hi Nick,

welcome and thanks for the idea! I've added it as the main topic for 
tomorrow's meeting, since it may require longer discussion.

Cheers,
Honza

On 09/15/2014 10:18 AM, Nick Coghlan wrote:
> Hi folks,
>
> I know some of you already, but since I just signed up to the list I
> figured it would be worthwhile explaining my interest in and perspective
> on the "Environment & Stacks" working group.
>
> I'm interested in the work of the Environments & Stacks working group
> from two perspectives:
>
> 1. As one of the chief cat herders in the upstream Python packaging
> ecosystem, I'm interested in working more closely with Linux
> distributions to resolve some of the issues that can make working with
> Python software on Linux more complicated than it needs to be. My Python
> Packaging 2.0 talk at linux.conf.au 2014 covers that aspect pretty well,
> and the write-up at http://lwn.net/Articles/580399/ is a good summary.
>
> 2. In my day job, I'm the deployment & provisioning architect for
> several of Red Hat's internal development support tools, including
> beaker-project.org and bugzilla.redhat.com. The primary languages we
> currently need to support in production are Python, Ruby, Perl, and Java
> (along with the ubiquitous JavaScript).
>
> I've been having various off-list discussions with Slavek and Langdon
> White (Red Hat's developer experience architect), but realised recently
> that it made more sense to take those discussions out of private email
> and bring them to the Envs & Stacks working group.
>
> In joining this group, my main aim is to help work out a good developer
> workflow for internal use in such a way that similarly smooth workflows
> can be adopted by anyone else developing on Fedora and deploying on
> CentOS or RHEL (including as containers running on Project Atomic or
> RHEL 7).
>
> In that vein, my current architectural concept is leaning towards a
> model where applications are structured along the following lines:
>
> - Application & dependencies (language specific)
> - Language runtime (Software Collections)
> - Base OS layer (Fedora/CentOS/RHEL)
>
> By default, we'd just use the versions of things that were in the base
> OS layer. If we needed something more specific (whether older on Fedora,
> or newer on CentOS/RHEL), we'd prefer to get it through a software
> collection if it was available. Within a language runtime, we'd switch
> away from yum/rpm entirely and instead use the language specific tools.
>
> The advantage of this approach is that:
>
> 1. It can be applied directly to existing applications that use upstream
> packaging tools
> 2. Switching to pip (et al) inside the software collection avoids any
> remaining issues with depending on software collections
> 3. It plays nice with any deployment target (bare metal, VM, container
> image build)
>
> This brings me to a notion which isn't in the current E&S PRD, but which
> *would* be helpful to us if we adopt this deployment model, rather than
> always deploying software as RPMs: having language specific repos
> available where the packages had been through the same level of review
> as was needed to get into Fedora Playground, but still used the
> *language* level packaging formats. (This isn't actually my idea, it
> came up in a conversation with Langdon. However, it ties in so well with
> other things I'm doing, I decided to take it and run with it).
>
> However, I'll post that idea in its own thread, rather than tacking it
> on here.
>
> Regards,
> Nick.
>



More information about the env-and-stacks mailing list