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

[Carl Karsten]

On Tue, Aug 25, 2015 at 1:15 PM, Christopher Allan Webber <address@hidden> 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 <
> address@hidden> 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
>> address@hidden
>> http://lists.mediagoblin.org/listinfo/userops
>>
> _______________________________________________
> Userops mailing list
> address@hidden
> http://lists.mediagoblin.org/listinfo/userops

_______________________________________________
Userops mailing list
address@hidden
http://lists.mediagoblin.org/listinfo/userops