[Yahoo-eng-team] [Bug 1817839] [NEW] in container panel, on create folder form, when the name is empty, no error shown

2019-02-26 Thread pengyuesheng 
Public bug reported:

in container panel, on create folder form, when the name is empty, no
error shown

** Affects: horizon
 Importance: Undecided
 Assignee: pengyuesheng (pengyuesheng)
 Status: In Progress

** Changed in: horizon
 Assignee: (unassigned) => pengyuesheng (pengyuesheng)

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

Title:
  in container panel, on create folder form, when the name is empty, no
  error shown

Status in OpenStack Dashboard (Horizon):
  In Progress

Bug description:
  in container panel, on create folder form, when the name is empty, no
  error shown

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1817839/+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 1817833] [NEW] Check compute_id existence when nova-compute reports info to placement

2019-02-26 Thread xulei 
Public bug reported:

Description
===
According to https://bugs.launchpad.net/nova/+bug/1756179, Currently we delete 
a nova-compute service, will delete compute_node records, resource provider 
records and host mapping records in DB. I found if deleting service when 
nova-compute service is active, it's no problem for deleting compute_node 
records and resource_provider records in DB, but nova-compute will continue to 
report the old resource_provider uuid. So when we restart nova-compute to 
recover service, will rasie ResourceProviderCreationFailed.


Steps to reproduce
==
1. Check enviroment and resource_provider table.
# nova service-list | grep 'nova-compute'
| 3d9092b0-e164-4094-8672-1c855971218d | nova-compute | devstack-q | nova   
  | enabled | up|
MariaDB [placement]> select uuid,name from resource_providers;
+--++
| uuid | name   |
+--++
| edfff022-c19f-4720-85f9-fd947ae36b07 | devstack-q |
+--++

2. Deleting a compute service when nova-compute process is running, check 
resource_provider table.
# nova service-delete 3d9092b0-e164-4094-8672-1c855971218d
MariaDB [placement]> select * from resource_providers;
Empty set (0.00 sec)

3. Wait a minute, restart nova-compute process.
# systemctl restart devstack@n-cpu


Expected result
===
nova-compute work properly and report to resource_provider with new uuid.


Actual result
===
nova-compute raise 409 when creae a new uuid resource_provider, and report 'No 
resource provider with uuid 52943fd2-d700-416f-9e16-7fe4744979b3 found'.


I found if nova-compute running, it will resume the old uuid to 
resource_providers when this uuid is gone. So
current resource_provider uuid in DB is still 
'edfff022-c19f-4720-85f9-fd947ae36b07'. Then nova-compute will try to create a 
new resource provider with name 'devstack-q'. Unfortunately, the name column in 
tables is unique.

So I think we should check compute_id existence first, then update
resource_provider_tree. If not exist, rasie ComputeHostNotFound  instead
of reporting.

** Affects: nova
 Importance: Undecided
 Assignee: xulei (605423512-j)
 Status: New


** Tags: placement

** Changed in: nova
 Assignee: (unassigned) => xulei (605423512-j)

** Tags added: placement

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

Title:
  Check compute_id existence when nova-compute reports  info to
  placement

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  According to https://bugs.launchpad.net/nova/+bug/1756179, Currently we 
delete a nova-compute service, will delete compute_node records, resource 
provider records and host mapping records in DB. I found if deleting service 
when nova-compute service is active, it's no problem for deleting compute_node 
records and resource_provider records in DB, but nova-compute will continue to 
report the old resource_provider uuid. So when we restart nova-compute to 
recover service, will rasie ResourceProviderCreationFailed.

  
  Steps to reproduce
  ==
  1. Check enviroment and resource_provider table.
  # nova service-list | grep 'nova-compute'
  | 3d9092b0-e164-4094-8672-1c855971218d | nova-compute | devstack-q | nova 
| enabled | up|
  MariaDB [placement]> select uuid,name from resource_providers;
  +--++
  | uuid | name   |
  +--++
  | edfff022-c19f-4720-85f9-fd947ae36b07 | devstack-q |
  +--++

  2. Deleting a compute service when nova-compute process is running, check 
resource_provider table.
  # nova service-delete 3d9092b0-e164-4094-8672-1c855971218d
  MariaDB [placement]> select * from resource_providers;
  Empty set (0.00 sec)

  3. Wait a minute, restart nova-compute process.
  # systemctl restart devstack@n-cpu

  
  Expected result
  ===
  nova-compute work properly and report to resource_provider with new uuid.

  
  Actual result
  ===
  nova-compute raise 409 when creae a new uuid resource_provider, and report 
'No resource provider with uuid 52943fd2-d700-416f-9e16-7fe4744979b3 found'.

  
  I found if nova-compute running, it will resume the old uuid to 
resource_providers when this uuid is gone. So
  current resource_provider uuid in DB is still 
'edfff022-c19f-4720-85f9-fd947ae36b07'. Then nova-compute will try to create a 
new resource provider with name 'devstack-q'. Unfortunately, the name column in 
tables is unique.

  So I think we should check compute_id existence first, then update

[Yahoo-eng-team] [Bug 1797237] Re: Superfluous "Create attachment failed for volume" error in nova-api logs

2019-02-26 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/581453
Committed: 
https://git.openstack.org/cgit/openstack/nova/commit/?id=5bef746c9b50537dde47278a208c4457b42896d0
Submitter: Zuul
Branch:master

commit 5bef746c9b50537dde47278a208c4457b42896d0
Author: Ken'ichi Ohmichi 
Date:   Tue Jul 10 18:57:48 2018 +

Avoid BadRequest error log on volume attachment

At the gate, only AttachVolumeNegativeTest makes nova-api output
error log as a negative test case like:

  ERROR nova.volume.cinder [None req-dcc8814f-7439-44c8-872e-86ea51f4b319
   tempest-AttachVolumeNegativeTest-431575524
   tempest-AttachVolumeNegativeTest-431575524]
   [instance: ca526f93-e723-4372-a1c1-4fa03ffc1bd7]
   Create attachment failed for volume 0a6e6a92-f095-4ab7-803c-826934824418.
   Error: Invalid volume: Volume 0a6e6a92-f095-4ab7-803c-826934824418 status
 must be available or downloading (HTTP 400)
 (Request-ID: req-5e5074ea-cd12-43ed-9355-5db539ca9720)
   Code: 400:
   BadRequest: Invalid volume: Volume 0a6e6a92-f095-4ab7-803c-826934824418
 status must be available or downloading (HTTP 400)
 (Request-ID: req-5e5074ea-cd12-43ed-9355-5db539ca9720)

Operators don't need to take care of BadRequest cases in general because
that is due to end user mistakes. So this patch makes nova-api avoiding
such error log case.

Closes-Bug: #1797237

Change-Id: I22d9d974822282ffc3c0942d4766b135717dd369


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

Title:
  Superfluous "Create attachment failed for volume" error in nova-api
  logs

Status in OpenStack Compute (nova):
  Fix Released
Status in OpenStack Compute (nova) queens series:
  Triaged
Status in OpenStack Compute (nova) rocky series:
  Triaged

Bug description:
  The nova-api logs an error when trying to attach an in-use volume to a
  server:

  http://logs.openstack.org/91/607391/1/check/tempest-full-
  
py3/b5b4c63/controller/logs/screen-n-api.txt.gz?level=TRACE#_Oct_04_20_25_02_115652

  Oct 04 20:25:02.115652 ubuntu-xenial-rax-ord-0002619241
  devstack@n-api.service[12723]: ERROR nova.volume.cinder [None req-
  45be0f9a-8af9-4886-9ef8-d09895704e36 tempest-
  AttachVolumeNegativeTest-1174814842 tempest-
  AttachVolumeNegativeTest-1174814842] [instance:
  9b06c833-dd88-4dd0-a601-bf3dac884cb0] Create attachment failed for
  volume c87044fa-7299-4559-a605-0e5d92e4e50b. Error: Invalid volume:
  Volume c87044fa-7299-4559-a605-0e5d92e4e50b status must be available
  or downloading (HTTP 400) (Request-ID: req-c7739c6e-b110-4b0e-a0ee-
  62f3e530205e) Code: 400: cinderclient.exceptions.BadRequest: Invalid
  volume: Volume c87044fa-7299-4559-a605-0e5d92e4e50b status must be
  available or downloading (HTTP 400) (Request-ID: req-c7739c6e-b110
  -4b0e-a0ee-62f3e530205e)

  This is normal and handled by the compute API which results in a 400
  response to the user:

  Oct 04 20:25:02.123693 ubuntu-xenial-rax-ord-0002619241
  devstack@n-api.service[12723]: INFO nova.api.openstack.wsgi [None req-
  45be0f9a-8af9-4886-9ef8-d09895704e36 tempest-
  AttachVolumeNegativeTest-1174814842 tempest-
  AttachVolumeNegativeTest-1174814842] HTTP exception thrown: Invalid
  input received: Invalid volume: Volume
  c87044fa-7299-4559-a605-0e5d92e4e50b status must be available or
  downloading (HTTP 400) (Request-ID: req-c7739c6e-b110-4b0e-a0ee-
  62f3e530205e)

  We shouldn't log an error for that since it doesn't require operator
  intervention.

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1797237/+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 1760562] Re: [VPNaaS] Check subnets used by IPsec site connection

2019-02-26 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/538115
Committed: 
https://git.openstack.org/cgit/openstack/neutron-vpnaas/commit/?id=0edb0e68f1a2f673d1befa8833eab0ce7a1521ba
Submitter: Zuul
Branch:master

commit 0edb0e68f1a2f673d1befa8833eab0ce7a1521ba
Author: wujun 
Date:   Fri Jan 26 10:27:37 2018 +0800

Check the router interface subnet whether used by vpn connection

When the "ROUTER_INTERFACE BEFORE_DELETE event" is triggered, we
should check the router interface subnet whether used by vpn
connection except vpn service.

Co-Authored-By: Dongcan Ye 
Change-Id: Idfba6481d23d19ec368be8d79c0450a0b158dc75
Closes-Bug: #1760562


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

Title:
  [VPNaaS] Check subnets used by IPsec site connection

Status in neutron:
  Fix Released

Bug description:
  While removing an router interface, we should check that subnet
  whether used by IPsec site connection.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1760562/+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 1817821] [NEW] security_group API return 500 error if Neutron disable the extension

2019-02-26 Thread Yang Youseok 
Public bug reported:

Description
===
If Neutron disable security-group extension, Nova security group API could not 
handle the 404 exception which Neutron returns emitting 500 error. Security API 
in Nova is deprecated though I think it's better to wrap 404 exception instead 
of 500 error.

Steps to reproduce
==
0) Disable neutron security-group extension
   m2_conf.ini [security_group] enabled_security_group = false
1) Request Nova to control any security-group related functions
   

Expected result
===
Return 404 error from Nova

Actual result
=
Return 500 error from Nova

Environment
===
1. Exact version of OpenStack you are running. See the following
stable/ocata

2. Which hypervisor did you use?
Libvirt + KVM

2. Which storage type did you use?
Ceph

3. Which networking type did you use?
Neutron with linuxbridge

Logs & Configs
==
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions 
[req-7459f23d-d972-4826-8596-4b7ece999727 0a084841c373499198a43b6d09c72f4f 
e4ce445c7c644f1481d48c36f5d962fc - default default] Unexpected exception in API 
method
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions Traceback 
(most recent call last):
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/api/openstack/extensions.py", line 338, in wrapped
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions return 
f(*args, **kwargs)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/api/openstack/compute/security_groups.py", line 
194, in create
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions context, 
group_name, group_description)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/network/security_group/neutron_driver.py", line 
64, in create_security_group
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions 
six.reraise(*exc_info)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/network/security_group/neutron_driver.py", line 
50, in create_security_group
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions 
body).get('security_group')
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/network/neutronv2/api.py", line 113, in wrapper
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions ret = 
obj(*args, **kwargs)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
938, in create_security_group
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions return 
self.post(self.security_groups_path, body=body)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/network/neutronv2/api.py", line 113, in wrapper
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions ret = 
obj(*args, **kwargs)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
366, in post
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions 
headers=headers, params=params)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/network/neutronv2/api.py", line 113, in wrapper
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions ret = 
obj(*args, **kwargs)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
301, in do_request
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions 
self._handle_fault_response(status_code, replybody, resp)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/src/nova/nova/network/neutronv2/api.py", line 113, in wrapper
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions ret = 
obj(*args, **kwargs)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
276, in _handle_fault_response
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions 
exception_handler_v20(status_code, error_body)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions   File 
"/opt/openstack/lib/python2.7/site-packages/neutronclient/v2_0/client.py", line 
92, in exception_handler_v20
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions 
request_ids=request_ids)
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions NotFound: The 
resource could not be found.
2019-02-27 11:25:18.150 26387 ERROR nova.api.openstack.extensions
2019-02-27

[Yahoo-eng-team] [Bug 1817644] Re: Cloud-init not applying networking config

2019-02-26 Thread Dan Watkins 
This doesn't sound like a cloud-init bug to me.  If it's provided with
two sets of network configuration (in this case, on disk via curtin from
MAAS and from you via user-data), it's going to have to choose one.  If
it had chosen the user-data one here, then it wouldn't have been able to
provision at all, so I think it's also making the right choice about
which config to use.

I don't have a full mental model of MAAS, but I think it expects to own
the networking of the instances it manages.  (This is, perhaps, a MAAS
feature request, to support this workflow?)

As things stand (unless there is something MAAS can do to already
support this), I think you'll need to handle this "deprovisioning" step
yourself in the way you described in the bug report.

(I'm going to mark this as Invalid for cloud-init, but please do move it
back to New if you think that's incorrect!)

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

Title:
  Cloud-init not applying networking config

Status in cloud-init:
  Invalid
Status in MAAS:
  Incomplete

Bug description:
  Machines deployed via MaaS is not applying the network configuration
  as defined in the user_data cloud config file.

  To deploy we are using the following (where $user_data is base64 encoded the 
cloud-config file)
  maas  machine deploy  user_data=$user_data 

  The #cloud-config file consists of the following:
  *adding a user
  *install packages
  *allow password authentication
  *configure eno1 which assigns a static IP and tags VLAN (version 2 specified)

  The result is a successful deploy with all the above configurations
  applied *except* the network portion.

  /var/lib/instances/user-data.txt obtains the expected configuration as
  it was provided in the mass deploy command, including the network
  config.

  /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg file obtains the
  configuration which MaaS is configured for during commissioning which
  is DHCP *rather* than the configuration for a static IP address
  assignment and VLAN tag.

  In addition, while trying to debug cloud-init we are not able to
  successfully analyze /var/log/cloud-init.log and get the following
  error:

  ubuntu@test:/var/log$ sudo cloud-init analyze show -i ./cloud-init.log
  Traceback (most recent call last):
File "/usr/bin/cloud-init", line 11, in 
  load_entry_point('cloud-init==18.4', 'console_scripts', 'cloud-init')()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 904, in 
main
  get_uptime=True, func=functor, args=(name, args))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2514, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/analyze/__main__.py", line 
104, in analyze_show
  args.print_format)):
File "/usr/lib/python3/dist-packages/cloudinit/analyze/show.py", line 192, 
in show_events
  return generate_records(events, print_format=print_format)
File "/usr/lib/python3/dist-packages/cloudinit/analyze/show.py", line 175, 
in generate_records
  prev_evt = unprocessed.pop()
  IndexError: pop from empty list
  ubuntu@test:/var/log$

  Upon searching in this log file however, we can see the user accounts
  being created and packages installed but any reference to the network
  configuration which was passed via cloud-init doesn't seem to exist.
  It is confirmed that the user created exists and is functional as well
  as the packages defined are installed.

  
  We are able to manually apply network configuration via cloud-init by 
performing the following steps:

  #rename current curtin networking config file
  mv /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg 
/etc/cloud/cloud.cfg.d/50-curtin-networking.cfg.old

  #create new curtin networking config file with same permissions as original
  touch /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg

  #copy network: stanza from cloud-config file to 50-curtin-
  networking.cfg

  #clean and re-init
  cloud-init clean
  cloud-init init

  #test network config 
  netplan try

  Result here is success where the static IP is accessible on the NIC.

  For reference the switch-port config for eno1 for this node is as follows:
  *default/native vlan XXX
  *vlan tagged on that interface YYY
  **goal here is to PXE on the network VLAN XXX and then jump to live network 
during deloyments which then should put the server on VLAN YYY, our production 
network.

  We cannot achieve this success with the MaaS deployments and would
  like some assistance to debug this issue.

  Thank you all in advance.


  
  mgaribaldi@maas-rack16:/var/log/maas$ dpkg -l '*maas*'|cat
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err:

[Yahoo-eng-team] [Bug 1817780] [NEW] Install and configure in keystone

2019-02-26 Thread Patrick Lepak 
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: In the "Finalize the installation" 
section, Step 2 displays the values that must be provided to configure an 
administrative account, but it does not specify where or how those values 
should be applied. Secondly, the "Configure the Apache HTTP server" section 
states to configure the ServerName option, but it is not made clear that no 
default value exists for ServerName. The entire line must be created by the 
user. If the user thinks to look for an existing ServerName value, they will 
not find one.
- [ ] 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.3.dev1 on 2018-11-21 21:10
SHA: 34185638dbf5f4421a44e44c7c245517eb79c938
Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.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/1817780

Title:
  Install and configure in keystone

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: In the "Finalize the installation" 
section, Step 2 displays the values that must be provided to configure an 
administrative account, but it does not specify where or how those values 
should be applied. Secondly, the "Configure the Apache HTTP server" section 
states to configure the ServerName option, but it is not made clear that no 
default value exists for ServerName. The entire line must be created by the 
user. If the user thinks to look for an existing ServerName value, they will 
not find one.
  - [ ] 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.3.dev1 on 2018-11-21 21:10
  SHA: 34185638dbf5f4421a44e44c7c245517eb79c938
  Source: 
https://git.openstack.org/cgit/openstack/keystone/tree/doc/source/install/keystone-install-ubuntu.rst
  URL: 
https://docs.openstack.org/keystone/queens/install/keystone-install-ubuntu.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1817780/+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 1817769] [NEW] Token validation failing with use of token caching.

2019-02-26 Thread prashkre 
Public bug reported:

In stein, with use of token caching, token deserialization is returning
list object instead of keystone.models.token_model.TokenModel object
causing it to fail in token validation.


2019-02-26 12:59:07.813 12027 WARNING keystone.server.flask.application 
[req-352b9795-976e-4346-8bca-00692b814ad5 - - - - -] Authorization failed. The 
request you have made requires authentication. from 9.114.192.69: Unauthorized: 
The request you have made requires authentication.
2019-02-26 12:59:08.228 12027 ERROR keystone.token.provider 
[req-16223960-fb19-4879-b4b2-ea409e4929c3 
f539d5d1e792c11dd599a0a30e2603027798f38069147c5b5ec6144e7755d849 
b4f8a3e36a844d31b9a0e3e7a9336ef7 - d2cfac6ed5cc481ab91bdeeea6af8e83 
d2cfac6ed5cc481ab91bdeeea6af8e83] Unexpected error or malformed token 
determining token expiry: [126, 
'\xde\x00\x1e\xc4\x07methods\x91\xa8password\xc4\x19application_credential_id\xc0\xc4\x0fparent_audit_id\xc0\xc4\x16_TokenModel__issued_at\xc4\x1b2019-02-26T17:59:07.00Z\xc4\tdomain_id\xc0\xc4\x08trust_id\xc0\xc4\x1a_TokenModel__trust_project\xc0\xc4\x07user_id\xd9@9db61c6bad18659d2d6f33e566e7cd6d55828c1b4a67365403760e2cae431dca\xc4\x06system\xc0\xc4\x02id\xd9\xf7gABcdX5raSAPS7bacoMPpETPCL3jXN_ryZXtgvh_I2tVMaL6nh4LJS3XPAbLrUh5xcwKu1PNAb0OUmSQQ5Rc1PK15ReYzz8mjzcMn4UMbpaMARRdSkk7fPK5n21sfhAV2DPJJy2uOUlEl3iInPAiUVHgcRnXLkr0gfr0dGYCJxul5ODNn85ItemuejLreKo25d4GK0xPmraeV5xSr0i30PDTzDVmuKQE_zs5vWQuNV89D1KvnQc\xc4\x13_TokenModel__domain\xc0\xc4\x0faccess_token_id\xc0\xc4\x18_TokenModel__user_domain\x85\xc4\x0bdescription\xd9#Domain
 for service users and groups\xc4\x07enabled\xc3\xc4\x02id\xd9 
d2cfac6ed5cc481ab91bdeeea6af8e83\xc4\x04name\xa7Service\xc4\x04tags\x90\xc4\x1b_TokenModel__project_domain\x85\xc4\x0bdescription\xd9#Domain
 for service users and groups\xc4\x07enabled\xc3\xc4\x02id\xd9 
d2cfac6ed5cc481ab91bdeeea6af8e83\xc4\x04name\xa7Service\xc4\x04tags\x90\xc4\x08audit_id\xb65gQ3yU0RQ5yI-ZDp_-PdNQ\xc4\x14_TokenModel__trustee\xc0\xc4\x14_TokenModel__trustor\xc0\xc4\x19_TokenModel__access_token\xc0\xc4\x17_TokenModel__expires_at\xc4\x1b2019-02-26T23:59:07.00Z\xc4\x10federated_groups\xc0\xc4\x0euser_domain_id\xd9
 
d2cfac6ed5cc481ab91bdeeea6af8e83\xc4\x0bprotocol_id\xc0\xc4\x12_TokenModel__trust\xc0\xc4#_TokenModel__application_credential\xc0\xc4\x0cis_federated\xc2\xc4\nproject_id\xd9
 
b4f8a3e36a844d31b9a0e3e7a9336ef7\xc4!_TokenModel__trust_project_domain\xc0\xc4\x14identity_provider_id\xc0\xc4\x11_TokenModel__user\x87\xc4\x13password_expires_at\xc0\xabdescription\xa9nova
 user\xc4\x07enabled\xc3\xc4\tdomain_id\xd9 
d2cfac6ed5cc481ab91bdeeea6af8e83\xc4\x07options\x80\xc4\x02id\xd9@9db61c6bad18659d2d6f33e566e7cd6d55828c1b4a67365403760e2cae431dca\xc4\x04name\xa4nova\xc4\x14_TokenModel__project\x88\xc4\tis_domain\xc2\xc4\x0bdescription\xd9/IBM
 Service Tenant for service users and 
groups\xc4\x04tags\x90\xc4\x07enabled\xc3\xc4\x02id\xd9 
b4f8a3e36a844d31b9a0e3e7a9336ef7\xc4\tparent_id\xd9 
d2cfac6ed5cc481ab91bdeeea6af8e83\xc4\tdomain_id\xd9 
d2cfac6ed5cc481ab91bdeeea6af8e83\xc4\x04name\xa7service']: AttributeError: 
'list' object has no attribute 'expires_at'
2019-02-26 12:59:08.228 12027 ERROR keystone.token.provider Traceback (most 
recent call last):
2019-02-26 12:59:08.228 12027 ERROR keystone.token.provider   File 
"/usr/lib/python2.7/site-packages/keystone/token/provider.py", line 184, in 
_is_valid_token
2019-02-26 12:59:08.228 12027 ERROR keystone.token.provider expiry = 
timeutils.parse_isotime(token.expires_at)
2019-02-26 12:59:08.228 12027 ERROR keystone.token.provider AttributeError: 
'list' object has no attribute 'expires_at'

** Affects: keystone
 Importance: Undecided
 Status: New

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

Title:
  Token validation failing with use of token caching.

Status in OpenStack Identity (keystone):
  New

Bug description:
  In stein, with use of token caching, token deserialization is
  returning list object instead of
  keystone.models.token_model.TokenModel object causing it to fail in
  token validation.

  
  2019-02-26 12:59:07.813 12027 WARNING keystone.server.flask.application 
[req-352b9795-976e-4346-8bca-00692b814ad5 - - - - -] Authorization failed. The 
request you have made requires authentication. from 9.114.192.69: Unauthorized: 
The request you have made requires authentication.
  2019-02-26 12:59:08.228 12027 ERROR keystone.token.provider 
[req-16223960-fb19-4879-b4b2-ea409e4929c3 
f539d5d1e792c11dd599a0a30e2603027798f38069147c5b5ec6144e7755d849 
b4f8a3e36a844d31b9a0e3e7a9336ef7 - d2cfac6ed5cc481ab91bdeeea6af8e83 
d2cfac6ed5cc481ab91bdeeea6af8e83] Unexpected error or malformed token 
determining token expiry: [126,

[Yahoo-eng-team] [Bug 1804517] Re: Remove obsolete idp policies from policy.v3cloudsample.json

2019-02-26 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/619376
Committed: 
https://git.openstack.org/cgit/openstack/keystone/commit/?id=c0e6d4498a7e6091212b2618a537eb786595397c
Submitter: Zuul
Branch:master

commit c0e6d4498a7e6091212b2618a537eb786595397c
Author: Lance Bragstad 
Date:   Wed Nov 21 22:26:25 2018 +

Remove idp policies from policy.v3cloudsample.json

By incorporating system-scope and default roles, we've effectively
made these policies obsolete. We can simplify what we maintain and
provide a more consistent, unified view of default idp behavior
by removing them.

Change-Id: I6091d1cdbc4e1fa3a3d5f83a707f003416a43ea0
Closes-Bug: 1804517


** 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 Identity (keystone).
https://bugs.launchpad.net/bugs/1804517

Title:
  Remove obsolete idp policies from policy.v3cloudsample.json

Status in OpenStack Identity (keystone):
  Fix Released

Bug description:
  Once support for scope types landed in the identity provider API
  policies, the policies in policy.v3cloudsample.json became obsolete
  [0][1].

  We should add formal protection for the policies with enforce_scope =
  True in keystone.tests.unit.protection.v3 and remove the old policies
  from the v3 sample policy file.

  This will reduce confusion by having a true default policy for
  identity providers.

  [0] https://review.openstack.org/#/c/526145/
  [1] 
https://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json?id=fb73912d87b61c419a86c0a9415ebdcf1e186927#n198

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1804517/+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 1817752] [NEW] Nova Compute errors when launch instance

2019-02-26 Thread light 
Public bug reported:

I launch an instance creation with the command: openstack server create
--flavor m1.small --image cirros --security-group secgroup01 --nic net-
id=$netID --key-name mykey instance

I get error

this a nova logs bellow

2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/neutronclient/v2_0/client.py", line 
282, in do_request
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi headers=headers)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/neutronclient/client.py", line 342, in 
do_request
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi 
self._check_uri_length(url)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/neutronclient/client.py", line 335, in 
_check_uri_length
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi uri_len = 
len(self.endpoint_url) + len(url)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/neutronclient/client.py", line 349, in 
endpoint_url
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi return 
self.get_endpoint()
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/adapter.py", line 247, in 
get_endpoint
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi return 
self.session.get_endpoint(auth or self.auth, **kwargs)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/session.py", line 1113, 
in get_endpoint
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi return 
auth.get_endpoint(self, **kwargs)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/identity/base.py", line 
380, in get_endpoint
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi 
allow_version_hack=allow_version_hack, **kwargs)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/identity/base.py", line 
271, in get_endpoint_data
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi service_catalog 
= self.get_access(session).service_catalog
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/identity/base.py", line 
134, in get_access
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi self.auth_ref = 
self.get_auth_ref(session)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/identity/generic/base.py",
 line 208, in get_auth_ref
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi return 
self._plugin.get_auth_ref(session, **kwargs)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/identity/v3/base.py", 
line 178, in get_auth_ref
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi 
authenticated=False, log=False, **rkwargs)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/session.py", line 1019, 
in post
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi return 
self.request(url, 'POST', **kwargs)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi   File 
"/usr/local/lib/python3.6/dist-packages/keystoneauth1/session.py", line 869, in 
request
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi raise 
exceptions.from_response(resp, method, url)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi 
keystoneauth1.exceptions.http.GatewayTimeout: Gateway Timeout (HTTP 504)
2019-02-26 15:44:17.610 2863 ERROR nova.api.openstack.wsgi
2019-02-26 15:45:16.632 2863 INFO nova.api.openstack.wsgi 
[req-f5cff5c7-0bec-4885-af15-a74c6dbf65fa 2aedac776fe7458d966b685c4ec83283 
e03854cd7f9b4dacb509404d33caf86b - default default] HTTP exception thrown: 
Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and 
attach the Nova API log if possible.

2019-02-26 15:45:18.634 2863 INFO nova.osapi_compute.wsgi.server 
[req-f5cff5c7-0bec-4885-af15-a74c6dbf65fa 2aedac776fe7458d966b685c4ec83283 
e03854cd7f9b4dacb509404d33caf86b - default default] 192.168.1.52 "POST 
/v2.1/e03854cd7f9b4dacb509404d33caf86b/servers HTTP/1.1" status: 500 len: 651 
time: 544.7109623

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

Title:
  Nova Compute errors when launch instance

Status in OpenStack Compute (nova):
  New

Bug description:
  I launch an instance creation with the

[Yahoo-eng-team] [Bug 1817670] Re: nova-compute could not destroy evacuated instance which was deleted

2019-02-26 Thread Matt Riedemann 
*** This bug is a duplicate of bug 1794996 ***
https://bugs.launchpad.net/bugs/1794996

This might already be fixed for bug 1794996:

https://review.openstack.org/#/q/I1f4b3540dd453650f94333b36d7504ba164192f7

But that was not backported to stable/ocata.

If that fixes your issue we could work on backporting
https://review.openstack.org/#/q/topic:bug/1550919+branch:stable/pike to
stable/ocata.

** This bug has been marked a duplicate of bug 1794996
   _destroy_evacuated_instances fails and kills n-cpu startup if lazy-loading 
flavor on a deleted instance

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

Title:
  nova-compute could not destroy evacuated instance which was deleted

Status in OpenStack Compute (nova):
  New

Bug description:
  Description
  ===
  After evacuation, nova-compute where VMs were evacuated could not restart 
emitting InstanceNotFound exception when init_host() called.

  
  Steps to reproduce
  ==
  0) service nova-compute stop at 'compute01'
  1) nova evacuate 'compute01'
  2) nova delete 'server at compute01'
  3) service nova-compute restart at 'compute01'

  
  Expected result
  ===
  nova-compute normally started

  Actual result
  =
  nova-compute could not started

  Environment
  ===
  1. Exact version of OpenStack you are running. See the following
list for all releases: http://docs.openstack.org/releases/

stable/ocata

  2. Which hypervisor did you use?
 (For example: Libvirt + KVM, Libvirt + XEN, Hyper-V, PowerKVM, ...)
 What's the version of that?
   
libvirt + kvm

  2. Which storage type did you use?
 (For example: Ceph, LVM, GPFS, ...)
 What's the version of that?

 Ceph

  
  3. Which networking type did you use?
 (For example: nova-network, Neutron with OpenVSwitch, ...)
 neutron with linux bridge   

  
  Logs & Configs
  ==
  2019-02-26 16:24:29.015 8901 INFO nova.virt.libvirt.driver 
[req-dc2a5061-29aa-4097-9a3e-83de36804460 - - - - -] [instance: 
25ab917a-1506-4154-9902-5b8b550ec929] Deleting instance files 
/var/lib/nova/instances/25ab917a-1506-4154-9902-5b8b550ec929_del
  2019-02-26 16:24:29.017 8901 INFO nova.virt.libvirt.driver 
[req-dc2a5061-29aa-4097-9a3e-83de36804460 - - - - -] [instance: 
25ab917a-1506-4154-9902-5b8b550ec929] Deletion of 
/var/lib/nova/instances/25ab917a-1506-4154-9902-5b8b550ec929_del complete
  2019-02-26 16:24:29.020 8901 DEBUG oslo_messaging._drivers.amqpdriver 
[req-dc2a5061-29aa-4097-9a3e-83de36804460 - - - - -] CALL msg_id: 
9bbf4371e977450d98a519dac213592b exchange 'nova' topic 'conductor' _send 
/opt/openstack/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:550
  2019-02-26 16:24:29.085 8901 DEBUG oslo_messaging._drivers.amqpdriver [-] 
received reply msg_id: 9bbf4371e977450d98a519dac213592b __call__ 
/opt/openstack/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:407
  2019-02-26 16:24:29.093 8901 DEBUG oslo_messaging._drivers.amqpdriver 
[req-dc2a5061-29aa-4097-9a3e-83de36804460 - - - - -] CAST unique_id: 
d5a0d3b93fbf42b6a379b9507e9c2a9a FANOUT topic 'scheduler' _send 
/opt/openstack/lib/python2.7/site-packages/oslo_messaging/_drivers/amqpdriver.py:539
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service 
[req-dc2a5061-29aa-4097-9a3e-83de36804460 - - - - -] Error starting thread.
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service Traceback (most 
recent call last):
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service   File 
"/opt/openstack/lib/python2.7/site-packages/oslo_service/service.py", line 722, 
in run_service
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service service.start()
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service   File 
"/opt/openstack/src/nova/nova/service.py", line 144, in start
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service 
self.manager.init_host()
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service   File 
"/opt/openstack/src/nova/nova/compute/manager.py", line 1155, in init_host
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service 
self._destroy_evacuated_instances(context)
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service   File 
"/opt/openstack/src/nova/nova/compute/manager.py", line 674, in 
_destroy_evacuated_instances
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service bdi, 
destroy_disks)
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service   File 
"/opt/openstack/src/nova/nova/virt/libvirt/driver.py", line 915, in destroy
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service destroy_disks, 
migrate_data)
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service   File 
"/opt/openstack/src/nova/nova/virt/libvirt/driver.py", line 1034, in cleanup
  2019-02-26 16:24:29.097 8901 ERROR oslo_service.service

[Yahoo-eng-team] [Bug 1657446] Re: Wrong timestamps in /var/log/cloud-init.log

2019-02-26 Thread Dan Watkins 
** Changed in: cloud-init
   Status: Incomplete => Fix Released

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

Title:
  Wrong timestamps in /var/log/cloud-init.log

Status in cloud-init:
  Fix Released

Bug description:
  Hi,

  The timestamps displayed in /var/log/cloud-init.log are different from
  the timestamps displayed in "journactl -u cloud-init".

  For example :

  $ head -n1 /var/log/cloud-init.log ; tail -n 1 /var/log/cloud-init.log
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Cloud-init v. 0.7.8 running 
'init-local' at Tue, 17 Jan 2017 23:22:36 +. Up 6.24 seconds.
  Jan 17 23:23:01 foo [CLOUDINIT] handlers.py[DEBUG]: finish: modules-final: 
SUCCESS: running modules for final

  Here, by looking at the timestamp at the beginning of the 2 lines, you
  could believe that cloud-init took 3 seconds to complete.

  However, there are several pieces of information that contradicts
  this.

  First, there is a discrepancy in the first line pasted above : the
  first timestamp says "Jan 17 23:22:58" but on the same line, you also
  have "at Tue, 17 Jan 2017 23:22:36 +."

  Then, there is the console log (this is an OpenStack VM), which shows
  :

  cloud-init[1050]: Cloud-init v. 0.7.8 running 'init' at Tue, 17 Jan 2017 
23:22:38 +. Up 7.55 seconds.
  [...]
  cloud-init[1690]: Cloud-init v. 0.7.8 running 'modules:final' at Tue, 17 Jan 
2017 23:23:00 +. Up 30.32 seconds.

  which hints that the run took ~23 seconds.

  Then, there are the various "duration" messages in /var/log/cloud-init.log :
  $ grep ' took ' /var/log/cloud-init.log
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'init' took 
0.530 seconds (0.53)
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Crawl of openstack metadata 
service took 18.093 seconds
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: resize_devices took 0.082 
seconds
  Jan 17 23:22:58 foo [CLOUDINIT] util.py[DEBUG]: Resizing took 0.048 seconds
  Jan 17 23:23:00 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' 
took 1.764 seconds (1.77)
  Jan 17 23:23:01 foo [CLOUDINIT] util.py[DEBUG]: cloud-init mode 'modules' 
took 0.240 seconds (0.24)

  The metadata discovery alone took 18s !

  And finally, it looks like the proper information is produced by "journactl 
-u cloud-init" :
  $ journalctl -u cloud-init |head -n2
  -- Logs begin at Tue 2017-01-17 23:22:35 UTC, end at Wed 2017-01-18 12:28:22 
UTC. --
  Jan 17 23:22:37 ubuntu systemd[1]: Starting Initial cloud-init job (metadata 
service crawler)...

  $ journalctl -u cloud-init |tail -n1
  Jan 17 23:22:57 foo systemd[1]: Started Initial cloud-init job (metadata 
service crawler).


  Could we please get the correct timestamps in /var/log/cloud-init.log
  ?

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1657446/+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 1817697] [NEW] [FwaasV1] Updating a ip address in firewall rule demands ip-version though it was accepted as default ipv4 while creating the rule

2019-02-26 Thread Bharath bhushan Patel 
Public bug reported:

Created a Firewall-rule with the following specifications
protocol: icmp
action: allow
destination-ip-address: 192.168.1.110
and while creating we dont have to specify any ip-version but while i try to 
update the same rule's destination ip, it asks for the ip-version

the firewall-rule-ip is
root@loadbalancer01:~# neutron firewall-rule-show rx-100
++--+
| Field  | Value|
++--+
| action | allow|
| description|  |
| destination_ip_address | 192.168.1.110|
| destination_port   |  |
| enabled| True |
| firewall_policy_id | deac8377-7e08-4dc8-a5f6-1f9e07f4aa9d |
| id | 89ddd54c-cb1f-4274-941e-ee0d11f9e36e |
| ip_version | 4|
| name   | rx-100   |
| position   | 1|
| project_id | 79e547b4eb6b43e287138dd7688a00e7 |
| protocol   | icmp |
| shared | False|
| source_ip_address  |  |
| source_port|  |
| tenant_id  | 79e547b4eb6b43e287138dd7688a00e7 |
++--+

but when i try to update:
root@loadbalancer01:~# neutron firewall-rule-update --destination-ip-address 
192.168.1.121 --protocol icmp rx-100
Invalid input - IP addresses do not agree with IP Version
Neutron server returns request_ids: ['req-f7df645c-e097-4b27-92a0-f94310106a06']


this must be handled in the fwaas driver to consider default as ip-versio 4 , 
as its while creating.

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

Title:
  [FwaasV1] Updating a ip address in firewall rule demands ip-version
  though it was accepted as default ipv4 while creating the rule

Status in neutron:
  New

Bug description:
  Created a Firewall-rule with the following specifications
  protocol: icmp
  action: allow
  destination-ip-address: 192.168.1.110
  and while creating we dont have to specify any ip-version but while i try to 
update the same rule's destination ip, it asks for the ip-version

  the firewall-rule-ip is
  root@loadbalancer01:~# neutron firewall-rule-show rx-100
  ++--+
  | Field  | Value|
  ++--+
  | action | allow|
  | description|  |
  | destination_ip_address | 192.168.1.110|
  | destination_port   |  |
  | enabled| True |
  | firewall_policy_id | deac8377-7e08-4dc8-a5f6-1f9e07f4aa9d |
  | id | 89ddd54c-cb1f-4274-941e-ee0d11f9e36e |
  | ip_version | 4|
  | name   | rx-100   |
  | position   | 1|
  | project_id | 79e547b4eb6b43e287138dd7688a00e7 |
  | protocol   | icmp |
  | shared | False|
  | source_ip_address  |  |
  | source_port|  |
  | tenant_id  | 79e547b4eb6b43e287138dd7688a00e7 |
  ++--+

  but when i try to update:
  root@loadbalancer01:~# neutron firewall-rule-update --destination-ip-address 
192.168.1.121 --protocol icmp rx-100
  Invalid input - IP addresses do not agree with IP Version
  Neutron server returns request_ids: 
['req-f7df645c-e097-4b27-92a0-f94310106a06']

  
  this must be handled in the fwaas driver to consider default as ip-versio 4 , 
as its while creating.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1817697/+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 1817692] [NEW] [OCTAVIA] LB resources created with invalid option are remained as Stale on db

2019-02-26 Thread Bharath bhushan Patel 
*** This bug is a security vulnerability ***

Public security bug reported:

The Octavia has the following issue:
when we try to create a Listener with "protocol UDP" which is not supported, 
the LB ans Listener enter into ERROR state and Loadbalancer goes immutable and 
the resources related to the LB can never be deleted.

Here is the state after the Listener creation with UDP as protocol option for a 
LB created on OCTAVIA.
/usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py:144: UserWarning: 
The psycopg2 wheel package will be renamed from release 2.8; in order to kee
p installing from binary please use "pip install psycopg2-binary" instead. For 
details see: .
  """)
+---+--+
| Field | Value|
+---+--+
| admin_state_up| True |
| connection_limit  | -1   |
| created_at| 2019-02-14T12:41:31  |
| default_pool_id   | None |
| default_tls_container_ref | None |
| description   |  |
| id| c912df7d-0f5a-4fbf-bee6-34b9347b136b |
| insert_headers| None |
| l7policies|  |
| loadbalancers | a9266c7a-8442-4d98-b4af-6ac12ccc21c9 |
| name  |  |
| operating_status  | ERROR|
| project_id| 3010a9f826944cc2919536a94a501e80 |
| protocol  | UDP  |
| protocol_port | 80   |
| provisioning_status   | ERROR|
| sni_container_refs| []   |
| timeout_client_data   | 5|
| timeout_member_connect| 5000 |
| timeout_member_data   | 5|
| timeout_tcp_inspect   | 0|
| updated_at| 2019-02-14T12:41:55  |
+---+--+

nicira@utu1604template:~/devstack$ openstack loadbalancer show 
a9266c7a-8442-4d98-b4af-6ac12ccc21c9
/usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py:144: UserWarning: 
The psycopg2 wheel package will be renamed from release 2.8; in order to keep 
installing from binary please use "pip install psycopg2-binary" instead. For 
details see: 
.
  """)
+-+--+
| Field   | Value|
+-+--+
| admin_state_up  | True |
| created_at  | 2019-02-14T12:38:50  |
| description |  |
| flavor  |  |
| id  | a9266c7a-8442-4d98-b4af-6ac12ccc21c9 |
| listeners   | c912df7d-0f5a-4fbf-bee6-34b9347b136b |
| name| lb-1 |
| operating_status| ERROR|
| pools   |  |
| project_id  | 3010a9f826944cc2919536a94a501e80 |
| provider| vmwareedge   |
| provisioning_status | ERROR|
| updated_at  | 2019-02-14T12:41:55  |
| vip_address | 27.0.0.92|
| vip_network_id  | 0ff2733a-bd7a-42e5-ae7d-5a11314e6aa5 |
| vip_port_id | fa369c3f-9039-4b29-bd34-614485720fab |
| vip_qos_policy_id   | None |
| vip_subnet_id   | e33f5c09-4822-439b-86ac-3706f2cc81aa |
+-+--+
  

and Loadbalancer is immutable and im unable to delete the resources

nicira@utu1604template:~/devstack$ ^C
nicira@utu1604template:~/devstack$ openstack loadbalancer listener delete  
c912df7d-0f5a-4fbf-bee6-34b9347b136b
/usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py:144: UserWarning: 
The psycopg2 wheel package will be renamed from release 2.8; in order to keep 
installing from binary please use "pip install psycopg2-binary" instead. For 
details see: 
.
  """)
Load Balancer a9266c7a-8442-4d98-b4af-6ac12ccc21c9 is immutable and cannot be

[Yahoo-eng-team] [Bug 1817694] [NEW] [OCTAVIA]Wrong error message while updating healthmonitor's expected codes

2019-02-26 Thread Bharath bhushan Patel 
Public bug reported:

Created Loadbalancer resources with OCTAVIA, which consists of LB,
listener, pool, members and health monitor,

initially, health monitor was created without expected codes option
now 
trying to update the health-monitor's expected codes with some value , 
Wrong error message is returned by octavia driver, which is needed to be 
handled.

url_path is not valid option message is displayed on while trying to
update the healthmonitor with expected codes option

nicira@utu1604template:~/devstack$ openstack loadbalancer healthmonitor set 
--expected-codes 201 hm1
/usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py:144: UserWarning: 
The psycopg2 wheel package will be renamed from release 2.8; in order to keep 
installing from binary please use "pip install psycopg2-binary" instead. For 
details see: 
.
  """)
url_path is not a valid option for health monitors of type PING (HTTP 400) 
(Request-ID: req-97e59c78-10aa-438a-ab2e-98e4a2d1eaaa)


Here the message expected is:
"expected-codes is not a valid option"

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

Title:
  [OCTAVIA]Wrong error message while updating healthmonitor's expected
  codes

Status in neutron:
  New

Bug description:
  Created Loadbalancer resources with OCTAVIA, which consists of LB,
  listener, pool, members and health monitor,

  initially, health monitor was created without expected codes option
  now 
  trying to update the health-monitor's expected codes with some value , 
  Wrong error message is returned by octavia driver, which is needed to be 
handled.

  url_path is not valid option message is displayed on while trying to
  update the healthmonitor with expected codes option

  nicira@utu1604template:~/devstack$ openstack loadbalancer healthmonitor set 
--expected-codes 201 hm1
  /usr/local/lib/python2.7/dist-packages/psycopg2/__init__.py:144: UserWarning: 
The psycopg2 wheel package will be renamed from release 2.8; in order to keep 
installing from binary please use "pip install psycopg2-binary" instead. For 
details see: 
.
""")
  url_path is not a valid option for health monitors of type PING (HTTP 400) 
(Request-ID: req-97e59c78-10aa-438a-ab2e-98e4a2d1eaaa)

  
  Here the message expected is:
  "expected-codes is not a valid option"

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1817694/+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 1817541] Re: Bump pbr minimum version

2019-02-26 Thread OpenStack Infra 
Reviewed:  https://review.openstack.org/639074
Committed: 
https://git.openstack.org/cgit/openstack/neutron/commit/?id=c6ae4fb8a2195c5b8d4a88194a70d5aede61f647
Submitter: Zuul
Branch:master

commit c6ae4fb8a2195c5b8d4a88194a70d5aede61f647
Author: Rodolfo Alonso Hernandez 
Date:   Mon Feb 25 11:45:38 2019 +

Bump pbr version to 4.0.0

"tox-lower-constrains" tests are failing because of some old
dependencies in lowest "pbr" version (2.0.0). Those dependencies
were removed in [1]. pbr==4.0.0 contains this commit.

[1] 
https://github.com/openstack-dev/pbr/commit/32c90ba598d7740e52bf21bc5e920fb5df08645a

Change-Id: I7551644ccf65fae19b34eee49151fdafacf29843
Closes-Bug: #1817541


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

Title:
  Bump pbr minimum version

Status in neutron:
  Fix Released

Bug description:
  "tox-lower-constrains" are failing because of some old dependencies in
  lowest "pbr" version (2.0.0). Those dependencies were removed in [1].
  pbr==4.0.0 contains this commit.

  Error log: http://logs.openstack.org/48/638648/2/check/openstack-tox-
  lower-constraints/72b133e/job-output.txt.gz

  [1] https://github.com/openstack-
  dev/pbr/commit/32c90ba598d7740e52bf21bc5e920fb5df08645a

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1817541/+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 1817683] [NEW] Key pair not imported when passing cloud-init script on initiation

2019-02-26 Thread Jelle Leempoels 
Public bug reported:

Description
===

The public SSH key is not imported when an instance is created with a
key pair (key pair tab) + cloud-init script (configuration tab)

- Reproduced in dashboard (Horizon)
- Reproduced with python (nova.server.create())


Steps to reproduce
==
- Create an instance in the GUI
- with a key pair

Key pair is inserted

  [   22.212331] cloud-init[993]: Cloud-init v. 18.4-0ubuntu1~18.04.1 running 
'modules:config' at Tue, 26 Feb 
  2019 09:44:27 +. Up 21.13 seconds.
  [[0;32m  OK  [0m] Started Apply the settings specified in cloud-config.
 Starting Execute cloud user/final scripts...
  ci-info: +Authorized keys from /home/ubuntu/.ssh/authorized_keys for user 
ubuntu++
  ci-info: 
+-+-+-+-+
  ci-info: | Keytype |Fingerprint (md5)| 
Options | Comment |
  ci-info: 
+-+-+-+-+
  ci-info: | ssh-rsa | 36:b4:ea:45:0a:77:c4:87:c9:71:d5:78:6e:a5:ee:ba |-   
 |-|
  ci-info: 
+-+-+-+-+

  => login to VM with key pair
  -> Login successful 

- Create a second instance
  - with a key pair
  - pass a cloud-init script in the user configuration 

  #cloud-config
  chpasswd: 
expire: false
list: |
root:toor
jelle:jelle
  users: 
- name: jelle
  lock-passwd: false
  sudo: ['ALL=(ALL) NOPASSWD:ALL']
  groups: sudo
  shell: /bin/bash

==> Public key from the key-pair is not imported

[   21.472835] cloud-init[937]: Cloud-init v. 18.4-0ubuntu1~18.04.1 running 
'modules:config' at Tue, 26 Feb 2019 09:36:21 +. Up 20.47 seconds.
[[0;32m  OK  [0m] Started Apply the settings specified in cloud-config.
 Starting Execute cloud user/final scripts...
ci-info: no authorized ssh keys fingerprints found for user jelle.
<14>Feb 26 09:36:23 ec2: 
<14>Feb 26 09:36:23 ec2: 
#
<14>Feb 26 09:36:23 ec2: -BEGIN SSH HOST KEY FINGERPRINTS-
<14>Feb 26 09:36:23 ec2: 1024 
SHA256:mfFrY4zKFLuJPRF6Pw6z8suzBzA7jx21sife3MwEee4 root@test (DSA)
<14>Feb 26 09:36:23 ec2: 256 SHA256:JzA4J0A6oN5c1vTiGpTPBgqisb1IlxXBumlnk/Jg1Po 
root@test (ECDSA)
<14>Feb 26 09:36:23 ec2: 256 SHA256:j/mU93YAfgHxdrXJD0QT6SMFFoOzRvtES/YZ+9ZBNaM 
root@test (ED25519)
<14>Feb 26 09:36:23 ec2: 2048 
SHA256:Hy1gMvK/7hSoyIacAgx+C/jEHkbCi5yS9YbiYfcTVGo root@test (RSA)
<14>Feb 26 09:36:23 ec2: -END SSH HOST KEY FINGERPRINTS-
<14>Feb 26 09:36:23 ec2: 
#
-BEGIN SSH HOST KEY KEYS-
ecdsa-sha2-nistp256 
E2VjZHNhLXNoYTItbmlzdHAyNTYIbmlzdHAyNTYAAABBBGBMYWNnP97Znq6Al0LHqzUu8tOa3/T4fuh+PLAIW26b2361MarI/1HxxseRmCUgb45Gw5zXu7CfLhAlHaThirk=
 root@test
ssh-ed25519 
C3NzaC1lZDI1NTE5IJ54epYzeKPsUs8UXyac+nTPQGpNY2CQWwBQL4aEPZD6 root@test
ssh-rsa 
B3NzaC1yc2EDAQABAAABAQCwtmWLjZrRB4BVxcWAZt8/uWkkQhMCkrdNQTS40ZGTGto46MyBmyA+4RJxnZ8MV9I/8lpBt1EY5ERdf/5gDwN51wzq57LVuTz46mhYU3i85YECaE98VXG9I52OC0/UzgvlEbwEbVPlMh+ZVkNSkZu4Mcuvi0hvzU7+Z5p8CvWEMhIvtWAKbf/ujK0WzeYRwsqQfGm5hUH6TJSjFRCC/T1DosnM+hgDlNkiYGjlUE9LvSPRTX1rMfakUbWzK/EJWuGuYO21P/oORNDeJxWPZS/Y8cW+VCQbXCuXqXFst347Tvnl/kmZULjRJjB05eAV6Ejto2tRbCku49POA26/GzMj
 root@test
-END SSH HOST KEY KEYS-
[   22.295189] cloud-init[995]: Cloud-init v. 18.4-0ubuntu1~18.04.1 running 
'modules:final' at Tue, 26 Feb 2019 09:36:23 +. Up 22.06 seconds.
[   22.299328] cloud-init[995]: ci-info: no authorized ssh keys fingerprints 
found for user jelle.
[   22.301658] cloud-init[995]: Cloud-init v. 18.4-0ubuntu1~18.04.1 finished at 
Tue, 26 Feb 2019 09:36:23 +. Datasource DataSourceOpenStackLocal 
[net,ver=2].  Up 22.27 seconds

  => Login with keypair
  -> login fails


  
  Environment
  ===

  
  ubuntu@juju-5dc387-0-lxd-6:~$ nova-manage --version
  15.1.5

  ubuntu@juju-5dc387-0-lxd-6:~$ dpkg -l | grep nova
  ii  nova-api-os-compute  2:15.1.5-0ubuntu1~cloud0 
  all  OpenStack Compute - OpenStack Compute API frontend
  ii  nova-common  2:15.1.5-0ubuntu1~cloud0 
  all  OpenStack Compute - common files
  ii  nova-conductor   2:15.1.5-0ubuntu1~cloud0 
  all  OpenStack Compute - conductor service
  ii  nova-consoleauth 2:15.1.5-0ubuntu1~cloud0 
  all  OpenStack Compute - Console Authenticator
  ii  nova-novncproxy  2:15.1.5-0ubuntu1~cloud0 
  all  OpenStack Compute - NoVNC proxy
  ii  nova-placement-api   2:15.1.5-0ubuntu1~cloud0 
  all  OpenStack Compute - placement API frontend
  ii  nova-scheduler   2:15.1.5-0ubuntu1~cloud0

[Yahoo-eng-team] [Bug 1817644] Re: Cloud-init not applying networking config

2019-02-26 Thread Andres Rodriguez 
Hi Michael,

The question is, why are you sending cloud-init configuration with
network config when MAAS already sends one?

Have you considered the possibility that since you are sending duplicate
information, cloud-init may be failing altogether? That said, 50-curtin-
networking.cfg is the configuration that is passed to curtin and curtin
passes to cloud-init and it is *not* the configuration that you are
sending via user-data. That configuration is part of the user-data, not
part of files in /var/lib/cloud-init.

My guess here is that cloud-init is either ignoring this or failing to
run.

Could you please attach the /var/log/cloud-*.log from the system being
deployed?

** Also 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/1817644

Title:
  Cloud-init not applying networking config

Status in cloud-init:
  New
Status in MAAS:
  Incomplete

Bug description:
  Machines deployed via MaaS is not applying the network configuration
  as defined in the user_data cloud config file.

  To deploy we are using the following (where $user_data is base64 encoded the 
cloud-config file)
  maas  machine deploy  user_data=$user_data 

  The #cloud-config file consists of the following:
  *adding a user
  *install packages
  *allow password authentication
  *configure eno1 which assigns a static IP and tags VLAN (version 2 specified)

  The result is a successful deploy with all the above configurations
  applied *except* the network portion.

  /var/lib/instances/user-data.txt obtains the expected configuration as
  it was provided in the mass deploy command, including the network
  config.

  /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg file obtains the
  configuration which MaaS is configured for during commissioning which
  is DHCP *rather* than the configuration for a static IP address
  assignment and VLAN tag.

  In addition, while trying to debug cloud-init we are not able to
  successfully analyze /var/log/cloud-init.log and get the following
  error:

  ubuntu@test:/var/log$ sudo cloud-init analyze show -i ./cloud-init.log
  Traceback (most recent call last):
File "/usr/bin/cloud-init", line 11, in 
  load_entry_point('cloud-init==18.4', 'console_scripts', 'cloud-init')()
File "/usr/lib/python3/dist-packages/cloudinit/cmd/main.py", line 904, in 
main
  get_uptime=True, func=functor, args=(name, args))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2514, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/analyze/__main__.py", line 
104, in analyze_show
  args.print_format)):
File "/usr/lib/python3/dist-packages/cloudinit/analyze/show.py", line 192, 
in show_events
  return generate_records(events, print_format=print_format)
File "/usr/lib/python3/dist-packages/cloudinit/analyze/show.py", line 175, 
in generate_records
  prev_evt = unprocessed.pop()
  IndexError: pop from empty list
  ubuntu@test:/var/log$

  Upon searching in this log file however, we can see the user accounts
  being created and packages installed but any reference to the network
  configuration which was passed via cloud-init doesn't seem to exist.
  It is confirmed that the user created exists and is functional as well
  as the packages defined are installed.

  
  We are able to manually apply network configuration via cloud-init by 
performing the following steps:

  #rename current curtin networking config file
  mv /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg 
/etc/cloud/cloud.cfg.d/50-curtin-networking.cfg.old

  #create new curtin networking config file with same permissions as original
  touch /etc/cloud/cloud.cfg.d/50-curtin-networking.cfg

  #copy network: stanza from cloud-config file to 50-curtin-
  networking.cfg

  #clean and re-init
  cloud-init clean
  cloud-init init

  #test network config 
  netplan try

  Result here is success where the static IP is accessible on the NIC.

  For reference the switch-port config for eno1 for this node is as follows:
  *default/native vlan XXX
  *vlan tagged on that interface YYY
  **goal here is to PXE on the network VLAN XXX and then jump to live network 
during deloyments which then should put the server on VLAN YYY, our production 
network.

  We cannot achieve this success with the MaaS deployments and would
  like some assistance to debug this issue.

  Thank you all in advance.


  
  mgaribaldi@maas-rack16:/var/log/maas$ dpkg -l '*maas*'|cat
  Desired=Unknown/Install/Remove/Purge/Hold
  | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
  |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
  ||/ NameVersion
Architecture Description