diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md new file mode 100644 index 0000000..24fbad4 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -0,0 +1,45 @@ +--- +name: Bug Report +about: Report a bug or issue with Azure IPAM +title: '[Bug] ' +labels: bug +assignees: '' +--- + +## Bug Description + +A clear and concise description of the bug. + +## Steps to Reproduce + +1. Go to '...' +2. Click on '...' +3. Scroll down to '...' +4. See error + +## Expected Behavior + +A clear and concise description of what you expected to happen. + +## Actual Behavior + +A clear and concise description of what actually happened. + +## Screenshots + +If applicable, add screenshots to help explain your problem. + +## Environment + +- **Deployment Type**: [e.g., Azure Container Apps, Docker, Kubernetes, Local] +- **Browser**: [e.g., Chrome 120, Firefox 121, Edge 120] +- **Azure IPAM Version**: [e.g., 1.0.0] +- **OS**: [e.g., Windows 11, macOS Sonoma] + +## Additional Context + +Add any other context about the problem here (logs, error messages, etc.) + +## Possible Solution + +If you have a suggestion for how to fix the bug, describe it here. diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md new file mode 100644 index 0000000..d7ff3a3 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -0,0 +1,41 @@ +--- +name: Feature Request +about: Suggest a new feature or enhancement for Azure IPAM +title: '[Feature Request] ' +labels: enhancement +assignees: '' +--- + +## Feature Summary + +A clear and concise description of the feature you'd like to see. + +## Problem Statement + +Describe the problem this feature would solve. What pain point or gap are you experiencing? + +## Proposed Solution + +Describe your ideal solution. How should this feature work? + +## Alternative Solutions + +Have you considered any alternative approaches? If so, describe them here. + +## Use Cases + +Provide specific scenarios where this feature would be valuable: +1. +2. +3. + +## Additional Context + +Add any other context, screenshots, mockups, or examples about the feature request here. + +## Acceptance Criteria + +What would need to be true for this feature to be considered complete? +- [ ] +- [ ] +- [ ] diff --git a/.github/ISSUE_TEMPLATE/reservations-and-exclusions.md b/.github/ISSUE_TEMPLATE/reservations-and-exclusions.md new file mode 100644 index 0000000..b254338 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/reservations-and-exclusions.md @@ -0,0 +1,259 @@ +--- +name: Feature Request - Reservations and Exclusions +about: New feature for IP Address Space Reservations and Exclusions management +title: '[Feature Request] IP Address Space Reservations and Exclusions' +labels: enhancement, feature-request +assignees: '' +--- + +## Feature Request: Reservations and Exclusions + +### Summary + +Add the ability to manage **IP Address Space Reservations** and **Exclusions** within Azure IPAM. This feature will enable network administrators to proactively plan IP address space allocation, prevent conflicts with external networks, and coordinate multi-team VNET deployments. + +--- + +## 🚫 Exclusions + +### Problem Statement + +Organizations often have address ranges that should **never** be used within their Azure environment due to: +- **Site-to-Site VPN connections** with suppliers, customers, or branch offices using specific address ranges +- **On-premises networks** that need to be routable from Azure +- **Partner/vendor networks** with established address spaces +- **Regulatory or compliance requirements** reserving specific ranges + +Currently, there is no way to mark these address ranges as "off-limits" in Azure IPAM, leading to potential deployment conflicts and connectivity issues. + +### Proposed Solution + +Allow users to define **Exclusion Ranges** that represent address spaces that should not be used within the Azure environment. + +#### Key Features + +1. **Add Exclusion Range** + - Define CIDR ranges that are excluded from use (e.g., `192.168.1.0/24`, `10.100.0.0/16`) + - Add a description/reason for the exclusion (e.g., "Customer XYZ Site-to-Site VPN") + - Optional: Set an expiration date for temporary exclusions + +2. **Exclusion Conflict Detection** + - When a user attempts to create a VNET/subnet that overlaps with an excluded range: + - Display a **warning notification** indicating the conflict + - Show which exclusion rule is being violated + - Provide details on why the range was excluded + - Integrate with existing CIDR Conflict Detection feature + +3. **Exclusion Management UI** + - New tab/section in the dashboard: **"Exclusions"** + - Table view with columns: + - CIDR Range + - Description/Reason + - Created By + - Created Date + - Expiration Date (if applicable) + - Status (Active/Expired) + - Actions: Add, Edit, Delete exclusion rules + +4. **Visual Indicators** + - In subnet/VNET views, mark ranges that overlap with exclusions + - Use distinct color coding (e.g., ⚫ black or 🔴 red striped) for excluded ranges + - Display exclusion indicators in the address space visualization + +--- + +## 📋 Reservations + +### Problem Statement + +In environments with multiple teams deploying Azure infrastructure: +- Teams may unknowingly deploy VNETs in overlapping address spaces +- Planning for future growth requires "reserving" address space before deployment +- No visibility into which address ranges are planned vs. actually deployed +- Lack of coordination leads to address space fragmentation + +### Proposed Solution + +Allow users to **reserve** address spaces for future VNET/subnet deployments, providing visibility and preventing conflicts before they occur. + +#### Key Features + +1. **Create Reservation** + - Reserve a CIDR range for future use (e.g., `10.50.0.0/16`) + - Add metadata: + - **Name/Title**: Brief identifier (e.g., "Project Alpha Network") + - **Description**: Purpose of the reservation + - **Requested By**: Team/user who requested the reservation + - **Target Date**: Expected deployment date + - **Subscription**: Target Azure subscription (optional) + - **Region**: Target Azure region (optional) + - Prevent overlapping reservations + +2. **Reservation States** + - **Reserved**: Address space is held for future use + - **Partially Used**: Some of the reserved range has been deployed + - **Fully Used**: Entire reserved range is now deployed + - **Expired**: Reservation expired without deployment + +3. **Reservation-to-Deployment Tracking** + - Automatically detect when a deployed VNET/subnet matches a reservation + - Update reservation status when corresponding resources are created + - Maintain history of reservations and their fulfillment + +4. **Address Space Visualization** + - Enhanced dashboard view showing: + - 🟢 **Free Address Spaces**: Available for use + - 🟡 **Reserved Address Spaces**: Planned for future deployment + - 🔵 **Used Address Spaces**: Currently deployed VNETs/subnets + - ⚫ **Excluded Address Spaces**: Off-limits ranges + - Interactive address space map/diagram + +5. **Reservation Management UI** + - New tab/section: **"Reservations"** + - Table view with columns: + - CIDR Range + - Name/Title + - Description + - Requested By + - Created Date + - Target Date + - Status + - Actions: Add, Edit, Delete, Convert to Deployment + +6. **Conflict Prevention** + - Warn when attempting to reserve an already reserved/deployed/excluded range + - Suggest available address ranges based on current usage patterns + - Integration with existing CIDR Conflict Detection + +--- + +## 💾 Data Storage Considerations + +### Options + +1. **Azure Storage Account (Table Storage or Cosmos DB)** + - Persistent storage for reservations and exclusions + - Requires infrastructure changes + +2. **Azure Resource Tags** + - Store reservations as metadata on a dedicated Azure resource + - No additional infrastructure needed + +3. **JSON Configuration File** + - Simple file-based storage + - Good for smaller deployments + +### Recommended Approach + +Use **Azure Table Storage** or **Cosmos DB** for: +- Scalability and performance +- Built-in Azure integration +- Auditing and versioning capabilities + +--- + +## 📐 UI/UX Mockup Suggestions + +### Dashboard Summary Card +``` +┌────────────────────────────────────────┐ +│ Address Space Overview │ +├────────────────────────────────────────┤ +│ 🟢 Free: 10.0.0.0/8 (65%) │ +│ 🔵 Deployed: 10.50.0.0/12 (25%) │ +│ 🟡 Reserved: 10.100.0.0/14 (7%) │ +│ ⚫ Excluded: 192.168.0.0/16 (3%) │ +└────────────────────────────────────────┘ +``` + +### New Navigation Tabs +``` +[ IP Addresses ] [ Subnets ] [ Conflicts ] [ Events ] [ Orphans ] [ Reservations ] [ Exclusions ] +``` + +--- + +## 🔄 API Endpoints (Proposed) + +### Exclusions API + +| Method | Endpoint | Description | +|--------|----------|-------------| +| GET | `/api/exclusions` | List all exclusions | +| POST | `/api/exclusions` | Create new exclusion | +| PUT | `/api/exclusions/{id}` | Update exclusion | +| DELETE | `/api/exclusions/{id}` | Delete exclusion | +| GET | `/api/exclusions/check/{cidr}` | Check if CIDR overlaps with exclusions | + +### Reservations API + +| Method | Endpoint | Description | +|--------|----------|-------------| +| GET | `/api/reservations` | List all reservations | +| POST | `/api/reservations` | Create new reservation | +| PUT | `/api/reservations/{id}` | Update reservation | +| DELETE | `/api/reservations/{id}` | Delete reservation | +| GET | `/api/reservations/check/{cidr}` | Check if CIDR overlaps with reservations | +| GET | `/api/reservations/available` | Get available address ranges | + +--- + +## ✅ Acceptance Criteria + +### Exclusions +- [ ] Users can add, edit, and delete exclusion ranges +- [ ] System detects and warns about conflicts with excluded ranges +- [ ] Exclusions are visible in the address space visualization +- [ ] Exclusions integrate with existing CIDR Conflict Detection + +### Reservations +- [ ] Users can create, modify, and delete reservations +- [ ] Reserved ranges are protected from overlapping reservations +- [ ] System tracks deployment of reserved ranges +- [ ] Dashboard shows free, reserved, and used address spaces +- [ ] Reservation status updates automatically when resources are deployed + +### General +- [ ] Data persists across sessions +- [ ] Audit trail for all changes to reservations and exclusions +- [ ] Export capability for reservations and exclusions +- [ ] Role-based access control for managing reservations/exclusions + +--- + +## 🎯 Priority & Scope + +### Phase 1 (MVP) +- Basic CRUD for Exclusions +- Basic CRUD for Reservations +- Simple visualization in dashboard + +### Phase 2 +- Automatic conflict detection and warnings +- Integration with existing CIDR Conflict Detection +- Reservation status tracking + +### Phase 3 +- Advanced visualization (address space map) +- Auto-suggest available ranges +- Audit trail and history + +--- + +## 📚 References + +- Current CIDR Conflict Detection implementation +- Azure IPAM subnet utilization tracking +- Similar features in other IPAM tools (e.g., NetBox, phpIPAM) + +--- + +## Additional Notes + +This feature request addresses common enterprise networking challenges: +1. **Multi-team coordination** - Prevent conflicts when multiple teams deploy infrastructure +2. **Hybrid connectivity** - Track address spaces used by on-premises and partner networks +3. **Capacity planning** - Plan for future growth with reserved address spaces +4. **Compliance** - Document and enforce address space policies + +We look forward to community feedback and suggestions on this feature proposal!