Re: pkgdb2 post-mortem and strategy for future deployments

[Toshio Kuratomi]

On Wed, Jun 04, 2014 at 05:27:44PM -0500, Dennis Gilmore wrote:
>  
>  I have a suggestion make everything provide and validate api info.
>  
>  this is something koji does, though we to date have not broken api, we
>  expect we will do when we start on koji-2.0  so each app would provide
>  a getAPIVersion() function, then the consumers validate that they know
>  how to talk to that API version.
>  
>  for bodhi for instance apps could check for api version if it fails
>  assume version 1 and then be able to support both version 1 and 2, when
>  we deploy live bodhi2 the clients like fedpkg update will transparently
>  switch over.
>  
<nod>  This would be nice.  I don't think it would have helped us with
the
pkgdb2 update where people didn't port at all but if we gave more
information it could.  Ideally we'd want to see something like this:

> >> data = service.requestAPIVersion([(1, 2), (2, 0)], 
... 
 'arbitrary-identification-string')
> >> print(data) 
[[1, 2], [1, 4]]

In that example the client would be claiming compatibility with API version
1.2 or later and 2.0 or later.

The server would be telling the client that it can supply something
compatible with 1.2, namely 1.4.

If we got clients to update their code to make requestAPIVersion() calls
both the client and the server would be able to track what the other wanted
and was capable of.  Serverside, we could keep track of what identification
strings were making requests for something other than API version 2.0 and help
those people port to 2.0 before deployment.

Is that sort of API too confusing (because it's attempting to track
information in both directions but the person using the code really just
wants information in a single direction)?

-Toshio