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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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",
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
+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,
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
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
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
rusty
> > Charm: cs:trusty/mysql
> >
> > Ok:
> >
> > Series: trusty
> > Charm: ./mysql
> >
> >
> > Case 2
> > --
> >
> > Ok:
> >
> > Series: trusty
> > Charm: cs:mysql
> >
> > Series: trusty
> > Cha
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
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
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
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
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
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
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
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
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
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
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
+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 <
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
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,
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
>
> 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
+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?
> >
/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
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
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
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
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: "
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
>>
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
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
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
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
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
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:
>
/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
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
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
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
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
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
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
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:
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
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
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
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
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
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
>
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
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
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.
+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"
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
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
:
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
&
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
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
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:
>
>
>
>
>
>
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
76 matches
Mail list logo