<walters>
(Today I like manually schedule cosa pods against remote clusters to test things that way, I know gangplank can streamline this, I just don't know how to use it)
<dustymabe>
I guess I have stronger opinions here.. I guess we can just stop using it, but not delete the code
<dustymabe>
I think gangplank has value, but the truth is that we don't have clusters we can use to leverage it (i.e. no non-x86_64 kube/openshift clusters)
<dustymabe>
so we end up with a wrapper around `podman remote` anyway - and a ton of code/complexity/maintenance for not a lot of value
<dustymabe>
ok let me pivot to another topic
<dustymabe>
some of the work I'm doing to enable podman remote workflow in our pipelines will deal with the top level `cosa` entrypoint
<dustymabe>
rather than try to work on top of what is there now, when you are actively working to replace it
<dustymabe>
does that sound reasonable?
<walters>
oh i see
jpn has joined #fedora-coreos
jpn has quit [Ping timeout: 272 seconds]
<walters>
I'm totally cool with with that if you think it will help! As of yet, the framework for adding new subcommands natively implemented in Go isn't there and that's a big piece, but that's a well known thing and once that's there it seems like what you're proposing may be easier
<dustymabe>
so right now (based on your PR) it's not easy to write a new subcommand in golang? TBH for what I'm going to do with the new subcommand it's really small so I might just start with bash anyway
<dustymabe>
it's literally something along the lines of "check if env var exists && podman remote $image $0"
<walters>
hmm but shouldn't that kind of logic live in e.g. `cmd-build` and not the toplevel entrypoint?
<dustymabe>
It depends.. in the model I'm working off of if an env var exists then transparently the `cosa foo && cosa bar && cosa baz` series runs on a remote machine via podman-remote
<dustymabe>
this means that our pipline will be able to use the same code essentially for x86_64 or the other architectures
<dustymabe>
and it's mostly transparent to the user
<dustymabe>
and the user can also run the exact same commands locally and try it out
<dustymabe>
i.e. you don't have to change your development mental model around cosa
<dustymabe>
cosa remote-session sync-up #syncs local settings to the remote
<dustymabe>
cosa fetch && cosa build && cosa kola run
<dustymabe>
cosa buildupload, etc...
<dustymabe>
cosa remote-session destroy
<dustymabe>
unset COSA_REMOTE_SESSION
<dustymabe>
honestly you can do all of this with a bash alias (that's how I did the proof of concept), but I figured it would be better to have some native support in cosa for it
plarsen has joined #fedora-coreos
jpn has joined #fedora-coreos
<jlebon>
makes sense to me. it definitely seems less disruptive to start than individually teaching all the commands we need to know about `podman remote`.
didib has quit [Quit: Leaving]
<dustymabe>
ravanelli: are you still using AWS instances for your testing?