[Yahoo-eng-team] [Bug 1782349] Re: Failed to schedule instances: NoValidHost_Remote: No valid host was found.

2018-11-02 Thread Launchpad Bug Tracker
[Expired for OpenStack Compute (nova) because there has been no activity
for 60 days.]

** Changed in: nova
   Status: Incomplete => Expired

-- 
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/1782349

Title:
   Failed to schedule instances: NoValidHost_Remote: No valid host was
  found.

Status in OpenStack Compute (nova):
  Expired

Bug description:
  openstack Q:

  (openstack) compute service list
  
++--++--+-+---++
  | ID | Binary   | Host   | Zone | Status  | State | Updated 
At |
  
++--++--+-+---++
  |  1 | nova-consoleauth | controller | internal | enabled | up| 
2018-07-18T12:23:51.00 |
  |  2 | nova-conductor   | controller | internal | enabled | up| 
2018-07-18T12:23:47.00 |
  |  3 | nova-scheduler   | controller | internal | enabled | up| 
2018-07-18T12:23:49.00 |
  |  6 | nova-compute | controller | nova | enabled | up| 
2018-07-18T12:23:53.00 |
  |  7 | nova-compute | compute01  | nova | enabled | up| 
2018-07-18T12:23:47.00 |
  
++--++--+-+---++


  (openstack) flavor list
  
+--+--+-+--+---+---+---+
  | ID   | Name | RAM | Disk | Ephemeral | 
VCPUs | Is Public |
  
+--+--+-+--+---+---+---+
  | 2340e418-8214-440f-a5b6-39a1e3648cf1 | f1   | 512 |   10 | 0 | 
1 | True  |
  | f1c886da-b5ab-4519-b0ca-b0703e18d629 | f0   | 512 |1 | 0 | 
1 | True  |
  
+--+--+-+--+---+---+---+

  
  (openstack) hypervisor stats show
  +--+---+
  | Field| Value |
  +--+---+
  | count| 2 |
  | current_workload | 0 |
  | disk_available_least | 81|
  | free_disk_gb | 87|
  | free_ram_mb  | 30718 |
  | local_gb | 98|
  | local_gb_used| 11|
  | memory_mb| 32766 |
  | memory_mb_used   | 2048  |
  | running_vms  | 2 |
  | vcpus| 20|
  | vcpus_used   | 2 |
  +--+---+

  
  [root@controller ~]# tail -f /var/log/nova/nova-conductor.log
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager 
[req-f360123a-42b8-4941-8fd6-496baa0742bb 93978126a56848db8a0cb177311c3076 
11bd52001a0a45fd87f1d6e44949abaa - default default] Failed to schedule 
instances: NoValidHost_Remote: No valid host was found. 
  Traceback (most recent call last):

File "/usr/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 
226, in inner
  return func(*args, **kwargs)

File "/usr/lib/python2.7/site-packages/nova/scheduler/manager.py", line 
139, in select_destinations
  raise exception.NoValidHost(reason="")

  NoValidHost: No valid host was found.
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager Traceback (most 
recent call last):
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager   File 
"/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 1116, in 
schedule_and_build_instances
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager 
instance_uuids, return_alternates=True)
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager   File 
"/usr/lib/python2.7/site-packages/nova/conductor/manager.py", line 716, in 
_schedule_instances
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager 
return_alternates=return_alternates)
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager   File 
"/usr/lib/python2.7/site-packages/nova/scheduler/utils.py", line 726, in wrapped
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager return 
func(*args, **kwargs)
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager   File 
"/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 53, 
in select_destinations
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager 
instance_uuids, return_objects, return_alternates)
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager   File 
"/usr/lib/python2.7/site-packages/nova/scheduler/client/__init__.py", line 37, 
in __run_method
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager return 
getattr(self.instance, __name)(*args, **kwargs)
  2018-07-18 20:21:22.904 13466 ERROR nova.conductor.manager   File 
"/usr/lib/python2.7/site-packages/nova/scheduler/client/query.py", line 42, in 
select_destinations
  2018-07-18 20:21:22.904 13466 

[Yahoo-eng-team] [Bug 1801465] [NEW] Update min tox version to 2.0

2018-11-02 Thread shupeng
Public bug reported:

The commands used by constraints need at least tox 2.0.  Update to
reflect reality, which should help with local running of constraints
targets.

** Affects: neutron
 Importance: Undecided
 Assignee: shupeng (superman000)
 Status: In Progress

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1801465

Title:
  Update min tox version to 2.0

Status in neutron:
  In Progress

Bug description:
  The commands used by constraints need at least tox 2.0.  Update to
  reflect reality, which should help with local running of constraints
  targets.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1801465/+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 1801444] [NEW] the nubmers of service components is not right

2018-11-02 Thread zhulingjie
Public bug reported:

the nubmers of service components is not right

** Affects: nova
 Importance: Undecided
 Assignee: caoyuan (cao-yuan)
 Status: In Progress

** Summary changed:

- the nubmers of service components is not rigth
+ the nubmers of service components is not right

** Description changed:

- the nubmers of service components is not rigth
+ the nubmers of service components is not right

-- 
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/1801444

Title:
  the nubmers of service components is not right

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  the nubmers of service components is not right

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1801444/+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 1769609] Re: neutron-tempest-plugin: there is no way to create a subnet without a gateway and this breaks trunk tests

2018-11-02 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/615206
Committed: 
https://git.openstack.org/cgit/openstack/neutron-tempest-plugin/commit/?id=21f5342de8b36c3c033d959b63451723e4fdbcf3
Submitter: Zuul
Branch:master

commit 21f5342de8b36c3c033d959b63451723e4fdbcf3
Author: Slawek Kaplonski 
Date:   Fri Nov 2 16:02:09 2018 +0100

Fix creating subnet without gateway

If create_subnet() method is called with gateway=None explicity,
subnet should be created without gateway_ip specified.
To achieve that "gateway_ip=null" should be passed in json in
request's body to neutron server.
This was missing, so neutron-server allocated gateway_ip automatically.
Now gateway for such network will not be set as is expected.

Closes-Bug: #1769609

Change-Id: Ia9f0646a3cf371f82f2aa2dc22837249531d1ff5


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1769609

Title:
  neutron-tempest-plugin: there is no way to create a subnet without a
  gateway and this breaks trunk tests

Status in neutron:
  Fix Released

Bug description:
  This commit [0] fixed an issue with the subnet CIDR generation in tempest 
tests.
  With the fix all subnets will get a gateway assigned regardless that it's 
attached to a router or not so it may happen that the gateway port doesn't 
exist. Normally, this shouldn't be a big deal but for trunk ports it's 
currently an issue with test_subport_connectivity [1] where the test boots a VM 
(advanced image) and then opens an SSH connection to its FIP to configure the 
interface for the subport and runs dhclient on it.

  When dhclient runs, a new default gateway route is installed and the
  connectivity to the FIP is lost thus making the test to fail as it
  fails to execute/read any further commands:

  I logged into the VM with virsh and checked the routes:

  [root@tempest-server-test-378882328 ~]# ip r
  default via 10.100.0.17 dev eth0.10
  default via 10.100.0.1 dev eth0 proto static metric 100
  default via 10.100.0.17 dev eth0.10 proto static metric 400
  10.100.0.0/28 dev eth0 proto kernel scope link src 10.100.0.5 metric 100
  10.100.0.16/28 dev eth0.10 proto kernel scope link src 10.100.0.25
  169.254.169.254 via 10.100.0.18 dev eth0.10 proto dhcp
  169.254.169.254 via 10.100.0.2 dev eth0 proto dhcp metric 100

  This shouldn't happen as the subnet is not even connected to a router
  and also 10.100.0.17 doesn't even exist in Neutron. Prior to [0] it
  didn't fail because old code would create the subnet with gateway=None
  and it was skipped (actually it will only setup a gateway
  automatically if gateway equals to '' [2] but it was None instead
  [3]).

  Let's allow a way to have the ability to configure subnets without a
  gateway.

  [0] 
https://github.com/openstack/neutron-tempest-plugin/commit/0ddc93b1b19922d08bedf331b57c363535bb357e
  [1] 
https://github.com/openstack/neutron-tempest-plugin/blob/02a5e2b07680d8c4dd69d681ae9a01d92b4be0ac/neutron_tempest_plugin/scenario/test_trunk.py#L229
  [2] 
https://github.com/openstack/neutron-tempest-plugin/commit/0ddc93b1b19922d08bedf331b57c363535bb357e#diff-872f814e35c7437b9f42aef71a991279L295
  [3] 
https://github.com/openstack/neutron-tempest-plugin/commit/0ddc93b1b19922d08bedf331b57c363535bb357e#diff-2f4232239c10eae0d0688617a3e6f98dL238

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1769609/+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 1799150] Re: [l3][port_forwarding] internal/external port should not allow 0

2018-11-02 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/613562
Committed: 
https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=8dc31ec5f2db6e6ff5b2b4d4a27c239de5e12cfb
Submitter: Zuul
Branch:master

commit 8dc31ec5f2db6e6ff5b2b4d4a27c239de5e12cfb
Author: LIU Yulong 
Date:   Fri Oct 26 19:40:15 2018 +0800

Disable port number 0 for floating IP port_forwarding

Floating IP port forwarding internal or external port number should
not allow 0, otherwise you will get some ValueError exception in
neutron server.

Directly modify the floating-ip-port-forwarding extension to change
the external_port and internal_port minimum value.

Change-Id: Icb177932f6cf1262757b29cb9b997321704616b7
Closes-Bug: #1799150


** Changed in: neutron
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1799150

Title:
  [l3][port_forwarding] internal/external port should not allow 0

Status in neutron:
  Fix Released

Bug description:
  ENV: devstack master

  Floating IP port forwarding internal or external port number should
  not allow 0, otherwise you will get some ValueError exception in
  neutron server.

  Step to reproduce:
  1. create router with connected privated subnet and public gateway.
  2. create VM to the private subnet
  3. create floating IP
  4. create port forwarding with internal or external port number 0

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1799150/+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 1800575] Re: the prompt message does not contain a name or id when creating volume with empty name

2018-11-02 Thread OpenStack Infra
Reviewed:  https://review.openstack.org/614059
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=6d2fd17f0950c9ca3e70aaeacdfc8d1881e22cf6
Submitter: Zuul
Branch:master

commit 6d2fd17f0950c9ca3e70aaeacdfc8d1881e22cf6
Author: wangliangyu 
Date:   Tue Oct 30 10:19:51 2018 +0800

Creating volume prompt message always contain name

The creating volume successful prompt message format is:
  'Creating volume "%s"' % data["name"]
the data['name'] could be empty since it is not request.
But volume.name is always has a value, that the name or
id of volume.

Change-Id: Ife870ebbc1f37a44729637ddec283686d29234fb
Closes-Bug: #1800575


** Changed in: horizon
   Status: In Progress => Fix Released

-- 
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/1800575

Title:
  the prompt message does not contain a name or id when creating volume
  with empty name

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  The name of volume is not requested, and we could not fill anything when 
creating volume.
  The prompt ,'Creating volume "%s"' % data["name"], will be 'Creating volume 
""'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1800575/+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 1801364] [NEW] persisting OpenStack metadat fails

2018-11-02 Thread Robert Schweikert
Public bug reported:

Persistsing OpenStack metadata may fail.

OpenStack has an entry named "random_seed" in the metadata [1]. This
entry is treaded specially in the openstack.py helper when the metadat
is read [2]. The attempt to decode the read data my result in a string
that is not utf-8 compliant which eventually results in an error when we
attempt to persist the metadata as follows:

2018-11-02 12:14:13,755 - __init__.py[WARNING]: Error persisting
instance-data.json: 'utf8' codec can't decode byte 0xc8 in position 2:
invalid continuation byte


[1] https://docs.openstack.org/nova/latest/user/metadata-service.html
[2] 
https://github.com/cloud-init/cloud-init/blob/master/cloudinit/sources/helpers/openstack.py#L294

** Affects: cloud-init
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1801364

Title:
  persisting OpenStack metadat fails

Status in cloud-init:
  New

Bug description:
  Persistsing OpenStack metadata may fail.

  OpenStack has an entry named "random_seed" in the metadata [1]. This
  entry is treaded specially in the openstack.py helper when the metadat
  is read [2]. The attempt to decode the read data my result in a string
  that is not utf-8 compliant which eventually results in an error when
  we attempt to persist the metadata as follows:

  2018-11-02 12:14:13,755 - __init__.py[WARNING]: Error persisting
  instance-data.json: 'utf8' codec can't decode byte 0xc8 in position 2:
  invalid continuation byte

  
  [1] https://docs.openstack.org/nova/latest/user/metadata-service.html
  [2] 
https://github.com/cloud-init/cloud-init/blob/master/cloudinit/sources/helpers/openstack.py#L294

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1801364/+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 1801361] [NEW] Missing install step for OVS-Self-service networks

2018-11-02 Thread Varun Nair
Public bug reported:

I am using Openstack Queens release (on Ubuntu 16.04.4 LTS) and
attempting to install the OVS mechanism driver for self-service network
creation, as per the official documentation in
https://docs.openstack.org/neutron/queens/admin/deploy-ovs-
selfservice.html

- [X] This doc is inaccurate in this way: At step 5 of the network node
configuration (https://docs.openstack.org/neutron/queens/admin/deploy-
ovs-selfservice.html#network-node), the user is asked to create the OVS
provider bridge "br-provider". However, following this step, an
instruction to add the provider network interface (in the network node)
as a port on "br-provider" is missing. As a result, the router
namespace, and consequently the VMs created in a self-service network
interfaced with the router, will be unable to communicate with the
provider network.

- [X] This is a doc addition request.

- [X] I have a fix to the document that I can paste below:
Following step needs to be added after step 5: 
ovs-vsctl add-port br-provider PROVIDER_INTERFACE
Replace PROVIDER_INTERFACE with the name of the underlying interface that 
handles provider networks. For example, eth1


---
Release: 12.0.5.dev39 on 2018-10-31 08:00
SHA: af84349a4cca1bb1dbca9d6444f3c50bbe260683
Source: 
https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/deploy-ovs-selfservice.rst
URL: https://docs.openstack.org/neutron/queens/admin/deploy-ovs-selfservice.html

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc ovs

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1801361

Title:
  Missing install step for OVS-Self-service networks

Status in neutron:
  New

Bug description:
  I am using Openstack Queens release (on Ubuntu 16.04.4 LTS) and
  attempting to install the OVS mechanism driver for self-service
  network creation, as per the official documentation in
  https://docs.openstack.org/neutron/queens/admin/deploy-ovs-
  selfservice.html

  - [X] This doc is inaccurate in this way: At step 5 of the network
  node configuration (https://docs.openstack.org/neutron/queens/admin
  /deploy-ovs-selfservice.html#network-node), the user is asked to
  create the OVS provider bridge "br-provider". However, following this
  step, an instruction to add the provider network interface (in the
  network node) as a port on "br-provider" is missing. As a result, the
  router namespace, and consequently the VMs created in a self-service
  network interfaced with the router, will be unable to communicate with
  the provider network.

  - [X] This is a doc addition request.

  - [X] I have a fix to the document that I can paste below:
  Following step needs to be added after step 5: 
  ovs-vsctl add-port br-provider PROVIDER_INTERFACE
  Replace PROVIDER_INTERFACE with the name of the underlying interface that 
handles provider networks. For example, eth1


  ---
  Release: 12.0.5.dev39 on 2018-10-31 08:00
  SHA: af84349a4cca1bb1dbca9d6444f3c50bbe260683
  Source: 
https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/admin/deploy-ovs-selfservice.rst
  URL: 
https://docs.openstack.org/neutron/queens/admin/deploy-ovs-selfservice.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1801361/+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 1801342] [NEW] Attach a volume with scsi bus on an instance boot from cdrom fails

2018-11-02 Thread Jose Castro Leon
Public bug reported:

Following the upstream documentation to create images from an ISO
(https://docs.openstack.org/nova/rocky/user/launch-instance-using-ISO-
image.html) with an image from a vendor that required to have the disk
attached on the scsi bus (/dev/sda) in order to install the system, it
failed on attach volume step with the following traceback:


Driver failed to attach volume 95b42945-5d2a-4fba-b970-1d3fafcfbecc at 
/dev/sda: ValueError: max() arg is an empty sequence
Traceback (most recent call last):
   File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 538, 
in _volume_attach
 device_type=self['device_type'], encryption=encryption)
   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
1451, in attach_volume
 disk_info['unit'] = self._get_scsi_controller_max_unit(guest) + 1
   File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
1134, in _get_scsi_controller_max_unit
 return max(ret)
 ValueError: max() arg is an empty sequence

Looking at the code

def _get_scsi_controller_max_unit(self, guest):
"""Returns the max disk unit used by scsi controller"""
xml = guest.get_xml_desc()
tree = etree.fromstring(xml)
addrs = "./devices/disk[@device='disk']/address[@type='drive']"

ret = []
for obj in tree.findall(addrs):
ret.append(int(obj.get('unit', 0)))
return max(ret)

As the instance has no existing devices in the scsi device bus, then the
ret array is empty and the max function just fails with the traceback
mentioned above.

** Affects: nova
 Importance: Undecided
 Assignee: Jose Castro Leon (jose-castro-leon)
 Status: In Progress

-- 
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/1801342

Title:
  Attach a volume with scsi bus on an instance boot from cdrom fails

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Following the upstream documentation to create images from an ISO
  (https://docs.openstack.org/nova/rocky/user/launch-instance-using-ISO-
  image.html) with an image from a vendor that required to have the disk
  attached on the scsi bus (/dev/sda) in order to install the system, it
  failed on attach volume step with the following traceback:

  
  Driver failed to attach volume 95b42945-5d2a-4fba-b970-1d3fafcfbecc at 
/dev/sda: ValueError: max() arg is an empty sequence
  Traceback (most recent call last):
 File "/usr/lib/python2.7/site-packages/nova/virt/block_device.py", line 
538, in _volume_attach
   device_type=self['device_type'], encryption=encryption)
 File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
1451, in attach_volume
   disk_info['unit'] = self._get_scsi_controller_max_unit(guest) + 1
 File "/usr/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 
1134, in _get_scsi_controller_max_unit
   return max(ret)
   ValueError: max() arg is an empty sequence

  Looking at the code

  def _get_scsi_controller_max_unit(self, guest):
  """Returns the max disk unit used by scsi controller"""
  xml = guest.get_xml_desc()
  tree = etree.fromstring(xml)
  addrs = "./devices/disk[@device='disk']/address[@type='drive']"

  ret = []
  for obj in tree.findall(addrs):
  ret.append(int(obj.get('unit', 0)))
  return max(ret)

  As the instance has no existing devices in the scsi device bus, then
  the ret array is empty and the max function just fails with the
  traceback mentioned above.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1801342/+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 1801326] [NEW] CRITICAL keystonemiddleware.auth_token

2018-11-02 Thread Taavi
Public bug reported:

Hi

I am facing issue with dashboard (flavors function) and also command line when 
creating new flavor.
Error (nova-api log):


2018-11-02 11:43:24.448 7149 INFO nova.osapi_compute.wsgi.server [-] 
194.24.226.85 "POST /v2.1/b09e14755fcb47f897c55681c8ef73ff/flavors HTTP/1.1" 
status: 503 len: 399 time: 0.0385082
2018-11-02 11:44:13.895 7143 WARNING keystonemiddleware.auth_token [-] Using 
the in-process token cache is deprecated as of the 4.2.0 release and may be 
removed in the 5.0.0 release or the 'O' development cycle. The in-process cache 
causes inconsistent results and high memory usage. When the feature is removed 
the auth_token middleware will not cache tokens by default which may result in 
performance issues. It is recommended to use  memcache for the auth_token token 
cache by setting the memcached_servers option.
2018-11-02 11:44:13.919 7143 ERROR keystonemiddleware.auth_token [-] Bad 
response code while validating token: 400
2018-11-02 11:44:13.929 7143 WARNING keystonemiddleware.auth_token [-] Identity 
response: {"error": {"message": "Invalid input for field 
'identity/password/user/password': None is not of type 'string'", "code": 400, 
"title": "Bad Request"}}
2018-11-02 11:44:13.930 7143 CRITICAL keystonemiddleware.auth_token [-] Unable 
to validate token: Failed to fetch token data from identity server
2018-11-02 11:44:13.932 7143 INFO nova.osapi_compute.wsgi.server [-] 
194.24.226.85 "POST /v2.1/b09e14755fcb47f897c55681c8ef73ff/flavors HTTP/1.1" 
status: 503 len: 399 time: 0.0378041


I have checked a lot of community posts and bugs raports but cannot get
rid of issue. Tried several methods. v2 api etc. Checked that username
and pw works for nova.

Configure paste: http://paste.openstack.org/show/733950/

** Affects: horizon
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1801326

Title:
  CRITICAL keystonemiddleware.auth_token

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Hi

  I am facing issue with dashboard (flavors function) and also command line 
when creating new flavor.
  Error (nova-api log):

  
  2018-11-02 11:43:24.448 7149 INFO nova.osapi_compute.wsgi.server [-] 
194.24.226.85 "POST /v2.1/b09e14755fcb47f897c55681c8ef73ff/flavors HTTP/1.1" 
status: 503 len: 399 time: 0.0385082
  2018-11-02 11:44:13.895 7143 WARNING keystonemiddleware.auth_token [-] Using 
the in-process token cache is deprecated as of the 4.2.0 release and may be 
removed in the 5.0.0 release or the 'O' development cycle. The in-process cache 
causes inconsistent results and high memory usage. When the feature is removed 
the auth_token middleware will not cache tokens by default which may result in 
performance issues. It is recommended to use  memcache for the auth_token token 
cache by setting the memcached_servers option.
  2018-11-02 11:44:13.919 7143 ERROR keystonemiddleware.auth_token [-] Bad 
response code while validating token: 400
  2018-11-02 11:44:13.929 7143 WARNING keystonemiddleware.auth_token [-] 
Identity response: {"error": {"message": "Invalid input for field 
'identity/password/user/password': None is not of type 'string'", "code": 400, 
"title": "Bad Request"}}
  2018-11-02 11:44:13.930 7143 CRITICAL keystonemiddleware.auth_token [-] 
Unable to validate token: Failed to fetch token data from identity server
  2018-11-02 11:44:13.932 7143 INFO nova.osapi_compute.wsgi.server [-] 
194.24.226.85 "POST /v2.1/b09e14755fcb47f897c55681c8ef73ff/flavors HTTP/1.1" 
status: 503 len: 399 time: 0.0378041
  

  I have checked a lot of community posts and bugs raports but cannot
  get rid of issue. Tried several methods. v2 api etc. Checked that
  username and pw works for nova.

  Configure paste: http://paste.openstack.org/show/733950/

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1801326/+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 1801319] [NEW] Severe risk in openstack horizon files from Acunetix test reports

2018-11-02 Thread Sowmya Divvi
Public bug reported:

We are using Openstack horizon of release Newton in our environment.
And we must pass all the security test, otherwise we will be disqualified.

But unfortunately when we are using Acunetix tool to scan,the system reported 
high risk vulnerabilities.
Please find the attachement for the effected files.

We have observed similar bug related to this 
issue(https://bugs.launchpad.net/horizon/+bug/1567673)
And the fix proposed in that bug was already present in our environment.

Any help will greatly support us in moving forward.

Thanks!
Sowmya

** Affects: horizon
 Importance: Undecided
 Status: New

** Attachment added: "Capture4.JPG"
   
https://bugs.launchpad.net/bugs/1801319/+attachment/5208218/+files/Capture4.JPG

-- 
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/1801319

Title:
  Severe risk in openstack horizon files from Acunetix test reports

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  We are using Openstack horizon of release Newton in our environment.
  And we must pass all the security test, otherwise we will be disqualified.

  But unfortunately when we are using Acunetix tool to scan,the system reported 
high risk vulnerabilities.
  Please find the attachement for the effected files.

  We have observed similar bug related to this 
issue(https://bugs.launchpad.net/horizon/+bug/1567673)
  And the fix proposed in that bug was already present in our environment.

  Any help will greatly support us in moving forward.

  Thanks!
  Sowmya

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1801319/+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 1801309] [NEW] Support configurable saml assertion property

2018-11-02 Thread wangxiyuan
Public bug reported:

Keystone as Identity Provider supports to generator saml assertion for
SP. The content in the saml assertion is hard code. The attribute
contains:
openstack_user,openstack_roles,openstack_project,openstack_project_domain,openstack_user_domain.

But in case the SP need more information from IdP Keystone,(or IdP want
to provide more information to SP) there is no way to extend the saml
information. Such as user's extra info, like email address, the
description of a role  and so on.

Or a case like: IdP Keystone mapping to two SP-SP1 and SP2, SP1 need
additional key1:value1, but SP2 need.key2:value2.

For those cases, Keystone as IdP should support configurable saml
assertion property

** Affects: keystone
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1801309

Title:
  Support configurable saml assertion property

Status in OpenStack Identity (keystone):
  New

Bug description:
  Keystone as Identity Provider supports to generator saml assertion for
  SP. The content in the saml assertion is hard code. The attribute
  contains:
  
openstack_user,openstack_roles,openstack_project,openstack_project_domain,openstack_user_domain.

  But in case the SP need more information from IdP Keystone,(or IdP
  want to provide more information to SP) there is no way to extend the
  saml information. Such as user's extra info, like email address, the
  description of a role  and so on.

  Or a case like: IdP Keystone mapping to two SP-SP1 and SP2, SP1 need
  additional key1:value1, but SP2 need.key2:value2.

  For those cases, Keystone as IdP should support configurable saml
  assertion property

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1801309/+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 1801306] [NEW] Race conditions in neutron_tempest_plugin/scenario/test_security_groups.py

2018-11-02 Thread Federico Ressi
Public bug reported:

I found a couple of race conditions in neutron-tempest-plugin affecting
recular CI build when executing test jobs with neutron-tempest-plugin
test suite. These race conditions are mostly because two test case
wrongly modify default security group causing random failures in other
scenario test cases or also failing themself.

1) Test case test_default_sec_grp_scenarios shouldn't change default security 
group rule at below lines:
https://github.com/openstack/neutron-tempest-plugin/blob/cf38b77328dbf94f1323f96f68aa77124a6f4a7b/neutron_tempest_plugin/scenario/test_security_groups.py#L109-L112
This could caouse other tests to fail. Modifying default resources should be 
forbidden. There is no difference between default security group and another 
group, therefore the test makes no sense at all. Tests that do some changes on 
resources should create its own target resources.

 
2) Test case test_protocol_number_rule list for security groups and takes the 
first one, then it changes it at line
https://github.com/openstack/neutron-tempest-plugin/blob/cf38b77328dbf94f1323f96f68aa77124a6f4a7b/neutron_tempest_plugin/scenario/test_security_groups.py#L147-L149
The problem here is that the first security group that is taken could be the 
default security group instead of the one created by the test. This would cause 
a failure in the same test and even worst in another test later.

** Affects: neutron
 Importance: Undecided
 Assignee: Federico Ressi (fressi-redhat)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Federico Ressi (fressi-redhat)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1801306

Title:
  Race conditions in
  neutron_tempest_plugin/scenario/test_security_groups.py

Status in neutron:
  In Progress

Bug description:
  I found a couple of race conditions in neutron-tempest-plugin
  affecting recular CI build when executing test jobs with neutron-
  tempest-plugin test suite. These race conditions are mostly because
  two test case wrongly modify default security group causing random
  failures in other scenario test cases or also failing themself.

  1) Test case test_default_sec_grp_scenarios shouldn't change default security 
group rule at below lines:
  
https://github.com/openstack/neutron-tempest-plugin/blob/cf38b77328dbf94f1323f96f68aa77124a6f4a7b/neutron_tempest_plugin/scenario/test_security_groups.py#L109-L112
  This could caouse other tests to fail. Modifying default resources should be 
forbidden. There is no difference between default security group and another 
group, therefore the test makes no sense at all. Tests that do some changes on 
resources should create its own target resources.

   
  2) Test case test_protocol_number_rule list for security groups and takes the 
first one, then it changes it at line
  
https://github.com/openstack/neutron-tempest-plugin/blob/cf38b77328dbf94f1323f96f68aa77124a6f4a7b/neutron_tempest_plugin/scenario/test_security_groups.py#L147-L149
  The problem here is that the first security group that is taken could be the 
default security group instead of the one created by the test. This would cause 
a failure in the same test and even worst in another test later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1801306/+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 1801303] [NEW] VM send DHCP request before openflow is created in br-int

2018-11-02 Thread harry huang
Public bug reported:

I am using OpenStack queens set up by OpenStack-Ansible.
When I create a VM, it seems to be started and sends DHCP request just before 
openflow is created.
This will result in a two minutes delay for VM to be accessible.
Test is carried out with Cirros image, as pasted below, VM can't get IP in the 
first round "sending discover".
Is there a way to add some delay when booting a VM ? Nova will not check 
openflow before starting the VM ?

info: initramfs: up at 0.64GROWROOT: CHANGED: partition=1 start=16065 old: 
size=64260 end=80325 new: size=2072385,end=2088450info: initramfs loading root 
from /dev/vda1
info: /etc/init.d/rc.sysinit: up at 0.70info: container: noneStarting logging: 
OKmodprobe: module virtio_blk not found in modules.dep
modprobe: module virtio_net not found in modules.dep
WARN: /etc/rc3.d/S10-load-modules failed
Initializing random number generator... done.
Starting acpid: OK
cirros-ds 'local' up at 0.76
no results found for mode=local. up 0.78. searched: nocloud configdrive ec2
Starting network...
udhcpc (v1.20.1) started
Sending discover...
Sending discover...
Sending select for 192.168.11.113...

** 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/1801303

Title:
  VM send DHCP request before openflow is created in br-int

Status in OpenStack Compute (nova):
  New

Bug description:
  I am using OpenStack queens set up by OpenStack-Ansible.
  When I create a VM, it seems to be started and sends DHCP request just before 
openflow is created.
  This will result in a two minutes delay for VM to be accessible.
  Test is carried out with Cirros image, as pasted below, VM can't get IP in 
the first round "sending discover".
  Is there a way to add some delay when booting a VM ? Nova will not check 
openflow before starting the VM ?

  info: initramfs: up at 0.64GROWROOT: CHANGED: partition=1 start=16065 old: 
size=64260 end=80325 new: size=2072385,end=2088450info: initramfs loading root 
from /dev/vda1
  info: /etc/init.d/rc.sysinit: up at 0.70info: container: noneStarting 
logging: OKmodprobe: module virtio_blk not found in modules.dep
  modprobe: module virtio_net not found in modules.dep
  WARN: /etc/rc3.d/S10-load-modules failed
  Initializing random number generator... done.
  Starting acpid: OK
  cirros-ds 'local' up at 0.76
  no results found for mode=local. up 0.78. searched: nocloud configdrive ec2
  Starting network...
  udhcpc (v1.20.1) started
  Sending discover...
  Sending discover...
  Sending select for 192.168.11.113...

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1801303/+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 1783278] Re: https url for image import

2018-11-02 Thread Abhishek Kekane
** 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/1783278

Title:
  https url for image import

Status in Glance:
  Invalid

Bug description:
  task API in Glance is failing while using https URL for import location 
because of this: 
  
https://github.com/openstack/glance/blob/master/glance/common/scripts/utils.py#L141
  while creating url connection, there is no way remote certificates can be 
used or ignored.

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1783278/+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