Re: Juju 2.4.0 has been released

: https://docs.jujucharms.com/2.4/en/models-upgrade Start with the controller and you should be good to go. On Tue, Jul 3, 2018 at 7:34 AM Rick Harding wrote: > On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk < > bogdan.kowalc...@canonical.com> wrote: > >> Thanks Vinodhin &

Re: Juju 2.4.0 has been released

On Tue, Jul 3, 2018 at 7:11 AM Bogdan Kowalczyk < bogdan.kowalc...@canonical.com> wrote: > Thanks Vinodhin > > I just installed juju from snap and wanted to test couple of deployments. > > Should the controller version be 2.4.0 as well or are we keeping 2.3.7? > Is this on an existing

Re: Juju 2.4-rc2 has been released

I want to make sure it's clear that this is the last exected RC release. If no issues are found in testing from the community we plan on a final release next week. Please give it a spin attempt to crush it for all your worth! Thanks! On Mon, Jun 18, 2018 at 6:36 PM Chris Lee wrote: > > > > > >

Re: adding nics to a vm in vmware built by juju deploy

I'm not familiar if there's any way to unlock/force through VMWare but Juju doesn't currently support the idea of adding nics to running instances at this moment. It's something we're definitely looking for the future as clouds do support things like hot plugging nics. It might be worth a test to

Re: Juju 2.4-rc1 Released

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

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

https://github.com/juju/charmstore/blob/v5-unstable/docs/API.md is the docs for the API to the charmstore itself. As Adam notes, you can pull down any file and there's manifest call that lists out the files in the charm. From there you could probably check if the charm has a layers.yaml and if so

Re: Juju 2.3.0 is here!

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

Re: Charm snap is now strictly confined

+1 awesome work folks. On Fri, Sep 8, 2017 at 2:49 PM Tim Van Steenburgh < tim.van.steenbu...@canonical.com> wrote: > > > On Fri, Sep 8, 2017 at 2:44 PM, Tom Barber wrote: > >> good effort devs! >> > > +1, thanks Cory. > > >> >> On 8 Sep 2017 7:42 pm, "Cory Johns"

collecting tips, how-tos, tools used in troubleshooting Juju

I'm working to build out the troubleshooting section of the Juju documentation. [1] I'd like to collate common issues, tips, scripts, and tools folks have buried in wikis, google docs, or their brains. I'd like to ask you send anything you've got, as raw an unproofed as it lives today, my way.

Re: A new release of Juju, 2.2-beta1 and conjure-up are here!

This is awesome Adam. Testing and bugs filing. Thanks for the work on this. On Tue, Mar 28, 2017 at 6:56 AM Adam Stokes wrote: > conjure-up was merged into hombrew last night, please give the macOS > version a try and let us know if there are any issues: > > brew

Re: ssh keys

This is definitely on the todo list. It's completely correct that users should be able to manage their own keys. On Wed, Mar 8, 2017 at 11:01 AM James Beedy wrote: > I'm quickly finding myself maintaining users ssh keys. How do people feel > about making ssh keys bound to

Re: Juju 2.1-beta5 is here

reenode.net]+1.281.736.5150 <(281)%20736-5150> > narindergupta2007[skype] > > Ubuntu- Linux for human beings | www.ubuntu.com | www.canonical.com > > > On Sat, Feb 4, 2017 at 9:20 AM, Rick Harding <rick.hard...@canonical.com> > wrote: >

Re: Juju 2.1-beta5 is here

Narinder, can you share the output of juju status --format=yaml and juju show-machine 0 On Sat, Feb 4, 2017, 5:15 AM Narinder Gupta wrote: > Hi Nicholas, > I am finding issues when do the deployment. Bundle i used to deploy with > juju 2.1-beta4 does not get

Re: lxd and constraints

In the end, you say you want an instance with 2gb of ram and if the cloud has an instance with that exact limit it is in fact an exact limit. The key things here is the clouds don't have infinite malleable instance types like containers (this works for kvm and for lxd). So I'm not sure the

Re: A new development release of Juju, 2.1-beta4, is here!

You will notice this is beta4 vs the rc1 we had been working toward. Part of 2.1 is an improvement to juju container networking that corrects issues that many users are facing. This updates Juju to only create bridges on a host machine only when a container is placed on the host and only for the

