Re: relation departure timing changes

[Nate Finch]

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 Wordpress connects to MySQL, it is WordPress
that initiates the relationship & thus the connection. WordPress requires
MySQL, but MySQL doesn't care if WordPress exists or not, it just does what
it's told by WordPress (or anyone else).

There way be more symbiotic relationships out there, where both services
"require" each other but I think this is what William meant.




On Thu, Aug 22, 2013 at 12:57 PM, Gustavo Niemeyer wrote:

> > requirers connect to providers and not vice versa.
>
> I'm not sure I understand what that means. A relation is a bilateral
> communication channel, and it is entirely valid for a requirer to send
> information to a provider. What does it mean for a requirer to
> "connect" to a provider and not vice versa?
>
> Although I cannot yet put my finger on a specific reason, I have a bad
> feeling about the change suggested. Reporting something as dead while
> it is in fact still around doesn't seem great.
>
>
>
> On Thu, Aug 22, 2013 at 1:42 PM, William Reade
>  wrote:
> > Hi all
> >
> > This is inspired by the "relation-list reporting dying units" bug [0],
> which
> > can be reasonably simply fixed by reporting peer units' departure from a
> > relation as soon as we know that they're being destroyed (rather than
> > *after* the unit has handled the departure as we currently do [1]).
> >
> > I'm not aware of any reason this measure might be controversial (please
> let
> > me know if you are); but it raises an interesting question whose answer
> > hinges on common practice across the charm community. So far, there has
> been
> > no practical distinction between relation providers and requirers; we're
> > considering introducing an asymetry in the relationship, such that
> providers
> > signal departure early as above (but requirers continue to signal
> departure
> > only once they have actually departed).
> >
> > This makes intuitive sense given the names of the roles; but it only
> makes
> > practical sense if requirers and providers are written such that,
> > essentially, requirers connect to providers and not vice versa. Many
> charms
> > certainly do work this way, and would thus benefit from such a change;
> but
> > it's hard to audit this behaviour across the charm ecosystem. However,
> I'd
> > like to know if anyone is aware which charms (or, most likely, entire
> > interfaces) would *not* work correctly if we were to introduce this
> > behaviour; this will help us figure out if, when, and how to do so.
> >
> > Cheers
> > William
> >
> >
> > [0] https://bugs.launchpad.net/juju-core/+bug/1192433
> >
> > [1] https://juju.ubuntu.com/docs/authors-charms-in-action.html --
> "Departing
> > relations"
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
> >
>
>
>
> --
>
> gustavo @ http://niemeyer.net
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju is slow to do anything

[Nate Finch]

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 local machine is running 1.13.2-precise-amd64 and the bootstrap node
> 1.13.2-raring-amd64. I've only ever used versions greater than 1.11 and
> seen this kind of latency (half a minute or more).
>
> Thanks,
>
> - Peter
>
>
> On 30 August 2013 00:22, Marco Ceppi  wrote:
>
>> Hi Peter (and ScraperWiki team!),
>>
>> Thanks for contact the list! I'm curious what version of juju do you all
>> currently use at ScraperWiki? In version of juju < 1.0 we were creating SSH
>> tunnels to the bootstrap node to create a socket for which to securely
>> communicate with Zookeeper, which was what we used as our state server.
>> Since 1.0 we've replaced Zookeeper with SSL secured Mongodb (and an API
>> server), which means connections to the bootstrap node for querying unit
>> information and performing actions has increased in speed quite a bit. So
>> if you're using, say, juju 0.7 you'll still be creating this tedious SSH
>> tunnels which create overhead in each juju command. If you're using, say,
>> juju 1.12 then you shouldn't see much latency at all.
>>
>> As for garbage collection, I think this is still an issue with both our
>> last 0.X release (0.7) and our latest 1.X release (1.13.2). I know that the
>> 1.0 series of juju release are getting better at allowing you to clean up
>> services that no longer exist in the topology but it's not quite there yet.
>>
>> Thanks,
>>
>> Marco Ceppi
>> Canonical, Ltd.
>>
>>
>> On Thu, Aug 29, 2013 at 6:57 AM, Peter Waller wrote:
>>
>>> Hi All,
>>>
>>> I've just joined ScraperWiki where juju is used to manage our AWS
>>> deployments.
>>>
>>> I don't have any prior juju experience. Is it expected that "juju
>>> status" and "juju ssh" take more than 30 seconds to do anything? Everyone
>>> in my organization is experiencing this. It is making it a frustrating tool
>>> to use at times.
>>>
>>> If this isn't normal, are there any obvious culprits I can check to
>>> diagnose the origin of this delay?
>>>
>>> Thanks in advance,
>>>
>>> - Peter
>>>
>>> p.s. To give some information about our setup:
>>>
>>> $ juju status | grep agent-state:  | sort | uniq -c | sort -n
>>>   1 agent-state: pending
>>>   1 agent-state: pending
>>>   7 agent-state: down
>>>   9 agent-state: started
>>>  10 agent-state: started
>>>
>>> We have quite some machines we're never going to use again, is there a
>>> way to garbage collect this list?
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Manual provisioning - feedback wanted

[Nate Finch]

Marco - no reason we can't do both. :) The nice thing about putting a list
in environments.yaml is that it makes the workflow the same as the other
providers. It also means that you don't have to go look up an external list
of IP addresses when you want to add a new service on a new machine. Think
of it like MAAS lite :)


On Mon, Sep 9, 2013 at 1:36 PM, Marco Ceppi  wrote:

> I'm also quite interested in this, however, I don't think your idea of
> listing IP addresses in the environments yaml is the way to go. I really
> like the add-machine functionality. I look 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, 2013 at 1:01 PM, Nate Finch wrote:
>
>> 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 don't know what the roadmap is like, but it seems like we should
>> implement the manual provider as an actual provider with a type and
>> everything that can live in your environments.yaml. For me, the ideal would
>> be able to just specify a list of IP addresses in environments.yaml and
>> make that my "cloud". MAAS is nice and all, but it's a lot of setup for a
>> situation where I specifically do not want a lot of setup. I just want to
>> be able to say "I have these three Ubuntu machines (specified by IP
>> addresses), juju go do your thing". Minimum barrier of entry.
>> On Sep 8, 2013 9:47 PM, "Andrew Wilkins" 
>> wrote:
>>
>>> Hello everyone,
>>>
>>> As was noted in the 1.13.3 release notes thread, we did not announce one
>>> the major features that made it into the release (manual provisioning).
>>> This was intentional as we have not written any documentation yet. On the
>>> other hand, it would be good to get some feedback so that we can make
>>> changes if necessary, or feed into the documentation.
>>>
>>> So, below is a bit of a run-down. If you're interested in this feature,
>>> try it out and let us know if you or have any issues or any thoughts for
>>> improvement.
>>>
>>> 
>>>
>>> As of 1.13.3 you can now do this:
>>> juju add-machine ssh:[user@]host
>>>
>>> and a series of commands will be carried out on that host, via SSH, to
>>> provision the machine into the current juju environment. This will enable
>>> you to compose a juju environment out of your existing systems.
>>>
>>> Here's a few things to bear in mind:
>>>  - Currently you do need to have an existing, bootstrapped environment.
>>> Work on improving this situation is underway
>>>  - The machine you're provisioning must be able to route to machine 0
>>> (for the state/API), and storage (to get tools, etc.)
>>>  - There is no change in supported operating systems; the machine being
>>> provisioned must be running Ubuntu 12.04+
>>>  - Multiple invocations of ssh will be made, and sudo is used on the
>>> remote host to install the machine agent. To reduce noisy prompts, you
>>> should use public key authentication. To completely eliminate prompting,
>>> you'll also need to enable passwordless sudo on the target host.
>>>
>>> Cheers,
>>> Andrew
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Manual provisioning - feedback wanted

[Nate Finch]

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 don't know what the roadmap is like, but it seems like we should
implement the manual provider as an actual provider with a type and
everything that can live in your environments.yaml. For me, the ideal would
be able to just specify a list of IP addresses in environments.yaml and
make that my "cloud". MAAS is nice and all, but it's a lot of setup for a
situation where I specifically do not want a lot of setup. I just want to
be able to say "I have these three Ubuntu machines (specified by IP
addresses), juju go do your thing". Minimum barrier of entry.
On Sep 8, 2013 9:47 PM, "Andrew Wilkins" 
wrote:

> Hello everyone,
>
> As was noted in the 1.13.3 release notes thread, we did not announce one
> the major features that made it into the release (manual provisioning).
> This was intentional as we have not written any documentation yet. On the
> other hand, it would be good to get some feedback so that we can make
> changes if necessary, or feed into the documentation.
>
> So, below is a bit of a run-down. If you're interested in this feature,
> try it out and let us know if you or have any issues or any thoughts for
> improvement.
>
> 
>
> As of 1.13.3 you can now do this:
> juju add-machine ssh:[user@]host
>
> and a series of commands will be carried out on that host, via SSH, to
> provision the machine into the current juju environment. This will enable
> you to compose a juju environment out of your existing systems.
>
> Here's a few things to bear in mind:
>  - Currently you do need to have an existing, bootstrapped environment.
> Work on improving this situation is underway
>  - The machine you're provisioning must be able to route to machine 0 (for
> the state/API), and storage (to get tools, etc.)
>  - There is no change in supported operating systems; the machine being
> provisioned must be running Ubuntu 12.04+
>  - Multiple invocations of ssh will be made, and sudo is used on the
> remote host to install the machine agent. To reduce noisy prompts, you
> should use public key authentication. To completely eliminate prompting,
> you'll also need to enable passwordless sudo on the target host.
>
> Cheers,
> Andrew
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm Quality Ratings updates

[Nate Finch]

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
emphasize that you can write as much as you want (and more documentation is
almost always better).


On Mon, Sep 30, 2013 at 9:16 AM, Richard Harding  wrote:

> Yes, we can do this. We currently support doing markdown rendering of a
> charm's readme in JS. Jorge, how are we looking to have users document
> their interfaces? As a description attribute in the yaml? Could that be
> easy to write out as markdown?
>
> On Mon, 30 Sep 2013, Mark Shuttleworth wrote:
>
> >
> > Are there good markdown renderers in JS? Should we aim for interface
> > documentation in MD?
> >
> > On 30/09/13 12:32, Richard Harding wrote:
> > > On Wed, 25 Sep 2013, Luca Paulina wrote:
> > >
> > >> On Wed, Sep 25, 2013 at 3:06 PM, Jorge O. Castro 
> wrote:
> > >>
> > >>> Hi everyone,
> > >>>
> > >>> I'd like to revise the charm quality stuff a bit, mostly the
> ~charmers
> > >>> have captured that we would like to encourage folks to document the
> > >>> interfaces in their charms and I'd like to add that as a charm
> quality
> > >>> bullet item.
> > >>>
> > >>> In the past that just meant getting a +1 from some charmers and
> > >>> editing the docs, but now that we have a GUI I want to make sure we
> > >>> don't add things to the guidelines and not sync up with the GUI and
> > >>> design teams, so what would be the best way for me to drive that
> > >>> forward?
> > >> Thanks for the email Jorge, maybe we can find sometime to discuss it
> > >> tomorrow over a hangout. There is a need to revise the copy of the
> intro
> > >> paragraph as well, we should discuss that at the same time.
> > >>
> > >> Thanks,
> > >>
> > >> Luca
> > > Did this happen? To answer the first, question, a bit on charmworld to
> add
> > > the new QA item with the text and section to place it in will allow us
> to
> > > add it to the QA process. The Gui will then pick it up and adjust
> scores
> > > accordingly.
> > >
> > > --
> > >
> > > Rick Harding
> > >
> > > Cloud Engineering
> > > https://launchpad.net/~rharding
> > > @mitechie
> > >
> >
>
> --
>
> Rick Harding
>
> Cloud Engineering
> https://launchpad.net/~rharding
> @mitechie
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How do I launch and m1.medium on AWS?

[Nate Finch]

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 --constraints "cpu-cores=2 mem=3.75"
>
> launches c1.mediums and not m1's.
>
> --
> Jorge Castro
> Canonical Ltd.
> http://juju.ubuntu.com/charm-championship - Share your infrastructure,
> win a prize!
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How do I launch and m1.medium on AWS?

[Nate Finch]

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 without an ec2 constraint in juju-core around instance type,
> the overlap around capabilities within ec2 instance types means exact
> specification via generic constraint is inexact. looks like you already
> filed a bug on this https://bugs.launchpad.net/juju-core/+bug/1237568
>
>
> 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 --constraints "cpu-cores=2 mem=3.75"
>>
>> launches c1.mediums and not m1's.
>>
>> --
>> Jorge Castro
>> Canonical Ltd.
>> http://juju.ubuntu.com/charm-championship - Share your infrastructure,
>> win a prize!
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How do I launch and m1.medium on AWS?

[Nate Finch]

So, it depends on what you mean by explode.  Juju won't misbehave, but
certainly the script will not function in the way the writer intended if
you do juju add-machine --constraints type=m1.large when running against
MaaS instead of EC2.

Both EC2's instance type and MaaS tags are exposed through generic
constraints (type and tags respectively) that are intended to be
implemented in provider-specific ways.  Right now they are just ignored by
providers that don't support them (so you can do tags=foo when running
against EC2, and it'll just act as if the constraint wasn't there).  So
trying to add-machine --constraints type=m1.large against maas will
actually give you any random machine on maas.

I see three possible behaviors when you specify a constraint that is not
supported by the provider you're working against:

1.  It could be ignored (this is what we do now)
2.  It could cause the command to simply fail immediately.
3.  We could try to make our best guess at what the user means.

I'm not a big fan of #3, either of the other behaviors are fine, in my
opinion.

In theory we could translate EC2 instance types into lists of other
constraints (cpu-cores, memory, etc), and use those lists of constraints
against other providers so effectively that would work like "hey, give
me something that looks like an m1.large on this provider"... but I'm not
sure if that would be more surprising than helpful.

-Nate


On Wed, Oct 9, 2013 at 11:25 PM, Kapil Thangavelu <
kapil.thangav...@canonical.com> wrote:

> quick indeed, that's awesome!
>
> fwiw, looking over the branch and the maas tags implementation, these
> provider specific constraints are actually exposed as global constraints so
> a script using wouldn't explode running elsewhere.
>
>
> On Wed, Oct 9, 2013 at 10:27 PM, Gustavo Niemeyer wrote:
>
>> Hey Nate,
>>
>> That was quick! :-)
>>
>> Have you read the previous threads on the subject?  Agree with Mark we
>> should do something, 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 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 without an ec2 constraint in juju-core around instance
>> type,
>> >> the overlap around capabilities within ec2 instance types means exact
>> >> specification via generic constraint is inexact. looks like you already
>> >> filed a bug on this https://bugs.launchpad.net/juju-core/+bug/1237568
>> >>
>> >>
>> >> 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 --constraints "cpu-cores=2 mem=3.75"
>> >>>
>> >>> launches c1.mediums and not m1's.
>> >>>
>> >>> --
>> >>> Jorge Castro
>> >>> Canonical Ltd.
>> >>> http://juju.ubuntu.com/charm-championship - Share your
>> infrastructure,
>> >>> win a prize!
>> >>>
>> >>> --
>> >>> Juju mailing list
>> >>> Juju@lists.ubuntu.com
>> >>> Modify settings or unsubscribe at:
>> >>> https://lists.ubuntu.com/mailman/listinfo/juju
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> Juju mailing list
>> >> Juju@lists.ubuntu.com
>> >> Modify settings or unsubscribe at:
>> >> https://lists.ubuntu.com/mailman/listinfo/juju
>> >>
>> >
>> > --
>> > Juju mailing list
>> > Juju@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> > https://lists.ubuntu.com/mailman/listinfo/juju
>> >
>>
>>
>>
>> --
>>
>> gustavo @ http://niemeyer.net
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How do I launch and m1.medium on AWS?

[Nate Finch]

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 easily shareable, so people online or people in
the same company could share configurations ideally stored in a
configuration file.

You could then specify an alias:

discourse "mem=2G root-disk=10G cpu-cores=2"

And then someone could copy and paste that into their .juju/aliases   (or
something similar)

then you could do

juju deploy discourse --constraints alias=discourse

It would make scripts a lot easier to write cross-provider, you'd just need
to translate your constraints aliases to the new provider, and the actual
deployment script could stay exactly the same.



On Thu, Oct 10, 2013 at 9:18 AM, Gustavo Niemeyer <
gustavo.nieme...@canonical.com> wrote:

> On Thu, Oct 10, 2013 at 8:31 AM, John Arbash Meinel
>  wrote:
> > We've gone around that discussion a *lot* about how you specify a
> > value that is site-specific. Do you need a site-specific key?
> (...)
> > We talked about supporting a potential list and we just pick out which
> > one might fit, but Canonistack and EC2 both define an "m1.tiny" that
> > may or may not match well enough (and we don't provide a way to be
> > more specific without just site specific meaning).
>
> We can perhaps get away with a simple mechanism: we define a generic
> "instance-type" constraint. If the name of that constraint matches
> exactly something that is available in the API endpoint being used
> (not just provider type, since we can have multiple API endpoints with
> the same provider type yet different machine types), we use it. If it
> does not match any, the script errors out so we can catch typos and
> actual errors. In a second moment, we can provide a mechanism for
> people to provide their own custom mappings tied to their environment
> ("in this environment t1.micro means 1 CPU and 512MB of memory").
>
>
> gustavo @ http://niemeyer.net
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: How do I launch and m1.medium on AWS?

[Nate Finch]

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 ec2 or canonistack.


On Thu, Oct 10, 2013 at 12:07 PM, William Reade  wrote:

> On Thu, Oct 10, 2013 at 4:55 PM, Sidnei da Silva <
> sidnei.da.si...@canonical.com> wrote:
>
>> Yes, I like this. I also like the idea that we might provide a
>>> "reference mapping" that at least describes all the certified public
>>> clouds, and which can be overridden for an environment or for a user's
>>> personal defaults. This would make it a lot easier to publish bundles
>>> which encode "size" logic and have them Just Work everywhere. How about
>>> we take baby steps in that direction?
>>
>>
>> At that point we could store the mapping alongside with the
>> 'simplestreams' metadata which describes what's the latest available Ubuntu
>> image, IIUC. If so, sounds like an excellent idea.
>>
>
> Depends on the cloud really. For EC2, we're planning to put instance-type
> data into simplestreams (ec2 doesn't publish it usefully, and hardcoding it
> as we do today just sucks); for arbitrary openstack deployments, it would
> be crazy to use anything other than the flavor lists supplied by the
> provider itself.
>
> The core distinction is between possible meanings of "provider"; the
> original juju meaning of "provider" ("openstack", "maas") cannot possibly
> work, but if you take a "provider" to mean a specific site it becomes
> simple. For now, we can use "instance-type" without fear of ambiguity,
> because all environments are single-site; if we're using several, we'll
> have to disambiguate constraints with "site:" (and ofc allow per-site
> values: ec2:type=t1.micro, canonistack:type=m1.small), but I don't think
> that's any reason to complicate the syntax before it's required. (By
> checking instance-type early, as Gustavo mentioned, we can provide clear
> feedback for the cases where someone tries to use an inappropriate value
> for a given provider.)
>
> Cheers
> William
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm Ecosystem Status for 30 October

[Nate Finch]

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

I prefer manual over ssh as the name, but either is significantly better
than implicitly having a default of "manual" in my opinion.


On Thu, Oct 31, 2013 at 9:51 AM, Jorge O. Castro  wrote:

> On Thu, Oct 31, 2013 at 12:00 AM, John Arbash Meinel
>  wrote:
> > For what its worth, Mark S really didn't prefer the term SSH provider.
> > The favorite was to call it Manual Registration. I think what we
> > converged on was to have an environment stanza with *no* provider
> > entry, and then use the term "use juju add-machine to manually
> > register a machine with your environment".
>
> Ok that works for us (eco). Anything but null. :)
>
> Having it just add it after you add the command instead of a null
> entry is one less step too.
>
> --
> Jorge Castro
> Canonical Ltd.
> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: High Availability command line interface - future plans.

[Nate Finch]

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.

More inline:

On Wed, Nov 6, 2013 at 1:49 PM, roger peppe  wrote:

> The current plan is to have a single "juju ensure-ha-state" juju
> command. This would create new state server machines if there are less
> than the required number (currently 3).
>
> Taking that as given, I'm wondering what we should do
> in the future, when users require more than a single
> big On switch for HA.
>
> How does the user:
>
> a) know about the HA machines so the costs of HA are not hidden, and that
> the implications of particular machine failures are clear?
>

- As above, documentation about what it means when you see servers in juju
status labelled as "Juju State Server" (or whatever).

- Have actual feedback from commands:

$ juju bootstrap --high-availability
Machines 0, 1, and 2 provisioned as juju server nodes.
Juju successfully bootstrapped environment Foo in high availability mode.

or

$ juju bootstrap
Machine 0 provisioned as juju server node.
Juju successfully bootstrapped environment Foo.

$ juju ensure-ha -n 7
Enabling high availability mode with 7 juju servers.
Machines 1, 2, 3, 4, 5, and 6 provisioned as additional Juju server nodes.

$ juju ensure-ha -n 5
Reducing number of Juju server nodes to 5.
Machines 2 and 6 destroyed.

b) fix the system when a machine dies?
>

$ juju destroy-machine 5
Destroyed machine/5.
Automatically replacing destroyed Juju server node.
Machine/8 created as new Juju server node.


> c) scale up the system to x thousand nodes


Hopefully 12 machines is plenty of Juju servers for 5000 nodes.  We will
need to revisit this if it's not, but it seems like it should be plenty.
 As above, I think a simple -n is fine for both raising and lowering the
number of state servers.  If we get to the point of needing more than


> d) scale down the system?
>

 $ juju disable-ha -y
Destroyed machine/1 and machine/2.
The Juju server node for environment Foo is machine/0.
High availability mode disabled for Juju environment Foo.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: High Availability command line interface - future plans.

[Nate Finch]

Oops, missed the end of a thought there.  If we get to the point of needing
more than 12 server nodes (not unfathomable), then we have to start doing
some more work for our "hyperscale" customers, which will probably involve
much more customization and require much more knowledge of the system.

I think one of the points of making HA simple is that we don't want people
to have to learn how Juju works before they can deploy their own stuff in a
robust manner.  Keep the barrier of entry as low as possible.  We can give
general guidelines about how many Juju servers you need for N unit agents,
and then people will know what to set N to, when they do juju ensure-ha -n.

I think most people will be happy knowing there are N servers out there,
and if one goes down, another will take its place. They don't want to know
about this job and that job.  Just make it work and let 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'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.
>
> More inline:
>
> On Wed, Nov 6, 2013 at 1:49 PM, roger peppe  wrote:
>
>> The current plan is to have a single "juju ensure-ha-state" juju
>> command. This would create new state server machines if there are less
>> than the required number (currently 3).
>>
>> Taking that as given, I'm wondering what we should do
>> in the future, when users require more than a single
>> big On switch for HA.
>>
>> How does the user:
>>
>> a) know about the HA machines so the costs of HA are not hidden, and that
>> the implications of particular machine failures are clear?
>>
>
> - As above, documentation about what it means when you see servers in juju
> status labelled as "Juju State Server" (or whatever).
>
> - Have actual feedback from commands:
>
> $ juju bootstrap --high-availability
> Machines 0, 1, and 2 provisioned as juju server nodes.
> Juju successfully bootstrapped environment Foo in high availability mode.
>
> or
>
> $ juju bootstrap
> Machine 0 provisioned as juju server node.
> Juju successfully bootstrapped environment Foo.
>
> $ juju ensure-ha -n 7
> Enabling high availability mode with 7 juju servers.
> Machines 1, 2, 3, 4, 5, and 6 provisioned as additional Juju server nodes.
>
> $ juju ensure-ha -n 5
> Reducing number of Juju server nodes to 5.
> Machines 2 and 6 destroyed.
>
> b) fix the system when a machine dies?
>>
>
> $ juju destroy-machine 5
> Destroyed machine/5.
> Automatically replacing destroyed Juju server node.
> Machine/8 created as new Juju server node.
>
>
>> c) scale up the system to x thousand nodes
>
>
> Hopefully 12 machines is plenty of Juju servers for 5000 nodes.  We will
> need to revisit this if it's not, but it seems like it should be plenty.
>  As above, I think a simple -n is fine for both raising and lowering the
> number of state servers.  If we get to the point of needing more than
>
>
>> d) scale down the system?
>>
>
>  $ juju disable-ha -y
> Destroyed machine/1 and machine/2.
> The Juju server node for environment Foo is machine/0.
> High availability mode disabled for Juju environment Foo.
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Windows clients and PuTTY

[Nate Finch]

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 command invocation.
>
> Who wants to raise the issue ?
>
> On Wed, Dec 4, 2013 at 8:10 AM, Marco Ceppi  wrote:
> > We have docs on creating keys for windows users, but not on how to set up
> > PuTTY https://juju.ubuntu.com/docs/getting-started-keygen-win.html We
> should
> > probably expand these to installing PuTTY
> >
> >
> > On Tue, Dec 3, 2013 at 3:26 PM, Tim Penhey 
> wrote:
> >>
> >> Hi folks,
> >>
> >> I watch the Ask Ubuntu questions around Juju, and saw one yesterday that
> >> I think we need to get better docs around.
> >>
> >> The user was saying he couldn't edit the files on the machines that Juju
> >> started.  This had me going "huh?".
> >>
> >> I should have twigged immediately at the use of Filezilla, but it became
> >> obvious when someone else suggested just using 'juju ssh' and the error
> >> was that 'juju not found in %PATH%'.
> >>
> >> Do we have docs that help people set up PuTTY on windows, enabling it
> >> for juju, and making sure that the key is uploaded?
> >>
> >> Cheers,
> >> Tim
> >>
> >> --
> >> Juju mailing list
> >> Juju@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >
> >
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> > https://lists.ubuntu.com/mailman/listinfo/juju
> >
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Windows clients and PuTTY

[Nate Finch]

Yeah, that's a good point. The problem comes when they don't have putty, or
if they do, we don't know where it is (putty isn't an installed
application, it's a standalone exe, so it can live anywhere... Mine always
just lived in my downloads folder). I'm not sure what the best solution for
that is. There's a bunch of not great work around.
On Dec 3, 2013 6:44 PM, "David Cheney"  wrote:

> :) Nice.
>
> The big problem with using the go ssh client is not the ssh support,
> but the terminal handling. To work properly on the remote side you
> need to request a PTY when setting up the shell session. That causes
> the remote shell to send lots of advanced messages, like 'how wide is
> your screen', etc, which need to be handled or you just get poop on
> your screen. Interfacing that with the W32 console subsystem 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
>
> Dave
>
>
> On Wed, Dec 4, 2013 at 10:40 AM, Nate Finch 
> wrote:
> > 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 command invocation.
> >>
> >> Who wants to raise the issue ?
> >>
> >> On Wed, Dec 4, 2013 at 8:10 AM, Marco Ceppi  wrote:
> >> > We have docs on creating keys for windows users, but not on how to set
> >> > up
> >> > PuTTY https://juju.ubuntu.com/docs/getting-started-keygen-win.html We
> >> > should
> >> > probably expand these to installing PuTTY
> >> >
> >> >
> >> > On Tue, Dec 3, 2013 at 3:26 PM, Tim Penhey 
> >> > wrote:
> >> >>
> >> >> Hi folks,
> >> >>
> >> >> I watch the Ask Ubuntu questions around Juju, and saw one yesterday
> >> >> that
> >> >> I think we need to get better docs around.
> >> >>
> >> >> The user was saying he couldn't edit the files on the machines that
> >> >> Juju
> >> >> started.  This had me going "huh?".
> >> >>
> >> >> I should have twigged immediately at the use of Filezilla, but it
> >> >> became
> >> >> obvious when someone else suggested just using 'juju ssh' and the
> error
> >> >> was that 'juju not found in %PATH%'.
> >> >>
> >> >> Do we have docs that help people set up PuTTY on windows, enabling it
> >> >> for juju, and making sure that the key is uploaded?
> >> >>
> >> >> Cheers,
> >> >> Tim
> >> >>
> >> >> --
> >> >> Juju mailing list
> >> >> Juju@lists.ubuntu.com
> >> >> Modify settings or unsubscribe at:
> >> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >> >
> >> >
> >> >
> >> > --
> >> > Juju mailing list
> >> > Juju@lists.ubuntu.com
> >> > Modify settings or unsubscribe at:
> >> > https://lists.ubuntu.com/mailman/listinfo/juju
> >> >
> >>
> >> --
> >> Juju mailing list
> >> Juju@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Windows clients and PuTTY

