We currently do not show --external containers when the user specifies
it, unless they also specify the --all flag. This has led to confusion.
I see no reason not to list them without the --all flag if the user
specifies the option.
Fixes: https://github.com/containers/podman/issues/12353
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
We have to get the network ID from the network backend. With the
netavark backend we no longer use the sha from the name as ID.
[NO NEW TESTS NEEDED]
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Because we cannot reqad the networking mode in the frontent because we
should always use the server default we have to parse the mac and ip
address to the server via a default network. Now when the server reads
the default nsmode it has to reject the provided networks when the mode
is not set to bridge.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
It is important that we store the current networks from the db in the
config. Also make sure to properly handle aliases and ignore static ip/mac
addresses.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Rework the --network parse logic to support multiple networks with
specific network configuration settings.
--network can now be set multiple times. For bridge network mode the
following options have been added:
- **alias=name**: Add network-scoped alias for the container.
- **ip=IPv4**: Specify a static ipv4 address for this container.
- **ip=IPv6**: Specify a static ipv6 address for this container.
- **mac=MAC**: Specify a static mac address address for this container.
- **interface_name**: Specify a name for the created network interface inside the container.
So now you can set --network bridge:ip=10.88.0.10,mac=44:33:22:11:00:99
for the default bridge network as well as for network names.
This is better than using --ip because we can set the ip per network
without any confusion which network the ip address should be assigned
to.
The --ip, --mac-address and --network-alias options are still supported
but --ip or --mac-address can only be set when only one network is set.
This limitation already existed previously.
The ability to specify a custom network interface name is new
Fixes#11534
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Add the new networks format to specgen. For api users cni_networks is
still supported to make migration easier however the static ip and mac
fields are removed.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The swagger api docs used the extra Body struct as part of the request
which is wrong. We just want the plain type.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Network connect now supports setting a static ipv4, ipv6 and mac address
for the container network. The options are added to the cli and api.
Fixes#9883
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Make sure we create new containers in the db with the correct structure.
Also remove some unneeded code for alias handling. We no longer need this
functions.
The specgen format has not been changed for now.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
... now that they have no public users.
Also remove the HeaderAuthName type, we don't need the type-safety
so much for private constants, and using plain strings results in
less visual noise.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Having a parameter that modifies the provides types.SystemContext
seems rather unexpected and risky to have around - and the only
user of that is actually a no-op, others only provide a nil
SystemContext; so, remove that option and simplify (well, somewhat;
many callers now have extra &types.SystemContext{AuthFilePath}
boilerplate; at least that's consistent with that code carrying
a TODO to create a larger-scope SystemContext).
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Having a parameter that modifies the provides types.SystemContext
seems rather unexpected and risky to have around - and the only
user of that is actually a no-op; so, remove that option and simplify.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
which used to contain more context, but now are just
a pointless copy.
Should not change (test) behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It is no longer used.
Split the existing tests into MakeXRegistryConfigHeader
and MakeXRegistryAuthHeader variants. For now we don't modify
the implementations at all, to make review simpler; cleanups
will follow.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... which can be called independently.
For now, there are no new callers, to test that the behavior
has not changed.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... which can be called independently.
For now, there are no new callers, to test that the behavior
has not changed.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
This shares the code, and makes getConfigCredentials
and getAuthCredentials side-effect free and possibly easier to test.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... and have GetCredentials pass the values down to
getConfigCredentials and getAuthCredentials.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
It's possibly a bit more expensive, but semantically safer
because it does header normalization.
And we'll regain the cost by not looking up the value repeatedly.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Both have a single caller, so there's no point in looking up
the header value twice.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
In the "no input" case, return a constant instead of
continuing with the decode/convert path, converting empty data.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Don't create a single-element map only for the only caller
to laboriously extract an element of that map; just return
a single entry.
Should not change behavior.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Almost every caller is using it only to wrap an error
in exactly the same way, so move that error context into GetCredentials
and simplify the users.
(The one other caller, build, was even wrapping the error incorrectly
talking about query parameters; so let it use the same text as the others.)
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
... as an end-to-end unit test of the header creation/parsing
code.
Leave the docker.io and docker.io/vendor test cases commented out,
because they are currently failing.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Just a single function that handles all of Header,
headerConfig and headerAuth; we will split that later.
Signed-off-by: Miloslav Trmač <mitr@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=2030599
When you create pod, it shares the UTS namespace with Containers.
Currently the --hostname is not passed to the pod created when
you create a container and pod in the same command.
Also fix error message on supported --share flags
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Users should be able to override containers entrypoint using
`--entrypoint ""` following works fine for podman but not for podman
remote.
Specgen ignores empty argument for entrypoint so make specgen honor
empty arguments.
Signed-off-by: Aditya Rajan <arajan@redhat.com>
