[Userops] Antonio Terceiro's DebConf talk on packaging free software web applications
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
> - 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
> > 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
> > 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
> > 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:
> >> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Userops