Seems like we need a third state: "Leaving" - means you shouldn't use the
unit (treat it as dead), but anything required by that unit still counts as
in use and required until it's actually gone.
Gustavo - I think what William means about who connects to whom is who
initiates the connection. When
They're definitely not expected to be that slow. Can you run
juju --debug status
and put the output in pastebin.ubuntu.com and send us the link? That will
turn on verbose logging and will give us a better idea of what's going on.
On Aug 30, 2013 3:31 AM, "Peter Waller" wrote:
> Hi Marco,
>
> My
ook forward to seeing how the
> bootstrap problem is overcome, as it appears based on Andrew's first email
> they are working on resolving this.
>
> I'll provide more feedback when I'm done testing, thanks for posting about
> this!
>
>
> On Mon, Sep 9, 2
I'm pretty interested in this, actually, since I want to be able to use
juju to deploy charms to a VPS I have... but even with this change, it's
not workable, because we can't manually choose a machine to bootstrap to.
Needing an AWS machine (or similar) as machine 0 is pretty much a deal
breaker.
I would recommend not making documentation an attribute in yaml. That puts
strong pressure on writers to make their documentation extremely short. No
one will want to type out a full page of documentation into a yaml
attribute. Far better to make the documentation into a separate file, to
emphas
m1's only have one CPU, they have CPU-power 200 (2 ECU).
A simple --constraints mem=3.75G worked for me to get a m1.medium
On Wed, Oct 9, 2013 at 2:14 PM, Jorge O. Castro wrote:
> I can't seem to figure out the right combination of constraints to get
> an m1.medium.
>
> juju bootstrap --constr
I just implemented that tonight, pending code review. :)
On Oct 9, 2013 4:59 PM, "Mark Shuttleworth" wrote:
>
> We should really allow passing substrate-specific constraints like
> instance types. No need for the voodoo in juju :)
>
> On 09/10/13 20:16, Kapil Thangavelu wrote:
>
> Unfortunately
ing, but would be good to keep in mind some of the
>> points raised (e.g. scripts that use these provider-specific
>> constraints shouldn't just explode when running elsewhere).
>>
>> On Wed, Oct 9, 2013 at 9:24 PM, Nate Finch
>> wrote:
>> > I just impleme
Certainly, erroring out when you specify an instance type that doesn't
exist for this endpoint seems like a good idea.
I also like your second idea, which is basically just creating an alias for
a list of constraints. I think that feature would be very handy if it was
handled in a way that was ea
Another way to do this would be the aforementioned aliases, just allow one
alias per site. So you could say
ec2:small "type=m1.small"
canonistack:small "mem=2G cpu-cores=1"
then you could do
juju deploy wordpress --constraints alias=small
and it would do the right thing whether it deployed to
I honestly prefer it to be explicit rather than implicit. It's a lot more
obvious when you see "type: manual", instead of having to notice there's no
type specified. It also makes it harder to do the wrong thing, since you
can't accidentally delete the line and silently change the environment to
The answer to "how does the user know how to X?" is the same as it always
has been. Documentation. Now, that's not to say that we still don't need
to do some work to make it intuitive... but I think that for something that
is complicated like HA, leaning on documentation a little more is ok.
Mor
et me get on with my
life. That's kind of the whole point of Juju, right?
On Wed, Nov 6, 2013 at 2:56 PM, Nate Finch wrote:
> The answer to "how does the user know how to X?" is the same as it always
> has been. Documentation. Now, that's not to say that we still don
I wonder if anyone has written an ssh client for go...
On Dec 3, 2013 6:10 PM, "David Cheney" wrote:
> I *think* the putty cli command is something like pssh, we can look it
> up. I think this is pretty easy to attempt as we can detect when the
> user is running windows and use an alternative co
system sounds
> like a major headache.
>
> I think for the windows cli the best experience would be to fire off
> putty.exe, so the user has all their normal putty customization
> necessary and doesn't have to use ssh though the crippled win32
> console.
>
> Cheers
>
>
That seems pretty valid, and with a decent error message when we can't find
it, it should be pretty easy for the user to fix (could we give a link the
website, or is that not kosher?)
On Dec 3, 2013 6:56 PM, "David Cheney" wrote:
> On Wed, Dec 4, 2013 at 10:50 AM, Nate Finch
+1
Markdown is great. It's basically the only way to write HTML that is
actually legible outside of a browser (like in diffs, code reviews, as
you're actually writing it, etc).
On Fri, Mar 21, 2014 at 1:47 PM, Marco Ceppi wrote:
> Hi everyone,
>
> I'm spreading this email out across the juju-c
I heard one of the mirrors for the apt packages was having problems today,
with people getting the same sort of error. You might want to retry, it
should have been fixed by now.
On Apr 21, 2014 6:19 PM, "Martyn Cross" wrote:
> About an hour ago I managed to get ssh going to it, for some reason I
Yeah, using a command line application to talk to a provider seems like the
best way to go. That's the usual way to make things pluggable in Go, and
fits our use cases quite well. It's definitely something I think we should
do, but I'm not sure it's that high on the priority list right now.
On
There seems to be no compelling reason why we can't distribute more than
just juju and jujud. However, I don't think there's anything to gain by
splitting out the providers we already have in core. Adding code that
enables pluggable providers seems like a no-brainer to let people provide
their ow
te:
> The Wednesday 07 May 2014 à 11:05:35 (-0400), Nate Finch wrote :
> > There seems to be no compelling reason why we can't distribute more than
> > just juju and jujud. However, I don't think there's anything to gain by
> > splitting out the provider
Actually, init is the main command, generate-config is an alias for init
(see juju help commands).
On Wed, May 7, 2014 at 1:55 PM, Nick Veitch wrote:
> Nice work, when it is ready we can add it to the getting started
> section of the docs too.
>
> Small point - 'juju generate-config', not 'juju
However, the fix is slightly different than just "always choose amd64".
Instead, we always choose the same architecture as the client machine,
that way if the user uses --upload-tools, the tools will actually work on
the cloud machine.
This means that if you're running i386, you would still need
For what it's worth, I agree with everyone. John and I discussed it, and I
thought we had decided that we needed to use the local arch because of
upload tools, evidently John though we'd decided in the other direction.
And Gustavo is right that we should have pushed the discussion to the
mailing
I'd be happy to help out, I'm natefinch on reddit.
On Tue, May 20, 2014 at 1:50 PM, Matthew Williams <
matthew.willi...@canonical.com> wrote:
> Thanks Joey,
>
> I've added you - if you can work out how to add the flair be my guest
>
> Cheers
>
> Matty
>
>
> On Tue, May 20, 2014 at 6:01 PM, Joey
Ug we really need to clean up our error reporting in this area. rc: 1
is a completely unacceptable error message.
On Wed, May 21, 2014 at 6:46 AM, David Cheney wrote:
> I am sorry, the bootstrap machine was not able to communicate with the
> server, streams.canonical.com. Please try again,
I made a bug for the rc: 1 error message:
https://bugs.launchpad.net/juju-core/+bug/1321793
I've looked at it in the past, but wasn't able to devote enough time to
actually make it report something useful.
On Wed, May 21, 2014 at 9:56 AM, Nate Finch wrote:
> Ug we really nee
github.com/canonical is claimed by someone already. The person who owns it
has been sent a couple emails asking if he'd be willing to change his
github username. We've received no response so far. I'm not sure if he's
just ignoring the emails or if he's not actually reading them.
On Fri, Sep
Nice! Digital Ocean really is super fast my Discourse charm takes
21(!) minutes to deploy on an AWS m1.small and 7 minutes on a DO 2GB
droplet, which is 2/3rds the price of the amazon instance.
Kapil's digital ocean plugin really makes it all (relatively) seamless,
too. I look forward to whe
The Juju application *has* moved to github. We use launchpad for bugs, but
github is the home for the code.
On Tue, Oct 7, 2014 at 4:08 PM, José Antonio Rey wrote:
> Juju didn't move to Github. Juju charms are only being mirrored to Github.
>
> --
> José Antonio Rey
> On Oct 7, 2014 9:06 AM, "V
The point is - don't use local provider. If you have a single VPS, use the
manual provider to bootstrap onto that machine. You can run juju bootstrap
from your laptop to bootstrap juju onto the VPS.
https://juju.ubuntu.com/docs/config-manual.html
On Wed, Oct 8, 2014 at 11:58 AM, Andrew Wilkins <
Funny you should ask, but putting constraints directly in the charm's
metadata.yaml is a feature we are planning to work on this cycle. Charm
authors will be able to set default constraints for their charm, so that if
you know your charm needs 2GB of RAM to work properly, for example, you can
set t
Definitely the low 1.20.x releases had a couple issues especially with
containers. These were all fixed later, as Mark mentioned. Hopefully
that'll solve your problems.
On Nov 15, 2014 1:02 PM, "Mark Shuttleworth" wrote:
> On 14/11/14 02:39, Sameer Zeidat wrote:
> > Hello,
> > I'm running juju
+1
On Jan 14, 2015 12:54 PM, "Marco Ceppi" wrote:
> Hey everyone,
>
> There's currently quite a few version of juju available [0] from various
> sources (cloud archive, ubuntu archive, stable ppa, source). While I know
> the release team is doing a great job in making sure that versions of juju
>
I'm a core dev on Juju, I can answer some, but not all of these questions.
First off, as far as long term commitment for Juju - Juju is a huge part of
Canonical's long term strategy... right up there with the Ubuntu Phone and
Ubuntu itself. The Juju team has been expanding hugely in the last coup
https://bugs.launchpad.net/juju-core/+bug/1316174
>
> Feature request:
> https://bugs.launchpad.net/juju-core/+bug/1432331
>
> The saltstack charm-helpers integration also has few problems. I just gave
> up on it and wrote the install hooks in python.
>
>
>
> 2015-03-
What does this do that just using the juju binary on your local system
doesn't do?
On Fri, Mar 27, 2015 at 11:49 AM, Jorge O. Castro wrote:
> Hi everyone,
>
> First, if you haven't seen this yet, this is a docker container that
> let's you just try Juju, with the limitation that you can't do the
That is fantastic! We've been wanting o implement something similar for a
while now and just haven't had the bandwidth. Thanks for this!
On Apr 24, 2015 8:35 AM, "Cory Johns" wrote:
> Last week, while in Nuremberg, Ben and I were able to create a new
> plugin to enable a much better charm develo
Hi list,
I'm Nate Finch, a developer on the core functionality of Juju.
One of our focuses this cycle is on improving the documentation of Juju.
Since it can be hard for those of us so close to the code to know where we
need better explanations, I'm sending this request out to the l
Hooks and actions all fire with the root of the charmdir as the current
directory, so in general, you don't need to get it, you're already there.
For example, if your charm has /assets/foo.jpg ... you can just
do
f, err := os.Open("assets/foo.jpg")
and it'll work correctly.
On Mon, Jun 1, 201
I'm not sure I understand the problems this is solving that aren't
adequately solved by branching from a source charm. It seems like the hard
part of branching - maintaining changes to non-trivial code - is not helped
by this tool. For charms that just need to add hook files or modify charm
metad
Compiling juju on any Linux is actually very straight forward... however
*running* Juju on any Linux except Ubuntu and Centos is not going to work
(due to some platform-specific code we have)... but if all you want to do
is compile, that's easy:
Install git, bzr, and mercurial (pretty sure mercuri
It depends on what you mean. If you mean "can I have some machines on AWS
talk to some other machines in Azure inside the same Juju environment" then
the answer is mostly no (you can use a machine's ssh info to "import" that
machine into an existing juju environment, but it's quite different than
Definitely look at the GCE provider, it's the newest and uses our current
best practices. Some of the older providers are not quite as good examples
(not that they're wrong, we've just figured out better ways to do structure
the code).
On Sat, Sep 19, 2015, 6:01 AM Mark Shuttleworth wrote:
> On
The environment variables are transferred to the server, so getting them
from /proc//environ on the server should be doable (someone better at
bash might be able to give you a one liner).
On Tue, Sep 22, 2015 at 1:19 PM Andreas Hasenack
wrote:
> Hi,
>
> given an existing juju environment, is the
In case you haven't heard of it, the lxd provider basically replaces the
old local provider, running nodes as containers using lxd on the local
machine.
There's a few differences from the the old local provider:
1. Bootstrap will be a little bit slower on lxd.
- This is because the local
I actually don't see why you would ever need to distribute a specific
library for connecting to an API on another charm. The charm using the
dynamically determined client would still require a static (i.e. backward
compatible) API on the client library (otherwise the client charm would
have no way
tl;dr: We'll fire the upgrade-charm hook, that code just wasn't done at
demo-time (I'm actually debugging it as we speak).
On Wed, Feb 17, 2016 at 9:24 AM Adam Collard
wrote:
> Hi Moonstone!
>
> On Fri, 12 Feb 2016 at 21:27 Katherine Cox-Buday <
> katherine.cox-bu...@canonical.com> wrote:
>
>> M
There is a new (optional) top level field in the metadata.yaml file called
min-juju-version. If supplied, this value specifies the minimum version of
a Juju server with which the charm is compatible. When a user attempts to
deploy a charm (whether from the charmstore or from local) that has
min-juj
BTW, I reported a very similar problems in this bug:
https://github.com/CanonicalLtd/jujucharms.com/issues/192
On Thu, Mar 17, 2016 at 10:18 AM Uros Jovanovic <
uros.jovano...@canonical.com> wrote:
> Hi Tom,
>
> We currently bump the recommended charms over the community ones. The
> reason other
17, 2016 at 1:57 PM, Nate Finch
> wrote:
>
>> There is a new (optional) top level field in the metadata.yaml file
>> called min-juju-version. If supplied, this value specifies the minimum
>> version of a Juju server with which the charm is compatible. When a user
>&g
>From what I've read, there's no server-side story to Ubuntu on Windows.
It's purely desktop, and in fact, only installs on desktop versions of
Windows 10. That could help with tooling for charm authors, but obviously
the charm code itself still needs to run on vanilla Windows.
The main tricky pa
At least... according to the core code, but it occurs to me I may well be
mistaken about what's allowed by the charm authoring tools and/or
charmstore.
On Mon, Apr 4, 2016 at 10:16 AM Nate Finch wrote:
> BTW, I don't believe this is true. I didn't work on series in metadat
BTW, I don't believe this is true. I didn't work on series in metadata,
but I skimmed the code and didn't see anything doing checks for OS
consistency across the stated series. I just tried it with a charm labeled
as trusty & win10 in the metadata.yaml and it worked fine deploying to
trusty.
On
Yeah, resource-get is specifically optimized to be able to be called as
often as you want. Each one makes a network call to the controller, but
unless the resource has changed, no data will be downloaded.
On Fri, Jun 24, 2016 at 4:24 PM Jay Wren wrote:
> Could you expand on the resource-get ine
You can use --series xenial --force I don't know if there's anything in
the charm that might fail, though.
On Mon, Jun 27, 2016, 7:40 AM Rajith P Venkata wrote:
> Hi
>
> I am deploying mariadb5.5 on juju 2.0, I am getting error . Mariadb charm
> supports only trusty , is there a way we can have
l --force.
>
> Error in log:
> ERROR juju.worker.uniter.operation runhook.go:107 hook "install" failed:
> exit status 127
>
>
>
> Rajith
>
> IBM AIX Certified, OCPCertified
>
>
> Cell- 9901966577
> Emai
Just FYI - running the juju client on Windows is 100% supported and we
actively fix bugs on it all the time. I hadn't seen the particular bug
you referenced about juju ssh, but that definitely seems like something we
should prioritize higher. The linux ssh works so much better because we
can sim
You don't need anything in the environment.yaml. You specify that you want
to deploy something to a lxc container in the deploy command. e.g.
juju deploy mysql --to lxc // deploys mysql to a new lxc container on a
new machine
juju deploy wordpress --to lxc:25 // deploys wordpress to a new lxc
This is one of the reasons we always make you type out the controller name
for destroy controller. Because
juju destroy-controller production-website
should ring a bell. Simply adding a long flag doesn't really help you
remember if you're killing something important or not, because you always
h
OMG, this is amazing.
On Thu, Sep 15, 2016 at 11:28 PM Tom Barber wrote:
> Indeed ramp up the american Marco ramp it up! ;)
>
> On a more mundane note, that is very good news.
>
> --
>
> Director Meteorite.bi - Saiku Analytics Founder
> Tel: +44(0)5603641316
>
> (Thanks to the Sa
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 pep
1. The stop hook happens when the unit is being removed entirely. It does
not run on reboot (and there's no reboot hook). The docs on the start hook
mention this: "Note that the charm's software should be configured so as to
persist through reboots without further intervention on juju's part." T
Resources are also stored in mongo and can be unlimited in size (not much
different than fat charms, except that at least they're only pulled down on
demand).
We should let admins configure their max log size... our defaults may not
be what they like, but I bet that's not really the issue, since w
Marshall
> > mailto:casey.marsh...@canonical.com>>
> > wrote:
> >
> > On Thu, Dec 1, 2016 at 6:53 AM, Marco Ceppi
> > mailto:marco.ce...@canonical.com>>
> > wrote:
> >
> > On Thu, Dec 1, 2016
I'm with Rick... the expected usage is to publish a dummy resource with the
charm. Then, when you deploy, you deploy the real resource from your local
machine at deploy time. If you forget, you can always add the resource
after deploy, as well. The charm needs to take into consideration that
som
FWIW, I think this *could* work, but it may be that we just haven't coded
it up. Just as *juju deploy mysql -n 4* will use existing clean machines
in the model where appropriate, deploying a bundle should as well
(presuming the existing machines match constraints etc as usual).
On Tue, Jan 3, 20
67 matches
Mail list logo