* Added 'quota_id','sso', 'boot_menu', 'usb_support', 'serial_console' fields to ovirt_vms module
* always run ansible-test first
* always run ansible-test first 2
* suggested changes applied
* Add additional properties to storage domains
* add warn low space for additional storage properties
* Fixing comments
1. Fixing documentation
2. Use default None
3. Remove redundant if condition
4. remove added discard since it was already added
* Apply comments #2
Fix default value to None
Use percentages instead of GB
* Add VnicProfileMapping to register VM
Add vnic profile mappings to be supported in vm registration
* Add VnicProfileMapping to register template
Add vnic profile mappings to be supported in template registration
* Add reassign bad macs to register VM
Add reassign bad macs to be supported in vm registration.
* Add additional mappings params for VM registration
As part of the effort to support DR with oVirt
the "Register" operation is being added with a new mapping parameter
that describes the configuration of the registration.
The idea of supporting DR site to site in oVirt is to have 2 active
setups using storage replication between the primary setup and the
secondary setup.
Both setups will have active DCs, clusters, and hosts, although those
will not be identical.
The user can define a mapping which will be used to recover its setup.
Each mapping can be used to map any VM's attribute stored in the OVF
with its correlated entity.
For example, there could be a primary setup with a VM configured on cluster A.
We also keep an active secondary setup which only have cluster B.
Cluster B is compatible for that VM and in case of a DR scenario theoretically
the storage domain can be imported to the secondary setup and the use can
register the VM to cluster B.
In that case, we can automate the recovery process by defining a cluster mapping,
so once the entity will be registered its OVF will indicate it belongs to
cluster A but the mapping which will be sent will indicate that cluster B should
be valid for every thing that is configured on cluster A.
The engine should do the switch, and register the VM to cluster B in the secondary site.
Cluster mapping is just one example.
The following list describes the different mappings which were
introduced:
LUN mapping
Role mapping
Permissions mapping
Affinity group mapping
Affinity label mapping
Each mapping will be used for its specific OVF's data once the register operation
will take place in the engine.
* Add additional mappings params for Template registration
As part of the effort to support DR with oVirt
the "Register" operation is being added with a new mapping parameter
that describes the configuration of the registration.
The idea of supporting DR site to site in oVirt is to have 2 active
setups using storage replication between the primary setup and the
secondary setup.
Both setups will have active DCs, clusters, and hosts, although those
will not be identical.
The user can define a mapping which will be used to recover its setup.
Each mapping can be used to map any Template's attribute stored in the OVF
with its correlated entity.
For example, there could be a primary setup with a Template configured on cluster A.
We also keep an active secondary setup which only have cluster B.
Cluster B is compatible for that Template and in case of a DR scenario theoretically
the storage domain can be imported to the secondary setup and the use can
register the Template to cluster B.
In that case, we can automate the recovery process by defining a cluster mapping,
so once the entity will be registered its OVF will indicate it belongs to
cluster A but the mapping which will be sent will indicate that cluster B should
be valid for every thing that is configured on cluster A.
The engine should do the switch, and register the Template to cluster B in the
secondary site.
Cluster mapping is just one example.
The following list describes the different mappings which were
introduced:
Role mapping
Permissions mapping
Each mapping will be used for its specific OVF's data once the register operation
will take place in the engine.
* Add support for update OVF store
Add support for task of update OVF store in a storage domain.
oVirt modules support environment variables to be passed as
authentication details for connection. But ovirt_auth doesn't support
it. This patch add support for it.
* Use latest available template
Documentation states:
template_version: version number of the template to be used for VM. By default the latest available version of the template is used.
This was not true because if parameter was not specified, template[0] is choosen, without checking if is the latest. Now, sorting + selecting the latest selects the one with the latest version number.
* Sort in reverse order, style cleanup
Applied fixes from comment
Make sure that example in docs is usable:
# Remove storage domain
- ovirt_storage_domains:
state: absent
name: mystorage_domain
format: true
Without this PR data_center and host parameters where required when we wanted to
remove some storage domain.
Also fixes a regression when trying to remove a detached
storage domain.
The following patch fixes a regression when trying to remove a detached
storage domain.
As part of the remove process the ovirt_storage_domains module first
tries to move the domain to maintenance and detach it.
In case of removing a detached storage domain with no DC attached to it
The maintenace process will fail with 404 (not exists) exception when
trying to fetch the DC using empty Guid.
The fix proposes a solution to return None value in case of a detached
storage domain.
As part of the absent state of ovirt_storage_domains module,
the pre_remove method tries to move the stoage domain to
maintenance and detach it.
In case a destroy of a storage domain is being called there is no need
for those operations since the destroy might be merely a DB operation.
The ansible action ovirt_storage_domains obligates a data center
name of the attached storage domain as part of its action's arguments,
so it will get the attached_sd_service as part of the functionality
of changing the storage domain status (to maintenance for example).
On the other hand, ovirt_storage_domains_facts retrieves a storage
domain entity with information about the data center which the storage
domain is attached to as a UUID identifier (without name).
So for the user to use that storage domain, fetched from the facts
module, one will have to fetch the DC entity to get the name.
We could use the search which is used today using:
service.list(search=...)
but that type of search does not support search by Guid.
Therefor this patch provides the ability to use ovirt_storage_domains
action with state change using also a DC UUID instead of a DC name.
* ovirt_disks: added option to export disk to glance
* ovirt_disks: Moving exporting to separate branch
* ovirt_disks: removed redundant line obtaining disk obj
* ovirt_templates: Update the argument spec of templates.
Add id of template since it is needed for register.
* ovirt_vms: Register unregistered VM.
Use register of VM with id instead of name since an
unregitered entity can be registered also without name attribute.
* ovirt_hosts: Add iscsidiscover to ovirt_hosts
Adding functionality of iscsidiscover to be used to discover iscsi
targets.
* ovirt_storage_domains: Add support for import block storage domain.
* Add functionality of partial import to unregistered VMs.
* Add functionality of partial import to unregistered Templates.
* ovirt_hosts: Add iscsilogin to ovirt hosts.
Add functionality of iscsi login to ovirt hosts to be used to connect to
iscsi targets and to be able to import iSCSI storage domain eventually.
* Add ovirt_storage_templates_facts
Adding fact module for storage templates.
The module should help with registering unregistered templates.
* Add ovirt_storage_vms_facts
Adding fact module for storage VMs.
The module should help with registering unregistered VMs.
* Fix 'the the' typos, fix 'pahting' filename typo
* Change 'the the' typos to a single 'the'.
* Change `playbook_pahting.rst` to `playbook_pathing.rst`.
* Delete trailing space in ec2_vol example
Delete the trailing space in `instance: "{{ item.id }} "`, which makes the
example fail when run because it looks for instance "i-xxxx ".
* First batch of modules renamed from plural to singular
Related to this proposal: https://github.com/ansible/proposals/issues/10
* Emit rename deprication warning
* Update legacy-files.txt and skip.txt to reflect new names
* ovirt_templates: added option to name imported disk as a template
* ovirt_templates: added version_added to new attribute
* ovirt_templates: added alias for image_name and example
* added alias glance_image_disk_name for image_name
* example how to import image from glance as template
* improve description of template_image_disk_name
Added 'ovirt_host_storage_facts' module to retrieve
a list of HostStorage[1] objects by a specified iscsi
target and address.
E.g.
- ovirt_host_storage_facts:
vm: myhost
iscsi:
target: iqn.2016-08-09.domain-01:nickname
address: 10.34.63.204
[1] http://ovirt.github.io/ovirt-engine-api-model/master/#types/host_storage
ISSUE TYPE
* Feature Pull Request
COMPONENT NAME
* lib/ansible/modules/cloud/ovirt/ovirt_host_storage_facts.py
@machacekondra
@mureinik @maorlipchuk
When creatinf a new VM from template, you can specify the storage domain
name and disk format where to copy all the template disks
For example if you want to create a VM from template into specific
storage domain you can do the following:
ovirt_vms:
name: vm_on_my_storage_domain
cluster: my_cluster
template: my_template
operating_system: other_linux
type: server
cpu_cores: 1
cpu_sockets: 1
state: stopped
clone: True
storage_domain: my_nfs_storage
format: COW
before this change adding nic was allowed only to a vm. Now it is
possible to add it to template.
example:
- name: test add nic to template
ovirt_nics:
auth: "{{ ovirt_auth }}"
state: present
template: mytemplate
name: nic1
interface: virtio
profile: ovirtmgmt
network: ovirtmgmt
Changes to the metadata format were approved here:
https://github.com/ansible/proposals/issues/54
* Update documentation to the new metadata format
* Changes to metadata-tool to account for new metadata
* Add GPL license header
* Add upgrade subcommand to upgrade metadata version
* Change default metadata to the new format
* Fix exclusion of non-modules from the metadata report
* Fix ansible-doc for new module metadata
* Exclude metadata version from ansible-doc output
* Fix website docs generation for the new metadata
* Update metadata schema in valiate-modules test
* Update the metadata in all modules to the new version
* fix module doc fields
* More module docs corrections
* More module docs corrections
* More module docs corrections
* More module docs corrections
* correct aliases
* Review comments
* Must quote ':'
* More authors
* Use suboptions:
* restore type: bool
* type should be in the same place
* More tidyups
* authors
* Use suboptions
* revert
* remove duplicate author
* More issues post rebase
This patch enhances waiting operation of stateless VM to be down.
Because stateless VM creates a snapshot and removes it after the
VM is shutdown, we must wait until the VM is really prepared to
start again.
* cloud: ovirt: add snapshots module
* Move imports in ovirt_snapshots module to match style & pass CI
* Move ovirt_snapshot_facts imports to comply w/ CI
* Update validate-modules
* Validates ANSIBLE_METADATA
* Ensures imports happen after documentation vars
* Some pep8 cleanup
* Clean up some left over unneeded code
* Update modules for new module guidelines and validate-modules checks
* Update imports for ec2_vpc_route_table and ec2_vpc_nat_gateway
* cloud: ovirt: add function to get id by name
* cloud: ovirt: add instance type parameter
* cloud: ovirt: use param method instead of module.params
* cloud: ovirt: use 'and' at begging of next line
* cloud: ovirt: add description parameter to vms module
* cloud: ovirt: add comment parameter to vms module
* cloud: ovirt: add timezone parameter to vms module
* cloud: ovirt: add serial_policy parameter to vms module
This patch add additional filtering of VNIC profiles by the cluster
parameter. It is a must, because there could be same names of the
VNIC profiles in system, as every datacenter can have VNIC profile
same name, which can be in other datacenter.
This patch fixes issue #20246