vmware/esx/vsphere module - planning

[Serge van Ginderachter]

Hi,

I'd like to get an overview of what exists so far when it comes to a module for vmware.

We definitely need this, and I might give it a try. I can't give a time frame on when I could work on this, as it's something I'll propbably work on in my own time, but I hope to get at least something basic starting in the coming weeks/month.

The only really interesting, existing base I know about is the stuff in the ansible-provisioning project (https://github.com/ansible-provisioning/ansible-provisioning), notably the vsphere_* modules in library/. AFAICS it seems to me the pysphere module is the way to go.

If someone has the same plans, or already started working on something, i'd very much like to hear about it.

In the mean time, it would be interesting to hear ideas on the subject, on implementation details, etc.

Not sure why the ansible-provisioning modules are split into different modules btw. Whilst the other two seem definitely to be 'not finished', vsphere_boot is a good start, as a more general module.

What I need in the first place, feature wise is

- create a guest, with all the parameters like on would conigure in the GUI (procs, memory, storage, nic's, ..)

- start the guest and let it do a pxe boot the first time

- reconfigure, at least be able to remove a nic (for when we pxe boot a dedicated nic)

- reconigure nic networks (change vlan...)

- stop, start, shutdown, reset

- totally delete & destroy a guest and his storage

- all this idempotently off course

    Serge

[Romeo Theriault]

Hi Serge, I've got an ansible vsphere module that is working, see here:

https://github.com/romeotheriault/ansible-vsphere_guest

It does a lot  of the items you've ticked off, but doesn't currently handle changing VM parameters once the VM is created or destroying the VM. (Let's just say the vmware api is not pretty.)  

I'm taking another approach to automating the guest install. Instead of PXE booting I'm creating a custom network install boot iso with the templated kickstart file on it, and attaching that iso to the VM on creation. (This is an idea I got from Dag @ ansible-provisioning.)  

I've been meaning to work on the module more to make it more generally consumable and maybe eventually integrated into core but have been busy getting our work VM creation workflow redesigned to use this. I'm open to working on it though. Would be interested in your thoughts.

Thanks,

Romeo

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Romeo

[Michael DeHaan]

+1

I would very much like to be able to see a VMware ESX capable, similar-to-EC2-and-rax-modules system in core.   (Aka returns things usable by add_hosts in the instances hash?)

(Is it also possible to do a VMware inventory plugin?)

I'd generally like to see something that is able to create a guest that can at least PXE boot, or do kernel+initrd + boot parameters, either way.

I generally think having to create a boot ISO should be unneccessary, and baking in the kickstart file is unneccessary as the kickstart could be dynamically served up by any one of many systems, including

Cobbler (http://cobblerd.org)*

I think for core inclusion it has to support more than just the boot media approach, since a lot about Ansible should be to get away from the need to spin images, though we can certaintly take over after images are deployed.

--Michael

* = disclaimer, wrote this some years ago, now not maintained by AnsibleWorks but in the excellent hands of James Cammarata, and you should check it out!

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Dag Wieers]

On Thu, 18 Apr 2013, Michael DeHaan wrote:

> I generally think having to create a boot ISO should be unneccessary, and
> baking in the kickstart file is unneccessary as the kickstart could be
> dynamically served up by any one of many systems, including
> Cobbler (http://cobblerd.org)*

Michael,

The ansible-provisioning vsphere_boot module can only do PXE at the
moment.

You've stated your case now a few times that you don't like the ISO stuff,
but all of the modules can do PXE as well.

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, in...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

[Michael DeHaan]

Ok, that's good.

Out of curiosity, is kernel+initrd+commandline also possible?

These may be suitable for core inclusion, the above is not a prereq, but it would be nice if it could avoid a PXE environment (in case one already existed and we wanted to ignore it).

(I believe when I last asked they only did the ISO, or the playbooks that referenced them required doing ISO builds.)

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.

[Dag Wieers]

On Fri, 19 Apr 2013, Michael DeHaan wrote:

> Ok, that's good.
>
> Out of curiosity, is kernel+initrd+commandline also possible?

I doubt vsphere can do that.

> These may be suitable for core inclusion, the above is not a prereq, but it
> would be nice if it could avoid a PXE environment (in case one already
> existed and we wanted to ignore it).

That's why we use ISO media. It's the only common thing all
hardware/hypervisors can do properly. (ESX, KVM, iLO, RSA, RHEV)

> (I believe when I last asked they only did the ISO, or the playbooks that
> referenced them required doing ISO builds.)

No, vsphere only did PXE because I never got the administrative rights on
vSphere to:

1. change the boot order
2. have an NFS datastore or push images to another datastore

You made conclusions based only on the examples I showed using ISO images.
And despite me mentioning that we use ISO just because it makes the most
sense in our environment. But PXE is supported for all *_boot modules (it
just isn't possible in heterogenous environments or disabled by security
in most large companies I have worked)

If you looked at the module documentation it's clear you can do PXE with
all of them. (media=network)

[Michael DeHaan]

Documentation was somewhat short at the time, we're talking about it now, it's all good :)

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-project+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Corey Gaffney]

I have a vsphere_clone module I would like to contribute (amongst others).  My only concern is that I have added async support to the module since this is part of PySphere functionality.  This allows the use of a boolean to indicate asynchronous vs synchronous(the default) in order to cooperate with loops and nested loops in Ansible (which we all know do not support Async at this point in time).  In the spirit of keeping the functionality of PySphere, I have kept this option available and find it quite powerful.

Would this be acceptable, if yes.. then I will perform a pull request or whatever is necessary to contribute.

Thanks,

Corey 

On Friday, April 19, 2013 5:36:47 PM UTC-5, Michael DeHaan wrote:

Documentation was somewhat short at the time, we're talking about it now, it's all good :)

On Fri, Apr 19, 2013 at 6:01 PM, Dag Wieers <d...@wieers.com> wrote:

On Fri, 19 Apr 2013, Michael DeHaan wrote:

Ok, that's good.

Out of curiosity, is kernel+initrd+commandline also possible?

I doubt vsphere can do that.

These may be suitable for core inclusion, the above is not a prereq, but it
would be nice if it could avoid a PXE environment (in case one already
existed and we wanted to ignore it).

That's why we use ISO media. It's the only common thing all hardware/hypervisors can do properly. (ESX, KVM, iLO, RSA, RHEV)

(I believe when I last asked they only did the ISO, or the playbooks that
referenced them required doing ISO builds.)

No, vsphere only did PXE because I never got the administrative rights on vSphere to:

 1. change the boot order
 2. have an NFS datastore or push images to another datastore

You made conclusions based only on the examples I showed using ISO images. And despite me mentioning that we use ISO just because it makes the most sense in our environment. But PXE is supported for all *_boot modules (it just isn't possible in heterogenous environments or disabled by security in most large companies I have worked)

If you looked at the module documentation it's clear you can do PXE with all of them. (media=network)

--
-- dag wieers, d...@wieers.com, http://dag.wieers.com/
-- dagit linux solutions, in...@dagit.net, http://dagit.net/

[Any errors in spelling, tact or fact are transmission errors]

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.

To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

[Michael DeHaan]

Sounds like we'd be interested in taking a look at least, and a PR is a good way to get that in the queue.  I will admit now the queue is quite longish as we're powering through things the best we can.   

I imagine if async is not used, it's a blocking operation, and the async operation in ansible would be needed to use with it, and that might be worth noting in docs?

To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/9e0fc804-8a2d-4923-bc32-feacb183c472%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Corey]

In looking at my original proposal, I think combining two unique implementations of Async functionality is going to be a bad idea, if not for being difficult to troubleshoot and impossible to test, for being a bad design.   

Instead, I would like to suggest not using PySphere Async support and have Ansible handle Async via it's own mechanism 100%.   While it will prevent having the ability to use Async while using with_items and with_nested, it would be consistent with other modules and if this were to ever become a supported feature, no changes would be necessary for the cloning module.

Furthermore, when using the vSphere API for Async tasks, it has it's own queue and comes with it's own set of issues. Such as the queue filling, tracking the many statuses it supports, additional network calls to get status, implementing additional timeouts, etc.

After I make and test this change, I will do a pull request... with the assumption you believe this is a cleaner implementation.

Thanks,

-Corey

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/33hmOR301YI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgyyZt9RKyaHUOC5Ji%2BhCVsZswbkCe8TPSDo0PSoYg9K3Q%40mail.gmail.com.

[kesten broughton]

If you've got a public git branch, i can help with testing and documentation.

I've worked with pysphere a bit.

kesten

[Michael DeHaan]

This is actually already in core.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/2f18a176-4a1e-42de-85de-28056ce51b83%40googlegroups.com.

[kesten broughton]

I was referring to the vsphere_clone mentioned, not vsphere_guest which is in trunk https://github.com/ansible/ansible/tree/devel/library/cloud

As far as i can tell, vsphere_guest currently only supports creating a vm from .iso

What i really need is creating clones from a template.

k

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgzA4TN_dX5eLciswrWQXUBk77%3DU1RSPn3UC5vPCOhAG_Q%40mail.gmail.com.

[Michael DeHaan]

It seems in this case we should try to work the features into the existing module, since they are both about creating guests?

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAK5UeTu4Nd%3DNVAXTcZ44Liv6jsCKF83LpDRtp8NM_8OxK6FZnA%40mail.gmail.com.

[kesten broughton]

I would agree, cloning functionality belongs in vsphere_guest module if possible.

[Jamal B]

Hi, I'm new to ansible and vmware and came across this post which is exactly what I need to do. Forgive me if this is answered elsewhere, but is there a way to configure the vsphere_guest module to clone a virtual machine or start a virtual machine from a template?  

[Jamal B]

Hi, is there a chance that cloning will be added to the vsphere_guest module in an upcoming release?

On Thursday, July 10, 2014 9:08:23 AM UTC-4, kesten broughton wrote:

[Tony Kinsley]

I actually recently got approval to release a module I wrote to manage vsphere. You can find it at https://github.com/ViaSat/ansible-vsphere

We currently use this to manage our datacenter of test and development vms. It uses pyvmomi which is VMWares python library for interacting with the vsphere api.

It currently has support for:

• Create, Clone ( from templates as well ), Delete VMs
• Create, Remove, and Revert to VM snapshots
• Create, Remove Inventory Folders
• Interact with the Guest Operations Manager.

So in order to get support for all those different things, I came up with a way to convert a "spec" object into pyvmomi objects. This allows me to call roughly any function on a Managed Object Reference. I hope it is not too confusing and the documentation is clear. I gave examples but there is likely more that the module is capable of than the examples I gave. My hope is that this module could be one day included in the core Ansible project.

Let me know what you think.

Tony

[kesten broughton]

Nice work!  That's half my battle,

the rest is attaching volumes.

Does your module support that sort of thing?

How would you extend to do that?

kesten

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/8f6fe9e8-ed97-4fba-82cf-429272968d6d%40googlegroups.com.

[Michael DeHaan]

Can I ask what's intended to be different from the module we already have in core?

http://docs.ansible.com/vsphere_guest_module.html

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAK5UeTvnmL%2Bju7Nb%2B0VOQ%3DjOpDRHTDKHFL%3DcWRKf4jDBEf_4oA%40mail.gmail.com.

[kesten broughton]

I started with vsphere_guest but had to give up for lack of the ability to clone from a vm.  There was talk about it, but i don't think it ever made it to trunk.  

It's unfortunate perhaps that vsphere_guest relies on pysphere whereas the current effort depends on pyvmomi which is vmware's officially supported python API.

I need to clone from vm and supply disks.  vsphere_guest has the disk support and ansible-vsphere has clone from template.

pyshere has a headstart in terms of exposed (documented) functionality and community, but will likely be eclipsed by pyvmomi if it can garner a community.  Maybe for now a hybrid approach is necessary with pip-pointed modules dependent on both.  It's no big deal for for a vsphere lover to install both dependencies, although likely one will win in the end.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgw2Vj2%3DYariR7UO4n%3D-Zjf03ObsRMG38PFatpMEFdzttw%40mail.gmail.com.

[Michael DeHaan]

It would be much better to add that capability to the existing one than bifurcate the modules.

See this pull request, though it hasn't had comments answered on it - https://github.com/ansible/ansible/pull/7690

Though I would tend to think maybe snapshot is a different module, and cloning is a parameter of the existing one.

Send me a pull request for an update and we can definitely prioritize it, I don't want to see these start to fork - there's no good reason for that.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAK5UeTsngJU8ecK13SrZ0ExYmEvNrhG2O_ieBCSddebXG4bGtg%40mail.gmail.com.

[Tony Kinsley]

Well it's unfortunate that their is so duplicated functionality. I actually started this before that module was part of core, and when it finally did get added to core it did not meet my needs. That said my module does a lot more than the one in core. Like I said before you can manage VM snapshots, and interact with the guest operations manager which I use to reconfigure the networking on the devices after I clone the VMs. My module can also power the VMs on and off. 

Unfortunately my module does not provide good output after the tasks, and I really could use some help extending it. 

As for attaching volumes I have never done that but I think you should be able too. Are you talking about attaching them during a Clone or Create process or attaching a volume to an existing VM?

I think something like this should work. If you look at the spec values they match up to the vsphere API identically. The spec type is the name of a function to run on the guest managed object and the value of the spec is the parameters to that function ( which in this case happens to be called spec ). You do need to fill in any required fields for those objects, which are specified in the vmware documenation.

-name:attach volume
 local_action:
   module:vsphere
   guest:
     name:test
     state: running
     action: task
   spec:
     type: ReconfigVM_Task
     value:
       spec:
         VirtualMachineConfigSpec :
           deviceChange:
             - VirtualDeviceConfigSpec:
                 operation: add
                 device:
                   VirtualDisk:
                     diskObjectId: <id of existing virtual disk>

 

[Michael DeHaan]

"hat said my module does a lot more than the one in core. "

Right, so I'm suggesting let's add functionality to the core one :)

