This change offloads some of the behaviour of FargateSpawner to client code.
It immediately allows setting of tags, platform version, public IP, user input: all of which have current separate PRs.
It allows the setting of any other existing RunTask options, not yet requested.
It allows setting of any future RunTask options.
It is a touch more future friendly to future changed to JupyterHub itself. FargeteSpawner makes slightly fewer calls to its base class, Spawner. If this changed, it is less likely that FargateSpawner would need to change.
To the potential criticism that this makes the abstraction leaky... it already was leaky: needing to know how security groups and subnets were used etc. Indeed, if every option to RunTask is exposed as a separate option on the spawner, which is then passed through blindly to RunTask, the spawner wouldn't be abstracting anything away. In fact, it would be increasing the burden on the developer since there is more to understand (and so potentially go wrong). I treat this spawner more as a utility than a layer of abstraction, and so this change makes the utility more powerful.
A reasonable criticism is that this makes the spawner a bit harder in simple cases. However, for me, the above benefits are worth it.
This is a breaking change. Existing users can pin (and I would argue, should have pinned) to a previous version to keep the same interface. The version format hints at SemVer, and which explicitly allows any pre 1.0.0 change to be breaking.
This change offloads some of the behaviour of FargateSpawner to client code.
It immediately allows setting of tags, platform version, public IP, user input: all of which have current separate PRs.
It allows the setting of any other existing RunTask options, not yet requested.
It allows setting of any future RunTask options.
It is a touch more future friendly to future changed to JupyterHub itself. FargeteSpawner makes slightly fewer calls to its base class, Spawner. If this changed, it is less likely that FargateSpawner would need to change.
To the potential criticism that this makes the abstraction leaky... it already was leaky: needing to know how security groups and subnets were used etc. Indeed, if every option to RunTask is exposed as a separate option on the spawner, which is then passed through blindly to RunTask, the spawner wouldn't be abstracting anything away. In fact, it would be increasing the burden on the developer since there is more to understand (and so potentially go wrong). I treat this spawner more as a utility than a layer of abstraction, and so this change makes the utility more powerful.
A reasonable criticism is that this makes the spawner a bit harder in simple cases. However, for me, the above benefits are worth it.
This is a breaking change. Existing users can pin (and I would argue, should have pinned) to a previous version to keep the same interface. The version format hints at SemVer, and which explicitly allows any pre 1.0.0 change to be breaking.