[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Add support for br --endpoint?

Hi all,

TL;DR: we can achieve what we want with the existing $BRCLI_HOME environment variable. Therefore suggest we defer this!

It turns out we already support the alternative suggestion of "custom configuration file" by using the environment variable $BRCLI_HOME. We discovered that our problem was just some new code had been added that didn't set this environment variable!

If you set $BRCLI_HOME, then it will use the configuration file $BRCLI_HOME/.brooklyn_cli. We can get jenkins to do exactly what we want by including the line (in all the scripts):



Much longer term, I agree that 'profile' is a nice way of thinking about it. However, to me it doesn't fit with idea of 'login' and 'logout' (e.g. aws CLI uses `aws configure --profile ...` to add a new profile).

But unless anyone is keen to work on that in the near future, I suggest we defer that conversation.


On 12/06/2018 10:12, Mark McKenna wrote:

I think i prefer the idea of a profile as its the same pattern that kubectl
sorta follow with contexts.
I assume we would have a way to delete a profile maybe `br logout --profile

For use within build / test pipelines I can see the `.brooklyn_cli` being
supplied so to give maximum flexibility it may be better to add both
`--profile` & `--config`


On Mon, 11 Jun 2018 at 20:20, Duncan Grant <duncan.grant@xxxxxxxxxxxx>


I like the endpoint option but I think it would imply that the username and
password parameters of br login should be optional in the case that they
have already been stored.

Possibly an alternative would be an init command a bit like the gcloud init
command but non-interactive.  br --config /path/to/.brooklyn_cli init
https://localhost:8443 admin pa55w0rd.  To me init better describes what
are doing anyway given there is no option to log out.



On Mon, 11 Jun 2018 at 17:49 Aled Sage <aled.sage@xxxxxxxxx> wrote:

Hi all,

TL;DR: I want to add `--endpoint` to the br command, because `br login`
has global scope.

We at Cloudsoft use `br` in our qa jenkins jobs. However, the `br login`
command has global scope. This means that two jobs run on the same
jenkins slave (both running as user `jenkins`) will interfere if their
`br login ...; br catalog add ...` commands become interleaved.

I propose that we add support for a `--endpoint` argument in br
commands. For example:

      br login https://localhost:8443 admin pa55w0rd
      br --endpoint https://localhost:8443 catalog add /path/to/mybundle/

Note that `br login` stores the credentials in ~/.brooklyn_cli, along
with a "target" for the endpoint that is currently active.

Alternative approaches include:

1. Custom configuration file, such as:

      br --config /path/to/.brooklyn_cli login https://localhost:8443
admin pa55w0rd
      br --config /path/to/.brooklyn_cli catalog add /path/to/mybundle/

2. Introduce the notion of "profiles", such as:

      br login --profile staging https://localhost:8443 admin pa55w0rd
      br --profile staging catalog add /path/to/mybundle/

But profiles would be more complex to implement - it implies support for
multiple logins to the same endpoint with different user:credentials.