[crac] RFR: Environment vars propagation into restored process

Dan Heidinga heidinga at redhat.com
Tue Oct 4 13:03:36 UTC 2022


On Tue, Oct 4, 2022 at 5:16 AM Jan Kratochvil <jkratochvil at azul.com> wrote:

> On Thu, 29 Sep 2022 17:45:01 +0200, Roman Marchenko wrote:
> > This PR provides functionality to propagate actual environment variables
> to
> > a restored process, as well as the test for this functionality.
>
> It would be nice to know what was the reason for introducing this feature.
>

When deploying a container to K8, it's pretty common to configure the
application using env vars - things like connection ports, host names, etc
get injected into the container.  If a checkpoint is taken in the CI
environment, we don't want to bind in those env vars as it's too early to
know what the values will be for a particular deployment.  If the restores
happen when the image is deployed, we need a way to inject the final
configuration data (the env vars) into the restored image.


>
> This mail thread discusses its disadvantages but not its advantages.
>

Less so the disadvantages and more consequences - the ability to set env
vars on restore is important for containers but it has knock on effects.
Existing applications haven't been architected to expect this so there's
some corner cases that need to be worked through.

I think we need this kind of ability for CRaC but am now looking at how do
we design it so that it limits the risk to applications, is easy to
service, and has a clear model that developers and users can reason about.

--Dan


>
>
> Jan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/crac-dev/attachments/20221004/3b53e895/attachment.htm>


More information about the crac-dev mailing list