cloudfoundry / cf-for-k8s

The open source deployment manifest for Cloud Foundry on Kubernetes
Apache License 2.0
300 stars 115 forks source link

Environment variables are not respected in Java buildpack #603

Closed braunsonm closed 3 years ago

braunsonm commented 3 years ago

Describe the bug

Since updating to v1.1.0, the Java buildpack will not pass environment variables to the Jar. In fact you cannot even disable the spring bindings anymore, which would point to something wrong with the launcher I would assume?

However I'm not sure if this is a buildpack issue since I downgraded the kpack buildpacks to the v1.0.0 values and the issue still appears.

To Reproduce*

Steps to reproduce the behavior:

  1. Deploy v1.1
  2. Deploy an app like the CF Spring Music Sample
  3. Try to set an environment variable like spring.profiles.active=test, notice that it has no effect but does in 1.0
  4. Or try to disable the spring cloud bindings and also notice it no longer has any effect

Expected behavior

Environment variables should be passed to the application.

Additional context

cf-for-k8s SHA

v1.1.0 tag

Cluster information

AKS

cf-gitbot commented 3 years ago

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/176286507

The labels on this github issue will be updated when the story is started.

9numbernine9 commented 3 years ago

This appears to be fixed in the revert-cc-eirini-buildpacks branch - specifically, commit 5645f4d2daf3d83a547b5680c7e262502ff141ef ("Reverting CC and Eirini to v1.0.0 for testing") appears to be sufficient to resolve the issue. Using that commit to deploy a cf-for-k8s instance with kind and then pushing a Java app there results in a Java app that behaves correctly. 😃

tcdowney commented 3 years ago

The changes on the Cloud Controller side of things that might impact this were the introduction of "kpack" droplets: https://github.com/cloudfoundry/cloud_controller_ng/commits/main/lib/cloud_controller/opi/apps_client.rb

I don't think it should have affected things since it shares the same env var codepath as "docker" droplets, but it is a change.

Would be interested to know what changed between the Eirini versions.

braunsonm commented 3 years ago

@Birdrock 's fix works! We are using it in the mean time with the following overlay for anyone else with this issue:

#@ load("@ytt:overlay", "overlay")

#@ deployments = overlay.subset({"kind": "Deployment"})
#@ jobs = overlay.subset({"kind": "Job"})

#@overlay/match by=overlay.or_op(deployments, jobs), expects="1+"
---
spec:
  template:
    spec:
      containers:
      #@overlay/match by=overlay.subset({"image": "cloudfoundry/cloud-controller-ng@sha256:00d4a985180b4a79c325860119aecd33af0fd06f2e2e9a49a375c9bad0b0b988"}), when="1+"
      - image: relintdockerhubpushbot/cloud-controller-ng@sha256:e2960fe5985e30963963364c97deab357ba64e2c8b811ad00e03d3bc7abc8f23

Thank you so much team for the rapid communication on this issue in Slack!

jamespollard8 commented 3 years ago

This was fixed by https://github.com/cloudfoundry/cloud_controller_ng/pull/2052 which was pulled into cf-for-k8s via a capi-k8s-release bump 1-2 days ago.