Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
|
|
We currently only enable NAT on undercloud for virtual deployments.
However, there could be a case where a baremetal deployment also needs
NAT as it is not using an interface on the overcloud nodes with external
access. Therefore this patch changes the behavior to configure NAT when
the gateway of either the external or admin (when external is disabled)
network matches an IP assigned to the undercloud.
JIRA: APEX-605
Change-Id: I9c79af371913e6e5f0d39b433f68205bc7e106c5
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
For ODL CSIT we want to deploy with:
- Minimum services per role
- 2 Compute nodes, 1 controller
- Single network enabled
Change-Id: If611c4c1ff68629670ef15904930124b5786a569
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
|
|
|
|
|
|
There was a compatibility issue with the centos 7.4/7.5 between the host
pacemaker version and container. Now that containers have moved to 7.5
we should not need this workaround anymore.
Change-Id: I9632c65e87687d4f36130719c6df9af2e913eed8
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
If it's not installed, opnfv-deploy will output an
error message.
JIRA: APEX-599
Change-Id: Ib826204120f53abce1f4f1e3e4ec3119a71ab650
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
|
|
We were not setting any vlan type value for the admin network. This
caused an issue when deploying and trying to use a single collapsed
network (no net isolation). The issue occurred when trying to create an
external neutron network. We happen to check if the phys type is flat
or vlan using this attribute to decide what kind of phys type to use for
the neutron network.
JIRA: APEX-606
Change-Id: I4e24dd5e8b99cef920b8203b820a77d0021631cc
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Ricky has been a very active Apex user and contributor over the past few
release cycles. He has helped find and fix numerous bugs, along with
being responsible for L2GW and SRIOV features for Fraser release. He
has shown a willingness to jump in and help whenever there are issues
with Apex, and also a willingness to work upstream in TripleO/OpenStack
to implement new features.
Change-Id: Ifd032fd349a46b0e34b2d77ba56e3c564e70226c
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
networking-vpp was referencing variables from the old variables.sh.
Moving those values into the Makefile as the variables.sh file was
removed.
Change-Id: I8ef5e6988299e7e3855d442657db2ed20086689f
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Default route was using the undercloud IP, and instead should be using
the gateway set for the network in network settings.
JIRA: APEX-597
Change-Id: Iff6b18a6553af98cf9da72c278f358922d489958
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
We now move master to deploy from upstream. That means we do not need
to build undercloud/overcloud images anymore.
Changes-Include:
- Remove bash build scripts as we do not need to build anything
other than the python package anymore
- Remove building images or iso from build.py
- Remove building of images and iso from Makefile
- Rename/refactor deploy settings files for nosdn and odl. The new
convention is that the typical scenario names we use will deploy
master. We also support n-1 OS, so in that case we use the branch
name for the "feature" in the scenario name: os-odl-queens-noha.
- Tacker/Congress are disabled in settings files until we fix that with
upstream. Containers are now enabled by default.
- Disable TLS for undercloud (was changed upstream to default enabled)
- Fix environments docker directory for master THT (was changed upstream)
- Includes fix for LP#1768901
- Includes workaround for LP#1770692
- Moves to docker.io for container images as it is more stable and
should contain the same images
- Removes the term 'common' from apex packaging for referencing the
Python Apex package
Change-Id: If6b433860b3ff882686c78d0f24a2f0c52b9b57a
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Change-Id: I19bfaa5b2778baf458df60a4a53d135e57859e04
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
|
|
|
|
Live migration fails due to this missing service
in the compute role
JIRA: APEX-564
Change-Id: I13d69673204f6157dcbce31507aaa132f8c4ecce
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
|
|
- Update networking-vpp to use master branch
- Update THT vpp ml2 environment file with correct parameters
- Update external network creation command to use 'externa' as
provider network name.
- Remove vpp network settings file as it's not used
apex-tripleo-heat-templates: Ia25db8456f1ad6beb96c7b9b5f318b166ef4576a
apex-puppet-tripleo: I231054a433eb7e598a6e24f6eaea02d476e776de
Change-Id: I4a1f68c75ae3b7d2a5b347d05abf0d025e8b116b
Signed-off-by: Feng Pan <fpan@redhat.com>
|
|
The OVN scenario would not deploy due to failures in trying to upgrades
to OVS 2.8 from OVS 2.7
JIRA: APEX-594.
Change-Id: Id84e488da8d2335f2240930c68119d0e2f6faf9c
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
We are seeing pip3 not found and collectd-write_sensu package conflicts
with latest pike overcloud images. This patch changes pip3 install to
python34-pip3 and updates collectd-write_sensu package version when
removing.
Change-Id: I7dfe1f2f39c3f21bffde8cfc6066f5bae66677d6
Signed-off-by: Feng Pan <fpan@redhat.com>
|
|
- Update neutron NSDriver patch
- Update os-net-config to fix config errors for vpp uio-driver
- Update puppet-tripleo to add configuration of physnets and type_driver
in vpp agent
- Update THT to change VPP environment file for vpp-agent, and add common.yaml
for vpp interface mapping
- Update VPP and networking-vpp version to 18.01
- Fix networking-vpp rpm build to enable proper uninstall.
- Update networking settings file to use ovs_bridge as default external interface type
JIRA: APEX-578
JIRA: APEX-568
JIRA: APEX-576
JIRA: APEX-577
apex-os-net-config: I915d5455acb8d496438b9c9e851639d3a43e6fa9
apex-puppet-tripleo: I472879b8f67e64b571638a0385943597a9120e6c
apex-tripleo-heat-templates: I5dfaf85d67fb038109edaf5c5d8a3e901b9148f4
Change-Id: I369bee232bfafef260d2ef19ac32614fdc487271
Signed-off-by: Feng Pan <fpan@redhat.com>
|
|
|
|
After deploying with nosdn, it looks like there is some out of state
issue between the services. First guess looks like something is going
on with the services and timing of registering to each other through
rabbit. Simply restarting the services seems to sync them back up
correctly.
Change-Id: I417911067c841725ee12eb9354e5759054724e01
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Previous fix to update delorean repo on undercloud was always failing
because the operations passed to virt-customize were not in a list type.
JIRA: APEX-565
Change-Id: Ic883309ac1c3aa6027dc252635e404e5355c269d
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
opnfv-pyutil was not working due to this relative import. The script
would only work out of the pwd.
Change-Id: I1ed5db779dd031d019012a814b2dfe27944a2e2f
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Change-Id: I03cda65f58753fc5d55ea4ede78f7d5bd8b7bdce
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Usage:
opnfv-pyutil --fetch-logs
python3 utils.py --fetch-logs --lib-dir ../lib
Eventually all utils.sh functions will be migrated here.
Note there is no support here for containers. Will be
added later.
Change-Id: I223b8592ad09e0370e287ee2801072db31f9aa12
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
Now, SDN_MAP is not needed to have a boolean true
value, but it will check internally posible value formats
such dicts and tuples.
Change-Id: Idaf492952a7dd9e48e16f42dcbf5c59d981dd535
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
|
|
Changes Include:
- For upstream deployments, Docker local registry will be updated with
latest current RDO containers, regular deployments will use latest
stable
- Upstream container images will then be patched/modified and then
re-uploaded into local docker registry with 'apex' tag
- Deployment command modified to deploy with containers
- Adds a --no-fetch deployment argument to disable pulling latest
from upstream, and instead using what already exists in cache
- Moves Undercloud NAT setup to just after undercloud is installed.
This provides internet during overcloud install which is now
required for upstream container deployments.
- Creates loop device for Ceph deployment when no device is
provided in deploy settings (for container deployment only)
- Updates NIC J2 template to use the new format in OOO since
the os-apply-config method is now deprecated in > Queens
JIRA: APEX-566
JIRA: APEX-549
Change-Id: I0652c194c059b915a942ac7401936e8f5c69d1fa
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
|
|
This scenario should enable SRIOV interfaces to be used
by Neutron. Only will be supported in baremetal deployments
with SRIOV capable NICs. The name of the interface must
be known in advance and the physnet of the SRIOV network
is set as nfv_sriov.
Change-Id: Ie4295413e0be2197bd9ada4f887f6b47cd486765
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
|
|
|
|
|
|
|
|
Although this is not required to be able to access overcloud, it is
required by some tests in Functest.
JIRA: APEX-570
Change-Id: I45deaa8061f1be44ce80eed4810537eaf6841803
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
If you have a non-vlan external network in a
separate interface, you will need to create an
extra bridge to hook up the interface. This patch
will allow the user to create:
- br-isolated: for all the vlan networks
- br-ex: for the native external network
JIRA: APEX-572
Change-Id: Ie76e2345ce75c77f2925c47451427ae41b6957d1
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
|
|
|
|
There is an issue with HA deployments where sometimes key imports fail
for Ceph which seem to occur around 50% of the time. When logging in
after a failure, the key import seems to work which indicates it may be
a race condition. In addition, sometimes the keyring that is created
is missing the "caps" section of the file, which will also fail import.
This patch adds a retries for a minute to try to import the key. It
also moves creating/importing to the same Exec because there is
evidence that the file is being modified by some other process right
after the file content is created in the previous exec.
JIRA: APEX-563
Change-Id: Ie8cfeb4803f6bed95f9e612eeb37c5cdf2d76617
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
|
|
|
|
It includes ODL L3 service plugin and trunk ports
apex-tripleo-heat-templates: I37039207bc7cf9965d26e6dfa034e84bf9b7224d
Change-Id: I29c398aabf9a2d1b98f76895ed73c01dcc008c19
Signed-off-by: Ricardo Noriega <rnoriega@redhat.com>
|
|
|
|
JIRA: APEX-535
Change-Id: If1d074d01246407b322d5a4bc27dfde35349e9db
Signed-off-by: Dan Radez <dradez@redhat.com>
|
|
|
|
|
|
We currently start VBMCs using CLI due to issues with the VBMC python
lib. However when we start them, there is no check to make sure they
are actually changed to 'running' status. This patch adds logic to
check (up to 5 times) to ensure each VBMC is running or raises an error.
Note this is for virtual deployments only.
JIRA: APEX-527
Change-Id: Iab7ee3b76292d6fc547f18c83f23c04205e9bb2e
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
JIRA: APEX-512
Change-Id: I875bd99203b425e448e7a3f64eb9a8f99d03ddaf
Signed-off-by: Dan Radez <dradez@redhat.com>
|
|
When we build artifacts for release, we try to freeze the disk images
and artifacts we use for deployment. This includes the delorean repo
which provides OpenStack packages. This repo however expires after a
couple months and then if any packages were missing in the Undercloud
released artifact, they will attempt to be downloaded during install
and fail.
This patch adds some logic to detect if there is internet connectivity,
and if so then download and update the delorean repo on the undercloud.
JIRA: APEX-565
Change-Id: I58c28437fb5c5b179033c939377fd97aefbf427c
Signed-off-by: Tim Rozet <trozet@redhat.com>
|
|
We configure host iptables to open different ports for VBMC. This may
fail if the iptables filters are not loaded.
JIRA: APEX-521
Change-Id: Ia33032c29aba3555551e39b4f819087aeafe05d9
Signed-off-by: Tim Rozet <trozet@redhat.com>
|