Activity log for bug #1468366

Date Who What changed Old value New value Message
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