Re: Migrating charmhelpers to github

[Charles Butler]

+1 from me as well.

I'll take webhook automation for the win, Alex.

All the best,

Charles

On Thu, May 25, 2017 at 7:58 AM James Page  wrote:

> Hi Charmers
>
> There has been a bubbling undercurrent of desire to move charmhelpers code
> hosting out of bazaar on Launchpad to git on github,com alongside other
> charm ecosystem development tooling.
>
> I'd like to get the code migrated over ASAP and then we can start enabling
> automatic PR testing and suchlike which we lack in LP at the moment.
>
> Anyone got any objections?
>
> This will of course impact anyone currently syncing charmhelpers into
> their charm, but that's not a hard problem to solve.
>
> Cheers
>
> James
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: My beginners experience of juju charm development

[Charles Butler]

Thank you so much for the detailed view into your journey and sharing this
feedback Erik.

Things like this will go far to help us improve our community resources. I
offer no excuses, only empathy that I understand where you're coming from.
As a 3 year veteran of the Juju ecosystem, I too felt this pain in the
early days. It got better, but we can certainly improve this experience,
and many of your suggestions are solid thoughts we've had on our side as
well. There's a big overlap between where you wish us to go and where we
want to be.

I'll make sure additional eyes make their way to the list to see this
detailed write-up.

Thanks and all the best,

lazyPower

On Thu, May 11, 2017 at 1:48 PM Erik Lönroth  wrote:

> Hello!
>
> I've been trying to become friends with juju for the last month or so and
> was asked in the #juju IRC channel on Freenode to share my experiences from
> a "beginner perspective on juju charming".
>
> Generally, I believe JuJu is a great concept. I makes alot of sense and
> the architecture and "thought" gone into the tool is impressive.
>
> BUT:
>
> Having some 10+ years in programmer/sysadmin/linux - I think the high
> learning curve of developing charms is a problem. Frankly, without the help
> from the guys in the IRC-channel - I would have given up a long time ago.
> Let me explain my problems and share my experiences.
>
> 1. The target developers are sysadmins - not programmers.
>
> Most developers new to JuJu charms are likely sysadmins or devops. Likely
> with -limited- amount of programming knowledge or even self taught
> scripters. These professionals are not always deep in with advanced
> development concepts like "interfaces", "stubs", "layers", "reactive",
> "hooks" etc.
> The need for a clear path in how to learn juju charming is critical
>
> 2. The documentation site really need some love and thought.
> A) Where are the tutorials?
> B) What is the "flow" of reading the documentation? What is the intended
> purpose and audience? At the moment its a mix between references,
> commercial, examples and feels just like some place you go to NOT really
> find what you are looking for. Perhaps split the content into developer
> sites, user sites, tutorial sites or something like that.
>
> I'm better off reading blogs trying to figure out what goes on in juju.
>
> 3. There are no "best practice" available for common tasks.
>
> Developing a simple useful charm today requires you to cover alot of
> ground before you even can produce your first "hello-world" charm. Concepts
> like "interfaces", "reactive programming", "layers" and juju-state-stuck
> debugging needs to be understood well before you write a decent charm. This
> would normally be OK if there was a extremely good, documented, examples -
> using a set of "best practices" clearly available to developers. Offcourse
> there are, but those are only known by the "elite developers" in the IRC
> channels.
>
> Beginners like me, have to learn these best-practices by either:
>
> A) Dwell in the IRC for extensive periods of time and have the courage to
> ask.
> B) Fight with the juju documentation and figure out "my own
> best-practises".
> C) Google and reading multiple of blogs with "others best practices" and
> selecting what ever works for you.
>
> In this process, I found myself getting confused over "old ways of doing
> things" and whatever new concepts was king today. As a beginner - I can't
> figure out if I was doing things wrong, or if juju was just volatile by
> nature. I'm still partially there...
>
> Quoting from #juju:
>
> "We've refactored our charms couple times after we got something working..
> First it was just bash that was run through Juju hooks And after getting
> comfortable with reactive we rebuilt everything from scratch using reactive
> only"
>
> 3. Reactive programming is great, but not intuitive.
>
> As I understand from some blogs, reactive programming is the way juju is
> transcending into (or already has?). It seems to make sense for most
> experienced charmers, but how about beginners?
>
> When I was starting to develop my first "hello-world" example charm. I
> used only hooks, which quickly got me to a working example. Happy thinking
> I was on the right track, I then discovered  I needed to "relearn/redo" all
> my knowledge because "reactive" was "the real" way of doing charms. Bump.
>
> So, taking on a new challenge on relearning that naturally got me into
> deep holes mixing these concepts up (hooks vs reactive) and not using them
> properly and leading up to new challenges and messy code. To make things
> even worse, I learned just today that in certain cases, these concepts are
> mixed up "deliberately"/"by design". Getting through all this is a hard
> task.
>
> Now, I want to be clear that I'm not criticising juju as such here. My
> message  is that the success of juju is highly dependent on the
> availability to clear paths through difficult terrain. A multitude of

[ANN] Kubernetes 1.6.3 snaps available in the edge channel for testing

[Charles Butler]

We’ve just published a new revision of the Kubernetes snaps in edge.

This includes the latest upstream release of Kubernetes for 1.6.


For those looking to upgrade from 1.6.2 or an earlier version of the snaps
this can be performed with the charms:


juju config kubernetes-master channel=1.6/edge

juju config kubernetes-worker channel=1.6/edge



We expect these snaps to be drop-in upgrades in the current charms. If you
find bugs or issues we’re ready to receive bug reports at the issue
tracker:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues


This is not recommended for production clusters until the snaps have been
promoted to the stable channel, this is for early adopters seeking
features/fixes in the latest releases of Kubernetes. A stable release
communication will follow soon, and that will indicate the version has been
verified to pass our internal testing and is ready for production usage.


Finally, if you're operating Kubernetes or using Kubernetes feel free to
reach out: kuberne...@ubuntu.com


Thanks and all the best,


- The Canonical distribution of Kubernetes team


-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Normalizing output dir for charm build

[Charles Butler]

I am +1 on this effort.

Lets drop dead code paths for juju 1.x and push forward with Juju 2.x
standards.

Constantly dancing the dance of convention over configuration feels like
we've lost sight of simplification and making things simpler is always
welcome in my book.

 / my two cents

All the best

On Wed, May 10, 2017 at 1:03 PM Cory Johns  wrote:

> Started on https://github.com/juju/charm-tools/pull/320, I'd like to
> bring this discussion to the list.
>
> The output directory for charm build can vary in seemingly unpredictable
> ways depending on how it is called, the environment, and the charm's
> metadata.yaml contents.  This is due to historical reasons, primarily with
> how Juju 1.x worked and how charm paths worked prior to the advent of
> multi-series charms.  However, now that 2.x and multi-series support are
> standard, I would like to push for simplifying the output directory, based
> on Merlijn's PR.
>
> Specifically, I'd like to push for the following changes:
>
> * Drop the series portion of the output directory (we recommend providing
> the series in the charm's metadata, making it redundant in the path).
> * Drop the "builds" portion of the output directory (that was mainly to
> distinguish it from the series portion).
> * Drop the current directory as a fallback option for the output directory
> (it causes more confusion than it saves).
>
> Thus, charm build would always require an output directory to be given
> either via --output-dir (-o) or via the $JUJU_REPOSITORY environment
> variable, and would always put the built charm in $output_dir/$charm_name
>
> Obviously, this is not backwards compatible, and may affect automated
> build systems, but I think it would be easy to adjust for and simplify
> things for everyone concerned.
>
> Thoughts?  Objections?
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Proposing Alex Kavanagh for ~charmers

[Charles Butler]

I for one, cast my +1 vote

It's been great working with tinwood regarding charms, layers, and reactive
2.0. His reviews have been on point and his helpful hand with the community
has been a pleasure to witness.

All the best,

Charles



On Wed, Apr 26, 2017 at 4:52 AM James Page  wrote:

> Hi Charmers
>
> I'd like to propose Alex (tinwood) for membership of charmers; he's worked
> extensively across the OpenStack charms, providing valuable reviews to the
> rest of the team, has been reviewing charm-helpers updates and has been
> instrumental in the OpenStack charms use of reactive and layers for
> building newer charms.
>
> He's also working as part of the team for Reactive 2.0.
>
> I think he'll be a valuable addition to the core charmers team!
>
> Cheers
>
> James
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Check out the openvpn charm form the tengu team

[Charles Butler]

> I think that Chuck was looking to have a relation available. In this way
you could tunnel traffic from an application across the VPN perhaps? In the
world of cross model relations, it might enable folks to wire traffic
across clouds/DC in some interesting ways.

This is precisely what I was looking for. One easy example I thought of, is
you could say deploy an SDN on the OpenVPN charm, and it would then inherit
that SDN topology as an accessible network. This would aid in secure access
to applications without requiring an ingress declaration in kubernetes for
example.

Sort of like an intranet running in the cloud, that's only available if
you're participating in the network segment, but also has implications when
debugging applications without having ssh access. You connect up to the VPN
and start the network debug session. It would be a more robust solution
than the current implementation of 'kubectl proxy'.

This isn't new, and there's a few early solutions in the kubernetes
community that leverage different VPN services. I think the idea of having
it available across the board to any Juju deployment makes it slightly more
powerful in that it lives on your infra level, not as a workload in the k8s
stack. But that's just a preference.

Great work on the charm Tengu team :)


On Fri, Apr 14, 2017 at 8:56 AM Rick Harding 
wrote:

> The delivery of the config files is interesting. There's nothing planning
> in the gui at the moment for this. It's kind of an inverse "resources" idea
> where you are building artifacts in the charm that you want clients to be
> able to get access to. It's an interesting concept. It's a bit like actions
> that generate a backup file or the like. The action can build the backup
> and tell you where on disk it is, but then you need to juju scp it down. I
> wonder if there's a specific action type that generates artifacts and then
> there's a followup plugin/helper that automates the juju scp step for you
> in a some nice way.
>
> I think that Chuck was looking to have a relation available. In this way
> you could tunnel traffic from an application across the VPN perhaps? In the
> world of cross model relations it might enable folks to wire traffic across
> clouds/DC in some interesting ways.
>
>
>
> On Fri, Apr 14, 2017 at 9:47 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Thanks for the post!
>>
>>
>> I'd really like to integrate this Charm more with JaaS. I'd like to give
>> JaaS users the ability to download the client config files from the Juju
>> GUI. Any idea if that's something that's being worked on?
>>
>> @chuck: I just watched the Juju show, what was the feature you were
>> talking about?
>>
>>
>>
>> Kind regards
>> Merlijn
>>
>> 2017-04-13 16:35 GMT+02:00 Rick Harding :
>>
>>> I wrote up a quick blog post [1] as I was tinkering with VPNs and the
>>> OpenVPN charm [2] from the Tengu team is really nice and easy. It also does
>>> some great work using metrics in Juju to output operational data. Running
>>> juju metrics --all will show you how many clients are connected on each
>>> unit. If you're a charmer, it might give you some new ideas for exposing
>>> internal data in a really nice standard way.
>>>
>>> I just wanted to highlight it as something really useful for folks if
>>> you've ever found yourself wishing you had a VPN around somewhere.
>>>
>>> 1:
>>> http://mitechie.com/blog/2017/4/12/three-reasons-you-need-to-keep-a-vpn-in-your-pocket
>>> 2: https://jujucharms.com/openvpn/
>>>
>>> Rick
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>> --
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] Elastisys Charmscaler Promulgated!

[Charles Butler]

Greetings,

I realized last week I had completed a review and failed to send an update
to the mailing list. As some of you may have heard on the Juju Show that
Elastisys released their Charm Scaler to the promulgated channel.


This was an easy +1 from me, with comprehensive test suites, and example
cases for auto-horizontal-scaling workloads based on CPU load.

https://jujucharms.com/charmscaler/

This particular charm is near and dear to my own interests, as they have
published a POC bundle using Canonical Distribution of Kubernetes as the
subject matter. Enjoy horizontally scaled workers when you reach node
pressure thresholds on CPU.

https://jujucharms.com/u/elastisys/autoscaled-kubernetes/0

Congratulations on your promulgation status to our friends at Elastisys!  I
look forward to seeing the bundles this charm unlocks the auto-scaling
goodness thanks to tight integration with Juju.

All the best,

Charles
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Etcd Charm (Snaps, 3.x, migrations) pushed to edge channel today

[Charles Butler]

Greetings,

Its been a busy couple of weeks for me evaluating the new snap format of
etcd. A lot of great things are incoming thanks to this early work in terms
of integration. We've shaken out some bugs in the layer. I'm ready to get
some early community feedback by any consumers of etcd.

juju deploy etcd --channel=edge

or

juju upgrade-charm etcd --channel=edge

There's a migration path outlined in the README  - which will help any
users currently deployed on 2.2.5 and how they can move to 2.3 => 3.0 =>
3.1 - all in place, all migrated safely with snapshots happening along the
way to ensure data consistency at the end and a recovery path if not.

*This is not recommended for production clusters as of yet*, this is early
access to invite community members to trial and help identify potential
issues before a GA release in the coming weeks. I'm leaving the
instructions in this mail intentionally brief to encourage users to go bang
on it and find code paths I haven't fully tested and get those issues filed
and squashed before release.

To anyone curious how I've been testing this in an automated fashion:


Note: the following presumes you have juju-wait plugin installed and the
petname package. I've been testing this regularly with a script that looks
similar to the following:


#!/bin/bash
set -e

juju add-model $(petname)
juju deploy cs:~containers/easyrsa
juju deploy cs:etcd
juju add-relation etcd easyrsa

echo "Waiting on model convergence..."
juju-wait

juju upgrade-charm etcd --switch cs:etcd --channel=edge
juju-wait
echo "Running snap upgrade"
juju run-action etcd/0 snap-upgrade
juju-wait

# Stepped upgrades
juju config etcd channel=3.0/stable
juju-wait

# stepped upgrades
juju config etcd channel=3.1/candidate
juju-wait

juju run --application etcd "/snap/bin/etcd.etcdctl cluster-health"
juju run --unit etcd/0 "/snap/bin/etcd.etcdctl ls -r /"


This deploys the existing stable channel, upgrades using the edge channel
and then moves between channels, with the final output being cluster health
and listing of any data in the etcd data store.  This is a very specific
path, and hence why I'm asking for more hands to help test.

Thanks and all the best,

Charles

-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
conjure-up canonical-kubernetes | jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju2 behind proxy

[Charles Butler]

Greetings Vladimir,

As an author of the Canonical Distribution of Kubernetes charms I'm curious
which connection attempts were blocking you. We've taken great care with
respect to ensuring the charms will work in an offline environment. Our
last hold-out issue was with the docker images. Docker just simply doesn't
respect the system level proxy variables and necessitated an additional
level of configuration on the charms to pass this through.

Could you perhaps retry the deployment in your limited egress env and pass
the proxy values to the kubernetes-worker charm?

juju config kubernetes-worker http_proxy=http://my.proxy: https_proxy=
http://my.proxy: no_proxy=10.0.0.1

as a basic example of what you would issue to the charm to configure the
container runtime engine proxy variables. Sub the proxy config values as
appropriate.

I'm open to better methods to do this, which I think we can get committed
in short order, such as reading from the system level variables and then
re-render the systemd template with those exported.  (thanks for the idea!)

However, until such a time that we have that reworked, I'm highly
interested in if there were other blocking factors in your setup.

Thanks and all the best,


On Mon, Feb 20, 2017 at 4:26 AM Vladimir Burlakov  wrote:

> Hi Mark,
> Some thoughts/tests on how charms works after/in deployment state in proxy
> environment, f.e in deploying Kubernetes charm we stuck, cause application
> trying to connect to public http/s servers without proxy,  and it not reads
> system settings for proxy .. so maybe there (in juju) should be an option
> to redirect all (or well known, such as http/https/ftp) connection to
> outside through juju controller using it as gateway or through proxy
> itself?!
> Or am I mistaken and this option is already there? :)
>
> Thanks,
> Vladimir
>
>
> > 10 февр. 2017 г., в 9:07, Mark Shuttleworth 
> написал(а):
> >
> > On 09/02/17 12:27, Vladimir Burlakov wrote:
> >> Hi Guys,
> >> Thank you a lot, it’s worked, you really helped me. :) as said my
> >> friend:  "community - is the power !"
> >
> > :)
> >
> > Welcome aboard, Vladimir!
> >
> > One question - are we good about passing this proxy information on to
> > the various machines that get spun up? Ubuntu, CentOS, Windows etc all
> > have ways to use proxy info, and I'm interested in whether we rigorously
> > pass this to them via cloud-init.
> >
> > Mark
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [lxc-users] Kubernetes Storage Provisioning using LXD

[Charles Butler]

Greetings,

The TL;DR - we don’t fully support this today, but are cycling towards a
resolution. I would love to have your thoughts/requirements added to the
bug listed below.

I've given this thread some thought and you're encountering an edge that we
haven't thoroughly tested. We do have a desire to enable developers to
properly model their workloads in kubernetes running on LXD just like they
would on a cloud.  This thread was started by the conjure-up folks:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/202
that somewhat explores the initial thoughts on this work.

I spent about an hour diving into the Ceph integration path we have already
completed to see if it is a viable option, but my results were not
successful, and reproduction seems to be order dependent. This is not an
ideal solution.

What I can say is that we are aware of this limitation, and would love to
enable this. We’re looking towards a lighter weight solution (like gluster
or nfs) for the initial enablement on local development setups.

I’ll include those links and a bit of instruction from my Ceph hacking for
further reading material just in case you feel like diving in and hacking
on that vector:

Solving for RBD Mount/Format permissions denied

https://github.com/lxc/lxd/issues/2709

Install ceph-common on the host

apt-get install ceph-common

Next step would be to stand up CDK

conjure-up canonical-kubernetes

Evaluate the nova-lxd lxd profile for kernel modules and escalated security
on the container.. Yielding a less secure lxd container in this
configuration, but more operability in this context:

https://github.com/conjure-up/spells/blob/master/openstack-novalxd/steps/lxd-profile.yaml

Specifically, you're going to need to add some whitelisted modules, set the
container to privileged, and add the rbd devices (min + major - found via
lsblk /dev/rbd# - order dependent, as the device has to exist first)


(note, I'm using the snap so my commands will be prefixed with lxd. to
scope the request to the snap bins, this may be divergent from your
commands which will just be native lxc profile show, and so on)

$ lxd.lxc profile show juju-storage-test

config:

 boot.autostart: "true"

 linux.kernel_modules: openvswitch,nbd,ip_tables,ip6_tables,netlink_diag,rbd

 raw.lxc: |

   lxc.aa_profile=unconfined

   lxc.mount.auto=sys:rw

 security.nesting: "true"

 security.privileged: "true"

description: ""

devices:

 root:

   path: /

   type: disk

name: juju-storage-test



Once the deployment has converged and it’s pulled down your credentials,
you're ready to deploy Ceph and start enlisting OSD's (using the file
storage type)

# note: you will indeed need 6 total lxd containers to run the ceph
service. 3 mons for quorum, and 3 osd’s to ensure your cluster health. I
tried with one and this failed.

juju deploy ceph-mon -n 3

juju deploy ceph-osd -n 3

juju add-relation ceph-mon ceph-osd

juju config ceph-osd osd-devices=/srv/ceph-osd use-direct-io=false

Juju add-relation kubernetes-master ceph-mon

Juju run-action kubernetes-master/0 create-rbd-pv name=testpv size=50


-- this is where things failed for me with regard to either unable to mount
the RBD due to it thinks there’s a mounted filesystem on it (I presume
watchers were to blame)



Cited sources for the answers:

Nova-lxd bundle configuration for ceph units

https://github.com/conjure-up/spells/blob/master/openstack-novalxd/bundle.yaml#L60-L76

Enable loopback storage support on the localhost provider for Juju
(unreferenced)

https://github.com/juju/docs/issues/1665


cholcomb, and icey on #juju on freenode (storage engineers)

stokachu and lazypower on #juju on freenode (kubernetes engineers)
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Create Juju Charms from your browser!

[Charles Butler]

And charmbox makes an appearance! Great work merlijin! I'm looking forward
to giving this a spin.
On Fri, Feb 3, 2017 at 8:06 PM Antonio Rosales <
antonio.rosa...@canonical.com> wrote:

>
>
> On Feb 3, 2017 7:08 PM, "Junaid Ali"  wrote:
>
> Great. Thanks Merlijn for sharing.
>
>
> +1 and juju deployable to give it a quick spin too, nice work.
>
> -Antonio
>
>
> -- Junaid
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] ODOO, ZNC, Dokkuwiki, ibm-platform-symphony-master, ibm-http

[Charles Butler]

Greetings!

The ~containers team took a stroll through the review queue today and
reviewed several submissions. We had some findings and the full report can
be found below:

ZNC Charm Review: (Disapprove Vote)

By @cynerva

Had a look through the ZNC charm submitted by adam-stokes. The charm looks
to be in great shape overall, but currently has an issue where the charm
doesn’t expose the port used by ZNC, so for the time being I had to give it
a -1. Once that is resolved I think we’ll be good to go.

https://review.jujucharms.com/reviews/24?revision=173


Dokuwiki Charm Review: (Disapprove Vote)

By @ryeterrell

This charm is looking quite good. Had to give it a -1 for now because of
the port exposure issue.

https://review.jujucharms.com/reviews/22?revision=127


Ibm-platform-symphony-master (Abstain vote)

By @mbruzek

Did another review of this charm, needs homepage and bug-url set along with
addressing old review comments.

https://review.jujucharms.com/reviews/15

Ibm-http (Disapprove -1)

By @mbruzek

Has a test term “lorem-ipsum” in the list, need to remove and repush this
charm without the test term.

https://review.jujucharms.com/reviews/33

IBM-HTTP (Disapprove -2)

By @lazypower

There were a few issues here regarding zero byte resources, html entites in
the readme, and a few suggestions to improve user experience around
deploying this charm, (such as the use of min-juju-version in the metadata,
and using proper terms as called out by mbruzek)  -1 at this time.


Odoo Charm Review:   (Abstain Vote)

By @lazypower

Did another review of the Odoo charm submission by mistoebe. The charm has
been vetted quite well, and only has one remaining blocking bug regarding
its automated testing suite. There is an open pull request, which I briefly
touched to keep contact alive and bump it in their notifications. Pending
that PR acceptance, I have to abstain for now.

https://review.jujucharms.com/reviews/23?revision=50


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com
Conjure up Kubernetes: `conjure-up canonical-kubernetes` on any ubuntu
install with Conjure and Juju.
-- 
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.2

[Charles Butler]

We’re proud to announce support for Kubernetes 1.5.2 in the Canonical
Distribution of Kubernetes. This is a pure upstream distribution of
Kubernetes, designed to be easily deployable to public clouds, on-premise
(ie vsphere, openstack), bare metal, and developer laptops. Kubernetes
1.5.2 is a patch release comprised of mostly bugfixes, and we encourage you
to check out the release notes

.

Getting Started:

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

sudo apt-add-repository ppa:juju/stable
sudo apt-add-repository ppa:conjure-up/next
sudo apt update
sudo apt install conjure-up
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
 for
localhost-specific considerations.

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/juju-solutions/bundle-canonical-kubernetes

How to upgrade

With your kubernetes model selected, you can deploy the 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

or

juju deploy kubernetes-core

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
tweaks, but can be modified to work for your deployment.

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.2
release of the Canonical Distribution of Kubernetes.
New features:

   -

   Full support for Kubernetes v1.5.2.


General Fixes

   -

   #151
   
   #187
   

   It wasn’t very transparent to users that they should be using conjure-up
   when locally developing, conjure-up is now the defacto default mechanism
   for deploying CDK.
   -

   #173
   
   Resolved permissions on ~/.kube on kubernetes-worker units
   -

   #169
   
   Tuned the verbosity of the AddonTacticManager class during charm layer
   build process
   -

   #162
   
   Added NO_PROXY configuration to prevent routing all requests through
   configured proxy [by @axinojolais ]
   -

   #160
   
   Resolved an error by flannel sometimes encountered during
   cni-relation-changed [by @spikebike ]
   -

   #172
   
   Resolved sporadic timeout issues between worker and apiserver due to nginx
   connection buffering [by @axinojolais ]
   -

   #101  Work-around
   for offline installs attempting to contact pypi to install docker-compose
   -

   #95 Tuned
   verbosity of copy operations in the debug script for debugging the debug
   script.


Etcd layer-specific changes

   -

   #72  #70
    Resolved a
   certificate-relation error where etcdctl would attempt to contact the
   cluster master before services were ready [by @javacruft
   ]


Unfiled/un-scheduled fixes:

   -

   #190
   
   Removal of assembled bundles from the repository. See bundle
   author/contributors notice below


Additional Feature(s):

   -

   We’ve open sourced our release management process scripts we’re using in
   a juju deployed jenkins model. These scripts contain the logic we’ve been
   running by hand, and give users a clear view into how we build, package,
   test, and release the CDK. You can see 

Re: What's with all the test talk? (aka, give me CI already)

[Charles Butler]

I think it would be best to reserve "auto publishing" to the edge channel.
That's exactly what edge is for, to receive the latest builds from whatever
process you are automating with the least amount of impact to existing
installations.  From there it's simple to promote the charm through the
channels.

This leaves the "lever pulling" to a manual process of a human once the
application has been properly vetted and QA'd. You could reasonably set
this up so edge is always possibly broken, but if the tests pass, it goes
into Beta/RC appropriately. (If you're installing from edge, you agree to
file bugs and deal with the shenanigans right?) Examples below:


charm release cs:~wethecharmers/mything-404 --channel=beta
and so on..


and of course, only push to --stable once you've verified that both
forward-looking upgrades work as expected, and it's so stable it's boring.

charm release cs:~wethecharmers/mything-404 --channel=stable

My 2 cents. All the best.


Charles


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Mon, Dec 12, 2016 at 6:38 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> I'm just not sure what the best approach would be. My idea is that our CI
> system will push directly to stable. However, I think it's best if the
> charms are only pushed to stable when both the Charm tests and bundle tests
> succeed. So maybe after charm tests, the charms are pushed to edge, and
> when the bundle tests succeed both the bundles and the charms are pushed to
> stable?
>
> 2016-12-12 11:17 GMT+01:00 Konstantinos Tsakalozos <
> kos.tsakalo...@canonical.com>:
>
>> This workflow sounds reasonable. One question, why are you using only the
>> edge channel?
>>
>> Thanks
>>
>> On Fri, Dec 9, 2016 at 10:13 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> The workflow that we'd like to have is very similar to what you do with
>>> the charms. The first steps are already possible with `bundle-cwr-ci`:
>>>
>>>- If a new charm version is committed, run the tests of that charm.
>>>- If the tests succeed, push the charm to edge.
>>>
>>> We save our bundles on Github with revision-less charm urls. A push of a
>>> charm to the edge channel should trigger a job that does the ci for the
>>> bundle:
>>>
>>>- Add the latest revision to all revision-less charm urls. (If they
>>>do have a revision specified, leave them be.)
>>>- Run bundletester on the resulting bundle.
>>>- If tests succeed, push the bundle to edge.
>>>
>>> What do you think of this workflow?
>>>
>>> Our workflow in the past was a lot more complex, but moving to MAAS
>>> allowed us to greatly simplify it.
>>>
>>>
>>>
>>> 2016-12-09 5:33 GMT-05:00 Konstantinos Tsakalozos <
>>> kos.tsakalo...@canonical.com>:
>>>
>>>> Hi Merlijn,
>>>>
>>>> Building/testing/releasing bundles from the CI is in our future tasks.
>>>>
>>>> Some time ago you posted on this list a script to update bundles in
>>>> light of charm updates. We will have to take a closer look in the way
>>>> bundles are handled in your case. Any feedback is much appreciated.
>>>>
>>>> Thanks,
>>>> Konstantinos
>>>>
>>>> On Fri, Dec 9, 2016 at 4:52 AM, Merlijn Sebrechts <
>>>> merlijn.sebrec...@gmail.com> wrote:
>>>>
>>>>> This is awesome!
>>>>>
>>>>> >  I have a nasty habit of committing straight to master, so bear with
>>>>> us as development is moving fast at the moment.
>>>>>
>>>>> If only you could have a CI system to test your bundles
>>>>> automatically... ;)
>>>>>
>>>>> 2016-12-08 19:36 GMT-05:00, Kevin Monroe <kevin.mon...@canonical.com>:
>>>>> > Hi Juju!
>>>>> >
>>>>> > From Matrix [0] to Review Queue [1] to Amulet [2] to Charm Author
>>>>> Workflows
>>>>> > [3], you'd think December was the month we all remembered the
>>>>> importance of
>>>>> > software testing.  There are oodles of test tools for
>>>>> charms/bundles, and
>>>>> > if you know about all of them, you're probably putting out
>>>>> thoughtful,
>>>>> > well-tested charms (thanks stub!).
>>>>> >
>>>>> > One thing that

Re: Issues with amulet tests

[Charles Butler]

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

> Ok, any idea where this comes from? I have no idea what tox is and why it
> is in my final Charm. I suspect it comes from a layer. Is there a way to
> backtrace from what layer a file comes from?


`charm layers` spits back a map of what files came from what lower layers
in the charm artifact. You'll need to run that command from the assembled
charm dir however.


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: One instance manual provider

[Charles Butler]

That's one thing I've done as a hacky work-around to this scenario is to
manual provider bootstrap the host as the controller, and deploy everything
but the load balancer to LXD.  colocate haproxy or nginx on the controller
host and viola. You've got a single instance LXD that's reachable by the
world.

But yeah, it's a work-around.


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Mon, Dec 5, 2016 at 11:20 AM, Nate Finch <nate.fi...@canonical.com>
wrote:

> Except you can't expose anything deployed to lxd to the network, right?
>
> On Mon, Dec 5, 2016, 5:49 PM Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
>> A one machine manual provider? Might as well just `ssh ; juju
>> bootstrap lxd`.
>>
>> On Mon, Dec 5, 2016 at 10:09 AM Nate Finch <nate.fi...@canonical.com>
>> wrote:
>>
>> The should be no reason you can't deploy to the controller machine using
>> manual just like any other cloud.
>>
>> juju bootstrap manual/x.x.x.x  mycloud
>> juju switch controller
>> juju deploy  --to 0
>>
>> Switching to the controller model is probably what you were missing,
>> since the default model comes with no machines.
>>
>> On Mon, Dec 5, 2016 at 9:27 AM Rick Harding <rick.hard...@canonical.com>
>> wrote:
>>
>> I'll have to test it out but I would think that you could
>>
>> 1) bring up a machine, create a container on it, bootstrap to that
>> container as the controller, create another container, and then add-machine
>> it as a second machine and things should work ok.
>>
>> 2) I wonder if you can bootstrap to a machine, manually add container on
>> that machine, and then add that container with add-machine.
>>
>> I'm guessing there's some bits about making sure the added containers
>> have the ssh key you want to use for the ssh connection for add-machine.
>>
>> On Mon, Dec 5, 2016 at 3:18 PM Matthew Williams <
>> matthew.willi...@canonical.com> wrote:
>>
>> Hey Folks,
>>
>> I notice the docs state that at least two instances are needed for the
>> manual provider: https://jujucharms.com/docs/stable/clouds-manual. Some
>> quick playing around suggests that this is indeed the case.
>>
>> Is there a technical reason why? I'd love to spin up a charm on [insert
>> vps provider here] and only spend money for one instance
>>
>> Matty
>> --
>> 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
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Feedback from a new charm author

[Charles Butler]

Greetings Dean,

First of all, great feedback. Thank you for posting this to the community
list so others can learn from your experience.

I'll attempt to address your concerns corresponding to the numbers they
were posted under.

1. Centos series charms, I haven't done a lot of work in this department,
but I do know that centos series charms do work, at least, under the
MAAS provider. This should be true for the other cloud providers but I'll
need to confirm with the core devs that this is the case, as centos support
was contributed by our partners over at Cloud Base Solutions.

2. This is a limitation of subordinates, that they must only co-locate with
the same series. You can define a multi-series charm, but once the
subordinate has been related to a series, i believe it will then be locked
to the series it was originally related to. I would need to run a
simulation to disprove that statement, as I haven't gotten my hands very
dirty with multi-series subordinates.

3.  It's expected that the subordinate itself would control the exposing of
the website, as its managing the workload. Any other scenario would need to
be coordinated with the principal charm and the principal charm would have
to perform those actions. It may be obtuse to do it this way, however, as
it's not obvious where the encapsulation begins/ends with this pattern. I'm
happy to take a look if you link the code in question.


4. Removing the entire application bundle does sound like an interesting
idea, but it's not something we've explored to date. I would highly
recommend filing a bug for this functionality so we can discuss it and get
it on the roadmap.

Thanks and all the best,

Charles



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Mon, Dec 5, 2016 at 10:21 AM, Dean Maniatis <dean.mania...@gmail.com>
wrote:

> Hello,
>
> I'm a new charm author trying to learn the basics and decided to start
> with a simple bash template. I'm working on porting netdata
> <https://github.com/firehol/netdata> as a subordinate charm which is a
> lightweight real-time performance and health monitoring tool. On my first 
> charm
> revision <https://github.com/deanmaniatis/netdata-charm> i managed to
> deploy it and test it with Xenial and Trusty both on LXD and AWS. I have
> identified the following challenges/questions and since i couldn't find any
> information from docs i decided to post here. Some maybe more related to
> feature requests than actual questions so please treat the following as a
> mixed feedback from a newbie.
>
>
> 1. How to test centos7 series? The upstream developer has put a lot of
> effort to support all major Linux distributions but i can't seem to be able
> to find any information regarding "charming" in regards with Centos7. After
> some quick research it seems that currently centos7 image is not supported
> in either AWS or localhost provider
> <https://bugs.launchpad.net/juju/+bug/1495978>. In addition, it seems
> there are no centos7 charms to look into their code nor even a simple blank
> centos7 charm to be used as a sandbox (similar to the ubuntu charm).
>
> 2. When i first deployed my subordinate charm i couldn't figure why i was
> able to relate it to only to a few charms and not all available on the
> canvas. Later i understood that i have to deploy at least one for each
> series which somehow doesn't provide this really cool user experience of
> application modeling, i.e. deploy a single subordinate charm and during
> relation let the system/charm code handle the intricate details and provide
> meaningful message in case the relation is not feasible, e.g. this charm is
> not supported for this series. There is an informative message when using
> CLI but on the GUI it simply grays out the target charm and it is not
> really clear why that's not possible.
>
> 3. When a subordinate charm enables a new service on the principal charm
> shouldn't that service be listed under the `Expose application` GUI
> section? For example my charm enables a web UI dashboard on port 1 so i
> would expect that to be added to whatever other service is listed under the
> principal charm. I've define this service on metadata.yaml with `provides:
> website: interface: http` and with `open-port 1` on install hook but
> doesn't seem to be working. What am i doing wrong?
>
> 4.I can easily deploy an application bundle with one command but the
> opposite is not available except manually removing each service or
> destroying completely the model. Shouldn't `juju remove kubernetes-core`
> just work?
>
>
> Dean
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju & Mesos

[Charles Butler]

+1

This sounds really interesting. Keep me apprised, please? I'd love to see
if there's some integration work we can do here (on top of the
kubernetes => mesos integration)


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Thu, Nov 24, 2016 at 9:47 AM, Tom Barber <t...@spicule.co.uk> wrote:

> Okay, it transpires some of my Java guys also know C  who knew.
>
> Anyway, they have been tasked with adding LXC/LXD support to Apache Mesos
> which we'll push upstream assuming they want it. My plan is to then extend
> Marathon to support LXD deployments and from that we'll then build a Juju
> provider for Juju 2 to do juju deploy to Mesos. who knows what pitfalls
> lie ahead but work has begun!.
>
> Tom
>
> On Fri, Nov 18, 2016 at 3:31 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> 2016-11-18 15:43 GMT+01:00 Tom Barber <t...@spicule.co.uk>:
>>
>>> You mention stateless, thats fine, but for example, if you have sessions
>>> in a web app, you'd need to share the sessions etc, so autoscaling isn't
>>> really any different to juju add-unit except you've got some stuff to
>>> monitor load and do it without user intervention. Also you'll find the flip
>>> side to the autoscaling argument where nodes could shutdown mid flow or
>>> ditch sessions etc, so whilst Im sure in a lot of places it works great,
>>> you still have to create containers that work properly in a scaling
>>> environment, which is exactly the same as when you design charms :)
>>>
>>>
>> Yes! Kubernetes autoscaling only works for stateless services. These
>> services should connect to an external datastore if they want stuff like
>> sessions.
>>
>> Applications that aren't "cloud-native" can't be autoscaled by Kubernetes
>> because they require more than "spin up another service and connect it to
>> the load balancer and the datastore". They need more complex configuration;
>> configuration that Juju is great at! Kubernetes is great at scheduling,
>> Juju is great at orchestration. Hence Juju + K8s = goodness.
>>
>>
>>> I agree with the image stuff to some extent, certainly I've used that as
>>> a selling point, the flip side of course is, do you run apt-get update when
>>> you start a container? Maybe, but most people won't, what about the latest
>>> security flaws in applications that will go unpatched? It also makes for
>>> complacency .
>>>
>>>
>> The sane way to use Docker is to build the image as part of a CI/CD
>> pipeline. Dev triggers a rebuild when code changes, ops triggers a rebuild
>> to fix security issues. After a rebuild, the ci system tests the image
>> heavily. If all tests succeed, the image gets deployed to production and
>> you are 100% sure that all prod images will be 100% what you just tested.
>> Reproducability so that wat runs in production is exactly what is tested.
>>
>> Although many people think that Docker means "what the dev runs on his
>> machine is what runs in production" which is obviously a bad idea and no
>> technology will fix that.
>>
>> Of course I agree, plenty of large businesses do run their stuff in
>>> docker, I use docker in production, I'm not saying don't use docker :) I'm
>>> just saying that in reality its not the panacea a lot of people who want to
>>> do high volume scale out apps think it is, not without writing a lot of
>>> code around it for your own solution :)
>>>
>>> On Fri, Nov 18, 2016 at 2:34 PM, Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
>>>> I'm mostly working with researchers and people developing early
>>>> prototypes. I can't blame them for using technologies that aren't
>>>> production ready. That said, I attended pragmatic docker days a while back
>>>> and there were some companies, like Yelp, who found a good way to run
>>>> Docker in production so it is possible, given you have a boatload of good
>>>> ops people.
>>>>
>>>> Big Data Europe <https://www.big-data-europe.eu/> seems to be going
>>>> towards Docker containers for scalable Hadoop setups
>>>> <https://www.big-data-europe.eu/scalable-sparkhdfs-workbench-using-docker/>.
>>>> Not that it's a production ready setup, but with a name like that and H2020
>>>> funding, we (big data researchers) can't really ignore them...
>>>>
>>>> Juju is awesom

Re: conjure-up Canonical Kubernetes in LXD

[Charles Butler]

This deserves a ton of fanfare. Let's celebrate this win by circulating
this like crazy.

I've already retweeted this evening and plan on following up again tomorrow
during normal business hours.  Great work Stokes on completing this
herculean task. The ~containers team, appreciates the effort that went into
this, and the collaboration across our teams.

Go team!



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Thu, Nov 17, 2016 at 5:51 PM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> Just pulled in changes to support deploying The Canonical Distribution of
> Kubernetes on the localhost cloud type.
>
> I've blogged about it here:
>
> http://blog.astokes.org/conjure-up-canonical-kubernetes-under-lxd-today/
>
> Please give it a shot deploy some workloads on it and let us know how it
> goes.
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Canonical Kubernetes charm Release Notes - week ending 11/18/2016

[Charles Butler]

Greetings Kubernauts and charm aficionados alike.

We've been cycling so hard we actually forgot to post release notes on the
last release of the Kubernetes bundles. I apologize for that, as it's been
a busy couple weeks with Kubecon, a lot of end-user engagements in IRC, and
future forward work.


Without any further adieu, here's the goodness that just landed in the
charm store as of today (and some last week, whoops!):


Etcd

   -

   Added snapshot/restore actions. This enables operators to snapshot and
   clone a running Etcd cluster. This is useful during version migrations, and
   restoring from a broken state.


Thanks @rimusz for requesting and piloting this feature in the edge channel.

https://github.com/juju-solutions/bundle-canonical-kubernetes/issues/126


   -

   Updated the Readme with snapshot/restore instructions
   -

   Stripped the (leader) identifier from status messages in favor of the
   asterisk
   -

   Python fixes for flake8 version 3.2.x
   -

   Added Juju Storage so the WAL and Data files may now be stored on a
   cloud provider persistent disk in the event of disaster recovery



Kubernetes-master


   -

   Updated kubernetes resource to version 1.4.5


   -

   Updated addon templates for kube-dns and kubernetes-dashboard
   -

   Updated README to bring up-to-date with recent changes
   -

   Added a `charm build tactic` to copy/rewrite manifests from the VCS
   system instead of maintaining forks


Kubernetes-worker


   -

   Updated kubernetes resource to version 1.4.5


   -

   Fixed microbot action failing when replicas param is omitted
   -

   Fixed a temporary hook failure involving premature deployment of the
   ingress controller
   -

   Added config option to set node labels for a deployed group of workers
   -

  Thanks @rimusz for requesting this feature.



Kubernetes-e2e (conformance/testing apparatus.)


   -

   Added support for running e2e tests in parallel. This is the new default
   behavior.


   -

   Added junit output to results
   -

   Updated charm icon for consistency
   -

   Fixed a bug when deploying with no resource
   -

   Fixed a bug when upgrading the e2e resource
   -

   Removed excess paths from the result archives


Special thanks to @rimusz for working with us to improve the operations.
Thank you to @mbruzek, @chuckbutler, @wwwtyro, and @cynerva for all the
assistance on this release.




Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Elastic Stack Charmer Planning - 11/15/2016

[Charles Butler]

Oops, Missed the document attachment.  The meeting agenda/notes will be
here:

https://docs.google.com/document/d/1Aq7JfAVZWoT2IAQGsR3UWGWO6wUka2ztvB0hLbwPy2Q


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Wed, Nov 9, 2016 at 10:04 AM, Charles Butler <
charles.but...@canonical.com> wrote:

> Greetings Everyone,
>
> In an effort to divide the labor, openly plan, and move the elastic stack
> charms forward post 5.0 release I've scheduled a meeting on *11/15/2016
> at 10AM PST*. If you are a consumer of our charms in the following list,
> this meeting is for you:
>
> - Elasticsearch
> - Kibana
> - Beats
> - Logstash
>
> I've also created a planning document for the session so anyone who is
> unable to attend can at least view the meeting agenda, and minutes from the
> meeting. This will be a very informal session, and was scheduled with an
> overlap in UK/PST time zones to catch two of our very active charmers in
> the data science field.
>
> If you're interested in attending, please send me an email and I'll get
> you on the calendar invite.
>
> Thanks and all the best,
>
> Charles Butler <charles.but...@canonical.com> - Juju Charmer
> Come see the future of modeling your datacenter: http://jujucharms.com
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Elastic Stack Charmer Planning - 11/15/2016

[Charles Butler]

Greetings Everyone,

In an effort to divide the labor, openly plan, and move the elastic stack
charms forward post 5.0 release I've scheduled a meeting on *11/15/2016 at
10AM PST*. If you are a consumer of our charms in the following list, this
meeting is for you:

- Elasticsearch
- Kibana
- Beats
- Logstash

I've also created a planning document for the session so anyone who is
unable to attend can at least view the meeting agenda, and minutes from the
meeting. This will be a very informal session, and was scheduled with an
overlap in UK/PST time zones to catch two of our very active charmers in
the data science field.

If you're interested in attending, please send me an email and I'll get you
on the calendar invite.

Thanks and all the best,

Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Charles Butler]

On Mon, Oct 24, 2016 at 1:22 PM, Casey Marshall <
casey.marsh...@canonical.com> wrote:

> I came to the conclusion that layer:nginx and layer:lets-encrypt should
> each do one thing well for better reuse. layer:lets-encrypt no longer
> includes layer:nginx, but they're easy to use together.
>

Best thing i've heard on this list in weeks Casey! +1 to that sentiment
about layer encapsulation.



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Prelert + ElasticStack

[Charles Butler]

I'm not sure if anyone here is following along with the elastic 5.x
upgrade, but that work is scheduled to happen during the 16.11 cycle which
is nearly upon us.

While doing some background checking on where the 5.0 release is (currently
in RC status), I stumbled across a new partnership to Elastic which brings
with it Machine Learning integration on the data-sets warehoused in
Elasticsearch.

Now I'm not proposing we immediately hop on board and start charming this
up, but it seems like an extension that adds Prometheus style
introspection, but with the added benefit of ML on the backend so it learns
your model(s) and knows what to expect vs what is an anomaly.

http://info.prelert.com/  and http://elastic.coboth of information and
announcements around the partnership.

Background to Prelert: they offer both business security monitoring and
operational monitoring for anomaly detection. Is this something we're
interested in evaluating as a POC to gather more information?  Is someone
out there already working on this?

It seems to me (assuming this is as awesome as it sounds) that if we were
able to ship both long-term metric aggregation and visualization, with an
added benefit of anomaly detection, that we'd be offering a powerful 1-2
punch out of the box with our solution. But I don't want to dedicate *any*
time to this if we're not even clear if it provides enough value to our
potential customers.  So I'm seeking commentary of any sort on if this is
something we're interested in looking at.

Thanks and all the best,

Charles

Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Complex store queries

[Charles Butler]

> - to see which charms have to be rebuilt if a vulnerability has been
found in a layer

There was a fair amount of talk about static and dynamic code analysis at
DevOps Days KC.
If I ever come up with free time again I'd love to take a look at what that
looks like for us in terms of charm code.

Something like OWASP <https://www.owasp.org/index.php/Main_Page> but not
limited to just webapps.


Would you happen to have any information around this subject Merlijin?



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Mon, Oct 24, 2016 at 6:15 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> +1 for "which charms use this layer" queries. This has a number of uses:
>
> - for finding what the quality of a layer is (more use in recommended
> charms = better quality)
> - for the maintainer of a layer so he can see what the impact is of a
> change on his layer
> - to see which charms have to be rebuilt if a vulnerability has been found
> in a layer
>
> 2016-10-18 16:55 GMT+02:00 Ondřej Kuzník <ondrej.kuz...@credativ.co.uk>:
>
>> Hi,
>> developing new charms or just exploring the store, one might want to
>> raise random queries like "which charms use a layer x", "which charms
>> are subordinate" and some others. Are there any plans to add those,
>> concerns why this might not be a good idea?
>>
>> While the store could extend the API to include these, I presume it
>> would just be an addition to a hardcoded list. Another option would be
>> for someone to scrape the store to PostgreSQL or a document DB of some
>> sort that could be searched with rather arbitrary queries (and a few
>> indexes for the more common ones).
>>
>> My first reaction is that such a scraper would be frowned upon as it
>> might not have a way to update its database intelligently and keep
>> hitting all sorts of rate limits imposed by the store, but I might be
>> wrong here.
>>
>> Any thoughts on this?
>>
>> Thanks,
>> Ondrej
>>
>> --
>> Consultant
>>
>> credativ Ltd
>> Open Source for Business
>> UK office:  +44 1788 298150
>> Email:  ondrej.kuz...@credativ.co.uk
>> Web:http://www.credativ.co.uk
>> Suite 5 | Bloxam Court | Corporation Street | Rugby | CV21 2DU | UK
>>
>> We would love to hear your thoughts on our service!
>> Please send your comments to feedb...@credativ.co.uk
>>
>> credativ Ltd is registered in England & Wales, company no. 5261743
>> Certified by CompTIA / AccredITUK with the ICT Supply standard of
>> quality for Software Product Design and Development
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] Canonical Distribution of Kubernetes Release Notes [week of 10/13]

[Charles Butler]

10/13 Release Notes

Greetings everyone! It's been a short but busy week for us.  We've landed a
lot more bugfixes and some new features for you all to kick the tires.
We're excited to push this week’s rollup as it contains the early work
(alpha?) in consuming Ceph RBD volumes for persistent volume storage in
your kubernetes workloads.

It’s missing from the readme, so here is a quick rundown below the release
notes.  As always, bugs/comments/questions are all welcome.
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues

Or you can find us on irc in #juju on irc.freenode.net


Layer-docker


   -

   Added DOCKER_OPTS passthrough config option. This enables end users to
   configure the runtime of their docker-engine (Such as insecure registries)
   without having to add python code to the layers and/or re-build a fork.


   -

   Corrected an immutable config when attempting to switch between archive
   docker package and the docker-engine package from upstream.


Thanks @brianlbaird and @simonklb for driving this feature during
dev/testing.

Flannel


   -

   Corrected the directory glob pattern on flannel which was failing and
   causing some false positives in the cloud weather report testing tool.


Kubernetes Master

   -

   Added a create-rbd-pv action to enlist persistent storage from Ceph.
   -

  This requires the use of the ceph-mon charm from the
  openstack-charmers-next branch.
  -

   Closed a bug where running microbots would yield an EOF error due to
   proxy settings. Consult the README for limited egress environments. (Thanks
   @ryebot and @cynerva)


Kubernetes Worker

   -

   Added a kubectl wrapper for context with manifests, and a kubectl
   wrapper for arbitrary keyword args.
   -

   Various lint fixes.
   -

   Worker nodes now cleanly remove themselves from the cluster during the
   stop hook. (Thanks to @ryebot and @cynerva)
   -

   The ingress controller now scales to the number of deployed worker
   units. 1 ingress controller per 1 worker unit. (Thanks to @ryebot and
   @cynerva)


Canonical Distribution of Kubernetes Bundle


   -

   Added documentation for proxy settings in network limited environments
   to the bundle README. (Thanks to @ryebot and @cynerva)
   -

   Updated the README with additional limitation notes about which charms
   are not compatible enough to run in LXD at this time.
   -

   Bumped each charm to their latest revision.


Kubernetes Core Bundle

A minimalist bundle, only deploying the bare minimum required to evaluate
kubernetes. Useful when doing laptop development or resource constrained
environments. (Thanks @cynerva and @ryebot)



   -

   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.


https://github.com/juju-solutions/bundle-kubernetes-core  - we’re still
testing this minimal bundle, and it will be published in the charm store as
early as next week. Thanks for your early interest!

Etcd

   -

   Refactored the test to gate on the status messages before reading the
   deployment as ready and proceeding with executing tests.



Quick Rundown on how to enlist RBD PV’s

You’ll need to be running at bare-minimum the ceph-mon charm from the
~openstack-charmers-next namespace.

juju deploy cs:~openstack-charmers-next/xenial/ceph-mon -n 3

juju deploy cs:ceph-osd -n 3

>From here you will need to enlist the OSD storage devices:

For example on GCE you would fulfill this request with GCE Persistent Disks:

juju add-storage ceph-osd/0 osd-devices=gce,10gb

juju add-storage ceph-osd/1 osd-devices=gce,10gb

juju add-storage ceph-osd/2 osd-devices=gce,10gb

This will allocate 30gb of storage, across the 3 OSD device nodes, and
begin your ceph replicated file storage cluster.

Next is to relate the storage cluster with the kubernetes master:

juju add-relation kubernetes-master ceph-mon

We’re now ready to enlist Persistent Volumes in Kubernetes which our
workloads can consume via PersistentVolumeClaims

juju run-action kubernetes-master/0 create-rbd-pv name=test size=50

Tailing a watch on your kubernetes cluster like the following, you should
see the PV become enlisted and be marked as available:

watch kubectl get pv --all-namespaces

NAME CAPACITY   ACCESSMODES   STATUSCLAIM  REASONAGE

test   50M  RWO   Available  10s


To consume these Persistent Volumes, your pods will need an associated PVC
with them, and is outside the scope of this tutorial. See:
http://kubernetes.io/docs/user-guide/persistent-volumes/  for more
information.

This work is early so please let us know if you using storage and remember
to open issues at:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues

-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your 

Re: Big memory usage improvements

[Charles Butler]

Fantastic!  Thanks to everyone involved!

:cheers:

On Wed, Oct 12, 2016 at 3:39 PM Menno Smits 
wrote:

> Christian (babbageclunk) has been busy fixing various memory leaks in the
> Juju controllers and has made some significant improvements. Chris
> (veebers) has been tracking resource usage for a long running test which
> adds and removes a bunch of models and he noticed the difference.
>
> Take a look at the memory usage graphs here:
>
> Before: http://people.canonical.com/~leecj2/perfscalemem/
> After: http://people.canonical.com/~leecj2/perfscalemem2/
>
> Interestingly the MongoDB memory usage profile is quite different as well.
> I'm not sure if this is due to Christian's improvements or something else.
>
> There's possibly still some more small leaks somewhere but this is
> fantastic regardless. Thanks to Christian for tackling this and Chris for
> tracking the numbers.
>
> - Menno
>
>
>
> --
>
> Juju-dev mailing list
>
> Juju-dev@lists.ubuntu.com
>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Canonical Distribution of Kubernetes - Update Release Notes (16.10 cycle)

[Charles Butler]

@mbruzek and I worked on the Canonical Distribution of Kubernetes this
week. There are still quite a few work items in flight, but let’s focus on
what made the early release today:

Kubernetes Master


   -

   Normalized the end user messaging displayed during cluster operations
   (full stops, grammar).
   -

   Added more debug logging output making it clearer to trace problems as
   to the order of what was happening.


Kubernetes Worker


   -

   Fixed status message so “Kubelet waiting to start” is not the last
   message.
   -

   Added debug logging output making it clearer to trace problems as to the
   order of what was happening.
   -

   Adjusted the kubelet systemd template to kill process-groups vs ‘parent
   process’ which was orphaning inotify threads, exhausting the system of open
   files. (thanks @cynerva and @ryebot)
   -

   Removed the SDN Logic from the top most kubernetes-worker layer, into
   the layer-docker to ensure encapsulation.
   -

   Used ‘data_changed’ to prevent excessive restarts of the kubelet and
   kube-proxy processes.



Flannel


   -

   Fixed a failing operation in flannel when it was attempting to remove
   files that had already been deleted.



CDK Bundle


   -

   Updated the version the changed charms to their latest stable
   beta-releases.
   - Updated the Conjure-Up section in the README (thanks @mmc)

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

Re: ANN: Metrics in Juju 2.0

[Charles Butler]

This is fantastic Casey!

There's a lot of raw information feeds we can use here directly in Juju. I
like it!

Thanks for sharing this :)

All the best

Charles

On Mon, Oct 3, 2016 at 10:22 AM Casey Marshall 
wrote:

> I’m pleased to announce Juju Metrics, new in Juju 2.0!
>
> Knowing an application's configuration isn’t enough to effectively operate
> and manage it. Consider that a well-designed application will have as few
> configurable parameters as possible. As an operator, you may find yourself
> wanting to know more about the resources that an application in your model
> consumes and provides -- resources such as:
>
>-
>
>Storage GiB used
>-
>
>Number of user accounts
>-
>
>Number of recently active users
>-
>
>Active database connections
>
>
> Juju Metrics complete the operational picture with application
> observability; by modeling, sampling and collecting measurements of
> resources such as these. Juju collects application metrics at a cadence
> appropriate for taking a model-level assessment of application utilization
> and capacity planning. Charm authors and communities can now collaborate on
> figuring out the critical metrics for service assurance and ops, and share
> that through the charms.
>
> There are many instrumentation and time-series data collection solutions
> supporting devops. Juju’s metrics complement these fine-grained,
> lower-level data sources with a model-level overview -- possibly a starting
> point for deeper analysis.
>
> At a glance, operators can pull the most recent measurements across the
> entire model:
>
> $ juju metrics --all
> UNITTIMESTAMP   METRIC  VALUE
> auth-sso/0  2016-09-19T22:14:29Zusers   28
> auth-sso/0  2016-09-19T22:14:31Ztokens  6
> ceph-mon/0  2016-09-19T22:15:36Zgb-usage5.2711902345
> webapp/02016-09-19T22:17:57Zrequests11903
> webapp/12016-09-19T22:17:52Zrequests13719
>
> View measurements for specific units or applications:
>
> $ juju metrics webapp/0
> UNITTIMESTAMP   METRIC  VALUE
> webapp/02016-09-19T22:17:57Zrequests13719
>
> $ juju metrics sso-auth
> auth-sso/0  2016-09-19T22:14:29Zusers   28
> auth-sso/0  2016-09-19T22:14:31Ztokens  6
>
> How about adding metrics to a charm? With the reactive framework, it’s
> quick and easy!
>
>
>1.
>
>Add layer:metrics to your charm’s layer.yaml
>2.
>
>Declare measurements in your charm’s metrics.yaml
>
>
> metrics.yaml declares each metric’s type and the command line that
> measures it. For example, the hypothetical auth-sso charm in the example
> above might declare metrics:
>
> metrics:
>  users:
>type: gauge
>description: Number of users
>command: scripts/count_users.py
>  tokens:
>type: gauge
>description: Number of active tokens
>command: scripts/count_tokens.py
>
> The command lines given in command: attributes above simply need to write
> the current gauge value -- a positive decimal number -- to standard output.
> Juju 2.0 will initially support type: gauge metrics for the operational
> use cases shown above; others such as type: absolute are experimental,
> and will be better supported in Juju 2.1.
>
> I’d like to encourage you to kick the tires on this new feature, and let’s
> start measuring things in our charms!
>
> For more information, here are links to documentation:
>
> Metrics, User Guide: https://jujucharms.com/docs/stable/charms-metrics
>
> Metrics, Developer Guide:
> https://jujucharms.com/docs/stable/developer-metrics
>
> -Casey
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charming with Resources

[Charles Butler]

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

Charming with Resources

[Charles Butler]

TL;DR - would it be helpful to just initialize every resource stream, at
index 0, a zero byte resource?  This aids users who are publishing charms
with copyrighted bins, or proprietary components. And give an immediately
publishable resource for streams.


It occurred to me this week while we were revving through the kubernetes
publication process, that on initial publish its best to have zero byte
resources at index 0. So its easy to remember - "man which resource was the
zero byte one?" it just corresponds to 0.

Instead of having users touch, gzip, etc a null resource, would it be
feasible to make the charm store have this convention by default? Every
charm that declares a resource, that resource, in turn gets a resource-0
allocated for zero byte, freeing the publisher of the charm to use the
provided null resource?  seems like a better UX than asking the user to
jump through hoops of say:

touch null && gzip null && charm attach mycharm big-resource=null.gz

There's likely a reason we didn't do this by default and I'm interested in
hearing it. However, I'm more interested in finding out if we can
streamline resource publication for our vendors and community.

All the best,

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

Re: "Kubernetes enterprise distribution" powered by Chuck

[Charles Butler]

I love the fanfare, but I'd have a regret if I didn't amend the headline.

"The Canonical Distribution of Kubernetes" - powered by Chuck and Matt,
with some helpful guidance from the community, our early adopters, and in
my case, coffee.

;) Stay fresh you two

Charles

On Wed, Sep 28, 2016 at 1:19 PM Mark Shuttleworth  wrote:

> On 28/09/16 18:39, Merlijn Sebrechts wrote:
>
> Congrats to Chuck and the team!
>
> The kubernetes bundle is now officially the "Commercially Supported
> Distribution of Kubernetes" of Canonical
> 
>
>
> Mooaarrr Chuck, moooaaarrr goodness :)
>
> Mark
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Change Incoming to layer-docker default behavior

[Charles Butler]

Gah, I sent that too quickly.

In some cases, you might also need to re-apply the default profile.
If you notice your apt-get installation fail, and you ifconfig and see you
have no networking. You'll likely need to apply the default profile and
cycle the container.

$ lxc profile apply test default
$ lxc stop test
$ lxc start test

All the best,

Charles

On Sat, Sep 10, 2016 at 3:33 PM Charles Butler <charles.but...@canonical.com>
wrote:

> Certainly Brian,
>
> I'll assume you are working from a xenial+ system, I have not tried this
> on any release prior to xenial.
>
> $ lxc launch xenial test
> $ lxc profile apply test docker
>
> To see what this actually did, let's view the docker profile
>
> $ lxc profile show docker
> name: docker
> config:
>   linux.kernel_modules: overlay, nf_nat
>   security.nesting: "true"
> description: Profile supporting docker in containers
> devices:
>   aadisable:
> path: /sys/module/apparmor/parameters/enabled
> source: /dev/null
> type: disk
>   fuse:
> path: /dev/fuse
> type: unix-char
>
> You'll see its tweaked the apparmor profile, added fuse support, enabled
> nested security, and allowed some kernel modules. This is where I say it's
> mostly functional, as there are some advanced docker features that won't be
> available. Some FS options that may not work as well, and more things I
> haven't actually dug my hands into.
>
> From here:
>
> $ lxc exec test  /bin/bash
> $ sudo apt install docker.io
> $ docker run hello-world
>
>
> On Sat, Sep 10, 2016 at 3:10 PM Brian Baird <brianlba...@gmail.com> wrote:
>
>> Chuck,
>>
>> Very interested in launching layer Docker charms inside lxd.
>>
>> Please share the goods.
>>
>> Cheers,
>>
>> Brian
>>
>> On Sep 10, 2016 3:02 PM, "Charles Butler" <charles.but...@canonical.com>
>> wrote:
>>
>>> TL;DR - we're changing from docker-engine by default to archive's
>>> docker.io package.
>>>
>>> This in most cases will be a minor change and won't require any
>>> additional action on your part. But I wanted to signal to the community at
>>> large for any consumers or potential consumers of layer-docker that the
>>> default installation path is changing.
>>>
>>> https://github.com/juju-solutions/layer-docker/pull/78
>>>
>>> I'm altering the default behavior of the installation which historically
>>> pulled from the docker inc ppa and installed the latest "stable" release of
>>> the docker-engine package.  The proposed change defaults to the '
>>> docker.io' package coming from the Ubuntu Archive.
>>>
>>> The upstream delivery has been somewhat problematic in our
>>> Kubernetes efforts, as kubernetes currently targets docker 1.11.x - the
>>> baked in orchestration bits in 1.12 can in some rare cases cause issues
>>> during deployment.
>>>
>>> This change however, has some really positive upswing results - namely
>>> that the docker.io package when applied against a LXD container with
>>> the 'docker' profile, will get you a mostly functional docker deployment
>>> inside of LXD. It's not perfect, but with additional bugs, and effort from
>>> all us as consumers, we can make this a winning story for users wanting to
>>> dev locally on their laptop without eating cloud expenses.
>>>
>>> If you're interested in this, I'm happy to send over instructions on how
>>> to do this. Additionally, I'm happy to lead any coordination efforts of
>>> the end user testing here, and will be happy to patch pilot any efforts to
>>> make this a better story.
>>>
>>> All the best,
>>>
>>> Charles
>>>
>>> --
>>> 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 Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your application | www.jujucharms.com
>
-- 
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

Kubernetes + Bundles - Release Notes

[Charles Butler]

We just validated across the board some good usability updates for
Kubernetes and its fellow bundles.  Below are the highlights from the
milestones we closed out.

Observable Kubernetes Release Notes - Rev4

juju deploy observable-kubernetes


   -

   Revs to Kubernetes to 8 which fixes master messaging
   -

   Revs to Elasticsearch 18 with rudimentary status messaging
   -

   Various Readme Updates re: Juju 1.x Juju 2.x terminology
   -

   Adds new method to the test suite to introspect and halt progression of
   amulet tests until DNS/Master has confirmed completion of setup



Kubernetes-Core Release Notes - Rev 4

juju deploy kubernetes-core


   -

   Revs to Kubernetes to 8 which fixes master messaging
   -

   Doesn’t Reset the model when testing after first deploy (speedups in CI)
   -

   Various Readme Updates
   -

   Adds new method to the test suite to introspect and halt progression of
   amulet tests until DNS/Master has confirmed completion of setup
   -

   Corrects expose typo in bundle



Kubernetes Charm Release Notes - Rev8

juju deploy kubernetes


   -

   Removed Storage Plugin from Admission Control due to unreliable behavior
   -

   Various Readme Updates
   -

   Adds Operational Actions
   -

  Pause
  -

  Resume
  -

   Changed automated testing behavior to not bootstrap a model during
   bundletests
   -

   Corrected Messaging on the master unit (previously stuck between reboots
   and bridges)


If you kick the tires over the weekend and if you encounter bugs, please
let us know by filing a bug on the bundle repository:
https://github.com/juju-solutions/bundle-canonical-kubernetes/issues

Thanks and all the best,

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

Re: How to register Mr.Smiths, em, agents to IdM

[Charles Butler]

Well that clears that up :) Thanks!

On Mon, Aug 8, 2016 at 8:10 AM Uros Jovanovic <uros.jovano...@canonical.com>
wrote:

> Hi Charles, all,
>
> This was sent to a wrong "j-tab" recipient. Sorry for spamming the list.
>
>
> On Monday, 8 August 2016, Charles Butler <charles.but...@canonical.com>
> wrote:
>
>> Greetings Uros,
>>
>> I don't mean to be daft, but what is this? At first glance, it looks like
>> adding a user to a controller? But it feels like there's some missing help
>> text around this, as to what it's doing, and when I would want to do this.
>> Also don't we have commands already to add a user to a controller such as
>> juju grant and juju register?
>>
>> All the best,
>>
>> Charles
>>
>>
>> On Fri, Aug 5, 2016 at 12:46 PM Uros Jovanovic <
>> uros.jovano...@canonical.com> wrote:
>>
>>> Store this into mrSmith.json
>>>
>>> {
>>> "owner": "admin@idm",
>>> "idpgroups": ["grouplist@idm"],
>>> "public_keys": ["DONGKZyGjKI4D4Uw8oGMofFbLPVQkRvllMkE6IL7RHM="]
>>> }
>>>
>>> http PUT http://admin:password@localhost:8081/v1/u/jem-0@admin@idm <
>>> mrSmith.json
>>>
>>> Adopt the names and public keys to your needs defined in config.yaml od
>>> the service.
>>>
>>> For jem, it helps to set
>>> state-server-admin: some-sso-name
>>>
>>> Have fun ...
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>> --
>> Juju Charmer
>> Canonical Group Ltd.
>> Ubuntu - Linux for human beings | www.ubuntu.com
>> Juju - The fastest way to model your service | www.jujucharms.com
>>
> --
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to register Mr.Smiths, em, agents to IdM

[Charles Butler]

Greetings Uros,

I don't mean to be daft, but what is this? At first glance, it looks like
adding a user to a controller? But it feels like there's some missing help
text around this, as to what it's doing, and when I would want to do this.
Also don't we have commands already to add a user to a controller such as
juju grant and juju register?

All the best,

Charles


On Fri, Aug 5, 2016 at 12:46 PM Uros Jovanovic 
wrote:

> Store this into mrSmith.json
>
> {
> "owner": "admin@idm",
> "idpgroups": ["grouplist@idm"],
> "public_keys": ["DONGKZyGjKI4D4Uw8oGMofFbLPVQkRvllMkE6IL7RHM="]
> }
>
> http PUT http://admin:password@localhost:8081/v1/u/jem-0@admin@idm <
> mrSmith.json
>
> Adopt the names and public keys to your needs defined in config.yaml od
> the service.
>
> For jem, it helps to set
> state-server-admin: some-sso-name
>
> Have fun ...
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Hung up post 2.0 upgrade? juju-unregister to the rescue!

[Charles Butler]

Greetings!

I was in #juju riffing with some juju users, and it became apparent that
there is a not-so-well-known feature of juju in the 2.0+ series.

As 2.0 is not marked as stable, every new release is treated like an
island. Sometimes it may be compatible with what you have deployed (eg
beta-12 to beta-13) and won't require a re-bootstrap, everything will
*appear* to just work. Sometimes the risk and failure is much more apparent
than this, such as the beta-13 to beta-14 update.

Traditionally you would terminate the instances via your cloud provider and
be left with some configuration left around in your $JUJU_DATA directory.
Less than ideal right?

juju unregister to the rescue!

Details:
Removes local connection information for the specified controller.
This command does not destroy the controller.  In order to regain
access to an unregistered controller, it will need to be added
again using the juju register command.

I thought I would share this great discovery with others that are being
intrepid and helping us test 2.0

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

[Review Queue] Ubuntu-repository-cache

[Charles Butler]

Greetings,

I spent some time today reviewing charm submissions and here are the
results:


   -
   
https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/error-message-fix/+merge/292622
  - The submission looks fine, however the charm fails deployment in
  its current form due to the errors introduced in rev 212. The python3
  change demands a resync of charm-helpers
  - Additionally the upstream of the charm appears to have moved to
  lp:~cloudware, and as such the mp was updated to request a resubmission
  - -1 for now, but +1 soon once the targets have been changed, and the
  charm is triaged for python3 compat
   -
   
https://code.launchpad.net/~cjwatson/charms/trusty/ubuntu-repository-cache/signed-is-metadata/+merge/295823
  - The submission looks fine,
  however
   the charm fails deployment in its current form due to the errors
  introduced in rev 212. The python3 change demands a resync of
charm-helpers
  - Additionally the upstream of the charm appears to have moved to
  lp:~cloudware, and as
  such
   the
  mp
   was updated to request a resubmission
  - -1 for now, but +1 soon once the targets have been changed, and the
  charm is triaged for python3
  compat

That's all for this week.  Thanks!
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

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

[Charles Butler]

With quick turn around this is now available for immediate testing in the
charmbox:devel flavor of images

docker pull jujusolutions/charmbox:devel

You can get started right away with some volume mounts to bring in your
charm's and $JUJU_DATA location. We on the ~containers team have a bash
alias to make this somewhat trivial:

I apologize in advance for the number of flags to make this feasible,
however its a vanilla juju workspace on every invocation.

docker run --rm \
  -ti  \
  -h charmbox.juju.solutions \
  -v $HOME/.juju-work:/home/ubuntu/.local/share/juju \
  -v $HOME/projects/work/interfaces:/home/ubuntu/interfaces \
  -v $HOME/projects/work/layers:/home/ubuntu/layers \
  -v $HOME/projects/work/builds:/home/ubuntu/builds \
  -v $HOME/projects/work/bundles:/home/ubuntu/bundles \
  -v $PWD:/home/ubuntu/pwd \
  jujusolutions/charmbox:devel

>From here you should be able to enter into any charm/bundle directory and
kick off a test against a boostrapped juju2 controller:

juju bootstrap amazon aws
bundletester -F -l DEBUG -v

If you encounter any issues, let us know on the issue tracker:

https://github.com/juju-solutions/charmbox/issues

Thanks and happy testing!

On Wed, Aug 3, 2016 at 11:01 AM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> These new releases work with the latest juju-2.0 betas while maintaining
> compatibility with juju-1.25.
>
> They are currently available on PyPI and in ppa:tvansteenburgh/ppa, and
> will likely be copied to ppa:juju/stable in the near future.
>
> Find bugs? File here:
> https://bugs.launchpad.net/python-jujuclient
> https://bugs.launchpad.net/juju-deployer
>
>
> Bundletester (https://github.com/juju-solutions/bundletester) works with
> the latest juju-2.0 betas if the latest versions of juju-deployer and
> python-jujuclient are installed.
>
> The Amulet charm testing library (http://pythonhosted.org/amulet/) has
> juju-2.0 support in master, but is awaiting a release that contains that
> support. Watch this space for an announcement of that release.
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
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

Do you docker? How about layer-docker? Learn how in this weeks post

[Charles Butler]

Greetings everyone,

I spent some time hacking up a deep dive on how to work with layer-docker,
the darling layer from the ~containers team making onboarding users looking
to use docker in their juju experience even easier.

http://dasroot.net/posts/2016-08-03-layer-docker-deep-dive/

This breaks down a multi-factor application comprising of:


   - A Python webapp which lets you vote between two options
   - A Redis queue which collects new votes
   - A .Net worker which consumes votes from redis and stores them in a
   database.
   - A Postgres database backed by a Docker volume
   - A Node.js webapp which shows the results of the voting in real time

You'll learn how to deploy this "bundle" (i didn't include bundle
instructions) as a stand-alone charm for evaluation purposes, and then how
to connect to external services for proper scale out production workloads
where data persistence and horizontal scalability is a key factor.

I wrote this post in tandem with doing the charming work. If you notice any
issues please either file a comment on the post, ping me here on the
mailing list, or file a bug against any of the mentioned repositories in
the post. (except the core vote-app-example from docker inc, they didn't
help in this post, so it's likely to get closed as wontfix).

This is also a prelim document that I plan on extracting for the juju docs,
if this was helpful, I'd love to know that too!

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

Re: Kubernetes v1.3.3 for Ubuntu Ready for Testing

[Charles Butler]

(initially sent yesterday, re-sending, expanding, and cc'ing the list today)

Greetings Ed,

I've been using traefik (http://traefik.io) to provide ingress access to my
services which works quite well for traditional http workloads. It runs as
a pod/service in your kubernetes cluster and can turn the nodes into LB's
for those workloads. If you're using a socket based service it's still
recommended to use nodeport.

We're investigating how best to approach cloud native integration on GCE
and AWS but there are no primitives in juju to lend us a hand here so we're
still in the investigation phase. I'm happy to discuss options for
networking and exposing ingress to your workloads further. Especially if
this relates to deploying kubernetes on OpenStack, as well as the public
clouds.

All the best

Charles

On Mon, Aug 1, 2016 at 7:41 AM Edward Bond  wrote:

> Jorge,
>
> This looks great. Is there still a limitation on being able to node port
> or load balancer exposing of services ?
>
> -Ed
>
> On Aug 1, 2016 7:34 AM, "Jorge O. Castro"  wrote:
>
>> Hey everyone, Chuck and Matt have been working real hard on this:
>>
>>
>> http://www.jorgecastro.org/2016/07/29/ubuntu-kubernetes-v1-dot-3-3-ready-for-testing/
>>
>> We're hoping to aggressively get to 1.4, so if you're into Kubes and
>> want to help out, let us know!
>>
>> --
>> Jorge Castro
>> Canonical Ltd.
>> http://jujucharms.com/ - The fastest way to model your service
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Events in August: FOSSCON 2016

[Charles Butler]

Hey Jose,

I won't be attending this year due to geographic location however I have
attended this conference before. It's a great meet and greet for the who's
who of open source in philly.

Last year there was no booth, but the hallway tracks were great.

Have fun and good luck!

All the best,

Charles

On Fri, Jul 29, 2016 at 11:48 AM José Antonio Rey  wrote:

> Whoops! Forgot to mention, you can find more information about the eent
> at fosscon.org.
>
> The event is completely free to attend, and you can register here:
> http://www.eventbee.com/v/fosscon2016
>
> Hope to see some of you around!
>
> On 07/29/2016 11:46 AM, José Antonio Rey wrote:
> > Hey everyone!
> >
> > Just wanted to give you a heads up that I'll be giving a Juju talk at
> > FOSSCON. Conference details below:
> >
> > August 20th, 2016
> > 9:00am - 5:00pm
> > International House of Philadelphia
> > 3701 Chestnut St, Philadelphia, PA 19104
> >
> > I'm not entirely certain if we'll have an Ubuntu booth, but if we do,
> > I'll let you know so we can drop by!
> >
> > Are you giving a Juju talk in an upcoming event, or even better, hosting
> > one? Let us know!
> >
>
> --
> José Antonio Rey
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Layer-Supervisor

[Charles Butler]

Greetings James,

+1 to Adams suggestion.

A  question about the readme examples:

There's a given example where you're getting a Workers() object but it
isn't imported, or declared. Where did it come from?

@when('myapp1.supervisor.available',
  'myapp2.supervisor.available')def run_workers():
w = Workers()
w.start_tasks()


Emittersare really states, I would probably rename that header for clarity.

Looking into the code, it looks like a great start. Some minor nits though:

https://github.com/jamesbeedy/layer-supervisor/blob/master/lib/charms/layer/supervisorlib.py#L43

There's some host modifications going on in here I wouldn't expect to find
here. Really I would expect to see this bit handled in the reactive layer.

Maybe place it around:
https://github.com/jamesbeedy/layer-supervisor/blob/master/reactive/supervisor.py#L11

And try to keep host modifications to the reactive module, and keep the
library tidy for interfacing with supervisor and doing the redundant things
for the user when those come about like scaling workers, providing sensible
defaults for common values.

I see quite a bit in here http://supervisord.org/configuration.html  so
you're definitely on the right path :)


All in all its a great start, I look forward to seeing where this goes, and
would like to thank you for your continued contributions to the charm and
layer ecosystem.

All the best,

Charles



On Thu, Jul 21, 2016 at 1:25 PM Adam Stokes 
wrote:

> looks good, one small nit pick, maybe change supervisorlib.py to just
> supervisor.py. that seems to be the current naming scheme of things
>
> On Thu, Jul 21, 2016 at 1:42 PM, James Beedy  wrote:
>
>> A big thanks to those of you who gave feedback! I have made some
>> revisions based on the suggestions I received from a few of you (thank
>> you!), and would like to get a second round of feedback now the
>> modifications  have been made -> [layer-supervisor](
>> https://github.com/jamesbeedy/layer-supervisor).
>>
>> Thanks all!
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] Nexenta Edge Suite

[Charles Butler]

Greetings Anton,

I took a moment to take a look today and they were +1 LGTM and have pushed
your proposed changes to the nexenta edge charms.

The following is the result of the review/publication cycle:


url: cs:~nexenta-charmers/trusty/nexentaedge-iscsi-gw-4
channel: stable

url: cs:~nexenta-charmers/trusty/nexentaedge-data-4
channel: stable

url: cs:~nexenta-charmers/trusty/nexentaedge-iscsi-gw-5
channel: stable

url: cs:~nexenta-charmers/trusty/nexentaedge-swift-gw-4
channel: stable


cs:trusty/nexentaedge-data-4
cs:trusty/nexentaedge-iscsi-gw-5
cs:trusty/nexentaedge-mgmt-5
cs:trusty/nexentaedge-swift-gw-4

You may need to update the nedge bundle respectively.

Thanks for your patience during the review cycle.

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

Re: Charm Store Policy Update: Propritary applications usage of Terms and Resources

[Charles Butler]

This has been on the list for > 1 month with a little activity. I'm poking
this thread to see if there are any remaining outliers that wish to chime
in.


Just a reminder: we have an open issue on the documentation to make this
formally accepted into the charm store policy. This will affect any new
incoming charms. Resources/terms are a 2.0 feature - should we wait for the
features to land as -stable, *then* make the policy update? Or do we want
to make this policy pre 2.0 so the policy verbiage is in place?


On Fri, May 27, 2016 at 2:59 AM Mark Shuttleworth  wrote:

> On 27/05/16 01:00, Antonio Rosales wrote:
> > I think most software require acceptance of the License. Perhaps the
> > point here is weather the acceptance has to be active or passive. If
> > this is the intent should the policy state: Any software which
> > requires active user acceptance of a license or EULA has to have that
> > as a term on the charm.
>
> +1
>
> >> Any software which installs components from outside of a distributions
> >> archive needs to represent that as a resource
> > Nice suggestion, this also massively helps with determining will my
> > charm run inside my restricted firewall. I have added your suggestion
> > to the issue as we discuss it to also track the suggestion there
>
> Yes, firewalls are the main driver of resources. More often than not a
> charm which tries to pull stuff from the internet randomly fails because
> of firewalls. We know the controller can reach the charm archive because
> "juju deploy" fetched the charm. So serving resources from the same
> place is much more effective.
>
> It also lets us slim down the charm itself in many cases, because
> bundled blobs just become resources, which means there is less to push
> and pull for every revision :)
>
> Mark
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] Auditd

[Charles Butler]

Tim Kuhlman needed a hot review for auditd. This was a good looking
submission, primarily a sync of lower layers and some minor top layer
edits. Approved has been pushed to: cs:trusty/auditd-1


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

Re: Question for cosmetic and understandability of breadcrumbs in github

[Charles Butler]

I was actually talking to beisner about this in Irc and the open stackers
are putting a report in their artifacts with the repository information.

https://api.jujucharms.com/charmstore/v5/~openstack-charmers-next/xenial/neutron-gateway/archive/repo-info

I think I like this better.

We are generating a manifest of the other layers but I'm not certain we are
storing any commit hash info in that manifest. I don't think we are.

But it would give me a nice trail to follow.
On Thu, Jun 16, 2016 at 4:42 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Well, Charles, I must admit that I'm a bit lost. There's some lingo in
> this email I don't quite understand, and it's quite late on my side of the
> globe ;)
>
> What I understand you want: You have a Github repo that contains the top
> layer of a Charm. Each tag in that repo corresponds to the revision of the
> charm build from that layer. Is this correct?
>
> This would allow you to see what Charm corresponds to what layer version.
>
> I don't quite understand how this would solve your kubernetes problem.
> Don't you want this information about every layer instead of just the top
> one? Is this something 'charm build' would be able to do automatically? It
> gets the layers from a repo so it might be able to put that info
> (repo/commit) in a log somewhere?
>
> 2016-06-16 19:51 GMT+02:00 Charles Butler <charles.but...@canonical.com>:
>
>> Greetings,
>>
>> I deposit many of my layers in GitHub, and one of the things  I've been
>> striving to do is keep tag releases at the revisions i cut a charm release
>> for a given channel. As we know, the default channel is seen by no-one, and
>> runs in increments of n+1.
>>
>> My prior projects i've been following semver for releases, but that has
>> *nothing* in terms of a breadcrumb trail back to the store.
>>
>> Would it be seen as good practice to tag releases - on the top most layer
>> of a charm - with what charm release its coordinated with?
>>
>> Given the scenario that i'm ready to release swarm, and lets assume that
>> to date i haven't tagged any releases in the layer repository:
>>
>> charm show cs:~containers/trusty/swarm revision-info
>> revision-info:
>>   Revisions:
>>   - cs:~containers/trusty/swarm-2
>>   - cs:~containers/trusty/swarm-1
>>   - cs:~containers/trusty/swarm-0
>>
>> I see that i'm ready to push swarm-3 to the store:
>>
>> git tag 3
>> git push origin --tags
>>
>> I can now correlate the source revision to what i've put in my account on
>> the store, but this does not account for promulgation (which has an
>> orthogonal revision history), and mis-match of those id's.
>>
>> I think this can simply be documented that tags track
>> <>/<> pushes, and to correlate source with release, to use
>> the method shown above to fetch release info.
>>
>> Does this sound useful/helpful or am I being pedantic? (I say this
>> because Kubernetes touches ~ 7 layers, and it gets confusing keeping
>> everything up to date locally while testing, and then again re-testing with
>> --no-local-layers to ensure our repositories are caught up with current
>> development work. (Cant count the number of open pull requests hanging
>> waiting for review because we've moved to the next hot-ticket item)
>>
>> 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 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

Question for cosmetic and understandability of breadcrumbs in github

[Charles Butler]

Greetings,

I deposit many of my layers in GitHub, and one of the things  I've been
striving to do is keep tag releases at the revisions i cut a charm release
for a given channel. As we know, the default channel is seen by no-one, and
runs in increments of n+1.

My prior projects i've been following semver for releases, but that has
*nothing* in terms of a breadcrumb trail back to the store.

Would it be seen as good practice to tag releases - on the top most layer
of a charm - with what charm release its coordinated with?

Given the scenario that i'm ready to release swarm, and lets assume that to
date i haven't tagged any releases in the layer repository:

charm show cs:~containers/trusty/swarm revision-info
revision-info:
  Revisions:
  - cs:~containers/trusty/swarm-2
  - cs:~containers/trusty/swarm-1
  - cs:~containers/trusty/swarm-0

I see that i'm ready to push swarm-3 to the store:

git tag 3
git push origin --tags

I can now correlate the source revision to what i've put in my account on
the store, but this does not account for promulgation (which has an
orthogonal revision history), and mis-match of those id's.

I think this can simply be documented that tags track
<>/<> pushes, and to correlate source with release, to use
the method shown above to fetch release info.

Does this sound useful/helpful or am I being pedantic? (I say this because
Kubernetes touches ~ 7 layers, and it gets confusing keeping everything up
to date locally while testing, and then again re-testing with
--no-local-layers to ensure our repositories are caught up with current
development work. (Cant count the number of open pull requests hanging
waiting for review because we've moved to the next hot-ticket item)

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

Re: TLS Terminated Etcd (If you use etcd this affects you)

[Charles Butler]

Thanks again for the feedback,

I'm going to cut and push this release of the Etcd charm and issue a follow
up announcement to the list advising pinning/avoiding upgrade if end users
wish to keep non-tls connections.

Cheers!

On Thu, Jun 16, 2016 at 2:34 AM Jay Wren  wrote:

> On Wed, Jun 15, 2016 at 12:08 PM, Casey Marshall <
> casey.marsh...@canonical.com> wrote:
>
>> The overhead of a TLS handshake can be minimal, it just depends on the
>> algorithm & key lengths used. This should be configurable in the layer, I
>> think. EC and 2048-bit RSA have reasonable handshake times.
>>
>>
> I take it all back. I just had a chat with coworkers who reminded me that
> etcd supports http2 already and that the performance improvements of http2
> could be very significant. Given that, I thank you greatly for these TLS
> changes and look forward to using them
> --
> Jay
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: TLS Terminated Etcd (If you use etcd this affects you)

[Charles Butler]

Thanks for the feedback Jay and Casey,

> We trust the network on which we run and we aren't getting and setting
any sensitive data.
> I value speed. I would continue to use a previous version of the charm.

Perfectly reasonable response, but be aware that the older charm
implementations aren't receiving updates going forward. But that does make
an interesting point, I encountered the same prickly situation when we were
pioneering with the folks over at Expeto using layer-docker right after we
enabled TLS terminated endpoints for swarm and Docker Engine. I feel we're
headed to the same boat of  secure by default, fine: but make it
configurable. Which gets tricky once workloads are humming away. Stripping
away TLS certificates before the consumers (related applications) are
updated can cause dropped connections. (bad certificate errors, service
unavailable, etc.)

>Etcd really doesn't handle a high volume of writes anyway though. The
overhead of a TLS handshake can be minimal, it just depends on the
algorithm & key lengths used. This
> should be configurable in the layer, I think. EC and 2048-bit RSA have
reasonable handshake times.

Yep, we're currently on the 2048 bit RSA key generation bandwagon with
layer-tls. I think we're right in the grey zone of still reasonably secure,
but it could go either way in the couple months/years, requiring the
2048-bit to be bumped up. Jay would really hate that overhead and I would
be right along with him to be honest. #noloveforprimes  But good feedback
for making it configurable. I took the liberty of filing a bug about this:
https://github.com/juju-solutions/layer-tls/issues/38


Great feedback! Thanks for taking the time :)

All the best,

Charles

On Wed, Jun 15, 2016 at 5:08 AM Casey Marshall <casey.marsh...@canonical.com>
wrote:

> On Wed, Jun 15, 2016 at 11:52 AM, Jay Wren <jay.w...@canonical.com> wrote:
>
>> On Tue, Jun 14, 2016 at 5:50 PM, Charles Butler <
>> charles.but...@canonical.com> wrote:
>>
>>> - There is currently no way to disable TLS wrapped endpoints on Etcd (we
>>> want to keep our coordination data secure don't we?)
>>>
>>>
>> For our use case, we consider the overhead of establishing a new TLS
>> connection for every read or write to be heavier weight than we wish for
>> our etcd clients. We trust the network on which we run and we aren't
>> getting and setting any sensitive data.
>>
>> I value speed. I would continue to use a previous version of the charm.
>>
>
> Etcd really doesn't handle a high volume of writes anyway though. The
> overhead of a TLS handshake can be minimal, it just depends on the
> algorithm & key lengths used. This should be configurable in the layer, I
> think. EC and 2048-bit RSA have reasonable handshake times.
>
> 4096-bit RSA for TLS server keys is really slow though, I've seen
> handshakes on the order of seconds when benchmarking.
>
>
>> --
>> Jay
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>> --
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

TLS Terminated Etcd (If you use etcd this affects you)

[Charles Butler]

Greetings,

TL;DR - If you have the time, are not listed in the grouping of
applications below, and are using etcd in your deployment - this effects
you and I *need* to hear from you!

I've been cycling the last few weeks on revamping the Etcd charm
 (a golang single binary
key/value store). One of the newest *enforced* features is TLS (provided by
layer-tls ) Terminated
endpoints for end to end encryption of a production ready Kubernetes
deployment.

Normally this would be just a bullet point in a release bulletin email,
however this time around I want to ping the community before we push the
latest revision to a stable channel due to the following concerns:

- TLS is enabled/enforced by default (with strict client key/server key
validation)
- There is currently no way to disable TLS wrapped endpoints on Etcd (we
want to keep our coordination data secure don't we?)
- End users now have to use TLS certificates to communicate with Etcd
(available from a convenient action / scp command)
- This will break compatibility with existing deployments unless supporting
charms are built with the latest 'etcd' interface, and this is not 100%
crystal clear which charms have been  updated - without releasing a new
bundle... and this only helps new deployments. Existing deployments will
require a bit more finesse in ensuring the related charms around Etcd have
been upgraded *prior* to the new etcd upgrade.

We did make the interface 
 backward compatible, so anyone building the Etcd charm can use either
communication path. However the layer itself is not engineered in such a
way that the TLS certificates can be toggled. If If the community at large
 has a need for a non-tls wrapped Etcd, I'd like to hear now, so we are
spending the engineering effort wisely. I'd like to support it, but not
without empirical evidence that it is required.* Secure by default* sounds
like a great place for us to be, but not at the expense of our community
members.

As best I can tell, this only effects the following projects:

- Calico (critical path)
- Kubernetes (critical path)
- Swarm (optional path)



Thank you for your time, and all the best,

-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: issue for other charms after installing mariadb 5.5

[Charles Butler]

Great team work Daniel and Rajith!

Really happy we were able to converge on this problem and get it sorted for
the power8 community. Your work here is much appreciated gentlemen.

All the best,

Charles

On Mon, Jun 13, 2016 at 4:25 AM Rajith P Venkata 
wrote:

> Thanks Daniel, for Mariadb 5.5 we were able to deploy on power machine
>  without any work around.
>
>
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> 
>
> Cell- 9901966577
> Email: rajith...@in.ibm.com
>
>
>
> From:Daniel Bartholomew 
> To:Rajith P Venkata/India/IBM@IBMIN
> Cc:juju 
> Date:11-06-16 01:40 AM
> Subject:Re: issue for other charms after installing mariadb 5.5
> --
>
>
>
> On Wed, Jun 8, 2016 at 9:30 AM, Rajith P Venkata 
> wrote:
> > Thanks for below information, after deploying Mariadb 5.5 , we are not
> able
> > to add any new charm we are getting  below error if we deploy any charm
> > after Mariadb 5.5 charm.
> >
> > http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu/dists/trusty/InRelease
> >
> >  Unable to find expected entry 'main/binary-ppc64el/Packages' in Release
> > file (Wrong sources.list entry or malformed file)
> >
> > As a workaround I  had tried to comment the below url, in
> > /etc/apt/sources.list, which helped to proceed with my charm.
>
> deb http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu trusty main
>
> Leave the above uncommented in your sources.list
>
> > and in sources.list we have below url commented:
> > # deb-src http://ftp.osuosl.org/pub/mariadb/repo/5.5/ubuntu trusty main
> >
>
> There was an error in the 5.5 repository. Basically, the metadata and
> some of the Power8 packages were missing. It should be good now. Can
> you check?
>
> Thanks.
>
> --
> Daniel Bartholomew, MariaDB Release Manager
> MariaDB | http://mariadb.com
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: where is upstream code for charms displayed?

[Charles Butler]

i just followed up on this and re-pointed the homepage to the launchpad
project.


All the best,

On Tue, Jun 7, 2016 at 9:00 AM Jorge O. Castro  wrote:

> On Tue, Jun 7, 2016 at 8:21 AM Adam Stokes 
> wrote:
> > For whatever reason I'm having a difficult time figuring out where the
> upstream source code is for a charm that I wish to contribute to.
>
> The "home" field is incorrectly pointing to the elastic.co page
> instead of the charm source code, I'll file a bug for that now. Even
> then there have been some issues with view code lately but the fixes
> have not yet landed:
>
> https://github.com/CanonicalLtd/jujucharms.com/issues/241
> https://github.com/CanonicalLtd/jujucharms.com/issues/275
>
> The `charm set` command sets the metadata that the store will use for
> this, as we touch charms for maintenance we should be updating these
> fields:
>
> charm set wordpress bugs-url=https://bugspageforwordpress.none
> charm set wordpress homepage=https://homepageforwordpress.none
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] MariaDB

[Charles Butler]

Greetings,

Today I took some time to peruse the MariaDB Charm submission by dbart
https://bugs.launchpad.net/charms/+bug/1587641

+1 - merged and published as cs:trusty/mariadb-3
https://jujucharms.com/mariadb/

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

Re: Charmers membership request!

[Charles Butler]

A big +1 to this application. You keep me honest, and always make me
contribute higher quality submissions. Even if you have to lend a hand
where my python-fu falls over. I look forward to having you join the ranks
as a Charmer Konstantinos!

On Mon, May 30, 2016 at 11:33 AM Konstantinos Tsakalozos <
kos.tsakalo...@canonical.com> wrote:

> Hi,
>
> This is to request membership to ~charmers.
>
> I have been working with the Bigdata team for some time now. You can find
> my contributions in the respective charms & bundles on https://github.com/
> juju-solutions. Also, I've been taking part in the regular (normally
> weekly) review sessions of the team so I am very familiar with the process.
>
>
> Thank you,
> Konstantinos Tsakalozos
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Docker compose in Juju

[Charles Butler]

Greetings Gayan!

You most certainly can compose and use a full docker-provided stack, mix
and match with charms - thats the power of wrapping your compose-based
service with layer-docker.

https://github.com/juju-solutions/layer-docker

Which is a great starting place for charming up your dockerized app using
charms.docker to lend a hand with the ops knowledge to get it running :)

https://github.com/juju-solutions/charms.docker
http://pythonhosted.org/charms.docker/modules.html

There are several examples in the charm store from myself (lazypower) and
Matt Bruzek (mbruzek)  that are docker based. I believe the most straight
forward example that I can illustrate today is the swarm layer, which
builds the swarm charm.

https://github.com/juju-solutions/layer-swarm
https://jujucharms.com/u/containers/swarm-core

This is a multi-series charm that delivers swarm via containers, backended
by consul or etcd as the discovery mechanism. This has a good mix of
relationships, base layers, top-layers (what you would be writing), and
uses the docker-native tooling to bring everything up with some help from
juju.

There are even more complex examples, such as Kubernetes - all being
brought up and controlled in a similar manner

https://github.com/kubernetes/kubernetes/tree/master/cluster/juju
https://jujucharms.com/u/containers/kubernetes-core

If you need any help charming with Docker you can get in touch with myself
on the mailing list here, or join us on irc in #juju on irc.freenode.net

I'd love to hear any feedback/questions/comments about the developer
tooling we have here, as its really ramped up our capacity to churn out
high quality charms quickly that are docker based, and if there's any rough
edges we can sand out for other developers would be great starting points.

All the best,

Charles

On Tue, May 31, 2016 at 9:41 AM Gayan Gunarathne  wrote:

> Hi Marco,
>
> Thanks for the details.
>
> Actually I just want to do something like this. Lets say I have tomcat and
> mysql composite application. So I need to deploy these two application in
> docker with depends on(I am really glad if I can use demo UI[1]). How can I
> do that?
>
> Do you already have charms that run in docker with the same? Can you point
> me to some sample?
>
> [1]https://demo.jujucharms.com/
>
> Thanks,
> Gayan
>
> On Tue, May 31, 2016 at 6:52 PM, Marco Ceppi 
> wrote:
>
>> Hi Gayan,
>>
>> I've added the general Juju list which covers more of these general
>> topics.
>>
>> So, because of the nature of LXC machines and Docker style application
>> containers it's hard to model that style application container in Juju in
>> the same way LXC machines work. However, it's quite easy to wrap something
>> like a Docker container, which works really well as a payload/software
>> delivery tool, but then you can use Juju to wrap that immutable object and
>> make it mutable inside of a Juju deployment.
>>
>> I know there are quite a few people on the juju mailing list doing this
>> today, so I'll let them weigh in. In short, yes you can use Docker and
>> docker style application containers with Juju, but not in the same direct
>> way you would a LXC machine just because of the differences in function and
>> form.
>>
>> Marco
>>
>> On Tue, May 31, 2016 at 7:09 AM Gayan Gunarathne 
>> wrote:
>>
>>> Hello,
>>>
>>> Can we run docker directly with Juju? I saw Juju is supporting the LXC
>>> containers. I need to know whether we can spawn docker containers as the
>>> same.
>>>
>>> If we support this can you point me to any document?
>>>
>>> Thanks,
>>> Gayan
>>> --
>>> Juju-dev mailing list
>>> Juju-dev@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>
>
> --
> Best Regards,
> Gayan
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
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-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Docker compose in Juju

[Charles Butler]

Greetings Gayan!

You most certainly can compose and use a full docker-provided stack, mix
and match with charms - thats the power of wrapping your compose-based
service with layer-docker.

https://github.com/juju-solutions/layer-docker

Which is a great starting place for charming up your dockerized app using
charms.docker to lend a hand with the ops knowledge to get it running :)

https://github.com/juju-solutions/charms.docker
http://pythonhosted.org/charms.docker/modules.html

There are several examples in the charm store from myself (lazypower) and
Matt Bruzek (mbruzek)  that are docker based. I believe the most straight
forward example that I can illustrate today is the swarm layer, which
builds the swarm charm.

https://github.com/juju-solutions/layer-swarm
https://jujucharms.com/u/containers/swarm-core

This is a multi-series charm that delivers swarm via containers, backended
by consul or etcd as the discovery mechanism. This has a good mix of
relationships, base layers, top-layers (what you would be writing), and
uses the docker-native tooling to bring everything up with some help from
juju.

There are even more complex examples, such as Kubernetes - all being
brought up and controlled in a similar manner

https://github.com/kubernetes/kubernetes/tree/master/cluster/juju
https://jujucharms.com/u/containers/kubernetes-core

If you need any help charming with Docker you can get in touch with myself
on the mailing list here, or join us on irc in #juju on irc.freenode.net

I'd love to hear any feedback/questions/comments about the developer
tooling we have here, as its really ramped up our capacity to churn out
high quality charms quickly that are docker based, and if there's any rough
edges we can sand out for other developers would be great starting points.

All the best,

Charles

On Tue, May 31, 2016 at 9:41 AM Gayan Gunarathne  wrote:

> Hi Marco,
>
> Thanks for the details.
>
> Actually I just want to do something like this. Lets say I have tomcat and
> mysql composite application. So I need to deploy these two application in
> docker with depends on(I am really glad if I can use demo UI[1]). How can I
> do that?
>
> Do you already have charms that run in docker with the same? Can you point
> me to some sample?
>
> [1]https://demo.jujucharms.com/
>
> Thanks,
> Gayan
>
> On Tue, May 31, 2016 at 6:52 PM, Marco Ceppi 
> wrote:
>
>> Hi Gayan,
>>
>> I've added the general Juju list which covers more of these general
>> topics.
>>
>> So, because of the nature of LXC machines and Docker style application
>> containers it's hard to model that style application container in Juju in
>> the same way LXC machines work. However, it's quite easy to wrap something
>> like a Docker container, which works really well as a payload/software
>> delivery tool, but then you can use Juju to wrap that immutable object and
>> make it mutable inside of a Juju deployment.
>>
>> I know there are quite a few people on the juju mailing list doing this
>> today, so I'll let them weigh in. In short, yes you can use Docker and
>> docker style application containers with Juju, but not in the same direct
>> way you would a LXC machine just because of the differences in function and
>> form.
>>
>> Marco
>>
>> On Tue, May 31, 2016 at 7:09 AM Gayan Gunarathne 
>> wrote:
>>
>>> Hello,
>>>
>>> Can we run docker directly with Juju? I saw Juju is supporting the LXC
>>> containers. I need to know whether we can spawn docker containers as the
>>> same.
>>>
>>> If we support this can you point me to any document?
>>>
>>> Thanks,
>>> Gayan
>>> --
>>> Juju-dev mailing list
>>> juju-...@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>
>>
>
>
> --
> Best Regards,
> Gayan
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm Store Policy Update: Propritary applications usage of Terms and Resources

[Charles Butler]

I'm +1 to requiring terms and resources for prop. applications.

This will effectively funnel our new onboarding efforts of these vendors
into the juju 2.0 path, and start them off using best practices - which
will really lend a hand to the robustness of their deployment (see: behind
the corp firewall)  As I just went through several rounds of this with our
own firewall setup to onboard a vendor into OIL.  Additionally it removes a
barrier to entry as many of these apps are behind registration walls or pay
walls (needs citation). Anywhere that we can ease use for our consumers I
am a loud +1.

Further more, terms ensures their IP concerns are being handled
appropriately. You don't agree to pay? you don't get to play.




On Thu, May 26, 2016 at 9:28 AM Mark Shuttleworth  wrote:

> On 26/05/16 00:21, Tom Barber wrote:
> >
> > I think Terms are good but terms for open source is overkill.
> >
> > For example if I apt install openjdk I wouldn't accept any terms
> > during the install process, but if I apt install oracle-jdk I would.
> >
> >
>
> Agreed, no acknowledgement of terms should be needed for FLOSS charms or
> resources.
>
> Mark
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[Charles Butler]

I love it when you support my arguments and I'm too dense to pick up on it
Tim :D
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[Charles Butler]

Thats only monitoring the host's ssh connection/heartbeat. If you want
application specific monitoring, you'll need the NRPE agent or to implement
it on the charm so it knows what to check.

It does the bare minimum by default which i believe to be: "is the host
still alive?"

On Mon, May 16, 2016 at 9:33 AM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> On Mon, May 16, 2016 at 6:44 AM, Tom Barber 
> wrote:
>
>>  I should be able to say "hey, I'm gonna install this new charm" and know
>> that I can hook it into our monitoring infrastructure without doing
>> anything too crazy.
>>
>>
> Isn't this already true? After seeing this thread, I took a brand new
> charm that I wrote, for which I had not yet even thought about monitoring,
> deployed Nagios, related it to my charm, and sure enough, it Just Worked.
>
>
>> Its all well and good selling Juju to Developers like myself or CTO's by
>> the Ops guys have their "special ways" and making sure that charms fit into
>> those ways will be key to adoption.
>>
>> Tom
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Promulgated charms (production readiness)

[Charles Butler]

>  should it not be a requirement for all promulgated charms to have a
monitoring endpoint

A bit of a nit, but i strongly disagree with the verbiage here. This should
be a best practice. Not every charm developer is going to know Nagios, and
its unlikely they are going to spend the time figuring out how to hook it
up without some massive incentive.


With that being said...

If we can enable this to be a short-story for every charm author, we should
run this down and tackle it, throw money at it, and make it the best
experience for "instant monitoring" ever.






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

> There was a chat we had over dinner at ApacheCon that I figure would be
> worth bringing up on the list, which was todo with what makes charms
> "production ready"
>
> Charms that have been signed off in the review queue are generally
> accepted to be of higher quality than ones that haven't(or at least have
> been validated by those in the know). So people new to the platform will
> naturally gravitate towards these charms. But does it make them production
> ready?
>
> A couple of questions that cropped up were, even though charms have been
> reviewed, it doesn't make the them infallible and if people new to the
> platform install MySQL for example and it fails before they've even
> started, they'll just spin up a box and apt-get it because what's the
> point, right? :) So mitigating that risk is one thing.
>
> Another point that cropped up was, monitoring. Obviously Charles and co
> have been working hard on beats, but there are a bunch of industry standard
> monitoring tools out there that sys admins will already use and be happy
> with Nagios, Zabbix etc + the commercial ones. Some charms already have
> Nagios monitoring points, but should it not be a requirement for all
> promulagated charms to have a monitoring endpoint. For example, we use
> Nagios on a bunch of our stuff, I should be able to say "hey, I'm gonna
> install this new charm" and know that I can hook it into our monitoring
> infrastructure without doing anything too crazy.
>
> Its all well and good selling Juju to Developers like myself or CTO's by
> the Ops guys have their "special ways" and making sure that charms fit into
> those ways will be key to adoption.
>
> Tom
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your service | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Is there a way to let juju know that an lxc container has gone away and isn't coming back?

[Charles Butler]

Happy to help! Glad it got you sorted.

All the best 

> On Apr 8, 2016, at 10:03 AM, Pete Vander Giessen <pet...@gmail.com> wrote:
> 
> @Charles: Aha! The various destroy commands don't have a --force flag; I 
> didn't know about the "remove-machine" command, which does accept --force.
> 
> That seemed to work. Thank you :-)
> 
> ~ PeteVG
> 
>> On Fri, Apr 8, 2016 at 9:47 AM Charles Butler <charles.but...@canonical.com> 
>> wrote:
>> I haven't validated this but you can try to remove the machine forcibly
>> 
>> Juju remove-machine ## --force
>> 
>> That should force removal of the container from the controller and let you 
>> destroy-service to remove it from the model.
>> 
>> 
>> 
>> > On Apr 8, 2016, at 8:56 AM, Pete Vander Giessen <pet...@gmail.com> wrote:
>> >
>> > Hi All,
>> >
>> > Let's say that someone (okay, me) is experimenting with juju2 (develop) 
>> > locally, and I've rudely destroyed an lxc container that had a juju charm 
>> > deployed to it (lxc stop  && lxc delete ).
>> >
>> > Is there a way to convince juju that the charm is no longer deployed? juju 
>> > destroy-service and juju destroy-unit both fail, because juju cannot 
>> > connect to the machine. Is there a way, short of clobbering 
>> > ~/.local/shrare/juju and attempting to start from scratch, of making juju 
>> > let go of the charm?
>> >
>> > Thank you in advance,
>> >
>> > ~ PeteVG
>> > --
>> > Juju mailing list
>> > Juju@lists.ubuntu.com
>> > Modify settings or unsubscribe at: 
>> > https://lists.ubuntu.com/mailman/listinfo/juju
> -- 
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Is there a way to let juju know that an lxc container has gone away and isn't coming back?

[Charles Butler]

I haven't validated this but you can try to remove the machine forcibly

Juju remove-machine ## --force

That should force removal of the container from the controller and let you 
destroy-service to remove it from the model.



> On Apr 8, 2016, at 8:56 AM, Pete Vander Giessen  wrote:
> 
> Hi All,
> 
> Let's say that someone (okay, me) is experimenting with juju2 (develop) 
> locally, and I've rudely destroyed an lxc container that had a juju charm 
> deployed to it (lxc stop  && lxc delete ).
> 
> Is there a way to convince juju that the charm is no longer deployed? juju 
> destroy-service and juju destroy-unit both fail, because juju cannot connect 
> to the machine. Is there a way, short of clobbering ~/.local/shrare/juju and 
> attempting to start from scratch, of making juju let go of the charm?
> 
> Thank you in advance,
> 
> ~ PeteVG
> -- 
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju

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

Re: Charm Store policy updates and refinement for 2.0

[Charles Butler]

Hey Stuart!

Thats a really good point about SSL on the interfaces service. I saw the
bug a few weeks back but it slipped my mind, and it surprised me to
discover its been there since 2015.

I'll work towards having a resolution on this in the next week or so and
will re-ping the list once its been TLS secure'd.

Thanks for beating the drum on this one, i've needed some motivation.

All the best,

On Mon, Mar 21, 2016 at 10:14 PM Stuart Bishop 
wrote:

> On 19 March 2016 at 02:58, Jorge O. Castro  wrote:
>
> > Recommendations from everyone on what we should include here would be
> > most welcome, specifically our recommendations around Windows charms
> > is non-existent.
>
> I think the acceptable software sources needs to be expanded.
> Launchpad PPAs should be acceptable as signing keys are securely
> retrieved when using 'add-apt-repository ppa:foo/bar'. Also, 3rd party
> apt repositories should be acceptable if the signing key is embedded
> in the charm (PyPi could be checked similarly, but it seems rare to
> find signed packages there).
>
> In addition, any software sources not in the main Ubuntu or CentOS
> archives should be listed in configuration items that can be
> overridden rather than hard coded in the charm, or else the charm is
> useless in network restricted environments (and yes, migrating to
> resources may be a better user experience in many cases).
>
> As examples, the PostgreSQL charm pulls non-default packages from the
> upstream PostgreSQL apt repository (PGDG, which is the source which
> flows to Debian and Ubuntu). The Cassandra charm pulls a required
> driver from a PPA I control. It also installs packages from either the
> Apache apt repository or the DataStax apt repository. Cassandra is not
> available in the Debian or Ubuntu main archives, probably as it
> required the Oracle JVM. Both charms use the
> install_sources/install_keys config items parsed by charm-helpers and
> the apt layer to make this configurable.
>
> On a side note, it is somewhat disingenuous to block charms in the
> store from pulling dependencies from untrusted sources at run time
> when we happily pull dependencies from untrusted sources at build
> time. I think the fix here is to do better at build time (Moving the
> interfaces web site to https: and ensuring clients use that address,
> only allowing https:, git+ssh: and other secure protocols for pulling
> branches, and checking GPG signatures of embedded wheels are the
> issues here I'm aware of)
>
> --
> Stuart Bishop 
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Container Ecosystem Update

[Charles Butler]

Greetings Everyone o/

There's a full writeup over on the blog space:
http://dasroot.net/posts/2016-03-22-containers-update/


I wanted to take some time to shed some light into what the containers team
has been up to these last couple weeks. Its been a very exciting time.

The highlights are:
 - Dashboard Anything in Juju with Elastic Beats and the beats-core bundle!
- Net code deletion of 1500+ lines in the upstream kubernetes repository -
Layers FTW!
- New ELK bundle
- New Logstash Charm
- New Beats charms (4 in total, 2 are 'stable')
- New Dashboard loading action in Kibana
- Kubernetes Log Aggregation, visualization, and storage (log dump from vis
to cold storage is still TODO:)


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

Re: Charm Store policy updates and refinement for 2.0

[Charles Butler]

Big +1 to the categories

What i'd like to see is the policy document move to strong language where
we can build tooling around the automated checking of policy.

Refactoring the MUSTS and SHOULDS give us a strong lead on that language.
MUST == has to be satisfied
SHOULD = area for improvement - (proper use of warn, which wont fail charm
proof for a change)

eg: We require OSI approved licenses, we can scan the copyright file for
that with a license bot to find the lingo of approved licenses, otherwise
it flags for human review. It may be an acceptable license we're not aware
of.

The more points in policy we can convert to strongly typed lingo, the more
targeted and automated we can make portions of policy review, and also
scopes the mission of ~charmers. A limited resource who is responsible for
enforcing this document.



On Fri, Mar 18, 2016 at 11:59 AM Jorge O. Castro  wrote:

> Hello everyone,
>
> With 2.0 around the corner we decided to spend some time cleaning up
> the page everyone loves to hate, the Juju Charm Store policy:
>
> https://jujucharms.com/docs/1.25/authors-charm-policy
>
> and here is what I would like to propose:
>
> https://github.com/castrojo/docs/blob/master/src/en/authors-charm-policy.md
>
> I've done a few things here:
>
> - I've separated it from one huge paragraph to sections, General,
> Testing and Quality requirements, Metadata requirements, and Security
> requirements.
> - I've split out things that a charm/bundle MUST do and what it SHOULD
> do in each section to make it clearer on what is a hard requirement
> and what is a recommendation.
> - I've removed most of the Ubuntu-specific jargon and generalized it
> to include other OSes such as CentOS.
> - Made documenting interfaces and external dependencies a requirement.
>
> There are also some new policies that we need ack from ~charmers in
> order to implement. Specifically we've made the testing and quality
> requirements explicit. I've also added a requirement of using Juju
> Resources (which appears to be undocumented?) for payloads.
>
> Recommendations from everyone on what we should include here would be
> most welcome, specifically our recommendations around Windows charms
> is non-existent.
>
>
> --
> Jorge Castro
> Canonical Ltd.
> http://jujucharms.com/ - The fastest way to model your service
>
> --
> 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: Get number of units

[Charles Butler]

Nice, I like this. +1 Marco

If we have a "tips and tricks" page or charmer snippets, this should live
there.


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Wed, Mar 2, 2016 at 6:45 AM, Marco Ceppi <marco.ce...@canonical.com>
wrote:

> To answer your question anyways, you can do this with the peers relation:
>
> ``` metadata.yaml
> peers:
> cluster:
> interface: my-service-cluster
> ```
>
> So, at anytime, in any hook you can do the following:
>
> ``` bash
> rid=$(relation-ids cluster)
> for unit in $(relation-list -r $rid); do
> echo "It's a  peer and confidant $unit"
> done
> ```
>
> However, since Juju gives unique numbers for each unit, you could use a
> units number to enumerate a port. You wouldn't need the peer relationship
> for this directly. As an example
>
> ``` bash
> port_start=4000
> port=$(expr $port_start + ${JUJU_UNIT_NAME##*/})
> ```
>
> So if it's unit/0 you'll get 4000, if it's unit/10 you'll get 4010, etc.
> Since unit numbers are unique in Juju you'll never get a conflict.
>
> Marco Ceppi
>
> On Wed, Mar 2, 2016 at 6:29 AM Tom Barber <t...@analytical-labs.com> wrote:
>
>> Scrap that, I have an alternative solution!
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> <http://kickstarter.com/projects/2117053714/saiku-reporting-interactive-report-designer/>
>> goal, but you can always help by sponsoring the project
>> <http://www.meteorite.bi/products/saiku/sponsorship>)
>>
>> On 2 March 2016 at 11:22, Tom Barber <t...@analytical-labs.com> wrote:
>>
>>> Morning
>>>
>>> I need to open an extra port for each unit in my charm, can I ask juju
>>> for a count of running units in a service?
>>>
>>> Thanks
>>>
>>> Tom
>>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] bird, neutron-calico, openbook, plumgrid-gateway

[Charles Butler]

Just as a follow up, I went ahead and merged the OpenBook MP, as it LGTM
aside from a few nits that really aren't blockers. Thanks for the attention
to detail.

All the best,


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of modeling your datacenter: http://jujucharms.com

On Mon, Jan 25, 2016 at 9:20 AM, Cory Johns <cory.jo...@canonical.com>
wrote:

> Greetings,
>
> This past Friday, Andrew, Konstantinos, and I spent some time on the
> review queue.
>
> We'd like to thank the fine folks at MetaSwitch for their work on the bird
> and neutron-calico charms, which add Project Calico and its virtual
> networking support to OpenStack.
>
>
>-
>
>bird
>-
>
>   https://bugs.launchpad.net/charms/+bug/1431445
>   -
>
>   Suggested changes were accepted.  Re-tested, passed, and the charm
>   was promulgated.
>   -
>
>neutron-calico
>-
>
>   https://bugs.launchpad.net/charms/+bug/1421230
>   -
>
>   Suggested changes were accepted.  Re-tested, passed, and the charm
>   was promulgated.
>   -
>
>openbook
>-
>
>
>   
> https://code.launchpad.net/~talligent/charms/trusty/openbook/trunk/+merge/280525
>   -
>
>   Tests all pass - this was held back due to long dashes in the
>   README and non-recommended tags in the metadata, neither of which will
>   affect charm functionality. Suggesting this be merged as the value of 
> the
>   charm outweighs potential README issues.
>   -
>
>plumgrid-gateway
>-
>
>
>   
> https://code.launchpad.net/~bbaqar/charms/trusty/plumgrid-gateway/charmers-next
>   -
>
>   Reviewing the fix for restarting the service in a timely fashion
>   yields some more questions.
>   -
>
>   The bundletester spotted some code style errors.
>   -
>
>   We will have to wait for a response from the author, before we
>   proceed with this merge.
>
>
> --
> 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: Does sftp eliminate the need to check sha1sum?

[Charles Butler]

Just as a word of calming against this our recommended patterns are to make
the payload you're fetching configurable:

such as fetch this particular tarball from server X with a shipping
SHA1/SHA256 sum of the payload to ensure a) its the same payload b) it
wasn't corrupted from the point of writing the charm to upgrading.

Shipping these upgrades via charm config leaves existing deployments at
their version, only new deployments will upgrade the components, and users
are still left to "manually upgrade" by changing the charm config, which
should keep you from seeing major breakage unless shipping components
contain the defect as outlined above.

The charm should handle upgrades, vs the user 'creating' the change.

The GPG approach is interesting, as its replicates some of the "trusted
registry" features i've been tracking on the app container side, where we
have warm fuzzies knowing that our image passes a validity hash match, and
further is verified against the developers signature w/ the hub, so we know
they signed the release.

I like these ideas, keep up the good work @cory


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Thu, Jan 14, 2016 at 7:36 AM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Please note that this doesn't have to be a burden on the vetting process.
> The vetting process for an updated binary can be more or less automated,
> especially with the upcoming juju resources. The important part is that
> every time the binary changes, the charm version has to be bumped.
>
> 2016-01-14 13:29 GMT+01:00 Merlijn Sebrechts <merlijn.sebrec...@gmail.com>
> :
>
>> hi all, Sorry to barge in like this, but this is very important for my
>> use-case.
>>
>>
>> Binaries that are downloaded always need to be checked using a checksum 
>> *included
>> in the charm*.
>>
>> One Charm version should always deploy the *exact same version of that
>> service*. If you want Juju to be used in production, *Charm deployment
>> has to be reproducible*. Please do not force people who use Juju in
>> production to fork all the Charms they use. Store Charms should be good
>> enough so they can be used in production.
>>
>> Consider the use-case of a platform that automatically scales a service
>> up and down depending on usage. This will break if we allow Charms to be
>> changed between versions. This has bitten me once already. The Hadoop
>> Charms downloads the jujubigdata pip dependency and uses code in this
>> dependency for communication between units. Because of an oversight, two
>> versions of this pip dependency were not compatible with each other. This
>> meant that running `juju add-unit` on an existing Hadoop installation was
>> successful one day and failed the next.
>>
>> I understand why the Hadoop Charms were build this way, it is a lot
>> easier to maintain. However layers fix the maintenance issue.
>>
>> We do not know who uses our Charms and for what, so *there is no way we
>> can reliably determine if a change would break a use case*. Yes, this
>> change could fix a bug but there could be some service relying on this bug
>> to be present. Because of this, one version of a Charm must always deploy
>> the exact same thing. Let the users handle the upgrade process themselves.
>>
>> There are examples enough of cases where even minor version changes of
>> binaries break relationships, so one version of a charm must always deploy
>> the same binary.
>>
>>
>>
>> Kind regards
>> Merlijn Sebrechts
>>
>> 2016-01-14 12:42 GMT+01:00 Cory Johns <cory.jo...@canonical.com>:
>>
>>> My preference over hard-coding a checksum into the charm would be
>>> hosting a GPG signature alongside the file and including the public key in
>>> the charm.  This allows the charm author to update a file if necessary
>>> without having to also update the charm, but also allows the charm to
>>> confirm that it got the file as intended by the author.
>>>
>>> Hopefully, though, this will become moot with the advent of resources
>>> support in Juju 2.0.
>>>
>>> On Thu, Jan 14, 2016 at 1:48 AM, Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
>>>> On Thu, Jan 14, 2016 at 3:23 AM José Antonio Rey <j...@ubuntu.com>
>>>> wrote:
>>>>
>>>>> I think this is more of a discusion on if you got 'what' you wanted or
>>>>> if you got it from 'where' you wanted. Even if you used SFTP, the file
>>>>> could've changed, and 

Re: Regarding Hadoop Charm - Role based implementation

[Charles Butler]

Greetings Shilpa,

I'm cross posting this to the juju mailing list, as there are probably
others who have had, or have the same question about using a single charm,
with multiple supporting roles. I would highly encourage you to engage the
mailing list as you develop questions about Juju, so that other users may
chime in with their experience.

With regard to changing how the charm deploys/interacts at runtime based on
relations. It's been noted that while this may ease some of the maintenance
burden of the charm author - this also causes confusion to users when they
are deploying the stack. If this is along the lines of needing a service
group leader, and each additional node becomes a follower unit
participating in the cluster, I would encourage you to use the leadership
features of juju

https://jujucharms.com/docs/stable/authors-charm-leadership


If you need to do raidcally different configuration of the software based
on what 'role' the charm is deployed as, it may be worth investigating the
work required to split the charm into layers, abstract the base delivery of
the software into a shared layer, and encapsulating the 'roles' into an
additional layer, and outputting 2 charms. As that will have a clear
definition of how to deploy the software, especially when you distribute
the recommended setup as a bundle.

Now that i've spoken my peace against a single charm with multiple roles,
in the spirit of answering the original question:

To do this you will need to have a few concerns lined out before hand, such
as what messaging you need to give to your user

- if the user only deploys the LSF charm by itself, with no additional
units, should it do anything? as in deploy in standalone mode
- If the user adds units, will this depend on leader data?

- If we need this secondary "role" to be related to enable the workload in
its most basic form, what messaging is required to do so?


With the pre-reqs sorted, and plotted - i'm going to assume the answer to
the last bullet point was "we need the secondary role, and we have a
relation for lsf-controller and lsf-node. both are encapsulated in the same
charm

As you deploy the LSF charm, you can check for the present of the relation.
In reactive this is fairly trivial, as relations consume interfaces, and
these interfaces establish states on the unit to identify that indeed the
relationship is present.

Looking over the HTTP interface, as an example - we see that the interface
 sets a state for the relation consuming the interface to .available.
https://github.com/juju-solutions/interface-http/blob/master/provides.py#L12



You can then decorate a method body on the receiving side with this:

@when('lsf-controller.available')
setup_controller(){
  # method body to setup the controller
}

@when('lsf-node.available')
setup_node(){
  # method body to setup the node
}

Each body is basically responsible for executing the setup portion that is
specific to configuring the LSF daemon for that 'role'. and you've
encapsulated 2 different roles in the same charm, dictated by
relationships.

All the best,

Charles

Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Mon, Dec 14, 2015 at 12:35 PM, Shilpa Kaul <shilk...@in.ibm.com> wrote:

> Hi Charles,
>
> I am working on IBM Platform LSF charm where I have to implement different
> hosts types of LSF to form a LSF Cluster. I was going through the juju docs
> where I read about the topic : charms-service-groups - Roles where services
> acquire a role at runtime based on the relations that are joined. Hadoop
> charm is an example where this role concept is implemented.I am not so
> clear that how services can acquire role at run time?.
> What I could understand is that I can deploy one charm but different
> service names and then having relations between these services.
>
> I was thinking to implement something similar for my LSF charm ,where I
> have one charm , say ibm-platform-lsf
> juju
> deploy ibm-platform-lsf  lsf-master
> juju
> deploy ibm-platform-lsf lsf-server
> juju
> deploy ibm-platform-lsf lsf-master-candidate
>
> So based upon the host type, I am deploying one single charm, but
> different service names during deployment and then adding relations among
> them, for example
>   juju
> add-relation lsf-server:server-host lsf-master:master-host
>
> I believe Hadoop charm is also implemented like this , please let me know
> if my understanding is correct.
>
> Also, if this is the case ie deploying one charm but different service
> names, then how we can do t

[Review Queue] ubuntu, plumgrid-edge,

[Charles Butler]

Ubuntu -
https://code.launchpad.net/~1chb1n/charms/trusty/ubuntu/amulet-sentry-unit-array/+merge/276712

+1 LGTM


Plumgrid Edge -
https://code.launchpad.net/~bbaqar/charms/trusty/plumgrid-edge/charmstore/+merge/277507

+1 LGTM

Plumgrid-Gateway -
https://code.launchpad.net/~bbaqar/charms/trusty/plumgrid-gateway/charmers-next/+merge/278253

-1 for now, needs information



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Blog] - Charmer Interviews

[Charles Butler]

Greetings,

As some of you may have noticed we (somewhat silently) published a video
interview with Adam Stokes over on the Juju youtube channel:

https://www.youtube.com/watch?v=lowRfWcxky0

This video interview gives a brief introduction to Adam, his take on
charming with layers and the reactive pattern, and goes on in depth to
cover his work with the NodeJS runtime layer for charmers looking to charm
up their NodeJS apps.

If you're working in this space, and are interested in getting a community
spotlight on your work - or even just want to talk about your experience
with layers and the reactive framework, let me know and I'll be happy to
schedule some time to hop on a hangout, record the interaction(s) and put
together a post similar to the above.

If you're interested in doing your own interviews, media kits, et-al feel
free to reach out. I've started an initiative to help our developers get
the word out about their awesome work. The world will only know about what
we're up to if we're telling them. This really helps our narrative as we
make the big push towards 1.26 - And a solid media profile of all the
greatness we've cranked out since 1.25 has landed will help us tell that
narrative. Food for thought :)

All the best,

Charles



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Error in deploying wordpress

[Charles Butler]

Greetings Dinesh,

This is indeed some strange behavior. I see this is a local charm
deployment. Was this a copy from the charm store?

If so, can you file a bug against the wordpress charm here:
https://bugs.launchpad.net/charms/+source/wordpress and attach the
wordpress unit logs so we can take a look at why this may have failed?

Sorry you ran into this, and we'll be happy to take a look.

All the best,

Charles


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Thu, Nov 19, 2015 at 4:10 AM, <dinesh.senap...@wipro.com> wrote:

> Hi,
>
>
>
> Am using manual provisioning to deploy wordpress on a machine and am
> getting the following error. When using “juju resolved --retry wordpress/0”
> got “ERROR unit "wordpress/0" is not in an error state”. Can anyone help me
> out?
>
> Juju version : 1.24.7-trusty-amd64
>
>
>
>
>
> Regards,
>
> Dinesh
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Blog] - Charmer Interviews

[Charles Butler]

It will look very similar to how charms are written today only you will use
the reactive pattern to call your playbook with a particular tag.

Hope this helps :)


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Thu, Nov 19, 2015 at 10:57 AM, Sebastian <sebas5...@gmail.com> wrote:

> Thanks Charles and Adam!, the interview was really useful to understand
> how this new way of developing charms works.
>
> How Ansible charms could be developed with layers?
>
> Em qui, 19 de nov de 2015 às 13:29, Rick Harding <
> rick.hard...@canonical.com> escreveu:
>
>> Great stuff Chuck and thanks for walking through this Adam. We should
>> definitely do some more of these and please make sure to share this stuff
>> out to folks who are interested in what we're up to and things like this
>> have some great real work examples to work with.
>>
>>
>> On Thu, Nov 19, 2015 at 6:32 AM Charles Butler <
>> charles.but...@canonical.com> wrote:
>>
>>> Greetings,
>>>
>>> As some of you may have noticed we (somewhat silently) published a video
>>> interview with Adam Stokes over on the Juju youtube channel:
>>>
>>> https://www.youtube.com/watch?v=lowRfWcxky0
>>>
>>> This video interview gives a brief introduction to Adam, his take on
>>> charming with layers and the reactive pattern, and goes on in depth to
>>> cover his work with the NodeJS runtime layer for charmers looking to charm
>>> up their NodeJS apps.
>>>
>>> If you're working in this space, and are interested in getting a
>>> community spotlight on your work - or even just want to talk about your
>>> experience with layers and the reactive framework, let me know and I'll be
>>> happy to schedule some time to hop on a hangout, record the interaction(s)
>>> and put together a post similar to the above.
>>>
>>> If you're interested in doing your own interviews, media kits, et-al
>>> feel free to reach out. I've started an initiative to help our developers
>>> get the word out about their awesome work. The world will only know about
>>> what we're up to if we're telling them. This really helps our narrative as
>>> we make the big push towards 1.26 - And a solid media profile of all the
>>> greatness we've cranked out since 1.25 has landed will help us tell that
>>> narrative. Food for thought :)
>>>
>>> All the best,
>>>
>>> Charles
>>>
>>>
>>>
>>> Charles Butler <charles.but...@canonical.com> - Juju Charmer
>>> Come see the future of datacenter orchestration: http://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

Re: Boot VM using JUJU

[Charles Butler]

Greetings,

to expand on Jose's answer:

In the manual provider, the enlistment phase is, as you may have guessed,
manual. The requirements are: must be reachable over SSH from the juju
controller and a user with passwordless sudo.

You can add any machine to any environment manually via:

juju add-machine ssh:user@host

Let us know if you run into any troubles.

All the best,

Charles


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Mon, Nov 16, 2015 at 6:22 AM, <dinesh.senap...@wipro.com> wrote:

> Hi,
>
>
>
> Is it possible to boot a VM using JUJU in manual provisioning environment
> and deploy charms on that VM?
>
>
>
> Regards,
>
> Dinesh
> The information contained in this electronic message and any attachments
> to this message are intended for the exclusive use of the addressee(s) and
> may contain proprietary, confidential or privileged information. If you are
> not the intended recipient, you should not disseminate, distribute or copy
> this e-mail. Please notify the sender immediately and destroy all copies of
> this message and any attachments. WARNING: Computer viruses can be
> transmitted via email. The recipient should check this email and any
> attachments for the presence of viruses. The company accepts no liability
> for any damage caused by any virus transmitted by this email.
> www.wipro.com
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju and monitoring systems

[Charles Butler]

As promised, here's the Zabbix bits along with some additional info:

Start from here : https://github.com/thomnico/juju-nfv-clearwater-restcomm



https://www.youtube.com/watch?v=IF7bUgDCYMM

https://github.com/SaMnCo/ob-zabbix
Direct commentary from the developer(s):

the ob-zabbix is important as it has a default behavior in the SQL DB for
Zabbix that enables easy recognition of workloads spawned by Juju and
auto-adding them to a group of devices

thus you can quickly create group triggers and autoscaling

however, the model is VERY simple







there is no machine learning or funky stuff

This is a demo-ware application implementation, it will double the number
of units every time there is a problem, but this provides some early
insight/view into where we've looked at addressing the question leveraging
third party tooling.





Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Fri, Nov 13, 2015 at 9:45 AM, Charles Butler <
charles.but...@canonical.com> wrote:

>
> On Fri, Nov 13, 2015 at 9:42 AM, Vasiliy Tolstov <v.tols...@selfip.ru>
> wrote:
>
>> May be the best look at https://github.com/prometheus/node_exporter
>> for by default enabled metrics.
>>
>
> This sounds like a prime case for a charm, and then wrapping your business
> logic for scaling into a charm that can take action on your behalf. Its not
> ideal as the final solution but would work well for a POC. We have similar
> work already done by nico-thomas and scozannet using Zabbix to auto-scale a
> telephony/voip video conferencing solution w/ clearwater.
>
> I'll see if i can find the material Nicholas showed during a sprint and
> forward that along as a reference guide, but it sounds right up your alley
> as an alternate implementation, but achieves the same result(s).
>
>
> Charles Butler <charles.but...@canonical.com> - Juju Charmer
> Come see the future of datacenter orchestration: http://jujucharms.com
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

[Review Queue] - Nuage VSRG

[Charles Butler]

I took some time to look at the Nuage VSRG charm today, it is a solid first
round submissino but needs additional work. -1 for now but i'm confident it
will be ready soon

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

Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju and monitoring systems

[Charles Butler]

Vasilily,

I've been taking a deep look at prometheus lately - namely due to the claim
of their top end benchmark of 360 thousand metric ingests per second on a
beefy modern host. This intrigued me as to the use cases for prometheus.
And seeing it being baked into the k8s apiserver for metric exports gave it
additional credibility for being investigated.

Rick's answer pretty much falls in line with what my analysis would be,
that we dont have it on any road maps today, however an ingest for
prometheus should be possible with some effort on both sides - the
prometheus charm maintainer (tbd) and then the metric scrapers for juju
(tbd).

If this is something you are interested in, I think this conversation is a
good starting point to look at what really needs to be done, and can be
prototyped outside of juju core as a POC. If it gains traction, that would
be a good identifier for it to be prioritized in a future iteration.

As a bit of a curiosity, what metrics are you looking for?

All the best,

Charles


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Fri, Nov 13, 2015 at 8:32 AM, Vasiliy Tolstov <v.tols...@selfip.ru>
wrote:

> 2015-11-13 15:49 GMT+03:00 Rick Harding <rick.hard...@canonical.com>:
> > Awesome to hear you're enjoying Juju Vasiliy. We don't currently have
> plans
> > to build monitoring directly into Juju. We've found most places have
> their
> > preferred tool for that, zabbix, munin, nagios, etc. We love that folks
> have
> > built charms that allow integration of their preferred tool through
> charms
> > that are typically used as subordinate services. It looks like prometheus
> > would be another service along those lines that would be great to charm
> for
> > use.
>
>
> Thats fine, but does juju agent support endpoints to export
> performance metrics from the running machine?
> Zabbix, munina and other need to create own tools to check this, but
> if juju agent have ability via some endpoints export needed data each
> monitoring solutions can use this and not create hand made tools =)
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: juju and monitoring systems

[Charles Butler]

On Fri, Nov 13, 2015 at 9:42 AM, Vasiliy Tolstov <v.tols...@selfip.ru>
wrote:

> May be the best look at https://github.com/prometheus/node_exporter
> for by default enabled metrics.
>

This sounds like a prime case for a charm, and then wrapping your business
logic for scaling into a charm that can take action on your behalf. Its not
ideal as the final solution but would work well for a POC. We have similar
work already done by nico-thomas and scozannet using Zabbix to auto-scale a
telephony/voip video conferencing solution w/ clearwater.

I'll see if i can find the material Nicholas showed during a sprint and
forward that along as a reference guide, but it sounds right up your alley
as an alternate implementation, but achieves the same result(s).


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

[Review Queue] MariaDB, Midonet, MongoDB, MediaWiki, Ubuntu-repository-cache, Kibana

[Charles Butler]

MariaDB - MariaDB has updated their product delivery mechanism to fetching
a bin from behind a tokenized paywall. These changes are +1'd - but have
not been officially proposed for the charm store

http://bazaar.launchpad.net/~dbart/charms/trusty/mariadb/trunk

Midonet - Still running into firewall access issues on this bundle, as
datastax and repo.midonet.com are both inaccessible from within server
stack, pending a resolution before I'm able to properly identify that the
bundle indeed works.

MongoDB - Mattyw proposed a backup/restore action for MongoDB. This is a
welcome change and example of actions in a charm reducing the need to ssh
into a remote unit to perform admin tasks. Simply run the action to
mongodump, scp the files over and run the action for mongorestore

https://code.launchpad.net/~mattyw/charms/trusty/mongodb/mongodb-backup/+merge/273544

After a bit of back and forth with osci, this is +1'd and merged

Mediawiki -  Tim updated memcache, kevin updated the validation routines to
flex the workload in question and properly follow the URI routes.

+1'd and merged

https://code.launchpad.net/~tvansteenburgh/charms/trusty/mediawiki/fix-tests/+merge/271875


UbuntuRepositoryCache - Slight readme update - +1'd and merged

https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/readme_tweak/+merge/275011

Kibana  - Chric McNaughton updated the Kibana version from 3.x to 4.x. Test
coverage verifies the
upgrade. +1'd and merged

https://code.launchpad.net/~chris.macnaughton/charms/trusty/kibana/version_bump/+merge/274029



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] Hectane

[Charles Butler]

I had a chance to review the Hectane charm today from Nathan Osman, its a
GoLang based API that aim at being a simple email service (similar to
mandrill). The charm was a great first submission, and well formed. It's
been +1'd and promulgated.

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



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: nodejs reactive layer

[Charles Butler]

ely reasonable. Perhaps ship some extra bits in the node
layer if applicable to handle common/routine node tasks, and include
actions to perform things like module cleanup, et-al (?)

All in all it sounds like you're well on your way to charming in reactive,
and I'd like to thank you for your interest and reaching out about it.
These are exciting times for early adopters :) We're shaping the future of
charm writing as we know it.

All the best,



Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Mon, Oct 19, 2015 at 11:08 AM, Adam Stokes <adam.sto...@canonical.com>
wrote:

> Additionally I was hoping I could just layer my application on top of the
> nodejs layer and have my node version available to the application layer so
> it would look like:
>
> - base layer
> - node layer
> - application api layer
>
> The application api layer would then have access to node/npm during charm
> deployment and be able to react to node's layer state. However, in testing
> this out it doesn't look like my application layer ever gets executed once
> the node layer has finished.
>
> My thinking was that in order to test multiple node versions for my
> application all I would need to do is deploy the charm with the node layers
> default version configuration. To give you a better idea this is my api
> service layer for an application I have:
>
> https://github.com/wffm/juju-layer-wffmapi
>
> That layer inherits from my node layer which inherits the base layer. I
> was hoping to keep each layer's responsibility to just one thing, ie node
> layer only installs node.js and exposes its installed state.
>
> On Mon, Oct 19, 2015 at 9:23 AM, Adam Stokes <adam.sto...@canonical.com>
> wrote:
>
>> I'm looking to get my nodejs layer[1] included at
>> http://interfaces.juju.solutions and wanted to make sure that this charm
>> can be properly tested. I noticed that a Makefile is generated during
>> `charm-compose` and was curious how I can utilize that with amulet or
>> whatever the preferred way to test charms is. The amulet documentation
>> doesn't really go into how to actually run the tests locally so I can
>> easily verify my charm. Is there a how-to on the preferred (blessed) way of
>> testing charms locally?
>>
>> For the curious my charm layer simply installs Node.js based on whatever
>> version you set in the config (0.10, 0.12, 4.x) and will be used when
>> deploying whatever node app you require.
>>
>> Oh one other thing, I didn't see how to pass config options in amulet's
>> deploy so that I can test my different default versions from the config.
>>
>> 1: https://github.com/battlemidget/juju-layer-node
>>
>> Thanks!
>>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [ Docs ] - Charming with Docker

[Charles Butler]

Kapil,

Great points, and we covered some of these pre-planning steps with users at
the Charmer Summit. What I came away with was the following, and it falls
in alignment with your analysis as well:

Actions for doing Image Garbage Collection
Actions for doing Container Garbage Collection in blue/green deployment
scenarios
Logspout based log shipping to start, with syslog and PAAS connectors (see:
papertrail sub) as stretch goals
Auto-scale with Swarm when swarm config=true (no additional charm, no
additional work on the end user. "magic")
Relation with private registry (pending) to alter behavior to always
poll/pull from a PR
-Experimental- LibNetwork based layers to extend the behavior to include
Weave, Calico, Flannel, Fan as options

These were 1:1 with what you outlined, and what our user base I was
communicating with over the summit agreed upon. So really good tip in terms
of what you want to see from the stack.

I'm still working through getting the spec put together, and working
through some of the sample code for what this looks like in terms of how
the layers will piece together, what lives where, and how many resulting
charms we gain from the layers + subscribable events for consuming app
containers charm layers.

All the best,

Charles


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Tue, Sep 15, 2015 at 8:17 PM, Kapil Thangavelu <kap...@gmail.com> wrote:

>
>
> On Tue, Sep 15, 2015 at 9:25 AM, Charles Butler <
> charles.but...@canonical.com> wrote:
>
>> I see your concerns about layering, reactive, et-al. for introductory/new
>> charmers. I however raise you a value proposition, and will speak to
>> the point we are generating the 'best practice' method, that we want to
>> guide charmers down. The common feedback we've received from
>> authors is "I'm not as concerned with the overhead of learning, I just
>> want you to tell me the best way to do it." While this represents a small
>> number from the overall community of people charming, we've delivered on
>> this asked behavior. We're taking away some maintenance
>> burdens, and exposing a scaffolded framework to deliver your app
>> containerized workload.
>>
>
> That's fair, it feels pretty good as an intro to best practices guide for
> writing reactive style python charms working in an ecosystem with reuse and
> extensibility.
>
>
>>
>> While its arguably more complex than `curl get.docker.com | sh` - there
>> are a few things happening here that should concern you already.
>>
>> - You're not verifying the payload, and blindly executing it via a shell.
>> This violates charm store policy, and is a black hole into whats happening
>> without tailing the unit logs.
>>
>
>> While the script is a replica of that installation method, (credit is
>> given in the layer repository readme) it was deemed important to mimic
>> their recommended install - when you look at the ansible based docker
>> charm and its divergent history + issue log.
>>
>> The script has been modified to surface what the unit is doing via the
>> newer `juju status-set` routines  for clear visibility. And we get the
>> added benefit of supporting  cent/debian out of the box with this method.
>> The ownership burden is on  us, the ~charmers that are maintaining
>> the docker layer.
>>
>
>> I appreciate the feedback though Kapil, and thanks for acknowledging the
>> raise in knowledge to 'get started' - you're right its not as straight
>> forward as curling a bash script and piping to sudo. But we don't
>> encourage that anyway :) We feel that you can learn and get productive with
>> this
>> fairly quickly, with minimal knowledge of whats actually happening layers
>> below. Just look at what states become exposed and take action.
>>
>>
> i think you misunderstood the download analogy, apt-get install docker is
> equivalent in this context or downloading over ssl with checksum and cert
> verification and pipe into shell. the concern and question was the best way
> to introduce folks to using juju with docker when the alternative is two
> lines of shell script.  ie. the comparison for the nginx example an install
> hook.
>
> apt-get install docker.io
>
> and a start hook
>
> docker run -p 80:80 dockerfile/nginx -v  html_dir:/var/www/html
>
>
>
>> Give it a spin and let us know if you've changed your opinion at all, and
>> I'll be happy to talk/work through the concerns.
>>
>
>
> as far as adoption goes, an easy on ramp up the learning curve matters.
> docker, terraform, packer, ansible, all great examples 

[Review Queue] Postgresql, IBM LSF Platform

[Charles Butler]

https://code.launchpad.net/~stub/charms/trusty/postgresql/rewrite-charmhelpers/+merge/267645

Quick sync charm helpers into PGSQL to break apart the noise from
features/fixes. +1 and merged


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

IBM LSF is a high performance workload management platform for distributed
compute jobs. The charm is well done for a first submission, and has a few
nitpicks that need to be addressed before it can be accepted, but i am
confident these changes are minor and will be fixed soon. -1 for now

All the best,


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [ Docs ] - Charming with Docker

[Charles Butler]

I see your concerns about layering, reactive, et-al. for introductory/new
charmers. I however raise you a value proposition, and will speak to
the point we are generating the 'best practice' method, that we want to
guide charmers down. The common feedback we've received from
authors is "I'm not as concerned with the overhead of learning, I just want
you to tell me the best way to do it." While this represents a small
number from the overall community of people charming, we've delivered on
this asked behavior. We're taking away some maintenance
burdens, and exposing a scaffolded framework to deliver your app
containerized workload.

While its arguably more complex than `curl get.docker.com | sh` - there are
a few things happening here that should concern you already.

- You're not verifying the payload, and blindly executing it via a shell.
This violates charm store policy, and is a black hole into whats happening
without tailing the unit logs.

While the script is a replica of that installation method, (credit is given
in the layer repository readme) it was deemed important to mimic
their recommended install - when you look at the ansible based docker charm
and its divergent history + issue log.

The script has been modified to surface what the unit is doing via the
newer `juju status-set` routines  for clear visibility. And we get the
added benefit of supporting  cent/debian out of the box with this method.
The ownership burden is on  us, the ~charmers that are maintaining
the docker layer.

I appreciate the feedback though Kapil, and thanks for acknowledging the
raise in knowledge to 'get started' - you're right its not as straight
forward as curling a bash script and piping to sudo. But we don't encourage
that anyway :) We feel that you can learn and get productive with this
fairly quickly, with minimal knowledge of whats actually happening layers
below. Just look at what states become exposed and take action.

Give it a spin and let us know if you've changed your opinion at all, and
I'll be happy to talk/work through the concerns.

- Charles




Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Tue, Sep 15, 2015 at 7:46 AM, Kapil Thangavelu <kap...@gmail.com> wrote:

> i think participating in the burgeoning docker ecosystem is a worthwhile
> goal by making it easier to write charms that utilize docker. I do have
> some concerns though about the complexity of the layering that's taking
> place in the charm ecosystem. I've found that juju has been fairly hard to
> teach and adapt to real world usage and the layering of frameworks at the
> charm authoring level makes learning and productivity for new users even
> harder to achieve (ie those docs reference, charm helpers, reactive charm
> helpers, docker reactive 'layer', charm composition), all of which are
> fairly advanced concepts to a new user, and frankly is all of that
> nescessary to understand running a shell script
> https://github.com/juju-solutions/layer-docker/blob/master/scripts/install_docker.sh
> which is effectively the jujuized version of (curl get.docker.com | sh)
> .. now say i want to configure an insecure registry or any other docker cli
> param i have to break apart the layer abstraction anyways. It does seem
> like a useful intro to some of the advanced/additional concepts in charm
> authoring ecosystem, but at the same time the burden seems high (ie. kiss
> violation) for how to run a docker container.
>
> cheers,
>
> Kapil
>
>
> On Fri, Sep 11, 2015 at 11:40 AM, Charles Butler <
> charles.but...@canonical.com> wrote:
>
>> If anyone here is interested in delivering Docker App Containers with
>> Juju, mbruzek and I have put together some documents around a hot new
>> process using composer layers and the reactive framework.
>>
>> This is interesting because you the charm author will only be concerned
>> with how to deliver your application layers logic. You don't need to worry
>> about installing docker, or how to scaffold out a full charm boilerplate.
>> This entire process reduces the total cost of ownership of the author to
>> just managing their app layer + container.
>>
>>  https://github.com/juju/docs/pull/672
>>
>> And we've constructed/linked to an example charm using this process.
>> There's probably holes in this document, and welcome feedback directly on
>> the pull request to suss them out.
>>
>> We're fully interested in receiving your feedback about this, as its
>> important that we are properly engaging our users that are interested in
>> delivering their dockerized app with Juju, and that we've given you the
>> proper lessons to do so easily, and made the right decisions in tooling.
>>
>> All the 

Re: [ Docs ] - Charming with Docker

[Charles Butler]

You are our target audience Ed.

If viewing that Pull Request is a bit difficult on the eyes, here's the
original drafts we composed.

https://github.com/juju-solutions/tupperware/blob/master/charming-with-docker.md
https://github.com/juju-solutions/tupperware/blob/master/reactive-charming-details.md

The associated docs above were condensed and placed as a single page doc in
the linked PR.


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Fri, Sep 11, 2015 at 11:45 AM, Ed Bond <celpa.f...@gmail.com> wrote:

> I would love to see some of the documentation around it. I was writing
> some charms around a docker wrapper and would love to not have to worry
> about the container layer.
>
> -Firl
>
> On Sep 11, 2015, at 10:40 AM, Charles Butler <charles.but...@canonical.com>
> wrote:
>
> If anyone here is interested in delivering Docker App Containers with
> Juju, mbruzek and I have put together some documents around a hot new
> process using composer layers and the reactive framework.
>
> This is interesting because you the charm author will only be concerned
> with how to deliver your application layers logic. You don't need to worry
> about installing docker, or how to scaffold out a full charm boilerplate.
> This entire process reduces the total cost of ownership of the author to
> just managing their app layer + container.
>
>  https://github.com/juju/docs/pull/672
>
> And we've constructed/linked to an example charm using this process.
> There's probably holes in this document, and welcome feedback directly on
> the pull request to suss them out.
>
> We're fully interested in receiving your feedback about this, as its
> important that we are properly engaging our users that are interested in
> delivering their dockerized app with Juju, and that we've given you the
> proper lessons to do so easily, and made the right decisions in tooling.
>
> All the best,
>
>
> Charles Butler <charles.but...@canonical.com> - Juju Charmer
> Come see the future of datacenter orchestration: http://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

[Review Queue] PLUMgrid ONS Components

[Charles Butler]

neutron-api-plumgrid - Approved and promulgated
neutron-api-plumgrid charm is an extension to neutron SDN to enable the
PLUMgrid platform
https://bugs.launchpad.net/charms/+bug/1459559

plumgrid-director - Approved and promulgated
PLUMgrid director is the brains of the Plumgrid Platform
https://bugs.launchpad.net/charms/+bug/1459568

plumgrid-edge - Approved and promulgated
PLUMgrid-Edge is SDN enablement for compute nodes
https://bugs.launchpad.net/charms/+bug/1459570

plumgrid-gateway - Approved and promulgated
PLUMgrid-gateway is an interface into legacy or physical network endpoints
https://bugs.launchpad.net/charms/+bug/1459572

These four components round out the basic stack for Plumgrid Openstack
enablement. there are stil OpenStack charms pending approval from the
~openstack-charmers team and a bundle on the way that should be landing
sometime this week.

Its great to see the PLUMgrid components start to fruit, growing our
OpenStack SDN solution ecosystem. Congrats Bilal, on the hard work that
went into landing these charms.


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Cheryl graduating

[Charles Butler]

HI5 Cheryl! Way to go!


Charles Butler <charles.but...@canonical.com> - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Mon, Aug 31, 2015 at 9:46 PM, Tim Penhey <tim.pen...@canonical.com>
wrote:

> Hi folks,
>
> I have been very happy with the quality of Cheryl's reviews and the time
> is right for her to be considered a fully graduated reviewer.
>
> Thanks for all the reviews Cheryl.
>
> Tim
>
> --
> 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 in (to ~charmers)

[Charles Butler]

I'm not certain how I missed this application, but I want to resurrect it
briefly to give my +1 and say Welcome to the team! You waited entirely too
long Kevin. Your contributions to the charming ecosystem speak for
themselves with your diligence in the Big Data ecosystem and onboarding of
the ~ibm-charmers work you do with mbruzek every week.

And I agree, most improved is a pretty fitting title :)


Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Mon, Aug 10, 2015 at 12:39 PM, 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

Re: [ANN] Amulet 1.11.0 released

[Charles Butler]

Excellent news!

Thanks for the continued work on Amulet this cycle Marco. Lots of features
I've been wanting have been cut. I look forward to getting some feedback to
you in the next week or two.


Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Wed, Aug 19, 2015 at 11:32 AM, Marco Ceppi marco.ce...@canonical.com
wrote:

 Hello,

 I'm happy to announce the Amulet 1.11.0 release. You can install and
 upgrade amulet from the juju stable ppa:

 sudo add-apt-repository ppa:juju/stable
 sudo apt-get update
 sudo apt-get install amulet

 For all other users, amulet is available in pip

 pip install amulet

 # Highlights

 Some highlights in this release

 - Ability to run actions through amulet
 - Support for the --to flag when adding services
 - Fixes to bundle parsing
 - Fixes to local charm, git charm, and uncommitted workflows

 See the full log below for all changes

 # Release notes

 These are the commits included in this release:

 6a15ee1 For local charms, use absolute path.
 e6fbe62 Add unique constraints from the environment to those explicit in
 the test
 5878b12 Use constraints from JUJU_TEST_CONSTRAINTS environment variable,
 if set.
 b3f106a Small bugfixes and linting cleanup
 226614a Fix status test
 4f36737 Fixes #77: pass '--format yaml' to juju status
 2b66205 Fixes #58: Refactor LocalCharm cleanup
 35375ba Added action support to amulet.
 0528c76 Respect when expose is set in a bundle fixes lp:1473580
 0dcc7ec Allow a target to be specified to Deployment.add_unit().

 Special thanks to all contributors for this release:

 - Tim Van Steenburgh
 - Bjorn Tillenius
 - Domas Monkus
 - Dann Frazier

 For any questions and support you can mail this list (
 juju@lists.ubuntu.com), find us on freenode in #juju, or
 http://askubuntu.com with questions tagged amulet. Any issues or bugs can
 be reported against the launchpad project: https://launchpad.net/amulet

 Thanks,
 Marco Ceppi

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


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

LazyPower out attending DOD PGH 2015

[Charles Butler]

I'll be attending Devops Days 2015 here in my back yard of Pittsburgh PA.

http://www.devopsdays.org/events/2015-pittsburgh/

If anyone is attending, feel free to hit me up and we can sync at the
conference. Perhaps you're doing something interesting with Juju that we'd
love to talk about :)

At any rate, i'll be in limited connectivity over the next 2 days to finish
out my week, so if there's anything pressing email would be the best way to
reach me and receive a timely response.

All the best,

Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] Big Data Ingestion Charms promulgated

[Charles Butler]

+ 1. https://bugs.launchpad.net/charms/+bug/1478771 Apache Flume HDFS
+ 2. https://bugs.launchpad.net/charms/+bug/1478770 Apache Flume Syslog
+ 3. https://bugs.launchpad.net/charms/+bug/1478772  Apache Flume Twitter

All three were quality releases, and have been promulgated to the charm
store.

Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] IBM Java SDK

[Charles Butler]

-1 IBM Java SDK - https://bugs.launchpad.net/charms/+bug/1477067

The charm is progressing nicely as a first iteration, there is still some
cleanup to be done here around the charm project files, and the
comprehensive amulet testing.



Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Eco Dashboard

[Charles Butler]

At present no, I feel like there's room for enhancement here (reactive
colors based on status! a cool blue tone for all systems go, a frightening
red when we have  X open charm reviews!). Most of what you see is default
for the dashing project http://dashing.io - they have a metro'ish UI. Its
something I haven't really put much effort into restyling as of yet -
getting the board useful for us was my primary goal. making it look super
appealing was going ot be the next steps once I had achieved full info
radiator status.

If a designer would like to alter the color scheme I'm happy to accept a
style sheet and plug it into the dash.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] Big Data Bundles Galore

[Charles Butler]

+ Apache Hadoop with Pig for data analytics
https://bugs.launchpad.net/charms/+bug/1475670

+ Apache Hadoop with Hive for data analytics
https://bugs.launchpad.net/charms/+bug/1475669

+  Apache Hadoop and spark with IPython Notebook
https://bugs.launchpad.net/charms/+bug/1475634

+ Apache Hadoop and spark with Zeppelin
https://bugs.launchpad.net/charms/+bug/1475632

+ Apache Hadoop and Spark base
https://bugs.launchpad.net/charms/+bug/1475630

- IPyNotebook for Spark
https://bugs.launchpad.net/charms/+bug/1463019

The only nitpick was the icon did not conform to the charm store
guidelines. -1 for now.


Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Announce] Juju driven Infrastructure CI with Drone

[Charles Butler]

Greetings,

I just published a blog about how to run your own CI around your charms
(and this applies to bundles too!) on a self-hosted Drone-CI instance.

Deployable with juju, driven by juju and amulet, full integration with your
VCS provider(s) - which currently is only github. Gitlab and Gogs support
is underway and should be landing sometime near next week.

I apologize for the short writeup, but all of the pertinent details are in
the repository Readme,  mirrored in the blog post, as well as a short 10
minute screencast of the entire setup from end to end.

http://blog.dasroot.net/2015-continuous-integration-with-juju-and-drone-ci.html

https://www.youtube.com/watch?v=ZIcf4mefX14

Deploy happy :)



Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Blogs] - Juju Docker Images, and DNS Automation with Juju

[Charles Butler]

Greetings!

This morning has been a productive one fueled by coffee and a month of
stuff to cover. I wrote 2 posts this morning covering some of the smaller
areas of interest I've been involved in over the last month:

Unofficial Juju Docker Images:
http://blog.dasroot.net/2015-unofficial-docker-images.html

If you're using the juju docker images from whitmo, or johnsca - nows the
time to repoint those Fom lines in your Dockerfiles! These images are built
nightly, and ready for you to consume and file bugs. More info in the post

DNS Automation (including 3rd party providers!) has landed in the DNS charm
upstream - http://blog.dasroot.net/2015-dns-automation-with-juju.html

The upstream DNS charm has realized the multi-provider plugin architecture,
refactored the test suite to use tox and increased coverage to 70%, along
with implementing the first crumbs of third party support starting with Rt53

Over the next 2 weeks I'll be updating the docs for anyone wanting to
contribute, there have been a few backwords incompat changes - namely
moving from a bind config approach to JSON objects to be parsed by the
charm.

I'll also be writing an in-depth hands on developer post within the next
month, and highlight how this charm was an integral component in an ad-hoc
PAAS built with Juju!

All the best,


Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[Review Queue] - Redis*, Apache Hive*, Apache Pig*, Spark*, Zeppelin*

[Charles Butler]

[1] Reviewed the incoming redis charm from frankban. This looks great! I
 made a quick adjustment to the charm to pass in CI and promulgated to the
~charmer namespace.

[2] Apache Hive was promulgated

[3] Apache Pig was promulgated

[4] Apache  Zeppelin was promulgated

1. https://bugs.launchpad.net/charms/+bug/1459345
2. https://bugs.launchpad.net/charms/+bug/1468769
3. https://bugs.launchpad.net/charms/+bug/1468768
4. https://bugs.launchpad.net/charms/+bug/1463026

Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Juju] Azure issues fix?

[Charles Butler]

I have a solid suite of specs/docs already for the DNS charm, more looking
for user requirements of what you need to make this happen, to correct the
Hostname Resolution. Does this constitute a new relationship? Should these
services just bind into the existing relationship model there and then DNS
takes care of it from there?

There are some impl. details that I'm not sure about, but your feedback
would be golden in making a first pass at making this happen.


http://github.com/chuckbutler/dns-charm
https://github.com/chuckbutler/DNS-Charm/tree/master/docs



If you could open issues about the suggested features, lets start there and
we'll work them into the project docs + roadmap and we can beta this as
quick as we can get the features written.

Cheers!



Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Fri, Jun 26, 2015 at 11:33 AM, Samuel Cozannet 
samuel.cozan...@canonical.com wrote:

 Hey,

 Thx, that would help.
 What form of documentation / specs are you expecting exactly?

 BTW, if that could also be included in Fan Networking, we would have a set
 of cool networking features for container workloads.
 On Jun 26, 2015 8:22 AM, Charles Butler charles.but...@canonical.com
 wrote:

 Hey Sam,

 Back when I was working on the big data eco we ran into this problem
 consistently on many substrates. There is work there that we can probably
 extrapolate into a helper function to eliminate this behavior on even the
 hackiest of situations. I'm not 100% a fan of just tossing a bunch of DNS
 data in /etc/hosts - but it does work.

 We should work together w/ the new work thats been landed in the DNS
 charm to try and offer a proper solution to this that doesn't involve a
 static list in /etc/hosts that is subject to environment changes, and let a
 proper DNS host offer that name resolution in our deployments. I know that
 I've gotten this to work with minmal effort on my internal LAN, which is a
 far cry from a data center, but this works extremely well.

 LMK if you're interested, I'd like to get some requirements established
 and extend the charm to do what you need it to, so we can call this a
 finished line item by adding 1 additional charm to the toplogy and some
 relations.

 All the best,



 Charles Butler charles.but...@canonical.com - Juju Charmer
 Come see the future of datacenter orchestration: http://jujucharms.com

 On Thu, Jun 25, 2015 at 8:17 PM, Samuel Cozannet 
 samuel.cozan...@canonical.com wrote:

 Hi All,

 Been struggling all week to get a decent Sentiment Analysis bundle on
 Azure, while it used to work for ages.

 Apparently, the new Azure after ARM templates is managing DNS a bit
 differently than in the past. There is no (more?) resolution of hostnames
 in the private network, but of the local machine.

 If you have any charm/bundle that uses (private) DNS resolution, I
 encourage you to test them against MS Azure, and eventually enforce charm
 relations to update /etc/hosts on all units, or whatever method to enable
 DNS resolution on, to and from every unit in the deployment.
 This should not break deployments on other clouds, and will re-enable
 Azure if it suddenly started to fail.

 If anyone has more / other info on this matter, or on specifics of
 Azure, I'd be happy hear your feedback.

 Thanks,
 Best,
 Samuel

 --
 Samuel Cozannet
 Cloud, Big Data and IoT Strategy Team
 Business Development - Cloud and ISV Ecosystem
 Changing the Future of Cloud
 Ubuntu http://ubuntu.com  / Canonical UK LTD http://canonical.com /
 Juju https://jujucharms.com
 samuel.cozan...@canonical.com
 mob: +33 616 702 389
 skype: samnco
 Twitter: @SaMnCo_23
 [image: View Samuel Cozannet's profile on LinkedIn]
 https://es.linkedin.com/in/scozannet

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



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

Re: [Juju] Azure issues fix?

[Charles Butler]

Hey Sam,

Back when I was working on the big data eco we ran into this problem
consistently on many substrates. There is work there that we can probably
extrapolate into a helper function to eliminate this behavior on even the
hackiest of situations. I'm not 100% a fan of just tossing a bunch of DNS
data in /etc/hosts - but it does work.

We should work together w/ the new work thats been landed in the DNS charm
to try and offer a proper solution to this that doesn't involve a static
list in /etc/hosts that is subject to environment changes, and let a proper
DNS host offer that name resolution in our deployments. I know that I've
gotten this to work with minmal effort on my internal LAN, which is a far
cry from a data center, but this works extremely well.

LMK if you're interested, I'd like to get some requirements established and
extend the charm to do what you need it to, so we can call this a finished
line item by adding 1 additional charm to the toplogy and some relations.

All the best,



Charles Butler charles.but...@canonical.com - Juju Charmer
Come see the future of datacenter orchestration: http://jujucharms.com

On Thu, Jun 25, 2015 at 8:17 PM, Samuel Cozannet 
samuel.cozan...@canonical.com wrote:

 Hi All,

 Been struggling all week to get a decent Sentiment Analysis bundle on
 Azure, while it used to work for ages.

 Apparently, the new Azure after ARM templates is managing DNS a bit
 differently than in the past. There is no (more?) resolution of hostnames
 in the private network, but of the local machine.

 If you have any charm/bundle that uses (private) DNS resolution, I
 encourage you to test them against MS Azure, and eventually enforce charm
 relations to update /etc/hosts on all units, or whatever method to enable
 DNS resolution on, to and from every unit in the deployment.
 This should not break deployments on other clouds, and will re-enable
 Azure if it suddenly started to fail.

 If anyone has more / other info on this matter, or on specifics of Azure,
 I'd be happy hear your feedback.

 Thanks,
 Best,
 Samuel

 --
 Samuel Cozannet
 Cloud, Big Data and IoT Strategy Team
 Business Development - Cloud and ISV Ecosystem
 Changing the Future of Cloud
 Ubuntu http://ubuntu.com  / Canonical UK LTD http://canonical.com /
 Juju https://jujucharms.com
 samuel.cozan...@canonical.com
 mob: +33 616 702 389
 skype: samnco
 Twitter: @SaMnCo_23
 [image: View Samuel Cozannet's profile on LinkedIn]
 https://es.linkedin.com/in/scozannet

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