Open Stack

On Thu, Aug 04, 2016 at 04:31:00PM -0400, Jay Pipes wrote:
> On 08/04/2016 01:17 PM, Chris Friesen wrote:
> >On 08/04/2016 09:28 AM, Edward Leafe wrote:
> >
> >>The idea that by specifying a distinct microversion would somehow
> >>guarantee
> >>an immutable behavior, though, is simply not the case. We discussed
> >>this at
> >>length at the midcycle regarding the dropping of the nova-network
> >>code; once
> >>that's dropped, there won't be any way to get that behavior no matter
> >>what
> >>microversion you specify. It's gone. We signal this with deprecation
> >>notices,
> >>release notes, etc., and it's up to individuals to move away from
> >>using that
> >>behavior during this deprecation period. A new microversion will never
> >>help
> >>anyone who doesn't follow these signals.
> >
> >I was unable to attend the midcycle, but that seems to violate the
> >original description of how microversions were supposed to work.  As I
> >recall, the original intent was something like this:
> >
> >At time T, we remove an API via microversion X.  We keep the code around
> >to support it when using microversions less than X.
> >
> >At some later time T+i, we bump the minimum microversion up to X.  At
> >this point nobody can ever request the older microversions, so we can
> >safely remove the server-side code.
> >
> >Have we given up on this?  Or is nova-network a special-case?
> 
> This is how Ironic works with microversions today, yes. However, in Nova
> we've unfortunately taken the policy that we will probably *never* bump the
> minimum microversion.

Well, ironic has taken the same policy so far. However, we are thinking
about breaking that, to be able to clean up technical debt (and frankly,
terrible APIs).

If we had an equivalent of nova-network to get rid of, we would drop it
in a microversion, (finally) figure out how to signal that we're finally
going to bump the minimum, and do it (with a reasonable timeframe for
folks to adjust). Or at least, that's how I envision it, I can't
speak for other ironic devs.

I do agree that using a microversion to signal that something is going
away in all versions is not cool. I spoke up about this at the nova
midcycle. If we're being real, someone that has accepted microversions
as a thing is going to assume that pinning to a given version will mean
their client will always work the same (because that's what we've
communicated). They won't read the API docs because they don't need to; the
API won't change, right? Then we drop a thing across all versions and
suddenly they're broken. With a client dev hat on, I'd much rather see
an error message of "this version no longer exists" as opposed to a
random 404. The former has a much more concrete action to take.

Again, if we're being real, there probably aren't very many nova client
applications that are complex enough that moving up a cycle or two worth
of microversions is a huge pain point. These versions spread across a
fairly large number of REST resources, and most apps don't use them all.
The changes for each version are also (or should be) fairly small,
and so it shouldn't be painful to upgrade across them. I tend to think
the worst case breakage is a couple hours worth of work.

That said, I do think we *should* be very careful about raising
minimums. Deprecation warnings should be very in-your-face, the choice to
do so should be very deliberate, and it should happen over multiple
cycles. But we need to be able to do it, otherwise we'll find ourselves
10 years from now supporting code that barely makes sense in the real
world.

So, I think what I'm saying is I somewhat agree with Jay here. :)

// jim

> 
> I personally find this extremely distasteful as I hate all the crap that
> needs to sit around along with all the conditionals in the code that have to
> do with continuing to support old behaviour.
> 
> If it were up to me, the Nova project would just say to operators and
> library/SDK develpers: if you want feature foo, then the tradeoff is that
> the minimum microversion is going up to X. Operators can choose to continue
> on the old code or indicate to their users that they are running a minimum
> newer version of the Compute API and users will need to use a library that
> passes that minimum version header at least.
> 
> IMHO we have gone out of our way to cater to mythical users who under no
> circumstances should ever be affected by changes in an API. Enough is
> enough. It's time we took back some control and cleaned up a bunch of
> technical debt and poor API design vestigial tails by raising the minimum
> microversion of the Compute API.
> 
> And no, the above isn't saying "to hell with our users". It's a simple
> statement that we cannot be beholden to a small minority of users, however
> vocal, that wish that nothing would ever change. These users can continue to
> deploy CentOS4 or Ubuntu 10.04 or libvirt 0.9.8 [1] if they wish and not
> upgrade OpenStack, but that shouldn't mean that we as a project cannot start
> tidying up our own house.
> 
> OK, frustration vented... I'm heading back in for reviews on cleaning up
> unit test cruft in the image backend that Matt Booth pushed.
> 
> Best,
> -jay
> 
> [1] Hmm, interesting that Nova requires a minimum libvirt version of 1.2.1
> nowadays. So, we're happy to say to operators "in order to use modern Nova
> you need to upgrade to 1.2.1 libvirt" but we aren't willing to tell those
> same operators "upgrading to this version of Nova will mean your users will
> have to make a small change to the way they interact with the Compute API".
> Really, this doesn't jive with me.
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev