Migrating app from Dockerfile to buildpack deploys fails

[gedimin45]

Hello,

So this is a simplified version of instructions I executed:

deis create
git push deis master # this version included a Dockerfile
rm Dockerfile; git add .; git commit
git push deis master
deis scale web=1
deis scale cmd=0

deis open now resulted with 503 Service Unavailable. When I look at the generated router config file, I see this:

server {
		#...

		location / {
			

			return 503;
		}
		
	}

So it seems there is something preventing from generating the config for proxying requests to the web process.

[mboersma]

We think this is similar to a Deis v1 issue--let me resurrect that and follow up.

Edit: this is somewhat related to deis/deis#2861, although that workaround doesn't appear to have helped here.

[gedimin45]

Cool! Let me know if you are able to reproduce this and whether I can help with that.

[mboersma]

@Ged15 I've reproduced the same thing. I added a dockerfile branch to our example-python-django app, then did this:

$ git push deis dockerfile  # app deploys ok
$ git push deis master
$ deis scale cmd=0 web=1  # returns 503

Not sure what the problem is yet, but I think I can use this to pin it down.

[mboersma]

This is a bit more pervasive a bug than it first appears. It also happens when going from Procfile to Dockerfile releases. In that case a web process type is left running, but when going the opposite direction, no processes are running. Doing the right deis scale command afterward appears to patch things up as far as controller knows, but routing still returns a 503 in both cases.

I think the default behavior in these cases should not require an additional deis scale command.

It's not unreasonable to expect an app to switch build types like this during its lifetime. I'll see if I can fix this behavior and write tests for it.

[mboersma]

When switching from cmd to web process type, it appears the spec -> selector -> type value for the app's deployment object stays at cmd. Doing a kubectl edit of the deployment and changing it to web gets things routable again.

I think the fact that you need to do a deis scale command here is a separate, lower-priority bug that we can address after fixing what I describe above.

[mboersma]

a deis scale command here is a separate, lower-priority bug

The fix I'm proposing in deis/controller#1201 actually removes the need for a deis scale command as well, so it handles both issues.