missioncriticalcloud / vagrant-cloudstack Goto Github PK
View Code? Open in Web Editor NEWUse Vagrant to manage your Cosmic or Cloudstack instances.
License: MIT License
Use Vagrant to manage your Cosmic or Cloudstack instances.
License: MIT License
hey All,
How much work would it be to support NFS mounts in the vagrant files? Currently you can only use rsync which makes the vagrant-cloudstack plugin less than ideal for code projects. I tried the rsync-auto flag but it doesn't seem to work.
Hi,
Can you advise how you install the plugin? Downloaded the files from git but not really sure how you install the plugin, is there a specific file/folder that needs to be referenced for this?
Cheers
Mark
When generating random ports for forwarding we need to open a range in the firewall. It would be very nice if we could have the option to open the random port only.
Guys, Hi. My "vagrant-cloudstack" is "0.0.5" and "Vagrant" is "1.3.4"
I have the following statement tried 60 times every 2 seconds.
...
INFO retryable: Retryable exception raised: Fog::Errors::TimeoutError: The specified wait_for timeout (2 seconds) was exceeded
...
What happens in the meantime (i.e.: what's sent from my test box to the cloud API):
[a.] An instance is created, I can see that in the Cloud portal. During this phase it is initializing. It takes from 3 to 5 minutes.
…
Request: /client/api?templateid=dafa6819-465d-4e87-bb21-d66f3ca5f1f1&serviceofferingid=a6fdb90b-9d56-4927-a2fe-386f9d473237&zoneid=d73e8d08-f1e6-4e67-9030-ff58f36b7b20&displayname=root_test
_1383140024&projectid=4c730aab-07ca-4a07-af24-ce13b50bc205&command=deployVirtualMachine&networkids=242d4c4c-4f0c-43d4-86f5-03d51ef531a1&response=json&apiKey=[MY_API_KEY]&signature=vM%2BSSI1qtFZHWhmQ%2BlhDTeEc2SI%3D
Response: { "deployvirtualmachineresponse" : {"id":"a65c3302-2fe0-4a86-8424-9aa2e2bd76f0","jobid":"b8097319-297a-44bc-afdf-01f002f2399f"} }
[b.] When point “[a.]” is completed the “cloudstack” will try every 2 seconds and for 60 tries request the following:
…
Request: /client/api?id=a65c3302-2fe0-4a86-8424-9aa2e2bd76f0&command=listVirtualMachines&response=json&apiKey=[MY_API_KEY]&signature=nJip8J2r9MhXD9ZyRkc4Dm8L0EQ%3D
Response: { "listvirtualmachinesresponse" : { } }
After 60 tries, Vagrant throws en exception when it tries to destroy the VM. Which makes sense looking at the above. This being said the VM itself is still not flagged as running in the Portal, at that point in time.
My problem is that even when it’s running, firing the “[b.]” URL again wont’ change the returned body. (i.e.: will remain “{ "listvirtualmachinesresponse" : { } }”)
Wondering what’s wrong.
Thanks in advance.
It would be nice to support the 'reload' command (https://docs.vagrantup.com/v2/cli/reload.html).
I have successfully booted a windows template using the cloudstack provider.However, when it gets to the ssh command it cannot login to confirm a successful boot as it is a windows box. Previously, with other providers, I have used the vagrant-windows plugin which allows logging in with winrm as opposed to ssh, the cloudstack plugin does not support that option.Am I missing something glaringly obvious in terms of setup or do you not currently support booting windows boxes or provisioning at the moment.Any help would be much appreciated.
originally reported by Timothy van Zadelhoff @j00p34
The problem is that is becomes impossible to automatically recreate the machine without expunging it in the CloudStack. Is it possible to do that with some option?
Quick check in logs suggest parsing error due to wrong version of ruby needed to build dependency to vagrant.
When creating a firewall rule the specified end port of the port range is not effective. The rule created effectivelly opens only one port.
The CloudStack API call to start a VM allows you to assign an IP address to you VM. The vagrant-cloudstack plugin doesn't expose this capability.
Vagrant's config.vm.network option can be used for it.
Add 'RDP capability' and automatic port forwarding (if Windows guest)
Review warnings and fix appropriately.
Some dependencies like fog
could actually be upgraded.
> gem build vagrant-cloudstack.gemspec
WARNING: description and summary are identical
WARNING: pessimistic dependency on fog (~> 1.22.0) may be overly strict
if fog is semantically versioned, use:
add_runtime_dependency 'fog', '~> 1.22', '>= 1.22.0'
WARNING: open-ended dependency on rake (>= 0, development) is not recommended
if rake is semantically versioned, use:
add_development_dependency 'rake', '~> 0'
WARNING: pessimistic dependency on rspec-core (~> 2.14.7, development) may be overly strict
if rspec-core is semantically versioned, use:
add_development_dependency 'rspec-core', '~> 2.14', '>= 2.14.7'
WARNING: pessimistic dependency on rspec-expectations (~> 2.14.4, development) may be overly strict
if rspec-expectations is semantically versioned, use:
add_development_dependency 'rspec-expectations', '~> 2.14', '>= 2.14.4'
WARNING: pessimistic dependency on rspec-mocks (~> 2.14.4, development) may be overly strict
if rspec-mocks is semantically versioned, use:
add_development_dependency 'rspec-mocks', '~> 2.14', '>= 2.14.4'
WARNING: See http://guides.rubygems.org/specification-reference/ for help
Successfully built RubyGem
Name: vagrant-cloudstack
Version: 1.0.0
File: vagrant-cloudstack-1.0.0.gem
Currently the templates are specified using template UUIDs. It would be great to be able to provide template names as an alternative. Template names are nicer from readability and maintenance (no need to update configs if the template is updated and put under the same name) standpoints.
Using vagrant-cloudstack plugin today we found out that when http server is throwing back error code it does not parses it into helpful error messages, and the Ruby exception takes place:
$ vagrant up --provider cloudstack
Bringing machine 'default' up with 'cloudstack' provider...
==> default: Warning! The Cloudstack provider doesn't support any of the Vagrant
==> default: high-level network configurations (`config.vm.network`). They
==> default: will be silently ignored.
DEBUG:: vagrant-acs action run_instance => hostname =
==> default: Fetching UUID for network with name 'world'
/Users/ofernandes/.vagrant.d/gems/gems/json-1.8.3/lib/json/common.rb:155:in `parse': 795: unexpected token at '<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> (Fog::JSON::DecodeError)
<html><head>
<title>203 Non-Authoritative Information</title>
</head><body>
<h1>Non-Authoritative Information</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator,
[no address given] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.</p>
<p>More information about this error may be available
in the server error log.</p>
<hr>
<address>Apache Server at betacloud.mccx.schubergphilis.com Port 443</address>
</body></html>
'
from /Users/ofernandes/.vagrant.d/gems/gems/json-1.8.3/lib/json/common.rb:155:in `parse'
from /Users/ofernandes/.vagrant.d/gems/gems/multi_json-1.11.0/lib/multi_json/adapters/json_common.rb:14:in `load'
from /Users/ofernandes/.vagrant.d/gems/gems/multi_json-1.11.0/lib/multi_json/adapter.rb:21:in `load'
from /Users/ofernandes/.vagrant.d/gems/gems/multi_json-1.11.0/lib/multi_json.rb:119:in `load'
from /Users/ofernandes/.vagrant.d/gems/gems/fog-json-1.0.2/lib/fog/json.rb:40:in `decode'
from /Users/ofernandes/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/cloudstack/compute.rb:237:in `rescue in issue_request'
from /Users/ofernandes/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/cloudstack/compute.rb:228:in `issue_request'
from /Users/ofernandes/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/cloudstack/compute.rb:192:in `request'
from /Users/ofernandes/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/cloudstack/requests/compute/list_networks.rb:13:in `list_networks'
from /Users/ofernandes/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:489:in `translate_from_to'
from /Users/ofernandes/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:495:in `resourcefield_to_id'
from /Users/ofernandes/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:508:in `name_to_id'
from /Users/ofernandes/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:61:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /Users/ofernandes/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/warn_networks.rb:14:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/synced_folders.rb:84:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/provision.rb:80:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builder.rb:116:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `block in run'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/util/busy.rb:19:in `busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `run'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/call.rb:53:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /Users/ofernandes/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/connect_cloudstack.rb:42:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builder.rb:116:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `block in run'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/util/busy.rb:19:in `busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in `run'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:214:in `action_raw'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:191:in `block in action'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/environment.rb:516:in `lock'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:178:in `call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:178:in `action'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'
May you guys please analise and see what can be improved on this corner cases?
(Thanks in advance)
I've used cloudstack.template_id
for a while with success, however I'd like to use an ISO (a subtype of template as far as I can tell) and I'm not quite sure the proper way to do that. If I set cloudstack.template_id
to a valid ISO id, I receive an error that CloudStack can't find that template. If I set cloudstack.iso_id
, I receive an error that says
Unable to execute API command deployvirtualmachine due to missing parameter templateid
This way we can better integrate with other tools (like kitchen e.g.).
Template name doesn't match the UUID used.
Doen't cause issue, just a visual thing.
I'm not very clear about how to run this. I copy the demo vagrant file. but there is the error when run varant up
Bringing machine 'default' up with 'cloudstack' provider...
==> default: Couldn't find Cheffile at ./Cheffile.
==> default: Warning! The Cloudstack provider doesn't support any of the Vagrant
==> default: high-level network configurations (config.vm.network
). They
==> default: will be silently ignored.
==> default: Fetching name for network with UUID 'network id'
/Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/socket.rb:108:in getaddrinfo': getaddrinfo: nodename nor servname provided, or not known (SocketError) (Excon::Errors::SocketError) from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/socket.rb:108:in
connect'
from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/ssl_socket.rb:148:in connect' from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/socket.rb:28:in
initialize'
from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/ssl_socket.rb:8:in initialize' from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/connection.rb:387:in
new'
from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/connection.rb:387:in socket' from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/connection.rb:106:in
request_call'
from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/middlewares/mock.rb:47:in request_call' from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/middlewares/instrumentor.rb:22:in
request_call'
from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/middlewares/base.rb:15:in request_call' from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/middlewares/base.rb:15:in
request_call'
from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/middlewares/base.rb:15:in request_call' from /Users/ezhang/.vagrant.d/gems/gems/excon-0.45.4/lib/excon/connection.rb:233:in
request'
from /Users/ezhang/.vagrant.d/gems/gems/fog-core-1.32.1/lib/fog/core/connection.rb:81:in request' from /Users/ezhang/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/xml.rb:23:in
request'
from /Users/ezhang/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/cloudstack/compute.rb:229:in issue_request' from /Users/ezhang/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/cloudstack/compute.rb:192:in
request'
from /Users/ezhang/.vagrant.d/gems/gems/fog-1.22.1/lib/fog/cloudstack/requests/compute/list_networks.rb:13:in list_networks' from /Users/ezhang/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:487:in
translate_from_to'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:501:in id_to_resourcefield' from /Users/ezhang/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:510:in
id_to_name'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/run_instance.rb:61:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/warn_networks.rb:14:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/synced_folders.rb:84:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-omnibus-1.4.1/lib/vagrant-omnibus/action/install_chef.rb:38:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-hostmanager-1.6.1/lib/vagrant-hostmanager/action/update_all.rb:24:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/config_validate.rb:25:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/provision.rb:80:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-librarian-chef-0.2.1/lib/vagrant-librarian-chef/action/librarian_chef.rb:20:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-berkshelf-4.0.4/lib/vagrant-berkshelf/action/upload.rb:13:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-berkshelf-4.0.4/lib/vagrant-berkshelf/action/install.rb:10:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /Users/ezhang/.vagrant.d/gems/gems/vagrant-berkshelf-4.0.4/lib/vagrant-berkshelf/action/save.rb:10:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:95:in block in finalize_action' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builder.rb:116:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in block in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/util/busy.rb:19:in
busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/call.rb:53:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /Users/ezhang/.vagrant.d/gems/gems/vagrant-cloudstack-1.1.0/lib/vagrant-cloudstack/action/connect_cloudstack.rb:42:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /Users/ezhang/.vagrant.d/gems/gems/vagrant-berkshelf-4.0.4/lib/vagrant-berkshelf/action/share.rb:10:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /Users/ezhang/.vagrant.d/gems/gems/vagrant-berkshelf-4.0.4/lib/vagrant-berkshelf/action/load.rb:10:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/env_set.rb:19:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /Users/ezhang/.vagrant.d/gems/gems/vagrant-berkshelf-4.0.4/lib/vagrant-berkshelf/action/check.rb:12:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builtin/config_validate.rb:25:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/warden.rb:34:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/builder.rb:116:in
call'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in block in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/util/busy.rb:19:in
busy'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/action/runner.rb:66:in run' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:214:in
action_raw'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:191:in block in action' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/environment.rb:516:in
lock'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:178:in call' from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/machine.rb:178:in
action'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'
When the automatically generated firewall rule is removed by hand (or otherwise outside vagrant)
destroy fails as the rule is not found. Destroy should skip deletion if the rule is not there.
When using cloudstack plugin with vagrant 1.5.1 I'm getting the following error stack.
/Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/plugin/v2/config.rb:73:in `method_missing': undefined method `domain' for #<VagrantPlugins::Cloudstack::Config:0x000001025b27e8> (NoMethodError)
from /Users/christopheroux/.vagrant.d/gems/gems/vagrant-cloudstack-0.2.0/lib/vagrant-cloudstack/action/connect_cloudstack.rb:18:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/warden.rb:34:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/warden.rb:34:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/builder.rb:116:in `call'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/runner.rb:69:in `block in run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/util/busy.rb:19:in `busy'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/action/runner.rb:69:in `run'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/machine.rb:157:in `action'
from /Applications/Vagrant/embedded/gems/gems/vagrant-1.5.1/lib/vagrant/batch_action.rb:72:in `block (2 levels) in run'
This seems to be caused by the following Vagrant change:
hashicorp/vagrant@f72db0c that now raises a NoMethodError for missing methods.
The lib/vagrant-cloudstack/config.rb
file defines the domain_id
attribute:
# Domain id to launch the instance into.
#
# @return [String]
attr_accessor :domain_id
but all files in lib/vagrant-cloudstack/action
are calling the domain
method instead.
So the fix could be either to rename the attribute from domain_id
to domain
in config.rb
(this is what I have tested and seems to work) or replace all calls to provider_config.domain
by provider_config.domain_id
.
And have some kind of clash protection?
RubyGems.org doesn't report a license for your gem. This is because it is not specified in the gemspec of your last release.
via e.g.
spec.license = 'MIT'
# or
spec.licenses = ['MIT', 'GPL-2']
Including a license in your gemspec is an easy way for rubygems.org and other tools to check how your gem is licensed. As you can imagine, scanning your repository for a LICENSE file or parsing the README, and then attempting to identify the license or licenses is much more difficult and more error prone. So, even for projects that already specify a license, including a license in your gemspec is a good practice. See, for example, how rubygems.org uses the gemspec to display the rails gem license.
There is even a License Finder gem to help companies/individuals ensure all gems they use meet their licensing needs. This tool depends on license information being available in the gemspec. This is an important enough issue that even Bundler now generates gems with a default 'MIT' license.
I hope you'll consider specifying a license in your gemspec. If not, please just close the issue with a nice message. In either case, I'll follow up. Thanks for your time!
Appendix:
If you need help choosing a license (sorry, I haven't checked your readme or looked for a license file), GitHub has created a license picker tool. Code without a license specified defaults to 'All rights reserved'-- denying others all rights to use of the code.
Here's a list of the license names I've found and their frequencies
p.s. In case you're wondering how I found you and why I made this issue, it's because I'm collecting stats on gems (I was originally looking for download data) and decided to collect license metadata,too, and make issues for gemspecs not specifying a license as a public service :). See the previous link or my blog post about this project for more information.
I am wondering if the plugin works with project in cloudstack.
In my cloudstack Vagrantfile i have these two lines (correct id)
cloudstack.pf_ip_address_id="679d396f-6837-4b69-b43e-452c7f2034a9"
cloudstack.project_id = "e69e9922-4c9e-4cb8-bcb7-709e99aa2b95"
but when I am running it i am getting the following error
└─$ vagrant up tom --provider=cloudstack [358/4051]
INFO global: Vagrant version: 1.6.0
INFO global: Ruby version: 2.0.0
INFO global: RubyGems version: 2.0.14
INFO global: VAGRANT_EXECUTABLE="/Applications/Vagrant/bin/../embedded/gems/gems/vagrant-1.6.0/bin/vagrant"
INFO global: VAGRANT_LOG="debug"
INFO global: VAGRANT_INSTALLER_EMBEDDED_DIR="/Applications/Vagrant/bin/../embedded"
INFO global: VAGRANT_INSTALLER_VERSION="2"
INFO global: VAGRANT_DETECTED_OS="Darwin"
INFO global: VAGRANT_INSTALLER_ENV="1"
INFO global: VAGRANT_INTERNAL_BUNDLERIZED="1"
INFO global: Plugins:
INFO global: - builder = 3.2.2
INFO global: - bundler = 1.6.2
INFO global: - excon = 0.33.0
INFO global: - formatador = 0.2.4
INFO global: - mime-types = 2.2
INFO global: - net-ssh = 2.9.1
INFO global: - net-scp = 1.1.2
INFO global: - fog-core = 1.22.0
INFO global: - multi_json = 1.10.0
INFO global: - fog-json = 1.0.0
INFO global: - fog-brightbox = 0.0.2
INFO global: - mini_portile = 0.6.0
INFO global: - nokogiri = 1.6.2.1
INFO global: - fog = 1.22.0
INFO global: - rest-client = 1.6.7
INFO global: - vagrant-cloudstack = 0.6.0
INFO global: - vagrant-login = 1.0.1
INFO global: - vagrant-share = 1.0.1
....
INFO interface: info: Creating a port forwarding rule for this instance ...
INFO interface: info: ==> tom: Creating a port forwarding rule for this instance ...
==> tom: Creating a port forwarding rule for this instance ...*messages
INFO run_instance: ONE {"listpublicipaddressesresponse"=>{}}*custom messages
ERROR warden: Error occurred: undefined method `[]' for nil:NilClass
INFO warden: Beginning recovery process...
INFO warden: Calling recover: #<VagrantPlugins::Cloudstack::Action::RunInstance:0x00000102db9ef0>
INFO machine: Calling action: read_state on provider Cloudstack (9d0cf504-8d9a-46ee-8e6e-38c497c51c06)
.....
which if i understand fails to get any response about the public ip.
What do you think?
Thanks
This way we could better integrate with other tools (kitchen e.g.)
When destroying a VM, the code will first remove static NAT and then tries to remove firewall rules.
It however fails on this step, as static NAT removal automatically removes firewall rules [TESTED ON CLOUDSTACK 4.4.3].
Commented lines 66-92 in action/terminate_instance.rb to get around the issue, though it is probably not a correct fix in all scenarios. Possibly removing firewall rules before static nat would work?
You can set user_data for the CloudStack VMs, but there's no way to set VM tags. The vagrant-aws plugin supports it and the CloudStack api supports it too.
My PROVIDER sets VM hostname to the VM-ID. Vagrant/cloud-stack doesn't support setting network vals. The API call to createVirtualMachine() has hostname parameter.
Setting hostname on VM doesn't update PROVIDER and internal DNS. ( I can't nslookup my machine based on set hostname, but on hostname in UI, auto-generated).
I can set with Puppet, but again doesn't update PROVIDER DNS.
Please ;)
Currently fog doesn't support the different project apis listed here:
https://cloudstack.apache.org/docs/api/apidocs-4.3/TOC_Root_Admin.html
I have registered an issue with fog:
fog/fog#3015
Hi, this is more a question than an issue.
Given the plugin does not support config.vm.network settings in Vagrantfile, I'm assuming your Cloudstack templates already have ssh and other settings setup?
Thanks,
Manuel
I've removed the public port on a working config and a public port gets generated (as expected) but the firewall rule does get the generated public port.
My config:
cloudstack.pf_open_firewall = false
cloudstack.firewall_rules = [{"ipaddress" => "A.B.C.D", "cidrlist" => "E.F.G.H/32", "protocol" => "tcp"}]
The resulting firewall rule in Cloudstack misses the start- and end-port.
Looking into the code I find that the generated public port is not propagated to the specified firewall rules.
That means we must use the trusted networks attribute to have the firewall well configured.
I guess this is not a bug, but maybe the documentation needs to be updated to explain how to use this.
Hi,
I'm trying this plugin to use Contegix CloudService(CloudStack3.0), but vagrant up fails.I'm checking the result now.
Please let me know folowings,
1.The endpoint of Contegix is as below.
Does this plugin support the API ptah "portal/client/api" ?
https://cloud.contegix.com/portal/client/api
2.Does this plugin support both CloudStack 3.0.x and 2.2.x ?
3.What environment have you tested?
Private Cloud? Public Cloud? Both?
Thanks,
The following configuration works (shortened for brevity) :
Vagrant.configure("2") do |config|
config.vm.box = "dummy"
config.vm.provider :cloudstack do |cloudstack, override|
cloudstack.host = "cs.example.com"
# ...
cloudstack.template_id = "foo"
end
config.vm.provision "shell", path: "provision.sh"
end
However, a similar configuration, attempting to define 2 VMs does not work :
Vagrant.configure("2") do |config|
config.vm.provider :cloudstack do |cloudstack, override|
cloudstack.host = "cs.example.com"
# ...
cloudstack.template_id = "foo"
end
config.vm.define "hdfs1" do |hdfs1|
hdfs1.vm.box = "dummy"
end
config.vm.define "hdfs2" do |hdfs2|
hdfs2.vm.box = "dummy"
end
config.vm.provision "shell", path: "provision.sh"
end
I'm not very familiar with Ruby, but if I get some free time I can attempt to submit a PR.
Would like to specify an ip/network range/multiple ranges to which the communication port is restricted to.
E.g. : pf_trusted_networks = "1.2.3.4/24,11.22.33.44/32"
Something like #99 😉
Hi!
It is currently not possible to override arguments provided to rsync. I would like to be able to use --copy-links
. With regular rsync folders, this is something easy to do: http://docs.vagrantup.com/v2/synced-folders/rsync.html
Would it be possible to have something similar when using the Cloudstack provider?
If an (explicit) cidrlist is missing in the rule
vagrant destroy, or an interrupted "build" run (up), breaks with an exception
This is specific for running vagrant/vagrant-cloudstack on a/my Windows host.
More specific, on terminate_instance, the firewall file is opened and read in a loop #L18.
After this the file is deleted #L39.
From the system it can be seen that the file is still open by the ruby interpreter.
Currently the template to use is set in a cloudstack specific attribute, but since vagrant requires a box to be set, one has to set that to a valid box (e.g. the dummy box found in the plugin).
It would be better to set the template to use via the config.vm.box atribute.
If an overlapping firewall rule is created vagrant fails with an error. The machine is created but this should be handled cleanly
Hi,
Trying to provision an instance on Exoscale Compute I'm running into a problem with version 1.2.0 of this plugin.
Exoscale Compute uses Cloudstack with Basic networking.
They provide vagrant boxes but to simplify troubleshooting, I'm not using them.
$ ruby --version
ruby 2.2.2p95 (2015-04-13 revision 50295) [x86_64-darwin14]
$ vagrant --version
Vagrant 1.7.4
My Vagrantfile:
Vagrant.configure(2) do |config|
config.vm.box = "csdummy"
config.vm.provider :cloudstack do |cloudstack, override|
override.nfs.functional = false
cloudstack.api_key = ENV['EXO_API_KEY']
cloudstack.secret_key = ENV['EXO_SECRET_KEY']
cloudstack.service_offering_name = "Micro"
#cloudstack.service_offering_id = "71004023-bb72-4a97-b1e9-bc66dfce9470"
cloudstack.security_group_names = ["default"]
cloudstack.keypair = "default"
cloudstack.ssh_key = "~/.ssh/id_rsa"
cloudstack.ssh_user = "root"
cloudstack.network_type = "Basic"
cloudstack.host = "api.exoscale.ch"
cloudstack.path = "/compute"
cloudstack.port = "443"
cloudstack.scheme = "https"
cloudstack.template_id = "cdefccdb-996d-41c4-9ffc-7e493ba24957"
#cloudstack.network_id = "00304a04-c7ea-4e77-a786-18bc64347bf7"
cloudstack.zone_id = "1128bd56-b4d9-4ac6-a7b9-c715b187ce11"
end
end
The error I get:
$ vagrant up --provider=cloudstack
Bringing machine 'default' up with 'cloudstack' provider...
==> default: Warning! The Cloudstack provider doesn't support any of the Vagrant
==> default: high-level network configurations (`config.vm.network`). They
==> default: will be silently ignored.
==> default: Fetching name for zone with UUID '1128bd56-b4d9-4ac6-a7b9-c715b187ce11'
default: Syncronized resource: zone - 1128bd56-b4d9-4ac6-a7b9-c715b187ce11:ch-gva-2
default: Syncronized resource: network - <unknown id>:<unknown name>
==> default: Fetching UUID for service_offering with name 'Micro'
default: Syncronized resource: service_offering - 71004023-bb72-4a97-b1e9-bc66dfce9470:Micro
default: Syncronized resource: disk_offering - <unknown id>:<unknown name>
==> default: Fetching name for template with UUID 'cdefccdb-996d-41c4-9ffc-7e493ba24957'
default: Syncronized resource: template - cdefccdb-996d-41c4-9ffc-7e493ba24957:Linux Ubuntu 15.04 64-bit
==> default: Fetching UUID for security_group with name 'default'
==> default: Launching an instance with the following settings...
==> default: -- Display Name: nicolasbrechet_vagrant_1446727893
==> default: -- Service offering: Micro (71004023-bb72-4a97-b1e9-bc66dfce9470)
==> default: -- Template: Linux Ubuntu 15.04 64-bit (cdefccdb-996d-41c4-9ffc-7e493ba24957)
==> default: -- Zone: ch-gva-2 (1128bd56-b4d9-4ac6-a7b9-c715b187ce11)
==> default: -- Keypair: default
==> default: -- Security Group: default (df89cc01-55b9-4222-9f70-d1ddad9e33ef)
There was an error talking to Cloudstack. The error message is shown
below:
unable to verify user credentials and/or request signature
My troubleshooting:
vagrant plugin install vagrant-cloudstack --plugin-version 1.0.0
vagrant up --provider=cloudstack
gives no errorvagrant plugin install vagrant-cloudstack --plugin-version 1.1.0
vagrant up --provider=cloudstack
gives no errorI also tried with Ruby 2.0.0p481 and I get the same error with vagrant-cloudstack 1.2.0
Do you have any idea what broke in 1.2.0 ?
Thanks!
Hi all,
Together with a few colleagues, we've been testing this plugin and found some things we would like to contribute. Then we browsed the PRs and saw that some of those things were already implemented by @atsaki. We also saw that, although, people commented very positively in the PRs, they are still pending (the oldest one is from Nov last year).
So, our question is, are the original developers still maintaining the plugin?
Or, are there forks already being maintained independently?
Cheers,
Problem:
pf_open_firewall directly maps to cloudstack (ACS) portforwarding rules (where cloudstack will generated the required firewall rules, open to 0.0.0.0/0).
Currently if pf_trusted_networks is specified, the ACS feature is negated for the portforwarding rule, but only for the Communicator forwards.
If additional portforwards are specified, they WILL be automatically opened to 0.0...
As it should be:
pf_open_firewall (restore) maps to the ACS feature on portforwards.
If pf_trusted_networks is specified (and pf_open_firewall is false), the plugin will generate a firewall rule for each portforward.
In docs it should be clear that pf_open_firewall relates directly to the ACS feature, and pf_trusted_networks (also) automatically opens the firewall to specified networks, but only if the ACS feature is not used (as that rule allows all networks)
Hi,
When trying to vagrant up on the cloudstack option it brings back the below error.
Bringing machine 'default' up with 'cloudstack' provider...
C:/Users/.vagrant.d/gems/gems/fog-1.15.0/lib/fog/core/service.rb:208:in validate_options': Missing required arguments: cloudstack_host (ArgumentError) from C:/Users/.vagrant.d/gems/gems/fog-1.15.0/lib/fog/core/service.rb:58:in
new'
from C:/Users/.vagrant.d/gems/gems/fog-1.15.0/lib/fog/compute.rb:44:in new' from C:/Users/.vagrant.d/gems/gems/vagrant-cloudstack-0.0.6/lib/vagrant-cloudstack/action/connect_cloudstack.rb:40:in
call'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/action/warden.rb:34:in call' from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/action/builtin/config_validate.rb:25:in
call'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/action/warden.rb:34:in call' from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/action/builder.rb:116:in
call'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/action/runner.rb:61:in block in run' from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/util/busy.rb:19:in
busy'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/action/runner.rb:61:in run' from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/machine.rb:147:in
action'
from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.3.5/lib/vagrant/batch_action.rb:63:in `block (2 levels) in run'
Using the below parameters
config.vm.provider :cloudstack do |cloudstack, override|
cloudstack.host = "cloudstackhost"
cloudstack.path = "/client/api"
cloudstack.port = "8080"
cloudstack.scheme = "http"
cloudstack.api_key = ""
cloudstack.secret_key = ""
cloudstack.template_id = ""
cloudstack.service_offering_id = ""
cloudstack.network_id = ""
cloudstack.zone_id = ""
cloudstack.project_id = "test"
end
end
Hi,
If you use a Vagrantfile specifying network_type='Basic'
and network_id="xxxx_xxxx"
, running vagrant up
fails with can't specify network ids in basic zone
.
Fails with can't specify network ids in basic zone
:
Vagrant.configure("2") do |config|
config.vm.provider :cloudstack do |cloudstack, override|
cloudstack.host = "api.exoscale.ch"
cloudstack.path = "/compute"
cloudstack.port = "443"
cloudstack.scheme = "https"
cloudstack.template_id = "cdefccdb-996d-41c4-9ffc-7e493ba24957"
cloudstack.network_id = "00304a04-c7ea-4e77-a786-18bc64347bf7"
cloudstack.zone_id = "1128bd56-b4d9-4ac6-a7b9-c715b187ce11"
cloudstack.network_type = "Basic"
end
end
Works:
Vagrant.configure("2") do |config|
config.vm.provider :cloudstack do |cloudstack, override|
cloudstack.host = "api.exoscale.ch"
cloudstack.path = "/compute"
cloudstack.port = "443"
cloudstack.scheme = "https"
cloudstack.template_id = "cdefccdb-996d-41c4-9ffc-7e493ba24957"
#cloudstack.network_id = "00304a04-c7ea-4e77-a786-18bc64347bf7"
cloudstack.zone_id = "1128bd56-b4d9-4ac6-a7b9-c715b187ce11"
cloudstack.network_type = "Basic"
end
end
Shouldn't it warn the user that network_id will not be used, instead of failing ? This would allow users to keep using Vagrantfile that were working with previous versions of vagrant-cloudstack.
.vagrant/machines/default/cloudstack/index_uuid
index_uuid: What is that a UUID for?
Thanks.
The plugin already supports usage of an SSH key-pair generated/stored in ACS (keypair
).
The plugin should have the following behaviour:
If SSH is needed (SSH Communicator), and keypair
and ssh_key
are not specified,
For all subsequent communication:
On destroy of VM,
Hey, is it possible for this plugin to acquire public IP address automatically to access the box via SSH later? If I just point the config to network "test' who has several acquired public IP`s, one of them being 22.22.22.22 for example, how can I get my box to use this IP and open SSH firewall from my ip(33.33.33.33) to it? My Vagrantfile now:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant.configure("2") do |config|
config.vm.box = "dummy"
config.vm.provider :cloudstack do |cloudstack, override|
cloudstack.private_ip_address = "22.22.22.22"
override.ssh.host = "22.22.22.22"
cloudstack.static_nat = [
{ :ipaddress => "22.22.22.22"}
]
cloudstack.firewall_rules = [
{ :ipaddress => "22.22.22.22", :cidrlist => "33.33.33.33/32", :protocol => "icmp", :icmptype => 8, :icmpcode => 0 },
{ :ipaddress => "22.22.22.22", :cidrlist => "33.33.33.33/32", :protocol => "tcp", :startport => 22, :endport => 22 },
{ :ipaddress => "22.22.22.22", :cidrlist => "33.33.33.33/32", :protocol => "tcp", :startport => 80, :endport => 80 },
]
override.ssh.private_key_path = "/home/ezis/.vagrant.d/vagrant.key"
cloudstack.host = "mycloud.cloudstack.test"
cloudstack.path = "/client/api"
cloudstack.port = "443"
cloudstack.scheme = "https"
cloudstack.api_key = "i..........AKRuigA"
cloudstack.secret_key = "2j_G..............FXw"
cloudstack.template_name = "vagrant"
cloudstack.service_offering_name = "Cloud Server 1 vCPU, 1 GB RAM"
cloudstack.network_name = "test"
cloudstack.zone_name = "Cloud-1"
cloudstack.name = "edik123"
instance_ready_timeout = "300"
end
end
By default, setting a port forwarding rule for a created VM will open up the firewall to 0.0.0.0/0.
This is actually the default behaviour in the Cloudstack API call (https://cloudstack.apache.org/docs/api/apidocs-4.5/user/createPortForwardingRule.html)
This can be a problem when using public IPs, therefore ti would be good to have the option to disable opening up the firewall.
Test if a windows template in ACS with vagrant/vagrant credentials works.
If that works:
Hi, have you tested this plugin with vagrant 1.6.* ?
It seems to be broken.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.