[Yahoo-eng-team] [Bug 1317792] [NEW] XenAPI: Race - import followed by upload / waiting for snapshot coalesce
Public bug reported: In a nutshell, so everyone doesn't have to read the rest of the bug description: If a tree is imported with more than two VDIs, then the _snapshot_attached_here method will never succeed as the condition it is waiting for (the parent being equal to the original parent again) will not occur. The following tree is imported from glance: May 8 13:41:10 localhost SMGC: [14336] *814ea7ed(40.000M/40.079M) May 8 13:41:10 localhost SMGC: [14336] *863cc348(40.000M/2.008M) May 8 13:41:10 localhost SMGC: [14336] eccebf0b(40.000M/2.008M) If we immediately try to perform an operation that uses a snapshot (e.g. resize), we get the 'original' parent as 863cc348 - which means that later we will expect 863cc348 to be the new parent: 2014-05-08 13:41:23.769 DEBUG nova.virt.xenapi.vm_utils [req-62887aaa-cd8a-43d1-841a-bd1c144a0155 ServerDiskConfigTestJSON-620298595 ServerDiskConfigTestJSON-1956337666] VHD eccebf0b-00b9-4df5-b558-8feaf835e850 has parent 863cc348-7a28-4dd0-a976-142eb887256c from (pid=19364) _get_vhd_parent_uuid /opt/stack/nova/nova/virt/xenapi/vm_utils.py:2026 We then take a snapshot and wait for coalesce so we have as few VHDs in the chain as possible: May 8 13:41:24 localhost SM: [24744] ['/usr/sbin/td-util', 'snapshot', 'vhd', '/var/run/sr-mount/16e0a27c-007c-d083-7459-ee038c92f8a4/eccebf0b-00b9-4df5-b558-8feaf835e850.vhd', '151c921e-dc28-4a66-b286-65cd43bf9a6f.vhd'] 2014-05-08 13:41:26.688 DEBUG nova.virt.xenapi.vm_utils [req-62887aaa-cd8a-43d1-841a-bd1c144a0155 ServerDiskConfigTestJSON-620298595 ServerDiskConfigTestJSON-1956337666] VHD eccebf0b-00b9-4df5-b558-8feaf835e850 has parent 151c921e-dc28-4a66-b286-65cd43bf9a6f from (pid=19364) _get_vhd_parent_uuid /opt/stack/nova/nova/virt/xenapi/vm_utils.py:2026 2014-05-08 13:41:26.688 DEBUG nova.virt.xenapi.vm_utils [req-62887aaa-cd8a-43d1-841a-bd1c144a0155 ServerDiskConfigTestJSON-620298595 ServerDiskConfigTestJSON-1956337666] [instance: 7f8db936-9634-47db-852e-7a43bbc992eb] Parent 151c921e-dc28-4a66-b286-65cd43bf9a6f doesn't match original parent 863cc348-7a28-4dd0-a976-142eb887256c, waiting for coalesce... from (pid=19364) _wait_for_vhd_coalesce /opt/stack/nova/nova/virt/xenapi/vm_utils.py:2119 The snapshot has the effect of creating two children (ecce is the one we're referencing and b554 keeps the snapshot from being deleted): May 8 13:41:34 localhost SMGC: [14336] *814ea7ed(40.000M/40.079M) May 8 13:41:34 localhost SMGC: [14336] *863cc348(40.000M/2.008M) May 8 13:41:34 localhost SMGC: [14336] *151c921e(40.000M/14.032M) May 8 13:41:34 localhost SMGC: [14336] b55436a7(40.000M/5.000K) May 8 13:41:34 localhost SMGC: [14336] eccebf0b(40.000M/4.012M) Coalescing then happens, destroying first 863cc348 then 151c921, merging the differences up the chain into 814ea7ed: May 8 13:41:59 localhost SMGC: [14336] *814ea7ed(40.000M/40.079M) May 8 13:41:59 localhost SMGC: [14336] *863cc348(40.000M/2.008M) May 8 13:41:59 localhost SMGC: [14336] *151c921e(40.000M/14.032M) May 8 13:41:59 localhost SMGC: [14336] b55436a7(40.000M/5.000K) May 8 13:41:59 localhost SMGC: [14336] eccebf0b(40.000M/16.036M) May 8 13:42:11 localhost SMGC: [14336] *814ea7ed(40.000M/40.079M) May 8 13:42:11 localhost SMGC: [14336] *151c921e(40.000M/14.032M) May 8 13:42:11 localhost SMGC: [14336] b55436a7(40.000M/5.000K) May 8 13:42:11 localhost SMGC: [14336] eccebf0b(40.000M/16.036M) May 8 13:42:36 localhost SMGC: [5186] *814ea7ed(40.000M/40.079M) May 8 13:42:36 localhost SMGC: [5186] b55436a7(40.000M/5.000K) May 8 13:42:36 localhost SMGC: [5186] eccebf0b(40.000M/16.036M) During this time, we're waiting for coalesce and checking the parent. Eventually we get: 2014-05-08 13:42:41.981 DEBUG nova.virt.xenapi.vm_utils [req-62887aaa-cd8a-43d1-841a-bd1c144a0155 ServerDiskConfigTestJSON-620298595 ServerDiskConfigTestJSON-1956337666] VHD eccebf0b-00b9-4df5-b558-8feaf835e850 has parent 814ea7ed-4b99-44cc-8e89-1a8d2e5509bd from (pid=19364) _get_vhd_parent_uuid /opt/stack/nova/nova/virt/xenapi/vm_utils.py:2026 2014-05-08 13:42:41.982 DEBUG nova.virt.xenapi.vm_utils [req-62887aaa-cd8a-43d1-841a-bd1c144a0155 ServerDiskConfigTestJSON-620298595 ServerDiskConfigTestJSON-1956337666] [instance: 7f8db936-9634-47db-852e-7a43bbc992eb] Parent 814ea7ed-4b99-44cc-8e89-1a8d2e5509bd doesn't match original parent 863cc348-7a28-4dd0-a976-142eb887256c, waiting for coalesce... from (pid=19364) _wait_for_vhd_coalesce /opt/stack/nova/nova/virt/xenapi/vm_utils.py:2119 2014-05-08 13:44:00.678 ERROR nova.virt.xenapi.vmops [req-62887aaa-cd8a- 43d1-841a-bd1c144a0155 ServerDiskConfigTestJSON-620298595 ServerDiskConfigTestJSON-1956337666] [instance: 7f8db936-9634-47db-852e- 7a43bbc992eb]
[Yahoo-eng-team] [Bug 1317794] [NEW] Complete translations are too big
Public bug reported: From http://lists.openstack.org/pipermail/openstack- i18n/2014-May/000594.html: I've come across this review for automated translations coming into Horizon https://review.openstack.org/#/c/91523/ It concerns me that it has over a half million LOC in it, and many of these languages have near 0 translation. (I checked here: https://www.transifex.com/projects/p/horizon/). 0 translation languages have just as many lines as full translations; they are just shorter. The proposal in the thread is: 1) Our translation jobs will only download files that have at least 75 % translated 2) Projects can delete (and I'm going to propose patches) files that currently have less than 75 % translated ** Affects: horizon Importance: Undecided Status: New ** Affects: openstack-i18n Importance: Undecided Assignee: Andreas Jaeger (jaegerandi) Status: In Progress ** Affects: openstack-manuals Importance: High Assignee: Andreas Jaeger (jaegerandi) Status: Confirmed ** Also affects: openstack-i18n Importance: Undecided Status: New ** Also affects: horizon Importance: Undecided Status: New ** Changed in: openstack-manuals Assignee: (unassigned) = Andreas Jaeger (jaegerandi) ** Changed in: openstack-i18n Assignee: (unassigned) = Andreas Jaeger (jaegerandi) ** Changed in: openstack-manuals Status: New = Confirmed ** Changed in: openstack-i18n Status: New = Confirmed ** Changed in: openstack-i18n Status: Confirmed = 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/1317794 Title: Complete translations are too big Status in OpenStack Dashboard (Horizon): New Status in OpenStack I18n L10n: In Progress Status in OpenStack Manuals: Confirmed Bug description: From http://lists.openstack.org/pipermail/openstack- i18n/2014-May/000594.html: I've come across this review for automated translations coming into Horizon https://review.openstack.org/#/c/91523/ It concerns me that it has over a half million LOC in it, and many of these languages have near 0 translation. (I checked here: https://www.transifex.com/projects/p/horizon/). 0 translation languages have just as many lines as full translations; they are just shorter. The proposal in the thread is: 1) Our translation jobs will only download files that have at least 75 % translated 2) Projects can delete (and I'm going to propose patches) files that currently have less than 75 % translated To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1317794/+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 1317804] [NEW] InstanceActionEvent traceback parameter not serializable
Public bug reported: The change to use InstanceActionEvent objects in compute.utils.EventReporter changed the order of how things are done. Before, traceback info were converted to strings before being sent to the conductor. Now, since the object method being used remotes itself, the order becomes the opposite and any captured tracebacks are sent as is, resulting in errors during messaging. See http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVmFsdWVFcnJvcjogQ2lyY3VsYXIgcmVmZXJlbmNlIGRldGVjdGVkXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjkwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjEzOTk2MjYzMjYwODZ9 ** Affects: nova Importance: Critical Assignee: Hans Lindgren (hanlind) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1317804 Title: InstanceActionEvent traceback parameter not serializable Status in OpenStack Compute (Nova): New Bug description: The change to use InstanceActionEvent objects in compute.utils.EventReporter changed the order of how things are done. Before, traceback info were converted to strings before being sent to the conductor. Now, since the object method being used remotes itself, the order becomes the opposite and any captured tracebacks are sent as is, resulting in errors during messaging. See http://logstash.openstack.org/#eyJzZWFyY2giOiJtZXNzYWdlOlwiVmFsdWVFcnJvcjogQ2lyY3VsYXIgcmVmZXJlbmNlIGRldGVjdGVkXCIiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6IjkwMCIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJ1c2VyX2ludGVydmFsIjowfSwic3RhbXAiOjEzOTk2MjYzMjYwODZ9 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1317804/+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 1317803] [NEW] host listed under host aggregate has a bullet near them
Public bug reported: the host's are in a table and have bullets near each host which looks like its coming from the table on the left. I'm using firefox: firefox-17.0.10-1.el6_4.x86_64 python-django-horizon-2014.1-4.el7ost.noarch ** Affects: horizon Importance: Undecided Status: New ** Attachment added: screen shot https://bugs.launchpad.net/bugs/1317803/+attachment/4108495/+files/bullets.png -- 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/1317803 Title: host listed under host aggregate has a bullet near them Status in OpenStack Dashboard (Horizon): New Bug description: the host's are in a table and have bullets near each host which looks like its coming from the table on the left. I'm using firefox: firefox-17.0.10-1.el6_4.x86_64 python-django-horizon-2014.1-4.el7ost.noarch To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1317803/+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 1317815] [NEW] Documetation Keystone SSL configuration lack
Public bug reported: Trying to configuring SSL on OpenStack Havana I read the official documentation here https://github.com/openstack/keystone/blob/stable/havana/doc/source/configuration.rst#ssl But I think that configuration is not enough to configure SSL on OpenStack. As far I know, to configure SSL on OpenStack, besides the configuration above, it is necessary to modify endpoints protocol from http to https and this is not documented on the official SSL Configuration document. Please, confirm if I'm wrong. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1317815 Title: Documetation Keystone SSL configuration lack Status in OpenStack Identity (Keystone): New Bug description: Trying to configuring SSL on OpenStack Havana I read the official documentation here https://github.com/openstack/keystone/blob/stable/havana/doc/source/configuration.rst#ssl But I think that configuration is not enough to configure SSL on OpenStack. As far I know, to configure SSL on OpenStack, besides the configuration above, it is necessary to modify endpoints protocol from http to https and this is not documented on the official SSL Configuration document. Please, confirm if I'm wrong. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1317815/+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 1317817] [NEW] change mbformat to float_mbformat in hypervisor table
Public bug reported: In hypervisor table, if you have total of 3.8GB of memory, it show 3GB. Need to change mbformat to float_mbformat. ** Affects: horizon Importance: Undecided Assignee: tinytmy (tangmeiyan77) Status: New ** Changed in: horizon Assignee: (unassigned) = tinytmy (tangmeiyan77) -- 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/1317817 Title: change mbformat to float_mbformat in hypervisor table Status in OpenStack Dashboard (Horizon): New Bug description: In hypervisor table, if you have total of 3.8GB of memory, it show 3GB. Need to change mbformat to float_mbformat. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1317817/+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 1317831] [NEW] debug level logs should not be translated
Public bug reported: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1317831 Title: debug level logs should not be translated Status in OpenStack Identity (Keystone): New Bug description: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1317831/+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 1317834] [NEW] Restore GARP for floating IPs by default
Public bug reported: Commit 591ee00a set the number of gratuitous ARP sent to advertise a floating IP to 0. This was because arping was triggering the kernel bug which was the root cause of bug 1273386 Now that the bug has been root caused, we can restore GARP. ** Affects: neutron Importance: Medium Assignee: Salvatore Orlando (salvatore-orlando) Status: In Progress ** Tags: l3-ipam-dhcp -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1317834 Title: Restore GARP for floating IPs by default Status in OpenStack Neutron (virtual network service): In Progress Bug description: Commit 591ee00a set the number of gratuitous ARP sent to advertise a floating IP to 0. This was because arping was triggering the kernel bug which was the root cause of bug 1273386 Now that the bug has been root caused, we can restore GARP. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1317834/+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 1317838] [NEW] unable to evacuate on shared storage
Public bug reported: debian testing 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 GNU/Linux libvirt 1.2.4 nova-compute 2014.1-4 shared storage on cinder with ceph Basicly, when I'm running nova evacuate instance id host id --on- shared-storage program exits with code 0. You can find all attached command and log output in gist - https://gist.github.com/szymonpk/de6380ac24caba8792b1. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1317838 Title: unable to evacuate on shared storage Status in OpenStack Compute (Nova): New Bug description: debian testing 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 GNU/Linux libvirt 1.2.4 nova-compute 2014.1-4 shared storage on cinder with ceph Basicly, when I'm running nova evacuate instance id host id --on- shared-storage program exits with code 0. You can find all attached command and log output in gist - https://gist.github.com/szymonpk/de6380ac24caba8792b1. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1317838/+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 1317839] [NEW] inconsistency between 'Image Name' output when booting from volumes
Public bug reported: I created two volumes from two different images: one image was qcow and one was raw. when I boot instances from the volumes, the 'Image Name' field under instances has '(not found)' for instance booted from one volume and '-' for the instance booted from the second volume (see screenshot) ** Affects: horizon Importance: Undecided Status: New ** Attachment added: screen shot https://bugs.launchpad.net/bugs/1317839/+attachment/4108540/+files/image_name.png ** Summary changed: - inconsistancy between 'Image Name' output when booting from volumes + inconsistency between 'Image Name' output when booting from volumes -- 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/1317839 Title: inconsistency between 'Image Name' output when booting from volumes Status in OpenStack Dashboard (Horizon): New Bug description: I created two volumes from two different images: one image was qcow and one was raw. when I boot instances from the volumes, the 'Image Name' field under instances has '(not found)' for instance booted from one volume and '-' for the instance booted from the second volume (see screenshot) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1317839/+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 1317847] [NEW] debug level logs should not be translated
Public bug reported: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1317847 Title: debug level logs should not be translated Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1317847/+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 1317851] [NEW] debug level logs should not be translated
Public bug reported: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. ** 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/1317851 Title: debug level logs should not be translated Status in OpenStack Neutron (virtual network service): New Bug description: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1317851/+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 1317854] [NEW] nova api error Malformed request URL: URL's project_id '$project_id' doesn't match Context's project_id '$request_token'
Public bug reported: Folk in TripleO are seeing nova list fail with an error about Malformed url - but the claimed context.project_id has the same context as the request token novaclient is given by keystone. sample trace at http://paste.ubuntu.com/7420801/ (nova --debug list) (and throwaway setup :)) ** Affects: nova Importance: Undecided Status: New ** Affects: tripleo Importance: Critical Status: Triaged ** Description changed: Folk in TripleO are seeing nova list fail with an error about Malformed url - but the claimed context.project_id has the same context as the request token novaclient is given by keystone. + + sample trace at http://paste.ubuntu.com/7420801/ (nova --debug list) + (and throwaway setup :)) ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1317854 Title: nova api error Malformed request URL: URL's project_id '$project_id' doesn't match Context's project_id '$request_token' Status in OpenStack Compute (Nova): New Status in tripleo - openstack on openstack: Triaged Bug description: Folk in TripleO are seeing nova list fail with an error about Malformed url - but the claimed context.project_id has the same context as the request token novaclient is given by keystone. sample trace at http://paste.ubuntu.com/7420801/ (nova --debug list) (and throwaway setup :)) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1317854/+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 1317870] [NEW] LBAAS :Lbaas conf on network node doesnot reflect the correct mode for https
Public bug reported: Steps to Reproduce: Setup onto ICEHouse GA: Build :2014.1-0ubuntu1~cloud0 1. Create a lbaas site with one client and two web server. 2. Create pool with protocol as https +--+---+-+--+++ | id | name | lb_method | protocol | admin_state_up | status | +--+---+-+--+++ | aebd47e9-d125-49f6-aef2-2a97954c051a | pool1 | ROUND_ROBIN | HTTPS| True | ACTIVE | +--+---+-+--+++ 3. Create a health monitor for type https +--+---++ | id | type | admin_state_up | +--+---++ | affb69f6-e6b0-4f34-ab42-a89acecc60b3 | HTTPS | True | +--+---++ 4. Create vip with protocol port as 443 and protocol as HTTPS +--+--+---+--+++ | id | name | address | protocol | admin_state_up | status | +--+--+---+--+++ | 405609a8-0e50-4d2c-a7b5-ab206290303d | | 10.10.1.6 | HTTPS| True | ACTIVE | +--+--+---+--+++ 5. Varify the same onto network node lbaas.conf file. Actual Results: vi var/lib/neutron/lbaas/aebd47e9-d125-49f6-aef2-2a97954c051a/conf global daemon user nobody group haproxy log /dev/log local0 log /dev/log local1 notice stats socket /var/lib/neutron/lbaas/aebd47e9-d125-49f6-aef2-2a97954c051a/sock mode 0666 level user defaults log global retries 3 option redispatch timeout connect 5000 timeout client 5 timeout server 5 frontend 405609a8-0e50-4d2c-a7b5-ab206290303d option tcplog bind 10.10.1.6:443 mode tcp default_backend aebd47e9-d125-49f6-aef2-2a97954c051a backend aebd47e9-d125-49f6-aef2-2a97954c051a mode tcp balance roundrobin timeout check 1s option httpchk GET / http-check expect rstatus 200 option ssl-hello-chk server dd7a7f63-9218-4d21-b8f8-967018a3ae9f 10.10.1.4:443 weight 2 check inter 4s fall 3 server f844e226-4c3f-4351-9750-7cb14f614c3c 10.10.1.5:443 weight 2 check inter 4s fall 3 Expected Results: for http: we have mod as http global daemon user nobody group haproxy log /dev/log local0 log /dev/log local1 notice stats socket /var/lib/neutron/lbaas/0e0577c1-d58b-4c82-84aa-a7a2da2b33b7/sock mode 0666 level user defaults log global retries 3 option redispatch timeout connect 5000 timeout client 5 timeout server 5 frontend 6fdb8775-101b-49f8-a466-5d2919dda13f option tcplog bind 10.10.1.6:80 mode http default_backend 0e0577c1-d58b-4c82-84aa-a7a2da2b33b7 option forwardfor backend 0e0577c1-d58b-4c82-84aa-a7a2da2b33b7 mode http balance roundrobin option forwardfor timeout check 1s option httpchk GET / http-check expect rstatus 200 server 1343e8c8-ed87-4fc5-a927-a5e1bd0ae61b 10.10.1.5:80 weight 2 check inter 4s fall 3 server 8c2187b5-8c70-40f7-b41e-98c3a2ef8470 10.10.1.4:80 weight 2 check inter 4s fall 3 Similarly for https it should be https. ** 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/1317870 Title: LBAAS :Lbaas conf on network node doesnot reflect the correct mode for https Status in OpenStack Neutron (virtual network service): New Bug description: Steps to Reproduce: Setup onto ICEHouse GA: Build :2014.1-0ubuntu1~cloud0 1. Create a lbaas site with one client and two web server. 2. Create pool with protocol as https +--+---+-+--+++ | id | name | lb_method | protocol | admin_state_up | status | +--+---+-+--+++ | aebd47e9-d125-49f6-aef2-2a97954c051a | pool1 | ROUND_ROBIN | HTTPS
[Yahoo-eng-team] [Bug 1317871] [NEW] LBAAS :Deletion of pool is not deleting the lbaas pool directory/folder structure from the network node but files are getting deleted
Public bug reported: Steps to Reproduce: Setup onto ICEHouse GA: Build :2014.1-0ubuntu1~cloud0 Steps to Reproduce: 1. Create a lbaas site. (Pool,member,vip,health monitor) 2. Check the configuration onto the network node under /var/lib/neutron/lbaas/$Pool_id/ conf pid sock 3. Delete all the lbaas and neutron resource created onto the controller. 4. Check the configuration onto the network node. Actual Results: Directory structure for the pool id remain as its but the files got delete Expected Results: all the configuration and files/folder should get deleted after deletion of lbaas resource. Note: Working in Havana GA release. ** Affects: neutron Importance: Undecided Status: New ** Attachment added: conf_delete.png https://bugs.launchpad.net/bugs/1317871/+attachment/4108617/+files/conf_delete.png -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1317871 Title: LBAAS :Deletion of pool is not deleting the lbaas pool directory/folder structure from the network node but files are getting deleted Status in OpenStack Neutron (virtual network service): New Bug description: Steps to Reproduce: Setup onto ICEHouse GA: Build :2014.1-0ubuntu1~cloud0 Steps to Reproduce: 1. Create a lbaas site. (Pool,member,vip,health monitor) 2. Check the configuration onto the network node under /var/lib/neutron/lbaas/$Pool_id/ conf pid sock 3. Delete all the lbaas and neutron resource created onto the controller. 4. Check the configuration onto the network node. Actual Results: Directory structure for the pool id remain as its but the files got delete Expected Results: all the configuration and files/folder should get deleted after deletion of lbaas resource. Note: Working in Havana GA release. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1317871/+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 1317868] [NEW] LBAAS :Member with protocol port as HTTPS is not coming in active state for Lbaas site
Public bug reported: Steps to Reproduce: Setup onto ICEHouse GA: Build :2014.1-0ubuntu1~cloud0 1. Create a lbaas site with one client and two web server. 2. Create pool with protocol as https +--+---+-+--+++ | id | name | lb_method | protocol | admin_state_up | status | +--+---+-+--+++ | aebd47e9-d125-49f6-aef2-2a97954c051a | pool1 | ROUND_ROBIN | HTTPS| True | ACTIVE | +--+---+-+--+++ 3. Create a health monitor for type https +--+---++ | id | type | admin_state_up | +--+---++ | affb69f6-e6b0-4f34-ab42-a89acecc60b3 | HTTPS | True | +--+---++ 4. Create vip with protocol port as 443 and protocol as HTTPS +--+--+---+--+++ | id | name | address | protocol | admin_state_up | status | +--+--+---+--+++ | 405609a8-0e50-4d2c-a7b5-ab206290303d | | 10.10.1.6 | HTTPS| True | ACTIVE | +--+--+---+--+++ 5. list the lbaas member status: +--+---+---++--+ | id | address | protocol_port | admin_state_up | status | +--+---+---++--+ | dd7a7f63-9218-4d21-b8f8-967018a3ae9f | 10.10.1.4 | 443 | True | INACTIVE | | f844e226-4c3f-4351-9750-7cb14f614c3c | 10.10.1.5 | 443 | True | INACTIVE | +--+---+---++--+ Actual Results: list the lbaas member status: +--+---+---++--+ | id | address | protocol_port | admin_state_up | status | +--+---+---++--+ | dd7a7f63-9218-4d21-b8f8-967018a3ae9f | 10.10.1.4 | 443 | True | INACTIVE | | f844e226-4c3f-4351-9750-7cb14f614c3c | 10.10.1.5 | 443 | True | INACTIVE | +--+---+---++--+ Expected Results: Members should come in active state after the successfull creation of lbaas ** Affects: neutron Importance: Undecided Status: New ** Description changed: - Steps to Reproduce: - Setup onto Havana GA stable build + Steps to Reproduce: + Setup onto ICEHouse GA1: + Build :2014.1-0ubuntu1~cloud0 1. Create a lbaas site with one client and two web server. 2. Create pool with protocol as https +--+---+-+--+++ | id | name | lb_method | protocol | admin_state_up | status | +--+---+-+--+++ | aebd47e9-d125-49f6-aef2-2a97954c051a | pool1 | ROUND_ROBIN | HTTPS| True | ACTIVE | +--+---+-+--+++ - + 3. Create a health monitor for type https +--+---++ | id | type | admin_state_up | +--+---++ | affb69f6-e6b0-4f34-ab42-a89acecc60b3 | HTTPS | True | +--+---++ - + 4. Create vip with protocol port as 443 and protocol as HTTPS +--+--+---+--+++ | id | name | address | protocol | admin_state_up | status | +--+--+---+--+++ | 405609a8-0e50-4d2c-a7b5-ab206290303d | | 10.10.1.6 | HTTPS| True | ACTIVE | +--+--+---+--+++ 5. list the lbaas member status: +--+---+---++--+ | id | address | protocol_port |
[Yahoo-eng-team] [Bug 1317875] [NEW] debug level logs should not be translated
Public bug reported: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. ** 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/1317875 Title: debug level logs should not be translated Status in OpenStack Neutron (virtual network service): New Bug description: According to the OpenStack translation policy, available at https://wiki.openstack.org/wiki/LoggingStandards, debug messages should not be translated. Like mentioned in several changes in Nova by garyk this is to help prioritize log translation. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1317875/+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 1317854] Re: nova api error Malformed request URL: URL's project_id '$project_id' doesn't match Context's project_id '$request_token'
** No longer affects: nova -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1317854 Title: nova api error Malformed request URL: URL's project_id '$project_id' doesn't match Context's project_id '$request_token' Status in tripleo - openstack on openstack: In Progress Bug description: Folk in TripleO are seeing nova list fail with an error about Malformed url - but the claimed context.project_id has the same context as the request token novaclient is given by keystone. sample trace at http://paste.ubuntu.com/7420801/ (nova --debug list) (and throwaway setup :)) To manage notifications about this bug go to: https://bugs.launchpad.net/tripleo/+bug/1317854/+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 1317880] [NEW] Boot from image (creates a new volume) starts an instance with no image
Public bug reported: 1. Fire up a DevStack instance from the stable/havana, stable/icehouse, or master branches. 2. Go into Horizon 3. Launch an instance 3.1 Instance Boot Source: Boot from image (creates a new volume) 3.2 Image Name: cirros 3.3 Device size (GB): 1 When the instance finishes booting you’ll see that the instance only has a ‘-‘ in the Image Name column. If you click on the instance you’ll see in the Overview Meta section “Image Name (not found)”. My understanding of Boot from image (creates a new volume) is that it simply creates a instance and attaches a volume automatically. It’s basically a convenience for the user. Is that right? Seems the bug is in Nova as the instance was created with the cirros image and Nova isn’t reporting that fact back. The different responses from various clients. API curl .../v2/tenant_id/servers/server_id image: “” python-novaclient nova show server_id Attempt to boot from volume - no image supplied” Horizon Image Name (not found) I suspect Horizon is making some bad calls but Nova shouldn’t be allowing an instance to get into this state. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1317880 Title: Boot from image (creates a new volume) starts an instance with no image Status in OpenStack Compute (Nova): New Bug description: 1. Fire up a DevStack instance from the stable/havana, stable/icehouse, or master branches. 2. Go into Horizon 3. Launch an instance 3.1 Instance Boot Source: Boot from image (creates a new volume) 3.2 Image Name: cirros 3.3 Device size (GB): 1 When the instance finishes booting you’ll see that the instance only has a ‘-‘ in the Image Name column. If you click on the instance you’ll see in the Overview Meta section “Image Name (not found)”. My understanding of Boot from image (creates a new volume) is that it simply creates a instance and attaches a volume automatically. It’s basically a convenience for the user. Is that right? Seems the bug is in Nova as the instance was created with the cirros image and Nova isn’t reporting that fact back. The different responses from various clients. API curl .../v2/tenant_id/servers/server_id image: “” python-novaclient nova show server_id Attempt to boot from volume - no image supplied” Horizon Image Name (not found) I suspect Horizon is making some bad calls but Nova shouldn’t be allowing an instance to get into this state. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1317880/+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 1317913] [NEW] it would be helpful to add the current volume size to the extend volume box
Public bug reported: when we extend a volume a new box is opened. it would be helpful if we add the current volume size to the new box. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: screen shot https://bugs.launchpad.net/bugs/1317913/+attachment/4108691/+files/size.png -- 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/1317913 Title: it would be helpful to add the current volume size to the extend volume box Status in OpenStack Dashboard (Horizon): New Bug description: when we extend a volume a new box is opened. it would be helpful if we add the current volume size to the new box. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1317913/+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 1317912] [NEW] VMware: get_info() fails if properties are missing
Public bug reported:
The properties that we retrieve from VirtualMachineConfigSummary are
optional and if they are missing get_info() throws an exception
(tracebacks below). We should use default values when the properties
are not available.
stack/common/vmware/vim.py:126
2014-05-06 21:52:44.485 421 DEBUG nova.openstack.common.vmware.vim [-]
No faults found in RetrievePropertiesEx API response.
_retrieve_properties_ex_fault_checker /usr/lib/python2.7/dist-
packages/nova/ope
nstack/common/vmware/vim.py:153
2014-05-06 21:52:44.486 421 DEBUG nova.openstack.common.vmware.vim [-]
Invocation of RetrievePropertiesEx on (propertyCollector){
value = propertyCollector
_type = PropertyCollector
} completed successfully. vim_request_handler /usr/lib/python2.7/dist-
packages/nova/openstack/common/vmware/vim.py:187
2014-05-06 21:52:44.487 421 DEBUG nova.openstack.common.vmware.api [-]
Function _invoke_api returned successfully after 0 retries. _func
/usr/lib/python2.7/dist-packages/nova/openstack/common/vmware/api.py:88
2014-05-06 21:52:44.491 421 ERROR nova.openstack.common.threadgroup [-]
int() argument must be a string or a number, not 'NoneType'
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
Traceback (most recent call last):
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-
packages/nova/openstack/common/threadgroup.py, line 117, in wait
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
x.wait()
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-
packages/nova/openstack/common/threadgroup.py, line 49, in wait
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
return self.thread.wait()
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line
168, in wait
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
return self._exit_event.wait()
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/eventlet/event.py, line 116, in
wait
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
return hubs.get_hub().switch()
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/eventlet/hubs/hub.py, line 187,
in switch
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
return self.greenlet.switch()
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/eventlet/greenthread.py, line
194, in main
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
result = function(*args, **kwargs)
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-
packages/nova/openstack/common/service.py, line 65, in run_service
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
service.start()
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/nova/service.py, line 154, in
start
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
self.manager.init_host()
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line
792, in init_host
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
self._init_instance(context, instance)
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line
700, in _init_instance
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
drv_state = self._get_power_state(context, instance)
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/nova/compute/manager.py, line
808, in _get_power_state
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
return self.driver.get_info(instance)[state]
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py,
line 737, in get_info
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
return _vmops.get_info(instance)
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
File /usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/vmops.py,
line 1493, in get_info
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
max_mem = int(query['summary.config.memorySizeMB']) * 1024
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
TypeError: int() argument must be a string or a number, not 'NoneType'
2014-05-06 21:52:44.491 421 TRACE nova.openstack.common.threadgroup
2014-05-06 21:52:44.496 421 DEBUG amqp [-] Closed channel #1 _do_close
/usr/lib/python2.7/dist-packages/amqp/channel.py:88
2014-05-06 21:52:44.902 421 INFO
[Yahoo-eng-team] [Bug 1317935] [NEW] Neutron does not follow the RFC 3442 spec for DHCP
Public bug reported: When metadata networking is enabled, neutron will generate a dnsmasq configuration that includes classless routes. The RFC states that those routes should include the default route if they are defined, and that the DHCP client should ignore the default router. This causes standards-abiding DHCP clients like dhcpcd to not provide a default gateway when running on nova. At https://github.com/openstack/neutron/pull/22 you can see an example of how to fix this. ** 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/1317935 Title: Neutron does not follow the RFC 3442 spec for DHCP Status in OpenStack Neutron (virtual network service): New Bug description: When metadata networking is enabled, neutron will generate a dnsmasq configuration that includes classless routes. The RFC states that those routes should include the default route if they are defined, and that the DHCP client should ignore the default router. This causes standards-abiding DHCP clients like dhcpcd to not provide a default gateway when running on nova. At https://github.com/openstack/neutron/pull/22 you can see an example of how to fix this. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1317935/+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 1318082] [NEW] Multicast IP validation missing for network profiles (N1KV plugin)
Public bug reported: Cisco N1KV plugin is missing certain validation checks when configuring multicast IP range for overlap type network profiles. Need to add validation for both create/update of network profiles of this type. ** Affects: neutron Importance: Undecided Status: New ** Summary changed: - Multicast IP validation missing for network profiles + Multicast IP validation missing for network profiles (N1KV plugin) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1318082 Title: Multicast IP validation missing for network profiles (N1KV plugin) Status in OpenStack Neutron (virtual network service): New Bug description: Cisco N1KV plugin is missing certain validation checks when configuring multicast IP range for overlap type network profiles. Need to add validation for both create/update of network profiles of this type. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1318082/+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 1248275] Re: guest_info permissions are bad for guest to start up
** Changed in: trove-integration Status: Fix Committed = Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1248275 Title: guest_info permissions are bad for guest to start up Status in devstack - openstack dev environments: Won't Fix Status in OpenStack Compute (Nova): Invalid Status in Integration scripts for Trove: Fix Released Bug description: the permissions of /etc/guest_info is not world readable and guest agent will not start up. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1248275/+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 1318104] [NEW] dhcp isolation via iptables does not work
Public bug reported: Attempting to block iptables across the bridge via iptables rules is not working. The iptables rules are never hit. blocking dhcp traffic from exiting the node will need to use ebtables instead. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1318104 Title: dhcp isolation via iptables does not work Status in OpenStack Compute (Nova): New Bug description: Attempting to block iptables across the bridge via iptables rules is not working. The iptables rules are never hit. blocking dhcp traffic from exiting the node will need to use ebtables instead. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1318104/+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
