[Yahoo-eng-team] [Bug 1750770] Re: installing cloud init in vmware breaks ubuntu user

[Scott Moser]

I suspect this is 16.04 only.
in 18.04, ds-identify should disable cloud-init correctly.
in 16.04 its still set to reporting only mode. and in the log it shows that the 
list got set to Ec2 (maybe).  

I'm not sure what you were expectin though, whether you thouht cloud-
init should get some vmware data from somewhere.


** Changed in: cloud-init
   Status: New => Incomplete

** Also affects: cloud-init (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: cloud-init (Ubuntu)
   Status: New => Fix Released

** Also affects: cloud-init (Ubuntu Xenial)
   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/1750770

Title:
  installing cloud init in vmware breaks ubuntu user

Status in cloud-init:
  Incomplete
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  New

Bug description:
  When installing cloud-init in vmware without any setup for user/vendor
  data it breaks the ubuntu user.

  Steps to reproduce:
  1. take vmwre (free 30 days is fine)
  2. install xenial (maybe newer as well but my case was xenial)
  3. set up your user to be ubuntu/ubuntu (through the vmware fast installer)
  # you now have a working system
  # no user/vendor data provider was set up (unless vmware did some internally)
  4. install cloud-init
  5. reboot
  # on reboot I see the cloud init vmware data gatherer timing out (fine as 
expected)
  # But after that I can't login anymore, so it seems it changed the user

  This came up in debugging another issue - so there is a chance I
  messed the service dependencies up enough to trigger this :-/ (we need
  to check that)

  Sorry, this sucks at getting logs and since I can't login anymore ...
  I'll have to setup a new system with a second user to use to take a look.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750770/+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 1754327] [NEW] Tempest scenario jobs failing due to no FIP connectivity

[Slawek Kaplonski]

Public bug reported:

It is quite often (especially for linuxbridge scenario job) that some tests 
(random) are failing because ssh to instance is not possible.
Example of such failed tests: 
http://logs.openstack.org/07/525607/12/check/neutron-tempest-plugin-scenario-linuxbridge/09f04f9/logs/testr_results.html.gz

Same issue appears sometimes in dvr scenario job but it is not so often
probably because it is multinode job and load on host is maybe lower so
instances can boot faster.

** Affects: neutron
 Importance: High
 Assignee: Slawek Kaplonski (slaweq)
 Status: In Progress


** Tags: gate-failure

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

Title:
  Tempest scenario jobs failing due to no FIP connectivity

Status in neutron:
  In Progress

Bug description:
  It is quite often (especially for linuxbridge scenario job) that some tests 
(random) are failing because ssh to instance is not possible.
  Example of such failed tests: 
http://logs.openstack.org/07/525607/12/check/neutron-tempest-plugin-scenario-linuxbridge/09f04f9/logs/testr_results.html.gz

  Same issue appears sometimes in dvr scenario job but it is not so
  often probably because it is multinode job and load on host is maybe
  lower so instances can boot faster.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1754327/+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 1720205] Re: neutron does not create the necessary iptables rules for l3 and dhcp agents when linuxbridge used

[OpenStack Infra]

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

commit 97b30494a9263db684e5901113b53c25e55d1854
Author: Sławek Kapłoński 
Date:   Tue Dec 5 14:37:50 2017 +0100

Iptables firewall driver adds forward rules for trusted ports

Iptables firewall driver can now add process trusted ports and
adds rules for them to FORWARD chain.

Change-Id: I67d0f17b4b56671fc2e2dd6e2fc4518dc42cd131
Closes-Bug: #1720205


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

Title:
  neutron does not create the necessary iptables rules for l3 and dhcp
  agents when linuxbridge used

Status in neutron:
  Fix Released

Bug description:
  Version: pike
  openstack-neutron-11.0.0-3.el7

  Config: according to 
https://docs.openstack.org/neutron/pike/install/install-rdo.html
  ml2 linuxbridge vxlan

  neutron creates rules in neutron-linuxbri-FORWARD chain only for
  compute ports but router and dhcp ports have no mention at all. So
  router and dhcp traffic remains within host bridge.

  Expected:
  neutron creates rules like -A neutron-linuxbri-FORWARD -m physdev 
--physdev-out tapb48c914e-20 --physdev-is-bridged for all agents ports in 
bridge.

  
  # iptables-save 
  # Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
  *nat
  :PREROUTING ACCEPT [23760:1495817]
  :INPUT ACCEPT [22739:1402147]
  :OUTPUT ACCEPT [1778:116606]
  :POSTROUTING ACCEPT [2260:170214]
  COMMIT
  # Completed on Thu Sep 28 18:16:57 2017
  # Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
  *mangle
  :PREROUTING ACCEPT [922003:1129881715]
  :INPUT ACCEPT [906034:1128976690]
  :FORWARD ACCEPT [20488:1851370]
  :OUTPUT ACCEPT [774093:3908358570]
  :POSTROUTING ACCEPT [793969:3910141934]
  COMMIT
  # Completed on Thu Sep 28 18:16:57 2017
  # Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
  *raw
  :PREROUTING ACCEPT [922261:1129974352]
  :OUTPUT ACCEPT [774348:3908396136]
  :neutron-linuxbri-OUTPUT - [0:0]
  :neutron-linuxbri-PREROUTING - [0:0]
  -A PREROUTING -j neutron-linuxbri-PREROUTING
  -A OUTPUT -j neutron-linuxbri-OUTPUT
  COMMIT
  # Completed on Thu Sep 28 18:16:57 2017
  # Generated by iptables-save v1.4.21 on Thu Sep 28 18:16:57 2017
  *filter
  :INPUT ACCEPT [0:0]
  :FORWARD ACCEPT [0:0]
  :OUTPUT ACCEPT [27196:421070402]
  :neutron-filter-top - [0:0]
  :neutron-linuxbri-FORWARD - [0:0]
  :neutron-linuxbri-INPUT - [0:0]
  :neutron-linuxbri-OUTPUT - [0:0]
  :neutron-linuxbri-local - [0:0]
  :neutron-linuxbri-sg-chain - [0:0]
  :neutron-linuxbri-sg-fallback - [0:0]
  -A INPUT -j neutron-linuxbri-INPUT
  -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
  -A INPUT -p icmp -j ACCEPT
  -A INPUT -i lo -j ACCEPT
  -A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
  -A INPUT -j REJECT --reject-with icmp-host-prohibited
  -A FORWARD -j neutron-filter-top
  -A FORWARD -j neutron-linuxbri-FORWARD
  -A FORWARD -j REJECT --reject-with icmp-host-prohibited
  -A OUTPUT -j neutron-filter-top
  -A OUTPUT -j neutron-linuxbri-OUTPUT
  -A neutron-filter-top -j neutron-linuxbri-local
  -A neutron-linuxbri-FORWARD -m physdev --physdev-out tapb48c914e-20 
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
  -A neutron-linuxbri-FORWARD -m physdev --physdev-in tapb48c914e-20 
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
  -A neutron-linuxbri-INPUT -m physdev --physdev-in tapb48c914e-20 
--physdev-is-bridged -m comment --comment "Accept all packets when port 
security is disabled." -j ACCEPT
  -A neutron-linuxbri-sg-chain -j ACCEPT
  -A neutron-linuxbri-sg-fallback -m comment --comment "Default drop rule for 
unmatched traffic." -j DROP
  COMMIT
  # Completed on Thu Sep 28 18:16:57 2017

  # brctl show
  bridge name bridge id   STP enabled interfaces
  brq76f218a0-55  8000.1a1da1c5730b   no  tap5015bfe4-c5
  tapa6d0f381-b7
  tapb48c914e-20
  vxlan-1006
  brq8856ee40-24  8000.921ccb87ce25   no  tap8d487e05-d8
  vxlan-1043

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1720205/+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 1748690] Re: Fix Unit Test to cover SGNotificationTestMixin class

[longfei.zhang]

not a bug

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

Title:
  Fix Unit Test to cover SGNotificationTestMixin class

Status in neutron:
  Invalid

Bug description:
  Because the current SGNotificationTestMixin class inherited from
  object, so the current unit tests of SGNotificationTestMixin class
  under the neutron/neutron/tests/unit/agent/test_securitygroups_rpc.py
  is not covered.

  The patch fixed this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1748690/+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 1734838] Re: rotate backups failed because of image in use

[Matt Riedemann]

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

** Changed in: nova/pike
   Status: New => In Progress

** Changed in: nova/pike
   Importance: Undecided => Low

** Changed in: nova/pike
 Assignee: (unassigned) => Wangpan (aspirer)

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

Title:
  rotate backups failed because of image in use

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) pike series:
  In Progress

Bug description:
  This issue similar to https://bugs.launchpad.net/nova/+bug/1634773,

  Reproduce steps:
  1. create an instance with system disk in rbd backend, named 
Instance-for-backup
  2. create the first backup of this instance, such as: nova backup 
Instance-for-backup backup-1 daily 2
  3. create a new instance with this backup-1 snapshot image, such as: nova 
boot --flavor m1.tiny --image backup-1 ...
  4. then create the second backup of Instance-for-backup, CLI is similar as 
step 2
  5. finally we create the third backup, we expect the backup-1 image should be 
rotated out by nova, but it doesn't, and nova-compute report an exception in 
it's log:

  2017-11-28 16:29:16.361 4154 DEBUG nova.compute.manager 
[req-56a39c62-2010-4004-aaac-9c3e2669ee4d af175a5930e2470c8725e742bab1ad
  7c 0e5bcf89990c455882649ed88b32e27d - - -] [instance: 
00bce146-5408-4c33-bc11-7458f847eb19] Rotating out 52 backups _rotate_back
  ups /usr/lib/python2.7/site-packages/nova/compute/manager.py:3262
  2017-11-28 16:29:16.361 4154 DEBUG nova.compute.manager 
[req-56a39c62-2010-4004-aaac-9c3e2669ee4d af175a5930e2470c8725e742bab1ad
  7c 0e5bcf89990c455882649ed88b32e27d - - -] [instance: 
00bce146-5408-4c33-bc11-7458f847eb19] Deleting image 9a993e71-71ca-490e-b3
  cb-0b4dca2e574c _rotate_backups 
/usr/lib/python2.7/site-packages/nova/compute/manager.py:3267
  2017-11-28 16:29:19.280 4154 DEBUG oslo_concurrency.lockutils 
[req-56a39c62-2010-4004-aaac-9c3e2669ee4d af175a5930e2470c8725e742
  bab1ad7c 0e5bcf89990c455882649ed88b32e27d - - -] Lock "compute_resources" 
acquired by "nova.compute.resource_tracker.update_usag
  e" :: waited 0.000s inner 
/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:270
  2017-11-28 16:29:19.353 4154 DEBUG oslo_concurrency.lockutils 
[req-56a39c62-2010-4004-aaac-9c3e2669ee4d af175a5930e2470c8725e742
  bab1ad7c 0e5bcf89990c455882649ed88b32e27d - - -] Lock "compute_resources" 
released by "nova.compute.resource_tracker.update_usag
  e" :: held 0.074s inner 
/usr/lib/python2.7/site-packages/oslo_concurrency/lockutils.py:282
  2017-11-28 16:29:19.354 4154 INFO nova.compute.manager 
[req-56a39c62-2010-4004-aaac-9c3e2669ee4d af175a5930e2470c8725e742bab1ad7
  c 0e5bcf89990c455882649ed88b32e27d - - -] [instance: 
00bce146-5408-4c33-bc11-7458f847eb19] Successfully reverted task state from
   None on failure for instance.
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher 
[req-56a39c62-2010-4004-aaac-9c3e2669ee4d af175a5930e2470c8725e
  742bab1ad7c 0e5bcf89990c455882649ed88b32e27d - - -] Exception during message 
handling: 409 Conflict: Image 9a993e71-71ca-490e-b3
  cb-0b4dca2e574c could not be deleted because it is in use: The image cannot 
be deleted because it is in use through the backend 
  store outside of Glance. (HTTP 409)
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher Traceback 
(most recent call last):
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dis
  patcher.py", line 138, in _dispatch_and_reply
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher 
incoming.message))
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dis
  patcher.py", line 185, in _dispatch
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher return 
self._do_dispatch(endpoint, method, ctxt, args)
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_messaging/rpc/dis
  patcher.py", line 127, in _do_dispatch
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher result = 
func(ctxt, **new_args)
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/nova/exception.py", li
  ne 110, in wrapped
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher payload)
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py
  ", line 220, in __exit__
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher 
self.force_reraise()
  2017-11-28 16:29:19.361 4154 ERROR oslo_messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py
  

[Yahoo-eng-team] [Bug 1718356] Re: Include default config files in python wheel

[OpenStack Infra]

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

commit 45f1404c68553fd01f386522dd16841526c68dbf
Author: Jesse Pretorius 
Date:   Thu Sep 21 13:28:09 2017 +0100

Include all rootwrap filters when building wheels

The current method of specifying each rootwrap filter
in the file list is prone to errors when adding or
removing filters. Instead of relying on a manually
maintained list this patch just includes all the files
of the correct naming convention from the applicable
folder. This is simpler and easier to maintain.

Closes-Bug: #1718356
Change-Id: I7f8c55f63d1c5a85a6a92062e918426f7d2d3c35


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

Title:
  Include default config files in python wheel

Status in Barbican:
  In Progress
Status in Cinder:
  Fix Released
Status in Cyborg:
  In Progress
Status in Designate:
  Fix Released
Status in Fuxi:
  New
Status in Glance:
  Fix Released
Status in OpenStack Heat:
  In Progress
Status in Ironic:
  Fix Released
Status in Karbor:
  In Progress
Status in OpenStack Identity (keystone):
  Fix Released
Status in kuryr-libnetwork:
  New
Status in Magnum:
  In Progress
Status in neutron:
  Fix Released
Status in OpenStack Compute (nova):
  In Progress
Status in octavia:
  Invalid
Status in openstack-ansible:
  Confirmed
Status in Sahara:
  Fix Released
Status in OpenStack DBaaS (Trove):
  Fix Released
Status in Zun:
  In Progress

Bug description:
  The projects which deploy OpenStack from source or using python wheels
  currently have to either carry templates for api-paste, policy and
  rootwrap files or need to source them from git during deployment. This
  results in some rather complex mechanisms which could be radically
  simplified by simply ensuring that all the same files are included in
  the built wheel.

  A precedence for this has already been set in neutron [1], glance [2]
  and designate [3] through the use of the data_files option in the
  files section of setup.cfg.

  [1] 
https://github.com/openstack/neutron/blob/d3c393ff6b5fbd0bdaabc8ba678d755ebfba08f7/setup.cfg#L24-L39
  [2] 
https://github.com/openstack/glance/blob/02cd5cba70a8465a951cb813a573d390887174b7/setup.cfg#L20-L21
  [3] 
https://github.com/openstack/designate/blob/25eb143db04554d65efe2e5d60ad3afa6b51d73a/setup.cfg#L30-L37

  This bug will be used for a cross-project implementation of patches to
  normalise the implementation across the OpenStack projects. Hopefully
  the result will be a consistent implementation across all the major
  projects.

  A mailing list thread corresponding to this standard setting was begun:
  http://lists.openstack.org/pipermail/openstack-dev/2017-September/122794.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/barbican/+bug/1718356/+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 1744103] Re: nova interface-attach 500 on conflict

[OpenStack Infra]

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

commit 0098dbf2f12902ccd79f6111ba3a1d5a094ae6dc
Author: Hongbin Lu 
Date:   Fri Jan 19 00:26:15 2018 +

Handle IpAddressAlreadyAllocated exception

Change-Id: I5bee9ae18764b6f285ecc5e8d7148a1019c74701
Closes-Bug: #1744103


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

Title:
  nova interface-attach  500 on conflict

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Nova returns with 5xx response instead of 4xx in case of user error.

  In this case it is clearly user issue, the user can know the 10.0.0.3
  ip address already allocated from the subnet and it cannot be
  allocated twice.

  nuva must return with 409/Conflict status code and state the problem
  to the user as neutron did to nova.

  $ nova boot --image cirros-0.3.5-x86_64-disk --flavor 42 --nic net-
  id=ef952752-b81c-478e-a114-04083c63827c test

  $ nova list
  
+--+--+++-++
  | ID   | Name | Status | Task State | Power 
State | Networks   |
  
+--+--+++-++
  | 7a453305-2684-4684-8005-04a98aebfc7e | test | ACTIVE | -  | Running 
| private=fd64:8b83:fea2:0:f816:3eff:fe5f:3da3, 10.0.0.3 |
  
+--+--+++-++

  $ nova interface-attach  7a453305-2684-4684-8005-04a98aebfc7e 
--net-id=ef952752-b81c-478e-a114-04083c63827c --fixed-ip 10.0.0.3
  ERROR (ClientException): Unexpected API Error. Please report this at 
http://bugs.launchpad.net/nova/ and attach the Nova API log if possible.
   (HTTP 500) (Request-ID: 
req-64d655fe-0564-46ec-85c2-c982d34f796c)

  Jan 18 15:21:29 afazekas-1516283855.localdomain 
devstack@n-api.service[15371]: DEBUG nova.api.openstack.wsgi [None 
req-64d655fe-0564-46ec-85c2-c982d34f796c demo demo] Action: 'create', calling 
method: 
  Jan 18 15:21:30 afazekas-1516283855.localdomain 
devstack@n-api.service[15371]: DEBUG nova.api.openstack.wsgi [None 
req-64d655fe-0564-46ec-85c2-c982d34f796c demo demo] Returning 500 to user: 
Unexpected API Error.
  Jan 18 15:21:30 afazekas-1516283855.localdomain 
devstack@n-api.service[15371]:  
{{(pid=15372) __call__ /opt/stack/nova/nova/api/openstack/wsgi.py:1079}}

  Tested on Fedora 27 on Jan 18 2018 sources, the issue reproducible on
  older versions (pike).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1744103/+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 1754359] [NEW] Apache configuration missing

[Robin Fourdeux]

Public bug reported:

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

Bellow the good apache2 configuration for keystone :

File : /etc/apache2/sites-available/keystone.conf

Listen 5000
Listen 35357


WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
WSGIProcessGroup keystone-public
WSGIScriptAlias / /usr/bin/keystone-wsgi-public
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
ErrorLogFormat "%{cu}t %M"
ErrorLog /var/log/apache2/keystone.log
CustomLog /var/log/apache2/keystone_access.log combined


Require all granted




WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
WSGIProcessGroup keystone-admin
WSGIScriptAlias / /usr/bin/keystone-wsgi-admin
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
ErrorLogFormat "%{cu}t %M"
ErrorLog /var/log/apache2/keystone.log
CustomLog /var/log/apache2/keystone_access.log combined


Require all granted



Default configuration but wrong :

Listen 5000


WSGIScriptAlias / /usr/bin/keystone-wsgi-public
WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
WSGIProcessGroup keystone-public
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
LimitRequestBody 114688

= 2.4>
  ErrorLogFormat "%{cu}t %M"


ErrorLog /var/log/apache2/keystone.log
CustomLog /var/log/apache2/keystone_access.log combined


= 2.4>
Require all granted


Order allow,deny
Allow from all




Alias /identity /usr/bin/keystone-wsgi-public

SetHandler wsgi-script
Options +ExecCGI

WSGIProcessGroup keystone-public
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On


DISTRIB_DESCRIPTION="Ubuntu 16.04.4 LTS"
OpenStack Version : Queens

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: doc

** Description changed:

- 
  - [ ] This doc is inaccurate in this way: __
  - [X] This is a doc addition request.
- - [ ] I have a fix to the document that I can paste below including example: 
input and output. 
+ - [ ] I have a fix to the document that I can paste below including example: 
input and output.
  
  Bellow the good apache2 configuration for keystone :
  
  File : /etc/apache2/sites-available/keystone.conf
  
  Listen 5000
  Listen 35357
  
  
- WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
- WSGIProcessGroup keystone-public
- WSGIScriptAlias / /usr/bin/keystone-wsgi-public
- WSGIApplicationGroup %{GLOBAL}
- WSGIPassAuthorization On
- ErrorLogFormat "%{cu}t %M"
- ErrorLog /var/log/apache2/keystone.log
- CustomLog /var/log/apache2/keystone_access.log combined
+ WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
+ WSGIProcessGroup keystone-public
+ WSGIScriptAlias / /usr/bin/keystone-wsgi-public
+ WSGIApplicationGroup %{GLOBAL}
+ WSGIPassAuthorization On
+ ErrorLogFormat "%{cu}t %M"
+ ErrorLog /var/log/apache2/keystone.log
+ CustomLog /var/log/apache2/keystone_access.log combined
  
- 
- Require all granted
- 
+ 
+ Require all granted
+ 
  
  
  
- WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
- WSGIProcessGroup keystone-admin
- WSGIScriptAlias / /usr/bin/keystone-wsgi-admin
- WSGIApplicationGroup %{GLOBAL}
- WSGIPassAuthorization On
- ErrorLogFormat "%{cu}t %M"
- ErrorLog /var/log/apache2/keystone.log
- CustomLog /var/log/apache2/keystone_access.log combined
+ WSGIDaemonProcess keystone-admin processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
+ WSGIProcessGroup keystone-admin
+ WSGIScriptAlias / /usr/bin/keystone-wsgi-admin
+ WSGIApplicationGroup %{GLOBAL}
+ WSGIPassAuthorization On
+ ErrorLogFormat "%{cu}t %M"
+ ErrorLog /var/log/apache2/keystone.log
+ CustomLog /var/log/apache2/keystone_access.log combined
  
- 
- Require all granted
- 
+ 
+ Require all granted
+ 
  
  
  Default configuration but wrong :
  
  Listen 5000
  
  
- WSGIScriptAlias / /usr/bin/keystone-wsgi-public
- WSGIDaemonProcess keystone-public processes=5 threads=1 user=keystone 
group=keystone display-name=%{GROUP}
- WSGIProcessGroup keystone-public
- WSGIApplicationGroup %{GLOBAL}
- WSGIPassAuthorization On
- LimitRequestBody 114688
+ WSGIScriptAlias / /usr/bin/keystone-wsgi-public
+ WSGIDaemonProcess keystone-public processes=5 

[Yahoo-eng-team] [Bug 1754417] [NEW] documentation error

[chris murray]

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: openstack queens on centos
7.4.  missing dependancy python-openstackclient that provides the
openstack command.

- [ ] 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: 13.0.0.0rc3.dev1 on 2018-02-22 22:43
SHA: c06d74fcf4cf5338db6572265c609036f6817466
Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-users-rdo.rst
URL: https://docs.openstack.org/keystone/queens/install/keystone-users-rdo.html

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: doc

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

Title:
  documentation error

Status in OpenStack Identity (keystone):
  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: openstack queens on centos
  7.4.  missing dependancy python-openstackclient that provides the
  openstack command.

  - [ ] 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: 13.0.0.0rc3.dev1 on 2018-02-22 22:43
  SHA: c06d74fcf4cf5338db6572265c609036f6817466
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-users-rdo.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-users-rdo.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1754417/+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 1754438] [NEW] keystone tests fail scope checking

[Lance Bragstad]

Public bug reported:

Now that system scope is implemented and oslo.policy understands
different scope types. One of two things will happen when a token of the
wrong scope is used to access an API. Either a warning will be logged if
oslo.policy's enforce_scope is False, or an exception will be raised.

This is apparent in keystone's unit tests because the warning spams the
logs.

We should make some utilities that get system-scoped tokens for a user.
This will be useful in tests that require system-scoped tokens to
operate.

Example warning when tests are run:
http://paste.openstack.org/raw/695596/

** Affects: keystone
 Importance: Medium
 Status: Triaged


** Tags: policy test-improvement

** Changed in: keystone
   Importance: Undecided => Medium

** Changed in: keystone
   Status: New => Triaged

** Tags added: policy

** Description changed:

  Now that system scope is implemented and oslo.policy understands
  different scope types. One of two things will happen when a token of the
  wrong scope is used to access an API. Either a warning will be logged if
  oslo.policy's enforce_scope is False, or an exception will be raised.
  
  This is apparent in keystone's unit tests because the warning spams the
  logs.
  
  We should make some utilities that get system-scoped tokens for a user.
  This will be useful in tests that require system-scoped tokens to
  operate.
+ 
+ Example warning when tests are run:
+ http://paste.openstack.org/raw/695596/

** Tags added: test-improvement

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

Title:
  keystone tests fail scope checking

Status in OpenStack Identity (keystone):
  Triaged

Bug description:
  Now that system scope is implemented and oslo.policy understands
  different scope types. One of two things will happen when a token of
  the wrong scope is used to access an API. Either a warning will be
  logged if oslo.policy's enforce_scope is False, or an exception will
  be raised.

  This is apparent in keystone's unit tests because the warning spams
  the logs.

  We should make some utilities that get system-scoped tokens for a
  user. This will be useful in tests that require system-scoped tokens
  to operate.

  Example warning when tests are run:
  http://paste.openstack.org/raw/695596/

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1754438/+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 1754413] [NEW] Documention Error

[chris murray]

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: 
Installing keystone queens on centos 7.4 from documentation 

ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/
command will not allow httpd to start due to selinux confilicts.  Missing 
dependancy is openstack-selinux which requires the Cloud, OS, and Extras 
repisitories enabled.

- [ ] 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: 13.0.0.0rc3.dev1 on 2018-02-22 22:43
SHA: c06d74fcf4cf5338db6572265c609036f6817466
Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-rdo.rst
URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-rdo.html

** Affects: keystone
 Importance: Undecided
 Status: New


** Tags: doc

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

Title:
  Documention Error

Status in OpenStack Identity (keystone):
  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: 
  Installing keystone queens on centos 7.4 from documentation 

  ln -s /usr/share/keystone/wsgi-keystone.conf /etc/httpd/conf.d/
  command will not allow httpd to start due to selinux confilicts.  Missing 
dependancy is openstack-selinux which requires the Cloud, OS, and Extras 
repisitories enabled.

  - [ ] 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: 13.0.0.0rc3.dev1 on 2018-02-22 22:43
  SHA: c06d74fcf4cf5338db6572265c609036f6817466
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-rdo.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-rdo.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1754413/+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 1753209] Re: neutron_tempest_plugin.api.admin.test_shared_network_extension.RBACSharedNetworksTest, rbac policy in use across tenants.

[Ihar Hrachyshka]

So the reason of failure here is that one test case uses a network that
was temporarily shared with all tenants while running a RBAC test case.
When the network is for a short span of time shared with everyone, the
other test case -
VolumesSnapshotTestJSON:test_snapshot_create_delete_with_volume_in_use -
creates an instance with the following request body:

Body: {"server": {"flavorRef": "e443576a-50cd-4023-88e0-574b1ec1726e", 
"name": "tempest-VolumesSnapshotTestJSON-instance-1302082485", "imageRef": 
"9a98ccb7-cd30-43da-85a9-5cfd8126c5ae"}}
which, as you can see, doesn't specify network to use, so nova then apparently 
picks one of available networks to boot the instance on, and it happens to be 
the network that was momentarily shared in RBAC test case.

I don't think that the Volumes test case should rely on nova to pick a
network for them, and instead pre-create a tenant network for this
specific test case and then boot the instance on it. By doing so, we
will avoid the race condition between those test cases b/c Volumes test
case won't touch the shared network and create VIF ports on it.

This is probably a bug for cinder folks to solve since the offending
test case is in VolumesSnapshot class.

One thing to mull over on neutron side though is whether the rbac test
case, as written, could reduce its impact. One thing to consider is that
the network that is momentarily shared with everyone will pop up for all
tenants, incl. those unaware of tempest running in background. Since
some operators execute tempest periodically against their cloud, they
probably don't want their customers to get random networks popping up
for a brief moment. Though the RBAC test case explicitly validates the
wildcard RBAC behavior so not sure if we can easily get rid of it w/o
loosing some coverage.

How does tempest core team look at such cases? Do we forbid any impact
on other cloud users? If so, we could probably shorten the neutron api
case to avoid it, even if it means a particular use case won't be
covered with tempest.

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

** Also affects: tempest
   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/1753209

Title:
  
neutron_tempest_plugin.api.admin.test_shared_network_extension.RBACSharedNetworksTest,
  rbac policy in use across tenants.

Status in neutron:
  New
Status in tempest:
  New
Status in tripleo:
  Triaged

Bug description:
  
neutron_tempest_plugin.api.admin.test_shared_network_extension.RBACSharedNetworksTest
  failure

  https://logs.rdoproject.org/openstack-periodic/periodic-tripleo-ci-
  centos-7-ovb-1ctlr_1comp-featureset020-master/6cec620/tempest.html.gz

  Details: {u'message': u'RBAC policy on object 3cfbd0a7-84f2-4e3f-917e-
  bf51b5995e20 cannot be removed because other objects depend on
  it.\nDetails: Callback
  neutron.plugins.ml2.plugin.Ml2Plugin.validate_network_rbac_policy_change
  --9223372036850840529 failed with "Unable to reconfigure sharing
  settings for network 3cfbd0a7-84f2-4e3f-917e-bf51b5995e20. Multiple
  tenants are using it.",Callback
  
neutron.services.network_ip_availability.plugin.NetworkIPAvailabilityPlugin.validate_network_rbac_policy_change
  --9223372036853400817 failed with "Unable to reconfigure sharing
  settings for network 3cfbd0a7-84f2-4e3f-917e-bf51b5995e20. Multiple
  tenants are using it.",Callback
  
neutron.services.network_ip_availability.plugin.NetworkIPAvailabilityPlugin.validate_network_rbac_policy_change
  --9223372036853463713 failed with "Unable to reconfigure sharing
  settings for network 3cfbd0a7-84f2-4e3f-917e-bf51b5995e20. Multiple
  tenants are using it."', u'type': u'RbacPolicyInUse', u'detail': u''}

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1753209/+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 1754412] [NEW] Install and configure (Ubuntu) in glance

[Dan Robinson]

Public bug reported:


- [x] This doc is inaccurate in this way:

The versions of /etc/glance/glance-api.conf and /etc/glance/glance-
registry.conf within the guide both still reference auth_url =
http://controller:35357

However, the Indentity configuration guide for Queens no longer utilises
this port. The install guide for Glance (Queens) should reference
auth_url = http://controller:5000 instead.


---
Release: 16.0.1.dev1 on 'Thu Mar 1 07:26:57 2018, commit 968f4ae'
SHA: 968f4ae9ce244d9372cb3e8f45acea9d557f317d
Source: 
https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst
URL: https://docs.openstack.org/glance/queens/install/install-ubuntu.html

** Affects: glance
 Importance: Undecided
 Status: New

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

Title:
  Install and configure (Ubuntu) in glance

Status in Glance:
  New

Bug description:


  - [x] This doc is inaccurate in this way:

  The versions of /etc/glance/glance-api.conf and /etc/glance/glance-
  registry.conf within the guide both still reference auth_url =
  http://controller:35357

  However, the Indentity configuration guide for Queens no longer
  utilises this port. The install guide for Glance (Queens) should
  reference auth_url = http://controller:5000 instead.

  
  ---
  Release: 16.0.1.dev1 on 'Thu Mar 1 07:26:57 2018, commit 968f4ae'
  SHA: 968f4ae9ce244d9372cb3e8f45acea9d557f317d
  Source: 
https://git.openstack.org/cgit/openstack/glance/tree/doc/source/install/install-ubuntu.rst
  URL: https://docs.openstack.org/glance/queens/install/install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1754412/+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 1754409] [NEW] invalid raise construct in test_build_resources_instance_not_found_before_yield

[Balazs Gibizer]

Public bug reported:

The test code in [1] uses `raise` statement without any parameter. It is
not a valid python construct if used outside of an `expect` block.

The test does not fail on this as this codepath never executed.

[1]
https://github.com/openstack/nova/blob/93a985d33662723872ec5eedd1a173dc397f96fa/nova/tests/unit/compute/test_compute_mgr.py#L5686

** Affects: nova
 Importance: Undecided
 Assignee: Balazs Gibizer (balazs-gibizer)
 Status: In Progress


** Tags: testing

** Tags added: testing

** Changed in: nova
 Assignee: (unassigned) => Balazs Gibizer (balazs-gibizer)

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

Title:
  invalid raise construct in
  test_build_resources_instance_not_found_before_yield

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  The test code in [1] uses `raise` statement without any parameter. It
  is not a valid python construct if used outside of an `expect` block.

  The test does not fail on this as this codepath never executed.

  [1]
  
https://github.com/openstack/nova/blob/93a985d33662723872ec5eedd1a173dc397f96fa/nova/tests/unit/compute/test_compute_mgr.py#L5686

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1754409/+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 1754495] [NEW] get_hostname on DataSourceAzure fails

[Douglas Jordan]

Public bug reported:

$ python3 -c "from cloudinit.sources.DataSourceAzure import get_hostname; 
get_hostname()"
Traceback (most recent call last):
  File "/home/dojordan/code/cloud-init/cloudinit/util.py", line 1875, in subp
env=env, shell=shell)
  File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
restore_signals, start_new_session)
  File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
raise child_exception_type(errno_num, err_msg)
FileNotFoundError: [Errno 2] No such file or directory: b'h'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "", line 1, in 
  File "/home/dojordan/code/cloud-init/cloudinit/sources/DataSourceAzure.py", 
line 226, in get_hostname
return util.subp(hostname_command, capture=True)[0].strip()
  File "/home/dojordan/code/cloud-init/cloudinit/util.py", line 1881, in subp
stderr="-" if decode else b"-")
cloudinit.util.ProcessExecutionError: Unexpected error while running command.
Command: hostname
Exit code: -
Reason: [Errno 2] No such file or directory: b'h'
Stdout: -
Stderr: -

This is on latest master (commit
1e2e810f3f7cb6a163a0229ac37037e8c6744d72). Due to this, any VM
provisioning will likely fail on Azure. Not entirely sure how
https://code.launchpad.net/~smoser/cloud-init/+git/cloud-
init/+merge/338586 passed the Azure test.

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

Title:
  get_hostname on DataSourceAzure fails

Status in cloud-init:
  New

Bug description:
  $ python3 -c "from cloudinit.sources.DataSourceAzure import get_hostname; 
get_hostname()"
  Traceback (most recent call last):
File "/home/dojordan/code/cloud-init/cloudinit/util.py", line 1875, in subp
  env=env, shell=shell)
File "/usr/lib/python3.5/subprocess.py", line 947, in __init__
  restore_signals, start_new_session)
File "/usr/lib/python3.5/subprocess.py", line 1551, in _execute_child
  raise child_exception_type(errno_num, err_msg)
  FileNotFoundError: [Errno 2] No such file or directory: b'h'

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File "", line 1, in 
File "/home/dojordan/code/cloud-init/cloudinit/sources/DataSourceAzure.py", 
line 226, in get_hostname
  return util.subp(hostname_command, capture=True)[0].strip()
File "/home/dojordan/code/cloud-init/cloudinit/util.py", line 1881, in subp
  stderr="-" if decode else b"-")
  cloudinit.util.ProcessExecutionError: Unexpected error while running command.
  Command: hostname
  Exit code: -
  Reason: [Errno 2] No such file or directory: b'h'
  Stdout: -
  Stderr: -

  This is on latest master (commit
  1e2e810f3f7cb6a163a0229ac37037e8c6744d72). Due to this, any VM
  provisioning will likely fail on Azure. Not entirely sure how
  https://code.launchpad.net/~smoser/cloud-init/+git/cloud-
  init/+merge/338586 passed the Azure test.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1754495/+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 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Scott Moser]

** No longer affects: maas

** No longer affects: nplan (Ubuntu)

** No longer affects: systemd (Ubuntu)

** Changed in: cloud-init
   Status: New => Confirmed

** Changed in: cloud-init
   Importance: Undecided => Medium

** Changed in: cloud-init
 Assignee: (unassigned) => Ryan Harper (raharper)

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

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  Confirmed

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750884/+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 1749629] Re: VIFs are not detached from ironic node when unprovision fails

[OpenStack Infra]

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

commit 1bd749288c12c83c2c48f5a6bf9a0b5fc9f682c7
Author: Hironori Shiina 
Date:   Thu Feb 15 12:13:23 2018 +0900

ironic: Clean up resources after unprovision fails

When deleting a bare metal instance, even if ironic fails to
unprovision a node, network resources are deallocated. Then, VIFs are
removed though the VIFs are not detached from the ironic node.

This patch cleans up resources nova prepares for ironic even if
unprovision fails.

Change-Id: I01f45f157078a92ccc9f4ff5b4bfeae6cef77c1a
Closes-Bug: 1749629


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

Title:
  VIFs are not detached from ironic node when unprovision fails

Status in OpenStack Compute (nova):
  Fix Released

Bug description:
  Description
  ===
  When deleting a bare metal instance, even if ironic fails to unprovision a 
node, network resources are deallocated. Then VIFs are removed though the VIFs 
are not detached from the ironic node. The instance gets in ERROR state and can 
be deleted by requesting deletion again without any call to ironic. In ironic, 
the node gets in 'error' provision state after the unprovision failure. Though 
node can be recovered by undeploying it with ironic API, the VIF UUIDs still 
remain in the node. This causes an error when the node is deployed again since 
ironic tries to bind the node to the deleted VIFs. It would be better to detach 
VIFs even if unprovisioning fails.

  Steps to reproduce
  ==
  * create an instance
  * delete an instance, then it failed due to ironic bug
  ironic node gets in 'error' provision state
  * recover the ironic node with:
  openstack baremetal node undeploy 
  * create an instance again, then the previous node is chosen

  Expected result
  ===
  After the execution of the steps above, what should have
  happened if the issue wasn't present?

  Actual result
  =
  What happened instead of the expected result?
  How did the issue look like?

  Environment
  ===
  Deploying Ironic with DevStack[1] with master branch.

  [1] https://docs.openstack.org/ironic/latest/contributor/dev-
  quickstart.html#deploying-ironic-with-devstack

  Logs & Configs
  ==

  n-cpu log when undeploy failed
  ---
  Feb 14 21:24:51 compute nova-compute[17722]: INFO nova.compute.manager [None 
req-420e3a3a-3af4-4662-877e-d19fd24ea036 service nova] [instance: 
651f3a00-6074-4346-a229-97e8874eed36] Successfully reverted task state from 
deleting on failure for instance.
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server 
[None req-420e3a3a-3af4-4662-877e-d19fd24ea036 service nova] Exception during 
message handling: NovaException: Error destroying the instance on node 
8a2eea80-d53a-419e-a56c-9981f248cf91. Provision state still 'deleting'.
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server 
Traceback (most recent call last):
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
 File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", 
line 163, in _process_incoming
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
   res = self.dispatcher.dispatch(message)
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
 File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
220, in dispatch
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
   return self._do_dispatch(endpoint, method, ctxt, args)
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
 File 
"/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 
190, in _do_dispatch 
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
   result = func(ctxt, **new_args)
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
 File "/opt/stack/nova/nova/exception_wrapper.py", line 76, in wrapped
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
   function_name, call_dict, binary)
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
 File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 
220, in __exit__
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
   self.force_reraise()
  Feb 14 21:24:52 compute nova-compute[17722]: ERROR oslo_messaging.rpc.server  
 File 

[Yahoo-eng-team] [Bug 1703666] Re: Templated catalog does not handle multi-regions properly

[OpenStack Infra]

** Changed in: keystone
   Status: Invalid => In Progress

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

Title:
  Templated catalog does not handle multi-regions properly

Status in OpenStack Identity (keystone):
  In Progress

Bug description:
  The current implementation of the keystone templated catalog does not
  group endpoints properly when there are multiple regions available.

  This is an working example when using the sql backend and the
  openstack catalog list command.

  | nova| compute| RegionTwo
  | ||   admin: http://10.0.3.15:8774/v2.1
  | || RegionOne
  | ||   admin: http://10.0.2.15:8774/v2.1

  This is the same example using the templated backend and the openstack
  catalog list command.

  | nova| compute| RegionTwo
  | ||   admin: http://10.0.3.15:8774/v2.1
  | nova| compute| RegionOne
  | ||   admin: http://10.0.2.15:8774/v2.1

  This causes issues in services that expects each service_type to
  include the endpoint for all regions.

  This is because the code in for example Horizon is initially only
  looking for the service_type, which will return the first one, in this
  case is RegionTwo. If Horizon was requesting RegionOne, this would
  fail, as the list of endpoints would only contain RegionTwo.

  As a work-around for Horizon a change like this is required
  http://paste.openstack.org/show/614967/

   -def get_service_from_catalog(catalog, service_type):
   +def get_service_from_catalog(catalog, service_type, region):
    if catalog:
    for service in catalog:
    if 'type' not in service:
    continue
    if service['type'] == service_type:
   -return service
   +for endpoint in service['endpoints']:
   +if endpoint['region'] == region:
   +return service
    return None

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703666/+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 1737630] Re: cloud-init's netplan rendering does not do anything that starts networkd

[Scott Moser]

** Changed in: cloud-init
   Status: New => Invalid

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

Title:
  cloud-init's netplan rendering does not do anything that starts
  networkd

Status in cloud-init:
  Invalid

Bug description:
  Currently if an instance ends up using cloud-init's netplan support
  with the networkd backed, networkd is never started and so networking
  doesn't come up. The fix is probably to call "netplan apply" rather
  than "netplan generate".

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1737630/+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 1731323] Re: quota-show security_group in_use not correct

[Takashi NATSUME]

Needs nova version.

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

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

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

Title:
  quota-show security_group in_use not correct

Status in OpenStack Compute (nova):
  Incomplete
Status in python-novaclient:
  Invalid

Bug description:
  python-novaclient (9.1.1)

  nova quota-show --detail does not reflect the correct security_groups
  usage.

  lab@Ubuntu-1404LTS:~$ nova quota-show --detail --tenant 
ef954183f6d548a69cc7e7de5282086f
  
+-+-+
  | Quota   | Limit 
  |
  
+-+-+
  | instances   | {u'limit': 20, u'reserved': 0, u'in_use': 14} 
  |
  | cores   | {u'limit': 80, u'reserved': 0, u'in_use': 21} 
  |
  | ram | {u'limit': 81920, u'reserved': 0, u'in_use': 
47104} |
  | floating_ips| {u'limit': 10, u'reserved': 0, u'in_use': 0}  
  |
  | fixed_ips   | {u'limit': -1, u'reserved': 0, u'in_use': 0}  
  |
  | metadata_items  | {u'limit': 128, u'reserved': 0, u'in_use': 0} 
  |
  | injected_files  | {u'limit': 5, u'reserved': 0, u'in_use': 0}   
  |
  | injected_file_content_bytes | {u'limit': 10240, u'reserved': 0, u'in_use': 
0} |
  | injected_file_path_bytes| {u'limit': 255, u'reserved': 0, u'in_use': 0} 
  |
  | key_pairs   | {u'limit': 100, u'reserved': 0, u'in_use': 0} 
  |
  | security_groups | {u'limit': 10, u'reserved': 0, u'in_use': 1}  
  |
  | security_group_rules| {u'limit': 20, u'reserved': 0, u'in_use': 0}  
  |
  | server_groups   | {u'limit': 10, u'reserved': 0, u'in_use': 0}  
  |
  | server_group_members| {u'limit': 10, u'reserved': 0, u'in_use': 0}  
  |
  
+-+-+

  List of security groups for this project: 
  
+--+--++--+
  | ID   | Name 
| Description| Project  |
  
+--+--++--+
  | 25fd771d-2e8c-497a-8e30-1bfc0d074f98 | 
FLASH-dbc4628c-c57b-11e7-8bfc-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 4ef98e22-f5f2-4e06-86b5-1cd93043ed7a | 
FLASH-117f4834-c4d6-11e7-91ff-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 57204137-8537-495a-b98e-9f168160456d | 
FLASH-db8f1654-c57b-11e7-b221-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 64a49394-40cb-4061-b752-a2fdb7b23cc4 | 
FLASH-db8cc02a-c57b-11e7-8b14-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 7d47aa36-57ed-49e8-a369-d254daed77d2 | 
FLASH-dbc74d80-c57b-11e7-9433-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 82418bda-148e-41eb-bc18-c1322927f4ee | 
bagursreenivasamurth-OneArmed-1-group|| 
ef954183f6d548a69cc7e7de5282086f |
  | b246f364-57a7-4b11-b278-344090f2efa6 | default  
| Default security group | ef954183f6d548a69cc7e7de5282086f |
  | bf4da89a-e1cf-4fac-80e1-ed69fe2dc350 | 
FLASH-117745ee-c4d6-11e7-8547-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | cbe42c81-513a-407c-89b8-6db96bbb0756 | 
FLASH-d85b76c2-c43f-11e7-b8c8-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  
+--+--++--+

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1731323/+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 1731323] Re: quota-show security_group in_use not correct

[Takashi NATSUME]

Python-novaclient just shows the result that nova returns.
So it seems an issue in nova side, not in python-novaclient side.


** Tags added: quotas

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

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

Title:
  quota-show security_group in_use not correct

Status in OpenStack Compute (nova):
  Incomplete
Status in python-novaclient:
  Invalid

Bug description:
  python-novaclient (9.1.1)

  nova quota-show --detail does not reflect the correct security_groups
  usage.

  lab@Ubuntu-1404LTS:~$ nova quota-show --detail --tenant 
ef954183f6d548a69cc7e7de5282086f
  
+-+-+
  | Quota   | Limit 
  |
  
+-+-+
  | instances   | {u'limit': 20, u'reserved': 0, u'in_use': 14} 
  |
  | cores   | {u'limit': 80, u'reserved': 0, u'in_use': 21} 
  |
  | ram | {u'limit': 81920, u'reserved': 0, u'in_use': 
47104} |
  | floating_ips| {u'limit': 10, u'reserved': 0, u'in_use': 0}  
  |
  | fixed_ips   | {u'limit': -1, u'reserved': 0, u'in_use': 0}  
  |
  | metadata_items  | {u'limit': 128, u'reserved': 0, u'in_use': 0} 
  |
  | injected_files  | {u'limit': 5, u'reserved': 0, u'in_use': 0}   
  |
  | injected_file_content_bytes | {u'limit': 10240, u'reserved': 0, u'in_use': 
0} |
  | injected_file_path_bytes| {u'limit': 255, u'reserved': 0, u'in_use': 0} 
  |
  | key_pairs   | {u'limit': 100, u'reserved': 0, u'in_use': 0} 
  |
  | security_groups | {u'limit': 10, u'reserved': 0, u'in_use': 1}  
  |
  | security_group_rules| {u'limit': 20, u'reserved': 0, u'in_use': 0}  
  |
  | server_groups   | {u'limit': 10, u'reserved': 0, u'in_use': 0}  
  |
  | server_group_members| {u'limit': 10, u'reserved': 0, u'in_use': 0}  
  |
  
+-+-+

  List of security groups for this project: 
  
+--+--++--+
  | ID   | Name 
| Description| Project  |
  
+--+--++--+
  | 25fd771d-2e8c-497a-8e30-1bfc0d074f98 | 
FLASH-dbc4628c-c57b-11e7-8bfc-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 4ef98e22-f5f2-4e06-86b5-1cd93043ed7a | 
FLASH-117f4834-c4d6-11e7-91ff-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 57204137-8537-495a-b98e-9f168160456d | 
FLASH-db8f1654-c57b-11e7-b221-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 64a49394-40cb-4061-b752-a2fdb7b23cc4 | 
FLASH-db8cc02a-c57b-11e7-8b14-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 7d47aa36-57ed-49e8-a369-d254daed77d2 | 
FLASH-dbc74d80-c57b-11e7-9433-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | 82418bda-148e-41eb-bc18-c1322927f4ee | 
bagursreenivasamurth-OneArmed-1-group|| 
ef954183f6d548a69cc7e7de5282086f |
  | b246f364-57a7-4b11-b278-344090f2efa6 | default  
| Default security group | ef954183f6d548a69cc7e7de5282086f |
  | bf4da89a-e1cf-4fac-80e1-ed69fe2dc350 | 
FLASH-117745ee-c4d6-11e7-8547-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  | cbe42c81-513a-407c-89b8-6db96bbb0756 | 
FLASH-d85b76c2-c43f-11e7-b8c8-fa163ea0bffb-group || 
ef954183f6d548a69cc7e7de5282086f |
  
+--+--++--+

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1731323/+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 1323996] Re: resize fail didn't show a correct info when --poll specified when resize down

[Takashi NATSUME]

CONFIRMED FOR: master (commit ff47787e11a0a1b6299298b25b4c982bcfae6e1c)

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

** Changed in: python-novaclient
   Status: New => Confirmed

** Changed in: python-novaclient
   Importance: Undecided => Low

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

Title:
  resize fail didn't show a correct info when --poll specified when
  resize down

Status in OpenStack Compute (nova):
  Confirmed
Status in python-novaclient:
  Confirmed

Bug description:
  jichen@controller:~$ nova resize --poll t9 12
  Server resizing... 100% complete
  Finished

  see following info in nova compute.log and the resize failed, we
  should give accurate info about it

  2014-05-28 15:29:12.508 4259 TRACE oslo.messaging.rpc.dispatcher 
self.instance_events.clear_events_for_instance(instance)
  2014-05-28 15:29:12.508 4259 TRACE oslo.messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/contextlib.py", line 35, in __exit__
  2014-05-28 15:29:12.508 4259 TRACE oslo.messaging.rpc.dispatcher 
self.gen.throw(type, value, traceback)
  2014-05-28 15:29:12.508 4259 TRACE oslo.messaging.rpc.dispatcher   File 
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 5556, in 
_error_out_instance_on_exception
  2014-05-28 15:29:12.508 4259 TRACE oslo.messaging.rpc.dispatcher raise 
error.inner_exception
  2014-05-28 15:29:12.508 4259 TRACE oslo.messaging.rpc.dispatcher ResizeError: 
Resize error: Unable to resize disk down.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1323996/+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 1754543] [NEW] not update request_spec.request_networks after attach or detach interface

[yangyegang]

Public bug reported:

i attach a port to vm ,but request_spec.request_networks did not update.
port_id of request_spec.request_networks is null.

"request_networks": {
"nova_object.version": "1.1",
"nova_object.changes": ["objects"],
"nova_object.name": "NetworkRequestList",
"nova_object.data": {
"objects": [{
"nova_object.version": "1.2",
"nova_object.changes": ["network_id", 
"pci_request_id", "tag", "port_id", "address"],
"nova_object.name": "NetworkRequest",
"nova_object.data": {
"network_id": 
"90ba0584-b2b7-4f6a-b862-f77864d8626f",
"pci_request_id": null,
"tag": null,
"port_id": null,
"address": null
},
"nova_object.namespace": "nova"
}]
},
"nova_object.namespace": "nova"
},

** Affects: nova
 Importance: Undecided
 Status: New

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

Title:
  not update request_spec.request_networks after attach or detach
  interface

Status in OpenStack Compute (nova):
  New

Bug description:
  i attach a port to vm ,but request_spec.request_networks did not
  update. port_id of request_spec.request_networks is null.

  "request_networks": {
"nova_object.version": "1.1",
"nova_object.changes": ["objects"],
"nova_object.name": "NetworkRequestList",
"nova_object.data": {
"objects": [{
"nova_object.version": "1.2",
"nova_object.changes": ["network_id", 
"pci_request_id", "tag", "port_id", "address"],
"nova_object.name": "NetworkRequest",
"nova_object.data": {
"network_id": 
"90ba0584-b2b7-4f6a-b862-f77864d8626f",
"pci_request_id": null,
"tag": null,
"port_id": null,
"address": null
},
"nova_object.namespace": "nova"
}]
},
"nova_object.namespace": "nova"
},

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1754543/+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 1754376] [NEW] keystone db_sync error "Index column size too large. The maximum column size is 767 bytes."

[Trinh Nguyen]

Public bug reported:

When I populate the keystone database with the following command:

su -s /bin/sh -c "keystone-manage db_sync" keystone

I got this error:

DBError: (pymysql.err.InternalError) (1709, u'Index column size too large. The 
maximum column size is 767 bytes.') [SQL: u'\nCREATE TABLE migrate_version 
(\n\trepository_id VARCHAR(250) NOT NULL, \n\trepository_path TEXT, \n\tversion 
INTEGER, \n\tPRIMARY KEY (repository_id)\n)\n\n'] (Background on this error at: 
http://sqlalche.me/e/2j85)
2018-03-09 00:31:18.480 19707 ERROR keystone

Full errors: http://paste.openstack.org/show/695366/

- OS: Uubntu desktop 16.04 LTS
- Keystone ppa: 
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/queens-staging
- Mariadb: 10.0.33-MariaDB-0ubuntu0.16.04.1

** Affects: keystone
 Importance: Undecided
 Status: New

** Description changed:

  When I populate the keystone database with the following command:
  
  su -s /bin/sh -c "keystone-manage db_sync" keystone
  
  I got this error:
  
  DBError: (pymysql.err.InternalError) (1709, u'Index column size too large. 
The maximum column size is 767 bytes.') [SQL: u'\nCREATE TABLE migrate_version 
(\n\trepository_id VARCHAR(250) NOT NULL, \n\trepository_path TEXT, \n\tversion 
INTEGER, \n\tPRIMARY KEY (repository_id)\n)\n\n'] (Background on this error at: 
http://sqlalche.me/e/2j85)
  2018-03-09 00:31:18.480 19707 ERROR keystone
  
  Full errors: http://paste.openstack.org/show/695366/
  
- OS: Uubntu desktop 16.04 LTS
- Keystone ppa: 
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/queens-staging
- Mariadb: 10.0.33-MariaDB-0ubuntu0.16.04.1
+ - OS: Uubntu desktop 16.04 LTS
+ - Keystone ppa: 
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/queens-staging
+ - Mariadb: 10.0.33-MariaDB-0ubuntu0.16.04.1

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

Title:
  keystone db_sync error "Index column size too large. The maximum
  column size is 767 bytes."

Status in OpenStack Identity (keystone):
  New

Bug description:
  When I populate the keystone database with the following command:

  su -s /bin/sh -c "keystone-manage db_sync" keystone

  I got this error:

  DBError: (pymysql.err.InternalError) (1709, u'Index column size too large. 
The maximum column size is 767 bytes.') [SQL: u'\nCREATE TABLE migrate_version 
(\n\trepository_id VARCHAR(250) NOT NULL, \n\trepository_path TEXT, \n\tversion 
INTEGER, \n\tPRIMARY KEY (repository_id)\n)\n\n'] (Background on this error at: 
http://sqlalche.me/e/2j85)
  2018-03-09 00:31:18.480 19707 ERROR keystone

  Full errors: http://paste.openstack.org/show/695366/

  - OS: Uubntu desktop 16.04 LTS
  - Keystone ppa: 
https://launchpad.net/~ubuntu-cloud-archive/+archive/ubuntu/queens-staging
  - Mariadb: 10.0.33-MariaDB-0ubuntu0.16.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1754376/+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 1743445] Re: Switch from msgpack-python to msgpack

[Matthew Thode]

** Changed in: openstack-requirements
   Status: In Progress => Fix Released

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

Title:
  Switch from msgpack-python to msgpack

Status in Ceilometer:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in OpenStack Global Requirements:
  Fix Released
Status in oslo.privsep:
  Fix Released
Status in oslo.serialization:
  Fix Released
Status in tooz:
  Fix Released

Bug description:
  msgpack-python has been renamed to msgpack, see
  https://pypi.python.org/pypi/msgpack-python/0.5.1:

  
  This package is deprecated. Install msgpack instead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1743445/+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 1754360] [NEW] no unquiesce for volume backed on quiesce failure

[Eric M Gonzalez]

Public bug reported:

Extension of bug #1731986;

The above bug and fix catches errors that occur during the snapshot of
an instance's volumes. I later discovered that a failure can occur
during the call to quisce_instance() that raises an uncaught Exceptions
through snapshot_volume_backed() that can leave the instance frozen /
quiesced.

Replication is tricky; my failures result during the RPC call to the
compute host and a MessagingTimeout waiting for a reply. I have not
found a way to handily replicate this. My compute combination is: Nova
Mitaka, Libvirt-1.3.1, & Ceph Jewel

Similar to the above bug, this condition was discovered in Mitaka and
the issue remains in Queens.

My proposed patch adds a blanket Exception catch around the call to
rpcapi.quiesce_instance(), logs the caught exception, and issues an
immediate rpcapi.unquiesce_instance() in order to thaw the instance.

Stack trace from nova-api-os container, responsible for quiesce /
unquiesce of instance during snapshot:

[req-6229d689-dcc3-41ca-99b5-3dfc04e1e994 50505ffa89754660b4e6f7ebf69532b5 
24bfcdab70714b85b5cb9f5f8270a414 - - -] Unexpected exception in API method
Traceback (most recent call last):
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/api/openstack/extensions.py",
 line 478, in wrapped
return f(*args, **kwargs)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/api/openstack/common.py",
 line 391, in inner
return f(*args, **kwargs)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/api/validation/__init__.py",
 line 73, in wrapper
return func(*args, **kwargs)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/api/validation/__init__.py",
 line 73, in wrapper
return func(*args, **kwargs)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/api/openstack/compute/servers.py",
 line 1108, in _action_create_image
metadata)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/compute/api.py", 
line 140, in inner
return f(self, context, instance, *args, **kw)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/compute/api.py", 
line 2389, in snapshot_volume_backed
mapping=None)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 220, in __exit__
self.force_reraise()
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_utils/excutils.py",
 line 196, in force_reraise
six.reraise(self.type_, self.value, self.tb)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/compute/api.py", 
line 2368, in snapshot_volume_backed
self.compute_rpcapi.quiesce_instance(context, instance)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/nova/compute/rpcapi.py",
 line 1041, in quiesce_instance
return cctxt.call(ctxt, 'quiesce_instance', instance=instance)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_messaging/rpc/client.py",
 line 158, in call
retry=self.retry)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_messaging/transport.py",
 line 90, in _send
timeout=timeout, retry=retry)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py",
 line 470, in send
retry=retry)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py",
 line 459, in _send
result = self._waiter.wait(msg_id, timeout)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py",
 line 342, in wait
message = self.waiters.get(msg_id, timeout=timeout)
  File 
"/openstack/venvs/nova-13.3.7/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py",
 line 244, in get
'to message ID %s' % msg_id)
MessagingTimeout: Timed out waiting for a reply to message ID 
70ee5f80284b4b68a289bf232b89325c

** Affects: nova
 Importance: Undecided
 Assignee: Eric M Gonzalez (egrh3)
 Status: In Progress

** Patch added: "master.a4f926b8e1.unquisece_on_quiesce_failure.patch"
   
https://bugs.launchpad.net/bugs/1754360/+attachment/5073086/+files/master.a4f926b8e1.unquisece_on_quiesce_failure.patch

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

Title:
  no unquiesce for volume backed on quiesce failure

Status in OpenStack Compute (nova):
  In Progress

Bug description:
  Extension of bug #1731986;

  The above bug and fix catches errors that occur during the snapshot of
  an instance's volumes. I later discovered that a failure can occur
  during the call to quisce_instance() that raises an uncaught
  Exceptions through snapshot_volume_backed() that can leave the
  instance frozen / quiesced.

  Replication is tricky; my failures result during the RPC call to the
  

[Yahoo-eng-team] [Bug 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Andres Rodriguez]

** Changed in: maas
   Importance: High => Medium

** Changed in: maas
   Status: Won't Fix => Triaged

** Changed in: maas
   Importance: Medium => Low

** Changed in: maas
Milestone: None => 2.4.x

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

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1750884/+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 1748153] Re: Proper error message should get displayed while trying to delete router interface

[Puneet Arora]

** Project changed: horizon => neutron

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

Title:
  Proper error message should get displayed while trying to delete
  router interface

Status in neutron:
  New

Bug description:
  Steps:
  1) Create network, subnet
  2) Create router and attach subnet to router.
  3) Attach router to external network as a gateway.
  4) Create port and associate port to floatingip.
  5) Goto Horizon and try to delete router-interface, it doesn't gives you 
proper error message.

  Error message on Horizon:
  Error: Unable to delete interface: (5148c328-d7df)

  But same If I try to delete from cli, it throws proper error message:
  $ neutron router-interface-delete 273b224e-033e-4fb4-89ca-6a7fcca595bd 
4b00cb1e-75df-4555-88c3-66dfb826e295
  neutron CLI is deprecated and will be removed in the future. Use openstack 
CLI instead.
  Router interface for subnet 4b00cb1e-75df-4555-88c3-66dfb826e295 on router 
273b224e-033e-4fb4-89ca-6a7fcca595bd cannot be deleted, as it is required by 
one or more floating IPs.

  Can we make changes on horizon side also to provide proper error
  message just like cli throws message?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1748153/+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 1748156] Re: Proper error message should get displayed while trying to delete dhcp port from horizon

[Puneet Arora]

** Project changed: horizon => neutron

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

Title:
  Proper error message should get displayed while trying to delete dhcp
  port from horizon

Status in neutron:
  New

Bug description:
  Steps
  1) Login to openstack horizon
  2) Create network and subnet .
  3) Goto admin --> Networks --> Ports and check there would be dhcp port 
listed.
  4) Try to delete dhcp port, exception appears on horizon "Error: Unable to 
delete port: (c33a1942-fa07)".

  But same if I try to delete from cli it throws proper error message:

  $ neutron port-delete c33a1942-fa07-454a-95ac-d0e6a52ff481
  neutron CLI is deprecated and will be removed in the future. Use openstack 
CLI instead.
  Bad port request: Can not delete DHCP port 
c33a1942-fa07-454a-95ac-d0e6a52ff481.

  From cli proper message gets displayed. Can we make changes on horizon
  side also to provide proper error message while deleting dhcp port?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1748156/+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 1750884] Re: [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic, leads to no DNS resolution

[Mike Pontillo]

** Changed in: maas
   Status: Triaged => Won't Fix

** Changed in: maas
 Assignee: Mike Pontillo (mpontillo) => (unassigned)

** Changed in: maas
Milestone: 2.4.0alpha2 => None

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

Title:
  [2.4, bionic] /etc/resolv.conf not configured correctly in Bionic,
  leads to no DNS resolution

Status in cloud-init:
  New
Status in MAAS:
  Triaged
Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  When deploying Bionic, /etc/resolv.conf is not configured correctly,
  which leads to no DNS resolution. In the output below, you will see
  that netplan config is correctly to the 10.90.90.1 nameserver, but in
  resolv.conf that's a local address.

  Resolv.conf should really be configured to use the provided DNS
  server(s). That said, despite that fact, DNS resolution doesn't work
  with the local address.

  Bionic
  --

  ubuntu@node01:~$ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  enp0s25:
  match:
  macaddress: b8:ae:ed:7d:17:d2
  mtu: 1500
  nameservers:
  addresses:
  - 10.90.90.1
  search:
  - maaslab
  - maas
  set-name: enp0s25
  bridges:
  br0:
  addresses:
  - 10.90.90.3/24
  gateway4: 10.90.90.1
  interfaces:
  - enp0s25
  parameters:
  forward-delay: 15
  stp: false
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 127.0.0.53

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  ping: google.com: Temporary failure in name resolution

  [...]

  ubuntu@node01:~$ sudo vim /etc/resolv.conf
  ubuntu@node01:~$ cat /etc/resolv.conf
  # This file is managed by man:systemd-resolved(8). Do not edit.
  #
  # 127.0.0.53 is the systemd-resolved stub resolver.
  # run "systemd-resolve --status" to see details about the actual nameservers.
  nameserver 10.90.90.1

  search maaslab maas
  ubuntu@node01:~$ ping google.com
  PING google.com (172.217.0.174) 56(84) bytes of data.
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=1 ttl=52 
time=4.46 ms
  64 bytes from mia09s16-in-f14.1e100.net (172.217.0.174): icmp_seq=2 ttl=52 
time=4.38 ms

  =
  Xenial
  ==

  ubuntu@node05:~$ cat /etc/network/interfaces.d/50-cloud-init.cfg
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  auto lo
  iface lo inet loopback
  dns-nameservers 10.90.90.1
  dns-search maaslab maas

  auto enp0s25
  iface enp0s25 inet static
  address 10.90.90.162/24
  gateway 10.90.90.1
  mtu 1500
  ubuntu@node05:~$ cat /etc/resolv.conf
  # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  nameserver 10.90.90.1
  search maaslab maas

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