You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the deis workflow cli looks for a Procfile in the pwd and uses it to declare proc types when doing a deis pull.
This feature is very error prone, because it can happen very easily that one does a deis create foo --no-remote followed by deis pull while in the git worktree of another workflow app "bar", eg. a rails app with buildpack deploy and a Procfile.
If one makes this error, deis will create the new app "foo", but it wil use the bogus Procfile to setup a "web" process type along with wrong labels on the "foo"-service which will cause routing to be broken. The app will also not start because the "web" proc type is scaled to 1 and cmd to 0.
To fix such an app, one has to manually scale up cmd and scale down web, edit the deis database to remove the bogus proctype and edit the "foo"-service selector to point to the "cmd" type.
In short it is a major pain to fix for a feature that is probably very rarely used and it is hard to even know what caused this without in-depth knowledge of deis workflow and kubernetes.
I propose to instead change the behavior of the --procfile switch to accept either a string or a path to a procfile and remove the automatic lookup for a Procfile in the pwd.
The text was updated successfully, but these errors were encountered:
Currently the deis workflow cli looks for a
Procfile
in the pwd and uses it to declare proc types when doing adeis pull
.This feature is very error prone, because it can happen very easily that one does a
deis create foo --no-remote
followed bydeis pull
while in the git worktree of another workflow app "bar", eg. a rails app with buildpack deploy and aProcfile
.If one makes this error, deis will create the new app "foo", but it wil use the bogus
Procfile
to setup a "web" process type along with wrong labels on the "foo"-service which will cause routing to be broken. The app will also not start because the "web" proc type is scaled to 1 and cmd to 0.To fix such an app, one has to manually scale up cmd and scale down web, edit the deis database to remove the bogus proctype and edit the "foo"-service selector to point to the "cmd" type.
In short it is a major pain to fix for a feature that is probably very rarely used and it is hard to even know what caused this without in-depth knowledge of deis workflow and kubernetes.
I propose to instead change the behavior of the
--procfile
switch to accept either a string or a path to a procfile and remove the automatic lookup for aProcfile
in the pwd.The text was updated successfully, but these errors were encountered: