juju2: how to edit a maas "cloud"?

John Meinel john at arbash-meinel.com
Wed Apr 27 14:15:42 UTC 2016


...


> 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.
>

So the cloud definition is something that needs to be created, but isn't
that shareable? I'm actually wondering if it is something that we could get
MaaS itself to generate, such that you go to a link on your running MaaS
and it gives you the cloud definition file. It does look like we could do
registration differently than a cloud definition file, though. For known
cloud types, I think Juju knows most of the items (auth-types, etc at least
would have sane defaults), and the only bit we'd really need is the
auth-url. Something like:

  juju add-cloud mymaas --type maas --endpoint https://10.0.0.1/blah

I guess one bit of complexity is that you can have multiple regions for a
given cloud, so there is potentially a few endpoints. It does feel like
streamlining the Maas case is something that would be worth spending a fair
bit of time on.

We do also have "juju add-credential cloud-name" that will start a "wizard"
dialogue to prompt you for the user/password/auth-key bits that you need
for the given cloud.

I do think there was an interesting goal to separate the bits that are
generic (everyone finds out about the same cloud endpoints, etc) from the
things that are user specific (what is your username and password). From
what is the particular details of this controller. One can certainly argue
that bootstrap timeout is a property of the cloud itself (how long do
machines take, on average, is not dependent on the individual controller,
but a property of the overall cloud).



>
>
>> 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.
>
>

I wanted to split this bit into a different thread, because I do think
there are aspects we want to make work well and polished here, separately
from the "bootstrap" story.

John
=:->
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20160427/1659d58c/attachment.html>


More information about the Juju mailing list