Re: Juju snap edge channel enabled

[Mark Shuttleworth]

On 16/08/16 15:01, Nicholas Skaggs wrote:
> Following up on Ian's work to remove the need for --upload-tools, I've
> enabled daily publishing to the edge channel for the juju snap. The
> snap utilizes this work so the snap 'just works' as expected. A new
> snap is generated and published once a day so you'll always have the
> latest changes. Make sure you install using the edge channel.
>
> snap install juju --edge --devmode

Thanks Nicholas, this is a great way to track master.

Mark

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

Re: Juju snap edge channel enabled

[Mark Shuttleworth]

On 16/08/16 15:01, Nicholas Skaggs wrote:
> Following up on Ian's work to remove the need for --upload-tools, I've
> enabled daily publishing to the edge channel for the juju snap. The
> snap utilizes this work so the snap 'just works' as expected. A new
> snap is generated and published once a day so you'll always have the
> latest changes. Make sure you install using the edge channel.
>
> snap install juju --edge --devmode

Thanks Nicholas, this is a great way to track master.

Mark

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

Juju snap edge channel enabled

[Nicholas Skaggs]

Following up on Ian's work to remove the need for --upload-tools, I've
enabled daily publishing to the edge channel for the juju snap. The snap
utilizes this work so the snap 'just works' as expected. A new snap is
generated and published once a day so you'll always have the latest
changes. Make sure you install using the edge channel.

snap install juju --edge --devmode

Remember, the code has been through basic QA checks, but stability is not
warranted. Please don't use them for production deployments, but otherwise
have fun living on the edge!

Note, snap-confine currently has a bug which affects the juju snap and LXD;
it's not possible to use LXD as a substrate when juju is installed as a
snap package. See LP# 1613845. I expect this to be sorted very soon so LXD
works once again.

Enjoy!

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

Juju snap edge channel enabled

[Nicholas Skaggs]

Following up on Ian's work to remove the need for --upload-tools, I've
enabled daily publishing to the edge channel for the juju snap. The snap
utilizes this work so the snap 'just works' as expected. A new snap is
generated and published once a day so you'll always have the latest
changes. Make sure you install using the edge channel.

snap install juju --edge --devmode

Remember, the code has been through basic QA checks, but stability is not
warranted. Please don't use them for production deployments, but otherwise
have fun living on the edge!

Note, snap-confine currently has a bug which affects the juju snap and LXD;
it's not possible to use LXD as a substrate when juju is installed as a
snap package. See LP# 1613845. I expect this to be sorted very soon so LXD
works once again.

Enjoy!

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

Re: Faster LXD bootstraps and provisioning

[Reed O'Brien]

On Mon, Aug 15, 2016 at 10:30 PM John Meinel  wrote:

> ...
>>
>
>
>> +### tuple ### allow any 8000 0.0.0.0/0 any 0.0.0.0/0 in
>> +-A ufw-user-input -p tcp --dport 8000 -j ACCEPT
>> +-A ufw-user-input -p udp --dport 8000 -j ACCEPT
>> +
>>
>>
> If I'm reading this one correctly, it also means that anyone from *any* IP
> address (not restricted to your local network). So anyone that can get to
> port 8000 on your machine can proxy to any other public website. Now, I'd
> guess that you also run a NAT router so this may not actually be opening up
> an open proxy for the world to access, but it seems a little bit iffy to
> put into a general guide.
>

Good eyes! I am behind a NAT, so it doesn't matter too much. My network is
IPv6 internally (and externally) and I am not 100% on ipv6 local vs global
links and avahi. So I just made a rule to allow the port from anywhere. I
hope to make it more robust and update the wiki RSN™.
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Faster LXD bootstraps and provisioning

[Reed O'Brien]

On Mon, Aug 15, 2016 at 10:30 PM John Meinel  wrote:

> ...
>>
>
>
>> +### tuple ### allow any 8000 0.0.0.0/0 any 0.0.0.0/0 in
>> +-A ufw-user-input -p tcp --dport 8000 -j ACCEPT
>> +-A ufw-user-input -p udp --dport 8000 -j ACCEPT
>> +
>>
>>
> If I'm reading this one correctly, it also means that anyone from *any* IP
> address (not restricted to your local network). So anyone that can get to
> port 8000 on your machine can proxy to any other public website. Now, I'd
> guess that you also run a NAT router so this may not actually be opening up
> an open proxy for the world to access, but it seems a little bit iffy to
> put into a general guide.
>

Good eyes! I am behind a NAT, so it doesn't matter too much. My network is
IPv6 internally (and externally) and I am not 100% on ipv6 local vs global
links and avahi. So I just made a rule to allow the port from anywhere. I
hope to make it more robust and update the wiki RSN™.
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Latest new about Juju master branch - upload-tools obsoleted

[Aaron Bentley]

On 2016-08-15 08:27 AM, Ian Booth wrote:
> Please let me know if there's any questions. --upload-tools is still supported
> but will be removed soon.

Has --upload-tools already been removed?  The lack of it appears to be
breaking gui tests:

http://reports.vapour.ws/releases/4259/job/function-uitest-gui/attempt/419#highlight

Aaron



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

Re: Faster LXD bootstraps and provisioning

[Casey Marshall]

I decided it'd be easier & safer to host squid-deb-proxy in a LXD container
rather than the host. My host doesn't route inbound to LXD from other
networks, and all the Juju machines can see it.

On Tue, Aug 16, 2016 at 12:30 AM, John Meinel 
wrote:

> ...
>>
>
>
>> +### tuple ### allow any 8000 0.0.0.0/0 any 0.0.0.0/0 in
>> +-A ufw-user-input -p tcp --dport 8000 -j ACCEPT
>> +-A ufw-user-input -p udp --dport 8000 -j ACCEPT
>> +
>>
>>
> If I'm reading this one correctly, it also means that anyone from *any* IP
> address (not restricted to your local network). So anyone that can get to
> port 8000 on your machine can proxy to any other public website. Now, I'd
> guess that you also run a NAT router so this may not actually be opening up
> an open proxy for the world to access, but it seems a little bit iffy to
> put into a general guide.
>
> John
> =:->
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Faster LXD bootstraps and provisioning

[Casey Marshall]

I decided it'd be easier & safer to host squid-deb-proxy in a LXD container
rather than the host. My host doesn't route inbound to LXD from other
networks, and all the Juju machines can see it.

On Tue, Aug 16, 2016 at 12:30 AM, John Meinel 
wrote:

> ...
>>
>
>
>> +### tuple ### allow any 8000 0.0.0.0/0 any 0.0.0.0/0 in
>> +-A ufw-user-input -p tcp --dport 8000 -j ACCEPT
>> +-A ufw-user-input -p udp --dport 8000 -j ACCEPT
>> +
>>
>>
> If I'm reading this one correctly, it also means that anyone from *any* IP
> address (not restricted to your local network). So anyone that can get to
> port 8000 on your machine can proxy to any other public website. Now, I'd
> guess that you also run a NAT router so this may not actually be opening up
> an open proxy for the world to access, but it seems a little bit iffy to
> put into a general guide.
>
> John
> =:->
>
>
-- 
Juju-dev mailing list
Juju-dev@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju-dev

Re: Deploying local code

[Alexander Taler]

Thanks for pointing that out Tim.

Resources look good for basic use cases, with a small number of
files, but there are a couple of scenarios which I don't think it
would handle well:

 - Handling a variable number of files, such as code which can
   have arbitrary dependencies. They could be combined into a
   single archive, but that makes versioning difficult.
 - Handling third party packaging and installation tools like npm
   or similar, providing a fast proxy with proper control over
   what's delivered.

Alex

  > Hi Alexander,

  > Great to hear fellow kiwis interested.

  > The dealing with artifacts is exactly the problem that resources were
  > designed to fix. A charm defines the resources it needs and as the charm is
  > deployed, it also has the resources fetched.

  > Personally I've not used any charms yet that use or defines resources, but
  > I'm sure there are some eco team folks that could point you to some good
  > examples.

  > Cheers, Tim

  > On 16/08/16 12:27, Alexander Taler wrote:
  >> 
  >> Hello everyone, I'm brand new to Juju, so first I'll say thanks for the
  >> exciting project, I really think that Juju takes the right approach to
  >> deployment.
  >> 
  >> I will be using Juju to help software development companies build
  >> deployment automation for their own work. The first requirements I'm
  >> focussing on are:
  >> - Deploy specific revisions of their code (source or compiled)
  >> - Control dependencies so that identical software can be redeployed
  >> 
  >> I am thinking to approach this by creating an artefact repository within
  >> the model, and then having charms fetch their dependencies from this
  >> repository. The repository could be a caching proxy server, or be
  >> populated directly from the client machine.
  >> 
  >> Are these already solved problems? Is anyone already working on something
  >> along these lines? Does my approach sound reasonable, and aligned with the
  >> future of Juju? I would of course be happy to contribute back anything
  >> that I develop.
  >> 
  >> Also thanks to the Launchpad team, if you're listening, for the "related
  >> projects" feature when registering a new project; it led me to Juju.
  >> 
  >> Alex
  >> 
  >> 

-- 
DEvelopment REFined http://deref.co.nz/
Enabling your software development team to reach their peak.
   022 659 0282

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

Re: Charm stuck dying

[Wayne Carty]

Hi John,


There are other services running on the box that I don't want destroyed. Is
there anyway to clean this up without killing the server.

Thanks,
Wayne

On Tue, Aug 16, 2016 at 1:33 AM, John Meinel  wrote:

> I'm quite surprised to see an 'agent-state: stopped' and life: dead with
> an 'agent-status: ... executing'.
> If the agent really is dead, then there is nothing for the hooks to run
> on. Is this particular unit (nrpe/20) running on a machine that has other
> services running on it, or was it the last thing on the machine. I believe
> 'juju destroy-machine --force' is able to clean up all of the units/etc
> that had been placed onto a machine (its used for the case where you
> actually stopped the machine via some other means, and there is nothing
> left that can run any cleanup steps.)
>
> John
> =:->
>
>
> On Mon, Aug 15, 2016 at 6:36 PM, Wayne Carty  wrote:
>
>>
>> Hi
>>
>> I have a charm that is stuck dying. It seem like the entry didn't get
>> updated in juju.
>> Is there a way to manually update the status or trigger the hooks
>>
>> nrpe/20:
>> workload-status:
>>   current: terminated
>>   since: 12 Aug 2016 10:57:55Z
>> agent-status:
>>   current: executing
>>   message: running stop hook
>>   since: 12 Aug 2016 10:57:54Z
>>   version: 1.25.3
>> agent-state: stopped
>> agent-version: 1.25.3
>> life: dead
>>
>>
>> Thanks
>>
>> --
>> Wayne Carty
>>
>> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>> an/listinfo/juju
>>
>>
>


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

Re: Latest new about Juju master branch - upload-tools obsoleted

[roger peppe]

This seems really nice, but I'm slightly wary of "magic" heuristics like this.
In particular, bootstrapping can take a while and I have wasted
plenty of time in the past trying to find bugs but having bootstrapped
using the wrong binary...

So I'm hoping this new feature provides at least these properties:

- if I bootstrap/upgrade from locally built binaries, the bootstrap process will
always unambiguously tell me that.
- there is some way to find out in advance whether juju will bootstrap/upgrade
from the locally built binaries (it's hard to interrupt a bootstrap).
- the --build-agent flag will guarantee that juju will bootstrap with
locally built
binaries (no fallback to released version).

  cheers,
rog.



On 15 August 2016 at 13:27, Ian Booth  wrote:
> So if you pull master you'll no longer need to use upload-tools.
> Juju will Do the Right Thing*, when you type:
>
> $ juju bootstrap mycontroller aws|lxd|whatever
> or
> $ juju upgrade-juju
>
> *so long as your $GOPATH/bin is in your path (as a developer).
>
> 1. As a user, you bootstrap a controller using a released client (incl betas)
>
> Juju will look for and find a packaged agent binary via simplesreams and use 
> that.
>
> 2. As a user, you want to upgrade a Juju system using a newer release (incl 
> betas)
>
> Juju will look for and find a packaged agent binary via simplesreams and use 
> that.
>
> 3. As a developer, you want to deploy with a Juju built locally from source
>
> You'll first build your work, go install github.com/juju/juju/..., then
>
> $ juju bootstrap mycontroller lxd
>
> 4. As a developer, you want to upgrade a running system using some local 
> changes
> you've been hacking on. This works for either a system running a released
> version, or a system running a development version, ie either case 1, 2 or 3 
> above
>
> You'll first build your work, go install github.com/juju/juju/..., then
>
> $ juju upgrade-juju
>
> It should be apparent that there's now no difference in Juju commands when
> running a production system or a development one.
>
> As a developer, you also have the "advanced" option of not building the Juju
> source before bootstrapping or upgrading, and asking Juju to do it for you. 
> This
> is similar to what happens currently and can be error prone, and there's no 
> need
> anyway. But if needed:
>
> $ juju bootstrap mycontroller lxd --build-agent
> $ juju upgrade-juju --build-agent
>
> But as I said, there's no need for this really, so long as as a developer you
> have your $GOPATH/bin directory early in your path so that locally built juju
> gets used in preference to /usr/bin/juju
>
> These changes also are to support running Juju for a single architecture 
> using a
> snap.
>
> Please let me know if there's any questions. --upload-tools is still supported
> but will be removed soon. You can use --show-logs to see what Juju is doing.
> I must admit, not having to type --upload-tools all the time is to quote 
> Borat,
> "Nce".
>
>
> TODO
>
> We still need to add a --agent-binary option to upgrade-juju so you can point 
> it
> to the new jujud you want it to use. This is to allow developers to upgrade a
> system running from a snap. ie go install and then use the resulting binary
> after copying somewhere the snap can see it. There's a bit of usability to 
> work
> out there. Or it also allows you to send someone a jujud binary and they can
> just easily using that, rather than messing around with tarballs and
> simplestreams like they need to do today.
>
>
>
>
>
> --
> canonical-juju mailing list
> canonical-j...@lists.canonical.com
> Modify settings or unsubscribe at: 
> https://lists.canonical.com/mailman/listinfo/canonical-juju

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