Skip to content

Commit 52755c1

Browse files
ritwik-gritwik-g
committed
feat: Improve add-deployment Command Tests and Coverage
1 parent 36aec3d commit 52755c1

File tree

16 files changed

+791
-8
lines changed

16 files changed

+791
-8
lines changed

‎docs/ADRs/006-helm-style-logging.md

Lines changed: 16 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -31,6 +31,12 @@ class HelmLogger:
3131
if args:
3232
msg = msg % args
3333
print("Error: %s" % msg, file=sys.stderr)
34+
35+
@staticmethod
36+
def warning(msg: str, *args: Any) -> None:
37+
if args:
38+
msg = msg % args
39+
print("Warning: %s" % msg, file=sys.stderr)
3440
```
3541

3642
### 2. Key Design Decisions
@@ -39,6 +45,7 @@ class HelmLogger:
3945
- Use stderr for all output
4046
- Prefix debug messages with "[debug]"
4147
- Prefix error messages with "Error:"
48+
- Prefix warning messages with "Warning:"
4249
- Control debug output via HELM_DEBUG environment variable
4350

4451
2. **Performance Optimization**
@@ -67,6 +74,7 @@ def some_function():
6774
logger.debug("Success!")
6875
except Exception as e:
6976
logger.error("Failed: %s", str(e))
77+
logger.warning("Something unexpected happened")
7078
```
7179

7280
## Consequences
@@ -95,7 +103,7 @@ def some_function():
95103
### Negative
96104
1. **Limited Flexibility**
97105
- Fixed output format
98-
- No log levels beyond debug/error
106+
- Limited log levels (debug/warning/error)
99107
- No log file support
100108

101109
2. **Global State**
@@ -113,6 +121,12 @@ def test_debug_output():
113121
mock.patch('helm_values_manager.utils.logger.sys.stderr', stderr):
114122
logger.debug("Test message")
115123
assert stderr.getvalue() == "[debug] Test message\n"
124+
125+
def test_warning_output():
126+
stderr = StringIO()
127+
with mock.patch('helm_values_manager.utils.logger.sys.stderr', stderr):
128+
logger.warning("Test warning")
129+
assert stderr.getvalue() == "Warning: Test warning\n"
116130
```
117131

118132
2. **Integration**
@@ -122,4 +136,5 @@ def validate(self):
122136
logger.debug("Validating PathData for path: %s", self.path)
123137
if not self.is_valid():
124138
logger.error("Invalid PathData: %s", self.path)
139+
logger.warning("PathData validation completed with warnings")
125140
```

‎docs/ADRs/011-command-structure-for-deployments.md

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
# ADR-011: Command Structure for Deployments and Backends
2+
3+
Date: 2025-02-28
4+
5+
## Status
6+
7+
Accepted
8+
9+
## Context
10+
11+
The Helm Values Manager needs to support multiple backend types (git-secret, aws, azure, gcp) and authentication methods (env, file, direct, managed_identity) for storing and retrieving values. The current implementation uses a single `add-deployment` command with many parameters, which can be complex and difficult to use.
12+
13+
As we implement more backend types and authentication methods, the command structure needs to be intuitive, discoverable, and maintainable. The command interface should guide users to provide the correct parameters for each backend and authentication type.
14+
15+
## Decision
16+
17+
We will adopt a nested subcommand structure for deployment and backend management with the following pattern:
18+
19+
```
20+
helm values add-deployment [name]
21+
22+
helm values add-backend [backend] --deployment=[name] [backend_options]
23+
- helm values add-backend aws --deployment=prod --region=us-west-2
24+
- helm values add-backend azure --deployment=prod --vault-url=https://myvault.vault.azure.net
25+
- helm values add-backend gcp --deployment=prod --project-id=my-project
26+
- helm values add-backend git-secret --deployment=prod
27+
```
28+
29+
Initially, deployments will be created with a `no-backend` type and `no-auth` authentication, indicating that they don't have a backend or authentication configured yet. This allows for deployments that might not need sensitive values, while providing a clear path to add a backend later if needed.
30+
31+
For authentication, we will use a similar pattern:
32+
33+
```
34+
helm values add-auth [auth_type] --deployment=[name] [auth_options]
35+
- helm values add-auth direct --deployment=prod --credentials='{...}'
36+
- helm values add-auth env --deployment=prod --env-prefix=AWS_
37+
- helm values add-auth file --deployment=prod --auth-path=~/.aws/credentials
38+
- helm values add-auth managed-identity --deployment=prod
39+
```
40+
41+
This approach:
42+
1. Separates the concerns of creating a deployment, configuring a backend, and setting up authentication
43+
2. Uses subcommands to provide context-specific options and help text
44+
3. Follows a natural workflow of first creating a deployment, then adding backend and auth configuration
45+
4. Supports deployments without sensitive values through the `no-backend` option
46+
47+
For the initial implementation, we will only implement the `add-deployment` command, with the backend and auth commands to be implemented later.
48+
49+
## Consequences
50+
51+
### Positive
52+
53+
- **Improved User Experience**: Users only see options relevant to their current task
54+
- **Better Discoverability**: Each subcommand can have its own help text explaining the specific options
55+
- **Progressive Disclosure**: Complex options are only shown when needed
56+
- **Reduced Cognitive Load**: Users don't need to remember all possible combinations of options
57+
- **Better Validation**: Each command can validate its specific inputs more effectively
58+
- **Maintainability**: New backend types and auth methods can be added without changing existing commands
59+
- **Flexibility**: Users can create deployments without immediately configuring backends, allowing for more flexible workflows
60+
- **Safety**: The `no-backend` option provides a clear indication that a deployment is not configured for sensitive values, and validation can prevent adding sensitive values to such deployments
61+
62+
### Negative
63+
64+
- **More Commands**: Users need to run multiple commands to fully configure a deployment
65+
- **Learning Curve**: Users need to learn the command structure and workflow
66+
- **Implementation Complexity**: More commands means more code to maintain
67+
68+
### Neutral
69+
70+
- **Alignment with Other Tools**: This approach is similar to other CLI tools like `git` and `kubectl`
71+
- **Documentation Requirements**: We will need to document the command workflow clearly
72+
73+
## Implementation Notes
74+
75+
1. For the initial implementation, we will only implement the `add-deployment` command, which will create a deployment with minimal configuration.
76+
2. The `add-deployment` command will validate that the deployment name is unique and create a basic deployment entry in the configuration.
77+
3. The backend and auth commands will be implemented later, with appropriate validation to ensure that the referenced deployment exists.
78+
4. We will use Typer's nested command structure to implement this design.
79+
5. The `Deployment` class will need to support a "partial" state where backend and auth configuration may not be fully defined yet.
80+
81+
## Related Issues
82+
83+
- GitHub Issue #[TBD]: Implement command structure for deployments and backends

‎docs/ADRs/README.md

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -78,3 +78,10 @@ For new ADRs, use the [ADR template](adr-template.md) as a starting point.
7878
- **Decision**: Implement configuration comparison and smart merging with multiple strategies
7979
- **Impact**: Simplifies configuration updates and reduces risk of missing required changes
8080
- **Dependencies**: ADR-001
81+
82+
### [ADR-011: Command Structure for Deployments and Backends](011-command-structure-for-deployments.md)
83+
- **Status**: Accepted
84+
- **Context**: Need for intuitive command structure for managing deployments with multiple backends and auth types
85+
- **Decision**: Implement nested subcommand structure for deployment, backend, and auth configuration
86+
- **Impact**: Improves user experience, discoverability, and maintainability
87+
- **Dependencies**: ADR-001

‎docs/Design/backends-and-auth.md

