missioncriticalcloud / vagrant-cloudstack Goto Github PK

View Code? Open in Web Editor NEW

67.0 23.0 45.0 669 KB

Use Vagrant to manage your Cosmic or Cloudstack instances.

License: MIT License

Ruby 97.51% Shell 0.82% PowerShell 0.65% Dockerfile 1.02%

cosmic cloudstack vagrant rubygem

vagrant-cloudstack's People

Contributors

Stargazers

Watchers

vagrant-cloudstack's Issues

Destroying VM with Static NAT and Firewall Rules

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?

Set cloudstack template via config.vm.box attribute

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.

QUESTION: What is this file for?

.vagrant/machines/default/cloudstack/index_uuid

index_uuid: What is that a UUID for?

Thanks.

Clear Error Messages

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)

Build is failing on TravisCI

Quick check in logs suggest parsing error due to wrong version of ruby needed to build dependency to vagrant.

Any chance setting VM hostname will be implemented

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 ;)

how to start this

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:inconnect'
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:ininitialize'
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:innew'
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:inrequest_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:inrequest_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:inrequest_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:inrequest'
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:inrequest'
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:inrequest'
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:intranslate_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:inid_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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:inbusy'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:incall'
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:inbusy'
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:inaction_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:inlock'
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:inaction'
from /opt/vagrant/embedded/gems/gems/vagrant-1.7.2/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

allow nfs mounting

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.

Is it possible to have the public port for SSH randomly generated?

And have some kind of clash protection?

Can't provision instance with Basic Networking in v1.2.0 - works on 1.1.0 and 1.0.0

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:

uninstalled vagrant-cloudstack
installed vagrant-cloudstack version 1.0.0 : vagrant plugin install vagrant-cloudstack --plugin-version 1.0.0
running vagrant up --provider=cloudstack gives no error
uninstalled vagrant-cloudstack v1.0.0
installed vagrant-cloudstack version 1.1.0 : vagrant plugin install vagrant-cloudstack --plugin-version 1.1.0
running vagrant up --provider=cloudstack gives no error

I 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!

pf_open_firewall should not be combined/related with pf_trusted_networks

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)

Would like to specify where pf_open_firewall opens the network to (world by default)

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 😉

Does vagrant-cloudstack support logging into windows boxes?

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.

[ EMS ] : INFO retryable: Retryable exception raised: #<Fog::Errors::TimeoutError: The specified wait_for timeout (2 seconds) was exceeded>

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.

Support the 'reload' command

It would be nice to support the 'reload' command (https://docs.vagrantup.com/v2/cli/reload.html).

CloudStack acquire Public IP address

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

No way to set VM tags

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.

Is cloudstack.iso_id an alternative to cloudstack.template_id ?

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

Firewall not appropriately open when using generated public port

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.

Template name used is mis-reported

Template name doesn't match the UUID used.
Doen't cause issue, just a visual thing.

vagrant-cloudstack plugin broken with vagrant >= 1.5

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.

overlapping firewall rules kill vagrant

If an overlapping firewall rule is created vagrant fails with an error. The machine is created but this should be handled cleanly

vagrant 1.6.* support

Hi, have you tested this plugin with vagrant 1.6.* ?
It seems to be broken.

Username and password prompt issues with multiple VM definitions

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.

firewall rule creation port range end port not working

When creating a firewall rule the specified end port of the port range is not effective. The rule created effectivelly opens only one port.

destroy fails when automatically created firewall rule is removed outside vagrant

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.

Is the project actively maintained?

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,

Trusted network CIDR would best be an Array

This way we can better integrate with other tools (like kitchen e.g.).

Random public port range should be split in two attributes: star & end

This way we could better integrate with other tools (kitchen e.g.)

network_ids should be ignored when network_type is set to Basic

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.

Option to open automagically generated random forwarding port in firewall

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.

Installing the plugin

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

Allow to override rsync arguments

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?

Use pf_trusted_networks as default cidrlist for Firewall rules

If an (explicit) cidrlist is missing in the rule

Does this support PublicCloud services?

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,

Ability to assign a static (private) IP

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.

Provide possibility to specify template names

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.

Issue with missing host parameter

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:innew'
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:incall'
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:incall'
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:incall'
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:inbusy'
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:inaction'
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

License missing from gemspec

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.

Destroy fails/breaks on Windows host

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.

Add support for resolving projects by name.

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

Enable RDP support for Windows guests

Add 'RDP capability' and automatic port forwarding (if Windows guest)

Generate SSH keys within ACS, specific to a VM, for the lifetime of that VM

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,

Generate a keypair in ACS, and save private key (alongside fwrules id's, etc)
Use generated keypair name and resulted private keyfile for communication.

For all subsequent communication:

Use generated keypair name and resulted private keyfile for communication.

On destroy of VM,

destroy the keypair name in ACS, and remove from disk.

Setting port forwarding rules opens up firewall to 0.0.0.0/0

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.

Building gem yields several warnings

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

Supporting projects

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

VMs are not expunged after being destroyed

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?

Add windows VM support

Test if a windows template in ACS with vagrant/vagrant credentials works.
If that works:

Investigate which ACS API call returns the generated password, or how we enable that in a API call
Investigate how vagrant passes on configuration to winrm communicator (https://github.com/mitchellh/vagrant/tree/d7eaf503298014a93e1faa8da88947bc7d32ba58/plugins/communicators/winrm)
In the plugin have an action (similar to SSH) that reads the config that comes from the Vagrantfile and creates a environment data structure with the correct credentials (vagrant-cloudstack/action/read_ssh_info.rb)
In the action module refine the action that reads the winrm config, but also the action that uses winrm to communicate (vagrant-cloudstack/action.rb)

Vagrant destroy destroys other vms when vagrant vm is not created yet

originally reported by Timothy van Zadelhoff @j00p34

How do you setup ssh?

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

missioncriticalcloud / vagrant-cloudstack Goto Github PK

vagrant-cloudstack's People

Contributors

Stargazers

Watchers

Forkers

vagrant-cloudstack's Issues

Recommend Projects

Recommend Topics

Recommend Org