[Yahoo-eng-team] [Bug 1468990] [NEW] ml2: exceptions in extension driver will be interceptered by extenstion manager
Public bug reported: Not sure if we make it intentionally, but exceptions in extension driver is interceptered by extenstion manager. https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L351 for examples, when a port creating, if one of the ext drivers emit a exception, the extension process could continue for the left ext drivers. But it may cover some error in that problem driver. Maybe that driver emit the exception passively(because of error in code) or intentionally(some kind of verification in ext driver itself). maybe I understand it wrong. ** Affects: neutron Importance: Undecided Assignee: yalei wang (yalei-wang) Status: New ** Description changed: Not sure if we make it intentionally, but exceptions in extension driver - will be interceptered by extenstion manager. + is interceptered by extenstion manager. https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L351 for examples, when a port creating, if one of the ext drivers emit a exception, the extension process could continue for the left ext drivers. But it may cover some error in that problem driver. Maybe that driver emit the exception passively(because of error in code) or intentionally(some kind of verification). ** Description changed: Not sure if we make it intentionally, but exceptions in extension driver is interceptered by extenstion manager. https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L351 for examples, when a port creating, if one of the ext drivers emit a exception, the extension process could continue for the left ext drivers. But it may cover some error in that problem driver. Maybe that driver emit the exception passively(because of error in code) or - intentionally(some kind of verification). + intentionally(some kind of verification in ext driver itself). + + maybe I understand it wrong. ** Changed in: neutron Assignee: (unassigned) = yalei wang (yalei-wang) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468990 Title: ml2: exceptions in extension driver will be interceptered by extenstion manager Status in OpenStack Neutron (virtual network service): New Bug description: Not sure if we make it intentionally, but exceptions in extension driver is interceptered by extenstion manager. https://github.com/openstack/neutron/blob/master/neutron/plugins/ml2/managers.py#L351 for examples, when a port creating, if one of the ext drivers emit a exception, the extension process could continue for the left ext drivers. But it may cover some error in that problem driver. Maybe that driver emit the exception passively(because of error in code) or intentionally(some kind of verification in ext driver itself). maybe I understand it wrong. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468990/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468992] [NEW] nova list's --tenant filter does not return expected servers
Public bug reported: This bug is opened as fix released for https://bugs.launchpad.net/nova/+bug/1185290 is reverted back in v2.1. Fix proposed in v3 was reverted/commented out in v2.1 to make v2.1 fully compatible and identical with v2. - https://review.openstack.org/#/c/145687/ We need to fix this for both v2 and v2.1 APIs. ** Affects: nova Importance: Undecided Assignee: Ghanshyam Mann (ghanshyammann) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Ghanshyam Mann (ghanshyammann) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1468992 Title: nova list's --tenant filter does not return expected servers Status in OpenStack Compute (Nova): In Progress Bug description: This bug is opened as fix released for https://bugs.launchpad.net/nova/+bug/1185290 is reverted back in v2.1. Fix proposed in v3 was reverted/commented out in v2.1 to make v2.1 fully compatible and identical with v2. - https://review.openstack.org/#/c/145687/ We need to fix this for both v2 and v2.1 APIs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1468992/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468998] [NEW] double-mocks cause non-deterministic failures
Public bug reported: calling mock.patch multiple times on the same target can result in leaked mocks. This is fixed in py34+ but affects our py27 tests. http://bugs.python.org/issue21239 ** Affects: neutron Importance: Undecided Assignee: Kevin Benton (kevinbenton) Status: New ** Changed in: neutron Assignee: (unassigned) = Kevin Benton (kevinbenton) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468998 Title: double-mocks cause non-deterministic failures Status in OpenStack Neutron (virtual network service): New Bug description: calling mock.patch multiple times on the same target can result in leaked mocks. This is fixed in py34+ but affects our py27 tests. http://bugs.python.org/issue21239 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468998/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468992] Re: nova list's --tenant filter does not return expected servers
Tempest tests needs to be modified. ** Also affects: tempest Importance: Undecided Status: New ** Changed in: tempest Status: New = Triaged ** Changed in: tempest Assignee: (unassigned) = Ghanshyam Mann (ghanshyammann) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1468992 Title: nova list's --tenant filter does not return expected servers Status in OpenStack Compute (Nova): In Progress Status in Tempest: Triaged Bug description: This bug is opened as fix released for https://bugs.launchpad.net/nova/+bug/1185290 is reverted back in v2.1. Fix proposed in v3 was reverted/commented out in v2.1 to make v2.1 fully compatible and identical with v2. - https://review.openstack.org/#/c/145687/ We need to fix this for both v2 and v2.1 APIs. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1468992/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468762] [NEW] lxc hypervisor does not support PCI devices
Public bug reported: OS: Ubuntu 14.04.02 OpenStack Kilo Hypervisor: LXC Nova: 1:2015.1.0-0ubuntu1~cloud0 libvirt-bin: Installed: 1.2.12-0ubuntu13~cloud0 I have lxc powered compute node with TeslaK40 card that I want to passthrough to VM. Tutorials that I used are: https://wiki.openstack.org/wiki/Pci_passthrough http://docs.openstack.org/kilo/config-reference/content/lxc.html I can run simple VMs, however when I try to create VM with PCI then it fails. Compute Node log: 2015-06-25 00:19:18.729 6509 ERROR nova.compute.manager [req-add1f483-f402-47dc-8701-574b8558d3d2 - - - - -] [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] Instance failed to spawn 2015-06-25 00:19:18.729 6509 TRACE nova.compute.manager [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] Traceback (most recent call last): //SPAWNING LOGS 2015-06-25 00:19:18.729 6509 TRACE nova.compute.manager [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] type=virt_type) 2015-06-25 00:19:18.729 6509 TRACE nova.compute.manager [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] PciDeviceUnsupportedHypervisor: lxc hypervisor does not support PCI devices I looked into /usr/lib/python2.7/dist- packages/nova/virt/libvirt/driver.py and found out that libvirt does not support pci passthrough for other hypervisors except (Xen,KVM,QEMU). Is it bug? This node originally used KVM, however I could not passthrough PCI successully there, If anybody wants to look into (It would be huge help): https://ask.openstack.org/en/question/68667/kvm-pci-passthrough-nvidia-tesla-k40/ If any data is reqired I will provide it ** Affects: nova Importance: Undecided Status: New ** Tags: libvirt lxc pci-passthrough -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1468762 Title: lxc hypervisor does not support PCI devices Status in OpenStack Compute (Nova): New Bug description: OS: Ubuntu 14.04.02 OpenStack Kilo Hypervisor: LXC Nova: 1:2015.1.0-0ubuntu1~cloud0 libvirt-bin: Installed: 1.2.12-0ubuntu13~cloud0 I have lxc powered compute node with TeslaK40 card that I want to passthrough to VM. Tutorials that I used are: https://wiki.openstack.org/wiki/Pci_passthrough http://docs.openstack.org/kilo/config-reference/content/lxc.html I can run simple VMs, however when I try to create VM with PCI then it fails. Compute Node log: 2015-06-25 00:19:18.729 6509 ERROR nova.compute.manager [req-add1f483-f402-47dc-8701-574b8558d3d2 - - - - -] [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] Instance failed to spawn 2015-06-25 00:19:18.729 6509 TRACE nova.compute.manager [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] Traceback (most recent call last): //SPAWNING LOGS 2015-06-25 00:19:18.729 6509 TRACE nova.compute.manager [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] type=virt_type) 2015-06-25 00:19:18.729 6509 TRACE nova.compute.manager [instance: 5be8bf76-0f8f-4641-8fa8-5ba42ae19388] PciDeviceUnsupportedHypervisor: lxc hypervisor does not support PCI devices I looked into /usr/lib/python2.7/dist- packages/nova/virt/libvirt/driver.py and found out that libvirt does not support pci passthrough for other hypervisors except (Xen,KVM,QEMU). Is it bug? This node originally used KVM, however I could not passthrough PCI successully there, If anybody wants to look into (It would be huge help): https://ask.openstack.org/en/question/68667/kvm-pci-passthrough-nvidia-tesla-k40/ If any data is reqired I will provide it To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1468762/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468723] [NEW] Resource uuid is not logged when a resource is created
Public bug reported:
In the case of Nova, instance uuid is output to log when new instance is
created.
The following logs are part of nova boot result.
2015-06-25 11:15:16.637 DEBUG nova.compute.api
[req-5f2782c8-1bb7-4735-a714-e720833f4a6d admin admin] Going to run 1
instances... from (pid=3336) _provision_instances
/opt/stack/nova/nova/compute/api.py:929
2015-06-25 11:15:16.756 DEBUG nova.compute.api
[req-5f2782c8-1bb7-4735-a714-e720833f4a6d admin admin] [instance:
e7dd5627-0b72-48e9-bcc1-0e49f267dcec] block_device_mapping
BlockDeviceMappingList(objects=[BlockDeviceMapping(UNKNOWN)]) from (pid=3336)
_create_block_device_mapping /opt/stack/nova/nova/compute/api.py:1200
But, in the case of Neutron or other component, uuid is not output to log when
new resource is created.
If error occurs in that resource, user cannot determine about followings.
*When the resource is created?
*Who the resources created?
That is not useful in all project and inconsistent between projects.
By adding resource argument to logging, new resource uuid is output to
log.
Because the log output mechanism has been already implemented in oslo.log[1],
this patch just adds resource information to log.
In addition, existing processing is not affected unless resource is specified
in logging_context_format_string.
Followings are sample executed neutron net-create.
*configure file
logging_context_format_string = %(asctime)s.%(msecs)03d
%(color)s%(levelname)s %(name)s [%(request_id)s %(user_name)s
%(project_id)s%(color)s] %(resource)s%(color)s%(message)s
*souruce file
rscdict = {'type': 'network', 'id': '8e6a748c-aa8a-440b-904a-a6e2f6dc00eb'}
LOG.info(network create success, resource=rscdict)
*log file
INFO neutron.db.db_base_plugin_v2 [req-1667753a-e5f5-4417-bd8d-16f12bcc2e34
admin 0862ba8c3497455a8fdf40c49f0f2644]
[network-8e6a748c-aa8a-440b-904a-a6e2f6dc00eb] network create success
[1]
https://review.openstack.org/#/c/144813/
** Affects: neutron
Importance: Undecided
Assignee: Daisuke Fujita (fuzita-daisuke)
Status: New
** Changed in: neutron
Assignee: (unassigned) = Daisuke Fujita (fuzita-daisuke)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1468723
Title:
Resource uuid is not logged when a resource is created
Status in OpenStack Neutron (virtual network service):
New
Bug description:
In the case of Nova, instance uuid is output to log when new instance is
created.
The following logs are part of nova boot result.
2015-06-25 11:15:16.637 DEBUG nova.compute.api
[req-5f2782c8-1bb7-4735-a714-e720833f4a6d admin admin] Going to run 1
instances... from (pid=3336) _provision_instances
/opt/stack/nova/nova/compute/api.py:929
2015-06-25 11:15:16.756 DEBUG nova.compute.api
[req-5f2782c8-1bb7-4735-a714-e720833f4a6d admin admin] [instance:
e7dd5627-0b72-48e9-bcc1-0e49f267dcec] block_device_mapping
BlockDeviceMappingList(objects=[BlockDeviceMapping(UNKNOWN)]) from (pid=3336)
_create_block_device_mapping /opt/stack/nova/nova/compute/api.py:1200
But, in the case of Neutron or other component, uuid is not output to log
when new resource is created.
If error occurs in that resource, user cannot determine about followings.
*When the resource is created?
*Who the resources created?
That is not useful in all project and inconsistent between projects.
By adding resource argument to logging, new resource uuid is output
to log.
Because the log output mechanism has been already implemented in oslo.log[1],
this patch just adds resource information to log.
In addition, existing processing is not affected unless resource is
specified in logging_context_format_string.
Followings are sample executed neutron net-create.
*configure file
logging_context_format_string = %(asctime)s.%(msecs)03d
%(color)s%(levelname)s %(name)s [%(request_id)s %(user_name)s
%(project_id)s%(color)s] %(resource)s%(color)s%(message)s
*souruce file
rscdict = {'type': 'network', 'id':
'8e6a748c-aa8a-440b-904a-a6e2f6dc00eb'}
LOG.info(network create success, resource=rscdict)
*log file
INFO neutron.db.db_base_plugin_v2
[req-1667753a-e5f5-4417-bd8d-16f12bcc2e34 admin
0862ba8c3497455a8fdf40c49f0f2644]
[network-8e6a748c-aa8a-440b-904a-a6e2f6dc00eb] network create success
[1]
https://review.openstack.org/#/c/144813/
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1468723/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468706] [NEW] Loading block wouldn't disappear after using compound key to click link
Public bug reported: When user want to using compound key to open link in new tab such as open instances page in new tab. He will hold control key and click link by left button of mouse. Then the page will be opened in new tab. But original page will occur loading block. And it will never disappear. This situation will happened either using middle button of mouse to click link or hold some other compound key (such as esc key or shift key) and click link. And not all of link will occur this bugs. It was exist at those links which are located at left navigation block. When user click link, maybe UI will assume browser to send request and receive the response. But browser will not send any request in this page. Therefore the loading block will stay there forever. This bug was exist in Chrome, Safari and Firefox. ** Affects: horizon Importance: Undecided Assignee: inwinSTACK inc. (inwinstack) Status: New ** Changed in: horizon Assignee: (unassigned) = inwinSTACK inc. (inwinstack) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1468706 Title: Loading block wouldn't disappear after using compound key to click link Status in OpenStack Dashboard (Horizon): New Bug description: When user want to using compound key to open link in new tab such as open instances page in new tab. He will hold control key and click link by left button of mouse. Then the page will be opened in new tab. But original page will occur loading block. And it will never disappear. This situation will happened either using middle button of mouse to click link or hold some other compound key (such as esc key or shift key) and click link. And not all of link will occur this bugs. It was exist at those links which are located at left navigation block. When user click link, maybe UI will assume browser to send request and receive the response. But browser will not send any request in this page. Therefore the loading block will stay there forever. This bug was exist in Chrome, Safari and Firefox. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1468706/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1443898] Re: TestVolumeBootPattern.test_volume_boot_pattern fail with libvirt-xen
Changing it to nova as it is going to be fixed there first. if So then we can open it for Tempest and fix it by making it config option etc. -https://review.openstack.org/180161/ ** Also affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1443898 Title: TestVolumeBootPattern.test_volume_boot_pattern fail with libvirt-xen Status in OpenStack Compute (Nova): New Status in Tempest: New Bug description: The following test is failling when runned with libvirt-xen nova compute node. tempest.scenario.test_volume_boot_pattern.TestVolumeBootPattern.test_volume_boot_pattern This is due to the function _boot_instance_from_volume which create a volume with the device name vda, but this is not supported by Xen. Also Nova itself does not reject the device name. This is with devstack master. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1443898/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468783] [NEW] File not Found error in check-neutron-lbaasv1-dsvm-api
Public bug reported: In https://review.openstack.org/#/c/195223/ (a backport to stable/juno) the jenkins check job failed at the check-neutron-lbaasv1-dsvm-api. Looking at the console.html log, the failure occurred during the test setup phase. The console.log is: http://logs.openstack.org/23/195223/1/check/check-neutron-lbaasv1-dsvm- api/3394a7e/console.html The failure is: ... 2015-06-25 02:22:54.814 | Running gate_hook 2015-06-25 02:22:54.814 | + gate_hook 2015-06-25 02:22:54.814 | + /opt/stack/new/neutron-lbaas/neutron_lbaas/tests/contrib/gate_hook.sh lbaasv1 2015-06-25 02:22:54.815 | ./safe-devstack-vm-gate-wrap.sh: /opt/stack/new/neutron-lbaas/neutron_lbaas/tests/contrib/gate_hook.sh: No such file or directory 2015-06-25 02:22:54.815 | + GATE_RETVAL=127 2015-06-25 02:22:54.815 | + RETVAL=127 2015-06-25 02:22:54.815 | + '[' 127 -ne 0 ']' 2015-06-25 02:22:54.815 | + echo 'ERROR: the main setup script run by this job failed - exit code: 127' 2015-06-25 02:22:54.815 | ERROR: the main setup script run by this job failed - exit code: 127 2015-06-25 02:22:54.816 | + echo 'please look at the relevant log files to determine the root cause' 2015-06-25 02:22:54.816 | please look at the relevant log files to determine the root cause 2015-06-25 02:22:54.816 | + echo 'Running devstack worlddump.py' 2015-06-25 02:22:54.816 | Running devstack worlddump.py ... Looking at the neutron-lbaas in the stable/juno branch, there is no contrib directory, hence the No such file or directory error. ** Affects: neutron Importance: Undecided Status: New ** Summary changed: - check-neutron-lbaasv1-dsvm-api failing due to file not found + File not Found error in check-neutron-lbaasv1-dsvm-api -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468783 Title: File not Found error in check-neutron-lbaasv1-dsvm-api Status in OpenStack Neutron (virtual network service): New Bug description: In https://review.openstack.org/#/c/195223/ (a backport to stable/juno) the jenkins check job failed at the check-neutron- lbaasv1-dsvm-api. Looking at the console.html log, the failure occurred during the test setup phase. The console.log is: http://logs.openstack.org/23/195223/1/check/check-neutron-lbaasv1 -dsvm-api/3394a7e/console.html The failure is: ... 2015-06-25 02:22:54.814 | Running gate_hook 2015-06-25 02:22:54.814 | + gate_hook 2015-06-25 02:22:54.814 | + /opt/stack/new/neutron-lbaas/neutron_lbaas/tests/contrib/gate_hook.sh lbaasv1 2015-06-25 02:22:54.815 | ./safe-devstack-vm-gate-wrap.sh: /opt/stack/new/neutron-lbaas/neutron_lbaas/tests/contrib/gate_hook.sh: No such file or directory 2015-06-25 02:22:54.815 | + GATE_RETVAL=127 2015-06-25 02:22:54.815 | + RETVAL=127 2015-06-25 02:22:54.815 | + '[' 127 -ne 0 ']' 2015-06-25 02:22:54.815 | + echo 'ERROR: the main setup script run by this job failed - exit code: 127' 2015-06-25 02:22:54.815 | ERROR: the main setup script run by this job failed - exit code: 127 2015-06-25 02:22:54.816 | + echo 'please look at the relevant log files to determine the root cause' 2015-06-25 02:22:54.816 | please look at the relevant log files to determine the root cause 2015-06-25 02:22:54.816 | + echo 'Running devstack worlddump.py' 2015-06-25 02:22:54.816 | Running devstack worlddump.py ... Looking at the neutron-lbaas in the stable/juno branch, there is no contrib directory, hence the No such file or directory error. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468783/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468765] [NEW] Multiple errors in thirdparty-ci.rst
Public bug reported: Building docs results in multiple errors from thirdparty-ci.rst, including: WARNING: Inline emphasis start-string without end-string. ERROR: Unexpected indentation. WARNING: document isn't included in any toctree ** Affects: neutron Importance: Undecided Assignee: John Davidge (john-davidge) Status: New ** Changed in: neutron Assignee: (unassigned) = John Davidge (john-davidge) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468765 Title: Multiple errors in thirdparty-ci.rst Status in OpenStack Neutron (virtual network service): New Bug description: Building docs results in multiple errors from thirdparty-ci.rst, including: WARNING: Inline emphasis start-string without end-string. ERROR: Unexpected indentation. WARNING: document isn't included in any toctree To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468765/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468803] [NEW] Modular L2 Agent
Public bug reported: Currently, both the Open vSwitch and Linux Bridge mechanism drivers for the ML2 plugin have their own agents. This means that when improvements are made to one agent implementation, they have to be ported over to the other agent to gain the improvement. This has already happened, with patches like https://review.openstack.org/#/c/138512/ . Much of the functionality that both the OVS and Linux Bridge agents provide is common enough that much of the code could be shared. Discussion on the mailing list. http://lists.openstack.org/pipermail/openstack-dev/2015-June/067605.html ** Affects: neutron Importance: Undecided Status: New ** Tags: linuxbridge ovs rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468803 Title: Modular L2 Agent Status in OpenStack Neutron (virtual network service): New Bug description: Currently, both the Open vSwitch and Linux Bridge mechanism drivers for the ML2 plugin have their own agents. This means that when improvements are made to one agent implementation, they have to be ported over to the other agent to gain the improvement. This has already happened, with patches like https://review.openstack.org/#/c/138512/ . Much of the functionality that both the OVS and Linux Bridge agents provide is common enough that much of the code could be shared. Discussion on the mailing list. http://lists.openstack.org/pipermail/openstack- dev/2015-June/067605.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468803/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468828] [NEW] HA router-create breaks ML2 Drivers
Public bug reported: When an admin creates HA router (neutron router-create --ha ), the HA framework invokes network_create() and sets tenant-id to null (empty). network_create() api expects tenant-id to be set, hence, ML2 driver rejects/fails the network_create() request, which in turn fails the router-create request. This will impact all ML2 drivers. ** Affects: neutron Importance: Undecided Status: New ** Tags: l3-ha ml2 ** Tags added: l3-ha ml2 ** Summary changed: - HA router create breaks ML2 Drivers + HA router-create breaks ML2 Drivers -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1468828 Title: HA router-create breaks ML2 Drivers Status in OpenStack Neutron (virtual network service): New Bug description: When an admin creates HA router (neutron router-create --ha ), the HA framework invokes network_create() and sets tenant-id to null (empty). network_create() api expects tenant-id to be set, hence, ML2 driver rejects/fails the network_create() request, which in turn fails the router-create request. This will impact all ML2 drivers. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1468828/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468806] [NEW] attempt to communicate with non-existent properties
Public bug reported:
Steps to reproduce:
1. Create new artifact.
POST /v3/artifacts/myartifact/v2.0/drafts HTTP/1.1
Host: 172.18.78.38:9393
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101
Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Length: 85
{description: This is a sample plugin, name: New Artifact,
version: 1 }
2. Trying to update non-existent property via PATCH method.
PATCH /v3/artifacts/myartifact/v2.0/a8c9c8c0-d357-4025-aaa1-5b51f54e74f5
HTTP/1.1
Host: 172.18.78.38:9393
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101
Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 99
[{op: remove, path: /something-non-existent-property/and-another-
one, value: anydata}]
Actual result:
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Content-Length: 0
Date: Thu, 25 Jun 2015 15:32:30 GMT
Connection: close
** Affects: glance
Importance: Undecided
Status: New
** Tags: artifacts
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1468806
Title:
attempt to communicate with non-existent properties
Status in OpenStack Image Registry and Delivery Service (Glance):
New
Bug description:
Steps to reproduce:
1. Create new artifact.
POST /v3/artifacts/myartifact/v2.0/drafts HTTP/1.1
Host: 172.18.78.38:9393
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101
Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Length: 85
{description: This is a sample plugin, name: New Artifact,
version: 1 }
2. Trying to update non-existent property via PATCH method.
PATCH /v3/artifacts/myartifact/v2.0/a8c9c8c0-d357-4025-aaa1-5b51f54e74f5
HTTP/1.1
Host: 172.18.78.38:9393
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101
Firefox/38.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 99
[{op: remove, path: /something-non-existent-property/and-
another-one, value: anydata}]
Actual result:
HTTP/1.1 500 Internal Server Error
Content-Type: text/plain
Content-Length: 0
Date: Thu, 25 Jun 2015 15:32:30 GMT
Connection: close
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1468806/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468946] [NEW] glance metadef tables need unique constraints
Public bug reported: Sometime during Kilo, the unique constraints on metadef_namespaces (namespace) metadef_objects(namespace_id, name) metadef_properties(namespace_id, name) metadef_tags(namespace_id, name) metadef_resource_types(name) were removed. I believe this was done erroneously to make the migrate_repo/versions/scripts match the db/sqlalchemy/models_metadef.py definitions. Unfortunately, the schema scripts were correct with the unique constraints and what should have changed was the models_metadef.py. This bug, puts one more migrate script in place which will rename any duplicate records it finds to make them unique and then re-establishes the unique constraints. It also, fixes models_metadef.py and adds in tests to create duplicates which should result in an HTTPConflict. ** Affects: glance Importance: Undecided Assignee: Wayne (wayne-okuma) Status: New ** Tags: metadef ** Changed in: glance Assignee: (unassigned) = Wayne (wayne-okuma) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1468946 Title: glance metadef tables need unique constraints Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Sometime during Kilo, the unique constraints on metadef_namespaces (namespace) metadef_objects(namespace_id, name) metadef_properties(namespace_id, name) metadef_tags(namespace_id, name) metadef_resource_types(name) were removed. I believe this was done erroneously to make the migrate_repo/versions/scripts match the db/sqlalchemy/models_metadef.py definitions. Unfortunately, the schema scripts were correct with the unique constraints and what should have changed was the models_metadef.py. This bug, puts one more migrate script in place which will rename any duplicate records it finds to make them unique and then re-establishes the unique constraints. It also, fixes models_metadef.py and adds in tests to create duplicates which should result in an HTTPConflict. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1468946/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468973] [NEW] Glance schema-image.json contains wrong URLs
Public bug reported: Two property descriptions in schema-image.json contain the wrong URL http://docs.openstack.org/trunk/openstack-compute/admin/content/adding- images.html. These URLs are exposed to users when they run e.g. glance help image-create using API v2. A better URL might be http://docs.openstack.org/cli-reference/content /chapter_cli-glance-property.html. I can see this in stable/Icehouse, stable/Juno, stable/Kilo and master. Glance client reports version 0.19.0. ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1468973 Title: Glance schema-image.json contains wrong URLs Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: Two property descriptions in schema-image.json contain the wrong URL http://docs.openstack.org/trunk/openstack-compute/admin/content /adding-images.html. These URLs are exposed to users when they run e.g. glance help image-create using API v2. A better URL might be http://docs.openstack.org/cli-reference/content /chapter_cli-glance-property.html. I can see this in stable/Icehouse, stable/Juno, stable/Kilo and master. Glance client reports version 0.19.0. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1468973/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1447004] Re: LBaaS- Unclear error message when edit Healthmonitor delay value to be smaller than Timeout
[Expired for neutron because there has been no activity for 60 days.]
** Changed in: neutron
Status: Incomplete = Expired
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1447004
Title:
LBaaS- Unclear error message when edit Healthmonitor delay value to
be smaller than Timeout
Status in OpenStack Neutron (virtual network service):
Expired
Bug description:
When I trying to edit an exist Healthmonitor with Delay value to
be smailler than timeout value I get unclear error message .
reproduce :
1.neutron lb-healthmonitor-create --delay 3 --type HTTP --max-retries 3
--timeout 3
2. try to edit it with delay value lower than timeout value
# neutron lb-healthmonitor-list
+--+--++
| id | type | admin_state_up |
+--+--++
| 6b52d5f0-a1a2-4a37-a3dd-df740277f3a2 | HTTP | True |
+--+--++
# neutron lb-healthmonitor-show 6b52d5f0-a1a2-4a37-a3dd-df740277f3a2
++-+
| Field | Value
|
++-+
| admin_state_up | True
|
| delay | 3
|
| expected_codes | 200
|
| http_method| GET
|
| id | 6b52d5f0-a1a2-4a37-a3dd-df740277f3a2
|
| max_retries| 3
|
| pools | {status: ACTIVE, status_description: null,
pool_id: 8c576c3a-75a0-4579-b908-7060df1ee01c} |
| tenant_id | 597cc04c77ee44eeb7b878f63a24eac9
|
| timeout| 3
|
| type | HTTP
|
| url_path | /
|
++-+
# neutron lb-healthmonitor-update 6b52d5f0-a1a2-4a37-a3dd-df740277f3a2
--delay 1
Bad Request (HTTP 400) (Request-ID: req-34ddb573-b0ef-43de-ba92-dc446f612add)
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1447004/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468973] Re: Glance schema-image.json contains wrong URLs
Well, when accessing http://docs.openstack.org/trunk/openstack- compute/admin/content/adding-images.html, one is usually redirected to the correct page. It seems to me, though, that this redirect doesn't always work. ** Changed in: glance Status: New = Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1468973 Title: Glance schema-image.json contains wrong URLs Status in OpenStack Image Registry and Delivery Service (Glance): Invalid Bug description: Two property descriptions in schema-image.json contain the wrong URL http://docs.openstack.org/trunk/openstack-compute/admin/content /adding-images.html. These URLs are exposed to users when they run e.g. glance help image-create using API v2. A better URL might be http://docs.openstack.org/cli-reference/content /chapter_cli-glance-property.html. I can see this in stable/Icehouse, stable/Juno, stable/Kilo and master. Glance client reports version 0.19.0. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1468973/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468976] [NEW] requirements file require higher pbr version
Public bug reported: currently requirements.txt have lines pbr2.0,=0.11 keystonemiddleware=1.5.0 while if you are using keystonemiddleware-1.6.1, which requires pbr1.0, =0.6, so only pbr-0.11.0 can be installed. But pbr-0.11.0 is NOT compatible with test-requirements.txt line: python-ldap=2.4;python_version=='2.7' It is the reason of bug https://bugs.launchpad.net/devstack/+bug/1468339 ** Affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1468976 Title: requirements file require higher pbr version Status in OpenStack Identity (Keystone): New Bug description: currently requirements.txt have lines pbr2.0,=0.11 keystonemiddleware=1.5.0 while if you are using keystonemiddleware-1.6.1, which requires pbr1.0, =0.6, so only pbr-0.11.0 can be installed. But pbr-0.11.0 is NOT compatible with test-requirements.txt line: python-ldap=2.4;python_version=='2.7' It is the reason of bug https://bugs.launchpad.net/devstack/+bug/1468339 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1468976/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1462154] Re: With DVR Pings to floating IPs replied with fixed-ips
** Changed in: neutron Status: Opinion = New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1462154 Title: With DVR Pings to floating IPs replied with fixed-ips Status in OpenStack Neutron (virtual network service): New Bug description: On my single node devstack setup, there are 2 VMs hosted. VM1 has no floating IP assigned. VM2 has a floating IP assigned. From VM1, ping to VM2 using the floating IP. Ping output reports the replies comes from VM2's fixed ip address. The reply should be from VM2's floating ip address. This is a DVR problem as it doesn't happen when the L3 agent's mode is 'legacy'. This may be a problem with the NAT rules defined by the DVR L3-agent. I used the latest neutron code on the master branch to reproduce, The agent_mode is set to 'dvr_snat'. Here is how the problem is reproduced: VM1 and VM2 runs on the same host. VM1 has fixed IP of 10.11.12.4, no floating-ip associated. VM2 has fixed IP of 10.11.12.5 floating-ip=10.127.10.226 Logged into VM1 from the qrouter namespace. From VM1, ping to 10.127.10.226, ping output at VM1 reports ping replies are from the VM2's fixed IP address # ssh cirros@10.11.12.4 cirros@10.11.12.4's password: $ ping 10.127.10.226 PING 10.127.10.226 (10.127.10.226): 56 data bytes 64 bytes from 10.11.12.5: seq=0 ttl=64 time=4.189 ms 64 bytes from 10.11.12.5: seq=1 ttl=64 time=1.254 ms 64 bytes from 10.11.12.5: seq=2 ttl=64 time=2.386 ms 64 bytes from 10.11.12.5: seq=3 ttl=64 time=2.064 ms ^C --- 10.127.10.226 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 1.254/2.473/4.189 ms $ If I associate a floating IP on VM1 then repeat the same test, ping reports the replies comes from VM2's floating IP: # ssh cirros@10.11.12.4 cirros@10.11.12.4's password: $ ping 10.127.10.226 PING 10.127.10.226 (10.127.10.226): 56 data bytes 64 bytes from 10.127.10.226: seq=0 ttl=63 time=16.750 ms 64 bytes from 10.127.10.226: seq=1 ttl=63 time=2.417 ms 64 bytes from 10.127.10.226: seq=2 ttl=63 time=1.558 ms 64 bytes from 10.127.10.226: seq=3 ttl=63 time=1.042 ms 64 bytes from 10.127.10.226: seq=4 ttl=63 time=2.770 ms ^C --- 10.127.10.226 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 1.042/4.907/16.750 ms $ To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1462154/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466444] Re: multipath device action incorrectly being parsed as the device name
@apahim we are actually trying to traverse the other way, starting with a single path device and working out the virtual mpath dm device details. We could actually use a glob to do this instead of `multipath -l /dev/path` : ~~~ # ll /sys/devices/virtual/block/*/slaves/sdk lrwxrwxrwx. 1 root root 0 Jun 3 03:56 /sys/devices/virtual/block/dm-2/slaves/sdk - ../../../../pci:00/:00:07.0/:1a:00.0/host0/rport-0:0-8/target0:0:3/0:0:3:3/block/sdk ~~~ IMHO moving to this method is out of scope for this bug but I will try to write up a spec detailing how we could use this method in os-brick. ** No longer affects: cinder ** Description changed: multipath device action incorrectly being parsed as the device name. The first word on the first line of `multipath -l $path` is currently being used as the name of a given multipath device. https://github.com/openstack/nova/blob/master/nova/storage/linuxscsi.py#L118 + https://github.com/openstack/os-brick/blob/master/os_brick/initiator/linuxscsi.py#L145 This however can be an `action:` string when the device is being created, reloaded, resized etc. [1][2][3] [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/DM_Multipath/MPIO_output.html [2] http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=libmultipath/print.c;h=5d63ed34d2a8816a5e287bdeb1bd90cdb026bb9e;hb=HEAD#l929 [3] http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=libmultipath/configure.h;h=c014b5533226d9a56571f87b9123de91c5ff1d2f;hb=HEAD -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1466444 Title: multipath device action incorrectly being parsed as the device name Status in OpenStack Compute (Nova): In Progress Status in Volume discovery and local storage management lib: New Bug description: multipath device action incorrectly being parsed as the device name. The first word on the first line of `multipath -l $path` is currently being used as the name of a given multipath device. https://github.com/openstack/nova/blob/master/nova/storage/linuxscsi.py#L118 https://github.com/openstack/os-brick/blob/master/os_brick/initiator/linuxscsi.py#L145 This however can be an `action:` string when the device is being created, reloaded, resized etc. [1][2][3] [1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/DM_Multipath/MPIO_output.html [2] http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=libmultipath/print.c;h=5d63ed34d2a8816a5e287bdeb1bd90cdb026bb9e;hb=HEAD#l929 [3] http://git.opensvc.com/gitweb.cgi?p=multipath-tools/.git;a=blob;f=libmultipath/configure.h;h=c014b5533226d9a56571f87b9123de91c5ff1d2f;hb=HEAD To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1466444/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468678] [NEW] instance action list to have reset state
Public bug reported: We have option in nova, where we can set the state of the instance to error or active. i.e === nova reset-state ( Reset the state of a server. ) usage: nova reset-state [--active] server [server ...] This functionality is missing from the action list. This is a wishlist bug, to have this. ** Affects: horizon Importance: Undecided Assignee: Ritesh (rsritesh) Status: New ** Changed in: horizon Assignee: (unassigned) = Ritesh (rsritesh) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1468678 Title: instance action list to have reset state Status in OpenStack Dashboard (Horizon): New Bug description: We have option in nova, where we can set the state of the instance to error or active. i.e === nova reset-state ( Reset the state of a server. ) usage: nova reset-state [--active] server [server ...] This functionality is missing from the action list. This is a wishlist bug, to have this. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1468678/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466851] Re: Move to graduated oslo.service
os-brick review: https://review.openstack.org/#/c/195469/ ** Also affects: os-brick Importance: Undecided Status: New ** Changed in: os-brick Status: New = In Progress ** Changed in: os-brick Assignee: (unassigned) = Sergey Vilgelm (sergey.vilgelm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1466851 Title: Move to graduated oslo.service Status in OpenStack Telemetry (Ceilometer): Fix Committed Status in Cinder: Fix Committed Status in Designate: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Magnum: In Progress Status in Manila: In Progress Status in Murano: In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): In Progress Status in Volume discovery and local storage management lib: In Progress Status in python-muranoclient: In Progress Status in OpenStack Data Processing (Sahara): Fix Committed Status in OpenStack Search (Searchlight): In Progress Status in Openstack Database (Trove): In Progress Bug description: oslo.service library has graduated so all OpenStack projects should port to it instead of using oslo-incubator code. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1466851/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468696] [NEW] Move cold migration from conductor's manager to separate task
Public bug reported: To increase cold-migration/resize process manageability and make code clearer new task similar to live-migration should be created in conductor. While moving logic, class hierarchy for tasks should be created it allows to use similar interface for all new task classes in future. ** Affects: nova Importance: Undecided Assignee: Timofey Durakov (tdurakov) Status: In Progress ** Changed in: nova Assignee: (unassigned) = Timofey Durakov (tdurakov) ** Changed in: nova Status: New = In Progress ** Summary changed: - move cold migration from conductor's manager to separate task + Move cold migration from conductor's manager to separate task -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1468696 Title: Move cold migration from conductor's manager to separate task Status in OpenStack Compute (Nova): In Progress Bug description: To increase cold-migration/resize process manageability and make code clearer new task similar to live-migration should be created in conductor. While moving logic, class hierarchy for tasks should be created it allows to use similar interface for all new task classes in future. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1468696/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468667] [NEW] console option from heat resource list
Public bug reported: In orchestration panel , we you check for stack details, you have following tabs : Topology Overview Resources Events Template In resources, tab we have a table with following columns Stack Resource Resource Stack Resource Type Date Updated Status Status Reason We should consider to add one more column or table action to get a console link for the OS:Nova:Server resource type. When you click on console link , it should automatically open the console of instance. ** Affects: horizon Importance: Undecided Assignee: Ritesh (rsritesh) Status: New ** Changed in: horizon Assignee: (unassigned) = Ritesh (rsritesh) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1468667 Title: console option from heat resource list Status in OpenStack Dashboard (Horizon): New Bug description: In orchestration panel , we you check for stack details, you have following tabs : Topology Overview Resources Events Template In resources, tab we have a table with following columns Stack ResourceResource Stack Resource Type Date Updated Status Status Reason We should consider to add one more column or table action to get a console link for the OS:Nova:Server resource type. When you click on console link , it should automatically open the console of instance. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1468667/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466851] Re: Move to graduated oslo.service
muranoclient-review: https://review.openstack.org/#/c/195456/ ** Also affects: python-muranoclient Importance: Undecided Status: New ** Changed in: python-muranoclient Status: New = In Progress ** Changed in: python-muranoclient Assignee: (unassigned) = Sergey Vilgelm (sergey.vilgelm) ** Also affects: murano Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1466851 Title: Move to graduated oslo.service Status in OpenStack Telemetry (Ceilometer): Fix Committed Status in Cinder: Fix Committed Status in Designate: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Magnum: In Progress Status in Manila: In Progress Status in Murano: In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): In Progress Status in python-muranoclient: In Progress Status in OpenStack Data Processing (Sahara): Fix Committed Status in Openstack Database (Trove): In Progress Bug description: oslo.service library has graduated so all OpenStack projects should port to it instead of using oslo-incubator code. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1466851/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466851] Re: Move to graduated oslo.service
searchlight review: https://review.openstack.org/#/c/195465/ ** Also affects: searchlight Importance: Undecided Status: New ** Changed in: searchlight Status: New = In Progress ** Changed in: searchlight Assignee: (unassigned) = Sergey Vilgelm (sergey.vilgelm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1466851 Title: Move to graduated oslo.service Status in OpenStack Telemetry (Ceilometer): Fix Committed Status in Cinder: Fix Committed Status in Designate: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Magnum: In Progress Status in Manila: In Progress Status in Murano: In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): In Progress Status in Volume discovery and local storage management lib: In Progress Status in python-muranoclient: In Progress Status in OpenStack Data Processing (Sahara): Fix Committed Status in OpenStack Search (Searchlight): In Progress Status in Openstack Database (Trove): In Progress Bug description: oslo.service library has graduated so all OpenStack projects should port to it instead of using oslo-incubator code. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1466851/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1468698] [NEW] Image-update api returns 500 while passing --min-ram and --min-disk greater than 2^(31) max value
Public bug reported: $ glance image-update b3886698-04c3-4621-9a04-4a587d3288d1 --min-ram 234578 HTTPInternalServerError (HTTP 500) $ glance image-update b3886698-04c3-4621-9a04-4a587d3288d1 --min-disk 234578 HTTPInternalServerError (HTTP 500) ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1468698 Title: Image-update api returns 500 while passing --min-ram and --min-disk greater than 2^(31) max value Status in OpenStack Image Registry and Delivery Service (Glance): New Bug description: $ glance image-update b3886698-04c3-4621-9a04-4a587d3288d1 --min-ram 234578 HTTPInternalServerError (HTTP 500) $ glance image-update b3886698-04c3-4621-9a04-4a587d3288d1 --min-disk 234578 HTTPInternalServerError (HTTP 500) To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1468698/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1466851] Re: Move to graduated oslo.service
congress review: https://review.openstack.org/#/c/195478/ ** Also affects: congress Importance: Undecided Status: New ** Changed in: congress Status: New = In Progress ** Changed in: congress Assignee: (unassigned) = Sergey Vilgelm (sergey.vilgelm) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1466851 Title: Move to graduated oslo.service Status in OpenStack Telemetry (Ceilometer): Fix Committed Status in Cinder: Fix Committed Status in OpenStack Congress: In Progress Status in Designate: In Progress Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Orchestration API (Heat): Fix Released Status in OpenStack Bare Metal Provisioning Service (Ironic): In Progress Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Magnum: In Progress Status in Manila: In Progress Status in Murano: In Progress Status in OpenStack Neutron (virtual network service): In Progress Status in OpenStack Compute (Nova): In Progress Status in Volume discovery and local storage management lib: In Progress Status in python-muranoclient: In Progress Status in OpenStack Data Processing (Sahara): Fix Committed Status in OpenStack Search (Searchlight): In Progress Status in Openstack Database (Trove): In Progress Bug description: oslo.service library has graduated so all OpenStack projects should port to it instead of using oslo-incubator code. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1466851/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
