Skip to content
This repository has been archived by the owner on Jan 30, 2021. It is now read-only.

error on executing vagrant up with provider azure on Mac OS El Capitan #182

Closed
njappboy opened this issue Apr 4, 2017 · 15 comments · Fixed by #183
Closed

error on executing vagrant up with provider azure on Mac OS El Capitan #182

njappboy opened this issue Apr 4, 2017 · 15 comments · Fixed by #183
Assignees
@devigned

Comments

@njappboy
Copy link

njappboy commented Apr 4, 2017

This issue just started yesterday:

Using vagrant-azure (2.0.0.pre6)

  • Version Constraint: 2.0.0.pre6
$vagrant up --provider=azure --provision
Bringing machine 'default' up with 'azure' provider...
==> default: Launching an instance with the following settings...
==> default:  -- Management Endpoint: https://management.azure.com
==> default:  -- Subscription Id: ********************************
==> default:  -- Resource Group Name: sparkling-sky-15
==> default:  -- Location: eastus2
==> default:  -- SSH User Name: someuser
==> default:  -- Admin Username: vagrant
==> default:  -- VM Name: purple-frog-63
==> default:  -- VM Size: Standard_DS2_v2
==> default:  -- Image URN: OpenLogic:CentOS:7.3:latest
==> default:  -- DNS Label Prefix: dark-morning-91
/Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday/options.rb:4
9:in `merge!': undefined method `each' for nil:NilClass (NoMethodError)
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
/options.rb:60:in `merge'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
/options.rb:52:in `block in merge!'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
/options.rb:49:in `each'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
/options.rb:49:in `merge!'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
/options.rb:60:in `merge'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
/connection.rb:61:in `initialize'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
.rb:67:in `new'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/faraday-0.12.0.1/lib/faraday
.rb:67:in `new'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/ms_rest-0.6.3/lib/ms_rest/ht
tp_operation_request.rb:71:in `block in run_promise'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/safe_task_executor.rb:24:in `call'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/safe_task_executor.rb:24:in `block in execute'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/synchronization/mri_lockable_object.rb:38:in `block in synchronize'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/synchronization/mri_lockable_object.rb:38:in `synchronize'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/safe_task_executor.rb:19:in `execute'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/promise.rb:531:in `block in realize'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/ruby_thread_pool_executor.rb:348:in `call'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/ruby_thread_pool_executor.rb:348:in `run_task'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/ruby_thread_pool_executor.rb:337:in `block (3 levels) in create_worke
r'
		from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/ruby_thread_pool_executor.rb:320:in `loop'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/ruby_thread_pool_executor.rb:320:in `block (2 levels) in create_worke
r'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/ruby_thread_pool_executor.rb:319:in `catch'
        from /Users/someuser/.vagrant.d/gems/2.2.5/gems/concurrent-ruby-1.0.5/lib/co
ncurrent/executor/ruby_thread_pool_executor.rb:319:in `block in create_worker'
@matt-richardson
Copy link
Contributor

Glad I'm not the only one - thought I was going mad.

Looks like its happening somewhere between line 68 and line 145 of run_instance.rb.

@matt-richardson
Copy link
Contributor

Okay, further investigations (long live printf debugging!) show it dies on:

images = azure.compute.virtual_machine_images.list(location, publisher, offer, sku)

on line 203.

@matt-richardson
Copy link
Contributor

I wonder if its the same issue as #122?

@devigned
Copy link
Member

devigned commented Apr 4, 2017

Looks like the specified image is not available in a given location. Check with https://github.com/Azure/azure-cli using the following (substituting your values for -p -s and -l).

$ az vm image list -p OpenLogic -s 7.3 -l westus --all
[
  {
    "offer": "CentOS",
    "publisher": "OpenLogic",
    "sku": "7.3",
    "urn": "OpenLogic:CentOS:7.3:7.3.20161221",
    "version": "7.3.20161221"
  }
]

@devigned
Copy link
Member

devigned commented Apr 4, 2017

With that said, this should definitely give a better error message!

@matt-richardson
Copy link
Contributor

I tracked it down to a similar place, but, with this config:

    azure.location = 'AustraliaEast'
    azure.vm_image_urn = 'MicrosoftSQLServer:SQL2016-WS2012R2:Express:latest'

I can still find the images:

$ azure vm image list --location AustraliaEast --publisher MicrosoftSQLServer --offer SQL2016-WS2012R2 --sku Express
info:    Executing command vm image list
+ Getting virtual machine images (Publisher:"MicrosoftSQLServer" Offer:"SQL2016-WS2012R2" Sku: "Express" Location:"australiaeast")
data:    Publisher           Offer             Sku      OS       Version     Location       Urn                                                   
data:    ------------------  ----------------  -------  -------  ----------  -------------  ------------------------------------------------------
data:    MicrosoftSQLServer  SQL2016-WS2012R2  Express  Windows  13.0.16021  australiaeast  MicrosoftSQLServer:SQL2016-WS2012R2:Express:13.0.16021
data:    MicrosoftSQLServer  SQL2016-WS2012R2  Express  Windows  13.0.21641  australiaeast  MicrosoftSQLServer:SQL2016-WS2012R2:Express:13.0.21641
data:    MicrosoftSQLServer  SQL2016-WS2012R2  Express  Windows  13.0.31640  australiaeast  MicrosoftSQLServer:SQL2016-WS2012R2:Express:13.0.31640
info:    vm image list command OK

@njappboy
Copy link
Author

njappboy commented Apr 4, 2017 •
edited
Loading

@devigned in my case it isn't an image issue because I've been iterating on the same image on and off for 2 weeks while developing an ansible role. I'm using OpenLogic:CentOS:7.3:latest in eastus2.

az vm image list -p OpenLogic -s 7.3 -l eastus2 --all
[
  {
    "offer": "CentOS",
    "publisher": "OpenLogic",
    "sku": "7.3",
    "urn": "OpenLogic:CentOS:7.3:7.3.20161221",
    "version": "7.3.20161221"
  }
]

I did try using a specific well known image to see if it was an issue with 'latest' but this yielded the same results/error:

==> default:  -- Location: eastus2
==> default:  -- SSH User Name: tibco
==> default:  -- Admin Username: vagrant
==> default:  -- VM Name: withered-violet-4
==> default:  -- VM Size: Standard_DS2_v2
==> default:  -- Image URN: OpenLogic:CentOS:7.3:7.3.20161221

@devigned
Copy link
Member

devigned commented Apr 4, 2017

What versions of Vagrant are you all running?

@devigned devigned self-assigned this Apr 4, 2017
@matt-richardson
Copy link
Contributor

I'm on Vagrant 1.8.7.

@devigned
Copy link
Member

devigned commented Apr 4, 2017

I think I found the issue. I believe it's a change between faraday 0.11.0 and 0.12.0.1. I just did a bundle update and got an error from faraday.

@salameer you should be aware as this will likely affect Ruby SDK.

@devigned
Copy link
Member

devigned commented Apr 4, 2017

@sarangan12 looks like this line: https://github.com/Azure/azure-sdk-for-ruby/blob/master/runtime/ms_rest/lib/ms_rest/service_client.rb#L91 needs to be:

  @@ssl_options = {}

This should be fixed as soon as possible as it will cause failures for all apps that have taken a dependency on ms_rest and are using faraday.

@devigned devigned mentioned this issue Apr 4, 2017
Merged
@devigned
Copy link
Member

devigned commented Apr 4, 2017

Grab pre7 and this should be mitigated. We'll update to the latest ms_rest when released.

@sarangan12 sarangan12 mentioned this issue Apr 4, 2017
Merged
@sarangan12
Copy link
Member

sarangan12 commented Apr 4, 2017 •
edited
Loading

The latest ms_rest 0.6.4 has been released - https://rubygems.org/gems/ms_rest/versions/0.6.4

@matt-richardson
Copy link
Contributor

Thanks for the quick turnaround, @devigned. Confirmed the fix works.

@njappboy
Copy link
Author

njappboy commented Apr 5, 2017

@devigned Let me echo @matt-richardson comments, thank you for the quick turnaround. Confirmed the fix works too.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@devigned devigned

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

lock down to faraday 0.11.0 devigned/vagrant-azure
4 participants
@njappboy @matt-richardson @devigned @sarangan12