Re: Clarification to ~charmers membership process

[Marco Ceppi]

+1 from me. I like having the list used as an application method to help
expose whose applying and feedback from there.


On Wed, Jul 31, 2013 at 6:32 PM, Antonio Rosales 
antonio.rosa...@canonical.com wrote:

 I added a clarification point at
 https://juju.ubuntu.com/community/charmers/ on how folks can
 officially submit to become a member of
 https://launchpad.net/~charmers. Specifically, emailing the juju list.
 Hopefully more folks will endeavour to become a ~charmer as we further
 build out the community.

 -thanks,
 Antonio Rosales

 --
 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] amulet 1.0.0 has been released

[Marco Ceppi]

It's been several weeks since I first announced amulet[0] and I'm happy to
release the 1.0 milestone of amulet. A lot has been added since the
simple `jitsu watch` port. However, before I go into the details of this
release I want to take this moment to describe really the aim of this
project.

Amulet is designed as a testing harness for Juju Functional Tests (tests
executed with the `juju test` plugin). These tests are designed to run the
charm, on actually bootstrapped environments, in order to insure your charm
works as you expect it to in a live environment. This type of testing is a
step up from just unit-testing your code and follows the same line as
integration testing.

Currently, tests can be executed now, but you only have the ability to
interact with services via `juju ssh` and then collect output of the log
files for analysis. With Amulet, you'll be able to drive the service from
within the test, collect information while the environment is running, and
then potentially influence change from this information while the test is
still running.

In the spirit of Juju Charms being language agnostic, Amulet is designed to
work within the scope of the `juju test` function but is not the only means
by which you can write functional tests. Instead, as a harness, it's
designed to allow you greater flexibility and control over your tests.
While this release is only available as a Python module, future releases
will provide an agnostic programmable API (much like in the second version
of charm-helpers) to allow languages other than Python to leverage the
Amulet testing harness.

In a sentence, Amulet is to tests as charm-helpers are to hooks; a tool set
to make the writing of said task easier and more predictable.

What can Amulet actually do? When used to it's full potential, Amulet
provides an abstraction layer to juju-deployer to simplify deployer
instructions and also provides a service called sentries which provide
deeper inspection of services and relations. At this time Amulet is able to
query files and directories on a remote unit, if/when all running hooks in
the environment cease (true wait support), allow the tester to run
arbitrary commands on a unit, and will collect the data sent between units
during relation hooks.

With these tools, a test can further drill down in to the deployed
environment to better insure the charm functions as expected when plugged
in to the other services it depends on.

The changes in this release are outlined below:

# Deployment

Juju Deployer is now integrated with Amulet. You can choose to either
describe your deployment via the abstraction layer or simply load an
existing deployer json/yaml config.

eg:

import amulet

d = amulet.Deployment()
d.add('mysql')
d.add('wordpress')
d.relate('wordpress:db', 'mysql:db')
d.setup(timeout=600)


## Sentries

If you're using deployer integration, you'll automatically get sentry
support (unless disabled). Sentries are subordinate charms that are created
on-the-fly for each service deployed. They collect information about the
services running and allow for deeper probing of units via an exposed API.


import amulet

d = amulet.Deployment()
d.add('mysql')
d.add('wordpress')
d.relate('wordpress:db', 'mysql:db')
d.setup(timeout=600)

d.sentry.unit['wordpress/0'].file_contents('/var/www/wp-info.php')
d.sentry.unit['mysql/0'].relation('db', 'wordpress:db')
d.sentry.unit['wordpress/0'].run('service php-fpm stop')

## Wait

Wait will continue to work as expected before; however, if you've used
deployer with sentries it'll check to insure a service is actually started
by checking for currently running hooks on each unit. This allows for more
accurate control when waiting for an environment to be completely set up.

import amulet

d = amulet.Deployment()
d.add('mysql')
d.add('wordpress')
d.relate('wordpress:db', 'mysql:db')

# Setup runs juju-deployer, which will end if all units are started, not
when all hooks are done executing.
d.setup(timeout=600)

# Wait will constantly query all units until there are no more hooks being
executed in the environment or a timeout threshold is met.
d.sentry.wait(timeout=300)


There are several other additions, the ability to build charms on-the-fly
as well as a rudimentary charmstore abstraction. These will be further
documented in the juju docs under the Amulet Developer Reference section.

As this is a first cut release, if you find any bugs please use LP to
report them (lp:amulet). Amulet is being packaged in ppa:juju/stable and
will be available soon for installation.


0: https://lists.ubuntu.com/archives/juju/2013-July/002658.html
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sharing a DB user password among units of the app

[Marco Ceppi]

On Wed, Oct 30, 2013 at 10:47 AM, Gustavo Niemeyer gust...@niemeyer.netwrote:

 On Wed, Oct 30, 2013 at 7:35 AM, Kapil Thangavelu
 kapil.thangav...@canonical.com wrote:
  Just thinking outloud, but In the active-active db scenario, there's an
  available db for the charm to store this info. ie. the charm could keep
 some
  bookeeping tables/db instead of using files on disk (a shared key via
 peer
  relation used for storing the credentials in db).

 So you share the credentials for the credentials? :-)

 Just share the credentials over the peer relation. Unit 0 creates them.


You can't make that assumption and we really frown upon it in charm
reviews. I've seen cases where `juju deploy -n 5 service` results in unit 2
or really unit  0 being first up. There's also scenarios where there might
not actually be a unit 0 there's no way to safely guarentee a leader
right now.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

So, what about all these oneiric charms?

[Marco Ceppi]

We still have and display oneiric charms in the charm store. I'm going to
keep this brief, but:

Can you still deploy to oneiric?
Do we want this to be displayed in the GUI at all?
Do we even want these in the store?

What's the plan for charms whos series has EOL'd?

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

Changing/removing configuration keys for a charm in the charm store.

[Marco Ceppi]

Hi all, I need some consensus on how to handle merge proposals for charms
in the charm charm store when these proposals change configuration key
names. The proposal in question is
https://code.launchpad.net/~sidnei/charms/precise/squid-reverseproxy/trunk/+merge/190500
in
the config.yaml diff the following is changed:

320- nagios_check_url:321+ nagios_check_http_params:322 default:
323type: string
324 description: 325- The URL to check squid has access to, most likely
inside your web server farm326+ The parameters to pass to the nrpe plugin
check_http.

It's my understanding we do not want to change configuration option names
as it will break what a user has deployed. Configuration values can be
added, as sane defaults will kick in with that but when it comes to
changing a name it's essentially removing that configuration option and
adding a new one.

I would recommend in this scenario that nagios_check_url remains and
nagios_check_http_params is added with the change and note of the
distinction of the two in the README.

I'm actually not sure how to handle this though, so I'm reaching out to the
list for feedback.

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

Re: Changing/removing configuration keys for a charm in the charm store.

[Marco Ceppi]

Okay, so taking in Sidnei's feedback I've merged this request as it's
reverting back to a previous state. The example not withstanding I'm
curious on how we should handle such changes in the future.

Thanks, Marco


On Mon, Nov 4, 2013 at 10:53 AM, David Ames david.a...@canonical.comwrote:

 On 11/03/2013 05:00 PM, Sidnei da Silva wrote:
  To be clear, this *specific* change (the rename of a config.yaml
 argument)
  is a revert of r31 of the charm in the charm store.

 Also in this specific case, nagios_check_http_params is the config key
 used in several of the other charms and would be correct to keep squid
 reverseproxy with the standard.

 --
 David Ames


  On Sun, Nov 3, 2013 at 9:50 PM, Marco Ceppi marco.ce...@canonical.com
 wrote:
 
  Hi all, I need some consensus on how to handle merge proposals for
 charms
  in the charm charm store when these proposals change configuration key
  names. The proposal in question is
 
 https://code.launchpad.net/~sidnei/charms/precise/squid-reverseproxy/trunk/+merge/190500in
  the config.yaml diff the following is changed:
 
   320- nagios_check_url: 321+ nagios_check_http_params: 322 default: 
 323type: string324description: 325-
  The URL to check squid has access to, most likely inside your web server
  farm 326 + The parameters to pass to the nrpe plugin check_http.
 
  It's my understanding we do not want to change configuration option
 names
  as it will break what a user has deployed. Configuration values can be
  added, as sane defaults will kick in with that but when it comes to
  changing a name it's essentially removing that configuration option and
  adding a new one.
 
  I would recommend in this scenario that nagios_check_url remains and
  nagios_check_http_params is added with the change and note of the
  distinction of the two in the README.
 
  I'm actually not sure how to handle this though, so I'm reaching out to
  the list for feedback.
 
  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

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

[ANN] Charm Tools 1.1.2 released!

[Marco Ceppi]

Hello everyone!

I'm happy to announce charm-tools 1.1.2 has been released! This release
succeeds 1.1.1, which was released a few hours. This announcements contains
the fixes for both 1.1.1 and 1.1.2. This release implements two patches to
improve proofing functionality for bundles and charms.

# Installing/Upgrading

If you're on Ubuntu and have ppa:juju/stable added you'll be able to update
to the latest. For Windows users please see
https://juju.ubuntu.com/docs/tools-charm-tools.html#intro For Mac OSX users
there's still a delay but this update will be landing in Homebrew shortly.
charm-tools is now available via pip, pip install charm-tools. Finally,
there is a source release available on Launchpad:
https://launchpad.net/charm-tools/1.1/1.1.2

# Changes

You can view a complete overview of the features and fixes applied on the
milestone page: https://launchpad.net/charm-tools/+milestone/1.1.2

## Highlights

- Fixes bug 1247951 https://bugs.launchpad.net/charm-tools/+bug/1247951
- Improves proof, making it more library call than shell entry point

# Support

Support for charm-tools is available at juju@lists.ubuntu.com or #juju on
freenode.

This is the last foreseen release of the 1.1 series and the development
focus remains targeted at the 1.2 series.

Thank you all for your feedback and suggestions so far. There will be a
charm-tools UDS session in November to discuss how charm-tools can better
improve the developer getting started experience.

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

[ANN] charmworldlib 0.1.0 released

[Marco Ceppi]

Hello all,

I've released the first version of a Python Library designed to interact
with data from charmworld (https://manage.jujucharms.com). Currently this
library is used by charm-tools to interact with the available charms and
bundles in the ecosystem. This isn't considered a stable API and methods
may be changing in the near future. Until a 1.0 release, expect changes to
the API.

# Installing/Upgrading

For Ubuntu users, add ppa:juju/stable if you haven't already and run the
following

sudo apt-get update
sudo apt-get install python-charmworldlib

For other users, charmworldlib is available on pypi
https://pypi.python.org/pypi/charmworldlib/0.1.0 and via pip: pip install
charmworldlib

# Features

At this time there are charm and bundle imports. charm provides a Charm
class which models a Charm, and a Charms object to search and poll the API
for charm related data. bundle provides a Bundles class and only a proof
endpoint is exposed. More features will be published in the upcoming
releases of charmworldlib.

# Support

Support for charmworldlib is available via bug reporting at
https://bugs.launchpad.net/charmworldlib

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

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

[Marco Ceppi]

Hi all,

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

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

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

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

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

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

Thanks,
Marco Ceppi

[0]: http://yaml.org/type/null.html
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Plugins

[Marco Ceppi]

So, when I first started plugins, I was like WE SHOULD HAVE A WEBSITE, AND
IT SHOULD HAVE PLUGINS, AND AWESOME, but then I realized that we don't
have that many plugins. In the future, if plugins become a popular thing we
can invest some time in making jujuplugins.com and have a plugin installer,
etc. For now just collecting them all in one place is a good start.

Thanks,
Marco Ceppi


On Thu, Feb 13, 2014 at 5:50 PM, Joshua Strobl truthfroml...@gmail.comwrote:

 Would it be feasible and/or benefitial to have some sort of rating
 system for the plugins, with those that get the most support being
 merged into juju-core (assuming there wouldn't be some upcoming
 functionality that would make the plugin no-longer-useful)? I see that
 as a great way to improve Juju's core functionality gradually without
 having to worry about tackling a possible issue later where plugin X
 that could've been merged is now out-of-date.

 On 02/13/2014 11:37 PM, Jorge O. Castro wrote:
  If you didn't know, Juju has support for plugins. So far these have
  been scattered over junk branches and pastebins so we're going to
  organize them so people have one place to find them:
 
  https://github.com/juju/plugins
 
  We're not going to package them (yet) so we can put them in one place
  and see which ones are useful and which ones aren't. If you have a
  Juju plugin you're using and want to share it then please submit it.
  Thanks to Marco Ceppi for organizing this!
 

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

OpenStack charms are being re-promulgated, how this affects you.

[Marco Ceppi]

Hi all,

Summary: In order to enable the OpenStack Charmers to better respond to
merge requests and iterate on the OpenStack charms, all OpenStack charms
will be re-promulgated from ~charmers to ~openstack-charmers. THIS WILL BE
A PROBLEM for anyone who is referencing an openstack charm, listed below,
with the full Launchpad branch name (ie:
lp:~charmers/charms/precise/charm/trunk). To avoid this issue in the
future please make sure you are at least using lp:charms/charm if not a
fully qualified charm store url, cs:precise/charm.

Charms Affected:

ceilometer
ceilometer-agent
ceph
ceph-osd
ceph-radosgw
cinder
glance
hacluster
heat
keystone
nova-cloud-controller
nova-compute
nova-compute
nova-volume
openstack-dashboard
quantum-gateway
swift-proxy
swift-storage

While this change won't break anyone who is referencing charm store URLs
(ie: cs:precise/charm or lp:charms/charm) this may break older bundles
or scripts which do not use the canonical naming scheme for charm store
charms.

In order facilitate a move these will be re-promulgated tonight but the
original ~charmers branches of each will remain for one week, finally being
removed on March 1st. Please note that these ~charmers branches will not be
updated and are merely left to allow time to update scripts.

I will be going through each bundle in the charm store and pinging bundle
authors directly if they need to update their bundles to new URLs. For
those who don't have bundles published in the charm store which utilize the
OpenStack charms, please review and update as necessary.

For those with merge proposals against the current openstack-charms I will
be resubmitting these against ~openstack-charmers. If I miss any, my
apologies, you simply need to resubmit and target against the new branch.

Finally, if you have any questions about this migration please feel free to
contact me directly or ping me on IRC (marcoceppi). I'll be happy to
explain further this process and it's potential impact on how you use the
OpenStack charms. I tried to include all the mailing lists this would
pertain to without dumping to too many lists. I also want to re-iterate
that unless you're using very specific (and, arguably the proper way) to
reference charms this change will be transparent to you.

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

Re: MySQL charm: hook failed: config-changed

[Marco Ceppi]

Which cloud were you running this against?
On Feb 3, 2014 5:23 PM, Daniele Stroppa daniele.stro...@joyent.com
wrote:

 Hi All,

 while running test for the Node.js charm I ran into an issue with the
 MySQL charm, see attached log. It looks like it's a permissions issue.

 I'm running on Ubuntu 12.04 with juju 1.16.4.1 and MySQL charm from
 cs:precise/mysql-32

 Anyone has seen this before?

 Thanks,
 Daniele

 --
 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: Application for Juju Charmer status

[Marco Ceppi]

I don't see any objections, and a minimum of two charmers with a plus one
is satisfied. I'll leave this open for any further discussion, but
otherwise starting next week Matt will be elevated to charmers status.

Welcome!

Thanks,
Marco Ceppi


On Tue, Apr 1, 2014 at 9:23 AM, Peter Petrakis peter.petra...@canonical.com
 wrote:

 + 1



 On Mon, Mar 31, 2014 at 9:44 AM, Matt Bruzek matthew.bru...@canonical.com
  wrote:

 Hello Charmers,


  I have been working for Canonical on the Juju Ecosystem team for 3
 months, and it is time to step up and apply for charmer status.


  I have had two tours on the Charm Review Queue and performed reviews of
 many charms. Most of my time has been spent doing the Charm Audit, writing
 tests to verify that charms are doing what they claim to do. This often
 involves diving in to learn the technology the charm provides, and figuring
 out how to test that technology in an automated way.


  Here are my credentials for your consideration:


  *Authored charms*:


  http://manage.jujucharms.com/charms/precise/openmrs

 OpenMRS is a open source electronic medical records platform written in
 Java.


  I have a charm on the way that installs/configures Apache Tomcat. This
 charm will have many new features and will provide Juju a robust Java
 Servlet and JSP framework. https://bugs.launchpad.net/charms/+bug/1295710


  I also engaged the Apache PMC team to gain permission to use the Apache
 Tomcat icon in Juju! So the Tomcat charm will have the official Apache
 Tomcat icon where the existing charms used the default icon. Once the
 Tomcat charm passes a review I plan on replacing/deprecating the existing
 tomcat6 and tomcat7 charms.


  *Juju Presentations*:


  Here is a UDS 2014 Charm School where I gave a deep dive on developing
 charms: http://www.youtube.com/watch?v=ByHDXFcz9Nkfeature=sharet=10m15s


  I have given a Juju presentation to the Rochester Minnesota Linux User
 Group. You can view the presentation I created here:
 http://prezi.com/7xgiezaajjek/juju/


  *Juju Documentation*:


  Having worked on several software products, I hold the firm belief that
 software need complete documentation to be a great product. I have
 contributed to the Juju documentation where ever I see an opportunity. My
 contributions can be reviewed here:


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

 https://github.com/juju/docs/pull/33

 https://github.com/juju/docs/pull/23

 And before the docs were on github:


 https://code.launchpad.net/~mbruzek/juju-core/fixed-404-in-authors-charm-writing

 https://code.launchpad.net/~mbruzek/juju-core/Fixed-references-to-contents


  *Bugs*:


  Creating bug reports is an important component of the software
 development process. As a developer myself I appreciate a complete bug
 report, so the golden rule applies when I find things that can be improved.
 I try to create bug reports with detailed descriptions and include steps on
 how to recreate the issue. Here are a few examples:


  #1299179 mysql hook failed: 
 mongos-relation-changedhttps://bugs.launchpad.net/charms/+source/mongodb/+bug/1299179

 #1279879 Juju error on HP cloud with Maximum number of attempts (3)
 reached sending requesthttps://bugs.launchpad.net/juju-core/+bug/1279879

 #1293878 Amulet should work with local charms that are not in version
 control https://bugs.launchpad.net/amulet/+bug/1293878

 #1294690 Amulet should provide a way to detect the Juju 
 environment.https://bugs.launchpad.net/amulet/+bug/1294690

 #1296780 KeyError for units that were added by 
 add_unithttps://bugs.launchpad.net/amulet/+bug/1296780

 #1284309 The rsync fails in error when the -o option is 
 usedhttps://bugs.launchpad.net/charm-tools/+bug/1284309


  I have reported 17 bugs that are currently open, you can see them all
 here: https://bugs.launchpad.net/~mbruzek/+reportedbugs

 I am involved with 23 bugs at the moment, if you want to view them all go
 to: https://bugs.launchpad.net/~mbruzek/+bugs


  *Code*:


  Most of my time has been spent writing Amulet tests for the Charm
 Audit. Here are some branches that illustrate my understanding of different
 charms and the amulet testing framework.


  
 lp:~mbruzek/charms/precise/rabbitmq-server/testshttps://code.launchpad.net/%7Embruzek/charms/precise/rabbitmq-server/tests

 lp:~mbruzek/charms/precise/lamp/trunkhttps://code.launchpad.net/%7Embruzek/charms/precise/lamp/trunk

 lp:~mbruzek/charms/precise/memcached/trunkhttps://code.launchpad.net/%7Embruzek/charms/precise/memcached/trunk

 lp:~mbruzek/charms/precise/haproxy/trunkhttps://code.launchpad.net/%7Embruzek/charms/precise/haproxy/trunk


  *Reviews*:


  One of the most important responsibilities of a charmer is to welcome
 the contributor to the community and help them create quality charms that
 follow charm store policy. Sometimes that means giving the contributor
 things to improve and fix before they are accepted in the charm store. I
 have tried to be welcoming and give constructive

Juju Academy

[Marco Ceppi]

Hi everyone!

I was trying to keep this under wraps as I worked on it more before
announcing to the world but I'm too excited with the progress so far so
here's the SUPER ALPHA BETA OMEGA introduction to Juju Academy.

I started this, http://juju.academy (http://learnjuju.com) based on my own
experiences when trying new software. Primarily modeled after the Learn Go
Lang webiste (http://tour.golang.org/) I set out to create an easy platform
that emulates a terminal environment and allows a user to try Juju before
ever having to install it. In addition I wanted to make a lightweight
lesson framework to help guide new users in this exciting new Service
Orchestration paradigm. Finally, the last goal of this project was to build
an easy to embed module that could live in the docs to provide very
lightweight terminal sessions that users could use to review what portions
of the docs they were reading.

Right now I've modeled just a hand full of lessons and only a few of the
juju commands have actually been implemented. As this is a spare time
project progress comes in chunks of time over the weekend and in the
evenings. However, if you're interested in piloting the demoware and
shaking out bugs please do so! You can view the lessons at
http://juju.academy the source code is
https://github.com/marcoceppi/juju-academy and the issue tracker is on that
repo.

Your juju environment(s) persist not only between lessons but also between
page visits. If at anytime you wish to start anew you can do so by issuing
the reset command in the terminal. I'm working on finishing
http://help.juju.academy which will have this and other FAQ/Guide like
questions to use the software. All Juju help can be found, as always, at
https://juju.ubuntu.com/docs

This is also a call for help! Anyone interested in writing lessons, command
modules, fixing bugs, making this look nicer, etc - pull requests are
welcome! The entire project aims to be modular (in that this framework
could be used for non juju terminal lessons). Lessons are simply JSONP
files that contain a set number of keys and commands are functions that
perform some rudimentary validation.

I eagerly await feedback and have had an immense amount of fun working on
this so far! I'll likely follow up with a more official announcement when
more of the commands have been implemented.

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

[ANN] charmworldlib 0.4.0

[Marco Ceppi]

Hello all,

charmworldlib is a Python library designed to make interfacing with the
Charmworld API in Python easy.

Today charmworldlib 0.4.0 was released which brings the project up to
feature parity with the bundles API endpoint in charmworld (many thanks to
Tim Van Steenburgh for his work making this happen).

Also, charmworldlib is available as both a python2 and python3 package.
(python-charmworldlib and python3-charmworldlib)

# Installing/Upgrading

For Ubuntu users, add ppa:juju/stable if you haven't already and run the
following

```
sudo apt-get update
sudo apt-get install python-charmworldlib python3-charmworldlib
```

For other users, charmworldlib is available on pypi
https://pypi.python.org/pypi/charmworldlib/0.4.0 and via pip: `pip install
charmworldlib`

# Changes

- [lp:1319178] Bundle searching doesn't exist

# Support

The 0.4.1 milestone has been opened for any bugs which may arise. At this
time no 0.5 series is planned as the charmworld API has no future versions
planned.

Support for charmworldlib is available via bug reporting at
https://bugs.launchpad.net/charmworldlib

Thanks,
Marco Ceppi, on behalf of the Juju Solutions team
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Application for Juju Charmer Status

[Marco Ceppi]

Hi Jose!

Thank you so much for your submission to be a charmer. Not only have you
been a huge asset helping community members but have done quite a lot of
work in the audit and in patching charms. That said, I've noticed a large
delta in your reviews of things which were missed and covered later by
another reviewer. Typically we want to see a much shorter delta of missed
items in review for a charmer application.

While you don't have a vote from me, I'm simply going to abstain my vote in
either direction as I really don't wish to diminish the amazing work you've
done so far and continue to do but simply wish to highlight some concerns I
have and think maybe re-applying again after some more time might be better.

Marco


On Thu, Aug 21, 2014 at 11:19 AM, Matt Bruzek matthew.bru...@canonical.com
wrote:

 A big +1 from me!

 José has been an outstanding Juju community member for quite some time
 now.  In addition to what he listed in his application, José helps out on
 IRC in #juju quite a bit.  José is a community member, helping with the
 audit!

 I have worked closely with José on several of the charm submissions he
 listed there and I know he is committed to doing what is right for Juju and
 Ubuntu.

 José has earned my respect and I endorse his application.

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


 On Wed, Aug 20, 2014 at 3:36 PM, José Antonio Rey j...@ubuntu.com wrote:

 Hello, Juju-ers!

 So I believe it's the time. After a while, I'm now applying for charmer
 status.

 For those who don't know me, I am not a Canonical employee, but instead
 have been contributing to Juju as what I am - a community contributor.
 My contributions to the Juju Charm Ecosystem include various things,
 such as writing, adopting, improving and reviewing charms. I am the
 author for:

  * postfix - https://jujucharms.com/precise/postfix/
  * mailman - https://jujucharms.com/precise/mailman/
  * chamilo - https://jujucharms.com/precise/chamilo/
  * seafile - https://jujucharms.com/precise/seafile/
  * pubphoto (still on the RevQ) -
 https://code.launchpad.net/~jose/charms/precise/pubphoto/trunk

 I have, as well, taken maintainership of the ownCloud charm
 (https://jujucharms.com/precise/owncloud/).

 In terms of charm improvements, I recognize that quality is one of the
 most important things. That is why I have taken some charms and
 refactored them as they were not working, or fixed some bitesize bugs.
 Examples of the refactoring can be seen in the ownCloud charm, as well
 as in the Tracks charm (https://jujucharms.com/precise/tracks/, see MP
 at https://code.launchpad.net/~jose/charms/precise/tracks/fixes). More
 of the work I have been doing in terms of bitesize bugs can be found at
 https://code.launchpad.net/~jose.

 I also see bugs as a vital part of the ecosystem, letting us know what's
 going on with charms. Here are some of the bugs I have fixed:

  * Wordpress bug #1309980 Relationship to memcache seems incomplete -
 https://bugs.launchpad.net/charms/+source/wordpress/+bug/1309980
  * ownCloud bug #1310164 Support SSL Connections -
 https://bugs.launchpad.net/charms/+source/owncloud/+bug/1310164
  * ownCloud bug #1315091 juju remove-relation mysql owncloud does not
 work. - https://bugs.launchpad.net/charms/+source/owncloud/+bug/1315091

 I have, as well, filed bugs and fixed them for proof errors that were
 currently on the store. Some examples are distcc
 (https://code.launchpad.net/~jose/charms/precise/distcc/fix-various),
 chef-server
 (
 https://code.launchpad.net/~jose/charms/precise/chef-server/add-icon-categories-fix-readme
 ),
 nyancat
 (
 https://code.launchpad.net/~jose/charms/precise/nyancat/add-categories-fix-readme
 )
 and jenkins-slave
 (
 https://code.launchpad.net/~jose/charms/precise/jenkins-slave/1297601-fix
 )

 On the other hand, I have been listed as deputy reviewer one week, and
 have (apart from that) done in-depth new submission and MP reviews. I
 have blocked charms into the Charm Store when they are not yet ready or
 do not meet a policy, and celebrated the efforts of the author(s) if
 they are. Some examples of that are:

  * Bug #993483 Charm Needed: CakePHP -
 https://bugs.launchpad.net/charms/+bug/993483
  * Bug #803538 Charm Needed: Diaspora -
 https://bugs.launchpad.net/charms/+bug/803538
  * MP #222358, adding tests to Ceph -

 https://code.launchpad.net/~mbruzek/charms/precise/ceph/trunk/+merge/222358
  * Bug #1314699 New charm - Apache Allura -
 https://bugs.launchpad.net/charms/+bug/1314699

 And fixed one bitesize bug in juju-core
 (https://bugs.launchpad.net/juju-core/+bug/1309805).

 I am also working on advocacy and outreach, which is why I already have
 two Charm Schools scheduled, one for September in Orlando, FL, and one
 for October, at University of Lima, Peru. And I helped host some of the
 Charm Schools held at Ubuntu on Air!

 Finally, I understand the Charm Audit that is currently taking place and
 that tests are an important feature we want in charms. 

Re: juju relation status

[Marco Ceppi]

My question is why do you need to run add-relation in a synchronous fashion?


On Fri, Aug 22, 2014 at 9:02 AM, Chris Glass chris.gl...@canonical.com
wrote:

 Charm-helpers uses a trick for this, which is to check if the
 private-address key was set on the relation.
 You can have a better look here:

 https://bazaar.launchpad.net/~charm-helpers/charm-helpers/devel/view/head:/charmhelpers/core/hookenv.py#L393

 Hope this helps :)

 - Chris

 On Fri, Aug 22, 2014 at 3:35 PM, Tudor Rogoz ro...@adobe.com wrote:
  Hi,
 
  Does anyone knows how to determine when a relation is establish (when the
  relation joined or relation changed hooks ended) ? The goal would be to
 be
  able to synchronously run the “juju add-relation” command.
 
  Thanks,
  Tudor
 
  --
  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: [Ecosystem-engineering] Proposal: New review queue and review process

[Marco Ceppi]

I wanted to update everyone to let them know the first iteration of this
review queue is out. While it's a very bare MVP it's the direction I'm
taking the review queue in. I've written a blog post,
http://marcoceppi.com/2014/09/a-new-charm-review-queue/ which outlines the
features and the short term roadmap for the queue. There are still quite a
few things which need to be implemented, mainly the top navigation does
nothing and a few queues are empty but quite a few new items have showed up
in the queue!

Feedback, suggestions, comments, and pull requests welcome!

Thanks,
Marco Ceppi


On Tue, Aug 26, 2014 at 4:34 PM, Cory Johns cory.jo...@canonical.com
wrote:

 Marco,

 I just wanted to follow up and say that this proposal sounds great to
 me.  The only addition I would make is clarifying what the logic is
 when there are conflicting reviews; e.g., if you mark something as
 TRIAGED (I don't suppose there's any possibility of getting a FIX
 ACCEPTED status added?) but I mark it as INCOMPLETE, does it get
 hidden / sorted down on the main review queue or not?

 In addition to having it formally defined, I also think it should be
 clearly and easily visible from the review queue itself; that is,
 there should be an obvious How Does This Work? link that displays
 all of this information for reviewers and reviewees alike to see.


 Thanks for working on this.  I think this will be a definite
 improvement to the review process.

 - Cory

 On Mon, Aug 18, 2014 at 1:59 PM, Marco Ceppi marco.ce...@canonical.com
 wrote:
  Hi everyone, I'm going to jump right in with this email be briefly
  describing a short summary of the issues people have brought up around
 the
  review process and the review queue, then outline what my proposal to fix
  this is, outline the new process for feedback prior to implementation,
  finally listing actions left to implement this. The current review queue
 has
  been an indispensable tool for helping maintain the ecosystem as it is
 today
  and the code that the new review queue is built on shares a lot of the
 same
  logic/concept. However, since we've grown a lot in the last few years
 this
  is an attempt to help bullet proof the process as we move forward.
 
  # Issues
 
  One of the biggest feedback we've gotten from users lays along the lines
 of
  where is my charm in the review process and what are next actions.
  Currently, the review queue doesn't illuminate any next actions for a
 user.
  As queue times increase this can leave a poor user experience. Another
  feedback point we have seen recently are reviews being lost in the
 process.
  This is arguably the primary reason behind a revamp of the review queue
 and
  review process to ensure a submitted item for review does not get lost in
  the process. These are two primary examples, while a more exhaustive list
  exists these items have the most impact for users contributing to the
  ecosystem.
 
  # Solution in Development
 
  For the past two weeks I've been working on a replacement review queue
 which
  uses a lot of the initial code from the current review queue. A few major
  points:
 
  * Ingests all bugs and merges regardless of state, owner, or series
  * Tracks reviews once ingested
  * Decoupled from charmworld
  * API access
  * Detailed statistic gathering
  * Track reviews per user
  * Track merges from LaunchPad and Github
  * Priority sorting of reviews
  * Track multiple queues of work at once
  * Modular code base for extensiblity
 
  This is what has been done for the first version of the review queue
 which I
  plan to release this week for review. However, as the review queue is
  currently tracking ALL items (and not items for which only a charmer can
  take action against) we will need to update the review process for
 charmers
  and charm-contributors (Jr. Charmers) alike. Those proposed changes are
  outlined below:
 
  # Proposed review policy changes
 
  ## New Charms
 
  With the new review queue, charmers being assigned to the bug is no
 longer a
  requirement for it to appear in the queue. Any bug against the charms
  distribution which isn't targeted at a source package (charm) will be
  ingested. Currently, NEW and FIX COMMITTED charms appear in the
 queue.
  Going forward, LP statuses will have more effect on the queue. NEW
 status
  will appear in a separate queue. These are charms that are just being
  submitted. The new queue is designed to get first contact to that user
  faster. TRIAGED should be what a reviewer (who isn't a charmer) moves
 the
  bug status to if it passes an initial review FIX COMMITTED will
 indicate
  that the charm author has received review items and is ready for another
  review, INCOMPLETE or IN PROGRESS indicates that someone has reviewed
  the charm and it needs work to complete. FIX RELEASED when the charm
 has
  been promulgated. All other statuses indicate an abandoned/closed review.
 
  ### Proposed workflow
 
  1. User submits a new charm by opening a bug

Re: Juju devel 1.21-alpha1 is released

[Marco Ceppi]

Is there a way to see what commits made it in to this release? I'm curious
to know if a few patches (that weren't tied to bugs until recently) made it
in.


On Fri, Sep 19, 2014 at 5:32 AM, Samuel Cozannet 
samuel.cozan...@canonical.com wrote:

 Thanks for all of this, all good and very helpful stuff :)

 On Wed, Sep 17, 2014 at 10:04 PM, Curtis Hovey-Canonical 
 cur...@canonical.com wrote:

 juju-core 1.21-alpha1

 A new development release of Juju, juju-core 1.21-alpha1, is now
 available.


 Getting Juju

 juju-core 1.21-alpha1 is available for utopic and backported to earlier
 series in the following PPA:

 https://launchpad.net/~juju/+archive/devel

 The devel packages in this archive use the devel simple-streams.
 You must configure the 'tools-metadata-url' option in your
 environments.yaml to use the matching juju tools.

 tools-metadata-url: https://streams.canonical.com/juju/devel/tools

 This ensures a clean separation between the stable tools and the devel
 tools. Production environments based on stable juju cannot accidentally
 upgrade to a devel release even when the --version option is passed to
 the 'upgrade-juju' command. The 'tools-metadata-url' option must be set
 to clearly state the environment is for evaluating development versions.

 Upgrading from stable releases to development releases is not
 supported. You can upgrade test environments to development releases
 to test new features and fixes, but it is not advised to upgrade
 production environments to 1.21-alpha1. You can switch your testing
 environment to use the devel streams like so:

 juju set-env
 tools-metadata-url=https://streams.canonical.com/juju/devel/tools

 This change may take hours to propagate. You can upgrade when the devel
 url
 is shown to be in the env.

  juju get-env tools-metadata-url


 Notable Changes

 * Harvest Modes

 * Disabling apt-get update/upgrade for faster provisioning

 * Using daily image streams for faster provisioning

 * Add many machines

 * Setting the MAAS network rules

 * Performing autopsies on failed bootstraps


 Harvest Modes

 Juju keeps a model of what it thinks the environment looks like, and
 based on that model, can harvest machines which it deems are no longer
 required. This can help keep your costs low, and keep you out of web
 consoles. Juju supports several harvesting modes to suit your needs.

 that Juju knows about. Unknown instances will not be harvested. This
 is the default mode.

 Destroyed: Juju will harvest only machine instances that are dead, and

 Unknown: Juju will harvest only instances that Juju doesn't know about.

 All: Juju will terminate all instances – destroyed or unknown – that it
 finds. This is a good option if you are only utilizing Juju for your
 environment.

 None: Juju won't harvest any machines. This is the most conservative
 mode, and a good choice if you manage your machines utilizing a separate
 process outside of Juju.

 Juju's harvesting behaviour is set through the environments.yaml file.

 provisioner-harvest-mode: MODE

 'provisioner-harvest-mode' replaces 'safe-mode'. Environments with
 'safe-mode' set will be converted to 'provisioner-harvest-mode' when
 upgraded.


 Disabling apt-get update/upgrade for faster provisioning

 When juju provisions a machine, its default behaviour is to update the
 list of available packages and upgrade the existing packages to the
 latest version. If your OS images are fresh or the services you deploy
 don't require updated packages, you can disable updates and upgrades to
 provision the machine faster.

 Two configuration options are available to disable apt updates and
 upgrades. When your OS images are fresh, you can set both
 'enable-os-refresh-update', and 'enable-os-upgrade' to false. When you
 know that some charms want the latest packages to to setup services, you
 will want to keep 'enable-os-refresh-update' set to true

 You can configure the options in environments.yaml for fast provision
 like so

 enable-os-upgrade: false
 enable-os-refresh-update: false


 Using daily image streams for faster provisioning

 Juju prefers to use the well slow changing released images when
 provisioning machines. The 'image-stream' option in environments.yaml
 can be set to daily use more up-to-date images, thus shortening the
 time it takes to perform apt-get update/upgrade. While this feature has
 existed since 1.18.0, it was not applied consistently KVM containers.
 KVM containers will now use daily when environments.yaml is set to:

 image-stream: daily


 Add many machines

 Juju's 'add-machine' command now accepts the '-n' option to add many
 machines. For example, to add two machines:

 juju add-machine -n 2

 The '-n' option can be combined with placement. You can add to lxc
 containers to machine 1 thusly

  juju add-machine lxc:1 -n 2


 Setting the MAAS network rules

 The default network bridge is eth0. MAAS environments can specify a
 different interface 

Re: Announcing the ubuntu-mirror charm

[Marco Ceppi]

Hi Chris!

Awesome work on the charm, I'm not sure I'll ever need to mirror the entire
Ubuntu repository, but if I ever did I'm happy there's a charm for it! I do
like that it leverages the storage charm and is scaleout safe (safe for
bandwidth + wallet too).

Marco

On Sat, Sep 20, 2014 at 10:55 AM, Christopher Glass trib...@gmail.com
wrote:

 Hi all,

 I've started playing with and deploying my ubuntu-mirror charm, that
 leverages the excellent storage subordinate charm to create full
 ubuntu mirrors.

 That allows you to mirror a lot of the bits that make up ubuntu: the
 apt repositories of course, but also cdimages, releases, ports and
 cloud-images, and hopefully more in the near future (the MAAS images
 are in the pipe, too, for example).

 I've kicked the tires and deployed the full mirror a couple of times,
 and I think it's now time for more eyes to look at the code, and
 hopefully somebody else will find it useful.

 For what it's worth, I am currently using a very similar setup as an
 official Ubuntu archive and it seems to be doing pretty good.

 The code lives at: lp:~tribaal/charms/trusty/ubuntu-mirror/trunk and
 merge proposals are very welcome, either against the charm or the
 ubumirror package it is using (that I also happen to maintain). You
 can deploy it with:

 juju deploy cs:~tribaal/trusty/ubuntu-mirror
 juju deploy storage
 juju set storage nfs  # Or whatever storage provider you have a few Tb on
 juju add-relation storage ubuntu-mirror
 # Wait a few hours :)

 Future plans are roughly: get some tests written (it's a very simple
 charm, but hey), get some version approved in the official
 charmstore, and add the maas images to the syncing options. I'd also
 like to randomize the crontab schedules a little if left unchanged,
 but I've hit a few problems with the approach I took (using peer
 storage). I'm happy to discuss good ways to solve that, too.

 Note: I've seen an ubuntu proxy charm around here some time ago - this
 one is a *mirror*, so it'll rsync a few *terrabytes* of data if you
 let it do its thing :) It should hopefully not download the whole
 thing multiple times if you scale out, however, so add-unit away!


 Hope this helps somebody somewhere :)

 - Chris

 --
 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: Gluu Server Juju Charm

[Marco Ceppi]

Jose and Charles,

Could you summarize the issue? Is it something that we need to document or
bugs we should file in core?

Marco

On Wed, Sep 24, 2014 at 12:42 AM, José Antonio Rey j...@ubuntu.com wrote:

 On 09/23/2014 11:25 PM, Tim Penhey wrote:
  On 24/09/14 16:20, Michael Schwartz wrote:
  Juju team,
 
  Thanks to Charles and José, I was able to get my local deployment of
  Juju running, and later I was successful getting the Gluu Server and
  Gluu OpenDJ charms installed, which is great progress.
 
  Good to hear.
 
  Tim
 
 

 That's awesome to hear, Mike! I really look forward to seeing these
 charms in the review queue soon!

 Let us know if there's anything else we can assist you with, and we'll
 be more than happy to.

 --
 José Antonio Rey

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

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

Re: Application to ~charmers - Jorge Niedbalski

[Marco Ceppi]

You have a big plus one from me Jorge, thanks for all your contributions
and continuing growth of charms and tool ecosystem!

On Wed, Sep 24, 2014 at 10:54 PM, Jorge Niedbalski 
jorge.niedbal...@canonical.com wrote:

 Hello Charmers,

 I would like to have your consideration to become a member of the
 http://launchpad.net/~charmers team.

 I have been playing around with the Juju's ecosystem since some
 months, fair enough time to understand where a ~charmer should be
 pushing to contributors to make the environment safer for everyone.

 Part of my daily job is to deal with customers with several distinct
 deployment scenarios. I have been dealing with issues and feature
 requests on almost the entire Juju stack (Juju-core, juju-plugins,
 charms,  charm-helpers, charm-tools, openstack, juju-client, deployer,
 etc).

 Regarding to my contributions, the charms that i authored/maintain are:

 - https://jujucharms.com/trusty/rsyslog
 - https://jujucharms.com/trusty/rsyslog-forwarder-ha

 I also have contributed patches to other charms ( mysql,
 rabbitmq-server, nrpe, postgresql) as well to most of the
 ~openstack-charms in different areas.

 On ecosystems,  I have contributed several patches on the
 charm-helpers package (important: contrib.python, core modules), I
 have performed revisions and observations on charm-tools changes and
 authored/re-factored juju-plugins.  I also have contributions to the
 Amulet suite and minor fixes to jujuclient library. Also i have a fair
 amount of juju-core's mps and bugs.

 I understand that we need mature and well tested charms (I use them
 daily!!), for that reason i have been directly pushing and teaching
 constantly to contributors and customers for having unit and
 functional tests (see: trusty/vem  trusty/vsm charms) to improve the
 code coverage and documentation.

 On the community side, I have performed several reviews; blocking
 changes and asking for improvements whenever i can.  Also have been
 listed as official reviewer a couple of weeks, helping people on
 public channels and performed several training sessions to co-workers
 , team and people interested in charming in general.

 Please, feel free to ask me whatever you think is important (IRC:
 niedbalski), and again, thanks for your consideration.

 --
 Jorge Niedbalski R.
 # Email: jorge.niedbal...@canonical.com (GPG:0x3DA28544)

 --
 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: split charm templates and logic for different os (ubuntu/debian/centos)

[Marco Ceppi]

There shouldn't be much in the WordPress charm that's Ubuntu specific and
should work fine on Debian. Some charms already have logic to support
multiple Ubuntu releases by either coding switches in the hooks or by
leveraging a configuration management tool like chef or puppet which
abstracts that.

Marco

On Fri, Oct 10, 2014 at 9:20 AM, Vasiliy Tolstov v.tols...@selfip.ru
wrote:

 Does juju team already have knowledge how the best split hooks and
 templates to provide support for different OS. AS i google somebody
 already have patches to deploy into centos. For example now - i want
 to rewrite wordpress charm to support debian wheezy.

 --
 Vasiliy Tolstov,
 e-mail: v.tols...@selfip.ru
 jabber: v...@selfip.ru

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

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

Re: how to get info about completing deploying charms

[Marco Ceppi]

So there's no current way to determine when an environment is idle in Juju,
there's work being done to allow services to illuminate more than just the
current states of PENDING, INSTALLED, STARTED, ERROR in Juju which will
help illuminate where a service is in it's lifecycle. However, all of that
would be gathered from the juju status output. Currently only YAML and JSON
are supported but in 1.21 new options such as summary, oneline (comparable
to git log --oneline), and tabular will be available for parsing.

Marco

On Sun, Oct 12, 2014 at 5:25 PM, Vasiliy Tolstov v.tols...@selfip.ru
wrote:

 2014-10-13 0:38 GMT+04:00 Vasiliy Tolstov v.tols...@selfip.ru:
  How can i know that all services are deployed and works fine and ready
 to work?


 Or i need to parse juju status output?

 --
 Vasiliy Tolstov,
 e-mail: v.tols...@selfip.ru
 jabber: v...@selfip.ru

 --
 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: machine state stuck at pending

[Marco Ceppi]

In addition, there's also a `juju retry-provisioning machine-number`
which can be used after you upgrade in the event you encounter provisioning
issues in the future. Typical provisioning issues for machines include
resource limitations on account and errors downloading required
dependencies.

Marco

On Sun Nov 16 2014 at 2:34:59 PM Nate Finch nate.fi...@canonical.com
wrote:

 Definitely the low 1.20.x releases had a couple issues especially with
 containers. These were all fixed later, as Mark mentioned.  Hopefully
 that'll solve your problems.
 On Nov 15, 2014 1:02 PM, Mark Shuttleworth m...@ubuntu.com wrote:

 On 14/11/14 02:39, Sameer Zeidat wrote:
   Hello,
  I'm running juju 1.20.1 on a test maas cluster. Every now and then when
 I run juju add-machine the machine gets stuck at pending state
 (permanently). Maas shows status as Failed deployment.
  Is there a way to force machine state to error so I can
 retry-provisioning on it? I don't want to destroy it as I have some service
 deployment scripts that rely on machine number (using --to # deployment
 option).
  Appreciating your help.
 

 Hi Sameer

 A range of those 'pending' container issues were fixed during the set of
 releases from 1.20.1 to 1.20.11. I think it would be worth your updating
 to the latest 1.20 release. If you're on Ubuntu, add this to your
 /etc/apt/sources.list:

deb http://ppa.launchpad.net/juju/stable/ubuntu trusty main

 That should give you 1.20.11.

 Let us know if you still see any issues with containers getting stuck on
 the way up. Also, it's a great idea to be able to nuke-and-retry in the
 event that this does happen, I'll find out if we have a nice way to add
 that regardless (a stuck container might happen thanks to cosmic rays,
 we should have an escape mechanism). Ideally, Juju should detect the
 issue and nuke the container, trying again on your behalf.

 Mark


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

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

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

Re: RFC: unmounting /mnt on AWS instances

[Marco Ceppi]

I have a few charms that expect /mnt to be the ephemeral disk, while it
wouldn't be a huge headache and I certainly wouldn't want to stand in the
way of progress. It won't be trivial and I'll start to devise a way to test
all the charms so we can get a count of charms that expect /mnt to exist.
This should be a good starting place for how much effort would be required
to accommodate this new feature.

Any idea what version of juju we can expect to start seeing this land?

Thanks!
Marco Ceppi

On Mon Nov 17 2014 at 9:13:45 PM Andrew Wilkins 
andrew.wilk...@canonical.com wrote:

 Hi all,

 I am working on introducing storage as a first-class primitive in Juju.
 Charms will be able to indicate that they require storage (block devices,
 filesystems...), and when you deploy that charm you will be able to specify
 some parameters in order to fulfil the storage requirement.

 One thing I'd like to do is provide users a means of assigning ephemeral
 disks to units. The AMIs we use on AWS currently auto-mount the first
 ephemeral disk (if there is one) at /mnt. I think Azure does something
 similar; not sure about other providers.

 Are you relying on /mnt being there? If so, would it cause you a headache
 if this were taken away, by performing a umount /mnt after booting? (Bear
 in mind you can still mount it afterwards if you want to).

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

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

Re: charm-helpers fetch apt_install optimization

[Marco Ceppi]

I have to disagree slightly, currently (and thankfully?) the current way
most charm-helpers aim to be included in charms is by embedding a working
snapshot of that version of charm-helpers. So merging this wouldn't affect
a huge number of charms, instead maybe the 5 or 6 at most that download
from pypi and of those none may actual be broken. As we rethink the
distribution model for charm-helpers (making it a debian package, having
actual releases, etc) this would certainly become a larger concern. The
changes look good at my cursory check, and I hope to review in more detail
later this week.

That said I just wanted to point out that I don't think a change, even as
drastic as this would have a huge effect on the ecosystem. As charm
authors sync charm-helpers they'll end up in our testing environment and
should be caught then.

Marco

On Thu Nov 20 2014 at 12:33:55 PM Charles Butler 
charles.but...@canonical.com wrote:

 Jay,

 I think you're touching on some important topics. Tuning and optimizing
 charm installation without fetching tons of extra packages around an
 install is certainly something I'm very open to experimentation with.

 This particular merge makes me suggest we run this through the gauntlet of
 testing scenarios - as if we merge this as is it effects the default
 expected behavior of the apt_install, with  200 charms in the store - and
 im' going to venture to guess ~ 40% of those are python and charm-helpers
 based charms. This means a very expensive test would follow to ensure we
 don't break whats in the wild. If you were to refactor this to make that a
 parameter on apt_install, and leave the default behavior as is - I would be
 more confident in making the merge happen.


 All the best,

 Charles


 On Wed, Nov 19, 2014 at 6:27 PM, Jay Wren jay.w...@canonical.com wrote:

 Greetings,

 I wanted to bring attention to a pending MR
 https://code.launchpad.net/~evarlast/charm-helpers/use-no-install-recommends/+merge/242270
 which I feel can help charm-helpers.

 By not installing recommended packages, charms will install packages
 faster, with less unneeded packages.

 This leads to faster deploys and faster experience for new users and an
 overall better feeling about juju.

 On a similar subject, I am asking for feedback from charm-helpers users
 regarding apt related activity. I feel it might make sense use apt_pkg for
 as many operations as possible. Would a merge request of this nature be
 considered or is fork and exec to the more familiar system commands
 preferred?

 Thanks,
 --
 Jay

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


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

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

Re: juju-gui on utopic

[Marco Ceppi]

oneiric, precise, quantal, raring, saucy, trusty, utopic, and vivid are all
valid series for charms. We don't' freeze releases so once a release of
Ubuntu exists a charm series will also exist.

On Fri Nov 21 2014 at 11:21:28 PM José Antonio Rey j...@ubuntu.com wrote:

 Please correct me if I'm wrong, but I believe that, at the moment, we
 only have precise and trusty as open series in the Charm Store? Would be
 nice to clarify that.

 On 11/21/2014 10:05 PM, Richard Harding wrote:
  On Sat, 22 Nov 2014, Sameer Zeidat wrote:
 
   Hello,
  How do I deploy juju-gui on Ubuntu 14.10 (stable or otherwise)? I get
 charm not found cs:utopic/juju-gui.
  Setting 'juju-gui-source' to 'develop' didn't help.
 
  Thank you,Sameer
 
  At the moment the only way to use the charm on utopic is to use it as a
  local charm. I copied the trusty charm and deployed it on utopic on ec2
  successfully and verified that it works. It's not currently part of our
  supported charms. We've not really talked about it, but currently we
 supply
  supported charms for precise and trusty.
 
  Actually, I started to look at pushing up a non-official branch for your
  use to utopic, but there's not currently a series for charms for utopic.
 
  So I guess the bigger question is what are you up to? Are you running a
  juju environment based on utopic? Are they all other local charms?
 
 
  --
 
  Rick Harding
 
  Juju UI Engineering
  https://launchpad.net/~rharding
  @mitechie
 

 --
 José Antonio Rey

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

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

Re: unit-get public-address

[Marco Ceppi]

We typically discourage querying cloud specific utils in charms as it makes
them far less portable. It would be much more preferred to have this
patched in Juju.

On Wed Nov 26 2014 at 10:10:35 PM Andrew Wilkins 
andrew.wilk...@canonical.com wrote:

 Hi Mike,

 Sounds like you're hitting
 https://bugs.launchpad.net/juju-core/+bug/1308374.
 There's a workaround described in the bug description: use an external DNS.

 Alternatively, you could (temporarily) do something EC2-specific in your
 charm:
 $(ec2metadata --public-ipv4)

 Cheers,
 Andrew


 On Thu, Nov 27, 2014 at 1:02 AM, Mike Schwartz m...@gluu.org wrote:

 Juju gurus,

 $(unit-get public-address) from within a hook is failing for us right now
 on AWS. It returns the private address instead. I heard a fix will be
 available in juju v1.21. Is there any way workaround, as we really want to
 ship the Gluu Server charm ASAP.

 thx,

 Mike


 -
 Michael Schwartz
 Gluu
 Founder / CEO
 m...@gluu.org

 --
 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: How do I ask for a review for my charm?

[Marco Ceppi]

Can you link us to your request?

On Thu, Dec 4, 2014, 8:43 AM saurabh saurabh.ku...@techblue.co.uk wrote:

 Hi,

 I wanted to know that how do I raise a request to review my charm? I
 have already subscribed a charmer to my branch but my charm doe not show
 up in the review queue at http://review.juju.solutions/

 Any help is appreciated.


 Many Thanks,

 --
 Saurabh Kumar
 System Admin


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

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

Re: How do I ask for a review for my charm?

[Marco Ceppi]

These were just created 10 mins ago. They should show in the review queue
shortly, it can take up to 45 mins.

On Thu Dec 04 2014 at 9:53:28 AM saurabh saurabh.ku...@techblue.co.uk
wrote:

  Thanks David and Marco,

 Here are the links to the bugs I just created and linked them to my
 respective charms.

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


 Many Thanks,



 On Thursday 04 December 2014 08:03 PM, David Britton wrote:

 Hi there,

 I think just a link to the bug in reply to this message so we are on the
 same page would be helpful.

 Thanks!

 --
 David Britton davidpbrit...@gmail.com
 On Dec 4, 2014 7:31 AM, saurabh saurabh.ku...@techblue.co.uk wrote:

  Hi Marco,

 Sorry for making the noise but I did not understand what you said. I have
 already set a branch reviewer and also have subscribed him to my branch.
 Shall I provide you the links to my charm's name-space?


 Thanks,

 On Thursday 04 December 2014 07:14 PM, Marco Ceppi wrote:

 Can you link us to your request?

 On Thu, Dec 4, 2014, 8:43 AM saurabh saurabh.ku...@techblue.co.uk
 wrote:

 Hi,

 I wanted to know that how do I raise a request to review my charm? I
 have already subscribed a charmer to my branch but my charm doe not show
 up in the review queue at http://review.juju.solutions/

 Any help is appreciated.


 Many Thanks,

 --
 Saurabh Kumar
 System Admin


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


 --
 Saurabh Kumar
 System Admin


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


 --
 Saurabh Kumar
 System Admin


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

[ANN] Amulet 1.9.0

[Marco Ceppi]

Hello,

I'm happy to announce the Amulet 1.9.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

# Release notes

These are the commits included in this release:

f88f85d Add Deployment.destroy(...) method
a12f3a8 Be smarter about getting name of the charm under test
5a699e6 Use constraints from bundle file when load() is called
28bd57f Removed obsolete test.
7efec49 Don't copy .git directory when making a local charm.

Special thanks to the contributors for this release:

- Brad Crittenden
- Tim Van Steenburgh

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 github repository
https://github.com/marcoceppi/amulet

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

Re: juju vs. Puppet/Chef/Salt/Ansible/etc.

[Marco Ceppi]

On Wed Dec 10 2014 at 10:28:41 AM Marco Ceppi ma...@ondina.co wrote:

 On Wed Dec 10 2014 at 10:26:48 AM Eric Snow eric.s...@canonical.com
 wrote:

 I had tried the explanation route to no avail.  I'll probably work up
 a demo for the specific folks I have in mind.  I think juju is one of
 those things that makes more sense when you see it in action.

 One thought I had is that we could work up a demo-in-a-box.  Either
 make a VM image available (with local provider in it?) or fix local
 provider so that it runs entirely in VMs/containers.  For the latter
 we could distribute a script that spins up the new local provider to
 make it super easy for someone to try juju out locally, AKA
 juju-in-a-box.


 We have most of this already, we spin vagrant images that have the local
 provider installed, configured, and bootstrapped on vagrant up


Forgot the link! https://juju.ubuntu.com/docs/config-vagrant.html



 -eric

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


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

Re: feedback about juju after using it for a few months

[Marco Ceppi]

 a --force flag to destroying a service so you can just
say kill this with fire, now plz

10. I think there's something weird about relation-set and relation-get
 between services when you add and remove relations multiple times. For
 example, the first time I set a relation to a Postgres charm I get a
 database back and my desired roles configured, but if I remove the relation
 and then add it back I only get the database settings. The roles parameter
 is missing setup, so I don't have the right permissions in the DB the
 second time I set the relation. Anyone has seen this too with other charms?


This is a bug in the PostgreSQL charm. I'd file a bug so the author is
aware of this. https://bugs.launchpad.net/charms/+source/postgresql

That's it, thank you for those who made it to the end :-D


Thank you so much for your usage and feedback of Juju thus far. We really
want to make a tool that works best for you and everyone else. You've
raised some good points, some things we're aware of and working on, some
things we can improve upon. Please continue to pass feedback as you
continue to use Juju and let us know anywhere else we can help improve!

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

Re: feedback about juju after using it for a few months

[Marco Ceppi]

On Thu Dec 18 2014 at 1:00:46 AM John Meinel j...@arbash-meinel.com wrote:

 ...


 9. If you want to cancel a deployment that just started you need to keep
 running remove-service forever. Juju will simply ignore you if it's still
 running some special bits of the charm or if you have previously asked it
 to cancel the deployment during its setting up. No errors, no other
 messages are printed. You need to actually open its log to see that it's
 still stuck in a long apt-get installation and you have to wait until the
 right moment to remove-service again. And if your connection is slow, that
 takes time, you'll have to babysit Juju here because it doesn't really
 control its services as I imagined. Somehow apt-get gets what it wants :-)


 You can now force-kill a machine. So you can run `juju destroy-service
 $service` then `juju terminate-machine --force #machine_number`. Just make
 sure that nothing else exists on that machine! I'll raise an issue for
 having a way to add a --force flag to destroying a service so you can just
 say kill this with fire, now plz


 I understand that, but I discovered it's way faster and less typing if I
 simply destroy-environment and bootstrap it again. If you need to force
 kill something every time you need to kill it, then perhaps somethings is
 wrong?


 I agree, something is wrong with the UX here. We need to (and would love
 your feedback) figure out what should happen here. The idea is, if a
 service experiences a hook failure, all events are halted, including the
 destroy event. So the service is marked as dying but it can't die until the
 error is resolved. There are cases, where during unit termination, that you
 may wish to inspect an error. I think adding a `--force` flag to destroy
 service would satisfy what you've outlined, where --force will ignore hook
 errors during the destruction of a service.

 Thanks,
 Marco Ceppi


 IIRC, the reason we support juju destroy-machine --force but not juju
 destroy-unit --force is because in the former case, because the machine is
 no-more Juju has ensured that cleanup of resources really has happened.
 (There are no more machines running that have software running you don't
 want.)
 The difficulty with juju destroy-unit --force is that it doesn't
 necessarily kill the machine, and thus an unclean teardown could easily
 leave the original services running (consider collocated deployments).
 juju destroy-service --force falls into a similar issue, only a bit more
 so since some units may be on shared machines and some may be all by
 themselves.


Right, and I agree. This isn't the best thing for --force at a service or
unit level. What I would like to see instead is the scenario I just typed
deploy on this service and I have three units and I don't want it anymore
or this is a mistake in which case destroy-service --force would execute
the destruction of the service and set juju into a state where when a hook
errors (or if it's in an error state) auto-resolve that and continue with
service destruction. Then the machine can just be reaped with the upcoming
machine reaper stuff and everything moves forward.

That said, I feel like we're doing a little throwing the baby out with the
 bathwater. If you are in a situation where there is just one unit on each
 machine, then destroy-unit --force could be equivalent to destroy-machine
 --force, and that could chain up into destroy-service --force (if all units
 of service are the only thing on their machines, then tear them all down
 ignoring errors and stop the machines).

 John
 =:-

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

[ANN] Charm Tools 1.5.1

[Marco Ceppi]

Hello Juju!

There is a new bug fix release of charm-tools which fixes issues with those
running charm proof in CI/build/testing environments. It is strongly
suggested those running charm-proof in any automated fashion update to this
latest release. To verify which version of charm-tools you are using you
can execute the following command:

charm version

# Install

Charm Tools is available for users via the stable juju ppa or from PyPi via
pip:

## Aptitude
sudo add-apt-repository ppa:juju/stable
sudo apt-get update
sudo apt-get install charm-tools

## Pip

pip install charm-tools

# Upgrade

Existing installs of charm-tools can be upgraded using the following methods

## Aptitude

sudo apt-get update
sudo apt-get install PyPi via `pip install -U charm-tools`

## Pip

pip install -U charm-tools

# Changes
- Expose returncode from subcommands

This is the last planned release in the 1.5 series and 1.6 series and
branch are now open for development. You can always contact us for
additional help via #juju on irc.freenode.net, http://askubuntu.com with
questions tagged #juju, or via this very mailing list juju@lists.ubuntu.com

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

Re: Screenshots in charm READMEs (policy request)

[Marco Ceppi]

You could, the only requirement is that it's served over HTTPS. We're
simply recommending imgur as an example of a free image hosting service
which has https enabled.

On Mon Feb 02 2015 at 2:05:57 PM Charles Butler 
charles.but...@canonical.com wrote:

 Nick,

 Why add a complex requirement such as validating image hosting?

 Why can't I use my Dropbox account for example?

 On Feb 2, 2015 8:32 AM, Nick Veitch nick.vei...@canonical.com wrote:
 
  I like the idea in general. We may want to be careful as to allowed
  domains though, (I think imgur generates specific urls per image, so
  they can't be swapped out, but not all sites do) which may increase
  the overhead on implementing it. I think you would definitely need to
  add some text specifying that the images must be their own!
 
  On Mon, Feb 2, 2015 at 12:16 PM, Jorge O. Castro jo...@ubuntu.com
 wrote:
   Hi everyone,
  
   Rick H. mentioned to me that if a charm has a Markdown image snippet,
 like say:
  
   ![alt-text](https://imgur.com/blah)
  
   ... then jujucharms.com will render the screenshot.
  
   Clearly this is a nice easy way to allow charm authors to add
   screenshots to their charm in the store, however, since we're serving
   the entire charm store over https the image URLs need to be served
   over https, so I would like to add the following to charm store
   policy:
  
   You can add screenshots to your readme using standard markdown
   format(link), however in order to be rendered in the store, the images
   must be served over https,
  
   We recommend something like imgur that has https and a CDN that makes
   it dead easy for people to host images. Over time Rick plans to enable
   us to host images and do fancier things, but the intent of this is
   just to allow images for people with little effort on the backend
   engineering.
  
   Thoughts?
  
   --
   Juju mailing list
   Juju@lists.ubuntu.com
   Modify settings or unsubscribe at:
 https://lists.ubuntu.com/mailman/listinfo/juju
 
 
 
  --
  Nick Veitch
  nick.vei...@canonical.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: An Open Question: Charm Dependency Management

[Marco Ceppi]

Well there are two notions of testing, unit_test and functional_test one is
largely more expensive than the other. Outside of that test-depends is a
good one. Whatever it is we should identify those so we can make sure
bundletester is updated to sniff these targets out (if this is the route we
chose).

On Tue Jan 20 2015 at 1:18:05 PM David Britton david.brit...@canonical.com
wrote:

 On Tue, Jan 20, 2015 at 05:58:24PM +, Marco Ceppi wrote:
  I don't see how a Makefile in a charm doesn't resolve this issue.

 +1 on some standard published Makefile targets.  We already have some
 that are highly recommended:

  - test
  - lint

 Maybe:

  - test-depends or depends  # to install/update dependencies needed for
   testing

 Are there others that are needed/missing or that I forgot we already
 have as standard?

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

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

Re: An Open Question: Charm Dependency Management

[Marco Ceppi]

I don't see how a Makefile in a charm doesn't resolve this issue. As long
as we define what targets a user should create in the Makefile, the
Makefile can then do everything required: create a virtualenv and install
deps, install ruby and execute bundler, npm for node, etc. Since charms are
so varies in how they're written and what language they're implemented in
this seems to make the most sense.

Marco

On Tue Jan 20 2015 at 12:37:00 PM Charles Butler 
charles.but...@canonical.com wrote:

 Greetings,

 If you work on charms in any capacity: this affects you, and I would love
 to have your feedback.

 While working the review queue I've encountered a few charm merges that
 are failing our testing infrastructure due to missing dependencies. This
 also has implications that reach beyond our testing infrastructure: Anyone
 that is submitting a new charm, Patches being accepted to existing charms,
 and even our documentation efforts over on the  Charm Authorship Docs.

  There seems to be a bit of confusion about what the recommended process
 is to ensure all our dependencies are encapsulated in the charm.

 Having spoken with various members of the development community, I feel
 like our dependency encapsulation process for charms is still very much a
 grey area with several different ideologies on how to manage them, thus far
 I've seen:

- A Virtualenv per project to manage python dependencies
- make targets that sudo install packages on the host system
- Zero Dependency management

 This is indeed a difficult topic to approach and digest as we're
 supporting basically everything out there. Not everyone uses the same
 tool-chain to accomplish the goal of dependency isolation - and several
 different Config Management tools have a different approach to this that
 assume it is installed on the host. this leaves a broken experience for:

- new charm authors
- CI
- Anyone that comes along and runs the test targets or bundletester

 If we're going to ask our community to contribute to charms, is it fair to
 make them run down dependencies that may or may not exist on their host? It
 seems like we can do a better job of highlighting this, and providing a
 quick start style development target to install these pre-deps which would
 satisfy CI and Development. With this being the proposal, I follow it with
 some questions:

- How have *we* solved this problem in other areas of our ecosystem?
- How have other platforms solved this problem?
- Can we emulate / improve on that pattern?
- If a package management solution exists for a technology (eg:
virtualenv for python, bundler for ruby, npm for node, berkshelf for chef)
- can we adopt these and get started by templating in the dependency
management into the charm generator template?


 I'm hoping this email is seen more as a conversation starter vs me being
 pedantic - I'm more concerned with getting the right set of information to
 our users/community than I am in solving some meta problem of packaging
 charms and their Development Environments.

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

Lets version lock the docs!

[Marco Ceppi]

Hey everyone,

There's currently quite a few version of juju available [0] from various
sources (cloud archive, ubuntu archive, stable ppa, source). While I know
the release team is doing a great job in making sure that versions of juju
are consistent across platforms, it's inevitable that users will be on
different versions. As more features land in juju, documentation will
become inconsistent for users. This, again, is a topic that has undergone
quite a bit of discussion from when the docs were originally migrated to
Markdown at various UDS and vUDS meetings what I'd like to do is get the
ball moving on completing this: offering multiple version of the docs for
released version of juju.

The proposal is as follows. The juju docs repository will continue to have
a master branch which will be tip of trunk for juju and documentation
bits, essentially devel. As the release team gears up for a release we
will create a branch for that release milestone (1.20, 1.21, 1.22, etc).
From there, the jujucharms.com/docs website will offer latest release as
default view (ie: jujucharms.com/docs/getting-started) and a drop down to
select previous versions of docs, which will be available at docs/VERSION
(ie: jujucharms.com/docs/1.21/getting-started).

Any issues, typos, or mistakes that need to be addressed and previous
versions of the docs can take place in that branch and will continued to be
built periodically with the rest of the doc. We're pretty confident this
model will work out great for those writing the docs, not wanting to land
fixes too soon while improving overall user experience in reading the
documentation.

Ideally, we'd like this to coincide with the next juju release, 1.21, so
before that lands we'd like to call for feedback about the process outlined
above, concerns, or questions.

[0]: http://packages.ubuntu.com/search?keywords=juju

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

Re: An Open Question: Charm Dependency Management

[Marco Ceppi]

We are striving to test charms against all substrates and architectures
juju supports; and are nearing completion for that goal. Manual provider is
not currently tested AFAIK but will likely be in the future.

On Tue Jan 20 2015 at 7:41:27 PM Andrew Wilkins 
andrew.wilk...@canonical.com wrote:

 On Wed, Jan 21, 2015 at 1:36 AM, Charles Butler 
 charles.but...@canonical.com wrote:

 Greetings,

 If you work on charms in any capacity: this affects you, and I would love
 to have your feedback.

 While working the review queue I've encountered a few charm merges that
 are failing our testing infrastructure due to missing dependencies. This
 also has implications that reach beyond our testing infrastructure: Anyone
 that is submitting a new charm, Patches being accepted to existing charms,
 and even our documentation efforts over on the  Charm Authorship Docs.


 On this topic, does the automated testing cover testing charms with the
 manual provider? There have been charms that failed (and were fixed)
 because they did not explicitly install dependencies. Those charms were
 using packages that are automatically installed as a result of cloud-init
 being on the machine; since the manual provider does not use cloud-init,
 those packages don't get automatically installed and the charms fail. IIRC,
 python-yaml fits into this category.


  There seems to be a bit of confusion about what the recommended process
 is to ensure all our dependencies are encapsulated in the charm.

 Having spoken with various members of the development community, I feel
 like our dependency encapsulation process for charms is still very much a
 grey area with several different ideologies on how to manage them, thus far
 I've seen:

- A Virtualenv per project to manage python dependencies
- make targets that sudo install packages on the host system
- Zero Dependency management

 This is indeed a difficult topic to approach and digest as we're
 supporting basically everything out there. Not everyone uses the same
 tool-chain to accomplish the goal of dependency isolation - and several
 different Config Management tools have a different approach to this that
 assume it is installed on the host. this leaves a broken experience for:

- new charm authors
- CI
- Anyone that comes along and runs the test targets or bundletester

 If we're going to ask our community to contribute to charms, is it fair
 to make them run down dependencies that may or may not exist on their host?
 It seems like we can do a better job of highlighting this, and providing a
 quick start style development target to install these pre-deps which would
 satisfy CI and Development. With this being the proposal, I follow it with
 some questions:

- How have *we* solved this problem in other areas of our ecosystem?
- How have other platforms solved this problem?
- Can we emulate / improve on that pattern?
- If a package management solution exists for a technology (eg:
virtualenv for python, bundler for ruby, npm for node, berkshelf for chef)
- can we adopt these and get started by templating in the dependency
management into the charm generator template?


 I'm hoping this email is seen more as a conversation starter vs me being
 pedantic - I'm more concerned with getting the right set of information to
 our users/community than I am in solving some meta problem of packaging
 charms and their Development Environments.

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

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

Re: Makefile target names

[Marco Ceppi]

We can also add Makefile checking to charm proof, for an even greater
redundancy.

To avoid multiple invocations of charm proof (not terrible, IMO) lint could
be broken down further:

lint: proof code_lint

proof:
charm proof

code_lint:
# Your code here

Then have bundle tester sniff out code_lint, or use the test.yaml
configuration to point lint to code_lint. Doesn't change UX for the
author/contributor but does add a level of complexity. It seems like
Makefile's are the overwhelming method for consolidating tasks for charms,
I'd like to kick off the following proposal for Makefile format to be
placed in charm create templates:

```
test: lint unit-test functional-test
lint: proof code-lint
sync: charm-helpers-sync

code-lint:
# FILL IN COMMANDS FOR PERFORMING CODE LINT

unit-test:
   # COMMANDS REQUIRED TO UNIT TEST

charm-helpers-sync:
@scripts/sync.py 

functional-test:
juju test

proof:
charm proof
```

With a test.yml file that contained the following:

```
makefile:
- code-lint
- unit-test
```

And where applicable, add a .venv target for python charms and recommend
the use of having charm deps modeled in requirements.txt and pip installed
to that virtualenv.

Opinions, additions, concerns?

On Thu Jan 22 2015 at 11:41:56 AM Wes Mason wesley.ma...@canonical.com
wrote:

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

  On 22 January 2015 at 16:29, David Britton david.brit...@canonical.com
 wrote:
  On Thu, Jan 22, 2015 at 04:17:26PM +, Simon Davy wrote:
  On 22 January 2015 at 15:13, David Britton 
 david.brit...@canonical.com wrote:
  
   lint:
- make lint
  
 
  Could we also make[1] the charm linter lint the makefile for the
  presence of targets agreed in the outcome of this thread?
 
  charm proof
 
  I like it.  (bundle tester already runs this)

 Which is interesting, as my lint targets general runs charm proof too,
 so it'd be run twice in that case?

 Not a big issue, but if the charm store/review queue is automatically
 charm-proofing too, perhaps the make lint target should not be?

 --
 Simon


 Whelp it's still nice to have as part of lint when developing the charm,
 and charm-proof isn't exactly the slowest process to run multiple times.

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

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

Re: Availability of alpha Easy Juju on Azure disk image

[Marco Ceppi]

Hey Andrew,

I agree with you on the feedback, since it's an HTML page at the moment
it's hard to incorporate those items, but I've forked the repo and started
building a lightweight Python app to provide that feedback to the user.

Marco

On Tue Feb 10 2015 at 9:37:48 PM Andrew Wilkins 
andrew.wilk...@canonical.com wrote:

 Hi Samuel,

 Looks neat. A few things:
  1. Once the VM is ready, the entire landing page keeps refreshing at 1s
 intervals. That doesn't leave a lot of time to add the .publishsettings
 file and upload.
  2. There's no feedback to say whether or not the .publishsetttings file
 has been uploaded, and whether bootstrapping is underway. I guess I did it
 twice because of point 1, because now I have two juju bootstrap processes
 on the machine :)
  3. When the GUI eventually came up, it wouldn't accept the password that
 the page displayed. This is related to point 2: the page gave me the link
 to the GUI for one env, and the password for the other.

 It'd be great if the upload credentials bit greyed out once uploaded,
 and then under 3. Wait for a few minutes... there was something
 describing the current status. e.g. Installing Juju, Deploying Juju GUI.

 Cheers,
 Andrew

 On Tue, Feb 10, 2015 at 11:01 PM, Samuel Cozannet 
 samuel.cozan...@canonical.com wrote:

 Dear All,

 Yesterday we released an alpha of a new Ubuntu image on MS Azure VM
 Depot: https://vmdepot.msopentech.com/Vhd/Show?vhdId=50248

 If you use that image and spin a VM with it, you'll be able to upload
 your Azure .publishsettings file to its web interface. From that moment,
 the VM will boostrap a Juju environment, install the Juju GUI.
 The main web page auto refreshes, and presents the link to the Juju GUI
 with a password when it's ready.

 The whole process from upload to Juju GUI takes about 10min to complete,
 and does not require any knowledge of Juju or Ubuntu to start playing.
 It leaves you with a fully functional Juju environment using your default
 subscription as your main Azure provider.

 We hope you enjoy that new and easy way to start with Juju. We aim at
 making this image available from the Marketplace when we gather enough
 feedback and fix bugs that remain.

 The whole code and explanations are available on
 https://github.com/SaMnCo/juju-azure. Please use that repo to send
 feedback while we make it better. You can also answer to this thread on the
 list to ask any question or feature request you may have.

 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

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


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

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

Re: Juju stable 1.21.1 is released

[Marco Ceppi]

WOW! What an action packed release! Great job to all the people who
reported bugs, hacked on code, and helped release this!

On Thu Jan 29 2015 at 12:03:07 PM Curtis Hovey-Canonical 
cur...@canonical.com wrote:

 # juju-core 1.21.1

 A new stable release of Juju, juju-core 1.21.1, is now available.
 This release replaces 1.20.14.


 ## Getting Juju

 juju-core 1.21.1 is available for utopic and backported to earlier
 series in the following PPA:

 https://launchpad.net/~juju/+archive/stable

 Windows and OS X users will find installers at:

 https://launchpad.net/juju-core/+milestone/1.21.1



 ## Notable Changes

   * Selecting provisioner harvest modes
   * Using apt mirrors
   * Configuring OS update and upgrade for faster provisioning
   * Using daily image streams for faster provisioning
   * Selecting the agent stream to get alternate version of Juju
   * Tuning Juju to take advantage of NUMA
   * Configuring the MAAS network rules
   * Improved availability zone selection in Openstack and MAAS
   * Juju now prefers SSD storage in AWS
   * Adding many machines
   * Choosing the nodes used to ensure high availability
   * Inspecting the API connection settings
   * Managing who can connect to the Juju environment
   * Upgrade robustness
   * Rebooting units from charm hooks
   * Improvements to ports management for charms
   * Developing Juju providers for clouds without storage
   * More mirrors for faster bootstraps


 ### Selecting provisioner harvest modes

 Juju keeps a model of what it thinks the environment looks like, and
 based on that model, can harvest machines which it deems are no longer
 required. This can help keep your costs low, and keep you out of web
 consoles. Juju supports several harvesting modes to suit your needs.

 Destroyed: Juju will harvest only machine instances that are marked as
 dead, and that Juju knows about. Running instances unknown to Juju will
 not be harvested. This is the default mode.

 Unknown: Juju will harvest only instances that Juju does not know about.

 All: Juju will terminate all instances – destroyed or unknown – that it
 finds. This is a good option if you are only utilizing Juju for your
 environment.

 None: Juju won't harvest any machines. This is the most conservative
 mode, and a good choice if you manage your machines utilizing a separate
 process outside of Juju.

 Juju's harvesting behaviour is set through the environments.yaml file.

 provisioner-harvest-mode: MODE

 'provisioner-harvest-mode' replaces 'safe-mode'. Environments with
 'safe-mode' set will be converted to 'provisioner-harvest-mode' when
 upgraded.


 ### Using apt mirrors

 You can now configure 'apt-mirror' in environments.yaml to specify the
 mirror used by all the machines provisioned in the environment:

 apt-mirror: http://my.archive.ubuntu.com

 On precise, the cloud tools archive is now pinned before calling apt
 upgrade to ensure its packages are a lower priority than the default
 precise archives. Charms developed on precise will see the same packages
 when deployed into a Juju provisioned machine. If your precise charm
 requires packages from the cloud tool's archive, you can use the
 'target-release' option to specify the archive to select:

 apt-get --target-release precise-updates/cloud-tools my-package


 ### Configuring OS update and upgrade for faster provisioning

 When Juju provisions a machine, its default behaviour is to update the
 list of available packages and upgrade the existing packages to the
 latest version. If your OS images are fresh or the services you deploy
 do not require updated packages, you can disable updates and upgrades to
 provision the machine faster.

 Two configuration options are available to disable apt updates and
 upgrades. When your OS images are fresh, you can set both
 'enable-os-refresh-update', and 'enable-os-upgrade' to false. When you
 know that some charms want the latest packages to to set up services,
 you will want to keep 'enable-os-refresh-update' set to true.

 You can configure the options in environments.yaml for fast provisioning
 like so:

 enable-os-upgrade: false
 enable-os-refresh-update: false

 The local provider skips apt upgrades by default for faster
 provisioning. If you wish to enable upgrades in your local
 development, set 'enable-os-upgrade' to
 true in your environments.yaml:

 enable-os-upgrade: true

 If you are using the local-provider to develop charms or test, you
 will want to regularly purge the juju template and lxc caches to
 be certain you are using fresh images. For example, before you start
 testing a new trusty charm, you can remove the template and cloud
 image like this:

 sudo lxc-destroy -n juju-trusty-lxc-template
 sudo rm -r /var/cache/lxc/cloud-trusty


 ### Using daily image streams for faster provisioning

 Juju prefers to use the slow-changing released images when
 provisioning machines. The 'image-stream' option in environments.yaml
 

Re: juju deploy ceph hangs in pending in maas environment

[Marco Ceppi]

If you're able to SSH in to the machine, can we see the contents of
`/var/log/juju/unit-ceph-0.log` and `/var/log/juju/machine-1.log` those
will be the first place to look as to why this isn't working. From the
sounds of it, MAAS provisioned the machine but the juju agent failed to
install. The agent-state: pending is a clear indication it hasn't
registered itself with the bootstrap node yet.

Thanks,
Marco Ceppi

On Wed Jan 28 2015 at 4:50:51 PM Daniel Bidwell drbidw...@gmail.com wrote:

 I have ubuntu 14.04.1 with maas 1.7.1 rc4 and juju 1.20.14. My client
 machine is commissioned and deployed. I can ssh ubu...@cl1stn2.maas and
 I can juju ssh 1 successfully. I did juju deploy --config config.yaml
 ceph --to 1.

 juju status ceph looks like:

 juju status ceph
 environment: maas
 machines:
   1:
 agent-state: pending
 dns-name: cl1stn2.maas

 instance-id: /MAAS/api/1.0/nodes/node-caa78cae-a5d5-11e4-b918-
 180373b04ac9/
 series: trusty
 hardware: arch=amd64 cpu-cores=16 mem=24576M tags=auitsdisk
 services:
   ceph:
 charm: cs:trusty/ceph-31
 exposed: false
 relations:
   mon:
   - ceph
 units:
   ceph/0:
 agent-state: pending
 machine: 1
 public-address: cl1stn2.maas
 networks:
   maas-em1:
 provider-id: maas-em1
 cidr: 10.20.0.0/24

 I don't see any attempt to contact cl1stn2.maas and the status stays in
 pending for ever. I can ssh to cl1stn2.maas and juju ssh 1
 successfully. I don't see anything in the all-machines.log.

 I can ping from the bootstrap server to the client machine and from the
 client machine to the bootstrap server.  They all have proper dns.

 Where do I look to find out what it is waiting for?
 --
 Daniel Bidwell drbidw...@gmail.com


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

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

Re: no matching node is available

[Marco Ceppi]

Hi VM,

The 409 CONFLICT error is the right error, and the error that MAAS provides
through the API when no machines matching the criteria supplied are
available. Juju doesn't directly query MAAS for how many machines are
available it simply takes the criteria you supplied (or the default
constraints) and requests MAAS provision a machine which has at least these
characteristics. MAAS will either do so or report back an error, in this
case the 409, since no machines are available that match that criteria (let
alone there not being any machines available).

Since you're using MAAS with a low number of available machines, you may
instead want to try deploying to containers on the single node you have
available. By default juju will provision one machine per unit of service
in it's topology, but you can help guide where Juju should place machines
if that pattern doesn't suite your needs.

There are two ways to achieve this. The first is using the `--to` flag, as
you've alluded to, though this is seldom recommended as you run the risk of
charms conflicting with each other over resources on a system. A better
solution would be to use containers on these machines, for instance `juju
deploy --to lxc:1` which would deploy that service to an LXC container on
machine 1. You can find the machine numbers from the output of `juju
status` in the machine section of the YAML output.
https://jujucharms.com/docs/charms-deploying#deploying-to-specific-machines-and-containers

For what it's worth, the MAAS experience is improved when you have more
machines available in your pool.

Thanks,
Marco

On Mon Dec 22 2014 at 5:54:41 PM Vahric Muhtaryan vah...@doruk.net.tr
wrote:

 Hello All ,

 Im testing juju with MAAS and looks like somehow juju or MAAS do not
 recognise that machine pool is over.
 For example if I have just only one machine available for reservation and
 install the mysql or  wordpress
 Juju get one machine from MAAS and install related software packages.

 Problem is when I would like to install second thing , in my example is
 database, its try to catch one more machine but problem is there is no
 available server , but its catching but because of serve is not available,
 its mark it 409 CONFLICT no matching node is available .

 My idea is before provision something MAAS can check and confirm the
 environment.

 My question is juju or MAAS somehow need to know servers are really
 available or not ? If not can ask to admin for continue or not or try to
 advise share or install on same machine which already other service is
 runnung (like deploy —to 1 mysql)

 Regards
 VM
 --
 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] Tests are officially required for trusty, will be strongly recommended for precise

[Marco Ceppi]

Testing is no new topic to the list and the ecosystem at large. We've
discussed and hashed out required testing for a while, over several UDS,
vUDS, and emails. Each time we discuss this testing garners a swelling
response, a large portion of +1s from charmers and community alike, and the
definition of which has not changed or been contested. Testing is largely
implemented in practice within the ecosystem, nearly all trusty charms
currently have testing within the charm to some extent. This mail shouldn't
surprise many and is really an administrative task which was overlooked the
last time this was discussed.

With that said I've made the following proposal to the Juju Docs [1]. This
is simply an announcement to mark what has been an effective policy for
charms for over 10 months now.

[0]: https://lists.ubuntu.com/archives/juju/2013-December/003330.html
[1]: https://github.com/juju/docs/pull/222

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

Re: problem with amulet and ssh

[Marco Ceppi]

Thanks Nicolás for brining this to our attention and Stuart for shedding
light on how deep this bug runs. While it's true we're kind of tied to
doing what Juju does, that doesn't mean we can't look at ways to alleviate
this in Amulet to avoid tests to prevent them from failing.

On Fri, Feb 13, 2015 at 12:38 PM, Stuart Bishop stuart.bis...@canonical.com
 wrote:

 On 13 February 2015 at 09:42, Nicolás Pace nicop...@gmail.com wrote:
  Hi guys,
  I'm having a problem with amulet.
  i implemented a test with this chunk of code inside:
 
  logstash_indexer_agent = d.sentry.unit['logstash-indexer/0']
  curl_response = logstash_indexer_agent.run(curl
  http://127.0.0.1:9200/index/_search?size=1;)[0]
  print(curl_response)
 
  that print is throwing this:
  http://paste.ubuntu.com/10197382/
 
  I found a fixed bug that appears to be similar to this one:
  https://bugs.launchpad.net/ubuntu-ci-services-itself/+bug/1283198
 
  Any idea what could it be?

 Good timing. This one bit me enough times today that I linked the
 original bug from 2011 to Amulet.
 https://bugs.launchpad.net/juju/+bug/802117.

 What is happening is juju pollutes both ~/.ssh/known_hosts and
 ~root/.ssh/known_hosts with provisioned host keys and they are never
 cleaned up. When the IP addresses gets recycled, which seems to happen
 a few times a day recently, all sorts of things start randomly
 failing. Particularly test suites that need to 'juju ssh' or 'juju
 run' stuff automatically.

 The simple fix is having juju pass an option to ssh to not use the
 user's known_hosts files, instead a file specific to the environment.
 Extra points for having juju clean out keys when machines are
 destroyed.

 --
 Stuart Bishop stuart.bis...@canonical.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] Lots

[Marco Ceppi]

The queue is quite backed up. A few people have reached out asking about
when items will be addressed so I spent a few hours cleaning up as much as
I could.

- Pure-Python Django: Merged;
https://code.launchpad.net/~patrick-hetu/charms/precise/python-django/pure-python/+merge/226742
- Liferay to trusty: Incomplete;
https://bugs.launchpad.net/charms/+bug/1390502
- Quassel-core: ; https://bugs.launchpad.net/charms/+bug/999439
- mariadb/fix1401971: Merged;
https://code.launchpad.net/~martijn4evers/charms/trusty/mariadb/fix1401971/+merge/244639
- mariadb/lp1401971: Fix Committed
- jenkins-add-password-default: Merged;
https://code.launchpad.net/~a.rosales/charms/precise/jenkins/jenkins-add-password-default/+merge/237919
- nfs/automated-test-fixes: Merged;
https://code.launchpad.net/~aisrael/charms/precise/nfs/automated-test-fixes/+merge/237590
- cassandra/fix-metadata: Merged;
https://code.launchpad.net/~jorge/charms/precise/cassandra/fix-metadata/+merge/239421
- squid-reverseproxy: Merged;
https://code.launchpad.net/~bloodearnest/charms/precise/squid-reverseproxy/trunk/+merge/235429
- nrpe: Needs Fixing;
https://code.launchpad.net/~rcj/charms/precise/nrpe/trunk/+merge/235380

I hope to spend more time in the queue later this week to get the items
over a month old out of there.

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

[ANN] Amulet 1.10.0 released

[Marco Ceppi]

Hello,

I'm happy to announce the Amulet 1.10.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

# Release notes

These are the commits included in this release:

8aa3e09 Validate commands against subordinates work
61ae7ee Simplify logic for making sure subordinate shows up
a151d7d Add a subordinate to functional tests
adfd785 Use trusty and trusty charms for function tests
8a1b911 Pull subordinate information when available and add them as units
eb556a9 Better language
33b9df1 add .git control_dir handling
bedc66b fix placement in add calls
e41c41d encapsulate some typical boilerplate for bundle testing
978f3ff more test fixes and factors
c517dce refactor deployer call out
4cea586 fix tests add stub for gitcharm
9052016 refactor, add gitcharm flow
86913f3 When adding units to already deployed env transform to string
ad16b83 Removes bitdeli broken badge
c944dee Several updates
39238e4 Corrects configure wrong example.
53c8ddd Fix failing test.
8d2f537 All large files for fat charms.

Special thanks to the additional contributors for this release:

- Whit Morriss
- Felipe Reyes
- Nicolás Pace
- Brad Crittenden

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

Re: State of the Best Practices Guide

[Marco Ceppi]

Developers using Windows can't download and hack on charms. There's really
not need to create symlinks in hooks directories, you can achieve the same
affect by stubbing hooks which import your hooks.py file and invoke the
methods that are wrapped with the Hook decorator.

Again, best practice, not policy.

On Wed, Mar 4, 2015 at 11:44 AM Simon Davy bloodearn...@gmail.com wrote:

 On 2 March 2015 at 17:46, Marco Ceppi ma...@ondina.co wrote:
  # Charm Authors
 
  - Avoid symlinks in charm

 /me blinks

 I assume you don't mean symlinks in hooks/ dir?

 Anything documenting why this is a bad idea?

 --
 Simon

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

Re: New Docker goodies

[Marco Ceppi]

It seems Jorge omitted why this is useful. When doing charm reviews or
performing charm testing (while developing) you can use the docker
container to quickly spin up an isolated environment so the charm can
execute it's testing dependencies without dirtying the testers system.
We're also now using the charmbox in the Charm CI system so it provides a
consistent testing experience from our CI systems to your machine.

Marco

On Fri, Mar 27, 2015 at 12:04 PM Nate Finch nate.fi...@canonical.com
wrote:

 What does this do that just using the juju binary on your local system
 doesn't do?

 On Fri, Mar 27, 2015 at 11:49 AM, Jorge O. Castro jo...@ubuntu.com
 wrote:

 Hi everyone,

 First, if you haven't seen this yet, this is a docker container that
 let's you just try Juju, with the limitation that you can't do the
 local provider.

 - https://registry.hub.docker.com/u/whitmo/jujubox/
 - https://github.com/whitmo/jujubox

 And here's the new bits, Cory Johns has been working on making a juju
 docker container that is more useful for charm developers and testers
 (so it's a bit larger than the jujubox)

 - https://registry.hub.docker.com/u/johnsca/charmbox/
 - https://github.com/juju-solutions/charmbox

 Again the limitation is you can't use the local provider, however if
 you're testing on public clouds then you should see dramatic workflow
 speed vs. using the vagrant boxes.

 PRs and feedback all welcome!

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

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


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

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

Re: juju error line 203 environments.yam

[Marco Ceppi]

The MAAS oauth keys contain a ':' which is an illegal character in YAML.
You'll need to wrap it in quotation marks to resolve that.

On Tue, Mar 24, 2015 at 1:43 PM José Antonio Rey j...@ubuntu.com wrote:

 This should be because of a formatting error on your environments.yaml
 file. Can you check that the value in line 203 has the correct
 formatting and is the one intended to be there?

 On 03/24/2015 12:39 PM, Stephen Drotar wrote:
  Hi,
 
  I receive a error in line 203 of environments.yaml
 
 
:found character that cannot start token
 
  does this have todo with  the maas oauth
 
 
  Best,
 
  Steve
 

 --
 José Antonio Rey

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

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

Re: [Plugin] sync-watch: Edit locally, run in the cloud

[Marco Ceppi]

This is nothing but pure awesome in plugin form! Thanks for working on this

On Fri, Apr 24, 2015 at 8:34 AM Cory Johns cory.jo...@canonical.com wrote:

 Last week, while in Nuremberg, Ben and I were able to create a new
 plugin to enable a much better charm development workflow.

 Once the Juju Plugins bundle (https://github.com/juju/plugins) is
 installed, you can now run `juju sync-watch unit` to enable local
 editing of a remote charm.  This works using inotify to watch for
 changes in the local copy of the charm and automatically sync those
 changes up to the deployed unit.  If the unit is in an error state, it
 will also automatically retry the failed hook, so that you can do
 fast, seamless iteration on a charm.

 This plugin works with any provider and any editor.

 --
 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: Request to support to work with Juju

[Marco Ceppi]

Hello, are you using the local provider? If so it can take several minutes
to seed the initial download of the cloud image. You can find if the image
was downloaded by checking /var/cache/lxc/cloud-* where * is precise,
trusty, or the series you're trying to deploy. Images are downloaded only
when you first attempt to deploy and then cached in that directory. Once
cached it will attempt to build a LXC template (`sudo lxc-ls --fancy`
should produce output with something like juju-trusty-lxc-template) if
you don't see anything in the cache directory, or in the lxc-ls output, or
you do, or you're not using local provider, let us know.

Also, the version of juju you're using may also help us identify issues
you're having.

Thanks,
Marco Ceppi

On Thu, Apr 30, 2015 at 3:52 AM dinesh.senap...@wipro.com wrote:

  Hi,

 I have been working on Juju for last 2 weeks. There are some blockages
 while working on it like:

 1.In *juju bootstrap. *It is *not downloading the  disc image* itself.
 But when I check juju status, it is showing machine-0 (started state).

 2.And when I try to *deploy any service*, it adding the charm but the new
 instance is staying in *pending state* forever and it is not *creating
 the template*.



 Kindly help me figure out the way to solve the above problems.



 Thanks and Regards,

 Dinesh Kumar Senapaty,

 Wipro Technologies.
  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

[ANN] Juju SVG - a web service to visualize bundles

[Marco Ceppi]

Hello everyone,

I'm excited to announce a small project I've been working which uses the
jujusvg project from Juju to render bundles in to consumable SVG. The goal
was to produce an image one might find in the GUI without having to load or
deploy the GUI. Cases where you may want to embed a deployment in a blog or
webpage as a static image or visual a deployment in a tool built on top of
Juju.

Consuming the webservice is straight forward. You either send it a GET
request with the data you wish to display whether it's a bundle in the
store or a raw bundle file:

- http://svg.juju.solutions/?bundle=cs:bundle/openstack-telemetry-31
-
http://svg.juju.solutions/?bundle-file=http://bazaar.launchpad.net/~bigdata-dev/charms/trusty/apache-analytics-sql-hue/trunk/download/head:/bundles.yaml-20150420030716-vycsb0pcenhst8wt-1/bundles.yaml

or, in the event the bundle is published, you can POST the bundle contents
to the service. In all cases you'll either get an unpleasant error or, on
success, the bundle you requested.

A full set of instructions is available at http://svg.juju.solutions

The webservice is designed to be somewhat smart in how it handles requests.
Whenever possible it'll use data from the charm store API to avoid
performing extra work. There's not caching between requests, yet, but that
will likely be the next feature I attempt. I will also have an SSL
certificate added in the coming days to allow embedding and increase
transport security.

I'd appreciate any feedback, feature, or bug requests.

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

[ANN] Benchmarking workloads with Juju

[Marco Ceppi]

Hello Everyone,

We in the Juju Ecosystems team would like to announce a new tool for charm
authors and users alike! This is a topic discussed about a lot in the past
few office hours and UOS, benchmarking workloads with Juju.

Currently, anyone can benchmark services and workloads using Juju Actions
and any Juju version greater than or equal to 1.23. What this announcement
brings is a suite of tools to help standardize the effort around
benchmarking to make authoring and consuming benchmarks very easy. We’re
releasing this tool as “charm-benchmark” which is currently available
through pip and soon to be packaged in other formats.

charm-benchmark provides a set of commands that abstract the calls to
`action-set` to ensure all benchmarks are written in a compatible format.
Adam Israel has written a blog post which goes over charm-benchmark in more
details, including how to write your first benchmark action[0]! We have a
set of charms we’ve created that have examples of benchmarking: siege, pts,
mysql-benchmark, mongodb, rally, and a few others which are covered in
Adam's post.

We invite users and authors alike to help us fill in the blanks for
services and workloads that don’t have benchmarks actions already. This
announcement is to kick off discussion for people who are interested in
benchmarking their workloads and giving you the tools you need to get the
results you want.

Also a reminder that we’ll be covering benchmarking in the next Juju Office
hours[1] and we’d love to help anyone who wants to get started, you can
find me, (marcoceppi), Adam (aisrael), or Tim (tvansteenburgh) on #juju on
Freenode and on this list.

Thanks,
Marco Ceppi
on behalf the Juju Ecosystems Team

[0]:
http://www.adamisrael.com/blog/2015/06/23/announcing-benchmarking-with-juju/
[1]: http://ubuntuonair.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: charm-tools version in wily

[Marco Ceppi]

Hello!

Yes we plan to update the charm tools versions and several other packages
in the archive this cycle. I've kicked off an upload of charm-tools 1.5.1
to the PPA in the mean time.

Thanks,
Marco Ceppi

On Tue, Jun 2, 2015 at 2:40 AM Nobuto Murata nob...@nobuto-murata.org
wrote:

 Hi,

 I've found the latest charm-tools is not available on Ubuntu wily.
 I've noticed it by `charm create -t python mycharm` giving error:
 unrecognized arguments: -t. charms-tools version in Ubuntu wily
 archive is 1.0.0-0ubuntu2.

 It would be nice if the latest charm-tools is uploaded into
 ppa:juju/stable for wily and/or Ubuntu wily archive.

 Thanks,

 --
 Nobuto Murata / 村田信人

 --
 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: Openstack bootstrap error

[Marco Ceppi]

While I'm not 100% confident, I believe that the image-metadata and
agent-metadata URLs need to be a URL that is addressible from within the
OpenStack cloud as they're used by cloud-init when bootstrapping which may
explain why you're not completing the process.

Marco

On Thu, Jul 2, 2015 at 7:21 AM dinesh.senap...@wipro.com wrote:

 I have tried on manual provisioning and local provider and I was able to
 ssh to the machine.

 Below is my 'Environments.yaml' for openstack

 openstack:
 type: openstack
 auth-url: http://10.200.8.203:5000/v2.0
 auth-mode: userpass
 use-floating-ip: true
 use-default-secgroup: true
 admin-secret: 81a1e7429e6847c4941fda7591246594
 image-metadata-url: file:///home/controller/opt/stack/images
 agent-metadata-url: file:///home/controller/opt/stack/tools
 network: demo-net
 region: regionOne
 username: admin
 password: password
 tenant-name: admin



 -Original Message-
 From: Mark Shuttleworth [mailto:m...@ubuntu.com]
 Sent: Thursday, July 02, 2015 4:40 PM
 To: Dinesh Kumar Senapaty (WT01 - Global Media  Telecom);
 juju@lists.ubuntu.com
 Subject: Re: Openstack bootstrap error

 On 02/07/15 06:50, dinesh.senap...@wipro.com wrote:
  Hi,
  I have been trying to bootstrap juju for 'openstack' environment. The
 instance being created and floating ip is also associated and also I am
 able to ping that instance but later bootstrap fails when it is attempting
 to connect giving the error failed to bootstrap environment: waited for
 10m0s without being able to connect: ssh: connect to host  .Can anyone
 help me regarding this issue?

 Are you able to deploy trusty with MAAS and ssh to the machine?

 Are you otherwise able to bootstrap on public clouds?

 Mark
 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

The future of Charm Helpers

[Marco Ceppi]

methods and features of python charm-helpers. I'd like to continue this
tend and add a CLI hook for everything in charm-helpers, within reason. A
recent addition, by Cory Johns, enabled the internal key-value store in
charm-helpers to be accesible via CLI. While making things like the
config_get method available by CLI is silly, other key and core methods
that exist as code in Python only and aren't a 1:1 bridge to Juju commands
should also be made available. This will allow authors creating first
drafts of charms in bash to access these higher methods.

# Conclusion

I welcome discussion, dissent, and suggestions around these topics. They
are by no means set in stone but are the assumed plan at the moment.

TL;DR: I want to make charm-helpers very slim, versioned, packaged,
documented, and easily portable to other languages.

Thanks,
Marco Ceppi
Juju Developer Experience group

[0] http://pythonwheels.com/
[1] https://github.com/cloudbase/juju-powershell-modules
[2] https://crates.io/crates/juju
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Ecosystem-engineering] The future of Charm Helpers

[Marco Ceppi]

On Tue, Aug 11, 2015 at 10:00 AM Matt Bruzek matthew.bru...@canonical.com
wrote:

 Thanks for the write up Marco.

 I am particularly interested in growing the CLI aspect of charm-helpers to
 aid authors who still use bash charms.  Also cleaning up the docs so they
 make sense and is easier to understand what some methods do.

 The idea of contrib was so that we could try out a few methods and if it
 worked well and was useful we pull that into core.  Is there any other
 contrib features that would be pulled in? How would someone propose a new
 feature in this new model?


That was the idea for using contrib. Proposing new features into core
will be like most other projects, either opening an issue/bug on the
charm-helpers project to outline what you want added or submitting code as
a merge request for review.

For those who want the contrib lifestyle of developing helpers and using
them in charms but not submitting them yet, branching on launchpad or any
other VCS and having pip install from a VCS is a viable workflow[0] and one
I think we should promote.

Marco

[0] https://pip.pypa.io/en/latest/reference/pip_install.html#vcs-support



 Thanks,

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

 On Tue, Aug 11, 2015 at 8:42 AM, Marco Ceppi marco.ce...@canonical.com
 wrote:

 Hello everyone,

 There have been a lot of conversations had over the past few months about
 charm-helpers and how to proceed forward with the project. As a result of
 these conversations I'd like to surface the following items for discussion:

 # Trimming down charm-helpers

 The first item, and arguably the largest is a complete reorganization of
 the current charm-helpers code base. Originally, charm helpers was setup to
 allow a path for developers to place unstable code (contrib directory)
 where they could iterate without a guarantee of API stability. However,
 this quickly grew to include code that simply didn't make sense as a core
 feature of charm-helpers. This includes a large set of code for domain
 specific charm ecosystems (bigdata, openstack, storage) as well as quickly
 fixes to missing features in Juju (leader election).

 The amount of collaborative code in contrib is fantastic! However, it's
 making the release and distribution of charm-helpers more complicated. With
 an inability to keep up with documentation for methods contrib and the
 volatile nature of unstable API, I'd like to propose we completely
 remove the contrib directory and instead urge code maintainers in contrib
 to create their own libraries for the feature and code they wish to
 maintain going forward which simply depends on charm-helpers for the code
 in core.

 This will allow groups like bigdata, openstack charmers, storage, and
 others to maintain their own release and review process for helpers
 specific to their solutions, as well as their own means of delivery (be it
 charm-helpers-sync, pypi, debian, or another means). This will also GREATLY
 slim down the charm-helpers library to instead include one of two things:

 - API in Python for communicating with Juju
 - Simple collection of tools in Python to solve shared universal problems

 Which roughly translates to hookenv.py, host.py, and fetch tools. Once
 contrib is removed and relocated I'd like to also propose flattening the
 library namespaces from

 charmhelpers.core.hookenv - charmhelpers.hookenv
 charmhelpers.core.host - charmhelpers.host
 charmhelpers.core.files - charmhelpers.host
 charmhelpers.core.fstab - charmhelpers.host
 charmhelpers.core.sysctl - charmhelpers.host
 charmhelpers.core.kv - separate project?

 Everything else, outside of contrib would remain the same. While I think
 it's important to slim down charm-helpers I'm not convinced the above
 outlined rename/code merges are the right or best way forward. I welcome
 feedback and a discussion around this.

 # Packaging charm-helpers

 Currently, charm-helpers are available via either bazaar source or PyPI.
 With a more stable, slim, and maintainable code base we would like to
 package charm-helpers still on PyPI with semantic versioning, make a
 dist/wheel[0] available for embedding (instead of charm-helpers-sycn), and
 in Debian and have them available via a PPA but also potentially in the
 archive proper.

 The hardest challenge will be keeping the archive as up to date as
 possible with releases of charm-helpers. Since charms and Juju versions are
 decoupled from packages frozen in the archive, just having a version of
 charm-helpers in the archive for the version of Juju in that archive won't
 necessarily last the test of time. Someone deploying a charm now from a new
 version of Juju against trusty would get the 1.21 equivalent of
 charm-helpers which may not include the new leadership or extended status
 methods causing the charm to fail erroneously.

 Having a PPA can alleviate this, but PyPI and PPAs may interfere with
 firewalls and policies where Juju is being deployed. Opinions on how to
 help

Re: The future of Charm Helpers

[Marco Ceppi]

On Wed, Aug 12, 2015 at 7:17 AM Adam Collard adam.coll...@canonical.com
wrote:

 On Wed, 12 Aug 2015 at 12:12 Marco Ceppi marco.ce...@canonical.com
 wrote:

 Working with the Juju QA team to add a Jenkins job for test landing is a
 great idea, one we should certainly do now while we figure the rest of this
 out.


 FYI there's an already an outstanding request with Juju QA team to set up
 CI for charm-helpers.


We should be able to help speed that along, we have access to create new
jobs in our Charm Testing jenkins slave. We'll take a look next week on how
quickly we can get a simple merge request approval/testing job setup and
reporting results back to the MP


 --

 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: The future of Charm Helpers

[Marco Ceppi]

On Wed, Aug 12, 2015 at 6:11 AM Stuart Bishop stuart.bis...@canonical.com
wrote:

 On 11 August 2015 at 20:42, Marco Ceppi marco.ce...@canonical.com wrote:


  # Trimming down charm-helpers
 
  The first item, and arguably the largest is a complete reorganization of
 the
  current charm-helpers code base. Originally, charm helpers was setup to
  allow a path for developers to place unstable code (contrib directory)
 where
  they could iterate without a guarantee of API stability. However, this
  quickly grew to include code that simply didn't make sense as a core
  feature of charm-helpers. This includes a large set of code for domain
  specific charm ecosystems (bigdata, openstack, storage) as well as
 quickly
  fixes to missing features in Juju (leader election).
 
  The amount of collaborative code in contrib is fantastic! However, it's
  making the release and distribution of charm-helpers more complicated.
 With
  an inability to keep up with documentation for methods contrib and the
  volatile nature of unstable API, I'd like to propose we completely
  remove the contrib directory and instead urge code maintainers in
 contrib to
  create their own libraries for the feature and code they wish to maintain
  going forward which simply depends on charm-helpers for the code in core.
 
  This will allow groups like bigdata, openstack charmers, storage, and
 others
  to maintain their own release and review process for helpers specific to
  their solutions, as well as their own means of delivery (be it
  charm-helpers-sync, pypi, debian, or another means). This will also
 GREATLY
  slim down the charm-helpers library to instead include one of two things:
 
  - API in Python for communicating with Juju
  - Simple collection of tools in Python to solve shared universal problems
 
  Which roughly translates to hookenv.py, host.py, and fetch tools. Once
  contrib is removed and relocated I'd like to also propose flattening the
  library namespaces from
 
  charmhelpers.core.hookenv - charmhelpers.hookenv
  charmhelpers.core.host - charmhelpers.host
  charmhelpers.core.files - charmhelpers.host
  charmhelpers.core.fstab - charmhelpers.host
  charmhelpers.core.sysctl - charmhelpers.host
  charmhelpers.core.kv - separate project?
 
  Everything else, outside of contrib would remain the same. While I think
  it's important to slim down charm-helpers I'm not convinced the above
  outlined rename/code merges are the right or best way forward. I welcome
  feedback and a discussion around this.

 I really like the big tree, including contrib.

 I discover cool things in there, which I would not if the cool things
 were hidden away in another branch I know nothing about. More and more
 teams get created around the globe and communication between them
 grows less and less. A shared repository helps in a small way.


I can see how this helps for discoverability for those already pretty
intimate with the code base, but a lot of the key complaints we've gotten
around new authors getting started is there is just an overwhelming amount
of code. If contrib just became charmutils or some other big umbrella I'd
be better with that, though I still don't think it solves the problems of
versioning. If the BIg Data charmers want to publish a backwards
incompatible change how does that get broadcast from a contrib directory?
Most all of the modules in contrib have merit, I think having them placed
in a tree does a disservice to the code created. Most that I've come across
are actually pretty generic and could just be standalone python modules the
rest of the python community uses (ssl, for example).


 And your test harnesses are already setup for you. It is easy to add
 new cool stuff, and its tests. And those tests get run under both
 Python 2 and Python 3 with the same versions of dependencies and your
 cool stuff is much more likely to work with other peoples cool stuff.
 I know for a fact if things get spit out they will have less rigorous
 testing, and we will end up with tech debt Py2 only modules for
 example, or conflicting dependencies.


If we provide similar scaffolding as we have now for those projects I don't
see why they wouldn't continue this way, if people don't take pride in
their projects they either don't get used or get forked and made better


 But I don't see the large tree as a problem. Its not unwieldy. And you
 don't have to worry about anything dumped into contrib, except from
 the perspective of if it is worth migrating it to the core area and
 how much work it would be (documentation, ensuring consistency,
 maintainability etc.). I don't see the large tree as a problem because
 you next talk about packaging.


From my perspective charm helpers should be core juju components mapped to
that language, tools to assist with writing charms in that language
(decorators, etc), and modules to help charms adhere to the charm policy.
I'd let things like host.py continue because they're small convenience
features

[ANN] charm-tools 1.8.0

[Marco Ceppi]

Hello everyone!

I'm happy to announce another charm-tools release today, this is the 1.8.0
which succeeds 1.7.1 as the latest release of charm-tools. As always, you
can verify the version you are running by executing: `charm version`

# Changes

ca0f40c [Benjamin Saller] fix issue with multiple includes of layer or
interface
951da9c [Benjamin Saller] help tests pass again
3830317 [Benjamin Saller] enable simple metics collections to help
visualize charm ecosystem
1fbb059 [Matt Bruzek] Updating readme with github and removing old info.
4a6bdf7 [Matt Bruzek] Replacing "sould" with "should".
8a236cb [Benjamin Saller] segregate deps by namespace (layer/interface)
cd66b45 [Benjamin Saller] reworked pypi installer (again). This does more
complex path mapping but properly gets /bin/* scripts and such
8aea18e [Benjamin Saller] attempt to clean up deprecation warning, make
delete_path safer
6fbb036 [Benjamin Saller] finish rename
a30876a [Benjamin Saller] rename composer to build
566b1e9 [Cory Johns] Move LPGitFetcher upstream and add missing rename
(fixes #14)
2a99239 [Cory Johns] Handle empty metadata.yaml (fixes #15)
bf563b9 [Marco Ceppi] Remove py3 testing
4d48eab [Marco Ceppi] Remove need to download deps from bzr archive
343555d [Marco Ceppi] Add support for travis ci
024852e [Marco Ceppi] Ignore pyc files
67983c4 [Marco Ceppi] converted bzrignore to gitignore

In this release compose, generate, and refresh were renamed to 'build' and
composer.yaml was renamed to layer.yaml. While we will maintain backwards
compat until 2.0, using these outdated terminologies will lead to problems
in the future.

# Install
Charm Tools is available to users either via the juju/stable PPA, Homebrew,
or pip

## PPA

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

## Homebrew

brew install charm-tools

## PIP

pip install -U charm-tools

# Summary

We have completed our move to github, all issues and pull requests should
be made against https://github.com/juju/charm-tools going forward.

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

Re: Unit number is increasing in latest juju version.

[Marco Ceppi]

Regardless of the outcome of the bug, the proper syntax for accessing units
is as follows:

self.d.sentry["ibm-mobilefirst-server"][0]

This is because, our new testing environment and soon to be normal testing
procedure for all charms while we wait for multi-model environments
recycles the environment and also incurs this increase. Either way,
hard-coded unit values tend to be fragile in general. This will do a look
up and always return the first unit. The previous hard-coded examples in
documentation are being updated to reflect this, I didn't realize how many
bad examples I'd produced over the years :)

Marco

On Fri, Nov 13, 2015 at 10:55 AM Matthew Williams <
matthew.willi...@canonical.com> wrote:

> Hi Sunitha,
>
> The bug is closed, it was fixed and released in juju 1.25.
>
> There are some docs at the below link that summarise the behaviour:
>
> https://jujucharms.com/docs/1.25/reference-numbering
>
> If you'd like to have a talk about this I'd be very happy to. I'm mattyw
> on irc in #juju and #juju-dev (otherwise email is fine)
>
> Thanks
>
> Matty
>
>
>
> On Fri, Nov 13, 2015 at 3:49 PM, Sunitha Radharapu 
> wrote:
>
>> Hi Matt,
>>
>> I am a little bit confused here, bug description says it should be as
>> unique id. If it is a bug and you are going to fix in future juju releases
>> then we no need to change our amulet tests.
>>
>> If it is a new feature then we will change our upcoming charms
>> accordingly,
>>
>> Thanks,
>> Sunitha.
>>
>>
>>
>>
>> [image: Inactive hide details for Matthew Williams ---13-11-2015
>> 20:32:45---Hi Mark, Sunitha, My apologies, I should have included the]Matthew
>> Williams ---13-11-2015 20:32:45---Hi Mark, Sunitha, My apologies, I should
>> have included the explanation in the original email.
>>
>> From: Matthew Williams 
>> To: Mark Shuttleworth 
>> Cc: Sunitha Radharapu/India/IBM@IBMIN, Juju email list <
>> juju@lists.ubuntu.com>
>> Date: 13-11-2015 20:32
>> Subject: Re: Unit number is increasing in latest juju version.
>> --
>>
> Hi Mark, Sunitha,
>>
>> My apologies, I should have included the explanation in the original
>> email.
>>
>> This was a change to address a long standing bug:
>> *https://bugs.launchpad.net/juju-core/+bug/1174610*
>> 
>>
>> There's a discussion in the bug report, but the summary is that in most
>> cases it's desirable to have the unit id be unique across the life of an
>> environment. Otherwise you loose the identity of a unit across relations.
>>
>> We were already numbering the machines in the same way, so this change
>> also gives us consistency between machine and unit numbering systems.
>>
>> Thanks
>>
>> Matty
>>
>> On Fri, Nov 13, 2015 at 1:50 PM, Mark Shuttleworth <*m...@ubuntu.com*
>> > wrote:
>>
>>
>>Thanks Sunitha. Matty, deeper question is - was this an intended
>>change
>>in behaviour, and what's the rationale?
>>
>>Mark
>>
>>
>>
>> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Bootstrap] vSphere provider

[Marco Ceppi]

Sorry to hear you're having troubles. It sounds like cloud-init didn't
finish. Are you able to get a console onto the VM? If so could you get the
contents of /var/log/cloud-init*?

On Thu, Nov 5, 2015, 6:36 AM Cseh Dávid  wrote:

> Hi
>
>
>
> I tried to bootstrap juju on a vCenter 5.5 environment, but it failed when
> juju tries to connect to the newly created VM throught ssh. (public key
> error)
>
> The VM is reachable, but there is no key to connect with.
>
>
>
> What could be the problem?
>
>
>
> Thanks
>
> David
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How to make Juju High Availability work properly?

[Marco Ceppi]

Hi Leon,

Sorry to hear you're having issues, I haven't seen this problem before but
I'm curious what version of Juju you're using (`juju version`) I know there
was recent work to make ensure-availability more robust. As to how to solve
the issue, could you run `juju ssh 0` then once on the zero node run:

sudo apt-get install pastebinit
pastebinit /var/log/juju/machine-0.log

This will provide a URL with the pastebin of the machine-0 log which would
be helpful in diagnosing this issue further and potentially ways to resolve
this.

Thanks,
Marco Ceppi

On Fri, Oct 16, 2015 at 3:56 AM 曾建銘 <godl...@gmail.com> wrote:

> Hi All,
>
> I got some problems when I was testing Juju High Availability after
> deploying OpenStack on my physical servers.
>
> I used "juju ensure-availability" to generate 3 state servers. Juju
> became unnormal after the bootstrap node was shutdown.
>
> When the bootstrap node was gone, the whole juju tasks seemed not switched
> to another state server successfully. I found agent-states of all services
> became "lost", workload-state of all services become unknown or error.
>
> I used "juju debug-log" to check the juju working status, a lot of
> messages passed by, they looked like there were many communications between
> services and the state server.
>
> I tried to wait for a while, I found that agent-states of services became
> idle again. But they will become lost again later. Then I try to wait for
> more a long time(more than 1 hour), I found the agent-state of all services
> were change from lost to executing, then to idle, then to lost finally.
>
> No matter how long I waited, I always found the same result I mentioned
> above. Then I could use juju commands normally.
>
> Did anyone get the same problem? I will be really appreciated if someone
> can tell me how to solve this issue.
>
> Thanks in advanced.
>
> Sincerely yours,
> Leon
>
> --
> 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: local: nested lxc containers

[Marco Ceppi]

For the time being you can add these entries to the lxc container defaults,
which should be in `/etc/lxc/default.conf` and new containers launched will
have those updated values. Going forward, we're working on a LXD provider
for Juju - part of that work will enable nesting of containers by default.
The local provider has always been a "work around" for developers, with the
LXD machine container hypervisor you'll be able to emulate deployments like
you do on clouds (with LXC nested) on your laptop.

Marco

On Wed, Oct 14, 2015 at 7:36 PM Frederico Araujo  wrote:

> For now, I'm just editing the configuration of the lxc container from
> which juju clone new lxc instances, so that all new machines allow nested
> containers.
> It would be nice if we could override container configurations during
> deployment, though :)
>
> On Wed, Oct 14, 2015 at 6:13 PM, Frederico Araujo 
> wrote:
>
>> Hi,
>>
>> I wrote a charm for an application I developed which deploys some lxc
>> containers. I wanted to test it in my local environment (bootstrapped
>> with juju-quickstart), but I couldn't find a way to configure juju to
>> automatically create containers with specific settings---in my case,
>> allowing for nested lxc containers. I need to somehow change the
>> configuration fo the parent lxc container created by juju during deployment
>> of the charm to add these two lines:
>>
>> lxc.mount.auto = cgroup
>> lxc.aa_profile = lxc-container-default-with-nesting
>>
>> After manually adding these lines to the parent container created by
>> juju, the internal containers work. The problem of adding them manually is
>> that juju won't be able to start the internal containers automatically
>> during juju deploy.
>>
>> Any ideas?
>>
>> Thanks,
>> Fred
>>
>
> --
> 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] ntp, kibana, mongodb, postgresql

[Marco Ceppi]

Had the pleasure of reviewing these merge requests for charms today. All
have been merged!

*
https://code.launchpad.net/~brad-marshall/charms/trusty/ntp/remove-ntp-status-check/+merge/261927
*
https://code.launchpad.net/~yellow/charms/trusty/kibana/trunk/+merge/262373
*
https://code.launchpad.net/~mattyw/charms/trusty/mongodb/mongodb-deployu/+merge/262666
*
https://code.launchpad.net/~stub/charms/trusty/postgresql/standby-service/+merge/262811

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

Re: Query - Charm not showing up in the review queue

[Marco Ceppi]

Hello!

Thank you for taking the time to work on this charm and submit it for
review. This process is due to be streamlined in the coming weeks, but at
this time you still must submit a bug against the charms distro,
currently you've created the bug against ibmcharms project. I've taken the
liberty to move the bug under the charms distribution and it should be in
the review queue momentarily.

In the weeks to come we'll be proposing a new, more streamlined review
process to this list, so your feedback (and everyone elses) will be much
appreciated then.

Thanks,
Marco Ceppi

On Thu, Jul 9, 2015 at 7:41 AM Shilpa Kaul shilk...@in.ibm.com wrote:

 Hi Team,

 I have pushed my charm for IBM WebSphere® Extreme Scale product to the
 charm store 2 days back but it is not showing up in the review queue(
 http://review.juju.solutions/) yet.
 I have followed the steps in charm store submission policy (
 https://jujucharms.com/docs/stable/authors-charm-store#submitting).

 I have pushed my code to trunk branch, created a bug, attached the branch
 to the bug report, and subscribed to the* charmers* team
 Here are the links:
 https://code.launchpad.net/~ibmcharmers/charms/trusty/ibmwxs/trunk
 https://bugs.launchpad.net/ibmcharms/+bug/1470017

 Can you please help us figure out why the charm is not showing up in the
 review queue yet.


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

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

Re: [ANN] Charm Tools 1.6.1

[Marco Ceppi]

Hey Adam,

Thanks for the report. This was a known limitation at the moment as those
dependencies require py3.1 which isn't in precise. The issues I alluded to
earlier were for those users running trusty or higher. I don't realize
there would be many people still on precise and figured I had a few more
days to figure out this snafu.

I'm on the case now and hope to have those three packages sorted in a few
hours.

Thanks,
Marco Ceppi

On Fri, Sep 4, 2015 at 5:38 AM Adam Collard <adam.coll...@canonical.com>
wrote:

> Hi Marco,
>
> On Wed, 2 Sep 2015 at 22:01 Marco Ceppi <marco.ce...@canonical.com> wrote:
>
>> The charm-tools 1.6.0 and 1.6.1 packages created a unique challenge in
>> packaging. The result was a potentially broken apt/dpkg state on a few
>> users machines. If you've attempted and upgrade in the past 24 hours you
>> may have experienced some oddness with jujubundlelib, charm-tools, and
>> other packages. Before reporting issues please make sure you've run `sudo
>> apt-get update` and a `sudo apt-get install -f`.
>>
>> Going forward we're producing a new set of QA tests for our tooling to
>> prevent having broken packages uploaded to the archive.
>>
>
> Looks like they're still broken for Precise.
>
> charm-tools 0.6.1 has a declared dependency on python-yaml (>= 3.11), but
> http://packages.ubuntu.com/search?keywords=python-yaml latest for Precise
> is 3.10.x
>
> This leads to a broken package -
>
>
> Some packages could not be installed. This may mean that you have
> requested an impossible situation or if you are using the unstable
> distribution that some required packages have not yet been created or been
> moved out of Incoming.
>
> The following information may help to resolve the situation:
>
> The following packages have unmet dependencies:
>  charm-tools : Depends: python-yaml (>= 3.11) but 3.10-2ubuntu0.1 is to be
> installed
>  Depends: python-blessings but it is not installable
>  Depends: python-ruamel.yaml but it is not installable
> E: Unable to correct problems, you have held broken packages.
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] Charm Tools 1.6.1

[Marco Ceppi]

Hello Juju!

There is a new feature release of charm-tools which fixes issues and adds
new functionality. This version superceeds 1.5.1 and 1.6.0 To verify which
version of charm-tools you are using you can execute the following command:

charm version

# Install

Charm Tools is available for users via the stable juju ppa or from PyPi via
pip:

## Aptitude

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

## Pip

pip install charm-tools

# Upgrade

Existing installs of charm-tools can be upgraded using the following methods

## Aptitude

sudo apt-get update
sudo apt-get install

## Pip

pip install -U charm-tools

# Changes

- [lazypower] Moved the cookbook out path to $CHARM_DIR
- [evarlast] change juju.ubuntu.com links to jujucharms.com
- [tvansteenburgh] Update bundle proof for v4
- [tvansteenburgh] Fixed some charm-create tests that were failing due to
new files in charm-helpers
- [johnsca] Add support for v4 format bundles in proof
- [marcoceppi] Make categories a WARN to prevent promulgation of charms
- [lazypower] Make readme linting more helpful
- [bcsaller] Add charm composer and port tests to tox.
- [bcsaller] Vendor in the fetchers module from bundletester.

# Compser

With this new release of charm-tools a new set of subcommands have been
added. This is the first iteration of a new feature called "composer" which
makes sharing and reusing common components in charms effortless. This new
feature allows authors to create charm based on varying layers of existing
code, the tool will "compile" a charm from the layers created and produce a
single charm that can be uploaded to the store. The advantage this has over
just copying bits around is that as layers evolve and update composer can
notify users of these updates and rebuild your charm from the newer bases.

It's a very exciting way to manufacture charms and helps break down charms
to further composable elements. In essence layers are to charms as quarks
are to protons.

You can find out more about composer, layers, and building charms on this
docs page: https://jujucharms.com/docs/devel/authors-charm-composing

# Note

The charm-tools 1.6.0 and 1.6.1 packages created a unique challenge in
packaging. The result was a potentially broken apt/dpkg state on a few
users machines. If you've attempted and upgrade in the past 24 hours you
may have experienced some oddness with jujubundlelib, charm-tools, and
other packages. Before reporting issues please make sure you've run `sudo
apt-get update` and a `sudo apt-get install -f`.

Going forward we're producing a new set of QA tests for our tooling to
prevent having broken packages uploaded to the archive.

# Summary

This is the last planned release in the 1.6 series. The 1.7 series and
branch are now open for development. You can always contact us for
additional help via #juju on irc.freenode.net, http://askubuntu.com with
questions tagged #juju, or via this very mailing list juju@lists.ubuntu.com

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

[ANN] Amulet 1.11.1 released

[Marco Ceppi]

Hello,

I'm happy to announce the Amulet 1.11.1 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 patch release

- Support for v4 bundle format
- Changed sentry commands to use ssh instead of run
- Remove cli module and entry point

See the full log below for all changes

# Release notes

These are the commits included in this release:

c545b09 Use services instead of series, and support series being left out
of bundle
5a68375 Support v4 format bundles
b6da1c3 Changed sentry commands to use ssh instead of run to avoid blocking
with hooks
a11573e Don't configure logging in the library code
e4e13c4 Remove cli module and entry point

Special thanks to all contributors for this release:

- Tim Van Steenburgh
- Cory Johns
- Skyler Berg

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

Review Queue:

[Marco Ceppi]

Did some time in the review queue today, here are the results

New:
- Bip: Charm has made several successful reviews, promulgated
  https://bugs.launchpad.net/charms/+bug/1401774
- IBM WebSphere Extreme Scale: I'm not sure how to get the software for
this. I'm working within the charmers team to get this figured out

Updates:
- ubuntu-repository-cache: small fix for error handling, merged

https://code.launchpad.net/~rcj/charms/trusty/ubuntu-repository-cache/lp1500442/+merge/272662
- mongodb: fix for py3 compat in wily, merged

https://code.launchpad.net/~james-page/charms/trusty/mongodb/pymongo-3.x/+merge/270525
- apache2: Adds support for nagios_servicegroups, merged

https://code.launchpad.net/~verterok/charms/trusty/apache2/nagios_servicegroups/+merge/269259

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

[ANN] Charm Tools 1.7.1 Released!

[Marco Ceppi]

Hello everyone!

I'm happy to announce another charm-tools release today, this one is 1.7.1
which succeeds 1.6.1 and 1.7.0 as the latest release of charm-tools. As
always, you can verify the version you are running by executing: `charm
version`

# Changes

[bcsaller] cleaner installer, replace existing files more cleanly
[bcsaller] Command aliases and fixing tmpdir/pipe colors
[bcsaller] turn down logging, fix path in tactics
[marcoceppi] look for peers in metadata.yaml
[marcoceppi] Remove colon from namespace URL

In this release compose is renamed to 'generate' and 'refresh'. This
version also fixes build issues for precise users.

# Install
Charm Tools is available to users either via the juju/stable PPA, Homebrew,
or pip

## PPA

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

## Homebrew

brew install charm-tools

## PIP

pip install -U charm-tools

# Summary

This is the last planned 1.7 series release barring any bug fixes. Going
forward we're looking to move charm-tools source hosting to
github.com/juju/charm-tools to better be aligned where the rest of the
ecosystems tools are.

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

Re: juju charm proof error

[Marco Ceppi]

Hello Fred!

charm proof provides three levels of output:

E: Error, this charm will not deploy in it's current state
W: Warning, this charm violates the "recommended" charm store policy
I: Information, things to consider, but no inherently wrong

Based on the output, you seem to be missing a copyright file and README.md
file which are required for uploading to the charm store but not
necessarily for deploying the charm. If you add these files the warnings
should disappear but they're safe to ignore if you're just trying to get
started in writing you charm. This will only be a problem when going
through the charm review process to have it listed as a recommended charm
in the charm store.

Thanks,
Marco Ceppi

On Fri, Oct 2, 2015 at 12:23 PM Frederico Araujo <arau...@gmail.com> wrote:

> Hi,
>
> I'm trying to create my first charm without success. I used 'juju charm
> create firstcharm', and then cd into firstcharm, edit the metadata and
> hooks to have a minimal charm that doesn't do anything. The problem arises
> when checking the charm with 'juju charm proof', which gives me the
> following error:
>
> W: no copyright file
> W: no README file
> ERROR subprocess encountered error code 100
>
> Any ideas?
>
> Thanks a lot!
> Fred
> --
> 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 charm proof error

[Marco Ceppi]

Hello Fred!

charm proof provides three levels of output:

E: Error, this charm will not deploy in it's current state
W: Warning, this charm violates the "recommended" charm store policy
I: Information, things to consider, but no inherently wrong

Based on the output, you seem to be missing a copyright file and README.md
file which are required for uploading to the charm store but not
necessarily for deploying the charm. If you add these files the warnings
should disappear but they're safe to ignore if you're just trying to get
started in writing you charm. This will only be a problem when going
through the charm review process to have it listed as a recommended charm
in the charm store.

Thanks,
Marco Ceppi

On Fri, Oct 2, 2015 at 12:22 PM Frederico Araujo <arau...@gmail.com> wrote:

> Hi,
>
> I'm trying to create my first charm without success. I used 'juju charm
> create firstcharm', and then cd into firstcharm, edit the metadata and
> hooks to have a minimal charm that doesn't do anything. The problem arises
> when checking the charm with 'juju charm proof', which gives me the
> following error:
>
> W: no copyright file
> W: no README file
> ERROR subprocess encountered error code 100
>
> Any ideas?
>
> Thanks a lot!
> Fred
> --
> 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: Which JUJU_DEV_FEATURE_FLAG were used?

[Marco Ceppi]

This is an interesting one, I hacked together a one-liner from both Nate
and your replies

juju ssh 0 "ps -ae -o command= | grep [j]ujud | grep JUJU_DEV_FEATURE_FLAGS
| awk -f'\"' '{ print $2 }'"

and added[0] it to the juju plugins repo as `juju flags`:
https://github.com/juju/plugins

$ juju flags
storage jes

Marco

[0]: https://github.com/juju/plugins/pull/61


On Tue, Sep 22, 2015 at 3:59 PM Andreas Hasenack 
wrote:

> On Tue, Sep 22, 2015 at 4:57 PM, Tim Penhey 
> wrote:
>
>> On 23/09/15 05:18, Andreas Hasenack wrote:
>> > Hi,
>> >
>> > given an existing juju environment, is there a way to tell which
>> > JUJU_DEV_FEATURE_FLAGs were used to bootstrap it?
>> >
>> > I'm using 1.24.6
>>
>> The second line of logging in every agent lists the feature flags that
>> the agent is using.
>>
>> As the agent starts it logs first the version of juju, then the feature
>> flags.
>>
>>
>
> Got it there too, thanks:
> machine-0: 2015-09-22 19:36:19 INFO juju.cmd.jujud machine.go:419 machine
> agent machine-0 start (1.24.5-trusty-amd64 [gc])
> machine-0: 2015-09-22 19:36:19 WARNING juju.cmd.jujud machine.go:421
> developer feature flags enabled: "address-allocation"
>
> --
> 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

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

[Marco Ceppi]

Here are my slides from the first session on Thursday morning. It's a meant
to be an overview of the Juju and Charm architecture. I'm curious on
feedback as it's the first time I've run this style presentation.

https://docs.google.com/presentation/d/1_rTFq-aS_ESK2wabnCviZtDZ-nYOPI23MeLp-GLDyJY/edit

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

Re: Juju devel 1.26-alpha2 is available for testing

[Marco Ceppi]

Okay, but I've added the LXD daily/stable PPA which installed `go version
go1.5.1 linux/amd64`. My question is, are the LXD features locked to an
Ubuntu release or is it dependent on checking platform ability at run time?
My point being, I have a trusty machine which has a more recent version of
golang and the latest stable LXD software installed. If Juju won't work
simply because it's trusty then I need to file a bug before 1.26.0 lands.

Marco

On Fri, Nov 27, 2015 at 11:04 AM Aaron Bentley <aaron.bent...@canonical.com>
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2015-11-27 11:00 AM, Marco Ceppi wrote:
> > - Running Wily (LXD is installed by default)
> >
> >
> > For the LXD provider, I have the latest LXD installed on trusty,
> > will that work or is it hard-coded to wily+ ?
>
> It will not work.  Only platforms with Go 1.3 will work, because the
> LXD provider only builds with Go 1.3+.  See "Upgrading minimum Go
> version" in juju-dev for more discussion.
>
> Aaron
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWWH75AAoJEK84cMOcf+9hWDwH/iuVczXD8UpRv1KZeXLK7AQC
> vaNY5jaUSwS3+lKGGimEdHHNwrMjH5FxEnMGqvQctRNbIgudCorL7nxEhM1J++3U
> vTus0MAe/le82t5PIos/wKHl4mNhVpxHA1x/mKmSW4CIiiA7us1v8ZOCxg/DKQen
> a+r6+/F8sne/2Q92dyIj02Vy/RN0HTKBz/3Royu0HZgdRbsJVpHaNObglvAbCbdc
> gErAMNPkzChiVceYAciqHUrmDA6FzeOB6Ep7J0kboIxJLiFf0oed0+z0Nt9qeMBE
> a+dJx+767D2B8iavpqr9thnIeoSqvH57Qzbaxev6sxnW2cQCHTN5PEY9hkODFy0=
> =dYa5
> -END PGP SIGNATURE-
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju devel 1.26-alpha2 is available for testing

[Marco Ceppi]

On Fri, Nov 27, 2015 at 9:37 AM Aaron Bentley 
wrote:

> # juju-core 1.26-alpha2
>

This is probably the most anticipated release of the year. Looking forward
to trying out all the new features!


> ### LXD Provider
>
> The new LXD provider is the best way to use Juju locally.
>
> The state-server is no longer your host machine; it is now a LXC
> container. This keeps your host machine clean and allows you to utilize
> your local environment more like a traditional Juju environment. Because
> of this, you can test things like Juju high-availability without needing
> to utilize a cloud provider.
>
> The previous local provider remains functional for backwards
> compatibility.
>
>  Requirements
>
> - Running Wily (LXD is installed by default)
>
>
For the LXD provider, I have the latest LXD installed on trusty, will that
work or is it hard-coded to wily+ ?


> - Import the LXD cloud-images that you intend to deploy and register
>   an alias:
>
>   lxd-images import ubuntu trusty --alias ubuntu-trusty
>   lxd-images import ubuntu wily --alias ubuntu-wily
>
>   or register an alias for your existing cloud-images
>
>   lxc image alias create ubuntu-trusty 
>   lxc image alias create ubuntu-wily 
>
> - For alpha2, you must specify the "--upload-tools" flag when
>   bootstrapping the environment that will use trusty cloud-images.
>   This is because most of Juju's charms are for Trusty, and the
>   agent-tools for Trusty don't yet have LXD support compiled in.
>
> juju bootstrap --upload-tools
>
> "--upload-tools" is not required for deploying a wily state-server and
> wily services.
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [ANN] charm-tools 1.9.3

[Marco Ceppi]

On Thu, Nov 26, 2015 at 3:05 AM Simon Davy <bloodearn...@gmail.com> wrote:

> On Thursday, 26 November 2015, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
> > On Wed, Nov 25, 2015 at 4:08 PM Simon Davy <bloodearn...@gmail.com>
> wrote:
> >>
> >> On 25 November 2015 at 16:02, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
> >> > ## Wheel House for layer dependencies
> >> >
> >> > Going forward we recommend all dependencies for layers and charms be
> >> > packaged in a wheelhouse.txt file. This perform the installation of
> pypi
> >> > packages on the unit instead of first on the local machine meaning
> Python
> >> > libraries that require architecture specific builds will do it on the
> units
> >> > architecture.
> >>
> >> If I'm understanding the above correctly, this approach is a blocker
> for us.
> >>
> >> We would not want to install direct from pypi on a production service
> >>
> >>  1) pypi packages are not signed (or when they are, pip doesn't verify
> >> the signature)
> >>  2) pypi is an external dependency and thus unreliable (although not
> >> as bad these days)
> >>  3) old versions can disappear from pypi at an authors whim.
> >>  4) installing c packages involves installing a c toolchain on your
> prod machine
> >>
> >> Additionally, our policy (Canonical's, that is), does not allow access
> >> to the internet on production machines, for very good reasons. This is
> >> the default policy in many (probably most) production environments.
> >>
> >> Any layer or charm that consumes a layer that uses this new approach
> >> for dependencies would thus be unusable to us :(
> >>
> >> It also harms repeatability, and I would not want to use it even if
> >> our access policy allowed access to pypi.
> >>
> >> For python charm dependencies, we use system python packages as much
> >> as possible, or if we need any wheels, we ship that wheel in the
> >> charm, and pip install it directly from the there. No external
> >> network, completely repeatable.
> >
> > So, allow me to clarify. If you review the pastebin outputs from the
> original announcement email, what this shift does is previously `charm
> build` would create and embed installed dependencies into the charm under
> lib/ much like charm-helper-sync did for instead for any arbitrary Pypi
> dependency. Issues there are for PyYAML it will build a yaml.so file which
> would be built based on the architecture of your machine and not the cloud.
>
> Right. This was the bit which confused me, I think.
>
> Can we not just use python-yaml, as its installed by default on cloud
> images anyway?
>
> We use virtualenv with --system-site-packages, and use system packages for
> python libs with c packages where possible, leaving wheels for things which
> aren't packaged or we want newer versions of.
>
>
Again, this is for hook dependencies, not exactly for dependencies of the
workload. The charm could apt intall python-yaml, but using
--system-site-packages when building is something I'd discourage since not
everyone has the same apt pacakges installed. Unless that user is building
on a fresh cloud-image there's a chance they won't catch some packages that
don't get declared.

We'd be interested in making this a better story. The wheelhousing for
dependencies not yet available in the archive instead of embedding them in
the charm was a first step but certainly not the last. I'm not sure how
this would work when we generate a wheelhouse since the wheelhouse
generation grabs dependencies of the install. That's why PyYAML is showing
up in the generated charm artifact. We're not explicitly saying "included
PyYAML" we're simply saying we need charmhelpers and charms.reactive from
PyPI as a minimum dependency for all charm hooks built with charm build to
work. Suggestions around this are welcome.

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

Re: [Review Queue] zulu8, mysql, bird, calico, apache2, postgresql, and ethercalc

[Marco Ceppi]

On Thu, Dec 3, 2015 at 6:21 PM Cory Johns  wrote:

> Greetings!
>
> The big data team, including myself, Kevin, Andrew, and Konstantinos, hit
> the Review Queue today:
>
>
>-
>
>zulu8
>-
>
>   https://bugs.launchpad.net/charms/+bug/1519858
>   -
>
>   Refactor to use java interface
>   -
>
>  https://github.com/juju-solutions/interface-java
>  -
>
>   Discovered issue when charm-building on one architecture and
>   deploying to another:
>   -
>
>  https://github.com/juju/charm-tools/issues/58
>  -
>
>   This charm could not be successfully deployed, but we suggested
>   README and reactive changes to fix this.
>   -
>
>   We also ran into a source control issue that may affect other
>   layered-charm authors. The *source* for a charm can be committed 
> anywhere
>   (launchpad, github, etc), but it must not interfere with where the charm
>   store will look for deployable charms:
>   -
>
>  lp:~/charms///trunk
>
>
This is one of the first charms submitted to the review queue which is in
reactive. This is amazing, but it's caught us a bit off guard. Yes, the
generated charm needs to be in this branch format. However, `charm upload`
has entered private beta, which will streamline this experience soon. Just
wanted to make everyone aware of that, esp those making charms with
Reactive.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

[ANN] charm-tools 1.10.0

[Marco Ceppi]

Hello everyone!

I'm happy to announce another charm-tools release today, this is the 1.10.0
which succeeds 1.9.3 as the latest release of charm-tools. If you've
managed to install 1.9.3 please be sure to upgrade. As always, you can
verify the version you are running by executing: `charm version`

# Changes

3b05f0c [Marco Ceppi] version bump
efb50fd [Cory Johns] Fixed tests
48ba928 [Cory Johns] Use Python 3 for layered charms
f2d5c5c [Cory Johns] Fixed hook name for storage and added test coverage
44e6c8c [Cory Johns] Resolve #66: Add reactive hooks for storage
238826d [Cory Johns] Add dist.yaml and resources.yaml as merged YAML files
912b903 [Cory Johns] Fix #49: Missing layer.yaml causes stack trace
8736471 [Cory Johns] Fix #58: Use "pip install --download" instead of "pip
wheel" because wheels are inherently binary
f8d9d4d [Cory Johns] Fix #56: Catch and report missing layers and interfaces
6423d66 [Kevin W Monroe] correct doc URL in generated hooks
30db73c [Cory Johns] Fixed issues with relative paths in charm build

# Highlights

This fix includes a mix of new feature and bug fixes. Here are a few
highlights.

## Storage hooks in reactive

As of this release, once storage is defined in the metadata.yaml for a
charm, Reactive hook stubs will be created. Charms can now use reactive
@hook to respond to storage events.

## Major fix to wheelhousing

1.9.3 added support for wheelhouses. However, due to the nature of
wheelhouses they were still binary builds. This breaks for charms built on
one architecture and deployed on another. 1.10.0 fixes this by building
"source only" wheels.

## Python3 for hooks

By default, all hooks and dependencies are built with Python3. This is in
anticipation of the Xenial switch to only having Python3 installed on the
cloud images by default.

# Install

Charm Tools is available to users either via the juju/stable PPA, Homebrew,
or pip

## PPA

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

## Homebrew

brew install charm-tools

## PIP

pip install -U charm-tools

As with Juju, charm-tools is gearing up for a 2.0 release. In this release
a few commands will be changing. Our goal is to have a 2.0 of charm-tools
ready in February in order to make sure it lands in Xenial. A follow up
email about this switch and what it means will be sent soon.

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

charm-tools 1.10.1

[Marco Ceppi]

Hello everyone!

I'm happy to announce another charm-tools release today, this is the 1.10.1
which succeeds 1.10.0 as the latest release of charm-tools. If you've
managed to install 1.10.0 please be sure to upgrade. As always, you can
verify the version you are running by executing: `charm version`

# Changes

a5d3cf6 [Marco Ceppi] version bump
e192b56 [Marco Ceppi] add /home/marco to whitelist fixes #47
742f669 [Cory Johns] Fix #69: newline before shebang in generated hooks

# Highlights

This addresses two bugs, one which is critical to charm creation.

# Install

Charm Tools is available to users either via the juju/stable PPA, Homebrew,
or pip

## PPA

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

## Homebrew

brew install charm-tools

## PIP

pip install -U charm-tools

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

Re: additional catering towards the application developer

[Marco Ceppi]

You can actually

juju action fetch --wait=0 

which will wait indefinitely for the result (ie, blocking) which would
simplify the code you provided. I agree there could be some improvements to
the action cli and will be making these bugs on the project as features
requests!

On Fri, Dec 11, 2015 at 12:03 AM Matthew Dirba 
wrote:

> Merlin,
>
> Adding a wrapper around juju action may have been the first juju
> related code that I wrote.
>
> function jujuaction {
> time=$1
> shift
> echo juju action do $@
> tmp=`juju action do "$@" |cut -f2 -d:`
> printf "${tmp} "
> while true; do
> sleep $time
> juju action status $tmp |grep -E "status: (pending|running)"
> >/dev/null || break
> printf "."
> done
> echo ""
> juju action fetch $tmp
> }
>
>
>   Looking at the help for juju I would ask/prefer that waiting for an
> action or parsing a result would be done with new commands sent to juju
> action.
>
> usage: juju action [options]  ...
> purpose: execute, manage, monitor, and retrieve results of actions
>
> options:
> --description  (= false)
>
> -h, --help  (= false)
> show help on a command or other topic
>
> "juju action" executes and manages actions on units; it queues up new
> actions,
> monitors the status of running actions, and retrieves the results of
> completed
> actions.
>
> commands:
> defined - show actions defined for a service
> do  - queue an action for execution
> fetch   - show results of an action by ID
> help- show help on a command or other topic
> status  - show results of all actions filtered by optional ID prefix
> wait - run an action and return all of the results
> parse - run an action and return the results matching a result string or
> dict
>
> Example Usage:
> juju action wait  
> juju action parse   result=Œavg.latency'
>
>
>
>
>
>
>
> Regards,
> Matt Dirba
> 512.779.4696
>
>
>
>
>
> >
> >Message: 6
> >Date: Wed, 9 Dec 2015 17:13:09 -0500
> >From: Adam Stokes 
> >To: Merlijn Sebrechts 
> >Cc: juju 
> >Subject: Re: additional catering towards the application developer
> >Message-ID:
> 

[ANN] charm-tools 1.11.0

[Marco Ceppi]

Hello everyone,

Following what has quickly become a 2 week release cadence as we prepare
for charm-tools 2.0, I'm happy to announce yet another release! Charm Tools
1.11.0 succeeds 1.10.0 and 1.10.1 as the latest release of charm-tools. If
you've managed to install 1.10.0 or 1.10.1 please be sure to upgrade. As
always you can verify the version you are running by executing: `charm
version`

# Changes

8b23dcd [Marco Ceppi] version bump
2dba307 [Marco Ceppi] Match source dependency as found in Xenial
e6890e0 [Cory Johns] Resolve #65: Add support for layer options in
layer.yaml
0b06f42 [Cory Johns] Refactor common code out of InterfaceBind and
StorageBind
892578f [Cory Johns] Revert unnecessary move of BuildError
15ea634 [Cory Johns] Removed superfluous HOOK_TEMPLATE_FILES and fix doc
copypasta error
8ce76ee [Cory Johns] Resolve #74: Use hook template from layers instead of
embedding in charm-tools

# Highlights

This fix includes a mix of new feature and bug fixes. Here are a few
highlights.

## Base layers determine hook templates

This is an advantage which paves the way for hook templates to be in
additional languages, such as powershell, and makes it easier to address
and plug future hooks into the build process

## Support for layer options in layer.yaml

This is a great new feature that helps steamline the charm build process.
Currently, several layers attempt to handle distribution data, they do this
by saying "fill out this yaml file" and the yaml file is usually named
after the layer, IE nginx.yaml, apache.yaml, django.yaml this makes it
harder for users to find options and provides no build time inspection.

With 1.11.0 layer authors can declare what their layer `defines` and an
`options` key in their layer.yaml. These "defines" are a jsonschema of the
"options" each layer accepts. Other layers can set values for these
"options" in their layer.yaml files. At build time, charm-tools will
validate that the options provided matches the defines schema to avoid
errors at deploy time. Furthermore the build process automatically
namespaces these options to avoid collisions between layers.

For more information about this feature, please see
https://github.com/juju/charm-tools/issues/65. I will follow up to this
post with an actual example of this implementation.

# Install

Charm Tools is available to users either via the juju/stable PPA, Homebrew,
or pip

## PPA

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

* There is a delay with precise version as some deps, mainly jsonschema,
are not available yet for this platform

## Homebrew

brew install charm-tools

* Will be available once https://github.com/Homebrew/homebrew/pull/47095 is
merged

## PIP

pip install -U charm-tools

Given our rapid release pace, we will be adding a new feature to
charm-tools which will provide a warning when charm-tools running locally
is out of date. This should help prompt swift upgrades as bugs are fixed
and new features land in our continued march to charm-tools 2.0!

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

Re: Charms, layers, and Launchpad

[Marco Ceppi]

Not sure if it will work completely offline, but you'll probably want to
pull all the layers/interfaces you want into INTERFACE_PATH and LAYER_PATH.
If I recall correctly, those are searched first for matches before the
index. The pip stuff is a bit harder, but it seems reasonable that we could
evaluate whats in the output path before attempting to do more fetches.
I'll open an issue to track what might be needed for limited to no
networking.

On Thu, Dec 17, 2015 at 6:33 PM Andrew Wilkins 
wrote:

> On Fri, Dec 18, 2015 at 9:27 AM Cory Johns 
> wrote:
>
>> Andrew,
>>
>> It's mentioned at the start of
>> https://jujucharms.com/docs/stable/authors-charm-building and there is a
>> PR (https://github.com/juju/docs/pull/746) to rework the existing
>> authors doc into a developer guide focused on creating charms with layers
>> that will bring a lot of this information together that is currently in
>> various locations.  Reviews on that are welcome.
>>
>
> Thanks, not sure how I missed that.
>
> As for building reactive charms offline, I'm not sure I understand the
>> question.  Layer and interface deps are cached under $JUJU_REPOSITORY/deps
>> and after the first build the wheelhouse will be in the charm output dir
>> and we could potentially prefer them over hitting the index again, but the
>> first build as well as any new deps, layer, interface, or wheelhouse, will
>> inherently require network access.
>>
>
> So I wanted to build charms while on a plane without Internet access.
> Maybe I was just doing something wrong, but it wanted network access
> despite having fetched/built the dependencies once before.
>
> Obviously we'll need to hit the network on the first build, and that's
> totally fine. If pip could be optionally instructed to reuse the existing
> wheelhouses, that would be helpful. I'd build the charms once before losing
> network, and then continue iterating with the cached dependencies.
>
> Cheers,
> Andrew
>
>
>> On Thu, Dec 17, 2015 at 6:09 PM, Andrew Wilkins <
>> andrew.wilk...@canonical.com> wrote:
>>
>>> On Fri, Dec 18, 2015 at 8:58 AM Cory Johns 
>>> wrote:
>>>
 Greetings, all.

 I wanted to suggest a convention for managing layered charms with
 Launchpad.

 Until the publish workflow is ready, the "built charm" (i.e., output
 from `charm build`) must be checked in to Launchpad in a repo such as:

 lp:~user/charms/trusty/foo/trunk

 The base path and branch are required to be charms/ and /trunk,
 respectively, for the charm to be ingested into the store.

 Launchpad isn't really set up to deal with charm layers, but I think we
 could settle on a convention of using the branch /layer to denote the
 source charm layer for the corresponding /trunk built charm.  The source
 layer (under /layer) is what we would like to have submitted to the Review
 Queue, and the /trunk branch could be used only for ingestion into the
 store.

 Note that interface and base layers would need to have their own
 project, since they don't really fit into the charms/series project
 structure.  They can also live outside of Launchpad and work just fine as
 long as they are registered in http://interfaces.juju.solutions/
 (which can be done by anyone with Launchpad credentials) (eventually, the
 plan is for them to be published to the store in a similar way to charms).

 I'd also like to mention our recommendations for developing layered
 charms.  Specifically, you should create a base Juju repository directory
 (e.g., ~/charms) and subdirectories for "layers", "interfaces" (if you plan
 to develop those), and any series directories such as "trusty".  Then, you
 should ensure that the following variables are set in your environment:

 JUJU_REPOSITORY=~/charms
 LAYER_PATH=$JUJU_REPOSITORY/layers
 INTERFACE_PATH=$JUJU_REPOSITORY/interfaces  # optional

 Many layer and interface repos are prefixed with "layer-" or
 "interface-" to indicate their role (e.g.,
 https://github.com/juju-solutions/layer-hadoop-base) but when cloned
 locally to work on them, the directory name must match the layer or
 interface name ("hadoop-base", in this case).  So, to clone that repo:

 git clone https://github.com/juju-solutions/layer-hadoop-base
 $JUJU_REPOSITORY/layers/hadoop-base

 This will ensure that `charm build` does the right thing, can find all
 of your in-progress layers, and puts the built charm in the right place.

>>>
>>> Is this all documented somewhere? I ended up doing almost exactly what
>>> you've described here through reading the charm tools code -- would be good
>>> to get it into the author's guide, I think.
>>>
>>> Is anyone looking at making it possible to build reactive charms
>>> offline? AFAICT, you have to have access 

Re: Juju-GUI and status-set

[Marco Ceppi]

I believe that the Juju GUI team is preparing a release in the coming weeks
to address this. It's not so much a bug, but rather a planned feature for
Juju GUI

On Fri, Dec 11, 2015 at 3:30 AM Sameer Zeidat  wrote:

> Hello,
>
> I'm setting charm status to blocked (sometimes to waiting), but juju-gui
> doesn't show any change (charm icon stays green). Is this a bug, or maybe
> I'm missing something?
>
> The juju status command shows status as expected (i.e. waiting or
> blocked), along with the message I specified.
>
> Thanks,
> Sameer
> --
> 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 Charm store submission and functional tests using Amulet

[Marco Ceppi]

Hi Bruno,

When I search the charm store, https://jujucharms.com/u/3-bruno/, I don't
see any of these charms. However, they are properly uploaded to bzr. We're
very close to switching over to a new (more direct) way to publish charms
to the store, one where the process is a lot more transparent and direct.
However, in the meantime I've looked at your charms and I don't see any
issue which would prevent ingestion. I'll speak with our web team to figure
out if something else is wrong which isn't catching my eye.

As for your Amulet bug, it's not directly related to this, the error is
indicating that the websocket is timing out on deployment. I've kicked off
another round of tests on the review for the registry charm:
http://review.juju.solutions/review/2398 it seems to be the only one
failing of the ~5 you've submitted. I'll respond and take the Amulet
question off list and onto the bug report.

Thanks,
Marco Ceppi

On Mon, Jan 4, 2016 at 9:04 AM Bruno Ranieri <br...@quobyte.com> wrote:

> Hello,
>
> I run into some problems when trying to bring some new charms through the
> charm store process
>
> https://bugs.launchpad.net/~3-bruno
>
> I submitted the charms, following the instructions on
> https://jujucharms.com/docs/stable/authors-charm-store, unfortunately the
> charms never showed up as name spaced charms. Thus
>
> juju deploy cs:~3-bruno/trusty/quobyte-registry
>> ERROR cannot resolve charm URL "cs:~3-bruno/trusty/quobyte-registry":
>> charm not found
>>
>
> while deployment using the local repository works fine.
>
> Another problem occurred, when I started to port my functional test from
> external scripts to /tests. Deployment is successful when using
> the local provider, but fails using a cloud provider (amazon):
>
> https://bugs.launchpad.net/amulet/+bug/1528582
>>
>
> Maybe this is related to the issue about name spaced charms described
> above? Unfortunately the uncaught Exception from Amulet does not provide
> further details.
>
> The problem is that my local environment does not provide enough
> resources, so I depend on using a cloud provider to port and test this
> functional tests. Just for completeness: my juju amazon environment is
> working fine. I can witness instances and volumes start-up and tear-down,
> when running my external functional tests or invoke tests using 'juju test'.
>
>
> regards
>  Bruno
>
>
> --
> *Quobyte* GmbH
> Hardenbergplatz 2 - 10623 Berlin - Germany
>
>
>
> --
> *Quobyte* GmbH
> Hardenbergplatz 2 - 10623 Berlin - Germany
> +49-30-814 591 800 - www.quobyte.com
> Amtsgericht Berlin-Charlottenburg, HRB 149012B
> management board: Dr. Felix Hupfeld, Dr. Björn Kolbeck, Dr. Jan Stender
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm for webapp with webserver or not?

[Marco Ceppi]

Hi Patrik,

We have a few layers for php and nginx (http://interfaces.juju.solutions/).
While are almost exclusively written in Python, Bash is another supported
language for creating layers (though, with less bash layers written at the
moment, it's likely not as well tested as Python).

Marco

On Mon, Jan 4, 2016 at 9:39 AM Patrik Karisch <patrik.kari...@gmail.com>
wrote:

> Hi Marco,
>
> seems the best way to do so. Better supply my correct configuration of
> nginx and php-fpm instead relying on another charm. Pro: My webapp charm
> can specialize all config params.
>
> I've read the charm layers already and they seem interesting to build
> different webapps. Although I must read more how my charm can adapt config
> stuff from the layer and create one a layer for my nginx/php needs. And I
> have to research in which languages I can use the reactive pattern, because
> I don't know Python :)
>
> Thanks,
> Patrik
>
> Marco Ceppi <marco.ce...@canonical.com> schrieb am Mo., 4. Jan. 2016 um
> 15:13 Uhr:
>
>> Hi Patrik,
>>
>> It's best to think of the charm as an entire solution for the
>> application/component your deploying. So if you need a web server to make
>> this solution complete, it's best to include it. There are some exceptions
>> to this, but generally speaking it's the rule of thumb.
>>
>> If you're looking to avoid re-implementing logic for apache2, or other
>> common components, then I'd suggesting taking a look at charm layers. Charm
>> layers give the same concept of composition as juju does with services, but
>> at the charm creation level.
>> https://jujucharms.com/docs/stable/authors-charm-building these are some
>> early docs and we'll have a fully rewritten author docs around charm layers
>> up in a week or so.
>>
>> Marco
>>
>> On Mon, Jan 4, 2016 at 6:54 AM Patrik Karisch <patrik.kari...@gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> if I create a charm for my webapp, should it already install the
>>> webserver or should it only provide a interface as subordinate for e.g. the
>>> apache2 charm? In the first case, each webapp must be run in separate
>>> containers as a minimum.. But I think scaling up is much easier, because it
>>> provides the server. What do you think?
>>>
>>> Another unclear point for me. If I use the apache2 charm with
>>> apache2-reverseproxy subordinate to proxy different webapps (everyone in
>>> it's own LXC container) on the same host, is it easy to remove the
>>> reverseproxy subordinate charm to deactivate the webapp easily?
>>>
>>> Best regards
>>> Patrik
>>>
>> --
>>> 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 Charm store submission and functional tests using Amulet

[Marco Ceppi]

On Mon, Jan 4, 2016 at 9:51 AM Bruno Ranieri <br...@quobyte.com> wrote:

> Hi Marco,
>
> thanks for the quick response.
>
> 2016-01-04 15:21 GMT+01:00 Marco Ceppi <marco.ce...@canonical.com>:
>
>
>> When I search the charm store, https://jujucharms.com/u/3-bruno/, I
>> don't see any of these charms. [...]
>>
>
>> As for your Amulet bug, it's not directly related to this, the error is
>> indicating that the websocket is timing out on deployment. I've kicked off
>> another round of tests on the review for the registry charm:
>> http://review.juju.solutions/review/2398 it seems to be the only one
>> failing of the ~5 you've submitted. I'll respond and take the Amulet
>> question off list and onto the bug report.
>>
>
>
> The registry charm is actually the only one with a tests folder. As I
> mentioned, my functional tests still need to be ported to the 'juju
> test'-environment.
>
> The registry charm only contains the example code that invoke the amulet
> installation and deploys the charm. Which leads to my remark about the
> relation between the two issues. Where does Amulet deploys the charm from,
> when it does not find it in the (named) charm store?
>

Thanks for the clarification. Amulet does several lookups to determine
charm location. However, if the name of the charm being deployed
(quobyte-registry) matches the current charm directory the test is running
from, it uploads the charm from disk for deployment.

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

New Developer Docs for review!

[Marco Ceppi]

Hello everyone!

With layers now becoming the defacto form for charming we found it
pertinent to also update the Developer documentation to reflect this shift.
A large portion of that work has been completed (!!!) but it's not quite
done yet.

Some of you may have seen these docs in one form or another but I'd like to
invite the community at large to help review the new docs to find any
issues with their structure and flow as well as provide feedback for ways
to improve or items we are missing. We're aware of a few major holes still
that we're working on plugging and any help would be great.

The docs are now in the devel branch on the website
https://jujucharms.com/docs/devel/developer-getting-started any issues
found can be logged here https://github.com/juju/docs/issues and pull
requests are welcome! Our goal is to have these docs completed come Juju
2.0 release to usher in the new juju hotness!

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

[ANN] charm-tools 1.9.3

[Marco Ceppi]

Hello everyone!

I'm happy to announce another charm-tools release today, this is the 1.9.3
which succeeds 1.8.0 as the latest release of charm-tools. If you've
managed to install 1.9.0, 1.9.1, or 1.9.2 in the past several days please
be sure to upgrade. As always, you can verify the version you are running
by executing: `charm version`

# Changes

5cadfda [Marco Ceppi] version bump
8c09431 [Marco Ceppi] Make sure wheel is available in build venv fixes #51
11557b3 [Marco Ceppi] version bump
2a70207 [Marco Ceppi] install_requires needed because Homebrew can't handle
a pip install
f820bfd [Marco Ceppi] version bump
3ae864a [Marco Ceppi] virtualenv is a dependency
975702a [Marco Ceppi] version bump
55193cd [Cory Johns] Switch WheelhouseTactic to use a venv and include
(newer) pip in wheelhouse
67639fa [Cory Johns] Added support for building a wheelhouse
da058a3 [Tim Van Steenburgh] Implement charm-proof for storage
a098a99 [Benjamin Saller] special case 'help' for issue #35
b2ec3b1 [Benjamin Saller] metrics no longer defaults to off


## Proof now supports storage

This was a nice update with the new storage feature in 1.25 - we're keeping
a close eye on 1.26 and will make sure metadata changes there are supported.

## Wheel House for layer dependencies

Going forward we recommend all dependencies for layers and charms be
packaged in a wheelhouse.txt file. This perform the installation of pypi
packages on the unit instead of first on the local machine meaning Python
libraries that require architecture specific builds will do it on the units
architecture. This also provides the added bonus of making `charm layers` a
much cleaner experience.

Here's an example of side-by-side output of a charm build of the basic
layer before and after converting to Wheelhouse.

Previous: http://paste.ubuntu.com/13502779/ (53 directories, 402 files)
Wheelhouse: http://paste.ubuntu.com/13502787/ (3 directories, 21 files)

This is the superior way package dependencies in charms, and we look
forward to current layers migrating to a wheelhouse tactic. That said,
charms which currently use a .pypi file in the lib directory will continue
to work as expected and is a supported method of including dependencies.

# Install
Charm Tools is available to users either via the juju/stable PPA, Homebrew,
or pip

## PPA

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

## Homebrew

brew install charm-tools

* This will be available once
https://github.com/Homebrew/homebrew/pull/46352 has been merged

## PIP

pip install -U charm-tools

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

Re: [ANN] charm-tools 1.9.3

[Marco Ceppi]

On Wed, Nov 25, 2015 at 4:08 PM Simon Davy <bloodearn...@gmail.com> wrote:

> On 25 November 2015 at 16:02, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
> > ## Wheel House for layer dependencies
> >
> > Going forward we recommend all dependencies for layers and charms be
> > packaged in a wheelhouse.txt file. This perform the installation of pypi
> > packages on the unit instead of first on the local machine meaning Python
> > libraries that require architecture specific builds will do it on the
> units
> > architecture.
>
> If I'm understanding the above correctly, this approach is a blocker for
> us.
>
> We would not want to install direct from pypi on a production service
>
>  1) pypi packages are not signed (or when they are, pip doesn't verify
> the signature)
>  2) pypi is an external dependency and thus unreliable (although not
> as bad these days)
>  3) old versions can disappear from pypi at an authors whim.
>  4) installing c packages involves installing a c toolchain on your prod
> machine
>
> Additionally, our policy (Canonical's, that is), does not allow access
> to the internet on production machines, for very good reasons. This is
> the default policy in many (probably most) production environments.
>
> Any layer or charm that consumes a layer that uses this new approach
> for dependencies would thus be unusable to us :(
>
> It also harms repeatability, and I would not want to use it even if
> our access policy allowed access to pypi.
>
> For python charm dependencies, we use system python packages as much
> as possible, or if we need any wheels, we ship that wheel in the
> charm, and pip install it directly from the there. No external
> network, completely repeatable.
>

So, allow me to clarify. If you review the pastebin outputs from the
original announcement email, what this shift does is previously `charm
build` would create and embed installed dependencies into the charm under
lib/ much like charm-helper-sync did for instead for any arbitrary Pypi
dependency. Issues there are for PyYAML it will build a yaml.so file which
would be built based on the architecture of your machine and not the cloud.

This new method builds source wheels and embeds the wheel in the charm.
There's a bootstrap process on deploy that will unpackage and install the
dependencies on the system when deployed. The deps are still bundled in the
charm just the output of the charm is much more sane and easier to read


>
> Another option is to require/configure a local pypi to pull the
> packages from, but  again, an external dependency and spof.
>
> I much prefer what the current tool seems to do, bundle deps as wheels
> into a wheels/ dir as part of the charm build process.  Then that
> charm is self-contained, and requires no external access, and is more
> reliable/repeatable.
>
> > This also provides the added bonus of making `charm layers` a
> > much cleaner experience.
> >
> > Here's an example of side-by-side output of a charm build of the basic
> layer
> > before and after converting to Wheelhouse.
> >
> > Previous: http://paste.ubuntu.com/13502779/ (53 directories, 402 files)
> > Wheelhouse:  http://paste.ubuntu.com/13502779// (3 directories, 21
> files)
>
> These are the same link?
>
> But looking at the link, I much prefer that version - everything is
> bundled with the charm, as I suggest above.
>

Sorry, meant to send two links.

The first: http://paste.ubuntu.com/13502779/
The Second: http://paste.ubuntu.com/13511384/

Now which one would you prefer :)

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

Re: [ANN] charm-tools 1.9.3

[Marco Ceppi]

On Wed, Nov 25, 2015 at 7:44 PM Rick Harding 
wrote:

> On Wed, Nov 25, 2015 at 4:08 PM Simon Davy
>
>> I don't know where we are at with the resources work, but maybe that
>> could have a part to play here?
>>
>
> This is exactly what I wanted to bring up for discussion. This work is
> about to start at the end of this month/start of next. It sounds like
> there's something here to building a wheel and using it as a resource and
> letting the charm pull the correct wheel based on the unit architecture.
>
> The harder part is how to get those built and upload to the store as
> resources. Marco, can you work with Simon on the start of a spec and let's
> start to look through some ideas on how to handle this.
>
> I do want to say the wheel based work is great. The UI Engineering team
> has done it and it's sped things up immensely. However, in their work
> there's only one architecture targeted so the wheels are all pre-built and
> only for one platform. To have truly reusable charms (big data on power and
> amd64 and ...) we need to think through this much closer to a PPA-like
> approach than building on the units, especially as we're working so hard to
> get deployment times down when charms get placed on units.
>

I'd be happy to help work on a spec and follow up with the team working on
resources. I do want to mention though that these wheel/dep embedded in the
charms is more resources/deps needed for hook execution and less workload
dependencies/resources. I'm not sure if that makes a difference or if the
distinction is worth discussing further.

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

Re: Is svg.juju.solutions down?

[Marco Ceppi]

Hi Merlijn,

Sorry for the outage. Apparently the cloud is an ephemeral world. We deploy
svg.juju.solutions from the charm store
https://jujucharms.com/u/marcoceppi/charm-svg/3 but the cloud it was on
decided to turn off all the instances. I've redeployed it and it's back up
now.

I'll work on deploying it across a few regions and get a loadbalancer in
place to prevent this in the future. `juju add-unit` :)

Marco

On Tue, Jun 14, 2016 at 12:15 PM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Is svg.juju.solutions down? The "download svg" part of
> cloud-weather-report seems to be timing out.
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Is svg.juju.solutions down?

[Marco Ceppi]

It's possible, it has been a while since I checked the code but I'll double
check and get back to you.

Marco

On Wed, Jun 15, 2016, 2:32 AM Merlijn Sebrechts <merlijn.sebrec...@gmail.com>
wrote:

> Thanks, Marco!
>
>
> It's working now, but I'm getting 500 errors on our bundles. Is it
> possible that local charms are not supported? Since we're using cwr for our
> ci pipeline, all charms will be local... It would be nice if
> svg.juju.solutions could just render blank charms when it receives a bundle
> with local charms.
>
> This is one of our bundles:
> https://github.com/IBCNServices/tengu-charms/blob/master/bundles/hauchiwa-testbundle/bundle.yaml
>
>
>
> Kind regards
> Merlijn Sebrechts
>
> 2016-06-14 21:33 GMT+02:00 Marco Ceppi <marco.ce...@canonical.com>:
>
>> Hi Merlijn,
>>
>> Sorry for the outage. Apparently the cloud is an ephemeral world. We
>> deploy svg.juju.solutions from the charm store
>> https://jujucharms.com/u/marcoceppi/charm-svg/3 but the cloud it was on
>> decided to turn off all the instances. I've redeployed it and it's back up
>> now.
>>
>> I'll work on deploying it across a few regions and get a loadbalancer in
>> place to prevent this in the future. `juju add-unit` :)
>>
>> Marco
>>
>> On Tue, Jun 14, 2016 at 12:15 PM Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Is svg.juju.solutions down? The "download svg" part of
>>> cloud-weather-report seems to be timing out.
>>>
>>
>
-- 
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

[Marco Ceppi]

I don't think this needs to be scoped to just proprietary charms. It can be
better scoped to:

Any software which requires acceptance of a license or EULA has to have
that as a term on the charm
Any software which installs components from outside of a distributions
archive needs to represent that as a resource

There are free software that require a EULA and free software not readily
distributed and consumable in an off-line environment where you only have a
mirror of that distros archive.

Marco

On Thu, May 26, 2016 at 10:02 AM Charles Butler <
charles.but...@canonical.com> wrote:

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

Re: Apache Drill Charm

[Marco Ceppi]

+1 to using % logic to make it scale across any sized instance. Awesome
stuff!

On Wed, Jun 1, 2016 at 6:28 AM Tom Barber  wrote:

> Okay latest "stable" build has RAM config options.
>
> Drill ships with defaults of 8GB and 3GB but I didn't want it to die on
> EC2 Large etc boxes that dont have that much. So I added a bit of logic,
> you can (I hope) add XXG and it will use that fixed amount, or you can, as
> it ships, tell it you want XX% MAX and XX% Heap and it will try and figure
> that out and stand you up a drill box.
>
>
> Tom
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 1 June 2016 at 00:50, Tom Barber  wrote:
>
>> Oh, also currently the RAM is clamped down real low
>> in /opt/drill/conf/drill-env.sh I will set it back to some sane defaults
>> tomorrow as soon as I put the RAM limits into the config options, just ran
>> out of time this evening!
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> On 31 May 2016 at 23:50, Tom Barber  wrote:
>>
>>> Here we are then, for Merlijn and anyone else interested in SQL
>>> interfaces to big data/NOSQL stuff.
>>>
>>> This is less than a days effort, so its patchy at best:
>>>
>>> https://jujucharms.com/u/spicule/drillbit
>>>
>>> For those of you who don't know Apache Drill, it will let you run SQL
>>> querys over, CSV/JSON data, MongoDB, HBase, Parquet files etc in a number
>>> of different locations. Basically its a great way for analysts who use
>>> "traditional" SQL tools to leverage data stored within NOSQL solutions.
>>>
>>> Getting something like this into the CS has been high on my list of
>>> priorities for Saiku Analytics as it suddenly offers up loads of new
>>> connection prospects(of course I can do this manually in the past, but this
>>> is what Juju is for, right?)
>>>
>>> You need to deploy a ZK node (or 3) and connect it to that and OpenJDK
>>> to run it. Currently its relations-lite, the only one in there is a MongoDB
>>> test relation that will connect Drill to your MongoDB cluster if you run
>>> one, but there will be actions and relations coming shortly for other
>>> stuff. Also its missing a fat load of config options, again, coming soon.
>>> You can set all of this stuff pretty simply though and there is a web
>>> console for queries/connections etc, on http://serverip:8047/
>>>
>>> Test it, let me know what you think or its its entirely broken. Adding
>>> this and a few other NOSQL SQL interfaces is key to people being able to
>>> sanely consume all this big data stuff that is great on Juju. Thats not a
>>> knock on the Zeppelin guys, but companies will continue to use SQL for a
>>> long time to come so we should service that requirement.
>>>
>>> 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