Proposal for deprecation of Cassandra 3.11 support and REST API v1 in Stargate v3

[jeffreyscarpenter]

Now that Stargate v2 has been officially released, there are a couple of features that the core team has identified that we'd like to mark for deprecation in order to help streamline development work moving forward.

• Cassandra 3.11 Persistence Backend - According to the Cassandra documentation, the 3.11 release is currently the "Previous Stable Version" scheduled for maintenance until 4.2 is released in mid-2023. Since 3.11 has a dependency on Java 8, removal of the 3.11 persistence backend would allow the build of the coordinator modules to be updated to Java 11 (for Cassandra 4.x) and to use a Java 11 base Docker image.
• REST API v1 endpoints - The /v1 endpoints are available in the Stargate v2 coordinator node, since we elected to only implement the /v2 endpoints on the new REST API Service added in Stargate v2. Removing support for the /v1 endpoints would allow the deletion of the restapi module. Usage data from Astra indicates the vast majority of REST API usage is on v1 endpoints.

The intent is to mark these features as deprecated in Stargate v2, and remove them in a Stargate v3 release. We do not currently have a target date or feature list for Stargate v3, but anticipate this being sometime in mid-2023. We will communicate more detail as it becomes available.

Please use this discussion to respond with any questions or comments.

[maheshrajamani]

@tatu-at-datastax Can we have a flag to add the restapi and graphqlapi jar to the osgi code? This way default deployment of the services in coordinator can be avoided.

[tatu-at-datastax]

I think the current plan is to simply remove old graphql and docs api implementations (there was even a PR) once we trust the new implementations. And same for RestV2 part of in-Coordinator REST API.
There is some benefit to simple removal as then things these APIs depend on can also be removed, compared to keeping them around as optionally included.

[jeffreyscarpenter]

I think the current plan is to simply remove old graphql and docs api implementations (there was even a PR) once we trust the new implementations. And same for RestV2 part of in-Coordinator REST API.

Yes, the pertinent issues are: #2121 and #2117

[ivansenic]

Regarding v1, I would propose to mark them deprecated and disabled by default, with the config option to enable them. This is best way to make people aware this is going away.

Wrt to persistance backend, we should do the same maybe? Would this even be possible? If not, then we should explicitly state it in the README and print in the logs on the module startup.

[tatu-at-datastax]

Yes, I think there is a system property that does this (enables/disables RESTv1 end point).
Default of "disabled" would make sense for OSS, and explicitly enable for Astra where it is deprecated but available until next major version, for backwards compatibility.

On backend/persistence, probably can only add in documentation as OSS users will run whatever they want.
Good idea to print a warning on startup.

[jeffreyscarpenter]

The system property stargate.rest.enableV1 only controls whether the REST API module in the coordinator exposes /v2 paths. The /v1 paths are always exposed. There is currently no way to disable the entire module. Do we want to modify this behavior?

[tatu-at-datastax]

@jeffreyscarpenter Ah, right you are. Too bad I chose name like that which implies different behavior.

We could decide to either change behavior or add yet another property, I don't have a strong opinion either way.
Although thinking out a loud, changing behavior would be more confusing as its meaning would depend on version.
So maybe adding a new property would be safer. And then selecting what is the default, in absence of setting. Maybe enable by default?

[jeffreyscarpenter]

@polandll this may have documentation implications as well

[jeffreyscarpenter]

Issues for C* 3.11 deprecation warning:

• Mark Cassandra 3.11 Persistence as Deprecated #2254
• Update Stargate docs to reflect deprecation of Cassandra 3.11 support docs#235

[jeffreyscarpenter]

While we're on this topic, I guess we should also discuss deprecation of Stargate v1. This would include:

• Marking https://github.com/stargate/docker-images as deprecated (since Docker images are built in this repo for v2)
• Updating README on v1 branch
• Updating Docker Hub pages for v1 specific images.

Suggest this would have a similar timeline - maintain v1 until we release Stargate v3.

[tatu-at-datastax]

Makes sense. We can also start considering some fixes to be v2-only in cases where fix itself requires different changes (as API implementations are separate), obv. depending on severity of the issue & added effort to fix v1.

[jeffreyscarpenter]

I broke this last point about deprecating the v1 branch out into a separate discussion to give it proper visibility: #2294

[jeffreyscarpenter]

This discussion is considered closed as all documentation and code changes have been implemented.

[jeffreyscarpenter]

We are now moving forward with removal of 3.11 support.