Expressing service deprecation?

[Theresa Dower]

Hello,

Just to piggyback on Markus' comments about real-world operational client support and registering multiple versions of services.

At MAST, we have several SSAP services where endpoints using multiple, non-backward-compatible MAJOR version numbers are available. We have kept the old versions of services up for clients that we know still use them. However, when we have tried registering them as multiple capabilities for one service, we have repeatedly run into issues with clients and validators either 1: getting confused about which namespace/version is meant based on the resource header, and/or 2: not acknowledging all the standard capabilities listed. Eventually, we split each resource record into multiple almost identical records in the registry, one for each major version. This is clearly less than ideal.

So on the whole, I strongly support a solution with VOResource 1.1 extended related-resource options. But I'm still confused as to how we're supposed to handle the versioned namespaces in the registry. And, unfortunately, whatever we do is going to need some push for client and validator support. (I.e. unfortunately these are my monkeys, and my circus.)

--Theresa

________________________________________
From: registry-bounces at ivoa.net [registry-bounces at ivoa.net] on behalf of Markus Demleitner [msdemlei at ari.uni-heidelberg.de]
Sent: Tuesday, June 13, 2017 3:48 AM
To: grid at ivoa.net; registry at ivoa.net
Subject: Re: Expressing service deprecation?

Hi,

On Mon, Jun 12, 2017 at 05:10:16PM -0700, Brian Major wrote:
> I am wondering if a mechanism within registry exists that allows providers
> to indicate that a particular service is deprecated.  And, if so, allows
> for the recommendation of an alternate service.
>
[...]
> I think this is a different problem than the one that the note on XML
> Schema versioning is trying to solve in that:
> - A new version of a service is deployed alongside the previous version.
> - There could be capabilities of the service that don't result in the
> client receiving an XML document from the service and thus have the ability
> to determine the version of the schema.

It is this scenario that makes us keep minor versions in registry
standardIDs although it somewhat complicates discovery, including the
necessity of using search patterns in the normal case
(cf.
http://www.ivoa.net/documents/IVOAIdentifiers/20160523/REC-Identifiers-2.0.html#tth_sEc4.2).

Although we don't have many cases that would require this kind of
thing (yet), service operators could write something like this
within *one* record:

  <capability standardID="ivo://ivoa.net/std/example#endpoint-1.0">
    ...

  <capability standardID="ivo://ivoa.net/std/example#endpoint-2.0">
    ...

  <capability standardID="ivo://ivoa.net/std/example#endpoint-2.1">
    ...

Personally, I'm not convinced there's a point in keeping several
endpoints of the same major version, since by definition clients for
2.0 must be able to drive 2.1 services, but anyway: While it's never
said explictily anywhere, I'd stipulate such a record should be
interpreted as "if at all possible, use capability[3]" or
"capability[1|2] are deprecated".

I don't think there's any client support for anything resembling this
yet (though I'm not sure what they do if they find multiple
capabilities for a standardID pattern during discovery).

I suspect the entire question arises in the context of VOSpace, and my
shallow reading of it suggests that for that, there may be a
requirement for this kind of thing (synctrans-2.0 vs synctrans-2.1
perhaps?).  If so, I'd be happy to help in working out the details.

There is another aspect to this question, though:

> I thought I had once seen 'replacedBy' attribute somewhere but cannot find
> it.  (Maybe I was thinking of the mirroring support).  If people think this
> is a good idea, perhaps such an attribute belongs at the capability level?

As I said, on the capability level I'd say the informal convention
"everything but the newest version is deprecated" is enough until
proven insufficient.

However, if you want to shut down a service at some point, you could
make a *different* resource record and declare it the old service's
replacement; that's not really dependent on different protocol
versions, there could be many reasons for moving services.  You need
VOResource 1.1 (RFC now!  Hurry!) to do that, though.  The sketch is:

Old Service:

  <Resource>
    <identifier>ivo://old.provider/oldservice</identifer>
    ...
    <relationship>
      <relationshipType>isContinuedBy</relationshipType>
      <relatedResource ivo-id="ivo://new.provider/newservice"
        >New Service</relatedResource>
    </relationship>
  </Resource>

New Service:

  <Resource>
    <identifier>ivo://new.provider/newservice</identifer>
    ...
    <relationship>
      <relationshipType>Continues</relationshipType>
      <relatedResource ivo-id="ivo://old.provider/oldservice"
        >Old Service</relatedResource>
    </relationship>
  </Resource>

Clients could take the presence of an isContinuedBy as an indication
that a service is deprecated.  I'm not sure, though, I'd like to make
a recommendation to check for isContinuedBy relationships as a part
of normal discovery operations.

IMHO more important than the isContinuedBy here is the Continues
relationship of the new service.  The reason is that the old service
will presumably get deleted from the Registry at some point.  With
this record, the isContinuedBy relationship will be gone.

But clients that, for one reason or another, still have the old
ivoid, can still do a RegTAP query like:

  SELECT ivoid
  FROM rr.relationship
  WHERE
    related_name='Continues'
    AND related_id='ivo://new.provider/newservice'

I'm sure no existing client does anything of this kind yet, and given
the usual modes of discovery so far I don't think they should.[1]

In VOSpace identifier resolution, where there's a built-in ivoid
reference, that might be different; being able to move a VOSpace's
registry record while still enabling resolution might be a use case.
Again, I'd be happy to help working out language for recommendations
for clients on how to deal with "broken" vos: URIs.

         -- Markus


[1] Note to the Registry folks: We have a little issue here in that
this (IMHO altogether valid) use case requires an ivoid that doesn't
really have a matching resource record (you could argue there's a
deleted record, but there's no requirement to keep it, and it won't
be in a searchable registry even if it's kept).  Hm.  Have you
noticed the three-headed monkey just outside your window?