dnsimple / chef-dnsimple Goto Github PK

ChefSpec is throwing a deprecation warning:

[DEPRECATION] `ChefSpec::Runner' is deprecated. Please use `ChefSpec::SoloRunner' or `ChefSpec::ServerRunner' instead. (called from spec/default_spec.rb:4:in `block (2 levels) in <top (required)>')

ChefSpec::ServerRunner seems to be the community. default

This cookbook will not work without build tools on the system. It does the right thing by installing libraries, but that's not enough: you'll need gcc and friends.

I only stumbled upon this issue because I wanted to issue DNS updates at the start of a recipe run (there was a recipe failing in the middle). Couldn't do it because nokogiri dependency would fail.

Also, you'll need to set

node[:build_essential][:compiletime] = true

Either by telling the user through documentation or letting them figure it out ;)

Fog requires zlib1g-dev to be installed.

When doing a CNAME create action on a record with an existing A record, the following error is returned:

Excon::Errors::BadRequest: Expected(201) <=> Actual(400 Bad Request)

CNAME must be the only record on a subdomain

Obviously we can't expect Chef to continue, as that might throw off expectations, but an extra option force would allow us to remove any existing A records on that subdomain if set to true, or continue the current behaviour (default) if set to false.

Use case that runs into this:

our nodes can be created on both EC2 or other external hosts. If on EC2, we create a CNAME record for the by amazon provided DNS record (like ec2-53-214-183-212.eu-west-1.compute.amazonaws.com). However, when using a non-ec2 instance, we use the public_ip with an A record.

Switching between ec2 and non-ec2, you'd have to manually remove the records before continuing.

Per some new foodcritic rules, specifically FC120 we need to not set the name property directly on the record resource. We'll probably want to rename it to record_name instead.

The username / password method of authentication used by this cookbook will log you out of the console. If you have many servers using this cookbook it renders the https://dnsimple.com web ui completely useless. After contacting support over there they applied a temp fix and suggested that I switch to the token authentication.

Maybe we should switch from Fog to https://github.com/aetrion/dnsimple-ruby#api-token

Hello,

We've tried to activate or update your repository on Depfu and couldn't find any supported dependency files. If we were to guess, we would say that this is not actually a project Depfu supports and has probably been activated by error.

Monorepos

Please note that Depfu currently only searches for your dependency files in the root folder. We do support monorepos and non-root files, but don't auto-detect them. If that's the case with this repo, please send us a quick email with the folder you want Depfu to work on and we'll set it up right away!

How to deactivate the project

• Go to the Settings page of either your own account or the organization you've used
• Go to "Installed Integrations"
• Click the "Configure" button on the Depfu integration
• Remove this repo (dnsimple/chef-dnsimple) from the list of accessible repos.

Please note that using the "All Repositories" setting doesn't make a lot of sense with Depfu.

If you think that this is a mistake

Please let us know by sending an email to [email protected].

This is an automated issue by Depfu. You're getting it because someone configured Depfu to automatically update dependencies on this project.

Hello! It appears that the latest nokogiri expects a patch command to be available on CentOS 6.5. build-essential was fixed in version 2.0.4 to install the patch package. However, this cookbook (dnsimple) is still pinned to an older build-essential version.

chef-boneyard/build-essential@97335d8

Update dnsimple gem version as it is currently locked to < 6

And there are > 6 versions published
https://github.com/dnsimple/dnsimple-ruby/blob/main/CHANGELOG.md

       RuntimeError
       ------------
       This resource is written with Chef 12.5 custom resources, and requires at least Chef 12.0 used with the compat_resource cookbook, it will not work with Chef 11.x clients, and those users must pin their cookbooks to older versions or upgrade.

Heads up :)

Upgrade dnsimple gem from 7 to 8.

As part of this dependency upgrade, the release process for the lib should be automated as well.

Whilst getting the new CPCP platform up and running I have been working on getting the cookbooks working properly.

I have got the dnsimple cookbook almost working, but it is failing on the last test.

I have registered the domain dnsimple.cpcp.chef.xyz in my Dnsimple Sandbox. All the tests for creating and deleting records work - however when the test for updating a record is performed it fails. This is because it is testing for the string testing.dnsimple.xyz.

The error is

Profile: Update Zone Record Test (update_record)
Version: 1.0.0
Target:  ssh://[email protected]:22


  zone record
     ���  lookup on dnsimple.cpcp.chef.xyz for cnamerecord content should eq "testing.dnsimple.xyz"
     
     expected: "testing.dnsimple.xyz"
          got: "testing.dnsimple.cpcp.chef.xyz"
     
     (compared using ==)
     
     ���  lookup on dnsimple.cpcp.chef.xyz for cnamerecord ttl should eq 60

Test Summary: 1 successful, 1 failure, 0 skipped

Full output for the latest build can be found here - https://cpcp.chef.io/job/dnsimple-cookbook/17/console

I originally released this cookbook with an old version of Stove (4.1.1) which does not include compiling a metadata.json file with the gem keyword. This makes the 2.0.0 version broken and a 2.0.1 release with an updated metadata.json file is in order.

When having for example these records on a zone:

    A 1.1.1.1
    MX wadus
    NS 1.1.1.1
    CNAME wadus

When running the LWRP with any of these records, the first record will be destroyed no matter which type is.

The Fog Gem now supports DNSimple API Auth here.

For now the cookbook could use the latest fog gem until the cookbook can be changed to the dnsimple 2.0 Ruby gem mentioned on GH Issue #24

I think the provider should use the load_current_resource method to determine if the record exists prior to attempting to create or destroy it. I wrote some prototype code a week or so ago, but I seem to have lost the changes I made. The idea is:

1. Add load_current_resource (aka lcr) method in provider.
2. Move the current detection code up to lcr.
3. Add a resource attribute, exists that is false by default, but true if the matching record is found.
4. Both action methods would check for existence, and behave accordingly.

While the current detection with name, value and ttl "works", it may not be as reliable for detecting different types of DNS records. I haven't done any testing of this yet, however.