Terraspace seed error

Terraspace
1

Running terraspace seed mystack I get

Traceback (most recent call last):
        17: from /opt/terraspace/embedded/bin/terraspace:23:in `<main>'
        16: from /opt/terraspace/embedded/bin/terraspace:23:in `load'
        15: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/terraspace-0.6.20/exe/terraspace:11:in `<top (required)>'
        14: from /opt/terraspace/embedded/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'
        13: from /opt/terraspace/embedded/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'
        12: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/terraspace-0.6.20/lib/terraspace.rb:10:in `<top (required)>'
        11: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/zeitwerk-2.5.1/lib/zeitwerk/kernel.rb:35:in `require'
        10: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/zeitwerk-2.5.1/lib/zeitwerk/kernel.rb:35:in `require'
         9: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/activesupport-7.0.0/lib/active_support/core_ext/hash.rb:3:in `<top (required)>'
         8: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/zeitwerk-2.5.1/lib/zeitwerk/kernel.rb:35:in `require'
         7: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/zeitwerk-2.5.1/lib/zeitwerk/kernel.rb:35:in `require'
         6: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/activesupport-7.0.0/lib/active_support/core_ext/hash/conversions.rb:3:in `<top (required)>'
         5: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/zeitwerk-2.5.1/lib/zeitwerk/kernel.rb:35:in `require'
         4: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/zeitwerk-2.5.1/lib/zeitwerk/kernel.rb:35:in `require'
         3: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/activesupport-7.0.0/lib/active_support/xml_mini.rb:11:in `<top (required)>'
         2: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/activesupport-7.0.0/lib/active_support/xml_mini.rb:201:in `<module:ActiveSupport>'
         1: from /opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/activesupport-7.0.0/lib/active_support/xml_mini.rb:103:in `backend='
/opt/terraspace/embedded/lib/ruby/gems/2.7.0/gems/activesupport-7.0.0/lib/active_support/xml_mini.rb:184:in `current_thread_backend':
 uninitialized constant ActiveSupport::XmlMini::IsolatedExecutionState (NameError)
2

Upgrade terraspace to the latest. It was a bug that was introduced by the latest version of activesupport a few days ago. It also was the way terraspace was requiring activesupport. Either way fixed it. See:

3

I have updated alpine based docker image now (3564b8f30ad6) and here I get

Could not find rake-13.0.6 in any of the sources
Run bundle install to install missing gems.

I have no experience with ruby so I am not sure should I really call bundle install or not.

6

So after bundle install and editing version of terraspace in Gemfile it works now. Thank you!
But maybe we need some info in documentation about necessary additional actions.

7

Cool glad it worked out. The standalone and docker installers are only updated once a day so thinking it may be fixed tomorrow. The gem installer is always going to have the latest.

Note: Could have been fixed with bundle update also. Editing the Gemfile works too. A bundle update updates the pinned terraspace version in Gemfile.lock to match your system version, since that is outside the control of Gemfile.lock. Details here: https://terraspace.cloud/docs/install/gem/multiple-versions/#long-answer-why-bundle-exec

Would consider adding a terraspace shim if you have multiple versions of terraspace. So you don’t have to keep typing bundle exec, which is nice. Details are here:

Also, would consider eventually installing Ruby and using the gem installer. That gives you a lot more control over other ruby gem dependencies. IE: You can better lock or pin gem versions:

There are docs and instructions on how to install Ruby with rbenv here:

With rbenv, the install is isolated to ~/.rbenv, so you could always remove it with:

rm -rf ~/.rbenv

And removing the 2 lines of rbenv configuration in the ~/.bash_profile

Added the Ruby rbenv uninstall instructions to the docs also: https://terraspace.cloud/docs/install/ruby/

Totally get why you would want to use the standalone and/or docker installers. The gem install does provide the most control though. Thanks!

8

I appreciate your fast and detailed answers, but I just want to emphasize that Ruby’s stuff looks like leaky abstraction here and it rises dramatically learning curve of entire tool.
I am sure being familiar with some technology we tend to underrate its complexity.

9

