[Bug 1616902] Re: libdevmapper logging not properly initialized
OK. This has been fixed in multipat-tools upstream repo. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1616902 Title: libdevmapper logging not properly initialized To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1616902/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1298061] Re: nova should allow evacuate for an instance in the Error state
** Description changed: [Impact] * Instances in error state cannot be evacuated. [Test Case] * nova evacuate * nova refuses to evacuate the instance because of its state [Regression Potential] * None - * Passed tempest smoke tests locally. + * Passed tempest smoke tests locally. + + Note: one simple way to put an instance into error state is to directly + change its database record, for example update instances set + vm_state='error' where uuid='' We currently allow reboot/rebuild/rescue for an instance in the Error state if the instance has successfully booted at least once. We should allow "evacuate" as well, since it is essentially a "rebuild" on a different compute node. This would be useful in a number of cases, in particular if an initial evacuation attempt fails (putting the instance into the Error state). ** Description changed: [Impact] * Instances in error state cannot be evacuated. [Test Case] * nova evacuate * nova refuses to evacuate the instance because of its state [Regression Potential] * None * Passed tempest smoke tests locally. Note: one simple way to put an instance into error state is to directly - change its database record, for example update instances set - vm_state='error' where uuid='' + change its database record, for example "update instances set + vm_state='error' where uuid=''" We currently allow reboot/rebuild/rescue for an instance in the Error state if the instance has successfully booted at least once. We should allow "evacuate" as well, since it is essentially a "rebuild" on a different compute node. This would be useful in a number of cases, in particular if an initial evacuation attempt fails (putting the instance into the Error state). ** Description changed: [Impact] * Instances in error state cannot be evacuated. [Test Case] * nova evacuate * nova refuses to evacuate the instance because of its state [Regression Potential] * None * Passed tempest smoke tests locally. Note: one simple way to put an instance into error state is to directly change its database record, for example "update instances set vm_state='error' where uuid=''" + We currently allow reboot/rebuild/rescue for an instance in the Error state if the instance has successfully booted at least once. We should allow "evacuate" as well, since it is essentially a "rebuild" on a different compute node. This would be useful in a number of cases, in particular if an initial evacuation attempt fails (putting the instance into the Error state). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1298061 Title: nova should allow evacuate for an instance in the Error state To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298061/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1298061] Re: nova should allow evacuate for an instance in the Error state
** Description changed: [Impact] - * Instances in error state cannot be evacuated. + * Instances in error state cannot be evacuated. [Test Case] - * nova evacuate - * nova refuses to evacuate the instance because of its state + * nova evacuate + * nova refuses to evacuate the instance because of its state [Regression Potential] - * None - + * None + * Passed tempest smoke tests locally. We currently allow reboot/rebuild/rescue for an instance in the Error state if the instance has successfully booted at least once. We should allow "evacuate" as well, since it is essentially a "rebuild" on a different compute node. This would be useful in a number of cases, in particular if an initial evacuation attempt fails (putting the instance into the Error state). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1298061 Title: nova should allow evacuate for an instance in the Error state To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298061/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1298061] Re: nova should allow evacuate for an instance in the Error state
** Changed in: nova (Ubuntu Trusty) Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: nova (Ubuntu Trusty) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1298061 Title: nova should allow evacuate for an instance in the Error state To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1298061/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1621340] Re: 'multipath -r' causes /dev/mapper/ being removed
** Description changed:
+ [Impact]
+
"multipath -r" causes the /dev/mapper/ to disappear momentarily,
which leads to some issue in consumer applications as such OpenStack.
- After some investigation, I found that /dev/mapper/ was deleted by
- udev during the reload, and it was re-created soon later by multipathd
- (livdevmapper code of cause). Detailed findings are as follows:
+
+ [Test Case]
+
+ * connect to an multipath iscsi target
+ * multipath -r
+ * /dev/mapper/ disappears momentarily
+
+ [Regression Potential]
+
+ * None
+
+
+ "multipath -r" causes the /dev/mapper/ to disappear momentarily, which
leads to some issue in consumer applications as such OpenStack. After some
investigation, I found that /dev/mapper/ was deleted by udev during the
reload, and it was re-created soon later by multipathd (livdevmapper code of
cause). Detailed findings are as follows:
For reload in domap (rename as well),
- case ACT_RELOAD:
- r = dm_addmap_reload(mpp, params);
- if (r)
- r = dm_simplecmd_noflush(DM_DEVICE_RESUME, mpp->alias,
- 0, MPATH_UDEV_RELOAD_FLAG);
- break;
+ case ACT_RELOAD:
+ r = dm_addmap_reload(mpp, params);
+ if (r)
+ r = dm_simplecmd_noflush(DM_DEVICE_RESUME, mpp->alias,
+ 0, MPATH_UDEV_RELOAD_FLAG);
+ break;
+ it passes 0 to dm_simplecmd_noflush as argument for needsync, which
+ makes dm_task_set_cookie call being skipped in dm_simplecmd,
- it passes 0 to dm_simplecmd_noflush as argument for needsync, which makes
dm_task_set_cookie call being skipped in dm_simplecmd,
+ if (udev_wait_flag && !dm_task_set_cookie(dmt, ,
((conf->daemon)? DM_UDEV_DISABLE_LIBRARY_FALLBACK : 0) | udev_flags)) {
+ dm_udev_complete(cookie);
+ goto out;
+ }
- if (udev_wait_flag && !dm_task_set_cookie(dmt, ,
((conf->daemon)? DM_UDEV_DISABLE_LIBRARY_FALLBACK : 0) | udev_flags)) {
- dm_udev_complete(cookie);
- goto out;
- }
-
-
- because of the short-circuit evaluation. Thus _do_dm_ioctl in libdevmapper
will add DM_UDEV_DISABLE_DM_RULES_FLAG flag to dmi->event_nr, and that will
eventually be used in the udev rules (55-dm.rules),
+ because of the short-circuit evaluation. Thus _do_dm_ioctl in
+ libdevmapper will add DM_UDEV_DISABLE_DM_RULES_FLAG flag to
+ dmi->event_nr, and that will eventually be used in the udev rules
+ (55-dm.rules),
ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*",
SYMLINK+="mapper/$env{DM_NAME}"
-
- Since the DM_UDEV_DISABLE_DM_RULES_FLAG is set, the rule will not match. As a
result the link is removed.
+ Since the DM_UDEV_DISABLE_DM_RULES_FLAG is set, the rule will not match.
+ As a result the link is removed.
** Tags added: sts
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1621340
Title:
'multipath -r' causes /dev/mapper/ being removed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1621340] Re: 'multipath -r' causes /dev/mapper/ being removed
** Patch added: "Yakkety patch" https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+attachment/4736879/+files/yakkety.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1621340 Title: 'multipath -r' causes /dev/mapper/ being removed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1621340] Re: 'multipath -r' causes /dev/mapper/ being removed
** Changed in: multipath-tools (Ubuntu Xenial) Status: New => In Progress ** Changed in: multipath-tools (Ubuntu Xenial) Assignee: (unassigned) => Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1621340 Title: 'multipath -r' causes /dev/mapper/ being removed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1621340] Re: 'multipath -r' causes /dev/mapper/ being removed
** Patch added: "xenial debdiff" https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+attachment/4736695/+files/xenial.diff ** Changed in: multipath-tools (Ubuntu) Assignee: (unassigned) => Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1621340 Title: 'multipath -r' causes /dev/mapper/ being removed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1621340] [NEW] 'multipath -r' causes /dev/mapper/ being removed
Public bug reported:
"multipath -r" causes the /dev/mapper/ to disappear momentarily,
which leads to some issue in consumer applications as such OpenStack.
After some investigation, I found that /dev/mapper/ was deleted by
udev during the reload, and it was re-created soon later by multipathd
(livdevmapper code of cause). Detailed findings are as follows:
For reload in domap (rename as well),
case ACT_RELOAD:
r = dm_addmap_reload(mpp, params);
if (r)
r = dm_simplecmd_noflush(DM_DEVICE_RESUME, mpp->alias,
0, MPATH_UDEV_RELOAD_FLAG);
break;
it passes 0 to dm_simplecmd_noflush as argument for needsync, which makes
dm_task_set_cookie call being skipped in dm_simplecmd,
if (udev_wait_flag && !dm_task_set_cookie(dmt, ,
((conf->daemon)? DM_UDEV_DISABLE_LIBRARY_FALLBACK : 0) | udev_flags)) {
dm_udev_complete(cookie);
goto out;
}
because of the short-circuit evaluation. Thus _do_dm_ioctl in libdevmapper will
add DM_UDEV_DISABLE_DM_RULES_FLAG flag to dmi->event_nr, and that will
eventually be used in the udev rules (55-dm.rules),
ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*",
SYMLINK+="mapper/$env{DM_NAME}"
Since the DM_UDEV_DISABLE_DM_RULES_FLAG is set, the rule will not match. As a
result the link is removed.
** Affects: multipath-tools (Ubuntu)
Importance: Undecided
Assignee: Liang Chen (cbjchen)
Status: In Progress
** Changed in: multipath-tools (Ubuntu)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1621340
Title:
'multipath -r' causes /dev/mapper/ being removed
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1621340/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1616902] [NEW] libdevmapper logging not properly initialized
Public bug reported:
dm_init();
if (getuid() != 0) {
fprintf(stderr, "need to be root\n");
exit(1);
}
/* make sure we don't lock any path */
chdir("/");
umask(umask(077) | 022);
conf = alloc_config();
dm_init is called before allocating conf. But dm_init depends on
conf->verbosity to initialize libdevmapper logging. In the current situation,
the verbosity is always set to 0 because conf is 0.
extern void
dm_init(void) {
dm_log_init(_write_log);
dm_log_init_verbose(conf ? conf->verbosity + 3 : 0);
}
** Affects: multipath-tools (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1616902
Title:
libdevmapper logging not properly initialized
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1616902/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1445947] Re: 'pip3 list' throws AssertionError
** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1445947 Title: 'pip3 list' throws AssertionError To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1445947/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1445947] Re: 'pip3 list' throws AssertionError
The package python-pip 1.5.4-1ubuntu4 is tested and it fixes the issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1445947 Title: 'pip3 list' throws AssertionError To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1445947/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1494350] Re: QEMU: causes vCPU steal time overflow on live migration
The proposed package is tested and it passed the test case described in the bug description. ** Tags removed: verification-needed-trusty ** Tags added: verification-done-trusty -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1494350 Title: QEMU: causes vCPU steal time overflow on live migration To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1494350/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1445947] Re: 'pip3 list' throws AssertionError
trusty also need the fix ** Patch added: "trusty patch" https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1445947/+attachment/4670738/+files/fix_legacy_version_support.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1445947 Title: 'pip3 list' throws AssertionError To manage notifications about this bug go to: https://bugs.launchpad.net/pip/+bug/1445947/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1382079] Re: [SRU] Project selector not working
The package in kilo-proposed archive fixed the issue for me. ** Tags removed: verification-kilo-needed ** Tags added: verification-kilo-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: [SRU] Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1382079/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1445947] Re: 'pip3 list' throws AssertionError
The proposed package (1.5.6-7ubuntu1.2) works well for me. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1445947 Title: 'pip3 list' throws AssertionError To manage notifications about this bug go to: https://bugs.launchpad.net/pip/+bug/1445947/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1369465] Re: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend
Matt, I made debian patch for wily-liberty. But the patch depends on many other commits that kilo doesn't have, and I would be too risky to backport them all to kilo. So I am not going propose a kilo backport. Sorry for the inconvenience. Thanks, Liang -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1369465 Title: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369465/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1445947] Re: 'pip3 list' throws AssertionError
** Description changed: + [Impact] + + * Not able show current list of installed packages, e.g. pip freeze. + + [Test Case] + + 1 - install wily/trusty-liberty python-pip package + 2 - pip freeze + 3 - the following error is shown without the patch + + Exception: + Traceback (most recent call last): + File "/usr/lib/python2.7/dist-packages/pip/basecommand.py", line 122, in main + status = self.run(options, args) + File "/usr/lib/python2.7/dist-packages/pip/commands/freeze.py", line 74, in run + req = pip.FrozenRequirement.from_dist(dist, dependency_links, find_tags=find_tags) + File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 286, in from_dist + assert len(specs) == 1 and specs[0][0] == '==' + AssertionError + + [Regression Potential] + + * None + + The command 'pip3 list' is broken on vivid: maxb@altimeter:~$ pip3 list [snip] Exception: Traceback (most recent call last): - File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 122, in main - status = self.run(options, args) - File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 80, in run - self.run_listing(options) - File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 142, in run_listing - self.output_package_listing(installed_packages) - File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 151, in output_package_listing - if dist_is_editable(dist): - File "/usr/lib/python3/dist-packages/pip/util.py", line 367, in dist_is_editable - req = FrozenRequirement.from_dist(dist, []) - File "/usr/lib/python3/dist-packages/pip/__init__.py", line 299, in from_dist - assert len(specs) == 1 and specs[0][0] == '==' + File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 122, in main + status = self.run(options, args) + File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 80, in run + self.run_listing(options) + File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 142, in run_listing + self.output_package_listing(installed_packages) + File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 151, in output_package_listing + if dist_is_editable(dist): + File "/usr/lib/python3/dist-packages/pip/util.py", line 367, in dist_is_editable + req = FrozenRequirement.from_dist(dist, []) + File "/usr/lib/python3/dist-packages/pip/__init__.py", line 299, in from_dist + assert len(specs) == 1 and specs[0][0] == '==' AssertionError The problem is that the version string of python-apt is not PEP 440 compliant. Avoiding this crash is already fixed with a one-line patch upstream. Please consider cherry-picking https://github.com/pypa/pip/commit/6cab71f422f2425b4d2283023c9e955f9663dde6 into Vivid's pip. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: python3-pip 1.5.6-5ubuntu2 ProcVersionSignature: Ubuntu 3.19.0-14.14-generic 3.19.3 Uname: Linux 3.19.0-14-generic x86_64 ApportVersion: 2.17.2-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Sun Apr 19 16:55:24 2015 EcryptfsInUse: Yes InstallationDate: Installed on 2014-05-29 (325 days ago) InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417) PackageArchitecture: all SourcePackage: python-pip UpgradeStatus: Upgraded to vivid on 2015-03-29 (20 days ago) ** Changed in: python-pip (Ubuntu) Status: Confirmed => In Progress ** Changed in: python-pip (Ubuntu) Assignee: (unassigned) => Liang Chen (cbjchen) ** Patch added: "wily debian patch" https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1445947/+attachment/4633565/+files/fix_legacy_version_support.diff ** Tags added: sts sts-sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1445947 Title: 'pip3 list' throws AssertionError To manage notifications about this bug go to: https://bugs.launchpad.net/pip/+bug/1445947/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1369465] Re: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend
** Changed in: nova (Ubuntu) Status: Confirmed => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1369465 Title: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369465/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1369465] Re: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend
** Changed in: nova (Ubuntu) Assignee: (unassigned) => Liang Chen (cbjchen) ** Patch added: "wily-liberty debian patch" https://bugs.launchpad.net/nova/+bug/1369465/+attachment/4629899/+files/fix_rbd_resize.diff ** Description changed: + [Impact] + + * Not able to resize rbd backed disk image. + + [Test Case] + + 1 - boot an instance with rbd backed disk image + 2 - resize it + 3 - log into the VM + 4 - the disk is not enlarged without this patch + + [Regression Potential] + + * None + + tested with nova trunk commit eb860c2f219b79e4f4c5984415ee433145197570 Configured Nova to use rbd disk backend nova.conf [libvirt] images_type=rbd instances booted successfully and instance disks are in rbd pools, when perform a nova resize to an existing instance, memory and CPU changed to be new flavors but instance disks size doesn't change ** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1369465 Title: nova resize doesn't resize(extend) rbd disk files when using rbd disk backend To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1369465/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1494350] Re: QEMU: causes vCPU steal time overflow on live migration
The backport has been acked in upstream for 3.4, 3.10, 3.14, and 3.16 stable kernel. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1494350 Title: QEMU: causes vCPU steal time overflow on live migration To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1494350/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
Tested with 1:2.2+dfsg-5expubuntu9.7~cloud2, and the fix works for me. ** Tags removed: verification-kilo-needed ** Tags added: verification-kilo-done -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
Tested with 1:2.2+dfsg-5expubuntu9.7~cloud2, and the fix works for me. ** Tags removed: verification-kilo-needed ** Tags added: verification-kilo-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1382079] Re: Project selector not working
** Changed in: cloud-archive Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: cloud-archive Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1382079/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1382079] Re: Project selector not working
** Changed in: cloud-archive Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: cloud-archive Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1382079/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Changed in: cloud-archive Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: cloud-archive Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Changed in: cloud-archive Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: cloud-archive Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Tags added: sts sts-sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Tags added: sts sts-sru -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1382079] Re: Project selector not working
** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1382079/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1382079] Re: Project selector not working
** Tags added: sts-sru -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1382079/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1382079] Re: Project selector not working
** Description changed: [Impact] - * Not able to switch projects by the project dropdown list. + * Not able to switch projects by the project dropdown list. [Test Case] - 1 - Log in on Horizon - 2 - make sure that the SESSION_BACKEND is "signed_cookies" - 3 - Try to change project on the dropdown + 1 - enable Identity V3 in local_settings.py + 2 - Log in on Horizon + 3 - make sure that the SESSION_BACKEND is "signed_cookies" + 4 - Try to change project on the dropdown [Regression Potential] - * None - + * None When you try to select a new project on the project dropdown, the project doesn't change. The commit below has introduced this bug on Horizon's master and has passed the tests verifications. https://github.com/openstack/horizon/commit/16db58fabad8934b8fbdfc6aee0361cc138b20af For what I've found so far, the context being received in the decorator seems to be the old context, with the token to the previous project. When you take the decorator out, the context received by the "can_access" function receives the correct context, with the token to the new project. Steps to reproduce: 1 - Enable Identity V3 (to have a huge token) 2 - Log in on Horizon (lots of permissions loaded on session) 3 - Certify that you SESSION_BACKEND is "signed_cookies" 4 - Try to change project on the dropdown The project shall remain the same. ** Tags added: sts ** Changed in: horizon (Ubuntu Vivid) Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: horizon (Ubuntu Vivid) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1382079/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1382079] Re: Project selector not working
** Description changed: [Impact] - * Not able to switch projects by the project dropdown list. + * Not able to switch projects by the project dropdown list. [Test Case] - 1 - Log in on Horizon - 2 - make sure that the SESSION_BACKEND is "signed_cookies" - 3 - Try to change project on the dropdown + 1 - enable Identity V3 in local_settings.py + 2 - Log in on Horizon + 3 - make sure that the SESSION_BACKEND is "signed_cookies" + 4 - Try to change project on the dropdown [Regression Potential] - * None - + * None When you try to select a new project on the project dropdown, the project doesn't change. The commit below has introduced this bug on Horizon's master and has passed the tests verifications. https://github.com/openstack/horizon/commit/16db58fabad8934b8fbdfc6aee0361cc138b20af For what I've found so far, the context being received in the decorator seems to be the old context, with the token to the previous project. When you take the decorator out, the context received by the "can_access" function receives the correct context, with the token to the new project. Steps to reproduce: 1 - Enable Identity V3 (to have a huge token) 2 - Log in on Horizon (lots of permissions loaded on session) 3 - Certify that you SESSION_BACKEND is "signed_cookies" 4 - Try to change project on the dropdown The project shall remain the same. ** Tags added: sts ** Changed in: horizon (Ubuntu Vivid) Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: horizon (Ubuntu Vivid) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1382079/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1382079] Re: Project selector not working
** Description changed: + [Impact] + + * Not able to switch projects by the project dropdown list. + + [Test Case] + + 1 - Log in on Horizon + 2 - make sure that the SESSION_BACKEND is "signed_cookies" + 3 - Try to change project on the dropdown + + [Regression Potential] + + * None + + When you try to select a new project on the project dropdown, the project doesn't change. The commit below has introduced this bug on Horizon's master and has passed the tests verifications. https://github.com/openstack/horizon/commit/16db58fabad8934b8fbdfc6aee0361cc138b20af For what I've found so far, the context being received in the decorator seems to be the old context, with the token to the previous project. When you take the decorator out, the context received by the "can_access" function receives the correct context, with the token to the new project. Steps to reproduce: 1 - Enable Identity V3 (to have a huge token) 2 - Log in on Horizon (lots of permissions loaded on session) 3 - Certify that you SESSION_BACKEND is "signed_cookies" 4 - Try to change project on the dropdown The project shall remain the same. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to horizon in Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1382079/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1382079] Re: Project selector not working
** Description changed: + [Impact] + + * Not able to switch projects by the project dropdown list. + + [Test Case] + + 1 - Log in on Horizon + 2 - make sure that the SESSION_BACKEND is "signed_cookies" + 3 - Try to change project on the dropdown + + [Regression Potential] + + * None + + When you try to select a new project on the project dropdown, the project doesn't change. The commit below has introduced this bug on Horizon's master and has passed the tests verifications. https://github.com/openstack/horizon/commit/16db58fabad8934b8fbdfc6aee0361cc138b20af For what I've found so far, the context being received in the decorator seems to be the old context, with the token to the previous project. When you take the decorator out, the context received by the "can_access" function receives the correct context, with the token to the new project. Steps to reproduce: 1 - Enable Identity V3 (to have a huge token) 2 - Log in on Horizon (lots of permissions loaded on session) 3 - Certify that you SESSION_BACKEND is "signed_cookies" 4 - Try to change project on the dropdown The project shall remain the same. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1382079 Title: Project selector not working To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1382079/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1494350] Re: QEMU: causes vCPU steal time overflow on live migration
** Description changed: + [Impact] + It is possible to have vcpu->arch.st.last_steal initialized + from a thread other than vcpu thread, say the main thread, via + KVM_SET_MSRS. That can cause steal_time overflow later (when subtracting from vcpu threads sched_info.run_delay). + + [Test Case] Testing Steps with patched trusty kernel: - Using savemv & loadvm to simulate the migration process. In guest: 1. check steal_time data location rdmsr 0x4b564d03 <- returns the start address 0x7fc0d000 2. exam the steal time before savevm in qemu monitor (qemu) xp /ug 0x7fc0d000 xp /ug 0x7fc0d000 7fc0d000:144139048 < steal time value before savevm (qemu) savevm mytestvm7 savevm mytestvm7 (qemu) quit quit 3. give some load to the host system, e.g. stress --cpu 4. start the guest with "-loadvm mytestvm7" to restore the state of the VM, thus the steal_time MSR 5. exam the steal time value again (qemu) xp /ug 0x7fc0d000 xp /ug 0x7fc0d000 7fc0d000:147428917 < with high cpu load after loadvm, steal time still shows a linear increase The steal_time value would go backward (because of the overflow) after the restoration of the VM state without the fix. - I'm pasting in text from Debian Bug 785557 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785557 b/c I couldn't find this issue reported. It is present in QEMU 2.3, but I haven't tested later versions. Perhaps someone else will find this bug and confirm for later versions. (Or I will when I have time!) Hi, I'm trying to debug an issue we're having with some debian.org machines running in QEMU 2.1.2 instances (see [1] for more background). In short, after a live migration guests running Debian Jessie (linux 3.16) stop accounting CPU time properly. /proc/stat in the guest shows no increase in user and system time anymore (regardless of workload) and what stands out are extremely large values for steal time: % cat /proc/stat cpu 2400 0 1842 650879168 2579640 0 25 136562317270 0 0 cpu0 1366 0 1028 161392988 1238598 0 11 383803090749 0 0 cpu1 294 0 240 162582008 639105 0 8 39686436048 0 0 cpu2 406 0 338 163331066 383867 0 4 333994238765 0 0 cpu3 332 0 235 163573105 318069 0 1 1223752959076 0 0 intr 355773871 33 10 0 0 0 0 3 0 1 0 0 36 144 0 0 1638612 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 5001741 41 0 8516993 0 3669582 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ctxt 837862829 btime 1431642967 processes 8529939 procs_running 1 procs_blocked 0 softirq 225193331 2 77532878 172 7250024 819289 0 54 33739135 176552 105675225 Reading the memory pointed to by the steal time MSRs pre- and post-migration, I can see that post-migration the high bytes are set to 0xff: (qemu) xp /8b 0x1fc0cfc0 1fc0cfc0: 0x94 0x57 0x77 0xf5 0xff 0xff 0xff 0xff The "jump" in steal time happens when the guest is resumed on the receiving side. I've also been able to consistently reproduce this on a Ganeti cluster at work, using QEMU 2.1.3 and kernels 3.16 and 4.0 in the guests. The issue goes away if I disable the steal time MSR using `-cpu qemu64,-kvm_steal_time`. So, it looks to me as if the steal time MSR is not set/copied properly during live migration, although AFAICT this should be the case after 917367aa968fd4fef29d340e0c7ec8c608dffaab. After
[Bug 1494350] Re: QEMU: causes vCPU steal time overflow on live migration
** Description changed: + Testing Steps with patched trusty kernel: + + Using savemv & loadvm to simulate the migration process. + + In guest: + 1. check steal_time data location + rdmsr 0x4b564d03 <- returns the start address 0x7fc0d000 + + 2. Exam the steal time before savevm in qemu monitor + (qemu) xp /ug 0x7fc0d000 + xp /ug 0x7fc0d000 + 7fc0d000:144139048 < steal time value before savevm + (qemu) savevm mytestvm7 + savevm mytestvm7 + (qemu) quit + quit + + 3. give some load to the host system, e.g. stress --cpu + + 4. start the guest with "-loadvm mytestvm7" to restore the state of the + VM, thus the steal_time MSR + + (qemu) xp /ug 0x7fc0d000 + xp /ug 0x7fc0d000 + 7fc0d000:147428917 < with high cpu load after loadvm, steal time still shows a linear increase + + The steal_time value would go backward (because of the overflow) after + the restoration of the VM state without the fix. + + - + + I'm pasting in text from Debian Bug 785557 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785557 b/c I couldn't find this issue reported. It is present in QEMU 2.3, but I haven't tested later versions. Perhaps someone else will find this bug and confirm for later versions. (Or I will when I have time!) Hi, - I'm trying to debug an issue we're having with some debian.org machines - running in QEMU 2.1.2 instances (see [1] for more background). In short, - after a live migration guests running Debian Jessie (linux 3.16) stop - accounting CPU time properly. /proc/stat in the guest shows no increase - in user and system time anymore (regardless of workload) and what stands + I'm trying to debug an issue we're having with some debian.org machines + running in QEMU 2.1.2 instances (see [1] for more background). In short, + after a live migration guests running Debian Jessie (linux 3.16) stop + accounting CPU time properly. /proc/stat in the guest shows no increase + in user and system time anymore (regardless of workload) and what stands out are extremely large values for steal time: - % cat /proc/stat - cpu 2400 0 1842 650879168 2579640 0 25 136562317270 0 0 - cpu0 1366 0 1028 161392988 1238598 0 11 383803090749 0 0 - cpu1 294 0 240 162582008 639105 0 8 39686436048 0 0 - cpu2 406 0 338 163331066 383867 0 4 333994238765 0 0 - cpu3 332 0 235 163573105 318069 0 1 1223752959076 0 0 - intr 355773871 33 10 0 0 0 0 3 0 1 0 0 36 144 0 0 1638612 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 5001741 41 0 8516993 0 3669582 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + % cat /proc/stat + cpu 2400 0 1842 650879168 2579640 0 25 136562317270 0 0 + cpu0 1366 0 1028 161392988 1238598 0 11 383803090749 0 0 + cpu1 294 0 240 162582008 639105 0 8 39686436048 0 0 + cpu2 406 0 338 163331066 383867 0 4 333994238765 0 0 + cpu3 332 0 235 163573105 318069 0 1 1223752959076 0 0 + intr 355773871 33 10 0 0 0 0 3 0 1 0 0 36 144 0 0 1638612 0 0 0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0 0 0 0 0 0 0 5 5001741 41 0 8516993 0 3669582 0 0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 + 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
[Bug 1494350] Re: QEMU: causes vCPU steal time overflow on live migration
** Also affects: linux (Ubuntu) Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Assignee: (unassigned) => Liang Chen (cbjchen) ** Changed in: linux (Ubuntu) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1494350 Title: QEMU: causes vCPU steal time overflow on live migration To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1494350/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Also affects: cloud-archive Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Also affects: cloud-archive Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Changed in: qemu (Ubuntu Wily) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1546445] Re: support vhost user without specifying vhostforce
** Changed in: qemu (Ubuntu Wily) Status: New => Fix Released -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to qemu in Ubuntu. https://bugs.launchpad.net/bugs/1546445 Title: support vhost user without specifying vhostforce To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-archive/+bug/1546445/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1514325] Re: VersionedObject.__repr__ should return encoded string
** Description changed: - The following error is reported when creating a volume snapshot with - non-ascii display-description, e.g. cinder snapshot-create --display- - description "中文" my-2nd-volume. + [Impact] + + * Cinder snapshot display-description cannot contain non-ascii + characters. + + [Test Case] + + * cinder create 1 + * cinder snapshot-create --display-description "中文" + + [Regression Potential] + + * None + + + The following error is reported when creating a volume snapshot with non-ascii display-description, e.g. cinder snapshot-create --display-description "中文" my-2nd-volume. 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher [req-81f48a02-b1ef-4aae-9e22-ac2ce1c75b2f 16818cbff07548889da69bf526558d97 7aac0111a39741f59513c05b2d83dd70 - - -] Exception during message handling: 'ascii' codec can't encode characters in position 111-117: ordinal not in range(128) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher executor_callback)) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher executor_callback) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 129, in _do_dispatch 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher result = func(ctxt, **new_args) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/osprofiler/profiler.py", line 102, in wrapper 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher info["function"]["kwargs"] = str(kwargs) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher UnicodeEncodeError: 'ascii' codec can't encode characters in position 111-117: ordinal not in range(128) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher Root cause is that profiler tries to get a string representation of the arguments (cinder.objects.snapshot.Snapshot) of the snapshot-create cinder-volume service api. As a result, VersionedObject.__repr__ is called to produce such a string representation with an attribute (display-description) containing non-ascii characters, thus returning an unicode object. However when __repr__ returns an unicode object, it's expected that the the returned string can be encoded by default encoding scheme which is ascii in general [1][2]. So __repr__ needs to make sure any unicode string it's going to return are properly encoded. [1] trying to encode the returned string when it's an unicode object https://github.com/python/cpython/blob/2.7/Objects/object.c#L387 [2] if encoding arg is left null, default encoding will be used https://github.com/python/cpython/blob/2.7/Objects/unicodeobject.c#L1355 ** Also affects: cinder (Ubuntu) Importance: Undecided Status: New ** Changed in: cinder (Ubuntu) Status: New => In Progress ** Changed in: cinder (Ubuntu) Assignee: (unassigned) => Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cinder in Ubuntu. https://bugs.launchpad.net/bugs/1514325 Title: VersionedObject.__repr__ should return encoded string To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1514325/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1514325] Re: VersionedObject.__repr__ should return encoded string
** Branch linked: lp:~cbjchen/cinder/lp1514325 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to cinder in Ubuntu. https://bugs.launchpad.net/bugs/1514325 Title: VersionedObject.__repr__ should return encoded string To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1514325/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1514325] Re: VersionedObject.__repr__ should return encoded string
** Branch linked: lp:~cbjchen/cinder/lp1514325 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1514325 Title: VersionedObject.__repr__ should return encoded string To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1514325/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1514325] Re: VersionedObject.__repr__ should return encoded string
** Description changed: - The following error is reported when creating a volume snapshot with - non-ascii display-description, e.g. cinder snapshot-create --display- - description "中文" my-2nd-volume. + [Impact] + + * Cinder snapshot display-description cannot contain non-ascii + characters. + + [Test Case] + + * cinder create 1 + * cinder snapshot-create --display-description "中文" + + [Regression Potential] + + * None + + + The following error is reported when creating a volume snapshot with non-ascii display-description, e.g. cinder snapshot-create --display-description "中文" my-2nd-volume. 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher [req-81f48a02-b1ef-4aae-9e22-ac2ce1c75b2f 16818cbff07548889da69bf526558d97 7aac0111a39741f59513c05b2d83dd70 - - -] Exception during message handling: 'ascii' codec can't encode characters in position 111-117: ordinal not in range(128) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher Traceback (most recent call last): 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 142, in _dispatch_and_reply 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher executor_callback)) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 186, in _dispatch 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher executor_callback) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 129, in _do_dispatch 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher result = func(ctxt, **new_args) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher File "/usr/lib/python2.7/dist-packages/osprofiler/profiler.py", line 102, in wrapper 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher info["function"]["kwargs"] = str(kwargs) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher UnicodeEncodeError: 'ascii' codec can't encode characters in position 111-117: ordinal not in range(128) 2015-11-09 05:55:50.995 29937 ERROR oslo_messaging.rpc.dispatcher Root cause is that profiler tries to get a string representation of the arguments (cinder.objects.snapshot.Snapshot) of the snapshot-create cinder-volume service api. As a result, VersionedObject.__repr__ is called to produce such a string representation with an attribute (display-description) containing non-ascii characters, thus returning an unicode object. However when __repr__ returns an unicode object, it's expected that the the returned string can be encoded by default encoding scheme which is ascii in general [1][2]. So __repr__ needs to make sure any unicode string it's going to return are properly encoded. [1] trying to encode the returned string when it's an unicode object https://github.com/python/cpython/blob/2.7/Objects/object.c#L387 [2] if encoding arg is left null, default encoding will be used https://github.com/python/cpython/blob/2.7/Objects/unicodeobject.c#L1355 ** Also affects: cinder (Ubuntu) Importance: Undecided Status: New ** Changed in: cinder (Ubuntu) Status: New => In Progress ** Changed in: cinder (Ubuntu) Assignee: (unassigned) => Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1514325 Title: VersionedObject.__repr__ should return encoded string To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1514325/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1500684] Re: update to 5.6.20 or above for security fixes
** Changed in: mysql-5.6 (Ubuntu Trusty) Status: Triaged => In Progress ** Changed in: mysql-5.6 (Ubuntu Trusty) Assignee: (unassigned) => Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1500684 Title: update to 5.6.20 or above for security fixes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1500684/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1500684] Re: update to 5.6.20 or above for security fixes
** Changed in: mysql-5.6 (Ubuntu Trusty) Status: Triaged => In Progress ** Changed in: mysql-5.6 (Ubuntu Trusty) Assignee: (unassigned) => Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mysql-5.6 in Ubuntu. https://bugs.launchpad.net/bugs/1500684 Title: update to 5.6.20 or above for security fixes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1500684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1500684] Re: update to 5.6.20 or above for security fixes
** Summary changed: - update to 5.6.20 for security fixes + update to 5.6.20 or above for security fixes -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mysql-5.6 in Ubuntu. https://bugs.launchpad.net/bugs/1500684 Title: update to 5.6.20 or above for security fixes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1500684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1500684] Re: update to 5.6.20 or above for security fixes
** Summary changed: - update to 5.6.20 for security fixes + update to 5.6.20 or above for security fixes -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1500684 Title: update to 5.6.20 or above for security fixes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1500684/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1500684] [NEW] update to 5.6.20 for security fixes
Public bug reported: A three year old security bug - MySQL Authentication Error Message User Enumeration Vulnerability still presents in trusty package. ** Affects: mysql-5.6 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to mysql-5.6 in Ubuntu. https://bugs.launchpad.net/bugs/1500684 Title: update to 5.6.20 for security fixes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1500684/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1500684] [NEW] update to 5.6.20 for security fixes
Public bug reported: A three year old security bug - MySQL Authentication Error Message User Enumeration Vulnerability still presents in trusty package. ** Affects: mysql-5.6 (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1500684 Title: update to 5.6.20 for security fixes To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1500684/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1457517] Re: Unable to boot from volume when flavor disk too small
** Description changed:
+ [Impact]
+
+ * Without the backport, booting from volume requires flavor disk size
+ larger than volume size, which is wrong. This patch skips flavor disk
+ size checking when booting from volume.
+
+ [Test Case]
+
+ * 1. create a bootable volume
+2. boot from this bootable volume with a flavor that has disk size smaller
than the volume size
+3. error should be reported complaining disk size too small
+4. apply this patch
+5. boot from that bootable volume with a flavor that has disk size smaller
than the volume size again
+6. boot should succeed
+
+ [Regression Potential]
+
+ * none
+
+
Version: 1:2015.1.0-0ubuntu1~cloud0 on Ubuntu 14.04
I attempt to boot an instance from a volume:
nova boot --nic net-id=[NET ID] --flavor v.512mb --block-device
source=volume,dest=volume,id=[VOLUME
ID],bus=virtio,device=vda,bootindex=0,shutdown=preserve vm
This results in nova-api raising a FlavorDiskTooSmall exception in the
_check_requested_image function in compute/api.py. However, according
to [1], the root disk limit should not apply to volumes.
[1] http://docs.openstack.org/admin-guide-cloud/content/customize-
flavors.html
Log (first line is debug output I added showing that it's looking at the
image that the volume was created from):
2015-05-21 10:28:00.586 25835 INFO nova.compute.api
[req-1fb882c7-07ae-4c2b-86bd-3d174602d0ae f438b80d215c42efb7508c59dc80940c
8341c85ad9ae49408fa25074adba0480 - - -] image: {'min_disk': 0, 'status':
'active', 'min_ram': 0, 'properties': {u'container_format': u'bare',
u'min_ram': u'0', u'disk_format': u'qcow2', u'image_name': u'Ubuntu 14.04
64-bit', u'image_id': u'cf0dffef-30ef-4032-add0-516e88048d85',
u'libvirt_cpu_mode': u'host-passthrough', u'checksum':
u'76a965427d2866f006ddd2aac66ed5b9', u'min_disk': u'0', u'size': u'255524864'},
'size': 21474836480}
2015-05-21 10:28:00.587 25835 INFO nova.api.openstack.wsgi
[req-1fb882c7-07ae-4c2b-86bd-3d174602d0ae f438b80d215c42efb7508c59dc80940c
8341c85ad9ae49408fa25074adba0480 - - -] HTTP exception thrown: Flavor's disk is
too small for requested image.
Temporary solution: I have special flavor for volume-backed instances so I
just set the root disk on those to 0, but this doesn't work if volume are used
on other flavors.
Reproduce: create flavor with 1 GB root disk size, then try to boot an
instance from a volume created from an image that is larger than 1 GB.
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
** Changed in: nova (Ubuntu)
Assignee: (unassigned) = Liang Chen (cbjchen)
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1457517
Title:
Unable to boot from volume when flavor disk too small
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1457517/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1457517] Re: Unable to boot from volume when flavor disk too small
** Description changed:
+ [Impact]
+
+ * Without the backport, booting from volume requires flavor disk size
+ larger than volume size, which is wrong. This patch skips flavor disk
+ size checking when booting from volume.
+
+ [Test Case]
+
+ * 1. create a bootable volume
+2. boot from this bootable volume with a flavor that has disk size smaller
than the volume size
+3. error should be reported complaining disk size too small
+4. apply this patch
+5. boot from that bootable volume with a flavor that has disk size smaller
than the volume size again
+6. boot should succeed
+
+ [Regression Potential]
+
+ * none
+
+
Version: 1:2015.1.0-0ubuntu1~cloud0 on Ubuntu 14.04
I attempt to boot an instance from a volume:
nova boot --nic net-id=[NET ID] --flavor v.512mb --block-device
source=volume,dest=volume,id=[VOLUME
ID],bus=virtio,device=vda,bootindex=0,shutdown=preserve vm
This results in nova-api raising a FlavorDiskTooSmall exception in the
_check_requested_image function in compute/api.py. However, according
to [1], the root disk limit should not apply to volumes.
[1] http://docs.openstack.org/admin-guide-cloud/content/customize-
flavors.html
Log (first line is debug output I added showing that it's looking at the
image that the volume was created from):
2015-05-21 10:28:00.586 25835 INFO nova.compute.api
[req-1fb882c7-07ae-4c2b-86bd-3d174602d0ae f438b80d215c42efb7508c59dc80940c
8341c85ad9ae49408fa25074adba0480 - - -] image: {'min_disk': 0, 'status':
'active', 'min_ram': 0, 'properties': {u'container_format': u'bare',
u'min_ram': u'0', u'disk_format': u'qcow2', u'image_name': u'Ubuntu 14.04
64-bit', u'image_id': u'cf0dffef-30ef-4032-add0-516e88048d85',
u'libvirt_cpu_mode': u'host-passthrough', u'checksum':
u'76a965427d2866f006ddd2aac66ed5b9', u'min_disk': u'0', u'size': u'255524864'},
'size': 21474836480}
2015-05-21 10:28:00.587 25835 INFO nova.api.openstack.wsgi
[req-1fb882c7-07ae-4c2b-86bd-3d174602d0ae f438b80d215c42efb7508c59dc80940c
8341c85ad9ae49408fa25074adba0480 - - -] HTTP exception thrown: Flavor's disk is
too small for requested image.
Temporary solution: I have special flavor for volume-backed instances so I
just set the root disk on those to 0, but this doesn't work if volume are used
on other flavors.
Reproduce: create flavor with 1 GB root disk size, then try to boot an
instance from a volume created from an image that is larger than 1 GB.
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
** Changed in: nova (Ubuntu)
Assignee: (unassigned) = Liang Chen (cbjchen)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1457517
Title:
Unable to boot from volume when flavor disk too small
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1457517/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348244] Re: debug log messages need to be unicode
@Sebastien, The fix for Nova is merged at LP#1459046. cinder patch is still needed. But the current cinder patch is unnecessarily big, it can be done more easily as LP#1459046 does. I will remove the cinder patch for now, and propose a simpler one later. Thanks. ** Patch removed: trusty cinder debdiff https://bugs.launchpad.net/nova/+bug/1348244/+attachment/4416906/+files/cinder-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348244] Re: debug log messages need to be unicode
@Sebastien, The fix for Nova is merged at LP#1459046. cinder patch is still needed. But the current cinder patch is unnecessarily big, it can be done more easily as LP#1459046 does. I will remove the cinder patch for now, and propose a simpler one later. Thanks. ** Patch removed: trusty cinder debdiff https://bugs.launchpad.net/nova/+bug/1348244/+attachment/4416906/+files/cinder-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
The proposed build have been deployed and tested, and this work as expected. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
The proposed build have been deployed and tested, and this work as expected. ** Tags removed: verification-needed ** Tags added: verification-done -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1353939] Re: Rescue fails with 'Failed to terminate process: Device or resource busy' in the n-cpu log
** Description changed: + [Impact] + + * Users may sometimes fail to shutdown an instance if the associated qemu +process is on uninterruptable sleep (typically IO). + + [Test Case] + + * 1. create some IO load in a VM +2. look at the associated qemu, make sure it has STAT D in ps output +3. shutdown the instance +4. with the patch in place, nova will retry calling libvirt to shutdown + the instance 3 times to wait for the signal to be delivered to the + qemu process. + + [Regression Potential] + + * None + + message: Failed to terminate process AND message:'InstanceNotRescuable' AND message: 'Exception during message handling' AND tags:screen-n-cpu.txt The above log stash-query reports back only the failed jobs, the 'Failed to terminate process' close other failed rescue tests, but tempest does not always reports them as an error at the end. message: Failed to terminate process AND tags:screen-n-cpu.txt Usual console log: Details: (ServerRescueTestJSON:test_rescue_unrescue_instance) Server 0573094d-53da-40a5-948a-747d181462f5 failed to reach RESCUE status and task state None within the required time (196 s). Current status: SHUTOFF. Current task state: None. http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres- full/90726cb/console.html#_2014-08-07_03_50_26_520 Usual n-cpu exception: http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres-full/90726cb/logs/screen-n-cpu.txt.gz#_2014-08-07_03_32_02_855 2014-08-07 03:32:02.855 ERROR oslo.messaging.rpc.dispatcher [req-39ce7a3d-5ceb-41f5-8f9f-face7e608bd1 ServerRescueTestJSON-2035684545 ServerRescueTestJSON-1017508309] Exception during message handling: Instance 0573094d-53da-40a5-948a-747d181462f5 cannot be rescued: Driver Error: Failed to terminate process 26425 with SIGKILL: Device or resource busy 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 134, in _dispatch_and_reply 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 177, in _dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 123, in _do_dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 408, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 88, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher payload) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 82, in __exit__ 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 71, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return f(self, context, *args, **kw) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 292, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher pass 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 82, in __exit__ 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 278, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 342, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE
[Bug 1353939] Re: Rescue fails with 'Failed to terminate process: Device or resource busy' in the n-cpu log
** Description changed: + [Impact] + + * Users may sometimes fail to shutdown an instance if the associated qemu +process is on uninterruptable sleep (typically IO). + + [Test Case] + + * 1. create some IO load in a VM +2. look at the associated qemu, make sure it has STAT D in ps output +3. shutdown the instance +4. with the patch in place, nova will retry calling libvirt to shutdown + the instance 3 times to wait for the signal to be delivered to the + qemu process. + + [Regression Potential] + + * None + + message: Failed to terminate process AND message:'InstanceNotRescuable' AND message: 'Exception during message handling' AND tags:screen-n-cpu.txt The above log stash-query reports back only the failed jobs, the 'Failed to terminate process' close other failed rescue tests, but tempest does not always reports them as an error at the end. message: Failed to terminate process AND tags:screen-n-cpu.txt Usual console log: Details: (ServerRescueTestJSON:test_rescue_unrescue_instance) Server 0573094d-53da-40a5-948a-747d181462f5 failed to reach RESCUE status and task state None within the required time (196 s). Current status: SHUTOFF. Current task state: None. http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres- full/90726cb/console.html#_2014-08-07_03_50_26_520 Usual n-cpu exception: http://logs.openstack.org/82/107982/2/gate/gate-tempest-dsvm-postgres-full/90726cb/logs/screen-n-cpu.txt.gz#_2014-08-07_03_32_02_855 2014-08-07 03:32:02.855 ERROR oslo.messaging.rpc.dispatcher [req-39ce7a3d-5ceb-41f5-8f9f-face7e608bd1 ServerRescueTestJSON-2035684545 ServerRescueTestJSON-1017508309] Exception during message handling: Instance 0573094d-53da-40a5-948a-747d181462f5 cannot be rescued: Driver Error: Failed to terminate process 26425 with SIGKILL: Device or resource busy 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher Traceback (most recent call last): 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 134, in _dispatch_and_reply 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher incoming.message)) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 177, in _dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return self._do_dispatch(endpoint, method, ctxt, args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /usr/local/lib/python2.7/dist-packages/oslo/messaging/rpc/dispatcher.py, line 123, in _do_dispatch 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher result = getattr(endpoint, method)(ctxt, **new_args) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 408, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 88, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher payload) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 82, in __exit__ 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/exception.py, line 71, in wrapped 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return f(self, context, *args, **kw) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 292, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher pass 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/openstack/common/excutils.py, line 82, in __exit__ 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher six.reraise(self.type_, self.value, self.tb) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 278, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher File /opt/stack/new/nova/nova/compute/manager.py, line 342, in decorated_function 2014-08-07 03:32:02.855 22829 TRACE oslo.messaging.rpc.dispatcher return function(self, context, *args, **kwargs) 2014-08-07 03:32:02.855 22829 TRACE
[Bug 1408088] Re: [SRU] not able to upload binary files when booting a vm
** Changed in: python-novaclient (Ubuntu Trusty) Assignee: (unassigned) = Liang Chen (cbjchen) ** Changed in: python-novaclient (Ubuntu) Status: In Progress = Fix Committed -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to python-novaclient in Ubuntu. https://bugs.launchpad.net/bugs/1408088 Title: [SRU] not able to upload binary files when booting a vm To manage notifications about this bug go to: https://bugs.launchpad.net/python-novaclient/+bug/1408088/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1408088] Re: [SRU] not able to upload binary files when booting a vm
** Changed in: python-novaclient (Ubuntu Trusty) Assignee: (unassigned) = Liang Chen (cbjchen) ** Changed in: python-novaclient (Ubuntu) Status: In Progress = Fix Committed -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1408088 Title: [SRU] not able to upload binary files when booting a vm To manage notifications about this bug go to: https://bugs.launchpad.net/python-novaclient/+bug/1408088/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1454070] Re: Upgrading to 1.3.0-0ubuntu1.1 causes a large number of connections
Hi Sam, 1.3.0-0ubuntu1.1 is already superseded by 1.3.0-0ubuntu1.2 in trusty-updates/main [1], and it works for me - 4 connections all the time. ubuntu@juju-cbjchen-machine-14:~$ sudo netstat -alnpt | grep 1979 tcp0 0 10.5.0.151:3886110.5.0.155:5672 ESTABLISHED 1979/python tcp0 0 10.5.0.151:3887210.5.0.155:5672 ESTABLISHED 1979/python tcp0 0 10.5.0.151:3886210.5.0.155:5672 ESTABLISHED 1979/python tcp0 0 10.5.0.151:3886310.5.0.155:5672 ESTABLISHED 1979/python Can you please try 1.3.0-0ubuntu1.2 instead? [1] https://launchpad.net/ubuntu/+source/oslo.messaging -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1454070 Title: Upgrading to 1.3.0-0ubuntu1.1 causes a large number of connections To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/oslo.messaging/+bug/1454070/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1459046] Re: [SRU] nova-* services do not start if rsyslog is not yet started
** Changed in: oslo.log Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1459046 Title: [SRU] nova-* services do not start if rsyslog is not yet started To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459046/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1459046] Re: [SRU] nova-* services do not start if rsyslog is not yet started
** Changed in: oslo.log Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1459046 Title: [SRU] nova-* services do not start if rsyslog is not yet started To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Description changed: + This feature will cause an ACPI event to be sent to the system while + shutting down, and the acpid running inside the system can catch the + event, thus giving the system a chance to shutdown cleanly. + [Impact] - * VMs being shutdown with any signal/notification from the The + * VMs being shutdown with any signal/notification from the The hypervisor level, services running inside VMs have no chance to perform a clean shutoff [Test Case] - * 1. stop a VM -2. the VM is shutdown without any notification + * 1. stop a VM + 2. the VM is shutdown without any notification + + The can be easily seen by ssh into the system before shutting down. With + the patch in place, the ssh session will be close during shutdown, + because the sshd has the chance to close the connection before being + brought down. Without the patch, the ssh session will just hang there + for a while until timeout, because the connection is not promptly + closed. + + + To leverage the clean shutdown feature, one can create a file named /etc/acpi/events/power that contains the following: + + event=button/power + action=/etc/acpi/power.sh %e + + Then create a file named /etc/acpi/power.sh that contains whatever required to gracefully shutdown a particular server (VM). + With the apicd running, shutdown of the VM will cause the rule in /etc/acpi/events/power to trigger the script in /etc/acpi/power.sh, thus cleanly shutdown the system. + [Regression Potential] - * none + * none - Currently in libvirt stop and delete operations simply destroy the - underlying VM. Some GuestOS's do not react well to this type of - power failure, and it would be better if these operations followed the - same approach a a soft_reboot and give the guest a chance to shutdown - gracefully. Even where VM is being deleted, it may be booted from a - volume which will be reused on another server. + Currently in libvirt stop and delete operations simply destroy the underlying VM. Some GuestOS's do not react well to this type of power failure, and it would be better if these operations followed the same approach a a soft_reboot and give the guest a chance to shutdown gracefully. Even where VM is being deleted, it may be booted from a volume which will be reused on another server. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Description changed: + This feature will cause an ACPI event to be sent to the system while + shutting down, and the acpid running inside the system can catch the + event, thus giving the system a chance to shutdown cleanly. + [Impact] - * VMs being shutdown with any signal/notification from the The + * VMs being shutdown with any signal/notification from the The hypervisor level, services running inside VMs have no chance to perform a clean shutoff [Test Case] - * 1. stop a VM -2. the VM is shutdown without any notification + * 1. stop a VM + 2. the VM is shutdown without any notification + + The can be easily seen by ssh into the system before shutting down. With + the patch in place, the ssh session will be close during shutdown, + because the sshd has the chance to close the connection before being + brought down. Without the patch, the ssh session will just hang there + for a while until timeout, because the connection is not promptly + closed. + + + To leverage the clean shutdown feature, one can create a file named /etc/acpi/events/power that contains the following: + + event=button/power + action=/etc/acpi/power.sh %e + + Then create a file named /etc/acpi/power.sh that contains whatever required to gracefully shutdown a particular server (VM). + With the apicd running, shutdown of the VM will cause the rule in /etc/acpi/events/power to trigger the script in /etc/acpi/power.sh, thus cleanly shutdown the system. + [Regression Potential] - * none + * none - Currently in libvirt stop and delete operations simply destroy the - underlying VM. Some GuestOS's do not react well to this type of - power failure, and it would be better if these operations followed the - same approach a a soft_reboot and give the guest a chance to shutdown - gracefully. Even where VM is being deleted, it may be booted from a - volume which will be reused on another server. + Currently in libvirt stop and delete operations simply destroy the underlying VM. Some GuestOS's do not react well to this type of power failure, and it would be better if these operations followed the same approach a a soft_reboot and give the guest a chance to shutdown gracefully. Even where VM is being deleted, it may be booted from a volume which will be reused on another server. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Changed in: nova (Ubuntu Trusty) Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Changed in: nova (Ubuntu Trusty) Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Changed in: nova (Ubuntu) Status: New = In Progress -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Changed in: nova (Ubuntu) Status: New = In Progress -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348244] Re: debug log messages need to be unicode
Nova SRU is removed as it will be fixed at https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1459046 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348244] Re: debug log messages need to be unicode
Nova SRU is removed as it will be fixed at https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1459046 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Patch removed: trusty nova debdiff https://bugs.launchpad.net/nova/+bug/1348244/+attachment/4408927/+files/nova-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Patch removed: trusty nova debdiff https://bugs.launchpad.net/nova/+bug/1348244/+attachment/4408927/+files/nova-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Patch added: vivid-kilo patch for python-oslo.log https://bugs.launchpad.net/oslo.log/+bug/1385295/+attachment/4423044/+files/python-oslo.log_1.0.0-0ubuntu2-lp1385259.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Patch added: vivid-kilo patch for python-oslo.log https://bugs.launchpad.net/oslo.log/+bug/1385295/+attachment/4423044/+files/python-oslo.log_1.0.0-0ubuntu2-lp1385259.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Also affects: nova (Ubuntu) Importance: Undecided Status: New ** Changed in: nova (Ubuntu) Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Changed in: python-oslo.log (Ubuntu) Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Description changed: + [Impact] + + * VMs being shutdown with any signal/notification from the The + hypervisor level, services running inside VMs have no chance to perform + a clean shutoff + + [Test Case] + + * 1. stop a VM +2. the VM is shutdown without any notification + + [Regression Potential] + + * none + + Currently in libvirt stop and delete operations simply destroy the underlying VM. Some GuestOS's do not react well to this type of power failure, and it would be better if these operations followed the same approach a a soft_reboot and give the guest a chance to shutdown gracefully. Even where VM is being deleted, it may be booted from a volume which will be reused on another server. ** Patch added: trusty nova patch https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1196924/+attachment/4423093/+files/nova-2014.1.4-0ubuntu2.2-lp1196924.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Description changed: + [Impact] + + * VMs being shutdown with any signal/notification from the The + hypervisor level, services running inside VMs have no chance to perform + a clean shutoff + + [Test Case] + + * 1. stop a VM +2. the VM is shutdown without any notification + + [Regression Potential] + + * none + + Currently in libvirt stop and delete operations simply destroy the underlying VM. Some GuestOS's do not react well to this type of power failure, and it would be better if these operations followed the same approach a a soft_reboot and give the guest a chance to shutdown gracefully. Even where VM is being deleted, it may be booted from a volume which will be reused on another server. ** Patch added: trusty nova patch https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1196924/+attachment/4423093/+files/nova-2014.1.4-0ubuntu2.2-lp1196924.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Changed in: python-oslo.log (Ubuntu) Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1196924] Re: Stop and Delete operations should give the Guest a chance to shutdown
** Also affects: nova (Ubuntu) Importance: Undecided Status: New ** Changed in: nova (Ubuntu) Assignee: (unassigned) = Liang Chen (cbjchen) -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1196924 Title: Stop and Delete operations should give the Guest a chance to shutdown To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1196924/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Description changed: - Nova SRU: + python-oslo.log SRU: [Impact] * Nova services not able to write log to syslog [Test Case] - * Set user_syslog to True in nova.conf, restart nova services. Log - is not written to syslog. + * 1. Set use_syslog to True in nova.conf/cinder.conf +2. stop rsyslog service +3. restart nova/cinder services +4. restart rsyslog service +5. Log is not written to syslog after rsyslog is brought up. [Regression Potential] * none - Cinder SRU: - [Impact] - - * Cinder services not able to write log to syslog - - [Test Case] - - * Set user_syslog to True in cinder.conf, restart cinder services. Log - is not written to syslog. - - [Regression Potential] - - * none Reproduced on: https://github.com/openstack-dev/devstack 514c82030cf04da742d16582a23cc64962fdbda1 /opt/stack/keystone/keystone.egg-info/PKG-INFO:Version: 2015.1.dev95.g20173b1 /opt/stack/heat/heat.egg-info/PKG-INFO:Version: 2015.1.dev213.g8354c98 /opt/stack/glance/glance.egg-info/PKG-INFO:Version: 2015.1.dev88.g6bedcea /opt/stack/cinder/cinder.egg-info/PKG-INFO:Version: 2015.1.dev110.gc105259 How to reproduce: Set use_syslog=True syslog_log_facility=LOG_SYSLOG for Openstack config files and restart processes inside their screens Expected: Openstack logs logged to syslog as well Actual: Nothing goes to syslog ** Patch added: vivid-kilo patch https://bugs.launchpad.net/oslo.log/+bug/1385295/+attachment/4423006/+files/python-oslo.log_1.0.0-0ubuntu2-lp1385259.patch ** Patch removed: vivid-kilo patch for python-oslo.log https://bugs.launchpad.net/oslo.log/+bug/1385295/+attachment/4423006/+files/python-oslo.log_1.0.0-0ubuntu2-lp1385259.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Description changed: - Nova SRU: + python-oslo.log SRU: [Impact] * Nova services not able to write log to syslog [Test Case] - * Set user_syslog to True in nova.conf, restart nova services. Log - is not written to syslog. + * 1. Set use_syslog to True in nova.conf/cinder.conf +2. stop rsyslog service +3. restart nova/cinder services +4. restart rsyslog service +5. Log is not written to syslog after rsyslog is brought up. [Regression Potential] * none - Cinder SRU: - [Impact] - - * Cinder services not able to write log to syslog - - [Test Case] - - * Set user_syslog to True in cinder.conf, restart cinder services. Log - is not written to syslog. - - [Regression Potential] - - * none Reproduced on: https://github.com/openstack-dev/devstack 514c82030cf04da742d16582a23cc64962fdbda1 /opt/stack/keystone/keystone.egg-info/PKG-INFO:Version: 2015.1.dev95.g20173b1 /opt/stack/heat/heat.egg-info/PKG-INFO:Version: 2015.1.dev213.g8354c98 /opt/stack/glance/glance.egg-info/PKG-INFO:Version: 2015.1.dev88.g6bedcea /opt/stack/cinder/cinder.egg-info/PKG-INFO:Version: 2015.1.dev110.gc105259 How to reproduce: Set use_syslog=True syslog_log_facility=LOG_SYSLOG for Openstack config files and restart processes inside their screens Expected: Openstack logs logged to syslog as well Actual: Nothing goes to syslog ** Patch added: vivid-kilo patch https://bugs.launchpad.net/oslo.log/+bug/1385295/+attachment/4423006/+files/python-oslo.log_1.0.0-0ubuntu2-lp1385259.patch ** Patch removed: vivid-kilo patch for python-oslo.log https://bugs.launchpad.net/oslo.log/+bug/1385295/+attachment/4423006/+files/python-oslo.log_1.0.0-0ubuntu2-lp1385259.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Also affects: python-oslo.log (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Also affects: python-oslo.log (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1459046] Re: nova-* services do not start if rsyslog is not yet started
Kilo master status: Master works without any problem. oslo.log 1.2.0 will start writing to syslog as soon as rsyslogd is brought up. Kilo uses oslo.log 1.1.0 which just ignores use_syslog setting when rsyslogd is not running or not started before nova-* services. I have proposed the backport (https://review.openstack.org/#/c/193633/) to oslo.log stable/kilo from oslo.log master, and will get to the maintainer do a 1.0.1 release once merged. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1459046 Title: nova-* services do not start if rsyslog is not yet started To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459046/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1459046] Re: nova-* services do not start if rsyslog is not yet started
Kilo master status: Master works without any problem. oslo.log 1.2.0 will start writing to syslog as soon as rsyslogd is brought up. Kilo uses oslo.log 1.1.0 which just ignores use_syslog setting when rsyslogd is not running or not started before nova-* services. I have proposed the backport (https://review.openstack.org/#/c/193633/) to oslo.log stable/kilo from oslo.log master, and will get to the maintainer do a 1.0.1 release once merged. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1459046 Title: nova-* services do not start if rsyslog is not yet started To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1459046/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Patch added: trusty cinder debdiff https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1348244/+attachment/4416906/+files/cinder-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Patch removed: trusty cinder debdiff https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1348244/+attachment/4411790/+files/cinder-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nova in Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Patch removed: trusty cinder debdiff https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1348244/+attachment/4411790/+files/cinder-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Patch added: trusty cinder debdiff https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1348244/+attachment/4416906/+files/cinder-2014.1.4-0ubuntu3-lp1348244.patch -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1348244 Title: debug log messages need to be unicode To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1385295] Re: use_syslog=True does not log to syslog via /dev/log anymore
** Also affects: nova (Ubuntu) Importance: Undecided Status: New ** Also affects: cinder (Ubuntu) Importance: Undecided Status: New ** Description changed: + Nova SRU: [Impact] - * Nova services not able to write log to syslog + * Nova services not able to write log to syslog [Test Case] - * Set user_syslog to True in nova.conf, restart nova services. Log -is not written to syslog. + * Set user_syslog to True in nova.conf, restart nova services. Log + is not written to syslog. [Regression Potential] - * none + * none + Cinder SRU: + [Impact] + + * Cinder services not able to write log to syslog + + [Test Case] + + * Set user_syslog to True in cinder.conf, restart cinder services. Log + is not written to syslog. + + [Regression Potential] + + * none Reproduced on: https://github.com/openstack-dev/devstack 514c82030cf04da742d16582a23cc64962fdbda1 /opt/stack/keystone/keystone.egg-info/PKG-INFO:Version: 2015.1.dev95.g20173b1 /opt/stack/heat/heat.egg-info/PKG-INFO:Version: 2015.1.dev213.g8354c98 /opt/stack/glance/glance.egg-info/PKG-INFO:Version: 2015.1.dev88.g6bedcea /opt/stack/cinder/cinder.egg-info/PKG-INFO:Version: 2015.1.dev110.gc105259 How to reproduce: Set use_syslog=True syslog_log_facility=LOG_SYSLOG for Openstack config files and restart processes inside their screens Expected: Openstack logs logged to syslog as well Actual: Nothing goes to syslog -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1385295 Title: use_syslog=True does not log to syslog via /dev/log anymore To manage notifications about this bug go to: https://bugs.launchpad.net/oslo.log/+bug/1385295/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1399088] Re: correct the position of the syslog Handler
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
** Also affects: cinder (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
[Impact]
- * syslog handler doesn't have the same settings as other handlers
+ * syslog handler doesn't have the same settings as other handlers
[Test Case]
- * Set user_syslog to True in nova.conf, restart nova services. Logs
-written to syslog doesn't have the same format as its own service
-log
-
+ * Set user_syslog to True in nova.conf, restart nova services. Logs
+ written to syslog doesn't have the same format as its own service
+ log
[Regression Potential]
- * none
-
+ * none
correct the position of the syslog Handler
syslog Handler should be in front of the line datefmt = CONF.log_date_format
Then syslog Handler can have the same settings with other handlers.
openstack/common/log.py
def _setup_logging_from_conf(project, version):
log_root = getLogger(None).logger
for handler in log_root.handlers:
log_root.removeHandler(handler)
logpath = _get_log_file_path()
if logpath:
filelog = logging.handlers.WatchedFileHandler(logpath)
log_root.addHandler(filelog)
if CONF.use_stderr:
streamlog = ColorHandler()
log_root.addHandler(streamlog)
elif not logpath:
# pass sys.stdout as a positional argument
# python2.6 calls the argument strm, in 2.7 it's stream
streamlog = logging.StreamHandler(sys.stdout)
log_root.addHandler(streamlog)
if CONF.publish_errors:
handler = importutils.import_object(
oslo.messaging.notify.log_handler.PublishErrorsHandler,
logging.ERROR)
log_root.addHandler(handler)
datefmt = CONF.log_date_format
for handler in log_root.handlers:
# NOTE(alaski): CONF.log_format overrides everything currently. This
# should be deprecated in favor of context aware formatting.
if CONF.log_format:
handler.setFormatter(logging.Formatter(fmt=CONF.log_format,
datefmt=datefmt))
log_root.info('Deprecated: log_format is now deprecated and will '
'be removed in the next release')
else:
handler.setFormatter(ContextFormatter(project=project,
version=version,
datefmt=datefmt))
if CONF.debug:
log_root.setLevel(logging.DEBUG)
elif CONF.verbose:
log_root.setLevel(logging.INFO)
else:
log_root.setLevel(logging.WARNING)
for pair in CONF.default_log_levels:
mod, _sep, level_name = pair.partition('=')
logger = logging.getLogger(mod)
# NOTE(AAzza) in python2.6 Logger.setLevel doesn't convert string name
# to integer code.
if sys.version_info (2, 7):
level = logging.getLevelName(level_name)
logger.setLevel(level)
else:
logger.setLevel(level_name)
if CONF.use_syslog:
try:
facility = _find_facility_from_conf()
# TODO(bogdando) use the format provided by RFCSysLogHandler
# after existing syslog format deprecation in J
if CONF.use_syslog_rfc_format:
syslog = RFCSysLogHandler(address='/dev/log',
facility=facility)
else:
syslog = logging.handlers.SysLogHandler(address='/dev/log',
facility=facility)
log_root.addHandler(syslog)
except socket.error:
log_root.error('Unable to add syslog handler. Verify that syslog '
'is running.')
** Description changed:
+ Nova SRU:
[Impact]
* syslog handler doesn't have the same settings as other handlers
[Test Case]
* Set user_syslog to True in nova.conf, restart nova services. Logs
written to syslog doesn't have the same format as its own service
log
[Regression Potential]
* none
+
+ Cinder SRU:
+ [Impact]
+
+ * syslog handler doesn't have the same settings as other handlers
+
+ [Test Case]
+
+ * Set user_syslog to True in cinder.conf, restart cinder services. Logs
+ written to syslog doesn't have the same format as its own service
+ log
+
+ [Regression Potential]
+
+ * none
+
correct the position of the syslog Handler
syslog Handler should be in front of the line datefmt = CONF.log_date_format
Then syslog Handler can have the same settings with other handlers.
openstack/common/log.py
def _setup_logging_from_conf(project, version):
log_root = getLogger(None).logger
[Bug 1348244] Re: debug log messages need to be unicode
Hi Chris,
Thanks for looking at the patch. I will contact James Page to review
wait-syslog-on-startup.patch, and update the corresponding bugs that are
referenced in the changelog.
Thanks,
Liang
** Description changed:
[Impact]
* Nova services fail to start because they cannot connect to rsyslog
[Test Case]
* Set user_syslog to True in nova.conf, stop rsyslog service and
restart nova services.
[Regression Potential]
- * None
+ * The following patches from 1385295 and 1399088 that address the
+regression introduced in this bug's fix are also included.
+fix-syslog-logging.patch (LP: #1385295)
+move-syslog-instantiation.patch (LP: #1399088)
- When nova services log to syslog, they should wait for syslog to start
- prior to the nova-* services start.
+ When nova services log to syslog, they should wait for syslog to start prior
to the nova-* services start.
Debug logs should be:
LOG.debug(message) should be LOG.debug(umessage)
Before the translation of debug log messages was removed, the
translation was returning unicode. Now that they are no longer
translated they need to be explicitly marked as unicode.
This was confirmed by discussion with dhellman. See
2014-07-23T13:48:23 in this log http://eavesdrop.openstack.org/irclogs
/%23openstack-oslo/%23openstack-oslo.2014-07-23.log
The problem was discovered when an exception was used as replacement
text in a debug log message:
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
In particular it was discovered as part of enabling lazy translation,
where the exception message is replaced with an object that does not
support str(). Note that this would also fail without lazy enabled, if
a translation for the exception message was provided that was unicode.
Example trace:
Traceback (most recent call last):
File nova/tests/virt/disk/test_api.py, line 78, in
test_can_resize_need_fs_type_specified
self.assertFalse(api.is_image_partitionless(imgfile, use_cow=True))
File nova/virt/disk/api.py, line 208, in is_image_partitionless
fs.setup()
File nova/virt/disk/vfs/localfs.py, line 80, in setup
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
File /usr/lib/python2.7/logging/__init__.py, line 1412, in debug
self.logger.debug(msg, *args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1128, in debug
self._log(DEBUG, msg, args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1258, in _log
self.handle(record)
File /usr/lib/python2.7/logging/__init__.py, line 1268, in handle
self.callHandlers(record)
File /usr/lib/python2.7/logging/__init__.py, line 1308, in callHandlers
hdlr.handle(record)
File nova/test.py, line 212, in handle
self.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 723, in format
return fmt.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 464, in format
record.message = record.getMessage()
File /usr/lib/python2.7/logging/__init__.py, line 328, in getMessage
msg = msg % self.args
File
/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo/i18n/_message.py,
line 167, in __str__
raise UnicodeError(msg)
UnicodeError: Message objects do not support str() because they may contain
non-ascii characters. Please use unicode() or translate() instead.
==
FAIL: nova.tests.virt.disk.test_api.APITestCase.test_resize2fs_e2fsck_fails
tags: worker-3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1348244
Title:
debug log messages need to be unicode
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1348244] Re: debug log messages need to be unicode
Hi Chris,
Thanks for looking at the patch. I will contact James Page to review
wait-syslog-on-startup.patch, and update the corresponding bugs that are
referenced in the changelog.
Thanks,
Liang
** Description changed:
[Impact]
* Nova services fail to start because they cannot connect to rsyslog
[Test Case]
* Set user_syslog to True in nova.conf, stop rsyslog service and
restart nova services.
[Regression Potential]
- * None
+ * The following patches from 1385295 and 1399088 that address the
+regression introduced in this bug's fix are also included.
+fix-syslog-logging.patch (LP: #1385295)
+move-syslog-instantiation.patch (LP: #1399088)
- When nova services log to syslog, they should wait for syslog to start
- prior to the nova-* services start.
+ When nova services log to syslog, they should wait for syslog to start prior
to the nova-* services start.
Debug logs should be:
LOG.debug(message) should be LOG.debug(umessage)
Before the translation of debug log messages was removed, the
translation was returning unicode. Now that they are no longer
translated they need to be explicitly marked as unicode.
This was confirmed by discussion with dhellman. See
2014-07-23T13:48:23 in this log http://eavesdrop.openstack.org/irclogs
/%23openstack-oslo/%23openstack-oslo.2014-07-23.log
The problem was discovered when an exception was used as replacement
text in a debug log message:
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
In particular it was discovered as part of enabling lazy translation,
where the exception message is replaced with an object that does not
support str(). Note that this would also fail without lazy enabled, if
a translation for the exception message was provided that was unicode.
Example trace:
Traceback (most recent call last):
File nova/tests/virt/disk/test_api.py, line 78, in
test_can_resize_need_fs_type_specified
self.assertFalse(api.is_image_partitionless(imgfile, use_cow=True))
File nova/virt/disk/api.py, line 208, in is_image_partitionless
fs.setup()
File nova/virt/disk/vfs/localfs.py, line 80, in setup
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
File /usr/lib/python2.7/logging/__init__.py, line 1412, in debug
self.logger.debug(msg, *args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1128, in debug
self._log(DEBUG, msg, args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1258, in _log
self.handle(record)
File /usr/lib/python2.7/logging/__init__.py, line 1268, in handle
self.callHandlers(record)
File /usr/lib/python2.7/logging/__init__.py, line 1308, in callHandlers
hdlr.handle(record)
File nova/test.py, line 212, in handle
self.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 723, in format
return fmt.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 464, in format
record.message = record.getMessage()
File /usr/lib/python2.7/logging/__init__.py, line 328, in getMessage
msg = msg % self.args
File
/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo/i18n/_message.py,
line 167, in __str__
raise UnicodeError(msg)
UnicodeError: Message objects do not support str() because they may contain
non-ascii characters. Please use unicode() or translate() instead.
==
FAIL: nova.tests.virt.disk.test_api.APITestCase.test_resize2fs_e2fsck_fails
tags: worker-3
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1348244
Title:
debug log messages need to be unicode
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Description changed:
+ Nova SRU:
[Impact]
* Nova services fail to start because they cannot connect to rsyslog
[Test Case]
* Set user_syslog to True in nova.conf, stop rsyslog service and
restart nova services.
[Regression Potential]
- * The following patches from 1385295 and 1399088 that address the
-regression introduced in this bug's fix are also included.
-fix-syslog-logging.patch (LP: #1385295)
-move-syslog-instantiation.patch (LP: #1399088)
+ * The following patches from 1385295 and 1399088 that address the
+ regression introduced in this bug's fix are also included.
+ fix-syslog-logging.patch (LP: #1385295)
+ move-syslog-instantiation.patch (LP: #1399088)
+ When nova services log to syslog, they should wait for syslog to start
+ prior to the nova-* services start.
- When nova services log to syslog, they should wait for syslog to start prior
to the nova-* services start.
+ Cinder SRU:
+ [Impact]
+
+ * Cinder services fail to start because they cannot connect to rsyslog
+
+ [Test Case]
+
+ * Set user_syslog to True in cinder.conf, stop rsyslog service and
+ restart cinder services.
+
+ [Regression Potential]
+
+ * The following patches from 1385295 and 1399088 that address the
+ regression introduced in this bug's fix are also included.
+ fix-syslog-logging.patch (LP: #1385295)
+ move-syslog-instantiation.patch (LP: #1399088)
+
+ When cinder services log to syslog, they should wait for syslog to start
+ prior to the cinder-* services start.
+
Debug logs should be:
LOG.debug(message) should be LOG.debug(umessage)
Before the translation of debug log messages was removed, the
translation was returning unicode. Now that they are no longer
translated they need to be explicitly marked as unicode.
This was confirmed by discussion with dhellman. See
2014-07-23T13:48:23 in this log http://eavesdrop.openstack.org/irclogs
/%23openstack-oslo/%23openstack-oslo.2014-07-23.log
The problem was discovered when an exception was used as replacement
text in a debug log message:
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
In particular it was discovered as part of enabling lazy translation,
where the exception message is replaced with an object that does not
support str(). Note that this would also fail without lazy enabled, if
a translation for the exception message was provided that was unicode.
Example trace:
Traceback (most recent call last):
File nova/tests/virt/disk/test_api.py, line 78, in
test_can_resize_need_fs_type_specified
self.assertFalse(api.is_image_partitionless(imgfile, use_cow=True))
File nova/virt/disk/api.py, line 208, in is_image_partitionless
fs.setup()
File nova/virt/disk/vfs/localfs.py, line 80, in setup
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
File /usr/lib/python2.7/logging/__init__.py, line 1412, in debug
self.logger.debug(msg, *args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1128, in debug
self._log(DEBUG, msg, args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1258, in _log
self.handle(record)
File /usr/lib/python2.7/logging/__init__.py, line 1268, in handle
self.callHandlers(record)
File /usr/lib/python2.7/logging/__init__.py, line 1308, in callHandlers
hdlr.handle(record)
File nova/test.py, line 212, in handle
self.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 723, in format
return fmt.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 464, in format
record.message = record.getMessage()
File /usr/lib/python2.7/logging/__init__.py, line 328, in getMessage
msg = msg % self.args
File
/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo/i18n/_message.py,
line 167, in __str__
raise UnicodeError(msg)
UnicodeError: Message objects do not support str() because they may contain
non-ascii characters. Please use unicode() or translate() instead.
==
FAIL: nova.tests.virt.disk.test_api.APITestCase.test_resize2fs_e2fsck_fails
tags: worker-3
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to nova in Ubuntu.
https://bugs.launchpad.net/bugs/1348244
Title:
debug log messages need to be unicode
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 1348244] Re: debug log messages need to be unicode
** Description changed:
+ Nova SRU:
[Impact]
* Nova services fail to start because they cannot connect to rsyslog
[Test Case]
* Set user_syslog to True in nova.conf, stop rsyslog service and
restart nova services.
[Regression Potential]
- * The following patches from 1385295 and 1399088 that address the
-regression introduced in this bug's fix are also included.
-fix-syslog-logging.patch (LP: #1385295)
-move-syslog-instantiation.patch (LP: #1399088)
+ * The following patches from 1385295 and 1399088 that address the
+ regression introduced in this bug's fix are also included.
+ fix-syslog-logging.patch (LP: #1385295)
+ move-syslog-instantiation.patch (LP: #1399088)
+ When nova services log to syslog, they should wait for syslog to start
+ prior to the nova-* services start.
- When nova services log to syslog, they should wait for syslog to start prior
to the nova-* services start.
+ Cinder SRU:
+ [Impact]
+
+ * Cinder services fail to start because they cannot connect to rsyslog
+
+ [Test Case]
+
+ * Set user_syslog to True in cinder.conf, stop rsyslog service and
+ restart cinder services.
+
+ [Regression Potential]
+
+ * The following patches from 1385295 and 1399088 that address the
+ regression introduced in this bug's fix are also included.
+ fix-syslog-logging.patch (LP: #1385295)
+ move-syslog-instantiation.patch (LP: #1399088)
+
+ When cinder services log to syslog, they should wait for syslog to start
+ prior to the cinder-* services start.
+
Debug logs should be:
LOG.debug(message) should be LOG.debug(umessage)
Before the translation of debug log messages was removed, the
translation was returning unicode. Now that they are no longer
translated they need to be explicitly marked as unicode.
This was confirmed by discussion with dhellman. See
2014-07-23T13:48:23 in this log http://eavesdrop.openstack.org/irclogs
/%23openstack-oslo/%23openstack-oslo.2014-07-23.log
The problem was discovered when an exception was used as replacement
text in a debug log message:
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
In particular it was discovered as part of enabling lazy translation,
where the exception message is replaced with an object that does not
support str(). Note that this would also fail without lazy enabled, if
a translation for the exception message was provided that was unicode.
Example trace:
Traceback (most recent call last):
File nova/tests/virt/disk/test_api.py, line 78, in
test_can_resize_need_fs_type_specified
self.assertFalse(api.is_image_partitionless(imgfile, use_cow=True))
File nova/virt/disk/api.py, line 208, in is_image_partitionless
fs.setup()
File nova/virt/disk/vfs/localfs.py, line 80, in setup
LOG.debug(Failed to mount image %(ex)s), {'ex': e})
File /usr/lib/python2.7/logging/__init__.py, line 1412, in debug
self.logger.debug(msg, *args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1128, in debug
self._log(DEBUG, msg, args, **kwargs)
File /usr/lib/python2.7/logging/__init__.py, line 1258, in _log
self.handle(record)
File /usr/lib/python2.7/logging/__init__.py, line 1268, in handle
self.callHandlers(record)
File /usr/lib/python2.7/logging/__init__.py, line 1308, in callHandlers
hdlr.handle(record)
File nova/test.py, line 212, in handle
self.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 723, in format
return fmt.format(record)
File /usr/lib/python2.7/logging/__init__.py, line 464, in format
record.message = record.getMessage()
File /usr/lib/python2.7/logging/__init__.py, line 328, in getMessage
msg = msg % self.args
File
/opt/stack/nova/.tox/py27/local/lib/python2.7/site-packages/oslo/i18n/_message.py,
line 167, in __str__
raise UnicodeError(msg)
UnicodeError: Message objects do not support str() because they may contain
non-ascii characters. Please use unicode() or translate() instead.
==
FAIL: nova.tests.virt.disk.test_api.APITestCase.test_resize2fs_e2fsck_fails
tags: worker-3
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1348244
Title:
debug log messages need to be unicode
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1348244/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1399088] Re: correct the position of the syslog Handler
** Also affects: nova (Ubuntu)
Importance: Undecided
Status: New
** Also affects: cinder (Ubuntu)
Importance: Undecided
Status: New
** Description changed:
[Impact]
- * syslog handler doesn't have the same settings as other handlers
+ * syslog handler doesn't have the same settings as other handlers
[Test Case]
- * Set user_syslog to True in nova.conf, restart nova services. Logs
-written to syslog doesn't have the same format as its own service
-log
-
+ * Set user_syslog to True in nova.conf, restart nova services. Logs
+ written to syslog doesn't have the same format as its own service
+ log
[Regression Potential]
- * none
-
+ * none
correct the position of the syslog Handler
syslog Handler should be in front of the line datefmt = CONF.log_date_format
Then syslog Handler can have the same settings with other handlers.
openstack/common/log.py
def _setup_logging_from_conf(project, version):
log_root = getLogger(None).logger
for handler in log_root.handlers:
log_root.removeHandler(handler)
logpath = _get_log_file_path()
if logpath:
filelog = logging.handlers.WatchedFileHandler(logpath)
log_root.addHandler(filelog)
if CONF.use_stderr:
streamlog = ColorHandler()
log_root.addHandler(streamlog)
elif not logpath:
# pass sys.stdout as a positional argument
# python2.6 calls the argument strm, in 2.7 it's stream
streamlog = logging.StreamHandler(sys.stdout)
log_root.addHandler(streamlog)
if CONF.publish_errors:
handler = importutils.import_object(
oslo.messaging.notify.log_handler.PublishErrorsHandler,
logging.ERROR)
log_root.addHandler(handler)
datefmt = CONF.log_date_format
for handler in log_root.handlers:
# NOTE(alaski): CONF.log_format overrides everything currently. This
# should be deprecated in favor of context aware formatting.
if CONF.log_format:
handler.setFormatter(logging.Formatter(fmt=CONF.log_format,
datefmt=datefmt))
log_root.info('Deprecated: log_format is now deprecated and will '
'be removed in the next release')
else:
handler.setFormatter(ContextFormatter(project=project,
version=version,
datefmt=datefmt))
if CONF.debug:
log_root.setLevel(logging.DEBUG)
elif CONF.verbose:
log_root.setLevel(logging.INFO)
else:
log_root.setLevel(logging.WARNING)
for pair in CONF.default_log_levels:
mod, _sep, level_name = pair.partition('=')
logger = logging.getLogger(mod)
# NOTE(AAzza) in python2.6 Logger.setLevel doesn't convert string name
# to integer code.
if sys.version_info (2, 7):
level = logging.getLevelName(level_name)
logger.setLevel(level)
else:
logger.setLevel(level_name)
if CONF.use_syslog:
try:
facility = _find_facility_from_conf()
# TODO(bogdando) use the format provided by RFCSysLogHandler
# after existing syslog format deprecation in J
if CONF.use_syslog_rfc_format:
syslog = RFCSysLogHandler(address='/dev/log',
facility=facility)
else:
syslog = logging.handlers.SysLogHandler(address='/dev/log',
facility=facility)
log_root.addHandler(syslog)
except socket.error:
log_root.error('Unable to add syslog handler. Verify that syslog '
'is running.')
** Description changed:
+ Nova SRU:
[Impact]
* syslog handler doesn't have the same settings as other handlers
[Test Case]
* Set user_syslog to True in nova.conf, restart nova services. Logs
written to syslog doesn't have the same format as its own service
log
[Regression Potential]
* none
+
+ Cinder SRU:
+ [Impact]
+
+ * syslog handler doesn't have the same settings as other handlers
+
+ [Test Case]
+
+ * Set user_syslog to True in cinder.conf, restart cinder services. Logs
+ written to syslog doesn't have the same format as its own service
+ log
+
+ [Regression Potential]
+
+ * none
+
correct the position of the syslog Handler
syslog Handler should be in front of the line datefmt = CONF.log_date_format
Then syslog Handler can have the same settings with other handlers.
openstack/common/log.py
def _setup_logging_from_conf(project, version):
log_root = getLogger(None).logger
