[Userops] Antonio Terceiro's DebConf talk on packaging free software web applications

Carl Karsten carl at nextdayvideo.com
Tue Aug 25 15:28:39 EDT 2015


On Tue, Aug 25, 2015 at 1:15 PM, Christopher Allan Webber <
cwebber at dustycloud.org> wrote:

> So I think I'm -1 on environment variables, and here's why:
>
>  - I agree that environment variables provide a sense of coherence
>    that's "already here", and so that's tempting.  But!
>
>  - Environment variables are the POSIX global variable system, and I've
>    had enough troubles fighting global variables the last few years.
>    I'd like to not invent new systems to fight them all over again.
>
>  - Environment variables are an extremely lossy format, being
>    strings-only.
>
>  - The primary goal is a shared state, but what if deploying multiple
>    applications?  This seems to move back towards the problem of
>    assuming packages are going to roll out one apache config for a user,
>    and that's all the user needs is one application.
>
>    Okay, you might say, we'll just swap out the environment variables
>    every time we launch an application!  This is still tricky when it
>    comes to, say, an application that is dependent upon connections to
>    two separate postgres daemons, which you might imagine are now
>    expecting environment-based configuration.
>
>  - It seems to me that a good system is a combination of reflection
>    upward towards a user interface for configuration, and then back down
>    again *through composition*.
>
>    (Notice, I do not expect end-users to be doing this composition
>    themselves, it's important to notice the reflection upwards as well
>    as the passing downwards to determine the user's system.)
>
>    It's unfortunate that we have so many configuration format systems
>    (which puts some towards system recipe authors), however, the
>    benefits of having an application built to run based off of the
>    composed configuration as made by very high level user decisions is
>    much stronger, and in this case at least you may consider both
>    configuration files and program arguments to be the equivalent to a
>    function invocation.  It's easy to invoke a function again and again
>    with different arguments; in a system where those functions read from
>    global variables, things become much trickier.
>


I think we need to better define global.

env vars set in /etc/profile/... are very global.

env vars set in ~/.bashrc are less global.

env vars set as part of the app's invocation are pretty not global.




>
>  - Patching all applications to become environment variable aware and
>    eschew their configuration formats is asking a lot of applications,
>    while introducing many new problems.
>
> So... if a new system were to come about that was environment variable
> based, I have to feel like I'd be pretty unenthused aobut it.
>
>
> Asheesh Laroia writes:
>
> > I was super impressed by this talk.
> >
> > One thing I realized today, a few days after seeing the talk (on
> Saturday)
> > is:
> >
> > I wonder if a lot of the config can be done, rather than by chef scripts
> > mutating files on-disk, by passing environment variables to the app. That
> > way, hopefully, the environment variables can store site-specific
> details,
> > similar to how Heroku describes "12 factor apps": http://12factor.net/
> >
> >
> > If that's unclear, let me know and I can try to say more. I'm curious
> what
> > you think, Antonio.
> >
> > On Mon, Aug 24, 2015 at 9:31 AM, Christopher Allan Webber <
> > cwebber at dustycloud.org> wrote:
> >
> >> Hello all,
> >>
> >> If you haven't watched it, I highly recommend watching:
> >>
> >>
> >>
> http://gemmei.acc.umu.se/pub/debian-meetings/2015/debconf15/Packaging_the_free_software_web_for_the_end_user.webm
> >>
> >> There are some interesting parts of this talk:
> >>
> >>  - First of all, most of the concerns I have had about deploying on
> >>    existing distributions have been reflected in this talk!  (Oh okay,
> >>    it turns out that's no coincidence, Deb and I's FOSDEM talk was
> >>    mentioned in here.  But I think regardless, we're hitting peak
> >>    zeitgeist on what the problem domain is...)
> >>
> >>  - Several components were identified as not being totally covered by
> >>    existing packaging solutions, including deploying multiple instances
> >>    of applications and handling shared configuration variables.
> >>
> >>  - In the talk, the idea of an "application" as a layer above "packages"
> >>    is proposed... right on!
> >>
> >>  - There's an application being hacked on called shak that has both a
> >>    command line and a web user interface.  Cool!
> >>
> >>  - Under the hood, Shak uses Chef.  I think the idea of a scriptable
> >>    configuration management system is the right choice... I think some
> >>    issues with Chef were mentioned.
> >>
> >> As a side note, Shak appears very similar to a direction of things I was
> >> exploring before I went full-on Guix, when I was very interested in
> >> solutions involving keeping Debian and etc systems up to date.  I was
> >> working on a recipe system that was using s-expressions with Hy and then
> >> later Guile, I think partly because I ran into some of the issues
> >> mentioned with Chef when I tried doing things with Salt and other
> >> tools...
> >>
> >> Anyway, even though my focus has shifted to Guix, I think Debian is
> >> super important and will be for a long time, and I think multiple groups
> >> working on this stuff is important.  A lot of the ideas happening in
> >> Shak are the right ones, I think.
> >>
> >> Cool stuff!  Happy userops'ing everyone,
> >>  - Chris
> >> _______________________________________________
> >> Userops mailing list
> >> Userops at mediagoblin.org
> >> http://lists.mediagoblin.org/listinfo/userops
> >>
> > _______________________________________________
> > Userops mailing list
> > Userops at mediagoblin.org
> > http://lists.mediagoblin.org/listinfo/userops
>
> _______________________________________________
> Userops mailing list
> Userops at mediagoblin.org
> http://lists.mediagoblin.org/listinfo/userops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mediagoblin.org/pipermail/userops/attachments/20150825/c868896f/attachment-0001.html>


More information about the Userops mailing list