brenton / openshift-extras Goto Github PK

Move the installer wrapper to openshift-ansible leaving only the install.openshift.com bootstrapping and site assets in openshift-extras.

Benefits:

• We can more easily attempt to get Ops using the tooling if it is alongside theirs, especially since we are looking at using this for installation, modifying existing environments (adding/removing nodes), and upgrades.
• work towards eliminating duplication of effort. There are bin/cluster scripts in openshift-ansible that can be used for relatively naive installs, having the full installer available would allow us to replace those scripts and handle both naive and complex use cases (and prevent bin/cluster and the installer from invoking the scripts differently, lets use Ops as part of our QA process)
• If our installer is driving the Ops automation, then we will get contributions from them associated with new features, bug fixes, etc

Cons:

• We'll need integration with launching, querying, and terminating instances associated with the cloud providers bin/cluster supports (vagrant, libvirt, openstack, gce, aws).
  • We could probably get away with having bin/cluster generating a config file for the installer and invoking the installer for config/update tasks only (leaving launch, list and terminate a native part of bin/cluster).
• Slower process for getting changes merged
  • Currently only Ops and Jhon Honce have merge access to openshift-ansible, we'd need to have someone granted merge access to allow for more expedited reviews (We should probably push for this anyway)

Would need to do the following:

• Create and populate the following groups:
  • oo_nodes_to_config
  • oo_masters_to_config
  • oo_first_master
• Set the following variables (at minimum)
  • group_vars/all:
    • openshift_cluster_id
    • openshift_debug_level (if we want to default to something higher than 0
    • openshift_deployment_type: enterprise
  • group_vars/oo_nodes_to_config:
    • openshift_first_master: "{{ groups.oo_first_master.0 }}"
• Call the common playbooks:
  • playbooks/common/openshift-master/config.yml
  • playbooks/common/openshift-node/config.yml
  • alternatively, if we can ensure that master and node groups are already populated, we can just call playbooks/common/openshift-cluster/config.yaml which will call both of the above. It may be nice to differentiate though, since adding nodes would only require the node config playbook to be run. We must ensure that the master playbook is run before the node playbook is run though (otherwise some of the facts used will be wrong).

Per deployment would be nice to prevent the user from specifying the username multiple times.

Per host may not be needed, but I wouldn't put it past some user to have a need for it down the line.

• We'll want to include a custom ansible.cfg in the current working directory when we invoke ansible-playbook (or set the appropriate env vars/flags when running ansible) for the following:
  • http://docs.ansible.com/intro_configuration.html#forks
    • by default ansible will limit itself to 5 forks (5 concurrent ops),
      we'll want to increase this, possibly given the end-user the ability to
      override our default.
  • http://docs.ansible.com/intro_configuration.html#host-key-checking
    • If left at true, the user can be presented with a lot of prompts to
      authorize keys depending on the number of hosts they are installing
  • This also prevents resource contention if the user has ssh host key
    checking disabled for a host (even if the file is set to /dev/null). We
    saw this severely limiting parallelization when Ops was testing against a
    large number of nodes.
  • http://docs.ansible.com/intro_configuration.html#inventory
    • avoid having to add -i on every ansible
      invocation
  • http://docs.ansible.com/intro_configuration.html#log-path
    • where we want ansible to log to
  • http://docs.ansible.com/intro_configuration.html#nocows
    • we probably don't want to be outputting cows if they happen to have
      cowsay installed
  • http://docs.ansible.com/intro_configuration.html#private-key-file
    • we will want to prompt the user to provide this in case they do not have
      it pre-configured in their ssh config
  • http://docs.ansible.com/intro_configuration.html#remote-tmp
    • for those user's that do not have executable tmp directories
  • http://docs.ansible.com/intro_configuration.html#ssh-args
    • we might want to consider increasing the ControlPersist timeout to avoid
      having to re-create the connection mid-run
  • http://docs.ansible.com/intro_configuration.html#control-path
    • long hostnames can cause issues with the length of the control path
      becoming too long with the default settings.

Need a getting started guide for development, it's not overly clear as to the proper way to run the project (running cli_installer.py works, but won't once things start getting more complicated.