delta/openstack/python-openstackclient.git/openstackclient/network/v2/security_group_rule.py, branch 5.4.0 opendev.org: openstack/python-openstackclient Revert "Format location columns in network commands" 2020-06-17T10:09:36+00:00 Jens Harbott (frickler) j.harbott@x-ion.de 2020-06-17T10:07:12+00:00 a04172969a5e440af50127dfd27a80a6beb7ddb8 This reverts commit 6ee7b8d138e07bfc37c5cd887f7afa49cdabb02f. Change-Id: I5f59959ba8a01aba49e29f4cb007397467344e58 
This reverts commit 6ee7b8d138e07bfc37c5cd887f7afa49cdabb02f.

Change-Id: I5f59959ba8a01aba49e29f4cb007397467344e58
Replace six.iteritems() with .items() 2020-01-09T09:41:29+00:00 lihaijing lihaijing@fiberhome.com 2017-07-07T03:48:48+00:00 d15bbada73f81136c966007d9c564dd6cfb2fd9c 1. As mentioned in [1], we should avoid using six.iteritems to achieve iterators. We can use dict.items instead, as it will return iterators in PY3 as well. And dict.items/keys will more readable. 2. In py2, the performance about list should be negligible, see the link [2]. [1] https://wiki.openstack.org/wiki/Python3 [2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html Co-Authored-By: Akihiro Motoki <amotoki@gmail.com> Change-Id: I4b9edb326444264c0f6c4ad281acaac356a07e85 Implements: blueprint replace-iteritems-with-items 
1. As mentioned in [1], we should avoid using six.iteritems to achieve
   iterators. We can use dict.items instead, as it will return iterators
   in PY3 as well. And dict.items/keys will more readable.

2. In py2, the performance about list should be negligible,
   see the link [2].

[1] https://wiki.openstack.org/wiki/Python3
[2] http://lists.openstack.org/pipermail/openstack-dev/2015-June/066391.html

Co-Authored-By: Akihiro Motoki <amotoki@gmail.com>
Change-Id: I4b9edb326444264c0f6c4ad281acaac356a07e85
Implements: blueprint replace-iteritems-with-items
neutron: autogenerate docs 2019-11-01T19:24:30+00:00 Eric Fried openstack@fried.cc 2019-10-28T22:27:38+00:00 cd6c285cc6c2274e6b42cc452ba4a61a3487ca23 $namespace = openstack.network.v2 The subcommand documents for $namespace were hardcoded and thus prone to drift over time. This commit removes the hardcoded content and uses the autoprogram-cliff directive to generate them automatically from the subcommand configuration classes. This one turned out to be quite involved, because we support both neutron and nova-network. When running in a real cloud, the command classes detect whether the neutron service is present, assume nova-network if that service is not found, and only add parser options relevant to the detected service. But the docs need to present both sets of options. This was easy enough when they were hardcoded, but required a bit of additional infrastructure for generated docs. Change-Id: I426261eb1d86bcc68656aabd61f10b7f082da402 
$namespace = openstack.network.v2

The subcommand documents for $namespace were hardcoded and thus prone to
drift over time. This commit removes the hardcoded content and uses the
autoprogram-cliff directive to generate them automatically from the
subcommand configuration classes.

This one turned out to be quite involved, because we support both
neutron and nova-network. When running in a real cloud, the command
classes detect whether the neutron service is present, assume
nova-network if that service is not found, and only add parser options
relevant to the detected service. But the docs need to present both sets
of options. This was easy enough when they were hardcoded, but required
a bit of additional infrastructure for generated docs.

Change-Id: I426261eb1d86bcc68656aabd61f10b7f082da402
Format location columns in network commands 2019-08-30T17:53:18+00:00 Dean Troyer dtroyer@gmail.com 2019-08-30T17:53:15+00:00 6ee7b8d138e07bfc37c5cd887f7afa49cdabb02f These return a Munch from the SDK, which can be handled exactly like a dict so do that. Note that the location column has a nested project dict in the return value, this is addressed separately in osc_lib.format_columns in https://review.opendev.org/#/c/679474/. Change-Id: I99a6d192749a4ac76777f72be8118261c0521cb0 Signed-off-by: Dean Troyer <dtroyer@gmail.com> 
These return a Munch from the SDK, which can be handled exactly
like a dict so do that.

Note that the location column has a nested project dict in the
return value, this is addressed separately in osc_lib.format_columns
in https://review.opendev.org/#/c/679474/.

Change-Id: I99a6d192749a4ac76777f72be8118261c0521cb0
Signed-off-by: Dean Troyer <dtroyer@gmail.com>
Support IPv6 addresses better 2019-07-16T02:35:49+00:00 Brian Haley bhaley@redhat.com 2017-11-30T22:53:29+00:00 969e6abd20570ae64b3d1fd049da1521fa148b5c When adding a security group rule, if no IP address is given we will use '0.0.0.0/0', but if the ethertype is IPv6 we will leave it as None. Change this to be '::/0' to match what we do for IPv4 - use the "any" address. The neutron server treats them both the same when checking for duplicates. Because there are most likely entries in the DB using None for the IP, print them as '0.0.0.0/0' or '::/0' so it is more obvious what address they are actually referring to. Also change to display the Ethertype column by default instead of with --long, since easily knowing IPv4 or IPv6 is useful. Change-Id: Ic396fc23caa66b6b0034c5d30b27c6ed499de5a6 Closes-bug: #1735575 
When adding a security group rule, if no IP address is given
we will use '0.0.0.0/0', but if the ethertype is IPv6 we will
leave it as None.  Change this to be '::/0' to match what we
do for IPv4 - use the "any" address.  The neutron server
treats them both the same when checking for duplicates.

Because there are most likely entries in the DB using None
for the IP, print them as '0.0.0.0/0' or '::/0' so it is more
obvious what address they are actually referring to.

Also change to display the Ethertype column by default
instead of with --long, since easily knowing IPv4 or IPv6
is useful.

Change-Id: Ic396fc23caa66b6b0034c5d30b27c6ed499de5a6
Closes-bug: #1735575
Merge "Change default security group protocol to 'any'" 2019-06-22T21:39:31+00:00 Zuul zuul@review.opendev.org 2019-06-22T21:39:31+00:00 3258b9e5e3c2c6e7752806f505d1fefbbe135eef 






Remove deprecated network options
2019-05-19T23:22:26+00:00

Sean McGinnis
sean.mcginnis@gmail.com

2018-10-26T16:50:32+00:00

5a0fc68a87d1c9733c1dd5bb6f68b2e518fe2105

The following were deprecated for several releases and can now be
removed:

* Remove ``port create|set`` options ``--device-id`` and ``--port-id``
* Remove ``router set`` option ``--clear-routes``
* Remove ``security group rule create`` options ``--src-group`` and ``--src-ip``

These are backwards incompatible changes and will require a major
version bump after they are merged.

Change-Id: Ieae74c14f6b3e263721a3146cf76f94a9ab792f6
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Signed-off-by: Dean Troyer <dtroyer@gmail.com>





The following were deprecated for several releases and can now be
removed:

* Remove ``port create|set`` options ``--device-id`` and ``--port-id``
* Remove ``router set`` option ``--clear-routes``
* Remove ``security group rule create`` options ``--src-group`` and ``--src-ip``

These are backwards incompatible changes and will require a major
version bump after they are merged.

Change-Id: Ieae74c14f6b3e263721a3146cf76f94a9ab792f6
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Signed-off-by: Dean Troyer <dtroyer@gmail.com>







Change default security group protocol to 'any'
2019-05-06T14:55:13+00:00

Brian Haley
bhaley@redhat.com

2017-11-10T15:58:58+00:00

33a255612c661f174d2cb5d4ca93f8d7096e9290

The default protocol used to create a security rule was changed to
``tcp``, which was a regression from the neutron client.  Change it
back to ``any``, which skips sending the protocol to the API
server entirely when using the Neutron v2 API.

Users that had been creating rules without specifying a protocol
and expecting ``tcp`` need to change to use ``--protocol tcp``
explicitly.

Change-Id: Iedaa027240e00dced551513d8fa828564386b79f
Closes-bug: #1716789





The default protocol used to create a security rule was changed to
``tcp``, which was a regression from the neutron client.  Change it
back to ``any``, which skips sending the protocol to the API
server entirely when using the Neutron v2 API.

Users that had been creating rules without specifying a protocol
and expecting ``tcp`` need to change to use ``--protocol tcp``
explicitly.

Change-Id: Iedaa027240e00dced551513d8fa828564386b79f
Closes-bug: #1716789







Ignore case in security group rule --ethertype
2019-04-01T19:56:40+00:00

Jim Rollenhagen
jim@jimrollenhagen.com

2019-04-01T19:41:17+00:00

c53de3214ed74ffd5b53e6d1cf8a0c0fa73dac99

Currently, this only allows 'IPv4' or 'IPv6', but one can imagine a user
frequently typing e.g. 'ipv6' and getting frustrated. Allow any case,
while still keeping correct case for the choices and the value sent to
Neutron.

Change-Id: I70ce1f43d32aad01b174437d03c984a5b608b161





Currently, this only allows 'IPv4' or 'IPv6', but one can imagine a user
frequently typing e.g. 'ipv6' and getting frustrated. Allow any case,
while still keeping correct case for the choices and the value sent to
Neutron.

Change-Id: I70ce1f43d32aad01b174437d03c984a5b608b161







Allow creating security rules without protocol
2017-10-17T17:36:40+00:00

Daniel Speichert
daniel@speichert.pl

2017-10-15T20:35:37+00:00

82f45d9bd203aee77914c1f9e300f7dbedf673c8

In order to create a rule for any protocol, the client
must not specify the protocol in the API call. This
is currently impossible because protocol defaults to TCP.

In order not to change the default behavior, a "new" protocol
name is added: "any", which makes this CLI skip sending the
protocol field altogether.

Change-Id: I58853d3745f3631007e5e9780c0c5c2526b730a3
Closes-Bug: 1712242





In order to create a rule for any protocol, the client
must not specify the protocol in the API call. This
is currently impossible because protocol defaults to TCP.

In order not to change the default behavior, a "new" protocol
name is added: "any", which makes this CLI skip sending the
protocol field altogether.

Change-Id: I58853d3745f3631007e5e9780c0c5c2526b730a3
Closes-Bug: 1712242