All BoltDB access and update functions now understand namespaces.
Accessing containers outside of your namespace will produce
errors, except for Lookup and All functions, which will perform
their tasks only on containers within your namespace.
The "" namespace remains a reserved, no-restrictions namespace.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Dependency containers must be in the same namespace, to ensure
there are never problems resolving a dependency.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Add basic awareness of namespaces to the database. As part of
this, add constraints so containers can only be added to pods in
the same namespace.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
this should represent the last major changes to get darwin to **compile**. again,
the purpose here is to get darwin to compile so that we can eventually implement a
ci task that would protect against regressions for darwin compilation.
i have left the manual darwin compilation largely static still and in fact now only
interject (manually) two build tags to assist with the build. trevor king has great
ideas on how to make this better and i will defer final implementation of those
to him.
Signed-off-by: baude <bbaude@redhat.com>
Closes: #1047
Approved by: rhatdan
I got my database state in a bad way by killing a hanging container.
It did not setup the network namespace correctly
listing/remove bad containers becomes impossible.
podman run alpine/nginx
^c
got me in this state.
I got into a state in the database where
podman ps -a
was returning errors and I could not get out of it, Makeing joining the network
namespace a non fatal error fixes the issue.
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
Closes: #918
Approved by: mheon
Add a mutable state to pods, and database backend sutable for
modifying and updating said state.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Closes: #784
Approved by: rhatdan
Containers in pods cannot depend on containers outside of the
same pod. Make the reverse true as well - containers not in pods
cannot depend on containers in pods. This greatly simplifies our
dependency handling, as we can guarantee that removing a pod will
not encounter dependency issues.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Closes: #558
Approved by: rhatdan
Currently, we will error if the DB is configured with the default
containers/storage config, and then opened by a libpod which has
explicitly set the defaults. This is due to us using an empty
config by default (to tell c/storage to use its defaults).
This patch changes our handling so that unset storage config
(using the default) and explicitly setting the defaults are both
compatible.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Closes: #423
Approved by: baude
Now, we don't need to use the global ID registry to iterate - we
can iterate only through containers or only through pods, without
having to iterate through both.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Closes: #184
Approved by: baude
This solves some dependency problems in the state, and makes
sense from a design standpoint.
Containers not in a pod can still depend on the namespaces of
containers joined to a pod, which we might also want to change in
the future.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Closes: #184
Approved by: baude
This allows us to JSON it and stuff it in the DB - previously,
all pod fields were private, so JSON couldn't encode them. This
allows us to keep all pod fields private by having a substruct
with public fields.
Signed-off-by: Matthew Heon <matthew.heon@gmail.com>
Closes: #184
Approved by: baude
