summaryrefslogtreecommitdiffstats
path: root/xci/config/ha-vars
AgeCommit message (Collapse)AuthorFilesLines
2019-08-01Introduction of Openstack-helm as installernikoskarandreas1-0/+1
This patch creates a new installer tree in xci that uses openstack-helm to deploy openstack on a kubernetes cluster. USAGE: Export INSTALLER_TYPE=osh, DEPLOY_SCENARIO=k8-calico-nofeature and XCI_FLAVOR=noha or mini and run xci-deploy.sh as in documentation. deploy-scenario:k8-calico-nofeature installer-type:osh Change-Id: I212f70eb51c2a38c798c11367d2ebb8bf5f4a1de Signed-off-by: nikoskarandreas <nick@intracom-telecom.com>
2018-06-28Use PDF to set up the XCI VMsManuel Buil1-3/+3
This patch is doing the first work item of the spec: https://github.com/opnfv/releng-xci/blob/master/docs/specs/infra_manager.rst It creates the required VMs by XCI to afterwards deploy the VIM. It does that by reading the pdf provided by the user. - It is currently assumed that the OS for the VM will be installed in the first disk of the node described by the pdf - It is assumed that the opnfv VM characteristics are not described in the pdf but in a similar document called opnfv_vm.yml - All references to csv from bifrost-create-vm-nodes were removed Change-Id: I46a85284e4ce7df21cbf66f66619b35f74251e68 Signed-off-by: Manuel Buil <mbuil@suse.com> Co-Authored-by: Markos Chandras <mchandras@suse.de>
2018-03-12Set VM node names and log the installer version based on installerFatih Degirmenci1-1/+2
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-02-20xci: Switch VM disk cache to 'unsafe' and use 'iothreads' for I/OMarkos Chandras1-1/+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>
2017-12-18Increase ram of XCI VM and change disk cache type for all VMsFatih Degirmenci1-1/+1
These options seem to help with the functest execution within XCI VM. Change-Id: I3b9b6b02fc571feb42543025f8ab179c6db18e0a Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
2017-09-22Reduce no of cpus allocated per nodeFatih Degirmenci1-1/+1
Change-Id: I62c167621e2b28a57b1ef7647d105ea73dbb0291 Signed-off-by: Fatih Degirmenci <fatih.degirmenci@ericsson.com>
2017-08-23xci: Bump OSA SHA to Pre-PikeFatih Degirmenci1-1/+1
This change bumps osa sha to 4d39f2cc. [1] The reason for going to a later osa sha is to include ODL and Tacker commits in upstream to ease the work done for ODL and SFC scenarios. However, this osa sha seems to be having issues with the flavor ha so the users should be aware of the problems which is added into the readme as known issue and the flavor is disabled in xci-deploy.sh. Another reason to bump sha right now is that upstream changed a lot during last 2 months and waiting longer will probably result in more changes, making it harder to move to a later osa sha even harder. Other changes included by this change are - update ansible role requirements to move to shas pinned by upstream for pike. - add odl and tacker roles into ansible role requirements. - update how aio is deployed due to removal of an upstream script. (this could perhaps have been done in a better way but the time pressure required this to be fixed in the way as proposed.) - ensure facts are gathered for all the hosts and containers before running setup-infrastructure.yml playbook. - stop grepping for failed in the log of setup-hosts.yml playbook due to existence of rescue block in rabbitmq_cluster_create.yml [2]. - reduce the resource needs by updating the user_variables that are based on upstream osa gate which uses aio. The values for none-aio xci flavors will be adjusted in a separate change once the sha bump is complete. - fix a bug in ha-vars. [1] https://review.openstack.org/gitweb?p=openstack/openstack-ansible.git;a=commit;h=4d39f2cc29417153780210fc0bb86223387e9968 [2] https://review.openstack.org/gitweb?p=openstack/openstack-ansible-rabbitmq_server.git;a=blob;f=tasks/rabbitmq_cluster_create.yml;h=4aaad5adafa42684c0d791b49539069fe1b45635;hb=HEAD#l24 Change-Id: Ia7fc495e315e4a41359641f8be4b3c8bbf7b61fa Signed-off-by: Fatih Degirmenci <fatih.degirmenci@ericsson.com>
2017-08-17prototypes: xci: config: Allow users to set VM specsMarkos Chandras1-4/+4
The default VM spec may not be good enough for every host so allow users to override the default VM_* variables. Change-Id: Ie846620ab81b7fedcbe4b23da735379ab75d3cc2 Signed-off-by: Markos Chandras <mchandras@suse.de>
2017-08-11xci: Rename the deployment host to opnfvFatih Degirmenci1-1/+1
Reflect the changes to other impacted files as well. Change-Id: I106f4e47fe5c75d288f4878fe6ec9f8ff39c652e Signed-off-by: Fatih Degirmenci <fatih.degirmenci@ericsson.com>
2017-08-11xci: Yet another try to find how best to structure stuffFatih Degirmenci1-0/+18
Summary of changes are - flavors directory has been removed and the flavor config files are moved into config and renamed to <flavor>-vars - common files are put under file - files specific to flavors are put under file/<flavor> directories - templates and var files are stored in template and var directories respectively - 3 playbooks are created Change-Id: I8a93e0947ccb02f93a6c8f00da27e0cc6b4dc21e Signed-off-by: Fatih Degirmenci <fatih.degirmenci@ericsson.com>