Please send me a pull request if this is something you think you'd like to do - it's way better long term, and we've always been about "batteries included" and getting everybody together to make modules that work for everyone.

We do need to keep the existing signature for module parameters it currently takes, and I do want to have the conversation about the form factor of extensions to it.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/1b796f24-bbfa-4675-a259-90a0562403bb%40googlegroups.com.

[Tony Kinsley]

After using both, I definitely like using pyvmomi better. Since the API is almost identical to the Vsphere API I was able to use not only the API docs from vmware, but docs for rbvmomi, rvc, and even the java vmware sdk and apply it towards getting the module to do what I want.

As for adding a drive to the cloned VM, that's definitely doable. Here is my example ( that I actually use ) that shows adding a network device. 

- name: clone vsphere machine

  local_action:

    module: vsphere

    host: "{{ vcenter_host }}"

    login: "{{ vcenter_login }}"

    password: "{{ vcenter_pwd }}"

    timeout: 60

    guest:

      name: "{{ host }}"

      state: present

      folder: "{{ group }}"

      clone_from: "{{ template }}"

    spec:

      type: VirtualMachineCloneSpec

      value:

        config:

          VirtualMachineConfigSpec:

            name: "{{ schema.hostname }}"

            memoryMB: 4096

            numCPUs: 1

            deviceChange:

              - VirtualDeviceConfigSpec:

                  operation: add

                  device:

                    VirtualVmxnet3 :

                      key: 0

                      backing:

                        VirtualEthernetCardNetworkBackingInfo:

                          deviceName: "{{ networks[0].name }}"

        location:

          VirtualMachineRelocateSpec:

            pool:

              ManagedObjectReference:

                type: ResourcePool

                name: '{{ resource_pool }}'

            host:

              ManagedObjectReference:

                type: HostSystem

                name: '{{ compute_host }}'

            datastore:

              ManagedObjectReference:

                type: Datastore

                name: '{{ datastore }}'

        powerOn: True

        template: False