Lines changed: 188 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,188 @@
1+
# Backends and Authentication Types
2+
3+
This document provides a comprehensive overview of the supported backends, authentication types, and backend configurations in the Helm Values Manager.
4+
5+
## Supported Backends
6+
7+
The Helm Values Manager supports the following backend types for storing values:
8+
9+
| Backend Type | Description | Use Case | Status |
10+
|--------------|-------------|----------|--------|
11+
| `git-secret` | Uses git-secret for encrypting sensitive values | Local development, small teams | Planned |
12+
| `aws` | Uses AWS Secrets Manager for storing sensitive values | AWS-based deployments | Planned |
13+
| `azure` | Uses Azure Key Vault for storing sensitive values | Azure-based deployments | Planned |
14+
| `gcp` | Uses Google Secret Manager for storing sensitive values | GCP-based deployments | Planned |
15+
16+
### Backend Selection Criteria
17+
18+
When selecting a backend, consider:
19+
20+
1. **Security Requirements**: Different backends offer varying levels of security, audit capabilities, and compliance features.
21+
2. **Cloud Provider**: Select the backend that aligns with your cloud infrastructure.
22+
3. **Team Size**: For small teams, simpler backends like `git-secret` may be sufficient.
23+
4. **Operational Complexity**: Some backends require more setup and maintenance than others.
24+
25+
## Authentication Types
26+
27+
Each backend supports multiple authentication methods:
28+
29+
| Auth Type | Description | Required Parameters | Supported Backends |
30+
|-----------|-------------|---------------------|-------------------|
31+
| `direct` | Direct credential input | `credentials` object | All |
32+
| `env` | Environment variable-based authentication | `env_prefix` | All |
33+
| `file` | File-based authentication | `path` to auth file | All |
34+
| `managed_identity` | Cloud provider managed identity | None | `aws`, `azure`, `gcp` |
35+
36+
### Authentication Type Details
37+
38+
#### Direct Authentication (`direct`)
39+
40+
Credentials are provided directly in the configuration file. This is suitable for testing but not recommended for production use.
41+
42+
**Required Parameters:**
43+
- `credentials`: An object containing backend-specific credentials
44+
45+
**Example:**
46+
```json
47+
"auth": {
48+
"type": "direct",
49+
"credentials": {
50+
"token": "your-token-here"
51+
}
52+
}
53+
```
54+
55+
#### Environment Variable Authentication (`env`)
56+
57+
Credentials are read from environment variables. This is suitable for CI/CD pipelines and containerized deployments.
58+
59+
**Required Parameters:**
60+
- `env_prefix`: Prefix for environment variables
61+
62+
**Example:**
63+
```json
64+
"auth": {
65+
"type": "env",
66+
"env_prefix": "AWS_"
67+
}
68+
```
69+
70+
#### File Authentication (`file`)
71+
72+
Credentials are read from a file. This is suitable for local development and when credentials are managed by external systems.
73+
74+
**Required Parameters:**
75+
- `path`: Path to the authentication file
76+
77+
**Example:**
78+
```json
79+
"auth": {
80+
"type": "file",
81+
"path": "~/.aws/credentials"
82+
}
83+
```
84+
85+
#### Managed Identity Authentication (`managed_identity`)
86+
87+
Uses cloud provider's managed identity service. This is the recommended approach for production deployments in cloud environments.
88+
89+
**Required Parameters:**
90+
- None
91+
92+
**Example:**
93+
```json
94+
"auth": {
95+
"type": "managed_identity"
96+
}
97+
```
98+
99+
## Backend Configurations
100+
101+
Each backend may require additional configuration parameters:
102+
103+
### Git Secret Backend (`git-secret`)
104+
105+
| Parameter | Description | Required | Default |
106+
|-----------|-------------|----------|---------|
107+
| None | No additional configuration required | - | - |
108+
109+
### AWS Secrets Manager Backend (`aws`)
110+
111+
| Parameter | Description | Required | Default |
112+
|-----------|-------------|----------|---------|
113+
| `region` | AWS region | Yes | - |
114+
| `prefix` | Prefix for secret names | No | Empty string |
115+
| `endpoint` | Custom endpoint URL | No | AWS default endpoint |
116+
117+
**Example:**
118+
```json
119+
"backend_config": {
120+
"region": "us-west-2",
121+
"prefix": "myapp/"
122+
}
123+
```
124+
125+
### Azure Key Vault Backend (`azure`)
126+
127+
| Parameter | Description | Required | Default |
128+
|-----------|-------------|----------|---------|
129+
| `vault_url` | Key Vault URL | Yes | - |
130+
| `prefix` | Prefix for secret names | No | Empty string |
131+
132+
**Example:**
133+
```json
134+
"backend_config": {
135+
"vault_url": "https://myvault.vault.azure.net/",
136+
"prefix": "myapp-"
137+
}
138+
```
139+
140+
### Google Secret Manager Backend (`gcp`)
141+
142+
| Parameter | Description | Required | Default |
143+
|-----------|-------------|----------|---------|
144+
| `project_id` | GCP Project ID | Yes | - |
145+
| `prefix` | Prefix for secret names | No | Empty string |
146+
147+
**Example:**
148+
```json
149+
"backend_config": {
150+
"project_id": "my-gcp-project",
151+
"prefix": "myapp_"
152+
}
153+
```
154+
155+
## Implementation Status
156+
157+
For the MVP release, the following components are implemented:
158+
159+
1. **Command Interface**:
160+
- `add-deployment`: Command interface implemented
161+
- Backend validation: Interface defined, implementation pending
162+
163+
2. **Backends**:
164+
- All backends: Interface defined, implementation pending
165+
166+
3. **Authentication Types**:
167+
- All auth types: Interface defined, implementation pending
168+
169+
4. **Backend Configurations**:
170+
- Basic validation implemented
171+
- Backend-specific validation defined in the command interface
172+
173+
## Future Enhancements
174+
175+
1. **Additional Backends**:
176+
- HashiCorp Vault
177+
- Kubernetes Secrets
178+
- Custom backends via plugins
179+
180+
2. **Enhanced Authentication**:
181+
- OIDC support
182+
- Role-based access for cloud providers
183+
- Multi-factor authentication integration
184+
185+
3. **Configuration Extensions**:
186+
- Rotation policies
187+
- Versioning support
188+
- Audit logging

