--json output doesn't work on vultr?

[unusualevent]

trying to get --json output to work for:

• ops image list -t vultr --json
• ops instance list -t vultr --json

are global options something that like MacOS needs to be at the front of the command? or can they be at the end of the options?

[unusualevent]

that would be useful to script together:

old_image=$(ops image list --json --filter "somename" | jq 'sort to newest')
go build thing.go
ops image create imgname -t vultr
# get single ID instead of a table
image_tag=$(ops image list --json | jq 'sort to newest....')
# launch newer instances
for i in 1..5; do
ops instance create $image_tag -t vultr --label somelabel --domain $i.somedomain
done
sleep 10m # let the cluster heal
# kill the old instances
for instance in $(ops instance list --filter $old_image); do
ops instance delete $instance -t vultr
done

[eyberg]

since we have so many providers/targets we sometimes don't add functionality for everything at once - this should be relatively easy to do though; happy to accept any prs for it

[unusualevent]

how ugly can the PR be? I'm also after getting the labels / domain names / names built - are you expecting PRs to have no new dependencies or something?

[eyberg]

we are totally ok with prs that don't diverge much from existing behavior and add incremental benefits/features

I think we can merge things that are shorter/feature specific much faster than larger changes - if you have completely different requests I'd break those up into diff prs

as for including new deps - we'd like to avoid that as much as we can - there's already a lot of existing 3rd party software that's included - good chance you can find existing behavior elsewhere in the code that could be re-used

[unusualevent]

@eyberg looking through this trying to find an example of where I would need to extend the provider.

[unusualevent]

added to PR #1462

[eyberg]

thanks!

[unusualevent]

@eyberg note - I can't build this locally. You're on 1.19.5 and I was using go1.20.3 - so I guess it's gonna have to wait until a new release artifact is published.

[eyberg]

the version shouldn't matter; if you're running into a build issue that is a diff. problem (possibly protobufs?)

[unusualevent]

https://github.com/distribution/distribution/issues/3590 <- it's this. my checksum db doesn't match the one you checked into the repo, when I clean the cache and retry it.

[eyberg]

oh, you could nuke the gosum, bump go.mod deps and you'll prob be ok

[unusualevent]

nice, so this works vultr=$(ops instance list -t vultr --json | jq -r '.[] | select(.tag=="nanos")|.main_ip') - I just had to add the "nanos" tag to the instance after it was made.

Is there an existing convention/preference if I add hostnames/labels/tags to the vultr part of the cli? that would make filtering using JQ a little easier. Is the cli option supposed to be something like --label?

[eyberg]

yes - we add tags to a handful of providers today such as aws (https://github.com/nanovms/ops/blob/master/provider/aws/aws_image.go#L118) and gcp ( https://github.com/nanovms/ops/blob/master/provider/gcp/gcp_instance.go#L42 ) and filter everything based on that - we can/should do the same for vultr as it's very common to have a mix of nanos instances and non-nanos instances

[eyberg]

added tags for vultr instances here https://github.com/nanovms/ops/pull/1472 - i didn't see offhand a way to do this for snapshots