summaryrefslogtreecommitdiffstats
path: root/xci/config
AgeCommit message (Collapse)AuthorFilesLines
2018-03-20Add initial support for multiple infra deployersMarkos Chandras1-0/+9
bifrost is currently the only way to deploy the infrastructure but in the future other solutions will be added so we need to do some preparation for XCI integration. Change-Id: I961dd42157c924d88747074ddba6a318f8b537ac Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-03-14Merge "xci: config: evn-vars: Dynamically determine the Ansible version"Markos Chandras1-1/+1
2018-03-13Merge "Set VM node names and log the installer version based on installer"Fatih Degirmenci3-3/+6
2018-03-13Merge changes from topics 'allow-pass-ansible-arguments', ↵Markos Chandras1-4/+2
'allow-pass-ansible-arguments-force-verify' * changes: xci: OSA: Fix warning about missing inventory file xci: Pass the XCI_PATH variable to all Ansible calls xci: Rename XCI_ANSIBLE_VERBOSITY to XCI_ANSIBLE_PARAMS
2018-03-12Set VM node names and log the installer version based on installerFatih Degirmenci3-3/+6
The VM nodes are named using OpenStack terminology but since we now have Kubernetes scenario, it is appropriate to name the nodes accordingly. Apart from that, we normally log the version of OSA which is not correct for kubernetes deployments. Logging Kubespray version would be correct for this scenario. Change-Id: I3964574c8592450f9fa3126f19e27bb78fd9d174 Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2018-03-12xci: config: evn-vars: Dynamically determine the Ansible versionMarkos Chandras1-1/+1
There is no good reason why we should pin the Ansible version without the ability to override it. OpenStack Ansible is doing a great work testing Ansible releases as early as possible so we could benefit from that work and use whatever Ansible our pinned OSA uses. Change-Id: I4677dbefc68f7140417ece34d013ca9674baab43 Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-03-12Combine vars setting installer type in INSTALLER_TYPEFatih Degirmenci2-4/+4
Change-Id: I330bc036f901d4ba61bc94ee6e085cadf54b4d8b Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2018-03-12xci: Rename XCI_ANSIBLE_VERBOSITY to XCI_ANSIBLE_PARAMSMarkos Chandras1-4/+2
We don't quite need a specific env variable just for Ansible verbosity so we can rename this variable to make it clear that it can be used to pass any Ansible option to XCI. Change-Id: Ie20517d4b563bfc6daeb27848168d36da7014cee Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-03-07bifrost: Use the pre-built XCI OS images instead of dibMarkos Chandras1-0/+1
We already have images for all 3 distros which we could simply re-use for all the XCI VM deployments instead of building new ones everytime with DIB. The images will be copied to the new VM from the cache directory if they are available otherwise we will simply download them during the XCI execution phase. Change-Id: I2a8391650558511668654c6b54a10db316f867a2 Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-03-07Bump bifrost sha and set UPPER_CONSTRAINTS_FILEFatih Degirmenci1-1/+1
The lack of UC means that pip is attempting to install libvirt-python 4.1.0, which is failing on Ubuntu due to https://bugs.launchpad.net/openstack-requirements/+bug/1753539. Currently upper-constraints limits libvirt-python to 4.0.0, which does not have this issue. Change-Id: Idc97a0d9928cebafc9167614723236d2584cc93f Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2018-03-02xci: Make few of OpenStack-Ansible components optionalMarkos Chandras1-0/+1
Ironic and Horizon are not quite needed for a functional deployment and they are not currently required by functest so we can remove them from the default deployment. Change-Id: I171483f7b774951f84687529e98cb519afa48043 Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-03-02xci: Bump SHAs to the latest stable/queensFatih Degirmenci1-2/+2
Rocky is still in early stages of development so bump SHAs to the latest version for Queens. Change-Id: I0721e6188889c3548c266c042414397385b85ca2 Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2018-03-02Pin kubespray to working shaFatih Degirmenci1-1/+3
Kubespray works fine on supported distros so it is important we pin the sha and bump it in a controlled manner since people might be trying xci/k8 scenario and we want them to have working versions. Apart from that, scenario specific verify/merge jobs are being created at the moment and we need a working version to test the CI/testing side of things. Change-Id: I8702ed697057386449dc99d8cd14391de18f345a Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2018-02-26Merge "xci: config: env-vars: Allow git urls overrides"Markos Chandras1-7/+11
2018-02-22xci: config: env-vars: Allow git urls overridesMarkos Chandras1-7/+11
It's useful to be able to pick alternative git repositories for the deployment. This facilitates testing in-flight features or simply save some bandwidth by keeping internal mirrors. Change-Id: I3eb2e48da1e91f6a52bb3ba14c22f0902c6cd777 Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-02-21Correct the BIFROST_IRONIC_VERSION variableDimitrios Markou1-1/+1
By mistake the BIFROST_IRONIC_VERSION variable was written BIFROST_IRONIC_CLIENT_VERSION Change-Id: Ie35a4938a2fb38c633dd149c1d18f1da20a4e82a Signed-off-by: Dimitrios Markou <mardim@intracom-telecom.com>
2018-02-20xci: Switch VM disk cache to 'unsafe' and use 'iothreads' for I/OMarkos Chandras4-4/+0
According to the docs[1] "writeback: This mode causes the hypervisor to interact with the disk image file or block device with neither O_DSYNC nor O_DIRECT semantics. The host page cache is used and writes are reported to the guest as completed when they are placed in the host page cache. The normal page cache management will handle commitment to the storage device. Additionally, the guest's virtual storage adapter is informed of the writeback cache, so the guest would be expected to send down flush commands as needed to manage data integrity. Analogous to a raid controller with RAM cache." and "writeback: This mode informs the guest of the presence of a write cache, and relies on the guest to send flush commands as needed to maintain data integrity within its disk image. This is a common storage design which is completely accounted for within modern file systems. This mode exposes the guest to data loss in the unlikely case of a host failure, because there is a window of time between the time a write is reported as completed, and that write being committed to the storage device." "unsafe: This mode is similar to writeback caching except for the following: the guest flush commands are ignored, nullifying the data integrity control of these flush commands, and resulting in a higher risk of data loss because of host failure. The name “unsafe” should serve as a warning that there is a much higher potential for data loss because of a host failure than with the other modes. As the guest terminates, the cached data is flushed at that time." It's beneficial to use the host page cache to cache I/O from the guest instead of waiting for data to reach the actual disk device. We do not normally care about data integrity so data loss is not a problem. Moreover, we drop the cache configuration from the flavor files since it's independent of the flavor that's being deployed. [1] https://www.suse.com/documentation/sles-12/singlehtml/book_virt/book_virt.html#cha.cachemodes Change-Id: I118ffdf84b1be672185b3eff60fe5d0b5f1a590d Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-02-13xci: Bump OpenStack Ansbile SHAsMarkos Chandras1-2/+2
* Bump up upstream SHAs * With these upstream SHAs, OSA installs neutron-agent container on controller node which would require eth12 interface on controller for establishing vlan provider networks. so adding eth12 interface and linking it with br-vlan over br-vlan-veth link. Change-Id: Iaf7cbe6e41dcfd15ec6527c5a50701f2d05eaad8 Signed-off-by: Markos Chandras <mchandras@suse.de> Signed-off-by: Periyasamy Palanisamy <periyasamy.palanisamy@ericsson.com>
2018-02-13bifrost: Add ability to pin Ironic-{,client,inspector,inspector-client} SHAsMarkos Chandras1-2/+10
We should pin the SHAs for Ironic components as part of the regular bifrost bump to ensure maximum long term stability. This also bumps the bifrost SHA to the latest available one. Change-Id: Ia66d8ab6566db58e2ddab5134eb8445bd84d2a8f Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-02-05bifrost: Bump bifrost sha1s to latest on masterFatih Degirmenci1-2/+2
This change brings in the fix for policy.json removal. https://review.openstack.org/#/c/536349/ Change-Id: Ib18a99502c0ce61278e13f25a01622e073749d14 Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2018-01-31deploy kubernetes in XCIwutianwei3-0/+21
This commit introduces kubespray into XCI. k8s install currently assumes k8s install and OpenStack install cannot coexist. If XCI_INSTALLER is set to "kubespray" and DEPLOY_SCENARIO is set to "k8-nosdn-nofeature" the xci-deploy.sh would install kubernetes instead of OpenStack. The version of kubernetes is beta release v1.9.0 currently according to the master of kubespray it only support the ubuntu now. Opensuse and centos still need to develop and test. This patch create the directory xci/installer/kubespray, the related files of kubespray would be placed to it. The xci/installer/$installer/playbooks/configure-localhost.yml was moved to xci/playbooks/configure-localhost.yml as a common yaml file. You can modify some parameters according your need in xci/installer/kubespray/files/k8s-cluster.yml to deploy cluster. When deploying kubernetes, it would download the kubespray to releng-xci/.cache/repos/kubespray. If your flavor is Ha, it will download haproxy_server and keepalived to xci/playbook/roles, which setup haproxy service for kubernetes. Change-Id: I24d521a735d7ee85fbe5af8c4def65f37586b843 Signed-off-by: wutianwei <wutianwei1@huawei.com>
2018-01-08xci: Rename 'nfvi' to 'installer'Markos Chandras2-2/+2
Using 'installer' to describe the tool that will deploy the foundations of a particular XCI scenario is more appropriate than NFVI which normally describes both the physical and virtual resources needed by an NFV deployment. Change-Id: Ib8b1aac58673bf705ce2ff053574fd10cb390d71 Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-01-03xci: Decouple VM distribution from host OSMarkos Chandras1-0/+1
Introduce a new XCI_DISTRO variable to select the distribution to deploy on the VMs in order to make deployments more flexible and decouple the VM OS selection from the host one. The default value for this new variable is to match the host OS but users can always set it to one of the supported distributions. We can now simply execute the install-ansible.sh script instead of sourcing it in order to keep the environment as clean as possible. Change-Id: Ia74eb0422f983848cde0fb7b220ea1035dfa78bc Signed-off-by: Markos Chandras <mchandras@suse.de>
2018-01-03[XCI] move osa files into xci/nfvi/osa/fileswutianwei1-1/+1
we maybe introduce other NFVI in the future in XCI. it is necessary to put the nfvi files to corresponding directory xci/nfvi/$NFVI/files, otherwise the files directory will be confused. Change-Id: Iea98167ff0bc8d338a94fe1c064ac0ab396c53d3 Signed-off-by: wutianwei <wutianwei1@huawei.com>
2017-12-22Merge "bifrost: Bump bifrost SHA"Markos Chandras1-1/+1
2017-12-20bifrost: Bump bifrost SHAMarkos Chandras1-1/+1
Bump the bifrost SHA so we can get rid of the testvm.xml.j2 template which has now made it upstream. Change-Id: Ia9cdd999a5702f37125d38e0ba68bb31920d2117 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-12-19Rename variable OPNFV_SCENARIO to DEPLOY_SCENARIOFatih Degirmenci1-1/+1
Rest of the OPNFV projects use the variable DEPLOY_SCENARIO so XCI should be aligned with them as well even though OPNFV_SCENARIO fits better than DEPLOY_SCENARIO. Change-Id: Id48c41fa8a1fa9493cfc7a4906f64b6d8ed27d64 Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2017-12-18Merge "Increase ram of XCI VM and change disk cache type for all VMs"Fatih Degirmenci4-4/+4
2017-12-18Increase ram of XCI VM and change disk cache type for all VMsFatih Degirmenci4-4/+4
These options seem to help with the functest execution within XCI VM. Change-Id: I3b9b6b02fc571feb42543025f8ab179c6db18e0a Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2017-12-15xci: Move OpenStack-Ansible out of the main scriptMarkos Chandras1-0/+1
In preparation for supporting more NFVIs in XCI, we need to make the main script NFVI agnostic. Right now, our NFVI is being deployed using bifrost+OSA so we keep bifrost in the main script since the hardware provisioning is NFVI agnostic (at least for now) but we move OSA to its own directory. This should allow more NFVI to plug into XCI by simply providing a nfvi-deploy.sh script. The user can select the preferred NFVI using the XCI_NFVI variable. Change-Id: Ieeacd3b22a64d363feff5d43ff23a80c39038837 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-12-13xci: Fix checkout location for OpenStack-AnsibleMarkos Chandras1-3/+5
The OPENSTACK_OSA_PATH only makes sense on localhost. As such, when we use it on playbooks that operate on remote hosts, the result is not predictable. However, we rsync the entire releng-xci repository to the opfnv host so we can make everything predictable by simply clone everything in advance in the .cache directory. That directory is then rsync'd to the opnfv host. As such, we can repurpose the OPENSTACK_OSA_PATH to point to the path into the OPNFV host. Moreover, all external repositories are being cloned to .cache/repos so we can eliminate some variables in order to simplify the code. Finally, we bring back the ability to use an external OSA repository for development purposes. Change-Id: Ieef3e22ae2085f6735185634d555cfc0d4b69b39 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-12-12xci: Restore the OPNFV_SCENARIO variableMarkos Chandras1-0/+1
The variable was accidentally removed in ab3c9ad0f9a4 so bring it back. Change-Id: I48e4b8dd68969c8e5336e5e571a73f037fb65988 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-12-12Move contents of os-nosdn-ovs into os-nosdn-nofeatureFatih Degirmenci1-1/+0
This change fixes the scenario os-nosdn-nofeature by moving directories/files from os-nosdn-ovs to os-nosdn-nofeature. The contents of the files and variables are also either adjusted or removed in order to prevent impacts on CI. Change-Id: Icfde27f413c8f93d097f9f262c8cb1230b7fe59d Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2017-12-11xci: Use local playbooks for XCI deploymentsMarkos Chandras2-25/+14
Previously, we used to clone the releng-xci repository under a directory in /tmp, copy our changes to that repository and then run the xci-deploy.sh script from it. However, this made things far too complex for deployers and developers since some playbooks were used from the local repo whereas others were used from teh /tmp checkout. By running everything from our local repository simplifies things a lot since we can directly test our changes and also reduces the code we have in our playbooks. Change-Id: If16aa51b2846c170676df82d25cb90e26b1568b2 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-12-11xci: playbooks: provision-vm-nodes: Simplify the provision VM playbookMarkos Chandras1-3/+0
The provision-vm-nodes playbook is only responsible for running bifrost to provision the XCI virtual machines. As such, drop all the extra tasks that this playbook performed in order to simplify it. This also drops the XCI_EXTRA_VARS_PATH variable since it had a rather obscure usage and there is not much value in passing inventory information outside of XCI. All these will be handled in the scenarios themselves. Change-Id: If5cb381a3d1e101100eb04478d80fb3045cdfaf8 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-12-11xci: Bump OpenStack Ansible and bifrost SHAsMarkos Chandras1-4/+4
Change-Id: I96c988ef6b303b89a5615c50ef60b45e49584b83 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-12-01xci: Allow variable overrides from external scenariosMarkos Chandras1-0/+1
All scenarios are being cloned to XCI_SCENARIOS_CACHE so look there for the various override files. This will allow external scenarios to influence the XCI environment. Change-Id: I39a48ce55baaa29d09737ce6232867ef1165f099 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-11-28XCI: Bump OpenStack Ansible SHAsMarkos Chandras1-2/+2
Change-Id: Iee45d9c865f3fdc83089126cf78b1daa0917df1a Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-11-23Integrate inband os-nosdn-ovs scenarioPeriyasamy Palanisamy1-0/+1
Change-Id: I9253edf028fce571e04f9f82103a94952e05d2d4 Signed-off-by: Periyasamy Palanisamy <periyasamy.palanisamy@ericsson.com>
2017-11-22xci: config: pinned-versions: Bump Bifrost SHAMarkos Chandras1-2/+2
Change-Id: I9df869fa82f4486b104f4330b83e8300362afb54 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-11-17XCI: Bump OpenStack Ansible SHAsMarkos Chandras1-2/+2
Change-Id: If5e4ff731b2bf59e44b753ce0574f25639694162 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-11-14Merge "Integrate ceph in XCI"Markos Chandras1-0/+1
2017-11-02Bump OpenStack Ansible SHAsMarkos Chandras1-2/+2
We also need to allow root logins when the ansible-hardening role is applied which are disabled by default. Change-Id: I71f881305bafdd884d541cd34796a6fed8eee157 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-10-26Integrate ceph in XCIwutianwei1-0/+1
Openstack ansible support to deploy ceph. The purpose of this patch is to configure the ceph, just like we configure other openstack components. The default is to not deploy ceph. If you want to deploy ceph you just need to export XCI_CEPH_ENABLED=true before running xci-deploy.sh. When deployed successfully, the openstack storage will use ceph. Change-Id: Ifd8d16fdce2914b6316842e72bbfd93228ea059d Signed-off-by: wutianwei <wutianwei1@huawei.com>
2017-10-06xci: Bump bifrost SHAMarkos Chandras1-1/+1
The latest bifrost code contains a fix when setting up DNS from a glean configuration drive and also a few virtualenv improvements. This allows us to get rid of all the workarounds we had in the past to switch Ansible versions in the middle of the XCI deployment. Change-Id: If49e290315ec96efdc07d04ff6624439c53aee19 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-09-27xci: Replace ANSIBLE_VERBOSITY with XCI_ANSIBLE_VERBOSITYMarkos Chandras1-3/+3
The ANSIBLE_VERBOSITY env variable is actually used internally by Ansible and exporting it actually makes Ansible super verbose even if the variable is empty. This feature is going away in the future so we introduce our own XCI_ANSIBLE_VERBOSITY variable which is simply passed to the command line to control verbosity in a proper and deterministic way. Change-Id: I8a32eeb1a86b4cb0a9872a51bbe9f9624d096e39 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-09-22Reduce no of cpus allocated per nodeFatih Degirmenci3-3/+3
Change-Id: I62c167621e2b28a57b1ef7647d105ea73dbb0291 Signed-off-by: Fatih Degirmenci <fatih.degirmenci@ericsson.com>
2017-09-16xci: xci-deploy.sh: Configure dib so VMs match the hostMarkos Chandras1-5/+0
In preparation for adding SUSE support, we need to configure the dib build process to build images which match the host's OS. Change-Id: I4944245d526f916b2033abc5d219fa7a69db54ab Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-09-15xci: env-vars: Bump Ansible version to 2.3.2.0Markos Chandras2-4/+5
Now that bifrost uses virtual env for Ansible we can go ahead and bump the Ansible version to match the one from OSA so we can make use of the latest features. Furthremore, we stop passing ANSIBLE_VERBOSITY to the command line since it's an environment variable so Ansible already knows about it. Change-Id: I52d9a211fc0ced1f7830f6945b2943f35d38109b Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-09-14Generate and use certificates for OSAYolanda Robla2-0/+4
Instead of making OSA to generate self signed certs, bring our own and pass them. By this way we will be able to trust in that certs, and start consuming OpenStack easily. It will also generate proper openrc file to source it and start consuming the cloud properly. Change-Id: Ic72a8b05e6efb222926fc5fa0800e033b2dbd22f Closes-Bug: RELENG-266 Signed-off-by: Yolanda Robla <yroblamo@redhat.com>