Dusty Mabe

I feel like there's a lot of overlap here with `cosa buildfetch --build=xyz --stream=testing-devel && cosa kola run --build=xyz`.

@HuijingHei do we know if this statement is still the case today? > The current [api v1](https://pkg.go.dev/google.golang.org/api/compute/v1#ConfidentialInstanceConfig) is not yet supported for `confidentialInstanceType` , but in [api alpha](https://pkg.go.dev/google.golang.org/[email protected]/compute/v0.alpha#ConfidentialInstanceConfig), should wait...

You should be able to use the `docker` container runtime to run COSA and build artifacts. You'll need to adapt the [documented podman invocation](https://github.com/coreos/coreos-assembler#define-a-bash-alias-to-run-cosa). One thing you'll definitely need is...

I think a short path to victory here is to just call `plume make-amis-public` twice in the pipeline (once for primary AWS partition and one for AWS Govcloud, if those...

This would need related changes in https://github.com/coreos/coreos-ci-lib to keep the status quo with what we have today. We'd also probably need to make that code stop relying on the cosa...

> This would need related changes in https://github.com/coreos/coreos-ci-lib to keep the status quo with what we have today. Well maybe not. Does this affect the defaults for `kola testiso` too?

I'm not 100% sure we want to make this change, but I dug into the problem space today and figured I'd propose it if for nothing else than to reference...

cc @kalev @owtaylor - anybody in particular I could get to look at this issue?

Thanks @jistr - the workaround worked well for me. Anyone know how we can fix this problem without working around it?

Note that using the become machinectl plugin seems to work for this because it creates a full user session. ```yaml become: yes become_user: dustymabe become_method: machinectl ``` The only problem...