| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the logic for registry authentication is
not implemented correctly to account for upgrades of
containerized hosts.
Additionally, the logic to account for multiple runs
of openshift-ansible might cause registry authentication
credentials to not be mounted inside of containerized hosts.
This commit adds the necessary logic to ensure containerized
hosts retain registry credentials.
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1494470
|
| |\
| |
| | |
Merged by openshift-bot
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Most of this role's purpose was to set facts. The vast majority
of these facts were simply redefining user-supplied variables.
This commit also removes various artifacts leftover from
previous versions, as well as variables that seem to be
entirely unused.
|
| | | |
|
| |/
|
|
|
|
|
| |
Previous commit set 'openshift_master_config_dir' to
'/var/lib/origin' if undefined during upgrades.
This commit sets value to the proper directory '/etc/origin'
|
| |
|
|
|
|
|
|
| |
Currently, openshift_master upgrade play imports tasks directly
from the openshift_master role. This method does not honor
role defaults.
This commit changes sets openshift_master_config_dir if undefined.
|
| | |
|
| |
|
|
| |
- remove dangling bool
|
| |
|
|
|
|
| |
From now on, all master configurations use the api / controller split,
regardless of HA mode or previous configuration. This will be our only
supported configuration starting in 3.7 or 3.8.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes a bug which reported that AFTER a cluster upgrade from OCP 3.5
to 3.6, any masters which are later added via the scaleup playbooks
are setting a value for OPENSHIFT_DEFAULT_REGISTRY which is
inconsistent with the already configured masters.
* OPENSHIFT_DEFAULT_REGISTRY value is saved from oo_first_master
* The new scaleup master has a fact set noting it is a scaleup host
* The saved OPENSHIFT_DEFAULT_REGISTRY value is used instead of the
default for 3.6, which is to use a hard-coded registry value of
'docker-registry.default.svc:5000'
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1469336
|
| | |
|
| |
|
|
|
|
|
| |
Adds service file templates for both maste and node. These will lay down
in /etc/system/systemd to override what may already be present from a
package. These instances take into account the name of the container
daemon (docker or container-engine).
|
| |
|
|
|
|
|
| |
Using lineinfile and with_items, the items end up logged and in this
case include AWS credentials.
Simple us of no_log to hide them.
|
| |
|
|
| |
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use use_system_containers=true in the inventory file
alternatively you can select each component as:
use_openvswitch_system_container=true
use_node_system_container=true
use_master_system_container=true
system_images_registry holds the registry from where to fetch system
containers.
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
|
| |
|
|
|
| |
* Added checks to make ci for yaml linting
* Modified y(a)ml files to pass lint checks
|
| |
|
|
|
|
|
|
| |
We did this for install but not upgrade, leading to situations where the
service restarts after upgrade could take much longer than expected as
docker pulls down the new image. Now the images are present when we
restart services and should allow them to come back online much more
quickly, equivalent to rpm service restarts.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
These could exist from 3.1 releases or manual edits, and were getting
wiped out in all variants of the master sysconfig files as we template
these.
This change uses the established pattern of grepping them out if they're
there, then reapplying them if the user has not configured the
cloudprovider framework already.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactored the 3.2 upgrade common files out to a path that does not
indicate they are strictly for 3.2.
3.3 upgrade then becomes a relatively small copy of the byo entry point,
all calling the same code as 3.2 upgrade.
Thus far there are no known 3.3 specific upgrade tasks. In future we
will likely want to allow hooks out to version specific pre/upgrade/post
tasks.
Also fixes a bug where the handlers were not restarting
nodes/openvswitch containers doing upgrades, due to a change in Ansible
2+.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
