We haven't needed these since we dropped the parsers in f7a4e68b
(pkg/types/config: Drop ParseConfig and other Parse* methods,
2018-10-02, #403).
Generated with:
$ sed -i 's/ yaml:.*/`/' $(git grep -l yaml pkg/tfvars)
It's the default. The old parameter was deprecated before
terraform-providers/terraform-provider-aws@1cc81c92
(docs/data-source/aws_region: Remove now deprecated current argument,
2018-02-09, v1.9.0), and we're pinning 1.39.0 since ac5aeed6
(data/aws: bump aws provider, 2018-11-01, #594). Changing this
avoids:
$ openshift-install --log-level=debug create cluster
...
- Downloading plugin for provider "aws" (1.39.0)...
...
Warning: module.vpc.data.aws_region.current: "current": [DEPRECATED] Defaults to current provider region if no other filtering is enabled
...
In OpenShift 3.x we opened 9000-9999 for TCP for all internal connections
between masters, infra, and workers so that we could have a range that
host level services inside the cluster could coordinate on. This range
is analogous to node ports, except unlike node ports it is only available
on the inside. The most common consumers are node network metrics ports
(node exporter, cluster version operator, network operator, sdn, node
proxy) that need to be reachable from prometheus without magic tricks.
A second set is internal secured services that want to connect but must
be host network, like gluster, storage services, or other cluster level
proxies.
Open the range 9000-9999 by default so that new services don't require
either a reinstall or manual management. Future changes in the platform
may autoallocate from this range, but for now teams must reserve.
The intention here is to help people debug. If you like this
I may also try to do something similar for masters.
V2: Applied code changes mostly written by @wking
No longer needed since we dropped the tectonic-system namespace.
I edited Gopkg.toml by hand and then ran:
$ dep ensure
using:
$ dep version
dep:
version : v0.5.0
build date :
git hash : 22125cf
go version : go1.10.3
go compiler : gc
platform : linux/amd64
features : ImportDuringSolve=false
The kube-addon operator was the last remaining component in that
namespace, and it was just controlling a metrics server. Metrics
aren't critical to cluster functions, and dropping kube-addon means we
don't need the old pull secret anymore (although we will shortly need
new pull secrets for pulling private release images [1]).
Also drop the admin and user roles [2], although I'm less clear on
their connection.
[1]: https://github.com/openshift/installer/pull/663
[2]: https://github.com/openshift/installer/pull/682#issuecomment-439145907
We see a lot of libvirt issues do to ancient libvirt versions. Just
today, I fielded one from someone running QEMU 1.5.3 (from 2013!).
Asking for this information up front saves a follow up
request/response, and hopefully it's obvious enough that folks using
other providers can skip it.
Terraform can load plugins from a few places [1], but I've used the
standard path on POSIX systems. I expect folks who install to
non-standard locations will be able to adapt, and we'll worry about
making it easy for Windows when we get users on Windows ;).
[1]: https://www.terraform.io/docs/extend/how-terraform-works.html#plugin-locations
To keep the platform-specific code separate.
The only thing that wasn't perfectly clean about this separation is
that now the AWS and OpenStack packages have their own defaultVPCCIDR.
There's no reason that they need to agree on that CIDR, though, so I
haven't bothered setting up a common-default package for them to share
a single constant.
This allows the user to supply and use an on-disk asset (such as
install-config.yml) without the need to also supply the state file that was
created. This is helpful when re-using an on-disk asset for multiple
installations. In particular, hive would like to run openshift-install
with a supplied install-config.yml and no state file.
To effect this behavior, the asset store loads all of the on-disk assets that a
fetched asset depends upon prior to fetching the dependencies for the fetched
asset. From this, the asset store can determine whether the fetched asset is
dirty or not. If the fetched asset is not dirty and is on-disk or in the state
file, then the asset is used as is without generating any of the dependent
assets--as they would be ignored in resolving the fetched asset anyway.
Conflicts can occur when the asset store resolves in different ways the fetch of
two assets that share a dependency. For example, let us say that there are two
assets, A and B, that both depend upon asset C. Asset A is present on disk, and
asset B is not present on disk. When the asset store fetchs asset A, then asset
C will not be generated. However, when the asset store fetches asset B, then
asset C will be generated in order to generate asset B. Asset A could
potentially have data that conflicts with the data that would have been taken
from the asset C that was generated.
The new load function creates new asset instances to store the asset state loaded
from on-disk and from the state file. The store tests were relying on the same
asset instance being used throughout the test. Unfortunately, the tests now
need to use a lot of global variables, making the tests more fragile.
The assetToPurge field was removed since the same information can be obtained by
iterating over the assets map. Also, the parameter passed to the purge function
was changed to a single Asset instead of an Asset slice since the function is
only ever called with a single Asset.
Fixes https://github.com/openshift/installer/issues/545
Because this is the next step beyond "my cluster didn't install,
here's the --log-level=debug output", for folks working up bug reports
that don't match one of the common failures.
To keep the platform-specific code separate. These converters are a
bit tiny for their own packages, but they seemed too
application-specific to belong to pkg/types.
To avoid wiping out the caller's whole libvirt environment, regardless
of whether it was associated with our cluster or not. Using
cluster-name prefixes still makes me a bit jumpy, so I've added
warnings to both the environment-variable and asset-prompt docs
warning libvirt users to pick something sufficiently unique.
Also:
* Use {cluster-name}-master-{count} naming. We used to use
master{count}, which diverged from other usage (e.g. AWS, which has
used master-{count} since way back in ca443c5e (openstack/nova:
replace cloud-init with ignition, 2017-02-27,
coreos/tectonic-installer#7).
* Rename module.libvirt_base_volume -> module.volume. There's no
reason to diverge from the module source for that name.
And I've rerolled deletion to use a single call to each deleter,
failing fast if they error. That should address cases where we cannot
destroy a shut-off domain [1]:
$ virsh -c $OPENSHIFT_INSTALL_LIBVIRT_URI list --all
Id Name State
----------------------------------------------------
- master0 shut off
- test1-worker-0-zd7hd shut off
$ bin/openshift-install destroy cluster --dir test --log-level debug
DEBUG Deleting libvirt volumes
DEBUG Deleting libvirt domains
DEBUG Deleting libvirt network
DEBUG Exiting deleting libvirt network
DEBUG goroutine deleteNetwork complete
ERROR Error destroying domain test1-worker-0-zd7hd: virError(Code=55, Domain=10, Message='Requested operation is not valid: domain is not running')
DEBUG Exiting deleting libvirt domains
DEBUG Exiting deleting libvirt volumes
DEBUG goroutine deleteVolumes complete
DEBUG Deleting libvirt domains
ERROR Error destroying domain test1-worker-0-zd7hd: virError(Code=55, Domain=10, Message='Requested operation is not valid: domain is not running')
[...]
Now we'll fail-fast in those cases, allowing the caller to clear the
stuck domains, after which they can restart deletion.
The previous goroutine approach was borrowed from the AWS destroyer.
But AWS has a large, complicated resource dependency graph which
includes cycles. Libvirt is much simpler, with volumes and a network
that are all independent, followed by domains which depend on the
network and some of the volumes. With this commit we now take a
single pass at destroying those resources starting at the leaf domains
and working our way rootwards.
I've retained some looping (although no longer in a separate
goroutine) for domain deletion. This guards against racing domain
creation, as discussed in the new godocs for deleteDomains.
Also:
* Rename from libvirt_prefix_deprovision.go to libvirt.go. The name
is from 998ba306 (cmd,pkg/destroy: add non-terraform destroy,
2018-09-25, #324), but the implementation doesn't need to be
represented in the filename. This commit renames to libvirt.go to
match the package name, since this file is the guts of this package.
* Simplify the AlwaysTrueFilter implementation. No semantic changes,
but this saves us a few lines of code.
* Add trailing periods for godocs to comply with [2].
[1]: https://github.com/openshift/installer/issues/656#issue-379634884
[2]: https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences
We'd been defaulting it to ClusterName in InstallConfig.Generate, and
I see no reason for the user to want to create a separate name for the
network alone. The variable dates back to 4a08942c (steps: bootstrap
/ etcd / topology support for libvirtm 2018-04-24,
coreos/tectonic-installer#3213), where it is not explicitly motivated.
The old *PlatformType are from cccbb37a (Generate installation assets
via a dependency graph, 2018-08-10, #120), but since 476be073
(pkg/asset: use vendored cluster-api instead of go templates,
2018-10-30, #573), we've had variables for the name strings in the
more central pkg/types. With this commit, we drop the more peripheral
forms. I've also pushed the types.PlatformName{Platform} variables
down into types.{platform}.Name at Ahbinav's suggestion [1].
I've added a unit test to enforce sorting in PlatformNames, because
the order is required by sort.SearchStrings in queryUserForPlatform.
[1]: https://github.com/openshift/installer/pull/659#discussion_r232849156
OpenStack creds cold be in 3 different paths (etc, home config and
current dir). Instead of re-implementing the logic to find and read the
clouds.yaml file, we should use gophercloud which is the standard
go library for OpenStack.
Note that deployments on OpenStack are currently broken unless there's
a clouds.yaml under /etc/openstack.
Fixes #550
gophercloud and gophercloud utils are a library and a set of utilities
that provide common functionality to interact with OpenStack clouds,
configurations, etc.
We need these libraries to manage OpenStack configs as it's done
upstream and for future work like adding an OpenStack destroyer.
The asset store tests that call Fetch create residual state files (and could also use
any state files left over from previous tests). This change uses a temporary directory
for each test run so that the environment is clean before and after the tests.
