[
https://issues.apache.org/jira/browse/CASSANDRA-21195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
BHARATH KUMAR updated CASSANDRA-21195:
--------------------------------------
Description:
*Overview*
Several components in Apache Cassandra require making HTTP calls to external
services (e.g., cloud metadata services or external authentication providers).
Currently, HTTP logic exists within specific implementations such as
{{{}AbstractCloudMetadataServiceConnector{}}}, which limits reuse and leads to
duplication if additional components require similar functionality.
This proposal introduces a generic, reusable HTTP utility under the {{utils}}
package that can be leveraged across Cassandra components requiring synchronous
HTTP interactions.
*Goals*
* Introduce a generic HTTP utility that can be reused across the Cassandra
codebase
* Avoid modifying existing behavior during the initial implementation
* Refactor existing cloud metadata connectors to leverage the shared utility
* Provide a foundation that can support additional HTTP methods and use cases
in the future
* Keep response parsing outside the utility to maintain separation of concerns
*Non-Goals*
The following are intentionally out of scope for the initial implementation:
* Introducing asynchronous HTTP clients
* Implementing automatic response parsing
* Adding external dependencies
* Changing existing public interfaces
* Modifying the behavior of existing cloud metadata connectors
The goal is strictly to extract and centralize HTTP logic, not redesign the
existing functionality.
*Design Principles*
# *Simplicity* - The utility will support synchronous HTTP requests only
# *Reusability* - Minimal interface that allows reuse across different
Cassandra components
# *Separation of Concerns* - Utility responsible only for executing HTTP
requests and returning raw responses; parsing remains the caller's
responsibility
# *Backward Compatibility* - Existing functionality must remain unchanged
during early phases
*Implementation Plan*
The implementation will be delivered in phases:
*Phase 1: Introduce HTTP Utility*
* Create a new {{HttpUtil}} class in {{org.apache.cassandra.utils}} package
* Encapsulate common HTTP logic from cloud metadata connectors
* Support synchronous HTTP requests with configurable timeouts and headers
* No modifications to existing classes (zero behavioral impact)
*Phase 2: Refactor Cloud Metadata Implementations*
* Update existing cloud metadata implementations to use {{HttpUtil}} internally
* Replace duplicated HTTP code with shared utility
* Preserve existing external behavior and APIs
*Phase 3: Validation and Regression Testing*
* Ensure all cloud metadata implementations behave exactly as before
* Validate through existing tests
* Confirm no regressions in metadata retrieval or authentication flows
*Phase 4: Extend the HTTP Utility*
* Add support for additional HTTP methods (POST, PUT, DELETE)
* Improve header handling
* Add reusable configuration patterns
*Phase 5: Maintain Clear Response Handling Boundaries*
* Keep utility transport-focused only
* Execute HTTP request and return raw response
* Response parsing remains with calling implementation
Current HTTP Usage in Cassandra
Analysis of existing code shows:
* {*}GET requests{*}: Used by all cloud metadata services (AWS EC2, Azure,
GCP, Alibaba Cloud, Cloudstack)
* {*}PUT requests{*}: Used by AWS IMDSv2 for token retrieval
({{{}Ec2MetadataServiceConnector.V2Connector{}}})
* Pattern: {{AbstractCloudMetadataServiceConnector.apiCall()}} method (lines
100-135)
Benefits
* *Reduced Code Duplication* - HTTP logic centralized rather than reimplemented
* *Improved Maintainability* - Bug fixes/improvements in one place
* *Better Extensibility* - Future features can reuse the same utility
* *Low Risk Migration* - Phased approach ensures minimal disruption
Future Opportunities
Once stable, the utility may be reused for:
* External secret managers (HashiCorp Vault)
* Metadata services
* Authentication integrations
* Configuration services
This utility could become the standard HTTP interaction mechanism within
Cassandra for startup-time operations.
was:
*Overview*
Several components in Apache Cassandra require making HTTP calls to external
services (e.g., cloud metadata services or external authentication providers).
Currently, HTTP logic exists within specific implementations such as
{{{}AbstractCloudMetadataServiceConnector{}}}, which limits reuse and leads to
duplication if additional components require similar functionality.
This proposal introduces a generic, reusable HTTP utility under the {{utils}}
package that can be leveraged across Cassandra components requiring synchronous
HTTP interactions.
*Goals*
* Introduce a generic HTTP utility that can be reused across the Cassandra
codebase
* Avoid modifying existing behavior during the initial implementation
* Refactor existing cloud metadata connectors to leverage the shared utility
* Provide a foundation that can support additional HTTP methods and use cases
in the future
* Keep response parsing outside the utility to maintain separation of concerns
*Non-Goals*
The following are intentionally out of scope for the initial implementation:
* Introducing asynchronous HTTP clients
* Implementing automatic response parsing
* Adding external dependencies
* Changing existing public interfaces
* Modifying behavior of existing cloud metadata connectors
The goal is strictly to extract and centralize HTTP logic, not redesign the
existing functionality.
*Design Principles*
# *Simplicity* - The utility will support synchronous HTTP requests only
# *Reusability* - Minimal interface that allows reuse across different
Cassandra components
# *Separation of Concerns* - Utility responsible only for executing HTTP
requests and returning raw responses; parsing remains the caller's
responsibility
# *Backward Compatibility* - Existing functionality must remain unchanged
during early phases
*Implementation Plan*
The implementation will be delivered in phases:
*Phase 1: Introduce HTTP Utility*
* Create a new {{HttpUtil}} class in {{org.apache.cassandra.utils}} package
* Encapsulate common HTTP logic from cloud metadata connectors
* Support synchronous HTTP requests with configurable timeouts and headers
* No modifications to existing classes (zero behavioral impact)
*Phase 2: Refactor Cloud Metadata Implementations*
* Update existing cloud metadata implementations to use {{HttpUtil}} internally
* Replace duplicated HTTP code with shared utility
* Preserve existing external behavior and APIs
*Phase 3: Validation and Regression Testing*
* Ensure all cloud metadata implementations behave exactly as before
* Validate through existing tests
* Confirm no regressions in metadata retrieval or authentication flows
*Phase 4: Extend the HTTP Utility*
* Add support for additional HTTP methods (POST, PUT, DELETE)
* Improve header handling
* Add reusable configuration patterns
*Phase 5: Maintain Clear Response Handling Boundaries*
* Keep utility transport-focused only
* Execute HTTP request and return raw response
* Response parsing remains with calling implementation
Current HTTP Usage in Cassandra
Analysis of existing code shows:
* {*}GET requests{*}: Used by all cloud metadata services (AWS EC2, Azure,
GCP, Alibaba Cloud, Cloudstack)
* {*}PUT requests{*}: Used by AWS IMDSv2 for token retrieval
({{{}Ec2MetadataServiceConnector.V2Connector{}}})
* Pattern: {{AbstractCloudMetadataServiceConnector.apiCall()}} method (lines
100-135)
Benefits
* *Reduced Code Duplication* - HTTP logic centralized rather than reimplemented
* *Improved Maintainability* - Bug fixes/improvements in one place
* *Better Extensibility* - Future features can reuse the same utility
* *Low Risk Migration* - Phased approach ensures minimal disruption
Future Opportunities
Once stable, the utility may be reused for:
* External secret managers (HashiCorp Vault)
* Metadata services
* Authentication integrations
* Configuration services
This utility could become the standard HTTP interaction mechanism within
Cassandra for startup-time operations.
> Extract HTTP-related code around cloud snitches so it can be reusable across
> the codebase
> -----------------------------------------------------------------------------------------
>
> Key: CASSANDRA-21195
> URL: https://issues.apache.org/jira/browse/CASSANDRA-21195
> Project: Apache Cassandra
> Issue Type: Task
> Components: Legacy/Core
> Reporter: Stefan Miklosovic
> Assignee: BHARATH KUMAR
> Priority: Normal
>
> *Overview*
> Several components in Apache Cassandra require making HTTP calls to external
> services (e.g., cloud metadata services or external authentication
> providers). Currently, HTTP logic exists within specific implementations such
> as {{{}AbstractCloudMetadataServiceConnector{}}}, which limits reuse and
> leads to duplication if additional components require similar functionality.
> This proposal introduces a generic, reusable HTTP utility under the {{utils}}
> package that can be leveraged across Cassandra components requiring
> synchronous HTTP interactions.
> *Goals*
> * Introduce a generic HTTP utility that can be reused across the Cassandra
> codebase
> * Avoid modifying existing behavior during the initial implementation
> * Refactor existing cloud metadata connectors to leverage the shared utility
> * Provide a foundation that can support additional HTTP methods and use
> cases in the future
> * Keep response parsing outside the utility to maintain separation of
> concerns
> *Non-Goals*
> The following are intentionally out of scope for the initial implementation:
> * Introducing asynchronous HTTP clients
> * Implementing automatic response parsing
> * Adding external dependencies
> * Changing existing public interfaces
> * Modifying the behavior of existing cloud metadata connectors
> The goal is strictly to extract and centralize HTTP logic, not redesign the
> existing functionality.
> *Design Principles*
> # *Simplicity* - The utility will support synchronous HTTP requests only
> # *Reusability* - Minimal interface that allows reuse across different
> Cassandra components
> # *Separation of Concerns* - Utility responsible only for executing HTTP
> requests and returning raw responses; parsing remains the caller's
> responsibility
> # *Backward Compatibility* - Existing functionality must remain unchanged
> during early phases
> *Implementation Plan*
> The implementation will be delivered in phases:
> *Phase 1: Introduce HTTP Utility*
> * Create a new {{HttpUtil}} class in {{org.apache.cassandra.utils}} package
> * Encapsulate common HTTP logic from cloud metadata connectors
> * Support synchronous HTTP requests with configurable timeouts and headers
> * No modifications to existing classes (zero behavioral impact)
> *Phase 2: Refactor Cloud Metadata Implementations*
> * Update existing cloud metadata implementations to use {{HttpUtil}}
> internally
> * Replace duplicated HTTP code with shared utility
> * Preserve existing external behavior and APIs
> *Phase 3: Validation and Regression Testing*
> * Ensure all cloud metadata implementations behave exactly as before
> * Validate through existing tests
> * Confirm no regressions in metadata retrieval or authentication flows
> *Phase 4: Extend the HTTP Utility*
> * Add support for additional HTTP methods (POST, PUT, DELETE)
> * Improve header handling
> * Add reusable configuration patterns
> *Phase 5: Maintain Clear Response Handling Boundaries*
> * Keep utility transport-focused only
> * Execute HTTP request and return raw response
> * Response parsing remains with calling implementation
> Current HTTP Usage in Cassandra
> Analysis of existing code shows:
> * {*}GET requests{*}: Used by all cloud metadata services (AWS EC2, Azure,
> GCP, Alibaba Cloud, Cloudstack)
> * {*}PUT requests{*}: Used by AWS IMDSv2 for token retrieval
> ({{{}Ec2MetadataServiceConnector.V2Connector{}}})
> * Pattern: {{AbstractCloudMetadataServiceConnector.apiCall()}} method (lines
> 100-135)
> Benefits
> * *Reduced Code Duplication* - HTTP logic centralized rather than
> reimplemented
> * *Improved Maintainability* - Bug fixes/improvements in one place
> * *Better Extensibility* - Future features can reuse the same utility
> * *Low Risk Migration* - Phased approach ensures minimal disruption
> Future Opportunities
> Once stable, the utility may be reused for:
> * External secret managers (HashiCorp Vault)
> * Metadata services
> * Authentication integrations
> * Configuration services
> This utility could become the standard HTTP interaction mechanism within
> Cassandra for startup-time operations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
