On Wed, Apr 27, 2016 at 9:55 AM, John Meinel <j...@arbash-meinel.com> wrote:
> > > On Tue, Apr 26, 2016 at 10:41 PM, Andreas Hasenack <andr...@canonical.com> > wrote: > >> On Tue, Apr 26, 2016 at 3:11 PM, John Meinel <j...@arbash-meinel.com> >> wrote: >> >>> I believe --config can take a file rather than just a 'key=value' >>> pairing. So you can save all your config to a file and pass it in with >>> '--config myconf.yaml' >>> >>> There was discussion of having a default search path for some of the >>> config, but I'm not sure if that got implemented, nor if it is actually >>> better since it is another magic place that you have to discover. >>> >>> >> This is the experience with juju 1: >> juju switch scapestack >> juju bootstrap >> >> This is the same experience with juju 2: >> juju bootstrap scapestack-controller scapestack --config >> ~/juju2-configs/scapestack.yaml >> >> > But where did the settings for scapestack get set up in the first place. > You're missing some of the original "edit ~/.juju/environment.yaml" to > insert the right information. > > The scenario is starting from an already configured cloud in both juju1 and juju2, and my use case is MAAS, not public clouds. Except in juju2 I have to specify the configuration file everytime. If starting from scratch, the juju2 way requires even more steps. > If you are sharing information with someone else, being able to give them > the file with all of the configuration becomes quite a bit easier, as you > gave them the file, they saved it somewhere they know about, and then they > pass that in to the bootstrap command. Rather than giving a snippet, that > needs to be inserted into an existing file in the right place, and then it > magically works if you named everything correctly. > This configuration file you mention is far from complete. It's 1/3 of the details, as it does not have, for example, the cloud endpoint, nor the credentials. Just bootstrap-timeout, in my case. > > So while for people that have everything set up already, there is a bit > more to write, for people coming to the system I think it is quite a bit > more obvious for them. > I think it's less obvious. At least it was less obvious to me, maybe because of my juju1 experience. And changing is fine: just wanted to share what my experience with this new process was. It's my understanding that there are 3 elements that you have to configure in juju2, separately, when you start from scratch: cloud definition, credential information and remaining configuration. In juju1 all 3 are in the same environments.yaml section. All under the "environment" (now model) name. You go from this one snippet (environments.yaml) to 3 files and 2 commands. In juju2 you have to create a cloud file for MAAS, then create a credentials file for that MAAS. Then import both (two commands), which links the credentials to the "maas cloud". Then create a config file for things that cannot be specified in the cloud definition file (like bootstrap-timeout, crucial for the MAAS provider), and specify that everytime you bootstrap. > As noted, the number of times you have to bootstrap should be going down, > and if you are bootstrapping different-but-similar, then you again have a > single config that can be reused. > I'd love to be able to share a controller node with my colleagues. I tried setting that up and creating a juju user, but in the end that user's MAAS nodes were all allocated to "me" in MAAS, which was a bit unexpected. The person running juju commands had his own MAAS credentials setup. Until that is not setup, I can't keep a MAAS node allocated to my user 24/7, it's an expensive resource. I need to play with this shared controller idea a bit more.
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
