[Yahoo-eng-team] [Bug 1689279] [NEW] tempest scenario trunk test "test_subport_connectivity" fails with non root rhel user
Public bug reported:
When I run the test (python -m testtools.run)
neutron.tests.tempest.scenario.test_trunk.TrunkTest.test_subport_connectivity
with rhel image and "cloud_user" user the test fails due to following :
Traceback (most recent call last):
File
"/home/centos/tempest-upstream/neutron/neutron/tests/tempest/scenario/test_trunk.py",
line 242, in test_subport_connectivity
out = server['ssh_client'].exec_command('ip addr list')
File "tempest/lib/common/ssh.py", line 202, in exec_command
stderr=err_data, stdout=out_data)
tempest.lib.exceptions.SSHExecCommandFailed: Command 'ip addr list', exit
status: 127, stderr:
bash: ip: command not found
stdout:
Ran 1 test in 154.543s
adding sudo in the code for the command solves the issue
** 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/1689279
Title:
tempest scenario trunk test "test_subport_connectivity" fails with
non root rhel user
Status in neutron:
New
Bug description:
When I run the test (python -m testtools.run)
neutron.tests.tempest.scenario.test_trunk.TrunkTest.test_subport_connectivity
with rhel image and "cloud_user" user the test fails due to following
:
Traceback (most recent call last):
File
"/home/centos/tempest-upstream/neutron/neutron/tests/tempest/scenario/test_trunk.py",
line 242, in test_subport_connectivity
out = server['ssh_client'].exec_command('ip addr list')
File "tempest/lib/common/ssh.py", line 202, in exec_command
stderr=err_data, stdout=out_data)
tempest.lib.exceptions.SSHExecCommandFailed: Command 'ip addr list', exit
status: 127, stderr:
bash: ip: command not found
stdout:
Ran 1 test in 154.543s
adding sudo in the code for the command solves the issue
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1689279/+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 1689278] [NEW] Compute Node goes down periodically
Public bug reported: Hello, Recently a node on my Openstack Cloud is going down periodically without nothing relevant happening, i have not found an explanation for this yet. I have the following environment: 1.- Version 13.1.2 2.- KVM 3.- Ceph. 4.- Neutron with VXlan tunneling. After reviewing nova logs i have seen these Error lines repeteadly: 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions [req-a88c0032-190f-4d44-a570-78e23714e761 5a2f3552384d4d6a9b45ddda6dd7b1a9 c7d1479503644cd0b793f2c81af5ee60 - - -] Unexpected exception in API method 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions Traceback (most recent call last): 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/extensions.py", line 478, in wrapped 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions return f(*args, **kwargs) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/validation/__init__.py", line 73, in wrapper 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions return func(*args, **kwargs) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/remote_consoles.py", line 56, in get_vnc_console 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions console_type) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 171, in wrapped 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions return func(self, context, target, *args, **kwargs) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 151, in wrapped 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions return function(self, context, instance, *args, **kwargs) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/api.py", line 2933, in get_vnc_console 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions instance=instance, console_type=console_type) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/nova/compute/rpcapi.py", line 574, in get_vnc_console 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions instance=instance, console_type=console_type) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 158, in call 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions retry=self.retry) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 91, in _send 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions timeout=timeout, retry=retry) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 512, in send 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions retry=retry) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 501, in _send 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions result = self._waiter.wait(msg_id, timeout) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 379, in wait 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions message = self.waiters.get(msg_id, timeout=timeout) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 277, in get 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions 'to message ID %s' % msg_id) 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions MessagingTimeout: Timed out waiting for a reply to message ID c670a34162914270ad9ca6b0bd40b2fb 2017-05-05 00:33:51.117 10983 ERROR nova.api.openstack.extensions 2017-05-05 00:33:51.119 10983 INFO nova.api.openstack.wsgi [req-a88c0032-190f-4d44-a570-78e23714e761 5a2f3552384d4d6a9b45ddda6dd7b1a9 c7d1479503644cd0b793f2c81af5ee60 - - -] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. https://bugs.launchpad.net/bugs/1689278/+attachment/4873430/+files/nova-api.log-20170505-1493969701 -- 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/1
[Yahoo-eng-team] [Bug 1689284] [NEW] should capture quota exceed error from cinder when create image for volume backed instance
Public bug reported: When create image for a volume backed instance, nova will create snapshots for all volumes attached to the instance in Cinder, and if quota exceed in Cinder, HTTP 500 will raise, we should capture this error and raise 404. ** Affects: nova Importance: Undecided Assignee: Zhenyu Zheng (zhengzhenyu) Status: New ** Changed in: nova Assignee: (unassigned) => Zhenyu Zheng (zhengzhenyu) -- 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/1689284 Title: should capture quota exceed error from cinder when create image for volume backed instance Status in OpenStack Compute (nova): New Bug description: When create image for a volume backed instance, nova will create snapshots for all volumes attached to the instance in Cinder, and if quota exceed in Cinder, HTTP 500 will raise, we should capture this error and raise 404. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1689284/+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 1689289] [NEW] can not delete an instance when resizing
Public bug reported: Description === When an instance task state is RESIZE_MIGRATED or RESIZE_FINISH, delete the instance will hint an error, I found some problems with the code, because my flavor contains vram, a TypeError Thrown out. Steps to reproduce == 1.create an instance use flavor1,names server1 2.resize it but not resize confirm. 3.delete the instance quickly. 4.you can run " nova resize service1 flavor2 && sleep 2.0 && nova delete server1 ". Just delete the instance quickly When resize an instance, its task state will go through None => resize_migrating => resize_migrated => resize_finish => None, the purpose of sleep is to catch the target state，resize_migrated or resize_finish. Environment === RDO Newton Logs & Configs == Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 338, in wrapped return f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 914, in delete self._delete(req.environ['nova.context'], req, id) File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 768, in _delete self.compute_api.delete(context, instance) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 166, in inner return function(self, context, instance, *args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 173, in _wrapped return fn(self, context, instance, *args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 147, in inner return f(self, context, instance, *args, **kw) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 2048, in delete self._delete_instance(context, instance) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 2039, in _delete_instance task_state=task_states.DELETING) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1815, in _delete quotas.rollback() File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__ self.force_reraise() File "/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in force_reraise six.reraise(self.type_, self.value, self.tb) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1735, in _delete project_id, user_id) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 1878, in _create_reservations instance_memory_mb = old_flavor.memory_mb + vram_mb TypeError: unsupported operand type(s) for +: 'int' and 'unicode' ** 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/1689289 Title: can not delete an instance when resizing Status in OpenStack Compute (nova): New Bug description: Description === When an instance task state is RESIZE_MIGRATED or RESIZE_FINISH, delete the instance will hint an error, I found some problems with the code, because my flavor contains vram, a TypeError Thrown out. Steps to reproduce == 1.create an instance use flavor1,names server1 2.resize it but not resize confirm. 3.delete the instance quickly. 4.you can run " nova resize service1 flavor2 && sleep 2.0 && nova delete server1 ". Just delete the instance quickly When resize an instance, its task state will go through None => resize_migrating => resize_migrated => resize_finish => None, the purpose of sleep is to catch the target state，resize_migrated or resize_finish. Environment === RDO Newton Logs & Configs == Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/nova/api/openstack/extensions.py", line 338, in wrapped return f(*args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 914, in delete self._delete(req.environ['nova.context'], req, id) File "/usr/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py", line 768, in _delete self.compute_api.delete(context, instance) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 166, in inner return function(self, context, instance, *args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 173, in _wrapped return fn(self, context, instance, *args, **kwargs) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 147, in inner return f(self, context, instance, *args, **kw) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", line 2048, in delete self._delete_instance(context, instance) File "/usr/lib/python2.7/site-packages/nova/compute/api.py", lin
[Yahoo-eng-team] [Bug 1689300] [NEW] [DOC] Sub-port MAC address needs to be the same as Parent port MAC
Public bug reported: Description of problem: We need to documents that while create sub-port it should be created with --mac-address PARENT_PORT_MAC_ADDERSS. This is the correct networking config- on VM subIF and IF should have the same mac and it is the default option. We need to match neutron port creation with same concept- parent and subport should have same mac address. Openstack Ocata ** 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/1689300 Title: [DOC] Sub-port MAC address needs to be the same as Parent port MAC Status in neutron: New Bug description: Description of problem: We need to documents that while create sub-port it should be created with --mac-address PARENT_PORT_MAC_ADDERSS. This is the correct networking config- on VM subIF and IF should have the same mac and it is the default option. We need to match neutron port creation with same concept- parent and subport should have same mac address. Openstack Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1689300/+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 1689328] [NEW] Danger: An error occurred when trying to create a port in an external network
Public bug reported: Creating a port in an external network results in the error message in the title. The backtrace: [Mon May 08 15:27:02.722361 2017] [wsgi:error] [pid 2907:tid 140386830882560] Internal Server Error: /horizon/admin/networks/a2acaf3f-d1a9-4a1b-9f41-3bf878e580fe/ports/create [Mon May 08 15:27:02.722376 2017] [wsgi:error] [pid 2907:tid 140386830882560] Traceback (most recent call last): [Mon May 08 15:27:02.722378 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 132, in get_response [Mon May 08 15:27:02.722380 2017] [wsgi:error] [pid 2907:tid 140386830882560] response = wrapped_callback(request, *callback_args, **callback_kwargs) [Mon May 08 15:27:02.722381 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/share/openstack-dashboard/horizon/decorators.py", line 36, in dec [Mon May 08 15:27:02.722383 2017] [wsgi:error] [pid 2907:tid 140386830882560] return view_func(request, *args, **kwargs) [Mon May 08 15:27:02.722384 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/share/openstack-dashboard/horizon/decorators.py", line 52, in dec [Mon May 08 15:27:02.722386 2017] [wsgi:error] [pid 2907:tid 140386830882560] return view_func(request, *args, **kwargs) [Mon May 08 15:27:02.722387 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/share/openstack-dashboard/horizon/decorators.py", line 36, in dec [Mon May 08 15:27:02.722395 2017] [wsgi:error] [pid 2907:tid 140386830882560] return view_func(request, *args, **kwargs) [Mon May 08 15:27:02.722396 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/share/openstack-dashboard/horizon/decorators.py", line 84, in dec [Mon May 08 15:27:02.722397 2017] [wsgi:error] [pid 2907:tid 140386830882560] return view_func(request, *args, **kwargs) [Mon May 08 15:27:02.722399 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 71, in view [Mon May 08 15:27:02.722400 2017] [wsgi:error] [pid 2907:tid 140386830882560] return self.dispatch(request, *args, **kwargs) [Mon May 08 15:27:02.722401 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/lib/python2.7/dist-packages/django/views/generic/base.py", line 89, in dispatch [Mon May 08 15:27:02.722402 2017] [wsgi:error] [pid 2907:tid 140386830882560] return handler(request, *args, **kwargs) [Mon May 08 15:27:02.722404 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/lib/python2.7/dist-packages/django/views/generic/edit.py", line 205, in get [Mon May 08 15:27:02.722405 2017] [wsgi:error] [pid 2907:tid 140386830882560] form = self.get_form() [Mon May 08 15:27:02.722406 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/share/openstack-dashboard/horizon/forms/views.py", line 168, in get_form [Mon May 08 15:27:02.722407 2017] [wsgi:error] [pid 2907:tid 140386830882560] return form_class(self.request, **self.get_form_kwargs()) [Mon May 08 15:27:02.722409 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/networks/ports/forms.py", line 98, in __init__ [Mon May 08 15:27:02.722410 2017] [wsgi:error] [pid 2907:tid 140386830882560] subnet_choices = self._get_subnet_choices(kwargs['initial']) [Mon May 08 15:27:02.722411 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/share/openstack-dashboard/openstack_dashboard/dashboards/admin/networks/ports/forms.py", line 151, in _get_subnet_choices [Mon May 08 15:27:02.722413 2017] [wsgi:error] [pid 2907:tid 140386830882560] for subnet in network.subnets] [Mon May 08 15:27:02.722414 2017] [wsgi:error] [pid 2907:tid 140386830882560] AttributeError: 'unicode' object has no attribute 'id' Maybe it has the same origin as the instance launch panel doesn't list external networks anymore for an admin user. ** 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/1689328 Title: Danger: An error occurred when trying to create a port in an external network Status in OpenStack Dashboard (Horizon): New Bug description: Creating a port in an external network results in the error message in the title. The backtrace: [Mon May 08 15:27:02.722361 2017] [wsgi:error] [pid 2907:tid 140386830882560] Internal Server Error: /horizon/admin/networks/a2acaf3f-d1a9-4a1b-9f41-3bf878e580fe/ports/create [Mon May 08 15:27:02.722376 2017] [wsgi:error] [pid 2907:tid 140386830882560] Traceback (most recent call last): [Mon May 08 15:27:02.722378 2017] [wsgi:error] [pid 2907:tid 140386830882560] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 132, in get_response [Mon May 08 15:27
[Yahoo-eng-team] [Bug 1689339] [NEW] Filter Scheduler doc claims filters can be specified in the request
Public bug reported: On https://docs.openstack.org/developer/nova/filter_scheduler.html, it says that with the configuration set to: --filter_scheduler.enabled_filters=RamFilter,ComputeFilter,MyFilter that the following is true: "With these settings, nova will use the FilterScheduler for the scheduler driver. The standard nova filters and MyFilter are available to the FilterScheduler. The RamFilter, ComputeFilter, and MyFilter are used by default when no filters are specified in the request." There is no ability to specify filters in a request. The text of this page should be changed to reflect that. ** Affects: nova Importance: Undecided Assignee: Ed Leafe (ed-leafe) Status: In Progress ** Tags: doc scheduler -- 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/1689339 Title: Filter Scheduler doc claims filters can be specified in the request Status in OpenStack Compute (nova): In Progress Bug description: On https://docs.openstack.org/developer/nova/filter_scheduler.html, it says that with the configuration set to: --filter_scheduler.enabled_filters=RamFilter,ComputeFilter,MyFilter that the following is true: "With these settings, nova will use the FilterScheduler for the scheduler driver. The standard nova filters and MyFilter are available to the FilterScheduler. The RamFilter, ComputeFilter, and MyFilter are used by default when no filters are specified in the request." There is no ability to specify filters in a request. The text of this page should be changed to reflect that. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1689339/+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 1677376] Re: growing partitions does not work when booted without initramfs
** Changed in: cloud-init Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1677376 Title: growing partitions does not work when booted without initramfs Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Status in cloud-init source package in Xenial: Fix Released Status in cloud-init source package in Yakkety: Fix Released Bug description: [SRU Justification] When booted without an initramfs, the root device will be /dev/root, not a named device. There is partial support for this when resizing filesystems, but not for growing partitions, without which it doesn't do much good. A system boots significantly slower with an initramfs than without, and we care about boot speed; a user should not have to have to boot with an initramfs to take advantage of root partition resizing. [Test case] Because there are not yet any official Ubuntu images that boot without initramfs, the test case is somewhat opaque. Here is a test case that should work with public branches, though I will be doing validation in GCE using a private branch. 1. Build livecd-rootfs from lp:~vorlon/livecd-rootfs/minimizing/ and upload it to a ppa. 2. bzr branch lp:launchpad-buildd 3. run the following setup commands: export BUILDID=cloud-init-test export CHROOT_ROOT=$HOME/build-$BUILDID/chroot-autobuild wget http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.xz -O /tmp/root.tar.xz mkdir -p $CHROOT_ROOT/build tar -C $CHROOT_ROOT -x -f /tmp/root.tar.xz rm $CHROOT_ROOT/etc/resolv.conf launchpad-buildd/mount-chroot $BUILDID launchpad-buildd/update-debian-chroot $BUILDID 4. Run a build without -proposed enabled: launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series --build-id $BUILDID --image-target=none 5. Boot the resulting image ($HOME/build-$BUILDID/chroot-autobuild/build/binary/boot/disk.ext4) in an openstack environment. 6. Verify that the image boots but does not expand the root partition. 7. Run a build again with -proposed enabled: launchpad-buildd/buildlivefs --arch amd64 --project ubuntu-cpc --subproject minimize --series --build-id $BUILDID --image-target=none --proposed 8. Boot the resulting image in an openstack environment. 9. Verify that the image boots, and that this time the root partition is expanded to use the full disk. [Regression potential] Users with existing initramfsless images that are configured with the default of resizing the root partition may be surprised when this starts to work. However, this only applies to first boot of an image, so only newly-mastered images would be affected, so this should be caught by any image CI before the affected users put such an image into production if it has serious impact for them. Related bugs: * bug 1684869: growing root partition does not always work with root=PARTUUID= * bug 1685291: RFC: virtio and virtio-scsi should be built in To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1677376/+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 1687379] Re: Nova quotas update for large values erroneous
The issue is with the database schema we were using. We used float to store the values, this is where it was getting messed up. Using 'int' or 'double' solves this. Please ignore this defect. ** Changed in: nova Status: New => Invalid -- 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/1687379 Title: Nova quotas update for large values erroneous Status in OpenStack Compute (nova): Invalid Bug description: When we update nova related quota values with larger values, the updated value is not what we expected. For example, 1. If we try to update virtual machines quota to 2147483647, the vm quota gets updated to 214748. 2. If we try to update virtual machines quota to 2147479 or 2147481, the vm quota gets updated to 2147480. 3. Similar to above examples there are several values in that range where the update behaves not as expected. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1687379/+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 1689019] Re: functional test test_cleanup_stale_devices fails with "ValueError: foo_host is not a valid host address"
Reviewed: https://review.openstack.org/463238
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=26920b8712859ab3c44641ff33ca7f0ecfc45bc2
Submitter: Jenkins
Branch:master
commit 26920b8712859ab3c44641ff33ca7f0ecfc45bc2
Author: YAMAMOTO Takashi
Date: Mon May 8 13:58:48 2017 +0900
test_dhcp: Use a safer host name
We use "foo_host" as a hostname in a test.
Usually "_" is not allowed in a hostname. (See RFC 952 etc)
Oslo.config (correctly) complains on that.
Closes-Bug: #1689019
Change-Id: Ife817d4f9f904ab1cecb1d8501b94069d5468bdf
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1689019
Title:
functional test test_cleanup_stale_devices fails with "ValueError:
foo_host is not a valid host address"
Status in neutron:
Fix Released
Bug description:
neutron.tests.functional.agent.linux.test_dhcp.TestDhcp
test_cleanup_stale_devices fails with:
ft1.1:
neutron.tests.functional.agent.linux.test_dhcp.TestDhcp.test_cleanup_stale_devices_StringException:
Empty attachments:
stderr
stdout
pythonlogging:'': {{{
DEBUG [stevedore.extension] found extension EntryPoint.parse('rabbit =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('fake =
oslo_messaging._drivers.impl_fake:FakeDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kafka =
oslo_messaging._drivers.impl_kafka:KafkaDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('amqp =
oslo_messaging._drivers.impl_amqp1:ProtonDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kombu =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('zmq =
oslo_messaging._drivers.impl_zmq:ZmqDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('pika =
oslo_messaging._drivers.impl_pika:PikaDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('rabbit =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('fake =
oslo_messaging._drivers.impl_fake:FakeDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kafka =
oslo_messaging._drivers.impl_kafka:KafkaDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('amqp =
oslo_messaging._drivers.impl_amqp1:ProtonDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kombu =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('zmq =
oslo_messaging._drivers.impl_zmq:ZmqDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('pika =
oslo_messaging._drivers.impl_pika:PikaDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('rabbit =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('fake =
oslo_messaging._drivers.impl_fake:FakeDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kafka =
oslo_messaging._drivers.impl_kafka:KafkaDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('amqp =
oslo_messaging._drivers.impl_amqp1:ProtonDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kombu =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('zmq =
oslo_messaging._drivers.impl_zmq:ZmqDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('pika =
oslo_messaging._drivers.impl_pika:PikaDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('rabbit =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('fake =
oslo_messaging._drivers.impl_fake:FakeDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kafka =
oslo_messaging._drivers.impl_kafka:KafkaDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('amqp =
oslo_messaging._drivers.impl_amqp1:ProtonDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('kombu =
oslo_messaging._drivers.impl_rabbit:RabbitDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('zmq =
oslo_messaging._drivers.impl_zmq:ZmqDriver')
DEBUG [stevedore.extension] found extension EntryPoint.parse('pika =
oslo_messaging._drivers.impl_pika:PikaDriver')
DEBUG [oslo_policy._cache_handler] Reloading cached file
/opt/stack/new/neutron/neutron/tests/etc/policy.json
DEBUG [oslo_policy.policy] Reloaded policy file:
/opt/stack/new/neutron/neutron/tests/etc/policy.json
}}}
Traceback (most rec
[Yahoo-eng-team] [Bug 1689468] [NEW] odd keystone behavior when X-Auth-Token ends with carriage return
Public bug reported:
I had to root cause a very odd problem today, where a user complained
that they had a token that worked with neutron but didn't work with
keystone. E.g. they could list networks, but couldn't list projects. I
thought there must be some mistake, but I was finally able to reproduce
it and they were correct. Here's a script that shows the problem:
OPENSTACK=
AUTH_FILE=/root/auth.json
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; print $2}'`
echo 'neutron:'; curl -1 -k -X GET https://$OPENSTACK:9696/v2.0/networks
-H "X-Auth-Token: $TOKEN" -H "Content-Type: application/json"; echo;
echo
echo 'keystone:'; curl -1 -k -X GET https://$OPENSTACK:5000/v3/projects
-H "X-Auth-Token: $TOKEN" -H "Accept: application/json"; echo; echo
With debug=True and insecure_debug=True and
default_log_levels=keystonemiddleware=True, this yields something like:
neutron:
{"networks": []}
keystone:
{"error": {"message": "auth_context did not decode anything useful (Disable
insecure_debug mode to suppress these details.)", "code": 401, "title":
"Unauthorized"}}
I was finally able to figure out why... the awk command used to parse
the token out of the X-Subject-Token header was leaving a \r on the end
of the $TOKEN value, and apparently that's handled fine when you make
the request to neutron (and presumably any non-keystone service), but
not when you are talking to keystone directly. That makes some sense,
since keystone has to do its own token validation differently.
Changing the following line in the script above (adding the gsub to trim
the \r) fixed the issue:
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; gsub(/\r$/,"",$2);
print $2}'`
We should fix this to be consistent with non-keystone token validation, to save
someone else the trouble debugging this if nothing else. Keystone was doing
weird things, where the debug logs would show that the context knew the user
and roles, but had no token... leaving one to wonder how it figured out the
user and roles if it didn't have a token?!? Not a good user experience for
someone trying to write a script to our APIs.
** Affects: keystone
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1689468
Title:
odd keystone behavior when X-Auth-Token ends with carriage return
Status in OpenStack Identity (keystone):
New
Bug description:
I had to root cause a very odd problem today, where a user complained
that they had a token that worked with neutron but didn't work with
keystone. E.g. they could list networks, but couldn't list projects. I
thought there must be some mistake, but I was finally able to
reproduce it and they were correct. Here's a script that shows the
problem:
OPENSTACK=
AUTH_FILE=/root/auth.json
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":"; print $2}'`
echo 'neutron:'; curl -1 -k -X GET
https://$OPENSTACK:9696/v2.0/networks -H "X-Auth-Token: $TOKEN" -H
"Content-Type: application/json"; echo; echo
echo 'keystone:'; curl -1 -k -X GET
https://$OPENSTACK:5000/v3/projects -H "X-Auth-Token: $TOKEN" -H
"Accept: application/json"; echo; echo
With debug=True and insecure_debug=True and
default_log_levels=keystonemiddleware=True, this yields something like:
neutron:
{"networks": []}
keystone:
{"error": {"message": "auth_context did not decode anything useful (Disable
insecure_debug mode to suppress these details.)", "code": 401, "title":
"Unauthorized"}}
I was finally able to figure out why... the awk command used to parse
the token out of the X-Subject-Token header was leaving a \r on the
end of the $TOKEN value, and apparently that's handled fine when you
make the request to neutron (and presumably any non-keystone service),
but not when you are talking to keystone directly. That makes some
sense, since keystone has to do its own token validation differently.
Changing the following line in the script above (adding the gsub to
trim the \r) fixed the issue:
TOKEN=`curl -s -1 -k -i -X POST https://$OPENSTACK:5000/v3/auth/tokens
-H "Accept:application/json" -H "Content-Type: application/json" -d
@${AUTH_FILE} | grep X-Subject-Token | awk '{FS=":";
gsub(/\r$/,"",$2); print $2}'`
We should fix this to be consistent with non-keystone token validation, to
save someone else the trouble debugging this if nothing else. Keystone was
doing weird things, where t
[Yahoo-eng-team] [Bug 1622753] Re: [RFE] Block non-IP traffic in security groups/firewall driver
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1622753 Title: [RFE] Block non-IP traffic in security groups/firewall driver Status in neutron: Expired Bug description: Presently the IPTables firewall driver (the reference security group implementation) permits all non-IP traffic to ingress and egress an instance port. This should be altered to block non-IP traffic by default. Security groups are a collection of rules which specify which traffic should be permitted into and out of an instance port. By only including allow rules, the order in which rules are enforced doesn't matter. Security groups are deny all by default except in for non-IP traffic. This was largely an oversight, since the original implementation just used iptables which doesn't filter non-IP traffic. Later ebtables was employed to filter ARP message (which are non-IP frames), but other Ethertypes besides IPv4, IPv6 and ARP are unfiltered. Since non-IP traffic is not routed by Neutron, there is no Internet facing security risk. In the case of a shared network, this is a cross tenant/project security risk. Since this would significantly alter the behavior of security groups I propose making change in several stages: 1. Introduce a new configuration option to specify the firewall driver behavior for non-IP traffic. This should default to allow initially. Modify the IPtables firewall driver to honor this configuration. 2. Change the default of this new configuration option to deny. 3. Introduce an extension to security groups which permits arbitrary 16-bit values to be specified as Ethertypes, so tenant's can use security groups to filter non-IP traffic. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1622753/+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 1504941] Re: RBAC-RFE- neutron net-show command should display all tenant that using the network
[Expired for neutron because there has been no activity for 60 days.] ** Changed in: neutron Status: Incomplete => Expired -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1504941 Title: RBAC-RFE- neutron net-show command should display all tenant that using the network Status in neutron: Expired Bug description: On rdo- liberty I thested neutron rbac feature . when network assigned to more then 1 tenant we still see one tenant in neutron net-show [root@cougar16 ~(keystone_admin)]# neutron net-show 590ca7b9-1682-4c40-8213-02feaa7a96cc +---+--+ | Field | Value| +---+--+ | admin_state_up| True | | id| 590ca7b9-1682-4c40-8213-02feaa7a96cc | | mtu | 0| | name | internal_ipv4_a | | provider:network_type | vxlan| | provider:physical_network | | | provider:segmentation_id | 70 | | router:external | False| | shared| False| | status| ACTIVE | | subnets | 9a1a387e-88cf-484a-8b12-5a1834be0233 | | tenant_id | fa4add4659704239b771b0bccb8b6829 | +---+--+ this network shared in 2 tenants : [root@cougar16 ~(keystone_admin)]# neutron rbac-list +--+--+ | id | object_id | +--+--+ | 4f1a9c9d-e820-46e4-b431-b3142c6bb245 | 818dd42f-f627-45d4-a578-dd475b9e19e4 | | 8c995ab1-dea6-411b-854c-a405cf5365fa | 590ca7b9-1682-4c40-8213-02feaa7a96cc | | abb375b9-95d0-4297-80f1-3f22f0f84a9e | b071a769-0d50-4d25-8730-fed3dea13a2f | | f3122b92-f47a-4a0f-a422-c9f7ed482341 | 590ca7b9-1682-4c40-8213-02feaa7a96cc | [root@cougar16 ~(keystone_admin)]# rpm -qa |grep neutron python-neutronclient-3.1.1-dev1.el7.centos.noarch python-neutron-7.0.0.0-rc2.dev21.el7.centos.noarch openstack-neutron-7.0.0.0-rc2.dev21.el7.centos.noarch openstack-neutron-ml2-7.0.0.0-rc2.dev21.el7.centos.noarch openstack-neutron-common-7.0.0.0-rc2.dev21.el7.centos.noarch openstack-neutron-openvswitch-7.0.0.0-rc2.dev21.el7.centos.noarch To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1504941/+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 1689482] [NEW] coverage job failure
Public bug reported: neutron-coverage-ubuntu-xenial is failing with timeout, probably after the recent coverage update. (4.3.4 -> 4.4) succeed: http://logs.openstack.org/38/463238/1/gate/neutron-coverage-ubuntu-xenial/f92036d/ failed: http://logs.openstack.org/75/437775/9/check/neutron-coverage-ubuntu-xenial/716a43a/ ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure ** Description changed: - neutron-coverage-ubuntu-xenial is failing, + neutron-coverage-ubuntu-xenial is failing with timeout, probably after the recent coverage update. (4.3.4 -> 4.4) + + succeed: http://logs.openstack.org/38/463238/1/gate/neutron-coverage-ubuntu-xenial/f92036d/ + failed: http://logs.openstack.org/75/437775/9/check/neutron-coverage-ubuntu-xenial/716a43a/ ** Tags added: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1689482 Title: coverage job failure Status in neutron: New Bug description: neutron-coverage-ubuntu-xenial is failing with timeout, probably after the recent coverage update. (4.3.4 -> 4.4) succeed: http://logs.openstack.org/38/463238/1/gate/neutron-coverage-ubuntu-xenial/f92036d/ failed: http://logs.openstack.org/75/437775/9/check/neutron-coverage-ubuntu-xenial/716a43a/ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1689482/+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