Sure :grinning_face_with_smiling_eyes: Appreciate leaky abstractions. Not in the way one might think, though.

Flipping things upside-down on its head a bit. Think leaky abstractions can actually be good thing. Leaky abstractions being a bad thing have been repeated often enough that it often goes unquestioned without considering the trade-offs. In practice, there are trade-offs.

Consider a few concrete examples:

ActiveRecord and DataMapper ORMs: The ActiveRecord ORMs is a complete leaky abstraction. It works quite well, though. The database column names straight-up map to the form fields used in the frontend. The backend is leaking all the way to frontend. DBAs can cringe when they learn this :sweat_smile: Folks might say this is terrible, but it works. The reason is abstractions can mean more overhead in maintaining that abstraction layer. In this case, mapping database columns to code methods definitions, and eventually to the form fields. We’ve traded a “purist abstraction against leaks” approach to an error-prone human manually updating multiple parts of code. Bummer.

Terraform Itself: Terraform approach is generally a wise one. It doesn’t try to abstract cloud providers to the lowest common denominator interface. IE: Something like OpenStack. There are concrete methods for each cloud provider resource. IE: aws_instance, azurerm_virtual_machine, and google_compute_instance vs a general instance. We can then better leverage the latest and greatest from each cloud provider. But then Terraform abstracts the for_each… :sob: It’s not obvious unless working with Terraform a lot that for_each is completely different at the resource and attributes levels. It’s pretty conflated. :man_shrugging:t2:

Terragrunt: Terragrunt provides a custom HCL syntax layer on top of Terraform’s native HCL. Folks usually do not know this and conflate them. They don’t realize that the terraform keyword in the terragrunt.hcl file is different from the terraform keyword in native terraform HCL. They think sourcing in reusable modules with terraform’s module and terragrunts terraform works the same. :worried: https://learn.boltops.com/courses/terraspace-and-terragrunt/lessons/terragrunt-to-terraspace-the-essential-concepts

The leaky abstraction term might be being abused here :rofl: Ruby :gem: gives terraspace a good amount of its superpowers. It provides you access to the power and might :muscle: of a full programming language. Ruby is also a great language to implement DSLs and has a super clean syntax. This means that terraspace development can move faster and improve at a rate that would not be possible otherwise. Unless you have a huge amount of resources :moneybag: - which comes with its own price.

To be straightforward, think this is more of an install setup thing than a leaky software abstraction thing. Leaky abstractions can be used for good. :innocent: Folks tend to point out the installation process as an impediment as it’s another step in this very busy world we live in. The standalone and docker installers can help with that but are not godsends. Nothing is. There are also many docs to help with the install process. Have seen junior engineers, QA testers, developers, and operations folks been able to install Terraspace with success. To be clear, am not saying that the process cannot be improved. There are just trade-offs.

Also, vagrant and the aws cli went to standalone installers similar to terraspace. Vagrant jams Ruby into their standalone installer, and AWS shoves Python into its standalone package. :rofl: Believe that vagrant wants to convert their Ruby implementation to a golang. Believe this has less to do with leaky abstractions, as go-lang will the leak. :rofl: Think this is great for hashicorp because guessing that their team is mainly composed of golang engineers. Even with their vast resources, am curious to see how long that process will take for hashicorp :thinking: For the same reason, don’t think AWS will rewrite the aws cli from python to golang. They have plenty of python engineers on their huge team.

All that being said, glad to hear you’re giving Terraspace a try and hope it works out for the best. No sweat either way. :grinning_face_with_smiling_eyes:

10

Released v1.

Improved the terraspace wrapper generated by the standalone installers. Details here:

You won’t have to remember to type bundle exec.

In addition, added a friendly usage message with instructions on how to resolve if the error occurs. PR: https://github.com/boltops-tools/terraspace/pull/177 The standalone installer’s new shim, as of terraspace v1 includes this smarter shim already.

Also, remove terraspace_plugins_* out of terraspace core. https://github.com/boltops-tools/terraspace/pull/173 This should also mitigate gem dependency graph resolution issues.

Believe this should resolve the issues. :face_with_monocle:

1 Like