Self-introduction & offer of assistance

[Nick Coghlan]

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.

-- 
Nick Coghlan
Red Hat Hosted & Shared Services
Software Engineering & Development, Brisbane

HSS Provisioning Architect