Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ovirt_vms does not proceed cloud-init when state is running. Manual start works #45900

Closed
marc-ledent opened this issue Sep 20, 2018 · 11 comments · Fixed by #47348 or #47854
Closed

ovirt_vms does not proceed cloud-init when state is running. Manual start works #45900

marc-ledent opened this issue Sep 20, 2018 · 11 comments · Fixed by #47348 or #47854
Labels
affects_2.6 This issue/PR affects Ansible v2.6 bug This issue/PR relates to a bug. cloud module This issue/PR relates to a module. ovirt oVirt and RHV community support:community This issue/PR relates to code supported by the Ansible community.

Comments

@marc-ledent
Copy link

SUMMARY

When I create a VM with cloud-init parameters, the cloud init is executed only if I start the VM manually:

In this example, if I set "state: running", the cloud-init part is not executed. I must set "state: present" and start the VM manually in the RHEV console.

ISSUE TYPE
  • Bug Report
COMPONENT NAME

ovirt_vms

ANSIBLE VERSION
ansible 2.6.3                                                                                               
  config file = /etc/ansible/ansible.cfg                                                                    
  configured module search path = [u'/root/.ansible/plugins/modules', u'/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python2.7/site-packages/ansible                                 
  executable location = /usr/bin/ansible                                                                    
  python version = 2.7.5 (default, May 31 2018, 09:41:32) [GCC 4.8.5 20150623 (Red Hat 4.8.5-28)]           

CONFIGURATION
DEFAULT_FORKS(/etc/ansible/ansible.cfg) = 10                                                                      
DEFAULT_GATHERING(/etc/ansible/ansible.cfg) = implicit                                                            
DEFAULT_GATHER_SUBSET(/etc/ansible/ansible.cfg) = all                                                             
DEFAULT_GATHER_TIMEOUT(/etc/ansible/ansible.cfg) = 10                                                             
DEFAULT_HOST_LIST(/etc/ansible/ansible.cfg) = [u'/etc/ansible/hosts.d']                                           
DEFAULT_ROLES_PATH(/etc/ansible/ansible.cfg) = [u'/etc/ansible/roles', u'/opt/ansible/roles']                     
HOST_KEY_CHECKING(/etc/ansible/ansible.cfg) = False                                                               
INVENTORY_IGNORE_EXTS(/etc/ansible/ansible.cfg) = ['~', '.orig', '.bak', '.ini', '.cfg', '.retry', '.pyc', '.pyo',
 '.dhl']                                                                                                          
PERSISTENT_CONNECT_TIMEOUT(/etc/ansible/ansible.cfg) = 30                                                         

OS / ENVIRONMENT
STEPS TO REPRODUCE
- name: Create VM                               
  ovirt_vms:                                    
    state: present                              
    cluster: Default                            
    auth: '{{ ovirt_auth }}'                    
   type: server                                
    name: '{{ inventory_hostname }}'            
    comment: '{{ inv_tag.hostdesc }}'           
    description: '{{ inv_tag.hostdesc }}'       
    memory: "{{ inv_tag.mem | default('2')}}GiB"
    boot_menu: True                             
    disk_format: cow                            
    disks:                                      
    - name: '{{ inventory_hostname }}_OS'       
      interface: virtio                         
      bootable: True                            
      activate: True                            
    nics:                                       
    - name: eth0                                
      interface: virtio                         
      profile_name: ovirtmgmt                   
    cloud_init_persist: True                    
    cloud_init:                                 
      host_name: '{{ inventory_hostname }}'     
      timezone: "GMT+01:00"                     
      dns_servers: "xxxxxxxxxxxxxx"       
      dns_search: "{{ fqdn_name.split('.', 1)[1] }}"
      custom_script: |                              
        users:                                      
          - name: root                              
          - name: ansible                           
            groups: wheel                           
        chpasswd:                                   
          list: |                                   
            root:{{ root_pass }}                    
            ansible:{{ ansible_ssh_pass }}          
          expire: False                             
        ssh_pwauth: True                            
        runcmd:                                     
          - sed -i '/192.168/d' /etc/resolv.conf    
    cloud_init_nics:                                
    - nic_name: eth0                                
      nic_boot_protocol: static                     
      nic_ip_address: '{{ main_ip }}'               
      nic_netmask: 255.255.254.0                    
      nic_gateway: YYYYYYYYYYYY                      
      nic_on_boot: True                             

In this case, "state" must be "present" ans the VM must be started manually unless cloud-config will not be applied and the VM will not be accessible...

EXPECTED RESULTS

The cloud-config settings should be applied when state is "running"

ACTUAL RESULTS

The vm is started with no cloud-init settings. Even the hostname is not set.


@ansibot
Copy link
Contributor

ansibot commented Sep 20, 2018

Files identified in the description:
None

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot ansibot added affects_2.6 This issue/PR affects Ansible v2.6 bug This issue/PR relates to a bug. needs_triage Needs a first human triage before being processed. support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Sep 20, 2018
@s-hertel s-hertel removed the needs_triage Needs a first human triage before being processed. label Sep 21, 2018
@dieterdm
Copy link
Contributor

dieterdm commented Oct 8, 2018

I had the same issue.
Looking at

use_cloud_init=not module.params.get('cloud_init_persist') and module.params.get('cloud_init') is not None,
, it seems use_cloud_init is set to False if cloud_init_persist is set to True. I'm not sure what the purpose of cloud_init_persist is, but setting it to False did fix the issue in my case.

@machacekondra
Copy link
Contributor

+label ovirt

@machacekondra
Copy link
Contributor

@mwperina

@machacekondra
Copy link
Contributor

!component =lib/ansible/modules/cloud/ovirt/ovirt_vm.py

@ansibot
Copy link
Contributor

ansibot commented Oct 17, 2018

Files identified in the description:

If these files are inaccurate, please update the component name section of the description or use the !component bot command.

click here for bot help

@ansibot ansibot added cloud module This issue/PR relates to a module. virt Virt community (incl. QEMU, KVM, libvirt, ovirt, RHV and Proxmox) support:community This issue/PR relates to code supported by the Ansible community. and removed support:core This issue/PR relates to code supported by the Ansible Engineering Team. labels Oct 17, 2018
@machacekondra
Copy link
Contributor

Right, that's because of cloud_init_persist: True. With this parameter you can choose if you want to store the cloud_init parameters in VM or, if cloud_init_persist: False (which is default) the cloud_init configuration will be used only with run once and won't be stored with VM. Is that clear, or should we improve documentation?

@dieterdm
Copy link
Contributor

Using the graphical user interface (I'm using RHV 4.2), one can configure the cloud-init parameters via the "Edit" -> "Initial Run" menu and run the virtual machine ("run", not "run once"). In this case, the cloud-init parameters are used and the VM will be configured correctly after booting. This looks similar to configuring the cloud_init parameter and setting cloud_init_persist to True in your Ansible playbook. However, with Ansible the behaviour is different than manual. The cloud-init parameters are not used and the VM will not be configured after boot.

I think the Ansible way should reflect the manual way and in both cases the cloud_init settings should be used (why would you want to configure cloud-init, but not use it?). Nevertheless, if this is the design intention, the ovirt_vm Ansible doc should state that the cloud_init parameters will never be used when setting cloud_init_persist=true. Also, the default values should be added to the docs.

@machacekondra
Copy link
Contributor

In this case, the cloud-init parameters are used and the VM will be configured correctly after booting. This looks similar to configuring the cloud_init parameter and setting cloud_init_persist to True in your Ansible playbook. However, with Ansible the behaviour is different than manual. The cloud-init parameters are not used and the VM will not be configured after boot.

It should works exactly as you described, same as in UI. Let me investigate why this happens, I will send fix as soon as possible.

machacekondra added a commit to machacekondra/ansible that referenced this issue Oct 19, 2018
Fixes: ansible#45900

This PR fixes the case when the cloud_init_persist was used, but we
still sent use_cloud_init=False, which is in oVirt API evaluated as not
to use cloud_init in first VM execution. This patch is changing it to
send just None, instead of False.

Signed-off-by: Ondra Machacek <omachace@redhat.com>
@machacekondra
Copy link
Contributor

So this was issue in oVirt reported here, fix will be part of 4.2.7 release:

https://bugzilla.redhat.com/show_bug.cgi?id=1593239

But also in Ansible fixed here, fix will be part of 2.7.1:

#47348

ansibot pushed a commit that referenced this issue Oct 19, 2018
Fixes: #45900

This PR fixes the case when the cloud_init_persist was used, but we
still sent use_cloud_init=False, which is in oVirt API evaluated as not
to use cloud_init in first VM execution. This patch is changing it to
send just None, instead of False.

Signed-off-by: Ondra Machacek <omachace@redhat.com>
machacekondra added a commit to machacekondra/ansible that referenced this issue Oct 23, 2018
Fixes: ansible#45900

This PR fixes the case when the cloud_init_persist was used, but we
still sent use_cloud_init=False, which is in oVirt API evaluated as not
to use cloud_init in first VM execution. This patch is changing it to
send just None, instead of False.

Signed-off-by: Ondra Machacek <omachace@redhat.com>
abadger pushed a commit that referenced this issue Oct 23, 2018
Fixes: #45900

This PR fixes the case when the cloud_init_persist was used, but we
still sent use_cloud_init=False, which is in oVirt API evaluated as not
to use cloud_init in first VM execution. This patch is changing it to
send just None, instead of False.

Signed-off-by: Ondra Machacek <omachace@redhat.com>
@bverschueren
Copy link
Contributor

This issue seems not to be solved with #47348; use_cloud_init is still sent as False if cloud_init_persist is set to True.

The negation seems to be the culprit here.
Unless I'm missing something else, following fixes it:

use_cloud_init=True if not module.params.get('cloud_init_persist') and module.params.get('cloud_init') is not None else None,

to

use_cloud_init=True if module.params.get('cloud_init_persist') and module.params.get('cloud_init') is not None else None,

Tomorrow9 pushed a commit to Tomorrow9/ansible that referenced this issue Dec 4, 2018
Fixes: ansible#45900

This PR fixes the case when the cloud_init_persist was used, but we
still sent use_cloud_init=False, which is in oVirt API evaluated as not
to use cloud_init in first VM execution. This patch is changing it to
send just None, instead of False.

Signed-off-by: Ondra Machacek <omachace@redhat.com>
@dagwieers dagwieers added ovirt oVirt and RHV community and removed virt Virt community (incl. QEMU, KVM, libvirt, ovirt, RHV and Proxmox) labels Feb 28, 2019
@ansible ansible locked and limited conversation to collaborators Jul 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
affects_2.6 This issue/PR affects Ansible v2.6 bug This issue/PR relates to a bug. cloud module This issue/PR relates to a module. ovirt oVirt and RHV community support:community This issue/PR relates to code supported by the Ansible community.
Projects
None yet
7 participants