cloud

func AzureCalendar ¶

func AzureCalendar(tenantId string, clientId string, clientSecret string, email string, start string, end string) error

AzureCalendar retrieves calendar events for a specified user within a date range using Microsoft Graph API. This function provides comprehensive calendar access with date filtering, pagination support, and efficient field selection for calendar event retrieval.

Calendar Access Features:

• Date range filtering with start and end parameters
• Pagination support for large calendar datasets
• Configurable result limits (currently 10 events)
• Selective field retrieval for performance optimization
• Iterator pattern for processing large result sets

Authentication Flow:

Uses the same Azure AD client credentials flow as AzureEmails,
requiring appropriate calendar permissions and admin consent.

Required Azure Permissions:

• Calendars.Read (application permission) - to read user calendars
• User.Read.All (application permission) - to access specific users
• Admin consent must be granted for application permissions

Date Range Processing:

The function accepts start and end date parameters in ISO 8601 format
and retrieves calendar events within the specified time window.

Pagination Implementation:

Uses Microsoft Graph SDK's PageIterator for efficient processing
of large calendar datasets without loading all data into memory.

Parameters:

• tenantId: Azure Active Directory tenant ID (GUID format)
• clientId: Registered application client ID (GUID format)
• clientSecret: Application client secret for authentication
• email: Target user's email address for calendar access
• start: Start date for event retrieval (ISO 8601 format: "2024-01-01T00:00:00Z")
• end: End date for event retrieval (ISO 8601 format: "2024-01-31T23:59:59Z")

Returns:

• error: nil on success, error details on authentication or API failures

Error Conditions:

• Invalid authentication credentials
• Insufficient permissions for calendar access
• Invalid date format in start/end parameters
• User calendar not found or inaccessible
• Network connectivity issues to Microsoft Graph API
• API rate limiting or throttling

Date Format Requirements:

Start and end parameters must be in ISO 8601 format with timezone:
- Valid: "2024-01-01T00:00:00Z"
- Valid: "2024-01-01T00:00:00.000Z"
- Invalid: "2024-01-01" (missing time component)
- Invalid: "01/01/2024" (wrong format)

Output Format:

Logs calendar event information using eve.Logger with:
- TIME: Event start and end timestamps
- Subject: Event title/subject
- Structured format for parsing and analysis

Performance Optimization:

• Limited result set (Top: 10) for initial retrieval
• Selective field retrieval (subject, start, end only)
• Iterator pattern prevents memory overload with large calendars
• Efficient pagination through Microsoft Graph SDK

Security Considerations:

• Calendar data may contain sensitive meeting information
• Implement appropriate access controls and audit logging
• Consider data retention and privacy policies
• Use secure credential storage (Azure Key Vault recommended)

Example Usage:

start := "2024-01-01T00:00:00Z"
end := "2024-01-31T23:59:59Z"
err := AzureCalendar("tenant-id", "client-id", "client-secret",
                    "user@company.com", start, end)
if err != nil {
    log.Printf("Failed to retrieve calendar: %v", err)
}

Integration Scenarios:

• Meeting attendance tracking and reporting
• Resource utilization analysis
• Automated scheduling conflict detection
• Calendar synchronization with external systems
• Compliance and audit reporting for meeting data

Scalability Notes:

• Consider implementing caching for frequently accessed calendar data
• Use background processing for large calendar synchronization
• Implement retry logic for transient API failures
• Monitor API usage to stay within rate limits

func AzureEmails ¶

func AzureEmails(tenantId string, clientId string, clientSecret string) error

AzureEmails retrieves email messages from a specified user's inbox using Microsoft Graph API. This function implements secure authentication and retrieves the most recent emails with configurable field selection for efficient data transfer.

Authentication Flow:

Uses Azure AD client credentials flow for service-to-service authentication.
This requires a registered Azure application with appropriate Graph API permissions
and admin consent for accessing user mailboxes.

Email Retrieval Features:

• Accesses user's inbox folder specifically
• Retrieves top 10 most recent messages (configurable)
• Returns selected fields only (subject, receivedDateTime) for efficiency
• Structured logging of email metadata

Required Azure Permissions:

• Mail.Read (application permission) - to read user mailboxes
• User.Read.All (application permission) - to access specific users
• Admin consent must be granted for application permissions

Data Privacy:

This function accesses sensitive email data. Ensure compliance with:
- GDPR and data protection regulations
- Company data handling policies
- Audit and logging requirements
- User consent and notification policies

