Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1519952 - Ambiguous output check for failure [NEEDINFO]
Summary: Ambiguous output check for failure
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Gluster Storage
Classification: Red Hat
Component: cns-deploy-tool
Version: cns-3.6
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: CNS 3.10
Assignee: Jose A. Rivera
QA Contact: Ashmitha Ambastha
URL:
Whiteboard:
Depends On:
Blocks: 1568861
TreeView+ depends on / blocked
 
Reported: 2017-12-01 18:55 UTC by Farid Saad
Modified: 2018-12-15 07:09 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-09-12 09:27:30 UTC
jrivera: needinfo? (madam)


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2018:2685 None None None 2018-09-12 09:28:07 UTC
Github gluster gluster-kubernetes pull 329 None None None 2018-05-07 14:18:57 UTC

Description Farid Saad 2017-12-01 18:55:41 UTC
Description of problem:
Came across this issue while attempting a CNS Gluster installation using cns-deploy tool calling it from Ansible. The installation script received the following output (among a lot more):
"Unable to use a TTY - input is not a terminal or the right kind of file"

Which by itself is harmless and should allow the installation to continue, yet the cns-deploy script is catching it with this check which I presume was intended for more critical problems:
===
  load_temp=$(mktemp)
  eval_output "${heketi_cli} topology load --json=/etc/heketi/topology.json 2>&1" | tee "${load_temp}"
  grep -q "Unable" "${load_temp}"
  unable=$?
  rm "${load_temp}"

  if [[ ${PIPESTATUS[0]} -ne 0 ]] || [[ ${unable} -eq 0 ]]; then
    output "Error loading the cluster topology."
    if [[ ${unable} -eq 0 ]]; then
      output "Please check the failed node or device and rerun this script."
    fi
    exit 1
  else
    output "heketi topology loaded."
  fi
===
Grepping from "Unable" is catching more problems than it probably should.

Version-Release number of selected component (if applicable):
5.0.0-54.el7rhgs.x86_64

How reproducible:
Running cns-deploy from Ansible via 'shell' command.

Steps to Reproduce:
Attempt a cns-deploy CNS installation from an ansible playbook:
# cat cns-deploy.yaml
- hosts: localhost
  tasks:

  - name: Deploy CNS
    shell: cns-deploy -y -v -g -n {{ storage_project }} --daemonset-label "{{ ds_label}}" --admin-key "{{ admin_key }}" --user-key "{{ user_key }}" --block-host {{ block_host_gb }} /tmp/topology.json

Actual results:

Determining heketi service URL ... OK
/usr/bin/oc -n gstorage02 exec -it deploy-heketi-1-tzbnr -- heketi-cli -s http://localhost:8080 --user admin --secret 'labadmin' topology load --json=/etc/heketi/topolo
gy.json 2>&1
Unable to use a TTY - input is not a terminal or the right kind of file
Creating cluster ... ID: 33971076ec3e75e1aab504a4d330eaa9
Allowing file volumes on cluster.
Allowing block volumes on cluster.
Creating node vlcapocp10.fisdev.local ... ID: 071de24ae4da6bbd7d2b3a0786692e8a
Adding device /dev/sdd ... OK
Creating node vlcapocp11.fisdev.local ... ID: 02dcb12755a98b86494d712c541acace
Adding device /dev/sdd ... OK
Creating node vlcapocp12.fisdev.local ... ID: 0c0abfe874201c2d06844682819a1a12
Adding device /dev/sdd ... OK
Error loading the cluster topology.
Please check the failed node or device and rerun this script.

Expected results:
Script to complete successfully

Additional info:

Comment 10 Jose A. Rivera 2018-05-30 12:11:26 UTC
Since this should already be fixed, moving this to ON_QA.

Comment 11 Jose A. Rivera 2018-06-12 20:01:12 UTC
Thinking on this a bit more.... do we want to even try verifying this? cns-deploy for all intents and purposes should be deprecated, and we are certainly no longer supporting CNS 3.6.

Michael, thoughts?

Comment 12 Ashmitha Ambastha 2018-07-10 09:59:36 UTC
Verified this bug on the builds, OCP - v3.10.0-0.58.0 and cns-deploy-7.0.0-1.el7rhgs. Moving it to Verified.

Comment 14 errata-xmlrpc 2018-09-12 09:27:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2018:2685


Note You need to log in before you can comment on or make changes to this bug.