The current "ir-install" and "ir-test" are both pointing to the same entry point as "ir-provision".
We should fix this to the installer folder and tester folder.

There's no use in this module atm.

See #54

Multiple placeholder tags in the same file, will crash with:

...
  File "/home/yfried/.virtualenvs/InfraRed/lib/python2.7/site-packages/yaml/representer.py", line 57, in represent_data
    node = self.yaml_representers[data_types[0]](self, data)
  File "/home/yfried/workspace/git/InfraRed/cli/yamls.py", line 310, in to_yaml
    message = re.sub("<string>", node.file_path, node.message)
  File "/home/yfried/.virtualenvs/InfraRed/lib64/python2.7/re.py", line 155, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "/home/yfried/.virtualenvs/InfraRed/lib64/python2.7/re.py", line 286, in _subx
    template = _compile_repl(template, pattern)
  File "/home/yfried/.virtualenvs/InfraRed/lib64/python2.7/re.py", line 271, in _compile_repl
    p = sre_parse.parse_template(repl, pattern)
  File "/home/yfried/.virtualenvs/InfraRed/lib64/python2.7/sre_parse.py", line 737, in parse_template
    s = Tokenizer(source)
  File "/home/yfried/.virtualenvs/InfraRed/lib64/python2.7/sre_parse.py", line 192, in __init__
    self.__next()
  File "/home/yfried/.virtualenvs/InfraRed/lib64/python2.7/sre_parse.py", line 194, in __next
    if self.index >= len(self.string):
TypeError: object of type 'NoneType' has no len()

I added new arguent in .spec file:

       - title: key_name
         options:
               key_name:
                   type: Value
                   help: The name of the key

When running ir-provision with the argument (like ir-provision openstack --image rhel-7.2) I still see the variable in the generated settings:

key_name: null

I would expect it to not be included in the settings at all. It makes it easier for us to check if the variable defined in Ansible tasks.

The all idea of this class is to create and return parsers which based on spec files - there is no a real need to create and instance of this class for that. Only need to call the 'get_specs' methos with the relevant module name.

There is a lot of problems installing IR on RHEL7.2, I noticed these major ones:

Missing prereqs in documentation:
$ yum install git python-virtualenv gcc

Missing pip
$ easy_install pip

pip install -e . # BUG
Obtaining file:///home/cloud-user/InfraRed
Running setup.py egg_info for package from file:///home/cloud-user/InfraRed
Traceback (most recent call last):
File "", line 16, in
File "/home/cloud-user/InfraRed/setup.py", line 9, in
install_reqs = req.parse_requirements('requirements.txt', session=False)
TypeError: parse_requirements() got an unexpected keyword argument 'session'
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "", line 16, in
File "/home/cloud-user/InfraRed/setup.py", line 9, in
install_reqs = req.parse_requirements('requirements.txt', session=False)
TypeError: parse_requirements() got an unexpected keyword argument 'session'
Cleaning up...

• workaround

  line 9 in InfraRed/setup.py remove ", session=False"

pip install -e . # BUG
Running setup.py install for python-keystoneclient
ImportError: No module named pytz
error in setup command: Error parsing /home/cloud-user/venv/build/python-keystoneclient/setup.cfg: ImportError: No module named pytz

• workaround
  pip install pytz

ir-provisioner --help # BUG # Seems to be fixed with https://github.com/rhosqeauto/InfraRed/pull/183
Traceback (most recent call last):
File "/home/cloud-user/venv/bin/ir-provisioner", line 5, in
from pkg_resources import load_entry_point
File "/home/cloud-user/venv/lib/python2.7/site-packages/pkg_resources.py", line 3007, in
working_set.require(requires)
File "/home/cloud-user/venv/lib/python2.7/site-packages/pkg_resources.py", line 728, in require
needed = self.resolve(parse_requirements(requirements))
File "/home/cloud-user/venv/lib/python2.7/site-packages/pkg_resources.py", line 626, in resolve
raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: functools32

• workaround
  pip install functools32

$ pip install -e .
Downloading/unpacking funcsigs>=0.4 (from oslo.utils>=3.5.0->python-novaclient>=2.21.0,!=2.27.0,!=2.32.0->infrared==0.0.1)
Downloading funcsigs-1.0.2.tar.gz
Running setup.py egg_info for package funcsigs
Traceback (most recent call last):
File "", line 16, in
File "/home/cloud-user/venv/build/funcsigs/setup.py", line 51, in
test_suite = 'unittest2.collector',
File "/usr/lib64/python2.7/distutils/core.py", line 112, in setup
_setup_distribution = dist = klass(attrs)
File "/home/cloud-user/venv/lib/python2.7/site-packages/setuptools/dist.py", line 265, in init
self.fetch_build_eggs(attrs.pop('setup_requires'))
File "/home/cloud-user/venv/lib/python2.7/site-packages/setuptools/dist.py", line 289, in fetch_build_eggs
parse_requirements(requires), installer=self.fetch_build_egg
File "/home/cloud-user/venv/lib/python2.7/site-packages/pkg_resources.py", line 630, in resolve
raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (setuptools 0.9.8 (/home/cloud-user/venv/lib/python2.7/site-packages), Requirement.parse('setuptools>=17.1'))
Complete output from command python setup.py egg_info:
Traceback (most recent call last):
File "", line 16, in
File "/home/cloud-user/venv/build/funcsigs/setup.py", line 51, in
test_suite = 'unittest2.collector',
File "/usr/lib64/python2.7/distutils/core.py", line 112, in setup
_setup_distribution = dist = klass(attrs)
File "/home/cloud-user/venv/lib/python2.7/site-packages/setuptools/dist.py", line 265, in init
self.fetch_build_eggs(attrs.pop('setup_requires'))
File "/home/cloud-user/venv/lib/python2.7/site-packages/setuptools/dist.py", line 289, in fetch_build_eggs
parse_requirements(requires), installer=self.fetch_build_egg
File "/home/cloud-user/venv/lib/python2.7/site-packages/pkg_resources.py", line 630, in resolve
raise VersionConflict(dist,req) # XXX put more info here
pkg_resources.VersionConflict: (setuptools 0.9.8 (/home/cloud-user/venv/lib/python2.7/site-packages), Requirement.parse('setuptools>=17.1'))

• workaround
  pip install --upgrade setuptools
  setuptools (20.10.1)

When following quickstart steps,
it ends in unusable ir-* commands:

$ git clone https://github.com/rhosqeauto/InfraRed.git ir
$ cd ir
$ pip install --user -e .
$ ir-provisioner --help
Traceback (most recent call last):
  File "/home/psedlak/.local/bin/ir-provisioner", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3084, in <module>
    @_call_aside
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3070, in _call_aside
    f(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 3097, in _initialize_master_working_set
    working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 653, in _build_master
    return cls._build_from_requirements(__requires__)
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 666, in _build_from_requirements
    dists = ws.resolve(reqs, Environment())
  File "/usr/lib/python2.7/site-packages/pkg_resources/__init__.py", line 844, in resolve
    raise VersionConflict(dist, req).with_context(dependent_req)
pkg_resources.ContextualVersionConflict: (python-keystoneclient 1.3.0 (/usr/lib/python2.7/site-packages), Requirement.parse('python-keystoneclient!=1.8.0,!=2.1.0,>=1.6.0'), set(['python-troveclient', 'python-glanceclient', 'python-cinderclient']))

almost complete log from pip install --user -e .
and then output of pip freeze

Inventory files are ansible property that IR users shouldn't have to worry about.
Need to map all use cases of inventory file and generate them based on the input.

Currently the topology is defined as:

N_topology

I think it's better to change it to:

topology:N

Example:

topology=2_compute,
topology=compute:2,

This spec file should store the common spec for all tools.

For example:
verbose/debug/input/output/dry-run - all are common to all IR tools.

The flag --hypervisor is less intuitive than "--host-file".
We would like the user to understand straight from the flag what it expects.
Also, please add proper Help line in the arg instead of "Hypervisor", something that is actually helpful to understand this flag.
Describing the content of the file or point to an example file.

At the moment, the ir-install have --storage-type a required flag.
We need to make this optional as some topologies don't have ceph as storage and currently it's defaults to "internal ceph" and gives an option to only choose internal/external ceph

Cleanup should trigger only cleanup and not provision

We need to decide whether to use the configure module or not.
Currently, we're using the module to create 'Configuration' (dict like) instances that load and merge yaml files and to register constructor for yaml tags.
If we decide to use this module, we can delete the 'cli.utils.dict_merge' method because the Configuration class already implements a 'merge' method

There are two different flags here.
DEBUG, this is a feature for someone to check what the ir-provison does (should be a flag "--debug")
VERBOSE, this is ansible -v option, this should be a separate flag to let the user choose verbosity of the output.
Please break the ir-provision DEBUG showing the merge of all files to a --debug flag.
Please break the ir-provision VERBOSE showing ansible verbosity to a --verbose (no flag means -v, flag means -vvvv)

In order to start the Lookup mechanism, there need to be at least one Lookup object before dumping the settings.
The Lookup object are created only when loading yaml files containing old-style lookup patterns (ex: !lookup some.key.to.lookup) in them. Lookup object are not created with new style lookup patterns (ex: "{{!lookup some.key.to.lookup}}").

FIX:
explicitly call the in_string_lookup from the Lookup class before dumping the settings.
(this method search from string values containing the new-style lookups and convert them into Lookup objects)

I'd like to add Application class to encapsulate common IR- logic there. This class will have a major method 'run' which will do the following:

 args, settings_files = self.configure()
 settings = self.lookup(settings_files)
 self.dump_settings(settings)
 self.execute(settings)

After that we will be able to create main methods for our ir- app's with some thing like that

main_provision = IRApplication.create_for('provisioner', CONF).run
main_installer = IRApplication.create_for('installer', CONF).run
main_tester = IRApplication.create_for('tester', CONF).run

What do you think on that? Any ideas?

Can we achieve somehow:

../ospd.spec
- title: Product
    options:
    product-version:
          type: Value
          help: The product version
          required: yes
          choices: ["7", "8"]
...
   images-version:
          type: Value
          default: <VALUE_OF product-version>
          help: Specifies the import image url. Required only when images task is 'build'

This way we don't have to specify multiple parameters like
--product-version=8
--images-version=8
...=8
...
Other way I can think of is connect references in playbooks with existing yaml parameter (product.version), this would mean also we can not specify separate "version" values both e.g. for product and/or images.

ir-provision -vvvv virsh ...

ANSIBLE COMMAND: ansible-playbook -M library -vvvvvvvvvv -i local_hosts --extra-vars @a.txt playbooks/cleanup.yml

Add a jenkins job for running on pool requests as needed

Currently execute.py is throwing general Exceptions on failure. Need proper exceptions.

The workaround for rhbz1302047 starts the nova-compute service on the controller nodes. The nova-compute service should only be started on the compute nodes:

[stack@undercloud ~]$ nova service-list
+----+------------------+------------------------------------+----------+---------+-------+----------------------------+-----------------+
| Id | Binary | Host | Zone | Status | State | Updated_at | Disabled Reason |
+----+------------------+------------------------------------+----------+---------+-------+----------------------------+-----------------+
| 2 | nova-scheduler | overcloud-controller-0.localdomain | internal | enabled | up | 2016-04-19T19:15:56.000000 | - |
| 5 | nova-scheduler | overcloud-controller-1.localdomain | internal | enabled | up | 2016-04-19T19:15:57.000000 | - |
| 8 | nova-scheduler | overcloud-controller-2.localdomain | internal | enabled | up | 2016-04-19T19:15:56.000000 | - |
| 11 | nova-consoleauth | overcloud-controller-2.localdomain | internal | enabled | up | 2016-04-19T19:15:54.000000 | - |
| 14 | nova-consoleauth | overcloud-controller-1.localdomain | internal | enabled | up | 2016-04-19T19:16:00.000000 | - |
| 17 | nova-consoleauth | overcloud-controller-0.localdomain | internal | enabled | up | 2016-04-19T19:15:53.000000 | - |
| 20 | nova-conductor | overcloud-controller-2.localdomain | internal | enabled | up | 2016-04-19T19:15:56.000000 | - |
| 26 | nova-conductor | overcloud-controller-0.localdomain | internal | enabled | up | 2016-04-19T19:15:56.000000 | - |
| 32 | nova-compute | overcloud-compute-0.localdomain | nova | enabled | up | 2016-04-19T19:15:54.000000 | - |
| 35 | nova-conductor | overcloud-controller-1.localdomain | internal | enabled | up | 2016-04-19T19:15:55.000000 | - |
| 38 | nova-compute | overcloud-controller-0.localdomain | nova | enabled | up | 2016-04-19T19:15:56.000000 | - |
| 41 | nova-compute | overcloud-controller-1.localdomain | nova | enabled | up | 2016-04-19T19:16:00.000000 | - |
| 44 | nova-compute | overcloud-controller-2.localdomain | nova | enabled | up | 2016-04-19T19:15:57.000000 | - |
+----+------------------+------------------------------------+----------+---------+-------+----------------------------+-----------------+

[stack@undercloud ~]$ nova hypervisor-list
+----+------------------------------------+-------+---------+
| ID | Hypervisor hostname | State | Status |
+----+------------------------------------+-------+---------+
| 2 | overcloud-compute-0.localdomain | up | enabled |
| 5 | overcloud-controller-0.localdomain | up | enabled |
| 8 | overcloud-controller-1.localdomain | up | enabled |
| 11 | overcloud-controller-2.localdomain | up | enabled |
+----+------------------------------------+-------+---------+

Need to display all the possible command arguments in order they are presented in the spec file. Currently order is random:

usage: provision.py virsh [-h] [-e EXTRA-VARS] [--dry-run] [--network NETWORK]
                          [--ssh-user SSH-USER] [-o OUTPUT-FILE]
                          --image-server IMAGE-SERVER --host HOST [--cleanup]
                          --image-file IMAGE-FILE [--ssh-key SSH-KEY]
                          [-n INPUT-FILES] [--topology TOPOLOGY]

Make the cleanup playbook use the topology file so it will clean only what the provision created

What I'm trying to do: I'm running openstack provisioner to provision one single controller node and then I'm running ir-tester to run tests on it

What is wrong: controller is not part of [tester] group, only undercloud is, so all tasks are skipped.

What I want: a simple way to tag with ir-provisioner the controller as my chosen tester node.

-i is a "standard" for "input" and -o for "output", we should try and be intuitive for the user regarding flags.

Need to check why it takes so much time to dump the settings.
It probablt related to 'handle_nested_lookup' method.

$ cd InfraRed
$ cd ..
$ ir-provisioner --help
WARNING Configuration file not found, using InfraRed project dir
ERROR Settings directory doesn't exist: settings

Is this really necesarry? I think help should be provided even without proper config files set up.

@yfried-redhat
in https://github.com/rhosqeauto/InfraRed/blob/master/README.rst
For example it mentions "infrared --help" that is not valid anymore.

UC image has around 13GB now, it is very impractical to download it every time, because:

1. Takes >=1 hour (e.g. when downloading in qeos7 virtual machine)
2. It is downloaded every time (to /tmp/) - it shouldn't be downloaded if it is already downloaded in "~" directory(idempotent problem)!
   • name: download the undercloud tar file
     get_url:
     url: "{{ private.mirror.base_url }}/undercloud-quickstart.tar"
     dest: "~/undercloud-quickstart.tar"
     force: yes
3. If this will be necesarry at all, we could at least compress the image and get:
   8.9G undercloud-quickstart.tar.gz

example run:
ir-provision virsh -o provision.yaml --hypervisor=seal24 --topology=ospd_1cont_1comp_1ceph -e @$VARIABLE_THAT_DOESNT_EXIST --cleanup

Result:
Traceback (most recent call last):
File "/home/tkammer/test/infrared/.infrared-venv/bin/ir-provision", line 9, in
load_entry_point('infrared==0.0.1', 'console_scripts', 'ir-provision')()
File "/home/tkammer/test/infrared/cli/provision.py", line 61, in main
args['extra-vars'])
File "/home/tkammer/test/infrared/cli/utils.py", line 123, in generate_settings
settings = update_settings(settings, settings_file)
File "/home/tkammer/test/infrared/cli/utils.py", line 88, in update_settings
loaded_file = configure.Configuration.from_file(file_path).configure()
File "/home/tkammer/test/infrared/.infrared-venv/lib/python2.7/site-packages/configure.py", line 193, in from_file
with open(filename, "r") as f:
IOError: [Errno 21] Is a directory: '/home/tkammer/test/infrared'

Add more details when exception is raised in 'ansible_wrapper' method.
In the current implementation, the user have to run the equivalent ansible-playbook command in order to get more details on why the playbook has failed.
It'll be much easier if more will be displayed in debug mode.

I wanted to run 'ir-installer ospd' on my openstack-ovb environment, but the required arguments made me confused. These are the required arguments:

product-core-version
product-version
images-task
network-isolation

Two questions/requests:

1. What is difference between product-version and product-core-version? I see it can receive the same values but it's not clear from the description what is the difference between the two. could you please extend the description? also, is it possible to determine the value of one them based on the second argument value?
2. network-isolation description is "The overcloud network isolation type" - I really have no idea what types exist. can you extend the description to include some examples for types? also, does it must to be required? can a default be set?

RHOS-16551 test the jira intg.

From current log it's very hard to get any useful information from what module/method/class the log line was printed. I'd suggest to add that information to simplify debug process.

We can do next:

1. Add %(module)s and %(funcName)s to the logger message format. But this will now work good for classes and objects.
2. Do not use one name for all the logger. Each class/module need to create own logger with:

LOG = logging.getLogger(self.__class__.__name__) 

And after that add logger name (%(name)s) to the logger message format.

My vote is for option 2).

Find where would be appropriate to document the below issue ,

When installer fails in gathering facts :
00:10:31.233 GATHERING FACTS ***************************************************************
00:10:32.063 ESTABLISH CONNECTION FOR USER: root
00:10:32.063 REMOTE_MODULE setup
00:10:32.063 EXEC ssh -C -tt -vvv -o ForwardAgent=yes -o ServerAliveInterval=30 -o ControlMaster=auto -o ControlPersist=30m -F /home/rhos-ci/jenkins/workspace/manual-poc-gate-ospd_qe-8_director-puddle-rhel-7.2-virthost-vega11-3cont-1comp-1ceph-isolation-vxlan/infrared/ansible.ssh.config -o ControlPath="/home/rhos-ci/.ansible/cp/%h-%r" -o StrictHostKeyChecking=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=gssapi-with-mic,gssapi-keyex,hostbased,publickey -o PasswordAuthentication=no -o User=root -o ConnectTimeout=30 controller2 /bin/sh -c 'mkdir -p $HOME/.ansible/tmp/ansible-tmp-1456762301.06-246301285095940 && chmod a+rx $HOME/.ansible/tmp/ansible-tmp-1456762301.06-246301285095940 && echo $HOME/.ansible/tmp/ansible-tmp-1456762301.06-246301285095940'
00:10:32.064 fatal: [controller2] => SSH Error: ssh_exchange_identification: Connection closed by remote host
00:10:32.064 It is sometimes useful to re-run the command using -vvvv, which prints SSH debug output to help diagnose the issue.

we need to edit jenkins slave (or any other server that runs ir) for not checking the hostkey :
[rhos-ci@gamado-jenkins-server-v1 infrared]$ vi ~/.ssh/config
add 2 lines :
StrictHostKeyChecking no
UserKnownHostsFile=/dev/null

As a user, I should not be forced to provide any params other than the --cleanup and --host/hypervisor flag for the cleanup process to start.

Settings related spec options can be generated from the settings folder structure and from the settings yaml files.

For example we have the following settings files

• provisioner\virsh\hypervisor\default.yaml
• provisioner\virsh\hypervisor\earth.yaml

cat default.yaml::

  host: myhost
  user: root
  key: mykey

cat earth.yaml::

  host: earth
  user: root
  key: mykey
  earth_specific_key: value

Spec generation steps:

1. Get all the folders under virsh

2. I every folder get all yaml files.

3. Get all the keys from yaml, remove duplicates.

4. Generate spec option. For example for given example we need to generate the following options:
   --hypervisor (value should point to the yaml file)
   --hypervisor-host (alternative to the 'hypervisor' option)
   --hypervisor-root
   --hypervisor-key
   --hypervisor-earth_specific_key

5. Default value can be taken from the default.yaml file (if provided)

Limitation:

• to many spec parameters can be generated. Need to limit, the deep (number of '-' in name) of parameters
• there could be a problem if we want to have subfolders under the 'hypervisor'.

A user should has the option to use any argument he want.

Need to remove the 'choices' from 'hypervisor' option in the virsh spec file and refer to the argument as path to a settings file.

• roles/ospd/overcloud/images/import/tasks/main.yml:7 wget=>get_url
• playbooks/installer/ospd/undercloud/pre.yml:39 yum

A user should has the ability to point the root dir (InfraRed) to a differnent dir which includes all needed dirs (settings, playbooks, library etc...)
In this case, instead of changing the paths of all dir in the the infrared.cfg file, there'll be a need to change only the path to the root dir, and the other paths will point into it automatically