lock-to-digest help text default is backwards and doesn't seem to work

[duglin]

service create help text:

      --lock-to-digest                    Keep the running image for the
                                          service constant when not
                                          explicitly specifying the image.
                                          (--no-lock-to-digest pulls the
                                          image tag afresh with each new
                                          revision) (default true)

Script:

$ cat bug
#!/bin/bash
./kn service create echo --image duglin/echo | tee out
URL=$(tail -1 out) ; rm out
curl $URL
read a # rebuild duglin/echo
./kn service update echo --image duglin/echo
curl $URL
echo should show new output
./kn service delete echo

HEAD output:

$ ./bug
Creating service 'echo' in namespace 'default':

  0.114s The Configuration is still working to reflect the latest desired specification.
  0.274s The Route is still working to reflect the latest desired specification.
  0.382s Configuration "echo" is waiting for a Revision to become ready.
  5.122s ...
  5.450s Ingress has not yet been reconciled.
  5.501s Waiting for load balancer to be ready
  5.724s Ready to serve.

Service 'echo' created to latest revision 'echo-wgjsy-1' is available at URL:
http://echo-default.kndev.us-south.containers.appdomain.cloud
Hi from echo (host: echo-wgjsy-1-deployment-7df68685bf-p9db5 rev: echo-wgjsy-1)

Updating Service 'echo' in namespace 'default':

  0.089s The Configuration is still working to reflect the latest desired specification.
  7.540s Traffic is not yet migrated to the latest revision.
  7.642s Ingress has not yet been reconciled.
  7.765s Waiting for load balancer to be ready
  8.246s Ready to serve.

Service 'echo' updated to latest revision 'echo-hctnz-2' is available at URL:
http://echo-default.kndev.us-south.containers.appdomain.cloud
test (host: echo-hctnz-2-deployment-74bc67846c-rp9dx rev: echo-hctnz-2)
should show new output
Service 'echo' successfully deleted in namespace 'default'.

Notice it shows "test" as the output of the curl because it picked up a new "echo" image.

Which shows that the default is 'false' not 'true'. I believe these are the correct semantics so the help text needs to be updated with 'false' as the default value. I think "create" has the same backwards default value.

When I modify the script to include --lock-to-digest or --no-lock-to-digest on the create and update, it seems to have no effect on the output - in all cases the new image is downloaded each time.

[navidshaikh]

  --lock-to-digest                    Keep the running image for the service constant when not  explicitly specifying the image.

this is for the case where you are not specifying the image, in your script I see update command has --image specified. did I miss something here @duglin ?

[duglin]

ok then I'm a bit confused... not unusual :-) Does specifying a flag that matches it's old value mean something or not? Based on your comment it sounds like it means "ignore lock-to-digest and grab the latest version". Which is actually ok with me. But then why does the CLI tell me it's not going to do anything onkn service update echo --image duglin/echo because to the CLI nothing has changed? It seems to me that we need to be consistent, either specifying the same value is a no-op, or not. I guess this is related to #1318.

I just tested again and the flag does seem to work as expected now.

[navidshaikh]

I think the lock-to-digest flag helps in cases where user wants to apply non-image config changes while keeping the image digest pinned as of last revision. In this case, kn finds the sha from base revision and refers image@sha256:.. for image in spec.

Does specifying a flag that matches it's old value mean something or not?

We should consider how the server reacts to such cases, kn is trying to be consistent here if the same set of values passed by other clients. To me this particular use case seems to require another knob on serving side which should answer:

• should it re-download the image per update if image string is same ?

[rhuss]

I added an issue to serving to discuss how the serveri-side could help with this use case: knative/serving#11483

[rhuss]

While fixing the image digest resolution issue via #1364 , I can confirm the following the behaviour, that has been there from the beginning (and actually is also explained in the help message, too)

• --lock-to-digest is the default
• If --no-lock-to-digest is given and you do a kn service update the image is re-resolved
• If --lock-to-digest is given (or no lock option, because this is the default) then no image is re-resolved except when you include the image via --image. In this case, the image is still re-resolved. This is meant by "Keep the running image for the service constant when not explicitly specifying the image"

So, the behavior is as documented. You just need to leave out --image for the update to avoid a re-resolving of the tag.

I'm closing the issue now, feel free to reopen it you think there is still something that we can improve