Refine Reserved Sharing Workflow

[michaelquigley]

The separate zrok reserve and zrok share reserved steps might be simplified. Maybe zrok share private --reserved or similar?

Spend some time figuring out how to refine this workflow.

[qrkourier]

I often find it necessary to reserve a new share because I need to adjust the backend proxy URL, which negates some of the value of the reservation, i.e., a stable URL.

[michaelquigley]

You can alter the backend proxy URL with a reserved share even in v0.3...

$ zrok share reserved --help
Start a backend for a reserved share

Usage:
  zrok share reserved <shareToken> [flags]

Flags:
      --headless                   Disable TUI and run headless
  -h, --help                       help for reserved
      --insecure                   Enable insecure TLS certificate validation
      --override-endpoint string   Override the stored target endpoint with a replacement

See the --override-endpoint flag.

[qrkourier]

One usability issue I am facing regarding the reserved sharing workflow is finding the reservation token for a particular share. As soon as I had more than one reservation, I had this problem of re-sharing the correct token for a particular purpose. As a workaround, I can find the correct token in the UI.

Zooming out, makes me think about zrok presenting as CLI-first vs. UI-first vs. API-first. I guess a particular use case will prefer only one of these three. My introduction to zrok has been CLI-first, so I naturally expect to find the token with the CLI. Switching contexts to the UI didn't come naturally to me, and I only thought to do it after I started writing this issue.

[qrkourier]

How zrok Reservations Work

Create a reservation

$ zrok reserve public http://127.0.0.1:4321
[   0.328]    INFO main.(*reserveCommand).run: your reserved share token is '1f33tjcds0az'
[   0.328]    INFO main.(*reserveCommand).run: reserved frontend endpoint: http://1f33tjcds0az.zroktest.ken.demo.openziti.org:8080

Share the reservation

$ zrok share reserved 1f33tjcds0az --headless
[   0.184]    INFO main.(*shareReservedCommand).run: sharing target: 'http://127.0.0.1:4321'
[   0.184]    INFO main.(*shareReservedCommand).run: using existing backend proxy endpoint: http://127.0.0.1:4321
[   0.498]    INFO main.(*shareReservedCommand).run: access your zrok share: http://1f33tjcds0az.zroktest.ken.demo.openziti.org:8080
[   0.525]    INFO sdk-golang/ziti.(*listenerManager).createSessionWithBackoff: {session token=[29428ec0-d61b-4c15-b2af-dccd03df247d]} new service session

[qrkourier]

It would be immediately helpful for the persistent public share use case I'm working on if the zrok reserve command could write JSON to a file like zrok reserve public -o ./reservation.json or if one of the existing JSON files' schemas in ~/.zrok were extended to describe reservations created by that environment. Without this, I'm forced to parse the stdout to obtain the share token and frontend URL, which is brittle because the signature of the log messages could change.

It makes sense to store the reservation tokens in the environment because they're already uniquely coupled to the environment, i.e., the Bind SP is for the particular Ziti identity of that particular enabled environment, not all enabled environments for the same zrok enable token.

If the reservation were stored in the environment with a label,, I could subsequently share it like zrok share reserved myfancyshare.

That also presents the opportunity to use zrok config to store additional parameters for the reservation as configuration, e.g. zrok config set reserved.1f33tjcds0az.name myfancyshare2 and zrok config set reserved.1f33tjcds0az.headless true

[michaelquigley]

It makes sense to store the reservation tokens in the environment because they're already uniquely coupled to the environment, i.e., the Bind SP is for the particular Ziti identity of that particular enabled environment, not all enabled environments for the same zrok enable token.

If the reservation were stored in the environment with a label,, I could subsequently share it like zrok share reserved myfancyshare.

That also presents the opportunity to use zrok config to store additional parameters for the reservation as configuration, e.g. zrok config set reserved.1f33tjcds0az.name myfancyshare2 and zrok config set reserved.1f33tjcds0az.headless true

Can you open a new issue with this? This seems like something I could implement in a day or two, and I think it would be a nice feature.

[michaelquigley]

It might also be useful to check out zrok overview, if you have not already. That could also be made more useful than it currently is, but it does give you JSON output describing all of the environments and their associated shares.

[michaelquigley]

(disregard new issue request... will work off this issue)

[qrkourier]

zrok modify share is now a thing and is starting as a way to adjust authorization within the new "closed" permissions model.

We could expand zrok modify share to adjust reservation authentication options. That way, it wouldn't be necessary to first zrok release and then zrok reserve with new authentication options.

[michaelquigley]

Yup! Just a basic plumbing thing.

However, we need #529 implemented before the frontend would react instantly. Same issue, different set of circumstances.