Update docs for main

main/_sources/CHANGELOG.rst.txt

@@ -0,0 +1,9 @@
+=============================================
+KubeVirt Collection for Ansible Release Notes
+=============================================
+
+.. contents:: Topics
+
+
+v0.1.0
+======

main/_sources/CONTRIBUTING.md.txt

@@ -0,0 +1,3 @@
+# Contributing
+
+Refer to the [KubeVirt Contributing guidelines](https://github.com/kubevirt/kubevirt/blob/main/CONTRIBUTING.md).

main/_sources/README.md.txt

@@ -0,0 +1,141 @@
+# Lean Ansible bindings for KubeVirt
+<!-- Add CI and code coverage badges here. Samples included below. -->
+[![CI](https://github.com/kubevirt/kubevirt.core/workflows/CI/badge.svg?event=push)](https://github.com/kubevirt/kubevirt.core/actions)
+
+<!-- Describe the collection and why a user would want to use it. What does the collection do? -->
+This repo hosts the kubevirt.core Ansible Collection.
+
+The collection includes an inventory plugin for Ansible to automate the management of VMs running on KubeVirt.
+
+## Code of Conduct
+
+We follow the [Ansible Code of Conduct](https://docs.ansible.com/ansible/devel/community/code_of_conduct.html) in all our interactions within this project.
+
+If you encounter abusive behavior, please refer to the [policy violations](https://docs.ansible.com/ansible/devel/community/code_of_conduct.html#policy-violations) section of the Code for information on how to raise a complaint.
+
+## Communication
+
+<!--List available communication channels. In addition to channels specific to your collection, we also recommend to use the following ones.-->
+
+We announce releases and important changes through Ansible's [The Bullhorn newsletter](https://github.com/ansible/community/wiki/News#the-bullhorn). Be sure you are [subscribed](https://eepurl.com/gZmiEP).
+
+Join us in the `#ansible` (general use questions and support), `#ansible-community` (community and collection development questions), and other [IRC channels](https://docs.ansible.com/ansible/devel/community/communication.html#irc-channels).
+
+We take part in the global quarterly [Ansible Contributor Summit](https://github.com/ansible/community/wiki/Contributor-Summit) virtually or in-person. Track [The Bullhorn newsletter](https://eepurl.com/gZmiEP) and join us.
+
+For more information about communication, refer to the [Ansible Communication guide](https://docs.ansible.com/ansible/devel/community/communication.html).
+
+## Contributing to this collection
+
+<!--Describe how the community can contribute to your collection. At a minimum, fill up and include the CONTRIBUTING.md file containing how and where users can create issues to report problems or request features for this collection. List contribution requirements, including preferred workflows and necessary testing, so you can benefit from community PRs. If you are following general Ansible contributor guidelines, you can link to - [Ansible Community Guide](https://docs.ansible.com/ansible/devel/community/index.html). List the current maintainers (contributors with write or higher access to the repository). The following can be included:-->
+
+The content of this collection is made by people like you, a community of individuals collaborating on making the world better through developing automation software.
+
+We are actively accepting new contributors.
+
+Any kind of contribution is very welcome.
+
+You don't know how to start? Refer to our [contribution guide](CONTRIBUTING.md)!
+
+We use the following guidelines:
+
+* [CONTRIBUTING.md](CONTRIBUTING.md)
+* [REVIEW_CHECKLIST.md](REVIEW_CHECKLIST.md)
+* [Ansible Community Guide](https://docs.ansible.com/ansible/latest/community/index.html)
+* [Ansible Development Guide](https://docs.ansible.com/ansible/devel/dev_guide/index.html)
+* [Ansible Collection Development Guide](https://docs.ansible.com/ansible/devel/dev_guide/developing_collections.html#contributing-to-collections)
+
+## Collection maintenance
+
+The current maintainers are listed in the [MAINTAINERS](MAINTAINERS) file. If you have questions or need help, feel free to mention them in the proposals.
+
+To learn how to maintain / become a maintainer of this collection, refer to the [Maintainer guidelines](MAINTAINING.md).
+
+## Governance
+
+<!--Describe how the collection is governed. Here can be the following text:-->
+
+The process of decision making in this collection is based on discussing and finding consensus among participants.
+
+Every voice is important. If you have something on your mind, create an issue or dedicated discussion and let's discuss it!
+
+## Tested with Ansible
+
+<!-- List the versions of Ansible the collection has been tested with. Must match what is in galaxy.yml. -->
+
+## External requirements
+
+<!-- List any external resources the collection depends on, for example minimum versions of an OS, libraries, or utilities. Do not list other Ansible collections here. -->
+- python >= 3.6
+
+Python libraries:
+- kubernetes
+- PyYaml
+- jsonpatch
+- jinja2
+
+### Supported connections
+<!-- Optional. If your collection supports only specific connection types (such as HTTPAPI, netconf, or others), list them here. -->
+
+## Included content
+
+<!-- Galaxy will eventually list the module docs within the UI, but until that is ready, you may need to either describe your plugins etc here, or point to an external docsite to cover that information. -->
+
+## Using this collection
+
+<!--Include some quick examples that cover the most common use cases for your collection content. It can include the following examples of installation and upgrade (change NAMESPACE.COLLECTION_NAME correspondingly):-->
+
+### Installing the Collection from Ansible Galaxy
+
+Before using this collection, you need to install it with the Ansible Galaxy command-line tool:
+```bash
+ansible-galaxy collection install kubevirt.core
+```
+
+You can also include it in a `requirements.yml` file and install it with `ansible-galaxy collection install -r requirements.yml`, using the format:
+```yaml
+---
+collections:
+  - name: kubevirt.core
+```
+
+Note that if you install the collection from Ansible Galaxy, it will not be upgraded automatically when you upgrade the `ansible` package. To upgrade the collection to the latest available version, run the following command:
+```bash
+ansible-galaxy collection install kubevirt.core --upgrade
+```
+
+You can also install a specific version of the collection, for example, if you need to downgrade when something is broken in the latest version (please report an issue in this repository). Use the following syntax to install version `0.1.0`:
+
+```bash
+ansible-galaxy collection install kubevirt.core:==0.1.0
+```
+
+See [Ansible Using collections](https://docs.ansible.com/ansible/devel/user_guide/collections_using.html) for more details.
+
+## Release notes
+
+See the [changelog](https://github.com/ansible-collections/REPONAMEHERE/tree/main/CHANGELOG.rst).
+
+## Roadmap
+
+<!-- Optional. Include the roadmap for this collection, and the proposed release/versioning strategy so users can anticipate the upgrade/update cycle. -->
+
+## More information
+
+<!-- List out where the user can find additional information, such as working group meeting times, slack/IRC channels, or documentation for the product this collection automates. At a minimum, link to: -->
+
+- [Ansible Collection overview](https://github.com/ansible-collections/overview)
+- [Ansible User guide](https://docs.ansible.com/ansible/devel/user_guide/index.html)
+- [Ansible Developer guide](https://docs.ansible.com/ansible/devel/dev_guide/index.html)
+- [Ansible Collections Checklist](https://github.com/ansible-collections/overview/blob/main/collection_requirements.rst)
+- [Ansible Community code of conduct](https://docs.ansible.com/ansible/devel/community/code_of_conduct.html)
+- [The Bullhorn (the Ansible Contributor newsletter)](https://us19.campaign-archive.com/home/?u=56d874e027110e35dea0e03c1&id=d6635f5420)
+- [News for Maintainers](https://github.com/ansible-collections/news-for-maintainers)
+
+## Licensing
+
+<!-- Include the appropriate license information here and a pointer to the full licensing details. If the collection contains modules migrated from the ansible/ansible repo, you must use the same license that existed in the ansible/ansible repo. See the GNU license example below. -->
+
+GNU General Public License v3.0 or later.
+
+See [LICENSE](./LICENSE) to see the full text.

main/_sources/developing.md.txt

@@ -0,0 +1,13 @@
+## Contributor's Guidelines
+
+- All YAML files named with `.yml` extension
+- Use spaces around jinja variables. `{{ var }}` over `{{var}}`
+- Variables that are internal to the role should be lowercase and start with the role name
+- Keep roles self contained - Roles should avoid including tasks from other roles when possible
+- Plays should do nothing more than include a list of roles except where `pre_tasks` and `post_tasks` are required when possible
+- Separators - Use valid name, ie. underscores (e.g. `my_role` `my_playbook`) not dashes (`my-role`)
+- Paths - When defining paths, do not include trailing slashes (e.g. `my_path: /foo` not `my_path: /foo/`). When concatenating paths, follow the same convention (e.g. `{{ my_path }}/bar` not `{{ my_path }}bar`)
+- Indentation - Use 2 spaces for each indent
+- `vars/` vs `defaults/` - internal or interpolated variables that don't need to change or be overridden by user go in `vars/`, those that a user would likely override, go under `defaults/` directory
+- All arguments have a specification in `meta/argument_specs.yml`
+- All playbooks/roles should be focused on compatibility with Ansible Automation Platform

main/_sources/index.rst.txt

@@ -0,0 +1,26 @@
+.. Red Hat kubevirt core Ansible Collection documentation main file
+
+Welcome to Kubevirt Collection documentation
+=======================================
+
+.. toctree::
+   :maxdepth: 2
+   :caption: User documentation
+
+   README
+   plugins/index
+   roles/index
+
+.. toctree::
+   :maxdepth: 2
+   :caption: Developer documentation
+
+   testing
+   developing
+   releasing
+
+.. toctree::
+   :maxdepth: 2
+   :caption: General
+
+   Changelog <CHANGELOG>

main/_sources/plugins/index.rst.txt

@@ -0,0 +1,15 @@
+Plugin Index
+============
+
+.. toctree::
+   :caption: inventory plugins
+   :maxdepth: 0
+
+   kubevirt
+
+.. toctree::
+   :caption: modules plugins
+   :maxdepth: 0
+
+   kubevirt_vm
+

main/_sources/releasing.md.txt

@@ -0,0 +1,61 @@
+# Collection Versioning Strategy
+
+Each supported collection maintained by Ansible follows Semantic Versioning 2.0.0 (https://semver.org/), for example:
+Given a version number MAJOR.MINOR.PATCH, the following is incremented:
+
+MAJOR version: when making incompatible API changes (see Feature Release scenarios below for examples)
+
+MINOR version: when adding features or functionality in a backwards compatible manner, or updating testing matrix and/or metadata (deprecation)
+
+PATCH version: when adding backwards compatible bug fixes or security fixes (strict).
+
+Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
+
+The first version of a generally available supported collection on Ansible Automation Hub shall be version 1.0.0. NOTE: By default, all newly created collections may begin with a smaller default version of 0.1.0, and therefore a version of 1.0.0 should be explicitly stated by the collection maintainer.
+
+## New content is added to an existing collection
+
+Assuming the current release is 1.0.0, and a new module is ready to be added to the collection, the minor version would be incremented to 1.1.0. The change in the MINOR version indicates an additive change was made while maintaining backward compatibility for existing content within the collection.
+
+
+## New feature to existing plugin or role within a collection (backwards compatible)
+
+Assuming the current release is 1.0.0, and new features for an existing module are ready for release . We would increment the MINOR version to 1.1.0. The change in the MINOR version indicates an additive change was made while maintaining backward compatibility for existing content within the collection.
+
+
+## Bug fix or security fix to existing content within a collection
+
+Assuming the current release is 1.0.0 and a bug is fixed prior to the next minor release, the PATCH version would be incremented to 1.0.1. The patch indicates only a bug was fixed within a current version. The PATCH release does not contain new content, nor was functionality removed. Bug fixes may be included in a MINOR or MAJOR feature release if the timing allows, eliminating the need for a PATCH dedicated to the fix.
+
+
+## Breaking change to any content within a collection
+
+Assuming the current release is 1.0.0, and a breaking change (API or module) is introduced for a user or developer. The MAJOR version would be incremented to 2.0.0.
+
+Examples of breaking changes within a collection may include but are not limited to:
+
+ - Argspec changes for a module that require either inventory structure or playbook changes.
+ - A change in the shape of either the inbound or returned payload of a filter plugin.
+ - Changes to a connection plugin that require additional inventory parameters or ansible.cfg entries.
+ - New functionality added to a module that changes the outcome of that module as released in previous versions.
+ - The removal of plugins from a collection.
+
+
+## Content removed from a collection
+
+Deleting a module or API is a breaking change. Please see the 'Breaking change' section for how to version this.
+
+
+## A typographical error was fixed in the documentation for a collection
+
+A correction to the README would be considered a bug fix and the PATCH incremented. See 'Bug fix' above.
+
+
+## Documentation added/removed/modified within a collection
+
+Only the PATCH version should be increased for a release that contains changes limited to revised documentation.
+
+
+## Release automation
+
+New releases are triggered by annotated git tags named after semantic versioning. The automation publishes the built artifacts to ansible-galaxy and github releases page.

main/_sources/roles/index.rst.txt

@@ -0,0 +1,5 @@
+Role Index
+==========
+
+.. toctree::
+    *

main/_sources/testing.md.txt

@@ -0,0 +1,35 @@
+# Testing
+
+## Continuous integration
+
+The collection is tested with a [molecule](https://github.com/ansible-community/molecule) setup covering the included roles and verifying correct installation and idempotency.
+In order to run the molecule tests locally with python 3.9 available, after cloning the repository:
+
+```
+pip install yamllint 'molecule[docker]~=3.5.2' ansible-core flake8 ansible-lint voluptuous
+molecule test --all
+```
+
+## Test playbooks
+
+Sample playbooks are provided in the `playbooks/` directory; to run the playbooks locally (requires a rhel system with python 3.9+, ansible, and systemd) the steps are as follows:
+
+```
+# setup environment
+pip install ansible-core
+# clone the repository
+git clone https://github.com/ansible-middleware/amq
+cd amq
+# install collection dependencies
+ansible-galaxy collection install -r requirements.yml
+# install collection python deps
+pip install -r requirements.txt
+# create inventory for localhost
+cat << EOF > inventory
+[amq]
+localhost ansible_connection=local
+EOF
+# run the playbook
+ansible-playbook -i inventory playbooks/activemq.yml
+```
+