| 2015-06-24 13:47:45 |
Yushiro FURUKAWA |
bug |
|
|
added bug |
| 2015-06-24 13:47:58 |
Yushiro FURUKAWA |
neutron: assignee |
|
Yushiro FURUKAWA (y-furukawa-2) |
|
| 2015-06-25 01:21:54 |
Yushiro FURUKAWA |
neutron: assignee |
Yushiro FURUKAWA (y-furukawa-2) |
|
|
| 2015-06-25 01:22:20 |
Yushiro FURUKAWA |
neutron: assignee |
|
Yushiro FURUKAWA (y-furukawa-2) |
|
| 2015-06-25 01:54:06 |
yong sheng gong |
bug |
|
|
added subscriber yong sheng gong |
| 2015-06-25 07:46:31 |
Cao Xuan Hoang |
summary |
RFE - logging API for Neutron |
RFE - Packet logging API for Neutron |
|
| 2015-06-25 08:38:02 |
Cao Xuan Hoang |
bug |
|
|
added subscriber Cao Xuan Hoang |
| 2015-07-01 15:46:10 |
Kyle Mestery |
neutron: status |
New |
Confirmed |
|
| 2015-07-01 18:59:20 |
vishwanath jayaraman |
bug |
|
|
added subscriber vishwanath jayaraman |
| 2015-07-07 01:33:52 |
shihanzhang |
bug |
|
|
added subscriber shihanzhang |
| 2015-07-09 05:19:27 |
Yushiro FURUKAWA |
description |
Current Neutron doesn't have the logging function of some resources.
e.g. Security-group, Firewall
This spec proposes to create new logging API for neutron resources.
We will define a new resource named "logging".
This resource manages the following contents:
* Target resource(UUID) for logging
* Service type of the target resource
"security-group", "firewall"
* Log level
For example:
$ neutron logging-create --service_type "sg" sg_id
=> logging resource with ID:abc will be created.
=> iptables' rule will be modified at this timing.
* Insert "LOG" configuration into a rule related to the specified security-group)
$ neutron logging-delete abc
=> iptables' rule will be modified at this timing.
* Delete "LOG" configuration from the rule.
This RFE is based on the comment in the following spec.
https://review.openstack.org/#/c/132134/
And, this spec is also related to this RFE:
https://review.openstack.org/#/c/132133/ |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for neutron resources.
We will define a new resource named "logging"(on the table)
"logging" resource manages the following contents:
- Target resource(UUID) for logging
- Service type of the target resource
e.g. "security-group", "security-group-rule",
"firewall", "firewall-rule"
- Log level
We'd like to hundle the same procedure for set logging configuration
even if the target resource is security-group or firewall.
For example:
$ neutron logging-create --service_type "sg" sg_id
=> logging resource with ID:abc will be created.
=> iptables' rule will be modified at this timing.
* Insert "LOG" configuration into a rule related to
the specified security-group
$ neutron logging-delete abc
=> iptables' rule will be modified at this timing.
* Delete "LOG" configuration from the rule.
This RFE is based on the comment in the following spec.
https://review.openstack.org/#/c/132134/
=> This spec will change that related to this RFE.
And, this spec is also related to this RFE:
https://review.openstack.org/#/c/132133/
=> This spec will change that related to this RFE. |
|
| 2015-07-09 14:16:00 |
Yushiro FURUKAWA |
description |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for neutron resources.
We will define a new resource named "logging"(on the table)
"logging" resource manages the following contents:
- Target resource(UUID) for logging
- Service type of the target resource
e.g. "security-group", "security-group-rule",
"firewall", "firewall-rule"
- Log level
We'd like to hundle the same procedure for set logging configuration
even if the target resource is security-group or firewall.
For example:
$ neutron logging-create --service_type "sg" sg_id
=> logging resource with ID:abc will be created.
=> iptables' rule will be modified at this timing.
* Insert "LOG" configuration into a rule related to
the specified security-group
$ neutron logging-delete abc
=> iptables' rule will be modified at this timing.
* Delete "LOG" configuration from the rule.
This RFE is based on the comment in the following spec.
https://review.openstack.org/#/c/132134/
=> This spec will change that related to this RFE.
And, this spec is also related to this RFE:
https://review.openstack.org/#/c/132133/
=> This spec will change that related to this RFE. |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for neutron resources.
We will define a new resource named "nw_logging"(on the table)
"nw_logging" resource manages the following contents:
* id(uuid) : nw_logging resource ID
* tenant_id(uuid) : ID of tenant that creates logging
* object_id(uuid) : Refer IDs for logging
* service_type(string): log supported type as follows
=> "sg", "sg_rule", "fw", "fw_rule"
* log_level(string) : Log level as follows
=> "info", "warn", "fatal", "debug", "notice"
We'd like to handle the same procedure for set logging configuration
even if the target resource is security-group, security-group-rule,
firewall or firewall-rule.
[REST API]
* POST v2.0/nw_logging
* GET v2.0/nw_logging
* GET v2.0/nw_logging/{nw_logging_id}
* DELETE v2.0/nw_logging/{nw_logging_id}
For example:
$ neutron logging-create --service_type "sg" sg_id
=> logging resource with ID:abc will be created.
=> iptables' rule will be modified at this timing.
* Insert "LOG" configuration into a rule related to the specified security-group
$ neutron logging-delete abc
=> iptables' rule will be modified at this timing.
* Remove "LOG" configuration from the rule of iptables.
This RFE is based on the comment in the following spec.
https://review.openstack.org/#/c/132134/
=> This spec will change that related to this RFE.
And, this spec is also related to this RFE:
https://review.openstack.org/#/c/132133/
=> This spec will change that related to this RFE. |
|
| 2015-07-14 07:48:23 |
Yushiro FURUKAWA |
description |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for neutron resources.
We will define a new resource named "nw_logging"(on the table)
"nw_logging" resource manages the following contents:
* id(uuid) : nw_logging resource ID
* tenant_id(uuid) : ID of tenant that creates logging
* object_id(uuid) : Refer IDs for logging
* service_type(string): log supported type as follows
=> "sg", "sg_rule", "fw", "fw_rule"
* log_level(string) : Log level as follows
=> "info", "warn", "fatal", "debug", "notice"
We'd like to handle the same procedure for set logging configuration
even if the target resource is security-group, security-group-rule,
firewall or firewall-rule.
[REST API]
* POST v2.0/nw_logging
* GET v2.0/nw_logging
* GET v2.0/nw_logging/{nw_logging_id}
* DELETE v2.0/nw_logging/{nw_logging_id}
For example:
$ neutron logging-create --service_type "sg" sg_id
=> logging resource with ID:abc will be created.
=> iptables' rule will be modified at this timing.
* Insert "LOG" configuration into a rule related to the specified security-group
$ neutron logging-delete abc
=> iptables' rule will be modified at this timing.
* Remove "LOG" configuration from the rule of iptables.
This RFE is based on the comment in the following spec.
https://review.openstack.org/#/c/132134/
=> This spec will change that related to this RFE.
And, this spec is also related to this RFE:
https://review.openstack.org/#/c/132133/
=> This spec will change that related to this RFE. |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for neutron resources.
We will define a new resource named "nw_logging"(on the table)
"nw_logging" resource manages the following contents:
* id(uuid) : nw_logging resource ID
* tenant_id(uuid) : ID of tenant that creates logging
* object_id(uuid) : Refer IDs for logging
* service_type(string): log supported type as follows
=> "sg", "sg_rule", "fw", "fw_rule"
* log_level(string) : Log level as follows
=> "info", "warn", "error", "debug", "notice"
We'd like to handle the same procedure for set logging configuration
even if the target resource is security-group, security-group-rule,
firewall or firewall-rule.
[REST API]
* POST v2.0/nw_logging
* GET v2.0/nw_logging
* GET v2.0/nw_logging/{nw_logging_id}
* DELETE v2.0/nw_logging/{nw_logging_id}
For example:
$ neutron logging-create --service_type "sg" sg_id
=> logging resource with ID:abc will be created.
=> iptables' rule will be modified at this timing.
* Insert "LOG" configuration into a rule related to the specified security-group
$ neutron logging-delete abc
=> iptables' rule will be modified at this timing.
* Remove "LOG" configuration from the rule of iptables.
This RFE is based on the comment in the following spec.
https://review.openstack.org/#/c/132134/
=> This spec will change that related to this RFE.
And, this spec is also related to this RFE:
https://review.openstack.org/#/c/132133/
=> This spec will change that related to this RFE. |
|
| 2015-07-20 08:05:48 |
Yushiro FURUKAWA |
description |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for neutron resources.
We will define a new resource named "nw_logging"(on the table)
"nw_logging" resource manages the following contents:
* id(uuid) : nw_logging resource ID
* tenant_id(uuid) : ID of tenant that creates logging
* object_id(uuid) : Refer IDs for logging
* service_type(string): log supported type as follows
=> "sg", "sg_rule", "fw", "fw_rule"
* log_level(string) : Log level as follows
=> "info", "warn", "error", "debug", "notice"
We'd like to handle the same procedure for set logging configuration
even if the target resource is security-group, security-group-rule,
firewall or firewall-rule.
[REST API]
* POST v2.0/nw_logging
* GET v2.0/nw_logging
* GET v2.0/nw_logging/{nw_logging_id}
* DELETE v2.0/nw_logging/{nw_logging_id}
For example:
$ neutron logging-create --service_type "sg" sg_id
=> logging resource with ID:abc will be created.
=> iptables' rule will be modified at this timing.
* Insert "LOG" configuration into a rule related to the specified security-group
$ neutron logging-delete abc
=> iptables' rule will be modified at this timing.
* Remove "LOG" configuration from the rule of iptables.
This RFE is based on the comment in the following spec.
https://review.openstack.org/#/c/132134/
=> This spec will change that related to this RFE.
And, this spec is also related to this RFE:
https://review.openstack.org/#/c/132133/
=> This spec will change that related to this RFE. |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for security-group
and firewall.
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509/1/specs/liberty/packet-logging.rst
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/ |
|
| 2015-07-20 21:10:23 |
Yushiro FURUKAWA |
description |
[Existing problem]
Operators need logs for trouble shooting.
However, current Neutron doesn't have the packet logging function.
e.g. Security-group, Firewall
Changing Security-group API/DB colomn and implement logging function
is bad approach because of the compatibility with AWS Security-group.
FWaaS also should not change the API/DB colomn.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for security-group
and firewall.
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509/1/specs/liberty/packet-logging.rst
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/ |
[Existing problem]
We would like to implement a packet logging API for neutron resources
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
Packet logging is currently a missing component in Neutron (particularly
for security-group & firewall), and it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group" For the same reason,
we should avoid changing the API/DB column in FWaaS.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for security-group
and firewall.
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509/1/specs/liberty/packet-logging.rst
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/ |
|
| 2015-07-20 21:12:54 |
Yushiro FURUKAWA |
description |
[Existing problem]
We would like to implement a packet logging API for neutron resources
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
Packet logging is currently a missing component in Neutron (particularly
for security-group & firewall), and it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group" For the same reason,
we should avoid changing the API/DB column in FWaaS.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for security-group
and firewall.
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509/1/specs/liberty/packet-logging.rst
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/ |
[Existing problem]
We would like to implement a packet logging API for neutron resources
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
Packet logging is currently a missing component in Neutron (particularly
for security-group & firewall), and it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group" For the same reason,
we should avoid changing the API/DB column in FWaaS.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for security-group
and firewall.
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/ |
|
| 2015-08-07 03:02:40 |
Yushiro FURUKAWA |
description |
[Existing problem]
We would like to implement a packet logging API for neutron resources
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
Packet logging is currently a missing component in Neutron (particularly
for security-group & firewall), and it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group" For the same reason,
we should avoid changing the API/DB column in FWaaS.
Hence, the common API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new logging API for security-group
and firewall.
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/ |
[Existing problem]
Logging is currently a missing feature in security-group & firewall, it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group For the same reason,
we should avoid changing the API/DB column in FWaaS.[1]
Hence, the generic logging API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new generic logging API for security-group and
firewall rules in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html |
|
| 2015-08-07 04:14:05 |
Henry Gessau |
summary |
RFE - Packet logging API for Neutron |
RFE - Logging API for security group and firewall rules |
|
| 2015-10-14 22:12:53 |
German Eichberger |
neutron: importance |
Undecided |
High |
|
| 2015-10-15 00:58:26 |
German Eichberger |
neutron: status |
Confirmed |
Triaged |
|
| 2015-10-20 16:57:30 |
Carl Baldwin |
description |
[Existing problem]
Logging is currently a missing feature in security-group & firewall, it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group For the same reason,
we should avoid changing the API/DB column in FWaaS.[1]
Hence, the generic logging API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new generic logging API for security-group and
firewall rules in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509
---------------------------------------------------------------------
Following specs are included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html |
[Existing problem]
Logging is currently a missing feature in security-group & firewall, it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group For the same reason,
we should avoid changing the API/DB column in FWaaS.[1]
Hence, the generic logging API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new generic logging API for security-group and
firewall rules in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509
---------------------------------------------------------------------
Following (ABANDONED) specs were included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html |
|
| 2015-10-22 07:46:40 |
Nguyen Phuong An |
bug |
|
|
added subscriber Nguyen Phuong An |
| 2015-11-06 09:48:48 |
Yushiro FURUKAWA |
description |
[Existing problem]
Logging is currently a missing feature in security-group & firewall, it is critical for troubleshooting.
Changing the security-group API/DB column by adding a logging function
would break the compatibility with the AWS Security-group For the same reason,
we should avoid changing the API/DB column in FWaaS.[1]
Hence, the generic logging API that set logging configuration is necessary.
[What is the enhancement?]
This spec proposes to create new generic logging API for security-group and
firewall rules in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc).
---------------------------------------------------------------------
Spec: https://review.openstack.org/#/c/203509
---------------------------------------------------------------------
Following (ABANDONED) specs were included this RFE:
* https://review.openstack.org/#/c/132134/
* https://review.openstack.org/#/c/132133/
[1] http://lists.openstack.org/pipermail/openstack-dev/2015-June/068319.html |
[Existing problem]
Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to trouble shooting easier.
Tenant also needs to make sure their security-groups works as expected, and to assess what kinds of events/packets went through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group rules in order to make
the trouble shooting process easier for operators (or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
|
| 2015-11-06 09:50:41 |
Yushiro FURUKAWA |
description |
[Existing problem]
Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to trouble shooting easier.
Tenant also needs to make sure their security-groups works as expected, and to assess what kinds of events/packets went through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group rules in order to make
the trouble shooting process easier for operators (or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
[Existing problem]
- Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to
trouble shooting easier.
- Tenant also needs to make sure their security-groups works as
expected, and to assess what kinds of events/packets went
through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group-rules
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model
extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
|
| 2015-11-06 09:53:22 |
Yushiro FURUKAWA |
summary |
RFE - Logging API for security group and firewall rules |
RFE - Logging API for security group rules |
|
| 2015-11-10 02:21:54 |
Yushiro FURUKAWA |
description |
[Existing problem]
- Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to
trouble shooting easier.
- Tenant also needs to make sure their security-groups works as
expected, and to assess what kinds of events/packets went
through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group-rules
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model
extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
[Existing problem]
- Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to
trouble shooting easier.
- Tenant also needs to make sure their security-groups works as
expected, and to assess what kinds of events/packets went
through their security-groups or were dropped.
[Main purpose of this feature]
* Enable to configure logs for security-group-rules.
* In order to assess what kinds of events/packets went
through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group-rules
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model
extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
|
| 2015-11-10 04:23:57 |
Yushiro FURUKAWA |
description |
[Existing problem]
- Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to
trouble shooting easier.
- Tenant also needs to make sure their security-groups works as
expected, and to assess what kinds of events/packets went
through their security-groups or were dropped.
[Main purpose of this feature]
* Enable to configure logs for security-group-rules.
* In order to assess what kinds of events/packets went
through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group-rules
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model
extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
[Existing problem]
- Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to
auditing easier.
- Tenant also needs to make sure their security-groups works as
expected, and to assess what kinds of events/packets went
through their security-groups or were dropped.
[Main purpose of this feature]
* Enable to configure logs for security-group-rules.
* In order to assess what kinds of events/packets went
through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group-rules
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model
extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
|
| 2015-11-10 15:22:00 |
Armando Migliaccio |
neutron: importance |
High |
Undecided |
|
| 2015-11-10 17:12:50 |
Armando Migliaccio |
tags |
rfe |
rfe-approved |
|
| 2015-11-10 17:12:57 |
Armando Migliaccio |
summary |
RFE - Logging API for security group rules |
Logging API for security group rules |
|
| 2015-11-11 21:22:19 |
Armando Migliaccio |
neutron: importance |
Undecided |
Wishlist |
|
| 2015-11-19 11:37:13 |
Yushiro FURUKAWA |
summary |
Logging API for security group rules |
(Admin-only) Logging API for security group rules |
|
| 2015-11-20 04:12:22 |
Yushiro FURUKAWA |
summary |
(Admin-only) Logging API for security group rules |
(Operator-only) Logging API for security group rules |
|
| 2015-11-24 23:35:01 |
Armando Migliaccio |
neutron: milestone |
|
mitaka-1 |
|
| 2015-12-03 19:20:44 |
Armando Migliaccio |
neutron: milestone |
mitaka-1 |
mitaka-2 |
|
| 2015-12-18 04:47:15 |
Armando Migliaccio |
neutron: status |
Triaged |
Incomplete |
|
| 2015-12-18 04:47:18 |
Armando Migliaccio |
neutron: assignee |
Yushiro FURUKAWA (y-furukawa-2) |
|
|
| 2015-12-18 04:47:21 |
Armando Migliaccio |
neutron: milestone |
mitaka-2 |
|
|
| 2016-02-17 04:17:16 |
Launchpad Janitor |
neutron: status |
Incomplete |
Expired |
|
| 2016-04-05 09:47:48 |
Nguyen Phuong An |
description |
[Existing problem]
- Logging is currently a missing feature in security-groups, it is
necessary for operators (Cloud admins, developers etc) to
auditing easier.
- Tenant also needs to make sure their security-groups works as
expected, and to assess what kinds of events/packets went
through their security-groups or were dropped.
[Main purpose of this feature]
* Enable to configure logs for security-group-rules.
* In order to assess what kinds of events/packets went
through their security-groups or were dropped.
[What is the enhancement?]
- Proposes to create new generic logging API for security-group-rules
in order to make the trouble shooting process easier for operators
(or Cloud admins, developers etc)..
- Introduce layout the logging api model for future API and model
extension for log driver types(rsyslog, ...).
Specification: https://review.openstack.org/#/c/203509 |
Learning what happened on traffic flows is necessary for cloud administrator to tackle a problem related to network.
Problem Description
===================
- When *operator* (including cloud administrator and developer) has an issue related to network (e.g network security issue). Gathering all events related to security groups is necessary for troubleshooting process.
- When tenant or operator deploys a security groups for number of VMs. They want to make sure security group rules work as expected and to assess what kinds of packets went through their security-groups or were dropped.
Currently, we don't have a way to perform that. In other word, logging is a missing feature in security groups.
Proposed Change
===============
- To improve the situation, we'd like to propose a logging API [1]_ to collect all events related to security group rules when they occurred.
- Only *operator* will be allowed to execute logging API.
[1] https://review.openstack.org/#/c/203509/ |
|
| 2016-04-05 09:48:07 |
Nguyen Phuong An |
tags |
rfe-approved |
rfe |
|
| 2016-04-05 09:48:14 |
Nguyen Phuong An |
neutron: status |
Expired |
New |
|
| 2016-04-14 03:12:18 |
Nguyen Phuong An |
description |
Learning what happened on traffic flows is necessary for cloud administrator to tackle a problem related to network.
Problem Description
===================
- When *operator* (including cloud administrator and developer) has an issue related to network (e.g network security issue). Gathering all events related to security groups is necessary for troubleshooting process.
- When tenant or operator deploys a security groups for number of VMs. They want to make sure security group rules work as expected and to assess what kinds of packets went through their security-groups or were dropped.
Currently, we don't have a way to perform that. In other word, logging is a missing feature in security groups.
Proposed Change
===============
- To improve the situation, we'd like to propose a logging API [1]_ to collect all events related to security group rules when they occurred.
- Only *operator* will be allowed to execute logging API.
[1] https://review.openstack.org/#/c/203509/ |
Learning what happened on traffic flows is necessary for cloud administrator to tackle a problem related to network.
Problem Description
===================
- When *operator* (including cloud administrator and developer) has an issue related to network (e.g network security issue). Gathering all events related to security groups is necessary for troubleshooting process.
- When tenant or operator deploys a security groups for number of VMs. They want to make sure security group rules work as expected and to assess what kinds of packets went through their security-groups or were dropped.
Currently, we don't have a way to perform that. In other word, logging is a missing feature in security groups.
Proposed Change
===============
- To improve the situation, we'd like to propose a logging API [1]_ to collect all events related to security group rules when they occurred.
- Only *operator* will be allowed to execute logging API.
- Layout logging API model can extend to other resource such as firewall.
[1] https://review.openstack.org/#/c/203509/ |
|
| 2016-04-14 03:22:46 |
Nguyen Phuong An |
description |
Learning what happened on traffic flows is necessary for cloud administrator to tackle a problem related to network.
Problem Description
===================
- When *operator* (including cloud administrator and developer) has an issue related to network (e.g network security issue). Gathering all events related to security groups is necessary for troubleshooting process.
- When tenant or operator deploys a security groups for number of VMs. They want to make sure security group rules work as expected and to assess what kinds of packets went through their security-groups or were dropped.
Currently, we don't have a way to perform that. In other word, logging is a missing feature in security groups.
Proposed Change
===============
- To improve the situation, we'd like to propose a logging API [1]_ to collect all events related to security group rules when they occurred.
- Only *operator* will be allowed to execute logging API.
- Layout logging API model can extend to other resource such as firewall.
[1] https://review.openstack.org/#/c/203509/ |
Learning what happened on traffic flows is necessary for cloud administrator to tackle a problem related to network.
Problem Description
===================
- When *operator* (including cloud administrator and developer) has an issue related to network (e.g network security issue). Gathering all events related to security groups is necessary for troubleshooting process.
- When tenant or operator deploys a security groups for number of VMs. They want to make sure security group rules work as expected and to assess what kinds of packets went through their security-groups or were dropped.
Currently, we don't have a way to perform that. In other word, logging is a missing feature in security groups.
Proposed Change
===============
- To improve the situation, we'd like to propose a logging API [1]_ to collect all events related to security group rules when they occurred.
- Only *operator* will be allowed to execute logging API.
- Layout the logging API model can extend to other resource such as firewall.
[1] https://review.openstack.org/#/c/203509/ |
|
| 2016-04-14 17:37:02 |
Armando Migliaccio |
neutron: status |
New |
Triaged |
|
| 2016-04-14 17:37:07 |
Armando Migliaccio |
summary |
(Operator-only) Logging API for security group rules |
[RFE] (Operator-only) Logging API for security group rules |
|
| 2016-04-21 08:06:00 |
OpenStack Infra |
neutron: status |
Triaged |
In Progress |
|
| 2016-04-21 08:06:00 |
OpenStack Infra |
neutron: assignee |
|
Nguyen Phuong An (annp) |
|
| 2016-04-29 14:46:45 |
Cao Xuan Hoang |
bug |
|
|
added subscriber Rossella Sblendido |
| 2016-05-12 18:12:04 |
Armando Migliaccio |
tags |
rfe |
rfe-approved |
|
| 2017-01-26 23:44:45 |
Armando Migliaccio |
neutron: milestone |
|
pike-1 |
|
| 2017-02-16 09:09:12 |
zhaobo |
bug |
|
|
added subscriber zhaobo |
| 2017-05-18 01:19:44 |
Armando Migliaccio |
neutron: milestone |
pike-1 |
pike-2 |
|
| 2017-10-09 12:02:35 |
Jakub Libosvar |
neutron: milestone |
pike-2 |
queens-1 |
|
| 2017-10-12 00:40:10 |
Han Zhou |
bug |
|
|
added subscriber Han Zhou |
| 2017-10-30 09:02:37 |
brenda |
bug |
|
|
added subscriber brenda |
| 2018-02-28 22:13:15 |
Akihiro Motoki |
neutron: milestone |
queens-1 |
queens-3 |
|
| 2018-02-28 22:13:20 |
Akihiro Motoki |
neutron: status |
In Progress |
Fix Released |
|