To add a disk you would just need to change the deviceChange list to include a VirtualDeviceConfigSpec for the hard drive that you want. I know this is not nearly as easy as just specifying a hard drive, but by taking this approach you can now get any feature that the vmware api provides such as the type of disk backing you want. 

[Michael DeHaan]

I'm open to anything that keeps the same compatible Ansible module signature.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/f5e78679-1a30-45d0-b98b-ddce6e7e6778%40googlegroups.com.

[Dave Hatton]

One thing that is missing from the current vsphere module is the ability reconfigure the cdrom device. My current build process uses a boot.iso to start the build (dont ask why) and so at the end of the create I want to remove the cdrom.

I'm currently using an external script that calls pysphere to do this, it would be nice to have this built in to the ansible module - I'm struggling to work out how to do this. Tony would your module handle this?

[kesten broughton]

Snapshots let you store the state of a vm to roll back to later.  It's different from cloning.  I searched the module for "clone" and "template" and neither is there.

The examples don't cover all the config options, nor do the docs.

vm_hardware:
	memory_mb: 2048
	num_cpus: 2
	osid: centos64Guest
	scsi: paravirtual

but when I played with vsphere_guest my conclusion was that the only support for selecting the base for the vm was

def add_cdrom(module, s, config_target, config, devices, default_devs, type="client", vm_cd_iso_path=None):

In vmware, there are two very different paths for creating a vm. One, you select the cd_rom which is like a bootable iso. The other (more common) is to build up a template (i believe it is backed by a vmdk) and then clone from the template. The latter is the functionality i need, and the former is all that is supported. I could be wrong, but would need an example to show cloning with the given api.

Tony, I am talking about adding a volume after boot, for logs or data drives, although creating partitions on boot would be nice too.

Vsphere is capable of sooo much, I think the idea of adding hooks that expose the functionality in an 'extra-params' like way is the way to go, otherwise you end up with a dozen vsphere-x modules. If vsphere_guest has that capability and it just needs exposing, great. If it is fundamentally not extend then perhaps other options should be explored.

I think apt and synchronize already offer this type of "deeper through extra-args" functionality. Perhaps the best option would be a master module capable of pretty much everything (with good documentation) and then a few facades modules for the most common usages. The code should be factored out into a handful of modules plus some helper classes that are used by all modules, like authentication and connection.

The trouble with the current vsphere_guest is it offers insufficient capabilities to satisfy any real-world usage pattern, and there doesn't seem to be much activity in extending it to do so. Tony's module with the built in power via spec can do orders of magnitude more but would need lots of examples for the various use cases.

I will try to play with the spec today to see if it meets my needs.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgxDB8BaOLQUuWBMq6Q5SrMODvP-3eqTjWq240K8%3D2M7SQ%40mail.gmail.com.