Parameters:

• tenantId: Azure Active Directory tenant ID (GUID format)
• clientId: Registered application client ID (GUID format)
• clientSecret: Application client secret for authentication

Returns:

• error: nil on success, error details on authentication or API failures

Error Conditions:

• Invalid tenant ID, client ID, or client secret
• Insufficient permissions for mailbox access
• Network connectivity issues to Microsoft Graph API
• User mailbox not found or inaccessible
• API rate limiting or throttling

Output Format:

Logs email information using eve.Logger with:
- Subject: Email subject line
- Received: Email received timestamp
- Separator line for readability

Security Notes:

• Client secrets should never be hardcoded
• Use Azure Key Vault or similar for secret management
• Implement proper audit logging for email access
• Consider using managed identities in Azure environments

Example Usage:

err := AzureEmails("tenant-id", "client-id", "client-secret")
if err != nil {
    log.Printf("Failed to retrieve emails: %v", err)
}

Performance Considerations:

• Limited to 10 messages for efficiency (hardcoded)
• Only retrieves essential fields to minimize data transfer
• Consider implementing pagination for larger result sets
• Cache authentication tokens to avoid repeated auth overhead

func HetznerPrices ¶

func HetznerPrices(token string)

HetznerPrices retrieves and displays current pricing information for all Hetzner Cloud server types. This function provides comprehensive cost analysis data including monthly pricing across different geographic locations for capacity planning and budget management.

Pricing Information Retrieved:

• Server type specifications and capabilities
• Monthly pricing for each server type
• Location-specific pricing variations
• Resource cost comparisons across regions

Cost Management Applications:

• Budget planning and forecasting
• Resource optimization and right-sizing
• Geographic cost analysis for multi-region deployments
• Total cost of ownership calculations
• Cost allocation and chargeback reporting

Pricing Structure:

Hetzner Cloud uses location-based pricing where costs may vary
between different datacenters. This function provides complete
pricing visibility across all available locations.

Server Type Categories:

• Shared CPU: Cost-effective for development and testing
• Dedicated CPU: Guaranteed performance for production workloads
• Memory-optimized: High RAM ratios for memory-intensive applications
• Storage-optimized: Enhanced storage performance for data workloads

Parameters:

• token: Hetzner Cloud API token with pricing read permissions

Data Format:

Pricing information is displayed with server type names followed
by monthly costs for each available location/datacenter.

Example Output:

cx11
3.29 Nuremberg
3.29 Helsinki
ccx13
15.99 Nuremberg
15.99 Helsinki

Business Intelligence:

• Compare costs across different server configurations
• Identify optimal locations for cost-sensitive workloads
• Plan resource scaling based on pricing tiers
• Analyze cost implications of architecture decisions

Integration Considerations:

• Pricing data can be exported for financial planning tools
• Regular monitoring helps track pricing changes
• Automated cost optimization based on current pricing
• Integration with cloud cost management platforms

Error Handling:

• API failures are logged with appropriate error messages
• Partial pricing data may be returned on network issues
• Rate limiting may affect data retrieval completeness

Example Usage:

HetznerPrices("your-api-token")

Operational Notes:

• Pricing information is updated regularly by Hetzner Cloud
• Consider caching pricing data for cost analysis applications
• Currency is typically in EUR (European pricing)
• Prices exclude VAT and may vary based on account type

func HetznerServerCreate ¶

func HetznerServerCreate(token, sName, sType string)

HetznerServerCreate creates a new server instance on Hetzner Cloud with predefined configuration. This function provisions a dedicated CPU server with AlmaLinux 10 in the Nuremberg datacenter, configured with SSH key access for secure remote administration.

Server Configuration:

• Operating System: AlmaLinux 10 (x86_64 architecture)
• Server Type: ccx13 (dedicated CPU, 8GB RAM, 2 vCPU cores)
• Location: nbg1 (Nuremberg, Germany datacenter)
• SSH Access: Configured with embedded SSH public key

Dedicated Server Types Available:

• ccx13: 8GB RAM, 2 dedicated CPU cores
• ccx23: 16GB RAM, 4 dedicated CPU cores
• ccx33: 32GB RAM, 8 dedicated CPU cores

SSH Key Configuration:

The function uses a hardcoded SSH key for server access. In production
environments, consider externalizing SSH key configuration or supporting
multiple keys for different users or use cases.

Parameters:

