from:"Matt Bruzek"

Kubernetes charms now support 1.6!

2017-04-12 Thread Matt Bruzek

We are proud to release the latest Charms supporting Kubernetes version
1.6.1!

Kubernetes 1.6 is a major milestone for the community, we’ve got a full
write up of features and support on our blog <
https://insights.ubuntu.com/2017/04/12/general-availability-of-kubernetes-1-6-on-ubuntu/
>
Getting Started

Here’s the simplest way to get a Kubernetes cluster up and running on an
Ubuntu 16.04 system:

sudo snap install conjure-up --classic
conjure-up kubernetes

During the installation conjure-up will ask you what cloud you want to
deploy on and prompt you for the proper credentials. If you’re deploying to
local containers (LXD) see these instructions <
https://kubernetes.io/docs/getting-started-guides/ubuntu/local/> for
localhost-specific considerations.

For production grade deployments and cluster lifecycle management it is
recommended to read the full Canonical Distribution of Kubernetes
documentation .
Upgrading an existing cluster

If you’ve got a cluster already deployed, we’ve got instructions to help
get you upgraded. If possible, deploying a new cluster will be the easiest
route. Otherwise, the instructions for upgrading are outlined here:
https://insights.ubuntu.com/2017/04/12/general-availability-of-kubernetes-1-6-on-ubuntu/#upgrades
Changes in this release

Support for Kubernetes v1.6, with the current release being 1.6.1
-

Installation of components via snaps: kubectl, kube-apiserver,
kube-controller-manager, kube-scheduler, kubelet, and kube-proxy. To learn
more about snaps: https://snapcraft.io
-

Added ‘allow-privileged’ config option on kubernetes-master and
kubernetes-worker charms. Valid values are true|false|auto (default: auto).
If the value is ‘auto’, containers will run in unprivileged mode unless GPU
hardware is detected on a worker node. If there are GPUs, or the value is
true, Kubernetes will set `--allow-privileged=true`. Otherwise the flag is
set to false.
-

Added GPU support (beta). If Nvidia GPU hardware is detected on a worker
node, Nvidia drivers and CUDA packages will be installed, and kubelet will
be restarted with the flags required to use the GPU hardware. The
‘allow-privileged’ config option must be ‘true’ or ‘auto’.
-

Nvidia driver version = 375.26; CUDA version = 8.0.61; these will be
configurable future charm releases.
-

GPU support does not currently work on lxd.
-

This feature is beta - feedback on the implementation is welcomed.
-

Added support for running your own private registry, see the docs here

for instructions.

General Fixes:

Fixed a bug in the kubeapi-load-balancer not properly forwarding
SPDY/HTTP2 traffic for `kubectl exec` commands.

Etcd specific changes:

Installation of etcd and etcdctl is now done using the `snap install`
command.
-

We support upgrading the previous etcd charm, to the latest charm with
snap delivery mechanism. See manual upgrade process for updating existing
etcd clusters.

Changes to the bundles and layers:

Add registry action to the kubernetes-worker layer, which deploys a
Docker registry in Kubernetes.
-

Add support for kube-proxy cluster-cidr option.

Test results

The Canonical Distribution of Kubernetes is running daily tests to verify
it works with the upstream code. As part of the Kubernetes test
infrastructructure we upload daily test runs. The test results are
available on the dashboard. Follow along with our progress here:

https://k8s-gubernator.appspot.com/builds/canonical-kubernetes-tests/logs/kubernetes-gce-e2e-node/
How to contact us

We're normally found in the Kubernetes Slack channels and attend these
Special Interest Group (SIG) meetings regularly:

- sig-cluster-lifecycle <
https://kubernetes.slack.com/messages/sig-cluster-lifecycle/>
- sig-cluster-ops

- sig-onprem >

Operators are an important part of Kubernetes, we encourage you to
participate with other members of the Kubernetes community!

We also monitor the Kubernetes mailing lists and other community channels <
http://kubernetes.io/community/>, feel free to reach out to us. As always,
PRs, recommendations, and bug reports are welcome:

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

[Review Queue] apache2

2017-03-22 Thread Matt Bruzek

I spent some time reviewing the changes to enable xenial for the apache2
charm by user ack.

The charm is still original and needs to be updated to reactive but the
author didn't make any changes to the code, just the metadata. Also this
charm needs a new maintainer as the existing one has moved on.

The changes passed my review and I promulgated the apache2 charm! You can
now use it on xenial!

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANNOUNCE] Canonical Distribution of Kubernetes - release 1.5.3

2017-03-03 Thread Matt Bruzek

We have released the 1.5.3 version of the Canonical Distribution of
Kubernetes!

Kubernetes 1.5.3 is a patch release comprised of mostly bugfixes, and we
encourage you to check out the release notes <
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG.md#changelog-since-v152
>.
Getting Started:

Here’s the simplest way to get a Kubernetes 1.5.3 cluster up and running on
an Ubuntu 16.04 system:

sudo snap install conjure-up --classic
conjure-up kubernetes

For production grade deployments and cluster lifecycle management it is
recommended to read the full Canonical Distribution of Kubernetes
documentation .

Home page: https://jujucharms.com/canonical-kubernetes/

Source code:
https://github.com/kubernetes/kubernetes/tree/master/cluster/juju
How to upgrade:

With your Kubernetes model selected, you can deploy the new bundle to
upgrade your cluster if on the 1.5.x series of kubernetes. At this time
releases before 1.5.x have not been tested. Depending on which bundle you
have previously deployed, run:

juju deploy canonical-kubernetes

juju deploy kubernetes-core

We have documented the upgrade scenarios in the Kubernetes documentation.
If your cluster is running pods you should upgrade with a Blue/Green
strategy outlined in the Upgrade documentation: <
https://kubernetes.io/docs/getting-started-guides/ubuntu/upgrades/>

If you have made tweaks to your deployment bundle, such as deploying
additional worker nodes as a different label, you will need to manually
upgrade the components. The following command list assumes you have made no
changes to the component names.

juju upgrade-charm kubernetes-master

juju upgrade-charm kubernetes-worker

juju upgrade-charm etcd

juju upgrade-charm flannel

juju upgrade-charm easyrsa

juju upgrade-charm kubeapi-load-balancer

This will upgrade the charm code, and the resources to kubernetes 1.5.3
release of the Canonical Distribution of Kubernetes.
Changes in this release:

Support for Kubernetes v1.5.3

General Fixes:

Fix some status messages to more accurately reflect the cluster state.

Clone the appropriate branch to get the right addon templates for a
release when building the kubernetes-master charm.

Make the python code in cluster/juju pass flake8 lint tools cleanly.

Make the kubernetes master sync with other masters for better HA support.

Update the actions to run with python3.

Disable anonymous authorization on kubelet
(Thanks to
community member @raesene for pointing this out!)

Etcd specific changes:

Add the ability to attach NRPE to etcd for monitoring with an external
Nagios server.
-

Add the debug action to the etcd charm that makes it easier to collect
debug information in the field.

Changes to the bundles:

Update conjure-up information the CDK bundle readme.

Update conjure-up information in the Kubernetes core bundle readme.

Test results:

The Canonical Distribution of Kubernetes is a running daily tests to verify
it works with the upstream code. As part of the Kubernetes test
infrastructructure we upload daily test runs. The test results are
available on the dashboard. Follow along with our progress here:

https://k8s-gubernator.appspot.com/builds/canonical-kubernetes-tests/logs/kubernetes-gce-e2e-node/

How to contact us:

We're normally found in the Kubernetes Slack channels and attend these
Special Interest Group (SIG) meetings regularly:

- sig-cluster-lifecycle <
https://kubernetes.slack.com/messages/sig-cluster-lifecycle/>
- sig-cluster-ops

Operators are an important part of Kubernetes, we encourage you to
participate with other members of the Kubernetes community!

Fwd: Agenda for tomorrow's meeting

2017-01-18 Thread Matt Bruzek

Suchitra,

Your team should be able to update the websphere-liberty charm in the
ibmcharmers namespace. Since I am in the ibmcharmers group I was able to
run the command successfully.

$ charm release cs:~ibmcharmers/trusty/websphere-liberty-6
url: cs:~ibmcharmers/trusty/websphere-liberty-6
channel: stable
warning: bugs-url and homepage are not set.  See set command.

And now I see version 6 at the ibmcharmers namespace:
https://jujucharms.com/u/ibmcharmers/websphere-liberty/trusty/

Your should be able to update the charm in the ~ibmcharmers namespace. I am
not sure why you saw the error. Perhaps your version of charm-tools is
different or you were not logged in. Use charm version and charm whoami to
verify. My version of charm tools is:

$ charm version
charm 2.2.0-0ubuntu1~ubuntu16.04.1~ppa2
charm-tools 2.1.9

Copying the juju mailing list in case someone has seen this problem before.
Discuss this on the juju mailing list if you have any further problems or
questions.

   - Matt Bruzek <matthew.bru...@canonical.com>

-- Forwarded message --
From: Suchitra Venugopal1 <suchv...@in.ibm.com>
Date: Tue, Jan 10, 2017 at 3:27 AM
Subject: Re: Agenda for tomorrow's meeting
To: Kevin Monroe <kevin.mon...@canonical.com>, Matt Bruzek <
matthew.bru...@canonical.com>
Cc: Shilpa Kaul <shilk...@in.ibm.com>, Shruthima Almavar <
salma...@in.ibm.com>


Hi Kevin,
 Regarding issue related to WLP charm push , we did a push again and tried
to do a charm release.

1. The charm push command worked but gave the old error which we ignored as
of now :

root@islrpbeixv685:~/charms/trusty/websphere-liberty# charm push .
cs:~ibmcharmers/trusty/websphere-liberty
url: cs:~ibmcharmers/trusty/websphere-liberty-6
channel: unpublished

2.  Charm release command gave the following error:




When we checked for the WLP charm in Charm store we see the stream as
* cs:trusty/websphere-liberty-3
*(as shown in below screenshot) and not finding the path*
cs:~ibmcharmers/trusty/websphere-liberty-6.  *How do we resolve this issue?



*Suchitra Venugopal*

*Project ManagerJuju Charms*
--
*Phone: **+91-80-494-93581*
*Mobile: **+91-966-312-6000*
*E-mail: **suchv...@in.ibm.com* <suchv...@in.ibm.com>
*Product Transformation Centre* <http://ptc.hursley.ibm.com/ptcshop/>

*INDIA SOFTWARE LABS, IBM SYSTEMS,EGL C, 6th FLOOR, BANGALORE*
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ibm-platform-lsf-master

2016-11-30 Thread Matt Bruzek

I spent some time reviewing charms from our IBM partners.

The ibm-platform-lsf-master passed my tests and I promoted it to
recommended status.

https://jujucharms.com/ibm-platform-lsf-master/

Congratulations and great job to the IBM charmers who made this possible.

Cheers!

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

jujubox and charmbox

2016-11-28 Thread Matt Bruzek

With the release of Juju 2.0 we have spent some time updating jujubox and
charmbox with the latest install steps and tools.

We use these containers for some of our internal tooling. If you are using
these containers please note the changes and let us know if you have any
feedback.

*jujubox* - an isolated container with just the Juju tools.

   - Created a "juju-1" branch that installs Juju 1.x the master branch now
   tracks Juju 2.x.
   - Added the ability to build with a user other than ubuntu.
   - Using ENV directives for JUJU_DATA and JUJU_REPOSITORY environment
   variables.
   - Using the ENTRYPOINT, WORKDIR and USER directives removed the need for
   run.sh.
   - Changed the ADD directives to COPY very minimal change but enough to
   warrant review comments.
   - Using FROM ubuntu:16.04 as the common base.
   - Removed the extra packages that are not used by Juju.


These changes resulted in a significant reduction in the jujubox image size.

*charmbox* - an isolated container with amulet, charm-tools, bundletester
and git. We use this container for some CI tools on our team, and some
people use it for charm reviews.

   - The master branch now installs Juju 2.x.
   - Removed the devel branch as we will only be tracking jujubox branches.
   - Updated charmbox to be in sync with the changes from jujubox.
   - Added the packages that were removed from jujubox
   - Using ENV directives for LAYER_PATH and INTERFACE_PATH.
   - Charm-tools is installed from source as this gives us all access to
   fixes that are not yet released.

We also re-enabled the build triggers to build charmbox when jujubox is
updated. This should provide a better experience using these containers.
Please let us know if you find any problems with these containers.

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Regarding juju Storage - using MAAS as cloud provider

2016-10-19 Thread Matt Bruzek

Shilpa,

There are some documentation about creating storage on MAAS here:
https://maas.ubuntu.com/docs/storage.html

Using this document you should be able to create block devices in MAAS that
you can later use in Juju.

The Juju storage documentation can be found here:
https://jujucharms.com/docs/stable/charms-storage

As an example, once you have your MAAS storage created and tagged, you
could create a storage pool in Juju like this:

juju create-storage-pool mypool maas tags=

And then you could add a storage constraint to deploy your charm like this:

juju deploy  --storage disks=mypool,1G

I have not tried MAAS storage with Juju so you may need some additional
commands. If anyone else has examples of combining MAAS storage with Juju
please reply here to let us know. Thanks!

   - Matt Bruzek <matthew.bru...@canonical.com>

On Tue, Oct 18, 2016 at 11:29 AM, Shilpa Kaul <shilk...@in.ibm.com> wrote:

> Hi Matt/Kevin,
>
> We have a charm called as Spectrum Scale (previously called as gpfs) which
> is making use of Juju Storage feature. I have tested this on AWS, making
> use of ebs as storage option. When I deploy the charm say  "*juju deploy
> ibm-spectrum-scale-manager --storage disks=ebs,1G*", I am able to get
> block storage disks. My charm uses this disk and then creates a file sytem
> on top of that.
> I am able to test this on AWS, but now we have got a scenario where we
> have to deploy the charm on physical servers or VM's. We have configured
> MAAS for VM's and are able to deploy a sample charm as well using MAAS as
> cloud provider, but I am not sure how to make use of juju storage options
> incase of MAAS. Can you please provide us with any contact who can help us
> in making use of storage option with MAAS as cloud provider.
>
> Thanks and Regards,
> Shilpa Kaul
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charming with Resources

2016-10-17 Thread Matt Bruzek

Late to this thread, but I had to add a few things to this resource
discussion.

In my experience with charm development zero byte resources has been
beneficial in three areas, charm development, third party charms, and
testing.

*Charm development*. When creating a new charm that uses resources, it is
impossible to push a charm to the store without a resource. It was useful
to push a zero byte resource to get the charm up to the store before we had
the resources ready or sorted.

*Third party charms*. We already have third party charm developers using
zero byte resources so they can push their charms to the store. Those
charms require users to pay for the resources and "juju attach" them when
to the controller. Zero byte resources allow them to get their charm in the
store, and companies can still deliver software the way they want.

*Testing*. Some charms can deal with the lack of resource by falling back
to an apt-get install, or another method and then it is useful to have a
zero byte resource for testing. Some networks will not have a connection to
the charm store, so being able to test the zero byte resource is crucial
for limited network environment testing.

At least one time in early betas of Juju we got an incomplete resource,
either the file was too big or the connection was interrupted. It was not
clear to me if the "resource_get" python method threw an exception in that
case (to the best of my knowledge it simply calls resource-get command line
which may have completed). So we came up with a work around that checked
the resulting file size.

Also charms can not be tested with many of our tools until they get in the
charm store. At this time some of our tools do not support attaching local
resources so we can not test local charms with these tools. Of course we
are improving the tools but that was a legitimate blocker for charms that
use resources.

If there is disagreement on this, we don't have to make it policy we can
just use zero byte resources as a convention for the charms that
legitimately need it.

   - Matt Bruzek <matthew.bru...@canonical.com>

On Thu, Sep 29, 2016 at 1:08 PM, Rick Harding <rick.hard...@canonical.com>
wrote:

> Correct, the original discussion was the charm behaving differently if the
> fingerprint had changed of the resource on the remote end. However, running
> resource-get deals with only fetching the new data if the fingerprint
> changes and so there wasn't a big draw to the feature to that end.
>
> Now, in this way, what you're asking is for some way to tell when there is
> no resource? I guess I'm missing what the 0byte resource is giving you out
> of the gates. The charm won't work, you want to fall back? And as soon as
> the charm gets a non-0byte resource it's no longer useful.
>
> I really feel like that if someone wants to publish something through the
> store that they have to supply at least some bin that runs and outputs a
> clear message to the user "got get the proper bins from here" instead of
> just failing to deploy. Charm authors should be doing whatever is possible
> to fail in a clear way, through the charm, so that users are guided on the
> right path to moving forward. I don't think the charmstore or juju having
> 0byte defaults or "no resource found" is correct. It really needs to be the
> charm taking that failure and putting context and a path for the user to
> follow vs just "not found".
>
> On Thu, Sep 29, 2016 at 11:48 AM Charles Butler <
> charles.but...@canonical.com> wrote:
>
>> We initially asked for resource fingerprints to be available before
>> fetching so we could do something less expensive.
>>
>> That didn't make the 2.0 cut and was pushed back needing more forethought.
>>
>> This however is a good example of why it's a better option.
>>
>>
>> And I had similar logic in etcd at one point. I'll be revisiting the etcd
>> later to fold offlineability back into the charm using what you've proposed.
>>
>> If not resource : apt install
>>
>> --
>> Juju Charmer
>> Canonical Group Ltd.
>> Ubuntu - Linux for human beings | www.ubuntu.com
>> Juju - The fastest way to model your application | www.jujucharms.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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] Kubernetes core bundle

2016-10-14 Thread Matt Bruzek

10/14 Release Notes

The container team at Canonical has released more Kubernetes goodies for
people to use and deploy on the public clouds. If you have seen the email
from Charles Butler you may already know we have been working on adding new
operations and improving the Canonical Distribution of Kubernetes (CDK).
That cluster requires 11 machines which can get expensive if you were
interested in evaluating Kubernetes on your favorite public cloud. So we
created a smaller “hyper converged” Juju bundle that uses LXD to create a
Kubernetes cluster with only two machines!

We call this one Kubernetes core and it is available at:
https://jujucharms.com/kubernetes-core/

Since this bundle reuses the same charms you get many of the same
operations in the core cluster just with less machines.

This is a work in progress so if you find any bugs with this Juju bundle
please create issues here:
https://github.com/juju-solutions/bundle-kubernetes-core/issues

If you have questions, you can find us on irc in #juju on chat.freenode.net.
My nickname is mbruzek.

Kubernetes Core Bundle

A minimal Kubernetes cluster, only deploying the bare minimum required to
evaluate Kubernetes. Useful when doing Kubernetes development in resource
constrained environments.


   -

   The kubernetes-core bundle has been updated with our latest release of
   the Canonical Distribution of Kubernetes (CDK) charms.
   -

   Brand new README imported from the CDK bundle.
   -

   Updated tests


This bundle is the fastest and cheapest way to get started with Kubernetes.
It does not have all the bells and whistles of our Canonical Distribution
of Kubernetes but you can always deploy that bundle if you need more
monitoring and log aggregation. https://jujucharms.com/canonical-kubernetes/

We are interested in your feedback on the cluster and how you are using
Kubernetes. If you want to contact me, please reply directly to this email,
or find me on slack or irc as “mbruzek”. Remember to file bugs or issues at
our github repository:
https://github.com/juju-solutions/bundle-kubernetes-core/issues

Thanks!

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 2.0 as default on main repos?

2016-08-08 Thread Matt Bruzek

Hi Steve,

If you have not installed any of the older packages the commands are
simple:

sudo add-apt-repository ppa:juju/develsudo apt updatesudo apt install juju

As always, please refer to the documentation when it comes to installation
instructions: https://jujucharms.com/docs/stable/getting-started-general

I found the process a little bit more difficult because I have installed
every release of the 2.0 beta and it caused problems. I had to purge all
the other juju packages before the above commands worked for me.

We are interested in your experience with Juju. Please email me or the list
if you have any further questions. We also communicate in IRC #juju in
chat.freenode.net.


   - Matt Bruzek <matthew.bru...@canonical.com>

On Mon, Aug 8, 2016 at 12:32 PM, Steve Pe <steve...@gmail.com> wrote:

> I'm newbi what is command to install latest beta version of Juju on
> ubuntu?  thx
>
> On Mon, Aug 8, 2016 at 12:23 PM, Rick Harding <rick.hard...@canonical.com>
> wrote:
>
>> Thanks for the feedback Jose. Merlijn also brought up a similar note and
>> I replied on the main juju list to help explain the current pain window
>> we're working through. Rather than copy/paste you can see it here:
>>
>> https://lists.ubuntu.com/archives/juju/2016-August/007679.html
>>
>> Please let me know if you'd like to chat. I understand that it feels very
>> awkward right now, but it's part 'by the plan' as far as the plan went, but
>> also 'not by the plan' as we'd hoped to have Juju 2.0 GA for folks at this
>> time. We're very close now and the feedback from users of 2.0 has been
>> essential to getting so much right and better for everyone.
>>
>> Jose, let me know if you want to reach out and chat about the transition
>> and why things are setup they way they are. We really appreciate the
>> feedback and patience as we go through the 1.X to 2.X transition.
>>
>> Rick
>>
>> On Mon, Aug 8, 2016 at 11:32 AM José Antonio Rey <j...@ubuntu.com> wrote:
>>
>>> Hey Matt,
>>>
>>> Thanks for the link.
>>>
>>> If anyone reading has a way to help get it fixed, please do so. This is
>>> a horrible bug that causes inconsistencies, and until 2.0 is released it
>>> should not be in main.
>>>
>>> On Mon, Aug 8, 2016, 09:22 Matt Bruzek <matthew.bru...@canonical.com>
>>> wrote:
>>>
>>>> Hello José,
>>>>
>>>> I ran into this problem myself and filed a bug with the packaging.
>>>>
>>>> https://bugs.launchpad.net/juju-release-tools/+bug/1609437
>>>>
>>>> While I still think this is a bug, I did find a work around which I put
>>>> in the bug for other people having this same problem. Hope that helps!
>>>>
>>>>- Matt Bruzek <matthew.bru...@canonical.com>
>>>>
>>>> On Wed, Aug 3, 2016 at 7:49 PM, José Antonio Rey <j...@ubuntu.com>
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I am deploying some production servers and am seeing a weird behavior:
>>>>>
>>>>> 2.0~beta12-0ubuntu1.16.04.1 is the default for the 'main' repositories
>>>>> of archive.ubuntu.com
>>>>>
>>>>> 1.25.6-0ubuntu1~16.04.1~juju1 is the default for ppa:juju/stable
>>>>>
>>>>> Is this intended? Doesn't feel right to me.
>>>>>
>>>>> Thanks in advance for the insight!
>>>>>
>>>>> --
>>>>> 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/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Best wishes;
>
> Steve Pe
> ( https://www.linkedin.com/in/stevepe )
>
> "Doing good to others is not a duty, it is a joy, for it increases our own
> health and happiness."
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 2.0 as default on main repos?

2016-08-08 Thread Matt Bruzek

Hi Steve,

If you have not installed any of the older packages the commands are
simple:

sudo add-apt-repository ppa:juju/develsudo apt updatesudo apt install juju

As always, please refer to the documentation when it comes to installation
instructions: https://jujucharms.com/docs/stable/getting-started-general

I found the process a little bit more difficult because I have installed
every release of the 2.0 beta and it caused problems. I had to purge all
the other juju packages before the above commands worked for me.

We are interested in your experience with Juju. Please email me or the list
if you have any further questions. We also communicate in IRC #juju in
chat.freenode.net.


   - Matt Bruzek <matthew.bru...@canonical.com>

On Mon, Aug 8, 2016 at 12:32 PM, Steve Pe <steve...@gmail.com> wrote:

> I'm newbi what is command to install latest beta version of Juju on
> ubuntu?  thx
>
> On Mon, Aug 8, 2016 at 12:23 PM, Rick Harding <rick.hard...@canonical.com>
> wrote:
>
>> Thanks for the feedback Jose. Merlijn also brought up a similar note and
>> I replied on the main juju list to help explain the current pain window
>> we're working through. Rather than copy/paste you can see it here:
>>
>> https://lists.ubuntu.com/archives/juju/2016-August/007679.html
>>
>> Please let me know if you'd like to chat. I understand that it feels very
>> awkward right now, but it's part 'by the plan' as far as the plan went, but
>> also 'not by the plan' as we'd hoped to have Juju 2.0 GA for folks at this
>> time. We're very close now and the feedback from users of 2.0 has been
>> essential to getting so much right and better for everyone.
>>
>> Jose, let me know if you want to reach out and chat about the transition
>> and why things are setup they way they are. We really appreciate the
>> feedback and patience as we go through the 1.X to 2.X transition.
>>
>> Rick
>>
>> On Mon, Aug 8, 2016 at 11:32 AM José Antonio Rey <j...@ubuntu.com> wrote:
>>
>>> Hey Matt,
>>>
>>> Thanks for the link.
>>>
>>> If anyone reading has a way to help get it fixed, please do so. This is
>>> a horrible bug that causes inconsistencies, and until 2.0 is released it
>>> should not be in main.
>>>
>>> On Mon, Aug 8, 2016, 09:22 Matt Bruzek <matthew.bru...@canonical.com>
>>> wrote:
>>>
>>>> Hello José,
>>>>
>>>> I ran into this problem myself and filed a bug with the packaging.
>>>>
>>>> https://bugs.launchpad.net/juju-release-tools/+bug/1609437
>>>>
>>>> While I still think this is a bug, I did find a work around which I put
>>>> in the bug for other people having this same problem. Hope that helps!
>>>>
>>>>- Matt Bruzek <matthew.bru...@canonical.com>
>>>>
>>>> On Wed, Aug 3, 2016 at 7:49 PM, José Antonio Rey <j...@ubuntu.com>
>>>> wrote:
>>>>
>>>>> Hello everyone,
>>>>>
>>>>> I am deploying some production servers and am seeing a weird behavior:
>>>>>
>>>>> 2.0~beta12-0ubuntu1.16.04.1 is the default for the 'main' repositories
>>>>> of archive.ubuntu.com
>>>>>
>>>>> 1.25.6-0ubuntu1~16.04.1~juju1 is the default for ppa:juju/stable
>>>>>
>>>>> Is this intended? Doesn't feel right to me.
>>>>>
>>>>> Thanks in advance for the insight!
>>>>>
>>>>> --
>>>>> 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/mailm
>>> an/listinfo/juju
>>>
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
>
> --
> Best wishes;
>
> Steve Pe
> ( https://www.linkedin.com/in/stevepe )
>
> "Doing good to others is not a duty, it is a joy, for it increases our own
> health and happiness."
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: 2.0 as default on main repos?

2016-08-08 Thread Matt Bruzek

Hello José,

I ran into this problem myself and filed a bug with the packaging.

https://bugs.launchpad.net/juju-release-tools/+bug/1609437

While I still think this is a bug, I did find a work around which I put in
the bug for other people having this same problem. Hope that helps!

   - Matt Bruzek <matthew.bru...@canonical.com>

On Wed, Aug 3, 2016 at 7:49 PM, José Antonio Rey <j...@ubuntu.com> wrote:

> Hello everyone,
>
> I am deploying some production servers and am seeing a weird behavior:
>
> 2.0~beta12-0ubuntu1.16.04.1 is the default for the 'main' repositories of
> archive.ubuntu.com
>
> 1.25.6-0ubuntu1~16.04.1~juju1 is the default for ppa:juju/stable
>
> Is this intended? Doesn't feel right to me.
>
> Thanks in advance for the insight!
>
> --
> 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: 2.0 as default on main repos?

2016-08-08 Thread Matt Bruzek

Hello José,

I ran into this problem myself and filed a bug with the packaging.

https://bugs.launchpad.net/juju-release-tools/+bug/1609437

While I still think this is a bug, I did find a work around which I put in
the bug for other people having this same problem. Hope that helps!

   - Matt Bruzek <matthew.bru...@canonical.com>

On Wed, Aug 3, 2016 at 7:49 PM, José Antonio Rey <j...@ubuntu.com> wrote:

> Hello everyone,
>
> I am deploying some production servers and am seeing a weird behavior:
>
> 2.0~beta12-0ubuntu1.16.04.1 is the default for the 'main' repositories of
> archive.ubuntu.com
>
> 1.25.6-0ubuntu1~16.04.1~juju1 is the default for ppa:juju/stable
>
> Is this intended? Doesn't feel right to me.
>
> Thanks in advance for the insight!
>
> --
> 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] collectd, and prometheus

2016-08-03 Thread Matt Bruzek

I reviewed the collectd and prometheus charms today. The reactive code is
very well written and both charms deployed correctly.

The charms still had the basic auto-generated tests, and the readme files
were VERY minimal. Both charms would fail the lint step on bundletester
(our automated testing tool), so I sent the review findings to the authors
and expect they will be easy fixes for the authors.

Very well written charm code, if you are looking for an example of some
great reactive code look no further than:
https://jujucharms.com/u/prometheus-charmers/collectd
https://jujucharms.com/u/prometheus-charmers/prometheus

That is all,

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Incoming Breaking Changes at the Series Boundary for ETCD

2016-08-02 Thread Matt Bruzek

Chuck,

I am plus one for introducing the new etcd charm in the Xenial series (on
release boundary). There have been enough features added and things changed
that both versions have diverged quite a bit. I am excited to get the new
etcd charm into other people's hands so publish it soon.

   - Matt Bruzek <matthew.bru...@canonical.com>

On Tue, Aug 2, 2016 at 11:07 AM, Charles Butler <
charles.but...@canonical.com> wrote:

> Greetings,
>
> *TL;DR *- There will be no upgrade path due to incompatible changes from
> cs:trusty/etcd to cs:xenial/etcd. Please be prepared for re-deployment if
> an upgrade is required.
>
> As some of you may know, we have been toiling quite hard on the Etcd charm
> this last month, adding TLS encryption for an "SSL Everywhere" experience.
> Read: End to End encryption on our Kubernetes bundle.
>
> This brought with it a lot of upgrade concerns, and we have not yet landed
> the changes in the stable channel. This was by design so we could evaluate
> the potential impact on existing clusters of Etcd deployed with Juju. It's
> become quite apparent to us that there is a very convoluted upgrade path.
> And this upgrade path is a one-time scenario, that will require an
> engineering effort that doesn't cover its use.
>
> With that being said, we're now settled on breaking compatibility on the
> series boundary of Xenial forward. Meaning when you deploy etcd from Xenial
> onward, TLS will be enabled by default, and we are dropping trusty as a
> supported series moving forward.
>
> This leaves users of the older etcd charm(s) in a very well understood
> behavior, and they will not be prompted for an update that would
> potentially break their existing deployments.
>
> We wanted the community to be well aware of the plan moving forward so
> there are no surprises, and will continue to strive towards a stellar user
> experience.
>
> If you have any questions, comments or concerns, please feel free to reply
> to this thread and continue the conversation.
>
> All the best,
>
>  Charles
> --
> 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
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Regarding the cs:trusty/docker charm

2016-07-29 Thread Matt Bruzek

As part of the unmaintained charm process
<https://jujucharms.com/docs/1.24/charm-unmaintained-process> the
containers team would like to deprecate the old Ansible based docker charm
in favor of the new layer-docker which we can either build into a catch all
docker charm, or other developers can use to build with their own container
and make a specific charm for their container.

We want to notify the community because the older docker charm is not
compatible with the new layer-docker and that could affect people using the
older charm.

The unmaintained process gives us one month to discuss request. If you are
opposed, or concerned about this change please reply to this email so we
can sort out the issues.

The bug can be found here:
https://bugs.launchpad.net/charms/+source/docker/+bug/1607831

We plan to replace it with a charm build from layer-docker which the source
can be found here: https://github.com/juju-solutions/layer-docker/

Please email me if you have any concerns.

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Wordpress charm PHP 7

2016-07-29 Thread Matt Bruzek

Luigi,

You have to join the email list before you can send to it. You can join
here:  https://lists.ubuntu.com/mailman/listinfo/juju

We don't have any books (yet) but we do have many youtube videos of some of
our charm schools and other training material that you can watch at your
convenience. Search for "Juju charm school" or "Juju office hours".
http://youtube.com/jujucharms

We currently do not have an nginx charm that acts as a reverseproxy
relation at this time. We do have haproxy with reverseproxy and a varnish
charm that works as a reverseproxy. The wordpress charm can be configured
to install nginx or apache as the web host.

I took the liberty to put a quick bundle together that is set up as you
have indicated with haproxy, wordpress, memcached, mariadb set up with
master and slave replication. I put redis in there, but those charms don't
currently have a redis relation (which we could add).

Deploy this bundle in your favorite cloud and let me know how it works for
your situation. Remember all these charms are open source operations so if
they don't do things exactly as you wish, you can edit and improve them as
you see fit.

Thanks,

   - Matt Bruzek <matthew.bru...@canonical.com>

On Fri, Jul 29, 2016 at 9:39 AM, Luigi Nica <lu...@nica.pro> wrote:

> Hi Matt,
>
> Thank you for your answers (I’m resending the email because juju list
> rejected the email).
>
> Ideally, I would take a one day training so I learn how to do things by
> myself. Where I can see the curriculum? There is a website?
>
> Also, I tried to find a book on this subject but without any luck.
>
> If we substitute nginx with haproxy we loose the caching feature of nginx
> so we will have to introduce Varnish, who have issues with woocommerce and
> need some advanced configs. But I know that it’s doable.
>
> Another solution will be implementing Litespeed, who can remove the need
> for nginx, varnish and apache.
>
> Thank you!
>
> Regards,
> Luigi
>
>
> On Fri, Jul 29, 2016 at 10:06 AM, Matt Bruzek <
> matthew.bru...@canonical.com> wrote:
>
>> Hello Luigi,
>>
>> Thanks for the email! I am happy to help with this project. My responses
>> are in-line.
>>
>>
>> On Thu, Jul 28, 2016 at 10:30 PM, M Bruzek <mbru...@gmail.com> wrote:
>>
>>> -- Forwarded message --
>>> From: "Luigi Nica" <lu...@nica.pro>
>>> Date: Jul 27, 2016 10:53 PM
>>> Subject: Wordpress charm PHP 7
>>> To: <mbru...@gmail.com>
>>> Cc:
>>>
>>> Hi Matt,
>>>
>>> Thank you for creating this Wordpress charm (
>>> https://code.launchpad.net/~charmers/charms/trusty/wordpress/trunk)
>>>
>>> 
>> I help curate the wordpress charm but I can not take credit for creating
>> it, that was Marco Ceppi.
>> 
>>
>>
>>> I am very new to orchestration but I’m learning…
>>>
>>> 
>> This is great news! I would be happy to show you how to model solutions
>> with Juju charms.
>> 
>>
>>
>>> Do you think you can adapt this charm to PHP7?
>>>
>>>
>> Yes, this is an open source project, and anyone can contribute.
>> 
>>
>>
>>> Also, do you think you can do a bundle for Woocommerce that can be
>>> deployed on Digital Ocean?
>>>
>>
>> We do not have an official DigitalOcean provider but I happen to know
>> this can be done with the manual provider
>> <https://jujucharms.com/docs/stable/clouds-manual> support in Juju. I
>> run a blog on DigitalOcean using Juju and the ghost charm.
>> 
>>
>>
>>> • Nginx as reverse proxy, Apache 2.4 load balanced, Php 7, Redis,
>>> Memcached, Mariadb master/slave
>>>
>>>
>> We have most of these applications already charmed up for you. I would
>> substitute haproxy for nginx and your contribution to the wordpress charm
>> would upgrade to Php 7.
>>
>> It’s not for a big project, just that I love speed and as I’m not a sys
>>> admin. Having a bundle like this, I could implement it with Digital Ocean
>>> and  have a load time under 400ms with this setup.
>>>
>>> If you can not contribute this, I’m ready to try to contribute with some
>>> money for your time.
>>>
>>
>> I am fully booked at the moment but I am happy to help you create a
>> bundle for this solution. We host charm schools which is one on one
>> training, we have staff on IRC in #juju on chat.freenode.net, and have a
>> mailing list (which I have carbon copied). We hold office hours where
>> users can bring up topics that they want to learn more about.
>>
>> Hopefully someone on this list might be interested in helping Woocommerce
>> model their solution.
>>
>> Which method would work best for you?
>>
>>
>>> Thank you! Please let me know.
>>>
>>> Regards,
>>> Luigi
>>> ᐧ
>>>
>> 
>>
>
> ᐧ
>


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

Re: Wordpress charm PHP 7

2016-07-29 Thread Matt Bruzek

Hello Luigi,

Thanks for the email! I am happy to help with this project. My responses
are in-line.

On Thu, Jul 28, 2016 at 10:30 PM, M Bruzek  wrote:

> -- Forwarded message --
> From: "Luigi Nica" 
> Date: Jul 27, 2016 10:53 PM
> Subject: Wordpress charm PHP 7
> To: 
> Cc:
>
> Hi Matt,
>
> Thank you for creating this Wordpress charm (
> https://code.launchpad.net/~charmers/charms/trusty/wordpress/trunk)
>
> 
I help curate the wordpress charm but I can not take credit for creating
it, that was Marco Ceppi.

> I am very new to orchestration but I’m learning…
>
> 
This is great news! I would be happy to show you how to model solutions
with Juju charms.

> Do you think you can adapt this charm to PHP7?
>
>
Yes, this is an open source project, and anyone can contribute.

> Also, do you think you can do a bundle for Woocommerce that can be
> deployed on Digital Ocean?
>

We do not have an official DigitalOcean provider but I happen to know this
can be done with the manual provider
 support in Juju. I run a
blog on DigitalOcean using Juju and the ghost charm.

> • Nginx as reverse proxy, Apache 2.4 load balanced, Php 7, Redis,
> Memcached, Mariadb master/slave
>
>
We have most of these applications already charmed up for you. I would
substitute haproxy for nginx and your contribution to the wordpress charm
would upgrade to Php 7.

It’s not for a big project, just that I love speed and as I’m not a sys
> admin. Having a bundle like this, I could implement it with Digital Ocean
> and  have a load time under 400ms with this setup.
>
> If you can not contribute this, I’m ready to try to contribute with some
> money for your time.
>

I am fully booked at the moment but I am happy to help you create a bundle
for this solution. We host charm schools which is one on one training, we
have staff on IRC in #juju on chat.freenode.net, and have a mailing list
(which I have carbon copied). We hold office hours where users can bring
up topics that they want to learn more about.

Hopefully someone on this list might be interested in helping Woocommerce
model their solution.

Which method would work best for you?

> Thank you! Please let me know.
>
> Regards,
> Luigi
> ᐧ
>

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

[Review Queue] ibm-mq and ibm-pac designs

2016-07-13 Thread Matt Bruzek

Hello,

Kevin and I spent some time reviewing the design documents for IBM MQ and
the IBM Platform Application Center (PAC).

ibm-mq:
https://docs.google.com/document/d/1C2Rlo1hwTcHljO1NacsQKfcBMki7wKI9WgAPUuv0Yy0/edit

ibm-pac:
https://docs.google.com/document/d/1JJRJM-UDZHsC1gGaU1j17oCWdg8ywYbzh_ILEoYNAlY/edit

Both designs needed more information before proceeding. We plan to review
them when they have been updated.

Thanks!

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Automatic hook retries in Juju 2.0

2016-07-07 Thread Matt Bruzek

This should really be added to the docs about the automatic retry and how
to shut it off.

I created an issue and linked it to this discussion.
https://github.com/juju/docs/issues/1235

Can someone from core or more familiar with the feature document it for the
rest of us?

   - Matt Bruzek <matthew.bru...@canonical.com>

On Thu, Jun 30, 2016 at 12:29 PM, Matt Rae <matt@canonical.com> wrote:

> Hi Adam, I've also found that debugging environments was difficult with
> hook retrying on. I've disabled it like this:
>
> juju set-model-config automatically-retry-hooks=false
>
> On Thu, Jun 30, 2016 at 11:05 AM, Adam Collard <adam.coll...@canonical.com
> > wrote:
>
>> Did we get a way of disabling this 'feature'? As I remember from the
>> initial ML post, there was a repeated request to be able to disable this
>> for certain environments (e.g. dev/test of charms).
>>
>> Many charms have race conditions in their hook execution which aren't
>> seen through regular use of the Juju CLI client, but other Juju API drivers
>> (e.g. Autopilot) expose.
>>
>> Although automatic hook retries may well negate transient network issues,
>> they risk hiding these kinds of bugs. As a charm author I want Juju to help
>> me find these bugs, so have it fail when I mess up. Papering over them
>> gives me a false sense of security.
>>
>>
>> On Thu, 30 Jun 2016 at 17:27 Bogdan Teleaga <
>> btele...@cloudbasesolutions.com> wrote:
>>
>>> Hey Casey,
>>>
>>> They are all retried using the same policy.
>>>
>>> The constants that control the delay are here:
>>>
>>> https://github.com/juju/juju/blob/master/apiserver/retrystrategy/retrystrategy.go#L21
>>>
>>> Basically it's an exponential backoff with a factor of 2 that starts at
>>> 5 seconds and has a maximum of 5 minutes, so 5, 10, 20...up to 300 seconds.
>>>
>>> Iirc attempting a manual retry will reset this timer. It also never
>>> gives up.
>>>
>>> Cheers,
>>> Bogdan
>>> On Jun 30, 2016, at 6:52 PM, Casey Marshall <
>>> casey.marsh...@canonical.com> wrote:
>>>>
>>>> What is the intended behavior for automatic hook retries in Juju 2.0?
>>>>
>>>> Specifically, I'd like to know, as a Juju user:
>>>>
>>>> Are errors in hooks all retried with the same policy, or are some
>>>> retried with a different policy / strategy than others (install, for
>>>> example)?
>>>>
>>>> Is there a limit to the number of times Juju will retry a hook error
>>>> before "giving up"?
>>>>
>>>> What kind of delay can I expect between retries?
>>>>
>>>> Thanks,
>>>> Casey
>>>>
>>> --
>>> 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
>>
>>
>
> --
> 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

[Review Queue] ibm-spectrum-scale and ibm-ucd

2016-06-10 Thread Matt Bruzek

Kevin and I spent some time reviewing design documents for IBM Spectrum
Scale (formerly gpfs), and UrbanCode Deploy (UCD).

The IBM Spectrum Scale design felt like a bundle already because it had a
client to manager relationship. We had some comments about using terms and
resources but feel this design was ready to move to the implementation
phase.

https://docs.google.com/document/d/15VPxSNZWnEZTDbxdpne5IHiDpyVhK29d3kQ5uZ5oPaA/edit?usp=sharing

The IBM UrbanCode Deploy seems like an interesting product. This charm had
some relation to other charms but it was light on details and we are
interested to find out more about the ibm-ucd charm.

https://docs.google.com/document/d/1KKkLZnxZrG6E_N8tV8AcLozYRNF9X6Fy9LmSCUyejtU/edit?usp=sharing

Thanks,

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Reviewed designs ibm-was-nd, ibm-xcat, ibm-was-wxs, ibm-dsm and ibm-pac

2016-05-04 Thread Matt Bruzek

Kevin Monroe and I reviewed several charm designs, and one bundle design
from our parters at IBM.

All these designs use the reactive framework and are well thought out. Most
got our +1 but we had a few questions about ibm-pac that was unclear.

Here is the summary:

was-nd
- approved last week, but thanks for the new diagram
-
https://docs.google.com/document/d/17Uh_EghiBKZiDf8ZiM6T-VQzVfoTj4gOlwTl9oieBwc/comment

xcat
- replies to previous comments seem sound
-
https://docs.google.com/document/d/1DgK79jsP2mnxfu_5uHWDSgMriy1VN3kYUK2On2OCSU8/comment

was-wxs
- a few comments, but nothing blocking.  please let us know if you have
questions about our comments
-
https://docs.google.com/document/d/1Zc396dKOHQU-PI1MvVT02q966FAs_H5f2X2L1ERcXBI/comment

web infrastructure bundle
- minor comments to keep in mind when implementing this bundle, but this
looks *really* interesting and is well thought-out.  nice job!
-
https://docs.google.com/document/d/1WWo8PSAjRrb0D4swdX2mghPgEbgT5LA2vD9wHsv8Qlc/comment

ibm-dsm:
- minor comments, overall +1
-
https://docs.google.com/document/d/1qQY5gJNDVTDPECWDmLzkNWWwGHukWHHucRQIosuL1RU/comment

ibm-pac:
- We had a few questions about co-location of charms on this design. While
you can use --to   we generally use a subordinate for proper co-location.
We will wait to hear back from the partners if the can use a subordinate
charm.
https://docs.google.com/document/d/1E46oFIUr0h_MpCLiGTnp2vD-UrKdLCuNP3T3hD4etqo/comment

Thanks,

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ibm-was-base, ibm-http-server

2016-04-20 Thread Matt Bruzek

Kevin and I spent some time reviewing the design documents for the IBM
layers ibm-was-base and ibm-http-server today.

https://docs.google.com/document/d/1O7J_SLDdCD-D7J8xG7k_9hAGTo8j7BcfCXbA3iTtkR8/edit

https://docs.google.com/document/d/1PQjZofa9aK4s9m2yKcvMkqsLT_esgZ2iJVf-DnVdNEU/edit

These are great examples of a layer design. They are well written and use
the reactive framework correctly. We look forward to seeing the charms
built from these layers soon.

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Query on IBM-Base- Layer

2016-03-29 Thread Matt Bruzek

Hello Shruthima,

There may not be enough information in this email to diagnose this problem,
but I will take a shot.

The layer-ibm-base requires juju 2.0 to run. See the metadata.yaml file in
that layer, and in your built ibm-im-new charm.

Please install juju 2.0 on your system:
https://jujucharms.com/docs/*devel*/getting-started
Note that juju 2.0 introduces some new commands and some names have
changed. They are listed in the "*devel*" documents.

Also we found a bug against charm-tools package that will not run properly
if the layer directory does not have a .bzr or .git directory. I don't see
ibm-im-new in https://code.launchpad.net/~ibmcharmers  You should
initialize the repository (bzr init) to make sure it has at minimum a .bzr
directory until we get the fix for charm-tools released.

Good luck!

   - Matt Bruzek <matthew.bru...@canonical.com>

On Tue, Mar 29, 2016 at 8:35 AM, Shruthima Almavar <salma...@in.ibm.com>
wrote:

> Hello Team,
>
> I am working on IBM-Installation Manager with including IBM-Base-Layer(
> https://code.launchpad.net/~ibmcharmers/layer-ibm-base/trunk) as a layer
> , i have included this layer in layer.yaml and charm build is successfully
>  worked.
>   includes: ['layer:ibm-base']
> But , when we tried to deploy we are getting the following  error.
> ...
> WARNING failed to load charm at "/home/charm/charms/trusty/ibm-im-new":
> metadata: series: expected string, got []interface {}([]interface
> {}{"trusty", "xenial"})
> ERROR charm not found in "/home/charm/charms/": local:trusty/ibm-im-new
> ..
>
> Could you please suggest us what can be the solution...!!!
> Thank you.
>
>
> Regards,
> Shruthima
>
> --
> 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: FW: Question - Creating first Charm

2016-03-07 Thread Matt Bruzek

Gilbert,

How do I get auth to post to the mailing list?

To post a message to all the list members, send email to
j...@lists.ubuntu.com.you may need to be a member so sign up here:
https://lists.ubuntu.com/mailman/listinfo/juju and other Ubuntu lists are
at https://lists.ubuntu.com/

Regarding the db2 charm:
Our partners at IBM are working on an update to the IBM DB2 charm at the
moment. So we will see that one improve soon.

Thank you for the feedback. I would like to know if there are specific ways
to better describe the charming development process.


   - Matt Bruzek <matthew.bru...@canonical.com>

On Sat, Mar 5, 2016 at 10:32 AM, Gilbert Standen <gilstan...@hotmail.com>
wrote:

> How do I get auth to post to the mailing list?
>
> Subject: RE: Question - Creating first Charm
> From: juju-ow...@lists.ubuntu.com
> To: gilstan...@hotmail.com
> Date: Sat, 5 Mar 2016 16:31:19 +
>
> You are not allowed to post to this mailing list, and your message has
> been automatically rejected.  If you think that your messages are
> being rejected in error, contact the mailing list owner at
> juju-ow...@lists.ubuntu.com.
>
>
>
> --Forwarded Message Attachment--
> From: gilstan...@hotmail.com
> To: j...@lists.ubuntu.com
> Subject: RE: Question - Creating first Charm
> Date: Sat, 5 Mar 2016 10:31:11 -0600
>
> Matt, thanks!  I very much appreciate all the help I can get.
>
> imho the best way to do these proprietary products which have free
> licenses is going to be to launch a webpage as part of the charm deployment
> at which point the user (a) accepts the license agreement and (b) downloads
> the install media.  This is the way oracle-xe will work, and the way that
> ibm-db2 will work, and in fact, the way that any advanced oracle product
> deployments such as oracle enterprise edition products (which can also be
> downloaded free of charge but require accepting export restrictions at a
> webpage).
>
> How do I create a charm which calls a product webpage such as
> oracle.com/downloads/productname and waits for the user to accept the
> export restrictions/license terms, and then downloads the software to the
> openstack deployment location (bare metal or lxc container) ?
>
> The frustration level trying to get a foothold on getting started with
> charming is quite high, from my perspective.  I can't find documentation
> that "feels" meaningful to me.  When I go to use existing charms as
> reverse-engineering guides, that is a pretty high wall too - mysql is way
> beyond me because it's just not realistic for me to learn python as part of
> this - that would be an incredibly long-term undertaking and honestly if I
> was thinking of something that long-term investment, I'd rather spend a
> couple years learning to play the violin (one of my goals).  I need to do
> this stuff in bash or work with a partner who knows python.  That's why I
> was looking at the couchdb charm because it's in bash and looks like a
> realistic entry point.
>
> I do think just from my perspective as someone who really loves and values
> the Ubuntu ecosystem and OS, for a consistent comprehensive capability to
> deploy proprietary db products on Ubuntu such as IBM DB2, Oracle, etc. and
> this is the contribution I would like to try and make.  The IBM DB2 charm
> in the charm store looks to me to be very underused, very out-of-date, and
> byzantine to deploy, and built around an old version (IBM DB2 10.5).  I
> thought the DB2 charm might have been a good template  because it requires
> a "webpage type license exports restrictions acceptance" but even doing a
> "charm get db2" has proven impossible to even examine how that charm is
> built.
>
> I'm afraid there's a very daunting road ahead to get anywhere with this
> for me, but I do want to get oracle onto ubuntu products.  As you know, I
> wrote https://github.com/gstanden/orabuntu-lxc which is kind of loosely
> speaking an LXC replacement for products like VirtualBox and VMWare Player
> for running Oracle Enterprise Edition products on Ubuntu kernels natively
> with no hypervisor, but the charm initiative for me is to move from a
> desktop experience to POC that Oracle Enterprise products can actually be
> run natively on Ubuntu kernels in LXC containers on actual production-ready
> Openstack deployments.  I get incredulous sceptical remarks from people
> about the idea of running Oracle Enterprise production workloads natively
> on Ubuntu kernels using LXC containers, but I see no real obstacles to
> this, and I have a philosophy of building a capability regardless of what
> the viewpoint is on use cases if that capability does not currently exist.
> I know you support these ideas too because you have been very very
> support

Re: Question - Creating first Charm

2016-03-04 Thread Matt Bruzek

Hello Gilbert,

Thanks for the email. I have added the Juju list so others can chime too.

Because Oracle-XE 11gR2 version requires accepting a license agreement to
> download from Oracle.com...
>
We are going to introduce a new concept in Juju 2.0 called "terms" where
you can run an "accept" command for software with proprietary software.
You would put "terms" key in your metadata.yaml. Check the release notes
for some tips on this feature:
https://jujucharms.com/docs/devel/temp-release-notes

Alternately you could make a configuration option where the user could
accept the license on the Oracle page, and put the key in a configuration
option, where the charm would not install if the key is empty or invalid.

So my install hook is taking shape kinda like this (and works): ...
>
I would really encourage you to look at our new Developer documents (
https://jujucharms.com/docs/devel/developer-getting-started ) that
introduce charm layers and a reactive framework. From my experience it is
much more "natural" to write charms this way where you can define states
and react to them. As an example you could define: 'oracle.downloaded',
'oracle.configured', and 'oracle.available' and the code could react to
different states.

My question is, what is the best way to automate this last step for charm
> deployment?

Non interactive install scripts are the bane of my existence! I have a
number of techniques to work around these, such as piping the "yes" command
to a script, or redirecting strings into the interactive bits. The best
approach is on a case to case basis, but you may have to re-write this
script. I

...to just use the default values and to use some hardcoded default
> password.
>
Hard coded passwords are never the right way to go and against Charm Store
policy ( https://jujucharms.com/docs/devel/authors-charm-policy ).  Either
randomly generate a password that the user can retrieve or have that set as
a configuration option but remember all configuration options must be able
to change at any time (mutability). I have used some template technologies
to put charm configuration options in places where the script would prompt
users.

So I'm thinking one obvious way would be to just have some sed and awk
> steps to just change the oracle-xe script to just non-interactively use the
> default ports

Make the ports configurable, so that you can deploy the service and know
the port where it is being served. The user could change it if they know
that port is being used.

Database charms are the most complex for *me* to understand, but I
encourage you to look at the "mysql" charm for tips on database. It was
written by one of our best charmers who knows how to install databases. You
will find many answers to your questions in that charm.

If you have any further questions please share them with
juju@lists.ubuntu.com so the whole community has the benefit of the
information, and other database charmers can pipe in.

   - Matt Bruzek <matthew.bru...@canonical.com>

On Fri, Mar 4, 2016 at 1:36 PM, Gilbert Standen <gilstan...@hotmail.com>
wrote:

> Hey I'm sorry to bug you with another question but I'm trying to find my
> way along to get through creating my first charm.
>
> Because Oracle-XE 11gR2 version requires accepting a license agreement to
> download from Oracle.com (adding a level of complexity to creating my first
> charm) I stepped back even further to Oracle-XE 10gR2 which actually is
> still available from a DEB repository.   I realize 10gR2 is pretty old but
> for purposes of learning how to charm, it's great, because it's available
> from a ppa still and it's pretty easy to deploy from a manual steps
> perspective, so it should be a good "first charm" exercise for me.
>
> So my install hook is taking shape kinda like this (and works):
>
> # GLS start
> echo 'deb http://oss.oracle.com/debian/ unstable main non-free' | sudo
> tee --append /etc/apt/sources.list
> echo 'deb-src http://oss.oracle.com/debian/ unstable main' | sudo tee
> --append /etc/apt/sources.list
> wget http://oss.oracle.com/el4/RPM-GPG-KEY-oracle  -O- | sudo apt-key add
> -
> apt-get update
> apt-get install -y  oracle-xe --force-yes
> # GLS end
>
> all of the above works great.  However, oracle-xe has a configuration
> script that has to be run at this point (as many db's do) which sets some
> ports and the admin password.  That script comes with it and is
> '/etc/init.d/oracle-xe" and it is run interactively (typically) as shown
> below:
>
> /etc/init.d/oracle-xe configure
>
> which goes like this (interactively):
>
> --- snip start
>
> root@W520:/etc/init.d# ./oracle-xe configure
>
> Oracle Database 10g Express Edition Configuration
>

Re: What to do with precise charms?

2016-02-19 Thread Matt Bruzek

Hello Jose,

Thanks for bringing this topic up! You make a good point there are going to
be three supported LTS releases available to Juju. I do not think we will
ask any maintainer to support all three releases. Currently each charm
lives in its own release and I would expect the precise charm contains an
older version of a service. It does not make sense to me that someone would
try to port the latest version of a service to the precise (12.04) charm.
If a charm happens to work on multiple releases we are talking about adding
support for that in Juju 2.0.

Our current unmaintained process addresses when an author is not responding
or maintaining the charms. We should come up with a process for "active"
charm developers to deprecate their precise charms. If a charm
developer/maintainer wants to deprecate a charm, I have seen someone
authors replace the entire readme and metadata with a deprecation warning
pointing to the latest version of the charm and get that through the review
process.

Although I don't expect we will have to do this very frequently, we locked
charms to releases so charms would continue to work with the packages that
were available in that release of the operating system. I hope that precise
charms continue to work in precise, and if that is not the case create a
bug and the author can fix the failure or put a depreciated message in the
metadata and readme.

Did I address the question you were talking about? If not please give us
more details.

Thanks!

   - Matt Bruzek <matthew.bru...@canonical.com>

On Fri, Feb 19, 2016 at 2:47 PM, José Antonio Rey <j...@ubuntu.com> wrote:

> Hello,
>
> In approximately two months, Xenial is going to be released. Once that
> happens, we are going to have three supported LTS releases: precise, trusty
> and xenial.
>
> I know that there is some people that have both precise and trusty charms.
> However, if they want to move their charms to xenial, they are going to
> have to maintain not two, but three charms. And if we want to have the
> latest in all charms, then features and software versions would have to be
> backported all the way to precise, which may complicate things a bit more.
>
> I'm wondering, would it be suitable for us to establish a process where a
> charm author decides to no longer maintain a charm in an old but supported
> release and just move that specific series charm to ~unmaintained-charms? I
> think it's better to start thinking on this now, before it gets too close
> to release time.
>
> Happy to hear all your comments/suggestions on this.
>
> --
> José Antonio Rey
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] lis-test-charm, etcd

2016-02-17 Thread Matt Bruzek

I reviewed the HyperV lis-test-charm today that had a few boilerplate files
left inside the charm that should be removed before it passes review:
https://bugs.launchpad.net/charms/+bug/1513612


I also reviewed a change to the etcd charm. I pushed this charm to the
charm store using the new charm2 command:

https://code.launchpad.net/~lazypower/charms/trusty/etcd/bump-to-six/+merge/286412

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: @when('config.changed')

2016-02-17 Thread Matt Bruzek

I hate to go against the love-in here. While I desperately want a
configuration changed feature for the reactive framework. I disagree with
the way it was implemented. I brought up issues with this implementation in
the pull request:  https://github.com/juju-solutions/layer-basic/pull/36

It feels wrong to lump configuration change events in to states. There
should be a different way to handle these types of events that are
generated by Juju. We already have @hook('config-changed') for when the
traditional hook would be called. When a configuration changes it would be
more natural should have a different decorator for that such as:
@when_changed('key') or more importantly
@when_any_changed('key1','key2','key3')

Charm states are completely arbitrary and an author (who may not read this
list) could legitimately set a 'config.changed' state that would create
invalid changed events and break other layers. Even if we pick a different
state name it seems we are inviting a possible collision that would be very
difficult to diagnose and debug.

It feels strange that we are "reserving" a state name (or many names) for
the configuration changes in this way. Implementing the feature with a
different decorator seems more deterministic and not overloading the states
with configuration events.

Thoughts?

   - Matt Bruzek <matthew.bru...@canonical.com>

On Wed, Feb 17, 2016 at 4:00 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Great! Very usefull! Thanks, Cory!
>
>
> Op woensdag 17 februari 2016 heeft Cory Johns <cory.jo...@canonical.com>
> het volgende geschreven:
> > Just wanted to give a heads-up about a feature that landed in the
> reactive base layer yesterday.
> > If a charm config option has changed, the state "config.changed" will be
> set for the duration of the hook.  Additionally, specific states will be
> set for each config option that changed; that is, if option "foo" has
> changed, the state "config.changed.foo" will be set.  An example of code
> using this would be:
> > @when('myservice.started', 'config.changed')
> > def update_config():
> > update_config_files()
> > restart_myservice()
> > This provides a much cleaner way of detecting changes to config, and it
> is recommended that this be used in favor of @hook('config-changed') going
> forward, as the latter can actually run in to some situations, albeit
> rather rarely, where the charm sees new config option values before the
> config-changed hook has fired.  Using the reactive states avoids that
> completely as well as working more naturally with existing @when decorators.
> > Please note that, while we are not aware of any charms currently using
> "config.changed" as a state, there is some risk of the state set by the
> base layer conflicting with it if set by the charm layer.  The
> recommendation is to always prefix your states by the name of the layer
> setting them,  or the relation name for interface layers.
>
> --
> 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: Query on IBM-Installtion Manger Charm Layer

2016-02-05 Thread Matt Bruzek

Hello Shurthima,

Thanks for reaching out to the Juju list. The layered approach is the way
to write all new charms. We do recommend that you use the basic layer when
creating a new base level feature such as IBM Installation Manager. To do
that the layer.yaml should look like this:

includes: ['layer:basic']

As far as interface, I would have to know more about what services IBM IM
can use or interact with. If IBM IM can talk to a database it should have a
database relation. If the product has an web interface it should implement
the http interface. You as the author knows the product better than I
would. Interface layers make it very easy to use juju interfaces.

We have some documentation about how to write layered charms, for more
information please read:

https://jujucharms.com/docs/devel/developer-getting-started

Please email the list if you have any more specific questions.  Thanks!

   - Matt Bruzek <matthew.bru...@canonical.com>

On Tue, Feb 2, 2016 at 12:34 PM, Shruthima Almavar <salma...@in.ibm.com>
wrote:

> Hello Team,
>
> I am working on IBM-Installation Manager charm and I will be developing
> this charm from layers .
>  i have explored on layers and thought to use basic layer which is present
> in "http://interface.juju.com; but not sure about it ??
>  Could you please suggest me  which layer and interface i can use for
> charming IBM-IM product. Thanks.
>
>
> Regards,
> Shruthima
>
>
>
>
> --
> 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] ibm-was-base

2016-01-13 Thread Matt Bruzek

I reviewed the ibm-was-base charm today. The charm has made some
significant improvement in the code quality, and now uses a sftp transfer
protocol.

This brings up an interesting topic.  Does the use of sftp eliminate the
need to check the sha1sum for downloaded packages.

The charm had some other blocking issues that you can read about in the bug:

https://bugs.launchpad.net/charms/+bug/1446966

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ibm-platform-symphony

2015-11-25 Thread Matt Bruzek

I took some time to review the ibm-platform-symphony charm today.  This
charm requires the IBM software to be downloaded (all 4.8 GB of it!) and
manually hosted on an HTTP server before the deploy will succeed.  This
charm did not pass my review and you can read more about the specifics here:

https://bugs.launchpad.net/charms/+bug/1459213

Thanks,

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] postgresql

2015-11-11 Thread Matt Bruzek

I reviewed the rewrite of the postgresql charm today.  It is finally
passing tests in the automated test runner but I also ran bundletester on a
local KVM provider where it too a REALLY long time but all 12 tests passed!

+1 LGTM so I merged it today.

You can read more about the proposal here:
https://code.launchpad.net/~stub/charms/trusty/postgresql/rewrite/+merge/267646

A big thank you to Stuart Bishop and Tim for all the cycles with our team
to get the postgresql tests to run in automation!

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] apache-kafka

2015-10-30 Thread Matt Bruzek

I spent some time reviewing the apache-kafka charm today.  Apache Kafka is
a message broker that can be used in some big-data solutions.

After a few iterations with the author we got the charm passing tests and I
promulgated it to the charm store!

You can read more about it here:

https://bugs.launchpad.net/charms/+bug/1489488

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] apache2

2015-10-16 Thread Matt Bruzek

I reviewed a merge proposal for the apache2 charm today.  The proposal
added a new configuration option but a description was not added to the
readme so I really didn't understand how to use it. The charm failed
automated testing and I was unable to merge this proposal.  I would really
like to see the new configuration option documented and the amulet tests
passing on this proposal, so we can ensure the apache2 charm's quality.

The review can be found here:
https://code.launchpad.net/~pedronis/charms/trusty/apache2/nagios_extra_check_https/+merge/270368

I did take the time to implement some of my suggestions with a merge
proposal of my own:

https://code.launchpad.net/+branch/~mbruzek/charms/trusty/apache2/nagios_extra_check_https

Cheers!

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Issue while deploying charm - Could not resolve 'archive.ubuntu.com'

2015-10-14 Thread Matt Bruzek

Hello Suchitra,

The error seems to indicate a problem not being able to find
archive.ubuntu.com.  This appears to be a DNS resolution problem.  The DNS
file can be found at /etc/resolv.conf on your system.

I would check that your DNS sever can be reached by the system you are
running Juju on.  If you can not ping the DNS server or other Internet
addresses I suspect there is a problem with the DNS server for that system.

Here is an Ask Ubuntu article shows how to temporarily use alternate DNS
servers to diagnose the problem:

http://askubuntu.com/questions/91543/apt-get-update-fails-to-fetch-files-temporary-failure-resolving-error

Please let me know if you need more assistance.

   - Matt Bruzek <matthew.bru...@canonical.com>

On Wed, Oct 14, 2015 at 8:07 AM, Suchitra Venugopal1 <suchv...@in.ibm.com>
wrote:

> Hi,
>  I am facing this issue while deploying a charm in my local container.
>
> 2015-10-14 12:47:09 INFO install After this operation, 11.7 MB of
> additional disk space will be used.
> 2015-10-14 12:47:09 INFO install Err http://archive.ubuntu.com/ubuntu/
> trusty-updates/main binutils amd64 2.24-5ubuntu13
> 2015-10-14 12:47:09 INFO install   Could not resolve 'archive.ubuntu.com'
> 2015-10-14 12:47:09 INFO install E: Failed to fetch
> http://archive.ubuntu.com/ubuntu/pool/main/b/binutils/binutils_2.24-5ubuntu13_amd64.deb
>  Could not resolve 'archive.ubuntu.com'
> 2015-10-14 12:47:09 INFO install
> 2015-10-14 12:47:09 INFO install E: Unable to fetch some archives, maybe
> run apt-get update or try with --fix-missing?
> 2015-10-14 12:47:09 ERROR juju.worker.uniter.operation runhook.go:103 hook
> "install" failed: exit status 100
>
> Tried to do apt-get update in the container, which is also failing.
>
> How do I resolve this issue ?
>
>
>
> Thanks & Regards,
> Suchitra Venugopal
> IBM India Pvt. Ltd
> Seat # EGLC 6F B099,
> C-Block, Embassy Golf Link,
> Intermediate Ring Road, Bangalore
> Off : (91)80-4129-7773
> Mobile  :   9663126000
> Email:   suchv...@in.ibm.com
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ibmwxs

2015-10-09 Thread Matt Bruzek

Kevin and I spent some time reviewing the IBM WebSphere eXtreme Scale charm.

The ibmwxs charm had some issues with not verifying the checksum if the
configuration values were empty, and the start hook not being called after
config-changed.  Also despite the name "Extreme Scale" the charm does not
have any relations or open ports, so the service is very limited from a
Juju perspective.

You can read more details here:

https://bugs.launchpad.net/charms/+bug/1470017

Have a good weekend,

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Inconsistencies between juju debug-hooks and "normal" hook environment

2015-10-06 Thread Matt Bruzek

Merlijn,

Now that I see more of what you are doing I have an alternate suggestion.

When you are running 'juju init' use the su command to run as the "ubuntu"
user.

su - ubuntu -c 'juju init'

Using the su command in this way gives a "login" environment for the user
"ubuntu".  I wrote a charm (named merlijn) to test this and I saw the error
you are reporting:
unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
unit.merlijn2/0.config-changed logger.go:40 + echo /root
unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
unit.merlijn2/0.config-changed logger.go:40 /root
unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
unit.merlijn2/0.config-changed logger.go:40 + juju init
unit-merlijn2-0[2994]: 2015-10-06 14:35:26 INFO
unit.merlijn2/0.config-changed logger.go:40 error: cannot determine juju
home, required environment variables are not set

What you were trying to do is create a juju environment for the root user
(which is not advised) rather you want to create a juju environment for the
normal (ubuntu) user.

Using the su command I was able to create a juju configuration file:
2015-10-06 14:47:10 INFO config-changed + echo /root
2015-10-06 14:47:10 INFO config-changed /root
2015-10-06 14:47:10 INFO config-changed + su - ubuntu -c 'juju init'
2015-10-06 14:47:11 INFO config-changed A boilerplate environment
configuration file has been written to /home/ubuntu/.juju/environments.yaml.

Likewise if you want to create artifacts for the ubuntu user, use the "su -
ubuntu" command.

Hope that helps.

   - Matt Bruzek <matthew.bru...@canonical.com>

On Tue, Oct 6, 2015 at 9:30 AM, Cory Johns <cory.jo...@canonical.com> wrote:

> Merlijn,
>
> That is an annoying inconsistency.  It's probably related to debug-hooks
> bootstrapping itself via `juju ssh` which logs in as the ubuntu user since
> root ssh is disabled, as well as it being unlikely that the actual hook
> context is a login shell.
>
> I imagine the generate-config error is due to the lack of either $HOME or
> $JUJU_HOME being set.  I would recommend trying explicitly setting
> JUJU_HOME=/home/ubuntu before calling generate-config and see if that works
> around it.
>
> I've also created a bug against juju-core for this:
> https://github.com/juju/juju/issues/3449
>
> On Tue, Oct 6, 2015 at 10:06 AM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>>
>> Hi Matt
>>
>>
>> Thank you for your response. It was nice seeing you too!
>>
>> Let me explain my two, maybe related problems a bit more:
>>
>>
>> 1. Home directory is different between debug and non-debug hook context.
>>
>>- Using the manual provider.
>>- When deploying a Charm, the install hook is run as the "root" user.* 
>> "echo
>>~" prints "/root".*
>>- When the install hook crashes, I connect to the unit using
>>`debug-hooks` and restart the install hook as you described using  'juju
>>resolved --retry unit/#'. After a while, tmux shows "[unit/0] 0:bash-
>>1:install* " at the bottom and cwd is '/var/lib/juju/agents/unit-0/charm'.
>>As I understand, I am now in the hook context, right? *However, "echo
>>~" prints "/home/ubuntu".* Even though the current user is root.
>>
>>
>>
>> 2. Something causes "juju init" to fail in non-debug hook context and
>> succeeds in debug hook context.
>>
>>
>>- Using manual provider
>>- Executing `juju init` or `juju generate-config` in a hook results
>>in the error message `error: cannot determine juju home, required
>>environment variables are not set`
>>- Executing `juju init` or `juju generate-config` in the hook context
>>using  `debug-hooks` and  'juju resolved --retry unit/#` succeeds.
>>
>>
>> My current workaround is to generate the initial juju config myself and
>> not use "juju generate-config". However, I'm not sure if this behavior is
>> intentional or a bug.
>>
>>
>> Thanks in advance!
>>
>>
>> 2015-10-06 15:37 GMT+02:00 Matt Bruzek <matthew.bru...@canonical.com>:
>>
>>> Hell again Merlijn,
>>>
>>> It was nice to see you at the Charmer summit!  This is a very
>>> interesting use of Juju.
>>>
>>> What you are seeing is what we call a "hook context".  Hooks execute
>>> with root authority and have certain environment variables are set. This is
>>> so Juju commands and tools work correctly.  The debug-hooks command puts
>>> you into a "hook context" when you run  'juju resolved --retry unit/#'
>>>
>>> As I

Re: Inconsistencies between juju debug-hooks and "normal" hook environment

2015-10-06 Thread Matt Bruzek

Hell again Merlijn,

It was nice to see you at the Charmer summit!  This is a very interesting
use of Juju.

What you are seeing is what we call a "hook context".  Hooks execute with
root authority and have certain environment variables are set. This is so
Juju commands and tools work correctly.  The debug-hooks command puts you
into a "hook context" when you run  'juju resolved --retry unit/#'

As I wrote all hooks are executed with these environment variables set.  If
you are running the install script manually outside of a hook context these
environment variables would not be set.

There is more information about the environment variables here:

https://jujucharms.com/docs/devel/authors-hook-environment

However, I don't see "JUJU_HOME" listed on this page. Perhaps you could
give me more information on what variable is causing a problem and perhaps
your hooks could set those values in the case where the script runs
manually.

Cheers!

   - Matt Bruzek <matthew.bru...@canonical.com>

On Tue, Oct 6, 2015 at 5:07 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi
>
>
> I'm developing a Charm that installs the Juju client, among other things.
> I'm having some trouble getting this to work. When I use juju debug-hooks
> and manually run the install hook, everything works fine. However, when the
> hook is executed by Juju automatically, I get strange errors such as
> "error: cannot determine juju home, required environment variables are not
> set"
>
> Both the debug-hooks and the normal hook environment execute as root.
> However, a lot of env vars are different, like the home dir.
>
> Debug-hooks:
> echo ~ : /home/ubuntu
> hook env:
> echo ~: /root
>
> Is this intentional? This causes a lot of bugs that cannot be reproduced
> by debug-hooks. Is there a way to solve  "error: cannot determine juju
> home, required environment variables are not set"?
>
>
>
> Kind regards
> Merlijn Sebrechts
>
> --
> 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] apache-hbase

2015-10-02 Thread Matt Bruzek

I reviewed the apache-hbase charm today:

https://bugs.launchpad.net/charms/+bug/1487050

While it did pass amulet tests it had some other issues that blocked it
this time.  I created a Merge Proposal to fix some of the problems here:

https://code.launchpad.net/~mbruzek/charms/trusty/apache-hbase/icon-code-fix/+merge/273275

Thanks!

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] was-base

2015-09-25 Thread Matt Bruzek

I spent some time reviewing the was-base charm today.  This charm exhausted
the default amazon root-disk and there was no mention of that in the
README. The charm needs more than 15GB of root disk.  I used
'set-constraints' to request a larger instance it did deploy with some
problems that were mentioned in the review.

https://bugs.launchpad.net/charms/+bug/1446966

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] mobilefirst-server

2015-09-04 Thread Matt Bruzek

I spent the time reviewing the IBM MobileFirst-Server today.  This one
required 2 other IBM charms (DB2 and WebSphere Liberty) to deploy and the
instructions indicated to deploy to the same server. The charms deployed
but "No runtime environments deployed to this server" so that looks like
something was not configured correctly.

You can read more about it here:
https://bugs.launchpad.net/charms/+bug/1478783

   - Matt Bruzek <matthew.bru...@canonical.com>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Deploying webapp to Tomcat Charm

2015-08-19 Thread Matt Bruzek

Hi Tom,

Take a look at the openmrs charm for an example of a war file deploying to
a tomcat charm.

https://jujucharms.com/openmrs/precise

Subordinate charms like openmrs it will not run the install hook until it
is related to a container charm, so normal charm hooks (install,
config-changed, start) would be what you can use.

The openmrs charm has not been ported/tested with trusty so that is the
reason there is no trusty version yet.  In the mean time you can put
openmrs in a trusty directory and deploy a local copy that way.  The
openmrs charm uses a juju-info relation that can relate to any charm
including the trusty version of tomcat. It was pointed out that creating a
javawebapp relation was a better way to relate webapps and that change was
made in precise but not tested/moved forward to trusty at this time.

Please contact me if you have any other questions, I would be happy to help
you develop your charm.

Thanks,


   - Matt Bruzek matthew.bru...@canonical.com

On Wed, Aug 19, 2015 at 8:34 AM, Tom Barber t...@analytical-labs.com wrote:

 Hi chaps

 After a chat with Corey et al a few weeks ago it was suggested I deploy
 our product using the Tomcat charm as a container, which I thought was a
 pretty good suggestion.

 So, I look at the precise charm and it says:

 For another charm to provide a webapp, it must be a subordinate charm that
 supports the java-webapp relation.

 Can someone show me an example or just elaborate on that a bit more, how
 does it know which file to deploy, does it require a trigger or similar?

 Also that stuff is missing in the Trusty Tomcat charm from what I can see.
 Why is there a disparity in versions and if so, whats the best way to
 deploy a war?

 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

[Review Queue] mysql

2015-08-19 Thread Matt Bruzek

The mysql charm was failing some of our automated tests.  Ryan Beisner took
some time to fix these issues.  In addition to passing OSCI tests they pass
the blockers that I identified in the automated tests.

https://code.launchpad.net/~1chb1n/charms/trusty/mysql/fix-amulet-deps/+merge/268410

Thanks Ryan!

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

[Review Queue] ibm-mq

2015-08-14 Thread Matt Bruzek

I spent some time reviewing the IBM MQ charm submission. This charm has had
several iterations of reviews by different people and this time the tests
passed and I was able to promulgate the charm.

It should be noted this charm still requires downloading proprietary
software, but the README clearly calls this out and when the software is
there this charm works very well and passes all tests.

https://bugs.launchpad.net/charms/+bug/1432489

Thanks to Cory and Kevin for the reviews on this charm as well.


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

Re: i want in (to ~charmers)

2015-08-10 Thread Matt Bruzek

Another person who delayed the charmer application too long!

Kevin forgot to mention he is also a concierge for the IBM charmers. That
has been a lot of work ... simply to put up with me!

I know Kevin to be a level headed realist.  He is great to bounce ideas off
of and often comes up with good solutions on his very own!  He has
co-authored a lot of Big Data charms and enumerates the fixes of those bug
ridden charms.

*Kevin gets a +1 from me!*  And if you don't get in on this one, please do
not wait 1 year to apply again!

   - Matt Bruzek matthew.bru...@canonical.com

On Mon, Aug 10, 2015 at 11:39 AM, Kevin Monroe kevin.mon...@canonical.com
wrote:

 Hey Charmers,

 I was waiting for a sufficient amount of time to pass after aisrael
 applied to ~charmers because no one can follow that...  But then cory_fu
 threw his hat in the ring.  These guys are giants in our space, and I'm
 humbled to get to work with them.

 That said, I'm ready to apply to ~charmers myself.  I've been with the
 Juju Eco team for about a year now.  If you compared my first charm (all
 1GB of db2 express) to my latest Apache Flume offerings, you'd +1 me for
 most improved without hesitation.  Like Cory, I'm mostly focussed on Big
 Data charms (for which I've authored a metric boat load).  I'm also proud
 of my contributions to the ecosystem with doc merges, speaking at local
 meetups, charm schools, and ISV work.

 I've done my fair share of Review Queue work over the last year, and like
 pornography, I know what a good charm looks like.  I'd be honored to change
 my lower third to 'Juju Charmer' if you'll have me.

 Thanks for your consideration!
 -Kevin


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

2015-08-07 Thread Matt Bruzek

I reviewed the IBM DB2 charm today.  This is another charm that requires a
lot of error prone setup before it will deploy, such as downloading the
binary and hosting it on a web server.  This will be very hard for
customers to accept when they have mysql or postgresql that deploy directly
from Juju with no manual setup involved.

In the end there were some errors in the db2 charm hooks that caused the
review to get a -1 from me.

Read more about it here:

https://bugs.launchpad.net/charms/+bug/1477057


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

Re: Charmers application

2015-08-07 Thread Matt Bruzek

It sure took you long enough to apply Cory!  You almost get a negative one
from me just on waiting so long!

My vote is +1 on Cory.

His anchor tells me he is very good at documentation, and we need all the
help on docs that we can get!

Welcome aboard Cory.

   - Matt Bruzek matthew.bru...@canonical.com

On Fri, Aug 7, 2015 at 11:29 AM, Cory Johns cory.jo...@canonical.com
wrote:

 Dear Charmers,

 I would like to apply for membership to https://launchpad.net/~charmers

 I have worked on the current set of Big Data charms
 https://jujucharms.com/u/bigdata-dev/ and bundles, Cloud Foundry charms
 https://jujucharms.com/u/cf-charmers/, and several other smaller
 charms.  I also try to participate on the Review Queue more or less weekly.

 I also work on many of the development tools for charms, such as Charm
 Helpers, the Services Framework, the upcoming reactive pattern, relation
 stubs, and composition, as well as several Juju Plugins for developing and
 debugging charms.

 Thank you for your consideration.

 - Cory

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

2015-07-22 Thread Matt Bruzek

I spent some more time in the review queue this week. Reviewing two charms
this time.

docker
A new branch was submitted for review.  This one merged cleanly but the
tests raised 3 problems.  I created a merge proposal to solve one of the
problems but the author will have to look into the other two.

https://code.launchpad.net/~lazypower/charms/trusty/docker/i-hate-bzr

precise/cassandra
Antoni had an update to the precise version of cassandra that I have
reviewed in the past.  The changes looked good to me so I gave this one a
+1.

https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120

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

[Review Queue] docker

2015-07-21 Thread Matt Bruzek

I spent some time this week reviewing a branch to the docker charm.

There were a few tab/space errors that generated bundletester errors and
the branch did not merge cleanly.  This branch got a needs fixing from me.

The next revision will be steller, of that I have no doubt.

https://code.launchpad.net/~lazypower/charms/trusty/docker/trunk/+merge/265205

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

[Review Queue] etcd

2015-07-17 Thread Matt Bruzek

Hi,

I had the pleasure of reviewing the etcd charm today.  It passed charm
proof, the python code passed pep8 and my review of the code.

I deployed this charm manually on GCE and scaled up to a 3 node cluster
successfully.  I also ran the tests with bundletester on Amazon and the
three tests passed!

For more details go here:  https://bugs.launchpad.net/charms/+bug/1474061

Thanks,

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

[Review Queue] precise/cassandra

2015-07-06 Thread Matt Bruzek

I got pinged by a friend in #juju and he asked about a merge proposal that
was not in the review queue.  The merge proposal was not in the review
queue because the status was In Progress.  It needs to be in Ready for
Review.

https://code.launchpad.net/~celebdor/charms/precise/cassandra/hostname_resolve/+merge/257120

This one did not get my approval because it contained immutable
configuration.  I spoke with the author and he will update it soon.

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

[Review Queue] platform-symphony

2015-06-26 Thread Matt Bruzek

Hello Juju people,

I spent a lot of time reviewing the latest IBM charm platform-symphony.  It
was an excellent start but in the end did not pass my review. Read more
about it here:  https://bugs.launchpad.net/charms/+bug/1459213

I could see that they needed a little help with the markdown so I created a
branch to clean up the formatting and markdown errors:
https://code.launchpad.net/~mbruzek/charms/trusty/platform-symphony/readme

I linked that to the branch for an easy merge.

Cheers,

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

Celebrate Kubernetes birthday today with Juju

2015-06-10 Thread Matt Bruzek

I am really excited to announce the latest feature that allows developers
to immediately deploy their changes to a cluster.  I wrote a blog post
about it here:
http://bruzer.net/2015/06/10/deploy-a-kubernetes-development-cluster-with-juju/

If you haven't tried the Juju Kubernetes provider, there is no time like
the present.  Kubernetes is celebrating its birthday today and we want to
celebrate with you!

https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/getting-started-guides/juju.md

Our goal is that you find this work valuable, and we appreciate any/all
feedback that you have.

Thanks!

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

[Review Queue] ibm-mq

2015-06-05 Thread Matt Bruzek

I reviewed the IBM MQ charm again.  The charm is making incremental steps
toward the store, but since the tests failed and other issues found in this
review I could not push this charm.  Read more about it here:

https://bugs.launchpad.net/charms/+bug/1432489

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

[Review Queue] gpfs

2015-05-29 Thread Matt Bruzek

I spent some time reviewing the IBM GPFS charm today.  This is a python
charm and the code seems really well done.  Again this is a charm that
needs a separate binary to be manually downloaded.  This charm requires
that the file must be unpacked and hosted as an apt repository before we
can deploy the charm.  I was unable to get the binary from IBM in time for
the review so I reviewed the other parts of the charm.

My comments can be found here:
https://bugs.launchpad.net/charms/+bug/1431045

Since we don't have the binary, it could not be fully tested and pass a
review.  I contacted the developer directly and we are working on getting a
binary file so this review can happen.  More to come!

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

[Review Queue] flannel-docker, nrpe

2015-05-22 Thread Matt Bruzek

Chuck found a bug in the flannel-docker charm and I reviewed that change
today.  It passed our CI and my manual testing.  Thanks to Chuck for a
quality submission.

https://code.launchpad.net/~lazypower/charms/trusty/flannel-docker/trunk/+merge/259786

I also reviewed a change to the nrpe-external-master charm.  That also
passed and was merged!

https://code.launchpad.net/~macgreagoir/charms/precise/nrpe-external-master/load/+merge/258034

Thanks,

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

[Review Queue] IBM IB

2015-05-08 Thread Matt Bruzek

I spent some time reviewing the IBM Integration Bus (IB) charm today.  My
review is here:  https://bugs.launchpad.net/charms/+bug/1452242

This is another charm where the author is expecting the Juju user to
download the software (1.2GB) separately, host it on a web server and
*then* deploy will work.  That is a really poor experience in my opinion
and I would like to see the charm automatically download the software for
the user, that is the magic bit of Juju!

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

[Review Queue] ibm-mq

2015-04-16 Thread Matt Bruzek

I spent some time reviewing the IBM MQ charm in the review queue today. My
review can be found here:
https://bugs.launchpad.net/charms/+bug/1432489

One important thing to note is this charm does *NOT* contain the binary
needed to deploy, *nor* does it download the binary.  This creates a lot of
extra (error prone) work for the Juju user.

I would very much like to see the 90 day trail software or the full
software included in the charm if possible to make it easy to deploy this
in Juju.

Thanks,

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

Re: Kuberentes provider code has landed in MASTER!

2015-04-02 Thread Matt Bruzek

Hello Dustin,

I blogged about Kubernetes and Juju a few weeks ago.

http://bruzer.net/2015/03/16/kubernetes/

Re-share if appropriate

   - Matt Bruzek matthew.bru...@canonical.com

On Thu, Apr 2, 2015 at 11:39 AM, Dustin Kirkland kirkl...@canonical.com
wrote:

 Fantastic!

 Can someone write up a good blog post about this, so we can syndicate
 out through our social media channels?  This is a container of gold
 ;-)

 Dustin Kirkland
 Canonical, Ltd.


 On Thu, Apr 2, 2015 at 11:36 AM, Charles Butler
 charles.but...@canonical.com wrote:
  Greetings,
 
  As some of you may know the new-workloads eco team has been working
  dilligently with Google upstream to land Juju as an officially supported
  provider in the Kubernetes project. We've just officially landed our
 first
  code PR that enables juju in the cluster-up (the official kubernetes
  deployment scripts)
 
  https://github.com/GoogleCloudPlatform/kubernetes/pull/5414
 
  I'm very proud to announce we are now ready to start iterating faster,
 and
  landed more features against the kubernetes charms than before. We are
  excited and looking to a great future being included in the upstream
  repository.
 
  Currently this will deploy the 0.8.1 release of juju, and can be
  accomplished by:
 
  cloning the kubernetes project
 
  export KUBERNETES_PROVIDER=juju
  cluster/kube-up.sh
 
 
  This will fire up juju-quickstart to populate details if there is no
  current-environment file in $JUJU_HOME.
 
  The rest is a fully automated deployment of the k8's charms to setup a
  micro-cluster consisting of 1 master, and 2 minions.
 
  If you try this and have any feedback we welcome it at the bundle
 repository
 
  https://github.com/whitmo/bundle-kubernetes
 
  Additionally we have a full fledge documentation suite setup here:
 
  http://whitmo.github.io/bundle-kubernetes/
 
 
  All the best,
 
 
  Charles Butler charles.but...@canonical.com - Juju Charmer
  Come see the future of datacenter orchestration: http://jujucharms.com
 
  --
  Cloud mailing list
  cl...@lists.canonical.com
  Modify settings or unsubscribe at:
  https://lists.canonical.com/mailman/listinfo/cloud
 

 --
 Cloud mailing list
 cl...@lists.canonical.com
 Modify settings or unsubscribe at:
 https://lists.canonical.com/mailman/listinfo/cloud

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

[Review Queue] galera-cluser

2015-03-31 Thread Matt Bruzek

I took some time to review the galera-cluster charm today.  The charm
deploys per the README, but had some issues that needed to be addressed. I
left my comments in the bug:
https://bugs.launchpad.net/charms/+bug/1430796

Thanks!

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

[Review Queue] Cassandra spike

2015-03-24 Thread Matt Bruzek

I reviewed the cassandra spike merge proposal.  The branch fail to run on
the automated testing infrastructure.

https://bugs.launchpad.net/charms/+bug/1419116

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

Interested in a Docker Hackathon?

2015-03-09 Thread Matt Bruzek

I am interested in participating in the Hackathon right before Dockercon:

https://www.eventbrite.com/e/dockercon-sf-hackathon-tickets-15613226581

Need some help with great ideas to get Docker working better with Ubuntu
technologies such as *Juju*, snappy or LXD.  Also looking for 2 more team
members that would be available that weekend in the San Francisco area. If
you are interested in hacking on Docker or have an idea for the hackathon
please reach out to me and let me know.

Thanks,

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

[Review Queue]: Openbook

2015-02-10 Thread Matt Bruzek

For my time in the review queue I did another round on the Talligent
Openbook charm.  The previous problem was fixed, but it had another
configuration related problem.

https://bugs.launchpad.net/charms/+bug/1411402

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

[Review Queue] unmaintained charms

2015-01-30 Thread Matt Bruzek

The time I spent in the review queue was following the unmaintained charm
process.

We have identified the charms failing automatic testing, emailed the list
and notified the maintainers, after a month of no activity I marked 5
charms unmaintained:
opentsdb, hive2, solr-jetty, thinkup, newrelic-php

I worked on the code to so the trusty nagios charm will not fail tests.  I
will also work on tomcat and websphere-liberty.

To avoid having a charm unmaintained all the author needs to do is respond
to the bug that they are aware of the problem and are looking to fix it.

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

Re: questions on Charm Store Policy

2015-01-27 Thread Matt Bruzek

Jason,

I think we discussed this in the #juju irc channel, but I wanted to follow
up with an email to be complete.

   - Matt Bruzek matthew.bru...@canonical.com

On Fri, Jan 16, 2015 at 5:07 PM, Jason Hobbs jason.ho...@canonical.com
wrote:

 Hi all,

 I spent some time this week reviewing a charm, and have some questions
 about some of the Charm Store Policy requirements. I want to make sure I
 understand these requirements well enough to explain them to people
 who's charms I review, and to be able to give them direction on how they
 can bring their charms in line with the policy. I also want to make sure
 that if someone else reviews the same charm I review they come to the
 same conclusions as I do. Some of these have been discussed some already
 on #juju@freenode, but it was suggested I post them here too; I would
 appreciate any thoughts you have on this!

 Must follow the spirit of the Ubuntu Philosophy.
 As applied to a charm I think this essentially boils down to the charm
 only containing free and open source software, and not doing anything
 nefarious. But, it should be acceptable for a charm to install non-free
 software from a location outside of the charm itself, as long it's clear
 up front, right?


We discussed this policy recently and I agree that it is vague.  Indeed we
do want to charm up non-free software as well.  We have partnered with
different companies and have developed several charms with partners
(mellanox, mariadb, websphere-liberty).  The important things to point out
here are the charm code should be an FOSS license, but the software or
service can be under its own license.


 Must also be valid for the charm and/or bundle format defined in Juju's
 documentation.
 I think this means that to be in the charm store, the software needs to
 be a charm or a bundle - not just some arbitrary piece of code like you
 can stick in a bzr repo.  Is that right?

 My understanding of this policy is the charm must be in a structure that
Juju understands.  There are certain files that must exist to be a valid
charm (metadata.yaml for example), or a valid bundle (bundles.yaml).  All
that means is the charm must not break with convention in ways that would
break Juju, or our automated testing.

Currently charms must be in launchpad to get in the recommended section of
the charm store.  However we recognise that many developers are using
github these days and we are looking at ways to support that.  Technically
you can write a charm in github, and deploy it from a local repository on
your machine (no launchpad needed).


 Should make use of AppArmor to increase security.
 I read this is a recommendation, not a requirement, because of the
 should. However, it's not clear what the intent is. It would be nice
 if there was guidance we could point to here on how charms should deal
 with apparmor. I think it's usually handled by packaging, and a charm
 shouldn't need to deal with it if it is. Are there cases where a charm
 does need to do something with apparmor, even if the package does? When
 developing a charm for software without apparmor enabled packaging, what
 are the recommendations?
 Thanks for the questions, my responses are in-line.

 Our documentation falls down here.  Since our discussion there are plans
made to improve that.  I would like to learn how to use apparmor better and
will post more information when I do.



 Must include tests for trusty series and any series afterwards. Testing
 is defined as unit tests, functional tests, or integration tests.
 Does any series mean any LTS or does it include non LTS releases too?
  Is this saying that if tests are included, they must support Trusty and
 future releases? Or is it ok to leave tests out altogether? If tests are
 required, is there a minimum standard of coverage? Is verifying the
 service is pingable after deploying it enough, or does it need to
 exercise features?


We are running all the recommended charms automatically now against
different Juju environments.  All trusty charms must contain tests to
become recommended charms so we can ensure the quality of the charms.

This is a relatively new policy so we could not retroactively enforce that
on older charms.  So older series can get by without tests, but are highly
encouraged.

The tests are up to the author.  Ideally there would be a full suite of
tests, unit, functional and integration tests.  The tests that charmers are
looking for are functional (does the charm work) and integration (does the
charm deploy, relate, scale, and configure properly).


 Thanks,
 Jason

 --
 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] wildfly charms

2015-01-20 Thread Matt Bruzek

I spent some time in the review queue today on the wildfly-ha-master and
wildfly-ha-slave charms.

https://bugs.launchpad.net/charms/+bug/1399239
https://bugs.launchpad.net/charms/+bug/1399228

Both are now in the recommended section of the charm store.  Many
thanks to *Saurabh
Kumar* from Techblue for working with the review comments and landing the
charms!

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

[Review Queue] mongodb

2015-01-13 Thread Matt Bruzek

Hello everyone during my time in the Review Queue I reviewed and merged the
changes to the trusty mongodb charm from Wes Mason.

https://code.launchpad.net/~wesmason/charms/trusty/mongodb/merge-precise-patches/+merge/237694

One of the files, hooks.py had some linting errors which I cleaned up, but
the author actually touched the hooks.py in this change.  Please remember
to run the lint on the charm before creating a merge proposal.

Thanks,

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

[Review Queue] openvpn-p2p, bind-resolver

2015-01-06 Thread Matt Bruzek

I spent some time reviewing two new networking charms.

* openvpn-p2p:  -1

https://bugs.launchpad.net/charms/+bug/1389826

* bind-resolver: -1

https://bugs.launchpad.net/charms/+bug/1389827

Thanks,

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

Review Queue mbruzek charm triage

2014-12-17 Thread Matt Bruzek

I spent most of my Review Queue time triaging charms that FAIL the
automated testing tools.  The CI team has built us a report that shows
which charms PASS or FAIL on multiple cloud environments.

If you are interested in which charms are failing or if you are interested
in helping fix a charm you can query the bugs related to auto-test by going
to the following link:

https://bugs.launchpad.net/bugs/+bugs?field.searchtext=field.tag=auto-test

Thanks!

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

Review Queue mbruzek (Dec 8 - 12)

2014-12-16 Thread Matt Bruzek

*sigh* This email was in draft form and never sent.

I spent some time triaging the charms that fail automated testing. If you
see bugs open against charms you know and love please take some time to fix
the errors that we are seeing.

I myself had some tests that failed. Cory created merge proposals against
my tests that helped them pass.  I reviewed those too.

couchdb -
https://code.launchpad.net/~johnsca/charms/precise/couchdb/fix-install/+merge/243549
distcc -
https://code.launchpad.net/~mbruzek/charms/precise/distcc/tests/+merge/240908


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

[Review Queue] owncloud, and transcode

2014-12-02 Thread Matt Bruzek

Today in the Review Queue I reviewed the following:

Promote owncloud charm to trusty:
https://bugs.launchpad.net/charms/+bug/1389078

The maintainer added tests but Amulet tests default to the precise series.
I made a small change to get it to pass the tests:
amulet.Deployment(series='trusty')

Once the tests passed I promulgated the owncloud charm for trusty.


Adding tests to transcode:
https://code.launchpad.net/~marcoceppi/charms/precise/transcode/tests/+merge/240890

This charm had a bundle in the charm directory that is incorrect and caused
the tests to fail.  I moved the bundle to a bundles directory and the charm
tests passed.  I merged the charm with these changes.

Thanks,


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

[Review Queue] Zend Server

2014-11-13 Thread Matt Bruzek

I spent some time reviewing the Zend Server charm yesterday.  This charm
was written by our partners at Zend and was used in a recent Turbo LAMP
stack demo.

The charm code contained tests which were really helpful to test it on the
environments such as Power 8, and HP-cloud.  All the tests passed and the
charm passed the Charm Store review criteria!

It is my pleasure to introduce the zend-server charm to the Juju
ecosystem.  http://manage.jujucharms.com/charms/trusty/zend-server

Thanks

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

Review Queue mbruzek

2014-11-04 Thread Matt Bruzek

Hello Juju,

I spent some time in the Review Queue today .  Reviewed some charms that
got tests and they could finally be added to trusty!  Here is what I found:

wordpress - https://bugs.launchpad.net/charms/+bug/1387335 - landed in
trusty
websphere-liberty - https://bugs.launchpad.net/charms/+bug/1388209 - landed
in trusty
sugarcrm - https://bugs.launchpad.net/charms/+bug/1388968 - landed in
trusty

I also got review feedback on my trusty zookeeper submission.  The branch
needed to be fixed so I worked on fixing the zookeeper charm so it passed
tests on local and the HP-cloud environment.

Thanks to all the authors who wrote tests for those charms!

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

New trusty charms

2014-11-03 Thread Matt Bruzek

I was working in the review queue last week on moving some precise charms
to trusty.  For the trusty series we have the requirement for tests and the
Eco team worked hard to add tests to many precise charms.  If you know of a
precise charm without tests, adding tests (that must pass) into trusty
would be a way you can contribute to the Juju Ecosystem.

Here are the charms I looked at last week:

varnish - https://bugs.launchpad.net/charms/+bug/1387368 - landed in trusty
vsftpd - https://bugs.launchpad.net/charms/+bug/1387727 - landed in trusty
apache2 - https://bugs.launchpad.net/charms/+bug/1387844 - landed in trusty
statusnet - https://bugs.launchpad.net/charms/+bug/1387742 - landed in
trusty
python-moinmoin - https://bugs.launchpad.net/charms/+bug/1387833 - landed
in trusty

Thanks to the authors who took the time to write these tests Tim
Vansteenburgh, Kevin Monroe and Charles Butler!

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

[Review Queue] hpcc

2014-10-23 Thread Matt Bruzek

I spent some time reviewing the High Performance Computing Cluster (HPCC)
charm today.  For those that do not know HPCC http://hpccsystems.com/faq
is a player in Big Data as an alternative platform to Hadoop.

The review passed and hpcc is the newest charm in the charm store!

https://bugs.launchpad.net/charms/+bug/1272083

This charm requires a minimum of 4GB nodes to deploy all the thor and roxie
processes so you will have to use the constraints flag to deploy it from
juju on a cloud properly.  All this is documented in the well written
README.md file inside the charm.

Thanks to the developer Xiaoming Wang for all the work and the patience
with the review process!

Go big data!

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

Re: Charmers Application

2014-10-13 Thread Matt Bruzek

A big +1 from me!

I know Tim to be an excellent python programmer!  His work on the
charmguardian testing tool has helped out the quality of Juju.

Welcome aboard Tim!

   - Matt Bruzek matthew.bru...@canonical.com

On Fri, Oct 10, 2014 at 5:28 AM, Tim Van Steenburgh 
tim.van.steenbu...@canonical.com wrote:

 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


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

[Review Queue] hdp-storm

2014-09-16 Thread Matt Bruzek

My time in the new Review Queue was spent on reviewing a new Big Data charm
hdp-storm.  This is the Hortonworks version of Apache Storm.  The charm
contained tests that passed, but I found some other things with the charm
that need polish before it goes into the charm store.

You can read more about it here:
https://bugs.launchpad.net/charms/+bug/1366979

Thanks,

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

Re: [Review Queue] hpcc charm

2014-08-27 Thread Matt Bruzek

I am tentatively +1 for adding some charm metadata for minimum requirements
for the charm.  We could certainly add that kind of information in the
README but having it in the metadata would make it automatic (magic).

José makes a great point about how something like this could increase the
cloud bill unexpectedly.  Perhaps some kind of informational message
requiring a response from the user would be good here.  Users could accept
or override the constraints.

The number of charms that would take advantage of this metadata would be a
small subset of what we have.  The big data charms, and other resource
intensive charms could set this optional metadata to give the user a good
experience.

Are there any other concerns that people have about this metadata idea?

   - Matt Bruzek matthew.bru...@canonical.com


On Wed, Aug 27, 2014 at 7:21 AM, José Antonio Rey j...@ubuntu.com wrote:

 It is a nice idea, but it should definitely fire up a warning saying
 that the machine will have larger specs, as well as asking for
 confirmation. I don't want to see any surprise charges in my AWS bills!

 On 08/27/2014 02:34 AM, Mark Shuttleworth wrote:
  On 27/08/14 00:10, Matt Bruzek wrote:
   First and most importantly the hpcc charm deploys according to the
 readme
  file! I had to increase the memory constraints on the HP-cloud to 4GB
 per
  machine (juju set-constraints mem=4GB) so all the services had enough
  memory to start up. After that I was able to cluster by adding units of
  hpcc.
 
  We have a couple of charms which break on tiny instances on some clouds
  because of this sort of disconnect. Would it be helpful to be able to
  encode minimum requirements in the charm metadata?
 
  Obviously, real requirements are configuration and load dependent, but I
  think we could avoid the obvious try it then debug it cycle if we had
  some explicit minimum requirements up front.
 
  Thanks for the review commentary and advice to charmers!
 
  Mark
 

 --
 José Antonio Rey

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

The gitlab charm is broken.

2014-08-25 Thread Matt Bruzek

Hello Juju community,

The gitlab charm has multiple (7) bugs open against it, gitlab also fails
charm proof, and does not deploy in precise.

https://bugs.launchpad.net/charms/+source/gitlab

This appears to be a charm without an active maintainer.  In following with
our charm policy I am emailing the community for help.

Is there anyone out there with Gitlab experience willing to maintain this
charm?

Kapil mentioned that Gogs is a git service written in Go that would be a
similar service, but so far we do not have a charm for that.

Please email me or the list if you are interested in maintaining the gitlab
charm.

Thank you,

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

We need a process to unpromulgate charms.

2014-08-22 Thread Matt Bruzek

Hello,

The Juju Ecosystem team is working on charm testing and it occurred to us
that we need a process for unpromulgation of charms.

Charles Butler came up with the process for when charms are broken or no
longer supported. That document can be found here:
https://docs.google.com/a/canonical.com/document/d/1k8IBaLmOTpgOJQHv54BAnRfQLiC4hQ35lAm_3prlHwA/edit

What I would like to discuss here is: When a charm is no longer needed.
For example the tomcat6 and tomcat7 charms are completely superseded by the
new tomcat charm. We want to unpromulgate them so Juju users use the new
tomcat charm.

The question I bring to you today is:

*What should the process be when we unpromulgate a charm?*

I see a few options:

1) Unpromulgate the charm and keep it in the ~charmers branch in
launchpad.
2) Unpromulgate the charm and move it to another personal name space
(something like ~unmaintained).
3 Unpromulgate the charm and delete the branch?

There are problems with each approach and therefore I wanted to present
this to the community.

The problem with #1 is that the ~charmers branch is our official branch and
I am not sure we want to keep unmaintained charms in there when they are no
longer maintained or the charm is no longer not recommended.

Please let us know what your opinion and reasoning is for what to do with
unpromulgated charms.

Thank you for your time,

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

[Review Queue] elasticsearch adding ufw support

2014-08-19 Thread Matt Bruzek

Today I had the chance to review the ufw changes for the trusty
elasticsearch charm. The elasticsearch charm is a really good example of a
charm that uses Ansible ( http://www.ansible.com/home ). Even though I am
not an Ansible expert, I was able to follow along.


 The change involved adding support for ufw (Uncomplicated FireWall) to the
charm and adding rules around the ports 9200 and 9300. I would recommend
the trusty elasticsearch charm as a great example of how to do firewalls if
anyone else needs to use firewall rules in their charms.


 Michael Nelson did a very good job of providing guidance on how to test
the changes. I ended up deviating from the steps, but I really appreciated
having a place to start with the testing. Thank you Michael for including
testing steps in your merge proposal, that was much appreciated and sped up
the review process for me. The more testing/verification instructions in
the merge proposals will help speed up the reviews that we are behind on.
So if you are reading this and do not have test/verification steps in your
merge proposal please add them!


 The new elasticsearch charm is available here:

http://manage.jujucharms.com/charms/trusty/elasticsearch


 Thanks,


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

Re: ~charmers Application - David Britton

2014-08-14 Thread Matt Bruzek

David,

You have been a great member of the Juju community. There have been
several occasions that you have helped me out and I really appreciate
that.

+ 1 from me on promotion to charmer status!

- Matt Bruzek matthew.bru...@canonical.com

On Fri, Aug 8, 2014 at 9:31 PM, David Britton david.brit...@canonical.com
wrote:

Hi Charmers --

Here you will find my application for inclusion into the charmers group.

I have been using and developing charms for juju since the pyjuju days,
while it was being renamed to juju from ensemble. I have authored a
number of charms (Some public, some just for personal use), and made
significant contributions to many more.

At my day job, I work for Canonical on the Landscape team. This has
afforded me the opportunity to work on those charms we use most to
faciliate our products (apache2, postgresql, haproxy). I have made a
number of visible contributions to these from small bug fixes to large
features.

Our own charms (landscape-server, landscape-client) are maintained under
the ~landcape-charmers team, of which I'm a member. We even have a
separate project (landscape-charm) in launchpad for tighter control of
our development process on our landscape-server charm -- these charms
are both fully open source (GPLv2).

We have a fairly extensive internal testing infrastructure for our
landscape charms where we spin them up in different combinations daily
(trusty, precise, multiple versions of Landscape, etc). We do this all
with juju test at an integration level. We also have a full and
comprehensive unit test suites for each of our charms.

Recently, I desinged, implemented and now maintain (with much help from
my fellow team members) the storage charm, and the block-storage-broker
charm. These charms allow other services to request, assiociate and
mount cloud storage in a juju-friendly way. I'm hoping to see wider
adoption of these.

I have contributed to the openstack charm collection in a number of
ways, testing, debugging, contributing patches, etc.

Past these charm specific contributions, I also test, file bugs and
contribute patches back to other juju products (juju-deployer,
charm-tools, charm-helpers, juju-core, juju-gui, ...) on a regular
basis.

Lastly, I am a heavy user of Juju, maintaining many of our teams
internal services with it -- so I undersatnd the need to have charm
quality and robustness. I also am very aware of making sure full
solutions work, not *just* individual charms.

Here are some of the charms where I've made significant contributions
(authorship-level):

https://jujucharms.com/precise/landscape-server
https://jujucharms.com/precise/landscape-client
https://jujucharms.com/precise/storage
https://jujucharms.com/precise/block-storage-broker

Charms I've conrtibuted major changes to:

https://jujucharms.com/precise/haproxy
https://jujucharms.com/precise/apache2

A couple larger MPs that I have authored:

https://code.launchpad.net/~davidpbritton/charms/precise/haproxy/fix-service-entries/+merge/202387

https://code.launchpad.net/~davidpbritton/charms/precise/apache2/vhost-config-relation/+merge/220295

https://code.launchpad.net/~davidpbritton/charms/trusty/apache2/avoid-regen-cert/+merge/223990

Feel free to ask me any questions, and thanks for your consideration.

:-)

--
David Britton david.brit...@canonical.com

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

Re: No icon = no promulgation?

2014-08-14 Thread Matt Bruzek

Hello José,

Thanks for sending this email out.  Your commitment to the Juju community
is pretty impressive.  What you did not mention in your email is the reason
you were subscribed to this bug is because you performed a community review
of this charm for us.  That is something I really appreciate, and want to
thank you again for reviewing the charm.

What we have here is a policy question.  Should we be able to promulgate
charms without icons?  In an ideal world, I want an icon for each charm but
in the real world I live in, not every charm has an icon.  Do I want to
make that better?  Heck yeah I do!  So I agree with the policy.

The old saying goes there is an exception to every rule.  I believe this
charm qualifies for an exception because of the circumstances.  The author
has asked for approval to use an official icon and has received no
response.  So my question to the group is:  Should there be an exception
process that we can follow for situations like this?  For example could the
charmers take a vote on the issue, or send a message to the community.  I
am looking for a pragmatic way to handle a minor exception to policy.

Incidentally, I am working with the author to create an icon for this charm
and hope to have something *soon* so we an add CakePHP to our ecosystem!

   - Matt Bruzek matthew.bru...@canonical.com


On Wed, Aug 13, 2014 at 11:48 PM, José Antonio Rey j...@ubuntu.com wrote:

 Hello,

 As I am subscribed to all bugs in Juju (as some of you may also be),
 today I got an email from a CakePHP charm review. On this one, a charmer
 had to reject the submission because, when promulgating, the tool runs
 `charm proof` to make sure things are not broken, not promulgating if
 any Error or Warning pops up. And there was a problem: this charm did
 not have an icon (which throws a Warning in `charm proof`, making it
 impossible to promulgate it.

 I totally understand what has been done. Now, a charm cannot be
 promulgated when there are Errors or Warnings. But since not having an
 icon is a Warning, it will not allow a charmer to promulgate any charms
 which do not contain an icon, may it be because the author is asking for
 official permission (like in this case), because the service has no
 icon, or any other reasons. In some of the cases, it may be a
 fully-working charm, with no other issues apart from not having an icon.
 We even have lots of charms with no icon in the store. And about
 proposing a temporary icon, when I proposed an icon which was just an
 orange background with the service name, it got rejected. So, I don't
 know what may be an idea for a 'temporary' or 'provisional' icon.

 I believe having an icon is not that of a priority, and that we should
 focus in having charms that provide working services. Still, we should
 try to ensure and promote the idea of charms having icons, but I do not
 see it as a fatal error like to prevent promulgation.

 In this case, I would be for demoting the level of the warning issued by
 `charm proof` from Warning to Information. This, as it is not something
 critical, and charms/services will still work, even with no icon. It
 doesn't affect functionality, but it only removes the pretty part (that
 can be added later) of the GUI. By doing this, we will throw something
 when `charm proof` is ran, but still allow promulgation if there is no
 icon.

 What do you guys think about it?

 --
 José Antonio Rey

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

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

Re: LXC OS Updates

2014-08-04 Thread Matt Bruzek

On Mon, Aug 4, 2014 at 4:26 AM, John Meinel j...@arbash-meinel.com wrote:


 Creating a template that never gets updated just isn't a great experience,
 and we really need a way to refresh that core snapshot.

 John
 =:-

I would like to second John's comment here.  We do need a good way for the
user to easily get a new local cloud image if the existing one is getting
old.

As a developer I know we can delete the lxc cache and Juju bootstrap will
download a new cloud-image, but this is not something we would want a users
to do.


 On Thu, Jul 31, 2014 at 6:34 PM, Katherine Cox-Buday 
 katherine.cox-bu...@canonical.com wrote:


 We'd like to remove the assumption embedded in the code that if we're
 cloning an LXC container, then we never want to perform OS upgrades.
 Instead, the logic based on the config variable will take over, and the
 user can have whatever behavior they desire. Local installations will be
 snappy, and production installations will be up to date.

 We feel this empowers both developers and end-users, but wanted to raise
 this for discussion. Feedback welcome!


This proposal looks good and seems to address the concerns I have with the
local update  upgrade.  How would this be implemented?  Would the
variables pass the appropriate values to cloud-init?

Thanks,

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

Re: Best practice to continuously integrate application updates

2014-07-02 Thread Matt Bruzek

Hello Denis,

Thanks for the email.  You are correct that you would use the juju
upgrade-charm command to update the contents of your web application.  You
would implement the upgrade-charm hook to do what is necessary to update
your web application.

There is an excellent example of an existing charm written by Robert Ayres
that you can look at here:
https://manage.jujucharms.com/~robert-ayres/precise/j2ee-deployer

If you have charm tools installed you can download this example to your
computer:
juju charm get cs:~robert-ayres/precise/j2ee-deployer

The README file details how you can use the j2ee-deployer charm to deploy
webapps and update them as necessary.  This would be a great model to use
for your own charm.

Let me know if you need any more help on this!

   - Matt Bruzek matthew.bru...@canonical.com


On Tue, Jul 1, 2014 at 9:47 PM, Denis Weerasiri ddweeras...@gmail.com
wrote:

 Hi,
 I mentioned the command as charm-update. But it should have been
 upgrade-charm
 https://juju.ubuntu.com/docs/authors-charm-upgrades.html


 On Wed, Jul 2, 2014 at 12:44 PM, Denis Weerasiri ddweeras...@gmail.com
 wrote:

 Hi,
 Support I have written a charm to deploy a web application on top of
 tomcat. And now I need to redeploy the web application when I update the
 source repository of the web application. What is the best practice to do
 this?
 What I have in mind is to write a new version of charm and use
 charm-update command. So juju will re-deploy the web application.

 --
 Thanks,
 Denis Weerasiri

 Sent from my iPhone




 --
 Thanks,
 Denis Weerasiri

 Sent from my iPhone

 --
 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: Proposal: making apt-get upgrade optional

2014-07-01 Thread Matt Bruzek

Hello Andrew,

I ran into a problem when Juju was no longer calling apt-get update.  I
filed bug:  https://bugs.launchpad.net/juju-core/+bug/1336353

The problem appears to be the apt metadata was out of date and the charms
that call apt-get install ... in the install hook fail.  We also saw this
problem on a different system where the cloud image was out of date and the
install hook failed because no apt-get update was run.

Not calling apt-get update will break a large number of existing charms and
needs to be fixed.

It looks like we have 2 problems:

1)  Juju should provide a way to turn on or off the apt-get update.  I
would suggest an environment variable to enable or disable apt-get update.

2)  Juju does not manage the local cloud image found in
/var/cache/lxc/cloud-series/ directory.  The image I was using was older
(05/28/2014) and that is why the apt-get meta data was out of date.  Not
quite sure how to solve this, someone suggested a cron job to download the
lastest cloud image in the background.  Someone else mentioned this is a
security issue if the stale image does not have a patch and is not updated
we could have an issue.

This is not the experience we want to give to Juju users.  As developers we
should be able to turn off apt-get update for our own development purposes,
but leave it on so existing charms work.

I am willing to help resolve these two problems.  Please reach out to
mbruzek on irc or email me directly.  Thanks,

   - Matt Bruzek matthew.bru...@canonical.com


On Mon, Jun 30, 2014 at 8:05 AM, Andrew Wilkins 
andrew.wilk...@canonical.com wrote:

 Hi folks,

 I've been debugging a bootstrap bug [0] that was caused by ssh timing out
 (and the client not noticing), which was caused by apt-get upgrade taking
 an awfully long time (6 minutes on Azure).
 [0] https://bugs.launchpad.net/juju-core/+bug/1316185

 I just filed https://bugs.launchpad.net/juju-core/+bug/1335822, and did a
 quick and dirty hack that brought the upgrade down to 3 minutes on Azure. I
 don't know the variance, so I can't be sure that it's all due to eatmydata,
 but smoser's results are similar.

 Even with eatmydata, a full bootstrap on Azure just took me 10 minutes.
 That's roughly broken down into:
  - apt-get update: 20s
  - apt-get upgrade: 3m20s
  - apt-get install various: 10s
  - Download tools (from shared Azure storage account): 5s
  - jujud bootstrap: 1m50s

 We could bring the 10m down to 6m40s. Still not brilliant, but
 considerably better IMO.

 I propose that we remove the apt-get upgrade altogether. Cloud images
 are regularly updated and tested, and I think we should be able to rely on
 that alone. If users want something more up-to-date, they can use the daily
 images which are not tested as a whole, but are composed of SRUs, which is
 effectively what users get today.

 Cheers,
 Andrew

 --
 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 for jboss,hazelcast,infinispan

2014-06-17 Thread Matt Bruzek

Hello Sanat,

Linux Containers (LXC) provision very fast and work very well.  Using Juju
on your laptop is an excellent way to rapidly prototype cloud image
development as you need to do.  There are many resources on the Internet
that describe how to create charms.

https://juju.ubuntu.com/docs/authors-charm-writing.html
http://www.youtube.com/watch?v=ByHDXFcz9Nk

This one is particularly good at showing how to optimize your workflow
using Juju charms and a little trick:

http://www.youtube.com/watch?v=ND-vmtCOEjY

If you have any questions/comments/concerns about creating charms you can
contact us in #juju on irc.freenode.net, or ask a question tagged with
juju on
http://askubuntu.com.

Cheers,

   - Matt Bruzek matthew.bru...@canonical.com


On Tue, Jun 17, 2014 at 2:34 AM, Sanat Meti sanat.m...@bizruntime.com
wrote:

 No actually client requirment is to have jboss,hazelcast,infinspan as
 juju-charm.So how to create a custom charm for this app server
 (jbos),datagrid (hazelcast,infinispan).So a littel help on creating this
 charm will be helpful


 On Tue, Jun 17, 2014 at 4:54 AM, Matt Bruzek matthew.bru...@canonical.com
  wrote:

 Hello Sanat,

 Most of the charms are Free and Open Source Software.

 We have Wildfly which is an open source version based on JBoss:
 http://manage.jujucharms.com/charms/precise/wildfly

 We also have memcached:
 http://manage.jujucharms.com/charms/precise/memcached

 Those charms already exist in the Juju Charm store and can relate to
 other Juju Charms in the ecosystem.

 The others would be great submissions if you were willing to charm them
 up!

- Matt Bruzek matthew.bru...@canonical.com


 On Fri, Jun 13, 2014 at 8:04 AM, Sanat Meti sanat.m...@bizruntime.com
 wrote:

 Hi,

 is there any pre-configured char for jboss fuse,hazelcast
 mem-cache,infinispan or i have to write a custom charm for that

 --
 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: begin with Juju

2014-04-29 Thread Matt Bruzek

Felane,

It took some looking but Gustavo has a blog posting about Juju architecture:

http://blog.labix.org/2013/06/25/the-heart-of-juju

Juju is very easy to install on Ubuntu Linux.

sudo apt-get install juju-local juju-quickstart


   - Matt Bruzek matthew.bru...@canonical.com


On Tue, Apr 29, 2014 at 9:00 AM, Ilisia Felane felane@gmail.com wrote:

 Thank Matt for you reply.

 1) I agree with you, the better way to learn is to test, but my research is
 set in the context of a study and my boss would like to receive more
 information on the operation of the architecture of Juju. What it takes
 install? How Juju maintenance services? And ... I can not find this
 information on the site and in the documentation.

 3) thank for link.

 Best regards,

 Felane


 2014-04-29 17:37 GMT+02:00 Matt Bruzek matthew.bru...@canonical.com:

 Greetings Felane,

 Thank you for your interest in Juju and on behalf of the community:
 Welcome!

 1) The easiest way to develop and test charms is to run Juju on your
 dekstop computer.  There is a workflow for Windows, Linux, and OSX.

 2) You have already found our documentation, but need more information on
 Juju works with many cloud environments, AWS, Azure, HP-cloud, Joyent,
 OpenStack, and more.

 3)  Juju is a service orchestration tool.  It is one level above simple
 Chef administration.  Juju allows you to create dynamic relations and wire
 services together and scale them up.  You don't have to take my word for it.


 http://askubuntu.com/questions/52840/whats-the-difference-between-juju-and-puppet-chef

 There is an answer from the founder of Puppet.  That answers your
 question it very very well.

- Matt


 On Tue, Apr 29, 2014 at 3:31 AM, Ilisia Felane felane@gmail.comwrote:

 Hi,

 I started with Juju, and I look for more information on the
 architecture of Juju.

 1) Is there a server to fully use Juju? I can not find on the site that
 installed a Client. If yes, where can I find a server version of Juju? If
 not, how can I integrate the charms that I create?

 2) Where can I find additional documentation on the establishment of a
 comprehensive architecture Juju? The documents on the website speak only the
 configuration for the cloud and the establishment of charms ...

 3) Can I use the recipes created with Chief, but what's the point? What
 are the differences between Juju and Chef?

 Best regards,

 Felane

 --
 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: Best practices for fat charms

2014-04-01 Thread Matt Bruzek

Thanks Jorge,

Not sure we want to call them fat charms, maybe enterprise charms.
Here is my approach when making a charm work on the enterprise or limited
networks.

1) Find out what hook downloads the packages that we are unable to access
(wget, curl, or special ppa repositories).  The enterprise network will
block these requests often resulting in a charm hook failing.
2) Download the necessary packages from system that has access.
3) Upload the packages to the locked down system, copying the packages to a
directory on the local charm.
4) Edit the local charm hooks to check for the package in the local
directory first and if that does not exist, the charm would continue to
download the files (using wget, or curl, or custom ppa).

I believe we could provide a charm-tools method that does something like
this and we could use this in charms to create enterprise charms that are
able to be used on limited network environments.

However this creates an interesting problem that I have not figured out a
good way to resolve yet (your feedback requested).

If the packages exist within the charm the URL will never be used.  Some
charms allow the user to configure the download URL and sha1sum of the
package.  Other charms do not allow this level of customization.

For charms that have a config option for URL we could change it to also
accept a file:// transport and some kind of $CHARM_DIR variable and use
http:// or https:// for normal URLs.  But what to do with the charms that
do not allow the URLs to be configurable, or the charms that use a custom
ppa repository?

   - Matthew Bruzek matthew.bru...@canonical.com


On Tue, Apr 1, 2014 at 2:07 PM, Jorge O. Castro jo...@ubuntu.com wrote:

 Hi everyone,

 Matt Bruzek and I have been doing some charm testing on a machine that
 does not have general access to the internet. So charms that pull from
 PPAs, github, etc. do not work.

 We've been able to fatten the charms by doing things like creating a
 /files directory in the charm itself and putting the
 package/tarball/jar file in there, and given the networking issues
 that we might face in production environments that we should start
 thinking about best practices for having charms with payloads instead
 of pulling from a network source.

 Marco has some ideas on how we can generalize this and he will respond
 to this thread.

 --
 Jorge Castro
 Canonical Ltd.
 http://juju.ubuntu.com/ - Automate your Cloud Infrastructure

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

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

Re: [Canonical-juju-qa] Cursed (final): #1173 lp:juju-core r2511 (manual-deploy)

2014-03-31 Thread Matt Bruzek

Curtis,

Did the level of Apache change recently on precise?  I saw a problem with
web based charms on the power system because the version of apache2 changed
on trusty and web pages were not enabled properly.  According to the logs
you are using precise, so it may not be the same thing, but something to
consider.


   - Matt


On Mon, Mar 31, 2014 at 7:47 AM, Curtis Hovey-Canonical 
cur...@canonical.com wrote:

 Juju CI has failed r2511 thought r2514.Trunk appears to be broken,
 though CI could also be at fault.

 https://bugs.launchpad.net/juju-core/+bug/1300207

 The tests show that the wordpress charm failed to present a web page.
 Juju status reports there was nothing wrong with juju or the charm. We
 have no logs for the failure.

 Aaron will capture some logs of what is wrong and investigate issues
 with CI. Can someone investigate Juju?

 Juju 1.18.0 will be based on r2510 if this bug is not fixed in time.


 -- Forwarded message --

 Build: #1173 Revision: lp:juju-core r2511 Version: 1.17.8

 Failed tests
 manual-deploy build #210

 http://ec2-54-84-137-170.compute-1.amazonaws.com:8080/job/manual-deploy/210/console



 --
 Curtis Hovey
 Canonical Cloud Development and Operations
 http://launchpad.net/~sinzui

 --
 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: I WANT YOU, to give me your feedback (Juju docs!)

2014-03-21 Thread Matt Bruzek

I have contributed to the Juju documentation and the process was harder
than the format.

Another vote for Markdown from me.

If we truly want contributions from the community we should keep the
barrier of entry low. It is written somewhere in the docs that people can
and should contribute to the Juju documentation.  The Juju community
already needs to know markdown for the README.md files in the charms, so it
makes sense to use the *same* format for the docs.

   - Matt Bruzek


On Fri, Mar 21, 2014 at 12:47 PM, Marco Ceppi marco.ce...@canonical.comwrote:

 Hi everyone,

 I'm spreading this email out across the juju-core, juju, and juju-gui list
 to start a discussion about the next format for the docs. Currently, I've
 worked on a proof of concept to converting the docs to Markdown and it's
 going really well. Using python-markdown with a few custom plugins to
 handle the unique user friendly features the docs provide.

 However, I wanted to get feedback on the choice of formatting. Markdown
 has quickly become the choice of formatting for new projects, it's used
 heavily on the StackExchange network as well as Github. It's even a
 recommendation for the charm README files and charm-tools creates a
 Markdown template for use. Finally, it bares similarities to RST but tends
 to be more forgiving and require less syntax to use.

 To quote the John Gruber, Markdown creator:

  While Markdown's syntax has been influenced by several existing
 text-to-HTML filters, the single biggest source of inspiration for
 Markdown's syntax is the format of plain text email.

 This low barrier of entry is likely one of the reasons it's grown in
 popularity over the years.

 I'm curious of people's opinions, do you support this move to Markdown? Do
 you have other formats for docs in mind and if so reasons that style
 instead? After some time I'll consider the responses, for and against, as a
 poll for which language to move the docs to as I finish my conversion

 Thanks,
 Marco Ceppi

 --
 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: github code reviews

2014-03-07 Thread Matt Bruzek

Hi Nate,

We used ReviewBoard at my last area and all the developers really liked the
tool.  It was very easy to review, and comment on code.

ReviewBoard ( www.reviewboard.org ) allows in-line comments and according
to the web page works with Bazaar and Git.

I found the interface very clean and easy to understand.

   - Matt


On Fri, Mar 7, 2014 at 3:07 PM, Nate Finch nate.fi...@canonical.com wrote:

 I like github.  I don't like in-line diffs and one email per code review
 comment, which is all github provides.  So I did a quick google, and this
 came up:

 https://review.gerrithub.io/#/c/2160/2/roles/packstack/rdo/tasks/main.yml


 it looks pretty good.   http://gerrithub.io/

 --
 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: AWS Request Rate

2014-02-20 Thread Matt Bruzek

Hello David,

When I first read your email, it reminded me of a bug (
https://bugs.launchpad.net/juju-core/+bug/1279879 ) that I opened where I
got the error message: Maximum number of attempts (3) reached sending
request...  but upon further review your problem appears to be a different
issue.

- Matt



On Thu, Feb 20, 2014 at 9:02 AM, David Britton
david.brit...@canonical.comwrote:

 Hi Juju Folks --

 I've been getting this from time to time:

   2:
   agent-state-info: '(error: cannot set up groups: Request limit
 exceeded. (RequestLimitExceeded))'
   instance-id: pending
   series: precise

 Which lead me to this:


 http://docs.aws.amazon.com/AWSEC2/latest/APIReference/api-error-codes.html

 Which says this:

   Amazon EC2 API requests are throttled to help maintain the performance
   of the service. If your requests have been throttled, you'll get the
   following error: Client.RequestLimitExceeded. For more information, see
   Query API Request Rate in the Amazon Elastic Compute Cloud User Guide.


 Some questions:

 1) Is there something I can do to prevent this?  I'm deploying a stack
 with juju-deployer.

 2) When it happens, it seems that juju is dead in the water on that
 operation (in this case launching an instnace).  Should it instead
 throttle back and keep trying?  I have to terminate-machine,
 destroy-service, and re-run deployer (which thankfully picks up where it
 left off).  Is that expected behavior for the juju system?

 3) This is a shared Amazon account, is this requestLimit across all of
 the people that have api credentials, or just me?


 Thanks!

 --
 David Britton david.brit...@canonical.com

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




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

Re: Removing strict type-validation for string/int type configuration options (None is good!)

2014-02-10 Thread Matt Bruzek

Hi Marco,

I have actually run in to this problem before you have my +1 for this!

- Matt


On Mon, Feb 10, 2014 at 8:49 AM, Marco Ceppi marco.ce...@canonical.comwrote:

 Hi all,

 Currently, one of the proof requirements within charm-tools is that all
 configuration options must have a default key with a matching type value
 for that key.

 Most notably, some charms omit the default key and use strict None/NULL
 checking within the charm.

 In order to statisfy this proof rule, which is currently a WARNING level
 (meaning it does not interrupt juju operation, but can affect tools within
 the ecosystem), we've taken to adding `default: ` to these missing keys.
 The reason being we had no way previously to set a None/NULL type value via
 the command line.

 Given that we now have the ability to do so via `juju unset` I'd like to
 propose we drop the requirement of having strict type checking and allow
 None/NULL as a valid configuration default for both string and int types
 (but not bool). In doing so we will still require you have a default: key
 present but it set to an appropriate value of either a value of the type
 the configuration is OR None/NULL[0]

 A WARNING will still be raised if no default key is present or if the
 default key is not the type the configuration option expects (and in the
 case of string or int, also not NULL/None)

 Looking for some +1's or feedback on this policy change, hoping to get it
 released in the next version of charm-tools.

 Thanks,
 Marco Ceppi

 [0]: http://yaml.org/type/null.html

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




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

95 matches

Mail list logo