Providing a better UX for unintended uninjected PASW tile upload

[awmartin]

The problem: Every PCF operator (Pivots and customers) who has attempted to deploy PASW so far has uploaded the uninjected (aka "thin") tile by mistake, which by design doesn't include the required windows2016fs-release.

The resulting error message gives the impression that the tile is broken (which it technically is, but not really). This provided error is the default and expected behavior for OpsMgr, but it doesn't imply a natural corrective action for the user. Our only mitigation so far is to document this behavior as expected for PASW:

https://docs.pivotal.io/pivotalcf/2-1/windows/troubleshooting.html#no-os

Can we provide a better user experience? I'd like to present two options:

Option 1 - Proactive: Change the file extension of the "thin" tile.

We could consider changing the file extension of the PivNet-hosted "thin" tile to not be .pivotal, but instead be something silly like .INJECT-ME or .NEEDS-INJECTOR. This way, we could also remove the --output-tile command line option, and the invocation for the injector could be something like:

> winfs-injector-windows.exe pas-windows-2.1.9.build.15.INJECTME

Then the result of running the injector would then be a "fat" tile with a proper .pivotal extension, being the consistent cue that says to operators, "This is uploadable to OpsMgr," like other tiles. This also removes the need for an operator to pick a filename.

This helps the operator avoid getting the error message to begin with. The odd file extension may serve as a prompt to read the docs.

Option 2 - Reactive: Improve the error message to be action-oriented.

The general idea here is to provide an action for the user that is actionable, after uploading the thin tile.

This may require code changes in OpsMgr, so I'm not really sure where they would be. But the idea would be to provide something like if error_message =~ /windows2016fs/ then alert("Inject your tile") into the proper place.

AFAIK, there is no consistent abstraction for supporting tiles intentionally shipped with missing BOSH releases. And if the release is actually invalid though, maybe the error message would be incorrect?

Option 3 - Self-extracting executables

The injector would include the tile bits. Running the injector would download the container image and produce the tile as its single output. This would provide a single-download experience, but those executables would be quite large (1.6GB).

Option 4 - Injector downloads the tile and the container image

The injector would download the tile and the container OS, producing a fat tile. This may require including the PivNet CLI and the operator providing credentials to their PivNet account.

---

I'd be willing to entertain any of these or others, but I do think we should do something until we can ship a better UX that doesn't require manual injection at all.

[sneal]

Lots of good options here, in fact implementing multiple options might be the way to go. Just like a good defense has multiple layers.

The other missing piece of good UX here is especially apparent on a typically lean Windows Server jumpbox.

• tar in your PATH
• git installed

A better user experience wouldn't require the end user to install or configure either of these. Tar could be placed in the PATH by the tile extractor and the functionality for git could be replaced with some other mechanism.

I think downloading an executable (that is clearly not a tile) that handled "all the things" for you would be ideal.

[awmartin]

Another option may be to ship the tile with the online release included, which assume internet access (i.e. through a customer's proxy).

Then when an operator runs the injector, that would remove the online release, create the offline release, then inject the container image into the tile.

This would at last give the option, but this may present additional confusion about the state of a given tile. Maybe we could ship two tiles, one clearly labeled online and another intended to be injected (offline).