cloudscale-ch/ansible-collection-cloudscale

cloudscale.ch Ansible Collection

ansible-collection-cloudscale's Issues

floating_ip: idempotency not given

idempotency currently not given due to API does not have a description or name field which could be used to identify the resource.

We evaluate a way to provide idempotency by using a custom tag as a name. Per definition, a new required field would be a breaking change and therefore available in the next major release.

cloudscale_ch.cloud.server does not work with ansible 6.0

Hi all

There seems to be an Issue with the cloudscale_ch.cloud.server module when using ansible 6.0. The module fails with the following error:
msg: dictionary requested, could not parse JSON or key=value

Steps to reproduce:

• update ansible to 6.0
• invoke cloudscale_ch.cloud.server module

Sanity tests failing in cloudscale_ch.cloud

SUMMARY

We are running sanity tests across every collection included in the Ansible community package (as part of this issue) and found that ansible-test sanity --docker against cloudscale_ch.cloud 2.2.1 fails with ansible-core 2.13.0rc1 in ansible 6.0.0a2.

ISSUE TYPE

• Bug Report

COMPONENT NAME

n/a

ANSIBLE VERSION

ansible [core 2.13.0rc1]

COLLECTION VERSION

2.2.1

STEPS TO REPRODUCE

ansible-test sanity --docker

EXPECTED RESULTS

Tests are either passing or ignored.

ACTUAL RESULTS

ERROR: Found 1 validate-modules issue(s) which need to be resolved:
ERROR: plugins/inventory/inventory.py:0:0: invalid-documentation: DOCUMENTATION.plugin_type: extra keys not allowed @ data['plugin_type']. Got 'inventory'
ERROR: The 1 sanity test(s) listed below (out of 43) failed. See error output above for details.
validate-modules
ERROR: Command "podman exec ansible-test-controller-C24clIj5 /usr/bin/env ANSIBLE_TEST_CONTENT_ROOT=/root/ansible_collections/cloudscale_ch/cloud LC_ALL=en_US.UTF-8 /usr/bin/python3.10 /root/ansible/bin/ansible-test sanity --containers '{}' --skip-test pylint --metadata tests/output/.tmp/metadata-og9ot2ka.json --truncate 0 --color no --host-path tests/output/.tmp/host-rrgtk4l2" returned exit status 1.

Inclusion of cloudscale_ch.cloud in Ansible 2.10

This collection will be included in Ansible 2.10 because it contains modules and/or plugins that were included in Ansible 2.9. Please review:

• The list of requirements for inclusion in Ansible: https://github.com/ansible-collections/overview/blob/master/collection_requirements.rst
• The roadmap with all important dates for Ansible 2.10: https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/roadmap/COLLECTIONS_2_10.rst

DEADLINE: 2020-08-18

The latest version of the collection available on August 18 will be included in Ansible 2.10.0, except possibly newer versions which differ only in the patch level. (For details, see the roadmap). Please release version 1.0.0 of your collection by this date! If 1.0.0 does not exist, the same 0.x.y version will be used in all of Ansible 2.10 without updates, and your 1.x.y release will not be included until Ansible 2.11 (unless you request an exception at a community working group meeting and go through a demanding manual process to vouch for backwards compatibility . . . you want to avoid this!).

Follow semantic versioning rules

Your collection versioning must follow all semver rules. This means:

• Patch level releases can only contain bugfixes;
• Minor releases can contain new features, new modules and plugins, and bugfixes, but must not break backwards compatibility;
• Major releases can break backwards compatibility.

Changelogs and Porting Guide

Your collection should provide data for the Ansible 2.10 changelog and porting guide. The changelog and porting guide are automatically generated from ansible-base, and from the changelogs of the included collections. All changes from the breaking_changes, major_changes, removed_features and deprecated_features sections will appear in both the changelog and the porting guide. You have two options for providing changelog fragments to include:

1. If possible, use the antsibull-changelog tool, which uses the same changelog fragment as the ansible/ansible repository (see the documentation).
2. If you cannot use antsibull-changelog, you can provide the changelog in a machine-readable format as changelogs/changelog.yaml inside your collection (see the documentation of changelogs/changelog.yaml format).

If you cannot contribute to the integrated Ansible changelog using one of these methods, please provide a link to your collection's changelog by creating an issue in https://github.com/ansible-community/ansible-build-data/. If you do not provide changelogs/changelog.yml or a link, users will not be able to find out what changed in your collection from the Ansible changelog and porting guide.

Make sure your collection passes the sanity tests

