This change is related to 2 issues;
- The API does not return destroyed VMs if zone ID is passed for CS version < 4.5.2. Also see CLOUDSTACK-8578. This only affects domain and root admins.
- The instance name must be unique across all zones. If we pass the zone ID to find a VM, it will not be found if it is in a different zone but a deployment with the name would fail.
Due to a software bug in vSphere, it fails to handle ampersand in datacenter names.
The solution is to do what vSphere does (when browsing) and double-encode ampersands.
It is likely other characters need special treatment like this as well, haven't found any.
This fixes::
Traceback (most recent call last):
File "/home/jpic/.ansible/tmp/ansible-tmp-1435080800.61-38257321141340/lxc_container", line 3353, in <module>
main()
File "/home/jpic/.ansible/tmp/ansible-tmp-1435080800.61-38257321141340/lxc_container", line 1712, in main
if not HAS_LXC:
NameError: global name 'HAS_LXC' is not defined
This fixes::
Traceback (most recent call last):
File "/home/jpic/.ansible/tmp/ansible-tmp-1435080916.98-133068627776311/lxc_container", line 3355, in <module>
main()
File "/home/jpic/.ansible/tmp/ansible-tmp-1435080916.98-133068627776311/lxc_container", line 1724, in main
lxc_manage.run()
File "/home/jpic/.ansible/tmp/ansible-tmp-1435080916.98-133068627776311/lxc_container", line 1605, in run
action()
File "/home/jpic/.ansible/tmp/ansible-tmp-1435080916.98-133068627776311/lxc_container", line 1145, in _started
self._config()
File "/home/jpic/.ansible/tmp/ansible-tmp-1435080916.98-133068627776311/lxc_container", line 714, in _config
_, _value = option_line.split('=')
ValueError: too many values to unpack
With such a task::
tasks:
- lxc_container:
name: buildbot-master
container_config:
- "lxc.mount.entry = {{ cwd }} srv/peopletest none defaults,bind,uid=0,create=dir 0 0"
The `--noreplace` argument to `emerge` is generally coupled with
`--newuse` or `--changed-use`, and can be used instruct Portage to
rebuild a package only if necessary. Simply checking to see if the
package is already installed using `equery` is not sufficient to
determine if any changes would be made, so that step is skipped when
the `noreplace` module argument is specified. The module then falls back
to parsing the output from `emerge` to determine if anything changed. In
check mode, `emerge` is called with `--pretend`, so it produces
different output, and the parsing fails to correctly infer that a change
would be made.
This commit adds another regular expression to check when running in
check mode that matches the pretend output from `emerge`.
Signed-off-by: Dustin C. Hatch <dustin@hatch.name>
When running in check mode, the *portage* module always reports that no
changes were made, even if the requested packages do not exist on the
system. This is because it was erroneously expecting `emerge --pretend`
to produce the same output as `emerge` by itself would, and attempts to
parse it. This is not correct, for several reasons. Most specifically,
the string for which it is searching does not exist in the pretend
output. Additionally, `emerge --pretend` always prints the requested
packages, whether they are already installed or not; in the former case,
it shows them as reinstalls.
This commit adjusts the behavior to rely on `equery` alone when running
in check mode. If `equery` reports at least one package is not
installed, then nothing else is done: the system will definitely be
changed.
Signed-off-by: Dustin C. Hatch <dustin@hatch.name>
Due to a spurious newline we corrupted the payload. It depends on the order of the headers and if there were headers added by vSphere.
The Accept header was also not needed.
Starting point for a reference when doing pull request reviews.
If something doesn't meet the guidelines we can point people
at them. If something is bad but is not mentioned in the
guidelines, we should add it here.
The lxc container restart state does not ensure that the container
is in fact started unless another config or command is passed into
the task. to fix this the module simply needs to have the function
call added ``self._container_startup()`` after the container is
put into a stopped state.
Signed-off By: Kevin Carter <kevin.carter@rackspace.com>
* Refactor code to be more robust. Run main logic inside a try {} catch {}
block. If there is any error, bail out and log all the command output
automatically.
* Rely on error code generated by chocolatey instead of scraping text
output to determine success/failure.
* Add support for unattended installs: (`-y` flag is a requirement by
chocolatey)
* Before (un)installing, check existence of files.
* Use functions to abstract logic
* The great rewrite of 0.9.9, the `choco` interface has changed, check
if chocolatey is installed and an older version. If so upgrade to
latest.
* Allow upgrading packages that are already installed
* Use verbose logging for chocolate actions
* Adding functionality to specify a source for a chocolatey repository.
(@smadam813)
* Removing pre-determined sources and adding specified source url in
it's place. (@smadam813)
Contains contributions from:
* Adam Keech <akeech@chathamfinancial.com> (@smadam813)
The python2-lxc library has been uploaded to pypi as such this commit
updates the requirements and doc information for the module such that
it instructs the user to install the pip package "lxc-python2" while
also noting that the package could be gotten from source as well. In
the update comments have been added to the requirements list which
notes where the package should come from,
Closes-Bug: https://github.com/ansible/ansible-modules-extras/issues/550
puppetmaster was used to determine if `agent` or `apply` should be used. But puppetmaster is not required by puppet per default. Puppet may have a config or could find out by itself (...) where the puppet master is.
It changed the code so we only use `apply` if a manifest was passed, otherwise we use `agent`.
This also fixes the example, which did not work the way without this change.
~~~
# Run puppet agent and fail if anything goes wrong
- puppet
~~~
puppet may be configured to operate in `--noop` mode per default.
That is why we must pass a `--no-noop` to make sure, changes are going to be applied.
There is a growing pattern for using ansible to orchestrate runs of
existing puppet code. For instance, the OpenStack Infrastructure team
started using ansible for this very reason. It also turns out that
successfully running puppet and interpreting success or failure is
harder than you'd expect, thus warranting a module and not just a shell
command.
This is ported in from
http://git.openstack.org/cgit/openstack-infra/ansible-puppet
