[Yahoo-eng-team] [Bug 1750777] Re: openvswitch agent eating CPU, time spent in ip_conntrack.py

[Launchpad Bug Tracker]

This bug was fixed in the package neutron - 2:12.0.1-0ubuntu1.1

---
neutron (2:12.0.1-0ubuntu1.1) bionic; urgency=medium

  * d/p/remove-race-and-simplify-conntrack-state-management.patch:
Cherry-picked from upstream stable/queens branch to prevent
ovs-agent from eating up CPU (LP: #1750777).
  * d/gbp.conf: Create stable/queens branch.

 -- Corey Bryant   Wed, 02 May 2018 15:00:58
-0400

** Changed in: neutron (Ubuntu Bionic)
   Status: Fix Committed => 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/1750777

Title:
  openvswitch agent eating CPU, time spent in ip_conntrack.py

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive queens series:
  Fix Committed
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Bionic:
  Fix Released
Status in neutron source package in Cosmic:
  Fix Released

Bug description:
  We just ran into a case where the openvswitch agent (local dev
  destack, current master branch) eats 100% of CPU time.

  Pyflame profiling show the time being largely spent in
  neutron.agent.linux.ip_conntrack, line 95.

  
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_conntrack.py#L95

  The code around this line is:

  while True:
  pool.spawn_n(self._process_queue)

  The documentation of eventlet.spawn_n says: "The same as spawn(), but
  it’s not possible to know how the function terminated (i.e. no return
  value or exceptions). This makes execution faster. See spawn_n for
  more details."  I suspect that GreenPool.spawn_n may behave similarly.

  It seems plausible that spawn_n is returning very quickly because of
  some error, and then all time is quickly spent in a short circuited
  while loop.

  SRU details for Ubuntu:
  ---
  [Impact]
  We're cherry-picking a single bug-fix patch here from the upstream 
stable/queens branch as there is not currently an upstream stable point release 
available that includes this fix. We'd like to make sure all of our supported 
customers have access to this fix as there is a significant performance hit 
without it.

  [Test Case]
  The following SRU process was followed:
  https://wiki.ubuntu.com/OpenStackUpdates

  In order to avoid regression of existing consumers, the OpenStack team
  will run their continuous integration test against the packages that
  are in -proposed. A successful run of all available tests will be
  required before the proposed packages can be let into -updates.

  The OpenStack team will be in charge of attaching the output summary
  of the executed tests. The OpenStack team members will not mark
  ‘verification-done’ until this has happened.

  [Regression Potential]
  In order to mitigate the regression potential, the results of the
  aforementioned tests are attached to this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1750777/+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 1770622] Re: QoS bandwidth limit rule's max_kbps parameter should be mandatory

[Slawek Kaplonski]

I checked it once again and it looks that max_kbps attribute don't have
default value and is mandatory. So bug is only in OSC and patch for that
was already proposed.

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

Title:
  QoS bandwidth limit rule's max_kbps parameter should be mandatory

Status in neutron:
  Invalid

Bug description:
  I think that creation of QoS bandwidth limit rule without max_kbps value 
provided doesn't makes sense and will not work in any predictable way.
  This parameter should be mandatory during creation of such rule type.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1770622/+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 1596611] Re: [RFE] Create L3 floating IPs with qos (rate limit)

[LIU Yulong]

** Changed in: neutron
   Status: Fix Committed => 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/1596611

Title:
  [RFE] Create L3 floating IPs with qos (rate limit)

Status in neutron:
  Fix Released

Bug description:
  For a certain tenant, there is not a implementation used for limiting
  the egrees bandwidth of floating ips.

  Use cases
  =
  In certain commercial scenery with neutron, such as some VNF cases using TECS 
of ZTE, the max egrees bandwidth of a floating ip should be limited because of 
its expensive cost and its flexibility with different fixed ips at different 
envirenments. As for the bandwidth limiting for one floating ip, it should be 
the implementation by means of the parameter '--max-kbps' in 
'--qos-policy-rule'. But for now, it is not allowed to executing 
'floating-ip-create' with '--qos-policy'.

  Now like below:
  
  [root@localhost devstack]# neutron floatingip-create public  --qos-policy 
qos-policy
  Unrecognized attribute(s) 'qos_policy'
  Neutron server returns request_ids: 
['req-b7ff870c-3f43-424b-a694-703726090d69']

  I think it should be:
  =
  When a floating ip, created with a 'qos-policy', is associated with a fixed 
ip, the 'qos-policy' is applied on the fixed port accordingly. This 
implementation will bring more convenience when tenant destroy the fixed port 
and deploy another re-associating.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1596611/+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 1770638] Re: While updating the address-scope with optional argument - -share=true, then user unable to update as - -share=false.

[Gary Kotton]

This is currently by design -
http://git.openstack.org/cgit/openstack/neutron/tree/neutron/db/address_scope_db.py#n88


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

Title:
  While updating the address-scope with optional argument - -share=true,
  then user unable to update as - -share=false.

Status in neutron:
  Invalid

Bug description:
  Problem:
  While updating the address-scope with optional argument - -share=true, then 
user unable to update as - -share=false.

  Steps to reproduce:

  1) Update the address scope using the command
  neutron address-scope-update --shared true 
0055ebc1-771f-4f98-9775-bafd8f563061
  2) Then try to update the address scope again 
  neutron address-scope-update --shared false 
0055ebc1-771f-4f98-9775-bafd8f563061
  output:
  Unable to update address scope 0055ebc1-771f-4f98-9775-bafd8f563061 : Shared 
address scope can't be unshared.
  Neutron server returns request_ids: 
['req-d98ce885-7e18-4b1b-9d7b-2c7538f80156']

  
  So, it should update the address scope as false again.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1770638/+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 1771088] [NEW] Admin user is not able to update the shared access for a network.

[kavitha h r]

Public bug reported:

Admin user is not able to update the shared access for a network. 
Steps to reproduce:
a) Create a network test from demo user.
b) As an admin user, create a subnet for that network.
c) Now, make the network shared using command “neutron net-update test –shared”.
d) Now, try to make the shared as false for the same network by using the 
command “neutron net-update test –shared false”. 
Here it throws an error saying "unable to reconfigure sharing settings for 
network test. Multiple tenants are using it."

** Affects: neutron
 Importance: Undecided
 Status: New

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

Title:
  Admin user is not able to update the shared access for a network.

Status in neutron:
  New

Bug description:
  Admin user is not able to update the shared access for a network. 
  Steps to reproduce:
  a) Create a network test from demo user.
  b) As an admin user, create a subnet for that network.
  c) Now, make the network shared using command “neutron net-update test 
–shared”.
  d) Now, try to make the shared as false for the same network by using the 
command “neutron net-update test –shared false”. 
  Here it throws an error saying "unable to reconfigure sharing settings for 
network test. Multiple tenants are using it."

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1771088/+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 1769777] Re: local doc build failed due to UpdateAction which was dropped

[OpenStack Infra]

Reviewed:  https://review.openstack.org/566764
Committed: 
https://git.openstack.org/cgit/openstack/horizon/commit/?id=8230f2cf7a6e62e220ee822e2e1a9675f2c977c3
Submitter: Zuul
Branch:master

commit 8230f2cf7a6e62e220ee822e2e1a9675f2c977c3
Author: Akihiro Motoki 
Date:   Tue May 8 09:36:11 2018 +0900

doc: Fix doc build failure due to dropped UpdateAction

Change-Id: Iae027ff58a4924fb3cfea1f9eaf07f357c861de8
Closes-Bug: #1769777


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

Title:
  local doc build failed due to UpdateAction which was dropped

Status in OpenStack Dashboard (Horizon):
  Fix Released

Bug description:
  tox -e docs fails due to the following error. UpdateAction was dropped
  in Rocky but contributor/ref/tables.rst still refers to UpdateAction.
  This must be dropped.

  Warning, treated as error:
  /home/ubuntu/tmp/horizon/doc/source/contributor/ref/tables.rst:96:autodoc: 
failed to import class u'UpdateAction' from module u'horizon.tables'; the 
following exception was raised:
  Traceback (most recent call last):
File 
"/home/ubuntu/tmp/horizon/.tox/docs/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py",
 line 665, in import_object
  obj = self.get_attr(obj, part)
File 
"/home/ubuntu/tmp/horizon/.tox/docs/local/lib/python2.7/site-packages/sphinx/ext/autodoc.py",
 line 554, in get_attr
  return safe_getattr(obj, name, *defargs)
File 
"/home/ubuntu/tmp/horizon/.tox/docs/local/lib/python2.7/site-packages/sphinx/util/inspect.py",
 line 185, in safe_getattr
  raise AttributeError(name)
  AttributeError: UpdateAction
  ERROR: InvocationError: '/home/ubuntu/tmp/horizon/.tox/docs/bin/sphinx-build 
-W -b html doc/source doc/build/html'
  

 summary 
_
  ERROR:   docs: commands failed

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1769777/+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 1736174] Re: update_hostname module fails on CentOS/RHEL with systemd

[MartinSteigerwald]

** Bug watch added: Red Hat Bugzilla #1577947
   https://bugzilla.redhat.com/show_bug.cgi?id=1577947

** Also affects: cloud-init (CentOS) via
   https://bugzilla.redhat.com/show_bug.cgi?id=1577947
   Importance: Unknown
   Status: Unknown

** No longer affects: cloud-init (CentOS)

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

Title:
  update_hostname module fails on CentOS/RHEL with systemd

Status in cloud-init:
  New

Bug description:
  Cloud provider:  OpenStack

  #cloud-config
  hostname: somehostname.somedomain
  fqdn: somehostname.somedomain

   __init__.py[INFO]: /var/lib/cloud/data/previous-hostname differs from
  /etc/hostname, assuming user maintained hostname.

  Error message is a little bit misleading, since when uses_systemd(),
  /etc/hostname isn't actually read, instead, the result of
  util.subp(['hostname']) is used.

  Also, this comparison/test will never succeed, because when
  uses_systemd() and filename.endswitch('/previous-hostname'), the
  return is stripped of cr/lf, however, the result of
  util.subp(['hostname']) will contain a lf, and it is not being
  stripped:

  (from rhel.py)
  if self.uses_systemd() and filename.endswith('/previous-hostname'):
  return util.load_file(filename).strip()
  elif self.uses_systemd():
  (out, _err) = util.subp(['hostname'])
  if len(out):
  return out
  else:
  return default

  The simplest solution appears to be to add .strip() to return out; but
  this fix may have other implications.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1736174/+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 1736739] Re: Machines attached to isolated network are able to reach VMs attached to other networks

[Jakub Libosvar]

This has been fixed by https://review.openstack.org/#/c/385085

I tested the described scenario and I couldn't see ICMP traffic on port of 
private machine. I reverted the mentioned patch and I'm able to see 
[root@compute ~]# tcpdump -s0 -e -nnvvi tap59d5b819-88
tcpdump: listening on tap59d5b819-88, link-type EN10MB (Ethernet), capture size 
262144 bytes
10:41:49.917436 fa:16:3e:55:0a:07 > fa:16:3e:e9:f2:03, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 58955, offset 0, flags [DF], proto ICMP (1), 
length 84)
192.168.134.7 > 10.0.0.9: ICMP echo request, id 34305, seq 1751, length 64
10:41:49.917713 fa:16:3e:e9:f2:03 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 
10.0.0.9, length 28
10:41:50.917342 fa:16:3e:e9:f2:03 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 
10.0.0.9, length 28
10:41:50.917799 fa:16:3e:55:0a:07 > fa:16:3e:e9:f2:03, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 59088, offset 0, flags [DF], proto ICMP (1), 
length 84)
192.168.134.7 > 10.0.0.9: ICMP echo request, id 34305, seq 1752, length 64
10:41:51.917444 fa:16:3e:e9:f2:03 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), 
length 42: Ethernet (len 6), IPv4 (len 4), Request who-has 10.0.0.1 tell 
10.0.0.9, length 28
10:41:51.918230 fa:16:3e:55:0a:07 > fa:16:3e:e9:f2:03, ethertype IPv4 (0x0800), 
length 98: (tos 0x0, ttl 64, id 59106, offset 0, flags [DF], proto ICMP (1), 
length 84)
192.168.134.7 > 10.0.0.9: ICMP echo request, id 34305, seq 1753, length 64

** Changed in: neutron
   Status: New => 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/1736739

Title:
  Machines attached to isolated network are able to reach VMs attached
  to other networks

Status in neutron:
  Fix Released

Bug description:
  Machines attached to isolated network are able to reach VMs attached to other 
networks.
  This behavior was observed using Symnet - the symbolic network analysis 
engine.

  Pre-conditions: devstack latest version (at the time of writing) + all
  services latest versions on ubuntu 16.04

  Steps to reproduce:
  Contents of local.conf:
  [[local|localrc]]
  ADMIN_PASSWORD=stack
  DATABASE_PASSWORD=stack
  RABBIT_PASSWORD=stack
  RABBIT_HOST=localhost
  SERVICE_PASSWORD=$ADMIN_PASSWORD
  HOST_IP=192.168.154.23
  IP_VERSION=4
  LOGFILE=$DEST/logs/stack.sh.log
  LOGDAYS=2
  MYSQL_PASSWORD=stack
  DATABASE_TYPE=mysql

  [[post-config|$NEUTRON_CONF]]
  [DEFAULT]
  service_plugins = router,trunk

  [[post-config|/$Q_PLUGIN_CONF_FILE]]
  [securitygroup]
  firewall_driver = openvswitch

  After stack.sh finishes operation (note that devstack creates networks
  public and private and a router to connect them).

  source openrc admin demo
  openstack server create --network private --image cirros-0.3.5-x86_64-disk 
--flavor m1.nano private
  openstack network create isolated
  openstack subnet create --network isolated --subnet-range 192.168.134.0/24 
isolated
  openstack server create --network isolated --image cirros-0.3.5-x86_64-disk 
--flavor m1.nano isolated

  openstack port list --server private
  // get MAC and IP of private server

  openstack port list --server isolated
  // get MAC and IP of isolated server

  Log into isolated and create an ARP entry for private machine:
  sudo ip route add 10.0.0.0/26 dev eth0 src 
  arp -s  
  ping 

  Back to the devstack machine:
  sudo tcpdump -e -vv -i tap
  // notice the ICMP traffic originating from isolated towards private

  Expected output: No traffic can get from the isolated VM to the private VM.
  Actual output: Traffic from the isolated machine reaches the private virtual 
machine even though they are not connected via any router.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1736739/+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 1771107] Re: unit test networking_bgpvpn.tests.unit.extensions.test_bgpvpn.BgpvpnExtensionTestCase.test_bgpvpn_list fails

[Thomas Morin]

I don't have a full analysis yet, but the part of [1] that causes the
breakage is more precisely the fact that the
extensions.PluginAwareExtensionManager singleton instance is created at
a different time than previously [2], and, in the context of the failing
unit test, at a time when the extension path does not include the path
to the directory containing the bgpvpn.py extension.

[1] https://review.openstack.org/#/c/545490/
[2] https://review.openstack.org/#/c/545490/19/neutron/api/api_common.py lines 
78 -> 98

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

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

Title:
  unit test
  
networking_bgpvpn.tests.unit.extensions.test_bgpvpn.BgpvpnExtensionTestCase.test_bgpvpn_list
  fails

Status in networking-bgpvpn:
  New
Status in neutron:
  New

Bug description:
  A change in neutron results in a networking-bgpvpn unit test failure:

  ==
  ERROR: 
networking_bgpvpn.tests.unit.extensions.test_bgpvpn.BgpvpnExtensionTestCase.test_bgpvpn_list
  --
  Traceback (most recent call last):
File "/home/teom7365/prog/openstack/neutron/neutron/tests/base.py", line 
140, in func
  return f(self, *args, **kwargs)
File "networking_bgpvpn/tests/unit/extensions/test_bgpvpn.py", line 192, in 
test_bgpvpn_list
  _get_path(BGPVPN_URI, fmt=self.fmt))
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
 line 331, in get
  expect_errors=expect_errors)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
 line 651, in do_request
  self._check_status(status, res)
File 
"/home/teom7365/prog/openstack/networking-bgpvpn/.tox/py27/local/lib/python2.7/site-packages/webtest/app.py",
 line 683, in _check_status
  res)
  webtest.app.AppError: Bad response: 404 Not Found (not 200 OK or 3xx redirect 
for http://localhost/bgpvpn/bgpvpns.json)
  '{"NeutronError": {"message": "Extensions not found: [\'bgpvpn\'].", "type": 
"ExtensionsNotFound", "detail": ""}}'


  'git bisect' allows to identify the neutron commit which introduces
  the issue:

 https://review.openstack.org/#/c/545490/

  
  At this point, I don't have identified /why/ this commit causes this failure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/bgpvpn/+bug/1771107/+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 1695275] [NEW] An KeyError: 'connection' has occurred when I executed the command su -s /bin/sh -c "glance-manage db_sync" glance

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

Hello.

I'm following the Installation Guide of Ocata from
https://docs.openstack.org/project-install-guide/ocata/ubuntu-
services.html

The release version of the guide (pdf) is 15.0.0

I'm using Ubuntu 16.04.2 x64

At the Image Service Section, the guide said that invoke
 su -s /bin/sh -c "glance-manage db_sync" glance

After invoking the command, an error has occurred as I attached
(error.png).

I entered options in conf files (glance-api.conf, glance-registry.conf)
as the guide said.

I checked glance database, glance user, privileges of glance database,
connection to glance database as the user glance.

Please reply this issue.

Thanks.

** Affects: glance
 Importance: Undecided
 Status: Invalid


** Tags: glance-manage
-- 
An KeyError: 'connection' has occurred when I executed the command  su -s 
/bin/sh -c "glance-manage db_sync" glance
https://bugs.launchpad.net/bugs/1695275
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to Glance.

-- 
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 1771116] [NEW] network configuration fails on CentoS 7.5: using dhcp instead of static address

[MartinSteigerwald]

Public bug reported:

Cloud-Provider: NoCloud via Proxmox and qm set

I have centostemplate CentOS 7.5 VM on Proxmox and with:

[root@centostemplate ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0 
TYPE=Ethernet
BOOTPROTO=none
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
NAME=eth0
UUID=9c[…]
DEVICE=eth0
ONBOOT=yes
DNS1=10.0.0.4
DOMAIN=qs.de
IPADDR=10.0.88.101
PREFIX=8
GATEWAY=10.0.0.4
IPV6_PRIVACY=no
PROXY_METHOD=none
BROWSER_ONLY=no

I have a script that on Proxmox does:

- qm clone 2100 2101 --name centos1
- qm set 2101 --ipconfig0 ip=10.0.88.151/8,gw=10.0.0.4 --cores 2 --memory 4096
- qm start 2101

I get

[root@centos1 ~]# cat /mnt/zeit/network-config 
version: 1
config:
- type: physical
  name: eth0
  mac_address: F2:15:C8:E1:0A:49
  subnets:
  - type: static
address: 10.0.88.151/8
gateway: 10.0.0.4
- type: nameserver
  address:
  - 10.0.0.4
  search:
  - somedomain.de

[root@centos1 ~]# ip -4 addr show eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
inet 10.0.0.161/16 brd 10.0.255.255 scope global noprefixroute dynamic eth0
   valid_lft 171536sec preferred_lft 171536sec

and:

[root@centos1 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth0
# Created by cloud-init on instance boot automatically, do not edit.
#
BOOTPROTO=none
DEFROUTE=yes
DEVICE=eth0
GATEWAY=10.0.0.4
HWADDR=F2:15:C8:E1:0A:49
IPADDR=10.0.88.151/8
ONBOOT=yes
TYPE=Ethernet
USERCTL=no
[root@centos1 ~]# ip link show eth0
2: eth0:  mtu 1500 qdisc pfifo_fast state UP 
mode DEFAULT group default qlen 1000
link/ether f2:15:c8:e1:0a:49 brd ff:ff:ff:ff:ff:ff

Yet while this works it is wrong on RedHat. It has to be:

IPADDR=10.0.88.151
PREFIX=8

Otherwise I get this:

[root@centos1 ~]# LANG=C ifup eth0
ipcalc: both netmask and prefix specified
Usage: ipcalc [OPTION...]
  -c, --check Validate IP address for specified address family
  -4, --ipv4  IPv4 address family (default)
  -6, --ipv6  IPv6 address family
  -b, --broadcast Display calculated broadcast address
  -h, --hostname  Show hostname determined via DNS
  -m, --netmask   Display default netmask for IP (class A, B, or C)
  -n, --network   Display network address
  -p, --prefixDisplay network prefix
  -s, --silentDon't ever display error messages

Help options:
  -?, --help  Show this help message
  --usage Display brief usage message
ipcalc: both netmask and prefix specified
Usage: ipcalc [OPTION...]
  -c, --check Validate IP address for specified address family
  -4, --ipv4  IPv4 address family (default)
  -6, --ipv6  IPv6 address family
  -b, --broadcast Display calculated broadcast address
  -h, --hostname  Show hostname determined via DNS
  -m, --netmask   Display default netmask for IP (class A, B, or C)
  -n, --network   Display network address
  -p, --prefixDisplay network prefix
  -s, --silentDon't ever display error messages

Help options:
  -?, --help  Show this help message
  --usage Display brief usage message
ipcalc: both netmask and prefix specified
Usage: ipcalc [OPTION...]
  -c, --check Validate IP address for specified address family
  -4, --ipv4  IPv4 address family (default)
  -6, --ipv6  IPv6 address family
  -b, --broadcast Display calculated broadcast address
  -h, --hostname  Show hostname determined via DNS
  -m, --netmask   Display default netmask for IP (class A, B, or C)
  -n, --network   Display network address
  -p, --prefixDisplay network prefix
  -s, --silentDon't ever display error messages

Help options:
  -?, --help  Show this help message
  --usage Display brief usage message
arping: 10.0.88.151/8: Name or service not known
Error: any valid prefix is expected rather than "10.0.88.151/8/".
ERROR : [/etc/sysconfig/network-scripts/ifup-eth] Error adding address 
10.0.88.151/8 for eth0.
arping: 10.0.88.151/8: Name or service not known
Error: any valid prefix is expected rather than "10.0.88.151/8/".
RTNETLINK answers: File exists


Consequently this little change fixes the issue:

[root@centos1 ~]# diff -u 
/etc/sysconfig/network-scripts/ifcfg-eth0.cloud-init.orig 
/etc/sysconfig/network-scripts/ifcfg-eth0
--- /etc/sysconfig/network-scripts/ifcfg-eth0.cloud-init.orig   2018-05-14 
14:29:42.80100 +0200
+++ /etc/sysconfig/network-scripts/ifcfg-eth0   2018-05-14 14:59:48.35200 
+0200
@@ -5,7 +5,8 @@
 DEVICE=eth0
 GATEWAY=10.0.0.4
 HWADDR=F2:15:C8:E1:0A:49
-IPADDR=10.0.88.151/8
+IPADDR=10.0.88.151
+PREFIX=8
 ONBOOT=yes
 TYPE=Ethernet
 USERCTL=no

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

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, 

[Yahoo-eng-team] [Bug 1656215] Re: Add qed disk format

[Brian Rosmaita]

Nothing to do unless glance spec is approved (see glance bug).

** Changed in: python-glanceclient
   Status: New => Invalid

** Changed in: python-glanceclient
 Assignee: Yafei Yu (yu-yafei) => (unassigned)

** Changed in: glance
   Status: In Progress => 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/1656215

Title:
  Add qed disk format

Status in Glance:
  Invalid
Status in Glance Client:
  Invalid
Status in python-openstackclient:
  Invalid

Bug description:
  QED is an image format (like qcow2, vmdk, etc) that supports backing files 
and sparse images.
  http://wiki.qemu.org/Features/QED

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1656215/+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 1656215] Re: Add qed disk format

[Brian Rosmaita]

Nothing to do unless glance spec is approved (see glance bug).

** Changed in: python-openstackclient
   Status: New => Invalid

** Changed in: python-openstackclient
 Assignee: Yafei Yu (yu-yafei) => (unassigned)

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

Title:
  Add qed disk format

Status in Glance:
  Invalid
Status in Glance Client:
  Invalid
Status in python-openstackclient:
  Invalid

Bug description:
  QED is an image format (like qcow2, vmdk, etc) that supports backing files 
and sparse images.
  http://wiki.qemu.org/Features/QED

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1656215/+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 1750777] Re: openvswitch agent eating CPU, time spent in ip_conntrack.py

[Corey Bryant]

This bug was fixed in the package neutron - 2:12.0.1-0ubuntu1.1~cloud0
---

 neutron (2:12.0.1-0ubuntu1.1~cloud0) xenial-queens; urgency=medium
 .
   * New update for the Ubuntu Cloud Archive.
 .
 neutron (2:12.0.1-0ubuntu1.1) bionic; urgency=medium
 .
   * d/p/remove-race-and-simplify-conntrack-state-management.patch:
 Cherry-picked from upstream stable/queens branch to prevent
 ovs-agent from eating up CPU (LP: #1750777).
   * d/gbp.conf: Create stable/queens branch.


** Changed in: cloud-archive/queens
   Status: Fix Committed => 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/1750777

Title:
  openvswitch agent eating CPU, time spent in ip_conntrack.py

Status in Ubuntu Cloud Archive:
  Fix Committed
Status in Ubuntu Cloud Archive queens series:
  Fix Released
Status in neutron:
  Fix Released
Status in neutron package in Ubuntu:
  Fix Released
Status in neutron source package in Bionic:
  Fix Released
Status in neutron source package in Cosmic:
  Fix Released

Bug description:
  We just ran into a case where the openvswitch agent (local dev
  destack, current master branch) eats 100% of CPU time.

  Pyflame profiling show the time being largely spent in
  neutron.agent.linux.ip_conntrack, line 95.

  
https://github.com/openstack/neutron/blob/master/neutron/agent/linux/ip_conntrack.py#L95

  The code around this line is:

  while True:
  pool.spawn_n(self._process_queue)

  The documentation of eventlet.spawn_n says: "The same as spawn(), but
  it’s not possible to know how the function terminated (i.e. no return
  value or exceptions). This makes execution faster. See spawn_n for
  more details."  I suspect that GreenPool.spawn_n may behave similarly.

  It seems plausible that spawn_n is returning very quickly because of
  some error, and then all time is quickly spent in a short circuited
  while loop.

  SRU details for Ubuntu:
  ---
  [Impact]
  We're cherry-picking a single bug-fix patch here from the upstream 
stable/queens branch as there is not currently an upstream stable point release 
available that includes this fix. We'd like to make sure all of our supported 
customers have access to this fix as there is a significant performance hit 
without it.

  [Test Case]
  The following SRU process was followed:
  https://wiki.ubuntu.com/OpenStackUpdates

  In order to avoid regression of existing consumers, the OpenStack team
  will run their continuous integration test against the packages that
  are in -proposed. A successful run of all available tests will be
  required before the proposed packages can be let into -updates.

  The OpenStack team will be in charge of attaching the output summary
  of the executed tests. The OpenStack team members will not mark
  ‘verification-done’ until this has happened.

  [Regression Potential]
  In order to mitigate the regression potential, the results of the
  aforementioned tests are attached to this bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1750777/+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 1771139] [NEW] 404 Error when creating swift container

[Mick Thompson]

Public bug reported:

Error is thrown on each keystroke when creating a new swift container.

Trying to create container called test:

First keystroke 't' -
[Mon May 14 16:01:40.923037 2018] [:error] [pid 64] REQ: curl -i 
http://10.196.224.61:8080/v1/AUTH_ff53e71c195b44169f9e85280458d9f7/t/ -X GET -H 
"X-Auth-Token: gABa-aKljIFW..."
[Mon May 14 16:01:40.923164 2018] [:error] [pid 64] RESP STATUS: 404 Not Found
[Mon May 14 16:01:40.923293 2018] [:error] [pid 64] RESP HEADERS: {u'Date': 
u'Mon, 14 May 2018 15:01:40 GMT', u'Content-Length': u'70', u'Content-Type': 
u'text/html; charset=UTF-8', u'X-Openstack-Request-Id': 
u'tx27c40e6d4d7147dcadb1e-005af9a4d4', u'X-Trans-Id': 
u'tx27c40e6d4d7147dcadb1e-005af9a4d4'}
[Mon May 14 16:01:40.923384 2018] [:error] [pid 64] RESP BODY: Not 
FoundThe resource could not be found.
[Mon May 14 16:01:40.923950 2018] [:error] [pid 64] Not Found: 
/api/swift/containers/t/metadata/

Second keystroke "e" -
[Mon May 14 16:01:45.743116 2018] [:error] [pid 62] REQ: curl -i 
http://10.196.224.61:8080/v1/AUTH_ff53e71c195b44169f9e85280458d9f7/te/ -X GET 
-H "X-Auth-Token: gABa-aKljIFW..."
[Mon May 14 16:01:45.743257 2018] [:error] [pid 62] RESP STATUS: 404 Not Found

[Mon May 14 16:01:45.743386 2018] [:error] [pid 62] RESP HEADERS: {u'Date': 
u'Mon, 14 May 2018 15:01:45 GMT', u'Content-Length': u'70', u'Content-Type': 
u'text/html; charset=UTF-8', u'X-Openstack-Request-Id': 
u'txa3ee96c08ef248f598846-005af9a4d9', u'X-Trans-Id': 
u'txa3ee96c08ef248f598846-005af9a4d9'}
[Mon May 14 16:01:45.743488 2018] [:error] [pid 62] RESP BODY: Not 
FoundThe resource could not be found.
[Mon May 14 16:01:45.743907 2018] [:error] [pid 62] Not Found: 
/api/swift/containers/te/metadata/

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

Title:
  404 Error when creating swift container

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Error is thrown on each keystroke when creating a new swift container.

  Trying to create container called test:

  First keystroke 't' -
  [Mon May 14 16:01:40.923037 2018] [:error] [pid 64] REQ: curl -i 
http://10.196.224.61:8080/v1/AUTH_ff53e71c195b44169f9e85280458d9f7/t/ -X GET -H 
"X-Auth-Token: gABa-aKljIFW..."
  [Mon May 14 16:01:40.923164 2018] [:error] [pid 64] RESP STATUS: 404 Not Found
  [Mon May 14 16:01:40.923293 2018] [:error] [pid 64] RESP HEADERS: {u'Date': 
u'Mon, 14 May 2018 15:01:40 GMT', u'Content-Length': u'70', u'Content-Type': 
u'text/html; charset=UTF-8', u'X-Openstack-Request-Id': 
u'tx27c40e6d4d7147dcadb1e-005af9a4d4', u'X-Trans-Id': 
u'tx27c40e6d4d7147dcadb1e-005af9a4d4'}
  [Mon May 14 16:01:40.923384 2018] [:error] [pid 64] RESP BODY: Not 
FoundThe resource could not be found.
  [Mon May 14 16:01:40.923950 2018] [:error] [pid 64] Not Found: 
/api/swift/containers/t/metadata/

  Second keystroke "e" -
  [Mon May 14 16:01:45.743116 2018] [:error] [pid 62] REQ: curl -i 
http://10.196.224.61:8080/v1/AUTH_ff53e71c195b44169f9e85280458d9f7/te/ -X GET 
-H "X-Auth-Token: gABa-aKljIFW..."
  [Mon May 14 16:01:45.743257 2018] [:error] [pid 62] RESP STATUS: 404 Not Found

  [Mon May 14 16:01:45.743386 2018] [:error] [pid 62] RESP HEADERS: {u'Date': 
u'Mon, 14 May 2018 15:01:45 GMT', u'Content-Length': u'70', u'Content-Type': 
u'text/html; charset=UTF-8', u'X-Openstack-Request-Id': 
u'txa3ee96c08ef248f598846-005af9a4d9', u'X-Trans-Id': 
u'txa3ee96c08ef248f598846-005af9a4d9'}
  [Mon May 14 16:01:45.743488 2018] [:error] [pid 62] RESP BODY: Not 
FoundThe resource could not be found.
  [Mon May 14 16:01:45.743907 2018] [:error] [pid 62] Not Found: 
/api/swift/containers/te/metadata/

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1771139/+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 1771137] [NEW] Xenapi disk resize broken by use of privsep code

[Bob Ball]

Public bug reported:

Patch I6c695c04ae586fec6adc354257638116277dda88 
(https://review.openstack.org/#/c/552242/) moved disk resizing into privsep.  
Unforutunately "None" was passed as the expected return code, which is not 
understood by processutils.
Further, Tempest flavor resizing moves from m1.nano to m1.micro, both of which 
have root_gb=0 thus skipping the resize code - so Tempest didn't spot this 
error.

May 14 11:26:45 DevStackOSDomU nova-compute[15359]: Traceback (most recent call 
last):
May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 445, in 
loop
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: reply = 
self._process_cmd(*msg)
May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 428, in 
_process_cmd
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: ret = func(*f_args, 
**f_kwargs)
May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/priv_context.py", line 
209, in _wrap
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: return func(*args, 
**kwargs)
May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/opt/stack/nova/nova/privsep/fs.py", line 152, in resize2fs
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: 
unprivileged_resize2fs(image, check_exit_code=check_exit_code, size=size)
May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/opt/stack/nova/nova/privsep/fs.py", line 162, in unprivileged_resize2fs
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: 
processutils.execute(*cmd, check_exit_code=check_exit_code)
May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 
414, in execute
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: if not ignore_exit_code 
and _returncode not in check_exit_code:
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: TypeError: argument of type 
'NoneType' is not iterable
May 14 11:26:45 DevStackOSDomU nova-compute[15359]: DEBUG oslo.privsep.daemon 
[None req-aad511d7-9f4a-450c-bf86-c4e948d7409b service nova] privsep: 
reply[140577558810448]: (5, 'exceptions.TypeError', ("argum
ent of type 'NoneType' is not iterable",)) {{(pid=16155) loop 
/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py:456}}

** Affects: nova
 Importance: Undecided
 Assignee: Bob Ball (bob-ball)
 Status: In Progress


** Tags: xenserver

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

Title:
  Xenapi disk resize broken by use of privsep code

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Patch I6c695c04ae586fec6adc354257638116277dda88 
(https://review.openstack.org/#/c/552242/) moved disk resizing into privsep.  
Unforutunately "None" was passed as the expected return code, which is not 
understood by processutils.
  Further, Tempest flavor resizing moves from m1.nano to m1.micro, both of 
which have root_gb=0 thus skipping the resize code - so Tempest didn't spot 
this error.

  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: Traceback (most recent 
call last):
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 445, in 
loop
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: reply = 
self._process_cmd(*msg)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 428, in 
_process_cmd
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: ret = func(*f_args, 
**f_kwargs)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/priv_context.py", line 
209, in _wrap
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: return func(*args, 
**kwargs)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/opt/stack/nova/nova/privsep/fs.py", line 152, in resize2fs
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: 
unprivileged_resize2fs(image, check_exit_code=check_exit_code, size=size)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/opt/stack/nova/nova/privsep/fs.py", line 162, in unprivileged_resize2fs
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: 
processutils.execute(*cmd, check_exit_code=check_exit_code)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 
414, in execute
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: if not 
ignore_exit_code and _returncode not in check_exit_code:
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: TypeError: argument of 
type 'NoneType' is not 

[Yahoo-eng-team] [Bug 1771145] [NEW] Hostname changes after every reboot with OpenNebula

[Corey Melanson]

Public bug reported:

When using the OpenNebula datasource (Ubuntu 16.04.4, cloud-init
18.2-4-g05926e48-0ubuntu1~16.04.2) the hostname switches after every
reboot between the one defined by the OpenNebula HOSTNAME context
variable and one based on the IP address (eg ip-10-22-33-44).

I took some time to review the code, and I believe it's happening
because HOSTNAME is a bash environment variable and also in context.sh
that is sourced in. When I applied the attached patch to unset HOSTNAME
prior to sourcing context.sh, the correct hostname stays persistent
across reboots. I'm not sure though if this is a "proper" fix for the
issue, but it's working for us.

Example:
root@cjm1604:~# cat /run/cloud-init/instance-data.json | jq .v1
{
  "availability-zone": null,
  "cloud-name": "opennebula",
  "instance-id": "iid-dsopennebula",
  "local-hostname": "cjm1604",
  "region": null
}
root@cjm1604:~# reboot


root@ip-10-236-120-173:~# cat /run/cloud-init/instance-data.json | jq .v1
{
  "availability-zone": null,
  "cloud-name": "opennebula",
  "instance-id": "iid-dsopennebula",
  "local-hostname": "ip-10-236-120-173",
  "region": null
}
root@ip-10-236-120-173:~# reboot


root@cjm1604:~# cat /run/cloud-init/instance-data.json | jq .v1
{
  "availability-zone": null,
  "cloud-name": "opennebula",
  "instance-id": "iid-dsopennebula",
  "local-hostname": "cjm1604",
  "region": null
}
root@cjm1604:~# reboot


Let me know if you require any additional information.

Cheers,
Corey Melanson

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

** Patch added: "DataSourceOpenNebula.py.patch"
   
https://bugs.launchpad.net/bugs/1771145/+attachment/5139300/+files/DataSourceOpenNebula.py.patch

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

Title:
  Hostname changes after every reboot with OpenNebula

Status in cloud-init:
  New

Bug description:
  When using the OpenNebula datasource (Ubuntu 16.04.4, cloud-init
  18.2-4-g05926e48-0ubuntu1~16.04.2) the hostname switches after every
  reboot between the one defined by the OpenNebula HOSTNAME context
  variable and one based on the IP address (eg ip-10-22-33-44).

  I took some time to review the code, and I believe it's happening
  because HOSTNAME is a bash environment variable and also in context.sh
  that is sourced in. When I applied the attached patch to unset
  HOSTNAME prior to sourcing context.sh, the correct hostname stays
  persistent across reboots. I'm not sure though if this is a "proper"
  fix for the issue, but it's working for us.

  Example:
  root@cjm1604:~# cat /run/cloud-init/instance-data.json | jq .v1
  {
"availability-zone": null,
"cloud-name": "opennebula",
"instance-id": "iid-dsopennebula",
"local-hostname": "cjm1604",
"region": null
  }
  root@cjm1604:~# reboot

  
  root@ip-10-236-120-173:~# cat /run/cloud-init/instance-data.json | jq .v1
  {
"availability-zone": null,
"cloud-name": "opennebula",
"instance-id": "iid-dsopennebula",
"local-hostname": "ip-10-236-120-173",
"region": null
  }
  root@ip-10-236-120-173:~# reboot

  
  root@cjm1604:~# cat /run/cloud-init/instance-data.json | jq .v1
  {
"availability-zone": null,
"cloud-name": "opennebula",
"instance-id": "iid-dsopennebula",
"local-hostname": "cjm1604",
"region": null
  }
  root@cjm1604:~# reboot


  
  Let me know if you require any additional information.

  Cheers,
  Corey Melanson

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1771145/+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 1771198] [NEW] Support disable_root-esque behaviour for other users

[Dan Watkins]

Public bug reported:

When building Ubuntu cloud images, we prefer to name the default user
"ubuntu" where possible, to maintain a consistent user experience
between substrates.  Some clouds, however, like to have a consistent
user name across all of their various image offerings.  This is an
inherent conflict.  One way in which we have agreed to resolve this is
to use the messaging that the disable_root behaviour currently provides
on the cloud-specific user, to point to the ubuntu user.  This means, at
least, that users are given some direction (rather than being left
wondering if their instance has provisioned correctly, or if their SSH
keys are invalid, or )

I propose a new cloud.cfg key named "ssh_disable_users" which defines a
list of users.  For each of these users, cloud-init will ensure they
exist, and configure the system so that users SSH'ing to that user will
be redirected to the default user (a la disable_root behaviour
currently).

(`disable_root: True` would translate as `ssh_disable_users: ["root"]`.)

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

Title:
  Support disable_root-esque behaviour for other users

Status in cloud-init:
  New

Bug description:
  When building Ubuntu cloud images, we prefer to name the default user
  "ubuntu" where possible, to maintain a consistent user experience
  between substrates.  Some clouds, however, like to have a consistent
  user name across all of their various image offerings.  This is an
  inherent conflict.  One way in which we have agreed to resolve this is
  to use the messaging that the disable_root behaviour currently
  provides on the cloud-specific user, to point to the ubuntu user.
  This means, at least, that users are given some direction (rather than
  being left wondering if their instance has provisioned correctly, or
  if their SSH keys are invalid, or )

  I propose a new cloud.cfg key named "ssh_disable_users" which defines
  a list of users.  For each of these users, cloud-init will ensure they
  exist, and configure the system so that users SSH'ing to that user
  will be redirected to the default user (a la disable_root behaviour
  currently).

  (`disable_root: True` would translate as `ssh_disable_users:
  ["root"]`.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1771198/+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 1771174] [NEW] cc_phone_home.py would benefit from allowing headers for the request to be specified by the user

[Mitch Kuppinger]

Public bug reported:

I user phone_home to programmatically set allowed_hosts on my management
node when creating cloud based VMs. eg. on DigitalOcean. I use a Rails
based tool to manage the VM creation. Without some work arounds that
lower security I receive a "Can't verify CSRF token authenticity." error
from Rails when phone_home attempts to connect. The ability to set a
header would be very useful:

phone_home:
url: http://example.com/$INSTANCE_ID/
post:
- pub_key_rsa
- instance_id
- fqdn
tries: 10
headers:   #<<<
- X-CSRF-Token: 1234567890 #<<<


Since util.read_file_or_url allows specifying headers
minor modifications to cc_phone_home.py would make this possible:

line 85:
url = ph_cfg['url']
post_list = ph_cfg.get('post', 'all')
header_list = ph_cfg['headers']#< Added
tries = ph_cfg.get('tries')

line 138:
try:
util.read_file_or_url(url, data=real_submit_keys,
  retries=tries, sec_between=3,
  ssl_details=util.fetch_ssl_details(cloud.paths),
  headers=header_list)#< Added

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

Title:
  cc_phone_home.py would benefit from allowing headers for the request
  to be specified by the user

Status in cloud-init:
  New

Bug description:
  I user phone_home to programmatically set allowed_hosts on my
  management node when creating cloud based VMs. eg. on DigitalOcean. I
  use a Rails based tool to manage the VM creation. Without some work
  arounds that lower security I receive a "Can't verify CSRF token
  authenticity." error from Rails when phone_home attempts to connect.
  The ability to set a header would be very useful:

  phone_home:
  url: http://example.com/$INSTANCE_ID/
  post:
  - pub_key_rsa
  - instance_id
  - fqdn
  tries: 10
  headers:   #<<<
  - X-CSRF-Token: 1234567890 #<<<

  
  Since util.read_file_or_url allows specifying headers
  minor modifications to cc_phone_home.py would make this possible:

  line 85:
  url = ph_cfg['url']
  post_list = ph_cfg.get('post', 'all')
  header_list = ph_cfg['headers']#< Added
  tries = ph_cfg.get('tries')

  line 138:
  try:
  util.read_file_or_url(url, data=real_submit_keys,
retries=tries, sec_between=3,
ssl_details=util.fetch_ssl_details(cloud.paths),
headers=header_list)#< Added

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1771174/+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 1771167] [NEW] empty seed dir /var/lib/cloud/seed/config_drive causes WARNING

[Scott Moser]

Public bug reported:

A completely empty /var/lib/cloud/seed/config_drive directory causes cloud-init 
to show a warning.
 It would seem that a completely empty dir should not cause warning on invalid 
seed, but less-loudly just go on.

>From a 16.04 image launched on IBM Cloud
(http://paste.ubuntu.com/p/dGGrPjBhrB/).


2018-05-14 16:21:56,350 - util.py[DEBUG]: Cloud-init v. 18.2 running 
'init-local' at Mon, 14 May 2018 16:21:56 +. Up 101.66 seconds.
2018-05-14 16:21:56,350 - main.py[DEBUG]: No kernel command line url found.
2018-05-14 16:21:56,350 - main.py[DEBUG]: Closing stdin.
2018-05-14 16:21:56,358 - util.py[DEBUG]: Writing to /var/log/cloud-init.log - 
ab: [644] 0 bytes
2018-05-14 16:21:56,359 - util.py[DEBUG]: Changing the ownership of 
/var/log/cloud-init.log to 104:4
2018-05-14 16:21:56,359 - util.py[DEBUG]: Attempting to remove 
/var/lib/cloud/instance/boot-finished
2018-05-14 16:21:56,359 - util.py[DEBUG]: Attempting to remove 
/var/lib/cloud/data/no-net
2018-05-14 16:21:56,359 - handlers.py[DEBUG]: start: init-local/check-cache: 
attempting to read from cache [check]
2018-05-14 16:21:56,360 - util.py[DEBUG]: Reading from 
/var/lib/cloud/instance/obj.pkl (quiet=False)
2018-05-14 16:21:56,360 - stages.py[DEBUG]: no cache found
2018-05-14 16:21:56,360 - handlers.py[DEBUG]: finish: init-local/check-cache: 
SUCCESS: no cache found
2018-05-14 16:21:56,360 - util.py[DEBUG]: Attempting to remove 
/var/lib/cloud/instance
2018-05-14 16:21:56,365 - stages.py[DEBUG]: Using distro class 
2018-05-14 16:21:56,366 - __init__.py[DEBUG]: Looking for data source in: 
['ConfigDrive', 'NoCloud'], via packages ['', 'cloudinit.sources'] that matches 
dependencies ['FILESYSTEM']
2018-05-14 16:21:56,375 - __init__.py[DEBUG]: Searching for local data source 
in: ['DataSourceConfigDrive', 'DataSourceNoCloud']
2018-05-14 16:21:56,375 - handlers.py[DEBUG]: start: 
init-local/search-ConfigDrive: searching for local data from 
DataSourceConfigDrive
2018-05-14 16:21:56,375 - __init__.py[DEBUG]: Seeing if we can get any data 
from 
2018-05-14 16:21:56,375 - openstack.py[DEBUG]: Unable to read openstack 
versions from /var/lib/cloud/seed/config_drive due to: [Errno 2] No such file 
or directory: '/var/lib/cloud/seed/config_drive/openstack'
2018-05-14 16:21:56,376 - openstack.py[DEBUG]: Selected version 'latest' from []
2018-05-14 16:21:56,376 - util.py[DEBUG]: Reading from 
/var/lib/cloud/seed/config_drive/openstack/latest/meta_data.json (quiet=False)
2018-05-14 16:21:56,376 - openstack.py[DEBUG]: Failed reading mandatory path 
/var/lib/cloud/seed/config_drive/openstack/latest/meta_data.json due to: [Errno 
2] No such file or directory: 
'/var/lib/cloud/seed/config_drive/openstack/latest/meta_data.json'
2018-05-14 16:21:56,376 - util.py[WARNING]: Failed reading config drive from 
/var/lib/cloud/seed/config_drive
2018-05-14 16:21:56,380 - util.py[DEBUG]: Failed reading config drive from 
/var/lib/cloud/seed/config_drive
Traceback (most recent call last):
  File 
"/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py", 
line 65, in _get_data
results = read_config_drive(sdir)
  File 
"/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py", 
line 176, in read_config_drive
raise excps[-1]
  File 
"/usr/lib/python3/dist-packages/cloudinit/sources/DataSourceConfigDrive.py", 
line 173, in read_config_drive
return functor(*args, **kwargs)
  File "/usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py", 
line 377, in read_v1
raise NonReadable("%s: no files found" % (self.base_path))
cloudinit.sources.helpers.openstack.NonReadable: 
/var/lib/cloud/seed/config_drive: no files found

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

Title:
  empty seed dir /var/lib/cloud/seed/config_drive causes WARNING

Status in cloud-init:
  New

Bug description:
  A completely empty /var/lib/cloud/seed/config_drive directory causes 
cloud-init to show a warning.
   It would seem that a completely empty dir should not cause warning on 
invalid seed, but less-loudly just go on.

  From a 16.04 image launched on IBM Cloud
  (http://paste.ubuntu.com/p/dGGrPjBhrB/).

  
  2018-05-14 16:21:56,350 - util.py[DEBUG]: Cloud-init v. 18.2 running 
'init-local' at Mon, 14 May 2018 16:21:56 +. Up 101.66 seconds.
  2018-05-14 16:21:56,350 - main.py[DEBUG]: No kernel command line url found.
  2018-05-14 16:21:56,350 - main.py[DEBUG]: Closing stdin.
  2018-05-14 16:21:56,358 - util.py[DEBUG]: Writing to /var/log/cloud-init.log 
- ab: [644] 0 bytes
  2018-05-14 16:21:56,359 - util.py[DEBUG]: Changing the ownership of 
/var/log/cloud-init.log to 104:4
  2018-05-14 16:21:56,359 - util.py[DEBUG]: Attempting to remove 
/var/lib/cloud/instance/boot-finished
  2018-05-14 16:21:56,359 - util.py[DEBUG]: 

[Yahoo-eng-team] [Bug 1765748] Re: webob-1.8.1 breaks projects

[OpenStack Infra]

Reviewed:  https://review.openstack.org/568304
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=f37895dc59f7bc2127b4e1ba8e38ab50e3f1f9cb
Submitter: Zuul
Branch:master

commit f37895dc59f7bc2127b4e1ba8e38ab50e3f1f9cb
Author: Lance Bragstad 
Date:   Mon May 14 14:29:52 2018 +

Update tests to work with WebOb 1.8.1

WebOb recently changed how they validate Accept-* headers [0] to
closely follow the definitions in RFC 7231 Section 5.3.2 [1].

WebOb now checks the actual value of the Accept-Language header and
compares it to a regular expression. This caused a couple keystone
unit tests to fail because we were generating random UUIDs for
Accept-Language testing just to make sure the logic within keystone
was behaving properly. The UUID format actual fails the new regular
expression being used by WebOb to validate the Accept-Language
header.

This commit changes the tests to use a language header that passes
the new validation put in place by WebOb.

[0] 
https://docs.pylonsproject.org/projects/webob/en/stable/whatsnew-1.8.html#backwards-incompatibilities
[1] https://tools.ietf.org/html/rfc7231.html#section-5.3.2

Change-Id: Ic53f4d00bc6c8dec08ec1bff589a91ff359276e1
Closes-Bug: 1765748


** Changed in: keystone
   Status: In Progress => 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/1765748

Title:
  webob-1.8.1 breaks projects

Status in Glance:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in OpenStack Global Requirements:
  In Progress

Bug description:
  Stuff like this

  ft2.2: 
glance.tests.unit.common.test_wsgi.ResourceTest.test_translate_exception_StringException:
 Traceback (most recent call last):
File 
"/home/zuul/src/git.openstack.org/openstack/glance/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py",
 line 1297, in patched
  arg = patching.__enter__()
File 
"/home/zuul/src/git.openstack.org/openstack/glance/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py",
 line 1369, in __enter__
  original, local = self.get_original()
File 
"/home/zuul/src/git.openstack.org/openstack/glance/.tox/py27/local/lib/python2.7/site-packages/mock/mock.py",
 line 1343, in get_original
  "%s does not have the attribute %r" % (target, name)
  AttributeError:  does not have the 
attribute 'best_match'

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1765748/+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 1771137] Re: Xenapi disk resize broken by use of privsep code

[OpenStack Infra]

Reviewed:  https://review.openstack.org/568318
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=eec0fe59ff08285181ac6c74ffcc36348b692b69
Submitter: Zuul
Branch:master

commit eec0fe59ff08285181ac6c74ffcc36348b692b69
Author: Bob Ball 
Date:   Mon May 14 16:27:56 2018 +0100

XenAPI: Pass expected return codes to resize2fs

None is not tolerated by ProcessUtils, therefore make sure that [0] is 
passed as the
expected return code

Change-Id: I7d6335633479dfd7715444ef4aefc85ed41b8fa3
Closes-Bug: #1771137


** Changed in: nova
   Status: In Progress => 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/1771137

Title:
  Xenapi disk resize broken by use of privsep code

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Patch I6c695c04ae586fec6adc354257638116277dda88 
(https://review.openstack.org/#/c/552242/) moved disk resizing into privsep.  
Unforutunately "None" was passed as the expected return code, which is not 
understood by processutils.
  Further, Tempest flavor resizing moves from m1.nano to m1.micro, both of 
which have root_gb=0 thus skipping the resize code - so Tempest didn't spot 
this error.

  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: Traceback (most recent 
call last):
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 445, in 
loop
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: reply = 
self._process_cmd(*msg)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py", line 428, in 
_process_cmd
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: ret = func(*f_args, 
**f_kwargs)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_privsep/priv_context.py", line 
209, in _wrap
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: return func(*args, 
**kwargs)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/opt/stack/nova/nova/privsep/fs.py", line 152, in resize2fs
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: 
unprivileged_resize2fs(image, check_exit_code=check_exit_code, size=size)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/opt/stack/nova/nova/privsep/fs.py", line 162, in unprivileged_resize2fs
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: 
processutils.execute(*cmd, check_exit_code=check_exit_code)
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]:   File 
"/usr/local/lib/python2.7/dist-packages/oslo_concurrency/processutils.py", line 
414, in execute
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: if not 
ignore_exit_code and _returncode not in check_exit_code:
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: TypeError: argument of 
type 'NoneType' is not iterable
  May 14 11:26:45 DevStackOSDomU nova-compute[15359]: DEBUG oslo.privsep.daemon 
[None req-aad511d7-9f4a-450c-bf86-c4e948d7409b service nova] privsep: 
reply[140577558810448]: (5, 'exceptions.TypeError', ("argum
  ent of type 'NoneType' is not iterable",)) {{(pid=16155) loop 
/usr/local/lib/python2.7/dist-packages/oslo_privsep/daemon.py:456}}

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1771137/+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 1750590] Re: space before keyword in /etc/neutron/neutron.conf makes service fail

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

Title:
  space before keyword in /etc/neutron/neutron.conf makes service fail

Status in neutron:
  Expired

Bug description:
  putting space before

verbose = true

  will make

systemctl status neutron-dhcp-agent.service

  to fail.

  Removing space will fix it, but this should NOT happen is this is
  plain text file (not Yaml or similar) and thus shouldn't make
  difference if there is space or not.

  
  Centos 7.3, Openstack 14.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1750590/+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 1765452] Re: Unable to use project_id as sort_key

[OpenStack Infra]

Reviewed:  https://review.openstack.org/563331
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=f213ba487b104e00048c5aeda52a04043413d51d
Submitter: Zuul
Branch:master

commit f213ba487b104e00048c5aeda52a04043413d51d
Author: Hongbin Lu 
Date:   Fri Apr 20 22:29:30 2018 +

Populate project info before using it

Sorting and filtering will rely on the attributes information. It is
necessary to populate project info before using it to sort/filter.

Closes-Bug: #1765452
Change-Id: Ife90268530b6e86a0b0d213e4742a2ef81cb2395


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

Title:
  Unable to use project_id as sort_key

Status in neutron:
  Fix Released

Bug description:
  List any neutron resource and sort the list result with 'project_id'
  as a sort_key. Neutron will return error. However, sorting with
  'tenant_id' is working so the API behavior is asymmetric and odd.

  * We cannot sort by 'project_id'

  $ sudo systemctl restart devstack@q-*
  $ curl -g -X GET 
"http://10.0.0.15:9696/v2.0/networks?sort_dir=asc_key=project_id; -H 
"Accept: application/json" -H "X-Auth-Token: $TOKEN"
  {"NeutronError": {"message": "[u'project_id'] is invalid attribute for 
sort_keys", "type": "HTTPBadRequest", "detail": ""}}

  * Sort by 'tenant_id' has no problem

  $ sudo systemctl restart devstack@q-*
  $ curl -g -X GET 
"http://10.0.0.15:9696/v2.0/networks?sort_dir=asc_key=tenant_id; -H 
"Accept: application/json" -H "X-Auth-Token: $TOKEN"
  
{"networks":[{"ipv6_address_scope":null,"dns_domain":"","revision_number":3,"port_security_enabled":true,"id":"3becdf9f-429b-4e9d-9856-403a5c8582de","router:external":false,"availability_zone_hints":[],"availability_zones":[],"ipv4_address_scope":null,"shared":true,"project_id":"a7a7fa10fd7a4c80acb7e4b224480495","l2_adjacency":true,"status":"ACTIVE","subnets":[],"description":"","tags":[],"updated_at":"2018-04-12T20:45:07Z","qos_policy_id":null,"name":"secret_network","admin_state_up":true,"tenant_id":"a7a7fa10fd7a4c80acb7e4b224480495","created_at":"2018-04-12T20:43:33Z","mtu":1450},{"updated_at":"2018-03-19T19:17:21Z","dns_domain":"","revision_number":7,"port_security_enabled":true,"id":"ad93b454-4836-46c7-bfc8-64a20a2ab95a","router:external":true,"availability_zone_hints":[],"availability_zones":["nova"],"ipv4_address_scope":null,"shared":false,"project_id":"a7a7fa10fd7a4c80acb7e4b224480495","l2_adjacency":true,"status":"ACTIVE","subnets":["c7b4904f-bf9b-4bd4-94e7-786a3d9d22fb","62d3fb30-082f-4ed1-93b8-286bd26e2530"],"description":"","tags":[],"ipv6_address_scope":null,"is_default":true,"qos_policy_id":null,"name":"public","admin_state_up":true,"tenant_id":"a7a7fa10fd7a4c80acb7e4b224480495","created_at":"2018-03-19T19:17:07Z","mtu":1500},{"ipv6_address_scope":null,"dns_domain":"","revision_number":4,"port_security_enabled":true,"id":"02dd8479-ef26-4398-a102-d19d0a7b3a1f","router:external":false,"availability_zone_hints":[],"availability_zones":["nova"],"ipv4_address_scope":null,"shared":false,"project_id":"b629c7f622ad4a7bbfc8fb0128cec046","l2_adjacency":true,"status":"ACTIVE","subnets":["49a703b8-e53e-420a-af20-3b30d6c73409","ae522c5a-7aea-4ce8-9412-73c0f5438cc4"],"description":"","tags":[],"updated_at":"2018-03-19T19:17:00Z","qos_policy_id":null,"name":"private","admin_state_up":true,"tenant_id":"b629c7f622ad4a7bbfc8fb0128cec046","created_at":"2018-03-19T19:16:56Z","mtu":1450}]}

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1765452/+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 1769283] Re: ImagePropertiesFilter has no default value resulting in unpredictable scheduling

[OpenStack Infra]

Reviewed:  https://review.openstack.org/566425
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=aa5b1326c86c408ce9cc4546e1c7a310fbce3136
Submitter: Zuul
Branch:master

commit aa5b1326c86c408ce9cc4546e1c7a310fbce3136
Author: Mohammed Naser 
Date:   Fri May 4 21:06:46 2018 -0400

Added ability to configure default architecture for ImagePropertiesFilter

When using ImagePropertiesFilter with multiple architectures inside the
same deployment, it is possible that images can be uploaded without the
hw_architecture property defined.

This results in behaviour where the instance could be scheduled on any
type of hypervisor, resulting in an instance that will successfully
transition to ACTIVE but never properly run because of the difference
in architecture.

This makes the ImagePropertiesFilter problematic as most images are
generally uploaded without the architecture property set because
most documentation does not encourage doing that.

The addition of this flag allows to make using the filter possible
because it allows the deployer to assume a default architecture if
the user did not supply one (assuming it would be the most common
architecture in their deployment, such as x86_64) yet if the user
wants a more specific architecture, they can do it in their image
properties.

In order to avoid a circular import loop, the references to the
architecture field have been moved to a seperate module so that
they can be properly and cleaned imported inside configuration.

Change-Id: Ib52deb095028e93619b93ef9e5f70775df2a403a
Closes-Bug: #1769283


** Changed in: nova
   Status: In Progress => 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/1769283

Title:
  ImagePropertiesFilter has no default value resulting in unpredictable
  scheduling

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  When using ImagePropertiesFilter for something like hardware
  architecture, it can cause very unpredictable behaviour because of the
  lack of default value.

  In our case, a public cloud user will most likely upload an image
  without `hw_architecture` defined anywhere (as most instruction and
  general OpenStack documentation refers to).

  However, in a case where there are multiple architectures available,
  the images tagged with a specific architecture will go towards
  hypervisors with that specific architecture.  However, those which are
  not tagged will go to *any* hypervisor.

  Because of how popular certain architectures are, it should be
  possible to be able to set a 'default' value for the architecture as
  it is the implied one, with the ability to override it if a user wants
  a specific one.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1769283/+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 1771265] [NEW] Install and configure controller node in Neutron: Port 35357

[Realtime]

Public bug reported:

This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:

- [X] This doc is inaccurate in this way: __

The Neutron install guide uses Port 35357 for Keystone instead of Port
5000. It is the same bug like in Nova
(https://bugs.launchpad.net/nova/+bug/1765144) where it is already
fixed.

- [ ] This is a doc addition request.
- [ ] I have a fix to the document that I can paste below including example: 
input and output. 

If you have a troubleshooting or support issue, use the following
resources:

 - Ask OpenStack: http://ask.openstack.org
 - The mailing list: http://lists.openstack.org
 - IRC: 'openstack' channel on Freenode

---
Release: 12.0.3.dev9 on 2018-05-10 22:09
SHA: ffa6ce61a0e9103ad173b2b20c2adfbbaa2eea7e
Source: 
https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-ubuntu.rst
URL: 
https://docs.openstack.org/neutron/queens/install/controller-install-ubuntu.html

** Affects: neutron
 Importance: Undecided
 Status: New


** Tags: doc

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

Title:
  Install and configure controller node in Neutron: Port 35357

Status in neutron:
  New

Bug description:
  This bug tracker is for errors with the documentation, use the
  following as a template and remove or add fields as you see fit.
  Convert [ ] into [x] to check boxes:

  - [X] This doc is inaccurate in this way: __

  The Neutron install guide uses Port 35357 for Keystone instead of Port
  5000. It is the same bug like in Nova
  (https://bugs.launchpad.net/nova/+bug/1765144) where it is already
  fixed.

  - [ ] This is a doc addition request.
  - [ ] I have a fix to the document that I can paste below including example: 
input and output. 

  If you have a troubleshooting or support issue, use the following
  resources:

   - Ask OpenStack: http://ask.openstack.org
   - The mailing list: http://lists.openstack.org
   - IRC: 'openstack' channel on Freenode

  ---
  Release: 12.0.3.dev9 on 2018-05-10 22:09
  SHA: ffa6ce61a0e9103ad173b2b20c2adfbbaa2eea7e
  Source: 
https://git.openstack.org/cgit/openstack/neutron/tree/doc/source/install/controller-install-ubuntu.rst
  URL: 
https://docs.openstack.org/neutron/queens/install/controller-install-ubuntu.html

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