SpecGen is our primary container creation abstraction, and is
used to connect our CLI to the Libpod container creation backend.
Because container creation has a million options (I exaggerate
only slightly), the struct is composed of several other structs,
many of which are quite large.
The core problem is that SpecGen is also an API type - it's used
in remote Podman. There, we have a client and a server, and we
want to respect the server's containers.conf. But how do we tell
what parts of SpecGen were set by the client explicitly, and what
parts were not? If we're not using nullable values, an explicit
empty string and a value never being set are identical - and we
can't tell if it's safe to grab a default from the server's
containers.conf.
Fortunately, we only really need to do this for booleans. An
empty string is sufficient to tell us that a string was unset
(even if the user explicitly gave us an empty string for an
option, filling in a default from the config file is acceptable).
This makes things a lot simpler. My initial attempt at this
changed everything, including strings, and it was far larger and
more painful.
Also, begin the first steps of removing all uses of
containers.conf defaults from client-side. Two are gone entirely,
the rest are marked as remove-when-possible.
[NO NEW TESTS NEEDED] This is just a refactor.
Signed-off-by: Matt Heon <mheon@redhat.com>
Don't require the need to connect to an engine/podman
machine when doing the farm create, ls, rm, and update
commands.
Connection to the engine is required for the farm build
command.
[NO NEW TESTS NEEDED]
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
For a base template like `foo@.container` the WantedBy and RequiredBy
keys does nothing. However, if a DefaultInstance= key is specified
that is used by default.
However, even if the DefaultInstance= is not given, the Install
section is still useful, because you can instantiate the generic
template by making a symlink for it, and that symlink will then
pick up the instance id.
So, for example, this foo@.container will not enable anything
on boot.
```
[Container]
Image=foo
Exec=sleep 100
[Install]
WantedBy=other.container
```
But if you have a symlink 'foo@instance.container` -> `foo@.container'
then the `foo@instance` service will be marked as wanted by `other`.
In addition, even if the main template doesn't have an Install
section, you can instantiate it with a symlink like above, and then
enabling it using a dropin file like
foo@instance.container.d/install.conf containing:
```
[Install]
WantedBy=other.container
```
Signed-off-by: Alexander Larsson <alexl@redhat.com>
This helper splits out a templated filename into the base template and
the instance name. This will be used later.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Podman5 will be shipped only on f40 and higher, so packit downstream tasks
should be enabled only for those.
Using `CI:DOCS` as the change only affects downstream Fedora, nothing
worth spending CI minutes on.
[NO NEW TESTS NEEDED]
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
Given that we can have multiple image digests,
fix the inspect test to check whether the digest
given matches one of the digests of the image.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Since images can have multiple digests, it is better
to compare the image ID as that will definitely change
on an update and each image can only have one ID.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