Re: Juju Wikipedia Needs Update

Thanks for the heads up. I'll take a look at it. I've wanted to write for wikipedia sometime. On Tue, Jan 3, 2017 at 12:55 PM James Beedy wrote: > Wikipedia entry for Juju needs update > https://en.m.wikipedia.org/wiki/Juju_(software) > > -- > Juju-dev mailing list >

charmv6-unstable...long live charmv6?

I went to the GH repo for /juju/charm and noticed that it was missing code. After too long a time I realized I was looking at the v5 branch and actually we're all using v6-unstable now. With the release of 2.0 I wanted to see if we're all ready to make v6 stable and update the default branch for

Re: Juju Show #2 Wed Dec 14th

in Juju 2.1. With the holidays we'll be having our next Juju Show on January 4th and the one after that will be the 18th. We'll have links and announcements out after folks get back from the holidays. On Tue, Dec 13, 2016 at 3:47 PM Rick Harding <rick.hard...@canonical.com> wrote: > Com

Juju Show #2 Wed Dec 14th

Come join us as we host the next Juju Show live stream tomorrow. We'll be going over the latest in community news, demoing the new developments in tools for charming, and getting a demonstration of the new model migration feature coming in Juju 2.1. When: Nov 30th, at 19:00 GMT, 2:00pm EST Where:

Re: One instance manual provider

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

Re: Deployment Oversight

That's very true on the items that are different. I wonder if we could work with the CPC team and note the things that are assumed promises when using cloud images so that it'd be easy to build a "patch" for manually provisioned machines. If we know specific packages or configuration is there on

Re: Bootstrap Constraints

James, can you provider more detailed info on the rules of your deployment you're looking for? You mention wanting a controller away from other things on a subnet? Does this reach out true for HA nodes on that controller, workloads brought up by that controller? Are you expecting some sort of

Re: List plugins installed?

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

Re: Reviews on Github

I spoke with Alexis today about this and it's on her list to check with her folks on this. The tech board has been tasked with he decision, so please feel free to shoot a copy of your opinions their way. As you say, on the one hand it's a big impact on the team, but it's also a standard developer

Re: Bootstraping Rackspace

James, what good timing. The streams with image info is just going through getting setup. https://bugs.launchpad.net/juju/+bug/1625243 It took a bit for the images for trusty/xenial to get setup and the team's working to make it all work out of the box. We had demo streams up for testing and

Re: Reviews on Github

I think that the issue is that someone has to maintain the RB and the cost/time spent on that does not seem commensurate with the bonus features in my experience. On Wed, Sep 14, 2016 at 6:13 PM Ian Booth wrote: > One thing review board does better is use gutter

Re: Reviews on Github

/me is always +1 on reducing the number of things we have to maintain and keeping things simpler. On Wed, Sep 14, 2016 at 4:04 PM Nate Finch wrote: > In case you missed it, Github rolled out a new review process. It > basically works just like reviewboard does, where

Re: 2.0 as default on main repos?

Thanks for the feedback Jose. Merlijn also brought up a similar note and I replied on the main juju list to help explain the current pain window we're working through. Rather than copy/paste you can see it here: https://lists.ubuntu.com/archives/juju/2016-August/007679.html Please let me know if

Re: hub github helper

Thanks Nate, that's really useful info and Hub makes it easy to get at other folk's repos/forks of Juju to really collaborate, look at code that's WIP and such. I highly recommend folks take a peek and see how it can improve their collaboration and workflows. Especially when reviewing and QA'ing

Re: top-issues preventing Juju from passing

On Tue, Aug 2, 2016 at 2:28 PM Curtis Hovey-Canonical wrote: > NEW: > > Deployer: KeyError: 'uuid' connecting to environment > https://bugs.launchpad.net/juju-core/+bug/1608952 > ^ Juju or deployer needs to change > The conversation here was that the deployer had been

Re: Schema for Juju RPC messages

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

Re: Schema for Juju RPC messages

On Wed, Jul 27, 2016 at 3:18 PM Katherine Cox-Buday < katherine.cox-bu...@canonical.com> wrote: > Good point, Mark. I agree that it's difficult to make an auto-generated > client idiomatic/nice to use. What I like to do is use the schema to > auto-generate the boilerplate, and then wrap that with