Run ansible-test sanity --docker -v in the collection with the latest ansible-base or stable-2.10 ansible/ansible checkout.

Keep informed

Be sure you're subscribed to:

• Changes impacting Collections to track changes that Collection maintainers should be aware of;
• The Bullhorn, a newsletter for the Ansible developer community, back issues and how to add content.

Questions and Feedback

If you have questions or want to provide feedback, please see the Feedback section in the collection requirements.

(Internal link to keep track of issues: ansible-collections/overview#102)

Cloudscale volume module still using server_uuids

While debugging an issue with our cloudscale volumes I've noticed that the module still makes use of server_uuids despite the api documentation mentioning it being deprecated and recommending the use of servers instead. Could this be an issue?

See:

• https://github.com/cloudscale-ch/ansible-collection-cloudscale/blob/master/plugins/modules/volume.py#L207
• https://www.cloudscale.ch/en/api/v1#volumes

Final Changes for Ansible 3.0 before 27.01.

Hi @cloudscale-ch

Please make the final changes for breaking the backwards compatibility. I'll create a the new major release (and document the steps)

inventory issue: ERROR! Unexpected Exception, this is probably a bug: cannot import name 'API_URL' from 'ansible_collections.cloudscale_ch.cloud.plugins.module_utils.api'

Output of ansible-inventory --list -i inventory-dynamic-cloudscale.yml -vvv

ansible-inventory 2.10.4
  config file = /home/my-user/git/ansible/ansible.cfg
  configured module search path = ['/home/my-user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  executable location = /usr/bin/ansible-inventory
  python version = 3.9.1 (default, Dec 13 2020, 11:55:53) [GCC 10.2.0]
Using /home/my-user/git/ansible/ansible.cfg as config file
ERROR! Unexpected Exception, this is probably a bug: cannot import name 'API_URL' from 'ansible_collections.cloudscale_ch.cloud.plugins.module_utils.api' (/home/my-user/git/ansible/collections/ansible_collections/cloudscale_ch/cloud/plugins/module_utils/api.py)
the full traceback was:

Traceback (most recent call last):
  File "/usr/bin/ansible-inventory", line 123, in <module>
    exit_code = cli.run()
  File "/usr/lib/python3.9/site-packages/ansible/cli/inventory.py", line 128, in run
    self.loader, self.inventory, self.vm = self._play_prereqs()
  File "/usr/lib/python3.9/site-packages/ansible/cli/__init__.py", line 467, in _play_prereqs
    inventory = InventoryManager(loader=loader, sources=options['inventory'])
  File "/usr/lib/python3.9/site-packages/ansible/inventory/manager.py", line 166, in __init__
    self.parse_sources(cache=True)
  File "/usr/lib/python3.9/site-packages/ansible/inventory/manager.py", line 224, in parse_sources
    parse = self.parse_source(source, cache=cache)
  File "/usr/lib/python3.9/site-packages/ansible/inventory/manager.py", line 275, in parse_source
    for plugin in self._fetch_inventory_plugins():
  File "/usr/lib/python3.9/site-packages/ansible/inventory/manager.py", line 203, in _fetch_inventory_plugins
    plugin = inventory_loader.get(name)
  File "/usr/lib/python3.9/site-packages/ansible/plugins/loader.py", line 780, in get
    return self.get_with_context(name, *args, **kwargs).object
  File "/usr/lib/python3.9/site-packages/ansible/plugins/loader.py", line 800, in get_with_context
    self._module_cache[path] = self._load_module_source(name, path)
  File "/usr/lib/python3.9/site-packages/ansible/plugins/loader.py", line 764, in _load_module_source
    spec.loader.exec_module(module)
  File "<frozen importlib._bootstrap_external>", line 790, in exec_module
  File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
  File "/home/my-user/git/ansible/collections/ansible_collections/cloudscale_ch/cloud/plugins/inventory/inventory.py", line 82, in <module>
    from ..module_utils.api import API_URL
ImportError: cannot import name 'API_URL' from 'ansible_collections.cloudscale_ch.cloud.plugins.module_utils.api' (/home/my-user/git/ansible/collections/ansible_collections/cloudscale_ch/cloud/plugins/module_utils/api.py)

Inventory inventory-dynamic-cloudscale.yml:

plugin: cloudscale_ch.cloud.inventory
api_token: ENTER_API_TOKEN_HERE
keyed_groups:
  - prefix: os
    key: cloudscale.image.operating_system | lower

(Based on https://docs.ansible.com/ansible/2.10/collections/cloudscale_ch/cloud/inventory_inventory.html#examples)

Inventory config from ansible.cfg

[inventory]
enable_plugins = ini, cloudscale_ch.cloud.inventory

Installed configuring requirements.txt and executing ansible-galaxy collection install -r requirements.yml -p collections

collections:
  - name: cloudscale_ch.cloud
    version: 1.3.0

It works for me with the following changes:

• Remove from ..module_utils.api import API_URL from plugins/inventory/inventory.py#L82
• Replace API_URL + '/servers', with self.get_option('api_url') + '/servers', in plugins/inventory/inventory.py#L99

Is there something wrong with my setup or is this a bug?

Integration test failure custom image import status

See https://github.com/cloudscale-ch/ansible-collection-cloudscale/runs/2799967668?check_suite_focus=true#step:8:576

TASK [custom_image : Wait for import of first image] ***************************
fatal: [testhost]: FAILED! => {"msg": "The conditional check 'import_status.import_status == 'failed'' failed. The error was: error while evaluating conditional (import_status.import_status == 'failed'): 'dict object' has no attribute 'import_status'"}

floating_ip: check mode is unsupported

The module claims to have check mode support but actually it has not.

Allow adding additional volumes during server creation

We would like to be able to add several disks to a newly created server right at the start, similar to how it is possible with the API.

If I read it correctly the ansible module currently supports adding an additional bulk volume via the bulk_volume_size_gb param.

However adding 2+ bulk volumes or any additional ssd volume besides the root volume is not possible.

Our current workaround is to add the desired disks right after the server creation with the volume module, but we are looking to simplify the setup. Because of the well established workaround this is not a high priority issue for us.

Module for managing subnets

CI integration missing secret

CI integration needs a secret to run

name:
CONFIG_FILE

value:

[default]
cloudscale_api_token = <api_token>

Allow name, uuid or object as argument for parameters

Some users might want to use fixed names for their resources in their playbooks:

    - name: Create volume
      cloudscale_ch.cloud.volume:
        name: 'my_ssd_volume'
        ...

    - name: Start a server
      cloudscale_ch.cloud.server:
        name: 'my_server'
        ...

    - name: Attach volume to server
      cloudscale_ch.cloud.volume:
        name: 'my_ssd_volume'
        servers:
          - 'my_server'

Other users don't want to dig into the structure of return values to pass a uuid to another task:

    - name: Create volume
      cloudscale_ch.cloud.volume:
        name: my_ssd_volume
        ...
      register: volume

    - name: Start a server
      cloudscale_ch.cloud.server:
        name: my_server
        ...
      register: server

    - name: Attach volume to server
      cloudscale_ch.cloud.volume:
        name: "{{ volume }}"
        servers:
          - "{{ server }}"

Create a function that can compare uuid, name or an object with a given object.

Spot all parameters that take only name, uuid or an object and make it possible to use any.

Consider using true/false for all booleans in docs

Based on the community decision to use true/false for boolean values in documentation and examples, we ask that you evaluate booleans in this collection and consider changing any that do not use true/false (lowercase).

See documentation block format for more info (specifically, option defaults).

If you have already implemented this or decide not to, feel free to close this issue.

---

P.S. This is auto-generated issue, please raise any concerns here

Create a module to manage objects users

API: https://www.cloudscale.ch/en/api/v1#objects-users

Important information for collection maintainers

SUMMARY

Dear maintainers,

This is important for your collections!

• In accordance with the Community decision, we have created the news-for-maintainers repository for announcements of changes impacting collection maintainers (see the examples) instead of Issue 45 that will be closed soon.

  • To keep yourself well-informed and, therefore, things in your collection working, please subscribe to the repository by using the Watch button in the upper right corner on the repository's home page.
  • If you do not want to get notifications about related discussions, please subscribe only to Issues.
  • Please read the brief guidelines on how the repository should be used.
  • Please avoid unnecessary discussions in issues, use the Discussions feature. Every comment posted will notify a lot of folks!

• Also we would like to remind you about the Bullhorn contributor newsletter which has recently started to be released weekly. To learn what it looks like, see the past releases. Please subscribe and talk to the Community via Bullhorn!

• Join us in #ansible-social (for news reporting & chat), #ansible-community (for discussing collection & maintainer topics), and other channels on Matrix/IRC.

• Help the Community and the Steering Committee to make right decisions by taking part in discussing and voting on the Community Topics that impact the whole project and the collections in particular. Your opinion there will be much appreciated!

Thank you!