‎docs/Design/low-level-design.md

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -174,6 +174,31 @@ Benefits:
174174
- Automatic file locking
175175
- Configuration backup support
176176

177+
#### Command Structure for Deployments and Backends
178+
179+
The command structure for managing deployments and backends follows a nested subcommand pattern (see [ADR-011](../ADRs/011-command-structure-for-deployments.md)):
180+
181+
```
182+
helm values add-deployment [name]
183+
184+
helm values add-backend [backend] --deployment=[name] [backend_options]
185+
- helm values add-backend aws --deployment=prod --region=us-west-2
186+
- helm values add-backend azure --deployment=prod --vault-url=https://myvault.vault.azure.net
187+
- helm values add-backend gcp --deployment=prod --project-id=my-project
188+
- helm values add-backend git-secret --deployment=prod
189+
190+
helm values add-auth [auth_type] --deployment=[name] [auth_options]
191+
- helm values add-auth direct --deployment=prod --credentials='{...}'
192+
- helm values add-auth env --deployment=prod --env-prefix=AWS_
193+
- helm values add-auth file --deployment=prod --auth-path=~/.aws/credentials
194+
- helm values add-auth managed-identity --deployment=prod
195+
```
196+
197+
This structure:
198+
- Separates the concerns of creating a deployment, configuring a backend, and setting up authentication
199+
- Uses subcommands to provide context-specific options and help text
200+
- Follows a natural workflow of first creating a deployment, then adding backend and auth configuration
201+
177202
### 4. Storage Backends
178203

179204
The `ValueBackend` interface defines the contract for value storage:
@@ -202,6 +227,8 @@ Implementations:
202227
- Azure Key Vault Backend
203228
- Additional backends can be easily added
204229

230+
For a comprehensive overview of supported backends, authentication types, and backend configurations, see [Backends and Authentication Types](backends-and-auth.md).
231+
205232
### 5. Schema Validation
206233

207234
The configuration system uses JSON Schema validation to ensure data integrity and consistency:

0 commit comments

Comments
 (0)