cf7 push with start command but no Procfile fails for Python app

stephanme commented 3 years ago

Issue

Pushing a simple Python app fails with cf7 when specifying the start command in manifest or on cmd line. In contrast to the documentation https://docs.cloudfoundry.org/buildpacks/python/index.html#start-command, a Procfile seems to be required.

Context

Simple python-hello app (attached):

empty requirements.txt
index.html
server.py
```
import http.server
import socketserver
```

PORT = 8080

Handler = http.server.SimpleHTTPRequestHandler

with socketserver.TCPServer(("", PORT), Handler) as httpd: print("serving at port", PORT) httpd.serve_forever()

- manifest.yml

applications:

name: python-hello buildpacks:
- python_buildpack random-route: true command: python3 server.py memory: 128M

stephan@WDFN34095835A:~/d047883/tmp/python-hello$ cf7 --version
cf7 version 7.1.0+4c3168f9a.2020-09-09

Same example works with cf6.

Colleagues report the same problem for nodejs apps. Therefore, I don't think that it is a buildpack issue but more related to CC v3.

https://docs.cloudfoundry.org/buildpacks/python/index.html#start-command refers to https://www.pivotaltracker.com/n/projects/966314/stories/132190561 which states:

Allow null process_types when a v2 app is staged

V2 apps can get start commands specified during a push or from a manifest, so Procfiles are not required

V3 apps continue to require Procfiles for successful staging

(https://github.com/cloudfoundry/cloud_controller_ng/commit/a0fc3c36bc0d34c7cdd7c2e17a872e60af12d029)

Steps to Reproduce

unzip the attached example python app
cf7 login
cf7 push -> failes with "StagingError - Staging error: No process types returned from stager" (see logs below)
cf7 push --no-manifest -c 'python3 server.py' --random-route -m 128M -b python_buildpack python-hello -> fails as well
cf6 push succeeds

When adding a Procfile to the app, cf7 push succeeds as well:

web: python3 server.py

Expected result

cf7 push succeeds without Procfile. I.e. same behavior as for cf6.

Current result

Pushing app python-hello to org uptime / space test as stephan.merker@sap.com...
Applying manifest file /c/Users/d047883/tmp/python-hello/manifest.yml...
Manifest applied
Packaging files to upload...
Uploading files...
 594 B / 594 B [=========================================================================================================================================================================================] 100.00% 1s

Waiting for API to complete processing files...

Staging app and tracing logs...
   Downloaded python_buildpack
   Cell 18ff5e53-a3a7-4252-984d-410a261a2eda creating container for instance 6cc2a860-5953-40ab-aa73-f4707235c61c
   Cell 18ff5e53-a3a7-4252-984d-410a261a2eda successfully created container for instance 6cc2a860-5953-40ab-aa73-f4707235c61c
   Downloading app package...
   Downloaded app package (594B)
   -----> Python Buildpack version 1.7.18
   -----> Supplying Python
   -----> Installing python 3.8.5
          Copy [/tmp/buildpacks/d7b853a1f20575496c8d1e954762b5cd/dependencies/e0d0b83bd1361d27c169058aedc9573c/python_3.8.5_linux_x64_cflinuxfs3_08613f97.tgz]
   -----> Installing pip-pop 0.1.5
          Copy [/tmp/buildpacks/d7b853a1f20575496c8d1e954762b5cd/dependencies/2e88c958cb5cf0638aa875fa2e7b99e0/pip-pop-0.1.5-b32efe86.tar.gz]
   -----> Running Pip Install
          WARNING: You are using pip version 20.1.1; however, version 20.2.4 is available.
          You should consider upgrading via the '/tmp/contents817893367/deps/0/bin/python -m pip install --upgrade pip' command.
   No start command specified by buildpack or via Procfile.
   App will not start unless a command is provided at runtime.
   Exit status 0
   Uploading droplet, build artifacts cache...
   Uploading build artifacts cache...
   Uploading droplet...
   Uploaded build artifacts cache (15.7K)
   Uploaded droplet (55.3M)
   Uploading complete
   Cell 18ff5e53-a3a7-4252-984d-410a261a2eda stopping instance 6cc2a860-5953-40ab-aa73-f4707235c61c
   Cell 18ff5e53-a3a7-4252-984d-410a261a2eda destroying container for instance 6cc2a860-5953-40ab-aa73-f4707235c61c
   Cell 18ff5e53-a3a7-4252-984d-410a261a2eda successfully destroyed container for instance 6cc2a860-5953-40ab-aa73-f4707235c61c
StagingError - Staging error: No process types returned from stager
FAILED

cf-gitbot commented 3 years ago

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

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

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

stephanme commented 3 years ago

python-hello.zip

Gerg commented 3 years ago

I followed up with the buildpacks team and it sounds like it's expected that some buildpacks will not return process types or start commands. Based on that, CC should handle this case more gracefully, especially if there is already a start command provided on via the API/manifest.

jgallucci32 commented 3 years ago

It is interesting to note the problem is fixed by simply specifying the process type in the Procfile as follows without any commands

web:

In this case the command in the manifest is honored. Probably better to do it this way to ensure you don't have one set of commands in the manifest overwrite the one in Procfile (or other way around).

Gerg commented 3 years ago

This issue was addressed in capi-release 1.105. Thank you for raising this issue!

cloudfoundry / cloud_controller_ng