| 2016-08-30 13:57:32 |
Timur Nurlygayanov |
bug |
|
|
added bug |
| 2016-08-30 13:57:40 |
Timur Nurlygayanov |
nominated for series |
|
mos/9.x |
|
| 2016-08-30 13:57:40 |
Timur Nurlygayanov |
bug task added |
|
mos/9.x |
|
| 2016-08-30 13:57:51 |
Timur Nurlygayanov |
mos/9.x: assignee |
|
MOS Linux (mos-linux) |
|
| 2016-08-30 13:57:54 |
Timur Nurlygayanov |
mos/9.x: importance |
Undecided |
High |
|
| 2016-08-30 13:57:56 |
Timur Nurlygayanov |
mos/9.x: milestone |
|
9.1 |
|
| 2016-08-30 13:57:59 |
Timur Nurlygayanov |
mos/9.x: status |
New |
Confirmed |
|
| 2016-08-30 13:58:15 |
Timur Nurlygayanov |
tags |
|
area-linux |
|
| 2016-08-30 14:01:17 |
Alexander Gromov |
bug |
|
|
added subscriber Alexander Gromov |
| 2016-08-30 14:03:46 |
Timur Nurlygayanov |
description |
Steps To Reproduce:
1. Deploy the OpenStack cloud on the bare-metal lab with MOS 9.0 or MOS 9.x (we tested it on MOS 9.1) - the main idea is to have Openstack compute nodes with Ubuntu 14.04 installed.
2. Login to Openstack controller node via ssh and upload Ubuntu 16.04 image to the cloud:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
glance image-create --name "Test-xenial-server-cloudimg-amd64-disk1.img" --disk-format raw --container-format bare --file xenial-server-cloudimg-amd64-disk1.img
3. Boot VM with this image and try to ssh to this VM via Floating IP:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/os_deploy
nova keypair-add --pub-key ~/.ssh/os_deploy.pub os-deploy
nova secgroup-add-rule default icmp -1 -1 0/0
nova secgroup-add-rule default tcp 1 65535 0/0
nova boot --image Test-xenial-server-cloudimg-amd64-disk1.img --nic net-name=admin_internal_net --flavor m1.medium --key-name os-deploy TestUbuntu16.04-VM
nova floating-ip-create
nova floating-ip-associate TestUbuntu16.04-VM <insert new Floating IP here>
ssh ubuntu@<insert Floating IP of VM here> -i ~/.ssh/os_deploy
Observed Result:
User can't login to VM, host system of VM in sigfolt:
http://xsnippet.org/361927/
http://paste.openstack.org/show/564837/
Upstream Ubuntu Issue:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1524069
Customer Impact:
All users of MOS 9.0 and 9.x with bare-metal labs are affected. It is not possible to boot VMs with the latest Ubuntu 16.04 image. |
Steps To Reproduce:
1. Deploy the OpenStack cloud on the bare-metal lab with MOS 9.0 or MOS 9.x (we tested it on MOS 9.1) - the main idea is to have Openstack compute nodes with Ubuntu 14.04 installed.
2. Login to Openstack controller node via ssh and upload Ubuntu 16.04 image to the cloud:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
glance image-create --name "Test-xenial-server-cloudimg-amd64-disk1.img" --disk-format raw --container-format bare --file xenial-server-cloudimg-amd64-disk1.img
3. Boot VM with this image and try to ssh to this VM via Floating IP:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/os_deploy
nova keypair-add --pub-key ~/.ssh/os_deploy.pub os-deploy
nova secgroup-add-rule default icmp -1 -1 0/0
nova secgroup-add-rule default tcp 1 65535 0/0
nova boot --image Test-xenial-server-cloudimg-amd64-disk1.img --nic net-name=admin_internal_net --flavor m1.medium --key-name os-deploy TestUbuntu16.04-VM
nova floating-ip-create
nova floating-ip-associate TestUbuntu16.04-VM <insert new Floating IP here>
ssh ubuntu@<insert Floating IP of VM here> -i ~/.ssh/os_deploy
Observed Result:
User can't login to VM, host system of VM in sigfolt:
http://xsnippet.org/361927/
http://paste.openstack.org/show/564837/
Expected Result:
User can successfully boot VMs with Ubuntu 16.04 in MOs 9.x clouds.
Upstream Ubuntu Issue (it looks like the same issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1524069
Customer Impact:
All users of MOS 9.0 and 9.x with bare-metal labs are affected. It is not possible to boot VMs with the latest Ubuntu 16.04 image. |
|
| 2016-08-30 14:12:57 |
Timur Nurlygayanov |
description |
Steps To Reproduce:
1. Deploy the OpenStack cloud on the bare-metal lab with MOS 9.0 or MOS 9.x (we tested it on MOS 9.1) - the main idea is to have Openstack compute nodes with Ubuntu 14.04 installed.
2. Login to Openstack controller node via ssh and upload Ubuntu 16.04 image to the cloud:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
glance image-create --name "Test-xenial-server-cloudimg-amd64-disk1.img" --disk-format raw --container-format bare --file xenial-server-cloudimg-amd64-disk1.img
3. Boot VM with this image and try to ssh to this VM via Floating IP:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/os_deploy
nova keypair-add --pub-key ~/.ssh/os_deploy.pub os-deploy
nova secgroup-add-rule default icmp -1 -1 0/0
nova secgroup-add-rule default tcp 1 65535 0/0
nova boot --image Test-xenial-server-cloudimg-amd64-disk1.img --nic net-name=admin_internal_net --flavor m1.medium --key-name os-deploy TestUbuntu16.04-VM
nova floating-ip-create
nova floating-ip-associate TestUbuntu16.04-VM <insert new Floating IP here>
ssh ubuntu@<insert Floating IP of VM here> -i ~/.ssh/os_deploy
Observed Result:
User can't login to VM, host system of VM in sigfolt:
http://xsnippet.org/361927/
http://paste.openstack.org/show/564837/
Expected Result:
User can successfully boot VMs with Ubuntu 16.04 in MOs 9.x clouds.
Upstream Ubuntu Issue (it looks like the same issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1524069
Customer Impact:
All users of MOS 9.0 and 9.x with bare-metal labs are affected. It is not possible to boot VMs with the latest Ubuntu 16.04 image. |
Steps To Reproduce:
1. Deploy the OpenStack cloud on the bare-metal lab with MOS 9.0 or MOS 9.x (we tested it on MOS 9.1) - the main idea is to have Openstack compute nodes with Ubuntu 14.04 installed.
2. Login to Openstack controller node via ssh and upload Ubuntu 16.04 image to the cloud:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
glance image-create --name "Test-xenial-server-cloudimg-amd64-disk1.img" --disk-format raw --container-format bare --file xenial-server-cloudimg-amd64-disk1.img
3. Boot VM with this image and try to ssh to this VM via Floating IP:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/os_deploy
nova keypair-add --pub-key ~/.ssh/os_deploy.pub os-deploy
nova secgroup-add-rule default icmp -1 -1 0/0
nova secgroup-add-rule default tcp 1 65535 0/0
nova boot --image Test-xenial-server-cloudimg-amd64-disk1.img --nic net-name=admin_internal_net --flavor m1.medium --key-name os-deploy TestUbuntu16.04-VM
nova floating-ip-create
nova floating-ip-associate TestUbuntu16.04-VM <insert new Floating IP here>
ssh ubuntu@<insert Floating IP of VM here> -i ~/.ssh/os_deploy
Observed Result:
User can't login to VM, host system of VM in sigfolt:
http://xsnippet.org/361927/
http://paste.openstack.org/show/564837/
Expected Result:
User can successfully boot VMs with Ubuntu 16.04 in MOs 9.x clouds.
Upstream Ubuntu Issue (it looks like the same issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1524069
Customer Impact:
All users of MOS 9.0 and 9.x with bare-metal labs are affected. It is not possible to boot VMs with the latest Ubuntu 16.04 image.
It is important to note that the issue not reproduced on virtual environments (with virtual OpenStack compute nodes) and we saw the issue only on one bare-metal lab. On our lab the issue reproduced in 100% of cases.
Ubuntu 14.04 image works fine. |
|
| 2016-08-30 15:38:33 |
Alexei Sheplyakov |
summary |
It is not possible to boot Ubuntu 16.04 xenial on hardware host with Ubuntu 14.04 |
nova-compute sets wrong CPU capabilites => guest kernel Oops'es on boot |
|
| 2016-08-30 15:39:13 |
Alexei Sheplyakov |
mos/9.x: assignee |
MOS Linux (mos-linux) |
|
|
| 2016-08-30 16:01:22 |
Alexei Sheplyakov |
description |
Steps To Reproduce:
1. Deploy the OpenStack cloud on the bare-metal lab with MOS 9.0 or MOS 9.x (we tested it on MOS 9.1) - the main idea is to have Openstack compute nodes with Ubuntu 14.04 installed.
2. Login to Openstack controller node via ssh and upload Ubuntu 16.04 image to the cloud:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
glance image-create --name "Test-xenial-server-cloudimg-amd64-disk1.img" --disk-format raw --container-format bare --file xenial-server-cloudimg-amd64-disk1.img
3. Boot VM with this image and try to ssh to this VM via Floating IP:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/os_deploy
nova keypair-add --pub-key ~/.ssh/os_deploy.pub os-deploy
nova secgroup-add-rule default icmp -1 -1 0/0
nova secgroup-add-rule default tcp 1 65535 0/0
nova boot --image Test-xenial-server-cloudimg-amd64-disk1.img --nic net-name=admin_internal_net --flavor m1.medium --key-name os-deploy TestUbuntu16.04-VM
nova floating-ip-create
nova floating-ip-associate TestUbuntu16.04-VM <insert new Floating IP here>
ssh ubuntu@<insert Floating IP of VM here> -i ~/.ssh/os_deploy
Observed Result:
User can't login to VM, host system of VM in sigfolt:
http://xsnippet.org/361927/
http://paste.openstack.org/show/564837/
Expected Result:
User can successfully boot VMs with Ubuntu 16.04 in MOs 9.x clouds.
Upstream Ubuntu Issue (it looks like the same issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1524069
Customer Impact:
All users of MOS 9.0 and 9.x with bare-metal labs are affected. It is not possible to boot VMs with the latest Ubuntu 16.04 image.
It is important to note that the issue not reproduced on virtual environments (with virtual OpenStack compute nodes) and we saw the issue only on one bare-metal lab. On our lab the issue reproduced in 100% of cases.
Ubuntu 14.04 image works fine. |
Steps To Reproduce:
1. Deploy the OpenStack cloud on the bare-metal lab with MOS 9.0 or MOS 9.x (we tested it on MOS 9.1) - the main idea is to have Openstack compute nodes with Ubuntu 14.04 installed.
2. Login to Openstack controller node via ssh and upload Ubuntu 16.04 image to the cloud:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
glance image-create --name "Test-xenial-server-cloudimg-amd64-disk1.img" --disk-format raw --container-format bare --file xenial-server-cloudimg-amd64-disk1.img
3. Boot VM with this image and try to ssh to this VM via Floating IP:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/os_deploy
nova keypair-add --pub-key ~/.ssh/os_deploy.pub os-deploy
nova secgroup-add-rule default icmp -1 -1 0/0
nova secgroup-add-rule default tcp 1 65535 0/0
nova boot --image Test-xenial-server-cloudimg-amd64-disk1.img --nic net-name=admin_internal_net --flavor m1.medium --key-name os-deploy TestUbuntu16.04-VM
nova floating-ip-create
nova floating-ip-associate TestUbuntu16.04-VM <insert new Floating IP here>
ssh ubuntu@<insert Floating IP of VM here> -i ~/.ssh/os_deploy
Observed Result:
User can't login to VM, host system of VM in sigfolt:
http://xsnippet.org/361927/
http://paste.openstack.org/show/564837/
Expected Result:
User can successfully boot VMs with Ubuntu 16.04 in MOs 9.x clouds.
Upstream Ubuntu Issue (it looks like the same issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1524069
Customer Impact:
All users of MOS 9.0 and 9.x with bare-metal labs are affected. It is not possible to boot VMs with the latest Ubuntu 16.04 image.
It is important to note that the issue not reproduced on virtual environments (with virtual OpenStack compute nodes) and we saw the issue only on one bare-metal lab. On our lab the issue reproduced in 100% of cases.
Ubuntu 14.04 image works fine.
The root cause is that libvirt specifies impossible combination of CPU model
and capabilities so the kernel Oops'es when trying to use the instructions which are reported as supported (when in reality they aren't).
Such a wrong CPU capabilities set is a result of <cpu mode='host-model'> in libvirt domain XML. This mode is documented to produce unexpected results
(http://libvirt.org/formatdomain.html#elementsCPU)
"Beware, due to the way libvirt detects host CPU and due to the fact libvirt does not talk to QEMU/KVM when creating the CPU model, CPU configuration created using host-model may not work as expected. The guest CPU may differ from the configuration and it may also confuse guest OS by using a combination of CPU features and other parameters (such as CPUID level) that don't work."
The wrong/inappropriate 'cpu mode' is set by Fuel in /etc/nova/nova.conf:
[libvirt]
inject_partition=-2
inject_password=False
disk_cachemodes="file=directsync,block=none"
cpu_mode=host-model
Fuel should not set a risky/problematic cpu_mode by default (it's better to leave this parameter unset). |
|
| 2016-08-30 16:11:54 |
Timur Nurlygayanov |
mos/9.x: assignee |
|
MOS Puppet Team (mos-puppet) |
|
| 2016-08-30 19:50:16 |
Maksim Malchuk |
information type |
Public |
Public Security |
|
| 2016-08-30 23:22:17 |
Adam Heczko |
information type |
Public Security |
Private Security |
|
| 2016-08-30 23:22:27 |
Adam Heczko |
removed subscriber Alexander Gromov |
|
|
|
| 2016-08-31 06:02:31 |
Alexei Sheplyakov |
information type |
Private Security |
Public |
|
| 2016-08-31 06:37:06 |
Alexei Sheplyakov |
description |
Steps To Reproduce:
1. Deploy the OpenStack cloud on the bare-metal lab with MOS 9.0 or MOS 9.x (we tested it on MOS 9.1) - the main idea is to have Openstack compute nodes with Ubuntu 14.04 installed.
2. Login to Openstack controller node via ssh and upload Ubuntu 16.04 image to the cloud:
wget https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-disk1.img
glance image-create --name "Test-xenial-server-cloudimg-amd64-disk1.img" --disk-format raw --container-format bare --file xenial-server-cloudimg-amd64-disk1.img
3. Boot VM with this image and try to ssh to this VM via Floating IP:
ssh-keygen -t rsa -b 4096 -f ~/.ssh/os_deploy
nova keypair-add --pub-key ~/.ssh/os_deploy.pub os-deploy
nova secgroup-add-rule default icmp -1 -1 0/0
nova secgroup-add-rule default tcp 1 65535 0/0
nova boot --image Test-xenial-server-cloudimg-amd64-disk1.img --nic net-name=admin_internal_net --flavor m1.medium --key-name os-deploy TestUbuntu16.04-VM
nova floating-ip-create
nova floating-ip-associate TestUbuntu16.04-VM <insert new Floating IP here>
ssh ubuntu@<insert Floating IP of VM here> -i ~/.ssh/os_deploy
Observed Result:
User can't login to VM, host system of VM in sigfolt:
http://xsnippet.org/361927/
http://paste.openstack.org/show/564837/
Expected Result:
User can successfully boot VMs with Ubuntu 16.04 in MOs 9.x clouds.
Upstream Ubuntu Issue (it looks like the same issue):
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1524069
Customer Impact:
All users of MOS 9.0 and 9.x with bare-metal labs are affected. It is not possible to boot VMs with the latest Ubuntu 16.04 image.
It is important to note that the issue not reproduced on virtual environments (with virtual OpenStack compute nodes) and we saw the issue only on one bare-metal lab. On our lab the issue reproduced in 100% of cases.
Ubuntu 14.04 image works fine.
The root cause is that libvirt specifies impossible combination of CPU model
and capabilities so the kernel Oops'es when trying to use the instructions which are reported as supported (when in reality they aren't).
Such a wrong CPU capabilities set is a result of <cpu mode='host-model'> in libvirt domain XML. This mode is documented to produce unexpected results
(http://libvirt.org/formatdomain.html#elementsCPU)
"Beware, due to the way libvirt detects host CPU and due to the fact libvirt does not talk to QEMU/KVM when creating the CPU model, CPU configuration created using host-model may not work as expected. The guest CPU may differ from the configuration and it may also confuse guest OS by using a combination of CPU features and other parameters (such as CPUID level) that don't work."
The wrong/inappropriate 'cpu mode' is set by Fuel in /etc/nova/nova.conf:
[libvirt]
inject_partition=-2
inject_password=False
disk_cachemodes="file=directsync,block=none"
cpu_mode=host-model
Fuel should not set a risky/problematic cpu_mode by default (it's better to leave this parameter unset). |
Steps To Reproduce:
1. Find a CPU which supports AVX2 instructions (such as Intel Core i7)
2. Install the kernel and qemu which can't handle AVX2 instructions in the guest mode (for instance, the ones shipped with Ubuntu 14.04)
3. Define a VM (via libvirt) with 'cpu_mode' parameter being 'host-model' (<cpu mode='host-model'> in the VM XML definition).
4. Boot the kernel which can make use of AVX2 instructions (such as Linux 4.4.x) in the VM
Expected result: the *guest* kernel boots
Actual result: the *guest* kernel panics during the boot while trying to execute an AVX2 instruction (see http://xsnippet.org/361927)
Customer Impact:
Depending on the hardware Ubuntu 16.04 cloud images can be unusable "out of the box" on OpenStack clouds deployed with Fuel/MOS 9.0 (and earlier versions). Most likely the problem affects other kernels/drivers which make use of SIMD instructions
Note: there are at least 3 factors which influence the problem:
- the host CPU (should be more or less recent)
- the host kernel and qemu which can't handle some of the SIMD instructions in the guest mode
- the guest kernel (which makes use of those instructions)
The root cause is that libvirt specifies impossible combination of CPU model
and capabilities so the kernel Oops'es when trying to use the instructions which are reported as supported (when in reality they aren't).
Such a wrong CPU capabilities set is a result of <cpu mode='host-model'> in libvirt domain XML. This mode is documented to produce unexpected results
(http://libvirt.org/formatdomain.html#elementsCPU)
"Beware, due to the way libvirt detects host CPU and due to the fact libvirt does not talk to QEMU/KVM when creating the CPU model, CPU configuration created using host-model may not work as expected. The guest CPU may differ from the configuration and it may also confuse guest OS by using a combination of CPU features and other parameters (such as CPUID level) that don't work."
The wrong/inappropriate 'cpu mode' is set by Fuel in /etc/nova/nova.conf:
[libvirt]
inject_partition=-2
inject_password=False
disk_cachemodes="file=directsync,block=none"
cpu_mode=host-model
Fuel should not set a risky/problematic cpu_mode by default (it's better to leave this parameter unset). |
|
| 2016-08-31 08:49:42 |
Ivan Berezovskiy |
mos/9.x: assignee |
MOS Puppet Team (mos-puppet) |
Alexei Sheplyakov (asheplyakov) |
|
| 2016-08-31 16:44:48 |
Timur Nurlygayanov |
mos/9.x: status |
Confirmed |
Fix Committed |
|
| 2016-08-31 16:44:58 |
Timur Nurlygayanov |
nominated for series |
|
mos/10.0.x |
|
| 2016-08-31 16:44:58 |
Timur Nurlygayanov |
bug task added |
|
mos/10.0.x |
|
| 2016-08-31 16:44:58 |
Timur Nurlygayanov |
nominated for series |
|
mos/8.0.x |
|
| 2016-08-31 16:44:58 |
Timur Nurlygayanov |
bug task added |
|
mos/8.0.x |
|
| 2016-08-31 16:45:16 |
Timur Nurlygayanov |
mos/10.0.x: milestone |
|
10.0 |
|
| 2016-08-31 16:45:20 |
Timur Nurlygayanov |
mos/8.0.x: milestone |
|
8.0-mu-4 |
|
| 2016-08-31 16:45:24 |
Timur Nurlygayanov |
mos/9.x: status |
Fix Committed |
Confirmed |
|
| 2016-08-31 16:45:27 |
Timur Nurlygayanov |
mos/10.0.x: status |
New |
Fix Committed |
|
| 2016-08-31 16:45:39 |
Timur Nurlygayanov |
mos/10.0.x: assignee |
|
Alexei Sheplyakov (asheplyakov) |
|
| 2016-08-31 16:45:43 |
Timur Nurlygayanov |
mos/10.0.x: importance |
Undecided |
High |
|
| 2016-08-31 16:45:45 |
Timur Nurlygayanov |
mos/8.0.x: importance |
Undecided |
High |
|
| 2016-08-31 16:45:55 |
Timur Nurlygayanov |
mos/8.0.x: assignee |
|
Alexei Sheplyakov (asheplyakov) |
|
| 2016-08-31 16:45:59 |
Vitaly Sedelnik |
mos/8.0.x: status |
New |
Confirmed |
|
| 2016-08-31 16:46:10 |
Vitaly Sedelnik |
mos/8.0.x: assignee |
Alexei Sheplyakov (asheplyakov) |
MOS Maintenance (mos-maintenance) |
|
| 2016-08-31 16:46:48 |
Timur Nurlygayanov |
nominated for series |
|
mos/7.0.x |
|
| 2016-08-31 16:46:48 |
Timur Nurlygayanov |
bug task added |
|
mos/7.0.x |
|
| 2016-08-31 16:46:56 |
Timur Nurlygayanov |
mos/7.0.x: status |
New |
Confirmed |
|
| 2016-08-31 16:46:58 |
Timur Nurlygayanov |
mos/7.0.x: importance |
Undecided |
High |
|
| 2016-08-31 16:47:03 |
Timur Nurlygayanov |
mos/7.0.x: milestone |
|
8.0-mu-4 |
|
| 2016-08-31 16:47:16 |
Timur Nurlygayanov |
mos/7.0.x: milestone |
8.0-mu-4 |
7.0-mu-6 |
|
| 2016-08-31 16:47:33 |
Vitaly Sedelnik |
mos/7.0.x: assignee |
|
MOS Maintenance (mos-maintenance) |
|
| 2016-09-06 15:58:00 |
Timur Nurlygayanov |
mos/8.0.x: status |
Confirmed |
Invalid |
|
| 2016-09-06 17:32:39 |
Alexey Stupnikov |
mos/8.0.x: milestone |
8.0-mu-4 |
8.0-updates |
|
| 2016-09-07 05:36:15 |
Alexey Stupnikov |
mos/8.0.x: milestone |
8.0-updates |
8.0-mu-4 |
|
| 2016-09-07 05:36:17 |
Alexey Stupnikov |
mos/8.0.x: status |
Invalid |
Confirmed |
|
| 2016-09-07 14:15:23 |
Alexey Stupnikov |
nominated for series |
|
mos/6.1.x |
|
| 2016-09-07 14:15:23 |
Alexey Stupnikov |
bug task added |
|
mos/6.1.x |
|
| 2016-09-07 14:15:23 |
Alexey Stupnikov |
nominated for series |
|
mos/5.1.x |
|
| 2016-09-07 14:15:23 |
Alexey Stupnikov |
bug task added |
|
mos/5.1.x |
|
| 2016-09-07 14:15:23 |
Alexey Stupnikov |
nominated for series |
|
mos/6.0.x |
|
| 2016-09-07 14:15:23 |
Alexey Stupnikov |
bug task added |
|
mos/6.0.x |
|
| 2016-09-07 14:15:33 |
Alexey Stupnikov |
mos/5.1.x: assignee |
|
Alexey Stupnikov (astupnikov) |
|
| 2016-09-07 14:15:36 |
Alexey Stupnikov |
mos/6.1.x: assignee |
|
Alexey Stupnikov (astupnikov) |
|
| 2016-09-07 14:15:38 |
Alexey Stupnikov |
mos/7.0.x: assignee |
MOS Maintenance (mos-maintenance) |
Alexey Stupnikov (astupnikov) |
|
| 2016-09-07 14:15:48 |
Alexey Stupnikov |
mos/5.1.x: importance |
Undecided |
High |
|
| 2016-09-07 14:15:53 |
Alexey Stupnikov |
mos/6.0.x: importance |
Undecided |
High |
|
| 2016-09-07 14:15:57 |
Alexey Stupnikov |
mos/6.1.x: importance |
Undecided |
High |
|
| 2016-09-07 14:15:59 |
Alexey Stupnikov |
mos/6.1.x: milestone |
|
6.1-updates |
|
| 2016-09-07 14:16:03 |
Alexey Stupnikov |
mos/6.0.x: milestone |
|
6.0-updates |
|
| 2016-09-07 14:16:10 |
Alexey Stupnikov |
mos/5.1.x: milestone |
|
5.1.1-updates |
|
| 2016-09-07 14:16:13 |
Alexey Stupnikov |
mos/6.0.x: assignee |
|
Alexey Stupnikov (astupnikov) |
|
| 2016-09-07 14:16:30 |
Alexey Stupnikov |
mos/8.0.x: assignee |
MOS Maintenance (mos-maintenance) |
Alexey Stupnikov (astupnikov) |
|
| 2016-09-08 14:04:43 |
Alexey Stupnikov |
mos/5.1.x: status |
New |
Confirmed |
|
| 2016-09-08 14:04:45 |
Alexey Stupnikov |
mos/6.0.x: status |
New |
Confirmed |
|
| 2016-09-08 14:04:47 |
Alexey Stupnikov |
mos/6.1.x: status |
New |
Confirmed |
|
| 2016-09-09 16:01:01 |
Vitaly Sedelnik |
mos/9.x: assignee |
Alexei Sheplyakov (asheplyakov) |
Rodion Tikunov (rtikunov) |
|
| 2016-09-09 16:07:00 |
Vitaly Sedelnik |
mos/9.x: assignee |
Rodion Tikunov (rtikunov) |
Alexei Sheplyakov (asheplyakov) |
|
| 2016-09-09 16:07:19 |
Vitaly Sedelnik |
mos/9.x: status |
Confirmed |
Fix Committed |
|
| 2016-09-12 10:26:49 |
Alexey Stupnikov |
mos/5.1.x: status |
Confirmed |
Won't Fix |
|
| 2016-09-12 10:26:52 |
Alexey Stupnikov |
mos/6.0.x: status |
Confirmed |
Won't Fix |
|
| 2016-09-12 10:27:14 |
Alexey Stupnikov |
mos/6.1.x: milestone |
6.1-updates |
6.1-mu-8 |
|
| 2016-09-12 11:30:27 |
Alexey Stupnikov |
mos/6.1.x: status |
Confirmed |
In Progress |
|
| 2016-09-12 11:30:29 |
Alexey Stupnikov |
mos/7.0.x: status |
Confirmed |
In Progress |
|
| 2016-09-12 11:30:33 |
Alexey Stupnikov |
mos/8.0.x: status |
Confirmed |
In Progress |
|
| 2016-09-12 11:36:57 |
Timur Nurlygayanov |
mos/9.x: status |
Fix Committed |
Fix Released |
|
| 2016-09-12 11:36:59 |
Timur Nurlygayanov |
mos/10.0.x: status |
Fix Committed |
Fix Released |
|
| 2016-09-21 21:26:03 |
Sergey Reshetnyak |
bug task added |
|
fuel-ccp |
|
| 2016-10-10 09:41:43 |
Alexey Stupnikov |
mos/6.1.x: status |
In Progress |
Fix Committed |
|
| 2016-10-10 09:41:47 |
Alexey Stupnikov |
mos/8.0.x: status |
In Progress |
Fix Committed |
|
| 2016-10-13 07:10:24 |
Alexey Stupnikov |
mos/7.0.x: status |
In Progress |
Fix Committed |
|
| 2016-10-19 14:34:27 |
TatyanaGladysheva |
tags |
area-linux |
area-linux on-verification |
|
| 2016-10-24 12:14:16 |
TatyanaGladysheva |
tags |
area-linux on-verification |
area-linux |
|
| 2016-10-24 12:14:24 |
TatyanaGladysheva |
mos/7.0.x: status |
Fix Committed |
Fix Released |
|
| 2016-11-15 12:29:43 |
Alexey Stupnikov |
mos/6.1.x: milestone |
6.1-mu-8 |
6.1-updates |
|
| 2016-11-18 11:11:40 |
Alexey Stupnikov |
mos/8.0.x: milestone |
8.0-mu-4 |
8.0-updates |
|
| 2017-01-13 13:47:14 |
Sergey Reshetnyak |
bug task deleted |
fuel-ccp |
|
|