• token: Hetzner Cloud API token with server creation permissions
• sName: Desired name for the new server (must be unique in the project)
• sType: Server type configuration ("default" for ccx13, other types not implemented)

Error Handling:

• API authentication failures are logged via eve.Logger.Error
• Server creation failures are logged with detailed error information
• Network connectivity issues are handled by the underlying HTTP client
• Resource quota limits may prevent server creation

Resource Management:

• Servers are billable resources that continue to incur costs until deleted
• Consider implementing automatic cleanup for temporary servers
• Monitor resource usage to avoid exceeding account limits

Example Usage:

HetznerServerCreate("your-api-token", "web-server-01", "default")

Post-Creation Steps:

1. Wait for server to reach "running" status
2. Configure firewall rules and security groups
3. Install and configure required software
4. Set up monitoring and backup procedures

Security Notes:

• The embedded SSH key provides full root access to created servers
• Ensure proper SSH key management and rotation policies
• Consider using cloud-init for automated security hardening
• Implement proper network security controls

func HetznerServerDelete ¶

func HetznerServerDelete(token, sName string)

HetznerServerDelete removes an existing server from Hetzner Cloud by name. This function performs a complete server deletion including all associated resources and data. The operation is irreversible and will permanently destroy the server and its data.

Deletion Process:

1. Lookup server by name in the current project
2. Retrieve server details and validate existence
3. Execute deletion with confirmation
4. Log deletion status and any errors

Data Loss Warning:

Server deletion is permanent and irreversible. All data stored on the
server's local storage will be permanently lost. Ensure proper backups
are in place before deletion.

Resource Cleanup:

• Server instance is terminated and removed
• Local storage is permanently destroyed
• Network interfaces are automatically cleaned up
• Attached volumes may require separate deletion

Parameters:

• token: Hetzner Cloud API token with server deletion permissions
• sName: Name of the server to delete (must exist in the project)

Error Conditions:

• Server not found: Function returns early with error log
• API authentication failures: Logged via eve.Logger.Error
• Deletion protection enabled: May prevent deletion
• Server in use by other resources: May require dependency cleanup

Billing Impact:

• Server billing stops immediately upon successful deletion
• Partial hour usage is typically billed as full hour
• Associated resources (volumes, load balancers) may have separate billing

Safety Considerations:

• Verify server name before calling this function
• Implement confirmation prompts in interactive applications
• Consider implementing soft deletion with recovery period
• Maintain audit logs of all deletion operations

Example Usage:

HetznerServerDelete("your-api-token", "web-server-01")

Best Practices:

• Always backup critical data before deletion
• Use server tagging to identify temporary vs. permanent servers
• Implement automation safeguards to prevent accidental deletions
• Monitor deletion operations for compliance and auditing

func HetznerServers ¶

func HetznerServers(token string)

HetznerServers retrieves and displays information about all servers in the Hetzner Cloud project. This function provides a comprehensive inventory of server resources including identification, location, and status information for monitoring and management purposes.

Information Retrieved:

• Server ID and name for identification
• Datacenter location for geographic distribution analysis
• Server status and configuration details
• Resource allocation and usage information

Use Cases:

• Infrastructure inventory and asset management
• Resource utilization monitoring
• Geographic distribution analysis
• Capacity planning and optimization
• Compliance and audit reporting

Data Processing:

The function iterates through all servers in the project and retrieves
detailed information for each one. This includes both basic listing
data and detailed server specifications.

Parameters:

• token: Hetzner Cloud API token with server read permissions

Performance Considerations:

• Makes API calls for each server (N+1 query pattern)
• Consider caching for frequently accessed data
• Large server inventories may require pagination
• Rate limiting may affect execution time for large deployments

Error Handling:

• Individual server retrieval failures are logged and skipped
• Overall listing failures may result in incomplete information
• Network connectivity issues are handled gracefully
• Missing servers are reported with appropriate logging

Output Format:

Server information is logged using the eve.Logger system with
structured information including ID, name, and location data.

Example Output:

server 12345 is called: web-server-01 location: Nuremberg
server 12346 is called: db-server-01 location: Helsinki

Monitoring Integration:

The logged information can be integrated with monitoring systems
for alerting, reporting, and operational dashboards.

Example Usage:

HetznerServers("your-api-token")

Optimization Notes:

• Consider implementing batch operations for large server counts
• Cache results for repeated calls within short time periods
• Implement filtering options for specific server subsets
• Add pagination support for very large deployments