[Tony Kinsley]

I'm fairly confident my module can do it, I just have never done that with the vsphere API. If you have already written a script to do this in pysphere it should be pretty simple to port that. I am assuming that you want to do a ReconfigVM_Task and it would look something like this below. One thing my module is definitely missing is a good facts gathering system. So you would need to gather the device key information in your inventory script. 

      local_action:

        module: vsphere

        host: "{{ vcenter_host }}"

        login: "{{ vcenter_login }}"

        password: "{{ vcenter_password }}"

        timeout: 60

        guest:

          name: "{{ deleteme }}"

          state: running

          action: task
        spec:
          type: ReconfigVM_Task
          value:
            spec:
              VirtualMachineConfigSpec:
                deviceChange:
                  - VirtualDeviceConfigSpec:

                  operation: remove

                  device:

                    VirtualCdrom:

                      key: <actual key of your cdrom>

[Michael DeHaan]

"I think the idea of adding hooks that expose the functionality in an 'extra-params' like way is the way to go"

It's not.

We really want to model things as nouns, so the vsphere_guest module should take a parameter that can boot from a cloned image.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAK5UeTtdoVbHaOW0yxdfVS1YoKbMZuNt2OOK%2BFnStpVpHZhNgQ%40mail.gmail.com.

[Dann Bohn]

Hi all,
I've added quite a bit to the vsphere_guest module to fit our needs, but haven't submitted PR due to lack of time to generalize / create documentation. I'm also the author of PR 7609 referenced above. Things that I've added are the ability to change dvs switch as part of reconfigure, clone, and expand disk as part of reconfigure_vm. If anyone is interested is taking a look at my crude implementation, I can put it up on github. Like I said, I haven't put in PR yet becuase, for example, reconfigure_vm only reconfigures dvs switches, and not standard. and the other bits aren't tested/documented well enough for me to be comfortable submitting. The green button is scary.

I'll open a new thread regarding PR 7690

[Dann Bohn]

It seems a few of us have different implementations of cloning a template, or VM. here's mine: Mine sets state to 'clone' (which probably should be 'cloned' or something more descriptive?) and then adds a parameter: template: to specify a template/VM in which to clone from. I had also noticed there is another PR out there to deploy from template.

https://github.com/whereismyjetpack/ansible/tree/clone

If you look at the branch you'll see there is a lot of logic regarding folders, our organization uses VM folders heavily to grant access and divide systems, so I baked that in, too (it's not documented yet)

I'm waiting on feedback from this PR to document the clone/new vm folders
https://github.com/ansible/ansible/pull/7792

P.S I'm also LogLevel9 -- i somehow got two github accounts and I'm trying to merge them into one.

On Friday, August 22, 2014 10:07:02 AM UTC-4, Michael DeHaan wrote:

[John-Paul Herold]

Hey guys, I've recently been looking to control vsphere via Ansible which lead me to this thread. Noticed a couple pull requests that were before the September 26th git core-module/extra-module split by the Ansible team. Just wanted to revive this thread for those that had PRs that were closed before resolution.

Cheers,

...

[jnit...@gmail.com]

Hi Tony,

I was playing with vsphere module which you had written.

Vmware tools option am trying

---

- hosts: 127.0.0.1

  connection: local

  user: xxx

  sudo: false

  gather_facts: false

  serial: 1

  tasks:

  - name: Upgrade Tools

    local_action:

     module: vsphere

     host: xxx

     login: xxx

     password: xxx

     timeout: 60

     guest:

      name: xxx

      state: running

      action: upgrade_tools

Above playbook (picked from vsphere module example) is giving me below error,

PLAY [127.0.0.1] **************************************************************

TASK: [Upgrade Tools] *********************************************************

failed: [127.0.0.1 -> 127.0.0.1] => {"failed": true, "parsed": false}

  File "/home/osboxes/.ansible/tmp/ansible-tmp-1424864706.76-270477126047013/vsphere", line 2491

    Status API Training Shop Blog About

             ^

SyntaxError: invalid syntax

FATAL: all hosts have already failed -- aborting

PLAY RECAP ********************************************************************

           to retry, use: --limit @/home/osboxes/test_tools.retry

127.0.0.1                  : ok=0    changed=0    unreachable=0    failed=1

I have pyvmomi 5.5 installed with requests and six.

Am I missing something in the playbook? Any clue?

Thanks,

Nitin

[Tony Kinsley]

Hey Nitin,

That error looks really strange, I do not know where "Status API Training Shop Blog About" comes from. But syntax errors are usually pretty easy to figure out. 

Try `export ANSIBLE_KEEP_REMOTE_FILES=1` and rerun the playbook verbose again. After it fails it will not clean up the module that it copies over to the host that gets executed on, so you should be able to navigate to the directory it stored it in and view the module itself. Then you can check out what line of code corresponds to line 2491. 

Also what version of ansible are you using? Not sure how well you know the inner workings of ansible, but basically it takes the custom modules and injects them into a much larger python file that contains loads of helper functions and classes that can be used by the custom modules. I think in newer versions ansible injects the custom module at the top of the file so when you see a backtrace and a line number it matches up with the module itself. Seeing the issue at line number 2491 also makes me think there might be something else going on.

Let me know how it goes.

Tony

--

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/33hmOR301YI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/5750b4d1-63fd-40a4-88db-8f8db482ba9d%40googlegroups.com.

[jnit...@gmail.com]

Hi Tony,

Ansible version am using is 1.8.2. I checked line of code corresponding to line 2491. It says "Status API Training Shop Blog About". No other clue:(. 

Last few lines are as below,

    def pretty_bytes(self,size):

        ranges = (

                (1<<70L, 'ZB'),

                (1<<60L, 'EB'),

                (1<<50L, 'PB'),

                (1<<40L, 'TB'),

                (1<<30L, 'GB'),

                (1<<20L, 'MB'),

                (1<<10L, 'KB'),

                (1, 'Bytes')

            )

        for limit, suffix in ranges:

            if size >= limit:

                break

        return '%.2f %s' % (float(size)/ limit, suffix)

def get_module_path():

    return os.path.dirname(os.path.realpath(__file__))

main()

Status API Training Shop Blog About

© 2015 GitHub, Inc. Terms Privacy Security Contact

and verbose output is as below,

PLAY [127.0.0.1] **************************************************************

TASK: [Upgrade Tools] *********************************************************

<127.0.0.1> REMOTE_MODULE vsphere host=xxx password=VALUE_HIDDEN login=admini...@vsphere.local

<127.0.0.1> EXEC ['/bin/sh', '-c', 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1424886684.83-207068257700957 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1424886684.83-207068257700957 && echo $HOME/.ansible/tmp/ansible-tmp-1424886684.83-207068257700957']

<127.0.0.1> PUT /tmp/tmp3gLdMW TO /home/osboxes/.ansible/tmp/ansible-tmp-1424886684.83-207068257700957/vsphere

<127.0.0.1> EXEC ['/bin/sh', '-c', u'LANG=C LC_CTYPE=C /usr/bin/env python /home/osboxes/.ansible/tmp/ansible-tmp-1424886684.83-207068257700957/vsphere; rm -rf /home/osboxes/.ansible/tmp/ansible-tmp-1424886684.83-207068257700957/ >/dev/null 2>&1']

failed: [127.0.0.1 -> 127.0.0.1] => {"failed": true, "parsed": false}

  File "/home/osboxes/.ansible/tmp/ansible-tmp-1424886684.83-207068257700957/vsphere", line 2491

    Status API Training Shop Blog About

             ^

SyntaxError: invalid syntax