Re: Juju 2.4-rc1 Released

[Marco Ceppi]

Eagerly awaiting remote LXD clusters :)

On Thu, Jun 7, 2018 at 10:52 AM Rick Harding 
wrote:

> Not yet. This enables bootstrapping on a clustered lxd that's also
> localhost. It's a step toward making Juju aware of the clustering APIs but
> does not yet enable the work of adding a remote lxd cloud. I showed this in
> last week's Juju show.
>
> https://youtu.be/CidoBy3iqUw
>
> On Wed, Jun 6, 2018, 6:58 PM Marco Ceppi 
> wrote:
>
>> On Wed, Jun 6, 2018, 21:33 Kelvin Liu  wrote:
>>
>>>
>>>
>>>
>>>
>>> *A new development release of Juju is here, 2.4-rc1.## New and Improved
>>> - LXD functionality has been updated to support version 3 of LXD. Better
>>> support exists for LXD installed as a Snap, defaulting to Snap-installed
>>> LXD by default if it is present. Initial support for LXD clustering is
>>> available under constrained conditions:*
>>>
>>
>> Does this mean that I can bootstrap a remote LXD cluster now?
>>
> --
>> 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: 100 contributors to juju!

[Marco Ceppi]

That page ends at #98 - but still great to see! Proud to have my 6 commits
in there

On Wed, Mar 14, 2018 at 5:45 PM Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> We're in triple digits! I'm not sure when this happened, but it's
> exciting nonetheless.
>
> https://github.com/juju/juju/graphs/contributors
>
> Thanks to all our contributors, and here's to the next 100.
>
> Nicholas
>
>
> --
> 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 2.3.0 is here!

[Marco Ceppi]

 Fan  Networking  is a  game  changer

I've got something else for the .1 release - m5 instance types dropped last
week in AWS, preparing a pull request now

On Fri, Dec 8, 2017 at 6:30 AM Rick Harding 
wrote:

> Hey, how did you know I was working on a plugin for that :P
>
> I just started poking at the problem of easier management of what version
> your controller and models are on and a helper to maas upgrade. I'll reach
> out for some testing once it's there.
>
> On Fri, Dec 8, 2017 at 7:22 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Slightly related; is there a way to update _all_ models on a controller
>> with one command?
>>
>> 2017-12-08 10:14 GMT+01:00 Andrew Wilkins :
>>
>>> On Fri, Dec 8, 2017 at 6:59 AM Nicholas Skaggs <
>>> nicholas.ska...@canonical.com> wrote:
>>>
 The Juju team are extremely pleased to announce the release of Juju
 2.3. Juju is now more versatile, more efficient, and more configurable than
 ever.

 Cross Model Relations deliver a new way of organising your software
 stack. Deploy a database in one model and connect it to an application
 running another, even one running on a different controller, or even a
 different cloud.

 For containers at scale, Juju now integrates Canonical's Fan overlay
 network system. This allows containers to map network traffic to any other
 container on the fan network without distributed databases, consensus
 protocols, or any extra overhead.

 Juju's support for bundles has made it possible to quickly deploy
 connected sets of applications for some time now, but no two use cases are
 the same. That's why we have introduced the concept of an 'overlay' bundle
 - now you can easily add your own configuration and tweaks to a bundle at
 deploy time. See below for links to more information on this and other key
 features.

>>>
>>> Hi folks,
>>>
>>> Unfortunately a critical bug [0] has escaped to the field. This bug
>>> affects existing relations in upgraded models. Models created after
>>> upgrading, or with a fresh bootstrap, or where relations are created after
>>> upgrading, will not be affected.
>>>
>>> I would not recommend upgrading from 2.x. to 2.3.0. We will be working
>>> on a fix for 2.3.1, and I expect this issue will bring that release forward
>>> much sooner. If you have already upgraded and are affected, then you can
>>> fix it by adding a document to the "statuses" collection in Mongo, as
>>> described in the bug.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> [0] https://bugs.launchpad.net/juju/+bug/1737107
>>>
>>>


 ## How can I get it?


 The best way to get your hands on this release of Juju is to install it
 via snap packages (see https://snapcraft.io/for more info on snaps).


snap install juju --classic


 Other packages are available for a variety of platforms. Please see the
 online documentation at
 https://jujucharms.com/docs/2.3/reference-install <
 https://jujucharms.com/docs/stable/reference-install>. Those
 subscribed to a snap channel should be automatically upgraded. If you’re
 using the ppa/homebrew, you should see an upgrade available.


 For highlights of this release, please see the documentation at

 https://jujucharms.com/docs/2.3/whats-new. Further details are below.



 ## New


 * Cross Model Relations:

  - see https://jujucharms.com/docs/2.3/models-cmr


 * Persistent Storage:

  - see https://jujucharms.com/docs/2.3/charms-storage


 * FAN:

  - see https://jujucharms.com/docs/2.3/charms-fan


 * Bundle deployments:

  - Changed flags for deploying bundles to existing machines

  - Bundle deploy flag --bundle-config replaced with --overlay

  - Deploying bundles now supports --dry-run

  - Deploying bundles can now target existing machines


 * Update Application Series:

  - see https://jujucharms.com/docs/2.3/howto-updateseries


 * Parallelization of the Machine Provisioner:

 - Groups of machines will now be provisioned in parallel reducing
 deployment time, especially on large bundles.


 * open_port and close_port hook tools now support ICMP

 - The open_port and close_port hook tools now support opening firewall
 access for ICMP. The syntax is:

 open_port icmp


 * LXD Storage Provider:

  - see https://jujucharms.com/docs/2.3/charms-storage#lxd-(lxd)


 ## Fixes


 * Listing of Juju models is more efficient and can now handle more
 models gracefully

 * Leadership coordinations is no longer tied to local time which avoids
 problems with clock skew and reduces overall load on the database

 

Re: Juju 2.3 beta2 is here!

[Marco Ceppi]

On Thu, Nov 2, 2017 at 12:57 AM Chris Lee  wrote:

> A new development release of Juju is here, 2.3-beta2.
>

Woop woop!


> * Autoconfiguration of FAN networking for EC2 and GCE providers
>
> When creating a model in a VPC environment on EC2 or on GCE FAN settings
> (model-config fan-config and container-networking-method) will be
> autoconfigured, and container networking will work out-of-the-box.
>

This means we can get a hyper converged Kuberentes on public cloud.
Lowering our 9 node HA deployment to just three! I plan on banging on this
for a the beta to make sure there aren't any oddities.

* Parallelization of the Machine Provisioner
>
> Provisioning of machines is now faster!  Groups of machines will now be
> provisioned in parallel reducing deployment time, especially on large
> bundles.  Please give it a try and let us know what you think.
>
> Benchmarks for time to deploy 16 machines on different clouds:
>
> AWS:
>
> juju 2.2.5 4m36s
>
> juju 2.3-beta2 3m17s
>
> LXD:
>
> juju 2.2.5 3m57s
>
> juju 2.3-beta2 2m57s
>
> Google:
>
> juju 2.2.5 5m21s
>
> juju 2.3-beta2 2m10s
>
> OpenStack:
>
> juju 2.2.5 12m40s
>
> juju 2.3-beta2 4m52s
>
>
>
Oh heck yes this is a great improvement! I don't see MAAS numbers here, but
I imagine palatalization has been implemented there too? Bare metal can be
so slow to boot sometimes ;)
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: open-port: command not found

[Marco Ceppi]

I think the use case is pretty apparent from the start of this thread, it's
opaque to a user that --all does not result in the same execution
environment as --unit or --application. It seems --all should be
disambiguated to --all-machines and possibly an --all-units feature. I
could see wanting to collect information from hook tools of all units in a
deploy, network-get for example, or other commands.

Marco

On Mon, Oct 23, 2017 at 11:20 AM Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Mon, Oct 23, 2017 at 5:12 PM Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
>> On Mon, Oct 23, 2017, 03:59 Andrew Wilkins <andrew.wilk...@canonical.com>
>> wrote:
>>
>>> On Mon, Oct 23, 2017 at 4:20 AM Akshat Jiwan Sharma <
>>> akshatji...@gmail.com> wrote:
>>>
>>>> HI,
>>>>
>>>> I'm trying to manually expose a port on a juju machine. According to this
>>>> answer
>>>> <https://askubuntu.com/questions/808176/how-to-manually-open-a-port-in-juju>
>>>> I should be able to do something like this:-
>>>>
>>>>  juju run  "open-port 443" --all
>>>>
>>>> However when I type this in my shell it throws an error
>>>>
>>>> open-port: command not found
>>>>
>>>
>>> The different between the command you're running, and the one on
>>> AskUbuntu, is that you're not passing --unit. When you pass --unit, it runs
>>> the command in the context of a unit on the machine. You must be running in
>>> the context of a unit to use "hook tools", such as open-port.
>>>
>>
>> It seems weird that `juju run` behaves differently when using --unit and
>> --all, is there a particular reason for that? I wouldn't expect the above
>> command to fail.
>>
>
> `juju run` supports running commands in either a machine or unit context.
> Only if you run within a unit context do you get access to hook tools.
> Hooks require a unit context.
>
> "--all" means "all machines", so the command runs in a machine context,
> for each machine. You could have multiple units on a machine, so we can't
> automatically choose a unit. Even if we could, what would be the use case
> for doing that? Different machines will run different applications, which
> will each have their own firewall requirements.
>
> Cheers,
> Andrew
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: open-port: command not found

[Marco Ceppi]

On Mon, Oct 23, 2017, 03:59 Andrew Wilkins 
wrote:

> On Mon, Oct 23, 2017 at 4:20 AM Akshat Jiwan Sharma 
> wrote:
>
>> HI,
>>
>> I'm trying to manually expose a port on a juju machine. According to this
>> answer
>> 
>> I should be able to do something like this:-
>>
>>  juju run  "open-port 443" --all
>>
>> However when I type this in my shell it throws an error
>>
>> open-port: command not found
>>
>
> The different between the command you're running, and the one on
> AskUbuntu, is that you're not passing --unit. When you pass --unit, it runs
> the command in the context of a unit on the machine. You must be running in
> the context of a unit to use "hook tools", such as open-port.
>

It seems weird that `juju run` behaves differently when using --unit and
--all, is there a particular reason for that? I wouldn't expect the above
command to fail.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Charm layer index now on GitHub

[Marco Ceppi]

This seems to have landed in candidate already, for those wanting to test
on something other than edge.

sudo snap refresh charm --channel candidate

On Fri, Sep 8, 2017 at 2:59 PM Tim Van Steenburgh <
tim.van.steenbu...@canonical.com> wrote:

> Fantastic, this is a great change - well done!
>
> On Fri, Sep 8, 2017 at 2:39 PM, Cory Johns 
> wrote:
>
>> Greetings,
>>
>> Today we migrated the index of base and interface layers used to build
>> charms over to the GitHub repository https://github.com/juju/layer-index.
>> Hosting the index in GitHub provides better discoverability for layers, a
>> better workflow for contributing layers, including more accountability for
>> changes, and both more flexibility and more visibility with community
>> contributions.  It also reduces our maintenance overhead and removes a
>> point of failure.
>>
>> The change should be seamless to the build process, and the existing
>> http://interfaces.juju.solutions/ site now redirects to the new repo.
>> An updated charm-build command is now in the edge channel which points
>> directly to the new index, and the old site will eventually be taken down
>> once that reaches the stable channel and some time has passed.
>>
>> I’m now happy to say, PRs welcome!
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Default Controller Type on GCE

[Marco Ceppi]

The "problem" with Google, is you can actually customize the CPU/Memory
arbitrarily per instance. So they have recommended instance types, but you
can change those properties. I'm not sure why you're getting an
n1-highcpu-4. Default bootstrap for me has been a n1-standard-1

Marco

On Tue, Jan 10, 2017 at 4:11 AM John Meinel  wrote:

> I'm not sure how we are selecting the instance type on GCE, but I do
> believe our default instance type on AWS is 2 CPUs and 2+GB of RAM.
>
> I believe our old default was something like an m3.medium, (1CPU, 3.75GB
> of ram), and we recently switched to target a t2.medium when available
> (2CPU, 4GB ram), which is credit based in that you don't get flat-out CPU,
> but if you burst a bit, you can use the full cpu speed.
>
> It certainly sounds like 2-cpu instance type in GCE matches better what
> our current expectations are. As always you can use:
>   juju bootstrap --boostrap-constraints "mem=X cpu-cores=Y"
> To set what you want for the bootstrap machine.
> John
> =:->
>
>
> On Mon, Jan 9, 2017 at 11:38 PM, Matthew Williams <
> matthew.willi...@canonical.com> wrote:
>
> Hello Juju Fans,
>
> I've recently been playing around with Juju on GCE. Google is suggesting
> that I could downgrade the instance type to save some money (attached
> screenshot)
>
> I was wondering if anyone else had something similar, and therefore, does
> this suggest our default controller instance type on GCE is bigger than we
> need?
>
> (The attached screenshot would be a saving of $47 per month)
>
> Matty
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A (Very) Minimal Charm

[Marco Ceppi]

So, I wanted to circle back around to this thread. I think a lot of good
feedback has come from this, and we're looking into making the reactive
framework leaner and better for charm authors. However, I ran a few deploy
tests and have the following results:

15 Dec 2016 00:18:53Z workload waiting waiting for machine
15 Dec 2016 00:18:53Z juju-unit allocating
15 Dec 2016 00:20:13Z workload waiting installing agent
15 Dec 2016 00:20:13Z workload waiting agent initializing
15 Dec 2016 00:20:14Z workload maintenance installing charm software
15 Dec 2016 00:20:14Z juju-unit executing   running install hook
15 Dec 2016 00:20:46Z workload active ready
15 Dec 2016 00:20:46Z juju-unit executing   running leader-elected hook
15 Dec 2016 00:20:47Z juju-unit executing   running start hook

I did this a few more times on Amazon, and the results were almost
identical. We have 80 seconds from machine requested to booted in cloud.
Less than a second for agent to initialize and 32 seconds to go from
install hook running to the workload being ready and active. While I'm sure
we can slim that down 10-15 seconds by not installing build-essentials the
largest time suck is still the cloud bringing up the instance.

I plan on doing this across all the clouds I have access to, and track in a
spreadsheet. I'll share that sheet out in a bit.

Thanks,
Marco Ceppi

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

[Marco Ceppi]

I think the actual path is to streamline reactive framework, so that Ubuntu
is the simplest example of reactive. Anyone can, as Nate demonstrated,
create a minimal charm. The feedback here is great so far and we're going
to be iterating on the framework.

Marco

On Fri, Dec 9, 2016, 9:32 AM John Meinel  wrote:

> So I went ahead and did slightly more than the minimal charm:
>  cs:~jameinel/xenial/ubuntu-lite
>
> It is essentially just installing Ubuntu, and in the Start hook, I do
> "status-set active" and report the Ubuntu version in
> "application-version-set".
>
> However, some feedback about the experience:
>
>
>1. "charm push cs:~jameinel/ubuntu-lite" fails ultimately with a TLS
>timeout error:
>ERROR cannot post archive: Post
>https://api.jujucharms.com/charmstore/v5/~jameinel/ubuntu-lite/archive?...:
>net/http: TLS handshake timeout
>I thought the point of multi-series charms is that you didn't have to
>publish to an explicit series.
>2. The result of a successful push tells you "unpublished". But the
>command to actually publish one is "charm release". Should we be using the
>verbiage of "unreleased"? Certainly there was no indication of what I
>should be doing to get the charm to a 'published' state from the CLI.
>3. ubuntu-lite does get from "pending" to "active" a fair bit faster
>than the full 'ubuntu' charm (about 1-2 minutes on my LXD provider.)
>
> John
> =:->
>
> On Thu, Dec 1, 2016 at 5:01 AM, 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.
>
> Figured this might be useful for others.
>
> -Nate
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: One instance manual provider

[Marco Ceppi]

A one machine manual provider? Might as well just `ssh ; juju
bootstrap lxd`.

On Mon, Dec 5, 2016 at 10:09 AM Nate Finch  wrote:

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

Re: Application names starting with digits

[Marco Ceppi]

On Fri, Dec 2, 2016 at 11:18 AM Nate Finch <nate.fi...@canonical.com> wrote:

> I generally assume that "hard to type" doesn't apply when you're talking
> about someone's native language.  Yes, you or I would have trouble
> typing 數據庫 (database), but to someone in China, that's probably a word they
> type all the time.  Forcing people to use an English translation for the
> name of their software is not very welcoming in this day and age.
>

Realistically, alpha-numerics are the most accessible character base today.
Unicode domains, the global index of ip addresses, just recently added
unicode support. If you have a charm in the store named 數據庫, only those
with keyboards that support those characters will work (without a lot of
time fumbling unicode libraries). My point was more this, for accessibility
I think the middle ground is:

juju deploy mysql 數據庫

You're taking a named product, which is a flat - alpha numerical - charm
name that everyone can type and access, and deploying it in Juju as a name
pertinent to you.

I'm sure this adds more complexities to core, in general, but it's the only
place I could imagine unicode working well, even then it's a bit of a
stretch weighing the pros and cons for the amount of work needed to support
unicode throughout Juju as an application name.

Marco


> On Fri, Dec 2, 2016 at 10:46 AM Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
> On Fri, Dec 2, 2016 at 10:31 AM Nate Finch <nate.fi...@canonical.com>
> wrote:
>
> One thing we *could* do to support non-english names that would not
> entirely open the door to emoji etc is to simply constrain the names to
> unicode letters and numbers.  Thus you could name something 數據庫 but
> not .
>
>
> I bothered Rick about this a while ago (half jokingly) since I own  http://
> ☁.ws <http://xn--l3h.ws> (poo cloud!) and was going to make a charm
> accompanying that name. Localized unicode characters - emoji or otherwise -
> are still a difficult UX compared to alphanumerics. It takes me 10 mins to
> find the emojis to type the damn domain in if I'm not on a phone.
>
> The only path for unicode names I could see happening, and it's a stretch,
> is if the application name can be set to a larger range of characters.
> Where you may want to name horizon deployed in your environment to
> something localized (or emoji) but the charm name should be flat and simple.
>
> On Fri, Dec 2, 2016 at 9:29 AM Mark Shuttleworth <m...@ubuntu.com> wrote:
>
> On 02/12/16 09:23, Adam Collard wrote:
>
> 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.
>
>
> This just transfers the definition of 'OK' to a different codebase.
>
> It's much better to have a simple rule that can be well documented,
> enforced the same way in store and client and snapd, and typed on any
> laptop without having to refer to the internet for assistance.
>
>
> Mark
>
> --
>
>
> 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: Application names starting with digits

[Marco Ceppi]

On Fri, Dec 2, 2016 at 10:31 AM Nate Finch  wrote:

> One thing we *could* do to support non-english names that would not
> entirely open the door to emoji etc is to simply constrain the names to
> unicode letters and numbers.  Thus you could name something 數據庫 but
> not .
>

I bothered Rick about this a while ago (half jokingly) since I own  http://
☁.ws  (poo cloud!) and was going to make a charm
accompanying that name. Localized unicode characters - emoji or otherwise -
are still a difficult UX compared to alphanumerics. It takes me 10 mins to
find the emojis to type the damn domain in if I'm not on a phone.

The only path for unicode names I could see happening, and it's a stretch,
is if the application name can be set to a larger range of characters.
Where you may want to name horizon deployed in your environment to
something localized (or emoji) but the charm name should be flat and simple.

On Fri, Dec 2, 2016 at 9:29 AM Mark Shuttleworth  wrote:
>
> On 02/12/16 09:23, Adam Collard wrote:
>
> 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.
>
>
> This just transfers the definition of 'OK' to a different codebase.
>
> It's much better to have a simple rule that can be well documented,
> enforced the same way in store and client and snapd, and typed on any
> laptop without having to refer to the internet for assistance.
>
>
> Mark
>
> --
> 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: Bundle SVG Generator updated

[Marco Ceppi]

A quick update: You can now put in a bundle URL from the charm store in
addition to a raw HTTP address to get an SVG/PNG/PDF/XML render.

Examples on the homepage have been updated, they're repeated here for your
convenience:

http://svg.juju.solutions/?bundle=openstack-telemetry
http://svg.juju.solutions/?bundle=cs:~bigdata-dev/bundle/apache-analytics-sql-15=png

Thanks,
Marco Ceppi

On Thu, Dec 1, 2016 at 9:48 AM James Donner <james.don...@canonical.com>
wrote:

> This is a godsend.
>
> It used to be incredibly difficult to gather images of Juju bundles, but
> this tool removes so many steps from the process I used to have to take.
>
> Awesome work Marco!
>
> On Wed, Nov 30, 2016 at 9:37 PM, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
> Hey everyone,
>
> A while ago I built a small web app that you could feed raw bundle.yaml
> files to and get back SVG images of the deployment like you would in the
> Charm Store or Juju GUI. This was built for things like Juju Benchmarking
> which shows an image representing the Juju deployment under test. Now it's
> become a resource for those building slides, presentations, blog posts, and
> readme files. However, SVG is not the most approachable format for some of
> these new use cases.
>
> As a result of this, I've added a raster converter as part of the
> application making bundle.yaml and transform them into transparent PNGs,
> PDF, or XML. The service will continue to default to SVG.
>
> Here's a few live examples:
>
> PNG: svg.juju.solutions/?bundle-file=https://[snip]/bundle.yaml=png
> <http://svg.juju.solutions/?bundle-file=https://raw.githubusercontent.com/marcoceppi/bundle-observable-kubernetes/8681c21a5592806ea90fc56825eee488ac0541d1/bundle.yaml=png>
> PDF: svg.juju.solutions/?bundle-file=https://[snip]/bundle.yaml=pdf
> <http://svg.juju.solutions/?bundle-file=https://raw.githubusercontent.com/marcoceppi/bundle-observable-kubernetes/8681c21a5592806ea90fc56825eee488ac0541d1/bundle.yaml=pdf>
>
> The landing page has been updated to include a quick submission form, no
> more need to hack URLs manually. https://svg.juju.solutions
>
> Finally, this is an open source project with an accompanying charm:
>
> * https://github.com/marcoceppi/svg.juju.solutions
> * https://github.com/marcoceppi/layer-charmsvg
> * https://jujucharms.com/u/marcoceppi/charm-svg
>
> The site is, of course, deployed and managed by Juju.
>
> Thanks,
> Marco Ceppi
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: A (Very) Minimal Charm

[Marco Ceppi]

On Thu, Dec 1, 2016 at 8:28 AM Free Ekanayaka <free.ekanay...@canonical.com>
wrote:

> On 1 December 2016 at 13: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:
>
>
> 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".
>
>
> 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.
>
>
> Yeah, and I think this is a good thing.
>
>
> Honestly, a handful of cached wheelhouses and some apt packages don't
> strike me as bloat
>
>
> No it's not per-se. However I think this highlights a more general issue
> with the current implementation of the reactive stack. It's not only the
> ubuntu charm that has slowed done, it's any reactive-based charm, because
> the steps required to "setup" reactive take longer than they used to.
>

The problem we're hitting with wheelhouses is exactly the one that snaps
aim to solve:

- apt packages are not cross distro, and we have reactive centos charms
- apt packages lag a bit meaning we can't get consistent features even
between trusty and xenial, let alone xenial and tip

I see a couple of (possibly alternative) ways to improve the situation:
>
> 1) Make sure the dependencies of the base reactive layer are packaged,
> that should be much faster than pip install, and fall back to pip only for
> what's not there (i.e. dependencies added by the consumers of the base
> layer). Also, package the base layer itself.
>

I'm very keen on a development in the snap world, where an unconfined
"classic" style package would be available. This means we could snap up all
the dependencies of the basic layer for every architecture and skip the
setup phase for reactive. I think this is probably our best bet going
forward.


> 2) Add support for images, so when you deploy some vanilla charm there's
> an associated "pre-built" image that will be very fast. I guess this is in
> the juju road map anyways.
>

Sure, a build step is an interesting one, but it still incurs the same wait
for a setup, you just don't feel it as much.


> We always need to keep in mind that this experience will be compared with
> things like Kubernetes and Docker, and speed-y deployments really unlock
> velocity when iterating on charm development (think for instance running
> integration tests).
>

Speed is just one facet of the experience, though an important one. For the
speed of Kubernetes we win, hands down: 10 mins to deploy a full k8s
cluster (with Juju) is only really outpaced by SAAS. I know that's not the
point you were making, but it's the true speed comparison of what we're
doing.

That being said, we're very keen on making charm development, and
deployment, faster. Reactive 1.0 was a first leap in that direction, as we
round off work in 2.0 and leveraging other technologies like unconfined
snaps, we can start to speed up the bootstrap process of reactive charms.

I'll file bugs to track these items

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

[Marco Ceppi]

On Thu, Dec 1, 2016 at 5:00 AM Adam Collard 
wrote:

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

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


> 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?
How does it not achieve it's goal of providing a relatively blank Ubuntu
machine? What are people using the Ubuntu charm for?

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

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

Bundle SVG Generator updated

[Marco Ceppi]

Hey everyone,

A while ago I built a small web app that you could feed raw bundle.yaml
files to and get back SVG images of the deployment like you would in the
Charm Store or Juju GUI. This was built for things like Juju Benchmarking
which shows an image representing the Juju deployment under test. Now it's
become a resource for those building slides, presentations, blog posts, and
readme files. However, SVG is not the most approachable format for some of
these new use cases.

As a result of this, I've added a raster converter as part of the
application making bundle.yaml and transform them into transparent PNGs,
PDF, or XML. The service will continue to default to SVG.

Here's a few live examples:

PNG: svg.juju.solutions/?bundle-file=https://[snip]/bundle.yaml=png
<http://svg.juju.solutions/?bundle-file=https://raw.githubusercontent.com/marcoceppi/bundle-observable-kubernetes/8681c21a5592806ea90fc56825eee488ac0541d1/bundle.yaml=png>
PDF: svg.juju.solutions/?bundle-file=https://[snip]/bundle.yaml=pdf
<http://svg.juju.solutions/?bundle-file=https://raw.githubusercontent.com/marcoceppi/bundle-observable-kubernetes/8681c21a5592806ea90fc56825eee488ac0541d1/bundle.yaml=pdf>

The landing page has been updated to include a quick submission form, no
more need to hack URLs manually. https://svg.juju.solutions

Finally, this is an open source project with an accompanying charm:

* https://github.com/marcoceppi/svg.juju.solutions
* https://github.com/marcoceppi/layer-charmsvg
* https://jujucharms.com/u/marcoceppi/charm-svg

The site is, of course, deployed and managed by Juju.

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

Re: [charms] Barbican + Identity Standalone - AWS

[Marco Ceppi]

Hey James!

We were looking at adding Keystone as a user management backend for
Kubernetes. This is a great step forward in making that possible, I noticed
the barbican charm in the AWS deploy was "local", are there any major
changes to the charm from ~openstack-charmers needed for it to run in AWS?

Marco

On Wed, Nov 30, 2016 at 6:50 AM Mark Shuttleworth  wrote:

>
> Might be worth sharing this on some of the OpenStack lists too, for folks
> who are interested in using Horizon this way on other substrates.
>
> Mark
>
>
> On 29/11/16 21:36, James Beedy wrote:
>
> Another great day of Juju driven successes - deploying the barbican
> standalone stack for identity mgmt and secrets mgmt. For those that don't
> know, newton horizon brings support for identity only! This means you can
> (as I am) use the openstack-dashboard for mgmt of just users, projects, and
> domains, without a full Openstack! In previous Openstack releases, if you
> hooked up horizon and you didn't have the core Openstack services
> registered in your service catalogue, horizon would throw errors and would
> be unusable. This is a huge win for those wanting object storage and
> identity mgmt only, too!
>
> AWS Barbican Stack -> http://paste.ubuntu.com/23556001/
>
> LXD Barbican Bundle (with script to help get started setting secrets in
> barbican)-> https://github.com/jamesbeedy/juju-barbican-lxd-bundle
>
> Also, here's a utility function from barbican-client layer I've been using
> to make getting secrets from barbican containers easy for charms (WIP) ->
> https://github.com/jamesbeedy/juju-layer-barbican-client/blob/master/lib/charms/layer/barbican_client.py
>
> ~james
>
>
>
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Zuul Charm

[Marco Ceppi]

Hey James,

I think this is the best way about it for the time being, discussing what
people are working on ahead of it being perfect gives everyone a chance to
see what's going on and can help focus people on getting help from others
interested!

On Wed, Nov 2, 2016 at 10:48 AM James Beedy  wrote:

> I would like to update/rewrite the Zuul charm. In lieu writing of writing
> chrams twice, I'm reaching out to see if anyone is currently working on or
> maintaining the Zuul charm already?  if you are interested in this, or
> already have something going on with Zuul please let me know.
>
> Secondly, as @marcoceppi and I lightly discussed, we should find a better
> way to introspect who is working on what so we don't end up with multiple
> people writing same charms.
>
> 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

Re: [ANN] Updated Python Juju Client

[Marco Ceppi]

This is really one of the goals. python-jujuclient, amulet, and even to an
extent deployer all poorly implement an abstraction to Juju. These will all
eventually fall away in favor of a consolidated, focused, well built Object
Oriented Python library.

Marco

On Tue, Nov 1, 2016, 4:25 PM Ryan Beisner 
wrote:

> This is good stuff.  I think keeping it focused on Juju 2.0 and later,
> completely free of legacy shims, is a good thing.  I'd love to be using
> this natively instead of the collective stack of [Amulet + Juju-deployer +
> python-jujuclient], and plan to take it for a spin.
>
> Cheers,
>
> Ryan
>
> On Tue, Nov 1, 2016 at 8:49 AM, Tim Van Steenburgh <
> tim.van.steenbu...@canonical.com> wrote:
>
> Hi everyone,
>
> We've been working on a new python client for Juju. It's still in
> development,
> but we wanted to share the first bits to illicit feedback:
> https://github.com/juju/python-libjuju
>
> Features of this library include:
>
>  * fully asynchronous - uses asyncio and async/await features of python 3.5
>  * websocket-level bindings are programmatically generated (indirectly)
> from the
>Juju golang code, ensuring full api coverage
>  * provides an OO layer which encapsulates much of the websocket api and
>provides familiar nouns and verbs (e.g. Model.deploy(),
> Application.add_unit(),
>etc.)
>
> Caveats:
>
>  * Juju 2+ only. Juju 1 support may be added in the future.
>  * Requires Python 3.5+
>  * Currently async-only. A synchronous wrapper will be provided in the
> future.
>
> If you want to try it out, take a look at the examples/ directory.
> https://github.com/juju/python-libjuju/blob/master/examples/unitrun.py is
> a
> fairly simple one that deploys a unit, runs a command on that unit, waits
> for
> and prints the results, then exits.
>
> Any and all comments, questions, and contributions are welcomed.
>
> Thanks,
>
> Tim
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: List plugins installed?

[Marco Ceppi]

Thanks have some ideas about this, I'll file a bug (blueprint?) about it. I
really care about plugins and would like to make them more robust in Juju.

Marco

On Thu, Sep 29, 2016, 6:07 PM Tim Penhey  wrote:

> If we do that, then we can make the plug-in also install a metadata file
> that explains help and usage, so you don't call the script to do that.
>
> It makes it easy to list plug-ins, because you are searching a known
> location, and not the entire path. Only show plug-ins that have the
> appropriate meta-data file.
>
> Tim
>
> On 30/09/16 10:47, Nate Finch wrote:
> > Seem alike the easiest thing to do is have a designated plugin directory
> > and have juju install  copy the binary/script there.
> > Then we're only running plugins the user has specifically asked to
> install.
> >
> > On Thu, Sep 29, 2016, 4:33 AM Stuart Bishop  > > wrote:
> >
> > On 28 September 2016 at 22:45, roger peppe
> > >
> wrote:
> >
> > On 28 September 2016 at 14:55, Rick Harding
> > >
> > wrote:
> > > This is just a miss. The original ability to see the plugins
> was a subset of
> > > the help command and didn't make our CLI spreadsheet for
> things to rework. I
> > > agree that list-plugins is the right idea here and that means
> that plugins
> > > becomes a noun in our language.
> > >
> > > What's interesting is that add/remove fall out because that
> > > installing/uninstalling. I think that show-plugin might be
> interesting to
> > > auto run the --description flag to bring it into CLI alignment
> with the new
> > > world order.
> >
> > I've voiced discomfort with this before - I don't think that we
> > should
> > arbitrarily run all executables that happen to have a "juju-"
> > prefix.
> > It's potentially dangerous (for example, note that although git
> > relies heavily
> > on plugins, it doesn't execute a plugin until you explicitly
> > name it).
> >
> > Perhaps there could be a standard way for a plugin to provide
> > metadata about itself as a data file.
> >
> >
> > It also might be time to work out how a Juju snap is going to call
> > or install plugins. I don't think the existing design is going to
> > work, and there is still time to flag it as deprecated in the
> > changelogs for 2.0 and work out the way forward for 2.1.
> >
> >
> > --
> > Stuart Bishop  > >
> > --
> > Juju-dev mailing list
> > Juju-dev@lists.ubuntu.com 
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju-dev
> >
> >
> >
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Proposal: display-name for charm metadata

[Marco Ceppi]

On Sat, Sep 24, 2016 at 11:34 AM Alex Kavanagh <alex.kavan...@canonical.com>
wrote:

> Why not allow the display of the name to be case sensitive, but all usage
> to be case insensitive?  So name is MySQL, but you can juju deploy mYSqL if
> you really wanted to.
>

I expect display names may also include unicode characters in the future,
for example

Übersoftware

Which would need name to still be defined from a store/unique id
perspective.

As for case insensitive juju deploy command, I'd consider that out of scope
of this proposal.

On Sat, Sep 24, 2016 at 2:50 PM, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
>> Hey everyone,
>>
>> I know we're rocking towards 2.0 but this is a problem I've seen voiced a
>> few times now. To date, the `name` field in charm has always been
>> [a-z-0-9_-] where you can't end with `-#`. This makes sense, simple flat
>> names that are all lowercase make it easy to do `juju deploy wordpress`
>> instead of following branding guidelines of `juju deploy WordPress`.
>>
>> However, a lot of applications have very specific branding guidelines for
>> how their display name should be represented. Just a few for example:
>>
>> - WordPress
>> - NS1
>> - MySQL
>> - PostgreSQL
>>
>> Today, in the charmstore each is rendered as:
>>
>> - Wordpress
>> - Ns1
>> - Mysql
>> - Postgresql
>>
>> Very rarely do the display names in the charm store and the intended
>> branding of application align. I'd like to propose an optional field in the
>> charm metadata, `display-name` which would allow slightly more control over
>> charmstore display:
>>
>> ```
>> name: ns1
>> display-name: NS1
>> ```
>>
>> ```
>> name: mysql
>> display-name: MySQL
>> ```
>>
>> etc. This would lead to the store and other places across the Juju Charms
>> properties which referenced the Application, instead of the deployment
>> instructions, to use the display-name field (see attached).
>>
>> Curious opinions on this, repercussions of adding metadata fields, esp
>> for older versions of Juju, and if this is worth pursing.
>>
>> --
>> Juju mailing list
>> j...@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
>
> --
> Alex Kavanagh - Software Engineer
> Cloud Dev Ops - Solutions & Product Engineering - Canonical Ltd
>
-- 
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

[Marco Ceppi]

Hi Siva,

In Juju, and especially with Cinder plugins, you can deploy multiple copies
of the Juju charm and relate them. Each application deployed is equivalent
to the scope of a SAN cluster:

juju deploy cinder
juju deploy your-charm san1
juju deploy your-charm san2

juju add-relation cinder san1
juju add-relation cinder san2

Now, you can configure each of the new applications, which are teh same
copy of the charm deployed multiple times. This will add a unique backend
per charm copy which seems to be your intended use case.

Thanks,
Marco Ceppi

On Wed, Sep 7, 2016 at 12:03 PM SivaRamaPrasad Ravipati <si...@vedams.com>
wrote:

> For example, We  have different storage arrays of same type with unique
> config parameter values.[Like San IP, SAN password, San user].
> Assume that our charm has been deployed with some configuration values and
> we added relation to cinder. Our charm will modify cinder.cong with the
> storage array driver. Next time we want to redeploy our charm to append
> only the new configuration changes. But we don't want to destroy already
> existing changes.
>
> Upto which extension,  "juju set-config" and "juju upgrade-charm" will be
> used here. Please give me a simple example if it possible.
>
> For this Scenario, Which use-case will be generally used. Please let me
> know that in a detailed manner.
>
>
> Thanks,
>
> Siva.
>
> On Wed, Sep 7, 2016 at 4:54 PM, SivaRamaPrasad Ravipati <si...@vedams.com>
> wrote:
>
>> OK. Thank you.
>>
>> I have One more Question. Knowing answer for this question is very
>> important for us.
>>
>> We have developed a JUJU Charm for configuring cinder to use one of our
>> Storage array as the backend.
>>
>>
>> So How to redeploy the Charm to add more storage arrays to configure
>> cinder without destroying/removing the current deployed charm. [For
>> example, We don't want to remove the current configured storage arrays from
>> the Cinder configuration.]
>>
>> Thanks,
>> Siva.
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Sep 7, 2016 at 3:37 PM, Adam Collard <adam.coll...@canonical.com>
>> wrote:
>>
>>> Hi Siva,
>>>
>>> On Wed, 7 Sep 2016 at 10:58 SivaRamaPrasad Ravipati <si...@vedams.com>
>>> 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
>>>> 

Re: Juju 2.0-beta17 is here!

[Marco Ceppi]

On Thu, Sep 1, 2016 at 3:10 PM Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> A new development release of Juju, 2.0-beta17, is here!
>
> ## What's new?
>
> * add-model now takes region name as an optional positional argument,
>to be consistent with bootstrap. The --region flag has been removed.
>

If I read this correctly, I can bootstrap  eastus2 controller on Azure and
create a model on westus? I was always under the impression that most
clouds don't have cross region communication.

* show-controller now includes the agent version
> * show-controllers has been removed as an alias to show-controller
>
> ## How do I get it?
>
> If you are running Ubuntu, you can get it from the juju devel ppa:
>
>  sudo add-apt-repository ppa:juju/devel
>  sudo apt update; sudo apt install juju-2.0
>
> Or install it from the snap store
>
> snap install juju --beta --devmode
>
> Windows, Centos, and OS X users can get a corresponding installer at:
>
>  https://launchpad.net/juju/+milestone/2.0-beta17
>
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe the mailing list at
> j...@lists.ubuntu.com and join us on #juju on freenode. We would love to
> hear
> your feedback and usage of juju.
>
>
> ## Anything else?
>
> You can read more information about what's in this release by viewing the
> release notes here:
>
> https://jujucharms.com/docs/devel/temp-release-notes
>
>
>
> --
> 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: kill-controller, unregister, destroy-controller

[Marco Ceppi]

On Thu, Sep 1, 2016 at 9:59 AM Mark Ramm-Christensen (Canonical.com) <
mark.ramm-christen...@canonical.com> wrote:

> I believe keeping the --destroy-all-models flag is helpful in keeping you
> from accidentally destroying a controller that is hosting important models
> for someone without thinking.
>

What happens if I destroy-controller without that flag? Do I have to go
into my cloud portal to kill those instances? Is there any way to recover
from that to get juju reconnected? If not, it's just a slower death.


> On Thu, Sep 1, 2016 at 3:40 PM, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
>> Hey everyone,
>>
>> I know we've had discussions about this over the past few months, but it
>> seems we have three commands that overlap pretty aggressively.
>>
>> Using Juju beta16, and trying to 'destroy' a controller it looks like
>> this now:
>>
>> ```
>> root@ubuntu:~# juju help destroy-controller
>> Usage: juju destroy-controller [options] 
>>
>> ...
>>
>> Details:
>> All models (initial model plus all workload/hosted) associated with the
>> controller will first need to be destroyed, either in advance, or by
>> specifying `--destroy-all-models`.
>>
>> Examples:
>> juju destroy-controller --destroy-all-models mycontroller
>>
>> See also:
>> kill-controller
>> unregister
>> ```
>>
>> When would you ever want to destroy-controller and not
>> destroy-all-models? I have to specify that flag everytime, it seems it
>> should just be the default behavior. Kill-controller seems to do what
>> destroy-controller --destroy-all-models does but more aggressively?
>>
>> Finally, unregister and destroy-controller (without --destroy-all-models)
>> does the same thing. Can we consider dropping the - very long winded almost
>> always required - flag for destroy-controller?
>>
>> Finally, there used to be a pretty good amount of feedback during
>> destroy-controller, while it was rolling text, I at least knew what was
>> happening. Now it's virtually silent. Given it runs for quite a long time,
>> can we get some form of feedback to the user back into the command?
>>
>> ```
>> root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
>> WARNING! This command will destroy the "cabs" controller.
>> This includes all machines, applications, data and other resources.
>>
>> Continue? (y/N):y
>> ERROR failed to destroy controller "cabs"
>>
>> If the controller is unusable, then you may run
>>
>> juju kill-controller
>>
>> to forcibly destroy the controller. Upon doing so, review
>> your cloud provider console for any resources that need
>> to be cleaned up.
>>
>> ERROR cannot connect to API: unable to connect to API: websocket.Dial
>> wss://10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route
>> to host
>> root@ubuntu:~# juju kill-controller cabs
>> WARNING! This command will destroy the "cabs" controller.
>> This includes all machines, applications, data and other resources.
>>
>> Continue? (y/N):y
>> Unable to open API: open connection timed out
>> Unable to connect to the API server. Destroying through provider.
>> ERROR listing resource groups: azure.ServicePrincipalToken#Refresh:
>> Failure sending request for Service Principal
>> 83d638b0-841c-4bd1-9e7c-868cae3393f4: StatusCode=0 -- Original Error: http:
>> nil Request.URL
>> root@ubuntu:~# juju bootstrap cabs azure
>> ERROR controller "cabs" already exists
>> ```
>>
>> Marco
>>
>> --
>> 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

kill-controller, unregister, destroy-controller

[Marco Ceppi]

Hey everyone,

I know we've had discussions about this over the past few months, but it
seems we have three commands that overlap pretty aggressively.

Using Juju beta16, and trying to 'destroy' a controller it looks like this
now:

```
root@ubuntu:~# juju help destroy-controller
Usage: juju destroy-controller [options] 

...

Details:
All models (initial model plus all workload/hosted) associated with the
controller will first need to be destroyed, either in advance, or by
specifying `--destroy-all-models`.

Examples:
juju destroy-controller --destroy-all-models mycontroller

See also:
kill-controller
unregister
```

When would you ever want to destroy-controller and not destroy-all-models?
I have to specify that flag everytime, it seems it should just be the
default behavior. Kill-controller seems to do what destroy-controller
--destroy-all-models does but more aggressively?

Finally, unregister and destroy-controller (without --destroy-all-models)
does the same thing. Can we consider dropping the - very long winded almost
always required - flag for destroy-controller?

Finally, there used to be a pretty good amount of feedback during
destroy-controller, while it was rolling text, I at least knew what was
happening. Now it's virtually silent. Given it runs for quite a long time,
can we get some form of feedback to the user back into the command?

```
root@ubuntu:~# juju destroy-controller --destroy-all-models cabs
WARNING! This command will destroy the "cabs" controller.
This includes all machines, applications, data and other resources.

Continue? (y/N):y
ERROR failed to destroy controller "cabs"

If the controller is unusable, then you may run

juju kill-controller

to forcibly destroy the controller. Upon doing so, review
your cloud provider console for any resources that need
to be cleaned up.

ERROR cannot connect to API: unable to connect to API: websocket.Dial wss://
10.0.0.4:17070/api: dial tcp 10.0.0.4:17070: getsockopt: no route to host
root@ubuntu:~# juju kill-controller cabs
WARNING! This command will destroy the "cabs" controller.
This includes all machines, applications, data and other resources.

Continue? (y/N):y
Unable to open API: open connection timed out
Unable to connect to the API server. Destroying through provider.
ERROR listing resource groups: azure.ServicePrincipalToken#Refresh: Failure
sending request for Service Principal 83d638b0-841c-4bd1-9e7c-868cae3393f4:
StatusCode=0 -- Original Error: http: nil Request.URL
root@ubuntu:~# juju bootstrap cabs azure
ERROR controller "cabs" already exists
```

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

Re: New jujucharms.com released -- upgrade to Juju 2.0-beta16 required

[Marco Ceppi]

What happened to the charms that were in development channel? Are they now
in edge?

Marco

On Wed, Aug 31, 2016, 9:06 AM Brad Crittenden  wrote:

> The new version of the charmstore provides support for four channels
> (edge, beta, candidate, stable). The development channel is now dropped.
>
> The versions of Juju 2.0 prior to beta 16 only recognized the development
> and stable channels.
>
> So if you are using Juju 2.0 it is necessary that you upgrade to beta 16
> now.
>
> More information is available at this blog post:
>
>
> https://blog.jujugui.org/2016/08/30/jujucharms-com-updated-with-new-channel-support/
>
> Best,
>
> Brad Crittenden
>
> --
> 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: hub github helper

[Marco Ceppi]

On Thu, Aug 4, 2016 at 6:16 AM John Meinel  wrote:

> On Aug 2, 2016 6:08 PM, "Nate Finch"  wrote:
> >
> >
> >
> > To make a PR from the CLI using hub, make sure the repo you want to PR
> against is the git remote called origin, then you can make a PR with your
> current branch by just doing
> >
> > hub pull-request
> >
> > This will open an editor to write the PR message, or you can use -m just
> like with git commit.
> >
> > -Nate
> >
>
> So my "upstream" is github.com/juju/juju but my "origin" is
> github.com/jameinel/juju. I would be concerned to set the former as an
> origin because as a lead I *do* have the ability to push to the master
> branch. I really don't want to do that by accident.
>
That is interesting, I use the same configuration: origin is me, upstream
is the parent fork. I didn't realize this was uncommon.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: juju run-action --application?

[Marco Ceppi]

Because of the ambiguous nature of actions and application. Some would
expect, as you do, to run on all units. Others would expect the leader to
coordinate that action. Furthermore, it becomes more complex as to how
results are curated. Do you get back X UUIDs one for each unit or a single
action UUID but results returned in a different fashion?

Marco

On Wed, Aug 3, 2016, 12:35 PM Matthew Williams <
matthew.willi...@canonical.com> wrote:

> Hey Folks,
>
> Is there any reason why I can't do juju run-action --application myapp (in
> the same way I can do juju run --application myapp).
>
> Thanks
>
> Matty
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: network spaces - aws support

[Marco Ceppi]

What does `juju status --format yaml` produce? it should provide more
fruitful machine errors.

Marco

On Mon, Aug 1, 2016 at 5:46 PM James Beedy  wrote:

> I'm having some issues with deploying instances to network spaces on aws.
>
> Problem: Instance errors on deploy
>
> I have successfully bootstrapped into my aws vpc with `juju bootstrap
> mycloud aws --credential mycred --config vpc-id=my-vpcid--config
> force-vpc-id='true' --upload-tools` and subsequently created a model on
> my aws controller in the vpc with `juju add-model my-new-model -credential
> mycred --config vpc-id=my-vpcid --config force-vpc-id='true'`. Following
> which, I add a network space, and then my subnet ->
> http://paste.ubuntu.com/21814798/. Ok, everything looks great so far 
> then I go and launch an instance and it all falls apart ->
> http://paste.ubuntu.com/21815678/
>
> Any insight into what is going on here would be greatly appreciated. Are
> these network spaces ops even supported on aws?
>
> ~thanks
> --
> 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: Any mentor for adding a new provider available?

[Marco Ceppi]

Hi Patrik,

This would be a great and welcomed addition. I'm adding the juju-dev
mailing list to this thread as that is where most the Juju Core development
happens.

Marco

On Mon, Aug 1, 2016, 6:23 AM Patrik Karisch 
wrote:

> Hi there,
>
> I want to add DigitalOcean as a new provider to Juju, but as I'm not Go
> experienced and new to the architecture of Juju, I'm searching for a mentor
> who gives me directions on what to do first/next and sometimes do code
> review. Anyone here? :)
>
> Cheers
> Patrik
> --
> Juju mailing list
> j...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Schema for Juju RPC messages

[Marco Ceppi]

On Wed, Jul 27, 2016 at 8:25 PM Rick Harding 
wrote:

> That being said, any API client that requires three API calls to login
>> should be beat over the head with a fail stick, but there are many cases
>> where performing some workflow might require multiple api calls. The API
>> clients should work out a single function of "doSomethingAwesome(param1,
>> pararm1)" when it's in fact performing multiple API steps because it makes
>> sense for end users, or I guess developers in this case.
>>
>
> Just to flesh this out with an obvious example that came to mind. There
> are three "addCharm"-ish API calls.
>
> addCharm [1]
> addCharmWithAuthorization [2]
> addLocalCharm [3]
>
> Writing an API client in Python or other languages I'd want to provide a
> single addCharm method that just made the right API call to Juju based on
> the arguments provided. If you provided a macaroon  from a current logged
> in session, I'd make a addCharmWithAuthorization. If you passed a local
> './' path as the charm url then I'd call out with addLocalCharm.
> There's no need to push the complexity of those three different calls to
> the end user of the API client.
>

And in python-libjuju we absolutely will hide that implementation detail
when it makes sense. For example, some non-existant psuedo code:

```
from libjuju import Model

m = Model.connect()
m.deploy(charm, name=None, config=None, macaroon=None ...)
```
Where charm is a store url or local url.

Marco
-- 
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.0-beta12 ETA

[Marco Ceppi]

Thanks!

On Wed, Jul 6, 2016 at 4:43 PM Cheryl Jennings <
cheryl.jenni...@canonical.com> wrote:

> There are no API changes planned for beta12, but if any do come up, they
> will be announced on the mailing lists.
>
> On Wed, Jul 6, 2016 at 8:59 PM, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
>> On Wed, Jul 6, 2016 at 3:51 PM Cheryl Jennings <
>> cheryl.jenni...@canonical.com> wrote:
>>
>>> Hi Everyone,
>>>
>>> Due to the US holidays and with much of the team at core and networking
>>> sprints, we will be releasing 2.0-beta12 next week.  There are currently 6
>>> assigned critical bugs [0] that need to be addressed for the next beta.
>>>
>>> This next beta is targeted to replace the out of date beta7 current
>>> uploaded into Xenial. We are moving the date out to allow developers time
>>> to fix these critical issues and make sure that beta12 is backported into
>>> Xenial allowing more users to test and beat on Juju 2.0.
>>>
>>
>> To date, does beta12 introduce any API changes?
>>
>
>
-- 
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.0-beta12 ETA

[Marco Ceppi]

On Wed, Jul 6, 2016 at 3:51 PM Cheryl Jennings <
cheryl.jenni...@canonical.com> wrote:

> Hi Everyone,
>
> Due to the US holidays and with much of the team at core and networking
> sprints, we will be releasing 2.0-beta12 next week.  There are currently 6
> assigned critical bugs [0] that need to be addressed for the next beta.
>
> This next beta is targeted to replace the out of date beta7 current
> uploaded into Xenial. We are moving the date out to allow developers time
> to fix these critical issues and make sure that beta12 is backported into
> Xenial allowing more users to test and beat on Juju 2.0.
>

To date, does beta12 introduce any API changes?
-- 
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.0-beta10 is here!

[Marco Ceppi]

On Fri, Jun 24, 2016 at 3:18 PM Curtis Hovey-Canonical 
wrote:

> A new development release of Juju, 2.0-beta10 is here!
>
> ## What's new?
>
> * Improved handling of LACP bonds
> * Continued usability enhancements
>   * Users can now use `juju relate` to add a relation between applications
>

This has got to be such a small change, but it goes a long way, love it!


>   * Additional `juju status` enhancements
> * Bundles requesting legacy ‘lxc’ type will automatically get new ‘lxd’
>   containers
>
> ## How do I get it?
>
> If you are running ubuntu, you can get it from the juju devel ppa:
>
> sudo apt-add-repository ppa:juju/devel
> sudo apt update; sudo apt install juju
>
> Windows, Centos, and OS X users can get a corresponding installer at:
>
> https://launchpad.net/juju-core/+milestone/2.0-beta10
>
> ## Feedback Appreciated!
>
> We encourage everyone to subscribe to the mailing list at
> j...@lists.ubuntu.com and join us at #juju on freenode.
> We would love to hear your feedback and about your usage of juju.
>
> ## Known issues
>
> * Juju GUI is not yet compatible with the API changes in 2.0-beta10
> * Juju deployer, and any tool using python-jujuclient are not yet
>   compatible with the API changes in recent betas.
>
> ## Anything else?
>
> You can read more information about what's in this release by viewing
> the release notes here:
>
> https://jujucharms.com/docs/devel/temp-release-notes
>
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Automatic commit squashing

[Marco Ceppi]

This is purely anecdotal, but on the ecosystem side for a lot of our
projects I've tried to psuedo-enforce the "one commit", or really, a
change/fix/feature per commit. Thereby allowing me to cherrypick for patch
releases to stable (or revert a commit) with confidence and without a lot
of hunting for the right grouping.

With the advent of squashing in github I've dropped this push and use this
unless the author has already done the logical grouping of commits, in
which case I'll merge them myself, out of github, to avoid merge messages
but retain their grouping (and potentially modify commit messages, to make
it easier to identify the PR number and the bug number it fixes).

I don't think the Juju core project can just carte blanche squash every
pull request, but I do think it's up to the code authors to put an effort
in to squashing/rewriting/managing their commits prior to submittion to
make the code's history more observable and manageable overtime. Much in
the same way you would document or comment blocks of code, commits are a
window into what this patch does, if you want to keep your history, for
reference, branching is cheap in git and you absolutely can.

Happy to share more of the latter mentioned workflow for those interested,
but otherwise just some 2¢

Marco

On Thu, Jun 16, 2016 at 10:12 AM John Meinel  wrote:

> Note that if github is squashing the commits when it lands into Master, I
> *believe* that this breaks the ancestry with your local branch. So it
> isn't a matter of "the history just isn't present in the master branch",
> but "it looks like a completely independent commit revision, and you have
> no obvious way to associate it with the branch that you have at all".
>
> It may be that git adds information to the commit ('this commit is a
> rollup of hash deadbeef") in which case the git tool could look it up.
>
> I don't know the github UI around this. If I do "git merge --squash" then
> it leaves me with an uncommitted tree with the file contents updated, and
> then I can do "git commit -m new-content"
>
> And then if I try to do:
> $ git branch -d test-branch
> error: The branch 'test-branch' is not fully merged.
> If you are sure you want to delete it, run 'git branch -D test-branch'
>
> Which indicates to me that it intentionally forgets everything about all
> of your commits, which mean *you* need to know when it got merged so that
> you can prune your branches, because the tool isn't going to track what has
> and hasn't been merged.
>
> (I don't know about other people, but because of the delays of waiting for
> reviews and merge bot bouncing things, it can take a while for something to
> actually land. I often have branches that sit for a while, and it is easy
> for me to not be 100% sure if that quick bugfix I did last week actually
> made it through to master, and having 'git branch -d ' as a short hand was
> quite useful.)
>
> Note that if we are going to go with "only 1 commit for each thing
> landed", then I do think that using github's squash feature is probably
> better than rebasing your branches. Because if we just rebase your branch,
> then you end up with 2 revisions that represent your commit (the one you
> proposed, and the merge revision), vs just having the "revision of master
> that represents your changes rebased onto master". We could 'fast forward
> when possible' but that just means there is a window where sometimes you
> rebased your branch and it landed fast enough to be only 1 commit, vs
> someone else landed a change just before you and now you have a merge
> commit. I would like us to be consistent.
>
> For people who do want to throw away history with a rebase, what's your
> feeling on whether there should be a merge commit (the change as I proposed
> it) separate from the change-as-it-landed-on-master. I mean, if you're
> getting rid of the history, the the change-as-I-proposed-it (and personally
> tested it) doesn't really matter, right? And the bot tests the
> change-as-it-landed.
>
> John
> =:->
>
>
> On Thu, Jun 16, 2016 at 4:20 PM, Ian Booth 
> wrote:
>
>>
>>
>> On 16/06/16 19:04, David Cheney wrote:
>> > Counter suggestion: the bot refuses to accept PR's that contain more
>> > than one commit, then it's up to the submitter to prepare it in any
>> > way that they feel appropriate.
>> >
>>
>> Please no. I do not want to be forced to alter my local history.
>>
>> I was hopeful that having the landing bot / github squash commits would
>> satisfy
>> those people what did not want to use git log --first-parent to present a
>> sanitised view of commits, but allow me to retain the history in my
>> branches
>> locally so I could look back on what I did and when and how (if needed).
>>
>> If the default github behaviour is not sufficient, perhaps we can add some
>> tooling in the merge bot to do the squashing prior to merging.
>>
>>
>> > On Thu, Jun 16, 2016 at 6:44 PM, roger peppe 

Re: Docker compose in Juju

[Marco Ceppi]

Hi Gayan,

I've added the general Juju list which covers more of these general topics.

So, because of the nature of LXC machines and Docker style application
containers it's hard to model that style application container in Juju in
the same way LXC machines work. However, it's quite easy to wrap something
like a Docker container, which works really well as a payload/software
delivery tool, but then you can use Juju to wrap that immutable object and
make it mutable inside of a Juju deployment.

I know there are quite a few people on the juju mailing list doing this
today, so I'll let them weigh in. In short, yes you can use Docker and
docker style application containers with Juju, but not in the same direct
way you would a LXC machine just because of the differences in function and
form.

Marco

On Tue, May 31, 2016 at 7:09 AM Gayan Gunarathne  wrote:

> Hello,
>
> Can we run docker directly with Juju? I saw Juju is supporting the LXC
> containers. I need to know whether we can spawn docker containers as the
> same.
>
> If we support this can you point me to any document?
>
> Thanks,
> Gayan
> --
> Juju-dev mailing list
> Juju-dev@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: LXD polish for xenial

[Marco Ceppi]

Thanks for the update, appreciate the consideration!

On Sat, Apr 23, 2016, 2:29 PM Alexis Bruemmer 
wrote:

> Thank you all for the great feedback on 2.0! Based on this thread and
> similar feedback the juju-core dev team has made some updates to the plan
> for lxd support in juju 2.0.  Most notably on how juju 2.0 will handle
> bundles specifying use of containers.  A summary of container support for
> juju 2.0:
>
> (1) Juju 2.0 will manage containers with LXD exclusively
> (2) On the command line the user will need to specify "--to lxd"; Juju 2.0
> will provide a clear error message if "--to lxc" is used
> (3) For bundles, Juju 2.0 will retain backwards compatibility by accepting
> the name of "lxc" and "lxd" to mean "you want a container managed by lxd",
> this will allow yaml files written for juju 1.x to be used for juju 2.0
> without requiring updates.  There will be a clear message post deployment
> that lets the user know lxd was used to deploy and manage containers and
> that the yaml file should be updated.  We will retain this backwards
> compatibility for the life of 2.0.
>
> Please also note that the current beta versions of Juju still has the
> previous lxc support (along side the lxd) to allow for proper test coverage
> of Juju 2.0 while the lxd "kinks" are worked through.  When the team is
> satisfied with test coverage of LXD on juju 2.0 we will remove the previous
> lxc implementation.
>
> Please continue to provide the team with great feedback and let us know if
> you have questions or concerns.
>
> Alexis
>
> On Thu, Apr 21, 2016 at 8:00 AM, Dean Henrichsmeyer 
> wrote:
>
>> On Tue, Apr 19, 2016 at 10:39 PM, John Meinel 
>> wrote:
>>
>>> ...
>>>
>>>
 So the plan as I understand it is that we're planning on updating
> Bundles to use the term "lxd" as the container they are requesting. And
> then updating the deployer and other tools to understand that they need to
> translate that back to LXC for Juju-1.X. The rationale is that we don't
> want to be stuck using old terminology forever, and the change is easy to
> do for bundles.
>

 My understanding was different. My understanding was that Juju 2.0 was
 to understand both lxc and lxd so old bundles work just fine with Juju 2.0.
 If you have a bundle with lxd in it, it was clearly written for 2.0 so it's
 fine that it doesn't deploy with Juju 1.x.

 Having Juju 2.0 not understand lxc seems silly given that in fact a lxd
 container is just an lxc. We seem to be splitting hairs at the cost of
 users.

 -Dean

>>>
>>> So I'd like to clarify a few points here. The first *very* key point is
>>> that the old "lxc" containers are *not* the same as "lxd" containers. It is
>>> a bit unfortunate, but I'll go through some reasons:
>>>
>>>1. Both of them do use cgroups, etc to create isolation between
>>>containers, but so does docker, and I don't think people feel docker
>>>containers are interchangable with lxc or lxd containers.
>>>2. There is a package called "lxc" that you can install, which
>>>provides the old "lxc-foo" commands (lxc-start, lxc-stop, lxc-launch, 
>>> etc)
>>>3. There is also a package called "lxdclient" which installs a local
>>>binary named "/usr/bin/lxc". That, however, does *not* interact with the
>>>former package.
>>>4. Very concretely, if you do "lxc-launch -t ubuntu-cloud" then that
>>>container will *not* show up in "lxc list". "lxc" is the lxdclient
>>>and talks to the lxd daemon to get work done. "lxc-*" commands do all of
>>>the container creation, etc, themselves.
>>>5. Going forward I'll call the old thing 'lxc1' because that is the
>>>new package for it (AIUI). And I'll enumerate some more of the 
>>> differences
>>>   1. lxc1 containers are priviledged by default and require you to
>>>   be root to create them. lxd containers are unpriviledged by default 
>>> and can
>>>   be requested by any user. The daemon itself runs as root to provide 
>>> the
>>>   functionality, but the container you get will not have a 
>>> root-elevation
>>>   escape mechanism.
>>>   2. lxc1 containers download from cloud-images to /var/cache/lxc
>>>   and populate /var/lxc/* with the rootfs and where the container files
>>>   themselves are. lxd caches images differently (/var/lib/lxd/images, 
>>> IIRC)
>>>   and supports the use of things like ZFS filesystem mounts to provide 
>>> fast
>>>   cloning to launch a new image.
>>>
>>>
>>> Juju itself *could* continue to support its existing logic to create
>>> and manage 'lxc' containers as a separate bunch of containers from 'lxd'
>>> containers. They would end up on different bridges, have different code
>>> paths for creating them (lxd we talk directly to the HTTP REST api of the
>>> daemon, 'lxc' we have to exec a command and parse the string 

Re: LXD polish for xenial

[Marco Ceppi]

On Mon, Apr 18, 2016 at 11:31 PM Nicholas Skaggs <
nicholas.ska...@canonical.com> wrote:

> On Mon, Apr 18, 2016 at 7:57 PM, Marco Ceppi <marco.ce...@canonical.com>
> wrote:
>
>> Thanks so much for spending time on this polish! It'll really help our
>> user experience shine for cost effective dev.
>>
>> On Mon, Apr 18, 2016, 2:17 PM Martin Packman <
>> martin.pack...@canonical.com> wrote:
>>
>>> When it comes to using lxd in clouds, as I understand it we've settled
>>> on retaining the 'lxc' and 'lxd' name distinction in 2.0 - which does
>>> mean bundles have to be manually changed at present to start using
>>> lxd. Most of the CI bundle testing is using real bundles out of the
>>> store, which all still say 'lxc' and therefore don't exercise the lxd
>>> container code at all.
>>>
>>
>> This bit confused me, and I realize this is late in the cycle, but I'd be
>> remiss if I didn't at least float the though.
>>
>> I would have expected juju to do the right thing for bundles. With what
>> you've stated, we now have bundles that won't deploy in 1.25 that will in
>> 2.0 and vice versa despite charms supporting both. This seems like a step
>> backwards from a UX.
>>
> Are you concerned bundles will have to be written specific to both lxc and
> lxd to support 1.25 and 2.0?  (one using lxc and the other lxd?)
>

No. I was expecting 1.25 juju deploy bundle to produce a lxc machine - for
a very brief moment in the passenger seat of a car as I wrote that I lived
in a world where juju deploy bundle existed in 1.25. Updating deployer to
translate lxd -> lxc makes sense and is easy enough to do.

My point was more, why can't juju go the extra mile to figure out that lxc
means lxd for any juju deployed bundle? While it's trivial to update the
bundles in the store, that is only a small subset of bundles that exist. It
seems just producing a message, WARN or otherwise, that juju deploy bundle
with lxc placement is being assumed as lxd and to prompt the user to update
their bundle.


>
>> What's the reasons behind this? Will there be a min-juju-version like in
>> charms? (Hopefully not)
>>
>> My expectation would have been juju 1.25 for lxc placement produces a
>> lxc-1 container and in 2.0 produces a lxd/lxc-2 container.
>>
>> Marco, I'm guessing for your expectation to work here, juju2 would have
> simply kept all of the juju-1 lxc code and supported both lxc and lxd? As
> Martin demonstrated, just swapping a bundle to use lxd instead of lxc
> fails, which I think is to be expected. Is there something else you were
> looking for here?
>

I don't want lxc code in juju 2.0 - lxd is clearly the way forward. I would
have simply expected things like charms and bundles are forward compatible.
This breaks forwards compatibility in the bundle format where deploying a
bundle with lxc placement will not work.

My expectation is that Juju would, on ingestion of the placement for the
bundle, map lxc placement to mean lxd.

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

Re: LXD polish for xenial

[Marco Ceppi]

On Mon, Apr 18, 2016, 6:12 PM Tycho Andersen 
wrote:

> Hi Martin,
>
> Thanks for looking into this.
>
> On Mon, Apr 18, 2016 at 07:17:29PM +0100, Martin Packman wrote:
> > With the LXD 2.0 release at the start of last week and the prospect of
> > some stability, I spent a good chunk of the week testing of Juju and
> > LXD.
> >
> > What CI has been doing so far this cycle has been running our standard
> > deployment tests with the lxd provider on a pre-prepared machine with
> > a known-working package set. My two goals beyond this were:
> >
> > - Validating the first install experience of the LXD provider on xenial
> > - Using lxd in place of lxc in containerised workloads across clouds
> >
> > The conclusion being at present, we don't have an experience that
> > works for either of these.
> >
> > For the lxd provider, I understand we're resigned to the user having
> > to manually configure a bridge for lxd before bootstrap can work.
> > Currently the documentation is confused as to what exactly the steps
> > are, the release notes refer to these two links:
> >
> > 
> > 
> >
> > But I think the latest advice is as committed with this change to our
> > documentation:
> >
> > 
> >
> > Note that just running dpkg-reconfigure is not enough, you have to
> > poke a service or run `lxc` afterwards or you get this error with
> > beta4:
> >
> > $ juju bootstrap --config default-series=xenial lxd-test lxd
> > ERROR cannot find network interface "lxcbr0": route ip+net: no
> > such network interface
> > ERROR invalid config: route ip+net: no such network interface
> >
> > That's probably the cause of the other confusion in the updated docs -
> > now we *do* want the bridge named lxdbr0 not lxcbr0. If the user
> > already has lxc setup in some fashion there's a different error from
> > juju telling them to run the dpkg-reconfigure command. That should
> > presumably always appear whenever there's no usable bridge.
> >
>
> Actually, you might get this error with current master too now that I
> think about it. I'll see about testing that and sending a PR which
> fixes it.
>
> > This also presents a challenge for automated testing of the lxd
> > provider in a clean environment, dpkg-reconfigure isn't the nicest
> > thing to use non-interactively, and I can't find clear reference to
> > what the exact required pieces are for the juju provider.
>
> In fact you shouldn't need anything if all you're trying to do is boot
> a container. The dpkg-reconfigure is only required if you want to
> actually have ipv4 connectivity from inside the containers, which you
> may or may not want to do.
>

Most workloads that people deploy, they'll want to connect to them. Many
people, myself included, who have had ipv6 issues on their machines, have
it disabled or do not have an ipv6 compatible connection/nat (unfortunately)

Note that you don't have to do dpkg-reconfigure, you can just edit
> /etc/default/lxd-bridge and restart lxd-bridge && lxd, see
> editLXDBridgeFile in /container/lxd/initialisation.go in the juju tree
> for an example. That may be easier for scripting purposes (you can
> probably just overwrite that file with whatever config you want if
> it's a throwaway VM).
>
> > As part of the juju 2.0 packaging for Ubuntu, we need an
> > autopackagetest that will run in a fresh xenial machine, so this
> > script is what I added to do the lxd configuration:
> >
> > <
> http://bazaar.launchpad.net/~juju-qa/ubuntu/xenial/juju/xenial-2.0-beta4/view/head:/debian/tests/setup-lxd.sh
> >
> >
> > With the additional step afterwards to call `lxc finger` that works
> > (with caveats) for me. In the autopkgtest.ubuntu.com infrastructure
> > however it does not, and it has also failed in two different ways for
> > Steve Langasek and Martin Pitt:
> >
> > "autopkgtest lxd provider tests fail for 2.0"
> > 
> >
> > So, at present we don't have confidence that the LXD provider will
> > work, even with the manual configuration step, for users installing
> > Xenial for the first time.
> >
> >
> > When it comes to using lxd in clouds, as I understand it we've settled
> > on retaining the 'lxc' and 'lxd' name distinction in 2.0 - which does
> > mean bundles have to be manually changed at present to start using
> > lxd. Most of the CI bundle testing is using real bundles out of the
> > store, which all still say 'lxc' and therefore don't exercise the lxd
> > container code at all.
> >
> > We do have the container networking test which uses 'juju add-machine
> > ... lxd:0' - and fails due to the networking setup:
> >
> > "container networking lxd 'Missing parent for bridged type nic'"
> > 
>
> Looks like this is probably related to 

Re: LXD polish for xenial

[Marco Ceppi]

Thanks so much for spending time on this polish! It'll really help our user
experience shine for cost effective dev.

On Mon, Apr 18, 2016, 2:17 PM Martin Packman 
wrote:

> When it comes to using lxd in clouds, as I understand it we've settled
> on retaining the 'lxc' and 'lxd' name distinction in 2.0 - which does
> mean bundles have to be manually changed at present to start using
> lxd. Most of the CI bundle testing is using real bundles out of the
> store, which all still say 'lxc' and therefore don't exercise the lxd
> container code at all.
>

This bit confused me, and I realize this is late in the cycle, but I'd be
remiss if I didn't at least float the though.

I would have expected juju to do the right thing for bundles. With what
you've stated, we now have bundles that won't deploy in 1.25 that will in
2.0 and vice versa despite charms supporting both. This seems like a step
backwards from a UX.

What's the reasons behind this? Will there be a min-juju-version like in
charms? (Hopefully not)

My expectation would have been juju 1.25 for lxc placement produces a lxc-1
container and in 2.0 produces a lxd/lxc-2 container.


> We do have the container networking test which uses 'juju add-machine
> ... lxd:0' - and fails due to the networking setup:
>
> "container networking lxd 'Missing parent for bridged type nic'"
> 
>
> That is probably less interesting than the default behaviour without
> the feature flag.
>
> As a separate test, I updated one of our simple bundles just to say
> 'lxd' in two places where it had 'lxc' for a service before. The
> deployment timed out after 24 minutes, where the normal test with lxc
> takes 12 minutes.
>
> The reason for that turns out to be pretty simple. Looking back at the
> lxd provider test, it hung for over 20 minutes just updating packages
> when setting up the first container:
>
> In container /var/log/apt/history.log
> Start-Date: 2016-04-15  22:11:16
> ...
> End-Date: 2016-04-15  22:33:03
>
> Unlike other providers, lxd exposes no way to use the daily images
> instead of release images, so at present any machine using lxd
> containers with juju for the first time will get the xenial beta2
> image then upgrade basically every package. This issue goes away next
> week, but gets in the way of testing before then.
>
> In a related note, the lxc container handling in juju manages images
> on the state server, but from what I see of the lxd code, each
> deployed machine will fetch images from cloud-images.ubuntu.com and
> keep a separate set of images. That makes the above problem much worse
> for any bundle with multiple machines that use containers.
>
> Finally, we'll need to update the log gathering code in CI to know how
> to look inside lxd containers. At the moment, only the machine log
> seems to be linked into the /var/log/lxd/ directory, so the cloud-init
> logs and other pieces are currently missing. It does seem we can peek
> inside using paths like:
>
>
> /var/lib/lxd/containers/juju-d9c2c426-f268-47d9-8b96-4468b3f60b51-machine-0/rootfs/var/log/apt/term.log
>
> But I'm not sure if that's behaviour we can rely on with all lxd
> configurations.
>
> 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

[ANN] charm & charm-tools 2.0!

[Marco Ceppi]

 2.1 then you're good to go! Thank you for
installing the charm command.

Finally, if your version wasn't represented above you're very special,
please email me with the precise version you have for removal instructions.

## charm-tools won't install because python-path.py

This is any issue for anyone who installed from the juju stable ppa. Make
sure the stable ppa is added, `sudo add-apt-repository ppa:juju/stable`,
issue a `sudo apt update`, then perform a `sudo apt dist-upgrade`.
python-path.py has been replaced by python-path from Xenial and is a far
superior package.

# charm-tools 2.2

We're already hard at work on the next version of charm-tools, due out in
October. You can follow along the progress:

charm-tools 2.1.3:
https://github.com/juju/charm-tools/issues?q=milestone%3A2.1.PATCH+is%3Aall+
charm-tools 2.2:
https://github.com/juju/charm-tools/issues?q=is%3Aall+milestone%3A2.NEXT+

# Support

Finally, if you have any questions, please feel free to email them to this
list, j...@lists.ubuntu.com - report issues against either
https://github.com/juju/charm-tools or
https://github.com/juju/charmstore-client ask questions in #juju on
freenode.net or on https://askubuntu.com

Thanks,
Marco Ceppi
on behalf of the Juju Charm Community Team and UI Engineering Team
-- 
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

[Marco Ceppi]

On Wed, Apr 6, 2016 at 10:07 AM Stuart Bishop 
wrote:

> On 5 April 2016 at 23:35, Martin Packman 
> wrote:
>
> > 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.
>
> How do our plugins know what version of juju is in play? Can they
> assume that the 'juju' binary found on the path is the juju that
> invoked the plugin, or is there some other way to tell using
> environment variables or such? Or will all the juju plugins just fail
> if they are invoked from the non-default juju version?
>

You can invoke `juju version` from within the plugin and parse the output.
That's what I've been doing when I need to distinguish functionality.
-- 
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

[Marco Ceppi]

On Tue, Apr 5, 2016 at 1:37 PM Martin Packman 
wrote:

> On 05/04/2016, Adam Collard  wrote:
> > Will there be a transitional release of 1.25.x that also gives us a juju1
> > binary to facilitate this?
>
> Yes, the plan entails both an update to the juju in main for the 2.0
> release and a new juju 1.25 in universe that cooperates with the
> changes.
>
> For the debian packaging nitty gritty, what we had before was:
>
> Archive:
>   juju (depends juju-core)
> juju-core (/usr/bin/juju etc)
>   juju-local (depends juju-core, juju-mongodb, lxc bits)
>   juju-local-kvm (depends juju-core, juju-mongodb, libvirt bits)
>
> Devel PPA:
>   juju2 (/usr/bin/juju2 etc)
>
> We have the following proposed:
>
> Main:
>   juju (depends juju-2.0, suggests juju-core)
> juju-2.0 (/usr/lib/juju-2.0/bin/juju, linked as /usr/bin/juju and
> wrapped as /usr/bin/juju-2.0)
>
> (The lxd provider is bundled, replacing the local packaging bits for 2.0).
>
> Universe:
>   juju-core (transitional depends juju-1.25)
>   juju-1 (depends juju-1.25)
> juju-1.25 (/usr/lib/juju-1.25/bin/juju, wrapped as /usr/bin/juju-1)
>   juju-local (depends juju-1.25, juju-mongodb, lxc bits)
>   juju-local-kvm (depends juju-1.25, juju-mongodb, libvirt bits)
>
> When upgrading, you keep your juju package and upgrade juju-core to
> the new 1.X packaging, and pick up the new 2.0 package. With a fresh
> install, you just get 2.0 unless you ask for juju-1 as well or take
> the suggests.
>

A funny side-effect of this is `juju 1` and `juju 2.0` are now valid
commands since they follow the plugin format. Which means `juju 1 2.0
status` would invoke the juju-2.0 bin and run the `juju-1` bin which would
then run the `juju-2.0` bin again before finally querying status :)
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reserved actions

[Marco Ceppi]

I've created this issue, and will make sure it lands in time for Xenial.
https://github.com/juju/charm-tools/issues/161

On Tue, Mar 29, 2016 at 1:55 AM Rick Harding <rick.hard...@canonical.com>
wrote:

> +1 to reserving the juju* space just as we do with relations and such.
>
> On Mon, Mar 28, 2016 at 10:12 PM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> On Tue, Mar 29, 2016 at 10:03 AM Marco Ceppi <marco.ce...@canonical.com>
>> wrote:
>>
>>> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins <
>>> andrew.wilk...@canonical.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> There's a code review in progress (http://reviews.vapour.ws/r/4286/)
>>>> that will introduce a predefined action, "juju-run", which is part of the
>>>> replacement for the current SSH-based juju-run.
>>>>
>>>
>>> This is interesting. What's the semantics for this? How does juju-run
>>> action work for machine level items?
>>>
>>
>> From the end-user perspective, juju run should work just the same as
>> before. There will be a machine-level worker in Juju that will initially
>> handle only juju-run actions. It's not expected that you'll use juju-run
>> actions directly, but I don't think there's anything stopping you.
>>
>> This means that "juju-run" will no longer be a valid action name for use
>>>> in a charm. This may come up again in the future, so we think it would be
>>>> prudent to reserve a namespace for additional predefined actions. The most
>>>> straightforward thing to do would be to reserve the "juju-" prefix, like we
>>>> do for relations.
>>>>
>>>
>>> This seems fine, we'll add "juju-run" as a blacklist in charm proof.
>>>
>>
>> If everyone's OK with reserving the "juju-" prefix, I think it would be
>> better to blacklist the whole namespace. Nip it in the bud.
>>
>>
>>> Any objections? Does anyone have any actions using the "juju-" prefix
>>>> already?
>>>>
>>>
>>> I don't believe so, I'l do a quick search in the charm store though to
>>> verify
>>>
>>>
>>>> Cheers,
>>>> Andrew
>>>>
>>> --
>>>> Juju-dev mailing list
>>>> Juju-dev@lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>>>
>>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Reserved actions

[Marco Ceppi]

On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins 
wrote:

> Hi,
>
> There's a code review in progress (http://reviews.vapour.ws/r/4286/) that
> will introduce a predefined action, "juju-run", which is part of the
> replacement for the current SSH-based juju-run.
>

This is interesting. What's the semantics for this? How does juju-run
action work for machine level items?

This means that "juju-run" will no longer be a valid action name for use in
> a charm. This may come up again in the future, so we think it would be
> prudent to reserve a namespace for additional predefined actions. The most
> straightforward thing to do would be to reserve the "juju-" prefix, like we
> do for relations.
>

This seems fine, we'll add "juju-run" as a blacklist in charm proof.

Any objections? Does anyone have any actions using the "juju-" prefix
> already?
>

I don't believe so, I'l do a quick search in the charm store though to
verify


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

Re: Charmers application - David Ames

[Marco Ceppi]

Well, an outstanding turnout, thank you everyone for your feedback. With
more than two +1 from existing charmers welcome thedac!

Thanks,
Marco Ceppi

On Mon, Mar 21, 2016 at 11:41 AM James Page <james.p...@canonical.com>
wrote:

> +1
>
> On Mon, 21 Mar 2016 at 15:37 Chris Glass <christopher.gl...@canonical.com>
> wrote:
>
>> Big +1 for thedac here as well.
>>
>> I'm actually surprised he's not a charmer already!
>>
>> On Sun, Mar 20, 2016 at 3:11 PM, Liam Young <liam.yo...@canonical.com>
>> wrote:
>> > tl;dr +1 for thedac
>> >
>> > I've worked on charms with David since the ol' pyjuju days. He has made
>> > numerous excellent contributions to the Openstack charms, charmhelpers
>> and
>> > charms from the wider community. He is also an excellent reviewer and
>> can be
>> > depended on to give a merge proposal a thorough dissection and offer
>> helpful
>> > suggestions.
>> >
>> > On Sat, Mar 19, 2016 at 11:38 PM, David Britton
>> > <david.brit...@canonical.com> wrote:
>> >>
>> >> Big +1 for thedac
>> >>
>> >>
>> >> On Saturday, March 19, 2016, James Beedy <jamesbe...@gmail.com> wrote:
>> >>>
>> >>> Team -
>> >>>
>> >>> David played a monumental role in resolving a handful of issues I was
>> >>> hitting my head on while trying to solidify my HA Openstack, also
>> with DVR
>> >>> issues which I was experiencing prior. The issues I was experiencing
>> were
>> >>> rather in depth and complex. David went a great deal out of his way to
>> >>> identify where the bugs were in the charms that were at the root of my
>> >>> issues, and ensured the issues I was experiencing were exploited and
>> >>> resolved in the respective charms. By doing this, I feel David has
>> >>> subsequently played a large role in solidifying the core
>> functionality of
>> >>> the charms. It is evident that David cares a great deal about the Juju
>> >>> ecosystem, producing quality artifacts, and the community in general.
>> It has
>> >>> been a pleasure working with David, and I look forward to working
>> with him
>> >>> in the future!
>> >>>
>> >>> Thanks David!
>> >>>
>> >>> ~James
>> >>>
>> >>
>> >>
>> >> --
>> >> David Britton <david.brit...@canonical.com>
>> >>
>> >>
>> >> --
>> >> Juju mailing list
>> >> j...@lists.ubuntu.com
>> >> Modify settings or unsubscribe at:
>> >> https://lists.ubuntu.com/mailman/listinfo/juju
>> >>
>> >
>> >
>> > --
>> > Juju mailing list
>> > j...@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>>
>> --
>> Juju-dev mailing list
>> Juju-dev@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>>
> --
> 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: Do we still need juju upgrade-charm --switch ... ?

[Marco Ceppi]

On Thu, Mar 10, 2016 at 10:28 PM Ian Booth  wrote:

> So we have a feature of upgrade-charm which allows you to crossgrade to a
> different charm than the one originally deployed.
>
> From the upgrade-charm help docs:
>
> The new charm's URL and revision are inferred as they would be when
> running a
> deploy command.
> Please note that --switch is dangerous, because juju only has limited
> information with which to determine compatibility; the operation will
> succeed,
> regardless of potential havoc.
>
> What is the use case for this functionality? I seemed to get the
> impression it
> was used mainly with local repos? But given local repos are going away in
> 2.0,
> do we still need it? And given the potential for users getting things
> wrong, do
> we even want to keep it regardless? Note also --switch is not allowed with
> --path which is how local charms are upgraded.
>

We use switch a lot, and customers use this as well. The primary use case
is "I have a bug in production charm that is not available upstream yet". I
expect future 2.0 uses to look like this:

charm pull 

juju upgrade-charm --switch ./ 

Another example, esp because of how the charmstore is structured now

juju deploy trusty/wordpress
# hackity hack
juju deploy --switch cs:~marcoceppi/trusty/wordpress wordpress


>
> What would folks lose if --switch were to be dropped for 2.0? Any
> objections to
> doing this?


I object. Switch should be updated to support ./local/directory/charm
instead of local:

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

filesystem type storage backend

[Marco Ceppi]

Hello,

We had a discussion earlier today about how the filesystem backend works
for the storage bits. Given the following example:

storage:
  hdfs-data:
type: filesystem
location: /srv/hdfs

Does this require the operator to add storage at deploy time? Does this
mean our charm should block until storage is added? We really want to be
able to support the /option/ or adding storage by the operator but we're
not sure how this functions. If we use that directory before the operator
attaches storage will it be mounted over or migrated?

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

Re: filesystem type storage backend

[Marco Ceppi]

This sounds very promising! Will play around with it a bit more.

On Fri, Feb 5, 2016, 7:16 PM Mark Shuttleworth <m...@ubuntu.com> wrote:

> On 05/02/16 17:47, Marco Ceppi wrote:
> > Does this require the operator to add storage at deploy time? Does this
> > mean our charm should block until storage is added? We really want to be
> > able to support the /option/ or adding storage by the operator but we're
> > not sure how this functions. If we use that directory before the operator
> > attaches storage will it be mounted over or migrated?
>
> AIUI:
>
>  * you can leave the storage unspecified and it will just write to the
> directory
>  * you cannot change the storage pool after deployment
>
> Mark
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Juju terminology change: controllers and models

[Marco Ceppi]

Very exciting to see these bits landing now! I'm looking forward to the
alpha and trying out all the commands

On Wed, Feb 3, 2016 at 12:05 AM Ian Booth  wrote:

> Yeah, there's a couple of places that need a bit of cleanup. With that
> one, I
> needed to double check existing call points before deleting, and ran out
> of time
> before needing to do the merge. But the intent is to delete it.
>
> On 03/02/16 12:53, Nate Finch wrote:
> > FYI, I noticed ServiceDeployWithNetworks still exists as a client and
> > facade method, but it's only called by tests. Maybe it should be removed?
> >
> > On Tue, Feb 2, 2016, 8:34 PM Ian Booth  wrote:
> >
> >> Hey all
> >>
> >> As has been mentioned previously in this list, for the Juju 2.0 release
> we
> >> have
> >> been working on fundamental terminology changes. In particular, we now
> talk
> >> about controllers and models instead of state servers and environments.
> >>
> >> To this end, a rather large change has landed in master and the upcoming
> >> 2.0-alpha2 release of Juju will reflect these changes. There are several
> >> things
> >> to be aware of. We have also taken the opportunity to remove a lot of
> code
> >> which
> >> existed to support older Juju clients. Needless to say, this Juju 2.0
> >> release
> >> will not support upgrading from 1.x - it works only as a clean install.
> >>
> >> Note: some of the changes will initially break the GUI and users of the
> >> Python
> >> Juju Client - work is underway to update these products for the next
> alpha3
> >> release scheduled for next week. For those wishing to continue to test
> >> Juju 2.0
> >> without the breaking changes, the alpha1 release is still available via
> >> ppa:juju/experimental. Separate communications to affected stakeholders
> >> has/will
> >> be made as part of the 2.0-alpha2 release.
> >>
> >> So, the changes are roughly broken down as follows:
> >>
> >> - CLI command name changes
> >> - facade name changes
> >> - api method and parameter name changes
> >> - facade method restructure
> >> - internal api name changes
> >> - external artifact/data changes (including on the wire changes)
> >> - deprecated and older version facades are removed
> >>
> >> 1. CLI command name changes
> >>
> >> As an obvious example, create-environment becomes create-model. We also
> >> have
> >> destroy-controller etc. This alpha2 release will also contain many of
> the
> >> other
> >> CLI changes targetted for 2.0 eg juju backup create becomes juju
> >> create-backup.
> >> Not all 2.0 CLI syntax is supported yet, but all the environment ->
> model
> >> changes are done.
> >>
> >> You will also use -m  instead of -e .
> >>
> >> The release notes will go into more detail.
> >>
> >> All user facing text now refers to model instead of environment.
> >>
> >> 2. Facade name changes
> >>
> >> If you are curious, see https://goo.gl/l4JqGd for a representative
> >> listing of
> >> all facade and method names and which ones have been changed.
> >>
> >> The main one is EnvironmentManager becomes ModelManager. These changes
> >> affect
> >> external API clients like the GUI and Python Juju client.
> >>
> >> 3. api method and parameter name changes
> >>
> >> By way of example:
> >> EnvironInfo() on the undertaker facade becomes ModelInfo().
> >> The param struct ModifyEnvironUsers becomes ModifyModelUsers etc.
> >> EnvironTag attributes become ModelTag.
> >>
> >> 4. Service facade method restructure
> >>
> >> As part of making our facades more manageable and maintainable when API
> >> changes
> >> are required, a whole bunch of service related methods are moved off the
> >> Client
> >> facade and onto the Service facade. This had already been started months
> >> ago,
> >> and there were shims in place to keep existing clients working, but now
> >> the job
> >> is finished.
> >> eg Client.AddRelation() becomes Service.AddRelation() etc.
> >>
> >> This change will break the GUI and Python Juju client.
> >>
> >> 5. Internal API name changes
> >>
> >> Things like state.AllEnvironments() becomes state.AllModels(), we now
> use
> >> names.ModelTag instead of names.EnvironTag, and many, many more.
> >>
> >> Note: the names package has not been forked into a .V2 yet (with
> EnvironTag
> >> removed) as there are dependencies to sort out. Please do not use
> >> EnvironTag
> >> anymore.
> >>
> >> 6. External artifact/data changes (including on the wire changes)
> >>
> >> There are several main examples here.
> >> On the wire, we transmit model-uuid tags rather than environment-uuid
> tags.
> >> In mongo, we store model-uuid doc fields rather than env-uuid.
> >> In agent.conf files we store Model info rather than Environment tags.
> >> In the controller blob store, we store and manage blobs for buckets
> rather
> >> than
> >> environments.
> >> The controller HTTP endpoints are /model/ >> In backups we store model tags and details, not environment.
> >>
> >> With the blobstore, we've 

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

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

[Marco Ceppi]

How do current customers, like dtag, who are very keen on having everything
goto syslog/rsyslog, going to keep that functionality going forward? Is
there an easy mechanism to get the logs out of mongodb?

All too often when I'm rummaging around in debug-hooks, I'll tail
/var/log/juju/unit-*.log to get an idea of what to expect or see what
failed. Does that workflow change with this feature?

Marco

On Thu, Oct 22, 2015, 6:04 AM Adam Collard 
wrote:

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

Re: coloring juju logs a bit

[Marco Ceppi]

ccze also works really well for colouring log output and is one less tool
we have to build/maintain. Getting some fixes to it so it better colors
juju logs would be a win I think. FWIW, I and others in eco have been using
it for a while on a variety of application outputs including juju

Marco

On Tue, Apr 28, 2015 at 4:30 PM, Horacio Duran horacio.du...@canonical.com
wrote:

 After an interesting discussion with one of my peers where things like
 bash is the devil where said, I decided to go the go way, I upgraded a
 bit a tool from our own Nate Finch to help filter and color the logs. The
 coloring is a bit crude but I have found it to be a quite useful little
 tool.
 here is the url https://github.com/natefinch/nolog
 and here is a sample of output: http://imgur.com/qRuaROh

 On Fri, Mar 6, 2015 at 2:31 PM, Horacio Duran horacio.du...@canonical.com
  wrote:

 So, for those like me, that usually end up hunting for what broke your
 tests and find themselves swimming in a sea of log output, I have added a
 bit of setup to my supercat to get some useful coloring.
 I most likely will be doing this in a more serious and less hacky (and
 more juju dev oriented) way bu in the mean time:
 create .spcrc/spcrc-juju-tests
 with the contents of: http://pastebin.ubuntu.com/10551462/
 and to get some coloring (bear in mind that if everything went well you
 will get absolutely nothing colored)
 go test github.com/juju/juju/... 21 | spc -w -t juju-tests

 the output is something like this
 http://imgur.com/TErS04p



 --
 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: Bleeding edge testers - do you want to try some new Juju Health/Status functionality?

[Marco Ceppi]

Whew, because I was about to raise some serious concern over conflating
namespaces :D

On Thu, Apr 2, 2015 at 6:47 AM, Ian Booth ian.bo...@canonical.com wrote:

 Ah, yes, of course. Typo, sorry.

 On 02/04/15 20:19, John Meinel wrote:
  ...
 
 
 
  Hook tools
  --
 
  juju-set, used to inform Juju or a charm's workload status
  eg
juju-set maintenance | waiting | blocked | active [message]
 
  juju-get, used to return the current workload status
 
 
  I'm guessing you mean status-set and status-get here, rather than
  juju-get and juju-set ?
 
  John
  =:-
 

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

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

Re: Question about the start hook

[Marco Ceppi]

Hi Tim,

Great question, sorry it took me so long to get back to you. I have an
assumption that all hooks run serially on a single unit regardless of
service group, etc. However, I want to say I've seen some kind
serialization between peers. I've cc'd the Juju core mailing list and the
regular juju mailing list to help correct and clarify these statements and
shed some light once and for all.

Finally, once it's been known, I'll be updating the author docs to detail
the execution pattern in detail.

Thanks,
Marco Ceppi


On Sat, Aug 30, 2014 at 6:31 AM, Humphrey, Timothy L (RIS-DAY) 
timothy.humph...@lexisnexis.com wrote:

 Marco,

 Do you know the answer to my question, below? Or should I re-phase it?

 Tim

 -Original Message-
 From: jorge.cas...@gmail.com [mailto:jorge.cas...@gmail.com] On Behalf Of
 Jorge O. Castro
 Sent: Friday, August 29, 2014 10:18 AM
 To: Humphrey, Timothy L (RIS-DAY); Marco Ceppi
 Subject: Re: Question about the start hook

 That's a good question! CCing in Marco, who should know.

 On Fri, Aug 29, 2014 at 10:16 AM, Humphrey, Timothy L (RIS-DAY) 
 timothy.humph...@lexisnexis.com wrote:
  Jorge,
 
  I am using juju charm to deploy to aws, an hpcc cluster, which is
 several instances that work together to complete some job.
 
  In my start hook, I'm copying files from S3 to each instance. And, once
 all files are copied to all instances, I perform an operation in my
 hpcc-cluster-relation-joined that tells the master instance that all files
 are copied to all instances.
 
  So, my question is, Do all instances complete the start hook before any
 instance begins the hpcc-cluster-relation-joined hook?
 
  Or is there a way to make this be true?
 
  Sincerely,
  Tim
 


 -
 The information contained in this e-mail message is intended only
 for the personal and confidential use of the recipient(s) named
 above. This message may be an attorney-client communication and/or
 work product and as such is privileged and confidential. If the
 reader of this message is not the intended recipient or an agent
 responsible for delivering it to the intended recipient, you are
 hereby notified that you have received this document in error and
 that any review, dissemination, distribution, or copying of this
 message is strictly prohibited. If you have received this
 communication in error, please notify us immediately by e-mail, and
 delete the original message.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: First customer pain point pull request - default-hook

[Marco Ceppi]

This might be a true problem when you don't map what event should fire what
code in the hook. The majority, if not all, of charms that currently
implement this pattern do so by either using charm-helpers or by having a
giant if/else case statement at the bottom of the hook which maps which
code should execute with each hook that has invoked the symlink'd file. I
can take a survey of current charms which use symlinks to see if any don't
fit this pattern.


On Sun, Aug 17, 2014 at 6:28 AM, John Meinel j...@arbash-meinel.com wrote:

 The main problem with having a hook that just fires instead of the others
 is that you end up firing a hook a whole bunch of times where it
 essentially does nothing because it is still waiting for some other hook
 for it to actually be ready. The something-changed proposal essentially
 colapses the 10 calls to various hooks into a single firing.

 William has thought much more about it, so I'd like him to fill in any
 details I've missed.

 John
 =:-



 On Sun, Aug 17, 2014 at 1:59 PM, Nate Finch nate.fi...@canonical.com
 wrote:

 That's an interesting document, but I feel like it doesn't really explain
 the problem it's trying to solve.

 Why does a single entry point cause a lot of boilerplate (I presume he
 means code boilerplate)? Isn't it just a switch on the name of the hook?
  What does it mean when a new hook is introduced?  Doesn't the charm
 define what hooks it has?  And wouldn't the aforementioned switch mean that
 any new hook (whatever that means) would be ignored the same way it would
 if the hook file wasn't there?

 Can someone explain to me what exactly the problem is?


 On Sun, Aug 17, 2014 at 1:30 AM, John Meinel j...@arbash-meinel.com
 wrote:

 I'd just like to point out that William has thought long and hard about
 this problem, and what semantics make the most sense (does it get called
 for any hook, does it always get called, does it only get called when the
 hook doesn't exist, etc).
 I feel like had some really good decisions on it:
 https://docs.google.com/a/canonical.com/document/d/1V5G6v6WgSoNupCYcRmkPrFKvbfTGjd4DCUZkyUIpLcs/edit#

 default-hook sounds (IMO) like it may run into problems where we do
 logic based on whether a hook exists or not. There are hooks being designed
 like leader-election and address-changed that might have side effects, and
 default-hook should (probably?) not get called for those.

 I'd just like us to make sure that we actually think about (and
 document) what hooks will fall into this, and make sure that it always
 makes sense to rebuild the world on every possible hook (which is how charm
 writers will be implementing default-hook, IMO).

 John
 =:-



 On Sat, Aug 16, 2014 at 1:02 AM, Aaron Bentley 
 aaron.bent...@canonical.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 14-08-15 04:36 PM, Nate Finch wrote:
  There's new hook in town: default-hook.  If it exists and a hook
  gets called that doesn't have a corresponding hook file,
  default-hook gets called with the name of the original hook as its
  first argument (arg[1]).
 
  That's it.

 Nice!  Thank you.

 Aaron
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJT7nVvAAoJEK84cMOcf+9h90UH/RMVabfJp4Ynkueh5XQiS6mD
 TPWwY0FVHfpAWEIbnQTQpnmkhMzSOKIFy0fkkXkEx4jSUt6I+iNYXdu8T77mA38G
 7IZ7HAi+dAzRCrGTIZHsextrs5VpxhdzFJYOxL+TN5VUWYt+U+awSPFn0MlUZfAC
 5aUuV3p3KjlHByLNT7ob3eMzR2mwylP+AS/9UgiojbUOahlff/9y83dYqkCDYzih
 C2rlwf0Wal12svu70ifggGKWcnF/eiwSm4TQjJsfMdCfw0gSg4ICgmIbWQ78OytJ
 AM4UBk1/Ue94dUm3YP+lcgAqJCC9GW5HksCFN74Qr+4xcnuqYoCJJxpU5fBOTls=
 =5YwW
 -END PGP SIGNATURE-

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



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




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


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

Re: Proposal: making apt-get upgrade optional

[Marco Ceppi]

I actually don't see a problem with removing apt-get upgrade, but what
apt-get update? It's only 20s user time according to the original post. For
stale cloud images, local provider and manual, it's just a no brained.

Marco
On Jul 1, 2014 4:04 PM, David Britton david.brit...@canonical.com wrote:

 On Tue, Jul 1, 2014 at 1:53 PM, Matt Bruzek matthew.bru...@canonical.com
 wrote:

 Hello Andrew,

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


 Agreed -- I've fixed this problem multiple times in charms by making the
 first step apt-get upgrade.  Which always seemed a bit wasteful to me. :)

 It happens more on the local provider since those images are copied from
 templates which are not rebuilt until you remove them (do lxc-ls --fancy to
 see them).  So, the templates package cache goes out of date, and your
 cloned machine also goes out of date.

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

 --
 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: MySQL charm: hook failed: config-changed

[Marco Ceppi]

Hi Daniele,

That's expected behavior with Amulet, as it caches the charm locally to do
some verification against the charms in the deployment. So it deploys from
local: rather than the charm store.

As for the dataset-size, if 80% isn't a sane value, I'll try various other
default values to make sure it deploys consistently and everytime on all
cloud providers. I'm in the process of writing tests for the MySQL charm so
we'll have better exposure of this issue sooner.

Thanks,
Marco Ceppi


On Thu, Feb 6, 2014 at 9:23 AM, Daniele Stroppa
daniele.stro...@joyent.comwrote:

 David,

 I missed that requirements, I was using the 3.5 kernel. I've updated to
 the raring kernel, and deploying mysql using 'juju deploy' with no
 additional configuration still give the same issue. Setting the
 innodb_buffer_pool_size as mentioned yesterday works fine.

 @Marco: One thing I've noticed is that when deploying mysql with juju
 deploy the charm being deployed is 'cs:precise/mysql-33', while when
 running the test the charm is 'local:precise/mysql-310' (in the .py file I
 do specify 'd.add('mysql', charm='cs:precise/mysql-33')'). Is this normal?

 Daniele


 On Wed, Feb 5, 2014 at 8:05 PM, David Cheney 
 david.che...@canonical.comwrote:

 You said earlier that you were using the local provider. Have you applied
 the raring kernel update to this machine ? This is required if you want to
 use LXC on Precise.


 On Thu, Feb 6, 2014 at 3:44 AM, Daniele Stroppa 
 daniele.stro...@joyent.com wrote:

 David,

 I'm using juju 1.16.4.1 on Ubuntu 12.04. If I just deploy mysql with no
 config changes, the issue still exists. However, if I decrease the size of
 the innodb_buffer_pool_size setting (using juju set mysql
 dataset-size='512M') as stated in
 https://bugs.launchpad.net/juju-core/+bug/1236994 it works fine.

 Daniele


 On Wed, Feb 5, 2014 at 9:30 AM, David Cheney david.che...@canonical.com
  wrote:

 https://bugs.launchpad.net/juju-core/+bug/1236994 is a dup of
 https://bugs.launchpad.net/juju-core/+bug/1247299, both of which are
 claimed to be resolved.

 Daniele, if this is still a problem with the latest development release
 of Juju please reopen one of these or open a new issue as soon as possible.


 On Wed, Feb 5, 2014 at 8:25 PM, Jorge O. Castro jo...@ubuntu.comwrote:

 On Tue, Feb 4, 2014 at 11:10 PM, David Cheney
 david.che...@canonical.com wrote:
  Looks like an apparmor issue to me.

 We've had this problem in the past with MySQL/apparmor/local provider:

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



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






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

Re: High Availability command line interface - future plans.

[Marco Ceppi]

Hi guys,

I'm glad j...@lists.ubuntu.com got accidentally looped in because I may not
have caught wind of this. I can understand both sides of the discussion,
one where we provide more magic and the users trust that it works and the
other where we leverage existing components and command structures of juju
to provide this magic.

I have to agree with Kapil's point about add-unit/remove-unit syntax for
Juju HA. Having had to teach and demonstrate juju to quite a few people
now, juju is not an easy concept to grasp. Orchestration is really
something that people are just now starting to think about in general,
never mind how to wrap their heads around the concept and then furthermore
how we envision that concept, which is distilled in our product - juju. At
the end of the day I get it, we get it, it's easy for us because we're here
building it, but for the people out there it's a whole new language. If we
start off by saying Oh, hey there, just run this ensure-ha command and
things will just be fantastic is fine, but once you open up that route
it's going to be hard to back-peddle.

We already teach Oh, your services is popular? Just `juju add-unit
service` magic will happen, units will fire, and you've scaled up. You've
added an additional available unit and you're safer than you were before.
Being able to convey the same strategy for when you want to safeguard and
make Juju's bootstrap a highly available service, the natural logic would
be to `juju add-unit`. In fact I was even asked this in a Charm School
recently, I'm paraphrasing but it was to some extent Can I juju add-unit
bootstrap.

Since the majority of people seem to believe having the ultimate goal of
adding and removing juju specific services via a unique and reserved
namespace is a great goal to have it seems not shooting for that first
would simply introduce another awkward period of time which we have this
great feature but it's going to change soon so videos, blog posts, content
we produce to promote this shear awesomeness becomes stale and out of date
just as soon as the more permanent method of HA lands. For new users
learning a language this just becomes another hurtle to overcome in order
to be an expert and one more reason to look at something else other than
Juju.

Therefore, I (who really has no major say in this, simply because I'm not
capable of helping produce a solution) believe it's best to work for the
ultimate goal now instead of having to build a stop gap just to say we have
HA.

On a final note, if namespacing does become a thing, can we *please *use a
unique character for the separation of namespace:service? A : would be
fantastic as calling something juju-db could very well be mistaken or
deployed as another service? `juju deploy some-random-thing juju-*` now we
have things sharing a special namespace that aren't actually special. (Like
juju-gui, though juju-gui is quite special and awesome, it's not juju-
core namespace special).

Thanks for all the awesome work you all do. I look forward to a solution,
whatever it may be, in the future!

Marco Ceppi


On Wed, Nov 6, 2013 at 9:22 PM, Tim Penhey tim.pen...@canonical.com wrote:

 On 07/11/13 15:00, Andrew Wilkins wrote:
  On Thu, Nov 7, 2013 at 9:23 AM, Ian Booth ian.bo...@canonical.com
  mailto:ian.bo...@canonical.com wrote:
 
  So, I haven't been involved directly in a lot of the discussion, but
  my 2c is:
 
  +1 to juju ensure-ha
 
  Users don't give a f*ck about how Juju achieves HA, they just want
  to know their
  data will survive a node outage. What Juju does under the covers to
  make that
  happen, what jobs are run on what nodes etc - that's for Juju to
  care about.
 
 
  I'm not so sure about that. I expect there'll be users who wants to know
  *exactly* how it works, because otherwise they won't feel they can trust
  it with their services. That's not to say that ensure-ha can't be
  trusted - just that some users will want to know what it's doing under
  the covers. Speculative, but based on past experience with banks,
  insurance companies, etc.

 I think if we gave no feedback at all, then yes, this would feel like
 magic.  However, I'd expect us to at least say what we are doing on the
 command line :-)

 I think ensure-ha is sufficient for a first cut, and a way to get ha on
 a running system.

 For the record, we discussed the default behaviour for ensure-ha was to
 make three nodes of manager services.  The user could override this by
 specifying -n 5 or -n 7, or some other odd number.

  Another thing to consider is that one person's HA is not the next
  person's. I may want to disperse my state servers across multiple
  regions (were that supported); you might find this costs too much in
  inter-region traffic. What happens if I have a temporary outage in one
  region - where does ensure-ha automatically spin up a new one? What
  happens when the original comes back? Each of these things are things
  people may want