Re: Juju CI is updated to test the autoload-credentials changes

Thanks Curtis, appreciate the catch and the update. On Mon, Jul 25, 2016 at 6:34 PM Curtis Hovey-Canonical wrote: > We saw the autoload-credential test failures this morning. The test is > strongly coupled to the prompt text. We updated the test to support > the new text,

Re: RFC: remove juju publish?

/me takes Tim's candy and yells "bad Tim! that was Aaron's candy!" On Sun, Jul 17, 2016 at 4:53 PM Tim Penhey <tim.pen...@canonical.com> wrote: > Was actually Aaron, I was just confirming with the list :-) > > Tim > > On 16/07/16 00:08, Rick Harding wrote

Re: Verification of proper model destroy in Azure

and decided to update the bug so whe, time to put things away for the night. On Fri, Jul 15, 2016 at 10:03 PM Rick Harding <rick.hard...@canonical.com> wrote: > I upgraded to b12 and repeated. The error is different in b12: > > juju status > ERROR unknown model: "

Re: Verification of proper model destroy in Azure

us message on the first juju status, but if you switch away and back to the dying model, you can run status up until it gives you either the b11 or b12 errors. On Fri, Jul 15, 2016 at 9:35 PM Rick Harding <rick.hard...@canonical.com> wrote: > It's a timing thing. I bootstrapped with b11 on azure

Re: Verification of proper model destroy in Azure

It's a timing thing. I bootstrapped with b11 on azure and will here's my shell history: https://pastebin.canonical.com/161089/ Note that after destroy the model was still around, I could switch of/to it, and it showed in the model list. It was somewhere in there were it finally went away. My

Re: juju beta upgrade woes

Daniel, sorry for the trouble there. As we work on things in the beta there are times when the upgrade from one beta to another might cause issues like this. You're hitting an incompatibility between the beta you were on and the latest. The only fix is to tear down and redeploy with the latest

Re: RFC: remove juju publish?

+1, good catch thanks Tim. On Fri, Jul 15, 2016 at 3:15 AM roger peppe wrote: > Yes, it should be removed. It's superceded by charm push. > > On 15 July 2016 at 04:32, Tim Penhey wrote: > > Does 'juju publish' still serve a purpose in Juju 2.0? > >

Re: authorized-keys is now optional

Thanks Andrew. On Fri, Jul 8, 2016 at 8:50 AM Andrew Wilkins <andrew.wilk...@canonical.com> wrote: > On Fri, Jul 8, 2016 at 8:30 PM Rick Harding <rick.hard...@canonical.com> > wrote: > >> Thanks Andrew. Do we hvae some hinting error messages in place for when a >>

Re: authorized-keys is now optional

Thanks Andrew. Do we hvae some hinting error messages in place for when a user attempts to juju ssh, juju run, etc and the ssh key is not set for the user that leads them to the add-ssh-key commands? Thanks Rick On Fri, Jul 8, 2016 at 12:15 AM Andrew Wilkins

Re: Automatic commit squashing

I'm going to push back on the why squash or even the "let's make it just auto clean it up". A commit to the tree should be a single, well thought out, chunk of work that another can review and process easily. Having the history of how you got there isn't valuable in my opinion. The most important

Re: Juju 2.0-beta9 ETA

Thanks Tim and I want to say that I really appreciate this change. The way the API exposed the Go-ism that all exported attributes are capitalized has been annoying for some time. I really appreciate you cleaning that up for users of the API. I think the only thing I'd change on this is that we

Re: Juju 2.0-beta9 ETA

On Sat, Jun 11, 2016 at 6:32 PM Ian Booth wrote: > We are also storing any config specified in clouds.yaml separately. These > items, > such as apt-mirror, are shared between models and are used by default if > not > specified in a hosted model. But you can override any

Re: Juju 2.0-beta9 ETA

On Sat, Jun 11, 2016 at 11:33 AM Mark Shuttleworth wrote: > On 10/06/16 19:20, Cheryl Jennings wrote: > > - Addition of a `juju unregister` command to remove references to > > controllers > > Seems we have two different cases > > * the opposite of register > * the opposite of

Re: Juju on Synnefo - which version?

Hi Stavros, definitely target Juju 2.0. It's soon to be released and great changes some fundamentals of Juju in order to make it easier for users to use. You'll be much happier following the development release for this early project of yours. I'm a bit biased, but I also think that path 2, a real

Re: admin model now called "controller" model

This was brought up via a bug before the sprint and confirmed during the sprint. Apolgoies Adam, while the bug was public, we failed to reach out as this effects conjure up. There are some other requests that the team are processing. I'd like to ask that someone from Core meet with and Prep Adam

Re: Fixing "juju help commands"

Some feedback If we have a debug command we should just show the debug commands. If we don't want users to have them ootb they should be plugins then I would think. This assumes the commands can't do anything destructive or otherwise harm a running model/etc by being run. The get is there

Re: auto-upgrading models

The key thing is that soon our path on upgrading models is via model migration. We should keep that in mind as we think of how best to lead the user to 'just do the right thing' On Mon, Apr 25, 2016, 2:38 PM Andrew Wilkins wrote: > On Sat, Apr 23, 2016 at 4:15 AM

Re: Unable to kill-controller

On Wed, Apr 6, 2016 at 8:25 PM Andrew Wilkins <andrew.wilk...@canonical.com> wrote: > On Wed, Apr 6, 2016 at 11:28 PM Rick Harding <rick.hard...@canonical.com> > wrote: > >> I strongly feel that we're avoiding and dancing around the issue. >> >> The

Re: Unable to kill-controller

I strongly feel that we're avoiding and dancing around the issue. The user should NEVER EVER have to use kill-controller. If someone types that we've failed to build Juju to the standards to which I feel we all should expect us to live up to. There is only ONE way for a user to take down a

Re: Unable to kill-controller

me, too. Kill-controller needs to work if at all >>> possible. That's the whole point. And yes, users may not hit specific >>> problems, but devs do, and that wastes our time trying to figure out how to >>> manually clean up the garbage. >>> >>> On Mon, Ap

Re: Unable to kill-controller

On Sun, Apr 3, 2016 at 6:56 PM Andrew Wilkins wrote: > In a non-beta release we would make sure that the config changes aren't > backwards incompatible. > I think this is the key thing. I think that kill-controller is an exception to this rule. I think we should

Re: Reserved actions

+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 > wrote: > >> On Mon, Mar 28, 2016 at 9:49 PM Andrew Wilkins <

Re: Openstack HA Portland Meetup Present

Thanks for the update James, glad things went so well! From our end, we appreciate the awesome first hand user feedback you're always willing to reach out and provide. Our stuff just gets better with folks like you putting it to the test day in and day out. I can't wait to get you some of the new

Re: Do we still need juju upgrade-charm --switch ... ?

The one use case that came up just this week is the ability to crosscrade from different channels of charms in the new charm publishing world. You deploy the charm from the stable path. You find a bug, and the charm author tests a fix and publishes it to the development channel. The author then

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

rusty > > Charm: cs:trusty/mysql > > > > Ok: > > > > Series: trusty > > Charm: ./mysql > > > > > > Case 2 > > -- > > > > Ok: > > > > Series: trusty > > Charm: cs:mysql > > > > Series: trusty > > Cha

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

lows users to easily switch between store and local charms during > development just by replacing "./" with "cs:" > > nova-compute: >series: xenial >charm: ./nova-compute > > nova-compute: >series: xenial >c

Re: Charm series in bundles (Was Re: Juju 2.0 and local charm deployment)

uju deploy ./charms/wordpress > > $ juju deploy ./wordpress > > > > So below deploys a local nova-compute charm in a directory co-located > with the > > bundle.yaml file. > > > > series: trusty > > services: > >nova-compute: > > charm

Re: Juju 2.0 and local charm deployment

Long term we want to have a pattern when the bundle is a directory with local charms in a directory next to the bundles.yaml file. We could not do this cleanly before the multi-series charms that are just getting out the door. I think that bundles with local charms will be suboptimal until we can

Re: Juju 2.0 and local charm deployment

No, right now charms can be multiple series but must be of the same OS. If there is truly portable code they can be wrapped as Layers to be shared among the charms, but in practice, it turns into to much ifdef style development that's difficult to debug and things like resources that are vastly

Re: admin is dead, long live $USER

If we do that we need to also make it configurable on bootstrap as an option. +1 overall On Thu, Mar 3, 2016, 4:07 PM Tim Penhey wrote: > Hi folks, > > I was thinking that with the upcoming big changes with 2.0, we should > tackle a long held issue where we have the

Re: Units & resources: are units homogeneous?

I wanted to add that the reason we're curious about this is because we're working on how Juju can help provide insights into things that could be off/wrong between units. If we expect the units to be the same, then things like warning users that a unit hasn't yet gotten a resource that the others

Re: Ubuntu in GSOC

I just want to say that I ran GSoC for my side open source project a couple of years ago and it was really awesome. I worked to setup standup meetings, a kanban board, and did things like code reviews and such. So this is something, that if folks are interested, can be really useful as far as

Re: Introducing, juju resources!

On Sun, Feb 14, 2016 at 12:50 PM Aaron Bentley wrote: > Another use case is when you want to create a charm deploys Python > code. You want it to use "resources" instead of downloading > dependencies from PyPI. > > 1. The list of resources can change over time. You

Re: Introducing, juju resources!

On Fri, Feb 12, 2016 at 11:06 PM Aaron Bentley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 2016-02-12 04:26 PM, Katherine Cox-Buday wrote: > > Moonstone have been working hard on a new feature coming up in Juju > > 2.0 called "Juju Resources",

Re: Defaulting tests internal to the package

I've got to toss another +1 for tests at both levels. One set of tests are tests against your contract to outsiders. Another is confidence that your internals are resilient. There are a ton of cases I can think of such as internal code that validates changes in state, validates various forms of

Re: Automatic retries of hooks

+1 retries are great, with backoff, when you know you're doing it because you have experience that certain api requests to clouds, or to other known failure points. Blindly just saying "if at first you don't succeed, go go go" isn't a better UX. It adds another layer of complexity in debugging,

Re: "environment" vs "model" in the code

No, there's not been a public note yet. It's work going into the 2.0 updates currently. The gist of the reason is that as support for things such as networking, storage, and workloads expand out the idea is that Juju is doing more to model your infrastructure and workloads vs an environment. So

Re: Comprehensive reviews & when to do them?

I think this is a bit of a difference in code review and feature QA. Doing something big at the end misses all the knowledge share, keeps things in silos for longer lengths of time without understanding the history, etc. Hey, maybe someone sees an obvious way to suggest doing those

Re: Juju devel 1.26-alpha2 is available for testing

On Fri, Nov 27, 2015 at 11:35 AM Mark Shuttleworth wrote: > On 27/11/15 16:21, Aaron Bentley wrote: > > It's dependent on what compiler was used to create the jujud binary. > AIUI, the Ubuntu policy is that nothing goes into a distroseries which > cannot be compiled with the

Re: Feature Request: -about-to-depart hook

Thanks for the feedback. I think this is something we should try to make some time for. I've copied Alexis and we'll see what can be done with the team. Alexis, can you put this on the list of things to investigate for future roadmap? Thanks On Tue, Nov 10, 2015 at 8:22 AM Mario Splivalo

Re: Feature Request: -about-to-depart hook

ether. (Hopefully tonight!) > > Thanks! > > > -Cheryl > On Nov 23, 2015 5:20 PM, "Rick Harding" <rick.hard...@canonical.com> > wrote: > >> Thanks for the feedback. I think this is something we should try to make >> some time for. I've copied Alexis

Re: juju and monitoring systems

Awesome to hear you're enjoying Juju Vasiliy. We don't currently have plans to build monitoring directly into Juju. We've found most places have their preferred tool for that, zabbix, munin, nagios, etc. We love that folks have built charms that allow integration of their preferred tool through

Re: Renaming of environments

That's interesting Andrew and not something considered in the conversations around this so far. With the new Azure provider and resource groups is the name of that group mutable? For Azure at least the resource groupings should help with the tags/identification though it does complicate things for

Re: juju min version feature

Then we should take up the burden to help others realize that their code will work with older versions of juju. Perhaps I am assuming, but if I am a charm author and I am wondering what my minimum version of juju is I will select the one I am currently using. Running tests and older versions are