Terraform's lifecycle can sometimes lead to unexpected changes in attributes managed by providers, particularly when external factors modify them. This blog post explores strategies to prevent Terraform from reverting these intentional external modifications. It focuses on using ignore_changes within a resource's lifecycle block to specify the attributes to disregard during the plan and apply phases. The post demonstrates this with an AWS security group example, where an external tool might add ingress rules that Terraform shouldn't overwrite. It emphasizes the importance of carefully choosing which attributes to ignore, as it can mask legitimate changes and potentially introduce drift. The author recommends using ignore_changes sparingly and considering alternative solutions like null_resource or data sources to manage externally controlled resources when possible.
IBM has finalized its acquisition of HashiCorp, aiming to create a comprehensive, end-to-end hybrid cloud platform. This combination brings together IBM's existing hybrid cloud portfolio with HashiCorp's infrastructure automation tools, including Terraform, Vault, Consul, and Nomad. The goal is to provide clients with a streamlined experience for building, deploying, and managing applications across any environment, from on-premises data centers to multiple public clouds. This acquisition is intended to solidify IBM's position in the hybrid cloud market and accelerate the adoption of its hybrid cloud platform.
HN commenters are largely skeptical of IBM's ability to successfully integrate HashiCorp, citing IBM's history of failed acquisitions and expressing concern that HashiCorp's open-source ethos will be eroded. Several predict a talent exodus from HashiCorp, and some anticipate a shift towards competing products like Pulumi, Ansible, and Terraform alternatives. Others question the strategic rationale behind the acquisition, suggesting IBM overpaid and may struggle to monetize HashiCorp's offerings. The potential for increased vendor lock-in and higher prices are also raised as concerns. A few commenters express a cautious hope that IBM might surprise them, but overall sentiment is negative.
A new Terraform provider allows for infrastructure-as-code management of Hrui (formerly TP-Link Omada) SDN-capable network switches, offering a cost-effective alternative to enterprise-grade solutions. This provider enables users to define and automate the configuration of Hrui-based networks, including VLANs, port settings, and other network features, directly within their Terraform deployments. This simplifies network management and improves consistency, particularly for those working with budget-conscious networking setups using these affordable switches.
HN users generally expressed interest in the terraform-provider-hrui, praising its potential for managing inexpensive hardware. Several commenters discussed the trade-offs of using cheaper, less feature-rich switches compared to enterprise-grade options, acknowledging the validity of both approaches depending on the use case. Some users questioned the long-term viability and support of the targeted hardware, while others shared their positive experiences with similar budget-friendly networking equipment. The project's open-source nature and potential for community contributions were also highlighted as positive aspects. A few commenters offered specific suggestions for improvement, such as expanding device compatibility and adding support for VLANs.
Summary of Comments ( 11 )
https://news.ycombinator.com/item?id=43454642
The Hacker News comments discuss practical approaches to the problem of Terraform providers sometimes changing attributes unexpectedly. Several users suggest using
ignore_changeslifecycle arguments within Terraform configurations, emphasizing its utility but also cautioning about potential risks if misused. Others propose leveraging thenullprovider or generating local values to manage these situations, offering specific code examples. The discussion touches on the complexities of state management and the potential for drift, with recommendations for robust testing and careful planning. Some commenters highlight the importance of understanding why the provider is making changes, advocating for addressing the root cause rather than simply ignoring the symptoms. The thread also features a brief exchange on the benefits and drawbacks of the presentedignore_changessolution versus simply overriding the changed value every time, with arguments made for both sides.The Hacker News post "Ignoring unwanted Terraform attribute changes" discussing the linked blog post has generated several comments. Many revolve around the complexities and frustrations of managing Terraform state, particularly when dealing with external forces modifying resources managed by Terraform.
One commenter highlights the common scenario where a provider might default a value that the user didn't explicitly set, leading to Terraform wanting to revert it on the next apply. They suggest this is especially problematic when combined with
for_eachresources. They appreciate the blog post's solution usingignore_changeslifecycle meta-argument but express a desire for Terraform to handle this more elegantly by default. This sentiment of wishing for better default behavior from Terraform echoes through other comments as well.Another user mentions the struggles of managing resources where underlying providers or external systems might alter values outside of Terraform's purview. They describe their current strategy of manually editing the state file which, while functional, is clearly not ideal. They see the
ignore_changesapproach as a much cleaner and more maintainable way to handle these situations.The discussion then delves into the nuances of when to utilize
ignore_changes. One participant cautions against overusing it as a catch-all solution. They emphasize the importance of understanding why a value is drifting and whether ignoring the change is truly the appropriate course of action. They suggest investigating if a provider's default behavior can be configured or if the external system modifying the resource can be adjusted. Ignoring changes should be a conscious decision made with full awareness of the potential implications.Another commenter reiterates this caution, pointing out that blindly using
ignore_changescould mask legitimate problems and create unexpected side effects down the line. They suggest treating it as a temporary fix while a more robust solution is investigated.Some users suggest alternative approaches like using
nullvalues for certain attributes to avoid conflicts or leveraging theprevent_destroylifecycle argument to prevent accidental deletion of resources. These suggestions highlight the various tools available in Terraform for managing state drift, but also reinforce the complexity of choosing the right approach for a given scenario.Finally, a commenter touches upon the broader issue of state management in Infrastructure-as-Code and expresses hope for future improvements in Terraform that could simplify these kinds of challenges.