Since the previous commit removed the associate_public_ip_address, we should
not be hitting the new behaviour introduced in 1.2.3, thus everything will
hopefully work as before.
The documentation for this option says the following:
> If using a non-default VPC, public IP addresses are not provided by default.
> If this is true, your new instance will get a Public IP. default: unset
We don't specify a VPC in the packer build, thus we are using the default
one. Therefore, I don't think we actually need this option as it's useful
only for non-default VPCs.
See
https://developer.hashicorp.com/packer/plugins/builders/amazon/ebs#run-configuration
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Validate custome repository filenames in order to
avoid unexpected `5xx` errors when building an image.
Before this the filename was only validated at the
yum repo stage, which was causing unexpected errors.
- remove `custom-repos.sh` integratoin test
- add custom repositories check to `api` tests for supported
images
- verify custom repositores are added to /etc/yum.repos.d
- verify gpg key is saved to /etc/pki/rpm-gpg (for inline keys)
Replace the dnf-json `Hash()` function in
favour of a hash calculated using the
`rpmmd.RepConfig.Hash()` function. The
`repoHash` field is populated when converting
a `rpmmd.RepoConfig` to `dnfjson.repoConfig`
object. The `dnfson.repoConfig.Hash()` function
then returns the `repoHash` field instead of
re-calculating the hash.
DNF has more elaborate locking system and can wait for other instances of
itself when installing packages. Using rpm directly to install local
package is causing failures in CI due to it not being able to acquire
lock on `/var/lib/rpm/.rpm.lock`.
Using DNF should improve the situation, although there is no good
documentation to link and support this claim for sure.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
Create an osbuild yum repository from
`rpmmd.RepoConfig`. Additionally, remove
pointers from the `YumRepository` struct,
since this will add values for fields that
weren't explicitly set by the user in the
repo customizations.
Create some utility functions that will be used for implementing
custom repo configuration files. This commit adds these functions:
- a helper to get the filename of a custom repo, or the
`<repo-id>.repo` if the filename is empty
- a function to convert the custom repos to a map of `RepoConfig`.
This function also creates an `fsnode.File` for each inline gpg
key set in the customizations and swaps the inline key for the
file path. The function returns the map of `RepoConfig` and a list
of `fsnode.File` containing the inline gpg keys.
Convert some of the fields in the `RepoConfig` struct
to pointers. Since `RepoConfig` will be used to convert
custom repositories to an array of `osbuild.YumRepository`,
we need to ensure that fields that are not set explicitly
are not saved to the `/etc/yum.repos.d` repository files.
Update the internal RepoConfig object to
accept a slice of baseurls rather than a
single field. This change was needed to
align RepoConfig with the dnf spec [1].
Additionally, this change adds custom json
marshal and unmarshal functions to ensure
backwards compatibility with older workers.
Add json tags to the internal rpmmd config
since this is serialized in dnfjson.
Add unit tests to check the serialization
is okay.
[1] See dnf.config
Version 1.2.3 made changes to how the plugin handles auto-selection of a
subnet when it's not specified, see
f1ec287c77
Sadly, the new algorithm selects us-east-1e for us that doesn't support
the machine types we use (c6*.large) which causes the build to fail.
I reported it here:
https://github.com/hashicorp/packer-plugin-amazon/issues/368
One workaround might be to pin a working subnet, but that's apparently also
broken in 1.2.3, see
https://github.com/hashicorp/packer-plugin-amazon/issues/367
Therefore, I decided to pin the plugin to 1.2.2 for now, and see what's
the recommended approach from terraform guys.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
Add a local name for the fedora minimal image which includes the tag
`v1`.
Check the image info for the expected names:
1. For the fedora-minimal image, the name as it appears in the blueprint
should be included in the names list.
2. For the manifest-list-test image, the full source reference should be
included in the names list since no name was specified in the
blueprint.
Add name field to the manifest-list-test container in the test
request. The value is the same as the source but with a `v1` tag
added.
In the manifests, the name field for the manifest-list-test is added to
the skopeo stage. The `name` option of the fedora-minimal container in
the skopeo stage is also changed to reflect the full source reference
including the `latest` tag.
Set the LocalName for the spec using a separate argument in the
NewSpec() constructor instead of reusing the `source` arg.
The name is already available in the calling scope in the client's
Resolve() method.
If the LocalName is an empty string, default to the remote (source)
reference. This is a change from the previous behaviour which only used
the base source.Name(). The full source corresponds to the
user-provided source value, which includes any specified tag or digest.
The `name` argument which is used in the `Resolve()` function should
always correspond to the user-provided container name.
The PR which added manifest lists and the format-request-map was changed
to include two containers for the `with-container` compose requests [1]
was rebased after the PR which added RHEL 8.9 and RHEL 9.3 was merged
[2]. The test manifests were not updated after the rebase, so they were
never created with the new request.
Updating them now.
[1] https://github.com/osbuild/osbuild-composer/pull/3336
[2] https://github.com/osbuild/osbuild-composer/pull/3350
This reverts commit 2b1facb44d.
The GPG key is now present in the RHUI client RPM, so there is no need
to not import it during the image build.
Signed-off-by: Tomáš Hozza <thozza@redhat.com>
We had this weird condition in code that prevented composer to create groups
with the same name as a user has. This unfortunately means that you are not
able to create a user with a primary group with a certain GID that has the
same name as the user. There's the gid field in the user customization,
but it requires that the group already exists.
In order to allow that, we need to remove the condition. From now on, it's
possible to create groups with the same name as a user has, which can be used
to create primary groups with a custom gid.
Note that the lorax compatibility behaviour was actually wrong. When lorax was
given a custom gid for a user, it didn't require the gid to exist. When it
didn't, the group was just created. Thus, we still don't have full backward
compatibility, but at least we now have support for this.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
