Closed Lewiscowles1986 closed 5 years ago
We have created an issue in Pivotal Tracker to manage this:
https://www.pivotaltracker.com/story/show/167980606
The labels on this github issue will be updated when the story is started.
The wheel misses the shared object because it is a runtime dependency.
To fix this I used the attic multi-buildpack (not great as my understanding is that attic is deprecated)
apt.yml
---
packages:
- libxmlsec1-openssl
multi-buildpack.yml
---
buildpacks:
- https://github.com/cloudfoundry/apt-buildpack#v0.1.8
- https://github.com/cloudfoundry/python-buildpack#v1.6.36
This seems to work and should have legs for the future. I'm a little upset it came to this.
Not sure what the issue is here. We don't include every possible os package on our rootfs and the use of the apt buildpack to install packages is a perfectly normal way to install packages. Multi-buildpack support is also fully supported (you could that multi-buildpack.yml content into your main manifest.yml per https://docs.cloudfoundry.org/devguide/deploy-apps/manifest-attributes.html#buildpack)
Building the buildpacks into the manifest.yml brought up errors. It didn't work, but was one of the first things attempted.
Something about an API version. We tried pulling from a newer cloudfoundry deploy docker image, I personally went through the docs. We received many other errors, but were unable to deploy using that tip.
We don't include every possible os package on our rootfs
Nobody asked you to and that was totally unnecessary misrepresentation of what this issue calls out.
This shared object used to be included when deployed on cflinuxfs3 using the python buildpack. AFAIK the buildpack is our only way to modify the application-specific system dependencies.
Up until this point, I've isolated and deployed changes including vendored dependencies from an earlier successful build. I can prove none of our code built that shared object and deploys worked (the dependency is very old).
Multiple engineers poured over the CF docs including the multi-buildpack docs you linked. None of it worked or signposted deeper troubleshooting docs. To avoid reading source-code of the managed system we pay for to avoid the burden of managing our own platform, we took an inventory.
As this is outside of our codebase and we only use official buildpacks, we looked into several other ways to remit and eliminated everything besides this buildpack including manually including the shared object in a python wheel.
I came to the place those system-level dependencies are supplied as I believe is reasonable to raise an issue so that others encountering this on this platform would have one place to look for solutions.
What version of Cloud Foundry and CF CLI are you using?
api: "2.139.0" (oddly one of the fields says version: 0... troubling) cli: cf version 6.42.0+0cba12168.2019-01-10
What version of the buildpack you are using?
v1.6.36
If you were attempting to accomplish a task, what was it you were attempting to do?
Deploy an app which has deployed for > 1 year
What did you expect to happen?
App deploys
What was the actual behavior?
Please confirm where necessary: