date:20170512

[Yahoo-eng-team] [Bug 1668226] Re: (HTTP 500)

2017-05-12 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/1668226

Title:
   (HTTP 500)

Status in OpenStack Compute (nova):
  Expired

Bug description:
  Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ 
and attach the Nova API log if possible.
   (HTTP 500)

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1668226/+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 1672338] Re: Defect: DVR Port deletion error

2017-05-12 Thread Launchpad Bug Tracker

[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/1672338

Title:
  Defect: DVR Port deletion error

Status in neutron:
  Expired

Bug description:
  Kolla stable/ocata on ubuntu xenial

  Neutron log: 
  2017-03-13 04:40:12.948 23 INFO neutron.db.db_base_plugin_v2 
[req-7f8f0445-f5b9-4bf5-b8e0-f298954a6a95 e0dc60aa4ad342f6807613e4d6203baa 
3f243f2f6d2547128217c34f850315f6 - - -] Found port 
(c1c68e69-ff8b-47c4-82bb-a63c1bc5a69e, 10.0.0.11) having IP allocation on 
subnet 0338d064-bab6-4895-91f4-601ee442a7d3, cannot delete
  2017-03-13 04:40:12.949 23 INFO neutron.api.v2.resource 
[req-7f8f0445-f5b9-4bf5-b8e0-f298954a6a95 e0dc60aa4ad342f6807613e4d6203baa 
3f243f2f6d2547128217c34f850315f6 - - -] delete failed (client error): There was 
a conflict when trying to complete your request.

  This is from the following heat template:
  https://hastebin.com/yowijofanu.http

  100% reproducible via rally (20x runs). It's always the
  network:router_centralized_snat interface that fails deletion.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1672338/+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 1664534] Re: [RFE] Auto allocated topology with no SNAT

2017-05-12 Thread Armando Migliaccio

We should probably favor effort [1] rather than customize the existing
logic. If [1] gets implemented, then possibilities are endless.

[1] https://bugs.launchpad.net/neutron/+bug/1690438

** Changed in: neutron
   Importance: Undecided => Wishlist

** Changed in: neutron
   Status: In Progress => Won't Fix

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

Title:
  [RFE] Auto allocated topology with no SNAT

Status in neutron:
  Won't Fix

Bug description:
  Today the neutron auto-allocated-topology (aka "get me a network") 
plugin/service allocates a router using the default enable_snat value for 
routers (True); so the resulting topology always has SNAT enabled. Some 
deployments would benefit from the ability to provision auto-allocated 
topologies that disable SNAT routing directly into the address space of the 
external network.
   
  One such way to support this ability would be to provide a simple 
configuration option such as `auto_topology_enable_snat` that's used by the 
service plugin when provisioning the router (for `enable_snat`). This would 
allow deployers the ability to configure the default SNAT behavior for 
auto-allocated topologies.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1664534/+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 1690439] [NEW] [RFE] Deal with NetworkAmbiguous error

2017-05-12 Thread Armando Migliaccio

Public bug reported:

Today if a tenant has more than a network visible to it and during boot
it does not specify any network, the famous NetworkAmbiguous is
returned. It would be nice if there was a way for Nova and Neutron to
fall back on the adoption of a tenant-level 'default' network.

[1] https://etherpad.openstack.org/p/pike-neutron-gman

** Affects: neutron
 Importance: Wishlist
 Status: Confirmed

** Affects: nova
 Importance: Wishlist
 Status: Confirmed


** Tags: auto-allocated-topology rfe

** Also affects: nova
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: New => Confirmed

** Changed in: neutron
   Importance: Undecided => Wishlist

** Changed in: nova
   Status: New => Confirmed

** Changed in: nova
   Importance: Undecided => Wishlist

** Tags added: auto-allocated-topology 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/1690439

Title:
  [RFE] Deal with NetworkAmbiguous error

Status in neutron:
  Confirmed
Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  Today if a tenant has more than a network visible to it and during
  boot it does not specify any network, the famous NetworkAmbiguous is
  returned. It would be nice if there was a way for Nova and Neutron to
  fall back on the adoption of a tenant-level 'default' network.

  [1] https://etherpad.openstack.org/p/pike-neutron-gman

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1690439/+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 1690438] [NEW] [RFE] make get-me-a-network work with any network topology

2017-05-12 Thread Armando Migliaccio

Public bug reported:

Today Get-me-a-network work in such a way that neutron provisions a
rather specific network topology for tenant connectivity. It would be
nice if Neutron were able to support any network topology (e.g. plain
provider vlans).

** Affects: neutron
 Importance: Wishlist
 Status: Confirmed


** Tags: auto-allocated-topology rfe

** Changed in: neutron
   Status: New => Confirmed

** Changed in: neutron
   Importance: Undecided => Wishlist

** Tags added: 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/1690438

Title:
  [RFE] make get-me-a-network work with any network topology

Status in neutron:
  Confirmed

Bug description:
  Today Get-me-a-network work in such a way that neutron provisions a
  rather specific network topology for tenant connectivity. It would be
  nice if Neutron were able to support any network topology (e.g. plain
  provider vlans).

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1690438/+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 1042049] Re: auto-associate floating ips

2017-05-12 Thread Armando Migliaccio

** Changed in: neutron
   Status: Invalid => Confirmed

** Summary changed:

- auto-associate floating ips 
+ [RFE] auto-associate floating ips

** Tags added: rfe

** Description changed:

  nova has a flag that indicates that each VM should automatically have a
  floating IP assigned and associated at the time of VM creation.
  
- In quantum, the equivalent would be at port creation time.  In Nova this
- is a system wide flag, but in quantum this woud likely be an option that
- is enabled per-network (i.e., for a particular network, it is
+ In neutron, the equivalent would be at port creation time.  In Nova this
+ is a system wide flag, but in neutron this would likely be an option
+ that is enabled per-network (i.e., for a particular network, it is
  automatically assigned a floating IP from external network X).  this
  would map to a amazon VPC use case as well.

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

Title:
  [RFE] auto-associate floating ips

Status in neutron:
  Confirmed

Bug description:
  nova has a flag that indicates that each VM should automatically have
  a floating IP assigned and associated at the time of VM creation.

  In neutron, the equivalent would be at port creation time.  In Nova
  this is a system wide flag, but in neutron this would likely be an
  option that is enabled per-network (i.e., for a particular network, it
  is automatically assigned a floating IP from external network X).
  this would map to a amazon VPC use case as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1042049/+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 1690433] [NEW] get me a network

2017-05-12 Thread Armando Migliaccio

Public bug reported:

It would be nice to expose get-me-a-network via horizon. Right now it
only works with the nova CLI. This came up for discussion during Boston
summit [2]

[1] https://blueprints.launchpad.net/nova/+spec/get-me-a-network
[2] https://etherpad.openstack.org/p/pike-neutron-gman

** Affects: horizon
 Importance: Undecided
 Status: New

** Description changed:

  It would be nice to expose get-me-a-network via horizon. Right now it
- only works with the nova CLI.
+ only works with the nova CLI. This came up for discussion during Boston
+ summit [2]
  
  [1] https://blueprints.launchpad.net/nova/+spec/get-me-a-network
+ [2] https://etherpad.openstack.org/p/pike-neutron-gman

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

Title:
  get me a network

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  It would be nice to expose get-me-a-network via horizon. Right now it
  only works with the nova CLI. This came up for discussion during
  Boston summit [2]

  [1] https://blueprints.launchpad.net/nova/+spec/get-me-a-network
  [2] https://etherpad.openstack.org/p/pike-neutron-gman

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1690433/+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 1690425] [NEW] [RFE] neutron cells aware

2017-05-12 Thread Armando Migliaccio

Public bug reported:

Cells is an option to scale OpenStack deployments. It would be nice to
make Neutron able to work with the individual cell DB/MQ clusters rather
than relying (as it does it to this day) on a global DB/MQ cluster. This
will help with scaling traffic involving messages as well as fault
tolerance.

[1] https://etherpad.openstack.org/p/pike-neutron-multi-site

** Affects: neutron
 Importance: Wishlist
 Status: Confirmed


** Tags: rfe

** Changed in: neutron
   Status: New => Confirmed

** Changed in: neutron
   Importance: Undecided => Wishlist

** Tags added: 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/1690425

Title:
  [RFE] neutron cells aware

Status in neutron:
  Confirmed

Bug description:
  Cells is an option to scale OpenStack deployments. It would be nice to
  make Neutron able to work with the individual cell DB/MQ clusters
  rather than relying (as it does it to this day) on a global DB/MQ
  cluster. This will help with scaling traffic involving messages as
  well as fault tolerance.

  [1] https://etherpad.openstack.org/p/pike-neutron-multi-site

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1690425/+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 1690275] Re: Create port will allocate reserved MAC address if no MAC provide

2017-05-12 Thread Armando Migliaccio

The base prefix is a config option (base_mac) and it currently defaults
to fa:16:3e:00:00:00. Make sure you choose what you like.

** Changed in: neutron
   Status: New => Invalid

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

Title:
  Create port will allocate reserved MAC address if no MAC provide

Status in neutron:
  Invalid

Bug description:
  Currently, if create port with no MAC specify, it will automatic allocate an 
MAC address. But this will allocate an RESERVED MAC address(eg, mac  
01:80:c2:00:00:01 reserved for IEEE Pause frame), and if packet with this 
destination MAC address, it will process by other networking equipment.
  So when allocate an MAC address, It should be check if Mac has been reserved.

  Currently, I found those MAC address(From OVS ovs-vswitchd.conf man
  pages) has been reserved for  special purpose.

    01:80:c2:00:00:00
   IEEE 802.1D Spanning Tree Protocol (STP).

    01:80:c2:00:00:01
   IEEE Pause frame.

    01:80:c2:00:00:0x
   Other reserved protocols.

    00:e0:2b:00:00:00
   Extreme Discovery Protocol (EDP).

    00:e0:2b:00:00:04 and 00:e0:2b:00:00:06
   Ethernet Automatic Protection Switching (EAPS).

    01:00:0c:cc:cc:cc
   Cisco Discovery Protocol (CDP),  VLAN  Trunking  Protocol
   (VTP),  Dynamic Trunking Protocol (DTP), Port Aggregation
   Protocol (PAgP), and others.

    01:00:0c:cc:cc:cd
   Cisco Shared Spanning Tree Protocol PVSTP+.

    01:00:0c:cd:cd:cd
   Cisco STP Uplink Fast.

    01:00:0c:00:00:00
   Cisco Inter Switch Link.

    01:00:0c:cc:cc:cx
   Cisco CFM.

  Start with 01(Multicast mac) we may don't care, but
  00:e0:2b:00:00:00(EDP) and 00:e0:2b:00:00:04 and 00:e0:2b:00:00:06
  should be check.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1690275/+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 1690387] [NEW] instance delete fails with: 403 Forbidden - CSRF verification failed

2017-05-12 Thread Andrew Lenards

Public bug reported:

Behavior is that an instance deletion from /project/instances is
failing.

The error returned is: 403 Forbidden - CSRF verification failed

This was noted in #openstack-horizon by zigo on 2017-05-12.

OpenStack Release was stated to be Newton, on Debian.

Below are the steps to reproduce from the original bug report.

The information is pulled from (replicated) Debian bugs:

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862387



Instance delete fails when I access:

  http://os-ctrl/horizon/project/instances/

and select "Delete Instance" from the list of actions with
the error:

  Forbidden (403)
  CSRF verification failed. Request aborted.

  Help
  Reason given for failure:
CSRF token missing or incorrect.

while I see the csrftoken being sent in the request:

  csrftoken: tMhcr99nId798AXdULs8dUjuEHemALp0ONGCa4Y8ahpIuckFFqxexCuD13uR5ATy

Apache error.log just reports the same thing:

  Forbidden (CSRF token missing or incorrect.):
/horizon/project/instances/, referer: http://os-
ctrl/horizon/project/instances/

Deleting the instance works if I enter the instance first:

  http://os-ctrl/horizon/project/instances/6a167f8a-f0c6-440a-
a1c1-c0063058d5c4/

and than select "Delete Instance" from the list of actions.

The same issue exists when deleting volumes from:

  http://os-ctrl/horizon/project/volumes/


-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64
 (x86_64)

Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages openstack-dashboard depends on:
ii  adduser3.115
ii  libjs-jquery   3.1.1-2
ii  libjs-jquery-cookie11-3
ii  python-django-horizon  3:10.0.1-1
pn  python:any 

openstack-dashboard recommends no packages.

Versions of packages openstack-dashboard suggests:
ii  memcached   1.4.33-1
ii  openstack-dashboard-apache  3:10.0.1-1

-- no debconf information

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

Title:
  instance delete fails with: 403 Forbidden - CSRF verification failed

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Behavior is that an instance deletion from /project/instances is
  failing.

  The error returned is: 403 Forbidden - CSRF verification failed

  This was noted in #openstack-horizon by zigo on 2017-05-12.

  OpenStack Release was stated to be Newton, on Debian.

  Below are the steps to reproduce from the original bug report.

  The information is pulled from (replicated) Debian bugs:

  - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=862387

  

  Instance delete fails when I access:

http://os-ctrl/horizon/project/instances/

  and select "Delete Instance" from the list of actions with
  the error:

Forbidden (403)
CSRF verification failed. Request aborted.

Help
Reason given for failure:
  CSRF token missing or incorrect.

  while I see the csrftoken being sent in the request:

csrftoken: tMhcr99nId798AXdULs8dUjuEHemALp0ONGCa4Y8ahpIuckFFqxexCuD13uR5ATy
  
  Apache error.log just reports the same thing:

Forbidden (CSRF token missing or incorrect.):
  /horizon/project/instances/, referer: http://os-
  ctrl/horizon/project/instances/

  Deleting the instance works if I enter the instance first:

http://os-ctrl/horizon/project/instances/6a167f8a-f0c6-440a-
  a1c1-c0063058d5c4/

  and than select "Delete Instance" from the list of actions.

  The same issue exists when deleting volumes from:

http://os-ctrl/horizon/project/volumes/

  
  -- System Information:
  Debian Release: 9.0
APT prefers testing
APT policy: (500, 'testing')
  Architecture: amd64
   (x86_64)

  Kernel: Linux 4.9.0-2-amd64 (SMP w/2 CPU cores)
  Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
  Shell: /bin/sh linked to /bin/dash
  Init: systemd (via /run/systemd/system)

  Versions of packages openstack-dashboard depends on:
  ii  adduser3.115
  ii  libjs-jquery   3.1.1-2
  ii  libjs-jquery-cookie11-3
  ii  python-django-horizon  3:10.0.1-1
  pn  python:any 

  openstack-dashboard recommends no packages.

  Versions of packages openstack-dashboard suggests:
  ii  memcached   1.4.33-1
  ii  openstack-dashboard-apache  3:10.0.1-1

  -- no debconf information

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

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

2017-05-12 Thread Kleber Sacilotto de Souza

** Changed in: linux (Ubuntu Yakkety)
   Status: New => Fix Released

** Changed in: linux (Ubuntu Zesty)
   Status: New => Fix Released

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

Title:
  attempts to rename vlans / vlans have addr_assign_type of 0 on kernel
  4.4

Status in cloud-init:
  Confirmed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  In Progress
Status in cloud-init source package in Yakkety:
  Fix Committed
Status in linux source package in Yakkety:
  Fix Released
Status in cloud-init source package in Zesty:
  Fix Committed
Status in linux source package in Zesty:
  Fix Released

Bug description:
  [Impact]

   * When vlan interfaces are created, their mac address is copied from
  the underlying interface, but it is not marked by kernel as stolen.

   * When underlying interface MAC address is changed, it does not
  propagate to the vlan interfaces.

  [Test Case]

   * Create vlan interface, check the addr_assign_type sysfs attribute,
  it should be 2, not 0.

   * Update the base interface mac address, the mac address of the vlan
  interface should change too.

   * cloud-init test case

  
  
  wget 
https://git.launchpad.net/~smoser/cloud-init/+git/sru-info/plain/bin/get-proposed-cloudimg;
  chmod 755 get-proposed-cloudimg;

  for release in xenial yakkety zesty; do
./get-proposed-cloudimg $release;
MODE=vlan ./btest-launch.sh $release-server-cloudimg-amd64-proposed.img 
;
# ubuntu/passw0rd
python3 -c 'from cloudinit.net import get_interfaces_by_mac; 
print(get_interfaces_by_mac())'; # results in no runtime error and doesn't 
report vlan interface name
  done
   


  
  [Regression Potential]

   * Userspace may rely on non-propagating MAC addresses, and the fact
  that vlan mac address type is wrongly stated as non-stolen; however
  this behaviour will be consistent with 4.7+ kernels.

  [Other Info]

   * Please cherrypick 308453aa9156a3b8ee382c0949befb507a32b0c1 into
  v4.4 kernels

  commit 308453aa9156a3b8ee382c0949befb507a32b0c1
  Author: Mike Manning 
  Date:   Fri May 27 17:45:07 2016 +0100

  vlan: Propagate MAC address to VLANs

  The MAC address of the physical interface is only copied to the VLAN
  when it is first created, resulting in an inconsistency after MAC
  address changes of only newly created VLANs having an up-to-date MAC.

  The VLANs should continue inheriting the MAC address of the physical
  interface until the VLAN MAC address is explicitly set to any value.
  This allows IPv6 EUI64 addresses for the VLAN to reflect any changes
  to the MAC of the physical interface and thus for DAD to behave as
  expected.

  Signed-off-by: Mike Manning 
  Signed-off-by: David S. Miller 

   * Original bug report

  When attempting to verify sru for bug 1669860, I found that vlans
  are not properly filtered out by 'get_interfaces_by_mac'.  That means
  that the bug is still present with vlans.

  The reason for this is that /sys/class/net//addr_assign_type
  shows '0' for a vlan on 4.4, but (correctly) shows '2' on 4.8.
  See https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net
  for doc on addr_assign_type.

  Related bugs:
   * bug 1669860: cloud-init attempts to rename bonds

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1682871/+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 1679703] Re: Unable to boot instance with VF( direct-port ) because the PF is not online

2017-05-12 Thread Rodolfo Alonso

** Also affects: nova
   Importance: Undecided
   Status: New

** Changed in: neutron
   Status: New => Invalid

** Changed in: nova
 Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez)

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

Title:
  Unable to boot instance with VF( direct-port ) because the PF is not
  online

Status in neutron:
  Invalid
Status in OpenStack Compute (nova):
  New

Bug description:
  Description of problem:

  Booted VM with Direct-physical port (The entire PF is associated to the 
instance).
  When I deleted the instance I expected that PF will be available and online.
  Actually when I am trying to boot instance with direct port (VF)
  I get this error message :

  VM in error state- 
  fault | {"message": "Exceeded maximum number of retries. Exceeded max 
scheduling attempts 3 for instance 102fde1b-22d3-4b05-8246-0f1af520455a. Last 
exception: internal error: Unable to configure VF 4 of PF 'p1p1' because the PF 
is not online. Please change host network config", "code": 500, "details": "  
File \"/usr/lib/python2.7/site-packages/nova/conductor/manager.py\", line 524, 
in build_instances | filter_properties, instances[0].uuid)  

  [root@compute-0 ~]# ifconfig |grep p1p1 --->PF is not online
  it's impossible to create an instance with a direct port (VF)

  
  version: 
  Ocata 
  How reproducible:
  Always

  Steps to Reproduce:
  1. Deploy SRIOV setup with PF support 
  2. boot instance with Direct-physical port
  3. Delete VM that is associated to PF
  4. boot instance with Direct port (VF)

  Expected results:
  VM with direct port should be booted. PF should be released

  Additional info:
  Workaround - systemctl restart network

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1679703/+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 1639239] Re: ValueError for Invalid InitiatorConnector in s390

2017-05-12 Thread Frank Heimes

** Changed in: ubuntu-z-systems
   Status: Confirmed => Fix Released

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

Title:
  ValueError for Invalid InitiatorConnector in s390

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive newton series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Released
Status in os-brick:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in nova package in Ubuntu:
  Fix Released
Status in python-os-brick package in Ubuntu:
  Fix Released
Status in nova source package in Yakkety:
  Confirmed
Status in python-os-brick source package in Yakkety:
  Confirmed
Status in nova source package in Zesty:
  Fix Released
Status in python-os-brick source package in Zesty:
  Fix Released

Bug description:
  Description
  ===
  Calling the InitiatorConnector factory results in a ValueError for 
unsupported protocols, which goes unhandled and may crash a calling service.

  Steps to reproduce
  ==
  - clone devstack
  - make stack

  Expected result
  ===
  The nova compute service should run.

  Actual result
  =
  A ValueError is thrown, which, in the case of the nova libvirt driver, is not 
handled appropriately. The compute service crashes.

  Environment
  ===
  os|distro=kvmibm1
  os|vendor=kvmibm
  os|release=1.1.3-beta4.3
  git|cinder|master[f6ab36d]
  git|devstack|master[928b3cd]
  git|nova|master[56138aa]
  pip|os-brick|1.7.0

  Logs & Configs
  ==
  [...]
  2016-11-03 17:56:57.204 46141 INFO nova.virt.driver 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Loading compute driver 
'libvirt.LibvirtDriver'
  2016-11-03 17:56:57.442 46141 DEBUG os_brick.initiator.connector 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x 
factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261
  2016-11-03 17:56:57.444 46141 DEBUG os_brick.initiator.connector 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x 
factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261
  2016-11-03 17:56:57.445 46141 DEBUG os_brick.initiator.connector 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISER on s390x 
factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261
  2016-11-03 17:56:57.445 46141 CRITICAL nova 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] ValueError: Invalid 
InitiatorConnector protocol specified ISER
  2016-11-03 17:56:57.445 46141 ERROR nova Traceback (most recent call last):
  2016-11-03 17:56:57.445 46141 ERROR nova   File "/usr/bin/nova-compute", line 
10, in 
  2016-11-03 17:56:57.445 46141 ERROR nova sys.exit(main())
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/cmd/compute.py", line 56, in main
  2016-11-03 17:56:57.445 46141 ERROR nova topic=CONF.compute_topic)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/service.py", line 216, in create
  2016-11-03 17:56:57.445 46141 ERROR nova 
periodic_interval_max=periodic_interval_max)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/service.py", line 91, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova self.manager = 
manager_class(host=self.host, *args, **kwargs)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/compute/manager.py", line 537, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova self.driver = 
driver.load_compute_driver(self.virtapi, compute_driver)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/driver.py", line 1625, in load_compute_driver
  2016-11-03 17:56:57.445 46141 ERROR nova virtapi)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44, in 
import_object
  2016-11-03 17:56:57.445 46141 ERROR nova return 
import_class(import_str)(*args, **kwargs)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 356, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova self._get_volume_drivers(), 
self._host)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/driver.py", line 44, in driver_dict_from_config
  2016-11-03 17:56:57.445 46141 ERROR nova driver_registry[driver_type] = 
driver_class(*args, **kwargs)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/libvirt/volume/iser.py", line 34, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova transport=self._get_transport())
  2016-11-03 17:56:57.445 46141 ERROR nova   File

[Yahoo-eng-team] [Bug 1639239] Re: ValueError for Invalid InitiatorConnector in s390

2017-05-12 Thread Arne Recknagel

** Changed in: nova/newton
   Status: In Progress => Confirmed

** Changed in: nova/newton
   Status: Confirmed => Fix Released

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

Title:
  ValueError for Invalid InitiatorConnector in s390

Status in Ubuntu Cloud Archive:
  Fix Released
Status in Ubuntu Cloud Archive newton series:
  Fix Committed
Status in Ubuntu Cloud Archive ocata series:
  Fix Released
Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) newton series:
  Fix Released
Status in os-brick:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Confirmed
Status in nova package in Ubuntu:
  Fix Released
Status in python-os-brick package in Ubuntu:
  Fix Released
Status in nova source package in Yakkety:
  Confirmed
Status in python-os-brick source package in Yakkety:
  Confirmed
Status in nova source package in Zesty:
  Fix Released
Status in python-os-brick source package in Zesty:
  Fix Released

Bug description:
  Description
  ===
  Calling the InitiatorConnector factory results in a ValueError for 
unsupported protocols, which goes unhandled and may crash a calling service.

  Steps to reproduce
  ==
  - clone devstack
  - make stack

  Expected result
  ===
  The nova compute service should run.

  Actual result
  =
  A ValueError is thrown, which, in the case of the nova libvirt driver, is not 
handled appropriately. The compute service crashes.

  Environment
  ===
  os|distro=kvmibm1
  os|vendor=kvmibm
  os|release=1.1.3-beta4.3
  git|cinder|master[f6ab36d]
  git|devstack|master[928b3cd]
  git|nova|master[56138aa]
  pip|os-brick|1.7.0

  Logs & Configs
  ==
  [...]
  2016-11-03 17:56:57.204 46141 INFO nova.virt.driver 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Loading compute driver 
'libvirt.LibvirtDriver'
  2016-11-03 17:56:57.442 46141 DEBUG os_brick.initiator.connector 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x 
factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261
  2016-11-03 17:56:57.444 46141 DEBUG os_brick.initiator.connector 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISCSI on s390x 
factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261
  2016-11-03 17:56:57.445 46141 DEBUG os_brick.initiator.connector 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] Factory for ISER on s390x 
factory /usr/lib/python2.7/site-packages/os_brick/initiator/connector.py:261
  2016-11-03 17:56:57.445 46141 CRITICAL nova 
[req-fb30a5af-e87c-4ee0-903c-a5aa7d3ad5e3 - -] ValueError: Invalid 
InitiatorConnector protocol specified ISER
  2016-11-03 17:56:57.445 46141 ERROR nova Traceback (most recent call last):
  2016-11-03 17:56:57.445 46141 ERROR nova   File "/usr/bin/nova-compute", line 
10, in 
  2016-11-03 17:56:57.445 46141 ERROR nova sys.exit(main())
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/cmd/compute.py", line 56, in main
  2016-11-03 17:56:57.445 46141 ERROR nova topic=CONF.compute_topic)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/service.py", line 216, in create
  2016-11-03 17:56:57.445 46141 ERROR nova 
periodic_interval_max=periodic_interval_max)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/service.py", line 91, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova self.manager = 
manager_class(host=self.host, *args, **kwargs)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/compute/manager.py", line 537, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova self.driver = 
driver.load_compute_driver(self.virtapi, compute_driver)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/driver.py", line 1625, in load_compute_driver
  2016-11-03 17:56:57.445 46141 ERROR nova virtapi)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/usr/lib/python2.7/site-packages/oslo_utils/importutils.py", line 44, in 
import_object
  2016-11-03 17:56:57.445 46141 ERROR nova return 
import_class(import_str)(*args, **kwargs)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/libvirt/driver.py", line 356, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova self._get_volume_drivers(), 
self._host)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/driver.py", line 44, in driver_dict_from_config
  2016-11-03 17:56:57.445 46141 ERROR nova driver_registry[driver_type] = 
driver_class(*args, **kwargs)
  2016-11-03 17:56:57.445 46141 ERROR nova   File 
"/opt/stack/nova/nova/virt/libvirt/volume/iser.py", line 34, in __init__
  2016-11-03 17:56:57.445 46141 ERROR nova transport=self._get_transport())
  2016-11-03 17:56:57.445 46141 ERROR nova   File

[Yahoo-eng-team] [Bug 1690311] [NEW] Raise particular exception when cannot found instance in driver layer

2017-05-12 Thread Zhenyu Zheng

Public bug reported:

TBA

** Affects: nova
 Importance: Undecided
 Assignee: Zhenyu Zheng (zhengzhenyu)
 Status: New

** Changed in: nova
 Assignee: (unassigned) => Zhenyu Zheng (zhengzhenyu)

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

Title:
  Raise particular exception when cannot found instance in driver layer

Status in OpenStack Compute (nova):
  New

Bug description:
  TBA

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1690311/+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 1668226] Re: (HTTP 500)

[Yahoo-eng-team] [Bug 1672338] Re: Defect: DVR Port deletion error

[Yahoo-eng-team] [Bug 1664534] Re: [RFE] Auto allocated topology with no SNAT

[Yahoo-eng-team] [Bug 1690439] [NEW] [RFE] Deal with NetworkAmbiguous error

[Yahoo-eng-team] [Bug 1690438] [NEW] [RFE] make get-me-a-network work with any network topology

[Yahoo-eng-team] [Bug 1042049] Re: auto-associate floating ips

[Yahoo-eng-team] [Bug 1690433] [NEW] get me a network

[Yahoo-eng-team] [Bug 1690425] [NEW] [RFE] neutron cells aware

[Yahoo-eng-team] [Bug 1690275] Re: Create port will allocate reserved MAC address if no MAC provide

[Yahoo-eng-team] [Bug 1690387] [NEW] instance delete fails with: 403 Forbidden - CSRF verification failed

[Yahoo-eng-team] [Bug 1682871] Re: attempts to rename vlans / vlans have addr_assign_type of 0 on kernel 4.4

[Yahoo-eng-team] [Bug 1679703] Re: Unable to boot instance with VF( direct-port ) because the PF is not online

[Yahoo-eng-team] [Bug 1639239] Re: ValueError for Invalid InitiatorConnector in s390

[Yahoo-eng-team] [Bug 1639239] Re: ValueError for Invalid InitiatorConnector in s390

[Yahoo-eng-team] [Bug 1690311] [NEW] Raise particular exception when cannot found instance in driver layer

15 matches

Site Navigation

Mail list logo

Footer information