Re: Statistics and metrics about Charm, layer and interface usage

[Adam Collard]

Hi Merlijn,

On Thu, 25 Jan 2018 at 16:17 Merlijn Sebrechts 
wrote:

> Hi all
>
>
> I'm writing a Juju-related paper and I'd like to get statistics on Charm,
> layer and interface usage. Are these publicly available?
>
> Related: is there a documented API to get the code of the charms that are
> available in the charm store?
>

GET https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/ will
give you a .zip
and

GET
https://api.jujucharms.com/charmstore/v5/$MY_CHARM_NAME/archive/$PATH/$TO/$FILE
will give you the 'raw' contents.

e.g. curl
https://api.jujucharms.com/charmstore/v5/postgresql/archive/hooks/install

YMMV,

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

Re: PROPOSAL: stop recording 'executing update-status hook'

[Adam Collard]

On Fri, 19 May 2017 at 03:14 Tim Penhey  wrote:

> Hi folks,
>
> Currently juju will update the status of any hook execution for any unit
> to show that it is busy doing things. This was all well and good until
> we do things based on time.
>
> Every five minutes (or so) each unit will have the update-status hook
> executed to allow the unit to set or update the workload status based on
> what is currently going on with that unit.
>
> Since all hook executions are stored, this means that the
> show-status-log will show the unit jumping from executing update-status
> to ready and back every five minutes.
>
> The proposal is to special case the update-status hook and show in
> status (or the status-log) that the hook is being executed. debug-log
> will continue to show the hook executing if you are looking.
>
> This will reduce noise in the status-log, simplify some of our code
> around dealing with status-log, and reduce load on controllers looking
> after hundreds or thousands of units.
>

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

Re: Juju 2.1.0, and Conjure-up, are here!

[Adam Collard]

On Fri, 24 Feb 2017 at 10:07 Adam Israel  wrote:

> Thanks for calling this out, Simon! We should be shouting this from the
> rooftops and celebrating in the streets.
>

Only if you also wave a big WARNING banner!

I can definitely see value in pre-installing a bunch of things in your LXD
images as a way of speeding up the development/testing cycle, but doing so
might give you false confidence in your charm. It will become much easier
to forget to list a package that you need installing,  or to ensure that
you have the correct access (PPA credentials, or proxy details etc.) and
having your charm gracefully handle when those are missing.

Juju promises charms encoding operations that can work across multiple
cloud providers, bare metal and containers please keep that in mind :)


> On Fri, Feb 24, 2017 at 8:42 AM Stuart Bishop 
> wrote:
>
> On 23 February 2017 at 23:20, Simon Davy  wrote:
>
> > One thing that seems to have landed in 2.1, which is worth noting IMO, is
> > the local juju lxd image aliases.
> >
> > tl;dr: juju 2.1 now looks for the lxd image alias juju/$series/$arch in
> the
> > local lxd server, and uses that if it finds it.
> >
> > This is amazing. I can now build a local nightly image[1] that
> pre-installs
> > and pre-downloads a whole set of packages[2], and my local lxd units
> don't
> > have to install them when they spin up. Between layer-basic and Canonical
> > IS' basenode, for us that's about 111 packages that I don't need to
> install
> > on every machine in my 10 node bundle. Took my install hook times from
> 5min+
> > each to <1min, and probably halfs my initial deploy time, on average.
>
> Ooh, thanks for highlighting this! I've needed this feature for a long
> time for exactly the same reasons.
>
>
> > [2] my current nightly cron:
> > https://gist.github.com/bloodearnest/3474741411c4fdd6c2bb64d08dc75040
>
> /me starts stealing
>
> --
> Stuart Bishop 
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Adam Israel, Software Engineer
> Canonical // Cloud DevOps // Juju // Ecosystem
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Squelching Leadership messages

[Adam Collard]

On Fri, 13 Jan 2017 at 15:51 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> John A Meinel  writes:
>
> > Note that we should still report leadership changes at INFO level, which
> should allow you to
> > debug easy things without changing the log level, as those changes
> should happen very
> > rarely.
>
> +1, thanks for this!
>

Hear hear, thanks John!

I'm looking forward to more signal in Juju logs \o/
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Opaque automatic hook retries from API

[Adam Collard]

Hi,

The automatic hook retries[0] that landed as part of 2.0 (are documented
as) run indefinitely[1] - this causes problems as an API user:

Imagine you are driving Juju using the API, and when you perform an
operation (e.g. set the configuration of a service, or reboot the unit, or
add a relation..) - you want to show the status of that operation.

Prior to the automatic retries, you simply perform your operation, and
watch the delta streams for the corresponding change to the unit - the
success or otherwise of the operation is reflected in the unit
agent-status/workload-status pair.

Now, with retries, if you see a unit in the error state, you can't
accurately reflect the status of the operation, since the unit will
undoubtedly retry the hook again. Maybe it succeeds, maybe it fails again.
How can one say after receiving the first delta of a unit error if the
operation succeeded or failed?

With no visibility up front on the retry strategy that Juju will perform
(e.g. something representing the exponential backoff and a fixed number of
retries before Juju admits defeat) it is impossible to say at any point in
the delta stream what the result of a failed-at-least-once operation is.

Can retries be limited to a small number, with a backoff algorithm
explicitly documented and stuck to by Juju, with the retry attempt number
included in the delta stream?

Thanks,

Adam

[0] https://jujucharms.com/docs/2.0/reference-release-notes
[1] https://jujucharms.com/docs/2.0/models-config#retrying-failed-hooks
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Application names starting with digits

[Adam Collard]

On Fri, 2 Dec 2016 at 13:43 Mark Shuttleworth <m...@ubuntu.com> wrote:

> On 02/12/16 07:46, Adam Collard wrote:
> > It'd be nice to have full Unicode support in both charm and
> > application names.
>
> Steady on, that would make it easy to have misleading charm names, or
> ones that are very difficult for people to type.


True, but we could do normalisation in the charm store to prevent malicious
names. I think it's an important aspect of software in the modern world
that it can support the wide array of languages that we humans use.

Besides, who doesn't want to have charms with emoji in them ?

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

Re: Application names starting with digits

[Adam Collard]

It'd be nice to have full Unicode support in both charm and application
names.

On Fri, 2 Dec 2016 at 12:43 Nate Finch  wrote:

> There's no technical reason for the restriction, AFAIK.  I believe it's
> just aesthetic.
>
> On Fri, Dec 2, 2016, 5:50 AM James Page  wrote:
>
> Hi All
>
> Is there a specific rationale for application names being limited to not
> starting with a digit?  I get why they can't end with one but I don't see
> why juju should place the same restriction on the start of an app name?
> Example (where we tripped over this):
>
>juju deploy ubuntu 6wind-virtual-accelerator
>
> (and ubuntu just to test the name out of a proposed charm where we had
> testing problems due to this limitation)
>
> Thoughts?
>
> James
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Fwd: A (Very) Minimal Charm

[Adam Collard]

Oops, forgot to reply to the list.

-- Forwarded message -
From: Adam Collard <adam.coll...@canonical.com>
Date: Thu, 1 Dec 2016 at 13:43
Subject: Re: A (Very) Minimal Charm
To: Marco Ceppi <marco.ce...@canonical.com>


On Thu, 1 Dec 2016 at 12:53 Marco Ceppi <marco.ce...@canonical.com> wrote:

On Thu, Dec 1, 2016 at 5:00 AM Adam Collard <adam.coll...@canonical.com>
wrote:

On Thu, 1 Dec 2016 at 04:02 Nate Finch <nate.fi...@canonical.com> wrote:

On IRC, someone was lamenting the fact that the Ubuntu charm takes longer
to deploy now, because it has been updated to exercise more of Juju's
features.  My response was - just make a minimal charm, it's easy.  And
then of course, I had to figure out how minimal you can get.  Here it is:

It's just a directory with a metadata.yaml in it with these contents:

name: min
summary: nope
description: nope
series:
  - xenial

(obviously you can set the series to whatever you want)
No other files or directories are needed.


This is neat, but doesn't detract from the bloat in the ubuntu charm.


I'm happy to work though changes to the Ubuntu charm to decrease "bloat".


Great!




IMHO the bloat in the ubuntu charm isn't from support for Juju features,
but the switch to reactive plus conflicts in layer-base wanting to a)
support lots of toolchains to allow layers above it to be slimmer and b) be
a suitable base for "just deploy me" ubuntu.


But it is to support the reactive framework, where we utilize newer Juju
features, like status and application-version to make the charm rich
despite it's minimal goal set. Honestly, a handful of cached wheelhouses
and some apt packages don't strike me as bloat, but I do want to make sure
the Ubuntu charm works for those using it. So,

What's the real problem with the Ubuntu charm today?


It apt-get installs something
It pip installs something

Both of these take non-trivial amounts of time.

How does it not achieve it's goal of providing a relatively blank Ubuntu
machine?


It does, but an additional goal (IMO) is to do so quickly and with minimal
(zero?) network requirements.


What are people using the Ubuntu charm for?


Demonstrating/finding Juju bugs whilst ruling out lots of other potential
sources of confusion.


Other than demos, hacks/workarounds, and testing I'm not clear on the
purpose of an Ubuntu charm in a model serves.


Hope this sheds some light on what we were using the Ubuntu charm for.


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

Re: A (Very) Minimal Charm

[Adam Collard]

On Thu, 1 Dec 2016 at 04:02 Nate Finch  wrote:

On IRC, someone was lamenting the fact that the Ubuntu charm takes longer
to deploy now, because it has been updated to exercise more of Juju's
features.  My response was - just make a minimal charm, it's easy.  And
then of course, I had to figure out how minimal you can get.  Here it is:

It's just a directory with a metadata.yaml in it with these contents:

name: min
summary: nope
description: nope
series:
  - xenial

(obviously you can set the series to whatever you want)
No other files or directories are needed.


This is neat, but doesn't detract from the bloat in the ubuntu charm.

IMHO the bloat in the ubuntu charm isn't from support for Juju features,
but the switch to reactive plus conflicts in layer-base wanting to a)
support lots of toolchains to allow layers above it to be slimmer and b) be
a suitable base for "just deploy me" ubuntu.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: "unfairness" of juju/mutex

[Adam Collard]

FWIW this is being tracked in https://bugs.launchpad.net/juju/+bug/1642541


On Thu, 17 Nov 2016 at 04:17 Nate Finch  wrote:

> Just for historical reference.  The original implementation of the new OS
> mutex used flock until Dave mentioned that it presented problems with file
> management (files getting renamed, deleted, etc).
>
> In general, I'm definitely on the side of using flock, though I don't
> think that necessarily solves our starvation problem, it depends on how
> flock is implemented and the specific behavior of our units.
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Github Reviews vs Reviewboard

[Adam Collard]

Not sure I get a vote, but -1

You're running an old version of ReviewBoard (2.0.12 released in January
2015) and many of the issues I think you've been hitting are fixed in later
revisions. Latest stable is 2.5.6.1, 3.0.x is under active development and
brings a chunk of new UI improvements.

Release notes for 2.5


3.0 demo site 

On Fri, 14 Oct 2016 at 12:34 Michael Foord 
wrote:

> 0
>
> On 13/10/16 23:44, Menno Smits wrote:
>
> We've been trialling Github Reviews for some time now and it's time to
> decide whether we stick with it or go back to Reviewboard.
>
> We're going to have a vote. If you have an opinion on the issue please
> reply to this email with a +1, 0 or -1, optionally followed by any further
> thoughts.
>
>- +1 means you prefer Github Reviews
>- -1 means you prefer Reviewboard
>- 0 means you don't mind.
>
> If you don't mind which review system we use there's no need to reply
> unless you want to voice some opinions.
>
> The voting period starts *now* and ends my* EOD next Friday (October 21)*.
>
> As a refresher, here are the concerns raised for each option.
>
> *Github Reviews*
>
>- Comments disrupt the flow of the code and can't be minimised,
>hindering readability.
>- Comments can't be marked as done making it hard to see what's still
>to be taken care of.
>- There's no way to distinguish between a problem and a comment.
>- There's no summary of issues raised. You need to scroll through the
>often busy discussion page.
>- There's no indication of which PRs have been reviewed from the pull
>request index page nor is it possible to see which PRs have been approved
>or otherwise.
>- It's hard to see when a review has been updated.
>
> *Reviewboard*
>
>- Another piece of infrastructure for us to maintain
>- Higher barrier to entry for newcomers and outside contributors
>- Occasionally misses Github pull requests (likely a problem with our
>integration so is fixable)
>- Poor handling of deleted and renamed files
>- Falls over with very large diffs
>- 1990's looks :)
>- May make future integration of tools which work with Github into our
>process more difficult (e.g. static analysis or automated review tools)
>
> There has been talk of evaluating other review tools such as Gerrit and
> that may still happen. For now, let's decide between the two options we
> have recent experience with.
>
> - Menno
>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: JUJU Charm Certification

[Adam Collard]

Hi Siva,

On Wed, 7 Sep 2016 at 10:58 SivaRamaPrasad Ravipati 
wrote:

> Hi,
>
> I have installed the openstack cloud using openstack Autopilot. I am trying 
> to deploy juju-gui in the internal juju environment.
>
>
>
>
> I did the following.
> 
>
> ->From MAAS node
>
> $export JUJU_HOME=~/.cloud-install/juju
>
> -> Connecting Landscape server to deploy our charm  and add relation to 
> cinder charm.
>
> $juju ssh landscape-server/0 sudo 
> 'JUJU_HOME=/var/lib/landscape/juju-homes/`sudo ls -rt 
> /var/lib/landscape/juju-homes/ | tail -1` sudo -u landscape -E bash'
>
> -> From Landscape Server
>
> landscape@juju-machine-0-lxc-1:~$ juju deploy cs:juju-gui-134
>
> Added charm "cs:trusty/juju-gui-134" to the environment.
>
>
> ubuntu@juju-machine-0-lxc-1:~$ juju status
>   
> "4":
> agent-state: error
> agent-state-info: 'cannot run instances: cannot run instances: gomaasapi: 
> got
>   error back from server: 409 CONFLICT (No available node matches 
> constraints:
>   zone=region1)'
> instance-id: pending
> series: trusty
>
>
>
>
>
>  juju-gui:
> charm: cs:trusty/juju-gui-134
> exposed: false
> service-status:
>   current: unknown
>   message: Waiting for agent initialization to finish
>   since: 07 Sep 2016 06:46:22Z
> units:
>   juju-gui/1:
> workload-status:
>   current: unknown
>   message: Waiting for agent initialization to finish
>   since: 07 Sep 2016 06:46:22Z
> agent-status:
>   current: allocating
>   since: 07 Sep 2016 06:46:22Z
> agent-state: pending
> machine: "4"
>
>
> JUJU Version
> = 
>
> ubuntu@juju-machine-0-lxc-1:~$ juju --version
> 1.25.6-trusty-amd64
>   
>
> My assumption
>
> =
>
> It looks like we need to define a pool of servers in a region called region1.
>
>
> I have a question. Once we have Ubuntu OpenStack Autopilot deployment, If we 
> need to deploy any Charm externally we need to add a sever to MAAS?
>
> How can I solve this Issue. Please provide me some solution.
>
>
After cleaning up (juju destroy-service juju-gui) please try with an
explicit placement e.g.

$ juju deploy juju-gui --to lxc:0

See
https://jujucharms.com/docs/1.25/charms-deploying#deploying-to-specific-machines-and-containers
for more information on providing placement directives to Juju.

Regards,

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

Re: RFC: proposed changes to debug-log API call

[Adam Collard]

On Tue, 9 Aug 2016 at 09:43 Tim Penhey  wrote:

> Is anyone currently using the streaming text aspects of the API right now?
>

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

Re: Juju stable 1.25.6 is released

[Adam Collard]

Can we use hyperlinks to Launchpad bugs in these release emails? It's a
small papercut but every time I want to dig in on some of the bugs to work
out the potential impact and have to go through a copy/paste step.

Thanks!

On Wed, 27 Jul 2016 at 10:35 Martin Packman 
wrote:

> # juju-core 1.25.6
>
> A stable release of Juju, juju-core 1.25.6, is now available.
> This release replaces version 1.25.5.
>
>
> ## Getting Juju
>
> juju-core 1.25.6 is available for Xenial and backported to earlier
> series in the following PPA:
>
> https://launchpad.net/~juju/+archive/stable
>
> Windows, Centos, and OS X users will find installers at:
>
> https://launchpad.net/juju-core/+milestone/1.25.5
>
>
> ## Notable Changes
>
> This releases addresses stability and performance issues reported by our
> users over the past months. Thanks everyone for continuing to push the
> limits and filing bugs.
>
>
> ## Resolved issues
>
>   * Machine agent failed to register ip addresses, borks agent
> Lp 1537585
>
>   * "invalid entity name or password" error with valid credentials.
> Lp 1514874
>
>   * 'juju help' provider information is out of date
> Lp 1519877
>
>   * Cached local charms should be deleted when their service is
> removed
> Lp 1580418
>
>   * Cannot obtain provisioning script
> Lp 1559299
>
>   * Uniter-hook-execution error prevents  "resolve" unit.
> Lp 1486712
>
>   * Goroutine panic launching container on xenial
> Lp 1592210
>
>   * Trusty juju 1.25.5 ha availability issues
> Lp 1575448
>
>   * Maas provider bridge script on trusty does not handle lacp bonds
> Lp 1594855
>
>   * Concurent map access in joyent
> Lp 1554251
>
>   * Juju run command failing
> Lp 1598964
>
>
> Finally
>
> We encourage everyone to subscribe the mailing list at
> juju-dev@lists.ubuntu.com, or join us on #juju-dev on freenode.
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Automatic hook retries in Juju 2.0

[Adam Collard]

Did we get a way of disabling this 'feature'? As I remember from the
initial ML post, there was a repeated request to be able to disable this
for certain environments (e.g. dev/test of charms).

Many charms have race conditions in their hook execution which aren't seen
through regular use of the Juju CLI client, but other Juju API drivers
(e.g. Autopilot) expose.

Although automatic hook retries may well negate transient network issues,
they risk hiding these kinds of bugs. As a charm author I want Juju to help
me find these bugs, so have it fail when I mess up. Papering over them
gives me a false sense of security.


On Thu, 30 Jun 2016 at 17:27 Bogdan Teleaga 
wrote:

> Hey Casey,
>
> They are all retried using the same policy.
>
> The constants that control the delay are here:
>
> https://github.com/juju/juju/blob/master/apiserver/retrystrategy/retrystrategy.go#L21
>
> Basically it's an exponential backoff with a factor of 2 that starts at 5
> seconds and has a maximum of 5 minutes, so 5, 10, 20...up to 300 seconds.
>
> Iirc attempting a manual retry will reset this timer. It also never gives
> up.
>
> Cheers,
> Bogdan
> On Jun 30, 2016, at 6:52 PM, Casey Marshall 
> wrote:
>>
>> What is the intended behavior for automatic hook retries in Juju 2.0?
>>
>> Specifically, I'd like to know, as a Juju user:
>>
>> Are errors in hooks all retried with the same policy, or are some retried
>> with a different policy / strategy than others (install, for example)?
>>
>> Is there a limit to the number of times Juju will retry a hook error
>> before "giving up"?
>>
>> What kind of delay can I expect between retries?
>>
>> Thanks,
>> Casey
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: New juju in ubuntu

[Adam Collard]

Will there be a transitional release of 1.25.x that also gives us a juju1
binary to facilitate this?
On Tue, 5 Apr 2016 at 19:36, Martin Packman 
wrote:

> Some of you will be aware of the excitement over the last week getting
> Juju 2.0 into Xenial, this is an update mail so everyone knows what
> the goal is with the user experience.
>
> The challenge here is we want Juju 2.0 and all the new functionality
> to be the default on release, but not break our existing users who
> have working Juju 1.X environments and no deployment upgrade path yet.
> So, versions 1 and 2 have to be co-installable, and when upgrading to
> xenial users should get the new version without their existing working
> juju being removed.
>
> There are several ways to accomplish that, but based on feedback from
> the release team, we switched from using update-alternatives to having
> 'juju' on xenial always be 2.0, and exposing the 1.X client via a
> 'juju-1' binary wrapper. Existing scripts can either be changed to use
> the new name, or add the version-specific binaries directory
> '/var/lib/juju-1.25/bin' to the path.
>
> Because the meaning of 'juju' is changing, we want to give a
> on-first-run message about how to work with any existing environments
> the user may have. That work is covered by:
> 
> The best way to detect seems to be, when creating the new
> configuration for 2.0, if ~/.juju or JUJU_HOME is set, use the series
> to suggest ways to access or install the 1.X client.
>
> There were some other interesting points from review.
>
> The way we do plugins both leads to large binaries with a lot of
> duplication, and means the only sane way to deal with multiple juju
> versions is through path manipulation. If anyone is wants to
> distribute juju plugins, they'll need to watch out for this. See this
> bug on the binary sizes:
> 
>
> Also we've had to avoid stripping the juju binaries, which is
> otherwise standard distro practice, as it was unsupported and go 1.2
> breaks. With the switch to go 1.6 it seems like this may now work as
> expected, but needs to go through testing:
> 
>
> We also have some ongoing questions over golang packaging in the
> distro as a whole, but have demonstrated we an split out and create
> seperate golang-*-dev packages for nearly all the juju dependencies as
> needed.
>
> We hope to avoid most of the pain from this packaging process next
> cycle by putting our alpha releases into the devel disto (Y 16.10),
> rather than just adding them to our PPA. This will not need to replace
> the 2.0 version if we have compatibility concerns with early versions
> given the packaging changes from this cycle, but we will also be back
> to no-breakage mode as well.
>
> Martin
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Introducing, juju resources!

[Adam Collard]

Hi Moonstone!

On Fri, 12 Feb 2016 at 21:27 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Moonstone have been working hard on a new feature coming up in Juju 2.0
> called "Juju Resources", and we're now at a point where we can share the
> goodness and call for bugs/feedback! As noted in the video linked below,
> the feature isn't quite complete, so expect some rough edges, and for some
> of the CLI details to shift just a bit.
>

After watching the demo (thanks for sharing!) it struck me that use of the
update-status hook to demonstrate this was pointing to a missing feature
(IMHO).

Is there a hook that fires when a resource is made available? If I have an
install hook that requires a resource, I could make it transition to
blocked when that resource is missing. But when that resource is provided,
how do I know to try again?

Thanks,

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

Re: Units & resources: are units homogeneous?

[Adam Collard]

On Tue, 16 Feb 2016 at 18:40 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> Thanks, Adam.
>
> Playing devil's advocate to my own question here: why isn't this 1 charm
> broken up into separate charms that handle the different bits of the
> workflow? It sounds like you'd want to break this up into different charms
> along lines of modeled responsibility and then deploy using bundles?
>

Well we do have a few bundles too, but these are different services inside
the one charm.

There are several advantages to using this approach
1) we can fail over services without user intervention
2) when the architecture of services inside Landscape changes, there is no
user intervention required (i.e. one upgrade-charm hook to write, config
files take over from there).
3) we encapsulate the details of Landscape inside the charm, maintained by
us and don't expose implementation details to Juju users
4) when the user "juju add-unit"s (or remove-unit's) we can scale the
services that we know should be scaled, maintaining affinity and
anti-affinity rules that are properties of the software we maintain.
5) avoid some complex interdependencies when relation-changed hooks fire

... I could probably come up with some more, but that should be enough for
you to chew over :)


> Sorry if I'm over-simplifying.
>

Nah it's fine :)
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Units & resources: are units homogeneous?

[Adam Collard]

Hi Katherine,


On Tue, 16 Feb 2016 at 18:20 Katherine Cox-Buday <
katherine.cox-bu...@canonical.com> wrote:

> The team is looking closely at some of our CLI surrounding resources, and
> an interesting question came up: should units be considered homogeneous?
>
> My understanding is that it's a goal to make the management of units more
> consistent, and making the units more homogeneous would support this, but
> I'm wondering from a workload perspective if this is also true? One example
> I could think of to support the discussion is a unit being elected leader
> and thus taking a different path through it's workflow than the other
> units. When it comes to resources, maybe this means it pulls a different
> sub-set of the declared resources, or maybe doesn't pull resources at all
> (e.g. it's coordinating the rest of the units or something).
>

Yes, as a concrete example the Landscape charm[0], does just that and runs
different Landscape services on different units, using the leader to decide
what goes where. The units are heterogeneous and under the control of the
charm.

Cheers,

Adam

[0] https://jujucharms.com/landscape-server/trusty/
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Breaking news - New Juju 2.0 home^H^H^H^H data location

[Adam Collard]

Is this location still controllable through the JUJU_HOME environment
variable?

On Mon, 8 Feb 2016 at 07:16 Ian Booth  wrote:

> As advance notice, the next alpha release of Juju 2.0 (due this week) will
> use a
> new default home location. Juju will now adhere to the the XDG desktop
> standard
> and use this directory (by default):
>
> ~/.local/share/juju
>
> to store its working files (%APPDATA%/Juju on Windows). This is partly to
> allow
> Juju 2.0 to be installed alongside 1.x.
>
> Very, very soon, the need for an environments.yaml file will be no more,
> meaning
> there will be no need for the user to edit any files in that directory. As
> a
> sneak peak of what is coming, you will be able to, out of the box:
>
> $ juju bootstrap mycontroller aws/us-west-2
>
> Note that there's no need to "$ juju init" or edit any environment.yaml to
> use
> the public clouds and regions supported by Juju. Adding support for new
> regions
> or cloud information is a simple matter of running "$juju update-clouds".
> There's more to come, but you get the idea.
>
> Anyway, the point of the above is to say the location of the home/data
> directory
> doesn't really matter as there will be no need to poke around inside it.
>
> As an interim measure, if you run off master, just:
>
> mkdir ~/.local/share/juju
> cp -r ~/.juju/* ~/.local/share/juju
>
> if you want to use existing models with the latest build from source.
>
>
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Making logging to MongoDB the default

[Adam Collard]

On Thu, 22 Oct 2015 at 10:39 roger peppe  wrote:

> I have one objection to the debug-log command - it doesn't
> appear to be possible to get the log up until the current time
> without blocking to wait for more messages when it gets
> to the end. So it's not quite a substitute because I can't easily
> grep the log without interrupting the grep command.
>

FWIW this is
https://bugs.launchpad.net/juju-core/+bug/1390585
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Doing chained diffs w/ Reviewboard

[Adam Collard]

On 18 September 2014 10:49, John Meinel j...@arbash-meinel.com wrote:

 Has anyone succeeded in getting this to work?

 The steps I tried to do were:

  git co master
  git pull upstream master
  git co base-branch
  git diff master...  base.diff
  git co dependent-branch
  git diff master...  dependent.diff
  git merge-base master HEAD  remember-this-rev

 And then put the dependent.diff into the Diff: *, and then the
 base.diff into Parent Diff: and then 'remember-this-rev' into the Base
 Commit ID.

 I also tried putting git merge-base master base-branch as the Base
 Commit ID.


This makes me think you're using the UI to do this.

Let me repeat my Public Safety Announcement: Do NOT use ReviewBoard's UI
for uploading diffs. Please for $deity's sake use rbt post.

https://www.reviewboard.org/docs/rbtools/0.6/rbt/commands/post/#distributed-version-control-systems
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju 1.17.5 is released

[Adam Collard]

On 19 March 2014 13:22, John Meinel j...@arbash-meinel.com wrote:

 As of right now (2014-05-19 11:20 UTC) streams.canonical.com no longer
 lists 1.17.[1-5] as available. At least if I go here:

 http://streams.canonical.com/juju/streams/v1/com.ubuntu.juju:released:tools.json
 vs going here:

 http://juju-dist.s3.amazonaws.com/tools/streams/v1/com.ubuntu.juju:released:tools.json

 The latter one shows 1.17.0,.1,.2,.3,.4,.5 as all available, but the
 former only lists:
   1.17.0-precise-amd64
 Though if I go to the actual tarballs, I see them on streams.canonical.com
  http://streams.canonical.com/juju/tools/releases/


I used Juju 1.17.5 today with tools being downloaded from
streams.canonical.com without issue (MAAS provider).

The URL you're accessing is, I suspect, wrong.

If we look here:
http://streams.canonical.com/juju/tools/streams/v1/com.ubuntu.juju:released:tools.jsonthen
1.17.5 is listed.

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