mirror of
https://github.com/saltstack/salt.git
synced 2025-04-17 10:10:20 +00:00
Merge branch '2016.11' into issue43373
This commit is contained in:
Nicole Thomas
GitHub
commit
e580ed4caa
2 changed files with 265 additions and 195 deletions
|
|
@ -31,7 +31,7 @@ documentation for more information.
|
|||
.. _github-pull-request:
|
||||
|
||||
Sending a GitHub pull request
|
||||
=============================
|
||||
-----------------------------
|
||||
|
||||
Sending pull requests on GitHub is the preferred method for receiving
|
||||
contributions. The workflow advice below mirrors `GitHub's own guide <GitHub
|
||||
|
|
@ -66,7 +66,7 @@ Fork a Repo Guide_>`_ and is well worth reading.
|
|||
.. code-block:: bash
|
||||
|
||||
git fetch upstream
|
||||
git checkout -b fix-broken-thing upstream/2016.3
|
||||
git checkout -b fix-broken-thing upstream/2016.11
|
||||
|
||||
If you're working on a feature, create your branch from the develop branch.
|
||||
|
||||
|
|
@ -130,7 +130,7 @@ Fork a Repo Guide_>`_ and is well worth reading.
|
|||
.. code-block:: bash
|
||||
|
||||
git fetch upstream
|
||||
git rebase upstream/2016.3 fix-broken-thing
|
||||
git rebase upstream/2016.11 fix-broken-thing
|
||||
git push -u origin fix-broken-thing
|
||||
|
||||
or
|
||||
|
|
@ -170,9 +170,9 @@ Fork a Repo Guide_>`_ and is well worth reading.
|
|||
https://github.com/my-account/salt/pull/new/fix-broken-thing
|
||||
|
||||
#. If your branch is a fix for a release branch, choose that as the base
|
||||
branch (e.g. ``2016.3``),
|
||||
branch (e.g. ``2016.11``),
|
||||
|
||||
https://github.com/my-account/salt/compare/saltstack:2016.3...fix-broken-thing
|
||||
https://github.com/my-account/salt/compare/saltstack:2016.11...fix-broken-thing
|
||||
|
||||
If your branch is a feature, choose ``develop`` as the base branch,
|
||||
|
||||
|
|
@ -205,80 +205,206 @@ Fork a Repo Guide_>`_ and is well worth reading.
|
|||
|
||||
.. _which-salt-branch:
|
||||
|
||||
Which Salt branch?
|
||||
==================
|
||||
|
||||
GitHub will open pull requests against Salt's main branch, ``develop``, by
|
||||
default. Ideally, features should go into ``develop`` and bug fixes and
|
||||
documentation changes should go into the oldest supported release branch
|
||||
affected by the bug or documentation update. See
|
||||
:ref:`Sending a GitHub pull request <github-pull-request>`.
|
||||
|
||||
If you have a bug fix or doc change and have already forked your working
|
||||
branch from ``develop`` and do not know how to rebase your commits against
|
||||
another branch, then submit it to ``develop`` anyway and we'll be sure to
|
||||
back-port it to the correct place.
|
||||
|
||||
The current release branch
|
||||
--------------------------
|
||||
|
||||
The current release branch is the most recent stable release. Pull requests
|
||||
containing bug fixes should be made against the release branch.
|
||||
|
||||
The branch name will be a date-based name such as ``2016.3``.
|
||||
|
||||
Bug fixes are made on this branch so that minor releases can be cut from this
|
||||
branch without introducing surprises and new features. This approach maximizes
|
||||
stability.
|
||||
|
||||
The Salt development team will "merge-forward" any fixes made on the release
|
||||
branch to the ``develop`` branch once the pull request has been accepted. This
|
||||
keeps the fix in isolation on the release branch and also keeps the ``develop``
|
||||
branch up-to-date.
|
||||
|
||||
.. note:: Closing GitHub issues from commits
|
||||
|
||||
This "merge-forward" strategy requires that `the magic keywords to close a
|
||||
GitHub issue <Closing issues via commit message_>`_ appear in the commit
|
||||
message text directly. Only including the text in a pull request will not
|
||||
close the issue.
|
||||
|
||||
GitHub will close the referenced issue once the *commit* containing the
|
||||
magic text is merged into the default branch (``develop``). Any magic text
|
||||
input only into the pull request description will not be seen at the
|
||||
Git-level when those commits are merged-forward. In other words, only the
|
||||
commits are merged-forward and not the pull request.
|
||||
|
||||
The ``develop`` branch
|
||||
Salt's Branch Topology
|
||||
----------------------
|
||||
|
||||
There are three different kinds of branches in use: develop, main release
|
||||
branches, and dot release branches.
|
||||
|
||||
- All feature work should go into the ``develop`` branch.
|
||||
- Bug fixes and documentation changes should go into the oldest supported
|
||||
**main** release branch affected by the the bug or documentation change.
|
||||
Main release branches are named after a year and month, such as
|
||||
``2016.11`` and ``2017.7``.
|
||||
- Hot fixes, as determined by SaltStack's release team, should be submitted
|
||||
against **dot** release branches. Dot release branches are named after a
|
||||
year, month, and version. Examples include ``2016.11.8`` and ``2017.7.2``.
|
||||
|
||||
.. note::
|
||||
|
||||
GitHub will open pull requests against Salt's main branch, ``develop``,
|
||||
byndefault. Be sure to check which branch is selected when creating the
|
||||
pull request.
|
||||
|
||||
The Develop Branch
|
||||
==================
|
||||
|
||||
The ``develop`` branch is unstable and bleeding-edge. Pull requests containing
|
||||
feature additions or non-bug-fix changes should be made against the ``develop``
|
||||
branch.
|
||||
|
||||
The Salt development team will back-port bug fixes made to ``develop`` to the
|
||||
current release branch if the contributor cannot create the pull request
|
||||
against that branch.
|
||||
.. note::
|
||||
|
||||
Release Branches
|
||||
----------------
|
||||
If you have a bug fix or documentation change and have already forked your
|
||||
working branch from ``develop`` and do not know how to rebase your commits
|
||||
against another branch, then submit it to ``develop`` anyway. SaltStack's
|
||||
development team will be happy to back-port it to the correct branch.
|
||||
|
||||
For each release, a branch will be created when the SaltStack release team is
|
||||
ready to tag. The release branch is created from the parent branch and will be
|
||||
the same name as the tag minus the ``v``. For example, the ``2017.7.1`` release
|
||||
branch was created from the ``2017.7`` parent branch and the ``v2017.7.1``
|
||||
release was tagged at the ``HEAD`` of the ``2017.7.1`` branch. This branching
|
||||
strategy will allow for more stability when there is a need for a re-tag during
|
||||
the testing phase of the release process.
|
||||
**Please make sure you let the maintainers know that the pull request needs
|
||||
to be back-ported.**
|
||||
|
||||
Once the release branch is created, the fixes required for a given release, as
|
||||
determined by the SaltStack release team, will be added to this branch. All
|
||||
commits in this branch will be merged forward into the parent branch as well.
|
||||
Main Release Branches
|
||||
=====================
|
||||
|
||||
The current release branch is the most recent stable release. Pull requests
|
||||
containing bug fixes or documentation changes should be made against the main
|
||||
release branch that is affected.
|
||||
|
||||
The branch name will be a date-based name such as ``2016.11``.
|
||||
|
||||
Bug fixes are made on this branch so that dot release branches can be cut from
|
||||
the main release branch without introducing surprises and new features. This
|
||||
approach maximizes stability.
|
||||
|
||||
Dot Release Branches
|
||||
====================
|
||||
|
||||
Prior to tagging an official release, a branch will be created when the SaltStack
|
||||
release team is ready to tag. The dot release branch is created from a main release
|
||||
branch. The dot release branch will be the same name as the tag minus the ``v``.
|
||||
For example, the ``2017.7.1`` dot release branch was created from the ``2017.7``
|
||||
main release branch. The ``v2017.7.1`` release was tagged at the ``HEAD`` of the
|
||||
``2017.7.1`` branch.
|
||||
|
||||
This branching strategy will allow for more stability when there is a need for
|
||||
a re-tag during the testing phase of the release process and further increases
|
||||
stability.
|
||||
|
||||
Once the dot release branch is created, the fixes required for a given release,
|
||||
as determined by the SaltStack release team, will be added to this branch. All
|
||||
commits in this branch will be merged forward into the main release branch as
|
||||
well.
|
||||
|
||||
Merge Forward Process
|
||||
=====================
|
||||
|
||||
The Salt repository follows a "Merge Forward" policy. The merge-forward
|
||||
behavior means that changes submitted to older main release branches will
|
||||
automatically be "merged-forward" into the newer branches.
|
||||
|
||||
For example, a pull request is merged into ``2016.11``. Then, the entire
|
||||
``2016.11`` branch is merged-forward into the ``2017.7`` branch, and the
|
||||
``2017.7`` branch is merged-forward into the ``develop`` branch.
|
||||
|
||||
This process makes is easy for contributors to make only one pull-request
|
||||
against an older branch, but allows the change to propagate to all **main**
|
||||
release branches.
|
||||
|
||||
The merge-forward work-flow applies to all main release branches and the
|
||||
operation runs continuously.
|
||||
|
||||
Merge-Forwards for Dot Release Branches
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The merge-forward policy applies to dot release branches as well, but has a
|
||||
slightly different behavior. If a change is submitted to a **dot** release
|
||||
branch, the dot release branch will be merged into its parent **main**
|
||||
release branch.
|
||||
|
||||
For example, a pull request is merged into the ``2017.7.2`` release branch.
|
||||
Then, the entire ``2017.7.2`` branch is merged-forward into the ``2017.7``
|
||||
branch. From there, the merge forward process continues as normal.
|
||||
|
||||
The only way in which dot release branches differ from main release branches
|
||||
in regard to merge-forwards, is that once a dot release branch is created
|
||||
from the main release branch, the dot release branch does not receive merge
|
||||
forwards.
|
||||
|
||||
.. note::
|
||||
|
||||
The merge forward process for dot release branches is one-way:
|
||||
dot release branch --> main release branch.
|
||||
|
||||
Closing GitHub issues from commits
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
This "merge-forward" strategy requires that `the magic keywords to close a
|
||||
GitHub issue <Closing issues via commit message_>`_ appear in the commit
|
||||
message text directly. Only including the text in a pull request will not
|
||||
close the issue.
|
||||
|
||||
GitHub will close the referenced issue once the *commit* containing the
|
||||
magic text is merged into the default branch (``develop``). Any magic text
|
||||
input only into the pull request description will not be seen at the
|
||||
Git-level when those commits are merged-forward. In other words, only the
|
||||
commits are merged-forward and not the pull request text.
|
||||
|
||||
.. _backporting-pull-requests:
|
||||
|
||||
Backporting Pull Requests
|
||||
=========================
|
||||
|
||||
If a bug is fixed on ``develop`` and the bug is also present on a
|
||||
currently-supported release branch, it will need to be back-ported to an
|
||||
applicable branch.
|
||||
|
||||
.. note:: Most Salt contributors can skip these instructions
|
||||
|
||||
These instructions do not need to be read in order to contribute to the
|
||||
Salt project! The SaltStack team will back-port fixes on behalf of
|
||||
contributors in order to keep the contribution process easy.
|
||||
|
||||
These instructions are intended for frequent Salt contributors, advanced
|
||||
Git users, SaltStack employees, or independent souls who wish to back-port
|
||||
changes themselves.
|
||||
|
||||
It is often easiest to fix a bug on the oldest supported release branch and
|
||||
then merge that branch forward into ``develop`` (as described earlier in this
|
||||
document). When that is not possible the fix must be back-ported, or copied,
|
||||
into any other affected branches.
|
||||
|
||||
These steps assume a pull request ``#1234`` has been merged into ``develop``.
|
||||
And ``upstream`` is the name of the remote pointing to the main Salt repo.
|
||||
|
||||
#. Identify the oldest supported release branch that is affected by the bug.
|
||||
|
||||
#. Create a new branch for the back-port by reusing the same branch from the
|
||||
original pull request.
|
||||
|
||||
Name the branch ``bp-<NNNN>`` and use the number of the original pull
|
||||
request.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git fetch upstream refs/pull/1234/head:bp-1234
|
||||
git checkout bp-1234
|
||||
|
||||
#. Find the parent commit of the original pull request.
|
||||
|
||||
The parent commit of the original pull request must be known in order to
|
||||
rebase onto a release branch. The easiest way to find this is on GitHub.
|
||||
|
||||
Open the original pull request on GitHub and find the first commit in the
|
||||
list of commits. Select and copy the SHA for that commit. The parent of
|
||||
that commit can be specified by appending ``~1`` to the end.
|
||||
|
||||
#. Rebase the new branch on top of the release branch.
|
||||
|
||||
* ``<release-branch>`` is the branch identified in step #1.
|
||||
|
||||
* ``<orig-base>`` is the SHA identified in step #3 -- don't forget to add
|
||||
``~1`` to the end!
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git rebase --onto <release-branch> <orig-base> bp-1234
|
||||
|
||||
Note, release branches prior to ``2016.11`` will not be able to make use of
|
||||
rebase and must use cherry-picking instead.
|
||||
|
||||
#. Push the back-port branch to GitHub and open a new pull request.
|
||||
|
||||
Opening a pull request for the back-port allows for the test suite and
|
||||
normal code-review process.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git push -u origin bp-1234
|
||||
|
||||
Keeping Salt Forks in Sync
|
||||
==========================
|
||||
--------------------------
|
||||
|
||||
Salt is advancing quickly. It is therefore critical to pull upstream changes
|
||||
Salt advances quickly. It is therefore critical to pull upstream changes
|
||||
from upstream into your fork on a regular basis. Nothing is worse than putting
|
||||
hard work into a pull request only to see bunches of merge conflicts because it
|
||||
has diverged too far from upstream.
|
||||
|
|
@ -340,92 +466,31 @@ the name of the main `saltstack/salt`_ repository.
|
|||
the current release branch.
|
||||
|
||||
Posting patches to the mailing list
|
||||
===================================
|
||||
-----------------------------------
|
||||
|
||||
Patches will also be accepted by email. Format patches using `git
|
||||
format-patch`_ and send them to the `salt-users`_ mailing list. The contributor
|
||||
will then get credit for the patch, and the Salt community will have an archive
|
||||
of the patch and a place for discussion.
|
||||
|
||||
.. _backporting-pull-requests:
|
||||
|
||||
Backporting Pull Requests
|
||||
=========================
|
||||
|
||||
If a bug is fixed on ``develop`` and the bug is also present on a
|
||||
currently-supported release branch it will need to be back-ported to all
|
||||
applicable branches.
|
||||
|
||||
.. note:: Most Salt contributors can skip these instructions
|
||||
|
||||
These instructions do not need to be read in order to contribute to the
|
||||
Salt project! The SaltStack team will back-port fixes on behalf of
|
||||
contributors in order to keep the contribution process easy.
|
||||
|
||||
These instructions are intended for frequent Salt contributors, advanced
|
||||
Git users, SaltStack employees, or independent souls who wish to back-port
|
||||
changes themselves.
|
||||
|
||||
It is often easiest to fix a bug on the oldest supported release branch and
|
||||
then merge that branch forward into ``develop`` (as described earlier in this
|
||||
document). When that is not possible the fix must be back-ported, or copied,
|
||||
into any other affected branches.
|
||||
|
||||
These steps assume a pull request ``#1234`` has been merged into ``develop``.
|
||||
And ``upstream`` is the name of the remote pointing to the main Salt repo.
|
||||
|
||||
1. Identify the oldest supported release branch that is affected by the bug.
|
||||
|
||||
2. Create a new branch for the back-port by reusing the same branch from the
|
||||
original pull request.
|
||||
|
||||
Name the branch ``bp-<NNNN>`` and use the number of the original pull
|
||||
request.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git fetch upstream refs/pull/1234/head:bp-1234
|
||||
git checkout bp-1234
|
||||
|
||||
3. Find the parent commit of the original pull request.
|
||||
|
||||
The parent commit of the original pull request must be known in order to
|
||||
rebase onto a release branch. The easiest way to find this is on GitHub.
|
||||
|
||||
Open the original pull request on GitHub and find the first commit in the
|
||||
list of commits. Select and copy the SHA for that commit. The parent of
|
||||
that commit can be specified by appending ``~1`` to the end.
|
||||
|
||||
4. Rebase the new branch on top of the release branch.
|
||||
|
||||
* ``<release-branch>`` is the branch identified in step #1.
|
||||
|
||||
* ``<orig-base>`` is the SHA identified in step #3 -- don't forget to add
|
||||
``~1`` to the end!
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git rebase --onto <release-branch> <orig-base> bp-1234
|
||||
|
||||
Note, release branches prior to ``2016.3`` will not be able to make use of
|
||||
rebase and must use cherry-picking instead.
|
||||
|
||||
5. Push the back-port branch to GitHub and open a new pull request.
|
||||
|
||||
Opening a pull request for the back-port allows for the test suite and
|
||||
normal code-review process.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
git push -u origin bp-1234
|
||||
|
||||
Issue and Pull Request Labeling System
|
||||
======================================
|
||||
--------------------------------------
|
||||
|
||||
SaltStack uses several labeling schemes to help facilitate code contributions
|
||||
and bug resolution. See the :ref:`Labels and Milestones
|
||||
<labels-and-milestones>` documentation for more information.
|
||||
|
||||
Mentionbot
|
||||
----------
|
||||
|
||||
SaltStack runs a mention-bot which notifies contributors who might be able
|
||||
to help review incoming pull-requests based on their past contribution to
|
||||
files which are being changed.
|
||||
|
||||
If you do not wish to receive these notifications, please add your GitHub
|
||||
handle to the blacklist line in the `.mention-bot` file located in the
|
||||
root of the Salt repository.
|
||||
|
||||
.. _`saltstack/salt`: https://github.com/saltstack/salt
|
||||
.. _`GitHub Fork a Repo Guide`: https://help.github.com/articles/fork-a-repo
|
||||
.. _`GitHub issue tracker`: https://github.com/saltstack/salt/issues
|
||||
|
|
@ -434,14 +499,3 @@ and bug resolution. See the :ref:`Labels and Milestones
|
|||
.. _`Closing issues via commit message`: https://help.github.com/articles/closing-issues-via-commit-messages
|
||||
.. _`git format-patch`: https://www.kernel.org/pub/software/scm/git/docs/git-format-patch.html
|
||||
.. _salt-users: https://groups.google.com/forum/#!forum/salt-users
|
||||
|
||||
Mentionbot
|
||||
==========
|
||||
|
||||
SaltStack runs a mention-bot which notifies contributors who might be able
|
||||
to help review incoming pull-requests based on their past contribution to
|
||||
files which are being changed.
|
||||
|
||||
If you do not wish to receive these notifications, please add your GitHub
|
||||
handle to the blacklist line in the `.mention-bot` file located in the
|
||||
root of the Salt repository.
|
||||
|
|
|
|||
|
|
@ -598,9 +598,14 @@ def exists(vpc_id=None, name=None, cidr=None, tags=None, region=None, key=None,
|
|||
try:
|
||||
vpc_ids = _find_vpcs(vpc_id=vpc_id, vpc_name=name, cidr=cidr, tags=tags,
|
||||
region=region, key=key, keyid=keyid, profile=profile)
|
||||
return {'exists': bool(vpc_ids)}
|
||||
except BotoServerError as e:
|
||||
return {'error': salt.utils.boto.get_error(e)}
|
||||
except BotoServerError as err:
|
||||
boto_err = salt.utils.boto.get_error(err)
|
||||
if boto_err.get('aws', {}).get('code') == 'InvalidVpcID.NotFound':
|
||||
# VPC was not found: handle the error and return False.
|
||||
return {'exists': False}
|
||||
return {'error': boto_err}
|
||||
|
||||
return {'exists': bool(vpc_ids)}
|
||||
|
||||
|
||||
def create(cidr_block, instance_tenancy=None, vpc_name=None,
|
||||
|
|
@ -722,27 +727,34 @@ def describe(vpc_id=None, vpc_name=None, region=None, key=None,
|
|||
try:
|
||||
conn = _get_conn(region=region, key=key, keyid=keyid, profile=profile)
|
||||
vpc_id = check_vpc(vpc_id, vpc_name, region, key, keyid, profile)
|
||||
if not vpc_id:
|
||||
except BotoServerError as err:
|
||||
boto_err = salt.utils.boto.get_error(err)
|
||||
if boto_err.get('aws', {}).get('code') == 'InvalidVpcID.NotFound':
|
||||
# VPC was not found: handle the error and return None.
|
||||
return {'vpc': None}
|
||||
return {'error': boto_err}
|
||||
|
||||
filter_parameters = {'vpc_ids': vpc_id}
|
||||
if not vpc_id:
|
||||
return {'vpc': None}
|
||||
|
||||
filter_parameters = {'vpc_ids': vpc_id}
|
||||
|
||||
try:
|
||||
vpcs = conn.get_all_vpcs(**filter_parameters)
|
||||
except BotoServerError as err:
|
||||
return {'error': salt.utils.boto.get_error(err)}
|
||||
|
||||
if vpcs:
|
||||
vpc = vpcs[0] # Found!
|
||||
log.debug('Found VPC: {0}'.format(vpc.id))
|
||||
if vpcs:
|
||||
vpc = vpcs[0] # Found!
|
||||
log.debug('Found VPC: {0}'.format(vpc.id))
|
||||
|
||||
keys = ('id', 'cidr_block', 'is_default', 'state', 'tags',
|
||||
'dhcp_options_id', 'instance_tenancy')
|
||||
_r = dict([(k, getattr(vpc, k)) for k in keys])
|
||||
_r.update({'region': getattr(vpc, 'region').name})
|
||||
return {'vpc': _r}
|
||||
else:
|
||||
return {'vpc': None}
|
||||
|
||||
except BotoServerError as e:
|
||||
return {'error': salt.utils.boto.get_error(e)}
|
||||
keys = ('id', 'cidr_block', 'is_default', 'state', 'tags',
|
||||
'dhcp_options_id', 'instance_tenancy')
|
||||
_r = dict([(k, getattr(vpc, k)) for k in keys])
|
||||
_r.update({'region': getattr(vpc, 'region').name})
|
||||
return {'vpc': _r}
|
||||
else:
|
||||
return {'vpc': None}
|
||||
|
||||
|
||||
def describe_vpcs(vpc_id=None, name=None, cidr=None, tags=None,
|
||||
|
|
@ -808,7 +820,7 @@ def _find_subnets(subnet_name=None, vpc_id=None, cidr=None, tags=None, conn=None
|
|||
Given subnet properties, find and return matching subnet ids
|
||||
'''
|
||||
|
||||
if not any(subnet_name, tags, cidr):
|
||||
if not any([subnet_name, tags, cidr]):
|
||||
raise SaltInvocationError('At least one of the following must be '
|
||||
'specified: subnet_name, cidr or tags.')
|
||||
|
||||
|
|
@ -926,34 +938,38 @@ def subnet_exists(subnet_id=None, name=None, subnet_name=None, cidr=None,
|
|||
|
||||
try:
|
||||
conn = _get_conn(region=region, key=key, keyid=keyid, profile=profile)
|
||||
filter_parameters = {'filters': {}}
|
||||
except BotoServerError as err:
|
||||
return {'error': salt.utils.boto.get_error(err)}
|
||||
|
||||
if subnet_id:
|
||||
filter_parameters['subnet_ids'] = [subnet_id]
|
||||
|
||||
if subnet_name:
|
||||
filter_parameters['filters']['tag:Name'] = subnet_name
|
||||
|
||||
if cidr:
|
||||
filter_parameters['filters']['cidr'] = cidr
|
||||
|
||||
if tags:
|
||||
for tag_name, tag_value in six.iteritems(tags):
|
||||
filter_parameters['filters']['tag:{0}'.format(tag_name)] = tag_value
|
||||
|
||||
if zones:
|
||||
filter_parameters['filters']['availability_zone'] = zones
|
||||
filter_parameters = {'filters': {}}
|
||||
if subnet_id:
|
||||
filter_parameters['subnet_ids'] = [subnet_id]
|
||||
if subnet_name:
|
||||
filter_parameters['filters']['tag:Name'] = subnet_name
|
||||
if cidr:
|
||||
filter_parameters['filters']['cidr'] = cidr
|
||||
if tags:
|
||||
for tag_name, tag_value in six.iteritems(tags):
|
||||
filter_parameters['filters']['tag:{0}'.format(tag_name)] = tag_value
|
||||
if zones:
|
||||
filter_parameters['filters']['availability_zone'] = zones
|
||||
|
||||
try:
|
||||
subnets = conn.get_all_subnets(**filter_parameters)
|
||||
log.debug('The filters criteria {0} matched the following subnets:{1}'.format(filter_parameters, subnets))
|
||||
if subnets:
|
||||
log.info('Subnet {0} exists.'.format(subnet_name or subnet_id))
|
||||
return {'exists': True}
|
||||
else:
|
||||
log.info('Subnet {0} does not exist.'.format(subnet_name or subnet_id))
|
||||
except BotoServerError as err:
|
||||
boto_err = salt.utils.boto.get_error(err)
|
||||
if boto_err.get('aws', {}).get('code') == 'InvalidSubnetID.NotFound':
|
||||
# Subnet was not found: handle the error and return False.
|
||||
return {'exists': False}
|
||||
except BotoServerError as e:
|
||||
return {'error': salt.utils.boto.get_error(e)}
|
||||
return {'error': boto_err}
|
||||
|
||||
log.debug('The filters criteria {0} matched the following subnets:{1}'.format(filter_parameters, subnets))
|
||||
if subnets:
|
||||
log.info('Subnet {0} exists.'.format(subnet_name or subnet_id))
|
||||
return {'exists': True}
|
||||
else:
|
||||
log.info('Subnet {0} does not exist.'.format(subnet_name or subnet_id))
|
||||
return {'exists': False}
|
||||
|
||||
|
||||
def get_subnet_association(subnets, region=None, key=None, keyid=None,
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue