Re: Problem with editing file on container

[Andrew Wilkins]

On Sun, Dec 10, 2017 at 3:00 AM Naas Si Ahmed 
wrote:

> Hi,
>
> I'm trying to modify a file using the command vi or nano to edit a file on
> a juju container, but I'm receiving an error such : terminal unknown.
>

In recent versions of Juju, "juju run" does not offer the ability to run
interactive commands.

Is there any way that I can use to edit a file graphically from another
> juju container ?
>

You can use "juju ssh" to SSH to the machine: "juju ssh 8 vi
/etc/conf.rules".

The juju command I used is :
> Juju run "vi /etc/conf.rules" --machine =8
>
> Thank you,
> Ahmed.
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.3.0 is here!

[Andrew Wilkins]

On Fri, Dec 8, 2017 at 6:59 AM Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> The Juju team are extremely pleased to announce the release of Juju 2.3.
> Juju is now more versatile, more efficient, and more configurable than ever.
>
> Cross Model Relations deliver a new way of organising your software stack.
> Deploy a database in one model and connect it to an application running
> another, even one running on a different controller, or even a different
> cloud.
>
> For containers at scale, Juju now integrates Canonical's Fan overlay
> network system. This allows containers to map network traffic to any other
> container on the fan network without distributed databases, consensus
> protocols, or any extra overhead.
>
> Juju's support for bundles has made it possible to quickly deploy
> connected sets of applications for some time now, but no two use cases are
> the same. That's why we have introduced the concept of an 'overlay' bundle
> - now you can easily add your own configuration and tweaks to a bundle at
> deploy time. See below for links to more information on this and other key
> features.
>

Hi folks,

Unfortunately a critical bug [0] has escaped to the field. This bug affects
existing relations in upgraded models. Models created after upgrading, or
with a fresh bootstrap, or where relations are created after upgrading,
will not be affected.

I would not recommend upgrading from 2.x. to 2.3.0. We will be working on a
fix for 2.3.1, and I expect this issue will bring that release forward much
sooner. If you have already upgraded and are affected, then you can fix it
by adding a document to the "statuses" collection in Mongo, as described in
the bug.

Cheers,
Andrew

[0] https://bugs.launchpad.net/juju/+bug/1737107


>
>
> ## How can I get it?
>
>
> The best way to get your hands on this release of Juju is to install it
> via snap packages (see https://snapcraft.io/for more info on snaps).
>
>
>snap install juju --classic
>
>
> Other packages are available for a variety of platforms. Please see the
> online documentation at https://jujucharms.com/docs/2.3/reference-install
>  . Those subscribed
> to a snap channel should be automatically upgraded. If you’re using the
> ppa/homebrew, you should see an upgrade available.
>
>
> For highlights of this release, please see the documentation at
>
> https://jujucharms.com/docs/2.3/whats-new. Further details are below.
>
>
>
> ## New
>
>
> * Cross Model Relations:
>
>  - see https://jujucharms.com/docs/2.3/models-cmr
>
>
> * Persistent Storage:
>
>  - see https://jujucharms.com/docs/2.3/charms-storage
>
>
> * FAN:
>
>  - see https://jujucharms.com/docs/2.3/charms-fan
>
>
> * Bundle deployments:
>
>  - Changed flags for deploying bundles to existing machines
>
>  - Bundle deploy flag --bundle-config replaced with --overlay
>
>  - Deploying bundles now supports --dry-run
>
>  - Deploying bundles can now target existing machines
>
>
> * Update Application Series:
>
>  - see https://jujucharms.com/docs/2.3/howto-updateseries
>
>
> * Parallelization of the Machine Provisioner:
>
> - Groups of machines will now be provisioned in parallel reducing
> deployment time, especially on large bundles.
>
>
> * open_port and close_port hook tools now support ICMP
>
> - The open_port and close_port hook tools now support opening firewall
> access for ICMP. The syntax is:
>
> open_port icmp
>
>
> * LXD Storage Provider:
>
>  - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)
>
>
> ## Fixes
>
>
> * Listing of Juju models is more efficient and can now handle more models
> gracefully
>
> * Leadership coordinations is no longer tied to local time which avoids
> problems with clock skew and reduces overall load on the database
>
> * Models are now more reliably destroyed and several fixes to avoid
> negative impacts while they are being removed
>
>
> You can check the milestones for a detailed breakdown of the Juju bugs we
> have fixed:
>
>
> https://launchpad.net/juju/+milestone/2.3.0
>
> https://launchpad.net/juju/+milestone/2.3-rc2
>
> https://launchpad.net/juju/+milestone/2.3-rc1
>
> https://launchpad.net/juju/+milestone/2.3-beta3
>
> https://launchpad.net/juju/+milestone/2.3-beta2
>
> https://launchpad.net/juju/+milestone/2.3-beta1
>
>
>
> ## Known issues
>
> The issues are targeted to be addressed in the upcoming 2.3.1 release.
>
>
> * Firewaller issues on vmware vsphere
> https://bugs.launchpad.net/juju/+bug/1732665
>
>
> * LXD broken on vmware
> https://bugs.launchpad.net/juju/+bug/1733882
>
>
> * Can't deploy bundle with map-machines=existing and subordinates
> https://bugs.launchpad.net/juju/+bug/1736592
>
>
> * load spike on controller following remove-application
> https://bugs.launchpad.net/juju/+bug/1733708
>
>
>
> ## Feedback Appreciated!
>
>
> We encourage everyone to let us know how you're using Juju.
>
>
> Join us at regular Juju shows - subscribe to our Youtube channel
> https://you

Re: Side effects of resizing a juju machine

[Andrew Wilkins]

On Thu, Nov 16, 2017 at 11:38 AM Akshat Jiwan Sharma 
wrote:

> Hi everyone,
>
> A couple of times I've noticed that the capacity of a machine provisioned
> by juju is much more than what I require for my workload. I was wondering
> that  if I were to manually resize the machine would it break any of juju
> services?
>

Juju won't care, you will just have some incorrect information in "juju
status". We record hardware characteristics for each machine, but it's used
only for describing machines to the user.

FWIW, I've just tested this:
 - juju bootstrap azure --bootstrap-constraints
instance-type=instance-type=Standard_DS12_v2
 - juju switch controller && juju deploy ubuntu --to 0
Then resized the machine to Standard_D4s_v3 via the Azure Portal. Juju came
back up fine, as did the unit.

Some charms might take a snapshot of hardware details when they're
installed, but I'm not aware of which if any would do that. But Juju itself
doesn't care.

Cheers,
Andrew


> Thanks,
> Akshat
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Disk ID for a provisioned instance

[Andrew Wilkins]

On Tue, Oct 31, 2017 at 1:40 PM Akshat Jiwan Sharma 
wrote:

> Thanks Andrew. I'm using google cloud platform. But also planning to use
> aws in the future.
>

For AWS, we tag the root disk EBS volume with:

   key=Name
   value=${INST_ID}-root

So if you add a machine in Juju and it gets assigned the instance ID
"inst-foo", then the root disk EBS volume will have a Name tag with the
value "inst-foo-root".

I don't know if we can guarantee that this will remain true forever, but it
hasn't changed in a long time.

HTH,
Andrew


> On Tue, Oct 31, 2017 at 8:23 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Tue, Oct 31, 2017 at 10:37 AM Akshat Jiwan Sharma <
>> akshatji...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I'd like to automate backups for my server provisioned via juju. For
>>> that I'm planning to use terraform. To take a snapshot of the disk,
>>> terraform needs a disk id.
>>>
>>> Is there a way I can get disk ID using juju commands? Juju show machine
>>> only gives the capacity of the disk not its id.
>>>
>>
>> Not at the moment. We'll need to extend the data model and update the
>> providers to support this. We do record information about volumes that Juju
>> provisions, but that excludes the root/OS disk.
>>
>> On a machine that I deployed on google cloud platform the disk id is same
>>> as the instance id. Can I assume that the disk id is same as the instance
>>> id everywhere?
>>>
>>
>> No, that's not a safe assumption in general. Which cloud providers are
>> you using?
>>
>> Thanks,
>>> Akshat
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Disk ID for a provisioned instance

[Andrew Wilkins]

On Tue, Oct 31, 2017 at 10:37 AM Akshat Jiwan Sharma 
wrote:

> Hi,
>
> I'd like to automate backups for my server provisioned via juju. For that
> I'm planning to use terraform. To take a snapshot of the disk, terraform
> needs a disk id.
>
> Is there a way I can get disk ID using juju commands? Juju show machine
> only gives the capacity of the disk not its id.
>

Not at the moment. We'll need to extend the data model and update the
providers to support this. We do record information about volumes that Juju
provisions, but that excludes the root/OS disk.

On a machine that I deployed on google cloud platform the disk id is same
> as the instance id. Can I assume that the disk id is same as the instance
> id everywhere?
>

No, that's not a safe assumption in general. Which cloud providers are you
using?

Thanks,
> Akshat
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: open-port: command not found

[Andrew Wilkins]

On Mon, Oct 23, 2017 at 5:12 PM Marco Ceppi 
wrote:

> On Mon, Oct 23, 2017, 03:59 Andrew Wilkins 
> wrote:
>
>> On Mon, Oct 23, 2017 at 4:20 AM Akshat Jiwan Sharma <
>> akshatji...@gmail.com> wrote:
>>
>>> HI,
>>>
>>> I'm trying to manually expose a port on a juju machine. According to this
>>> answer
>>> <https://askubuntu.com/questions/808176/how-to-manually-open-a-port-in-juju>
>>> I should be able to do something like this:-
>>>
>>>  juju run  "open-port 443" --all
>>>
>>> However when I type this in my shell it throws an error
>>>
>>> open-port: command not found
>>>
>>
>> The different between the command you're running, and the one on
>> AskUbuntu, is that you're not passing --unit. When you pass --unit, it runs
>> the command in the context of a unit on the machine. You must be running in
>> the context of a unit to use "hook tools", such as open-port.
>>
>
> It seems weird that `juju run` behaves differently when using --unit and
> --all, is there a particular reason for that? I wouldn't expect the above
> command to fail.
>

`juju run` supports running commands in either a machine or unit context.
Only if you run within a unit context do you get access to hook tools.
Hooks require a unit context.

"--all" means "all machines", so the command runs in a machine context, for
each machine. You could have multiple units on a machine, so we can't
automatically choose a unit. Even if we could, what would be the use case
for doing that? Different machines will run different applications, which
will each have their own firewall requirements.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: open-port: command not found

[Andrew Wilkins]

On Mon, Oct 23, 2017 at 11:09 AM Akshat Jiwan Sharma 
wrote:

> Thanks Andrew. Just one more question how does the open-port command
> behave with respect to the  firewalls with cloud providers. Specifically
> I'm asking in context of google cloud platform which by default only allows
> port 80 and 443(IIRC). So after running this command will I have to adjust
> firewall rules there as well?
>

That's exactly what open-port/expose is controlling :)

When you run open-port (or close-port), you're updating Juju's database to
say which ports should be open for the unit. When you run "juju expose", it
updates Juju's database to say that the "open" ports for the units of the
specified application should now be exposed. Juju will then update the
cloud firewall to come in line with what's in the Juju database.

Cheers,
Andrew


> Thanks,
> Akshat
>
> On Mon, Oct 23, 2017 at 7:28 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Mon, Oct 23, 2017 at 4:20 AM Akshat Jiwan Sharma <
>> akshatji...@gmail.com> wrote:
>>
>>> HI,
>>>
>>> I'm trying to manually expose a port on a juju machine. According to this
>>> answer
>>> <https://askubuntu.com/questions/808176/how-to-manually-open-a-port-in-juju>
>>> I should be able to do something like this:-
>>>
>>>  juju run  "open-port 443" --all
>>>
>>> However when I type this in my shell it throws an error
>>>
>>> open-port: command not found
>>>
>>
>> The different between the command you're running, and the one on
>> AskUbuntu, is that you're not passing --unit. When you pass --unit, it runs
>> the command in the context of a unit on the machine. You must be running in
>> the context of a unit to use "hook tools", such as open-port.
>>
>> I can verify that the application on this particular controller is
>>> already exposed and it thus satisfies the requirement for running this
>>> command.
>>>
>>> >"The port range will only be open while the application is exposed."
>>>
>>> Can you help me understand what I'm doing wrong?
>>>
>>
>> Ports are managed on a per-unit basis, so you need to execute the "run"
>> command against a unit or application, using --unit or --application
>> respectively.
>>
>> Once you've run open-port, you'll need to run "juju expose "
>> for the ports to actually be opened up.
>>
>> Thanks,
>>> Akshat
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: open-port: command not found

[Andrew Wilkins]

On Mon, Oct 23, 2017 at 4:20 AM Akshat Jiwan Sharma 
wrote:

> HI,
>
> I'm trying to manually expose a port on a juju machine. According to this
> answer
> 
> I should be able to do something like this:-
>
>  juju run  "open-port 443" --all
>
> However when I type this in my shell it throws an error
>
> open-port: command not found
>

The different between the command you're running, and the one on AskUbuntu,
is that you're not passing --unit. When you pass --unit, it runs the
command in the context of a unit on the machine. You must be running in the
context of a unit to use "hook tools", such as open-port.

I can verify that the application on this particular controller is already
> exposed and it thus satisfies the requirement for running this command.
>
> >"The port range will only be open while the application is exposed."
>
> Can you help me understand what I'm doing wrong?
>

Ports are managed on a per-unit basis, so you need to execute the "run"
command against a unit or application, using --unit or --application
respectively.

Once you've run open-port, you'll need to run "juju expose "
for the ports to actually be opened up.

Thanks,
> Akshat
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: vsphere support

[Andrew Wilkins]

On Wed, Oct 4, 2017 at 12:09 PM Serge E. Hallyn  wrote:

> Hi,
>
> I've inherited a few vsphere machines where I was hoping to use juju
> to fire off openstack etc.  I've been trying to use the vsphere
> provider (which I was excited to see existed), but am seeing a few
> inconsistencies, so had a few questions.
>
> The first blunt question - is this going to be a maintained driver,
> or am I in 6 months likely to find the vsphere driver dropped?
>

We are actively working on making the vsphere provider to be a great
experience in the Juju 2.3 release. There's some more work to be done for
mirroring VMDKs from cloud-images, but otherwise I think everything's
working well now.

I don't have any reason to believe that we would drop the provider, or to
reduce focus on quality. People seem to want it :)

The second is motivating the first - when I looked at
> https://jujucharms.com/docs/2.1/help-vmware it says hardware version
> 8 (ESX 5.0) should be sufficient.  But in fact juju has a ubuntu.ovf
> hardcoded in it that specifies 'vmx-10', which is ESX 5.5..  I currently
> have 5 ESX 5.1 machines and one 6.0.
>

To my knowledge, Juju has only been tested with ESXi 5.5 and 6.0. In terms
of hardware support, version 8 seems like it should be sufficient. I'm not
sure about the APIs we're using, but we don't use a lot, so it wouldn't
surprise me if ESXi 5.1 just works.

If you're able to tweak the OVF and build Juju from source, that would be a
great help. Otherwise I will check what we require in terms of APIs when I
return from vacation next week - and try it out and report back. If it
works, then we can look to update the OVF for Juju 2.3.

Even with a custom DC using only the 6.0 host, I have some (probably
> proxy) issues bootstrapping, which I'm sure are surmountable - but the
> answer to Q1 will decide whether it's worth pursuing that further, or
> whether I should spend my time elsewhere :)
>

Please file a bug if you're still having issues. Juju 2.3 beta 1 is
imminent, so please use that if you can.

Cheers,
Andrew

thanks,
> -serge
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju hangs during bootstrapping

[Andrew Wilkins]

On Fri, Sep 29, 2017 at 11:55 PM  wrote:

>
>
>
>
> *From:* Andrew Wilkins [mailto:andrew.wilk...@canonical.com]
> *Sent:* Saturday, September 30, 2017 12:23 AM
> *To:* Chen2, Dave ; juju@lists.ubuntu.com
> *Subject:* Re: juju hangs during bootstrapping
>
>
>
> On Fri, Sep 29, 2017 at 10:43 AM  wrote:
>
> Hi All,
>
>
>
> I am trying to bootstrap a MAAS cloud based on juju’s official guide (
> https://jujucharms.com/docs/2.2/clouds-maas), everything seems correct
> but after the Operation System (Ubuntu 16.04 or Ubuntu14.0) has been
> installed, juju hangs when attempting to connect to the MAAS node, here is
> what I can see from the terminal,
>
>
>
> $ juju bootstrap maas-cloud
>
> Creating Juju controller "maas-cloud" on maas-cloud
>
> Looking for packaged Juju agent version 2.2.4 for amd64
>
> Launching controller instance(s) on maas-cloud...
>
> - cka68p (arch=amd64 mem=32G cores=12)
>
> Fetching Juju GUI 2.9.2
>
> Waiting for address
>
> Attempting to connect to 10.20.3.254:22 (JUJU hangs here!)
>
>
>
> And it’s pending here forever, so I tried it again with the debug mode,
>
> $ juju bootstrap --show-log --debug --bootstrap-series=trusty maas-cloud
> maas-cloud-controller
>
>
>
> I saw some detail information like below,
>
> Attempting to connect to 10.20.3.254:22
>
> 19:33:11 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:16 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:21 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:56 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:34:32 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:35:08 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:35:43 INFO  juju.cloudconfig userdatacfg_unix.go:410 Fetching agent:
> curl -sSfw 'tools from %{url_effective} downloaded: HTTP %{http_code}; time
> %{time_total}s; size %{size_download} bytes; speed %{speed_download}
> bytes/s ' --retry 10 -o $bin/tools.tar.gz <[
> https://streams.canonical.com/juju/tools/agent/2.2.4/juju-2.2.4-ubuntu-amd64.tgz]>
>
>
>
> Is this the last thing logged? Try running that curl command on the
> machine manually. Perhaps there's an issue getting out to the internet.
>
> *[Dave] Yes, this is the last line I saw, our network topology is MAAS
> server can access internet (dual NIC with one NIC can access outer
> network), but each node that is deployed by MAAS/JUJU only get the IP from
> internal DHCP service, do you mean each deployed node also need access
> outer internet?*
>

The bootstrap machine requires access to the Juju agent repository, which
is on  "streams.canonical.com". It's possible to point Juju at a private
mirror to avoid the need to go to the internet.

*And… Do you have any idea about the  ssh connection refused error?*
>

That's just log spam, we should clean that up. Juju requests the MAAS
server, and then immediately starts attempting to connect via SSH. When the
server is still starting, we expect to see connection refused errors.


>
> I have no idea what’s going wrong since I can telnet to the node and ssh
> to that node is also possible, I just need type “yes” then I can login to
> the node,
>
> $ ssh ubuntu@10.20.3.254
>
> The authenticity of host ' 10.20.3.254 (10.20.3.254)' can't be established.
>
> ECDSA key fingerprint is
> SHA256:4FVm21s4dx7gc0/yDgz0+QAMGK4qWODoIqeoWtZg9RI.
>
> Are you sure you want to continue connecting (yes/no)?
>
>
>
> From the console of that node, I can find the controller’s public key has
> been injected to the node,
>
> -BEGIN SSH HOST KEY KEYS---
>
> …
>
> -END SSH KEY FINGERPRINTS
>
> …
>
> Cloud-init v. 0.7.9 finished at … Datasource DataSourceMAAS 
> [http://...:5240/MAAS/metadata/].
> Up 153.77 seconds.   (cloud-init hangs here!)
>
>
>
>
>
> I googled it and found someone said it is because “authorized-keys-path”
> is commented out in the “environments.yaml” [1], but the juju version I am
> using is “2.2.4-xenial-amd64”, the MAAS version is 2.2.2,
>
> Initially, I ins

Re: juju hangs during bootstrapping

[Andrew Wilkins]

On Sat, Sep 30, 2017 at 5:55 AM  wrote:

> Hi Narinder,
>
>
>
> Here is the log from the deployed node, actually, I can deploy Operation
> System successfully with MAAS or “juju bootstrap” but failed at some final
> steps, Our external network is exactly broken for some reason yesterday and
> won’t be recovered in short term, but I guess the network broken is
>  happened after I saw the below error message during bootstrapping.
>
> “Waiting for address
>
> Attempting to connect to 10.20.3.254:22”
>
>
>
> I can see apt-get update works from the log at the beginning, and the
> network is broken couple of hours after I saw those error message.
>
>
>
> Does the error message like below has any connection with connection
> refused error message? I am not quite sure.
>

No, they're not connected, but the failing curl command is what is
preventing bootstrap from proceeding. That's the server trying to download
the Juju agent.


>
>
> “0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>
> Fetching Juju agent version 2.2.4 for amd64
>
> Attempt 1 to download tools from
> https://streams.canonical.com/juju/tools/agent/2.2.4/juju-2.2.4-ubuntu-amd64.tgz.
> ..
>
> curl: (6) Could not resolve host: streams.canonical.com
>
> “
>
>
>
> Anyway, I will try it again when our network back to normal, it would be
> great if you can see any other issue beside the network, thanks again for
> your help!
>
>
>
> Best Regards,
>
> Dave Chen
>
>
>
> *From:* Narinder Gupta [mailto:narinder.gu...@canonical.com]
> *Sent:* Friday, September 29, 2017 10:52 PM
> *To:* Chen2, Dave 
> *Cc:* juju 
> *Subject:* Re: juju hangs during bootstrapping
>
>
>
> Hi Dave,
>
> May I know which division of Dell you are working on? As i have setup
> Openstack deployed t Dell multiple time with MAAS and have not seen this
> issue so far.
>
>
>
> So please send me log /var/log/cloud-init-output.log which will let us
> know what is wrong. Also try sudo apt-get update on the bootstrap node to
> confirm you have external access.
>
>
>
> In MAAS you can always add the ssh keys to land into the installed nodes
> though.
>
>
>
>
> Thanks and Regards,
>
> Narinder Gupta (PMP)   narinder.gu...@canonical.com
>
> Canonical, Ltd.narindergupta [irc.freenode.net]
>
> +1.281.736.5150 <(281)%20736-5150>
> narindergupta2007[skype]
>
>
>
> Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com
>
>
>
> On Fri, Sep 29, 2017 at 9:42 AM,  wrote:
>
> Hi All,
>
>
>
> I am trying to bootstrap a MAAS cloud based on juju’s official guide (
> https://jujucharms.com/docs/2.2/clouds-maas), everything seems correct
> but after the Operation System (Ubuntu 16.04 or Ubuntu14.0) has been
> installed, juju hangs when attempting to connect to the MAAS node, here is
> what I can see from the terminal,
>
>
>
> $ juju bootstrap maas-cloud
>
> Creating Juju controller "maas-cloud" on maas-cloud
>
> Looking for packaged Juju agent version 2.2.4 for amd64
>
> Launching controller instance(s) on maas-cloud...
>
> - cka68p (arch=amd64 mem=32G cores=12)
>
> Fetching Juju GUI 2.9.2
>
> Waiting for address
>
> Attempting to connect to 10.20.3.254:22 (JUJU hangs here!)
>
>
>
> And it’s pending here forever, so I tried it again with the debug mode,
>
> $ juju bootstrap --show-log --debug --bootstrap-series=trusty maas-cloud
> maas-cloud-controller
>
>
>
> I saw some detail information like below,
>
> Attempting to connect to 10.20.3.254:22
>
> 19:33:11 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:16 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:21 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:56 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:34:32 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:35:08 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:35:43 INFO  juju.cloudconfig userdatacfg_unix.go:410 Fetching agent:
> curl -sSfw 'tools from %{url_effective} downloaded: HTTP %{http_code}; time
> %{time_total}s; size %{size_download} bytes; speed %{speed_download}
> bytes/s ' --retry 10 -o $bin/tools.tar.gz <[
> https://streams.canonical.com/juju/tools/agent/2.2.4/juju-2.2.4-ubuntu-amd64.tgz]>
>
>
>
> I have no idea what’s going wrong since I can telnet to the node and ssh
> to that node is also possible, I just need type “yes” then I can login to
> the node,
>
> $ ssh ubuntu@10.20.3.254
>
> The authenticity of host ' 1

Re: juju hangs during bootstrapping

[Andrew Wilkins]

On Fri, Sep 29, 2017 at 10:43 AM  wrote:

> Hi All,
>
>
>
> I am trying to bootstrap a MAAS cloud based on juju’s official guide (
> https://jujucharms.com/docs/2.2/clouds-maas), everything seems correct
> but after the Operation System (Ubuntu 16.04 or Ubuntu14.0) has been
> installed, juju hangs when attempting to connect to the MAAS node, here is
> what I can see from the terminal,
>
>
>
> $ juju bootstrap maas-cloud
>
> Creating Juju controller "maas-cloud" on maas-cloud
>
> Looking for packaged Juju agent version 2.2.4 for amd64
>
> Launching controller instance(s) on maas-cloud...
>
> - cka68p (arch=amd64 mem=32G cores=12)
>
> Fetching Juju GUI 2.9.2
>
> Waiting for address
>
> Attempting to connect to 10.20.3.254:22 (JUJU hangs here!)
>
>
>
> And it’s pending here forever, so I tried it again with the debug mode,
>
> $ juju bootstrap --show-log --debug --bootstrap-series=trusty maas-cloud
> maas-cloud-controller
>
>
>
> I saw some detail information like below,
>
> Attempting to connect to 10.20.3.254:22
>
> 19:33:11 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:16 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:21 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: ssh: connect to host 10.20.3.254 port 22:
> Connection refused
>
> 19:33:56 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:34:32 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:35:08 DEBUG juju.provider.common bootstrap.go:497 connection attempt
> for 10.20.3.254 failed: /var/lib/juju/nonce.txt does not exist
>
> 19:35:43 INFO  juju.cloudconfig userdatacfg_unix.go:410 Fetching agent:
> curl -sSfw 'tools from %{url_effective} downloaded: HTTP %{http_code}; time
> %{time_total}s; size %{size_download} bytes; speed %{speed_download}
> bytes/s ' --retry 10 -o $bin/tools.tar.gz <[
> https://streams.canonical.com/juju/tools/agent/2.2.4/juju-2.2.4-ubuntu-amd64.tgz]>
>

Is this the last thing logged? Try running that curl command on the machine
manually. Perhaps there's an issue getting out to the internet.


>
> I have no idea what’s going wrong since I can telnet to the node and ssh
> to that node is also possible, I just need type “yes” then I can login to
> the node,
>
> $ ssh ubuntu@10.20.3.254
>
> The authenticity of host ' 10.20.3.254 (10.20.3.254)' can't be established.
>
> ECDSA key fingerprint is
> SHA256:4FVm21s4dx7gc0/yDgz0+QAMGK4qWODoIqeoWtZg9RI.
>
> Are you sure you want to continue connecting (yes/no)?
>
>
>
> From the console of that node, I can find the controller’s public key has
> been injected to the node,
>
> -BEGIN SSH HOST KEY KEYS---
>
> …
>
> -END SSH KEY FINGERPRINTS
>
> …
>
> Cloud-init v. 0.7.9 finished at … Datasource DataSourceMAAS 
> [http://...:5240/MAAS/metadata/].
> Up 153.77 seconds.   (cloud-init hangs here!)
>
>
>
>
>
> I googled it and found someone said it is because “authorized-keys-path”
> is commented out in the “environments.yaml” [1], but the juju version I am
> using is “2.2.4-xenial-amd64”, the MAAS version is 2.2.2,
>
> Initially, I installed juju 1.25 and configured environments.yaml, but now
> I have uninstalled juju 1.25, removed all those file in $home/.juju/ and
> start it over again with juju 2.2.4.
>
> I really cannot figure out why it always hangs at this step, is there any
> cache persisted anywhere that masked the  “authorized-keys-path” even after
> the uninstallation of juju1.25? or there is any step I missed with juju
> 2.2.4?
>
>
>
> Where is user-data of cloud-init persisted on the filesystem? Any more
> detail logs I can refer to?
>
>
>
>
>
> I feel frustration after trying several days without any progress, pls
> help me out, many many thanks for any inputs!
>
>
>
>
>
> [1]
> https://serverfault.com/questions/588967/juju-bootstrap-fails-connection-refused-port-22
>
>
>
>
>
> Best Regards,
>
> Dave Chen
>
>
>
> Best Regards,
>
> Dave Chen
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Kubernetes with Juju

[Andrew Wilkins]

On Wed, Aug 16, 2017 at 3:50 AM Micheal B  wrote:

> How can I use local images when doing juju bootstrap vsphere/myregions
> --bootstrap-constraints "cores=2 mem=4G root-disk=32G"  rather than the
> downloading of the ova? Same thing for the images used in bundles ..
>

For now, I think the only thing you can do is to create a local mirror of
the relevant parts of http://cloud-images.ubuntu.com/. You can use the
"simplestreams" utility to make this easier, e.g.:

$ sudo apt install simplestreams
$ sudo apt install ubuntu-cloudimage-keyring
$ sstream-mirror
--keyring=/usr/share/keyrings/ubuntu-cloudimage-keyring.gpg --max=1
--progress http://cloud-images.ubuntu.com/releases path/to/mirror
'arch=amd64' 'release~xenial' 'ftype=ova'

Once you've downloaded the image(s) and metadata, you'll need to serve it
over HTTP, and point Juju at it with the "image-metadata-url" config.

We really should be caching the images, making this all seamless. I've just
filed a bug, to make things better:
https://bugs.launchpad.net/juju/+bug/1711019.

Cheers,
Andrew


>
>
> Trying to cut down on the downloading times ..
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: HELP! Can I run Juju on localhost?

[Andrew Wilkins]

On Mon, Jul 31, 2017 at 11:32 AM 葛光乐  wrote:

> Hi, guys,
>

Hi leoge,

I had downloaded Juju、Juju-gui、GuiProxy, and read the docs. But I can run
> them on localhost looks like jujucharms.com.
>

Sorry, I don't quite understand. Do you mean you *can't* get it to run?

I want to figure out how it work, then debug it and study the code.
>
> What can I  do  to achieve it.
>

Which operating system are you using? If you're on Ubuntu, then you can use
the LXD provider to run things locally. See the instructions here:
https://jujucharms.com/docs/stable/tut-lxd.

Cheers,
Andrew


> Thank you very much!
>
> Best,
> leoge
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Coming in 2.3: storage improvements

[Andrew Wilkins]

Hi folks,

I've just published https://awilkins.id.au/post/juju-2.3-storage/, which
highlights some of the new bits added around storage that's coming to Juju
2.3. I particularly wanted to highlight that a new LXD storage provider has
just landed on develop today. It should be available in the edge snap soon.

The LXD storage provider will enable you to attach LXD storage volumes to
your containers, and use that for a charm's storage requirements. e.g.

$ juju deploy postgresql --storage pgdata=1G,lxd-zfs

This will create a LXD storage pool backed by a ZFS pool, create a 1GiB ZFS
volume and attach that to the container.

I'd appreciate feedback on the new provider, and the attach/detach changes
described in the blog post, preferably before 2.3 comes around. In
particular, UX warts or functionality that you're missing or anything you
find broken-by-design -- stuff that can't easily be fixed after we release.

Thanks!

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Is it possible to return management to Juju after manual provision of a machine?

[Andrew Wilkins]

On Fri, Jun 30, 2017 at 7:39 AM N. S.  wrote:

> Hi,
>
> Excuse me if this seems a strange scenario.
>
> My scenario is as follows:
>
> I have a charm that has lots of problems in its install script, needs
> massive change (NOT SURE how to fix it)
>
> So,
>
> I added an empty machine by
> Juju add-machine --series Xenial
>
> And then I logged into it by
> Juju SSH 9
> And
> I provisioned it (installed some software on it).
>
>
> Now,
> Is it possible to get it back to Juju among the units and the applications?
> How?
>

You can "juju deploy  --to 9" to deploy the application unit to the
"empty" machine. It'll be up to your charm to know how to deal with the
existing software.

Other hooks are probably fine, how to integrate them in the machine?
>

Hooks are expected to be idempotent, because they may run more than once
(Juju guarantees at-least-once). So the install hook should be written in a
way that it won't fail if the software is already failed.


> Thanks,
> BR
> NAZ
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Running KVM in addition to LXC on local LXD CLOUD

[Andrew Wilkins]

On Sat, Jun 24, 2017 at 9:14 PM N. S.  wrote:

> Hi,
>
>
> I am running 10 machines on local LXD cloud, and it's fine.
>
> My host is Ubuntu 16.04, kernel 4.4.0-81.
>
> However, I have the following challenge:
> One of the machines (M0) stipulates a kernel 4.7+
>
>
> As it's known, unlike KVM, LXC makes use of same kernel of the host system
> and in this case (4.4.0-81) breaching thus the stipulation of M0 (4.7+).
>
>
> I have read that starting Juju 2.0, KVM is no more supported.
>

Juju still supports kvm, but the old "local" provider which supported
lxc/kvm is gone.

You could run a kvm container from within a lxd machine with the right
apparmor settings. Probably the most straight forward thing to do, though,
would be to create a KVM VM yourself, install Ubuntu on it, and then
manually provision it using "juju add-machine ssh:".


> How could I prepare the stipulation of M0?
>
> Thanks for your help
> BR,
> Nazih
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju deploy with a series

[Andrew Wilkins]

On Fri, Jun 16, 2017 at 1:36 AM John Meinel  wrote:

> "juju show-machine 10" is likely to tell you why we are failing to
> provision the machine.
>
> My guess is that we acctually need the alias to be "juju/centos7/amd64"
> for Juju to recognize that it is the container image we want to be starting.
>

Also, the centos7 image from linuxcontainers.org is not suitable for Juju
to use. See https://bugs.launchpad.net/juju/+bug/1495978/comments/21.

(We really need to publish the image, so people don't have to do this.)


> John
> =:->
>
>
> On Thu, Jun 15, 2017 at 8:37 PM, Daniel Bidwell 
> wrote:
>
>> I am trying to deploy a charm that I am writing for both ubuntu and
>> centos.  "lxc image alias list" produces:
>>
>> lxc image alias list
>> +---+--+---+
>> |   ALIAS   | FINGERPRINT  |DESCRIPTION|
>> +---+--+---+
>> | centos7   | 41c7bb494bbd | centos7   |
>> +---+--+---+
>> | juju/xenial/amd64 | 1e59027d1d58 | juju/xenial/amd64 |
>> +---+--+---+
>> | ubuntu-xenial | 1e59027d1d58 | ubuntu-xenial |
>> +---+--+---+
>>
>> "juju deploy ~/charms/xenial/aubase1 --series centos7 aubasecentos"
>> looks like it is starting, but a "juju status" produces:
>>
>> juju status
>> ModelController  Cloud/Region Version
>> default  lxd-testlocalhost/localhost  2.1.2
>>
>> App   Version  Status   Scale  CharmStore  Rev  OS  Notes
>> aubase1active   1  aubase1  local5  ubuntu
>> aubasecentos   waiting0/1  aubase1  local4  centos
>>
>> UnitWorkload  Agent   Machine  Public
>> address  Ports  Message
>> aubase1/4*  activeidle910.130.54.192
>> aubasecentos/4  waiting   allocating  10  waiting
>> for machine
>>
>> Machine  StateDNSInst idSeries   AZ
>> 9started  10.130.54.192  juju-a0c4c9-9  xenial
>> 10   downpendingcentos7
>>
>> What do I need to do to deploy a centos lxd container with my charm?
>> --
>> Daniel Bidwell 
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: OS X VMS on JAAS

[Andrew Wilkins]

On Sat, Jun 3, 2017 at 2:56 PM John Meinel  wrote:

> You can add a manually provisioned machine to any model, as long as there
> is connectivity from the machine to the controller. Now, I would have
> thought initial setup was initiated by the Controller, but its possible
> that initial setup is actually initiated from the client.
>

Given the command:

$ juju add-machine ssh:

it goes something like this:

1. client connects to  via SSH, and performs basic hardware/OS
discovery
2. client asks controller to add a machine entry, and controller returns a
script to be executed on the target machine, using the discovered details,
in order to fetch and install jujud
3. client executes that script over the SSH connection

Once initial setup is complete, then it is definitely true that all
> connections are initiated from the agent running on the controlled machine
> to the controller. The controller no longer tries to socket.connect to the
> machine. (In 1.X 'actions' were initiated via ssh from the controller, but
> in 2.X the agents listen to see if there are any actions to run like they
> do for all other changes.)
>
> Now, given that he added a model into "us-east-1" if he ever did just a
> plain "juju add-machine" or "juju deploy" (without --to) it would
> definitely create a new instance in AWS and start configuring it, rather
> than from your VM.
>
> Which is why using something like the "lxd provider" would be a more
> natural use case, but according to James the sticking point is having to
> set up a controller in the first place. So "--to lxd:0" is easier for them
> to think about than setting up a provider and letting it decide how to
> allocate machines.
>
> Note, it probably wouldn't be possible to use JAAS to drive an LXD
> provider, because *that* would have JAAS be trying to make a direct
> connection to your LXD agent in order to provision the next machine.
> However "--to lxd:0" has the local juju agent (running for 'machine 0')
> talking to the local LXD agent in order to create a container.
>
> John
> =:->
>
>
> On Fri, Jun 2, 2017 at 6:28 PM, Jay Wren  wrote:
>
>> I do not understand how this works. Could someone with knowledge of how
>> jujud on a  controller communicates with jujud agents on units describe how
>> that is done?
>>
>> My limited understanding must be wrong give that James has this working.
>>
>> This is what I thought:
>>
>> On most cloud providers: add-machine instructs the cloud provider to
>> start a new instance and the cloud-config passed to cloud-init includes how
>> to download jujud agent and run it and configure it with public key trust
>> of the juju controller.
>>
>> On manually added machine: same thing only instead of cloud-init and
>> cloud-config an ssh connection is used to perform the same commands.
>>
>> I had thought the juju controller was initiating the ssh-connection to
>> the address given in the add-machine command and that a non-internet
>> routable address would simply not work as the controller cannot open any
>> TCP connection to it. This is where my understanding stops.
>>
>> Please, anyone, describe how this works?
>> --
>> Jay
>>
>>
>> On Fri, Jun 2, 2017 at 9:42 AM, James Beedy  wrote:
>>
>>> I think the primary advantage being less clutter to the end user. The
>>> difference between the end user have to bootstrap and control things from
>>> inside the vm vs from their host. For some reason this small change made
>>> some of my users who were previously not really catching on, far more apt
>>> to jump in. I personally like it because these little vms go further when
>>> they don't have the controller on them as well. @jameinel totally, possibly
>>> I'll add the bridge bits in place of the lxd-proxy in that write up, or
>>> possibly in another.
>>>
>>> ~James
>>>
>>> On Jun 2, 2017, at 12:56 AM, John Meinel  wrote:
>>>
>>> Interesting. I wouldn't have thought to use a manually added machine to
>>> use JAAS to deploy applications to your local virtualbox. Is there a reason
>>> this is easier than just "juju bootstrap lxd" from inside the VM?
>>>
>>> I suppose our default lxd provider puts the new containers on a NAT
>>> bridge, though you can reconfigure 'lxdbr0' to bridge your 'eth0' as well.
>>>
>>> John
>>> =:->
>>>
>>>
>>> On Fri, Jun 2, 2017 at 8:33 AM, James Beedy 
>>> wrote:
>>>

 https://medium.com/@jamesbeedy/using-jaas-to-deploy-lxd-containers-to-virtualbox-vms-on-os-x-a06a8046756a

 --
 Juju-dev mailing list
 juju-...@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju-dev


>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or un

Re: Call for testers: preview of persistent storage support

[Andrew Wilkins]

On Fri, May 26, 2017 at 11:26 AM Patrizio Bassi 
wrote:

> Dear Andrew,
>  what about private clouds such as maas?
>

MAAS is a bit special, because the disks are physically attached to the
machines. If and when we support something like Ceph RBD natively inside
Juju, then that could be detached from one machine and attached to another.

The new storage commands should work with private OpenStack clouds.

Cheers,
Andrew


> Patrizio
>
> Il giorno mer 24 ma 2017 alle 03:38 Andrew Wilkins <
> andrew.wilk...@canonical.com> ha scritto:
>
>> Hi folks,
>>
>> One of the things we're working on for the 2.3 release (not 2.2!) is
>> persistent storage. What this means is the ability to detach storage from a
>> unit, and reattach it to another unit keeping the storage contents intact.
>> We would like to get some feedback before this all gets set in stone.
>>
>> With the changes, removing an application unit will detach storage rather
>> than destroy it as Juju currently does. The storage will then be available
>> for attaching to another unit using "juju attach-storage  "
>> or to a new application unit using "juju deploy  --attach-storage
>> "; or for removal using "juju remove-storage ".
>>
>> For example, I can deploy postgresql on AWS with EBS storage. If I remove
>> the postgresql application, I can add another and attach the storage to it:
>>
>> $ juju deploy postgresql --storage pgdata=100G,ebs
>> Located charm "cs:postgresql-148".
>> Deploying charm "cs:postgresql-148".
>> (wait for postgresql/0 to become active)
>>
>> $ juju remove-application postgresql
>> removing application postgresql
>> - will detach storage pgdata/0
>> (wait for postgresql/0 and machine 0 to be removed)
>>
>> $ juju deploy postgresql postgresql2 --attach-storage pgdata/0 --to
>> zone=
>> Located charm "cs:postgresql-148".
>> Deploying charm "cs:postgresql-148".
>> (wait for postgresql2/0 to become active)
>>
>> If you like, you can confirm for yourself that the data is persisted by
>> logging into the first machine and runing "sudo -u postgres psql", creating
>> some data, and then checking that it is still there from the second machine.
>>
>> (The --to zone=... is required due to a limitation that we will remove by
>> the time 2.3 is released. EBS volumes and EC2 instances must be created in
>> the same AZ, and that's not automatic yet. This is fixed by
>> https://github.com/juju/juju/pull/7378 which, at the time of writing
>> this email, has not yet been merged.)
>>
>> If you have any interest in these changes, please help us make them great
>> by testing out this early release:
>>
>> $ sudo snap install --channel=edge --classic juju-axw
>> $ /snap/bin/juju-axw.juju bootstrap ...
>>
>> The new/updated commands are:
>>  - juju attach-storage  
>>  - juju detach-storage 
>>  - juju remove-storage 
>>  - juju deploy  --attach-storage 
>>
>> (We'll also be adding --attach-storage to the "juju add-unit" command
>> soon.)
>>
>> Thank you!
>>
>> Cheers,
>> Andrew
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
>
> Patrizio Bassi
> www.patriziobassi.it
> http://piazzadelpopolo.patriziobassi.it
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Call for testers: preview of persistent storage support

[Andrew Wilkins]

Hi folks,

One of the things we're working on for the 2.3 release (not 2.2!) is
persistent storage. What this means is the ability to detach storage from a
unit, and reattach it to another unit keeping the storage contents intact.
We would like to get some feedback before this all gets set in stone.

With the changes, removing an application unit will detach storage rather
than destroy it as Juju currently does. The storage will then be available
for attaching to another unit using "juju attach-storage  "
or to a new application unit using "juju deploy  --attach-storage
"; or for removal using "juju remove-storage ".

For example, I can deploy postgresql on AWS with EBS storage. If I remove
the postgresql application, I can add another and attach the storage to it:

$ juju deploy postgresql --storage pgdata=100G,ebs
Located charm "cs:postgresql-148".
Deploying charm "cs:postgresql-148".
(wait for postgresql/0 to become active)

$ juju remove-application postgresql
removing application postgresql
- will detach storage pgdata/0
(wait for postgresql/0 and machine 0 to be removed)

$ juju deploy postgresql postgresql2 --attach-storage pgdata/0 --to
zone=
Located charm "cs:postgresql-148".
Deploying charm "cs:postgresql-148".
(wait for postgresql2/0 to become active)

If you like, you can confirm for yourself that the data is persisted by
logging into the first machine and runing "sudo -u postgres psql", creating
some data, and then checking that it is still there from the second machine.

(The --to zone=... is required due to a limitation that we will remove by
the time 2.3 is released. EBS volumes and EC2 instances must be created in
the same AZ, and that's not automatic yet. This is fixed by
https://github.com/juju/juju/pull/7378 which, at the time of writing this
email, has not yet been merged.)

If you have any interest in these changes, please help us make them great
by testing out this early release:

$ sudo snap install --channel=edge --classic juju-axw
$ /snap/bin/juju-axw.juju bootstrap ...

The new/updated commands are:
 - juju attach-storage  
 - juju detach-storage 
 - juju remove-storage 
 - juju deploy  --attach-storage 

(We'll also be adding --attach-storage to the "juju add-unit" command soon.)

Thank you!

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to build juju for centOS

[Andrew Wilkins]

On Thu, May 11, 2017 at 10:27 PM fengxia  wrote:

> Andrew,
>
> I tried stock Juju on Ubuntu 16.04, but having the same error:
>
> ERROR cannot obtain provisioning script
> ERROR getting instance config: finding tools: no matching tools available
> (not found)
>
> Here are the steps:
>
> 1. juju bootstrap lxd lxd-test
>
> 2. juju add-machine ssh:username@ip --series centos7
>
> I have also tried setting default-series when bootstrap, same error.
>
> I checked streams.canonical.com, there is centos agent listed under
> /tools. I also manually tried setting version to 2.0.1, for example, and
> got the same error.
>
Hi Feng,

Sorry for the late response.

You may be hitting https://bugs.launchpad.net/juju/+bug/1495978. There are
several fixes for CentOS related to LXD that were released in Juju 2.1.
Please try updating to a newer version.

FWIW, I've just successfully started a centos7 series machine on AWS using
Juju 2.2-beta4, but earlier versions should work there as well.

Cheers,
Andrew

> Best,
>
> Feng
> On 05/10/2017 03:44 AM, Andrew Wilkins wrote:
>
> On Wed, May 10, 2017 at 3:08 PM fengxia  wrote:
>
>> I have followed dev instruction and can build Juju binaries for Ubuntu.
>> The dev machine is also Ubuntu.
>>
>> $ go install -v github.com/juju/juju/…
>>
>> Using the same binaries will not however bootstrap with "--config
>> default-series=centos", nor "add-machine --series centos". Both failed at
>> "no tools founds".
>>
>> How to build an agent for centos?
>>
> For a start, you should use "centos7", not "centos". "juju add-machine
> --series=centos" *should* give you an immediate error indicating that
> that's not a valid series, and ideally inform you of the closest match(es);
> I'll file a bug to get that fixed.
>
> Do you need to build from source? If you're using a released version of
> Juju, then the agents are available on streams.canonical.com.
>
> For dev builds, we don't have a nice, supported solution. The supported
> solution is to create agent tarballs and generate simplestreams metadata. I
> wrote a plugin a while ago that you can use to build and upload agent
> tarballs to the controller directly, but you shouldn't use it in production
> systems:
>
> $ go get github.com/axw/juju-tools
> $ juju tools build 2.2-beta4.1-centos7-amd64
> building: juju-2.2-beta4.1-centos7-amd64.tgz
> $ juju tools upload -m controller juju-2.2-beta4.1-centos7-amd64.tgz
> uploading "juju-2.2-beta4.1-centos7-amd64.tgz"
> $ juju add-machine --series=centos7
>
> Cheers,
> Andrew
>
>> --
>> Feng xia
>> Engineer
>> Lenovo USA
>>
>> Phone: 5088011794 <%28508%29%20801-1794>fx...@lenovo.com
>>  
>> Lenovo.com
>> Twitter | Facebook | Instagram | Blogs | Forums
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>fx...@lenovo.com
>   
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: matchmaking a jupyter community, and a reminder to share your work

[Andrew Wilkins]

On Tue, May 16, 2017 at 9:46 PM Rick Harding 
wrote:

> Last week for the Juju Show [1] I played with Jupyter Notebook which is a
> great way to put together online instructional for code. It was fun to get
> going and I was motivated by a charm from a new author [2] I had seen in
> the new published api [3].
>
> What was interesting was five minutes after the show Merlijn pointed out
> that he had a charm[4] for it that he'd never pushed to the store. Then
> after that Andrew from the Juju team mentioned he was playing with it and
> had some layers and code [5][6][7][8][9] sitting around for Jupyter.
>

(Thanks Rick)

Hi folks,

I'm not actively working on these layers/interfaces at the moment, but if
anyone wants to pick them up and move them to an org then that's fine by
me. I'd then contribute later if/when I have the time.


> Clearly, this is awesome that there's so much interest around a great
> piece of software. The bigger opportunity is that folks can now start
> collaborating and really taking advantage of the shared brain powers of
> everyone out there.
>
> So I get to play matchmaker. Guiseppe, Merlijn, Andrew, and everyone else
> out there interested in Jupyter I suggest you get together. I'm excited to
> see what the combined power can bring to a great Jupyter experience.
>
> If you've got a charm you've been sitting on and not yet pushed to the
> charm store I really suggest you do it now. You never know what community
> is waiting to pool around chunk of work. They just need that central point
> to kick it all off.
>

On that note: yesterday I started work on an interface and layer for GitLab
Runner. It doesn't do anything except for install gitlab-runner yet, but my
intention is to modify layer-gitlab with a relation that will extract the
registration token from the DB and send it across. Then the runner can
automatically register itself. If anyone else is working on this/similar,
please let me know.

Cheers,
Andrew


> Rick
>
> 1: https://www.youtube.com/watch?v=oJukQzROo-Q
> 2: https://jujucharms.com/u/attardi-h/jupyter-notebook/
> 3: https://api.jujucharms.com/charmstore/v5/changes/published?limit=100
> 4: https://jujucharms.com/u/tengu-team/jupyter-notebook/
> 5: https://github.com/axw/interface-jupyterhub-spawner
> 6: https://github.com/axw/interface-jupyterhub-authenticator
> 7: https://github.com/axw/layer-jupyterhub
> 8: https://github.com/axw/jupyterhub-usso-authenticator
> 9: https://github.com/axw/jupyterhub-lxd-spawner
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to build juju for centOS

[Andrew Wilkins]

On Wed, May 10, 2017 at 3:08 PM fengxia  wrote:

> I have followed dev instruction and can build Juju binaries for Ubuntu.
> The dev machine is also Ubuntu.
>
> $ go install -v github.com/juju/juju/…
>
> Using the same binaries will not however bootstrap with "--config
> default-series=centos", nor "add-machine --series centos". Both failed at
> "no tools founds".
>
> How to build an agent for centos?
>
For a start, you should use "centos7", not "centos". "juju add-machine
--series=centos" *should* give you an immediate error indicating that
that's not a valid series, and ideally inform you of the closest match(es);
I'll file a bug to get that fixed.

Do you need to build from source? If you're using a released version of
Juju, then the agents are available on streams.canonical.com.

For dev builds, we don't have a nice, supported solution. The supported
solution is to create agent tarballs and generate simplestreams metadata. I
wrote a plugin a while ago that you can use to build and upload agent
tarballs to the controller directly, but you shouldn't use it in production
systems:

$ go get github.com/axw/juju-tools
$ juju tools build 2.2-beta4.1-centos7-amd64
building: juju-2.2-beta4.1-centos7-amd64.tgz
$ juju tools upload -m controller juju-2.2-beta4.1-centos7-amd64.tgz
uploading "juju-2.2-beta4.1-centos7-amd64.tgz"
$ juju add-machine --series=centos7

Cheers,
Andrew

> --
> Feng xia
> Engineer
> Lenovo USA
>
> Phone: 5088011794 <(508)%20801-1794>fx...@lenovo.com
>   
> Lenovo.com
> Twitter | Facebook | Instagram | Blogs | Forums
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: libjuju macaroons workaround

[Andrew Wilkins]

On Wed, Mar 29, 2017 at 3:03 AM James Beedy  wrote:

> I'm back around to building a CI system that will rely heavily on libjuju
> to interact with my Juju models. I'm experiencing a problem authenticating
> to the hosted controller via JAAS due to libjuju not yet supporting the
> fetching and discharging of macaroons, see
> https://github.com/juju/python-libjuju/issues/50.
>
> Wondering if anyone has a workaround on hand to interface libjuju to
> JAAS/hosted controller?
>

If you can use the Juju CLI as well, one option would be to first run "juju
login". If you don't specify a password, libjuju will use those cookies:
https://github.com/juju/python-libjuju/blob/master/juju/client/connection.py#L409
.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Can't juju deploy p2.xlarge in aws/us-east-1

[Andrew Wilkins]

On Mon, Mar 20, 2017 at 10:17 PM Junien Fridrick <
junien.fridr...@canonical.com> wrote:

> And once/if you have no Classic instance running in a region, you should
> file a ticket to AWS Support asking for a default VPC creation. Once
> it's done, you don't need to supply the VPC ID anymore.
>
> Could juju maybe be instructed to use a VPC if and only if a single VPC
> exist in a region, without specifying its ID ? For example, --config
> "force-vpc=true" or something.
>

Yes we could do that. I'd like to go a bit further; what I would like to
have happen is:

1. juju will use the VPC specified in config, if any
2. else, Juju will look for a VPC called (say) "juju-default-vpc"
3. else, Juju will create a VPC with the same name, if it can*, and use that
4. else, Juju will use the default VPC, if available
5. else, bootstrap/add-model will fail

The outcome being that Juju will then *always* use VPC, and the user
shouldn't need to do a thing. This would also allow the provider to be
cleaned up (assuming there's a migration path for existing deployments),
and new features to be implemented more easily (e.g. support for EFS).

Everyone on the team is currently fully booked, so I can't give you an
estimate of when that'll come to fruition yet. We could do everything
except have Juju fail pretty easily I would think.

* "if it can", because there are pretty severe limits on the number of VPCs
you can create: 5 per region.

Cheers,
Andrew


> On Thu, Mar 16, 2017 at 08:04:22AM -0400, Tim Van Steenburgh wrote:
> > A. That was it. After passing --config "vpc-id=vpc-924fc7f6" to `juju
> > bootstrap`, I can now deploy p2 instance types. Thanks Andrew!
> >
> > On Thu, Mar 16, 2017 at 4:21 AM, Samuel Cozannet <
> > samuel.cozan...@canonical.com> wrote:
> >
> > > Aaah whaow. I have a default VPC myself, so that may explain the
> problem
> > > Tim is having. Early adopters problem!!
> > >
> > >
> > > --
> > > Samuel Cozannet
> > > Cloud, Big Data and IoT Strategy Team
> > > Business Development - Cloud and ISV Ecosystem
> > > Changing the Future of Cloud
> > > Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com>
> /
> > > Juju <https://jujucharms.com>
> > > samuel.cozan...@canonical.com
> > > mob: +33 616 702 389
> > > skype: samnco
> > > Twitter: @SaMnCo_23
> > > [image: View Samuel Cozannet's profile on LinkedIn]
> > > <https://es.linkedin.com/in/scozannet>
> > >
> > > On Thu, Mar 16, 2017 at 9:17 AM, Andrew Wilkins <
> > > andrew.wilk...@canonical.com> wrote:
> > >
> > >> On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet <
> > >> samuel.cozan...@canonical.com> wrote:
> > >>
> > >>> I am using the default settings, no change as far as I know to what
> Juju
> > >>> would do by default.
> > >>>
> > >>
> > >> What Juju will do depends on what is available in your EC2 account.
> Not
> > >> all EC2 accounts were born alike.
> > >>
> > >> If your account has a default VPC, that will be used by Juju. In that
> > >> case, you'll have p2 instance types available. I expect this to be
> the case
> > >> for most people - all accounts created since 2013-12-04 will have a
> default
> > >> VPC.
> > >>
> > >> If you've got an older account, then you may or may not have a default
> > >> VPC. If you do not, then Juju will fall back to EC2 Classic. In that
> case,
> > >> no p2 instance types.
> > >>
> > >> Cheers,
> > >> Andrew
> > >>
> > >>
> > >>> --
> > >>> Samuel Cozannet
> > >>> Cloud, Big Data and IoT Strategy Team
> > >>> Business Development - Cloud and ISV Ecosystem
> > >>> Changing the Future of Cloud
> > >>> Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com>
> /
> > >>> Juju <https://jujucharms.com>
> > >>> samuel.cozan...@canonical.com
> > >>> mob: +33 616 702 389
> > >>> skype: samnco
> > >>> Twitter: @SaMnCo_23
> > >>> [image: View Samuel Cozannet's profile on LinkedIn]
> > >>> <https://es.linkedin.com/in/scozannet>
> > >>>
> > >>> On Thu, Mar 16, 2017 at 8:52 AM, Andrew Wilkins <
> > >>> andrew.wilk...@canonical.com> wrote:
&g

Re: Can't juju deploy p2.xlarge in aws/us-east-1

[Andrew Wilkins]

On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet <
samuel.cozan...@canonical.com> wrote:

> I am using the default settings, no change as far as I know to what Juju
> would do by default.
>

What Juju will do depends on what is available in your EC2 account. Not all
EC2 accounts were born alike.

If your account has a default VPC, that will be used by Juju. In that case,
you'll have p2 instance types available. I expect this to be the case for
most people - all accounts created since 2013-12-04 will have a default VPC.

If you've got an older account, then you may or may not have a default VPC.
If you do not, then Juju will fall back to EC2 Classic. In that case, no p2
instance types.

Cheers,
Andrew


> --
> Samuel Cozannet
> Cloud, Big Data and IoT Strategy Team
> Business Development - Cloud and ISV Ecosystem
> Changing the Future of Cloud
> Ubuntu <http://ubuntu.com>  / Canonical UK LTD <http://canonical.com> /
> Juju <https://jujucharms.com>
> samuel.cozan...@canonical.com
> mob: +33 616 702 389
> skype: samnco
> Twitter: @SaMnCo_23
> [image: View Samuel Cozannet's profile on LinkedIn]
> <https://es.linkedin.com/in/scozannet>
>
> On Thu, Mar 16, 2017 at 8:52 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
> On Tue, Mar 14, 2017 at 8:48 PM Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
> 2.1.1 juju client and controller, controller bootstrapped in aws/us-east-1:
>
> juju deploy ./kubernetes-worker --constraints "instance-type=p2.xlarge" 
> kubernetes-worker-gpu
> Deploying charm "local:xenial/kubernetes-worker-1".
> ERROR cannot add application "kubernetes-worker-gpu": invalid constraint 
> value: instance-type=p2.xlarge
> valid values are: [m1.small cc2.8xlarge cr1.8xlarge g2.2xlarge r3.8xlarge 
> i2.xlarge t1.micro c1.xlarge g2.8xlarge m3.xlarge m3.medium c3.4xlarge 
> hs1.8xlarge r3.2xlarge m1.xlarge c3.xlarge c3.large c3.8xlarge r3.xlarge 
> m2.xlarge m1.large i2.2xlarge i2.8xlarge cg1.4xlarge d2.2xlarge m2.2xlarge 
> m3.2xlarge hi1.4xlarge m2.4xlarge r3.4xlarge r3.large d2.xlarge c1.medium 
> d2.8xlarge m3.large m1.medium c3.2xlarge i2.4xlarge d2.4xlarge]
>
> Are you using VPC? p2 instance types only support VPC.
>
> I /am/ able to deploy a p2.xlarge in aws/us-east-1 using the AWS console. 
> Looking at the code it seems this instance-type should be available: 
> https://github.com/juju/juju/blob/juju-2.1.1/provider/ec2/internal/ec2instancetypes/generated.go#L6165
>
> Not sure if this is a bug or PEBKAC. Grateful for any ideas while I continue 
> to poke at it.
>
>
> Tim
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Can't juju deploy p2.xlarge in aws/us-east-1

[Andrew Wilkins]

On Tue, Mar 14, 2017 at 8:48 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> 2.1.1 juju client and controller, controller bootstrapped in aws/us-east-1:
>
> juju deploy ./kubernetes-worker --constraints "instance-type=p2.xlarge" 
> kubernetes-worker-gpu
> Deploying charm "local:xenial/kubernetes-worker-1".
> ERROR cannot add application "kubernetes-worker-gpu": invalid constraint 
> value: instance-type=p2.xlarge
> valid values are: [m1.small cc2.8xlarge cr1.8xlarge g2.2xlarge r3.8xlarge 
> i2.xlarge t1.micro c1.xlarge g2.8xlarge m3.xlarge m3.medium c3.4xlarge 
> hs1.8xlarge r3.2xlarge m1.xlarge c3.xlarge c3.large c3.8xlarge r3.xlarge 
> m2.xlarge m1.large i2.2xlarge i2.8xlarge cg1.4xlarge d2.2xlarge m2.2xlarge 
> m3.2xlarge hi1.4xlarge m2.4xlarge r3.4xlarge r3.large d2.xlarge c1.medium 
> d2.8xlarge m3.large m1.medium c3.2xlarge i2.4xlarge d2.4xlarge]
>
> Are you using VPC? p2 instance types only support VPC.

> I /am/ able to deploy a p2.xlarge in aws/us-east-1 using the AWS console. 
> Looking at the code it seems this instance-type should be available: 
> https://github.com/juju/juju/blob/juju-2.1.1/provider/ec2/internal/ec2instancetypes/generated.go#L6165
>
> Not sure if this is a bug or PEBKAC. Grateful for any ideas while I continue 
> to poke at it.
>
>
> Tim
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.1.0, and Conjure-up, are here!

[Andrew Wilkins]

On Fri, Feb 24, 2017 at 6:51 PM Mark Shuttleworth  wrote:

> On 24/02/17 11:30, Andrew Wilkins wrote:
>
> On Fri, Feb 24, 2017 at 6:15 PM Adam Collard 
> wrote:
>
> On Fri, 24 Feb 2017 at 10:07 Adam Israel 
> wrote:
>
> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in your LXD
> images as a way of speeding up the development/testing cycle, but doing so
> might give you false confidence in your charm. It will become much easier
> to forget to list a package that you need installing,  or to ensure that
> you have the correct access (PPA credentials, or proxy details etc.) and
> having your charm gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across multiple
> cloud providers, bare metal and containers please keep that in mind :)
>
>
> Indeed, and this is the reason why it wasn't called out. We probably
> should document it for power-users/charmers, but in general I wouldn't go
> encouraging its use. Optimising for LXD is great for repeat deploys, but it
> wouldn't be great if that leads to less attention to quality on the rest of
> the providers.
>
> Anyway, I'm glad it's helping make charmers' lives easier!
>
>
> We should call this out loudly because it helps people making charms.
>
> Those people are plenty smart enough to debug a failure if they forget a
> dependency which was preinstalled in their dev images.
>

I was thinking about deployment times more than anything else. If you don't
feel your user's pain, you're less likely to make it go away. But anyway,
that can be fixed with automation as well (CI, as you say below).


> Don't HIDE something that helps developers for fear of those developers
> making mistakes, TEACH them to put CI or other out-of-band tests in place
> anyway that will catch that every time.
>

FWIW, it wasn't intentionally hidden to start with, it was just missed. I
made the changes primarily to support an external user who wanted to demo
CentOS charms on LXD; the change also enabled custom images in general, and
also slightly improved container startup time. Three birds, one stone; only
one bird-hitting was reported ;)

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.1.0, and Conjure-up, are here!

[Andrew Wilkins]

On Fri, Feb 24, 2017 at 6:15 PM Adam Collard 
wrote:

> On Fri, 24 Feb 2017 at 10:07 Adam Israel 
> wrote:
>
> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>
>
> Only if you also wave a big WARNING banner!
>
> I can definitely see value in pre-installing a bunch of things in your LXD
> images as a way of speeding up the development/testing cycle, but doing so
> might give you false confidence in your charm. It will become much easier
> to forget to list a package that you need installing,  or to ensure that
> you have the correct access (PPA credentials, or proxy details etc.) and
> having your charm gracefully handle when those are missing.
>
> Juju promises charms encoding operations that can work across multiple
> cloud providers, bare metal and containers please keep that in mind :)
>

Indeed, and this is the reason why it wasn't called out. We probably should
document it for power-users/charmers, but in general I wouldn't go
encouraging its use. Optimising for LXD is great for repeat deploys, but it
wouldn't be great if that leads to less attention to quality on the rest of
the providers.

Anyway, I'm glad it's helping make charmers' lives easier!

Cheers,
Andrew


> On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
> wrote:
>
> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New in 2.1-beta5: Prometheus monitoring

[Andrew Wilkins]

On Tue, Feb 7, 2017 at 6:19 PM Jacek Nykis 
wrote:

> On 07/02/17 02:25, Andrew Wilkins wrote:
> > Hi folks,
> >
> > In the release notes there was an innocuous line about introspection
> > endpoints added to the controller. What this really means is that you can
> > now monitor Juju controllers with Prometheus. Juju controllers export
> > metrics, including:
> >  - API requests (total number and latencies by facade/method, grouped by
> > error code)
> >  - numbers of entities (models, users, machines, ...)
> >  - mgo/txn op counts
> >
> > We're working on getting the online docs updated. In the mean time,
> please
> > refer to https://github.com/juju/docs/issues/1624 for instructions on
> how
> > to set up Prometheus to scrape Juju. It would be great to get some early
> > feedback.
>
> Hi Andrew,
>
> Thanks! Those metrics will be super useful, I will try to find some time
> to look into them properly.
>
> Some early feedback:
> 1. Your docs say the metrics endpoint requires authentication. I think
> this can be problematic for people who run multiple controllers or
> recycle them often. Secrets set up requires manual steps and they need
> to be distributed to prometheus server. It would be very useful to allow
> unauthenticated access and rely on firewalls to restrict access
> (approach followed by most prometheus exporters I looked at).
> 2. You don't offer option to downgrade to HTTP which is problematic as
> well IMO. Similar to above it's an obstacle users have to go through
> before they can scrape targets, manual steps are required, CA certs need
> to be shipped around. It would be very convenient if users could
> explicitly fall back to http and let other layers to provide security.
>
> Basically I think letting users enable unauthenticated HTTP endpoint for
> prometheus metrics would be big usability win.
>

Thanks for the feedback, Jacek.

I agree that providing unauthenticated HTTP would be helpful for many
users. I don't think that should be the default, because some of the
metrics exposed could be considered sensitive. Also, it should be fairly
straight forward to automate the configuration of the Prometheus server.

Eventually, we intend for Juju itself to be described within the model.
When that is reality, it would be sensible for the Juju controller
application to have an endpoint for unauthenticated HTTP access to metrics.
You could then just bind that to a space that Prometheus can access.

In the interim, there is https://jujucharms.com/u/axwalk/juju-introspection/.
Deploy that to any machine in Juju (including but not limited to controller
machines), and you get access to that machine agent's metrics over
unauthenticated HTTP on a configurable port. PRs welcome if it doesn't
quite fit your needs.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

New in 2.1-beta5: Prometheus monitoring

[Andrew Wilkins]

Hi folks,

In the release notes there was an innocuous line about introspection
endpoints added to the controller. What this really means is that you can
now monitor Juju controllers with Prometheus. Juju controllers export
metrics, including:
 - API requests (total number and latencies by facade/method, grouped by
error code)
 - numbers of entities (models, users, machines, ...)
 - mgo/txn op counts

We're working on getting the online docs updated. In the mean time, please
refer to https://github.com/juju/docs/issues/1624 for instructions on how
to set up Prometheus to scrape Juju. It would be great to get some early
feedback.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Create Juju Charms from your browser!

[Andrew Wilkins]

On Fri, Feb 3, 2017 at 10:14 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> I've been looking at Eclipse Che for a while, it is a cloud Workspace and
> IDE from the Eclipse Foundation. An IDE that runs in your browser, with
> docker containers as workspaces.
>
> It's a great way to lower the barrier for new developers. Open Che in your
> browser, choose the stack you want, and start coding.
>
> I've created a Charm that deploys Eclipse Che and creates a stack that has
> everything you need to start Charming. The stack is based on the `charmbox`
> Docker container.
>
> Eclipse Che Charm: https://jujucharms.com/u/tengu-team/eclipse-che/
> Eclipse Che Layer: https://github.com/IBCNServices/layer-eclipse-che
>
> Check it out and let me know what you think of it!
>

Very cool, thanks for sharing.

A few things which I think would make this even better:
 - integration with Ubuntu SSO (or GitHub OAuth, etc.)
 - with above: inject macaroon/token into the charmbox container, so that
the juju CLI would be automatically logged in (would only work with
external identity management)
 - with above: Right-click "Deploy to Juju", with detection of changes to
deployed code and an option to update.

... in case anyone has spare time ;)

Cheers,
Andrew


> Kind regards
> Merlijn
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Can not juju register.

[Andrew Wilkins]

On Wed, Jan 25, 2017 at 1:43 PM yuki kono  wrote:

> Hello.
> I'm yuki.
>

Hi Yuki,


> I tried to run "juju register" to juju-bootstrap node,but receive
> following error message.
>
> ---
> ubuntu@jc01:~$ juju --debug register 10.0.10.38:17070
> 03:52:18 INFO  juju.cmd supercommand.go:63 running juju [2.0.2 gc go1.6.2]
> 03:52:18 DEBUG juju.cmd supercommand.go:64   args: []string{"juju",
> "--debug", "register", "10.0.10.38:17070"}
> 03:52:18 INFO  juju.api apiclient.go:530 dialing "wss://
> 10.0.10.38:17070/api"
> 03:52:18 INFO  juju.api apiclient.go:539 error dialing "wss://
> 10.0.10.38:17070/api": websocket.Dial wss://10.0.10.38:17070/api: x509:
> certificate signed by unknown authority
> 03:52:18 ERROR cmd supercommand.go:458 unable to connect to API:
> websocket.Dial wss://10.0.10.38:17070/api: x509: certificate signed by
> unknown authority
> 03:52:18 DEBUG cmd supercommand.go:459 (error details: [{
> github.com/juju/juju/cmd/juju/controller/register.go:140: } {
> github.com/juju/juju/cmd/juju/controller/register.go:223: } {
> github.com/juju/juju/api/apiclient.go:185: } {
> github.com/juju/juju/api/apiclient.go:464: } {
> github.com/juju/juju/api/apiclient.go:494: } {
> github.com/juju/juju/api/apiclient.go:540: unable to connect to API}
> {websocket.Dial wss://10.0.10.38:17070/api: x509: certificate signed by
> unknown authority}])
> ---
> I guess it is caused by some certificate error for golang net/http library.
> (Not use "InsecureSkipVerify: true" ???)
>
> Does anyone know the solution?
>

Can you explain what you're trying to do?

Normally you would use "juju add-user" first, which prints out a "juju
register" command to run from another machine. There are scenarios where
you use "juju register ", but they're not so common at the
moment.

Cheers,
Andrew

Yuki.
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.x bootstrap on LXD broken (regular bridge, no NAT)

[Andrew Wilkins]

On Tue, Jan 24, 2017 at 12:54 AM John Meinel  wrote:

> For your workaround, where does spec.Endpoint get filled in? By the user
> as part of bootstrap-contraints? or by juju as a default value? I don't see
> anything in your patch, which sounds like you would have to do:
>  juju bootstrap --bootstrap-constraints endpoint=HOSTIP lxd ...
> if you were working on a non-NAT bridge.
>
> Is that true?
>

The workaround involves adding a new cloud, as described in
https://bugs.launchpad.net/juju/+bug/1640455, Comment #9 and down.


> John
> =:->
>
>
> On Mon, Jan 23, 2017 at 3:07 PM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
> On Mon, Jan 23, 2017 at 6:54 PM Toubeau, Anthony <
> anthony.toub...@intel.com> wrote:
>
> Hello all,
>
> I'd like to bring to your attention a currently broken bootstrapping
> scenario:
> Local deployment through LXD using a standard bridge instead of the usual
> LXD provided lxdbr0.
>
> As a development vehicle, a Juju install was planned reusing the
> LXD-host's network. This implies having the Juju agent plus the future
> charms on the same subnet as the actual LXD host.
> As detailed in Bug 1633788 (https://bugs.launchpad.net/juju/+bug/1633788),
> the LXD-host's gateway is assumed (based on the current code) to be
> providing the tools for the actual bootstrapping.
>
> But, in the "non-lxdbr0" case let's say, the actual gateway may only be a
> simple DHCP provider for example, hence leading to a failed deployment.
>
> Reference:
> https://github.com/juju/juju/blob/staging/provider/lxd/environ_raw.go#L140
>
> // getRemoteConfig returns a lxdclient.Config using a TCP-based remote
> // if called from within an instance started by the LXD provider.
> Otherwise,
> // it returns an errors satisfying errors.IsNotFound.
> func getRemoteConfig(readFile readFileFunc, runCommand runCommandFunc)
> (*lxdclient.Config, error) {
> [...]
>
> // Read here...
> hostAddress, err := getDefaultGateway(runCommand)
>
> [...]
> return &lxdclient.Config{
> lxdclient.Remote{
> Name:  "remote",
> Host:  hostAddress,
> [...]
> },
> }, nil
>
>
> Is this behavior an assumed trend or could we consider fixing it to allow
> this sort of "localhost-based" deployments without NAT?
>
>
> A workaround has been implemented in the 2.1 branch, here:
>
> https://github.com/juju/juju/commit/19bf802db6511d2081369da2a3fe9b13f1bcb9fd
>
> To use this workaround, please see the comments on
> https://bugs.launchpad.net/juju/+bug/1640455. I'll mark that bug as a
> duplicate of #1633788 now.
>
> This is just a workaround though. We can go (and probably should) go back
> to doing what we were doing. That was also imperfect: there was a built-in
> assumption that the host's address would never change. The ideal solution
> requires that LXD be changed; changes which got bumped this cycle.
>
> I'll look at reverting the default behaviour ASAP, if nobody else gets to
> it first.
>
> HTH,
> Andrew
>
>
> Many thanks in advance,
> Anthony
> -
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.x bootstrap on LXD broken (regular bridge, no NAT)

[Andrew Wilkins]

On Mon, Jan 23, 2017 at 6:54 PM Toubeau, Anthony 
wrote:

> Hello all,
>
> I'd like to bring to your attention a currently broken bootstrapping
> scenario:
> Local deployment through LXD using a standard bridge instead of the usual
> LXD provided lxdbr0.
>
> As a development vehicle, a Juju install was planned reusing the
> LXD-host's network. This implies having the Juju agent plus the future
> charms on the same subnet as the actual LXD host.
> As detailed in Bug 1633788 (https://bugs.launchpad.net/juju/+bug/1633788),
> the LXD-host's gateway is assumed (based on the current code) to be
> providing the tools for the actual bootstrapping.
>
> But, in the "non-lxdbr0" case let's say, the actual gateway may only be a
> simple DHCP provider for example, hence leading to a failed deployment.
>
> Reference:
> https://github.com/juju/juju/blob/staging/provider/lxd/environ_raw.go#L140
>
> // getRemoteConfig returns a lxdclient.Config using a TCP-based remote
> // if called from within an instance started by the LXD provider.
> Otherwise,
> // it returns an errors satisfying errors.IsNotFound.
> func getRemoteConfig(readFile readFileFunc, runCommand runCommandFunc)
> (*lxdclient.Config, error) {
> [...]
>
> // Read here...
> hostAddress, err := getDefaultGateway(runCommand)
>
> [...]
> return &lxdclient.Config{
> lxdclient.Remote{
> Name:  "remote",
> Host:  hostAddress,
> [...]
> },
> }, nil
>
>
> Is this behavior an assumed trend or could we consider fixing it to allow
> this sort of "localhost-based" deployments without NAT?
>

A workaround has been implemented in the 2.1 branch, here:

https://github.com/juju/juju/commit/19bf802db6511d2081369da2a3fe9b13f1bcb9fd

To use this workaround, please see the comments on
https://bugs.launchpad.net/juju/+bug/1640455. I'll mark that bug as a
duplicate of #1633788 now.

This is just a workaround though. We can go (and probably should) go back
to doing what we were doing. That was also imperfect: there was a built-in
assumption that the host's address would never change. The ideal solution
requires that LXD be changed; changes which got bumped this cycle.

I'll look at reverting the default behaviour ASAP, if nobody else gets to
it first.

HTH,
Andrew


> Many thanks in advance,
> Anthony
> -
> Intel Corporation SAS (French simplified joint stock company)
> Registered headquarters: "Les Montalets"- 2, rue de Paris,
> 92196 Meudon Cedex, France
> Registration Number:  302 456 199 R.C.S. NANTERRE
> Capital: 4,572,000 Euros
>
> This e-mail and any attachments may contain confidential material for
> the sole use of the intended recipient(s). Any review or distribution
> by others is strictly prohibited. If you are not the intended
> recipient, please contact the sender and delete all copies.
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Instance metadata for private cloud.

[Andrew Wilkins]

On Thu, Nov 10, 2016 at 11:52 PM Jonathan Proulx  wrote:

> Hi All,
>

Hi Jon,


> Trying to test out juju on my private OpenStack cloud.
>
> Having trouble bootstraping.
>

First, sorry. We recognise that the experience for setting up image
metadata is not great. We've got some ideas about improving the validation
tools, and generally simplifying the process. I can't say when that'll get
implemented, but it is on the list.


> I've followed https://jujucharms.com/docs/stable/howto-privatecloud to
> generate image metadata in ~/simplestreams and nomatter how I feed it
> in I get:
>
> ERROR failed to bootstrap model: no image metadata found
>
>
> I've tried the 'juju bootstrap --metadata-source
> /afs/csail.mit.edu/u/j/jon/simplestreams' suggested by the out put of
> 'juju metadata generate-image'
>
> I've tried uploading to OpenStack object store as described in
> https://jujucharms.com/docs/stable/howto-privatecloud and creating a
> servic eand an endpoitn for it. This may have failed because our
> object store is ceph not swift so semantics might be different.
>
> Also tried copying the simplestreams directory to public webspace and
> specifying:
>
> juju bootstrap tigtest tigtest-CSAIL_Stata --config image-metadata-url=
> https://people.csail.mit.edu/jon/simplestreams


It looks to me that you just need to append "/images" to that URL. I've
just gone ahead and run the same command but with "
https://people.csail.mit.edu/jon/simplestreams/images";.

I just hacked up my client to query as if it were your setup, with a reigon
name of "CSAIL_Stata" and keystone endpoint of "
https://keystone.csail.mit.edu:35358/v3";. With the adjusted
image-metadata-url, my client found the image metadata.

HTH.

Cheers,
Andrew


> and stepping out that url one level at a time as far as
>
> https://people.csail.mit.edu/jon/simplestreams/images/streams/v1/com.ubuntu.cloud-released-imagemetadata.json
>
> but always erors out the same way.
>
> What am I missing here?
>
>
> -Jon
> --
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju agent status remains "Allocating" and is not starting on MAAS 2.0 when --storage option is used

[Andrew Wilkins]

On Tue, Nov 8, 2016 at 8:29 PM Shilpa Kaul  wrote:

> Hi,
>
> I am trying to deploy a charm on MAAS 2.0 and making use of Juju Storage
> feature, so when I deploy my charm as shown below:
> *juju deploy  ibm-spectrum-scale  --storage disks=maas*, the machine gets
> started and status on MAAS is "deployed" but the juju agent does not start.
> The agent message is "*agent initializing*" and nothing happens after
> that.
>
> The same charm gets deployed if I dont give the --storage parameter during
> deploy time or use *--storage disks=loop*. This issue is seen only when i
> deploy the charm with *--storage disks=maas*. I have tried deploying the
> charm on AWS environment with --storage disks=ebs, there it works fine and
> no issues are seen.
>
> In the juju logs I see the below messages:
> to agent config as ["192.168.100.101:17070" "192.168.122.101:17070"]
> 2016-11-08 17:47:59 ERROR juju.worker.dependency engine.go:539
> "metric-collect" manifold worker returned unexpected error: failed to read
> charm from: /var/lib/juju/agents/unit-ibm-spectrum-scale-manager2-2/charm:
> stat /var/lib/juju/agents/unit-ibm-spectrum-scale-manager2-2/charm: no such
> file or directory
> 2016-11-08 17:47:59 INFO juju.worker.leadership tracker.go:184
> ibm-spectrum-scale-manager2/2 will renew ibm-spectrum-scale-manager2
> leadership at 2016-11-08 17:48:29.13919966 + UTC
> 2016-11-08 17:47:59 INFO juju.worker.meterstatus connected.go:112 skipped
> "meter-status-changed" hook (missing)
> 2016-11-08 17:47:59 INFO worker.uniter.jujuc tools.go:20 ensure jujuc
> symlinks in /var/lib/juju/tools/unit-ibm-spectrum-scale-manager2-2
> 2016-11-08 17:47:59 INFO worker.uniter.jujuc tools.go:40 was a symlink,
> now looking at /var/lib/juju/tools/2.0.1-xenial-amd64
> 2016-11-08 17:47:59 INFO juju.worker.uniter uniter.go:159 unit
> "ibm-spectrum-scale-manager2/2" started
> 2016-11-08 17:47:59 INFO juju.worker.uniter uniter.go:168 resuming charm
> install
> 2016-11-08 17:47:59 INFO juju.worker.uniter.charm bundles.go:77
> downloading local:xenial/ibm-spectrum-scale-manager2-3 from API server
> 2016-11-08 17:47:59 INFO juju.downloader download.go:111 downloading from
> local:xenial/ibm-spectrum-scale-manager2-3
> 2016-11-08 17:47:59 INFO juju.downloader download.go:94 download complete
> ("local:xenial/ibm-spectrum-scale-manager2-3")
> 2016-11-08 17:47:59 INFO juju.downloader download.go:174 download verified
> ("local:xenial/ibm-spectrum-scale-manager2-3")
>
> I compared the logs of the charm that I deployed on AWS and MAAS. In AWS
> also when I deploy the charm, same messages are logged, the only difference
> is that there its resuming the correct unit ie
> *ibm-spectrum-scale-manager2-2,* but in case of MAAS, it resumes for unit*
> ibm-spectrum-scale-manager2-3* which does not exist.
>
> Can anyone please help me in resolving this issue, I  need to test my
> charm deployment on MAAS making use of juju storage, but unable to do so
> due to the above noted behavior.


Hi Shilpa,

AFAICT, this is the same issue as you mentioned in the thread "Regarding
juju Storage - using MAAS as cloud provider". Can you please respond to
Blake's request for information in that thread? That should help us
identify the problem.

Thanks,
Andrew


> Thanks and Regards,
> Shilpa Kaul
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [ANN] Mattermost and layer:lets-encrypt

[Andrew Wilkins]

On Tue, Oct 25, 2016 at 2:22 AM Casey Marshall 
wrote:

> On Mon, Oct 24, 2016 at 3:51 AM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
> On Sun, Oct 16, 2016 at 12:07 AM Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
> With a much appreciated recent contribution from James Beedy (bdx) our
> Mattermost charm cs:~cmars/mattermost[1] is working again!
>
> This encouraged me to add some followup improvements to the charm to make
> it even easier to deploy with secure defaults -- automatic registration
> with Let's Encrypt.
>
> I've broken out the Let's Encrypt integration to a separate reactive charm
> layer, layer:lets-encrypt[2], which extends layer:nginx. Practically any
> charm that uses layer:nginx should be able to use layer:lets-encrypt. When
> a config option `fqdn` is set, the layer will automatically register with
> LE and obtain certificates.
>
>
> Nice, thank you. This will be useful for some stuff I'm working on.
>
> It would be nice if the nginx charm supported (included) this by default.
> Is there a reason it shouldn't? Having to create a separate charm that
> includes both means you then have to track changes.
>
>
> I came to the conclusion that layer:nginx and layer:lets-encrypt should
> each do one thing well for better reuse. layer:lets-encrypt no longer
> includes layer:nginx, but they're easy to use together.
>
> layer:lets-encrypt now just obtains certs, which you can then use in nginx
> templates -- or in any web application configuration, really. See the
> latest README[1] for up-to-date usage.
>

OK, indeed sounds better than including nginx. I'll have a play with it
soon.

Cheers,
Andrew


> -Casey
>
> [1] https://github.com/cmars/layer-lets-encrypt
>
>
>
> With the epic release of Juju 2.0 this past week -- the Mattermost charm
> depends on several features new in Juju 2 -- it's now ready to share.
>
> I'm operating a deployment of cs:~cmars/mattermost at
> https://live.cmars.tech/. If you'd like to try it out, here's an invite:
> https://live.cmars.tech/signup_user_complete/?id=wccpdu6dqp88mjkqbngnws6ohc
>
> -Casey
>
> [1] https://jujucharms.com/u/cmars/mattermost
> https://github.com/cmars/juju-charm-mattermost
> [2] https://github.com/cmars/layer-lets-encrypt
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [ANN] Mattermost and layer:lets-encrypt

[Andrew Wilkins]

On Sun, Oct 16, 2016 at 12:07 AM Casey Marshall <
casey.marsh...@canonical.com> wrote:

> With a much appreciated recent contribution from James Beedy (bdx) our
> Mattermost charm cs:~cmars/mattermost[1] is working again!
>
> This encouraged me to add some followup improvements to the charm to make
> it even easier to deploy with secure defaults -- automatic registration
> with Let's Encrypt.
>
> I've broken out the Let's Encrypt integration to a separate reactive charm
> layer, layer:lets-encrypt[2], which extends layer:nginx. Practically any
> charm that uses layer:nginx should be able to use layer:lets-encrypt. When
> a config option `fqdn` is set, the layer will automatically register with
> LE and obtain certificates.
>

Nice, thank you. This will be useful for some stuff I'm working on.

It would be nice if the nginx charm supported (included) this by default.
Is there a reason it shouldn't? Having to create a separate charm that
includes both means you then have to track changes.

With the epic release of Juju 2.0 this past week -- the Mattermost charm
> depends on several features new in Juju 2 -- it's now ready to share.
>
> I'm operating a deployment of cs:~cmars/mattermost at
> https://live.cmars.tech/. If you'd like to try it out, here's an invite:
> https://live.cmars.tech/signup_user_complete/?id=wccpdu6dqp88mjkqbngnws6ohc
>
> -Casey
>
> [1] https://jujucharms.com/u/cmars/mattermost
> https://github.com/cmars/juju-charm-mattermost
> [2] https://github.com/cmars/layer-lets-encrypt
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0 is here!

[Andrew Wilkins]

On Fri, 14 Oct 2016, 12:34 p.m. Nicholas Skaggs, <
nicholas.ska...@canonical.com> wrote:

Juju 2.0 is here! This release has been a year in the making. We’d like
to thank everyone for their feedback, testing, and adoption of juju 2.0
throughout its development process! Juju brings refinements in ease of
use, while adding support for new clouds and features.


What an epic release! I for one am proud of what we've created together.
Great work everyone.

## New to juju 2?

https://jujucharms.com/docs/2.0/getting-started

## Need to install it?

If you are running Ubuntu, you can get it from the juju stable ppa:

 sudo add-apt-repository ppa:juju/stable
 sudo apt update; sudo apt install juju-2.0

Or install it from the snap store

 snap install juju --beta --devmode

Windows, Centos, and MacOS users can get a corresponding installer at:

https://launchpad.net/juju/+milestone/2.0.0

## Want to upgrade to GA?

Those of you running an RC version of juju 2 can upgrade to this release
by running:

juju upgrade-juju

## Feedback Appreciated!

We encourage everyone to subscribe the mailing list at
juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
hear
your feedback and usage of juju.


--
Juju-dev mailing list
juju-...@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/juju-dev
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upgrading to VPC on AWS

[Andrew Wilkins]

On Fri, Oct 7, 2016 at 11:31 PM Mark Shuttleworth  wrote:

> Hi folks
>
>
>
> My AWS account pre-dates VPCs, so I didn't have one by default. I've now
>
> added one, how can I update my credential / controller to make use of it
>
> by default?
>

At the moment the only way to use a non-default VPC is to specify it
explicitly when bootstrapping or adding a model, using "--config
vpc-id=vpc-xyz". There are some requirements for the VPC, which bootstrap
will inform you of if they are not met. The error message is pasted below.
A couple of additional things I found while trying it out just now:
 - you should have a subnet for each availability zone
 - to create "default route", set the destination as 0.0.0.0/0. Your routes
should look like:
Destination
Target
Status
Propagated
10.0.0.0/16
local
Active
No
0.0.0.0/0
igw-5bd2103c

Active
No

We'll be making this all automatic. If it can, Juju will create a suitable
VPC, subnets, etc. for you to use, and then use it without you having to
specify any config.

Cheers,
Andrew

"""
The given vpc-id does not meet one or more of the following minimum
Juju requirements:

1. VPC should be in "available" state and contain one or more subnets.
2. An Internet Gateway (IGW) should be attached to the VPC.
3. The main route table of the VPC should have both a default route
   to the attached IGW and a local route matching the VPC CIDR block.
4. At least one of the VPC subnets should have MapPublicIPOnLaunch
   attribute enabled (i.e. at least one subnet needs to be 'public').
5. All subnets should be implicitly associated to the VPC main route
   table, rather than explicitly to per-subnet route tables.

A default VPC already satisfies all of the requirements above. If you
still want to use the VPC, try running 'juju bootstrap' again with:

  --config vpc-id=%s --config vpc-id-force=true

to force Juju to bypass the requirements check (NOT recommended unless
you understand the implications: most importantly, not being able to
access the Juju controller, likely causing bootstrap to fail, or trying
to deploy exposed workloads on instances started in private or isolated
subnets).
"""


> Mark
>
>
>
>
>
> --
>
> Juju mailing list
>
> Juju@lists.ubuntu.com
>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0-rc3 is here!

[Andrew Wilkins]

On Fri, Oct 7, 2016 at 6:15 AM Curtis Hovey-Canonical 
wrote:

> A new development release of Juju, 2.0-rc3, is here!
>
>
> ## What's new?
>
> * For an AWS VPC account juju will create a t2.medium for controller
>   instances by default now. Non-controller instances are unchanged for
>   now, and remain m3.medium by default. Controller instance root disk
>   now defaults to 32GiB, but can be overridden with constraints.
> * Shorten the hostnames we apply to instances created by the OpenStack
>   provider.
> Example old hostname:
> juju-fd943864-df2e-4da1-8e7d-5116a87d4e7c-machine-14
>
> Example new hostname:
> Juju-df7591-controller-0
> * Added support for LXD 2.3 apis
> * New update-credential command
> * Added --model-default option to the bootstrap
> * LXD containers now have proper hostnames set
>

Also, support for the aws/ap-south-1 region has been added.

Adam Stokes just found a bug related to this, which prevented him from
being able to destroy his rc2 controller with an rc3 client. I'll fix this
for 2.0, but in the mean time I recommend you destroy your controller
before upgrading the client.

If you do upgrade the client, then you will need to modify
~/.local/share/juju/bootstrap-config.yaml, fixing the endpoint cached in
there. You can find the correct value by running "juju show-cloud aws", and
picking out the value associated with the region you bootstrapped.

Cheers,
Andrew


> ## How do I get it?
>
> If you are running Ubuntu, you can get it from the juju devel ppa:
>
> sudo add-apt-repository ppa:juju/devel
> sudo apt-get update; sudo apt-get install juju-2.0
>
> Windows, Centos, and MacOS users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0-rc3
>
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> ## Anything else?
>
> You can read more information about what's in this release by viewing the
> release notes here:
>
> https://jujucharms.com/docs/devel/temp-release-notes
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming changes for the ec2 provider

[Andrew Wilkins]

On Fri, Oct 7, 2016 at 7:26 AM Mark Shuttleworth  wrote:

> On 06/10/16 16:14, Andrew Wilkins wrote:
>
> On Thu, Oct 6, 2016 at 8:30 PM Rick Harding 
> wrote:
>
> Thanks Andrew, this is great to hear. Can I bug you about details as to
> how it works? Does this introduce their pricing API as a blocker to
> deploying with Juju? If they introduce a change to the API we miss or their
> API goes down is there any sort of cache of the info that users can
> continue with until service is restored?
>
>
> So I said API because that's what it's called by AWS, but IMO it's a bit
> of an overstatement. It's just a set of (very large) JSON files in a well
> defined location. Very large, as in 48M for the one file that we need.
>
> Because it's so big, pulling that down each time you go to bootstrap isn't
> really reasonable. So for now, we're doing that at build time, and the
> information is still hard coded into the client. The process can be
> automated, so there shouldn't be a great lag time between updates and
> bringing them into a Juju release.
>
> We intend to update Juju later to periodically pull down the JSON file
> server-side, asynchronously, so a running controller will get the updates
> without us having to release a new Juju or you having to upgrade.
>
>
> Could we not process the file on our side regularly and publish a
> (smaller) just-what-juju-needs bit of json at a well-known location
> ourselves?
>

Yes, we could. There was some discussion about doing that, and someone
brought up concerns that I can't recall (or find) now. We will explore this
option further.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming changes for the ec2 provider

[Andrew Wilkins]

On Thu, Oct 6, 2016 at 8:30 PM Rick Harding 
wrote:

> Thanks Andrew, this is great to hear. Can I bug you about details as to
> how it works? Does this introduce their pricing API as a blocker to
> deploying with Juju? If they introduce a change to the API we miss or their
> API goes down is there any sort of cache of the info that users can
> continue with until service is restored?
>

So I said API because that's what it's called by AWS, but IMO it's a bit of
an overstatement. It's just a set of (very large) JSON files in a well
defined location. Very large, as in 48M for the one file that we need.

Because it's so big, pulling that down each time you go to bootstrap isn't
really reasonable. So for now, we're doing that at build time, and the
information is still hard coded into the client. The process can be
automated, so there shouldn't be a great lag time between updates and
bringing them into a Juju release.

We intend to update Juju later to periodically pull down the JSON file
server-side, asynchronously, so a running controller will get the updates
without us having to release a new Juju or you having to upgrade.

Hope that clarifies things.

Cheers,
Andrew


>
>
> On Thu, Oct 6, 2016 at 4:52 AM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
> Hi folks,
>
> Just a heads up to let you know about some changes made to the ec2
> provider, which will show up in Juju 2.0.
>
> We are now pulling down the Price List API (
> http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html)
> and using that to determine which instance types to launch. This means that
> you will have access to more instance types now, and we should have more
> accurate/up-to-date pricing information, and region availability.
>
> The default constraints for controllers has been modified, so that on ec2
> we will now default controller machines to t2.medium, as long as you have a
> default VPC in your region, or you specify one by ID (--config vpc-id=...).
> We were previously defaulting to m3.medium. The t2.medium instances have a
> little more memory, and 2 CPUs instead of 1. They are burstable instances,
> so they should suit controllers managing a small-to-medium set of
> applications. Controllers are now started with 32GiB root disk, instead of
> 8GiB as they were before.
>
> As before, you can override the defaults by specifying constraints at
> bootstrap time. Also, these changes do not affect non-controller instances.
> If you use "add-machine", you will get an m3.medium if your region supports
> them.
>
> Cheers,
> Andrew
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Upcoming changes for the ec2 provider

[Andrew Wilkins]

Hi folks,

Just a heads up to let you know about some changes made to the ec2
provider, which will show up in Juju 2.0.

We are now pulling down the Price List API (
http://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/price-changes.html)
and using that to determine which instance types to launch. This means that
you will have access to more instance types now, and we should have more
accurate/up-to-date pricing information, and region availability.

The default constraints for controllers has been modified, so that on ec2
we will now default controller machines to t2.medium, as long as you have a
default VPC in your region, or you specify one by ID (--config vpc-id=...).
We were previously defaulting to m3.medium. The t2.medium instances have a
little more memory, and 2 CPUs instead of 1. They are burstable instances,
so they should suit controllers managing a small-to-medium set of
applications. Controllers are now started with 32GiB root disk, instead of
8GiB as they were before.

As before, you can override the defaults by specifying constraints at
bootstrap time. Also, these changes do not affect non-controller instances.
If you use "add-machine", you will get an m3.medium if your region supports
them.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0-rc1 is here!

[Andrew Wilkins]

On Wed, Sep 21, 2016 at 1:56 PM Curtis Hovey-Canonical 
wrote:

> A new development release of Juju, 2.0-rc1, is here!
>

Woohoo!


> ## What's New in RC1
>
> * The Juju client now works on any Linux flavour. When bootstrapping
>   with local tools, it's now possible to create a controller of any
>   supported Linux series regardless of the Linux flavour the client
>   is running on.
> * Juju resolved command retries failed hooks by default:
>   juju resolved  // marks unit errors resolved and retries failed
> hooks
>   juju resolved --no-retry  //marks unit errors resolved w/o
> retrying hooks
> * MAAS 2.0 Juju provider has been updated to use MAAS API 2.0's owner
>   data for instance tagging.
> * Networking fixes for containers in MAAS 2.0 when the parent device is
>   unconfigured. (#1566791)
> * Azure provider performance has been enhanced, utilising Azure Resource
>   Manager templates, and improved parallelisation.
> * Azure provider now supports an "interactive" auth-type, making it much
>   easier to set up credentials for bootstrapping. The "userpass"
>   auth-type has been deprecated, and replaced with
>   "service-principal-secret".
>

In case anyone jumps right on this, please note that
https://streams.canonical.com/juju/public-clouds.syaml isn't yet updated.
It will be updated soon, but in the mean time, if you want to try out the
azure interactive add-credential, make sure you:
 - delete ~/.local/share/juju/public-clouds.yaml (if it exists)
 - *don't* run "juju update-clouds" until that file is updated
Then Juju will use the cloud definitions built into the client.

Cheers,
Andrew


> ## How do I get it?
>
> If you are running Ubuntu, you can get it from the juju devel ppa:
>
> sudo add-apt-repository ppa:juju/devel
> sudo apt-get update; sudo apt-get install juju-2.0
>
> Or install it from the snap store
>
> snap install juju --beta --devmode
>
> Windows, Centos, and OS X users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0-rc1
>
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> juju@lists.ubuntu.com and join us on #juju on freenode. We would love
> to hear your feedback and usage of juju.
>
>
> ## Anything else?
>
> You can read more information about what's in this release by viewing
> the release notes here:
>
> https://jujucharms.com/docs/devel/temp-release-notes
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming Azure auth changes

[Andrew Wilkins]

On Thu, Sep 15, 2016 at 9:56 AM Andrew Wilkins 
wrote:

> On Thu, Sep 15, 2016 at 9:15 AM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> Hi folks,
>>
>> Just a heads up, where will be some changes to authentication in the
>> Azure provider. When https://github.com/juju/juju/pull/6247 lands (if
>> you're working off master), or otherwise when rc1 is out, you will need to
>> remove "tenant-id" from your credentials.yaml.
>>
>
> Slight change of plans. I'm going to deprecate the "userpass"
> authentication type, but keep it working until rc1 is out.
>
> There will be two new auth-types: "service-principal-secret", and
> "interactive". The former is a replacement for userpass, and has exactly
> the same attributes as today, minus the tenant-id. "Interactive" is a work
> in progress. I'll write back about it once the work is progressed enough
> that I can explain how to use it.
>

The "interactive" auth-type for Azure has just landed on master, so it
should be in 2.0 RC1. This is now the default auth-type when using "juju
add-credential azure".

To add a credential for Azure, you now do the following:
 - run "juju add-credential azure"
 - enter credential name of your choosing
 - select the "interactive" auth-type
 - enter your subscription ID [0]
 - you will now be prompted to open a URL and enter a code, then proceed to
authenticate with Azure and authorise Juju to create credentials on your
behalf. Once you have given your consent, Juju will do the rest.

Cheers,
Andrew

[0] your subscription ID can be found in the Azure Portal, under the
Subscriptions blade:
https://portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming Azure auth changes

[Andrew Wilkins]

On Thu, Sep 15, 2016 at 9:15 AM Andrew Wilkins 
wrote:

> Hi folks,
>
> Just a heads up, where will be some changes to authentication in the Azure
> provider. When https://github.com/juju/juju/pull/6247 lands (if you're
> working off master), or otherwise when rc1 is out, you will need to remove
> "tenant-id" from your credentials.yaml.
>

Slight change of plans. I'm going to deprecate the "userpass"
authentication type, but keep it working until rc1 is out.

There will be two new auth-types: "service-principal-secret", and
"interactive". The former is a replacement for userpass, and has exactly
the same attributes as today, minus the tenant-id. "Interactive" is a work
in progress. I'll write back about it once the work is progressed enough
that I can explain how to use it.


> There is more work underway to improve the bootstrap/credentials
> experience for Azure.
>
> Cheers,
> Andrew
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Upcoming Azure auth changes

[Andrew Wilkins]

Hi folks,

Just a heads up, where will be some changes to authentication in the Azure
provider. When https://github.com/juju/juju/pull/6247 lands (if you're
working off master), or otherwise when rc1 is out, you will need to remove
"tenant-id" from your credentials.yaml.

There is more work underway to improve the bootstrap/credentials experience
for Azure.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploying Xenial charms in LXD? Read this

[Andrew Wilkins]

On Thu, Sep 8, 2016 at 9:23 PM Marco Ceppi 
wrote:

> Hey everyone,
>
> An issue was identified late yesterday for those deploying Xenial charms
> to either the LXD provider or LXD instances in a cloud.
>
> The symptoms for this manifest as the LXD machine running is in a running
> state (and has an IP address assigned) but the agent does not start. This
> leaves the workload permanently stuck in a "Waiting for agent to
> initialize" state. This problem originates from a problem in cloud-init and
> systemd, being triggered by an update to the snapd package for xenial.
>

FYI this is not LXD-specific. I've just now seen the same thing happen on
Azure.

Thanks to James Beedy, from the community, for posting this workaround
> which appears to be working consistently for the moment:
>
> juju set-model-config enable-os-refresh-update=false
> juju set-model-config enable-os-upgrade=false
>
>
> This should bypass the section of the cloud-init process that's causing
> the hang at the moment. For those interested in tracking the bugs I believe
> these are the two related ones for this problem:
>
> - https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1621229
> - https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1576692
>
> I'll make sure to post an update when this has been resolved.
>
> Thanks,
> Marco Ceppi
> --
> canonical-juju mailing list
> canonical-j...@lists.canonical.com
> Modify settings or unsubscribe at:
> https://lists.canonical.com/mailman/listinfo/canonical-juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0-beta17 is here!

[Andrew Wilkins]

On Fri, Sep 2, 2016 at 3:26 AM Marco Ceppi 
wrote:

> On Thu, Sep 1, 2016 at 3:10 PM Nicholas Skaggs <
> nicholas.ska...@canonical.com> wrote:
>
>> A new development release of Juju, 2.0-beta17, is here!
>>
>> ## What's new?
>>
>> * add-model now takes region name as an optional positional argument,
>>to be consistent with bootstrap. The --region flag has been removed.
>>
>
> If I read this correctly, I can bootstrap  eastus2 controller on Azure and
> create a model on westus? I was always under the impression that most
> clouds don't have cross region communication.
>

This was possible in beta16, just using a different CLI syntax. When you
create models in different regions, their agents will communicate with the
controller across the public network.

* show-controller now includes the agent version
>> * show-controllers has been removed as an alias to show-controller
>>
>> ## How do I get it?
>>
>> If you are running Ubuntu, you can get it from the juju devel ppa:
>>
>>  sudo add-apt-repository ppa:juju/devel
>>  sudo apt update; sudo apt install juju-2.0
>>
>> Or install it from the snap store
>>
>> snap install juju --beta --devmode
>>
>> Windows, Centos, and OS X users can get a corresponding installer at:
>>
>>  https://launchpad.net/juju/+milestone/2.0-beta17
>>
>>
>> ## Feedback Appreciated!
>>
>> We encourage everyone to subscribe the mailing list at
>> juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
>> hear
>> your feedback and usage of juju.
>>
>>
>> ## Anything else?
>>
>> You can read more information about what's in this release by viewing the
>> release notes here:
>>
>> https://jujucharms.com/docs/devel/temp-release-notes
>>
>>
>>
>> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju 2.0-beta16 is here!

[Andrew Wilkins]

On Fri, Aug 26, 2016 at 4:05 AM Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> A new development release of Juju, 2.0-beta16, is here!
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get it from the juju devel ppa:
>
> sudo add-apt-repository ppa:juju/devel
> sudo apt update; sudo apt install juju-2.0
>
> Or install it from the snap store
>
> snap install juju --beta --devmode
>
> Windows, Centos, and OS X users can get a corresponding installer at:
>
> https://launchpad.net/juju/+milestone/2.0-beta16
>
> ## What's new?
>
> This release fixed 61 bugs and added some new and expanded features. Some
> of the notable changes include:
>
> * Juju rejects LXD 2.1 https://bugs.launchpad.net/bugs/1614559
> * debug-log usability changes
>  - only tails by default when running in a terminal
> --no-tail can be used to not tail from a terminal
> --tail can be used for force tailing when not on a terminal
>  - time output now defaults to local time (--utc flag added to show times
> in utc)
>  - filename and line number no longer shown by default (--location flag
> added to include location in the output)
>  - dates no longer shown by default (--date flag added to include dates in
> output)
> --ms flag added to show timestamps to millisecond precision
>  - severity levels and location now shown in color in the terminal
> --color option to force ansi color codes to pass to 'less -R'
> * controllers models, and users commands now show current controller and
> model respectively using color as well as the asterix
> * removal of smart formatter for CLI commands. Where 'smart' used to be
> the default, now it is 'yaml'.
> * controllers, models, and users commands now print the access level users
> have against each model/controller
> * juju whoami command prints the current controller/model/logged in user
> details
> * fix for LXD image aliases so that the images auto update (when
> bootstrapping a new LXD cloud, images will be downloaded again the first
> time, even if existing ones exist)
> * Expanded controller and model permissions.
>
> Also, juju-2 has moved on launchpad to launchpad.net/juju.
> launchpad.net/juju-core will continue to be utilized for juju-1
> milestones and bug tracking.
>
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> juju@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> ## Anything else?
>

There is something else I had meant to email the list about yesterday, but
slipped my mind. The manual provider's "bootstrap-user" model config
attribute has been removed. Instead, you can now do:

juju bootstrap controller-name manual/user@host

And in your clouds.yaml, you can include "user@" in the endpoint for
manual-type clouds.

Cheers,
Andrew

You can read more information about what's in this release by viewing the
> release notes here:
>
> https://jujucharms.com/docs/devel/temp-release-notes
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: DestroyModel, ModelInfo API deprecation

[Andrew Wilkins]

On Mon, Aug 15, 2016 at 2:13 PM Andrew Wilkins 
wrote:

> Hi,
>
> We're making a handful of changes around model- and cloud-related APIs.
> Some of these will be broken in beta16, and some will be deprecated then
> and broken directly after.
>
> The first change is to ModelManager.DestroyModel. This method is now
> deprecated, and replaced with the pluralised ModelManger.DestroyModels,
> which takes a set of model tags. The old method will be removed after
> beta16 is out.
>
> The second change is to Client.ModelInfo. This was superseded a while ago
> by ModelManager.ModelInfo, which takes model tags. The Client.ModelInfo
> method will be removed after beta16 is out.
>
> There's a couple of other changes in the works:
>  - Cloud.CloudDefaults will be renamed to DefaultCloud, and just return
> the tag of a cloud
>

This has now been done as described. You can continue

 - Cloud.Credentials will be updated or replaced to avoid exposing
> credentials to the client
>

I will be updating the existing API to return new credential tags. Since
this is a new API that nobody should yet be using, I'll save the list from
more emails about it.

There will be one more small change, which is to the CloudCredential field
in the ModelManager.CreateModel parameters. If you're not filling in the
field (most likely), you don't need to do anything. If you are, then let me
know and I'll send you more details when they're finalised.

Cheers,
Andrew

I will reply to this thread when the details of these two have been
> finalised.
>
> Cheers,
> Andrew
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

DestroyModel, ModelInfo API deprecation

[Andrew Wilkins]

Hi,

We're making a handful of changes around model- and cloud-related APIs.
Some of these will be broken in beta16, and some will be deprecated then
and broken directly after.

The first change is to ModelManager.DestroyModel. This method is now
deprecated, and replaced with the pluralised ModelManger.DestroyModels,
which takes a set of model tags. The old method will be removed after
beta16 is out.

The second change is to Client.ModelInfo. This was superseded a while ago
by ModelManager.ModelInfo, which takes model tags. The Client.ModelInfo
method will be removed after beta16 is out.

There's a couple of other changes in the works:
 - Cloud.CloudDefaults will be renamed to DefaultCloud, and just return the
tag of a cloud
 - Cloud.Credentials will be updated or replaced to avoid exposing
credentials to the client
I will reply to this thread when the details of these two have been
finalised.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Upcoming CLI change for beta15

[Andrew Wilkins]

Hi folks,

We've just landed a change that will be part of beta15 which changes how
you refer to models owned by other users.

Model names may be reused by different users, e.g. alex and billie can each
have a model called "foo". Until beta15, there is no way for either alex or
billie to refer to each other's foo after being granted access.

As of beta15, you can now refer to others' models with the syntax
"owner/model". Just saying "foo" is short-hand for foo within the logged-in
user's namespace. e.g. If I'm alex, I can get the status of billie's model
foo with "juju status -m billie/foo".

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: "juju attach"

[Andrew Wilkins]

On Sun, Jun 19, 2016 at 1:51 AM Mark Shuttleworth  wrote:

> On 18/06/16 16:45, Marco Ceppi wrote:
> >
> > Why not just "add" which is already pretty well used. Throughout the
> > Juju CLI.
> >
>
> Well, I think the context here is more attach-a-disk. I really like
> Roger's suggestion of 'mount', it immediately brings all the right
> elements into focus, and it's only one syllable.
>

I concur that add is not really appropriate here, and that mount makes a
lot of sense for storage (thanks for the suggestion, Roger). For me,
"attach" does not have similar connotations re resources, but at least
there's no looming danger of conflict with storage. I can't think of a
better single word, either.

We've got hooks called "storage-attached", and "storage-detaching", which
are in use by existing charms, and baked into charm helpers and probably
elsewhere. I don't think we can/should change these, or we'll have charms
that work with 2.0 but not 1.25, and vice versa. I think we should change
the statuses though, to keep the user-visible parts aligned.

Cheers,
Andrew


> Mark
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

"juju attach"

[Andrew Wilkins]

Hi folks,

A couple of days ago I started looking at charming TitanDB. I was looking
at using resources to store the TitanDB distribution, and while looking at
the docs [0] I found a rather surprisingly named command: "juju attach".

The verb "attach" by itself tells me that, presumably, it will attach
something to something else. It doesn't tell me what. And because it's
non-specific, it either rules out the possibility of multiple unrelated
attach-type commands.

We always intended to give the user a means of attaching floating storage
to a unit/machine. i.e. I should be able to detach and reattach storage to
units in a model, so long as the storage provider supports it. I think the
commands would naturally be called "attach-storage" and "detach-storage".

Can we rename attach to attach-resource? Note that there's also "charm
attach". That may benefit from a similar rename too, at least to be
consistent.

Cheers,
Andrew

[0] https://jujucharms.com/docs/devel/developer-resources
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju: how to get Admin password for windows

[Andrew Wilkins]

On Tue, Jun 14, 2016 at 11:45 PM Геннадий Дубина 
wrote:

> Hi everybody,
>
> We are using juju(v.2.0) to deploy windows machine to openstack(nova)
> We use windows 2012 r2 image from cloudbase.
>
> Machine was created successfully.
> but i don't know how to get Admin user password.
>
> i have found one option: "nova get-password 
> "
> but it doesn't work in juju case. seems it doesn't provide private key for
> this machine.
> "key name" field is "None" for this machine on openstack details page.
>
> also "juju ssh " doesn't work for window machine too
>
> so how to get password for this machine? we need to get RDP.
>

You should be able to do something like:
juju run --machine  "net user JujuAdministrator "

Thanks,
> --
> Gennadiy Dubina
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Model config

[Andrew Wilkins]

On Wed, Jun 8, 2016 at 9:01 PM Mark Shuttleworth  wrote:

>
>  juju set-model-defaults
>

I was mostly wondering whether we should have model defaults, or things
that that we'd set at a common level *without* the ability to set on a
per-model basis to keep things compartmentalised. Once
cloud/region/endpoint and credential attributes are separated from model
config, there aren't *that* many things that make sense to have common
across models.

Anyway, based on Nicolas's response and other discussions the dev team has
had internally, we'll go ahead with defaults with the ability to override.

Thanks,
Andrew


>  juju set-model-config
>  juju set-controller-config
>
> Have we a strong preference for get/set names, or could we just use
> "model-config" and "model-defaults" as read/write commands?
>
>
> Mark
>
>
> On 08/06/16 18:41, Andrew Wilkins wrote:
>
> Hi folks,
>
> We're in the midst of making some changes to model configuration in Juju
> 2.0, separating out things that are not model specific from those that are. 
> For
> many things this is very clear-cut, and for other things not so much.
>
> For example, api-port and state-port are controller-specific, so we'll be
> moving them from model config to a new controller config collection. The
> end goal is that you'll no longer see those when you type "juju
> get-model-config" (there will be a separate command to get controller
> attributes such as these), though we're not quite there yet.
>
> We also think there are some attributes that people will want to set
> across all models, but are not necessarily related to the *controller*. For
> example, http-proxy, apt-http-proxy, and their siblings. I expect that if
> anyone is setting these particular attributes, they are doing so for *all*
> models, as they're operating within a private cloud with limited network
> access.
>
> Does anyone have a real, uncontrived use-case for configuring proxy
> settings on a per-model basis?
>
> Cheers,
> Andrew
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Model config

[Andrew Wilkins]

Hi folks,

We're in the midst of making some changes to model configuration in Juju
2.0, separating out things that are not model specific from those that are. For
many things this is very clear-cut, and for other things not so much.

For example, api-port and state-port are controller-specific, so we'll be
moving them from model config to a new controller config collection. The
end goal is that you'll no longer see those when you type "juju
get-model-config" (there will be a separate command to get controller
attributes such as these), though we're not quite there yet.

We also think there are some attributes that people will want to set across
all models, but are not necessarily related to the *controller*. For
example, http-proxy, apt-http-proxy, and their siblings. I expect that if
anyone is setting these particular attributes, they are doing so for *all*
models, as they're operating within a private cloud with limited network
access.

Does anyone have a real, uncontrived use-case for configuring proxy
settings on a per-model basis?

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju2: format of clouds.yaml for juju add-cloud

[Andrew Wilkins]

On Thu, Apr 21, 2016 at 2:44 AM Andreas Hasenack 
wrote:

> Hi,
>
> I was trying to add another "cloud" so that I could have multiple MAAS
> servers available to bootstrap on, without having to type the MAAS IP
> everytime in the bootstrap command line, and pass --credential.
>
> Some reading lead me to juju add-cloud, but the documentation only has
> examples for openstack clouds, like:
>
> clouds:
>   :
> type: 
> regions:
>   :
> endpoint: 
> auth-types: <[access-key, oauth, userpass]>
>
>
> That does not translate immediately to a MAAS configuration. I asked for
> help on IRC and mgz provided me with this syntax:
>
> clouds:
>   some-name:
> type: maas
> auth-types: [oauth1]
> endpoint: 'http:///MAAS/'
>
>
> Are there other options that could be used here, specific to the "maas"
> type? What about other cloud types, what changes in this template?
>

Everything that you can use is used here:
http://streams.canonical.com/juju/public-clouds.syaml. So the things in
there of note are "storage-endpoint" and "regions".

The "storage-endpoint" field is for clouds that have separate storage API
endpoints. Most clouds only have the one API endpoint, or you can derive
the storage endpoint from the compute one.

The "region" field contains a mapping from region names (e.g. "us-east-1")
to region-specific endpoint and storage-endpoint values.

We intend to add support for interactively adding clouds, similar to what's
been done for credentials, but I don't know when that will happen.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layers & Windows

[Andrew Wilkins]

On Sun, Apr 17, 2016 at 12:17 AM Marco Ceppi 
wrote:

> If it's acceptable to do so, I'll propose changes to charmhelpers and
>> charms.reactive at some point. It would be nice to be able to have a core
>> set of Python helpers that work on all platforms.
>>
>
> I think instead it'd be better to break some of the charm
> helpers.core.hookenv methods to a simpler, streamlined, charms.juju or
> charms.hooktools where it is _just_ the juju hook-tools and nothing more.
> It's something we've talked about these last few months in ecosystems/juju
> list but haven't quite had the time to flesh out.
>

This SGTM as long as what's split out is enough for charms.reactive. There
should be no false impressions of full compatibility then, but enough to
provide a nice experience, and familiarity for those charming software for
other operating systems.

So what I would imagine is:
 - a core set of platform-independent helpers, say charms.juju
(charms.core?)
 - charms.reactive, which depends on charms.juju/core/whatever, also
platform-independent
 - the "basic" layer, which knows how to bootstrap the above on Ubuntu,
CentOS, and Windows
 - all the rest of the charmhelpers in separate package(s), which may be
platform-specific

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layers & Windows

[Andrew Wilkins]

On Tue, Apr 5, 2016 at 7:30 AM Andrew Wilkins 
wrote:

> On Mon, Apr 4, 2016 at 10:42 PM Marco Ceppi 
> wrote:
>
>> There are two things that need to be done. The first, we need the
>> reactive framework to be ported to powershell - that way we can have charms
>> written in powershell and compiled as such. I know the cloud base folks
>> poked at that a bit in Gent during the Summit but I haven't heard much from
>> there.
>>
>> The second, is two base layers. The first is a powershell base layer so
>> you get the awesome powerhshell helpers cloudbase has created (like the
>> python charm helpers). That way native power shell layers can be written.
>> The second is to create a python-windows base layer, this would be the
>> basic layer and then the necessary methods to install Python on the windows
>> machine so that python layers work properly.
>>
>> Some of this we can pilot ourselves, (mostly the python-windows layer) -
>> some of the team is sprinting so I'll add that as a stretch goal. The
>> powershell native features we'll need help and I admit I've done a terrible
>> job keeping up with the cloudbase folks who have been invaluable as a
>> windows + juju resource thus far.
>>
>
> Thanks, Marco. FWIW, I had imagined an MVP just as Stuart described: add
> the Windows bootstrap scripts (install.ps1|bat|cmd, etc.), which should
> just need to install Python and then defer to the reactive framework. Going
> full Powershell support sounds ideal, but not what I'm after.
>

Brief update: I managed to get a Hello World reactive charm running on a
Windows VM in Azure.

My charm:
 - includes the Python 3.5.1 web installer. It's reasonably small (just
under 1MiB).
 - has a short PowerShell hook script (install.ps1) that installs Python
and PyYAML; and then defers to the standard Python hook (install.py)

To enable private cloud deployments, it would probably make more sense for
the charm to require Python as a resource. I just did what I did for
expedience.

I had to make a handful of changes to the basic layer, charm-helpers, and
charms.reactive.
In the basic layer, there are some Ubuntu assumptions that I had to remove:
it wants to apt-get install stuff. Also, I changed it to use "python -m
pip", rather than the pip command directly, which I didn't have available.

I had to make three classes of changes to charm-helpers and charms.reactive:
 - refer to hook tools as (e.g.) status-set.exe, rather than status-set
 - don't require unix-specific Python modules, like "pwd" and "grp"
 - run Python hooks with python(.exe), rather than assuming
shebang/executable

If it's acceptable to do so, I'll propose changes to charmhelpers and
charms.reactive at some point. It would be nice to be able to have a core
set of Python helpers that work on all platforms.

And just to be clear: I'm not suggesting that all all of charmhelpers
should be OS neutral; but at least the core bits for interacting with Juju,
and for writing reactive charms.

Cheers,
Andrew

Cheers,
> Andrew
>
>
>> Marco
>>
>> On Mon, Apr 4, 2016 at 7:46 AM Rick Harding 
>> wrote:
>>
>>> I know that Gabriel and some of the CloudBase folks seemed interested in
>>> layers and possibly some tooling with powershell. I'm not sure how far that
>>> went but I thought they were experimenting during the charmer's summit.
>>> That would help with a charm build on windows, but not for some common code
>>> between both operating systems.
>>>
>>> An interesting thing is how much setup and how ootb the Ubuntu on
>>> Windows needs. If it's working out of the box, it might be an interesting
>>> move for us and our tools that Windows users could get a Linux experience.
>>> I guess that it won't be ideal though as I'm not sure what the server side
>>> plans around that work is.
>>>
>>> On Mon, Apr 4, 2016 at 3:18 AM Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> I would like to write a charm that should be mostly identical on
>>>> Windows and Linux, so I think it would make sense to have common code in
>>>> the form of a layer.
>>>>
>>>> Is anyone working on getting "charm build", layers, and friends to work
>>>> with Windows workloads? If not, I may look into it myself.
>>>>
>>>> Cheers,
>>>> Andrew
>>>> --
>>>> Juju mailing list
>>>> Juju@lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Model statuses

[Andrew Wilkins]

On Wed, Apr 13, 2016 at 7:43 PM Mark Shuttleworth  wrote:

>
> The guidance is that we want it to be VERY clear to people, when someone
> quotes just a status, what they are talking about. There is a very
> different situation in progress when a unit state is being described
> than the state of the whole application. Imagine a telephone
> conversation between two stressed people; you want the word they use,
> even without much context, to tell as much as possible to the other
> person about what they are dealing with.
>
> In this case, I don't think there is as much risk of confusion between
> the state of the model and the state of the application, as there is
> between app and unit. For that reason, I think it's "OK" but not great
> to use the same terms for model and application.
>

Thanks for the feedback. I think I see where this is coming from now, with
juju/agent vs. workload status. I'll go ahead with what I've proposed for
2.0.0rc1 (or whatever we're calling it). I doubt there will be any
confusion, but we'll have some time to test it out and rework it as
necessary.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Model statuses

[Andrew Wilkins]

On Wed, Apr 13, 2016 at 8:46 AM Pete Vander Giessen 
wrote:

> > - would you find it helpful to have common* statuses?
> > - or, would you find it more helpful to have statuses unique to each
> entity type?
>
> I'm still very much a beginner when it comes to developing charms, but
> from my perspective, it would be most useful to have common statuses, so
> that knowledge gained while working with one entity could be applied to
> others.
>
> Of course, there's a trap: "destroying" might end up meaning very
> different things for different entities, depending on how they get torn
> down, what remnants they leave, and what tools can be applied to them when
> they, say, get stuck and hang while being destroyed.
>

This is a very legitimate concern, and something I think we should avoid. I
agree with Mark, it would be a mistake to use the same status if it means
something different for the different entities. I don't think that's the
case here though.

Thanks for the feedback.

Cheers,
Andrew

I think that I'd still prefer simplicity, even if I occasionally bump my
> shins on the sharp edges that the simplicity masks. Others with more
> knowledge of the system internals might have different opinions, though :-)
>
> ~ PeteVG
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Model statuses

[Andrew Wilkins]

Hi,

I'm working on a fix for a bug, where we list dying/dead models in the
output of "juju list-models". While working on this, it became clear to me
that we need a way to convey the status of models to users: whether they're
available for use, being destroyed, or archived for post-mortem analysis.
We would hide the last of these by default, but show the former two and
provide the status as feedback to the user.

My intention was to standardise on some of the existing statuses: "active"
(initial state of a model; meaning it is available for use) and
"destroying" (the contents of the model are being destroyed). There would
also be a new status, "archived", which we'll set when a model has no more
external resources remaining, and its database entries exist only for
post-mortem analysis.

In some off-list conversations, it has been pointed out that we have
(nearly?) non-overlapping statuses for entities in Juju, and that we might
want to preserve this. On the other hand, some of the statuses we use have
little to do with the entities they're assigned to, and a lot to do with
the generic action being used (e.g. "destroying" relates to the action
"destroy", not so much to storage). So I thought I'd put it to the users:
 - would you find it helpful to have common* statuses?
 - or, would you find it more helpful to have statuses unique to each
entity type?

* Bear in mind that we wouldn't be changing the existing statuses now; this
is just about models for now, and new entities going forwards.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Storage

[Andrew Wilkins]

On Tue, Apr 5, 2016 at 10:03 PM Bruno Ranieri  wrote:

> Hi,
>

Hi Bruno,

I am working on charms for the Quobyte Storage System. These charms make
> use of the Juju Storage support,
> but unfortunately juju storage does not behave as expected:
>
> In my charms block-type storage is defined (metadata.yaml):
>
>> [...]
>> storage:
>>   registry-storage:
>> type: block
>> description: registry storage
>> minimum-size: 10G
>> multiple:
>>   range: '1'
>>
>
> When I deploy this charm to ec2 I assume that juju will create an
> ebs-volume [1].
> What it does instead is creating a loop-device?
>

The command line arguments for storage a little bit (too?) subtle. If you
don't specify any constraints for a store, then you'll get "loop" for
block-type, and "rootfs" for filesystem-type stores.

If you want to get the provider's default, you need to specify at least one
constraint for the store. For example, say you want an EBS volume of 10G.
You would deploy with "--storage registry-storage=10G". For the ec2
provider, this will allocate an EBS volume of 10GiB.

After 'juju switch amazon' and 'juju bootstrap' [2] my storage pool is
> initialized to
>
>> ubuntu@bruno:~$ juju storage pool list
>> ebs-ssd:
>>   provider: ebs
>>   attrs:
>> volume-type: ssd
>>
>
>
> When deploying this charm
>
>> ubuntu@bruno:~$ juju deploy --repository=. local:quobyte-registry
>> Added charm "local:trusty/quobyte-registry-1" to the environment.
>
>
Try one of the following:
(1) juju deploy --repository=. local:quobyte-registry --storage
registry-storage=10G
(2) juju deploy --repository=. local:quobyte-registry --storage
registry-storage=ebs
(3) juju deploy --repository=. local:quobyte-registry --storage
registry-storage=ebs-ssd

(1) will allocate the provider's native volume type (if the provider has
one; otherwise loop), of at least 10GiB
(2) will allocate an EBS magnetic volume with the store's minimum size
(3) will allocate an EBS SSD volume with the store's minimum size


> already the agent deployment fails with:
>
>> $ juju debug-log --replay
>> [...]
>> machine-1[14401]: 2016-04-05 12:06:01 ERROR juju.worker runner.go:223
>> exited "deployer": cannot create agent
>> config dir "/var/lib/juju/agents/unit-quobyte-registry-0": mkdir
>> /var/lib/juju/agents/unit-quobyte-registry-0: no space left on device
>>
>
> Debugging into the deployed machine (and ec2-console) shows that no
> ebs-volume was created but an image on the local disk:
>
>> $ juju ssh 1
>> ubuntu@ip-x.y.z.a:~$ df -h
>> Filesystem  Size  Used Avail Use% Mounted on
>> udev1.9G   12K  1.9G   1% /dev
>> tmpfs   375M  204K  375M   1% /run
>> /dev/disk/by-label/cloudimg-rootfs  7.8G  7.8G 0 100% /
>> none4.0K 0  4.0K   0% /sys/fs/cgroup
>> none5.0M 0  5.0M   0% /run/lock
>> none1.9G 0  1.9G   0% /run/shm
>> none100M 0  100M   0% /run/user
>> /dev/xvdb   3.9G  8.1M  3.7G   1% /mnt
>>
>
>
> I'm aware that it is possible to control the storage usage during
> service-deploment on the command-line
> using '--storage registry-storage=ebs', but I do not think that this is
> the correct solution? Currently I am working on tests
> for the 'juju test' -runner. There I cannot hard-wire storage to ebs,
> since these tests should be independent form a specific provider.
>

Right, so as above, you'll just need to specify the size and let Juju take
care of determining the appropriate storage provider.

Let us know how you get on.

Cheers,
Andrew

Any ideas what is possible wrong I my setup?
>
> Thanks and Regards,
>  Bruno Ranieri
>
>
> [1] 'If pool is not specified, then Juju will select the default storage
> provider for the current environment
>   (e.g. cinder for openstack, ebs for ec2, loop for local)'
> https://jujucharms.com/docs/1.25/storage
>
> [2] $ cat ~/.juju/environments.yaml
>
>> default: local
>> environments:
>>   local:
>> type: local
>> admin-secret: xyz
>> lxc-clone: true
>> allow-lxc-loop-mounts: true
>> default-series: trusty
>>
>>   amazon:
>>type: ec2
>>region: eu-central-1
>>access-key: xyz
>>secret-key: xyz
>>admin-secret: xyz
>>default-series: trusty
>>
>>
>
> --
> Quobyte GmbH
> Hardenbergplatz 2 - 10623 Berlin - Germany
> +49-30-814 591 800 - www.quobyte.com
> Amtsgericht Berlin-Charlottenburg, HRB 149012B
> management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layers & Windows

[Andrew Wilkins]

On Mon, Apr 4, 2016 at 10:42 PM Marco Ceppi 
wrote:

> There are two things that need to be done. The first, we need the reactive
> framework to be ported to powershell - that way we can have charms written
> in powershell and compiled as such. I know the cloud base folks poked at
> that a bit in Gent during the Summit but I haven't heard much from there.
>
> The second, is two base layers. The first is a powershell base layer so
> you get the awesome powerhshell helpers cloudbase has created (like the
> python charm helpers). That way native power shell layers can be written.
> The second is to create a python-windows base layer, this would be the
> basic layer and then the necessary methods to install Python on the windows
> machine so that python layers work properly.
>
> Some of this we can pilot ourselves, (mostly the python-windows layer) -
> some of the team is sprinting so I'll add that as a stretch goal. The
> powershell native features we'll need help and I admit I've done a terrible
> job keeping up with the cloudbase folks who have been invaluable as a
> windows + juju resource thus far.
>

Thanks, Marco. FWIW, I had imagined an MVP just as Stuart described: add
the Windows bootstrap scripts (install.ps1|bat|cmd, etc.), which should
just need to install Python and then defer to the reactive framework. Going
full Powershell support sounds ideal, but not what I'm after.

Cheers,
Andrew


> Marco
>
> On Mon, Apr 4, 2016 at 7:46 AM Rick Harding 
> wrote:
>
>> I know that Gabriel and some of the CloudBase folks seemed interested in
>> layers and possibly some tooling with powershell. I'm not sure how far that
>> went but I thought they were experimenting during the charmer's summit.
>> That would help with a charm build on windows, but not for some common code
>> between both operating systems.
>>
>> An interesting thing is how much setup and how ootb the Ubuntu on Windows
>> needs. If it's working out of the box, it might be an interesting move for
>> us and our tools that Windows users could get a Linux experience. I guess
>> that it won't be ideal though as I'm not sure what the server side plans
>> around that work is.
>>
>> On Mon, Apr 4, 2016 at 3:18 AM Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> Hi,
>>>
>>> I would like to write a charm that should be mostly identical on Windows
>>> and Linux, so I think it would make sense to have common code in the form
>>> of a layer.
>>>
>>> Is anyone working on getting "charm build", layers, and friends to work
>>> with Windows workloads? If not, I may look into it myself.
>>>
>>> Cheers,
>>> Andrew
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Charm layers & Windows

[Andrew Wilkins]

Hi,

I would like to write a charm that should be mostly identical on Windows
and Linux, so I think it would make sense to have common code in the form
of a layer.

Is anyone working on getting "charm build", layers, and friends to work
with Windows workloads? If not, I may look into it myself.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Storage documentation (Was "Re: Planning for Juju 2.2 (16.10 timeframe)")

[Andrew Wilkins]

Just changed subject so we don't derail the 2.2 discussion.

On Tue, Mar 29, 2016 at 6:27 PM Jacek Nykis 
wrote:

> On 19/03/16 03:20, Andrew Wilkins wrote:
> > It seems like the issues you've noted below are all documentation issues,
> > rather than limitations in the implementation. Please correct me if I'm
> > wrong.
> >
> >
> >> If we come up with sensible defaults for different providers we could
> >> make end users' experience even better by making --storage-type optional
> >>
> >
> > Storage type is already optional. If you omit it, you'll get the provider
> > default. e.g. for AWS, that's EBS magnetic disks.
>
> Good to hear, it's a simple documentation fix then.
>
> >> * it would be good to have ability to use single storage stanza in
> >> metadata.yaml that supports all types of storage. They way it is done
> >> now [0] means I can't test block storage hooks in my local dev
> >> environment. It also forces end users to look for storage labels that
> >> are supported
> >>
> >> [0] http://paste.ubuntu.com./15414289/
> >
> >
> > Not quite sure what you mean here. If you have a "filesystem" type, you
> can
> > use any storage provider that supports natively creating filesystems
> (e.g.
> > "tmpfs") or block devices (e.g. "ebs"). If you specify the latter, Juju
> > will manage the filesystem on the block device.
>
> OK this makes sense. Documentation is really confusing on this subject.
> I assumed that "location" was a pre existing local path for juju to use.
>

Assuming you're looking at the stable docs, take a look at devel and see if
it helps at all. They were restructured and reworded because they were
found to be a be confusing (first cut never really got translated from
developerese into English). You'll find that here:
https://jujucharms.com/docs/devel/charms-storage
and here:
https://jujucharms.com/docs/devel/developer-storage

If juju will manage filesystem what's the point in having "location"
> option? Paths can be easily autogenerated and that would remove need to
> hardcode paths in metadata.yaml
>

It's only there in case your charmed application expects to find things in
a specific location. Having a predefined location makes charming storage a
bit easier in those cases. In general, though, you shouldn't need to
specify a location. In fact, it's harmful if not done correctly, because
then you're prone to collisions with other charms.


> > * the way things are now hooks are responsible for creating filesystem
> >> on block devices. I feel that as a charmer I shouldn't need to know that
> >> much about storage internals. I would like to ask juju and get
> >> preconfigured path back. Whether it's formatted and mounted block
> >> device, GlusterFS or local filesystem it should not matter
> >
> >
> > That is exactly what it does, so again, I think this is an issue of
> > documentation clarity. If you're using the "filesystem" type, Juju will
> > create the filesystem; if you use "block", it won't.
>
> I am glad to hear it's just docs. I'll be happy to review them when
> fixed just let me know when it's done
>

Great, I'll try to keep that in mind. Take a look at the devel docs some
time and see if you still find them confusing.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Reserved actions

[Andrew Wilkins]

On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi 
wrote:

> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> Hi,
>>
>> There's a code review in progress (http://reviews.vapour.ws/r/4286/)
>> that will introduce a predefined action, "juju-run", which is part of the
>> replacement for the current SSH-based juju-run.
>>
>
> This is interesting. What's the semantics for this? How does juju-run
> action work for machine level items?
>

>From the end-user perspective, juju run should work just the same as
before. There will be a machine-level worker in Juju that will initially
handle only juju-run actions. It's not expected that you'll use juju-run
actions directly, but I don't think there's anything stopping you.

This means that "juju-run" will no longer be a valid action name for use in
>> a charm. This may come up again in the future, so we think it would be
>> prudent to reserve a namespace for additional predefined actions. The most
>> straightforward thing to do would be to reserve the "juju-" prefix, like we
>> do for relations.
>>
>
> This seems fine, we'll add "juju-run" as a blacklist in charm proof.
>

If everyone's OK with reserving the "juju-" prefix, I think it would be
better to blacklist the whole namespace. Nip it in the bud.


> Any objections? Does anyone have any actions using the "juju-" prefix
>> already?
>>
>
> I don't believe so, I'l do a quick search in the charm store though to
> verify
>
>
>> Cheers,
>> Andrew
>>
> --
>> Juju-dev mailing list
>> juju-...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reserved actions

[Andrew Wilkins]

Hi,

There's a code review in progress (http://reviews.vapour.ws/r/4286/) that
will introduce a predefined action, "juju-run", which is part of the
replacement for the current SSH-based juju-run.

This means that "juju-run" will no longer be a valid action name for use in
a charm. This may come up again in the future, so we think it would be
prudent to reserve a namespace for additional predefined actions. The most
straightforward thing to do would be to reserve the "juju-" prefix, like we
do for relations.

Any objections? Does anyone have any actions using the "juju-" prefix
already?

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Planning for Juju 2.2 (16.10 timeframe)

[Andrew Wilkins]

On Sat, Mar 19, 2016 at 12:53 AM Jacek Nykis 
wrote:

> On 08/03/16 23:51, Mark Shuttleworth wrote:
> > *Storage*
> >
> >  * shared filesystems (NFS, GlusterFS, CephFS, LXD bind-mounts)
> >  * object storage abstraction (probably just mapping to S3-compatible
> APIS)
> >
> > I'm interested in feedback on the operations aspects of storage. For
> > example, whether it would be helpful to provide lifecycle management for
> > storage being re-assigned (e.g. launch a new database application but
> > reuse block devices previously bound to an old database  instance).
> > Also, I think the intersection of storage modelling and MAAS hasn't
> > really been explored, and since we see a lot of interest in the use of
> > charms to deploy software-defined storage solutions, this probably will
> > need thinking and work.
>
> Hi Mark,
>
> I took juju storage for a spin a few weeks ago. It is a great idea and
> I'm sure it will simplify our models (no more need for
> block-storage-broker and storage charms). It will also improve security
> because block-storage-broker needs nova credentials to work
>
> I only played with storage briefly but I hope my feedback and ideas will
> be useful
>
> * IMO it would be incredibly useful to have storage lifecycle
> management. Deploying a new database using pre-existing block device you
> mentioned would certainly be nice. Another scenario could be users who
> deploy to local disk and decide to migrate to block storage later
> without redeploying and manual data migration
>
>

> One day we may even be able to connect storage with actions. I'm
> thinking "storage snapshot" action followed by juju deploy to create up
> to date database clone for testing/staging/dev
>
> * I found documentation confusing. It's difficult for me to say exactly
> what is wrong but I had to read it a few times before things became
> clear. I raised some specific points on github:
> https://github.com/juju/docs/issues/889
>
> * cli for storage is not as nice as other juju commands. For example we
> have the in the docs:
>
> juju deploy cs:~axwalk/postgresql --storage data=ebs-ssd,10G pg-ssd
>
> I suspect most charms will use single storage device so it may be
> possible to optimize for that use case. For example we could have:
>
> juju deploy cs:~axwalk/postgresql --storage-type=ebs-ssd --storage-size=10G
>

It seems like the issues you've noted below are all documentation issues,
rather than limitations in the implementation. Please correct me if I'm
wrong.


> If we come up with sensible defaults for different providers we could
> make end users' experience even better by making --storage-type optional
>

Storage type is already optional. If you omit it, you'll get the provider
default. e.g. for AWS, that's EBS magnetic disks.


> * it would be good to have ability to use single storage stanza in
> metadata.yaml that supports all types of storage. They way it is done
> now [0] means I can't test block storage hooks in my local dev
> environment. It also forces end users to look for storage labels that
> are supported
>
> [0] http://paste.ubuntu.com./15414289/


Not quite sure what you mean here. If you have a "filesystem" type, you can
use any storage provider that supports natively creating filesystems (e.g.
"tmpfs") or block devices (e.g. "ebs"). If you specify the latter, Juju
will manage the filesystem on the block device.

* the way things are now hooks are responsible for creating filesystem
> on block devices. I feel that as a charmer I shouldn't need to know that
> much about storage internals. I would like to ask juju and get
> preconfigured path back. Whether it's formatted and mounted block
> device, GlusterFS or local filesystem it should not matter


That is exactly what it does, so again, I think this is an issue of
documentation clarity. If you're using the "filesystem" type, Juju will
create the filesystem; if you use "block", it won't.

If you could provide more details on what you're doing (off list, I think
would be best), I can try and help. We can then feed back into the docs to
make it clearer.

Cheers,
Andrew

* finally I hit 2 small bugs:
>
> https://bugs.launchpad.net/juju-core/+bug/1539684
> https://bugs.launchpad.net/juju-core/+bug/1546492



>
>
> If anybody is interested in more details just ask, I'm happy to discuss
> or try things out just note that I will be off next week so will most
> likely reply on 29th
>
>
> Regards,
> Jacek
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Logging into the API on Juju 2.0

[Andrew Wilkins]

On Sat, Feb 27, 2016 at 1:10 AM Adam Stokes 
wrote:

> Also, will the API support non admin users to login and query the various
> modelmanager methods they have access to? If so, will this be available by
> GA release?
>
> On Fri, Feb 26, 2016 at 11:45 AM, Adam Stokes 
> wrote:
>
>> Currently, the only way to login to the Juju 2.0 api is to use the Tag of
>> 'user-admin'.
>>
>
You can log in with additional users. With the CLI, you can do:
  - juju add-user bob
  - juju change-user-password bob
  - juju switch-user bob
(or you could use the "register" command to add another controller entry;
you'll still end up with the "bob" user)

However, all the files created by juju during bootstrap (accounts.yaml,
>> models.yaml, controllers.yaml) only mention the admin user as 'admin@local'
>> for the controller.
>>
>
"admin" is equivalent to "admin@local"; the latter form is canonical. What
you're passing over the API is a different form altogether: it is a "tag".
The tag form of a user is: user-[@domain].

So for the "admin@local" user, the tag form is "user-admin@local". You can
also supply just "user-admin", and the "local" is implied.

When will the API login support logging in as the admin user for the
>> specified controller?
>>
>> An example of the request being passed to the api server:
>>
>> {'Type': 'Admin',
>>  'Version': 3,
>>  'Request': 'Login',
>>  'RequestId': 1,
>>  'Params': {'auth-tag': user,
>>'credentials': password}}
>>
>> user = 'user-admin' and not 'admin@local' as seen in the yaml configs.
>>
>
That should be working. Please file a bug if it's not, with steps to
reproduce.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju devel 2.0-beta1 is available for testing

[Andrew Wilkins]

On Sun, Feb 21, 2016 at 2:06 PM Mark Shuttleworth  wrote:

> On 21/02/16 03:57, Andrew Wilkins wrote:
> > The lxd/ format has not been implemented yet. That will come later,
> > along with support for remote lxd, which AFAIK does not exist in the
> > provider.
>
> I'm not sure it will be appropriate to do that way now that we have made
> the assumption of a single credential working in every region of a
> cloud. The foo/bar syntax iirc was for cloud/region and upon reflection
> I don't think we can consider all the different LXD hosts as different
> regions of a common cloud because they will have different identity
> spaces. Subsequent to the design work on bootstrap, we made the
> simplifying decision to treat all regions of a cloud as having the same
> credential. That works for all the big public clouds but it would break
> for a world where LXD is a single cloud of many regions.
>
> Instead, I think we'll need to special-case your OWN lxd as a cloud that
> you have immediate access to, and allow people to define remote hosts as
> explicit lxd clouds. They could, in theory, have a LXD cloud with many
> regions (each host being a region :)) as long as they all can share a
> credential, which I think is straightforward and actually quite exciting
> as a way to enable teams to simulate multi-region deployments.
>

That sounds useful to me. We could consider the remotes registered with
your local lxd as regions. There's one client certificate for the local
lxd, which is uploaded to each registered remote, so you could then:
* lxc remote add foobar https://foo.bar:8443 --accept-certificate
--password=..."
* juju bootstrap lxc/foobar

It does mean that the name and credentials aren't really portable, though.
Also, I think we would still need to enable per-region credentials so we
have somewhere to stick the server certificates.

Damn, this stuff is exciting :)
>
> Mark
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju devel 2.0-beta1 is available for testing

[Andrew Wilkins]

On Sun, Feb 21, 2016 at 7:28 AM Ian Booth  wrote:

> To specify a different LXD host:
>
> $ juju bootstrap mycontroller lxd/
>
> For now, just localhost (the default) has been fully tested and is
> guaranteed to
> work with this beta1.
>

The lxd/ format has not been implemented yet. That will come later,
along with support for remote lxd, which AFAIK does not exist in the
provider.

There's no need to edit any clouds.yaml file for the LXD cloud. It's meant
> to be
> really easy to use!
>
>
> On 21/02/16 09:21, Marco Ceppi wrote:
> > Won't the user be able to create different LXD clouds by specifying a
> > remote LXD host though?
> >
> > On Sun, Feb 21, 2016, 12:19 AM Ian Booth 
> wrote:
> >
> >> The lxd cloud works on Juju 2.0 beta1 out of the box.
> >>
> >> $ juju bootstrap mycontroller lxd
> >>
> >> There is no need to edit any clouds.yaml. It Just Works.
> >>
> >> It seems the confusion comes from not seeing lxd in the output of juju
> >> list-clouds. list-clouds ostensibly shows available public clouds (aws,
> >> azure
> >> etc) and any private clouds (maas, openstack etc) added by the user. The
> >> lxd
> >> cloud is just built-in to Juju. But from a usability perspective, it's
> >> seems we
> >> should include lxd in the output of list-clouds.
> >>
> >> NOTE: the latest lxd 2.0.0 beta3 release recently added to the archives
> >> has an
> >> api change that is not compatible with Juju. You will need to ensure
> that
> >> you're
> >> still using the lxd 2.0.0 beta2 release to test with Juju.
> >>
> >>
> >> On 21/02/16 08:26, Jorge O. Castro wrote:
> >>> Awesome, a nice weekend present!
> >>>
> >>> I updated and LXD is not listed when I `juju list-clouds`. Rick and I
> >>> were guessing that maybe because the machine I am testing on is on
> >>> trusty that we exclude that cloud on purpose. If I was on a xenial
> >>> machine I would assume lxd would be available?
> >>>
> >>> What's an example clouds.yaml look like for a lxd local provider? I
> >>> tried manually adding a lxd cloud via `add-cloud` but I'm unsure of
> >>> what the formatting would look like for a local provider.
> >>>
>  Development releases use the "devel" simple-streams. You must
> configure
>  the `agent-stream` option in your environments.yaml to use the
> matching
>  juju agents.
> >>>
> >>> I am confused, I no longer have an environments.yaml so is this
> >>> leftover from a previous release?
> >>>
> >>> Thanks!
> >>>
> >>
> >> --
> >> Juju mailing list
> >> Juju@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >>
> >
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: EC2 VPC firewall rules

[Andrew Wilkins]

On Thu, Feb 18, 2016 at 6:51 PM John Meinel  wrote:

> Shouldn't we at least be giving a "juju 2.0 cannot operate with a juju 1.X
> API server, please install juju-1.25 if you want to use this system", or
> something along tohse lines. Admin(3).Login is not implemented sounds like
> a poor way for them to discover that.
>

It's *meant* to be providing an informative message, but it looks like it's
not quite working. Relevant code:
https://github.com/juju/juju/blob/master/apiserver/root.go#L267


John
> =:->
>
>
> On Thu, Feb 18, 2016 at 2:49 PM, John Meinel 
> wrote:
>
>> Looks like the changes to Login broke compatibility. We are adding a
>> Login v3, but it looks like the new code will refuse to try to Login to v2.
>> I'm a bit surprised, but it means you'll need to bootstrap again if you
>> want to test it out with current trunk.
>>
>> John
>> =:->
>>
>>
>> On Thu, Feb 18, 2016 at 2:47 PM, Tom Barber 
>> wrote:
>>
>>> Hey Dimiter,
>>>
>>> Thanks for that. As am running trunk I wanted to make sure I was fully
>>> up to date before progressing further. I pulled trunk locally and ran juju
>>> upgrade-juju --upload-tools
>>>
>>> That gives me:
>>>
>>> WARNING no addresses found in space "default"
>>> WARNING using all API addresses (cannot pick by space "default"):
>>> [public:52.30.224.20 local-cloud:172.31.2.38]
>>> WARNING discarding API open error: no such request - method
>>> Admin(3).Login is not implemented (not implemented)
>>> ERROR no such request - method Admin(3).Login is not implemented (not
>>> implemented)
>>>
>>>
>>> I assume the ERROR portion is pretty critical. So here's a slightly off
>>> topic question, which I suspect has a very simple yes/no answer. Can I
>>> either a) force a bootstrapped environment upgrade b) manually upgrade an
>>> environment by passing the error but making the bootstrap node up to date
>>> c) export the existing nodes it manages and import them back into a new
>>> bootstrap node without having to recreate them as well?
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> 
>>> goal, but you can always help by sponsoring the project
>>> )
>>>
>>> On 18 February 2016 at 10:42, Dimiter Naydenov <
>>> dimiter.nayde...@canonical.com> wrote:
>>>
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 18.02.2016 12:01, Tom Barber wrote:
 > Hello folks
 >
 > I'm not sure if my tinkering has broken something, the fact I'm
 > running trunk has broken something or I just don't understand
 > something.
 >
 > Until last week we've been running EC2 classic, but we have now
 > switched to EC2-VPC and have launched a few machines.
 >
 > juju ssh to these machines works fine and I've been configuring
 > them to suit our needs.
 >
 > Then I came to look at external access, `juju expose mysqldb` for
 > example, I would then expect to be able to access it from the
 > outside world, but can't unless go into my VPC settings and open
 > the port in one of the juju security groups, at which point
 > external access works fine.
 >
 > Am I missing something?
 >
 > Thanks
 >
 > Tom
 >
 >
 Hey Tom,

 What you're describing sounds like a bug, as "juju expose "
 should trigger the firewaller worker to open the ports the service has
 declared (with open-ports within the charm) using the security group
 assigned to the host machine for all units of that service.

 Have you changed the "firewall-mode" setting by any chance?
 Can you provide some logs from /var/log/juju/*.log on the bootstrap
 instance (machine 0)?

 Cheers,
 - --
 Dimiter Naydenov 
 Juju Core Sapphire team 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJWxaAXAAoJENzxV2TbLzHwGgEIAIuj0sPzh7S/4jvTQ6aA/dwP
 i7WkSZ586JkNbEFeCBjDavO6oZFOwIAEW+EpGuy1C0O8BJr5Y2YJBMR96pdf3Rj/
 Y6xS4Byt0HrwCWixt7ut6zu7BsT+nv6YFO7fNQvNYLyroufzpqUKaALJp5xwedkJ
 JIx1iyLnAZ4ZC1/0VkoBM/UjbZN7xQIteNvChBCZSSk8RvbqXCKhbXZKuUKMAw5g
 R+D3wIwLEyZHb5SATcSSdE6nidv4A0F2waac1/3lOvFebeOsnapnRKkIDp3Y9v19
 /zDiDLWSJJvMDau8iIzSQ4STK/sLEmA78iRNkfDRWRifv0z1KkY6ppnhaS+jrj4=
 =kPA7
 -END PGP SIGNATURE-

 --
 Juju mailing list
 Juju@lists.ubuntu.com
 Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju

>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mai

Re: filesystem type storage backend

[Andrew Wilkins]

On Sat, Feb 6, 2016 at 2:30 AM Marco Ceppi 
wrote:

> This sounds very promising! Will play around with it a bit more.
>
> On Fri, Feb 5, 2016, 7:16 PM Mark Shuttleworth  wrote:
>
>> On 05/02/16 17:47, Marco Ceppi wrote:
>> > Does this require the operator to add storage at deploy time? Does this
>> > mean our charm should block until storage is added? We really want to be
>> > able to support the /option/ or adding storage by the operator but we're
>> > not sure how this functions. If we use that directory before the
>> operator
>> > attaches storage will it be mounted over or migrated?
>>
>> AIUI:
>>
>>  * you can leave the storage unspecified and it will just write to the
>> directory
>>  * you cannot change the storage pool after deployment
>>
>
Correct on both counts. If you don't specify storage, Juju will just create
"/srv/hdfs" on the root filesystem, and you cannot change this after
deployment.

Furthermore: the charm's install hook will not fire until the storage is
available and attached (which means "-storage-attached" hooks will fire
before "install"). So you know, at charm install time, the storage is
there; no need to block, Juju is doing that for you.

It's worth noting that it is also possible to make make storage optional by
setting the minimum number of storage instances to 0, like so:

storage:
hdfs-data:
type: filesystem
location: /srv/hdfs
multiple:
range: 0-1

If you deploy such a charm without specifying a storage directive, you will
get no storage. If you do want the storage, you either deploy with
--storage, or use "juju storage add" (juju add-storage in 2.0, I believe).
IIRC, if the specified location already exists, and is non-empty, Juju will
refuse to mount the storage over the top.

Cheers,
Andrew

Mark
>>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Does sftp eliminate the need to check sha1sum?

[Andrew Wilkins]

On Thu, Jan 14, 2016 at 3:23 AM José Antonio Rey  wrote:

> I think this is more of a discusion on if you got 'what' you wanted or
> if you got it from 'where' you wanted. Even if you used SFTP, the file
> could've changed, and if it doesn't have a SHA1SUM it could result in
> unexpected charm breakage.
>
> If it were me, I would always implement SHA1SUMS, just to make sure that
> the file is, in fact, what I wanted. It would make it easier to debug
> and fix later down the road.
>

+1

SFTP/SSH will (can?) ensure the integrity during transit, but can't tell
you that the data wasn't tampered with outside of the SFTP transfer
process. Someone could have replaced the file on the file server. The
client needs to know ahead of time what to expect.

On 01/13/2016 02:18 PM, Adam Israel wrote:
> > Matt,
> >
> > For the charm in question, I would think adding the sha1sum check to the
> > process would be sufficient, especially in the scenario that the binary
> > is being self-hosted for the purposes of installing it via the charm.
> >
> > Adam Israel - Software Engineer
> > Canonical Ltd.
> > http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
> >
> >> On Jan 13, 2016, at 2:14 PM, Tom Barber  >> > wrote:
> >>
> >> Yeah but as pointed out earlier,  it verifies where you got it from,
> >> but not what you got.  :)
> >>
> >> On 13 Jan 2016 19:11, "Jay Wren"  >> > wrote:
> >>
> >> StrictHostKeyChecking and shipping the public key of the ssh host
> with
> >> the charm does seem to meet the criteria of verifying the intended
> >> source.
> >>
> >>
> >> On Wed, Jan 13, 2016 at 1:46 PM, Matt Bruzek
> >>  >> > wrote:
> >> > I recently reviewed a charm that is using sftp to download the
> >> binary files
> >> > with a username and password.  The charm does not check the
> >> sha1sum of these
> >> > files.
> >> >
> >> > The Charm Store Policy states:  Must verify that any software
> >> installed or
> >> > utilized is verified as coming from the intended source
> >> >
> >> > https://jujucharms.com/docs/stable/authors-charm-policy
> >> >
> >> > Does using sftp eliminate the need to check the sha1sum of the
> files
> >> > downloaded?
> >> >
> >> > What does the Juju community say to this question?
> >> >
> >> >- Matt Bruzek  >> >
> >> >
> >> > --
> >> > Juju mailing list
> >> > Juju@lists.ubuntu.com 
> >> > Modify settings or unsubscribe at:
> >> > https://lists.ubuntu.com/mailman/listinfo/juju
> >> >
> >>
> >> --
> >> Juju mailing list
> >> Juju@lists.ubuntu.com 
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >>
> >> --
> >> Juju mailing list
> >> Juju@lists.ubuntu.com 
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >
> >
> >
>
>
> --
> José Antonio Rey
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: JNS: Juju Name Server

[Andrew Wilkins]

On Tue, Jan 5, 2016 at 5:00 PM Matthew Williams <
matthew.willi...@canonical.com> wrote:

> That's an awesome idea and tool Andrew thanks for sharing. Any plans for
> turning it into a charm? Would only take moments with the go binary charm
> layer
>
For my needs that would be counter-productive, I specifically want it to
exist outside Juju.

I'm not likely to create a charm it. It would need additional work, too,
because JNS requires the Juju client credentials to exist (though I think
there's a charm layer for things that need that).

Cheers,
Andrew

> Matty
> On 5 Jan 2016 08:13, "Andrew Wilkins" 
> wrote:
>
>> Hi,
>>
>> A little while ago, I found myself wanting to address a service by its
>> Juju name, but outside of Juju. I didn't want to be tied to an IP/host
>> name, because they might change; I didn't want to be tied to any one cloud
>> provider; and I wanted it to work across environments.
>>
>> So I wrote a little DNS server that resolves Juju entity names to IP
>> addresses. It's called "jns", Juju Name Server. You can find it here:
>> https://github.com/axw/jns
>> (go get github.com/axw/jns)
>>
>> Names take one of the following forms:
>> 0.juju# machine 0
>> machine-0-lxc-0.juju # machine 0/lxc/0
>> mysql.juju # IP address of a random unit of the mysql
>> service
>> unit-mysql-0.juju   # IP address of mysql/0
>>
>> In the above forms, the entity is within the current environment. If you
>> want to resolve the address of an entity in another environment, you can
>> precede ".juju" with the name of the environment. e.g.
>> mysql.prod.juju
>> mysql.dev.juju
>> etc.
>>
>> Enjoy.
>>
>> Cheers,
>> Andrew
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

JNS: Juju Name Server

[Andrew Wilkins]

Hi,

A little while ago, I found myself wanting to address a service by its Juju
name, but outside of Juju. I didn't want to be tied to an IP/host name,
because they might change; I didn't want to be tied to any one cloud
provider; and I wanted it to work across environments.

So I wrote a little DNS server that resolves Juju entity names to IP
addresses. It's called "jns", Juju Name Server. You can find it here:
https://github.com/axw/jns
(go get github.com/axw/jns)

Names take one of the following forms:
0.juju# machine 0
machine-0-lxc-0.juju # machine 0/lxc/0
mysql.juju # IP address of a random unit of the mysql
service
unit-mysql-0.juju   # IP address of mysql/0

In the above forms, the entity is within the current environment. If you
want to resolve the address of an entity in another environment, you can
precede ".juju" with the name of the environment. e.g.
mysql.prod.juju
mysql.dev.juju
etc.

Enjoy.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

git charm layers

[Andrew Wilkins]

Hi,

I was recently inspired by Domas's git charm (https://jujucharms.com/git/)
to create a pair of git charm layers and interface. You can find them at:
https://github.com/axw/layer-git-server
https://github.com/axw/layer-git-client
https://github.com/axw/interface-git

layer-git-server manages a git repository for related services. In theory,
each unit of the service should access the same repository (but different
services get different repositories); I haven't actually gone through and
fixed all the bits that make this work though. It shouldn't be too
difficult.

The server has a couple of nice features:
 - if you can authenticate as ubuntu on the server, you can also
authenticate as the service repository users. so on my laptop, I can clone
ssh://@/.git
 - when you push to the server, it will inform the clients by setting the
commit in relation data

I'm not sure when I'll have time to polish the code and make this
production ready. If anyone's keen to take it further, please fork and have
at it.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charms, layers, and Launchpad

[Andrew Wilkins]

On Fri, Dec 18, 2015 at 9:27 AM Cory Johns  wrote:

> Andrew,
>
> It's mentioned at the start of
> https://jujucharms.com/docs/stable/authors-charm-building and there is a
> PR (https://github.com/juju/docs/pull/746) to rework the existing authors
> doc into a developer guide focused on creating charms with layers that will
> bring a lot of this information together that is currently in various
> locations.  Reviews on that are welcome.
>

Thanks, not sure how I missed that.

As for building reactive charms offline, I'm not sure I understand the
> question.  Layer and interface deps are cached under $JUJU_REPOSITORY/deps
> and after the first build the wheelhouse will be in the charm output dir
> and we could potentially prefer them over hitting the index again, but the
> first build as well as any new deps, layer, interface, or wheelhouse, will
> inherently require network access.
>

So I wanted to build charms while on a plane without Internet access. Maybe
I was just doing something wrong, but it wanted network access despite
having fetched/built the dependencies once before.

Obviously we'll need to hit the network on the first build, and that's
totally fine. If pip could be optionally instructed to reuse the existing
wheelhouses, that would be helpful. I'd build the charms once before losing
network, and then continue iterating with the cached dependencies.

Cheers,
Andrew


> On Thu, Dec 17, 2015 at 6:09 PM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Fri, Dec 18, 2015 at 8:58 AM Cory Johns 
>> wrote:
>>
>>> Greetings, all.
>>>
>>> I wanted to suggest a convention for managing layered charms with
>>> Launchpad.
>>>
>>> Until the publish workflow is ready, the "built charm" (i.e., output
>>> from `charm build`) must be checked in to Launchpad in a repo such as:
>>>
>>> lp:~user/charms/trusty/foo/trunk
>>>
>>> The base path and branch are required to be charms/ and /trunk,
>>> respectively, for the charm to be ingested into the store.
>>>
>>> Launchpad isn't really set up to deal with charm layers, but I think we
>>> could settle on a convention of using the branch /layer to denote the
>>> source charm layer for the corresponding /trunk built charm.  The source
>>> layer (under /layer) is what we would like to have submitted to the Review
>>> Queue, and the /trunk branch could be used only for ingestion into the
>>> store.
>>>
>>> Note that interface and base layers would need to have their own
>>> project, since they don't really fit into the charms/series project
>>> structure.  They can also live outside of Launchpad and work just fine as
>>> long as they are registered in http://interfaces.juju.solutions/ (which
>>> can be done by anyone with Launchpad credentials) (eventually, the plan is
>>> for them to be published to the store in a similar way to charms).
>>>
>>> I'd also like to mention our recommendations for developing layered
>>> charms.  Specifically, you should create a base Juju repository directory
>>> (e.g., ~/charms) and subdirectories for "layers", "interfaces" (if you plan
>>> to develop those), and any series directories such as "trusty".  Then, you
>>> should ensure that the following variables are set in your environment:
>>>
>>> JUJU_REPOSITORY=~/charms
>>> LAYER_PATH=$JUJU_REPOSITORY/layers
>>> INTERFACE_PATH=$JUJU_REPOSITORY/interfaces  # optional
>>>
>>> Many layer and interface repos are prefixed with "layer-" or
>>> "interface-" to indicate their role (e.g.,
>>> https://github.com/juju-solutions/layer-hadoop-base) but when cloned
>>> locally to work on them, the directory name must match the layer or
>>> interface name ("hadoop-base", in this case).  So, to clone that repo:
>>>
>>> git clone https://github.com/juju-solutions/layer-hadoop-base
>>> $JUJU_REPOSITORY/layers/hadoop-base
>>>
>>> This will ensure that `charm build` does the right thing, can find all
>>> of your in-progress layers, and puts the built charm in the right place.
>>>
>>
>> Is this all documented somewhere? I ended up doing almost exactly what
>> you've described here through reading the charm tools code -- would be good
>> to get it into the author's guide, I think.
>>
>> Is anyone looking at making it possible to build reactive charms offline?
>> AFAICT, you have to have access to the Internet for the pip resources. And
>> maybe the base layer?
>>
>> Cheers,
>> Andrew
>>
>> Thanks!
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charms, layers, and Launchpad

[Andrew Wilkins]

On Fri, Dec 18, 2015 at 8:58 AM Cory Johns  wrote:

> Greetings, all.
>
> I wanted to suggest a convention for managing layered charms with
> Launchpad.
>
> Until the publish workflow is ready, the "built charm" (i.e., output from
> `charm build`) must be checked in to Launchpad in a repo such as:
>
> lp:~user/charms/trusty/foo/trunk
>
> The base path and branch are required to be charms/ and /trunk,
> respectively, for the charm to be ingested into the store.
>
> Launchpad isn't really set up to deal with charm layers, but I think we
> could settle on a convention of using the branch /layer to denote the
> source charm layer for the corresponding /trunk built charm.  The source
> layer (under /layer) is what we would like to have submitted to the Review
> Queue, and the /trunk branch could be used only for ingestion into the
> store.
>
> Note that interface and base layers would need to have their own project,
> since they don't really fit into the charms/series project structure.  They
> can also live outside of Launchpad and work just fine as long as they are
> registered in http://interfaces.juju.solutions/ (which can be done by
> anyone with Launchpad credentials) (eventually, the plan is for them to be
> published to the store in a similar way to charms).
>
> I'd also like to mention our recommendations for developing layered
> charms.  Specifically, you should create a base Juju repository directory
> (e.g., ~/charms) and subdirectories for "layers", "interfaces" (if you plan
> to develop those), and any series directories such as "trusty".  Then, you
> should ensure that the following variables are set in your environment:
>
> JUJU_REPOSITORY=~/charms
> LAYER_PATH=$JUJU_REPOSITORY/layers
> INTERFACE_PATH=$JUJU_REPOSITORY/interfaces  # optional
>
> Many layer and interface repos are prefixed with "layer-" or "interface-"
> to indicate their role (e.g.,
> https://github.com/juju-solutions/layer-hadoop-base) but when cloned
> locally to work on them, the directory name must match the layer or
> interface name ("hadoop-base", in this case).  So, to clone that repo:
>
> git clone https://github.com/juju-solutions/layer-hadoop-base
> $JUJU_REPOSITORY/layers/hadoop-base
>
> This will ensure that `charm build` does the right thing, can find all of
> your in-progress layers, and puts the built charm in the right place.
>

Is this all documented somewhere? I ended up doing almost exactly what
you've described here through reading the charm tools code -- would be good
to get it into the author's guide, I think.

Is anyone looking at making it possible to build reactive charms offline?
AFAICT, you have to have access to the Internet for the pip resources. And
maybe the base layer?

Cheers,
Andrew

Thanks!
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: "Designing for Success: Juju and Charm architecture overview" - Juju Charm Summit

[Andrew Wilkins]

On Sat, Sep 19, 2015 at 2:43 AM Marco Ceppi 
wrote:

> Here are my slides from the first session on Thursday morning. It's a
> meant to be an overview of the Juju and Charm architecture. I'm curious on
> feedback as it's the first time I've run this style presentation.
>
>
> https://docs.google.com/presentation/d/1_rTFq-aS_ESK2wabnCviZtDZ-nYOPI23MeLp-GLDyJY/edit
>

Good stuff!

Teeny weeny correction: storage.yaml does not exist, you define storage in
metadata.yaml. See: https://jujucharms.com/docs/devel/storage.

Cheers,
Andrew

Thanks,
> Marco Ceppi
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju on CloudStack

[Andrew Wilkins]

On Mon, Sep 21, 2015 at 5:53 AM Herman Bergwerf 
wrote:

> I find it quite difficult to understand the semantics of a general juju
> provider (so far juju/environs helped a bit to understand the general
> principle). Is there a place where I can find what I need to write a very
> minimal provider? I don't really have experience with juju, cloudstack or
> cloud computing so I'm not sure if I'm the right person to write a
> cloudstack integration for juju. I think I'll start using juju on a manual
> cluster first or write the integration like
> https://github.com/kapilt/juju-digitalocean (I'm not sure how this code
> integrates with juju, is it just a wrapper around the juju cli?)
>

Hi Herman,

In case you change you later want to write a fully integrated provider,
I've just written some notes about implementing a provider here:
https://github.com/juju/juju/wiki/Implementing-environment-providers. If
you're interested, take a look and let me know if that helps, and what
you're still unclear on.

The approach I would take is:
 1. Implement EnvironProvider and configuration handling first
 2. Implement Environ and Instance, in the following order:
 a. StartInstance
 b. Bootstrap (probably just call common.Bootstrap)
 c. Destroy (probably just call common.Destroy)
 d Instances and StateServerInstances
 e. the rest; no-ops for the firewall-related (*Ports) methods for an
MVP

I'm working on a new Azure provider at the moment, so you can find a fairly
minimal environment implementation here:
https://github.com/axw/juju/tree/d921824ddd7064327c8eab884ecc2e303e9097f0/provider/azure
. It's not
pretty, but it bootstraps.

Cheers,
Andrew

Op za 19 sep. 2015 om 13:44 schreef Nate Finch :
>
>> Definitely look at the GCE provider, it's the newest and uses our current
>> best practices. Some of the older providers are not quite as good examples
>> (not that they're wrong, we've just figured out better ways to do structure
>> the code).
>>
>> On Sat, Sep 19, 2015, 6:01 AM Mark Shuttleworth  wrote:
>>
>>> On 18/09/15 17:27, Herman Bergwerf wrote:
>>> > Hmm, ok. I'm quite surprised a pretty widely used virtualization stack
>>> such
>>> > as cloudstack is not implemented in juju at all. Are there maybe future
>>> > plans to do this?
>>>
>>> Anybody can write a cloud provider and contribute it to Juju. Canonical
>>> will usually write one as part of the certification process for a large
>>> public cloud (like AWS, Google, Azure) but I'm not aware of any large
>>> CloudStack clouds so it's not on our roadmap. Of course we'd gladly land
>>> the work if someone else does it.
>>>
>>> > By the way, wouldn't it be easier to write a provider directly inside
>>> the
>>> > juju code? I'm not sure if there is any documentation to do this.
>>>
>>> Yes, a "proper" provider is built-in to juju-core and lives in the Go
>>> code of Juju itself.
>>>
>>> As a limited workaround, you can use the Juju client plugin mechanism to
>>> automate some of the "manual" provider work. Essentially, you use your
>>> local cloud tools to launch machines, then register them with Juju
>>> controller using the manual provider mechanisms. If you want to dig into
>>> Go programming, then a cloudstack provider would be a good project. You
>>> would be copying the structure of the OpenStack, GCE, Azure, or AWS
>>> provider, then using the cloudstack operations to do what's necessary
>>> there. A main question would be whether or not their is already an
>>> implementation of the cloudstack API in Go.
>>>
>>> Mark
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What is the default username/password of LXC instances (Ubuntu) deployed by Juju via MAAS?

[Andrew Wilkins]

On Sun, Sep 20, 2015 at 12:17 AM Jeff McLamb  wrote:

> Hi all -
>
> I am currently in a situation where my juju deployment host and MAAS host
> (thus DHCP/DNS) are down and I won’t be able to power them back on for a
> few days.
>
> I have manually added entries to /etc/hosts on all of my bare metal
> machines (so that OpenStack services can resolve names absent the DNS
> server) but I cannot login to my LXC instances in order to modify
> /etc/hosts.
>
> For whatever reason the keys aren’t in place to directly ssh into each LXC
> instance from my bare-metal machines. The only option I have is to
> lxc-console directly into each instance, where I am presented with a login
> prompt.
>

You can use "lxc-attach" command to run arbitrary processes within the
container, without the need for a login.

Is there a default user/pass for these Ubuntu LXC instances deployed by
> juju (via MAAS?) or some way to inject a file (e.g. replace/mod /etc/hosts)
> into the container?
>
> It appears as though I could just modify
> /var/lib/lxc//rootfs/etc/hosts directly, but that seems like it
> might cause consistency issues? Or maybe doing that followed by an
> `lxc-stop —name  -r` will reboot the container and it will Just
> Work?
>

AFAIK editing the file via the rootfs path is fine, and you only need to
restart the container if some application is caching the host resolution.

FYI the LXC container, if provisioned by Juju, should have the public SSH
keys of the user who bootstrapped. So you should be able to ssh to the LXC
container from your client machine if you can ssh to the MAAS node.

I'm not sure what versions of the juju CLI this is true for (definitely the
most recent), but for a while now "juju ssh" will accept an IP address or
hostname, and and attempt to ssh to it using a Juju server as a proxy. i.e.:
juju ssh 10.x.y.z
will do something like
ssh -o ProxyCommand="juju ssh 0" 10.x.y.z

HTH,
Andrew

Thanks,
>
> Jeff
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Compiling juju on openSUSE

[Andrew Wilkins]

On Sat, Sep 19, 2015 at 11:12 PM Herman Bergwerf 
wrote:

> So I installed the Go code without make install-dependencies and it
> paniced because my os was not supported (these versions are supported:
> https://github.com/juju/juju/blob/master/juju/series/supportedseries.go)
> I thought Go code was pretty platform independent. So why is this OS check
> there... Because those OS's are tested?
>

The OS-detection code exists primarily to decide how the Juju
servers/agents should be installed, configured, and how they should behave
at runtime. We should stop being so pedantic on the client side.

Having said that, it would be simplest in the short term to extend the
OS/series-detection code to handle openSUSE as well: this would address
your immediate goal, and would also pave the way for running workloads on
openSUSE, should that ever be desirable. We would be happy to review and
merge patches to detect the openSUSE version.


> Does anyone know what exactly is in the ppa's added by `make
> install-dependencies`? It seems it's all about mongodb, but does the juju
> client even need mongodb? I mean, a juju cluster does not depend on the
> client, or does it? I thought the client was only used for bootstrapping
> and some management...
>

The PPAs are only there for developing and testing Juju. You do not need
them to build and run the client only.

Cheers,
Andrew

Op vr 18 sep. 2015 om 21:41 schreef Curtis Hovey-Canonical <
> cur...@canonical.com>:
>
>> On Fri, Sep 18, 2015 at 1:18 PM, Jorge O. Castro 
>> wrote:
>> > On Fri, Sep 18, 2015 at 1:35 PM, Herman Bergwerf
>> >  wrote:
>> >> Anyone who has experience compiling juju on openSUSE?
>>
>> As the juju is staticly compiled for most archs, and series/os-version
>> is irrelevant, you can use any Juju that matched your os and
>> architecture. eg. you can download a linux amd64 client and expect it
>> to work.
>>
>> e.g. I downloaded the centos7 client from
>> https://launchpad.net/juju-core/+milestone/1.24.5  and ran it on
>> Ubuntu precise and Ubuntu wily.
>>
>> You probably do need to hack and compile your own client though.
>> Juju's client thinks it needs to know the version of linux which is
>> bogus for the common case of bootstrapping and maintaining a server in
>> a cloud.
>> https://bugs.launchpad.net/juju-core/+bug/1465317
>>
>> See version/osversion.go and version/supportedseries.go
>>
>>
>>
>>
>>
>> --
>> Curtis Hovey
>> Canonical Cloud Development and Operations
>> http://launchpad.net/~sinzui
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Accessing files between conatiners.

[Andrew Wilkins]

Hi Sunitha,

We intend to support shared filesystems in the core of Juju, but this is
not currently available. You could use NFS if a shared filesystem is
appropriate.

Can you describe the problem you're trying to solve by sharing files? There
may be a better approach that will work today.

Cheers,
Andrew

On Thu, Aug 13, 2015 at 7:52 PM Sunitha Radharapu 
wrote:

> Hi,
>
> I have a scenario where my application is connecting to Remote DB.
>
> Example:
>
>  If my DB is running in container 1  and my application is running in
> container 2 , Is it possible to access the files of container 1(where my DB
> is installed) from container 2(where my application is installed).?
>
> Can you please  provide any solution for these kind of scenarios?
>
>
> Thanks,
> Sunitha.
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Adding a new machine in juju

[Andrew Wilkins]

Hi Suchitra,

The first time you try to add a machine with the local provider (or adding
an LXC container in any provider), Juju will download the required LXC
image. Once that's done, it'll be updating packages with APT. If your
network speed is slow, this can take a while. This should be much improved
for subsequent machine additions.

If you use "pstree" on the jujud process, you should be able to see if it's
downloading LXC images.

Cheers,
Andrew

On Thu, Jul 2, 2015 at 8:08 PM Suchitra Venugopal1 
wrote:

> Hi Team,
>  I installed juju(1.24.0) version  in my Ubuntu box and when tried to add
> a juju machine using juju add-machine its waiting in pending state for long
> time as shown below:
>
>
>
> The log is also not getting updated and the status is also not getting
> updated after 30 - 40 minutes.
> This issue has been observed in some more ubuntu machines in the near past
> and we were not able to resolve this after cleaning the environment and
> reisntall.
>
> At the same time we had few other machines which is working fine  and we
> able to deploy charms in them. The version of juju in them are lower than
> 1.24.0. Few of them has 1.23.2 and few 1.22.0, 1.22.1 etc.
>
> We are trying to install an older vrsion of juju to confirm whether this
> is an issue with version. Also thought to check with you whether any issue
> is ther with later version of Juju ?
> Also can anyone help us with the step to get an older version which is
> supported in trusty(14.04) version. I had a quick look in
> *https://launchpad.net/~juju/+archive/ubuntu/stable*
>  and found the below
> versions available under *stable*.  Or should we be looking at some other
> place other than *stable* ?
>
>
>
>
> Can anyone help me in this.
>
> Thanks & Regards,
> Suchitra Venugopal
> IBM India Pvt. Ltd
> Seat # EGLC 6F B099,
> C-Block, Embassy Golf Link,
> Intermediate Ring Road, Bangalore
> Off : (91)80-4129-7773
> Mobile  :   9663126000
> Email:   suchv...@in.ibm.com--
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What is the proper procedure to upgrade juju (from 1.18 to 1.24)

[Andrew Wilkins]

On Wed, Jul 1, 2015 at 1:34 AM Mario Splivalo 
wrote:

> Hi, lads (and ladies!)
>
> I need to upgrade customer who's running juju 1.18 (on a fairly large
> setup, 100+ nodes), and I'm not sure what's the proper procedure to do so.
>
> I tried (in our lab, local OpenStack) upgrading juju-core package to
> 1.24, and then running 'upgrade-juju', but that just left my environment
> unusable.
>
> Then I opted for a 'intermediate' step - I'll upgrade to 1.20 (which is
> in trusty-updates, and from there I'll upgrade to 1.24.
>
> So, I installed 1.18 from trusty (apt-get install
> juju-core=1.18.1-0ubuntu1), bootstraped, and deployed two simple
> services, one-unit ubuntu service (u1) and three unit ubuntu service (u2).
>
> After services were installed I run upgrade-juju (with juju-core still
> being 1.18)
>
> juju upgrade-juju
>
> That upgraded agents on all the installed units to 1.20.14. (juju status
> confirmed that, as well as symlinks in /var/lib/juju/tools on each of
> the deployed units).
>
> After that I upgraded juju-core (on my control node) to 1.20.11. But,
> after that running 'juju upgrade-juju' yielded with "no upgrades
> available". As I was running 1.20 agent on all of the installed units I
> went further and upgraded juju-core to 1.24 (from juju stable ppa), and
> tried 'juju upgrade-juju' again. But again I was greeted with "no
> upgrades available".
>
> I then run 'juju upgrade-juju --dry-run --version 1.24.0', and this time
> juju showed me available versions and suggested that 1.24 was the best one:
>
> ubuntu@mariosplivalo-bastion:~$ juju upgrade-juju --dry-run
> no upgrades available
> ubuntu@mariosplivalo-bastion:~$ juju upgrade-juju --dry-run --version
> 1.24.0
> available tools:
> 1.24.0-precise-amd64
> 1.24.0-precise-armhf
> 1.24.0-precise-i386
> 1.24.0-trusty-amd64
> 1.24.0-trusty-arm64
> 1.24.0-trusty-armhf
> 1.24.0-trusty-i386
> 1.24.0-trusty-ppc64el
> 1.24.0-utopic-amd64
> 1.24.0-utopic-arm64
> 1.24.0-utopic-armhf
> 1.24.0-utopic-i386
> 1.24.0-utopic-ppc64el
> 1.24.0-vivid-amd64
> 1.24.0-vivid-arm64
> 1.24.0-vivid-armhf
> 1.24.0-vivid-i386
> 1.24.0-vivid-ppc64el
> best version:
> 1.24.0
> upgrade to this version by running
> juju upgrade-juju --version="1.24.0"
> ubuntu@mariosplivalo-bastion:~$ juju upgrade-juju --dry-run
> --version="1.24.0"
> available tools:
> 1.24.0-precise-amd64
> 1.24.0-precise-armhf
> 1.24.0-precise-i386
> 1.24.0-trusty-amd64
> 1.24.0-trusty-arm64
> 1.24.0-trusty-armhf
> 1.24.0-trusty-i386
> 1.24.0-trusty-ppc64el
> 1.24.0-utopic-amd64
> 1.24.0-utopic-arm64
> 1.24.0-utopic-armhf
> 1.24.0-utopic-i386
> 1.24.0-utopic-ppc64el
> 1.24.0-vivid-amd64
> 1.24.0-vivid-arm64
> 1.24.0-vivid-armhf
> 1.24.0-vivid-i386
> 1.24.0-vivid-ppc64el
> best version:
> 1.24.0
> upgrade to this version by running
> juju upgrade-juju --version="1.24.0"
>
>
> So I did what was suggested:
>
> ubuntu@mariosplivalo-bastion:~$ juju upgrade-juju --version="1.24.0"
> available tools:
> 1.24.0-precise-amd64
> 1.24.0-precise-armhf
> 1.24.0-precise-i386
> 1.24.0-trusty-amd64
> 1.24.0-trusty-arm64
> 1.24.0-trusty-armhf
> 1.24.0-trusty-i386
> 1.24.0-trusty-ppc64el
> 1.24.0-utopic-amd64
> 1.24.0-utopic-arm64
> 1.24.0-utopic-armhf
> 1.24.0-utopic-i386
> 1.24.0-utopic-ppc64el
> 1.24.0-vivid-amd64
> 1.24.0-vivid-arm64
> 1.24.0-vivid-armhf
> 1.24.0-vivid-i386
> 1.24.0-vivid-ppc64el
> best version:
> 1.24.0
> ubuntu@mariosplivalo-bastion:~$
>
> Although the output from the command didn't suggest it, actually the
> upgrade started in the background. After some time 'juju status'
> returned output, and everything seemed to be ok, but the agent version
> was still 1.20. Inside /var/lib/juju/tools there was 1.24.0-trusty-i386
> directory, but the symlinks for machine-X etc were still pointing to 1.20:
>
> ubuntu@juju-mariosplivalo-machine-1:/var/lib/juju/tools$ ls -al
> total 20
> drwxr-xr-x 5 root root 4096 Jun 30 17:11 .
> drwxr-xr-x 5 root root 4096 Jun 30 16:51 ..
> drwxr-xr-x 2 root root 4096 Jun 30 16:51 1.18.4-trusty-i386
> drwxr-xr-x 2 root root 4096 Jun 30 17:02 1.20.14-trusty-i386
> drwxr-xr-x 2 root root 4096 Jun 30 17:11 1.24.0-trusty-i386
> lrwxrwxrwx 1 root root   19 Jun 30 17:02 machine-1 -> 1.20.14-trusty-i386
> lrwxrwxrwx 1 root root   19 Jun 30 17:02 unit-u1-0 -> 1.20.14-trusty-i386
>
>
> However, when I try to add another service (juju deploy ubuntu u3), that
> one never finishes - the machine is brought up, I can ssh into it (using
> ssh keys from ~/.juju/), but juju status for that service shows this:
>   u3:
> charm: cs:trusty/ubuntu-3
> exposed: false
> service-status:
>   current: unknown
>   message: Waiting for agent initialization to finish
>   since: 30 Jun 2015 17:25:36Z
> units:
>   u3/0:
> workload-status

Re: Upcoming change in 1.24: tags in EC2

[Andrew Wilkins]

On Tue, May 26, 2015 at 1:48 PM, Kapil Thangavelu  wrote:

>
>
> On Mon, May 25, 2015 at 9:23 PM, Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Tue, May 26, 2015 at 12:18 PM, Richard Harding <
>> rick.hard...@canonical.com> wrote:
>>
>>> On Tue, 26 May 2015, Andrew Wilkins wrote:
>>>
>>> > On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth 
>>> wrote:
>>> >
>>> > > On 25/05/15 18:57, Kapil Thangavelu wrote:
>>> > > > That's super awesome, and very helpful for real world usage. A few
>>> > > > suggestions, For users with multiple environments, seeing a bunch
>>> > > > machine-0 in the ui, is rather confusing, i'd suggest prefixing
>>> with
>>> > > > the env name. Potentially even more useful is actually naming the
>>> > > > machines not for their pet names, but their cattle names (workload
>>> > > > name), ie. name with the primary unit that caused the machine to
>>> > > > exist, or was the first unit assigned to the machine (minus state
>>> > > > servers).
>>> > >
>>> > > Agreed; for full chargeback we need environment uuid, for social
>>> > > debugging we need some sort of environment name, unit names and
>>> charm(s)
>>> > > deployed, including in containers on the machine. For EBS it would be
>>> > > the store name, uuid, and unit identity.
>>> > >
>>> >
>>> > Kapil, Mark, thanks for the suggestions. Sounds good, I'll look at
>>> doing
>>> > that.
>>> >
>>> > A concern I have is that these resources can be reassigned (units
>>> added,
>>> > volume
>>> > assigned to different store) so those tags would then be misleading.
>>> That's
>>> > the main
>>> > reason why I avoided including information about the workload/store in
>>> the
>>> > name. I
>>> > suppose the benefit outweighs, and we could look at updating tags
>>> later on.
>>> >
>>> > Cheers,
>>> > Andrew
>>>
>>> One suggestion is being careful about what tags might already exist on a
>>> machine that a user might have set through their own control UI. If Juju
>>> is
>>> tracking tags it sets we should make sure it never messed with ones it
>>> did
>>> not set.
>>>
>>
>> When we come to updating existing machines, we won't touch existing tags.
>> The tags we do add, apart from Name, will be prefixed with Juju so they're
>> obviously under the management of Juju. Change them at your own peril.
>>
>> This does highlight a problem of how we identify whether or not Juju can
>> update
>> the resource's Name tag though. We would either never update it, and live
>> with
>> possibly-wrong machine names, or alternatively we'd have a sufficiently
>> unique
>> name format that Juju will replace only if it matches.
>>
>
> one option is to leave the machine id static at allocation (ie what it is
> now) and then do workloads dynamically in an additional tag under the juju
> namespace. At least with aws, this does degrade console usability as the
> user will be looking at a flat list of machines and will have to poke into
> details to learn workload on an individual. There's some mitigation in that
> the aws console added a nice feature earlier this year for browsing
> resource groups via query by tag albeit with additional end user setup.
> Compound values (all services on a machine) can be searched via contains.
> ie. i could find all machines running units of service xyz in a given env
> with juju-env=uuid and juju-units=contains xyz. There's some
> usability/discoverability issues with env uuid vs name. aws limits to 10
> tags and 255 length utf8 values, most orgs reserve some set of tags for
> their own use.
>

I think going with a static name and adding the additional information in
tags is the best way forward.
It does mean that you have to click an extra level down, but that's going
to be true of everything other
than AWS anyway. This way we can reserve certain tags (say, everything
starting with "Juju") and
periodically reconcile them with Juju's state; and we don't have to worry
about overwriting changes
made by users to machine names. We'll set the machine name once on
creation, then users can
update them if desired.


> the alternative for dynamic values means storing both the name tag as
> d

Re: Upcoming change in 1.24: tags in EC2

[Andrew Wilkins]

On Tue, May 26, 2015 at 12:18 PM, Richard Harding <
rick.hard...@canonical.com> wrote:

> On Tue, 26 May 2015, Andrew Wilkins wrote:
>
> > On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth 
> wrote:
> >
> > > On 25/05/15 18:57, Kapil Thangavelu wrote:
> > > > That's super awesome, and very helpful for real world usage. A few
> > > > suggestions, For users with multiple environments, seeing a bunch
> > > > machine-0 in the ui, is rather confusing, i'd suggest prefixing with
> > > > the env name. Potentially even more useful is actually naming the
> > > > machines not for their pet names, but their cattle names (workload
> > > > name), ie. name with the primary unit that caused the machine to
> > > > exist, or was the first unit assigned to the machine (minus state
> > > > servers).
> > >
> > > Agreed; for full chargeback we need environment uuid, for social
> > > debugging we need some sort of environment name, unit names and
> charm(s)
> > > deployed, including in containers on the machine. For EBS it would be
> > > the store name, uuid, and unit identity.
> > >
> >
> > Kapil, Mark, thanks for the suggestions. Sounds good, I'll look at doing
> > that.
> >
> > A concern I have is that these resources can be reassigned (units added,
> > volume
> > assigned to different store) so those tags would then be misleading.
> That's
> > the main
> > reason why I avoided including information about the workload/store in
> the
> > name. I
> > suppose the benefit outweighs, and we could look at updating tags later
> on.
> >
> > Cheers,
> > Andrew
>
> One suggestion is being careful about what tags might already exist on a
> machine that a user might have set through their own control UI. If Juju is
> tracking tags it sets we should make sure it never messed with ones it did
> not set.
>

When we come to updating existing machines, we won't touch existing tags.
The tags we do add, apart from Name, will be prefixed with Juju so they're
obviously under the management of Juju. Change them at your own peril.

This does highlight a problem of how we identify whether or not Juju can
update
the resource's Name tag though. We would either never update it, and live
with
possibly-wrong machine names, or alternatively we'd have a sufficiently
unique
name format that Juju will replace only if it matches.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming change in 1.24: tags in EC2

[Andrew Wilkins]

On Tue, May 26, 2015 at 4:05 AM, Mark Shuttleworth  wrote:

> On 25/05/15 18:57, Kapil Thangavelu wrote:
> > That's super awesome, and very helpful for real world usage. A few
> > suggestions, For users with multiple environments, seeing a bunch
> > machine-0 in the ui, is rather confusing, i'd suggest prefixing with
> > the env name. Potentially even more useful is actually naming the
> > machines not for their pet names, but their cattle names (workload
> > name), ie. name with the primary unit that caused the machine to
> > exist, or was the first unit assigned to the machine (minus state
> > servers).
>
> Agreed; for full chargeback we need environment uuid, for social
> debugging we need some sort of environment name, unit names and charm(s)
> deployed, including in containers on the machine. For EBS it would be
> the store name, uuid, and unit identity.
>

Kapil, Mark, thanks for the suggestions. Sounds good, I'll look at doing
that.

A concern I have is that these resources can be reassigned (units added,
volume
assigned to different store) so those tags would then be misleading. That's
the main
reason why I avoided including information about the workload/store in the
name. I
suppose the benefit outweighs, and we could look at updating tags later on.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Upcoming change in 1.24: tags in EC2

[Andrew Wilkins]

On Mon, May 25, 2015 at 6:22 AM, Tim Penhey 
wrote:

> On 22/05/15 17:26, Andrew Wilkins wrote:
> > Hi all,
> >
> > Just a small announcement, in case anyone cares. In the EC2 provider,
> > from 1.24, we will start tagging instances and volumes with their
> > Juju-internal names and the Juju environment UUID. Instances, for
> > example, will have a name of "machine-0", "machine-1", etc.,
> > corresponding to the ID in "juju status". There is not currently an
> > upgrade step to tag existing resources, so only newly created resources
> > will be tagged.
>
> What is the rationale behind not tagging existing machines? Surely it
> would be useful?
>

It just hasn't been done yet. It should be. I needed to add tags to volumes,
so I just added them to machines while I was in the vicinity.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Upcoming change in 1.24: tags in EC2

[Andrew Wilkins]

Hi all,

Just a small announcement, in case anyone cares. In the EC2 provider, from
1.24, we will start tagging instances and volumes with their Juju-internal
names and the Juju environment UUID. Instances, for example, will have a
name of "machine-0", "machine-1", etc., corresponding to the ID in "juju
status". There is not currently an upgrade step to tag existing resources,
so only newly created resources will be tagged.

The environment UUID can be used to identify all instances and volumes that
are part of an environment. This could be used to for billing purposes; to
charge the infrastructure costs for a Juju environment to a particular
user/organisation.

We will be looking at doing the same for OpenStack for 1.24 also.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Running Juju in Google compute engine

[Andrew Wilkins]

On Fri, May 1, 2015 at 8:26 PM, Jorge O. Castro  wrote:

> I was able to find the project name, client email, and client id in
> the GCE UI, but I wasn't able to find where I'm supposed to find the
> private key, can someone help me out?


Did you get a JSON key file from the console yet?
APIs & Auth > Credentials
Generate New JSON key

You can just point environments.yaml at that JSON file, like so:
type: gce
auth-file: /path/to/project-1230182313.json
project-id: whatever
region: us-central1

HTH


> --
> Jorge Castro
> Canonical Ltd.
> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: failure upgrading Juju from 1.21.1 to 1.22.0 on trusty

[Andrew Wilkins]

On Wed, Apr 8, 2015 at 6:09 PM, Joshua Randall  wrote:

> > I'd want to hear from others on this matter, as my experience with
> repairing upgrades is limited.
> > I recommend you don't take any action on the following immediately,
> until others have weighed in.
> I will hold off doing anything else for now, as I don’t want to risk
> losing our running environment (everything that Juju set up still seems to
> be running fine at the moment, we just can’t make any changes).
>
> > John figured that the error you've got could be related to having
> containers in the environment.
> > Unfortunately it appears that the upgrade step doesn't work if there are
> any containers, as it
> > mistakenly thinks they're MAAS machines (and is rightly told that they
> don't exist in MAAS). It'd
> > be great to get confirmation that you do have containers in your
> environment.
> Yes! We are using containers, and they are present on machine 0. Actually,
> one of the reasons we are upgrading Juju is in the hopes to resolve another
> issue which seems related to having containers on machine 0, which was that
> the cloud-init user-data that Juju has started sending to MAAS was using
> the IP address of the LXC bridge for the state server instead of the real
> IP address, so a machine we were trying to enroll into Juju hasn’t been
> able to finish because it can’t contact the Juju state server. I saw some
> bug fix changes that went into the 1.22 version that I thought might fix
> that problem, which is why I was trying the upgrade.
>
> Anyway, it sounds like what you are saying is that the upgrade state
> database migration step is iterating through a list that contains all of
> the MAAS machines as well as the containers when it should just be
> iterating through the MAAS machines themselves?


Correct.


> > Now, this could be repaired without *too* much trouble I think. That
> upgrade step is the last one
> > to upgrade to 1.22 completely. So, options are:
> >  1. Hand-edit the agent's config file so it thinks it's finished
> upgrading.
> >  2. Fix Mongo so the upgrade step thinks it has nothing to do.
> >  3. Wait for a fix to Juju. I'm not sure how long that'll take, as we're
> all about to travel. I've just filed:
> >  https://bugs.launchpad.net/juju-core/+bug/1441478
> Thanks for filing the bug! I’ve subscribed to it and am happy to move this
> discussion there. I’ll monitor both places.
>
> > #1 will work, but will mean that you'll have no availability-zone
> information in your instances.
> > I'm not sure if that'd cause any immediate problems (Eric?), but it will
> mean that charms won't
> > be able to take advantage of that information.
> >
> > #2 would be preferable; this would involve opening the Juju state
> database with the mongo
> > shell, and updating all documents in the "instancedata" collection so
> that they have "availzone"
> > fields.
> I’ll take a look at the Juju state mongodb, and take a backup in
> preparation for making changes, but I’ll hold off on making them for now.
>
> Should there be a default value entered for “availzone” or is an empty
> value fine? My reading of the code (I think the relevant bit is:
> https://github.com/juju/juju/blob/1.22/state/upgrades.go#L559-582) is
> that just having the availzone key should be fine to convince the upgrade
> it is done, but I’m not sure whether the availzone value might be used
> during operations (will it safely be ignored for containers and/or is the
> empty string a safe value to set it to?).
>

This is the bit I'm unsure of. I *think* it is only used for (a) FYI (in
status), and (b) for the information of charms. Charms are able to identify
the availability zone their machine is allocated to, and then organise
appropriately (e.g. to minimise cross-zone traffic, or to maximise
redundancy).

Since you've said there's only one zone, I'd guess you could just set the
value to that for all of the MAAS machines, and "" for the containers.

Eric, who is currently at PyCon, will hopefully be able to answer on this
definitively after the conference.

Also, it seems likely that the upgrade will have bailed out as soon as the
> interator hit the first container, meaning it may not have properly set the
> availzone for all of our MAAS machines. I suppose I could hope that it at
> least did machine 0 and use that value for the other MAAS machines (in any
> case, we only have one availability zone).
>
> Cheers,
>
> Josh.
>
>
> --
> This email is sent on behalf of Genomics Limited, a limited company
> registered in England and Wales with registered number 8839972, VAT
> registered number 189 2635 65 and registered office at 24 Cornhill, London,
> EC3V 3ND, United Kingdom.
> The contents of this e-mail and any attachments are confidential to the
> intended recipient. If you are not the intended recipient please do not use
> or publish its contents, contact Genomics Limited immediately at
> i...@genomicsltd.com then delete. You may not copy, forward, use or

Re: failure upgrading Juju from 1.21.1 to 1.22.0 on trusty

[Andrew Wilkins]

On Wed, Apr 8, 2015 at 3:24 PM, John Meinel  wrote:

> upgrade step "set AvailZone in instanceData" failed: no instances found
> seems suspicious.
> What version of MAAS are you running?
> It is possible that it would come before MAAS availability zones?
>
> Certainly we couldn't really find 0 instances in MAAS because the machine
> this is running on has to be at least one of them.
>
> Unfortunately a few people are on vacation this week in preparation for
> our sprint next week, but hopefully we can still get ahold of the people
> who were working on this upgrade step.
>
> John
> =:->
>
>
> On Wed, Apr 8, 2015 at 4:49 AM, Joshua Randall <
> josh.rand...@genomicsltd.com> wrote:
>
>> I ran `juju upgrade-juju` today to upgrade a MAAS environment to Juju
>> version 1.22.0 and now `juju status` says that the upgrade has failed (and
>> thus we have limited access to the state server since an upgrade is in
>> progress). What can I do to manually complete the upgrade?
>>
>> `juju status` shows the following error:
>> > environment: maas
>> > machines:
>> >   "0":
>> > agent-state: error
>> > agent-state-info: 'upgrade to 1.22.0 failed (giving up): set
>> AvailZone in instanceData:
>> >   no instances found'
>> > agent-version: 1.22.0
>> > ...
>>
>> While '/var/log/juju/machine-0.log’ on machine 0 has:
>> > 2015-04-08 00:03:16 DEBUG juju.provider.maas environprovider.go:32
>> opening environment "maas".
>> > 2015-04-08 00:03:16 ERROR juju.upgrade upgrade.go:134 upgrade step "set
>> AvailZone in instanceData" failed: no instances found
>> > 2015-04-08 00:03:16 ERROR juju.cmd.jujud upgrade.go:360 upgrade from
>> 1.21.1 to 1.22.0 for "machine-0" failed (will retry): set AvailZone in
>> instanceData: no instances found
>> > 2015-04-08 00:03:16 DEBUG juju.apiserver apiserver.go:265 <- [3]
>> machine-0
>> {"RequestId":22,"Type":"Machiner","Request":"Life","Params":{"Entities":[{"Tag":"machine-0"}]}}
>> > 2015-04-08 00:03:16 DEBUG juju.apiserver apiserver.go:272 -> [3]
>> machine-0 410.699us
>> {"RequestId":22,"Response":{"Results":[{"Life":"alive","Error":null}]}}
>> Machiner[""].Life
>> > 2015-04-08 00:03:16 DEBUG juju.apiserver apiserver.go:265 <- [3]
>> machine-0
>> {"RequestId":23,"Type":"Machiner","Request":"SetStatus","Params":{"Entities":[{"Tag":"machine-0","Status":"
>> > error","Info":"upgrade to 1.22.0 failed (will retry): set AvailZone in
>> instanceData: no instances found","Data":null}]}}
>>
>> I would very much appreciate any pointers in the right direction on how
>> to go about resolving this… any ideas?
>>
>
I'd want to hear from others on this matter, as my experience with
repairing upgrades is limited.
I recommend you don't take any action on the following immediately, until
others have weighed in.

John figured that the error you've got could be related to having
containers in the environment.
Unfortunately it appears that the upgrade step doesn't work if there are
any containers, as it
mistakenly thinks they're MAAS machines (and is rightly told that they
don't exist in MAAS). It'd
be great to get confirmation that you do have containers in your
environment.

Now, this could be repaired without *too* much trouble I think. That
upgrade step is the last one
to upgrade to 1.22 completely. So, options are:
 1. Hand-edit the agent's config file so it thinks it's finished upgrading.
 2. Fix Mongo so the upgrade step thinks it has nothing to do.
 3. Wait for a fix to Juju. I'm not sure how long that'll take, as we're
all about to travel. I've just filed:
 https://bugs.launchpad.net/juju-core/+bug/1441478

#1 will work, but will mean that you'll have no availability-zone
information in your instances.
I'm not sure if that'd cause any immediate problems (Eric?), but it will
mean that charms won't
be able to take advantage of that information.

#2 would be preferable; this would involve opening the Juju state database
with the mongo
shell, and updating all documents in the "instancedata" collection so that
they have "availzone"
fields.

Cheers,
Andrew
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju