Skip to content
This repository has been archived by the owner on Jun 5, 2020. It is now read-only.

autorequire 'require' gem #125

Open
danieldreier opened this issue Mar 19, 2015 · 6 comments
Open

autorequire 'require' gem #125

danieldreier opened this issue Mar 19, 2015 · 6 comments

Comments

@danieldreier
Copy link

When I run puppet agent using this module on a new Debian Wheezy PE system, I get:

Error: Could not autoload puppet/provider/ec2_instance/v2: cannot load such file -- retries
Error: Could not autoload puppet/type/ec2_instance: Could not autoload puppet/provider/ec2_instance/v2: cannot load such file -- retries
Error: Could not retrieve catalog from remote server: Could not intern from text/pson: Could not autoload puppet/type/ec2_instance: Could not autoload puppet/provider/ec2_instanc
e/v2: cannot load such file -- retries
Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run

When I install the 'require' gem these errors are resolved. This happens even though I have the following in my manifests:

  package { 'retries':
    ensure   => present,
    provider => 'pe_gem',
  }

I believe that the problem is that there isn't an autorequire creating a dependency, so the ec2_instance resource applies before the gem can be installed.

@garethr
Copy link
Contributor

garethr commented Mar 20, 2015

Mmmm. I'll have a think about this. I'm not sure we should manage these resources as part of the module, but we should probably provide an example that demonstrates how to manage the dependencies with Puppet. I'd sort of envisaged a typical install and configure class setup when using the module.

@danieldreier
Copy link
Author

The difficulty with that approach for this specific case is that the user then has to add explicit ordering between the prerequisites and every single type, because if (for example) the ec2_instance resource is applied before the gem is installed, then puppet fails, exits, and the gem is never installed. I'm working around it by installing those gems from my cloudinit shell script, but that's a hack because it puts it outside of puppet management.

@Iristyle
Copy link
Contributor

Iristyle commented Oct 4, 2015

IMHO, it would be nice to ditch our usage of the retry gem if possible. It looks like there have been a number of user reports of similar operations requiring retries, and they have been sprinkled about the SDK.

It looks like most of our issues are around create_tags (and waiting for a resource to be created prior to tagging):
https://github.com/puppetlabs/puppetlabs-aws/search?utf8=%E2%9C%93&q=with_retries

AWS addressed this by fixing the waiters in the 2.1.12 gem from 8-4-2015 - see release notes at https://github.com/aws/aws-sdk-ruby/blob/5b25e478a526849280a73770ac26a09cc93f016e/CHANGELOG.md#2112-2015-08-04

And the related issue report at aws/aws-sdk-ruby#859

Worth seeing if this can address the issue / remove the gem dependency.

Also - my original comments to AWS SDK maintainers are at aws/aws-sdk-ruby@f9e33b4

@ahenroid
Copy link

ahenroid commented Mar 4, 2017

@danieldreier, I know this is an old issue, but do you think this is still interesting, or should we close this for now? Thanks!

@danieldreier
Copy link
Author

@ahenroid if it was never fixed, I think it's still a valid issue, because it's a behavior that causes the module to be broken out of the box for a typical use case.

@ahenroid
Copy link

ahenroid commented Mar 6, 2017

Thanks, @danieldreier. I'll leave this on the books.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants