With the current template, people just fill in the name of their platform,
leaving the list of platforms as is. This makes it a bit hard to label
issues. Let's modify the template so the platforms are mentioned in a
comment and user explicitly ask writes (or copy&paste) the relevant
platform.
We're still getting issue reports about installer crashes that attempt
to summarize the issue but do not include copies of the actual error
messages. While summaries can be accurate, they're usually not much
more compact than a copy/paste of the errors from the logs, and it's a
lot easier to find existing reports for a given error if those reports
include the error you're looking for.
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
Make it easier for issue-reporters to find these docs, which will
hopefully help improve issue quality.
Ideally this would be a relative link into the local repository, in
case folks wanted to enable issues in a fork or some such. But
there's no way (that I've found) to do that which works from both
[1,2]. We can't event use an absolute-path reference
(/openshift/installer/blob/...), because GitHub interprets those as
relative to the filebrowser repo root when rendering [1] but not when
rendering [2]). Still, while I think hard-coding the org/repo is
ugly, we already do an awful lot of that for our internal Go imports.
[1]: https://github.com/openshift/installer/blob/master/.github/ISSUE_TEMPLATE.md
[2]: https://github.com/openshift/installer/issues/new
And print the error information if we can't extract it.
The .Stderr stuffing is because Terraform just prints usage
information to stdout (not stderr!) if you call it with an
unrecognized command:
$ terraform does-not-exit >stdout 2>stderr
$ head -n1 stdout
Usage: terraform [-version] [-help] <command> [args]
$ ls -l stderr
-rw-r--r--. 1 trking trking 0 Oct 2 17:14 stderr
and in this case we want to see that usage information. Ideally
Terraform would have printed "unrecognized command 'does-no-exist'" or
some such to stderr, but that's a bit bigger than we can work around
here.
This will make it easier to add special-case OWNERS files to
openshift/release while still getting the members slurped up with the
populate-owners tooling. That tooling pulls OWNERS_ALIASES since
openshift/release@e1f993fb (populate-owners: Also slurp
OWNERS_ALIASES, 2018-08-25, openshift/release#1285).
MAINTAINERS is obsolete since 49779c3e (OWNERS: Configure Prow with
approver and reviewer information, 2018-07-25, #71). I've also
dropped the email/IRC section, since as far as I know there are
currently no public lists or IRC channels for installer discussion.
Folks outside of Red Hat should communicate via GitHub issues and pull
requests, and I think that's the expectation for projects that don't
give alternatives in their CONTRIBUTING file.
