Open Stack

> onSharedStorage = True
> on_shared_storage = False

This is a good example. I'm not sure it's worth breaking users _or_
introducing a new microversion for something like this. This is
definitely what I would call a "purity" concern as opposed to "usability".

Things like the twenty different datetime formats we expose _do_ seem
worth the change to me as it requires the client to parse a bunch of
different formats depending on the situation. However, we could solve
that with very little code by just exposing all the datetimes again in
proper format:

 {
  "updated_at": "%(random_weirdo)s",
  "updated_at_iso": "%(isotime)s",
 }

Doing the above is backwards compatible and doesn't create code
organizations based on any sort of pasta metaphor. If we introduce a
discoverable version tag so the client knows if they will be available,
I think we're good.

URL inconsistencies seem "not worth the trouble" and I tend to think
that the "server" vs. "instance" distinction probably isn't either, but
I guess I'm willing to consider it.

Personally, I would rather do what we can/need in order to provide
features in a compatible way, fix real functional issues (like the
datetimes), and not ask users to port to a new API to clear up a bunch
of CamelCase inconsistencies. Just MHO.

--Dan