Allow newer Azure Storage SDKs in azure-kusto-ingest
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
Research direction
Start with azure-kusto-ingest/pyproject.toml and the Queue and Blob client construction in azure/kusto/ingest/ingest_client.py. Review the linked Azure SDK discussion, determine which service API version the managed ingestion storage accounts support, and test queued ingestion with newer Storage SDKs. Done means compatibility is established and the dependency constraints or client configuration can be changed safely if supported.
Written by the indexing model from the issue text.
Description
Codex for Tamir:
I’m upgrading an environment from Kusto Data and Ingest 5.0.1 to 6.0.4. It already uses Azure Storage Blob 12.28.0 and Queue 12.15.0, and I expected to keep those versions during the Kusto upgrade. But Ingest 6.0.4 requires Blob 12.26.0 and Queue 12.13.0 exactly, so those requirements are incompatible with the installed Storage versions.
I traced the exact pins to 51d8968a6, introduced in #574 after newer Storage SDKs began requesting an API version that was not yet available everywhere. The linked Azure SDK discussion describes the partial service rollout, and its last substantive update still mentions one lagging scale unit.
Kusto creates its Queue client and Blob client without an explicit api_version, so it relies on the SDK defaults. Are the exact package pins still needed? If Kusto-managed ingestion storage accounts still require an older service API, could these clients select that API version explicitly and allow applications to upgrade the Blob and Queue packages independently?
I have not tested live queued ingestion with the newer Storage SDKs. Before preparing a change, I’d like to understand whether the service limitation still exists and which API version these accounts support.
- Dominant language
- Python
- Stars
- 204
- Forks
- 119
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Azure/azure-kusto-python
-
When query against Log Analytics workspaces, dynamic are not converted to listMay be free again @yogilad claimed this 1131 days ago, and no pull request is open. Open
Azure/azure-kusto-python#491 · 2 comments · 1 assignee ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
Azure/azure-kusto-python#470 · 5 comments ·
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
Azure/azure-kusto-python#424 · 4 comments ·
-
Discussion enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
Azure/azure-kusto-python#191 · 3 comments · 2 reactions ·
-
Discussion
Difficulty 5/5 Over a week Newbie friendliness 25/100
Azure/azure-kusto-python#126 · 2 comments ·
All issues in Azure/azure-kusto-python
Similar issues
-
first
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
AcademySoftwareFoundation/rmtc#54 · 1 comment ·
-
feature/cohorts feature/feature-flags team/feature-flags
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
License examples/ as MITPossibly taken @PGrayCS claimed this today. Opendocumentation enhancement example good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
speedyk-005/yasbd-lib#383 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
interactions-py/interactions.py#1827 ·
-
Managed start can fail when OpenVMM reads its control capability before NVX writes itPossibly taken @ppenna claimed this today. Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day