[Yahoo-eng-team] [Bug 1440441] [NEW] "(CIDR)" in Manage Security Group Rules page is no longer needed
Public bug reported: In the column of Remote IP Prefix in Security Group Rules table, values are shown as "0.0.0.0/0 (CIDR)" or "10.56.0.0/24 (CIDR)", but "(CIDR)" is completely unnecessary now. Previously (until Juno) there was "Remote" column, and "(CIDR)" suffix was used to mention a value is "remote IP prefix". However, in Kilo this column was split into "Remote IP Prefix" and "Remote Security Group" columns, and "(CIDR)" suffix is no longer needed and now meaningless. ** Affects: horizon Importance: Low Assignee: Akihiro Motoki (amotoki) Status: In Progress -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1440441 Title: "(CIDR)" in Manage Security Group Rules page is no longer needed Status in OpenStack Dashboard (Horizon): In Progress Bug description: In the column of Remote IP Prefix in Security Group Rules table, values are shown as "0.0.0.0/0 (CIDR)" or "10.56.0.0/24 (CIDR)", but "(CIDR)" is completely unnecessary now. Previously (until Juno) there was "Remote" column, and "(CIDR)" suffix was used to mention a value is "remote IP prefix". However, in Kilo this column was split into "Remote IP Prefix" and "Remote Security Group" columns, and "(CIDR)" suffix is no longer needed and now meaningless. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1440441/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440442] [NEW] "-" in "Port Range" column of Security Group Rule table is confusing
Public bug reported: In the security group rule table (Manage Security Group Rules), '-' has two meaning. In "Port Range" column, '-' means "Any". In "Remote IP prefix" and "Remote Security Group" columns, '-' means that the corresponding fields has no effect. I would suggest to change '-' in "Port Range" column to "Any" to match other columns like "IP Protocol". ** Affects: horizon Importance: Low Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1440442 Title: "-" in "Port Range" column of Security Group Rule table is confusing Status in OpenStack Dashboard (Horizon): New Bug description: In the security group rule table (Manage Security Group Rules), '-' has two meaning. In "Port Range" column, '-' means "Any". In "Remote IP prefix" and "Remote Security Group" columns, '-' means that the corresponding fields has no effect. I would suggest to change '-' in "Port Range" column to "Any" to match other columns like "IP Protocol". To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1440442/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440309] Re: Fwaas - update/create firewall will use the associated policy no matter whether it's audited or not
That's better to be discussed with fwaas team first. Description doesn't look like a valid bug report. ** Changed in: neutron Status: New => Opinion -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1440309 Title: Fwaas - update/create firewall will use the associated policy no matter whether it's audited or not Status in OpenStack Neutron (virtual network service): Opinion Bug description: New Firewall Rules cannot be directly added to a virtual Firewall. The rules have to be first added to a Firewall Policy and the Firewall Policy has to be reapplied for the rules to take effect This two step process allows the Firewall Policy to be audited after the new rules are added and before the policy is reapplied to a Firewall However in implementation, create/update firewall will use the associated firewall policy no matter whether it's audited or not which makes all the design decisions meaningless I consider the right implementation is similar to git workflow. 1. The audited firewall policy is the master branch and create/update firewall can only use the master branch. 2. A modification to a firewall policy is just like a feature branch. Once set its audited attribute to True, it got merged back into master branch So this implies: 1. Create a firewall policy must have audited set to True 2. we should support version control for firewall policy, so rollback is available It's a lot of work to do which suggests that we rethink about the necessarity of audition To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1440309/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1039304] Re: make ip + interface util apis indepedent of DictModel
This probably is too old report to be relevant for current project status ** Changed in: neutron Status: In Progress => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1039304 Title: make ip + interface util apis indepedent of DictModel Status in OpenStack Neutron (virtual network service): Won't Fix Bug description: I noticed at least one agent library method (get_device_name() in interface.py) that seems to depend on the DictModel stuff from the DHCP work. These APIs should be independent of DictModel, and if a data representation of a port needs to be passed, it should just be the standard dictionary formats for port/network/subnet. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1039304/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1397489] Re: VM boot failure since nova to neutron port notification fails
This is a problem of keystone which in turn causes failures in neutron-nova communication. I don't think neutron can be fixed to avoid this. ** Changed in: neutron Status: In Progress => Confirmed ** Changed in: neutron Status: Confirmed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1397489 Title: VM boot failure since nova to neutron port notification fails Status in OpenStack Neutron (virtual network service): Invalid Bug description: When I run the latest devstack and use nova boot to create a VM,but it failed. Nova show the VM,it show:"message": "Build of instance cb509a04-ca8a- 491f-baf1-be01b15f4946 aborted: Failed to allocate the network(s), not rescheduling.", "code": 500, "details": " File \"/opt/stack/nova/nova/compute/manager.py\", line 2030, in _do_build_and_run_instance and the following error in the nova-compute.log: Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 1714, in _spawn block_device_info) File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 2266, in spawn block_device_info) File "/usr/lib/python2.7/dist-packages/nova/virt/libvirt/driver.py", line 3681, in _create_domain_and_network raise exception.VirtualInterfaceCreateException() VirtualInterfaceCreateException: Virtual Interface creation failed Adding "vif_plugging_is_fatal = False" and "vif_plugging_timeout = 5" to the compute nodes stops the missing message from being fatal and guests can then be spawned normally and accessed over the network. In the bug: https://bugs.launchpad.net/nova/+bug/1348103 says it happened in cells environment,but it doesn't happen only in cells environment.This problem should arouse our attention more. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1397489/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440309] [NEW] Fwaas - update/create firewall will use the associated policy no matter whether it's audited or not
Public bug reported: New Firewall Rules cannot be directly added to a virtual Firewall. The rules have to be first added to a Firewall Policy and the Firewall Policy has to be reapplied for the rules to take effect This two step process allows the Firewall Policy to be audited after the new rules are added and before the policy is reapplied to a Firewall However in implementation, create/update firewall will use the associated firewall policy no matter whether it's audited or not which makes all the design decisions meaningless I consider the right implementation is similar to git workflow. 1. The audited firewall policy is the master branch and create/update firewall can only use the master branch. 2. A modification to a firewall policy is just like a feature branch. Once set its audited attribute to True, it got merged back into master branch So this implies: 1. Create a firewall policy must have audited set to True 2. we should support version control for firewall policy, so rollback is available It's a lot of work to do which suggests that we rethink about the necessarity of audition ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1440309 Title: Fwaas - update/create firewall will use the associated policy no matter whether it's audited or not Status in OpenStack Neutron (virtual network service): New Bug description: New Firewall Rules cannot be directly added to a virtual Firewall. The rules have to be first added to a Firewall Policy and the Firewall Policy has to be reapplied for the rules to take effect This two step process allows the Firewall Policy to be audited after the new rules are added and before the policy is reapplied to a Firewall However in implementation, create/update firewall will use the associated firewall policy no matter whether it's audited or not which makes all the design decisions meaningless I consider the right implementation is similar to git workflow. 1. The audited firewall policy is the master branch and create/update firewall can only use the master branch. 2. A modification to a firewall policy is just like a feature branch. Once set its audited attribute to True, it got merged back into master branch So this implies: 1. Create a firewall policy must have audited set to True 2. we should support version control for firewall policy, so rollback is available It's a lot of work to do which suggests that we rethink about the necessarity of audition To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1440309/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1440297] [NEW] Create Volume from Snapshot / Image creates empty volume
Public bug reported: When creating a volume from snapshot or image in current version of horizon the operation apparantly succeeds but the created volume does not contain any data. Examining the request sent to Horizon shows that the snapshot_id / image_id is present. Examining the request to Cinder API shows that the snapshot_id / image_id is NOT present. I have tracked this down to the tests done in the handle fucntion in openstack_dashboard/dashboards/project/volumes/volumes/forms.py around line 309. The tests expects source_type (retrieved from data['volume_source_type']) to either be None or 'snapshot_source' / 'image_source'. This is also supported by the prepare_source_fields_if_XXX functions. However, when the actual data reaches the function 'volume_source_type' is set to '' (empty string) and not None. I am not sure if it is the test that is wrong or if the data gets changed unexpectedly on the way into the function by other parts of the code. Running on Ubuntu 14.04 LTS with packages from the Kilo Cloud archive. ** Affects: horizon Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1440297 Title: Create Volume from Snapshot / Image creates empty volume Status in OpenStack Dashboard (Horizon): New Bug description: When creating a volume from snapshot or image in current version of horizon the operation apparantly succeeds but the created volume does not contain any data. Examining the request sent to Horizon shows that the snapshot_id / image_id is present. Examining the request to Cinder API shows that the snapshot_id / image_id is NOT present. I have tracked this down to the tests done in the handle fucntion in openstack_dashboard/dashboards/project/volumes/volumes/forms.py around line 309. The tests expects source_type (retrieved from data['volume_source_type']) to either be None or 'snapshot_source' / 'image_source'. This is also supported by the prepare_source_fields_if_XXX functions. However, when the actual data reaches the function 'volume_source_type' is set to '' (empty string) and not None. I am not sure if it is the test that is wrong or if the data gets changed unexpectedly on the way into the function by other parts of the code. Running on Ubuntu 14.04 LTS with packages from the Kilo Cloud archive. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1440297/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
