Description of problem: While executing cpma utility, it missed to config hostname's value, which caused that it's unable to find config files Version-Release number of selected component (if applicable): OCP 3.7 commit id: bbf1f97aaf646f94691c46ee520c823520bb73c1 How reproducible: always Steps to Reproduce: 1. execute cpma utility with local model Actual results: 1. It doesn't ask customer to input hostname's value $ ./bin/cpma ? Do you wish to save configuration for future use? true ? What will be the source for OCP3 config files? Local ? Path to crio config file /etc/crio/crio.conf ? Path to etcd config file /etc/etcd/etcd.conf ? Path to master config file /etc/origin/master/master-config.yaml ? Path to node config file /etc/origin/node/node-config.yaml ? Path to registries config file /etc/containers/registries.conf ? What will be the source for cluster name used to connect to API? Select kubeconfig context ? Select cluster obtained from KUBECONFIG contexts ci-vm-10-0-151-250-hosted-upshift-rdu2-redhat-com:8443 ? Path to application data, skip to use current directory data INFO[02 Sep 19 22:23 CST] Starting manifest and report generation INFO[02 Sep 19 22:23 CST] Transform:Starting for - API INFO[02 Sep 19 22:23 CST] APITransform::Extract WARN[02 Sep 19 22:23 CST] Skipping API: open data/etc/origin/master/master-config.yaml: no such file or directory INFO[02 Sep 19 22:23 CST] Transform:Starting for - Cluster .... 2. checked the generated cpma.yaml, it missed hostname's value $ cat ~/cpma.yaml clustername: ci-vm-10-0-151-250-hosted-upshift-rdu2-redhat-com:8443 configsource: local crioconfigfile: /etc/crio/crio.conf debug: false etcdconfigfile: /etc/etcd/etcd.conf fetchfromremote: false home: /Users/xinjiang hostname: "" insecurehostkey: false Expected results: it should config hostname's value in cpma.yaml. Additional info:
I confirm the issue, thanks for reporting it.
This issue has been addressed with upstream patch https://github.com/fusor/cpma/pull/385.
Backported to release-1.0 and available in latest corresponding build.
Verified and it works well. Git commit id: commit 006c5698376dda59438d6b25e78f00ad1dd630a4 (HEAD -> release-1.0, origin/release-1.0)
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/RHBA-2019:3151