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 
> 

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

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

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

Re: Juju Kubernetes vSphere storage

[Tim Van Steenburgh]

On Thu, Sep 7, 2017 at 1:31 PM, Micheal B <tic...@tictoc.us> 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 <tim.van.steenbu...@canonical.com>
> *Date: *Thursday, September 7, 2017 at 6:33 AM
> *To: *Micheal B <tic...@tictoc.us>
> *Cc: *juju <Juju@lists.ubuntu.com>
> *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 <tic...@tictoc.us> 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 <haw.loe...@canonical.com>
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 <jamesbe...@gmail.com> 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 <jamesbe...@gmail.com>
>> 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" <tim.van.steenburgh@canonical.
> 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" <tim.van.steenburgh@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]
>>
>>
>> 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

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

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
>>>>>>>
>>>>>>>
>>>>>>> I'm trying to 

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)
>>>>> --
>>>>> Traceback (most recent call last):
>>>>>   File "./10-deploy&q

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

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 <t...@analytical-labs.com> 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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

[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: 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 <t...@analytical-labs.com>
>> 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 <t...@analytical-labs.com>
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 <t...@analytical-labs.com>
>> 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 <t...@analytical-labs.com> 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

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 <t...@analytical-labs.com>
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 <t...@analytical-labs.com> 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 <t...@analytical-labs.com>
>>> 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 <stuart.bis...@canonical.com>
>>>> wrote:
>>>>
>>>>> On 9 March 2016 at 20:31, Tom Barber <t...@analytical-labs.com> wrote:
>>>>> > Morning all
>>>>> >
>>>>> > I'm trying to test for c

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

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
> <tim.van.steenbu...@canonical.com> 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 jos...@liau.ca 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 jos...@liau.ca 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] 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] 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] 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 ma...@ondina.co 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 wesley.ma...@canonical.com
 wrote:

 On 22 January 2015 at 16:36, Simon Davy bloodearn...@gmail.com wrote:

  On 22 January 2015 at 16:29, David Britton david.brit...@canonical.com
 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

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

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

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

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 jo...@ubuntu.com wrote:

 On Wed, Aug 20, 2014 at 4:36 PM, José Antonio Rey j...@ubuntu.com 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 fgime...@coit.es
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