`juju register` should add cloud definition to local client config


#1

It would be super useful if when registering with a controller, the details for the cloud would be initialized in the local client config too. Without this, it leaves the new user with quite a bit more configuration then just running the register command in order to start using the new controller/cloud.

Thanks!


#2

Hi, thanks for this question. What sort of extra configuration did you need to do? What information is missing? My client has the file .local/share/juju/controllers.yaml.


#3

The user can not add their own model until they have a cloud + credential definition for the cloud the controller is on.

Decreasing the init workload on new users by automatically adding the definition for the cloud they are registering +1!


#4

I’m not sure on this. Getting allowed access is one thing, adding those cloud credentials to the user is another. I’m curious a bit more on the actual workflow you’re looking for users to have and if the right thing isn’t more in line with our plans to add permissions to credentials on the controller so I can grant access to james to my google credential on the controller for new models vs giving him the actual keys.


#5

I’m not sure there are any credentials associated with the cloud definition… ?

Looking in my clouds.yaml

clouds:
  bdxopenstack:
    type: openstack
    auth-types: [userpass]
    endpoint: http://10.10.20.23:5000/v3
    regions:
      RegionOne:
        endpoint: http://10.10.20.23:5000/v3
  dcmaas:
    type: maas
    auth-types: [oauth1]
    endpoint: http://10.10.0.103:5240/MAAS

And the k8s cloud definition

clouds:
  myk8scloud:
    type: kubernetes
    auth-types: [userpass]
    endpoint: https://172.31.102.181:443
    ca-certificates:
    - |-
      -----BEGIN CERTIFICATE-----
      ....
      -----END CERTIFICATE-----


#6

Hi James. The user who has been granted ‘add-model’ access needs to add their credential locally (add-credential) in order to create a model.


#7

Correct, but they also need a definition for the cloud to be able to add the credential.


#8

Fair enough but you did originally point out "The user can not add their own model until they have a cloud + credential definition for the cloud " so I’m just stating that I’m not comfortable going with credential definitions. I also think that we have to worry about things like collisions in folks that do already have a cloud definition as well.

This starts to feel like perhaps we can do something with an interactive register command that gives an option to copy locally or what not as optional steps, but doesn’t require it for things like scripted setups, or setups where you really don’t want the clients to have more than they need to get the job done.


#9

Ah, gotcha. You’re talking about a private cloud (e.g. not listed in the default output to juju clouds).


#10

+1 to all this. After thinking about it, I guess going through the add-cloud interactive prompt isn’t too cumbersome, and only takes a user to know a few minimum configs for their cloud. We just hit some bumps yesterday trying to get users registered and working on our openstack controller and I was trying to touch on some of the papercuts and pain points we hit.

Totally - then we wouldn’t be making any assumptions about how the cloud would be configured, but also give the user the option to have the cloud definition automatically added if they choose. I think I’m starting to see how automatically adding things to the cloud definition may not be as simple as I initially thought. That said, I like the where you are going with this!


The Juju Show #44 - 6PM UTC - Getting and using Juju 2.5