This change adds support for running `suspend/resume` on multiple
supported resources at the same time. This improves the user
experience by converting
```
flux suspend ks operator && \
flux suspend ks database && \
flux suspend ks app
```
to
```
flux suspend ks operator database app
```
This works for all types of resources (Kustomizations, Sources, etc.)
since it has been implemented at the `suspend.go` and `resume.go`
level.
When the `--wait` flag is passed to the `resume` command, then Flux
will wait for all resources in parallel within a goroutine each.
Each object is only processed once, even if user provided its name
more than once.
If suspension or resuming fails for one object, it is still carried
out for the remaining objects.
As a special case, the old behaviour of `resume` is retained, i.e.
when only one object name is provided, `resume` waits for the object
to become ready even if the `--wait` flag is not provided. In all
other cases the `--wait` flag is always considered.
closes#3746closes#3793
Co-Authored-By: Max Jonas Werner <mail@makk.es>
Signed-off-by: Rishikesh Nair <alienware505@gmail.com>
Signed-off-by: Max Jonas Werner <mail@makk.es>
This should prevent the generation of the object getting bumped, as
observed on a GKE K8s 1.18 cluster using the logic before this commit.
We only want to generation to increase when there are actual changes to
the `spec` of a resource, as some controllers use the `generation`
value to make assumptions about what they should do during a
reconciliation.
Signed-off-by: Hidde Beydals <hello@hidde.co>
controller-runtime methods now accept `client.Object` and
`client.ObjectList` rather than `runtime.Object`. This means the
adapter interfaces need to change signature, but happily, little else.
Since the list adapter is now distinct to the object adapter, `len()`
can go there instead of the command-specific interfaces.
Signed-off-by: Michael Bridgen <michael@weave.works>
It's a common pattern in the create commands to construct a value,
then (if not exporting it) upsert it and wait for it to
reconcile. This commit factors `upsert`, which does the update/insert
bit, and `upsertAndWait`, which does the whole thing.
Since these output messages, they are methods of `apiType` (previously
`names`), so that they have access to the name of the kind they are
operating on.
Signed-off-by: Michael Bridgen <michael@weave.works>
Most commands use either a kind, or a more readable spelling of a
kind, in their output. To make this easier, this centralises the
definition of those names in one place, and lets the command
implementations choose whichever they need.
Signed-off-by: Michael Bridgen <michael@weave.works>
Since the generic commands tend to share a few of the methods they
need -- at least AsClientObject -- it's worth having just one wrapper
struct for each API type, and adding methods to it where necessary.
For the automation types, I put these in auto.go.
While doing this I also did some tidying:
- I changed the name of the wrappers to `<type>Adapter`, and the
generic adapter to `universalAdapter` (it's only needed for delete,
so far).
- I de-exported and renamed some interface methods e.g.,
`exportItem`. They aren't needed outside the package.
Signed-off-by: Michael Bridgen <michael@weave.works>
This adds a command for deleting ImagePolicy objects. Since the
control flow for the command needs only a runtime.Object (and a name
for the type), it can be factored out.
I have made the argument (field in the deleteCommand struct) an
interface `objectContainer`, through which the command code gets a
`runtime.Object` to deserialise into (and delete). It could be simply
a `runtime.Object` here; however things like `getCommand` require
other methods, so it's convenient to have an interface for it.
Signed-off-by: Michael Bridgen <michael@weave.works>
Rishikesh Nair
Somtochi Onyekwere
Hidde Beydals
Stefan Prodan
Michael Bridgen