[feedbacks wanted] Fly CLI team scope command format

We are planning to make fly cli command to be able to scope in a different team/teams with the parameter(s) --team.
E.g.: fly -t TARGET containers --team OTHER-TEAM. This command is going to show containers in team OTHER-TEAM if the user is authorized to the team OTHER-TEAM.

For pipelines, volumes, containers we are planning to provision multiple teams with --team multiple times.
For command jobs and the other commands about pipeline we are planning to support single team with parameter --team.

However, the commands like trigger-job take a parameter -j PIPELINE/JOB. Do you think the format TEAM/PIPELINE/JOB make more sense than a new parameter --team?

Any suggestions on the above change of fly cli?

I think it’s great that the fly CLI will be able to target teams within a target. In general though, I am a bit worried about what happens to “targets” (-t) more mid/long-term.

I love that concourse switched from team-based to user-based, so I can be logged into many teams at once. The -t parameter always targeted a single team (as you specify it during the login command). How will this change in the future? If this is one of the early steps to rework -t, brilliant, count me in. If this is meant to co-exist over a long time though, I’m worried about explaining this to my users.

In an ideal world, I would want -t to represent the cluster that I am targeting, and then use the --team flag to run commands against teams (caveat: commands will get longer? Can we specify a --default-team with a target?).
For some context, we have around 400-500 developers working with concourse from a regular basis to “maybe once a month”. Concourse and the CLI have a fair bit of a steep learning curve, and having to explain to my devs that you log in to a single team, but then can target other teams with the same target again is going to be very confusing.

Sorry for straying quite a bit off topic here, but if there’s any higher-level story/epic to this it would be awesome if it could be linked; I’m just worried about the complexity of the fly cli.

As for your question, is there a way to implement this without breaking backwards-compatibility? We provide boilerplate Makefiles to our team that use the hijack commands and it would not be great if all of them had to be changed.

For the pipelines, volumes, and containers commands, if I’m understanding you correctly they would look like this:

fly -t ci containers --team team1 --team team2 --team team3 ...

Why not just accept a comma-separated list and have the flag be called teams (plural):

fly -t ci containers --teams team1,team2,team3

For the commands like trigger-job, I don’t think it’s worth introducing a breaking change with a new -j format of team/pipeline/job. Any scripts that people wrote will have to be updated and if a dev is only on one team then it’s going to seem really silly to have to always type in their team name when triggering a job. Just add a --team parameter that’s optional. Keeps it simple and doesn’t break fly for our current users.

@Rukenshia I really like this idea

This is part of a bigger epic, see here: https://github.com/concourse/concourse/issues/4192
tl;dr is it’s for admins of Concourse, to make it easier for them to work with many/all teams.

Here’s the main story/issue for this specific command: https://github.com/concourse/concourse/issues/4196

1 Like

Many thanks for the link. Been waiting from the admin side of things for being able to get more visibility into the system and I figured this change would be a part of that, it just needs to be clear for end-users which is the way to go (log in with one target, then use --team or each team a target etc) :slight_smile:

Thinking of pushing the story in this direction, which isn’t changing much to be honest.
We would want to enable these two workflows. This first one is for most of the fly commands.

# use default team
fly -t ci <command> <command-options>
# use another team
fly -t ci <command> <command-options> --team-name team3

For containers, volumes, and pipelines we want to enable these workflows:

fly -t ci <command> <command-options>
fly -t ci <command> <command-options> --team-name team1
fly -t ci <command> <command-options> --team-name team1 --team-name team2 -n team3
fly -t ci <command> <command-options> --all-teams

wdyt?

trigger-job and other pipeline related commands should use TEAM/PIPELINE/JOB format, much like docker images, and assume team MAIN by default if it’s not specified.

1 Like

Looks good to me, but hopefully the plan is to throw an error when supplying multiple --team-name where only one is permitted? Otherwise I would take another flag name to differentiate commands that take one vs many teams.

For the TEAM/PIPELINE/JOB notation as mentioned please try to find a backwards compatible way if possible :pray: One way of doing it might be to assume the targets team by default(?)

thank you for your suggestion!

Thanks @taylorsilva!

My general thoughts look like below.

When the fly command is:

  • Multi team applicable:

    fly -t TARGET containers --team TEAM1 --team TEAM2
    

    With the repeatable --team we could benifit from the library jessevdk/go-flags. These multiple --team parameters are going to be parsed to a array in subcommand definition. e.g.:

    type ContainersCommand struct {
            Json bool `long:"json" description:"Print command result as JSON"`
            Teams []string `long:"team" short:"n" description:"......"`
    }
    
  • Single team applicable:

    Solution 1:

    fly -t TARGET trigger-job -j PIPELINE/JOB --team TEAM1
    # --team is optional. if it is absent, the default value is the team user logged in.
    

    Solution 2:

    fly -t TARGET trigger-job -j TEAM/PIPELINE/JOB
    # TEAM is optional. if it is absent, the default value is the team user logged in.
    

Both Solution 1 and Solution 2 should not break any existed scripts.

WDYT?

That’s true when a user login in with fly command fly login --team the user has a default team. I don’t think there is too much change for the --team. In general, it is going to give the user the ability to operate other team(s) without fly login --team to that team again. Those parameters are optional, so there shouldn’t be a problem with backwards-compatibility. Please see my post [feedbacks wanted] Fly CLI team scope command format . Wish to see your opinions!

Agree. It should be better to throw an error in that situation.
In term TEAM/PIPELINE/JOB, TEAM would be optional. so, there shouln’t be a backwards compatible issue.
Please see [feedbacks wanted] Fly CLI team scope command format
WDYT?

I prefer solution one over solution two. It’s easier for us to parse solution one with the go-flag package we’re using and is consistent with the behaviour of all the other commands. Solution two is cool but cool doesn’t make for a good UX. I think it’s important that our CLI commands are consistent across as many commands as possible. Makes the CLI feel intuitive.