[Nate Finch]

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 
> wrote:
> > Yeah, that's a good point. The problem comes when they don't have putty,
> or
> > if they do, we don't know where it is (putty isn't an installed
> application,
> > it's a standalone exe, so it can live anywhere... Mine always just lived
> in
> > my downloads folder). I'm not sure what the best solution for that is.
> > There's a bunch of not great work around.
>
> If we can make the restriction that it must live in %PATH% that sounds
> preferable to
>
> a. writing our own ssh client
> b. adding another configuration value to environments.yaml, especially
> as that file has no concept of global configuration, only per
> environment configuration.
>
> >
> > On Dec 3, 2013 6:44 PM, "David Cheney" 
> wrote:
> >>
> >> :) Nice.
> >>
> >> The big problem with using the go ssh client is not the ssh support,
> >> but the terminal handling. To work properly on the remote side you
> >> need to request a PTY when setting up the shell session. That causes
> >> the remote shell to send lots of advanced messages, like 'how wide is
> >> your screen', etc, which need to be handled or you just get poop on
> >> your screen. Interfacing that with the W32 console subsystem 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
> >>
> >> Dave
> >>
> >>
> >> On Wed, Dec 4, 2013 at 10:40 AM, Nate Finch 
> >> wrote:
> >> > 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 command invocation.
> >> >>
> >> >> Who wants to raise the issue ?
> >> >>
> >> >> On Wed, Dec 4, 2013 at 8:10 AM, Marco Ceppi  wrote:
> >> >> > We have docs on creating keys for windows users, but not on how to
> >> >> > set
> >> >> > up
> >> >> > PuTTY https://juju.ubuntu.com/docs/getting-started-keygen-win.htmlWe
> >> >> > should
> >> >> > probably expand these to installing PuTTY
> >> >> >
> >> >> >
> >> >> > On Tue, Dec 3, 2013 at 3:26 PM, Tim Penhey <
> tim.pen...@canonical.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Hi folks,
> >> >> >>
> >> >> >> I watch the Ask Ubuntu questions around Juju, and saw one
> yesterday
> >> >> >> that
> >> >> >> I think we need to get better docs around.
> >> >> >>
> >> >> >> The user was saying he couldn't edit the files on the machines
> that
> >> >> >> Juju
> >> >> >> started.  This had me going "huh?".
> >> >> >>
> >> >> >> I should have twigged immediately at the use of Filezilla, but it
> >> >> >> became
> >> >> >> obvious when someone else suggested just using 'juju ssh' and the
> >> >> >> error
> >> >> >> was that 'juju not found in %PATH%'.
> >> >> >>
> >> >> >> Do we have docs that help people set up PuTTY on windows, enabling
> >> >> >> it
> >> >> >> for juju, and making sure that the key is uploaded?
> >> >> >>
> >> >> >> Cheers,
> >> >> >> Tim
> >> >> >>
> >> >> >> --
> >> >> >> Juju mailing list
> >> >> >> Juju@lists.ubuntu.com
> >> >> >> Modify settings or unsubscribe at:
> >> >> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Juju mailing list
> >> >> > Juju@lists.ubuntu.com
> >> >> > Modify settings or unsubscribe at:
> >> >> > https://lists.ubuntu.com/mailman/listinfo/juju
> >> >> >
> >> >>
> >> >> --
> >> >> Juju mailing list
> >> >> Juju@lists.ubuntu.com
> >> >> Modify settings or unsubscribe at:
> >> >> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: I WANT YOU, to give me your feedback (Juju docs!)

[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-core, juju, and juju-gui list
> to start a discussion about the next format for the docs. Currently, I've
> worked on a proof of concept to converting the docs to Markdown and it's
> going really well. Using python-markdown with a few custom plugins to
> handle the unique user friendly features the docs provide.
>
> However, I wanted to get feedback on the choice of formatting. Markdown
> has quickly become the choice of formatting for new projects, it's used
> heavily on the StackExchange network as well as Github. It's even a
> recommendation for the charm README files and charm-tools creates a
> Markdown template for use. Finally, it bares similarities to RST but tends
> to be more forgiving and require less syntax to use.
>
> To quote the John Gruber, Markdown creator:
>
> > While Markdown's syntax has been influenced by several existing
> text-to-HTML filters, the single biggest source of inspiration for
> Markdown's syntax is the format of plain text email.
>
> This low barrier of entry is likely one of the reasons it's grown in
> popularity over the years.
>
> I'm curious of people's opinions, do you support this move to Markdown? Do
> you have other formats for docs in mind and if so reasons that style
> instead? After some time I'll consider the responses, for and against, as a
> poll for which language to move the docs to as I finish my conversion
>
> Thanks,
> Marco Ceppi
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: MAAS Bootstrap

[Nate Finch]

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
> couldn't get the rsa key to work initially, came back after some
> frustration and a reboot for it to start working.  Currently battling it
> now, unfortunately I can't just drop the problematic repo's as one of them
> is the 'main' one, doing so takes out a lot of essential packages.  All I
> can find online is 4-5 unanswered questions from people getting the same
> error from the repo when going from ubuntu 13.10 to 14.04.
>
> I guess I need to have another go at forcing it to an older version of
> Ubuntu for now.
>
> Thanks
>
>
> On 21 April 2014 23:05, Sameer Zeidat  wrote:
>
>>  Not sure about the issue. But why not find out the bootstrap's node ip
>> from MAAS and ssh to it directly with username ubuntu.
>>  --
>> From: Martyn Cross 
>> Sent: ‎22/‎04/‎2014 5:14 AM
>> To: juju@lists.ubuntu.com
>> Subject: MAAS Bootstrap
>>
>> Hi all,
>>
>> I'm currently trying to get Juju up and running with my MAAS setup.  I
>> have got Juju working using the local provider and working perfectly.
>>  However when I switch to maas and run juju bootstrap, all goes well until
>> it runs apt on the node that it images and is configuring.  The following
>> takes place, causing the bootstrap to fail:
>>
>>  Ign http://archive.ubuntu.com trusty-backports/universe
>> Translation-en_US
>> Fetched 7,214 kB in 14s (488 kB/s)
>> W: Failed to fetch
>> gzip:/var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_trusty_main_binary-i386_Packages
>>  Hash Sum mismatch
>>
>> W: Failed to fetch
>> gzip:/var/lib/apt/lists/partial/archive.ubuntu.com_ubuntu_dists_trusty_universe_binary-i386_Packages
>>  Hash Sum mismatch
>>
>> E: Some index files failed to download. They have been ignored, or old
>> ones used instead.
>>
>>
>> I have tried specifying precise as the default-series in my
>> environment.yaml and confirmed that there are relevant images in the
>> cluster, however trusty is still being pulled down from maas.
>>
>> As this is before the bootstrap is complete, I can't use juju ssh node to
>> fix the issue myself.
>>
>> Is there something that I am missing or have I just channeled my inner
>> power of breaking everything in obscure ways.  Any suggestions or advice
>> would be appreciated.  Let me know if you need any specific info about the
>> setup or config.
>>
>> Many thanks,
>>  Martyn Cross.
>>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Questions about the integration of the Outscale cloud provider into juju-core

[Nate Finch]

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 Tue, May 6, 2014 at 12:36 AM, John Meinel  wrote:

> I'll also note that Tim had some good ideas about how to change the Local
> provider to be more consistent with other providers. (Essentially creating
> a separate process that could implement a "Remote Provider" sort of
> interface.) That could allow bringing up more 'pluggable' providers that
> just talk the same language as the 'local' one would.
> I personally would prefer if we used a command line interface (call this
> process with these arguments to start an instance), even if the local one
> would use the command line to make RPC/socket calls to another process. (If
> you think about it, all of them are just sending requests to some other
> long-lived process over a socket, but I'd rather not have to run a full
> service for every system we want to interact with.)
> John
> =:->
>
>
> On Tue, May 6, 2014 at 8:33 AM, John Meinel wrote:
>
>> There is work being done this cycle to switch from using storage from the
>> Provider to instead using our own internal storage. I don't know that the
>> work will be done for another few months, though. I believe Tim Penhey is
>> going to be leading up that work as part of exposing Resources for charms
>> to consume. I'm sure he'd be happy to coordinate with someone who wants to
>> work on moving us over to having storage internally.
>>
>> John
>> =:->
>>
>>
>> On Tue, May 6, 2014 at 8:24 AM, Benoît Canet wrote:
>>
>>> The Monday 05 May 2014 à 22:36:52 (-0400), Kapil Thangavelu wrote :
>>> > from https://wiki.outscale.net/display/DOCU/AWS+Compatibility+Matrix
>>> >
>>> > its a little unclear if outscale implements object storage compatible
>>> with
>>> > s3. if so then support in core would probably amount to making the
>>> ec2/s3
>>> > api endpoint url pluggable in the core code, along with userdata
>>> support
>>> > and cloudinit and compatible os images in outscale cloud.
>>>
>>> From what I know Outscale implement only EC2 compute: no object storage.
>>> How could we work around this ?
>>>
>>> Best regards
>>>
>>> Benoît
>>>
>>> >
>>> > cheers,
>>> >
>>> > Kapil
>>> >
>>> >
>>> > On Mon, May 5, 2014 at 11:56 AM, Benoît Canet <
>>> benoit.ca...@irqsave.net>wrote:
>>> >
>>> > >
>>> > > Hello,
>>> > >
>>> > > I am a developper planning to add the support for the Outscale cloud
>>> into
>>> > > juju-core.
>>> > >
>>> > > The Outscale cloud implement most of the EC2 API.
>>> > >
>>> > > Does the Juju maintainer have some guidance on how the support
>>> should be
>>> > > written ?
>>> > >
>>> > > Best regards
>>> > >
>>> > > Benoît Canet
>>> > > Nodalink
>>> > >
>>> > > --
>>> > > Juju mailing list
>>> > > Juju@lists.ubuntu.com
>>> > > Modify settings or unsubscribe at:
>>> > > https://lists.ubuntu.com/mailman/listinfo/juju
>>> > >
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at:
>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>
>>
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Questions about the integration of the Outscale cloud provider into juju-core

[Nate Finch]

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 own interface for their own cloud (whether it's a private cloud or
simply one of the public ones we don't yet support).

Yes, the manual provider sort of works now, but it is so incredibly
*manual *that I hesitate to even call it a solution for all but the most
limited of use cases.


On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical  wrote:

> On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins
>  wrote:
> > A bit tangential now, but...
> >
> > Plugin-style was originally how I thought it would best work, but that
> > requires distribution with both jujud *and* the juju CLI. That sounds
> like a
> > nightmare to me. OTOH, having a remote service means you can just point
> the
> > CLI and jujud at that remote service with nothing to distribute. It does
> > mean having a service, which brings its own set of issues.
> >
> > Of course, the two approaches are not mutually exclusive. As you say, you
> > could easily provide a plugin that talks to a remote service.
>
> Oh.  I think we already have this problem. Windows users cannot
> backup, restore or generate metadata because they only have the juju
> CLI binary installed.
>
> OSX users may have the current plugins since juju was built by brew,
> but I have not tested they work.
>
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Questions about the integration of the Outscale cloud provider into juju-core

[Nate Finch]

Two things:
1.) There's no inheritance in Go (though you can still reuse functionality
in a number of ways).
2.) Juju is open source.  There's no reason why the Outscale provider can't
use the ec2 implementation from an external repo.

Being in core grants the provider code no special benefits other than
ensuring that the code gets compiled and tested with the rest of the code.
 If we start having providers external to core, we'd work more carefully to
keep the provider interface stable, or at least backwards compatible.


On Wed, May 7, 2014 at 1:01 PM, Benoît Canet wrote:

> 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 providers we already have in core.  Adding code that
> > enables pluggable providers seems like a no-brainer to let people provide
> > their own interface for their own cloud (whether it's a private cloud or
> > simply one of the public ones we don't yet support).
>
> Would not it be better for the Outscale provider to be in core so it can
> inherit from the EC2 driver and only implement the differences ?
>
> Best regards
>
> Benoît
>
> >
> > Yes, the manual provider sort of works now, but it is so incredibly
> > *manual *that I hesitate to even call it a solution for all but the most
> > limited of use cases.
> >
> >
> > On Wed, May 7, 2014 at 9:20 AM, Curtis Hovey-Canonical <
> cur...@canonical.com
> > > wrote:
> >
> > > On Tue, May 6, 2014 at 9:53 PM, Andrew Wilkins
> > >  wrote:
> > > > A bit tangential now, but...
> > > >
> > > > Plugin-style was originally how I thought it would best work, but
> that
> > > > requires distribution with both jujud *and* the juju CLI. That sounds
> > > like a
> > > > nightmare to me. OTOH, having a remote service means you can just
> point
> > > the
> > > > CLI and jujud at that remote service with nothing to distribute. It
> does
> > > > mean having a service, which brings its own set of issues.
> > > >
> > > > Of course, the two approaches are not mutually exclusive. As you
> say, you
> > > > could easily provide a plugin that talks to a remote service.
> > >
> > > Oh.  I think we already have this problem. Windows users cannot
> > > backup, restore or generate metadata because they only have the juju
> > > CLI binary installed.
> > >
> > > OSX users may have the current plugins since juju was built by brew,
> > > but I have not tested they work.
> > >
> > > --
> > > Curtis Hovey
> > > Canonical Cloud Development and Operations
> > > http://launchpad.net/~sinzui
> > >
> > > --
> > > Juju mailing list
> > > Juju@lists.ubuntu.com
> > > Modify settings or unsubscribe at:
> > > https://lists.ubuntu.com/mailman/listinfo/juju
> > >
>
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Academy

[Nate Finch]

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 init', you may await my PR
>
> On Wed, May 7, 2014 at 6:24 PM, Gustavo Niemeyer 
> wrote:
> > This is _extremely_ cool, Marco. Very well done!
> >
> > One tiny suggestion, for anyone interested in contributing: it would
> > be great to have "ls [-la]" at some point. That's the first thing most
> > people will type when seeing a prompt, and gives them room for
> > navigating to the juju configuration directory.
> >
> > On Wed, May 7, 2014 at 1:16 PM, Marco Ceppi  wrote:
> >> Hi everyone!
> >>
> >> I was trying to keep this under wraps as I worked on it more before
> >> announcing to the world but I'm too excited with the progress so far so
> >> here's the "SUPER ALPHA BETA OMEGA" introduction to Juju Academy.
> >>
> >> I started this, http://juju.academy (http://learnjuju.com) based on my
> own
> >> experiences when trying new software. Primarily modeled after the Learn
> Go
> >> Lang webiste (http://tour.golang.org/) I set out to create an easy
> platform
> >> that emulates a terminal environment and allows a user to try Juju
> before
> >> ever having to install it. In addition I wanted to make a lightweight
> lesson
> >> framework to help guide new users in this exciting new Service
> Orchestration
> >> paradigm. Finally, the last goal of this project was to build an easy to
> >> embed module that could live in the docs to provide very lightweight
> >> terminal sessions that users could use to review what portions of the
> docs
> >> they were reading.
> >>
> >> Right now I've modeled just a hand full of lessons and only a few of the
> >> juju commands have actually been implemented. As this is a spare time
> >> project progress comes in chunks of time over the weekend and in the
> >> evenings. However, if you're interested in piloting the demoware and
> shaking
> >> out bugs please do so! You can view the lessons at http://juju.academythe
> >> source code is https://github.com/marcoceppi/juju-academy and the issue
> >> tracker is on that repo.
> >>
> >> Your juju environment(s) persist not only between lessons but also
> between
> >> page visits. If at anytime you wish to start anew you can do so by
> issuing
> >> the "reset" command in the terminal. I'm working on finishing
> >> http://help.juju.academy which will have this and other FAQ/Guide like
> >> questions to use the software. All Juju help can be found, as always, at
> >> https://juju.ubuntu.com/docs
> >>
> >> This is also a call for help! Anyone interested in writing lessons,
> command
> >> modules, fixing bugs, making this look nicer, etc - pull requests are
> >> welcome! The entire project aims to be modular (in that this framework
> could
> >> be used for non juju terminal lessons). Lessons are simply JSONP files
> that
> >> contain a set number of keys and commands are functions that perform
> some
> >> rudimentary validation.
> >>
> >> I eagerly await feedback and have had an immense amount of fun working
> on
> >> this so far! I'll likely follow up with a more official announcement
> when
> >> more of the commands have been implemented.
> >>
> >> Thanks,
> >> Marco Ceppi
> >>
> >> --
> >> Juju mailing list
> >> Juju@lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/juju
> >>
> >
> >
> >
> > --
> >
> > gustavo @ http://niemeyer.net
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
>
> --
> Nick Veitch
> nick.vei...@canonical.com
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: arch constraint default changed?

[Nate Finch]

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 --arch amd64
to get amd64 machines in the cloud.

On Mon, May 12, 2014 at 1:50 PM, John Meinel  wrote:

> https://bugs.launchpad.net/ubuntu/+source/juju-core/+bug/1304407
>
> It should be fixed in 1.18.3.
> John
> =:->
>
>
>
> On Mon, May 12, 2014 at 9:36 PM, Henning Eggers  wrote:
>
>> Hi!
>>
>> I just noticed that I now have specify the arch constraint if I want amd64
>> instances. Without it, I get i386 instances. "juju help constraints" still
>> tells me that amd64 is supposed to be the default.
>>
>> I am using juju 1.18.2 on EC2, precise on the instances, trusty on my
>> workstation.
>> Has this since been fixed? Or is it an intentional change and the help
>> page is
>> outdated?
>>
>> Cheers,
>> Henning
>>
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: arch constraint default changed?

[Nate Finch]

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

I didn't want the local arch have any influence on the arch we pick, unless
the user uses --upload-tools, because as Gustavo said, where I'm sitting
right now shouldn't affect what architecture my cloud uses.

Honestly, the reason I didn't code the fix to take --upload-tools into
consideration is because that was going to be more complicated and I didn't
have time for it (the fix I made was tiny and quick).  Perhaps that was a
misjudgment, and perhaps if we had moved the question to the mailing list
it would have become obvious the time would be worth it.

If people think it's worth it, we can just go ahead and make the right fix
to use the local arch only when we use --upload-tools, but it still doesn't
help us with the problem of which one we pick if they don't use upload
tools, and multiple arches are available.  What logic would people
recommend?  I don't think alphabetical is really the best choice, though at
least it's deterministic, unlike "take whatever happens to be listed first"
which is what we seemed to be doing before.


On Tue, May 13, 2014 at 8:17 AM, Gustavo Niemeyer wrote:

> On Tue, May 13, 2014 at 8:18 AM, John Meinel 
> wrote:
> > FWIW, I've gotten bug requests from a user that did a regular bootstrap
> and
> > then was trying to "juju upgrade-juju --upload-tools" and was confused
> that
> > his local machine wasn't able to upgrade tools for his environment. (he
> was
> > running i386 locally, and bootstrap created an amd64 machine).
> > And while we desperately want to not expose --upload-tools in its current
> > incarnation, we haven't given an alternative for those use cases.
>
> There's nothing wrong with tweaking constraints if the application
> sees the --upload-tools option. At the same time, getting a bug from a
> user is not enough reason to tweak the defaults for everybody.
>
> > Also, while we have a reasonably clear model for "if you have the choice
> > between amd64 and i386 pick amd64", I don't think people disagree with
> that.
> > But what if you have the choice between amd64 and ppc64le and the client
> is
> > running on ppc64le? Is it likely that they are actually thinking in a ppc
> > world?
>
> I don't see how that logic holds. Using an arm laptop as a client does
> not imply I want to use all my server deployments on arm. The same
> holds true for the operating system, or to the Ubuntu series, or to
> pretty much anything else: I would not expect the tool to deploy a
> completely different environment based on where I'm sitting this
> second.
>
> > We certainly had a lot of discussions around this between Nate and
> myself,
> > and while I think I was reasonably convinced that we could just pick
> amd64
> > if it was an option, it seems he was also reasonably convinced that we'd
> > want to use the client arch if available. (He wrote it as "just pick
> amd64",
> > I argued against it but ended up feeling it was a reasonable pick among
> > alternatives, but then he changed it before landing.)
>
> If I had the chance, I would submit these kinds of decisions to the
> development mailing list, rather than arbitrating it back and forth in
> isolation like that. This is changing the default behavior for
> everybody, so sending it for the team's appraisal feels cheap.
>
>
> gustavo @ http://niemeyer.net
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju on Reddit

[Nate Finch]

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 STANFORD  wrote:
>
>> On Tue, May 20, 2014 at 04:25:47PM +0100, Matthew Williams wrote:
>>
>>> We now have a subreddit for posting topics about juju:
>>>
>>> http://www.reddit.com/r/juju
>>>
>>> I'm looking for volunteers who would like to help with being moderators.
>>>
>>
>> If you get no helpers, I'll signup.
>>
>> http://www.reddit.com/user/Rinchen/
>>
>> You should do what they did in /r/Ubuntu and add Canonical and Ubuntu
>> flairs.
>>
>> Joey
>>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju bootstrap error

[Nate Finch]

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 hope this error is
> temporary.
>
> On Wed, May 21, 2014 at 7:32 PM, boyd yang  wrote:
> > Hello,
> >
> > Juju bootstrap gives below error:
> > ...
> > bridge-utils is already the newest version.
> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > rsyslog-gnutls is already the newest version.
> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > Reading package lists...
> > Building dependency tree...
> > Reading state information...
> > juju-mongodb is already the newest version.
> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> > curl: (56) SSL read: error::lib(0):func(0):reason(0), errno 104
> > tools from
> https://streams.canonical.com/juju/tools/releases/juju-1.18.3-trusty-amd64.tgz
> > downloaded: HTTP 200; time 1471.629s; size 7094272 bytes; speed
> > 4820.000 bytes/s 2014-05-21 08:29:45 ERROR juju.provider.common
> > bootstrap.go:123 bootstrap failed: rc: 1
> > Stopping instance...
> > 2014-05-21 08:29:45 ERROR juju.cmd supercommand.go:305 rc: 1
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: juju bootstrap error

[Nate Finch]

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 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 hope this error is
>> temporary.
>>
>> On Wed, May 21, 2014 at 7:32 PM, boyd yang  wrote:
>> > Hello,
>> >
>> > Juju bootstrap gives below error:
>> > ...
>> > bridge-utils is already the newest version.
>> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> > Reading package lists...
>> > Building dependency tree...
>> > Reading state information...
>> > rsyslog-gnutls is already the newest version.
>> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> > Reading package lists...
>> > Building dependency tree...
>> > Reading state information...
>> > juju-mongodb is already the newest version.
>> > 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> > curl: (56) SSL read: error::lib(0):func(0):reason(0), errno 104
>> > tools from
>> https://streams.canonical.com/juju/tools/releases/juju-1.18.3-trusty-amd64.tgz
>> > downloaded: HTTP 200; time 1471.629s; size 7094272 bytes; speed
>> > 4820.000 bytes/s 2014-05-21 08:29:45 ERROR juju.provider.common
>> > bootstrap.go:123 bootstrap failed: rc: 1
>> > Stopping instance...
>> > 2014-05-21 08:29:45 ERROR juju.cmd supercommand.go:305 rc: 1
>> >
>> > --
>> > Juju mailing list
>> > Juju@lists.ubuntu.com
>> > Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Tool for deploying Juju on private OpenStack

[Nate Finch]

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 12, 2014 at 1:06 PM, Zygmunt Krynicki <
zygmunt.kryni...@canonical.com> wrote:

> On Fri, Sep 12, 2014 at 6:45 PM, Matthew Williams
>  wrote:
> > Nice tool Ian,
> >
> > You might also be interested in the cloud installer.
> > https://github.com/Ubuntu-Solutions-Engineering/cloud-installer
>
> Is it the time when we should just have github.com/canonical and
> github.com/ubuntu so that we don't need go google for our company's
> code?
>
> Thanks
> ZK
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: I gave a quick writeup over Juju on Digital Ocean

[Nate Finch]

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 when we can make a real provider for Digital Ocean,
and I can take out that "relatively" part :)

On Mon, Sep 22, 2014 at 11:42 AM, Charles Butler <
charles.but...@canonical.com> wrote:

> http://blog.dasroot.net/juju-digital-ocean-awesome/
>
> Juju on Digital Ocean, WOW! That's all I have to say. Digital Ocean is one
> of the fastest cloud hosts around with their SSD backed virtual machines.
> To top it off their billing is a no-nonsense straight forward model. $5/mo
> for their lowest end server, with 1TB of included traffic. That's enough to
> scratch just about any itch you might have with the cloud.
>
> Speaking of scratching itches, if you haven't checked out Juju yet, now
> you have a *prime, low cost cloud provider* to toe the waters. Spinning
> up droplets with Juju is very straight forward, and offers you a hands on
> approach to service orchestration thats affordable enough for a weekend
> hacker to whet their appetite. Not to mention, Juju is currently the #1
> project on their API Integration listing! http://goo.gl/m6u781
>
> In about 11 minutes, we will go from zero to deployed infrastructure for a
> scale-out blog (much like the one you're reading right now).
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: request for mirror all charms from jujucahrms to github

[Nate Finch]

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, "Vasiliy Tolstov"  wrote:
>
>> 2014-10-07 18:02 GMT+04:00 José Antonio Rey :
>> > As far as I know, the github mirror is a one-way mirror. Having it as a
>> > two-way mirror is something a bit more complicated and that would have
>> some
>> > other implications. Probably some discussion around before proceeding
>> would
>> > be better.
>>
>>
>> Yes, but as i see that juju moved to github i thinks that all charms
>> migrated to.
>> Github provides beautiful interface for issues and automatic merges
>> (also supports hooks to jenkins and other ci)..
>>
>> --
>> Vasiliy Tolstov,
>> e-mail: v.tols...@selfip.ru
>> jabber: v...@selfip.ru
>>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: proper way to deploy to one server (lxc based)

[Nate Finch]

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 <
andrew.wilk...@canonical.com> wrote:

> On Wed, Oct 8, 2014 at 11:33 AM, Vasiliy Tolstov 
> wrote:
>
>> 2014-10-08 10:35 GMT+04:00 Andrew Wilkins :
>> > Not as a first-class citizen in Juju. There's
>> > https://github.com/cmars/juju-nat, but I've just spoken to the author
>> who
>> > informs me that it currently has some issues.
>> >
>>
>> Thanks!
>> >>
>> >> Or does it possible to install for example http proxy charm on node 0
>> >> that route all needed traffic to containers... ?
>> >
>> >
>> > That should work. Deploy ha-proxy to machine 0 and relate it to nginx.
>>
>> Hm, but juju can't deploy to machine 0, does it possible via relation
>> system configure ha-proxy on machine 0 to serve to container nginx ?=)
>
>
> Sorry, I don't understand. Juju can deploy to machine 0 on everything
> other than the local provider, which is intended for development
> environments.
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Where is the Juju-gui heading ?

[Nate Finch]

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 that in the charm's configuration.  The work is not yet underway but
should be starting very soon.

I'll have to let the GUI guys answer the rest of the questions, but figured
I could at least answer that part.

On Wed, Nov 12, 2014 at 10:57 AM, Stein Myrseth 
wrote:

> In earlier versions of the Juju-gui it was easy and simple to deploy a
> charm, by just dragging and dropping it into the canvas and hit commit.
>
> With the latest versions the same process it is no more intuitive how to
> deploy anymore. I hit “confirm” and “commit” and nothing happens. I have
> create a machine first, or auto place, or add the constraints or as part of
> the unit configuration, or as part of the machine configuration to create a
> machine and assign the unit etc. And the approach is different if I do it
> from the CLI and UI.
>
>  To me this set the focus on two things. There will be two very distinct
> different user groups using Juju with different requirements.
>
> 1) A charm designer/developers want to expose options for configuration
>
> 2) A charm consumer, want to add a “service” to his or her deployment and
> is interested in a “serious relationships” :-)
>
>  The first category has all the data, info and knows all requirements
> needed for the charm regarding constraints etc.
>
> The constraints are a part of my frustrations here. Today constraints are
> detached from the charm, which to me does not make sense regarding the two
> different target user groups. It’s detached in the UI on creation, but can
> be assigned from the CLI, and also copied as a constraint on export.
>
>  As a charm developer I would very much like to see the support of adding
> the constraints like RAM, cores etc. as part of the charm config itself.
> This could be added to either the config.yaml or in a separate
> constraints.yaml file as an option.
>
>  In this way as a charm developer I have an option to enforce the
> constraints on deployment, either using the CLI or the UI. It could be easy
> to check on deployment (as done when deploying bundles) if there is
> available machine resource matching the constraints or if the user would
> like a new machine matching the constraints to be created automatically.
> The deployment part has become to complex, and involved to many steps for
> the charm consumer. For the consumer the machines, assigned units, where
> etc. are completely secondary. The consumer is looking for storage, db
> proxy service relation without the need to learn how Mongodb works. Thats’s
> my focus.
>
>  So as
>
> 1) As a charm developer I need a way to make the constraints of my charms
> consistent across the different way of deploying.
>
> 2) As a charm consumer I don’t care about machines, only services and the
> relationships provided and deploying should be simple.
>
> What is the future plans and directions for the the UI, define constraints
> and the easy of deployments ?
>
> Stein Myrseth
> Bjørkesvingen 6J
> 3408 Tranby
> mob: +47 909 62 763
> mailto:stein.myrs...@gmail.com 
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: machine state stuck at "pending"

[Nate Finch]

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.20.1 on a test maas cluster. Every now and then when
> I run juju add-machine the machine gets stuck at "pending" state
> (permanently). Maas shows status as "Failed deployment".
> > Is there a way to force machine state to error so I can
> retry-provisioning on it? I don't want to destroy it as I have some service
> deployment scripts that rely on machine number (using --to # deployment
> option).
> > Appreciating your help.
> >
>
> Hi Sameer
>
> A range of those 'pending' container issues were fixed during the set of
> releases from 1.20.1 to 1.20.11. I think it would be worth your updating
> to the latest 1.20 release. If you're on Ubuntu, add this to your
> /etc/apt/sources.list:
>
>deb http://ppa.launchpad.net/juju/stable/ubuntu trusty main
>
> That should give you 1.20.11.
>
> Let us know if you still see any issues with containers getting stuck on
> the way up. Also, it's a great idea to be able to nuke-and-retry in the
> event that this does happen, I'll find out if we have a nice way to add
> that regardless (a stuck container might happen thanks to cosmic rays,
> we should have an escape mechanism). Ideally, Juju should detect the
> issue and nuke the container, trying again on your behalf.
>
> Mark
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Lets version lock the docs!

[Nate Finch]

+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
> are consistent across platforms, it's inevitable that users will be on
> different versions. As more features land in juju, documentation will
> become inconsistent for users. This, again, is a topic that has undergone
> quite a bit of discussion from when the docs were originally migrated to
> Markdown at various UDS and vUDS meetings what I'd like to do is get the
> ball moving on completing this: offering multiple version of the docs for
> released version of juju.
>
> The proposal is as follows. The juju docs repository will continue to have
> a "master" branch which will be "tip of trunk" for juju and documentation
> bits, essentially "devel". As the release team gears up for a release we
> will create a branch for that release milestone (1.20, 1.21, 1.22, etc).
> From there, the jujucharms.com/docs website will offer latest release as
> default view (ie: jujucharms.com/docs/getting-started) and a drop down to
> select previous versions of docs, which will be available at docs/VERSION
> (ie: jujucharms.com/docs/1.21/getting-started).
>
> Any issues, typos, or mistakes that need to be addressed and previous
> versions of the docs can take place in that branch and will continued to be
> built periodically with the rest of the doc. We're pretty confident this
> model will work out great for those writing the docs, not wanting to land
> fixes too soon while improving overall user experience in reading the
> documentation.
>
> Ideally, we'd like this to coincide with the next juju release, 1.21, so
> before that lands we'd like to call for feedback about the process outlined
> above, concerns, or questions.
>
> [0]: http://packages.ubuntu.com/search?keywords=juju
>
> Thanks,
> Marco Ceppi
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What's the future of Juju?

[Nate Finch]

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 couple
years... I forget exactly the numbers we're at now, but it's an order of
magnitude more people working on Juju than there were just a couple years
ago.

Juju is used *extensively* internally at Canonical.  We have a mandate that
all internal services be deployed via Juju.

As far as supporting other operating systems, we actually do support
Windows, right now (though it can be a little tricky to set up, and
generally only works on private clouds, due to licensing restrictions on
distributing Windows images).  See here:
http://www.cloudbase.it/windows-with-juju-and-maas/   (Cloudbase partnered
with us to get Juju working with Windows)

Cloudbase is also currently tackling CentOS support.  It currently works
and is just being cleaned up, it should be available for testing in a few
weeks.

The number of features that have landed in the last year is tremendous -
high availability, networking, storage, major improvements in the GUI,
support for more clouds (Google Cloud Compute support is coming out with
1.23, which is due any day now), Windows support, backup and restore

As for bugs, there are bugs in every product, especially new and rapidly
expanding products, like Juju.  If there are particular bugs that concern
you, we'd be happy to look into them.  We try to make sure that we fix
anything that is a regression or would majorly hinder usage we do use
this internally after all, so believe me, we hear about it when things
aren't working well! :)

I'm sorry you find the documentation lacking. We have been putting effort
into that recently.  I, personally, am a big fan of extensive
documentation, and I know our documentation is not nearly as extensive as
it could be.

I can't personally talk about big companies using Juju... I know we have
several very large companies doing very large installations, but I don't
think anything is public about that.  Hopefully someone else can bring up a
list of people using Juju.

Hope that answers at least some of your questions.


On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi
>
>
> I'm interested in what the future of Juju is. From the small experience
> I've had with it, it seems like a product with a lot of potential. It fills
> a gap in our project that no other technology can fill. Its biggest
> strength is how relations between services are managed. This is something
> that, to my knowledge, does not exist in any tool today. It enables a very
> modular approach and solves a lot of problems we would have with other
> tools.
>
> However, I've also seen some things that worry me. Even after three years,
> there are still a lot of bugs in the project. The documentation is lacking,
> especially in the parts of Juju that are the most competitive. The
> community is also very small. The fact that it can still only manage Ubuntu
> servers worries me too. I could go more into detail here, but I don't think
> it is relevant to this question.
>
> I'm considering starting a big long-term project on top of Juju. The
> project would be very dependent on Juju, so I don't want to do this if
> there is a chance that Juju will be abandoned in 5 years...
>
> What can you tell me about the future of Juju? Things I'm interested in:
>
> - Big companies building services on top of Juju
>
> - Statements of long-term commitment from Canonical
>
> - Usage statistics
>
> - Statements of commitment to support other distro's
>
> - .. or else, signs that Juju doesn't have a bright future.
>
>
> Thanks
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: What's the future of Juju?

[Nate Finch]

I wanted to specifically thank you for pointing out the bugs that affect
you. It's a huge help in prioritizing what we work on.



On Wed, Mar 25, 2015 at 5:24 PM, Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Thanks for your answer! I didn't know Windows and Centos support was
> coming so soon, great to know!
>
> The lacking documentation is the biggest issue to me. The charm-helpers
> documentation is outdated in a lot of places and that makes it seem as it
> isn't being actively maintained anymore. Ofcourse, this is a side-effect of
> a rapidly expanding product...
> The charm-helpers documentation also lacks some good examples and
> "guidelines". Things like "What's the best way to create templates, What's
> the easiest way to get relation data, ..". The documentation shows you how
> to do it in bash, but is really lacking for python. I had a really hard
> time trying to decipher how the services framework works exactly. Then
> again, this is probably also partly due to the fact that I'm still learning
> my way around python.
>
>
> As for the bugs. I submitted/"affects me" a few:
> Critical:
> https://bugs.launchpad.net/juju-deployer/+bug/1434458
>
> Medium:
> https://bugs.launchpad.net/charm-tools/+bug/1433035
> https://bugs.launchpad.net/juju-core/+bug/1415176
> https://bugs.launchpad.net/juju-core/+bug/1429790
> 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-25 21:32 GMT+01:00 Nate Finch :
>
>> 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
>> couple years... I forget exactly the numbers we're at now, but it's an
>> order of magnitude more people working on Juju than there were just a
>> couple years ago.
>>
>> Juju is used *extensively* internally at Canonical.  We have a mandate
>> that all internal services be deployed via Juju.
>>
>> As far as supporting other operating systems, we actually do support
>> Windows, right now (though it can be a little tricky to set up, and
>> generally only works on private clouds, due to licensing restrictions on
>> distributing Windows images).  See here:
>> http://www.cloudbase.it/windows-with-juju-and-maas/   (Cloudbase
>> partnered with us to get Juju working with Windows)
>>
>> Cloudbase is also currently tackling CentOS support.  It currently works
>> and is just being cleaned up, it should be available for testing in a few
>> weeks.
>>
>> The number of features that have landed in the last year is tremendous -
>> high availability, networking, storage, major improvements in the GUI,
>> support for more clouds (Google Cloud Compute support is coming out with
>> 1.23, which is due any day now), Windows support, backup and restore
>>
>> As for bugs, there are bugs in every product, especially new and rapidly
>> expanding products, like Juju.  If there are particular bugs that concern
>> you, we'd be happy to look into them.  We try to make sure that we fix
>> anything that is a regression or would majorly hinder usage we do use
>> this internally after all, so believe me, we hear about it when things
>> aren't working well! :)
>>
>> I'm sorry you find the documentation lacking. We have been putting effort
>> into that recently.  I, personally, am a big fan of extensive
>> documentation, and I know our documentation is not nearly as extensive as
>> it could be.
>>
>> I can't personally talk about big companies using Juju... I know we have
>> several very large companies doing very large installations, but I don't
>> think anything is public about that.  Hopefully someone else can bring up a
>> list of people using Juju.
>>
>> Hope that answers at least some of your questions.
>>
>>
>> On Wed, Mar 25, 2015 at 4:01 PM, Merlijn Sebrechts <
>> merlijn.sebrec...@gmail.com> wrote:
>>
>>> Hi
>>>
>>>
>>> I'm interested in what the future of Juju is. From the small experience
>>> I've had with it, it seems like a product with a lot of potential. It fills
>>> a gap in our project th

Re: New Docker goodies

[Nate Finch]

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
> local provider.
>
> - https://registry.hub.docker.com/u/whitmo/jujubox/
> - https://github.com/whitmo/jujubox
>
> And here's the new bits, Cory Johns has been working on making a juju
> docker container that is more useful for charm developers and testers
> (so it's a bit larger than the jujubox)
>
> - https://registry.hub.docker.com/u/johnsca/charmbox/
> - https://github.com/juju-solutions/charmbox
>
> Again the limitation is you can't use the local provider, however if
> you're testing on public clouds then you should see dramatic workflow
> speed vs. using the vagrant boxes.
>
> PRs and feedback all welcome!
>
> --
> Jorge Castro
> Canonical Ltd.
> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Plugin] sync-watch: Edit locally, run in the cloud

[Nate Finch]

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 development workflow.
>
> Once the Juju Plugins bundle (https://github.com/juju/plugins) is
> installed, you can now run `juju sync-watch ` to enable local
> editing of a remote charm.  This works using inotify to watch for
> changes in the local copy of the charm and automatically sync those
> changes up to the deployed unit.  If the unit is in an error state, it
> will also automatically retry the failed hook, so that you can do
> fast, seamless iteration on a charm.
>
> This plugin works with any provider and any editor.
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Juju Documentation - what can we improve?

[Nate Finch]

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 list to ask
you.  Where is Juju documentation lacking?  Where can we best spend our
time to make the most impact?

Any and all feedback - from the newest user just starting with Juju to the
most grizzled veteran - it's all helpful to us.

By providing feedback about the docs, you can help your future selves, and
all future users of Juju.  If you haven't looked at the docs lately, please
take a look, and let us know what we can do better.

Please keep in mind that this is not just a question of fixing up what's
there... improvements can include adding more in-depth information, adding
information in different formats, adding case-studies, use cases, best
practices, etc.

Thanks for your help!
-Nate Finch
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: gocharm or harm.v5 how to get charm dir?

[Nate Finch]

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, 2015 at 2:35 PM, Vasiliy Tolstov  wrote:

> Does it possible to determine charm dir using go bindings?
> I need absolute path to charm dir to get files from assets dir in
> various places in my code.
>
> --
> Vasiliy Tolstov,
> e-mail: v.tols...@selfip.ru
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju Compose

[Nate Finch]

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
metadata, this seems fine, but those don't seem like the difficult parts of
branching from a source charm either.  I guess my point is, this seems like
it's doing a lot of what version control already does.

On Fri, Jul 10, 2015 at 2:22 PM Benjamin Saller <
benjamin.sal...@canonical.com> wrote:

> Charm Composition is a small tool facilitating a new pattern for
> developing and maintain Juju Charms. In its simplest form it lets you
> combine directories, called Layers, of files to create a charm. Rather than
> just copying files around however it keeps track of which files came from
> which Layer so that at a later time the process can be run again. This
> means that if any of the Layers have changed those bits will be reflected
> in the newly regenerated charm.
>
> Imaging that you have a charm you’ve forked to add some simple tweak or
> customization. You might be able to maintain your changes in a new Layer
> allowing the base you depend on to continue to evolve.
>
> Suppose we have layer ‘a’.
>
> trusty/a/
>
> ├── hooks/install
>
> ├── metadata.yaml
>
> └── README.md
>
> And a layer ‘b’
>
> trusty/b/
>
> ├── hooks/db-relation-changed
>
> ├── composer.yaml
>
> ├── metadata.yaml
>
> └── README.md
>
> If ‘b’ included ‘a’ (specified in the composer.yaml file) then composer
> might combine the layers in the following way.
>
> trusty/b/
>
> ├── hooks/install
>
> ├── hooks/db-relation-changed
>
> ├── composer.yaml
>
> ├── metadata.yaml
>
> └── README.md
>
> That is just a ‘cp -r’ you’re saying, and it would be except the compose
> process is able to support a variety of methods for combining layers. By
> default compose knows about Charm specific files like metadata.yaml and
> config.yaml it is able to combine them in sensible ways. For files like
> this the default is a merge with the ability to remove add/replace keys
> within the data of the file in the lower layer (in this case ‘a’ would be
> overridden if it had a key in common with ‘b’ when composed).
>
> Composer itself is extensible so if you’re layers need special rules
> associated with how certain types of files should be combined there is an
> interface for doing that.
>
> Composer has code for doing much more interesting things than just
> combining layers, but we can save that for another post. If you’re
> interested in this now and want to start thinking about what nice base
> layers might look like, check it out at
> https://github.com/bcsaller/juju-compose
>
>
>
> Thanks,
> Ben
>
> There is more that should be said about how this relates to the work with
> Relation Stubs and so on but that can be another thread.
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Compiling juju on openSUSE

[Nate Finch]

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 mercurial is no longer
required at this point, though).
install go, version 1.2.1 or higher (1.2.1 is the officially supported
version for Juju... newer versions *should* work, but are not official yet).

export GOPATH=$HOME
this tells go where to store its code, you could pick a different
gopath if you want.

run these commands to compile juju's master branch:

go get github.com/juju/juju/...
this will download and compile juju, but there may be a couple compiler
errors... that's ok
go get launchpad.net/godeps
this will download and compile the godeps application, and copy it to
$GOPATH/bin
cd $GOPATH/src/github.com/juju/juju
$GOPATH/bin/godeps -u dependencies.tsv
this will update the various repos that juju uses to the correct
versions (and thus fix the compiler errors from above)
go install ./...
this will recompile with the newly updated juju code and copy the juju
and jujud binaries to $GOPATH/bin

You can, of course, use git to switch from the master juju branch to a
release branchand compile that instead.  Just do that in $GOPATH/src/
github.com/juju/juju before running godeps, and then follow the rest of the
steps.

-Nate

On Fri, Sep 18, 2015 at 1:35 PM Herman Bergwerf 
wrote:

> Anyone who has experience compiling juju on openSUSE?
> I'm an openSUSE users myself and I wanted to use the juju client on
> openSUSE. Everything worked out until I came to make install-dependencies
> because there are Ubuntu/Debian commands in the Makefile. Is it possible to
> compile juju on openSUSE and is there someone who could give me some leads
> for this?
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju on multiple public clouds

[Nate Finch]

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
full support of more than one cloud provider in the same environment...
like no ability to automatically spin up or destroy the manually added
machines).  To do the import, use juju add-machine ssh@ipaddress to add the
machine to the current environment.

That being said, as Jose said... if you just want to have a collection of
AWS machines talk to each other and a separate collection of Azure (or
whatever) machines talk to each other (without being able to talk Azure <->
AWS) then you can create them as separate environments and that works fine.

On Fri, Sep 18, 2015 at 1:06 PM José Antonio Rey  wrote:

> Yes. Just set up different environments in your environments.yaml file,
> and then you can switch between them using juju switch.
>
> On 09/18/2015 12:28 PM, Herman Bergwerf wrote:
> > Is it possible to run juju across multiple public (/private) clouds? For
> > example, you can run juju on AWS and select different regions but can
> > you also run juju on AWS and GCP?
> >
> >
>
> --
> José Antonio Rey
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Juju on CloudStack

[Nate Finch]

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 18/09/15 17:27, Herman Bergwerf wrote:
> > Hmm, ok. I'm quite surprised a pretty widely used virtualization stack
> such
> > as cloudstack is not implemented in juju at all. Are there maybe future
> > plans to do this?
>
> Anybody can write a cloud provider and contribute it to Juju. Canonical
> will usually write one as part of the certification process for a large
> public cloud (like AWS, Google, Azure) but I'm not aware of any large
> CloudStack clouds so it's not on our roadmap. Of course we'd gladly land
> the work if someone else does it.
>
> > By the way, wouldn't it be easier to write a provider directly inside the
> > juju code? I'm not sure if there is any documentation to do this.
>
> Yes, a "proper" provider is built-in to juju-core and lives in the Go code
> of Juju itself.
>
> As a limited workaround, you can use the Juju client plugin mechanism to
> automate some of the "manual" provider work. Essentially, you use your
> local cloud tools to launch machines, then register them with Juju
> controller using the manual provider mechanisms. If you want to dig into
> Go programming, then a cloudstack provider would be a good project. You
> would be copying the structure of the OpenStack, GCE, Azure, or AWS
> provider, then using the cloudstack operations to do what's necessary
> there. A main question would be whether or not their is already an
> implementation of the cloudstack API in Go.
>
> Mark
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Which JUJU_DEV_FEATURE_FLAG were used?

[Nate Finch]

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 there a way to tell which
> JUJU_DEV_FEATURE_FLAGs were used to bootstrap it?
>
> I'm using 1.24.6
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Call for Feedback: LXD local provider

[Nate Finch]

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 provider didn't create a container for
  the bootstrap node, it used your local machine as the bootstrap node.
  2. The lxd provider doesn't dump junk all over your local machine,
   because it puts the bootstrap node in a container
  - This makes it a lot more robust, and means you never have to worry
  about your lxd environment munging anything on your machine (or
vice versa)
   3. The local provider required that you install a ppa that installed a
   special version of mongo on your machine.
  - The lxd provider does not require this because of #2.
  4. The local provider required sudo credentials at bootstrap because
   of #2.
  - the lxd provider does not require sudo
   5. The local provider was special in a lot of terrible ways.
  - The lxd provider is considerably less special, and in general just
  works like any other provider, which means fewer WTF moments.  Treat it
  basically like you would any other remote provider.

There may be some benefits I'm forgetting, but figured I'd put these out
there.

On Thu, Jan 7, 2016 at 1:33 PM Adam Israel 
wrote:

> This sounds amazing. I’ve been looking forward to this for a while, to see
> how we can optimize the developer workflow under Vagrant. I’ll get a VM
> spun up and see how it looks!
>
> Adam Israel - Software Engineer
> Canonical Ltd.
> http://juju.ubuntu.com/ - Automate your Cloud Infrastructure
>
> > On Jan 7, 2016, at 12:48 PM, Jorge O. Castro  wrote:
> >
> > Hi everyone,
> >
> > Katherine walked me through using the new LXD provider in the Juju
> > Alpha: https://linuxcontainers.org/lxd/
> >
> > The one caveat right now is that you need to be on wily or xenial as
> your host.
> >
> > We are collecting feedback here along with the current working
> > instructions:
> https://docs.google.com/document/d/1lbh3ZkkSdBOGRadF_6FWrijbOhH4Vf2f7alrZFr8pz0/edit?usp=sharing
> >
> > Here are my initial results:
> >
> > - This is really, really fast.
> > - I was able to `juju deploy bundle/realtime-syslog-analytics`. Since
> > Juju now natively also supports bundles that's one less thing I needed
> > to worry about. It all just worked.
> >
> > This got me a working spark stack with 9 containers (+1 for the state
> > server) in about 10 minutes on my Thinkpad X230. And since the bundle
> > has proper status it was all just a really nice experience from both a
> > performance and observability standpoint.
> >
> > If you are developing charms then I think you should really
> > investigate making a xenial/wily machine with ppa:juju/devel part of
> > your workflow as soon as you can, I cannot overstate what an
> > improvement this is over the older lxc local provider.
> >
> > Note that the bundle I happened to pick does do a bunch of remote
> > fetching, so I am interested in seeing how deploys work for you
> > speed-wise with this vs. the old local provider. Feedback and bug
> > reports gladly welcome!
> >
> > --
> > Jorge Castro
> > Canonical Ltd.
> > http://jujucharms.com/ - The fastest way to model your service
> >
> > --
> > Juju mailing list
> > Juju@lists.ubuntu.com
> > Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Sending binaries over relations

[Nate Finch]

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 to know how to use the client library)... so why not just put
that static API on the server? and then you don't need a different client.
Obviously, you can distribute new clients with new functionality, but by
definition, you'd need new code in the client charm to understand how to
use that functionality.

On Thu, Jan 21, 2016 at 8:55 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> wrote:

> Hi Mark
>
>
> I understand your concern. Leaking operational details is something that
> should not be done in Juju. Apache proxy relationship cannot be implemented
> by Nginx because the relation leaks operational details (apache specific
> config files). This is not 'the Juju way'.
>
> The reason for sharing resources actually is interoperability. Say a
> client wants to connect to a server, then the client may need libraries to
> do that. What libraries will be used is dependent on both the client and
> the server. If you ship the libraries with the client, you are essentially
> hard-coding the server version. This is also not the Juju way; information
> like this should be passed over relations. The problem here is that both
> Charms have to make a joint decision about what libraries, if any, to use
> and where to get them. No Charm has full knowledge to make that decision.
>
> I've seen two common patterns in the wild for these kind of libraries:
>
> 1. The client uses its own libraries compiled for that specific version of
> the server.
> 2. The client uses libraries bundled with the server.
>
> The first case is easy: The client has full knowledge about where to get
> the libraries. It only needs to know the server version. The server tells
> the client his version and it's done. The second case is a little bit
> tougher. The client has knowledge about what libraries it needs, but the
> server has knowledge about where to get those libraries. In this case, the
> client should request the libraries from the server, and the server should
> have a way to send them to the client.
>
> If both cases are supported by the server, you can swap any client in and
> out. This also translates nicely to the idea that a Charm gets created by
> the person who is an expert in that service. The server experts know where
> to get the libraries if the server has to provide them. The client expert
> knows how to compile the libraries if the client has to compile them.
>
> What do you think?
>
>
>
>
> *PS: I don't think this should be done on stack level, since the shared
> libraries are only relevant to the two related Charms. The relevance of the
> libraries is on relation-level so they should be handled by the relations.*
>
>
>
>
> 2016-01-21 13:58 GMT+01:00 Mark Shuttleworth :
>
>>
>> Two thoughts.
>>
>> First, I think it's interesting that you see resources as such a dynamic
>> thing. I believe the current model accommodates this (we considered
>> user-provided resources, and what you are describing are essentially
>> charm-generated resources, but they would behave the same way).
>>
>> Second, I am sceptical about cross-charm resource coordination. We go to
>> great lengths to keep a service encapsulated. Each service is generally
>> prevented from knowing too much about what is going on in the service
>> next door. This is deliberate because it leads to the development of
>> services which can more naturally be swapped out, because the web of
>> expectations between related services is limited by what they can
>> possibly know about each other. What you are describing suggests too
>> intimate an awareness between two services of their exact operational
>> implementation.
>>
>> That said, we do have an idea in the "futures" department, which is a
>> higher-level charm that would manage a group of charms. While they would
>> remain encapsulated, the higher-level charm would have admin-like
>> visibility across all of the services it is supervising. Imagine an
>> "openstack" charm which can command-and-control events across all the
>> constituent services. In THAT case, yes, it would make sense for the
>> higher level charm, which we call a "stack", to be able to coordinate
>> resources across services under its supervision.
>>
>> How does that sound?
>>
>> Mark
>>
>> On 21/01/16 01:21, Merlijn Sebrechts wrote:
>> > Hi John, Mark
>> >
>> >
>> > If I understand you correctly, a Charm will be able to decide what
>> version
>> > of the resource it needs at runtime? This way, a Charm could tell
>> related
>> > Charms what version of the resource they should get? That would solve my
>> > use-case almost completely...
>> >
>> > The only exception being the case where a Charm compiles a library
>> during
>> > installation and wants to dis

Re: Introducing, juju resources!

[Nate Finch]

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:
>
>> Moonstone have been working hard on a new feature coming up in Juju 2.0
>> called "Juju Resources", and we're now at a point where we can share the
>> goodness and call for bugs/feedback! As noted in the video linked below,
>> the feature isn't quite complete, so expect some rough edges, and for some
>> of the CLI details to shift just a bit.
>>
>
> After watching the demo (thanks for sharing!) it struck me that use of the
> update-status hook to demonstrate this was pointing to a missing feature
> (IMHO).
>
> Is there a hook that fires when a resource is made available? If I have an
> install hook that requires a resource, I could make it transition to
> blocked when that resource is missing. But when that resource is provided,
> how do I know to try again?
>
> Thanks,
>
> Adam
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

New feature for charmers - min-juju-version

[Nate Finch]

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-juju-version specified, if the targeted model's Juju version is lower
than that specified, then the user will be shown an error noting that the
charm requires a newer version of Juju (and told what version they need).
The format for min-juju-version is a string that follows the same scheme as
our release versions, so you can be as specific as you like. For example,
min-juju-version: "2.0.1-beta3" will deploy on 2.0.1 (release), but will
not deploy on 2.0.1-alpha1 (since alpha1 is older than beta3).

Note that, at this time, Juju 1.25.x does *not* recognize this flag, so it
will, unfortunately, not be respected by 1.25 environments.

This code just landed in master, so feel free to give it a spin.

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

Re: Unfairly weighted charmstore results

[Nate Finch]

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 shows is due to using N-grams (3-N) in search and the ranking
> logic using that puts recommended charms over the non-recommended ones. And
> we're not only searching over names of charms but a bunch of content that a
> charm has.
>
> The system works relatively well for recommended charms if you know the
> name (or close to what name is), but not in cases where a name is long and
> the charm is only in community space. That's why you get better results
> with short query vs a longer one.
>
> We're working on providing better search results in the following weeks.
>
>
>
>
> On Thu, Mar 17, 2016 at 2:18 PM, Tom Barber 
> wrote:
>
>> Cross posted from IRC:
>>
>> Hello folks,
>>
>> I have a gripe about the charm store search. Mostly because its really
>> badly weighted towards recommended charms, and finding what you(an end user
>> wants is really hard unless they know what they are doing).
>>
>> Take this example:
>>
>> https://jujucharms.com/q/pentaho
>>
>> Now I'm writing a charm called Pentaho Data Integration, so why do I have
>> to scroll past 55 recommended charms that have nothing to do with what I
>> have looked for?
>>
>> But
>>
>> https://jujucharms.com/q/etl
>>
>> Shows me exactly what I need at the top, with no recommended charms
>> blocking the view.
>>
>> So I guess its weighted towards tags, then names, sorta.
>>
>> Im not against recommended charms being dumped at the top, they are
>> recommended after all but it appears the ranking could be vastly improved.
>>
>> Off the top of my head a ranking combo of something like, keyword
>> relevance, recommended vs non recommended, times deployed, age, tags and
>> last updated. would give a half decent weighting for the charms and would
>> hopefully stop 55 unrelated charms appearing at the top of the list.
>>
>> Now I guess, I could dump pentaho in as a tag to get me top of the SEO
>> rankings, but it seems like generally the method could be improved as the
>> amount of charms increases, quite plausibly using something like Apache
>> Nutch to crawl the available charms and build a proper search facility
>> would improve things.
>>
>> Cheers
>>
>> Tom
>>
>>
>> --
>>
>> Director Meteorite.bi - Saiku Analytics Founder
>> Tel: +44(0)5603641316
>>
>> (Thanks to the Saiku community we reached our Kickstart
>> 
>> goal, but you can always help by sponsoring the project
>> )
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: New feature for charmers - min-juju-version

[Nate Finch]

Yes, it'll be ignored, and the charm will be deployed normally.

On Thu, Mar 17, 2016 at 3:29 PM Ryan Beisner 
wrote:

> This is awesome.  What will happen if a charm possesses the flag in
> metadata.yaml and is deployed with 1.25.x?  Will it gracefully ignore it?
>
> On Thu, Mar 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
>> attempts to deploy a charm (whether from the charmstore or from local) that
>> has min-juju-version specified, if the targeted model's Juju version is
>> lower than that specified, then the user will be shown an error noting that
>> the charm requires a newer version of Juju (and told what version they
>> need). The format for min-juju-version is a string that follows the same
>> scheme as our release versions, so you can be as specific as you like. For
>> example, min-juju-version: "2.0.1-beta3" will deploy on 2.0.1 (release),
>> but will not deploy on 2.0.1-alpha1 (since alpha1 is older than beta3).
>>
>> Note that, at this time, Juju 1.25.x does *not* recognize this flag, so
>> it will, unfortunately, not be respected by 1.25 environments.
>>
>> This code just landed in master, so feel free to give it a spin.
>>
>> -Nate
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layers & Windows

[Nate Finch]

>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 part I see is that the charm code for Windows expects hooks
to be .exe, .ps1, .cmd, or .bat.  You can't have a hook with no extension
on Windows, and on Linux we expect it to be a command with no extension.
That being said, there's nothing that says you can't have both an
'install.ps1' hook file for Windows and an 'install' hook file for Linux in
the same charm.  The code will do the right thing and use the right hook
for each OS.

On Mon, Apr 4, 2016 at 7:46 AM Rick Harding 
wrote:

> I know that Gabriel and some of the CloudBase folks seemed interested in
> layers and possibly some tooling with powershell. I'm not sure how far that
> went but I thought they were experimenting during the charmer's summit.
> That would help with a charm build on windows, but not for some common code
> between both operating systems.
>
> An interesting thing is how much setup and how ootb the Ubuntu on Windows
> needs. If it's working out of the box, it might be an interesting move for
> us and our tools that Windows users could get a Linux experience. I guess
> that it won't be ideal though as I'm not sure what the server side plans
> around that work is.
>
> On Mon, Apr 4, 2016 at 3:18 AM Andrew Wilkins <
> andrew.wilk...@canonical.com> wrote:
>
>> Hi,
>>
>> I would like to write a charm that should be mostly identical on Windows
>> and Linux, so I think it would make sense to have common code in the form
>> of a layer.
>>
>> Is anyone working on getting "charm build", layers, and friends to work
>> with Windows workloads? If not, I may look into it myself.
>>
>> Cheers,
>> Andrew
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layers & Windows

[Nate Finch]

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 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 Mon, Apr 4, 2016 at 9:48 AM Stuart Bishop 
> wrote:
>
>>
>> You will need two root layers for the two charms, one for Ubuntu and
>> one for Windows, since you can't list both Windows and Ubuntu releases
>> as supported series in the same metadata.yaml.
>>
>>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charm layers & Windows

[Nate Finch]

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 Mon, Apr 4, 2016 at 9:48 AM Stuart Bishop 
wrote:

>
> You will need two root layers for the two charms, one for Ubuntu and
> one for Windows, since you can't list both Windows and Ubuntu releases
> as supported series in the same metadata.yaml.
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: [Review Queue] rlec, nrpe-external, nagios, squid-reverseproxy, ubuntu-repository-cache, ibm-im

[Nate Finch]

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 inefficiencies?
>
> The resource-get docs say this:
>
> If "resource-get" for a resource has not been run before (for the unit)
>>
>> then the resource is downloaded from the controller at the revision
>>
>> associated with the unit's application. That file is stored in the unit's
>>
>> local cache. If "resource-get" *has* been run before then each
>>
>> subsequent run syncs the resource with the controller. This ensures
>>
>> that the revision of the unit-local copy of the resource matches the
>>
>> revision of the resource associated with the unit's application.
>>
>>
>> Either way, the path provided by "resource-get" references the
>>
>> up-to-date file for the resource. Note that the resource may get
>>
>> updated on the controller for the application at any time, meaning the
>>
>> cached copy *may* be out of date at any time after you call
>>
>> "resource-get". Consequently, the command should be run at every
>>
>> point where it is critical that the resource be up to date.
>>
>
> Expanding on the inefficiencies given the above optimizations may help
> other charm writers be aware of things which may be inefficient.
>
> Thanks,
> --
> Jay
>
>
> On Fri, Jun 24, 2016 at 1:59 PM, Kevin Monroe 
> wrote:
>
>> Andrew, Cory, Kostas, Pete, and I went through the queue.  Here's what we
>> found:
>>
>>
>>-
>>
>>RLEC (Kostas)
>>-
>>
>>   https://bugs.launchpad.net/charms/+bug/1551133
>>   -
>>
>>   This charm deploys Redis Labs Enterprise Cluster that enables you
>>   to install an enterprise-grade cluster for managing and running 
>> multiple
>>   Redis databases.
>>   -
>>
>>   The charm seems functional. Deploys correctly and scales.
>>   -
>>
>>   There are still a few points that need the attention of the author:
>>   -
>>
>>  Opening ports
>>  -
>>
>>  Better testing
>>  -
>>
>>  Align with the new promulgation process
>>  -
>>
>>nrpe-external (Cory)
>>-
>>
>>
>>   
>> https://code.launchpad.net/~aluria/charms/precise/nrpe-external-master/donotremove-hostdefs/+merge/290957
>>   -
>>
>>   The PR had already been approved, but to merge in accordance with
>>   the new process, it needs to be moved out of the ~charmers namespace.  
>> This
>>   brought to light that the maintainer is no longer recommending this and
>>   users should transition to cs:trusty/nrpe, raising the question of how 
>> to
>>   handle the transition.  We will apply the PR but move this to 
>> ~unmaintained
>>   with an announcement to transition and a possible grace period.
>>   -
>>
>>squid-reverseproxy (Pete)
>>-
>>
>>
>>   
>> https://code.launchpad.net/~dbuliga/charms/trusty/squid-reverseproxy/centos/+merge/287481
>>   -
>>
>>   Marked as “needs fixing” due to failing tests (missing an import
>>   on trusty).
>>   -
>>
>>nagios (Pete)
>>-
>>
>>
>>   
>> https://code.launchpad.net/~dbuliga/charms/trusty/nagios/nagios/+merge/288614
>>   -
>>
>>   Code looks good -- is blocked by nrpe-external being merged,
>>   however.
>>   -
>>
>>Ubuntu-repository-cache (Andrew)
>>-
>>
>>
>>   
>> https://code.launchpad.net/~daniel-thewatkins/charms/trusty/ubuntu-repository-cache/error-message-fix/+merge/292622
>>   -
>>
>>   Due to the large amount of files that need to be synced this fails
>>   with a timeout error. Should try to limit the amount of repos synced 
>> for
>>   the test.
>>   -
>>
>>IBM Installation Manager (Kevin)
>>-
>>
>>   https://bugs.launchpad.net/charms/+bug/1575746
>>   -
>>
>>   We noticed our previous MP was inefficiently calling resource-get
>>   multiple times for the fixpack (which is a real problem with large
>>   resources). Fixed.
>>   -
>>
>>   IBM found a bug in our previous MP where we sentry’d the wrong
>>   status message in the ibm-im amulet test.  Fixed.
>>   - Awaiting merge decision.
>>
>>
>> Let us know if you have any questions. Thanks!
>> -Kevin
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
>>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Need info for deploying Mariadb as xenial

[Nate Finch]

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 Mariadb charm deployed
> with series  xenial
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> 
>
> Email: rajith...@in.ibm.com
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Need info for deploying Mariadb as xenial

[Nate Finch]

Sounds there are problems with the charm on xenial, which is not super
surprising.  Is there a reason you need xenial specifically for this
machine?  Can you just use trusty instead?

On Mon, Jun 27, 2016, 9:37 AM Rajith P Venkata  wrote:

> Hi
>
> I tried to install with --series xenial --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
> Email: rajith...@in.ibm.com
>
>
>
> From:Nate Finch 
> To:Rajith P Venkata/India/IBM@IBMIN, juju 
> Date:27-06-16 12:30 PM
> Subject:Re: Need info for deploying Mariadb as xenial
> --
>
>
>
> 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 <*rajith...@in.ibm.com*
> > 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 Mariadb charm deployed
> with series  xenial
>
> Rajith
>
> IBM AIX Certified, OCPCertified
> 
>
> Email: *rajith...@in.ibm.com* 
>
> --
> Juju mailing list
> *Juju@lists.ubuntu.com* 
> Modify settings or unsubscribe at:
> *https://lists.ubuntu.com/mailman/listinfo/juju*
> <https://lists.ubuntu.com/mailman/listinfo/juju>
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Point people to ubuntu-on-windows instead of the broken juju-on-windows?

[Nate Finch]

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 simply run the OS's ssh and everything Just Works, but that's not
possible on Windows, so it's much more involved to make it work (we
basically have to write an entire ssh client).

However, as a workaround, it would be pretty trivial to write a juju plugin
to launch putty with the right parameters.  Then you'd just do `juju putty
0` rather than juju ssh 0.  Obviously, it would open putty, not a CLI ssh
terminal, but the overall experience is probably a lot better than what we
could provide.

On Thu, Aug 11, 2016 at 11:41 AM Marco Ceppi 
wrote:

> On Thu, Aug 11, 2016 at 11:27 AM Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> Hi all
>>
>>
>> Juju-on-windows is pretty broken and it doesn't seem that bugs are being
>> fixed anymore. Wouldn't it be better to point people to Juju on "Ubuntu on
>> windows" instead? One of my colleagues started using it and it seems to
>> work just fine.
>>
>> Some show-stopping bugs in Juju-on-windows:
>>
>>- `juju ssh` is not translating newlines correctly
>>.
>>- windows users can't create layered charms because the Charm tools
>>for windows is still at 1.2.9.
>>
>>
>> This is a doc mistake, I'll have an updated charm-tools msi before the
> end of the week in the docs.
>
> What do you guys think?
>>
>
> I think you've got a good point, however, not everyone is on Windows 10.
> Pointing people who are on Windows 10 to WSL instead would be fruitful for
> a good native experience.
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: 1.25.6-xenial-amd64 and lxc containers

[Nate Finch]

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
container on the already-existing machine #25
juju deploy haproxy --to 1/lxc/3  // deploys haproxy to lxc container #3 on
machine #1

you can also use add-machine to create empty containers:

juju add-machine lxc // adds a new machine with an empty lxc container on it
juju add-machine lxc:5 // adds a new empty lxc container on machine 5

Hope that helps.
-Nate

On Tue, Aug 30, 2016 at 4:16 PM Daniel Bidwell  wrote:

> What do I have to put in my .juju/environment.yaml to get juju-1.25.6-
> xenial-amd64 to use lxc containers?
> --
> Daniel Bidwell 
>
>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: kill-controller, unregister, destroy-controller

[Nate Finch]

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
have to type the same flag for every controller.

This is also why I just always use kill-controller... it's like
destroy-controller --destroy-all-models except you don't need the flag and
it's easier to type even disregarding the flag.  I'm sure I'm not the only
one that will figure this out and just avoid destroy-controller, which
defeats the purpose of trying to make it safer.

I agree with Roger we should be encouraging people to put blocks on
important controllers, and not rely on typing out long things that aren't
actually helpful.



On Fri, Sep 2, 2016 at 7:16 AM roger peppe 
wrote:

> It seems to me that this kind of thing is exactly what "blocks" are
> designed for. An explicit unblock command seems better to me than either an
> explicit flag or an extra prompt, both of which are vulnerable to typing
> without thinking. Particularly if "throwaway" controllers created for
> testing purposes are not blocked by default, so you don't get used to to
> typing "unblock" all the time.
>
> On 1 Sep 2016 16:14, "Mark Ramm-Christensen (Canonical.com)" <
> mark.ramm-christen...@canonical.com> wrote:
>
> I get the desire to remove friction everywhere we can, but unless
> destroying controllers is a regular activity, I actually think SOME
> friction is valuable here.
>
> If controllers are constantly getting into a wedged state where they must
> be killed, that's likely a product of a fast moving set of betas, and
> should be addressed *directly* rather than as they say "applying lipstick
> to a pig"
>
> On Thu, Sep 1, 2016 at 4:04 PM, Marco Ceppi 
> wrote:
>
>> 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 
>>> 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
 Un

Re: Juju client now works properly on all Linuxes

[Nate Finch]

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 Saiku community we reached our Kickstart
> 
> goal, but you can always help by sponsoring the project
> )
>
> On 16 September 2016 at 04:21, Marco Ceppi 
> wrote:
>
>> This is FANTASTIC news for those using the Snap!
>>
>> On Thu, Sep 15, 2016 at 10:53 PM Rick Harding 
>> wrote:
>>
>>> Thanks Menno, this is great stuff.
>>>
>>> On Thu, Sep 15, 2016, 10:35 PM Menno Smits 
>>> wrote:
>>>
 Hi everyone,

 This is just a quick heads up about an improvement that will be in Juju
 2.0 rc1.

 The Juju client has never really worked on flavours of Linux which we
 hadn't explicitly added support for (i.e. Ubuntu and Centos). This has now
 been fixed: the client will work on any Linux distribution. This has been
 tested with Fedora, Debian and Arch.

 Additionally, when using local Juju binaries (i.e. a juju and jujud
 which you've built yourself or someone has sent you), checks have been
 relaxed allowing a Juju client running on any Linux flavour to bootstrap a
 controller running any of the supported Ubuntu series. Previously it wasn't
 possible for a client not running a non-Ubuntu distribution to bootstrap a
 Juju controller using local Juju binaries.

 Please ask if anything about this is unclear.

 - Menno




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

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

Re: List plugins installed?

[Nate Finch]

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

Re: What are the best practices for stop hook handling?

[Nate Finch]

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."  The
stop hook should clean up everything to the best of its ability, to make
the machine appear as it did before the unit was added to it (so, uninstall
the software, remove all config files, etc).

2. Don't colocate units if at all possible.  In separate containers on the
same machine, sure.  But there's absolutely no guarantee that colocated
units won't conflict with each other. What you're asking about is the very
problem colocation causes. If both units try to take over the same port, or
a common service, or write to the same file on disk, etc... the results
will very likely be bad.  Stop hooks should clean up everything they
started.  Yes, this may break other units that are colocated, but the
alternative is leaving machines in a bad state when they're not colocated.

3. Many charms don't do this (in fact, there's an email about this on our
internal mailing list right now). They absolutely should.   Many charms get
away with not doing cleanup because Juju's main use case is containers and
throw-away VMs that are discarded after the unit is removed... but there
are many cases where this does not happen, such as using the Manual
provider or colocated units.  Please write cleanup code.


On Wed, Oct 19, 2016 at 10:17 AM Rye Terrell 
wrote:

> I have a number of questions regarding how to handle stop hooks properly:
>
> 1. Background services - stop them or stop & disable them?
>
> The docs say "stop runs immediately before the end of the unit's
> destruction sequence. It should be used to ensure that the charm's software
> is not running, and will not start again on reboot."
>
> Can anyone verify that that is correct? If so, it seems clear that
> services should be stopped & disabled, but leaves me with another question
> - is there no hook that handles scenarios like host rebooting?
>
> If it's not correct, what is the proper behavior for the stop hook
> handler? Stop & disable on stop hook and start & enable on start hook?
>
> 2. Background services - how do we handle colocated applications with
> shared background services?
>
> I'm not sure this is something we support, but if so, what do we do when
> one application is stopped and it has a colocated application that shares a
> background service dependency? I don't think this is something we can
> detect at the charm level, so do we _not_ stop services so that we don't
> cause conflicts?
>
> 3. File cleanup - is anyone doing this?
>
> The docs also say "Remove any files/configuration created during the
> service lifecycle" is part of a charm's stop hook handling behavior. My
> experience isn't exactly vast, but I'm unaware of charms doing this. Is
> this something we actually do? Should we keep that statement in the docs?
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Controllers running out of disk space

[Nate Finch]

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 we cap them
smallish (the logs stored in mongo are capped, right?)

Do we still store all logs from all machines on the controller?  Are they
capped?  That has been a problem in the past with large models.

On Thu, Nov 17, 2016 at 8:53 AM Rick Harding 
wrote:

> I'm definitely agreeing we need to provide some better tools for the admin
> of the controller to track and garden things such as charms and resources
> which can be quite large and grows over time.
>
> My main point with Uros was that we have this way due to model migrations
> to stick a controller/model into a quiet mode so that a migration can take
> place. It feels like a natural fit for a bit of a maintenance mode as
> operators manage large scale/long running Juju controllers over time. I
> wanted to look into the feasibility of allowing the operator to engage the
> quiet mode while they manage disk or other issues.
>
> The other question is, is this a temp issue? When you migrate models to
> another controller only the latest charm/resource revision goes with it.
> Maybe there's a place for a migration as part of good hygiene. It feels a
> bit forceful, but actually might be a safe practice.
>
> On Thu, Nov 17, 2016 at 4:13 AM John Meinel 
> wrote:
>
> So logs in mongo and logs on disk should be capped, and purged when they
> get above a certain size. 'audit.log' should never be automatically purged.
> Charms in the blobstore are potentially local data that we can't reproduce,
> so hard to automatically purge them. I think there has been some work done
> to properly reference count them, so we at least know if anything is
> currently referencing them. And we could purge things that are from a
> charmstore, since we know it is available elsewhere.
>
> I'm fine with a "pause" sort of mode so that you have an opportunity to
> move things out, and some sort of manually triggered garbage collection.
> But if we do know that some garbage collection is safe, we should probably
> just do it by default.
>
> John
> =:->
>
>
> On Thu, Nov 17, 2016 at 12:20 PM, Uros Jovanovic <
> uros.jovano...@canonical.com> wrote:
>
> Hi all,
>
> I'd like to start a discussion on how to handle storage issues on
> controller machines, especially what we can do when storage is getting 95%
> or even 98% full. There are many processes that are storing data, we have
> at least:
> - charms and resources in the blobstore
> - logs in mongo
> - logs on disk
> - audit.log
>
> Even if we put all models in the controller into read-only mode to prevent
> upload of new charms or resources to blobstore, we still have to deal with
> logs which can fill the space quickly.
>
> While discussing about this with Rick, given the work on model migrations,
> maybe the path forward would be to allow admin to put the whole controller
> in "maintenance" mode and put all agents on "hold".
>
> How to deal with storage issue after that is open to discussion, maybe we
> need tools to "clear" blobstore, or export/compress/truncate logs, etc.
>
> Thoughts?
>
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: A (Very) Minimal Charm

[Nate Finch]

So, the whole point of my original email was to say - if you want a minimal
charm, just make one, it's easy.
I just published my above mentioned minimal charm as cs:~natefinch/nop

It's not showing up on jujucharms.com, maybe because charm proof is failing
because it's missing everything except the metadata?  I don't know, but it
still works with juju deploy.

On Thu, Dec 1, 2016 at 10:07 PM José Antonio Rey  wrote:

> Wouldn't it be possible for us to implement a configuration flag, and
> have it as default? Going back to the general point, the idea behind the
> ubuntu charm is to have a vainilla Ubuntu where you can work on
> anything. I understand we're mostly using it for testing, and reactive
> is now a big part of the ecosystem. I find two simple approaches for this:
>
>   * Create a ubuntu-vainilla charm which doesn't install any of the
> required packages OR
>   * Implement a 'vainilla' boolean configuration flag, where you can
> specify True for the vainilla Ubuntu install, False to install all of
> the reactive/other dependencies.
>
> If we get to work around the pyyaml issue and implement a better
> solution in the long term, I think that would be amazing. However, we
> can't let one dependency drag us down, and in the meanwhile, we have to
> implement a workaround.
>
> On 12/01/2016 01:56 PM, Cory Johns wrote:
> > Marco,
> >
> > What is the issue you mentioned with using snaps where you mentioned
> > needing an "unconfined classic snap"?
> >
> > On Thu, Dec 1, 2016 at 1:13 PM, Marco Ceppi  > <mailto:marco.ce...@canonical.com>> wrote:
> >
> > On Thu, Dec 1, 2016 at 12:56 PM Casey 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 at 5:00 AM Adam Collard
> >  > <mailto:adam.coll...@canonical.com>> wrote:
> >
> > On Thu, 1 Dec 2016 at 04:02 Nate Finch
> >  > <mailto:nate.fi...@canonical.com>> wrote:
> >
> > On IRC, someone was lamenting the fact that the
> > Ubuntu charm takes longer to deploy now, because it
> > has been updated to exercise more of Juju's
> > features.  My response was - just make a minimal
> > charm, it's easy.  And then of course, I had to
> > figure out how minimal you can get.  Here it is:
> >
> > It's just a directory with a metadata.yaml in it
> > with these contents:
> >
> > name: min
> > summary: nope
> > description: nope
> > series:
> >   - xenial
> >
> > (obviously you can set the series to whatever you
> want)
> > No other files or directories are needed.
> >
> >
> > This is neat, but doesn't detract from the bloat in the
> > ubuntu charm.
> >
> >
> > I'm happy to work though changes to the Ubuntu charm to
> > decrease "bloat".
> >
> >
> > 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,
> >
> >
> > I think a minimal wheelhouse to provide a consistent charm hook
> > runtime is very reasonable and definitely not the problem here.
> >
> > There are too many packages that get installed by default with
> > the reactive framework that most charms don't ne

Re: Hide resources from showing on the store

[Nate Finch]

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
someone may forget to include the real resource at deploy time.

Yes, someone could download the dummy resource from the charmstore... I'm
not sure why this matters, though?  It should be pretty obvious right away
that it's not the real resource, and the README should also ensure to
clarify this.

-Nate

On Fri, Dec 2, 2016 at 9:08 AM Gabriel Samfira <
gsamf...@cloudbasesolutions.com> wrote:

> Say you have a charm that deploys a proprietary piece of software. That
> software has an EULA that prohibits anyone from redistributing it. The user
> is essentially forced to go to the software vendor website, login using
> their account, buy the software, and accept the EULA before being able to
> use the software.
>
> In this scenario, we cannot upload that piece of software as a resource
> into the charm store, and set that as the "default" resource for the charm.
> The license for that software does not allow us to. Most users that consume
> such software are aware of this, and is of no surprise to them that they
> have to "own" those resources before they can deploy them.
>
> There are 2 options here:
>
> 1) Canonical is given permission to redistribute the piece of software in
> question (Sharepoint, Exchange, MS SQL ISOs, etc), and validates that the
> user deploying the charm has the right to deploy that software.
> 2) Allow a charm to be published without resources, and validate during
> deployment if the resources are available or not. The charm can handle the
> missing resources and print a nice comprehensive status message. If the
> charm also includes a decent README on how to deploy the service, it should
> be enough to smooth the process. In this scenario, the responsibility of
> making sure all license terms are satisfied, falls onto the user.
>
> It is unfortunate that licensing gets in the way of simplicity, but it is
> an issue that we need to keep in mind.
>
> Cheers,
> Gabriel
>
> On Vi, 2016-12-02 at 13:33 +, Rick Harding wrote:
>
> On Fri, Dec 2, 2016 at 5:49 AM Konstantinos Tsakalozos <
> kos.tsakalo...@canonical.com> wrote:
>
> This works but has a side effect, the dummy binaries are available for
> downloading from the charm's page. Is there a way to hide the resources
> from the charm's readme page?
>
>
> I'm confused why the user cannot know there's a default resource there?
>
> In an ideal world, the author would provide a default resource that at
> least helps guide the user to how to use the charm if they forget or use
> the wrong type of local resource. We want to make sure the user is guided
> on how to get things working as smoothly as possible.
>
> The other side is charm testing. The charm should have enough of what it
> needs in the default resource to perform functional tests to pass via tools
> such as Matrix.
>
> I'm curious how the user even knowing a thing is there is bad for the
> user. At this time we don't have any pattern to assist this.
>
> --
> Juju mailing listj...@lists.ubuntu.com
> Modify settings or unsubscribe at: 
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Regards,
> Gabriel Adrian Samfira
> Cloudbase Solutions SRL
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: using a bundle with manually added machines

[Nate Finch]

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, 2017 at 9:08 AM Rick Harding 
wrote:

> Hi Vance, you can deploy a bundle that uses existing machines in the model
> with the juju-deployer [1] tool.
>
> The built in juju deploy method is the first stage in a generic tool and
> does not allow pointing at existing machines because it means the bundles
> are not sharable and that you need your model in a specific state before
> you can use the bundle. Since Juju doesn't allow you to rename machines it
> means that you have to keep the bundle in sync with the model.
>
> 1: https://pypi.python.org/pypi/juju-deployer/
>
> On Thu, Dec 29, 2016 at 9:09 AM Vance Morris  wrote:
>
>
> Hi all,
>
> Is it possible to use a bundle.yaml in conjunction with manually added
> machines?
>
> $ juju version
> 2.0.2-xenial-s390x
>
> $ juju status
> << snip >>
> Machine  StateDNS  Inst id  Series  AZ
> 0started  REDACTED  manual:REDACTED   xenial
> 1started  REDACTED  manual:REDACTED   xenial
> 2started  REDACTED  manual:REDACTED   xenial
> << snip >>
>
> When I go to deploy a bundle that defines machines 0, 1, and 2 and
> describes deployment of services to these machines, the charms are
> deployed, but no units are created.
>
> ERROR cannot deploy bundle: cannot create machine for holding aodh,
> ceilometer, ceph-mon, ceph-osd, cinder, glance, keystone, mongodb, mysql,
> neutron-api, neutron-gateway, nova-cloud-controller, nova-compute,
> openstack-dashboard, rabbitmq-server, swift-proxy and swift-storage-z1
> units: cannot add a new machine: use "juju add-machine ssh:[user@]"
> to provision machines
>
> If I manually deploy charms to the manually added machines, it's happy to
> oblige.
>
>
> VANCE MORRIS
> --
> Phone:  1-720-349-9450 <(720)%20349-9450>
> E-mail: vmor...@us.ibm.com
> [image: IBM]
> 
> 
> 
> 1177 S Belt Line Rd
> Coppell, TX 75019-4642
> United States
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
> --
> Juju mailing list
> Juju@lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju