| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This change
- bumps OSA SHA to cbfdb7dc295ff702044b807336fab067d84a3f20
(mostly based on Rocky RC1)
- bumps bifrost SHA to c1c6fb7487d5b967624400623fd35aabf303b917
- pins Ansible to 2.4.6.0
- switches to ollivier/functest-healtcheck since OS is bumped to Rocky
Change-Id: Icc14e3e794b489dafd78b426c54051a3732ccb1a
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
|
|
Leap 15 is using ID=opensuse-leap and Tumbleweed is using
ID=opensuse-tumbleweed so we should extend the regexp to match
these distributions as well. This allows XCI to support more
openSUSE variants as deployment hosts.
Change-Id: I8bf8e7b15fc00c45807ff92fbc14d7ec79ec4bcb
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
This change integrates os-nosdn-osm scenario.
The installation of OSM is done as post-deployment. This is achieved by
the addition of the new playbook named post-deployment.yml in scenario
role folder.
This mechanism is available for all OpenStack scenarios. If anything
needs to be done for a specific scenario as part of the post-deployment,
it can be achieved by creating playbook post-deployment.yml.
If post-deployment.yml exists in scenario role, the framework will run
it once the regular deployment playbooks are run successfully. If the
file does not exist, it will be skipped.
The location of the post-deployment.yml is
releng-xci-scenarios/<scenario>/role/<scenario>/tasks/post-deployment.yml
This is only implemented for OpenStack scenarios currently and similar
mechanism is needed for K8S scenarios as well which will be implemented
in a separate change.
installer-type:osa
deploy-scenario:os-nosdn-osm
Change-Id: I16780abffca39699eb2f38f662479f0e4d551504
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
|
|
The flavor all-in-one (aio) hasn't been maintained well and
the stability of it is in question. This change disables the
flavor aio and sets the default flavor to mini.
It is important for XCI to enable the aio back in order to help
users who want to try XCI but don't have big enough machine to
go for bigger flavors. However, we need to verify all flavors
for acceptable user experience so the flavor can only be enabled
back once this happens.
Change-Id: I053c8fec78876dea71439f1f1bd737a105254ad4
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
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>
|
|
Functest changes have significant impact which blocks everything in XCI so this
change pins the image to a known sha to get the original set of healthcheck
testcases until the impacts are analysed and concerns are raised to Functest
and the wider OPNFV Community and addressed based on community consensus.
Pinned version of functest-healthcheck contains the test cases below.
- connection_check
- api_check
- snaps_health_check
deploy-scenario:os-nosdn-nofeature
installer-type:osa
Change-Id: Ic9222af8c27e58491b7b60a7504df9d792b5e753
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
The spice-html5 repository moved from github to its own gitlab hosting
and that broke everything. As such, we update the OSA roles which
contain the correct URL for the new repository.
Change-Id: I3e2883c0436c9c93d2a8a338343ca3a75a1431e4
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
|
|
The kubespray installer contains one inventory per flavor. We can get
rid of these files and use the dynamic inventory similar to OSA.
Moreover, we extend the dynamic inventory to read additional group
variables per flavor if necessary. This way we can still pass additional
information to inventory on per-flavor basis. This also fixes a typo
in the 'IDF' file. We also need to bump Ansible for kubespray since the
version we were using is having troubles with dynamic inventories.
Change-Id: Ic58101555f81aec5fee3c193608440aa89bbe445
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
1. this change bumps Kubespray SHA to the HEAD of "master" as of 16.05.2018
2. install ansible-modules-hashivault, due to kubespray refactor vault role
https://github.com/kubernetes-incubator/kubespray/commit/07cc98197187535619ac8e57ee4e04ae02631a5
installer-type:kubespray
deploy-scenario:k8-nosdn-nofeature
Change-Id: I2e3ade3b16eac1506e8556fe1820d84d64c09435
Signed-off-by: wutianwei <wutianwei1@huawei.com>
|
|
|
|
The upstream PR to include openSUSE support has been merged so we need
to bump the SHA to make it available in XCI.
Change-Id: Ida5bd05ce8b0c883b6d7582a495ca934ecc4b1f1
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
|
CI_LOOP, NODE_NAME, and BUILD_TAG are needed for logging info to console.
FUNCTEST_MODE and FUNCTEST_SUITE_NAME are important for stating what level
of testing we do for verify and merge jobs.
Change-Id: Iaa5499155b4b94a1cfc6b5c70fe6f8f7417502a6
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
The hash value for the OpenStack requirements project is consumed
for other projects which can be out of the openstack-ansible scope.
This change creates the OPENSTACK_REQUIREMENTS_VERSION variable using
the openstack_services.yml value as default one.
Change-Id: I4544bcc3f14c107aab8ebba1dced1ba203f07f68
Signed-off-by: Victor Morales <victor.morales@intel.com>
|
|
This change brings the fix for
- cinder haproxy check for ha deployments
- pip related fixes
- fixes for lxc_hosts
Change-Id: I4af64041a4a76c10361456f73577e7c7040edf8a
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
Change-Id: Iae3f642bea54feae4c033b61e8ea4cfe759848ec
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
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>
|
|
|
|
|
|
'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
|
|
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>
|
|
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>
|
|
Change-Id: I330bc036f901d4ba61bc94ee6e085cadf54b4d8b
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
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>
|
|
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>
|
|
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>
|
|
* 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
|
|
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>
|
|
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>
|
|
|
|
These options seem to help with the functest execution
within XCI VM.
Change-Id: I3b9b6b02fc571feb42543025f8ab179c6db18e0a
Signed-off-by: Fatih Degirmenci <fdegir@gmail.com>
|
|
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>
|
|
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>
|
|
The variable was accidentally removed in ab3c9ad0f9a4 so bring it back.
Change-Id: I48e4b8dd68969c8e5336e5e571a73f037fb65988
Signed-off-by: Markos Chandras <mchandras@suse.de>
|
Fatih Degirmenci
Markos Chandras
Manuel Buil
wutianwei
Victor Morales
Dimitrios Markou