Hi folks, The onyx team is dealing with sharing environments between multiple people. Currently how this is handled is that often there is a shared file system somewhere that contains the environments directory, and people use juju from there.
We are in the middle of dealing with simple user management tasks, so we can at least have multiple different user identities connecting to an environment. Initially all users that can connect to an environment will have admin privileges. We want to ease the way that we share environments. The initial work that has been signed off includes the ability for an existing admin to create a new user in state server and to create a .jenv file that is sufficient for that user to connect to the environment. This is half the problem solved. What we want to do is make it easy for a beginner user to start using someone else's environment. Let's say that I have an existing environment, and I want to allow Eric access to that environment. I'll run the command: $ juju user add eric "Eric the Viking" --output=foo-eric.jenv This will create a .jenv file that contains what is needed to allow Eric to connect to my environment. I now email that file to Eric (or pass it to him on a USB key). Now what? Let's also assume that Eric isn't very familiar with juju, and has just installed it. The proposal: We add a command [1] juju connect that makes it easy for Eric to connect to the environment. Now ideally where we'd like to get to is the following: juju connect eric@<api-endpoint> [<env uuid>] Where Eric wouldn't need the .jenv file at all, but this would connect to the API, prompt for a password, and then look for the environment identified by the uuid specified. For current environments where we have only one environment supported by the state server which has the api server that is being connected to, the uuid would be optional, but if it is specified, the command should fail if the uuids don't match. PROBLEM: right now all connections to the api server are secured with TLS and the client-cert. I want to add this command to behave this way because I think it leads us to where we want to go, but in order to do that, we need a few interim steps: juju connect --jenv ~/Downloads/foo-eric.jenv What this would do would be to effectively copy the jenv file into the correct location for the juju client ($JUJU_HOME/environments) without the user knowing nor caring. There should probably be a few extra checks like making sure that there are no name clashes etc. We also talked about actually connecting to the environment identified by the .jenv file, and use the name of that environment as a default environment name to use. The user would be prompted for the local name they want to call this, with the default being the name of the environment. We can also catch name clashes there if there are some: $ juju connect --jenv ~/Downloads/foo-eric.jenv local environment name [foo-production]: In the future we will have servers that we can connect to over the API where the connections are over SSL with signed certificates, and so the client will not need a client-cert for authenticated connections. So in that world, we would have similar behaviour: $ juju connect eric@awesome.ninja fb5a2570-e6f2-11e3-ac10-0800200c9a66 password: local environment name [foo-production]: and the result would be a file $JUJU_HOME/environments/foo-production.jenv being written out with Eric's credentials. The connect function could default to the known default socket, or allow specification on the command line: $ juju connect eric@local.ninja:38013 fb5a2570-e6f2-11e3-ac10-0800200c9a66 We do have the current issue of knowing which end points will be SSL protected and which are TLS with a client-cert, but for now, we know that we need a client cert for the connection. In order to handle this behaviour now, I suggest we do the following: $ juju connect e...@random-aws.com fb5a2570-e6f2-11e3-ac10-0800200c9a66 --client-cert ~/Downloads/cert.txt password: local environment name [foo-production]: This at least moves us in the right direction. Thoughts? Tim [1] An alternative command name could be 'login'. We should also have an equivalent 'logout' or 'disconnect' that removes the .jenv file (with sufficient warnings about the environment still running). -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
