eucher/opennebula-provider

opennebula-provider's Issues

Publish new version

Hello! Thanks for good stuff, we used it in the cloudlinux.
But we build gem from last commit on the fog branch and upload from our server for access other staff.
It's works very well for OpenNebula 4.14.2 in our case.
Could you publish new version (0.4.0) and upload it to rubygems?

Vagrant up failed with unknown 'LCM_INIT_3' VM state

In some rare cases, we got

The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'pending, prolog, boot, active'. The machine is in the
'LCM_INIT_3' state. Please verify everything is configured
properly and try again.

Cannot execute vagrant ssh -c

Vagrant supports executing commands via SSH, but when I'm trying to do so with VMs in OpenNebula, I'm receiving the following error:
vagrant ssh -c "uname -r"
Vagrant attempted to call the action 'ssh_run' on the provider
'#VagrantPlugins::OpenNebulaProvider::Provider:0x000000018c3ab0', but this provider doesn't support this action. This
is probably a bug in either the provider or the plugin calling this
action, and should be reported.

opennebula-provider version: 1.0.1
vagrant version: 1.8.4

Not compatible with vagrant 1.9.0

After update from 1.8.7 to 1.9.0 opennebula plugin became broken and reinstall does not fix the issue.

VM not deleted in new opennebula versions

Environment:

$ vagrant plugin list
opennebula-provider (1.1.6, global)

Opennebula server where work: 5.10.1
Opennebula server where not work: 6.4.0.1

Steps to reproduce:

$ vagrant destroy --force
TEMPLATE_ID: 78949

Expected behavior: VM deleted
Current: VM not deleted. Vagrant not return any error

readme

Hi,

maybe could you replace the todos on the readme with actual text?
even better would be to have complete working examples instead of all this

How to do this

...
do something but I'll not tell you the steps before and after it.
...

in the readme.
As you can probably guess, right now the docs are too thin to contribute to them.
Users will help extend your docs, but as long as they're not even able to make things work due to doc issues, there will be no users, meaning no contributions. Please help us help you.

Not working with OpenNebula 5.5.80 «:in rescue in new': opennebula has no compute service (Fog::Service::NotFound)»

Not working with OpenNebula 5.5.80 «:in rescue in new': opennebula has no compute service (Fog::Service::NotFound)»

Looks like problem
https://forum.opennebula.org/t/fog-plugin-needs-some-work/5755

Missing CPU_MODEL when create VM from template

When I try to create a VM from template, that contain CPU_MODEL option, opennebula-provider miss them:

   WARN fog: Deploying VM with options   <Fog::Compute::OpenNebula::Flavor
      id="51788",
      name="centos-9.0-x86_64",
      content="CONTEXT=[\n  NETWORK=\"YES\",\n  SSH_PUBLIC_KEY=\"$USER[SSH_PUBLIC_KEY]\" ]\nCPU=\"1\"\nCPU_MODEL=[\n  MODEL=\"host-passthrough\" ]\nDESCRIPTION=\"СentOS 9.0 x86_64 \"\nDISK=[\n  IMAGE=\"centos-9.0-x86_64.ceph-ssd\",\n  IMAGE_SIZE=\"10240\",\n  IMAGE_UNAME=\"alternatives\" ]\nHYPERVISOR=\"kvm\"\nLOGO=\"images/logos/centos.png\"\nMEMORY=\"1024\"\nNIC=[\n  NETWORK=\"buildsys23\",\n  NETWORK_UNAME=\"mrybas\" ]\nOS=[\n  ARCH=\"x86_64\" ]\nVCPU=\"1\"",
      cpu="1",
      vcpu="1",
      memory="1024",
      sched_requirements=nil,
      sched_rank=nil,
      sched_ds_requirements=nil,
      sched_ds_rank=nil,
      disk={"IMAGE"=>"centos-9.0-x86_64.ceph-ssd", "IMAGE_SIZE"=>"10240", "IMAGE_UNAME"=>"alter"},
      nic=[    <Fog::Compute::OpenNebula::Interface
        id=nil,
        vnet=      <Fog::Compute::OpenNebula::Network
          id="151",
          name="buildsys23",
          uname="mrybas",
          uid="2",
          gid="0",
          description="",
          vlan="241"
        >,
        model=nil,
        name=nil,
        mac=nil
      >],
      os={"ARCH"=>"x86_64"},
      graphics=nil,
      raw=nil,
      context={"NETWORK"=>"YES", "SSH_PUBLIC_KEY"=>"$USER[SSH_PUBLIC_KEY]"},
      user_variables=""
    >
   INFO machine: New machine ID: 4433256

I.e. in CONTEXT it exist (CPU_MODEL=[\n MODEL=\"host-passthrough\" ]\n) but in result context= - no

undefined method ip for nil:NilClass

Hey, guys

I am using the latest vagrant-opennebula plugin which has parallel up execution. When I run vagrant up --provider=opennebula having multiple machines sometimes I get such a stack trace:

==> kd_rhost1: An error occurred. The error will be shown after all tasks complete.
An error occurred while executing multiple actions in parallel.
Any errors that occurred are shown below.

An unexpected error occurred when executing the action on the
'kd_rhost1' machine. Please report this as a bug:

undefined method `ip' for nil:NilClass

/Users/xenon/.vagrant.d/gems/gems/opennebula-provider-1.1.0/lib/opennebula-provider/helpers/fog.rb:105:in `ssh_info'
/Users/xenon/.vagrant.d/gems/gems/opennebula-provider-1.1.0/lib/opennebula-provider/driver.rb:53:in `ssh_info'
/Users/xenon/.vagrant.d/gems/gems/opennebula-provider-1.1.0/lib/opennebula-provider/action/read_ssh_info.rb:19:in `read_ssh_info'
/Users/xenon/.vagrant.d/gems/gems/opennebula-provider-1.1.0/lib/opennebula-provider/action/read_ssh_info.rb:11:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:224:in `action_raw'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:199:in `block in action'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:530:in `lock'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `action'
/Users/xenon/.vagrant.d/gems/gems/opennebula-provider-1.1.0/lib/opennebula-provider/provider.rb:27:in `ssh_info'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:425:in `ssh_info'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/plugins/synced_folders/rsync/synced_folder.rb:41:in `enable'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/synced_folders.rb:93:in `block in call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/synced_folders.rb:90:in `each'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/synced_folders.rb:90:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/wait_for_communicator.rb:71:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/Users/xenon/.vagrant.d/gems/gems/opennebula-provider-1.1.0/lib/opennebula-provider/action/create.rb:14:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:95:in `block in finalize_action'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/call.rb:53:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builtin/config_validate.rb:25:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/warden.rb:34:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/builder.rb:116:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `block in run'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/util/busy.rb:19:in `busy'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/action/runner.rb:66:in `run'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:224:in `action_raw'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:199:in `block in action'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/environment.rb:561:in `lock'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `call'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/machine.rb:185:in `action'
/opt/vagrant/embedded/gems/gems/vagrant-1.8.1/lib/vagrant/batch_action.rb:82:in `block (2 levels) in run'

Right after I did vagrant destroy -f && vagrant up --provider=opennebula and everything went fine.

Do you have any idea why this happens? It may be some opennebula bug, but in such I case I would prefer to see some friendly error. And optionally expect a retry :)

problem with vcenter VM templates

Does this plugin work with vcenter hosts defined in opennebula? Using 1.1.2 version btw.
When I try to bring up VM which is based on KVM template, it works. In the case of vcenter based templates, it won't work. It seems like the only difference is that user template sent to opennebula does not contain "SCHED_REQUIREMENTS" information (when vagrantfile has vcenter-based VM template ID) and the final result is that opennebula is not making correct scheduler decision.

Unkown machine state

The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'pending, prolog, boot, active'. The machine is in the
'PROLOG_RESUME_3' state. Please verify everything is configured
properly and try again.

Conflicting dependency chains with `vagrant-google`

Versions:

• Vagrant 2.1.5
• opennebula-provider (1.1.2, global)

How to reproduce: install conflicting plugin vagrant plugin install vagrant-google

conflicting dependencies fog-google (<= 0.1.0) and fog-google (~> 1.8.1)
  Activated fog-google-1.8.1
  which does not match conflicting dependency (<= 0.1.0)

  Conflicting dependency chains:
    vagrant-google (= 2.2.1), 2.2.1 activated, depends on
    fog-google (~> 1.8.1), 1.8.1 activated

  versus:
    opennebula-provider (= 1.1.2), 1.1.2 activated, depends on
    fog (>= 1.38.0, ~> 1.38), 1.42.1 activated, depends on
    fog-google (<= 0.1.0)

Could we use a more recent version of fog ?

`vagrant rsync` do nothing

Hi @eucher
I've got a simple Vagrantfile with config.vm.synced_folder ".", "/vagrant", type: "rsync" inside.
vagrant rsync do not proceed synchronizing but vagrant provision do the job.

I tried to debug it myself with no luck.

Thanks!

Something not quite right ...

Hi, I'm trying this out with OpenNebula 4.4.1 and Vagrant 1.5.4, doesn't seem to be happening for me and there's no obvious indication as to why. Can you point me in the right direction?

vagrant up --provider=opennebula

On the server;
[E]: User not authorized
[I]: 10.10.0.100 - - [04/May/2014 18:39:35] "HEAD /-/ HTTP/1.1" 401 - 0.0027

On the client;
gems/gems/occi-api-4.2.2/lib/occi/api/client/http/authn_plugins/keystone.rb:43:in `process_headers': Response does not contain the www-authenticate header, fallback failed! (Occi::Api::Client::Errors::AuthnError)

Vagrant config;

Vagrant.configure("2") do |config|
config.vm.box = "dummy"

config.vm.provider :opennebula do |one, override|
one.endpoint = 'http://nebula:4568'
one.username = 'vagrant'
one.password = 'vagrantpass009'
one.os_tpl = 'small'
one.auth = 'basic'
one.resource_tpl = 'ubuntu'
end
end

Any ideas??

Translation missing for the boot state

Current machine states:
default                   translation missing: en.opennebula_provider.states.short_boot (opennebula)
translation missing: en.opennebula_provider.states.long_boot