- 
                Notifications
    
You must be signed in to change notification settings  - Fork 1
 
Migration of cloud monitoring from observability-instances #3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think Metrics routing should still be its own submodule. Otherwise we have no migration path for consumers migrating from old repo
| 
           /run pipeline  | 
    
| 
           /run pipeline  | 
    
| 
           /run pipeline  | 
    
| 
           /run pipeline  | 
    
| 
           /run pipeline  | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you ensure all modules and examples are at required_version = ">= 1.9.0"
This reverts commit 9d376c2.
| 
           /run pipeline  | 
    
| 
           /run pipeline  | 
    
| 
           /run pipeline  | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see comments
        
          
                README.md
              
                Outdated
          
        
      | Use real values instead of "var.<var_name>" or other placeholder values | ||
| unless real values don't help users know what to change. | ||
| --> | ||
| To provision cloud monitoring instance | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, the usage is showing metrics config too. I would suggest to just remove the sentence and use code comments in the example tf code itself to explain the usage
        
          
                outputs.tf
              
                Outdated
          
        
      | # Outputs | ||
| ######################################################################################################################## | ||
| output "crn" { | ||
| value = length(ibm_resource_instance.cloud_monitoring) > 0 ? ibm_resource_instance.cloud_monitoring.id : null | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can remove length function from all these inputs. there is no count around the instance creation.
        
          
                modules/metrics_routing/variables.tf
              
                Outdated
          
        
      | id = string | ||
| }))) | ||
| }) | ||
| description = "Global settings for Metrics Routing" | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should mention that in order to configure metrics routing, the account must have a primary_metadata_region value set
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps also mention the impact of setting private_api_endpoint_only to true (you are unable to see the settings in the UI)
        
          
                modules/metrics_routing/main.tf
              
                Outdated
          
        
      | 
               | 
          ||
| # metric routing to cloud monitoring s2s auth policy | ||
| resource "ibm_iam_authorization_policy" "metrics_router_cloud_monitoring" { | ||
| for_each = { for target in var.metrics_router_targets : target.target_name => target if !target.skip_mrouter_sysdig_iam_auth_policy } | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There should be a boolean to skip auth policy creation if required, same way we have in all other modules
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
skip_mrouter_sysdig_iam_auth_policy is the boolean to skip auth policy creation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have renamed the variable to skip_metrics_router_auth_policy
        
          
                examples/basic/main.tf
              
                Outdated
          
        
      | ############################################################################## | ||
| 
               | 
          ||
| # | ||
| # Developer tips: | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this can be removed its only needed in the initial template as a guide for developers creating a module example
        
          
                variables.tf
              
                Outdated
          
        
      | 
               | 
          ||
| variable "enable_platform_metrics" { | ||
| type = bool | ||
| description = "Receive platform metrics in the provisioned IBM Cloud Monitoring instance." | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggest to mention that only 1 instance in a given region can be enabled for platform metrics.
        
          
                examples/advanced/main.tf
              
                Outdated
          
        
      | ############################################################################## | ||
| # IBM Cloud Metrics Routing | ||
| # - Cloud Monitoring target | ||
| # - Metrics Router route to the target | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe explain more about the type of rule your creating in the example
| 
           /run pipeline  | 
    
| backup_metadata_region = var.metrics_router_settings.backup_metadata_region | ||
| private_api_endpoint_only = var.metrics_router_settings.private_api_endpoint_only | ||
| 
               | 
          ||
| # The create_before_destroy meta-argument makes sure that the new settings are applied first before the prior ones are removed. | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@iamar7 I don't understand this comment? These settings can only have 1 value at any given time. So I don't understand how create_before_destroy could work in this scenario?
| 
           🎉 This PR is included in version 1.0.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀  | 
    

Description
Cloud Monitoring & Metrics Router code from the observabilities-instances repo has been moved here and examples for this module created.
Release required?
x.x.X)x.X.x)X.x.x)Release notes content
Run the pipeline
If the CI pipeline doesn't run when you create the PR, the PR requires a user with GitHub collaborators access to run the pipeline.
Run the CI pipeline when the PR is ready for review and you expect tests to pass. Add a comment to the PR with the following text:
Checklist for reviewers
For mergers