Unable to use new manifests when using "current_app_name" param about cf-resource HOT 3 OPEN

This also has the more problematic limitation that vars is incompatible with the legacy manifest format:

error: The following flags cannot be used with deprecated usage: var

This means we have to choose between the zero-downtime-deploy feature, and being able to use a single manifest per app.

from cf-resource.

This is caused by autopilot (contraband/autopilot#59) which in turn points to cf cli's API (cloudfoundry/cli#1445), finally pointing at a description of a massive refactor which has been causing problems like this for plugins (cloudfoundry/cli#1399 (comment))

The short explanation is that this line in autopilot uses the CF CLI plugin code (as it should):

https://github.com/contraband/autopilot/blob/5e34f165d172fd1253070c6c7ada984a03cb447e/autopilot.go#L301

But the CF CLI plugin code is stuck using legacy code, and has no way to use non-legacy.

I think the simplest fix (but likely years away) would be to continue CF CLI's existing replicate-the-world approach and add a new non-legacy plugin API which plugins can choose to switch to. Then autopilot could switch to that, and this issue should be resolved. In that case, this problem would be entirely out of the hands of the cf-resource project.

Alternatively, cf-resource could replace autopilot with a series of raw cf commands doing exactly the same thing that the plugin is currently doing (since the CLI part of the CF CLI is using non-legacy codepaths). Translated into bash, the tasks appear to be:

APP_NAME="<app-name>";

app_state() {
  cf app "$1" | grep 'requested state:' | tr -s ' ' | cut -f3 -d' ' || echo 'missing';
}
VEN_NAME="${APP_NAME}-venerable";
APP_STATE="$(app_state "$APP_NAME")";
MADE_VEN='false';

if [[ "$APP_STATE" != 'missing' ]]; then
  if [[ "$APP_STATE" != 'started' ]]; then
    cf delete "$APP_NAME" -f;
  else
    VEN_STATE="$(app_state "$VEN_NAME")";
    if [[ "$VEN_STATE" != 'missing' ]]; then
      cf delete "$VEN_NAME" -f;
    fi;
    cf rename "$APP_NAME" "$VEN_NAME";
    MADE_VEN='true';
  fi;
fi;

if cf push "$APP_NAME" [extra args here...]; then
  if [[ "$MADE_VEN" == 'true' ]]; then
    cf delete "$VEN_NAME" -f;
  fi;
  echo 'SUCCESS!';
else
  if [[ "$MADE_VEN" == 'true' ]]; then
    cf logs "$APP_NAME" --recent; # (I added this; autopilot doesn't do it)
    cf delete "$APP_NAME" -f;
    cf rename "$VEN_NAME" "$APP_NAME";
  fi;
  echo 'FAILED :(';
fi;

It would take a bit of work to translate this from bash into go, and it will make PushApp much more complicated, but it would mean entirely bypassing CF CLI's plugin architecture, which means all these issues would go away.

from cf-resource.

Hi @ipsi thanks for pointing this issue out. As @davidje13 points out, our plugin architecture is tied to our legacy code, which does not interact nicely with refactored commands or new features. The CLI team did an exploration recently to try to get to an understanding as to how to help plugin authors but we do not have enough information to move forward, and also we want to understand how the new upcoming rolling deployments feature fits into the picture for some of the plugins which have reported issues.

Here is the tracker story for reference which includes a document detailing some of the engineers' findings. Please feel free to comment in the document.

from cf-resource.