Juju 2.0-rc2 is here!

[Nicholas Skaggs]

A new proposed release of Juju 2.0, 2.0-rc2, is here! As of rc1, we
guarantee upgradability up through Juju 2.0 final. We encourage you to
try this candidate build now in anticipation of Juju 2.0!


## What's new?
* The upgrade-charm command now has --config and --storage flags,
  so you can atomically update application config and storage
  constraints at the same time as upgrading the charm. This means you
  can now upgrade charms with additional required storage
  (https://bugs.launchpad.net/juju/+bug/1504658)
* get-controller-config has been renamed to controller-config to be
  consistent with the rest of the config commands.
* Juju no longer auto creates bridges for interfaces in MAAS that are
  unconfigured.
* kill-controller now as a --timeout flag that allows the user to set
  the time to wait before direct destruction.
* Rackspace cloud now works out of the box with updated add-credential
  and streams use.


## How do I get it?

If you are running Ubuntu, you can get it from the juju devel ppa:

sudo add-apt-repository ppa:juju/devel
sudo apt update; sudo apt install juju-2.0

Or install it from the snap store

snap install juju --candidate --devmode

Windows, Centos, and MacOS users can get a corresponding installer at:

https://launchpad.net/juju/+milestone/2.0-rc2


## Feedback Appreciated!

We encourage everyone to subscribe the mailing list at
juju@lists.ubuntu.com and join us on #juju on freenode.
We would love to hear your feedback and usage of juju.


## Anything else?

You can read more information about what's in this release by viewing the
release notes here:

https://jujucharms.com/docs/devel/temp-release-notes


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

Re: List plugins installed?

[Tim Penhey]

Thanks Marco.

Would be good to have something solid to drive the plug-in changes with.

Tim

On 30/09/16 11:16, Marco Ceppi wrote:

Thanks have some ideas about this, I'll file a bug (blueprint?) about
it. I really care about plugins and would like to make them more robust
in Juju.

Marco


On Thu, Sep 29, 2016, 6:07 PM Tim Penhey mailto:tim.pen...@canonical.com>> wrote:

If we do that, then we can make the plug-in also install a metadata file
that explains help and usage, so you don't call the script to do that.

It makes it easy to list plug-ins, because you are searching a known
location, and not the entire path. Only show plug-ins that have the
appropriate meta-data file.

Tim

On 30/09/16 10:47, Nate Finch wrote:
> 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
mailto:stuart.bis...@canonical.com>
> >> wrote:
>
> On 28 September 2016 at 22:45, roger peppe
> mailto:roger.pe...@canonical.com>
>> wrote:
>
> On 28 September 2016 at 14:55, Rick Harding
> mailto:rick.hard...@canonical.com>
>>
> 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 mailto:stuart.bis...@canonical.com>
> >>
> --
> Juju-dev mailing list
> juju-...@lists.ubuntu.com 
>
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju-dev
>
>
>

--
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: List plugins installed?

[Marco Ceppi]

Thanks have some ideas about this, I'll file a bug (blueprint?) about it. I
really care about plugins and would like to make them more robust in Juju.

Marco

On Thu, Sep 29, 2016, 6:07 PM Tim Penhey  wrote:

> If we do that, then we can make the plug-in also install a metadata file
> that explains help and usage, so you don't call the script to do that.
>
> It makes it easy to list plug-ins, because you are searching a known
> location, and not the entire path. Only show plug-ins that have the
> appropriate meta-data file.
>
> Tim
>
> On 30/09/16 10:47, Nate Finch wrote:
> > 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
> > mailto:roger.pe...@canonical.com>>
> wrote:
> >
> > On 28 September 2016 at 14:55, Rick Harding
> > mailto:rick.hard...@canonical.com>>
> > 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-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: List plugins installed?

[Tim Penhey]

If we do that, then we can make the plug-in also install a metadata file 
that explains help and usage, so you don't call the script to do that.


It makes it easy to list plug-ins, because you are searching a known 
location, and not the entire path. Only show plug-ins that have the 
appropriate meta-data file.


Tim

On 30/09/16 10:47, Nate Finch wrote:

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 mailto:stuart.bis...@canonical.com>> wrote:

On 28 September 2016 at 22:45, roger peppe
mailto:roger.pe...@canonical.com>> wrote:

On 28 September 2016 at 14:55, Rick Harding
mailto:rick.hard...@canonical.com>>
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 mailto:stuart.bis...@canonical.com>>
--
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: 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: Charming with Resources

[Rick Harding]

Correct, the original discussion was the charm behaving differently if the
fingerprint had changed of the resource on the remote end. However, running
resource-get deals with only fetching the new data if the fingerprint
changes and so there wasn't a big draw to the feature to that end.

Now, in this way, what you're asking is for some way to tell when there is
no resource? I guess I'm missing what the 0byte resource is giving you out
of the gates. The charm won't work, you want to fall back? And as soon as
the charm gets a non-0byte resource it's no longer useful.

I really feel like that if someone wants to publish something through the
store that they have to supply at least some bin that runs and outputs a
clear message to the user "got get the proper bins from here" instead of
just failing to deploy. Charm authors should be doing whatever is possible
to fail in a clear way, through the charm, so that users are guided on the
right path to moving forward. I don't think the charmstore or juju having
0byte defaults or "no resource found" is correct. It really needs to be the
charm taking that failure and putting context and a path for the user to
follow vs just "not found".

On Thu, Sep 29, 2016 at 11:48 AM Charles Butler <
charles.but...@canonical.com> wrote:

> We initially asked for resource fingerprints to be available before
> fetching so we could do something less expensive.
>
> That didn't make the 2.0 cut and was pushed back needing more forethought.
>
> This however is a good example of why it's a better option.
>
>
> And I had similar logic in etcd at one point. I'll be revisiting the etcd
> later to fold offlineability back into the charm using what you've proposed.
>
> If not resource : apt install
>
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your application | www.jujucharms.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: Charming with Resources

[Charles Butler]

We initially asked for resource fingerprints to be available before
fetching so we could do something less expensive.

That didn't make the 2.0 cut and was pushed back needing more forethought.

This however is a good example of why it's a better option.


And I had similar logic in etcd at one point. I'll be revisiting the etcd
later to fold offlineability back into the charm using what you've proposed.

If not resource : apt install

-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charming with Resources

[Stuart Bishop]

On 29 September 2016 at 21:58, Charles Butler 
wrote:

> TL;DR - would it be helpful to just initialize every resource stream, at
> index 0, a zero byte resource?  This aids users who are publishing charms
> with copyrighted bins, or proprietary components. And give an immediately
> publishable resource for streams.
>

I currently rely on resource-get failing if the resource hasn't been
uploaded, so I can catch the error and download via other channels.


> It occurred to me this week while we were revving through the kubernetes
> publication process, that on initial publish its best to have zero byte
> resources at index 0. So its easy to remember - "man which resource was the
> zero byte one?" it just corresponds to 0.
>
> Instead of having users touch, gzip, etc a null resource, would it be
> feasible to make the charm store have this convention by default? Every
> charm that declares a resource, that resource, in turn gets a resource-0
> allocated for zero byte, freeing the publisher of the charm to use the
> provided null resource?  seems like a better UX than asking the user to
> jump through hoops of say:
>
> touch null && gzip null && charm attach mycharm big-resource=null.gz
>
> There's likely a reason we didn't do this by default and I'm interested in
> hearing it. However, I'm more interested in finding out if we can
> streamline resource publication for our vendors and community.
>

I don't understand why you would do this. Having your charm download a
resource, unpack it and check if it is 0 bytes long seems a very long
winded way of doing try: resource_get() except: ...

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

Re: Charming with Resources

[Charles Butler]

https://github.com/juju-solutions/kubernetes/blob/master-node-split/cluster/juju/layers/kubernetes-worker/reactive/kubernetes_worker.py#L70-L74

Seems like an applicable code-first way to solve this.  Matt and I have
been discussing extracting these common bits of code and contributing back
to charmhelpers when using resources so there are established patterns on
how to address this issue. LIke set a common threshold on fillesize when
invoking resource_get

resource_get('mything', min_bytes='100')

which would block on a sub 1MB resource and return. Leaving
control/execution state manipulation to the charmer to handle, but still
handled all the same.

Any thoughts on this? or am I running down the same hallway with the same
hammer looking for nails?

All the best,

Charles


On Thu, Sep 29, 2016 at 10:06 AM Rick Harding 
wrote:

> We didn't do an original 0byte resource because that's almost promised to
> fail. The thought was, in order to publish the charm into the store then
> you need some minimal resource that the charm will accept. If it's a django
> charm, a hello world application; if a file server, a demo image; etc. Just
> having a 0byte charm means the deploy is probably going to come up in some
> awkward error state that the end user has to track down "why did this fail"
> vs something obvious and documented.
>
> On Thu, Sep 29, 2016 at 10:59 AM Charles Butler <
> charles.but...@canonical.com> wrote:
>
>> TL;DR - would it be helpful to just initialize every resource stream, at
>> index 0, a zero byte resource?  This aids users who are publishing charms
>> with copyrighted bins, or proprietary components. And give an immediately
>> publishable resource for streams.
>>
>>
>> It occurred to me this week while we were revving through the kubernetes
>> publication process, that on initial publish its best to have zero byte
>> resources at index 0. So its easy to remember - "man which resource was the
>> zero byte one?" it just corresponds to 0.
>>
>> Instead of having users touch, gzip, etc a null resource, would it be
>> feasible to make the charm store have this convention by default? Every
>> charm that declares a resource, that resource, in turn gets a resource-0
>> allocated for zero byte, freeing the publisher of the charm to use the
>> provided null resource?  seems like a better UX than asking the user to
>> jump through hoops of say:
>>
>> touch null && gzip null && charm attach mycharm big-resource=null.gz
>>
>> There's likely a reason we didn't do this by default and I'm interested
>> in hearing it. However, I'm more interested in finding out if we can
>> streamline resource publication for our vendors and community.
>>
>> All the best,
>>
>> Charles
>> --
>> Juju Charmer
>> Canonical Group Ltd.
>> Ubuntu - Linux for human beings | www.ubuntu.com
>> Juju - The fastest way to model your application | www.jujucharms.com
>>
> --
>> Juju mailing list
>> Juju@lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/juju
>>
> --
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: Charming with Resources

[Rick Harding]

We didn't do an original 0byte resource because that's almost promised to
fail. The thought was, in order to publish the charm into the store then
you need some minimal resource that the charm will accept. If it's a django
charm, a hello world application; if a file server, a demo image; etc. Just
having a 0byte charm means the deploy is probably going to come up in some
awkward error state that the end user has to track down "why did this fail"
vs something obvious and documented.

On Thu, Sep 29, 2016 at 10:59 AM Charles Butler <
charles.but...@canonical.com> wrote:

> TL;DR - would it be helpful to just initialize every resource stream, at
> index 0, a zero byte resource?  This aids users who are publishing charms
> with copyrighted bins, or proprietary components. And give an immediately
> publishable resource for streams.
>
>
> It occurred to me this week while we were revving through the kubernetes
> publication process, that on initial publish its best to have zero byte
> resources at index 0. So its easy to remember - "man which resource was the
> zero byte one?" it just corresponds to 0.
>
> Instead of having users touch, gzip, etc a null resource, would it be
> feasible to make the charm store have this convention by default? Every
> charm that declares a resource, that resource, in turn gets a resource-0
> allocated for zero byte, freeing the publisher of the charm to use the
> provided null resource?  seems like a better UX than asking the user to
> jump through hoops of say:
>
> touch null && gzip null && charm attach mycharm big-resource=null.gz
>
> There's likely a reason we didn't do this by default and I'm interested in
> hearing it. However, I'm more interested in finding out if we can
> streamline resource publication for our vendors and community.
>
> All the best,
>
> Charles
> --
> Juju Charmer
> Canonical Group Ltd.
> Ubuntu - Linux for human beings | www.ubuntu.com
> Juju - The fastest way to model your application | www.jujucharms.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

Charming with Resources

[Charles Butler]

TL;DR - would it be helpful to just initialize every resource stream, at
index 0, a zero byte resource?  This aids users who are publishing charms
with copyrighted bins, or proprietary components. And give an immediately
publishable resource for streams.


It occurred to me this week while we were revving through the kubernetes
publication process, that on initial publish its best to have zero byte
resources at index 0. So its easy to remember - "man which resource was the
zero byte one?" it just corresponds to 0.

Instead of having users touch, gzip, etc a null resource, would it be
feasible to make the charm store have this convention by default? Every
charm that declares a resource, that resource, in turn gets a resource-0
allocated for zero byte, freeing the publisher of the charm to use the
provided null resource?  seems like a better UX than asking the user to
jump through hoops of say:

touch null && gzip null && charm attach mycharm big-resource=null.gz

There's likely a reason we didn't do this by default and I'm interested in
hearing it. However, I'm more interested in finding out if we can
streamline resource publication for our vendors and community.

All the best,

Charles
-- 
Juju Charmer
Canonical Group Ltd.
Ubuntu - Linux for human beings | www.ubuntu.com
Juju - The fastest way to model your application | www.jujucharms.com
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: List plugins installed?

[Stuart Bishop]

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