Re: canonical-kubernetes - Adding worker get stuck

[Tim Van Steenburgh]

Please post an issue at
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/new

The issue template contains instructions for gathering debug info from the
cluster.

On Fri, Apr 27, 2018 at 11:37 AM, sSeBBaSs  wrote:

> Hi Guys,
>
> Today I was able to correctly deploy a kubernetes-cluster, but somehow it
> seems that adding a worker fail, here you have an extract of the juju
> debug-log
>
> 2018-04-27 15:30:23 INFO juju-log Reactive main running for hook update-status
> 2018-04-27 15:30:24 INFO juju-log Initializing Snap Layer
> 2018-04-27 15:30:24 DEBUG update-status none
> 2018-04-27 15:30:24 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:257:charm_status
> 2018-04-27 15:30:24 INFO juju-log Invoking reactive handler: 
> reactive/docker.py:341:enable_grub_cgroups
> 2018-04-27 15:30:24 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:301:send_data
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/tls_client.py:60:store_client
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:234:set_app_version
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/tls_client.py:15:store_ca
> 2018-04-27 15:30:25 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:977:catch_change_in_creds
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:965:request_kubelet_and_proxy_credentials
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:956:notify_master_gpu_not_enabled
> 2018-04-27 15:30:26 INFO juju-log Setting gpu=False on kube-control relation
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/tls_client.py:36:store_server
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:1007:fix_iptables_for_docker_1_13
> 2018-04-27 15:30:26 INFO juju-log Invoking reactive handler: 
> reactive/kubernetes_worker.py:424:apply_node_labels
> 2018-04-27 15:30:27 INFO juju-log Skipping malformed option: .
> 2018-04-27 15:30:27 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:27 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
> 2018-04-27 15:30:28 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:28 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
> 2018-04-27 15:30:29 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:29 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
> 2018-04-27 15:30:30 DEBUG update-status Error from server (NotFound): nodes 
> "ip-10-0-3-204.ec2.internal" not found
> 2018-04-27 15:30:30 INFO juju-log Failed to apply label 
> juju-application=kubernetes-worker. Will retry.
>
> Any thoughts?
> ​
> --
> ---
> Sebastian Juárez
> Mail: ssebb...@gmail.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: Error conjure-up canonical-kubernetes

[Tim Van Steenburgh]

I've hit this too (https://github.com/conjure-up/conjure-up/issues/1392).
The important bit from the log is:

2018-04-26 16:42:13,390 [ERROR] conjure-up/canonical-kubernetes -
juju.py:741 - cannot change profile for the next exec call: No such file or
directory
The error happens when conjure-up runs the juju-wait snap. In my case, the
problem just went away. At the time there had been some issues with the
core snap, so I just chalked it up to that and moved on.

Other similar reports I've seen:

https://bugs.launchpad.net/snappy/+bug/1687079
https://bugs.launchpad.net/snapcraft/+bug/1760514

If the problem continues I'd suggest opening a bug against conjure-up or
snappy. Either way we'll likely need help from the snappy team to debug and
resolve this.

On Thu, Apr 26, 2018 at 3:46 PM, sSeBBaSs  wrote:

> Hi Guys!
>
> I’m trying to deploy a clean kubernetes cluster with conjure-up, but since
> today I’m having this issue:
>
> conjure-up canonical-kubernetes aws juju-test-controller00 kube00
> [info] Summoning canonical-kubernetes to aws
> [info] Connecting to Juju model kube00...
> [info] Juju model connected.
> [info] Running Canonical Distribution of Kubernetes step: 
> 00_process-providertype before-deploy.
> [info] Deploying Applications.
> [info] Waiting for deployment to settle.
> [error] Some applications failed to start successfully.
> [warning] Shutting down
>
> And from the conjure-up log:
>
> 2018-04-26 16:41:15,037 [DEBUG] conjure-up/_unspecified_spell - juju.py:34 - 
> bin_path candidate found
> 2018-04-26 16:41:15,038 [DEBUG] conjure-up/_unspecified_spell - juju.py:34 - 
> wait_path candidate found
> 2018-04-26 16:41:15,132 [DEBUG] conjure-up/_unspecified_spell - app.py:263 - 
> Juju version: 2.3.7-xenial-amd64, conjure-up version: 2.5.6
> 2018-04-26 16:41:15,144 [DEBUG] conjure-up/_unspecified_spell - app.py:346 - 
> found spell {'key': 'canonical-kubernetes', 'name': 'Canonical Distribution 
> of Kubernetes', 'description': 'Kubernetes is an open-source platform for 
> deploying, scaling, and operations of application containers across a cluster 
> of hosts. Kubernetes is portable in that it works with public, private, and 
> hybrid clouds. Extensible through a pluggable infrastructure. Self healing in 
> that it will automatically restart and place containers on healthy nodes if a 
> node ever goes away.\n'}
> 2018-04-26 16:41:15,144 [DEBUG] conjure-up/_unspecified_spell - 
> telemetry.py:31 - Spell Choice: canonical-kubernetes
> 2018-04-26 16:41:15,156 [DEBUG] conjure-up/canonical-kubernetes - 
> download.py:60 - Path is local filesystem, copying 
> /snap/conjure-up/987/spells/canonical-kubernetes to 
> /home/sjuarez/.cache/conjure-up/canonical-kubernetes
> 2018-04-26 16:41:18,868 [DEBUG] conjure-up/canonical-kubernetes - step.py:27 
> - steps: [ 00_process-providertype v: False c: []>,  Kubernetes 01_select-network v: True c: []>,  Distribution of Kubernetes 02_get-kubectl v: True c: []>,  Canonical Distribution of Kubernetes 03_cluster-info v: True c: []>, 
> ]
> 2018-04-26 16:41:22,892 [DEBUG] conjure-up/canonical-kubernetes - 
> telemetry.py:17 - Showing screen: Application Start
> 2018-04-26 16:41:22,899 [DEBUG] conjure-up/canonical-kubernetes - 
> telemetry.py:31 - OS: Linux-4.13.0-39-generic-x86_64-with-debian-stretch-sid
> 2018-04-26 16:41:23,336 [INFO] conjure-up/canonical-kubernetes - 
> events.py:172 - Watching for shutdown
> 2018-04-26 16:41:23,394 [DEBUG] conjure-up/canonical-kubernetes - 
> events.py:53 - Awaiting Shutdown at conjureup/events.py:175
> 2018-04-26 16:41:23,394 [DEBUG] conjure-up/canonical-kubernetes - 
> utils.py:512 - Pulling bundle for canonical-kubernetes from channel: stable
> 2018-04-26 16:41:25,739 [DEBUG] conjure-up/canonical-kubernetes - 
> events.py:53 - Awaiting Bootstrapped at 
> conjureup/controllers/bootstrap/tui.py:17
> 2018-04-26 16:41:27,334 [INFO] conjure-up/canonical-kubernetes - 
> juju.client.connection: connection.py:464 - Driver connected to juju 
> wss://54.157.235.156:17070/api
> 2018-04-26  16:41:28,020 [INFO] 
> conjure-up/canonical-kubernetes - common.py:74 - Connecting to Juju model 
> kube00...
> 2018-04-26 16:41:28,683 [INFO] conjure-up/canonical-kubernetes - 
> juju.client.connection: connection.py:464 - Driver connected to juju 
> wss://54.157.235.156:17070/model/9e1305ba-211c-4aa5-8dc8-b34986d682b1/api
> 2018-04-26 
> 
>  16:41:29,516 [DEBUG] conjure-up/canonical-kubernetes - events.py:53 - 
> Setting ModelConnected at conjureup/juju.py:174 in task run at 
> conjureup/controllers/bootstrap/common.py:19
> 2018-04-26 16:41:29,516 [INFO] conjure-up/canonical-kubernetes - common.py:74 
> - Juju model connected.
> 2018-04-26 16:41:29,520 [DEBUG] conjure-up/canonical-kubernetes - 
> events.py:53 - Setting Bootstrapped at 
> conjureup/controllers/bootstrap/common.py:42 in task run at 
> conjureup/controllers/

Re: Charm Developer program

[Tim Van Steenburgh]

Sorry for the confusion guys. This program is no longer active and the page
is being taken down.

If you (or others) come across links to http://developer.juju.solutions,
please let me know so I can remove them.

On Mon, Dec 18, 2017 at 12:03 AM, Nadeem Idrees 
wrote:

> Agreed, if this program is not active anymore then the page should be
> removed. Though the program can really be helpful for both beginner and
> advanced Juju charmers.
>
> On Mon, Dec 18, 2017 at 12:56 AM, Tom Barber  wrote:
>
>> Hi Nadeem
>>
>> I had one of my guys sign up about 6 months ago  and pinged a bunch of
>> people,  never got anywhere. It'd make more sense to remove the page to be
>> honest!
>>
>> Tom
>>
>>
>> On 17/12/17 10:20, Nadeem Idrees wrote:
>>
>> Hi,
>> I have filled the form  to be a part of
>> charm developer program about 2 weeks ago but I haven't received any
>> response yet. I have re-submitted the form today again. Is there anything
>> else that I would need to share/complete after the form submission?
>>
>> Thanks,
>> Nadeem
>>
>>
>>
>>
>> Spicule Limited is registered in England & Wales. Company Number:
>> 09954122. Registered office: First Floor, Telecom House, 125-135 Preston
>> Road, Brighton, England, BN1 6AF. VAT No. 251478891.
>>
>>
>> All engagements are subject to Spicule Terms and Conditions of Business.
>> This email and its contents are intended solely for the individual to whom
>> it is addressed and may contain information that is confidential,
>> privileged or otherwise protected from disclosure, distributing or copying.
>> Any views or opinions presented in this email are solely those of the
>> author and do not necessarily represent those of Spicule Limited. The
>> company accepts no liability for any damage caused by any virus transmitted
>> by this email. If you have received this message in error, please notify us
>> immediately by reply email before deleting it from your system. Service of
>> legal notice cannot be effected on Spicule Limited by email.
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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: Submission of sme-1 for charm store

[Tim Van Steenburgh]

Hi Steven,

Sure, can you `charm publish` your charm please (it's not currently in the
the stable channel). See `charm publish -h` for more info.

Thanks,
Tim

On Mon, Dec 4, 2017 at 6:59 PM, Steven Sweeting 
wrote:

> Hi,
>
>
>
> I’d like to respectively request that our new charm sme be considered for
> promulgation to the charm store.
>
>
>
> https://jujucharms.com/u/storage-made-easy/sme/xenial/1
>
>
>
> Thanks,
>
> Steven
>
>
>
> [image:
> ttps://ci3.googleusercontent.com/proxy/nSxujEAVw9X420WUHPIBYcRjA22BecHwnLB0qX-2xlC8H9FM3et5uNacTODnhnMDf]
>
> *Steven Sweeting*. Director, Product Management
> Storage Made Easy  | Twitter: Storage Made
> Easy  | +1 510.213.0965 <(510)%20213-0965>
> Email: Steven Sweeting  | Blog:
> blog.storagemadeeasy.com | Skype
>
>
> The information in this e-mail and any files transmitted with it are
> confidential and are intended solely for the use of the addressee. Access
> to this e-mail by anyone else is unauthorized. If you are not the intended
> recipient any disclosure, copying and distribution of the information
> contained in this e-mail is prohibited. Although this e-mail has been
> checked for all known viruses, Vehera LTD cannot accept responsibility for
> any loss or damage arising from the use of this e-mail or its attachments.
> We keep personal data to be able to communicate with you. This can  include
> your name, email address, contact number, and may document the nature of
> any interactions we have had. If you wish to, unsubscribe
>  from further
> emails from Storage Made Easy. Please be aware that unsubscribing may
> generate a further email acknowledging your removal. Vehera Limited is a
> company registered in England. Registered Number: 07079346. The Registered
> address is Mulgrave Chambers, 26-28 Mulgrave Road, Sutton, Surrey SM2 6LE.
>
>
>
> --
> 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: promulgate ~tengu-team/openvpn

[Tim Van Steenburgh]

Done.

On Mon, Nov 20, 2017 at 8:01 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> ~tengu-team/openvpn is a promulgated charm, but I'm not able to push an
> update to the store:
>
> $ charm release cs:~tengu-team/openvpn-10
> ERROR cannot release charm or bundle: access denied for user
> "merlijn-sebrechts"
>
> Can we (tengu-team) get access to that charm? (merlijn-sebrechts is member
> of tengu-team)
>
>
>
> 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: charmhelpers migration to github

[Tim Van Steenburgh]

On Mon, Sep 18, 2017 at 6:22 AM, James Page  wrote:

> Resurrecting this thread; I think its a good time to push on with this
> work - anyone have any objections to targeting this week to complete the
> migration?
>

+1, no objections from me,  thanks James!


> On Fri, 21 Jul 2017 at 19:55 David Ames  wrote:
>
>> On Fri, Jul 21, 2017 at 5:46 AM, James Page 
>> wrote:
>> > Hi All
>> >
>> > Managed to find some time to test the bzr->git migration more, including
>> > some tidy of committers and other general hygiene.
>> >
>> >https://github.com/juju/charm-helpers
>> >
>> > I think we're in a good position to plan for a switch - I appreciate
>> there
>> > are a number of open reviews against the bzr branch for charmhelpers so
>> it
>> > would be nice to get those landed where possible first.
>> >
>> > I can re-run the process at any time so we can pick when we want to
>> actually
>> > switch over.
>> >
>> > Once we have migrated, we can push forward on travis setup etc... so
>> that we
>> > can automatically test pull requests.
>> >
>> > Cheers
>> >
>> > James
>>
>> I landed two of Alex's MPs today which fix unit test failures that
>> would need to get pulled in. Other than that, the road is clear from
>> the OpenStack Charm team.
>>
>> --
>> David Ames
>>
>
> --
> 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 layer index now on GitHub

[Tim Van Steenburgh]

Fantastic, this is a great change - well done!

On Fri, Sep 8, 2017 at 2:39 PM, Cory Johns  wrote:

> Greetings,
>
> Today we migrated the index of base and interface layers used to build
> charms over to the GitHub repository https://github.com/juju/layer-index.
> Hosting the index in GitHub provides better discoverability for layers, a
> better workflow for contributing layers, including more accountability for
> changes, and both more flexibility and more visibility with community
> contributions.  It also reduces our maintenance overhead and removes a
> point of failure.
>
> The change should be seamless to the build process, and the existing
> http://interfaces.juju.solutions/ site now redirects to the new repo.  An
> updated charm-build command is now in the edge channel which points
> directly to the new index, and the old site will eventually be taken down
> once that reaches the stable channel and some time has passed.
>
> I’m now happy to say, PRs welcome!
>
> --
> 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: Charm snap is now strictly confined

[Tim Van Steenburgh]

On Fri, Sep 8, 2017 at 2:44 PM, Tom Barber  wrote:

> good effort devs!
>

+1, thanks Cory.


>
> On 8 Sep 2017 7:42 pm, "Cory Johns"  wrote:
>
>> Greetings,
>>
>> I just wanted to make a quick announcement that the charm snap is now
>> strictly confined on the stable channel (rev 17).  This fixes issues like
>> https://github.com/juju/charm-tools/issues/339 and
>> https://github.com/juju/charm-tools/issues/319 and prevents similar
>> issues from cropping up in the future.
>>
>> In general, this change should be pretty much transparent, with the one
>> caveat being that you can only build charms from under your HOME directory.
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/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: We are excited to announce the release of Juju 2.2.3!

[Tim Van Steenburgh]

The new bundle stuff is very useful, thanks Juju devs!

On Fri, Sep 8, 2017 at 3:43 AM, Burton Swan 
wrote:

> ## New and Improved
>
> * The remove-machine command has a --keep-instance flag which allows the
> cloud instance to be left running when the machine is removed from the Juju
> model
>
> * Bundles can now reference local resources by specifying a relative path
> (as can already be done for local charms).
>
> * Values in local bundles for options and annotations can now specify a
> file to be read for the specified value. This is to support charm options
> where the value is some structured content, such as a configuration file.
> For binary external files, such as binary certificates, there is an option
> to base64 encode the contents of the file so it can be used as a string
> value. The referenced file can include the path to the file. The file
> location is relative to the bundle file location. e.g.:
>
> applications:
> my-app:
> charm: some-charm
> options:
> config: include-file://my-config.yaml
> cert: include-base64://my-cert.crt
>
> * There is a new option for deploying bundles: --bundle-config. This
> configuration file needs to be a YAML file, and currently only supports
> applications as a top level key. The format of the applications is the same
> as applications section in the bundle. Any values specified for an
> application in the bundle-config file override those values defined in the
> bundle, with the exception of the map type values, where the maps are
> merged with preference given to the bundle-config. The purpose of this to
> allow the use of a common bundle definition, and have model specific
> configuration kept in a separate file. Option and annotation values
> specified in the bundle-config file can also use the include-file:// and
> include-base64:// directives mentioned above for local bundles. Paths
> specified are relative to the bundle-config file.
>
>
> For a list of all bugs fixed in this release, see
> https://launchpad.net/juju/+milestone/2.2.3
>
> ## How can I get it?
>
> The best way to get your hands on this release of Juju is to install it as
> a snap package (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/
> stable/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.2/whats-new
>
> --
> 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 Kubernetes vSphere storage

[Tim Van Steenburgh]

On Thu, Sep 7, 2017 at 1:31 PM, Micheal B  wrote:

> Thanks!
>
>
>
> Stuck on
>
>
>
> Step-6 Add flags to controller-manager, API server and Kubelet to enable
> vSphere Cloud Provider. * Add following flags to kubelet running on every
> node and to the controller-manager and API server pods manifest files.
>
> --cloud-provider=vsphere
>
> --cloud-config=
>
>
>
>
>
> tried this .. did not make a difference
>
>
>

It's difficult to help because I don't know what steps were performed. You
may find it helpful to follow along with the steps here:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/402.
This give more detail about configuring the vsphere cloud provider in the
context of CDK.


> Configuring Masters
>
> Edit or create the master configuration file on all masters
> (/etc/origin/master/master-config.yaml by default) and update the
> contents of the apiServerArguments and controllerArguments sections with
> the following:
>
>
>
> kubernetesMasterConfig:
>
>   admissionConfig:
>
> pluginConfig:
>
>   {}
>
>   apiServerArguments:
>
> cloud-provider:
>
> - "vsphere"
>
> cloud-config:
>
> - "/etc/vsphere/vsphere.conf"
>
>   controllerArguments:
>
> cloud-provider:
>
> - "vsphere"
>
> cloud-config:
>
> - "/etc/vsphere/vsphere.conf"
>
> When triggering a containerized installation, only the /etc/origin and
> /var/lib/origin directories are mounted to the master and node container.
> Therefore, master-config.yaml must be in /etc/origin/master rather than
> /etc/.
>
> Configuring Nodes
>
> Edit or create the node configuration file on all nodes
> (/etc/origin/node/node-config.yaml by default) and update the contents of
> the kubeletArguments section:
>
>
>
> kubeletArguments:
>
>   cloud-provider:
>
> - "vsphere"
>
>   cloud-config:
>
>     - "/etc/vsphere/vsphere.conf"
>
> When triggering a containerized installation, only the /etc/origin and
> /var/lib/origin directories are mounted to the master and node container.
> Therefore, node-config.yaml must be in /etc/origin/node rather than /etc/.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From: *Tim Van Steenburgh 
> *Date: *Thursday, September 7, 2017 at 6:33 AM
> *To: *Micheal B 
> *Cc: *juju 
> *Subject: *Re: Juju Kubernetes vSphere storage
>
>
>
> Hi Micheal,
>
>
>
> Have you enabled the vsphere cloud provider for kubernetes as documented
> here: https://kubernetes.io/docs/getting-started-guides/vsphere/ ?
>
>
>
> Tim
>
>
>
> On Thu, Sep 7, 2017 at 4:06 AM, Micheal B  wrote:
>
> While working through -- https://github.com/kubernetes/
> examples/tree/master/staging/volumes/vsphere
>
>
>
> To test the different storage types on my vSphere lab I seem to either
> have a bug or am no able to copy and paste some code ☺
>
>
>
> None work. All get pretty close to the same error.
>
>
>
>
>
> MountVolume.SetUp failed for volume "test-volume" : mount failed: exit
> status 32 Mounting command: mount Mounting arguments:
> /var/lib/kubelet/plugins/kubernetes.io/vsphere-volume/mounts/[DS_TICTOC01]
> <http://kubernetes.io/vsphere-volume/mounts/%5BDS_TICTOC01%5D>
> volumes/myDisk /var/lib/kubelet/pods/aa94ec10-9349-11e7-a663-
> 005056a192ad/volumes/kubernetes.io~vsphere-volume/test-volume [bind]
> Output: mount: special device /var/lib/kubelet/plugins/kuber
> netes.io/vsphere-volume/mounts/[DS_TICTOC01]
> <http://kubernetes.io/vsphere-volume/mounts/%5BDS_TICTOC01%5D>
> volumes/myDisk does not exist
>
>
>
> Unable to mount volumes for pod 
> "test-vmdk_default(aa94ec10-9349-11e7-a663-005056a192ad)":
> timeout expired waiting for volumes to attach/mount for pod
> "default"/"test-vmdk". list of unattached/unmounted volumes=[test-volume]
>
>
>
>
>
>
>
> The volume is there /volume/myDisk.vmdk for the first test and the auto
> create volume also fails. Tested using the paths
>
>
>
> From datastore cluster + datastore to /vmfs/volumes/55b828da-
> b978a6d4-6619-002655e59984/volumes
>
>
>
> datastore: DS_TICTOC01/volumes
>
> datastore: ticsdata/DS_TICTOC01/volumes
>
>
>
> My user making the connection is the default Admininistrator and have used
> it for years to create other assorted vm’s so I know that good.  No error
> in vsphere vcenter either.
>
>
>
> I am using vSphere 6.1 / Kubernetes 1.7 / vSphere DRS is enabled using
> local drives to create the DS Cluster. JUJU had no issues deploying to
> them.
>
>
>
> What am I missing or could try?
>
>
>
> Cheers
>
>
>
>
>
> Micheal
>
>
>
>
>
>
>
>
>
>
> --
> 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 Kubernetes vSphere storage

[Tim Van Steenburgh]

Hi Micheal,

Have you enabled the vsphere cloud provider for kubernetes as documented
here: https://kubernetes.io/docs/getting-started-guides/vsphere/ ?

Tim

On Thu, Sep 7, 2017 at 4:06 AM, Micheal B  wrote:

> While working through -- https://github.com/kubernetes/
> examples/tree/master/staging/volumes/vsphere
>
>
>
> To test the different storage types on my vSphere lab I seem to either
> have a bug or am no able to copy and paste some code ☺
>
>
>
> None work. All get pretty close to the same error.
>
>
>
>
>
> MountVolume.SetUp failed for volume "test-volume" : mount failed: exit
> status 32 Mounting command: mount Mounting arguments:
> /var/lib/kubelet/plugins/kubernetes.io/vsphere-volume/mounts/[DS_TICTOC01]
> 
> volumes/myDisk /var/lib/kubelet/pods/aa94ec10-9349-11e7-a663-
> 005056a192ad/volumes/kubernetes.io~vsphere-volume/test-volume [bind]
> Output: mount: special device /var/lib/kubelet/plugins/kuber
> netes.io/vsphere-volume/mounts/[DS_TICTOC01]
> 
> volumes/myDisk does not exist
>
>
>
> Unable to mount volumes for pod 
> "test-vmdk_default(aa94ec10-9349-11e7-a663-005056a192ad)":
> timeout expired waiting for volumes to attach/mount for pod
> "default"/"test-vmdk". list of unattached/unmounted volumes=[test-volume]
>
>
>
>
>
>
>
> The volume is there /volume/myDisk.vmdk for the first test and the auto
> create volume also fails. Tested using the paths
>
>
>
> From datastore cluster + datastore to /vmfs/volumes/55b828da-
> b978a6d4-6619-002655e59984/volumes
>
>
>
> datastore: DS_TICTOC01/volumes
>
> datastore: ticsdata/DS_TICTOC01/volumes
>
>
>
> My user making the connection is the default Admininistrator and have used
> it for years to create other assorted vm’s so I know that good.  No error
> in vsphere vcenter either.
>
>
>
> I am using vSphere 6.1 / Kubernetes 1.7 / vSphere DRS is enabled using
> local drives to create the DS Cluster. JUJU had no issues deploying to
> them.
>
>
>
> What am I missing or could try?
>
>
>
> Cheers
>
>
>
>
>
> Micheal
>
>
>
>
>
>
>
>
>
> --
> 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 backup yaml

[Tim Van Steenburgh]

Hi Micheal,

1. The topology of the cluster is encoded as yaml in the bundle itself,
e.g.
https://api.jujucharms.com/charmstore/v5/~containers/bundle/canonical-kubernetes/archive/bundle.yaml
2. The yaml for the objects deployed in your cluster are typically kept in
your own source control repo.
3. The state of the cluster is stored in etcd and can be backed up and
restored using the etcd snapshot/restore actions documented here:
https://kubernetes.io/docs/getting-started-guides/ubuntu/backups/#exporting-etcd-data

Hope this helps,

Tim

On Tue, Sep 5, 2017 at 4:16 PM, Micheal B  wrote:

> Is there a way to extract your current cluster config to a YAML file for a
> redeployment?
>
> --
> 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: External IP's

[Tim Van Steenburgh]

Hi Micheal,

You don't get the external IP automatically because the k8s cloud-provider
flag is not automatically set to vsphere for you (yet).

When you deploy to AWS with conjure-up, we set the k8s cloud-provider for
you so that you can use AWS features like ELBs and EBS. We intend to add
this native-cloud integration for vsphere also, but haven't yet. So for now
you'd need to do it manually. More info here:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/402

Hope that helps,
Tim

On Tue, Sep 5, 2017 at 7:31 PM, Micheal B  wrote:

> My lab is juju using vsphere kubernetes - https://jujucharms.com/docs/2.
> 1/help-vmware - my nodes all get their IP’s and DNS from a local domain
> server and tested used using the - https://kubernetes.io/docs/
> concepts/services-networking/dns-pod-service/
>
> All of the Nodes Master and worker have 8GB Mem, 30GB of disk space as
> well. The VMware environment is my main lab and it’s well established, I do
> allot of testing ☺
>
>
>
>
>
> So as far as I know everything looks good and the logs seem happy on the
> DNS side. I did have to adjust my DHCP Server some and the deployment
> script to use the server but other than that it seems to be fine.  It’s
> part of the reason I am looking for a way to build a deployment YAML file
> out of my current running environment so I can change settings without
> redepoloying and having to redo all of the DNS Server names etc.
>
>
>
> But when I start testing using this - https://kubernetes.io/docs/
> tutorials/stateless-application/expose-external-ip-address/
>
>
>
> I never get an external IP Address – I have been through several documents
> and test some ingress and such still not getting an IP automatically
>
>
>
> Now if I do the same above but add in
>
>
>
> kubectl expose deployment hello-world --type=LoadBalancer
> --external-ip=192.168.0.162 --name=my-service  – set the
> externalip= is one of my worker nodes then I can hit the deployment fine.
>
>
>
> So what else am I missing?
>
>
>
>
>
> Cheers
>
>
>
> Micheal
>
>
>
>
>
> --
> 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: Promulgate request: InfluxDB

[Tim Van Steenburgh]

Done.

On Tue, Sep 5, 2017 at 11:55 AM, Tom Haddon 
wrote:

> Hi Folks,
>
> Could we get cs:~influxdb-charmers/influxdb promulgated?
>
> The code for the charm is https://code.launchpad.net/influxdb-charm and
> there's
> a team that maintains it https://launchpad.net/~influxdb-charmers. The
> charm
> supports trusty and xenial.
>
> If anyone is interested in joining the team to help maintain the influxdb
> charm please let us know.
>
> Thanks, Tom
>
> --
> 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: Promulgate request: Apache2

[Tim Van Steenburgh]

Done.

On Mon, Sep 4, 2017 at 5:35 AM, Tom Haddon  wrote:

> Hi Folks,
>
> Could we get cs:~apache2-charmers/apache2 promulgated?
>
> The code for the charm is https://code.launchpad.net/apache2-charm and
> there's
> a team that maintains it https://launchpad.net/~apache2-charmers. The
> charm
> supports trusty and xenial.
>
> The current owner of cs:apache2 is ~ack (cc-ed), and I've spoken to him
> about
> this charm migrating to team ownership and he's happy for us to do so.
>
> If anyone is interested in joining the team to help maintain apache2 please
> let us know.
>
> Thanks, Tom
>
> --
> 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: PostgreSQL PITR

[Tim Van Steenburgh]

Awesome feature and write-up, thanks Stuart!

On Fri, Sep 1, 2017 at 10:28 AM, Stuart Bishop 
wrote:

> Hi.
>
> The PostgreSQL charm has some point in time recovery features we have
> been using on production. I've put together a walk through of the
> feature for others who might be interested in using it directly, or to
> provide inspiration for other charms wanting to encode more
> operational procedures.
>
> https://stubish.wordpress.com/2017/09/01/postgresql-point-
> in-time-recovery-with-juju/
>
>
> --
> Stuart Bishop 
>
> --
> 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: kubectl run

[Tim Van Steenburgh]

This works for me:

kubectl run -it db2express-c --port=5 --env DB2INST1_PASSWORD=db2inst1
--env LICENSE=accept --image ibmcom/db2express-c:latest -- bash

On Thu, Aug 31, 2017 at 3:17 PM, Micheal B  wrote:

> Trying to convert a Docker run to kubectl
>
>
>
> Working thru
>
>
>
> https://hub.docker.com/r/ibmcom/db2express-c/
>
>
>
> docker run -it -p 5:5 -e DB2INST1_PASSWORD=db2inst1-pwd -e
> LICENSE=accept ibmcom/db2express-c:latest bash
>
>
>
>
>
> in Docker I have it running great just need to figure out the Kubectl run
> translation
>
>
>
> I thought that
>
> kubectl run db2express-c --image=db2express-c --port=5 --command -e
> DB2INST1_PASSWORD=db2inst1 -e LICENSE=accept ibmcom/db2express-c:latest
> bash --generator=run-pod/v1
>
>
>
> but that fails…
>
>
>
>
>
> thanks
>
>
>
> Micheal
>
> --
> 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: Elasticsearch Charm Promulgation

[Tim Van Steenburgh]

It's been promulgated, thanks!

On Wed, Aug 30, 2017 at 7:08 PM, Haw Loeung 
wrote:

> On Wed, Aug 30, 2017 at 02:38:42PM -0400, Tim Van Steenburgh wrote:
> > I checked with James Beedy and he's +1 on promulgating this one too.
> >
> > Looks like there's no bugs-url or homepage set on the charm though.
> Please
> > add those (see `charm set -h`) and then I'll be happy to promulgate it.
>
> I've updated the two:
>
> | $ charm show cs:~elasticsearch-charmers/elasticsearch bugs-url homepage
> | bugs-url: https://bugs.launchpad.net/elasticsearch-charm
> | homepage: https://launchpad.net/elasticsearch-charm
>
>
> Regards,
>
> Haw
>
> --
> 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 Charmer application

[Tim Van Steenburgh]

Thanks Frode, welcome to ~charmers!

On Wed, Aug 30, 2017 at 4:10 PM, David Ames 
wrote:

> Huge +1
>
> On Wed, Aug 30, 2017 at 3:14 AM, Frode Nordahl 
> wrote:
> > Dear Juju community,
> >
> > I would like to officially apply for membership of the Juju ~charmers
> team.
> >
> > Through the course of the past year I have made contributions to the
> > OpenStack Charms and other Charm projects. I have also had the privilege
> of
> > meeting many of you in person, and have shared fruitful exchanges. I have
> > signed the Ubuntu Code of Conduct.
> >
> > Before playing around with Juju I have had a long career in tech from
> which
> > I have experience with both operations and development of system level
> code.
> > I particularly like having my code well tested to make sure it keeps on
> > running in the future.
> >
> > Some examples of my charm-related work:
> > https://github.com/openstack/charm-neutron-openvswitch/commit/
> 4ffbc2fe25400abf55719a370f3a2cd37f90c99d
> > https://github.com/openstack/charm-rabbitmq-server/commit/
> 08b10513c5725fb740382668c47fc769a6f2936c
> > https://github.com/marcoceppi/charm-mysql/commit/
> cefb77fafcd1ee36d4dc30c14d07aa857d5273a2
> > https://github.com/marcoceppi/charm-mysql/commit/
> 1a8277855be4020b26121cb9d573cd150b6aa882
> > https://github.com/openstack/charm-ceph-radosgw/commit/
> 7fa6639ab3fde7dc89131fb204f018fd4339e82f
> > https://github.com/openstack/charm-keystone/commit/
> 5de1770931e886732870da1909f08279a0b804b4
> > https://github.com/openstack/charm-nova-cloud-controller/commit/
> 2eef644a5c1acb2675e94908c88182658fec4ac5
> > https://github.com/openstack/charm-openstack-dashboard/commit/
> 8f3a93ac4e7102736da492a189144220312f93df
> > https://github.com/openstack/charm-swift-proxy/commit/
> 7c24ae81283710c830ab03f240ec9cc10dccd975
> >
> > Launchpad ID: fnordahl
> >
> > --
> > Frode Nordahl
> >
> > --
> > 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: Elasticsearch Charm Promulgation

[Tim Van Steenburgh]

On Wed, Aug 30, 2017 at 6:27 AM, Haw Loeung 
wrote:

> On Tue, Aug 22, 2017 at 08:54:14AM +0100, Tom Haddon wrote:
> > On Mon, Aug 21, 2017 at 02:53:10PM +0100, Tom Haddon wrote:
> > [...]
> > > I checked with some of the ~onlineservices-charmers team and they were
> happy
> > > for https://jujucharms.com/u/elasticsearch-charmers/elasticsearch/ to
> replace
> > > the current promulgated charm (which only supports precise and
> trusty). We
> > > should test that you can successfully charm upgrade from theirs to
> this charm
> > > (on trusty) - I'm happy to take that on, and will update here once
> we've done
> > > so.
> >
> > I've tested an upgrade on trusty from the existing upstream elasticsearch
> > charm to cs:~elasticsearch-charmers/trusty/elasticsearch and it seems
> to work
> > okay:
> >
> > https://pastebin.ubuntu.com/25368096/
> >
>
> I've confirmed that the existing charm also supports ElasticSearch 5.x
> (thanks to all the hard work from Ante).
>
> Any chance we could get cs:~elasticsearch-charmers/elasticsearch
> promulgated to cs:elasticsearch now?
>

I checked with James Beedy and he's +1 on promulgating this one too.

Looks like there's no bugs-url or homepage set on the charm though. Please
add those (see `charm set -h`) and then I'll be happy to promulgate it.


>
>
> Thanks,
>
> Haw
>
> --
> 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: Promulgate request: Grafana

[Tim Van Steenburgh]

Done, thanks!

On Wed, Aug 30, 2017 at 4:38 AM, Tom Haddon 
wrote:

> Hi Folks,
> Could we get cs:~prometheus-charmers/grafana promulgated?
>
> The code for the charm is https://code.launchpad.net/grafana-charm and
> there's
> a team that maintains it https://launchpad.net/~prometheus-charmers. That
> team
> already maintains a number of other promulgated charms (mtail, prometheus,
> prometheus-alertmanager, prometheus-push-gateway and
> prometheus-blackbox-exporter). The grafana charm supports trusty and
> xenial.
>
> If anyone is interested in joining the team to help maintain grafana and
> those
> other charms please let us know.
>
> Thanks, Tom
>
> --
> 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: Promulgate request: Graylog

[Tim Van Steenburgh]

Done, thanks!

On Thu, Aug 24, 2017 at 11:13 PM, Haw Loeung 
wrote:

> Hi All,
>
> Could I get cs:~graylog-charmers/graylog promulgated?
>
> We're using it internally will maintain it.
>
> It's also set up as a new team in Launchpad so we could add community
> members on request.
>
>
> Regards,
>
> Haw
>
> --
> 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: Elasticsearch Charm Promulgation

[Tim Van Steenburgh]

Hey James, my point was that if you want to replace the existing top-level
ES charm with your own, we would need agreement from the maintainers of the
existing charm.

On Mon, Aug 14, 2017 at 12:45 PM, James Beedy  wrote:

> @tim yeah ... possibly I'm not looking for promulgation then, and just
> need to push it and grant everyone because its already promulgated?
>
> On Mon, Aug 14, 2017 at 9:29 AM, Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> There's already a top-level elasticsearch charm. https://jujucharms.com/
>> elasticsearch/
>>
>> On Mon, Aug 14, 2017 at 12:13 PM, James Beedy 
>> wrote:
>>
>>> Request for promulgation of Elasticsearch. The Elasticsearch charm can
>>> be found at cs:~jamesbeedy/elasticsearch-7.
>>>
>>> Thanks,
>>>
>>> James
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Elasticsearch Charm Promulgation

[Tim Van Steenburgh]

There's already a top-level elasticsearch charm.
https://jujucharms.com/elasticsearch/

On Mon, Aug 14, 2017 at 12:13 PM, James Beedy  wrote:

> Request for promulgation of Elasticsearch. The Elasticsearch charm can be
> found at cs:~jamesbeedy/elasticsearch-7.
>
> Thanks,
>
> James
>
> --
> 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: Future of the Charm Review Queue

[Tim Van Steenburgh]

Not that I'm aware of, but it can't hurt to open a github issue for that
idea.

On Fri, Aug 4, 2017 at 2:40 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Are there any plans to let users assess the "quality" of a charm in a
> different way? Like showing the amount of (successful) deploys or smth?
>
> On Aug 4, 2017 16:21, "Tim Van Steenburgh"  com> wrote:
>
>> Hi All,
>>
>> I wanted to send a note about some changes in the way we handle charm
>> reviews and the top-level namespace of the charm store. We’ve taken a look
>> at what’s happened in the past and where we want to get to and decided that
>> a much more lightweight process is the way forward.
>>
>> The biggest change is actually the sunsetting of the charm review queue.
>> The reality is the process as it stands cannot keep up with the demand for
>> reviews. We’ve decided to take a community curation approach.
>>
>> A charm review is no longer a prerequisite for promulgation to the
>> top-level namespace of the charm store. If you would like your charm
>> promulgated, and the name is available, you may simply request promulgation
>> on this mailing list. A member of the ~charmers Launchpad group will then:
>>
>>
>>1.
>>
>>Download your charm using `charm pull`
>>2.
>>
>>Run `charm proof` on your charm
>>3.
>>
>>Ensure you have `charm set` a bugs-url and homepage
>>4.
>>
>>If 2 or 3 fails, the charmer will request an update to the charm
>>5.
>>
>>`charm promulgate` the charm (or request that #2-3 be fixed)
>>6.
>>
>>`charm grant` you write access on the promulgated charm
>>
>>
>> Some things to keep in mind as a charm author:
>>
>>
>>1.
>>
>>It is your responsibility as the charm author and maintainer to test
>>your charm and ensure its quality and security.
>>2.
>>
>>Promulgation to the top level does not imply endorsement by Canonical.
>>3.
>>
>>Charm authors are encouraged to use their personal or group
>>namespace. Although promulgation is still available, there is nothing 
>> wrong
>>with using personal and group namespaces.
>>
>>
>> For those seeking assistance with charm development, members of ~charmers
>> and other proficient charm developers are available in #juju on Freenode
>> IRC and on this mailing list. Discontinuing the formal charm review process
>> does not in any way decrease the availability of or access to these
>> resources. If you need help, just ask!
>>
>> In the coming weeks, the docs at jujucharms.com will be updated to
>> reflect these changes. The review queue (review.jujucharms.com) will be
>> shut down, and all open reviews will be closed with a comment/email linking
>> to this explanatory post. Anyone with an open review that still desires
>> promulgation can request it with an email to this list.
>>
>> If you have any questions or concerns, please reply to this post!
>>
>> Thanks,
>>
>> Tim Van Steenburgh
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgate request: dokuwiki

[Tim Van Steenburgh]

Done.

On Fri, Aug 4, 2017 at 9:51 PM, Adam Stokes 
wrote:

> Hi,
>
> Could I get cs:~adam-stokes/dokuwiki-32 promulgated?
>
> Thanks!
> Adam
>
> --
> 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

Future of the Charm Review Queue

[Tim Van Steenburgh]

Hi All,

I wanted to send a note about some changes in the way we handle charm
reviews and the top-level namespace of the charm store. We’ve taken a look
at what’s happened in the past and where we want to get to and decided that
a much more lightweight process is the way forward.

The biggest change is actually the sunsetting of the charm review queue.
The reality is the process as it stands cannot keep up with the demand for
reviews. We’ve decided to take a community curation approach.

A charm review is no longer a prerequisite for promulgation to the
top-level namespace of the charm store. If you would like your charm
promulgated, and the name is available, you may simply request promulgation
on this mailing list. A member of the ~charmers Launchpad group will then:


   1.

   Download your charm using `charm pull`
   2.

   Run `charm proof` on your charm
   3.

   Ensure you have `charm set` a bugs-url and homepage
   4.

   If 2 or 3 fails, the charmer will request an update to the charm
   5.

   `charm promulgate` the charm (or request that #2-3 be fixed)
   6.

   `charm grant` you write access on the promulgated charm


Some things to keep in mind as a charm author:


   1.

   It is your responsibility as the charm author and maintainer to test
   your charm and ensure its quality and security.
   2.

   Promulgation to the top level does not imply endorsement by Canonical.
   3.

   Charm authors are encouraged to use their personal or group namespace.
   Although promulgation is still available, there is nothing wrong with using
   personal and group namespaces.


For those seeking assistance with charm development, members of ~charmers
and other proficient charm developers are available in #juju on Freenode
IRC and on this mailing list. Discontinuing the formal charm review process
does not in any way decrease the availability of or access to these
resources. If you need help, just ask!

In the coming weeks, the docs at jujucharms.com will be updated to reflect
these changes. The review queue (review.jujucharms.com) will be shut down,
and all open reviews will be closed with a comment/email linking to this
explanatory post. Anyone with an open review that still desires
promulgation can request it with an email to this list.

If you have any questions or concerns, please reply to this post!

Thanks,

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

Re: Application of Membership for Charmers

[Tim Van Steenburgh]

+1 and approved, thanks Billy.

On Fri, Jul 21, 2017 at 8:41 AM, Billy Olsen 
wrote:

> Hello Charmers,
>
> My name is Billy Olsen and I've been a long time contributor to the
> OpenStack Charms, going back 3 years now. I'm currently a core member of
> the OpenStack charming community and have additionally made contributions
> of code and review effort to the charm-helpers library.
>
> I believe that I can provide a positive contribution in the overall
> charming ecosystem.
>
> Thanks,
>
> Billy
>
> --
> 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

[ANN] Canonical Distribution of Kubernetes 1.7 is here!

[Tim Van Steenburgh]

Hi everyone,

We’re proud to announce support for Kubernetes 1.7 in the Canonical
Distribution of Kubernetes. This release includes the latest upstream
version of Kubernetes, along with various fixes and improvements to the
charms which comprise the Kubernetes bundles.

Here’s the simplest way to get a Kubernetes 1.7 cluster up and running:

# on linux
sudo snap install conjure-up --classic
conjure-up kubernetes

# on macOS
brew install conjure-up
conjure-up kubernetes

For full release details, along with instructions for upgrading from a
prior version, see the official release announcement at
https://insights.ubuntu.com/2017/07/07/kubernetes-1-7-on-ubuntu/.

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

Re: juju test doesn't work

[Tim Van Steenburgh]

>
> But, I couldn't. The review form at https://review.jujucharms.com/ will
> respond with a empty response (Firefox says https protocol error. Chrome
> says empty response.)
> Where would I report that as a bug?
>
>
There's a "report bug" link at the bottom of the review queue web pages. I
went ahead and filed a bug for the problem you're hitting:
https://github.com/juju-solutions/review-queue/issues/86
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: database-relation-join not invoked

[Tim Van Steenburgh]

On Thu, May 25, 2017 at 12:59 PM, Giuseppe Attardi  wrote:

> I have written a charm for OpenStack Gnocchi.
> The service requires a postgresql database relation.
>
> The start hook fails, of course, because the relation is not set.
>
> I expected that, but I expected that when I issue
>
> juju add-relation gnocchi postgresql:db
>
> it will invoke the database-relation-joined hook, which does set the
> required parameter and then start would work.
> However the hook is not invoked: as a sanity check I set a juju-log
> message in it and it does not run at all.
>
> Is it correct to assume that add-relation will always trigger
> database-relation-join?
>

Yes it will. Assuming your relation is named 'database', then the
database-relation-joined will be triggered when that relation is
established. For more help debugging you may need to post a link to your
code.


> A second question, I would like to avoid to start the service until the
> relation has been joined.
> What is the best way to test for the relation to be present?
>

You should start the service in the database-relation-changed hook handler,
once you have received all necessary relation data.


>
> I tried with
>
> db=`relation-get -r database host`
>
> but it fails with:
>
> INFO start error: invalid value "database" for flag -r: invalid
> relation id
>
> I am using juju-2.1.2
>
> Thanks for the help.
>
> — Beppe Attardi
> --
> 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: Migrating charmhelpers to github

[Tim Van Steenburgh]

+1 from me, especially since James is volunteering. :D  Thanks for getting
this ball rolling!

On Thu, May 25, 2017 at 8:57 AM, James Page  wrote:

> Hi Charmers
>
> There has been a bubbling undercurrent of desire to move charmhelpers code
> hosting out of bazaar on Launchpad to git on github,com alongside other
> charm ecosystem development tooling.
>
> I'd like to get the code migrated over ASAP and then we can start enabling
> automatic PR testing and suchlike which we lack in LP at the moment.
>
> Anyone got any objections?
>
> This will of course impact anyone currently syncing charmhelpers into
> their charm, but that's not a hard problem to solve.
>
> Cheers
>
> James
>
> --
> 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

[Tim Van Steenburgh]

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:
>>>
>>> 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/mailm
>>> an/listinfo/juju
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/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

[Tim Van Steenburgh]

Yeah, and it also doesn't list any p2 types in the list of valid values.
I'm not sure why. IIRC, 2.1 introduced a querying-clouds-for-instance-types
feature - I wonder if that could be related.

I might just drop back to 2.0 and see if it works there. Sam, curious if
you've tried a p2 with 2.1?

On Tue, Mar 14, 2017 at 9:09 AM, Samuel Cozannet <
samuel.cozan...@canonical.com> wrote:

> It is weird, it fails because it doesn't recognize the instance type in
> the constraint.
>
> I haven't seen that in the past, though to spin more than one you need to
> ask to upgrade your quota.
>
> ++
> Sam
>
> On Mar 14, 2017 13:48, "Tim Van Steenburgh"  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]
>>
>>
>> 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/mailm
>> an/listinfo/juju
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Tim Van Steenburgh]

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]


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

ICYMI: Intro to python-libjuju on The Juju Show #4

[Tim Van Steenburgh]

Hi everyone,

The most recent episode of The Juju Show features an introduction to the
new python library for Juju. The libjuju segment of the show is about 20
minutes long and starts here:

https://youtu.be/Lsbo7f7yMxY?t=14m

If you're interested in interacting with Juju from Python, check it out!
The video gives an intro to the library, it's design and requirements, and
concludes with a brief demo showing the library in action. In between, we
do some libjuju Q&A, and talk to community member James Beedy about how
he's using libjuju in his CI pipeline.

In the video, a question is raised regarding how Juju version changes will
be handled by libjuju. That discussion has been moved here:
https://lists.ubuntu.com/archives/juju/2017-January/008477.html

I'll be giving another talk on libjuju at Config Management Camp in a
couple weeks: http://cfgmgmtcamp.eu/schedule/juju/tim-van-steenburgh.html

For more info, or to get involved with libjuju development, see the source
repo and documentation here:

https://github.com/juju/python-libjuju
https://pythonhosted.org/juju/

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

Re: Versioning of libjuju

[Tim Van Steenburgh]

Yeah, thanks for bringing this up. I think that your strawman is the
correct approach. To make this happen we really just need to keep the old
facade versions around instead of blowing them away every time we
regenerate the facades for a new version of juju.

On Wed, Jan 18, 2017 at 2:38 PM, Adam Collard 
wrote:

> Hi all,
>
> Something that came up at today's Juju Show[0] was how versioning of
> libjuju should work. Should we have 1:1 releases of libjuju with associated
> Juju's (I'm -1 - it could get very messy very quickly) or can we have one
> libjuju version talking with multiple Juju versions?
>
> As far as I understand it, the way that libjuju uses generated code from
> the Golang source makes it non-trivial to generate dynamically from a
> remote connection.
>
> Strawman: what if we split the current generated blob[1] into each facade,
> and further into each facade version. libjuju is constantly updated with
> the stubs of latest facade version from Juju releases as they come out.
> When libjuju connects, it does a negotiation to work out what's the latest
> facade version that both it and the remote API know about.
>
> Thoughts?
>
> Adam
>
> [0] https://www.youtube.com/watch?v=Lsbo7f7yMxY
> [1] https://github.com/juju/python-libjuju/blob/master/
> juju/client/_client.py
>
>
> --
> 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: Amulet doesn't find deployed units

[Tim Van Steenburgh]

You're right, deployment.add() isn't needed - the sentries get parsed out
of the real-time
Juju status.

Are you sure the bundle is actually being deployed before your test is run?
You can pass
-vl DEBUG for more verbose output.

I wonder if you need to set "bundle_deploy: true" instead of
"bundle_deploy: True"
in your tests.yaml.

On Mon, Jan 16, 2017 at 1:14 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Tim
>
> The tests for the kubernetes-core bundle
> <https://api.jujucharms.com/charmstore/v5/kubernetes-core/archive/tests/20-basic-component-check.py>
> don't do `deployment.add..`. I thought that bundle was a good start for my
> tests since the bundle is promulgated.. Does this mean that the tests for
> that bundle also won't work?
>
> I added those two lines, and now I'm having the following error. The url
> itself seems wrong the Charm I'm testing isn't promulgated. The bundle
> itself should be correct since bundletester deployed the bundle
> correctly..  You can see the bundle here: https://github.com/
> IBCNServices/bundle-limeds-core
>
> bundles/limeds-core$ bundletester
> bundle
> charm-proof
>  PASS
> 20-basic-check.py
>  ERROR
>
> 
> --
> ERROR: bundle::20-basic-check.py
> [/tmp/bundletester-gIybTn/limeds-core/tests/20-basic-check.py exit 1]
> E
> ==
> ERROR: setUpClass (__main__.TestBundle)
> --
> Traceback (most recent call last):
>   File "/usr/local/lib/python3.5/dist-packages/theblues/charmstore.py",
> line 58, in _get
> response.raise_for_status()
>   File "/usr/local/lib/python3.5/dist-packages/requests/models.py", line
> 893, in raise_for_status
> raise HTTPError(http_error_msg, response=self)
> requests.exceptions.HTTPError: 404 Client Error: Not Found for url:
> https://api.jujucharms.com/v4/xenial/docker/meta/any?
> include=bundle-machine-count&include=bundle-metadata&
> include=bundle-unit-count&include=bundles-containing&
> include=charm-actions&include=charm-config&include=charm-
> metadata&include=common-info&include=extra-info&include=
> revision-info&include=stats&include=supported-series&
> include=manifest&include=tags&include=promulgated&include=perm&include=id
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File "/tmp/bundletester-gIybTn/limeds-core/tests/20-basic-check.py",
> line 18, in setUpClass
> cls.deployment.add('docker')
>   File "/usr/local/lib/python3.5/dist-packages/amulet/deployer.py", line
> 208, in add
> service_name, charm, branch=branch, series=service['series'])
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 57,
> in fetch
> series=series)
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 42,
> in get_charm
> return Charm(with_series(charm_path, series))
>   File "/usr/local/lib/python3.5/dist-packages/charmstore/lib.py", line
> 165, in __init__
> super(Charm, self).__init__(id, api=api, timeout=timeout)
>   File "/usr/local/lib/python3.5/dist-packages/charmstore/lib.py", line
> 115, in __init__
> AVAILABLE_INCLUDES).get('Meta')
>   File "/usr/local/lib/python3.5/dist-packages/theblues/charmstore.py",
> line 107, in _meta
> data = self._get(url)
>   File "/usr/local/lib/python3.5/dist-packages/theblues/charmstore.py",
> line 62, in _get
> raise EntityNotFound(url)
> theblues.errors.EntityNotFound: https://api.jujucharms.com/v4/
> xenial/docker/meta/any?include=bundle-machine-count&
> include=bundle-metadata&include=bundle-unit-count&
> include=bundles-containing&include=charm-actions&include=
> charm-config&include=charm-metadata&include=common-info&
> include=extra-info&include=revision-info&include=stats&
> include=supported-series&include=manifest&include=tags&
> include=promulgated&include=perm&include=id
>
> --
> Ran 0 tests in 0.096s
>
> FAILED (errors=1)
>
> PASS: 1 ERROR: 1 Total: 2 (1.032546 sec)
>
>
>
> 2017-01-16 18:52 GMT+01:00 Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com>:
>
>> You need to define the services in the deployment, even if they are
>> already deployed
>

Re: Amulet doesn't find deployed units

[Tim Van Steenburgh]

You need to define the services in the deployment, even if they are already
deployed
by bundletester. So for example:

cls.deployment.add('docker')
cls.deployment.add('limeds')

On Mon, Jan 16, 2017 at 10:15 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi all
>
>
> Code: https://github.com/IBCNServices/bundle-limeds-
> core/blob/master/tests/20-basic-check.py
>
> I'm basing these tests off of the kubernetes core bundle. I want to rely
> on bundletester to deploy the bundle and then use the deployed applications
> to run tests.
>
> When I run these tests, Amulet doesn't seem to find the deployed units.
>
> code:
>
> cls.docker = cls.deployment.sentry['docker']
> cls.limeds = cls.deployment.sentry['limeds']
> print("docker: {}".format(cls.docker))
> for unit in cls.docker:
> print(unit.info['public-address'])
> print("limeds: {}".format(cls.limeds))
> for unit in cls.limeds:
> print(unit.info['public-address'])
> output:
>
> docker: []
> limeds: []
>
>
> I expected both docker and limeds to contain one unit, since they are
> indeed deployed.
>
> docker/0* active   idle   154.85.195.24
>  30001/tcp,30002/tcp  Ready
> limeds/0* active   idle   154.85.195.24
>   Ready. (ibcndevs/limeds)
>
>
> What am I doing wrong?
>
>
>
> 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

[ANN] First release of new Python library for Juju

[Tim Van Steenburgh]

Hi everyone,

v0.1.0 of the new 'juju' library for Python has been released. Installation
instructions and documentation are available at
https://pythonhosted.org/juju/.

There is still plenty to do, but a number of people and projects are
already using the library in its current form. Please kick the tires and
provide feedback. If a feature that you need is missing, please file a bug.
If the docs are confusing or lacking, please file a bug. All bug reports
(and other contributions) are welcomed.

I'll be giving a talk (Driving Juju with Python) demonstrating the library
at Config Management Camp 2017 in Gent in February.

Watch this space for future release announcements!

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

Re: Issues with amulet tests

[Tim Van Steenburgh]

Yeah, you might be stuck for the moment. The current version of jujuclient
only
supports user/pass authentication. It looks like your model requires
macaroon
auth, which hasn't been added to jujuclient yet. I have the most of the
changes
ready but they haven't been merged/released yet.

On Tue, Dec 6, 2016 at 6:07 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Still the same error with the newest version (0.53.3+bzr96+41~ubuntu16.04.1).
> I'm running the tests on an existing model on a MAAS controller. I can't
> run the tests locally since OpenVPN doesn't work in LXD containers.
>
> 2016-12-06 17:53 GMT-05:00 Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com>:
>
>> Try installing python-jujuclient from ppa:tvansteenburgh/ppa. It has some
>> fixes
>> that aren't in stable yet.
>>
>> On Tue, Dec 6, 2016 at 5:51 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Python jujuclient version:
>>>
>>>
>>> sudo apt-get install python-jujuclient
>>> Reading package lists... Done
>>> Building dependency tree
>>> Reading state information... Done
>>> python-jujuclient is already the newest version (0.50.5-0ubuntu1).
>>>
>>>
>>> 2016-12-06 17:46 GMT-05:00 Tim Van Steenburgh <
>>> tim.van.steenbu...@canonical.com>:
>>>
>>>> Not sure where it comes from but you can skip make targets by adding
>>>> this line
>>>> to your tests.yaml:
>>>>
>>>> makefile: []
>>>>
>>>> What version of python-jujuclient do you have?
>>>>
>>>> On Tue, Dec 6, 2016 at 5:37 PM, Merlijn Sebrechts <
>>>> merlijn.sebrec...@gmail.com> wrote:
>>>>
>>>>> Ok, any idea where this comes from? I have no idea what tox is and why
>>>>> it is in my final Charm. I suspect it comes from a layer. Is there a way 
>>>>> to
>>>>> backtrace from what layer a file comes from?
>>>>>
>>>>>
>>>>> I got a bit further. Now I have the following error:
>>>>>
>>>>>
>>>>> $bundletester -t ./openvpn -e mesebrec/merlijnTest
>>>>> 2016-12-06 17:32:26 Starting deployment of sojobo:mesebrec/merlijntest
>>>>> Traceback (most recent call last):
>>>>>   File "/usr/local/bin/juju-deployer", line 11, in 
>>>>> sys.exit(main())
>>>>>   File "/usr/local/lib/python2.7/dist-packages/deployer/cli.py", line
>>>>> 140, in main
>>>>> run()
>>>>>   File "/usr/local/lib/python2.7/dist-packages/deployer/cli.py", line
>>>>> 250, in run
>>>>> importer.Importer(env, deployment, options).run()
>>>>>   File 
>>>>> "/usr/local/lib/python2.7/dist-packages/deployer/action/importer.py",
>>>>> line 301, in run
>>>>> self.env.connect()
>>>>>   File "/usr/local/lib/python2.7/dist-packages/deployer/env/go.py",
>>>>> line 78, in connect
>>>>> self.client = self.client_class.connect(self.name)
>>>>>   File "/usr/local/lib/python2.7/dist-packages/jujuclient/environment.py",
>>>>> line 87, in connect
>>>>> return connector().run(cls, env_name)
>>>>>   File "/usr/local/lib/python2.7/dist-packages/jujuclient/connector.py",
>>>>> line 41, in run
>>>>> jhome, data = self.parse_env(env_name)
>>>>>   File 
>>>>> "/usr/local/lib/python2.7/dist-packages/jujuclient/juju2/connector.py",
>>>>> line 64, in parse_env
>>>>> 'password': account['password'],
>>>>> KeyError: 'password'
>>>>> /usr/local/lib/python3.5/dist-packages/path.py:1717:
>>>>> DeprecationWarning: path is deprecated. Use Path instead.
>>>>>   warnings.warn(msg, DeprecationWarning)
>>>>> E
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2016-12-06 17:25 GMT-05:00 Tim Van Steenburgh <
>>>>> tim.van.steenbu...@canonical.com>:
>>>>>
>>>>>> Yeah, but it's not a dependency for all tests. ;)
>>>>>>
>>>>>> It's a dependency for your charm tests because your 'make test'
>>>>>> target calls tox.
>>>&g

Re: Issues with amulet tests

[Tim Van Steenburgh]

Try installing python-jujuclient from ppa:tvansteenburgh/ppa. It has some
fixes
that aren't in stable yet.

On Tue, Dec 6, 2016 at 5:51 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Python jujuclient version:
>
>
> sudo apt-get install python-jujuclient
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> python-jujuclient is already the newest version (0.50.5-0ubuntu1).
>
>
> 2016-12-06 17:46 GMT-05:00 Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com>:
>
>> Not sure where it comes from but you can skip make targets by adding this
>> line
>> to your tests.yaml:
>>
>> makefile: []
>>
>> What version of python-jujuclient do you have?
>>
>> On Tue, Dec 6, 2016 at 5:37 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Ok, any idea where this comes from? I have no idea what tox is and why
>>> it is in my final Charm. I suspect it comes from a layer. Is there a way to
>>> backtrace from what layer a file comes from?
>>>
>>>
>>> I got a bit further. Now I have the following error:
>>>
>>>
>>> $bundletester -t ./openvpn -e mesebrec/merlijnTest
>>> 2016-12-06 17:32:26 Starting deployment of sojobo:mesebrec/merlijntest
>>> Traceback (most recent call last):
>>>   File "/usr/local/bin/juju-deployer", line 11, in 
>>> sys.exit(main())
>>>   File "/usr/local/lib/python2.7/dist-packages/deployer/cli.py", line
>>> 140, in main
>>> run()
>>>   File "/usr/local/lib/python2.7/dist-packages/deployer/cli.py", line
>>> 250, in run
>>> importer.Importer(env, deployment, options).run()
>>>   File "/usr/local/lib/python2.7/dist-packages/deployer/action/importer.py",
>>> line 301, in run
>>> self.env.connect()
>>>   File "/usr/local/lib/python2.7/dist-packages/deployer/env/go.py",
>>> line 78, in connect
>>> self.client = self.client_class.connect(self.name)
>>>   File "/usr/local/lib/python2.7/dist-packages/jujuclient/environment.py",
>>> line 87, in connect
>>> return connector().run(cls, env_name)
>>>   File "/usr/local/lib/python2.7/dist-packages/jujuclient/connector.py",
>>> line 41, in run
>>> jhome, data = self.parse_env(env_name)
>>>   File 
>>> "/usr/local/lib/python2.7/dist-packages/jujuclient/juju2/connector.py",
>>> line 64, in parse_env
>>> 'password': account['password'],
>>> KeyError: 'password'
>>> /usr/local/lib/python3.5/dist-packages/path.py:1717:
>>> DeprecationWarning: path is deprecated. Use Path instead.
>>>   warnings.warn(msg, DeprecationWarning)
>>> E
>>>
>>>
>>>
>>>
>>> 2016-12-06 17:25 GMT-05:00 Tim Van Steenburgh <
>>> tim.van.steenbu...@canonical.com>:
>>>
>>>> Yeah, but it's not a dependency for all tests. ;)
>>>>
>>>> It's a dependency for your charm tests because your 'make test' target
>>>> calls tox.
>>>>
>>>> On Tue, Dec 6, 2016 at 5:22 PM, Merlijn Sebrechts <
>>>> merlijn.sebrec...@gmail.com> wrote:
>>>>
>>>>> Thanks for this, Tim. That seems to do the trick of the first error.
>>>>> Now I get a bunch of linter errors. I'll fix those and get back to you if 
>>>>> I
>>>>> run into any more errors. The tox thing seems like a bug in bundletester.
>>>>> Shouldn't bundletester install tox if it is a dependency for all tests?
>>>>>
>>>>>
>>>>>
>>>>> Kind regards
>>>>> Merlijn
>>>>>
>>>>> 2016-12-06 17:15 GMT-05:00 Tim Van Steenburgh <
>>>>> tim.van.steenbu...@canonical.com>:
>>>>>
>>>>>> The first problem is because `make test` runs tox, but tox isn't
>>>>>> installed. You can
>>>>>> add it to your packages list in tests.yaml. I would also recommend
>>>>>> changing the
>>>>>> shebang line of your 10-deploy test to #!/usr/bin/env python3
>>>>>>
>>>>>> On Tue, Dec 6, 2016 at 4:25 PM, Merlijn Sebrechts <
>>>>>> merlijn.sebrec...@gmail.com> wrote:
>>>>>>
>>>>>>> Hi
>>>>>>>
&g

Re: Issues with amulet tests

[Tim Van Steenburgh]

Not sure where it comes from but you can skip make targets by adding this
line
to your tests.yaml:

makefile: []

What version of python-jujuclient do you have?

On Tue, Dec 6, 2016 at 5:37 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Ok, any idea where this comes from? I have no idea what tox is and why it
> is in my final Charm. I suspect it comes from a layer. Is there a way to
> backtrace from what layer a file comes from?
>
>
> I got a bit further. Now I have the following error:
>
>
> $bundletester -t ./openvpn -e mesebrec/merlijnTest
> 2016-12-06 17:32:26 Starting deployment of sojobo:mesebrec/merlijntest
> Traceback (most recent call last):
>   File "/usr/local/bin/juju-deployer", line 11, in 
> sys.exit(main())
>   File "/usr/local/lib/python2.7/dist-packages/deployer/cli.py", line
> 140, in main
> run()
>   File "/usr/local/lib/python2.7/dist-packages/deployer/cli.py", line
> 250, in run
> importer.Importer(env, deployment, options).run()
>   File "/usr/local/lib/python2.7/dist-packages/deployer/action/importer.py",
> line 301, in run
> self.env.connect()
>   File "/usr/local/lib/python2.7/dist-packages/deployer/env/go.py", line
> 78, in connect
> self.client = self.client_class.connect(self.name)
>   File "/usr/local/lib/python2.7/dist-packages/jujuclient/environment.py",
> line 87, in connect
> return connector().run(cls, env_name)
>   File "/usr/local/lib/python2.7/dist-packages/jujuclient/connector.py",
> line 41, in run
> jhome, data = self.parse_env(env_name)
>   File "/usr/local/lib/python2.7/dist-packages/jujuclient/juju2/connector.py",
> line 64, in parse_env
> 'password': account['password'],
> KeyError: 'password'
> /usr/local/lib/python3.5/dist-packages/path.py:1717: DeprecationWarning:
> path is deprecated. Use Path instead.
>   warnings.warn(msg, DeprecationWarning)
> E
>
>
>
>
> 2016-12-06 17:25 GMT-05:00 Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com>:
>
>> Yeah, but it's not a dependency for all tests. ;)
>>
>> It's a dependency for your charm tests because your 'make test' target
>> calls tox.
>>
>> On Tue, Dec 6, 2016 at 5:22 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Thanks for this, Tim. That seems to do the trick of the first error. Now
>>> I get a bunch of linter errors. I'll fix those and get back to you if I run
>>> into any more errors. The tox thing seems like a bug in bundletester.
>>> Shouldn't bundletester install tox if it is a dependency for all tests?
>>>
>>>
>>>
>>> Kind regards
>>> Merlijn
>>>
>>> 2016-12-06 17:15 GMT-05:00 Tim Van Steenburgh <
>>> tim.van.steenbu...@canonical.com>:
>>>
>>>> The first problem is because `make test` runs tox, but tox isn't
>>>> installed. You can
>>>> add it to your packages list in tests.yaml. I would also recommend
>>>> changing the
>>>> shebang line of your 10-deploy test to #!/usr/bin/env python3
>>>>
>>>> On Tue, Dec 6, 2016 at 4:25 PM, Merlijn Sebrechts <
>>>> merlijn.sebrec...@gmail.com> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>>
>>>>> I'm trying to get my charm ready for the review queue and I'm having
>>>>> some issues getting the tests to work right.
>>>>>
>>>>> Running bundletester on the charm gives the following error:
>>>>>
>>>>> openvpn
>>>>> charm-proof
>>>>>  PASS
>>>>> make test
>>>>>  FAIL
>>>>>
>>>>> 
>>>>> --
>>>>> FAIL: openvpn::make test
>>>>> [/usr/bin/make -s test  exit 2]
>>>>> make: tox: Command not found
>>>>> Makefile:3: recipe for target 'test' failed
>>>>> make: *** [test] Error 127
>>>>>
>>>>>
>>>>>
>>>>> Running the test script manually also throws errors.
>>>>>
>>>>> ==
>>>>> ERROR: test_service (__main__.TestCharm)
>>>>> --
>>>>&g

Re: Issues with amulet tests

[Tim Van Steenburgh]

Yeah, but it's not a dependency for all tests. ;)

It's a dependency for your charm tests because your 'make test' target
calls tox.

On Tue, Dec 6, 2016 at 5:22 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Thanks for this, Tim. That seems to do the trick of the first error. Now I
> get a bunch of linter errors. I'll fix those and get back to you if I run
> into any more errors. The tox thing seems like a bug in bundletester.
> Shouldn't bundletester install tox if it is a dependency for all tests?
>
>
>
> Kind regards
> Merlijn
>
> 2016-12-06 17:15 GMT-05:00 Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com>:
>
>> The first problem is because `make test` runs tox, but tox isn't
>> installed. You can
>> add it to your packages list in tests.yaml. I would also recommend
>> changing the
>> shebang line of your 10-deploy test to #!/usr/bin/env python3
>>
>> On Tue, Dec 6, 2016 at 4:25 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi
>>>
>>>
>>> I'm trying to get my charm ready for the review queue and I'm having
>>> some issues getting the tests to work right.
>>>
>>> Running bundletester on the charm gives the following error:
>>>
>>> openvpn
>>> charm-proof
>>>PASS
>>> make test
>>>FAIL
>>>
>>> 
>>> --
>>> FAIL: openvpn::make test
>>> [/usr/bin/make -s test  exit 2]
>>> make: tox: Command not found
>>> Makefile:3: recipe for target 'test' failed
>>> make: *** [test] Error 127
>>>
>>>
>>>
>>> Running the test script manually also throws errors.
>>>
>>> ==
>>> ERROR: test_service (__main__.TestCharm)
>>> --
>>> Traceback (most recent call last):
>>>   File "./10-deploy", line 14, in setUp
>>> self.d.add('openvpn')
>>>   File "/usr/local/lib/python3.5/dist-packages/amulet/deployer.py",
>>> line 192, in add
>>> service_name, charm, branch=branch, series=service['series'])
>>>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line
>>> 57, in fetch
>>> series=series)
>>>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line
>>> 40, in get_charm
>>> return LocalCharm(charm_path, series)
>>>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line
>>> 72, in __init__
>>> raise Exception('Charm not found')
>>> Exception: Charm not found
>>>
>>> --
>>> Ran 1 test in 0.025s
>>>
>>> FAILED (errors=1)
>>>
>>>
>>> I'm trying to run these tests from local charms. You can find the charm
>>> here: https://github.com/IBCNServices/tengu-charms/tree/open
>>> vpn/charms/builds/openvpn
>>>
>>>
>>>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Issues with amulet tests

[Tim Van Steenburgh]

The second error won't really matter once you get things working with
bundletester,
but that error generally happens when you run an amulet test (for a local
charm)
directly and your cwd is not the charm dir, or some dir beneath it. Try
running it from
the charmdir instead.

On Tue, Dec 6, 2016 at 4:25 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi
>
>
> I'm trying to get my charm ready for the review queue and I'm having some
> issues getting the tests to work right.
>
> Running bundletester on the charm gives the following error:
>
> openvpn
> charm-proof
>  PASS
> make test
>  FAIL
>
> 
> --
> FAIL: openvpn::make test
> [/usr/bin/make -s test  exit 2]
> make: tox: Command not found
> Makefile:3: recipe for target 'test' failed
> make: *** [test] Error 127
>
>
>
> Running the test script manually also throws errors.
>
> ==
> ERROR: test_service (__main__.TestCharm)
> --
> Traceback (most recent call last):
>   File "./10-deploy", line 14, in setUp
> self.d.add('openvpn')
>   File "/usr/local/lib/python3.5/dist-packages/amulet/deployer.py", line
> 192, in add
> service_name, charm, branch=branch, series=service['series'])
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 57,
> in fetch
> series=series)
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 40,
> in get_charm
> return LocalCharm(charm_path, series)
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 72,
> in __init__
> raise Exception('Charm not found')
> Exception: Charm not found
>
> --
> Ran 1 test in 0.025s
>
> FAILED (errors=1)
>
>
> I'm trying to run these tests from local charms. You can find the charm
> here: https://github.com/IBCNServices/tengu-charms/
> tree/openvpn/charms/builds/openvpn
>
>
>
>
> --
> 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: Issues with amulet tests

[Tim Van Steenburgh]

The first problem is because `make test` runs tox, but tox isn't installed.
You can
add it to your packages list in tests.yaml. I would also recommend changing
the
shebang line of your 10-deploy test to #!/usr/bin/env python3

On Tue, Dec 6, 2016 at 4:25 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi
>
>
> I'm trying to get my charm ready for the review queue and I'm having some
> issues getting the tests to work right.
>
> Running bundletester on the charm gives the following error:
>
> openvpn
> charm-proof
>  PASS
> make test
>  FAIL
>
> 
> --
> FAIL: openvpn::make test
> [/usr/bin/make -s test  exit 2]
> make: tox: Command not found
> Makefile:3: recipe for target 'test' failed
> make: *** [test] Error 127
>
>
>
> Running the test script manually also throws errors.
>
> ==
> ERROR: test_service (__main__.TestCharm)
> --
> Traceback (most recent call last):
>   File "./10-deploy", line 14, in setUp
> self.d.add('openvpn')
>   File "/usr/local/lib/python3.5/dist-packages/amulet/deployer.py", line
> 192, in add
> service_name, charm, branch=branch, series=service['series'])
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 57,
> in fetch
> series=series)
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 40,
> in get_charm
> return LocalCharm(charm_path, series)
>   File "/usr/local/lib/python3.5/dist-packages/amulet/charm.py", line 72,
> in __init__
> raise Exception('Charm not found')
> Exception: Charm not found
>
> --
> Ran 1 test in 0.025s
>
> FAILED (errors=1)
>
>
> I'm trying to run these tests from local charms. You can find the charm
> here: https://github.com/IBCNServices/tengu-charms/
> tree/openvpn/charms/builds/openvpn
>
>
>
>
> --
> 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 Review Queue & Charm Testing

[Tim Van Steenburgh]

Hi everyone,


To follow up on ideas discussed at the past Juju Charmer summit, we've been
working to improve the Juju Charm review queue experience.  The Juju Charm
Store is no longer tied to Launchpad, and thus we no longer rely on branch
merges and auto-ingestion to get reviewed items into the store.  We instead
rely on the new charm release model, where a maintainer pushes a charm to
their namespace and requests a review using their charm store url.

A new review queue has been developed to support this workflow.  It is
currently lives at:

https://review.jujucharms.com

For the curious, the application code is available at:

https://github.com/juju-solutions/review-queue


And the charm can be found at:

https://github.com/juju-solutions/review-queue-charm

Notable features:

   -

   Not tied to any source code management (SCM) system.  You can now
   develop your charm where you are comfortable -- Github, Launchpad,
   Bitbucket, etc.
   -

   In-line policy checklist so charm developers know what is required and
   where they are in the review process.
   -

   In-line charm diffs with version mapping so charm developers and
   reviewers can track code changes through the review cycle.
   -

   Status and progress field on the landing page so folks can track
   progress against a set of charms.


The new review queue deprecates the old one (http://review.juju.solutions/).
If you have a charm or bundle that you would like reviewed, please use
https://review.jujucharms.com/:

   -

   Click “Login” and authenticate with your Ubuntu SSO credentials
   -

   Click “Request a Review” and submit your charm store URL


Comments, contributions, and bugs for the new review queue are welcomed.
Please see the link in the footer of https://review.jujucharms.com/ to
contribute.

Thanks,

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

Functional testing with Juju in Travis-CI

[Tim Van Steenburgh]

Hi everyone,

Since we're working on an api client, I wanted to be able to run
post-commit tests against a real Juju controller or model, using Travis-CI.
One caveat with Travis-CI is that they don't support xenial vms yet, so you
have to use trusty. If you can live with that, here's a .travis.yml that
will install juju and lxd on trusty, bootstrap a controller, run your
tests, and destroy the controller.

https://github.com/juju/python-libjuju/blob/master/.travis.yml

Hope it proves useful to others!

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

Re: Authenticating to model on shared controller

[Tim Van Steenburgh]

Thanks Francesco - I didn't realize that the base64-decoded value was in
fact the
json-serialized macaroon.

Now I have valid macaroons, but I'm still getting the "redirection
required" error
message back from the Login api, and I have no idea why. Digging around in
juju
code trying to figure it out, but if anyone has any pointers that'd be
great.


On Sat, Nov 5, 2016 at 6:44 PM, Francesco Banconi <
francesco.banc...@canonical.com> wrote:

>
> > On 5 Nov 2016, at 23:07, Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
> >
> > Can anyone tell me how the macaroons in ~/.go-cookies are encoded? If I
> try to
> > deserialize the 'Value' value directly (using libmacaroons), I get an
> 'invalid macaroon'
> > error. I also tried base64-decoding the value first, and that didn't
> work either.
>
> Decoding the cookie values with base64 should work for that.
> I just quickly tested that the following works locally with Python3 for
> instance:
>
> import base64, json, os
> cookies = json.load(open(os.path.expanduser('~/.go-cookies')))
> values = [c['Value'] for c in cookies if c['Name'].startswith('macaroon-')
> and c['Value']]
> macaroons = [json.loads(base64.b64decode(value).decode('utf-8')) for
> value in values]
>
> --
> Francesco
>
>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Authenticating to model on shared controller

[Tim Van Steenburgh]

Can anyone tell me how the macaroons in ~/.go-cookies are encoded? If I try
to
deserialize the 'Value' value directly (using libmacaroons), I get an
'invalid macaroon'
error. I also tried base64-decoding the value first, and that didn't work
either.

My plan is to grab macaroons out of ~/.go-cookies, reserialize them to
json, and
ship them along with my Login request to the api. If that is a dumb plan
and I just
don't know it yet, please enlighten me. :)

On Fri, Nov 4, 2016 at 12:54 PM, Uros Jovanovic <
uros.jovano...@canonical.com> wrote:

> Through Identity manager and SSO with macaroons. You'll have them in
> ~/.go-cookies and ~/.local/share/juju/usso-store-token (or something like
> that).
>
> Feel free to ask in #jaas
>
> On Fri, Nov 4, 2016 at 6:51 PM, Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> If I `juju register` a shared controller and add a model to it, how does
>> the juju client authenticate to that model, since AFAICT there is no
>> password locally? I'm asking b/c I need to be able to make other clients
>> (python) work for this case. For the heck of it I tried with a blank
>> password but got the (unexpected?) error below:
>>
>> 2016-11-04 12:07:42 [DEBUG] jujuclient.connector: Connecting to wss://
>> 162.213.33.28:443/model/5ce2c723-7db5-4ed7-801c-210250f244dc/api
>> 2016-11-04 12:07:43 [DEBUG] jujuclient.rpc: rpc request:
>> {
>>   "request": "Login",
>>   "type": "Admin",
>>   "params": {
>> "credentials": "",
>> "auth-tag": "user-tvansteenburgh@external"
>>   },
>>   "version": 3,
>>   "request-id": 1
>> }
>> 2016-11-04 12:07:43 [DEBUG] jujuclient.rpc: rpc response:
>> {
>>   "request-id": 1,
>>   "response": {},
>>   "error": "redirection required",
>>   "error-code": "redirection required"
>> }
>>
>> TIA,
>>
>> Tim
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Authenticating to model on shared controller

[Tim Van Steenburgh]

If I `juju register` a shared controller and add a model to it, how does
the juju client authenticate to that model, since AFAICT there is no
password locally? I'm asking b/c I need to be able to make other clients
(python) work for this case. For the heck of it I tried with a blank
password but got the (unexpected?) error below:

2016-11-04 12:07:42 [DEBUG] jujuclient.connector: Connecting to wss://
162.213.33.28:443/model/5ce2c723-7db5-4ed7-801c-210250f244dc/api
2016-11-04 12:07:43 [DEBUG] jujuclient.rpc: rpc request:
{
  "request": "Login",
  "type": "Admin",
  "params": {
"credentials": "",
"auth-tag": "user-tvansteenburgh@external"
  },
  "version": 3,
  "request-id": 1
}
2016-11-04 12:07:43 [DEBUG] jujuclient.rpc: rpc response:
{
  "request-id": 1,
  "response": {},
  "error": "redirection required",
  "error-code": "redirection required"
}

TIA,

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

Re: [ANN] Updated Python Juju Client

[Tim Van Steenburgh]

On Tue, Nov 1, 2016 at 9:55 AM, Tom Barber  wrote:

> solicit, not illicit... unless the client is illegal?! ;)
>

Oops, should've been "elicit".


>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
> goal, but you can always help by sponsoring the project
> <http://www.meteorite.bi/products/saiku/sponsorship>)
>
> On 1 November 2016 at 13:49, Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> Hi everyone,
>>
>> We've been working on a new python client for Juju. It's still in
>> development,
>> but we wanted to share the first bits to illicit feedback:
>> https://github.com/juju/python-libjuju
>>
>> Features of this library include:
>>
>>  * fully asynchronous - uses asyncio and async/await features of python
>> 3.5
>>  * websocket-level bindings are programmatically generated (indirectly)
>> from the
>>Juju golang code, ensuring full api coverage
>>  * provides an OO layer which encapsulates much of the websocket api and
>>provides familiar nouns and verbs (e.g. Model.deploy(),
>> Application.add_unit(),
>>etc.)
>>
>> Caveats:
>>
>>  * Juju 2+ only. Juju 1 support may be added in the future.
>>  * Requires Python 3.5+
>>  * Currently async-only. A synchronous wrapper will be provided in the
>> future.
>>
>> If you want to try it out, take a look at the examples/ directory.
>> https://github.com/juju/python-libjuju/blob/master/examples/unitrun.py
>> is a
>> fairly simple one that deploys a unit, runs a command on that unit, waits
>> for
>> and prints the results, then exits.
>>
>> Any and all comments, questions, and contributions are welcomed.
>>
>> Thanks,
>>
>> Tim
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] Updated Python Juju Client

[Tim Van Steenburgh]

Hi everyone,

We've been working on a new python client for Juju. It's still in
development,
but we wanted to share the first bits to illicit feedback:
https://github.com/juju/python-libjuju

Features of this library include:

 * fully asynchronous - uses asyncio and async/await features of python 3.5
 * websocket-level bindings are programmatically generated (indirectly)
from the
   Juju golang code, ensuring full api coverage
 * provides an OO layer which encapsulates much of the websocket api and
   provides familiar nouns and verbs (e.g. Model.deploy(),
Application.add_unit(),
   etc.)

Caveats:

 * Juju 2+ only. Juju 1 support may be added in the future.
 * Requires Python 3.5+
 * Currently async-only. A synchronous wrapper will be provided in the
future.

If you want to try it out, take a look at the examples/ directory.
https://github.com/juju/python-libjuju/blob/master/examples/unitrun.py is a
fairly simple one that deploys a unit, runs a command on that unit, waits
for
and prints the results, then exits.

Any and all comments, questions, and contributions are welcomed.

Thanks,

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

[ANN] New juju-deployer-0.9.0, python-jujuclient-0.53.1

[Tim Van Steenburgh]

These new releases work with the latest juju-2.0 betas while maintaining
compatibility with juju-1.25.

They are currently available on PyPI and in ppa:tvansteenburgh/ppa, and
will likely be copied to ppa:juju/stable in the near future.

Find bugs? File here:
https://bugs.launchpad.net/python-jujuclient
https://bugs.launchpad.net/juju-deployer


Bundletester (https://github.com/juju-solutions/bundletester) works with
the latest juju-2.0 betas if the latest versions of juju-deployer and
python-jujuclient are installed.

The Amulet charm testing library (http://pythonhosted.org/amulet/) has
juju-2.0 support in master, but is awaiting a release that contains that
support. Watch this space for an announcement of that release.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Need information for connecting to mariadb from remote machine

[Tim Van Steenburgh]

Have you tried including the db name when connecting, e.g.:

mysql -h db_host -u db_user -p db_pass -D `relation-get database`

Pretty sure you only get perms to the database created for you when you
join the relation.

On Mon, Jun 20, 2016 at 5:51 AM, Rajith P Venkata 
wrote:

> Hi
>
> I am connecting to mariadb from remote machine , I am executing this
> commands from bash
>
> @when 'relation_name.available'
> function mariadb_install_check(){
> db_host=`relation-get host`
> db_user=`relation-get user`
> db_pass=`relation-get password`
> mysql -h db_host -u db_user -p db_pass
> }
>
>
> while connecting to my sql : I am getting error: ERROR 1045 (28000):
> Access denied for user
>
> please let me know what grant permission I can provide from mariadb to
> default user of remote machine.
>
> remote machine user I am getting: ietohvoibaitaik
>
>
>
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> 
>
> Cell- 9901966577
> Email: rajith...@in.ibm.com
>
>
>
> From:Rajith P Venkata/India/IBM
> To:Daniel Bartholomew , juju <
> juju@lists.ubuntu.com>
> Date:14-06-16 11:31 PM
> Subject:Need information  for performing housekeeping tasks on
> mariadb from a remote machine
> --
>
>
> Hi,
>
> I have deployed mariadb in unit 1 and want to perform following tasks from
> RTM charm which is in unit 2
>
> rm -f /var/lib/mysql/ib_logfile*
> service mysql stop
> rm -f /var/lib/mysql/ibdata*
>
> Please let me know how I can perform this housekeeping tasks.
>
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> 
>
> Cell- 9901966577
> Email: rajith...@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: Promulgated charms (production readiness)

[Tim Van Steenburgh]

Right, but NRPE can be related to any charm too. My point was just that the
charm doesn't need to explicitly support monitoring.

On Mon, May 16, 2016 at 9:35 AM, Charles Butler <
charles.but...@canonical.com> wrote:

> Thats only monitoring the host's ssh connection/heartbeat. If you want
> application specific monitoring, you'll need the NRPE agent or to implement
> it on the charm so it knows what to check.
>
> It does the bare minimum by default which i believe to be: "is the host
> still alive?"
>
> On Mon, May 16, 2016 at 9:33 AM Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> On Mon, May 16, 2016 at 6:44 AM, Tom Barber 
>> wrote:
>>
>>>  I should be able to say "hey, I'm gonna install this new charm" and
>>> know that I can hook it into our monitoring infrastructure without doing
>>> anything too crazy.
>>>
>>>
>> Isn't this already true? After seeing this thread, I took a brand new
>> charm that I wrote, for which I had not yet even thought about monitoring,
>> deployed Nagios, related it to my charm, and sure enough, it Just Worked.
>>
>>
>>> Its all well and good selling Juju to Developers like myself or CTO's by
>>> the Ops guys have their "special ways" and making sure that charms fit into
>>> those ways will be key to adoption.
>>>
>>> Tom
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> --
>>> 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 Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your service | www.jujucharms.com
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[Tim Van Steenburgh]

On Mon, May 16, 2016 at 6:44 AM, Tom Barber  wrote:

>  I should be able to say "hey, I'm gonna install this new charm" and know
> that I can hook it into our monitoring infrastructure without doing
> anything too crazy.
>
>
Isn't this already true? After seeing this thread, I took a brand new charm
that I wrote, for which I had not yet even thought about monitoring,
deployed Nagios, related it to my charm, and sure enough, it Just Worked.


> Its all well and good selling Juju to Developers like myself or CTO's by
> the Ops guys have their "special ways" and making sure that charms fit into
> those ways will be key to adoption.
>
> 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
> )
>
> --
> 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: Not able to create the charm after installation of juju2.0Version

[Tim Van Steenburgh]

Hi,

It's just `charm create testcharm` (drop the leading juju).



On Sun, May 1, 2016 at 8:44 AM, Saranabasava 110 
wrote:

> Hi,
>
> I have installed 2.0-beta6-xenial-s390x on Ubuntu 16.04 LTS by
> following https://jujucharms.com/docs/devel/getting-started. I can able
> to add the new machine but not able to create the charm. If i am trying to
> create the new charm using "juju charm create testcharm", getting an error
> message called "error: unrecognized command: charm create".
>
> I have installed charm tools along with the installation of
> juju2.0 and i am getting the message as "charm-tools is already the newest
> version (2.1.2-0ubuntu4).". Please help me to resolve this issue.
>
> Thanks
> Sharan
>
> --
> 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: Testing Leader Election reconfiguration

[Tim Van Steenburgh]

On Tue, Mar 15, 2016 at 12:30 PM, Tom Barber 
wrote:

> Hi Tim,
>
> Why would I need to increase the timeout when the status says all the unit
> are operational?
>

The default wait time is 300s, with an "idle threshold" of 30s. Which
means, it waits for everything to be idle for 30s before returning from the
wait. This means that with the default timeout, if the env doesn't settle
within 4m30s, it'll time out. This may not be what's happening in your
case, but it's worth trying a longer timeout value to make sure.


> The status dump came out of bundletester which said that it failed on the
> first wait(), I assume the status dump arrived at the same time?
> Bugs are allowed, the test was hacked up from a previous one, it doesn't
> do anything yet, I'm trying to make sure the logic works first.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
> goal, but you can always help by sponsoring the project
> <http://www.meteorite.bi/products/saiku/sponsorship>)
>
> On 15 March 2016 at 16:27, Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
>> Hey Tom,
>>
>> 1. You can increase the wait time until it doesn't time out:
>> self.d.sentry.wait(timeout=1200)
>> 2. At what point in this sequence of commands was the status dump
>> captured?
>> 3. There is a bug here. You take a reference to the pdi/0 info dict on
>> line 1. It's the same object you use to get message2 and message3 later.
>> So, you'll get the same message that you got on line 1. You need `message3
>> = self.d.sentry['pdi'][0].info['workload-status'].get('message')`
>> instead.
>>
>> Hope this helps.
>>
>> On Tue, Mar 15, 2016 at 11:41 AM, Tom Barber 
>> wrote:
>>
>>> Okay back here again, so my nice leader election function looks like:
>>>
>>>def test_leader_election_failover(self):
>>> unit = self.d.sentry['pdi'][0].info
>>> message = unit['workload-status'].get('message')
>>> ip = message.split(':', 1)[-1]
>>> self.d.add_unit('pdi', 2)
>>> self.d.sentry.wait()
>>> message2 = unit['workload-status'].get('message')
>>> ip2 = message2.split(':', 1)[-1]
>>> self.assertEqual(ip, ip2)
>>> self.d.remove_unit('pdi/0')
>>> self.d.sentry.wait()
>>> message3 = unit['workload-status'].get('message')
>>> ip3 = message3.split(':', 1)[-1]
>>>
>>> self.assertNotEqual(ip3, ip2)
>>>
>>> I know there's no logic in there, but I need to make sure the stuff
>>> actually functions.
>>>
>>> So Tim says wait() should work, but when I tested this last night,
>>>
>>> I get a timeout error o the wait right after add_unit.
>>>
>>> https://gist.github.com/buggtb/c271dd79d782af57dea6
>>>
>>> Yet in the status dump you can see all 3 units sat there seemingly happy.
>>>
>>> Tom
>>>
>>> --
>>>
>>> Director Meteorite.bi - Saiku Analytics Founder
>>> Tel: +44(0)5603641316
>>>
>>> (Thanks to the Saiku community we reached our Kickstart
>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>> goal, but you can always help by sponsoring the project
>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>
>>> On 9 March 2016 at 18:31, Tom Barber  wrote:
>>>
>>>> Oh really?
>>>>
>>>> /me stokes his invisible beard.
>>>>
>>>>
>>>> Okay I'll go back and try again.
>>>>
>>>> Tom
>>>>
>>>> --
>>>>
>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>> Tel: +44(0)5603641316
>>>>
>>>> (Thanks to the Saiku community we reached our Kickstart
>>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>>> goal, but you can always help by sponsoring the project
>>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>>
>>>

Re: Testing Leader Election reconfiguration

[Tim Van Steenburgh]

Hey Tom,

1. You can increase the wait time until it doesn't time out:
self.d.sentry.wait(timeout=1200)
2. At what point in this sequence of commands was the status dump captured?
3. There is a bug here. You take a reference to the pdi/0 info dict on line
1. It's the same object you use to get message2 and message3 later. So,
you'll get the same message that you got on line 1. You need `message3
= self.d.sentry['pdi'][0].info['workload-status'].get('message')`
instead.

Hope this helps.

On Tue, Mar 15, 2016 at 11:41 AM, Tom Barber 
wrote:

> Okay back here again, so my nice leader election function looks like:
>
>def test_leader_election_failover(self):
> unit = self.d.sentry['pdi'][0].info
> message = unit['workload-status'].get('message')
> ip = message.split(':', 1)[-1]
> self.d.add_unit('pdi', 2)
> self.d.sentry.wait()
> message2 = unit['workload-status'].get('message')
> ip2 = message2.split(':', 1)[-1]
> self.assertEqual(ip, ip2)
> self.d.remove_unit('pdi/0')
> self.d.sentry.wait()
> message3 = unit['workload-status'].get('message')
> ip3 = message3.split(':', 1)[-1]
>
> self.assertNotEqual(ip3, ip2)
>
> I know there's no logic in there, but I need to make sure the stuff
> actually functions.
>
> So Tim says wait() should work, but when I tested this last night,
>
> I get a timeout error o the wait right after add_unit.
>
> https://gist.github.com/buggtb/c271dd79d782af57dea6
>
> Yet in the status dump you can see all 3 units sat there seemingly happy.
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
> goal, but you can always help by sponsoring the project
> <http://www.meteorite.bi/products/saiku/sponsorship>)
>
> On 9 March 2016 at 18:31, Tom Barber  wrote:
>
>> Oh really?
>>
>> /me stokes his invisible beard.
>>
>>
>> Okay I'll go back and try again.
>>
>> Tom
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 9 March 2016 at 16:56, Tim Van Steenburgh <
>> tim.van.steenbu...@canonical.com> wrote:
>>
>>>
>>>
>>> On Wed, Mar 9, 2016 at 6:31 AM, Tom Barber 
>>> wrote:
>>>
>>>> Thanks Stuart.
>>>>
>>>> I do put a note in my charm message indicating the leader IP address so
>>>> that users know which to connect to.
>>>>
>>>> So with juju wait, would I destroy a unit then execute juju wait? At
>>>> which point it will hang until the leader election stuff is over and all
>>>> becomes stable again?
>>>>
>>>>
>>> Since you're already using amulet, there's no need to use the juju-wait
>>> plugin
>>> since d.sentry.wait() does the same thing. So yes, you would do
>>> d.remove_unit(...)
>>> and then call d.sentry.wait().
>>>
>>>
>>>> Also, will this work if I push it upstream to the charmers and the
>>>> automated tests up there?
>>>>
>>>>
>>> Yes.
>>>
>>>
>>>> Thanks
>>>>
>>>> Tom
>>>>
>>>> --
>>>>
>>>> Director Meteorite.bi - Saiku Analytics Founder
>>>> Tel: +44(0)5603641316
>>>>
>>>> (Thanks to the Saiku community we reached our Kickstart
>>>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>>>> goal, but you can always help by sponsoring the project
>>>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>>>
>>>> On 9 March 2016 at 11:00, Stuart Bishop 
>>>> wrote:
>>>>
>>>>> On 9 March 2016 at 20:31, Tom Barber  wrote:
>>>>> > Morning all
>>>>> >
>>>>> > I'

Re: Testing Leader Election reconfiguration

[Tim Van Steenburgh]

On Wed, Mar 9, 2016 at 6:31 AM, Tom Barber  wrote:

> Thanks Stuart.
>
> I do put a note in my charm message indicating the leader IP address so
> that users know which to connect to.
>
> So with juju wait, would I destroy a unit then execute juju wait? At which
> point it will hang until the leader election stuff is over and all becomes
> stable again?
>
>
Since you're already using amulet, there's no need to use the juju-wait
plugin
since d.sentry.wait() does the same thing. So yes, you would do
d.remove_unit(...)
and then call d.sentry.wait().


> Also, will this work if I push it upstream to the charmers and the
> automated tests up there?
>
>
Yes.


> 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 9 March 2016 at 11:00, Stuart Bishop 
> wrote:
>
>> On 9 March 2016 at 20:31, Tom Barber  wrote:
>> > Morning all
>> >
>> > I'm trying to test for charm reconfiguration if the leader goes AWOL.
>>
>> I put the role of the unit in its workload status, so it is easy for
>> operators to see which unit is master. And this also makes it easy for
>> tests to tell.
>>
>>
>> > Adam suggested that I watch the status waiting for the next leader
>> election
>> > hook the wait on that and then check my service configs.
>>
>> You are best of waiting for all the hooks to complete and a steady
>> state, not just leader elected (since things will still be in flux
>> when that hook fires, such as the leader-settings-changed hooks it
>> will probably trigger and the relation changes those hooks will likely
>> trigger). Use the juju-wait plugin, and maybe add support to
>> https://bugs.launchpad.net/juju-core/+bug/1488777 to get this into
>> core.
>>
>> --
>> Stuart Bishop 
>>
>
>
> --
> 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: Installing 2.0

[Tim Van Steenburgh]

1. ppa:juju/devel
2. Use the layer!

On Tue, Feb 2, 2016 at 11:54 AM, Tom Barber  wrote:

> Morning folks,
>
> What was the PPA for Juju 2.0?
>
> On a separate note, if I'm writing a charm to install a Java based package
> should I use layers to include openjdk from Kevins charm or somewhere or do
> I just apt get it? IE: whats the recommended approach.
>
> Cheers
>
> 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
> )
>
> --
> 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: Saiku Amulet charm testing

[Tim Van Steenburgh]

On Tue, Dec 8, 2015 at 6:43 AM, Tom Barber  wrote:

> Hi guys,
>
> I'm trying to finally finish off this Saiku charm so I can submit it for
> validation.
>
> I want to write a few simple tests but I need a couple of pointers for
> help with Amulet as I'm not a python guy.
>
> d = amulet.Deployment()
> d.add('tomcat')
> d.add('saiku','cs:~f-tom-n/trusty/saikuanalytics-enterprise')
> d.relate('saiku', 'tomcat')
> d.expose('tomcat')
>
> I'm trying that but the relate throws a wobbly:
>
> ValueError: All relations must be explicit, service:relation
>
> What have I done wrong there?
>

You have to be explicit about what relation you're connecting services on,
e.g.,

d.relate('saiku:website', 'tomcat:website')


>
> Also, we use a manual environment internally, can I get amulet to deploy
> to an LXC container like we do when deploying manually?
>

Yep, you can use the same placement directives that you'd use in a bundle
file (see
https://jujucharms.com/docs/1.25/charms-bundles#bundle-placement-directives),
e.g.,

d.add('tomcat', placement='lxc:0')


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

[Review Queue] precise/haproxy

[Tim Van Steenburgh]

Reviewed
https://code.launchpad.net/~jacekn/charms/precise/haproxy/haproxy-updates/+merge/272559

This branch makes a few improvements to the precise/haproxy charm:
- add SSL support
- add nagios_servicegroups config option
- multiple monitoring fixes
- add open_monitoring_port option

Changes looked good, although there were proof, lint, and unit test errors
(deploy tests were successful) not related to the changes. I created a new
branch containing test fixes (
http://reports.vapour.ws/charm-test-details/charm-bundle-test-parent-3392) and
proposed it for merging. The original changes will be merged once the fixes
land.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: ERROR cannot read info: lock timeout exceeded

[Tim Van Steenburgh]

On Fri, Sep 25, 2015 at 9:56 AM, Curtis Hovey-Canonical <
cur...@canonical.com> wrote:

> On Fri, Sep 25, 2015 at 9:15 AM, Tim Van Steenburgh
>  wrote:
> > Hi everyone,
> >
> > I have a jenkins slave that's running charm and bundle tests on 5
> different
> > clouds pretty much all the time. My problem is that tests will randomly
> fail
> > after hitting this lock timeout.
>
> Juju QA has pondered deleting any lock more than a minute old every
> time we call the client to bootstrap or destroy-environment.
>

This is a good idea and probably worth doing, although it won't fix our
most common
failure, where a test run bootstraps successfully, but then fails later
when *another*
env bootstraps just before the running test tries to execute a juju command.


>
> > Is the best way around this to have a separate $JUJU_HOME for all my test
> > clouds, so that I end up with one lock per cloud? I haven't tried this
> yet
> > but it seems like the simplest way forward, if it works and is safe (is
> > it?).
>
> Generating separate JUJU_HOMEs will insulate your from bug
> https://bugs.launchpad.net/juju-core/+bug/1467331


Thanks, I'm going to try this approach and see what happens. Although, it
seems
to me that if it's safe to have multiple JUJU_HOMEs, all "doing stuff"
concurrently,
it would also be possible to have one lock per env, instead of one global
lock. Can
anyone on the core team explain why there is one global lock? I'm just
curious.


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

ERROR cannot read info: lock timeout exceeded

[Tim Van Steenburgh]

Hi everyone,

I have a jenkins slave that's running charm and bundle tests on 5 different
clouds pretty much all the time. My problem is that tests will randomly
fail after hitting this lock timeout.

Here's an example:
http://reports.vapour.ws/all-bundle-and-charm-results/charm-bundle-test-parent-928/charm/aws/17

Between successful bootstrap and that test failure, 17 tests ran
successfully. Presumably, a new test job for a different cloud got kicked
off, the env.lock was held to bootstrap that cloud, and my test that was
using `juju ssh` at the time failed because the lock was held. I'm not
certain that's what is happening, but it's my best guess based on what I've
observed, and my limited understanding of the env.lock.

Is the best way around this to have a separate $JUJU_HOME for all my test
clouds, so that I end up with one lock per cloud? I haven't tried this yet
but it seems like the simplest way forward, if it works and is safe (is
it?).

Thanks for the help,
Tim
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] zulu8

[Tim Van Steenburgh]

Yesterday evening I did a final review of the new zulu8 charm.

zulu8 is a subordinate charm which provides Azul Zulu, an open source
implementation of OpenJDK. It provides both the JRE and JDK. More
information at http://www.azulsystems.com/products/zulu

I'm happy to report that the charm passed its review and has been
promulgated to the Charm Store!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] apache-kafka, docker

[Tim Van Steenburgh]

apache-kafka (https://bugs.launchpad.net/charms/+bug/1489488)

A truly excellent new charm submission from Kevin Monroe on the Juju Big
Data team. This is a great example of a clean, well-written python charm.
It's built on the `charmhelpers.core.charmframework`, uses the
`jujuresources` lib for fetching external resources, and uses juju actions
for managing the deployed service.

If you're making a new python charm and need a good example to model it
after, take a look!


docker (
https://code.launchpad.net/~lazypower/charms/trusty/docker/test-fixes/+merge/270817
)

Miscellaneous updates to the existing docker charm.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: SuiteCRM Charm - No Auto-entry of database details

[Tim Van Steenburgh]

On Thu, Jul 23, 2015 at 3:25 PM, Joseph Liau  wrote:

>  On 2015-07-23 12:11 PM, Tim Van Steenburgh wrote:
>
> Hi Joseph,
>
>  Here's one way to solve this:
>
>  1. Setup up the software manually one time.
> 2. Once it's set up, dump the database to a file.
> 3. Put that file in your charm, and use it to automatically load the
> database when the db relation is joined.
>
> Hi Tim,
>
> Neat idea. I had thought that I copied a lot of the SugarCRM hooks, but I
> missed that thought. I will give that a go.
> But, then does that also mean the login information for SuiteCRM would not
> be chosen by the person installing? Should be ok as long as documented.
>
> i.e. admin-password  (string) Password for Admin user. thisisaTEST!
>

In the charm I linked to there is an admin-password config option which can
be set by the user. The database is initially loaded with the default
password (which is embedded in the db dump file). After the db is loaded,
the config-changed hook is re-invoked, updating the admin-password in the
database using the value from the config (see bottom of
hooks/config-changed).


> Thanks,
> Joseph
>
>
>  For an example of this, check out
> https://jujucharms.com/u/cabs-team/sugarcrm/trusty/16, specifically the
> hooks/database-relation-changed file.
>
> On Thu, Jul 23, 2015 at 2:01 PM, Joseph Liau  wrote:
>
>>
>> Hello,
>>
>> A while back I was working on a SuiteCRM charm (my first time doing
>> anything like this):
>> https://github.com/userj/suitecrm-charm
>>
>> It installs all right, but when it comes time to go through the setup
>> via the web-gui of SuiteCRM, then database details do not get
>> automatically populated/entered in the installation process.
>>
>> If I dig into the details of the database, I can find the details and
>> manually input them. If I do that, then the SuiteCRM installation works
>> as it should. This is obviously an unacceptable solution though.
>>
>> I'm hoping that someone can help me to either fix the charm or liaise
>> with the SuiteCRM community resolve this issue. A lot of the charm is
>> based on templates from SugarCRM and similar installations.
>>
>> Thanks,
>> Joe
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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: SuiteCRM Charm - No Auto-entry of database details

[Tim Van Steenburgh]

Hi Joseph,

Here's one way to solve this:

1. Setup up the software manually one time.
2. Once it's set up, dump the database to a file.
3. Put that file in your charm, and use it to automatically load the
database when the db relation is joined.

For an example of this, check out
https://jujucharms.com/u/cabs-team/sugarcrm/trusty/16, specifically the
hooks/database-relation-changed file.

On Thu, Jul 23, 2015 at 2:01 PM, Joseph Liau  wrote:

>
> Hello,
>
> A while back I was working on a SuiteCRM charm (my first time doing
> anything like this):
> https://github.com/userj/suitecrm-charm
>
> It installs all right, but when it comes time to go through the setup
> via the web-gui of SuiteCRM, then database details do not get
> automatically populated/entered in the installation process.
>
> If I dig into the details of the database, I can find the details and
> manually input them. If I do that, then the SuiteCRM installation works
> as it should. This is obviously an unacceptable solution though.
>
> I'm hoping that someone can help me to either fix the charm or liaise
> with the SuiteCRM community resolve this issue. A lot of the charm is
> based on templates from SugarCRM and similar installations.
>
> Thanks,
> Joe
>
>
>
>
>
>
>
> --
> 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

[Review Queue] docker

[Tim Van Steenburgh]

This morning I reviewed and merged the latest version of the docker
charm[1], which, among other improvements, raises the default docker
version to 1.7.0 and introduces a new config option for installing
docker-compose.

[1] https://code.launchpad.net/~charmers/charms/trusty/docker/trunk
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] cassandra, charm-helpers

[Tim Van Steenburgh]

This morning I reviewed a change to the cassandra charm which takes
advantage of the leadership features of juju, and bumps the default
cassandra version to 2.1.7. [0]

The changes look great in general, although there are some test failures to
address before merging.

On a related note, a new `coordinator` module, used in cassandra, has been
merged into charmhelpers. This module provides a nice abstraction over unit
coordination using juju leadership. Description from the commit log:

"Coordinate operations in hooks using leadership.

Common uses will be rolling restarts and rolling upgrades.

App specific applications will be things like 'don't reboot while
another node is streaming data from you' or 'don't bootstrap until
the seed nodes are ready' or 'only allow (num_nodes/2-1) units to
bootstrap at a time."

Thanks to stub for this fine work!


[0]
https://code.launchpad.net/~stub/charms/trusty/cassandra/spike/+merge/262608
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ntp, mongodb

[Tim Van Steenburgh]

Merged fixes:

https://code.launchpad.net/~paulgear/charms/trusty/ntp/fix-trusty-exceptions-psutil-1.2.x/+merge/260080
https://code.launchpad.net/~verterok/charms/trusty/mongodb/fix-data_directory-migration/+merge/260290
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] New charm: trusty/cassandra

[Tim Van Steenburgh]

"This is a total rewrite of the Cassandra charm. It supports Apache
Cassandra 2.0, 2.1 and DataStax Enterprise 4.6.

It is not backwards compatible with the old precise/cassandra charm that
only supported earlier versions of Cassandra."

Many thanks to Stuart Bishop for his work on this charm!
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] galera-cluster

[Tim Van Steenburgh]

After a final review, this new charm has been promulgated to the charm
store.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] apache2, ntp, nrpe, squid-reverseproxy, mongodb

[Tim Van Steenburgh]

Reviewed and merged:

[1] apache2 - Support apache-website interface.
[2] ntp  - Fix divide by zero.
[3] nrpe - Fix nagios checks to handle haproxy 1.5
[4] squid-reverseproxy - Add visible_hostname to avoid excessive DNS queries
[5] mongodb - Add support for benchmarking mongodb with mongoperf, using
juju actions.

[1] https://code.launchpad.net/~abentley/charms/trusty/
apache2/apache-website/+merge/249758
[2]
https://code.launchpad.net/~paulgear/charms/trusty/ntp/fix-divide-by-zero/+merge/255660
[3]
https://code.launchpad.net/~cjwatson/charms/trusty/haproxy/nrpe-handle-backports/+merge/257416
[4]
https://code.launchpad.net/~michael.nelson/charms/trusty/squid-reverseproxy/1454485-set-visible-hostname/+merge/258959
[5]
https://code.launchpad.net/~aisrael/charms/trusty/mongodb/benchmarking/+merge/258558
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] sugarcrm, kibana tests

[Tim Van Steenburgh]

https://code.launchpad.net/~nicopace/charms/trusty/sugarcrm/all-tests/+merge/251318
https://code.launchpad.net/~nicopace/charms/trusty/kibana/all-tests/+merge/251309

Rejected both for test failures, with comments on how to fix.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Makefile target names

[Tim Van Steenburgh]

Marco, I like your proposal with one change - we don't need the test.yaml
changes. Instead I would suggest we add 'unit-test' to the list of default
bundletester targets. So bundletester will run proof, lint, test, and
unit-test (charm author should choose test or unit-test, not both).
Bundletester will *not* run functional-test, since it runs everything +x in
the tests/ dir, which almost always overlaps with functional-test.

On Thu, Jan 22, 2015 at 11:57 AM, Marco Ceppi  wrote:

> We can also add Makefile checking to charm proof, for an even greater
> redundancy.
>
> To avoid multiple invocations of charm proof (not terrible, IMO) lint
> could be broken down further:
>
> lint: proof code_lint
>
> proof:
> charm proof
>
> code_lint:
> # Your code here
>
> Then have bundle tester sniff out code_lint, or use the test.yaml
> configuration to point lint to code_lint. Doesn't change UX for the
> author/contributor but does add a level of complexity. It seems like
> Makefile's are the overwhelming method for consolidating tasks for charms,
> I'd like to kick off the following proposal for Makefile format to be
> placed in charm create templates:
>
> ```
> test: lint unit-test functional-test
> lint: proof code-lint
> sync: charm-helpers-sync
>
> code-lint:
> # FILL IN COMMANDS FOR PERFORMING CODE LINT
>
> unit-test:
># COMMANDS REQUIRED TO UNIT TEST
>
> charm-helpers-sync:
> @scripts/sync.py 
>
> functional-test:
> juju test
>
> proof:
> charm proof
> ```
>
> With a test.yml file that contained the following:
>
> ```
> makefile:
> - code-lint
> - unit-test
> ```
>
> And where applicable, add a .venv target for python charms and recommend
> the use of having charm deps modeled in requirements.txt and pip installed
> to that virtualenv.
>
> Opinions, additions, concerns?
>
> On Thu Jan 22 2015 at 11:41:56 AM Wes Mason 
> wrote:
>
>> On 22 January 2015 at 16:36, Simon Davy  wrote:
>>
>>>  On 22 January 2015 at 16:29, David Britton 
>>> wrote:
>>> > On Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote:
>>> >> On 22 January 2015 at 15:13, David Britton <
>>> david.brit...@canonical.com> wrote:
>>> >> >
>>> >> > lint:
>>> >> >  - make lint
>>> >> >
>>> >>
>>> >> Could we also make[1] the charm linter lint the makefile for the
>>> >> presence of targets agreed in the outcome of this thread?
>>> >
>>> > "charm proof"
>>> >
>>> > I like it.  (bundle tester already runs this)
>>>
>>> Which is interesting, as my lint targets general runs charm proof too,
>>> so it'd be run twice in that case?
>>>
>>> Not a big issue, but if the charm store/review queue is automatically
>>> charm-proofing too, perhaps the make lint target should not be?
>>>
>>> --
>>> Simon
>>>
>>>
>> Whelp it's still nice to have as part of lint when developing the charm,
>> and charm-proof isn't exactly the slowest process to run multiple 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] fail2ban, mysql, python-django, wildfly-ha-slave, wordpress

[Tim Van Steenburgh]

Merged:

fail2ban
https://code.launchpad.net/~jose/charms/trusty/fail2ban/tag-security/+merge/245923
mysql
https://code.launchpad.net/~niedbalski/charms/precise/mysql/precise-syncup/+merge/244436

Not merged: (sent back for further work or clarification from submitter)

python-django
https://code.launchpad.net/~bloodearnest/charms/precise/python-django/trunk/+merge/235430
wildfly-ha-slave https://bugs.launchpad.net/charms/+bug/1399239
wordpress
https://code.launchpad.net/~hackedbellini/charms/trusty/wordpress/mod_rewrite/+merge/244599
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] bundletester 0.5.0 released on PyPI

[Tim Van Steenburgh]

# Features

- Test remote sources, e.g.: `bundletester -t cs:trusty/meteor`

Remote sources URL can point to the Charm Store, Launchpad, Github, or
Bitbucket. Full list with examples can be found in the README [1].

# Bug Fixes

- Fix bug that caused captured process output to be empty when using the
json reporter.

# Upgrading

`pip install -U bundletester`


[1] https://github.com/juju-solutions/bundletester#remote-sources
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] bitlbee, bip, mysql, rabbitmq-server

[Tim Van Steenburgh]

This morning I reviewed and merged the following:

https://code.launchpad.net/~jose/charms/precise/bitlbee/set-maintainer/+merge/243701
https://code.launchpad.net/~barryprice/charms/precise/bip/add_backlog_always_option/+merge/245145
https://code.launchpad.net/~corey.bryant/charms/trusty/mysql/render/+merge/245027
https://code.launchpad.net/~corey.bryant/charms/trusty/rabbitmq-server/render/+merge/245039

I also created and proposed a basic amulet test for rabbitmq-server.

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

[Review Queue] wildfly-ha-master

[Tim Van Steenburgh]

Today I reviewed this new charm submission:
https://bugs.launchpad.net/charms/+bug/1399228

Good-looking start, just needs a little cleanup. I posted a new branch with
my suggested changes and some comments to explain those changes.

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

[Review Queue] Misc charm cleanup

[Tim Van Steenburgh]

This morning I reviewed and merged the changes listed below. All of these
were minor changes: fixes for tests, typos, and proofing errors.

https://code.launchpad.net/~jorge/charms/precise/spip/fix-category/+merge/239378
https://code.launchpad.net/~jorge/charms/precise/couchdb/add-readme/+merge/239386
https://code.launchpad.net/~jorge/charms/precise/mysql/fix-metadata/+merge/239391
https://code.launchpad.net/~jorge/charms/precise/serverdensity/fix-metadata/+merge/239429
https://code.launchpad.net/~jorge/charms/precise/tomcat6/fix-metadata/+merge/239430
https://code.launchpad.net/~jorge/charms/precise/teamspeak3/fix-metadata/+merge/239390
https://code.launchpad.net/~aisrael/charms/precise/musica/charm-proof/+merge/237756
https://code.launchpad.net/~aisrael/charms/precise/nfs/automated-test-fixes/+merge/237590
https://code.launchpad.net/~dannf/charms/trusty/mongodb/typo/+merge/240313
https://code.launchpad.net/~dannf/charms/trusty/mongodb/deploy-test-trusty/+merge/240322

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

[Review Queue] Trusty charms: samhain, rkhunter, logrotate, logstash

[Tim Van Steenburgh]

This morning I did follow-up reviews on:

[1] samhain - instrusion alert subordinate
[2] rkhunter - rootkit scanner subordinate
[3] logrotate

All are quality submissions by Chris Stratford (thanks Chris!) with passing
Amulet tests. Each got a +1 from me, pending some minor suggested updates
to metadata and tests.

I also reviewed and gave a +1 to a new logstash charm [4] from Charles
Butler, also with passing Amulet tests. Nice work Chuck!

[1] https://bugs.launchpad.net/charms/+bug/1375865
[2] https://bugs.launchpad.net/charms/+bug/1375796
[3] https://bugs.launchpad.net/charms/+bug/1375790
[4] https://bugs.launchpad.net/charms/+bug/1386140
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ForgeRock OpenAM & OpenDJ

[Tim Van Steenburgh]

This morning I did two preliminary reviews on OpenAM and OpenDJ charms from
ForgeRock [1]. These charms are still in development but are off to a good
start. Both would benefit greatly from better usage instructions in the
READMEs. My review comments can be found in Launchpad [2].

[1] http://forgerock.com/
[2] https://bugs.launchpad.net/charms/+bug/1384290
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Break a relationship from the config-change hook

[Tim Van Steenburgh]

>
> In my config-change hook when triggered after initial install, changes
> will have effect on some of the relationships already established. The
> relationship has to be broken/invalidated and reestablished.
>
> 1) How can I check what relations are established from within the
> config-changed hook ?
>

You can use `relation-ids` and `relation-list` for this. [1]


> 2) How can I executed the “*relation-broken” hook from the "config-change"
> hook for those relationship which are established ?
>

Instead of breaking and reestablishing existing relationships, you'll want
to reconfigure them. Use `relation-set` [2] to set relation data from
within you config-changed hook. This will trigger the *relation-changed
hook on related units. Those units can get the new relation data using
`relation-get`, reconfigure themselves, and if necessary, restart their
service(s).

[1] https://juju.ubuntu.com/docs/authors-hook-environment.html#relation-list
[2] https://juju.ubuntu.com/docs/authors-hook-environment.html#relation-set
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Charmers Application

[Tim Van Steenburgh]

Hi everyone,

Please consider this my application to join the Charmers team!

I've been working in the Juju ecosystem for about 7 months, writing and
reviewing charms, contributing to charm-related tools and libraries, and
establishing automated-testing for charms and bundles. Here's a
non-exhaustive list of my contributions, in no particular order:

* Author and maintainer of the Meteor charm [1]
* Numerous charm patches and reviews [2]
* Contributions to the Amulet testing tool [3]
* Author of the plugin system for `charm create` in the charm-tools project
[4]
* Author of the charmguardian testing tool [5]
* Extensive work on automated charm testing [6]
* Created documentation for the charm-helpers library [7]
* Miscellaneous other contributions to charmworldlib, charm-tools,
charm-helpers, bundletester, juju-deployer

I've thoroughly enjoyed being a part of the Juju community and I'm excited
about the future of Juju! I hope I can further contribute to Juju by
becoming a Charmer and helping to maintain the Juju ecosystem in an
official capacity. Thanks for your consideration!

Tim Van Steenburgh

[1] https://jujucharms.com/precise/meteor-2/?text=meteor#readme
[2] http://review.juju.solutions/user/tvansteenburgh
[3] https://github.com/marcoceppi/amulet/commits?author=tvansteenburgh
[4] https://launchpad.net/charm-tools
[5] https://github.com/juju-solutions/charmguardian
[6] http://blog.juju.solutions/cloud/juju/2014/10/02/charm-testing.html
[7] http://pythonhosted.org/charmhelpers/
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] encrypted storage

[Tim Van Steenburgh]

Here's what I reviewed this morning:

[1] This merge brings encryption to the storage charm. A great addition but
lacks tests. Sent back requesting tests be added to cover the new
functionality.

[2] Bugfix for rabbitmq-server. Approved.

[3] Bugfix for cassandra. Approved.

---
[1]
https://code.launchpad.net/~chris-gondolin/charms/trusty/storage/trunk/+merge/234452
[2]
https://code.launchpad.net/~cprov/charms/precise/rabbitmq-server/rabbit-admin-for-real/+merge/234426
[3]
https://code.launchpad.net/~aisrael/charms/precise/cassandra/apt-gpg-key/+merge/235341
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] devspace-simulator

[Tim Van Steenburgh]

>
> When we review a charm do we bring it up on various clouds? Do we have any
> way to verify that it works on, say, OpenStack and EC2?
>

We've been working on automated charm/bundle testing quite a bit recently.
Right now we kick off tests on AWS, HP, and LXC any time a charm is updated
in the store. The next step (coming soon) is to trigger these same tests
when a charm/bundle merge proposal is submitted, so we can ensure tests
pass before starting the review. I expect we'll be adding more test
substrates over time as well.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] devspace-simulator

[Tim Van Steenburgh]

Yesterday I reviewed devspace-simulator [1], a new charm submission. The
charm deploys successfully, but needs some clean-up [2] in order to meet
Charm Store poilcy and be eligible for promulgation.

[1] http://devspace.hsenidmobile.com/
[2] https://bugs.launchpad.net/charms/+bug/1353535/comments/1
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] charm proof errors

[Tim Van Steenburgh]

>
> # Questions
> Should charm proof run lint check? Right now our docs say charms must
> pass proof (no warning or errors) to pass review, but it does not say
> the charm has to pass lint check. Thus, we should consider making lint
> errors not fail charm tests or have charm proof run lint (where
> appropriate, ie for py charms) and return an appropriate
> error/warning/info.
>

Lint is only run against charms that have voluntarily included a lint
target in
their Makefile. It's an opt-in extra test for charm authors. You don't have
to
participate, but if you include a lint target, we'll insist that it passes.

This won't be officially enforced until the review queue is hooked up to the
new automated charm testing stuff, at which point we'll need to update the
docs, making it clear exactly which tests will be run when a review is
posted.
(I'll be happy to take care of that.)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] rabbitmq-server, python-django

[Tim Van Steenburgh]

# TL;DR for Charm Authors (tips from today's reviews)

1. Make sure charm-proof, "testing" make targets (e.g. lint, test), and
amulet tests are passing. We are quickly approaching a day when all merge
proposals for charms and bundles will be gated on tests automatically, and
rejected if they fail.

If you do have lint/test make targets, make sure your makefile handles
installation of any dependencies required by your tests.

2. Don't assume the reviewer will know how to test the feature you're
adding to your charm. Please include instructions for testing!


# The Reviews

The rabbitmq-server [1] merge proposal adds an 'access-network' config
option for specifying the network on which clients can connect.

The code looked fine but there were some `charm-proof` failures, and I was
unsure how to conduct a functional test of the new feature as there were no
instructions on how to do so.

Set to Needs Fixing.


The python-django [2] merge proposal is a patch to add some new relations
and remove ansible dependencies.

This review ended rather quickly after I hit charm-proof, lint, and test
failures.

Set to Needs Fixing.


[1]
https://code.launchpad.net/~james-page/charms/trusty/rabbitmq-server/network-splits/+merge/228152
[2]
https://code.launchpad.net/~patrick-hetu/charms/precise/python-django/pure-python/+merge/226742
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Application for Juju Charmer Status

[Tim Van Steenburgh]

I'm not a charmer either, but I'd give this a big +1 based on my
personal interactions with José. He's very active in #juju,
super-friendly, enthusiastic, and has put a ton of time into the
Juju ecosystem by charm-authoring, reviewing, and helping others.

Awesome job José, you rock!


On Mon, Aug 25, 2014 at 3:29 PM, Jorge O. Castro  wrote:

> On Wed, Aug 20, 2014 at 4:36 PM, José Antonio Rey  wrote:
> > So I believe it's the time. After a while, I'm now applying for charmer
> > status.
>
> I'm not a voting charmer but just wanted to +1 your application and
> your contributions so far!
>
>
> --
> 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

[Review Queue] Cassandra for ppc64le

[Tim Van Steenburgh]

Today I reviewed an update [1] to the Cassandra charm that allows it to run
on ppc64le. It does so by installing a Cassandra .deb that is bundled with
the charm, modifying the java stack size, and removing a jvm option that
does not work on OpenJDK.

The charm can still be deployed on other architectures without a bundled
.deb, in which case it will install Cassandra from the Apache apt repo.

The charm started up successfully on ppc64le, and on x86_64 both with and
without a bundled .deb.

For more details, see the full review [2].

Tim

[1]
https://code.launchpad.net/~mbruzek/charms/precise/cassandra/ppc64le/+merge/226291
[2]
https://code.launchpad.net/~mbruzek/charms/precise/cassandra/ppc64le/+merge/226291/comments/563679
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Unit-testing hooks

[Tim Van Steenburgh]

Hi Federico,

Yes, python is preferred. The Openstack charms have great unit tests - you
might start by looking at one of those (cinder, for example).

Tim


On Sat, Jun 14, 2014 at 6:18 AM, Federico Giménez Nieto 
wrote:

> Hi list, this is my first message so greetings to all.
>
> Just a quick newbie question, are there any preferred practices for
> unit-testing the charm hooks? I've seen some examples, all for python
> hooks, would it be better use python instead of shellscript in order have
> more testable code?
>
> Thanks, cheers
>
>
>
> --
> 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-helpers documentation

[Tim Van Steenburgh]

Hi Xander,

Unfortunately there is no charmhelpers documentation right now other than
the source itself. Hopefully that will be rectified in the coming months.
To get started you may want to look at the rabbitmq-server charm, which has
a ceph relation and uses charmhelpers[1]. There is also a video[2] on
charmhelpers which may be useful if you're new to it.

If you get stuck please don't hesitate to ask for help in #juju on freenode
irc!

HTH,

Tim

[1]
http://bazaar.launchpad.net/~charmers/charms/precise/rabbitmq-server/trunk/view/head:/hooks/rabbitmq_server_relations.py#L304
[2] http://www.youtube.com/watch?v=6kWfLujVwNI




On Thu, May 15, 2014 at 3:39 AM, Xander Maas  wrote:

> Hi all,
>
> Is there any (unfinished) documentation for charm-helpers I can use? I am
> trying to implement Ceph into the ownCloud charm and would like to use
> Charm-helpers in this.
>
> Xander
>
> --
> 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