potiuk commented on code in PR #74236:
URL: https://github.com/apache/airflow/pull/74236#discussion_r4185757745
##########
providers/google/pyproject.toml:
##########
@@ -82,14 +82,14 @@ dependencies = [
"google-auth-httplib2>=0.0.1",
"google-genai>=2.8.0",
# google-cloud-aiplatform doesn't install ray for python 3.12 (issue:
https://github.com/googleapis/python-aiplatform/issues/5252).
- # Temporarily lock in ray 2.42.0 which is compatible with python 3.12
until linked issue is solved.
+ # Temporarily require ray directly until the linked issue is solved.
# Remove the ray dependency as well as google-cloud-bigquery-storage once
linked issue is fixed
# Floor raised to 1.164.0: earlier "evaluation" extras cap litellm below
the version that
# carries the fixes for CVE-2026-35030 and its follow-on advisories on
Python 3.14.
# - https://github.com/googleapis/python-aiplatform/issues/7057
"google-cloud-aiplatform[evaluation]>=1.164.0",
- "ray[default]>=2.42.0;python_version<'3.13'",
- "ray[default]>=2.49.0;python_version>='3.13' and python_version <'3.14'",
+ "ray[default]>=2.52.0;python_version<'3.13'",
Review Comment:
This raises the `ray[default]` minimum of the **released** Google provider:
from `>=2.42.0` to `>=2.52.0` on Python < 3.13, and from `>=2.49.0` to
`>=2.52.0` on 3.13. The cleanup handler doesn't need it, and there's no
changelog note, so users pinned to ray 2.42–2.51 would hit resolution failures
or forced upgrades on the next provider release. It also leaves two identical
lines that could be merged. Could you drop it from this PR, or move it to its
own PR with the reason and a changelog entry?
##########
providers/google/tests/system/google/resources_cleanup/airflow_google_provider_resource_cleanup/handlers/alloydb.py:
##########
@@ -0,0 +1,55 @@
+#
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+from __future__ import annotations
+
+from airflow_google_provider_resource_cleanup.handlers._base import
BaseDeleteHandler
+from airflow_google_provider_resource_cleanup.helpers import get_resource_path
+from google.cloud import alloydb_v1
+
+
+async def _delete_resource(resource: dict, request_type, delete_method_name:
str, **request_kwargs):
+ client = alloydb_v1.AlloyDBAdminAsyncClient()
+ request = request_type(name=get_resource_path(resource), **request_kwargs)
+ operation = await getattr(client, delete_method_name)(request=request)
+ await operation.result()
+
+
+async def _delete_backup(resource: dict, log_prefix: str):
+ await _delete_resource(resource, alloydb_v1.DeleteBackupRequest,
"delete_backup")
+
+
+async def _delete_instance(resource: dict, log_prefix: str):
+ await _delete_resource(resource, alloydb_v1.DeleteInstanceRequest,
"delete_instance")
+
+
+async def _delete_cluster(resource: dict, log_prefix: str):
+ await _delete_resource(resource, alloydb_v1.DeleteClusterRequest,
"delete_cluster", force=True)
Review Comment:
All clusters are deleted in parallel here (one `asyncio.gather` per asset
type in `BaseDeleteHandler.handle`), but AlloyDB refuses to delete a primary
cluster while it still has secondary clusters. `force=True` only cascades to
instances, not to secondaries. `example_alloy_db.py` creates a secondary
cluster (`SECONDARY_CLUSTER_ID`), so if that test fails partway, cleanup
deletes the secondary and fails on the primary with `FAILED_PRECONDITION`. The
error is only printed, so the primary and its instances keep running and
billing until someone reruns the tool. Could you delete secondary clusters
before primaries, e.g. two passes split on `cluster_type` / `secondary_config`?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
