1. Messages
  2. Immutability of applications

Re: Immutability of applications

Marco Nicosia
 

John,

I'd like to understand more about what you are hoping to accomplish.

Are you trying to detect gaps where a new env var has been pushed, but the
app has not been restarted? Is this for monitoring/compliance or debugging
purposes?

It seems like Apps these days get configuration from a pretty wide variety
of sources, env variables being only one. Apps also ship with defaults,
UNIX defaults (max filedes, semaphores, etc), and apps sometimes adjust
their settings based on values in SQL or Redis*, etc.

Each app cares about these settings differently, some are sensitive to RAM
available, but not number of open files, etc.

I only ask because it seems like asking for "effective environment" vs
"actual environment" is only a subset of configurations.

The infrastructure can only express what has been provided to the app, but
for any number of reasons, may not represent the current actual running
state of the app.

I understand that it means more work for the app dev, but I often implement
a quick "/config" endpoint in my apps. This allows me to verify what
configuration the App is actually using at a given moment.

It's a more comprehensive way of validating that all "intended
configuration," is in fact actual configuration.

--
Marco Nicosia
Product Manager
Pivotal Cloud Foundry

* A quick example: the NOC can use an admin endpoint to toggle on/off an
experimental feature, which is detected via Redis, etc.

On Monday, November 9, 2015, Dieu Cao <dcao(a)pivotal.io> wrote:

Hi John,

I had been thinking about this a bit more, and I think it would be
reasonable to consider adding an end point that is similar to the /stats
end point, that queries Diego, to get actual state on environment variables
and as part of that VCAP_SERVICES for the running app instances.
Thoughts on that approach? Would that help address the problem?

-Dieu

On Wed, Nov 4, 2015 at 9:03 AM, john mcteague <john.mcteague(a)gmail.com
<javascript:_e(%7B%7D,'cvml','john.mcteague(a)gmail.com');>> wrote:

I had this conversation with a few different people during the berlin
summit and promised one of them I would repeat it on the mailing list today
to get further feedback.

Today, once we push an application, the droplet is immutable. It doesnt
change until you push the application again or restage. I believe the
entire container could change without a new push if you upgrade the rootfs
and restart all the apps (which the CF operator would do).

However, the environment vars and service bindings can be changed on an
application but they would not take affect until the next restart.The CF
API would report these changes as active when you run *cf env *or *cf
services. *There is no distinction between desired state and current
state when using the API.

To me this is a significant gap as we cannot necessarily get a true view
of the world (i call cf set-env but dont restart the app, how do I know
from the API what value of that env var my app is using).

How are people addressing this in their own environments and is it
something that the core API team should be considering (I ask the latter
publicly even though I asked Dieu during the summit :) ).

John
--
--
Marco Nicosia
Product Manager
Pivotal Software, Inc.
mnicosia(a)pivotal.io
c: 650-796-2948

?
attachment.html

Join cf-dev@lists.cloudfoundry.org to automatically receive all group messages.