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.
Steve Losh's blog post explores leveraging the Common Lisp Object System (CLOS) for dependency management within Lisp applications. Instead of relying on external systems, Losh advocates using CLOS's built-in dependent maintenance protocol to automatically track and update derived values based on changes to their dependencies. He demonstrates this by creating a depending macro that simplifies defining these dependencies and automatically invalidates cached values when necessary. This approach offers a tightly integrated, efficient, and inherently Lisp-y solution to dependency tracking, reducing the need for external libraries or complex build processes. By handling dependencies within the language itself, this technique enhances code clarity and simplifies the overall development workflow.
Hacker News users discussed the complexity of Common Lisp's dependency system, particularly its use of the CLOS dependent maintenance protocol. Some found the system overly complex for simple tasks, arguing simpler dependency tracking mechanisms would suffice. Others highlighted the power and flexibility of CLOS for managing complex dependencies, especially in larger projects. The discussion also touched on the trade-offs between declarative and imperative approaches to dependency management, with some suggesting a hybrid approach could be beneficial. Several commenters appreciated the blog post for illuminating a lesser-known aspect of Common Lisp. A few users expressed interest in exploring other dependency management solutions within the Lisp ecosystem.
Boardgame.io is an open-source JavaScript framework that simplifies the development of turn-based games, both digital and tabletop. It provides a core game engine with features like state management, turn order, and action validation, abstracting away common game mechanics. Developers define the game logic through a declarative format, specifying the game's setup, available player moves, and victory conditions. Boardgame.io also offers built-in support for various game clients (React, vanilla JS) and transports (local, network), making it easy to create and deploy games across different platforms. This allows developers to focus on the unique aspects of their game design rather than low-level implementation details.
HN commenters generally praised boardgame.io for its ease of use and helpfulness in prototyping board games. Several users shared positive experiences using it for game jams or personal projects, highlighting its clear documentation and gentle learning curve. Some discussed the advantages of its declarative approach and the built-in networking features for multiplayer games. A few comments mentioned potential areas for improvement, like better handling of complex game logic or more advanced UI features, but the overall sentiment was overwhelmingly positive, with many recommending it as a great starting point for web-based board game development. One commenter noted its use in a commercial project, a testament to its stability and practicality.
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.