Re: Juju 2.2-rc2 has been released
conjure-up still seem to be on rc1 % sudo snap install conjure-up --classic --candidate conjure-up (candidate) 2.2-rc1-20170606.0106 from 'canonical' installed % juju --version 2.2-rc1-xenial-amd64 % conjure-up --version conjure-up 2.2-rc1 % sudo snap remove conjure-up conjure-up removed % sudo snap install juju --classic --candidate juju (candidate) 2.2-rc2 from 'canonical' installed % juju --version 2.2-rc2-xenial-amd64 On 9 June 2017 at 13:25, Chris Lee wrote: > # Juju 2.2-rc2 Release Notes > > > > We are delighted to announce the release of Juju and conjure-up 2.2-rc2! > In this release, Juju greatly improves memory and storage consumption, > works on KVM containers, and improves network modelling. conjure-up now > supports Juju as a Service (JAAS), provides a MacOS client, and adds > support for repeatable spell deployments. > > > > The best way to get your hands on this release of Juju and conjure-up is > to install them via snap packages (see https://snapcraft.io/ for more > info on snaps). > > > > snap install juju --classic --candidate > > snap install conjure-up --classic --candidate > > > > Other packages are available for a variety of platforms. Please see the > online documentation at https://jujucharms.com/docs/ > devel/reference-releases#development > > > > Please note that if you are upgrading an existing controller, please make > sure there is at least 6G of free disk space. The upgrade step for the logs > can take a while, in the vicinity of 10 or more minutes if the current logs > collection is at its maximum size. > > > > Since 2.2-rc1 > > > ## New and Improved > > -- > > > > Better support credential management in the Azure provider > > * support autoload-credentials and juju add-credential in the azure > provider when Azure CLI is installed. > > (this removes the requirement that the user discover their subscription ID > before creating credentials) > > > > Rate limit login and connection requests to the controller(s) on busy > systems. > > > > ## Fixes > > -- > > > > Fix issue where status history logs were not pruned: > > https://bugs.launchpad.net/juju/+bug/1696491 > > > -- > 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: Normalizing output dir for charm build
+1!
While you're at it; I think it could be wise to namespace everything with
Juju. For example $JUJU_LAYER_PATH and ~/.cache/juju/charm-build/deps or
something similar. I think it would make everything more coherent and also
eliminate the possibility of naming collisions.
This could of course be done in a different PR if you feel that it's
outside of this scope.
On 11 May 2017 at 16:25, Cory Johns wrote:
> Adam,
>
> I think the name "charms" is up to the user, it's just whatever they have
> set $JUJU_REPOSITORY to. It just so happens that Merlijn sets his to
> JUJU_REPOSITORY=~/charms (or similar).
>
> Previously, the build charm would end up in {$JUJU_REPOSITORY,$PWD}/{
> builds,trusty,xenial,...}/$charm_name. The proposal is to always have it
> go to $JUJU_REPOSITORY/$charm_name instead.
>
> Additionally, it was the case previously that the layers, interfaces, and
> deps directories would default to living under $JUJU_REPOSITORY. The
> proposal is to move deps to always be under ~/.cache/charm-build/deps and
> to not have any default for layers or interfaces, such that if $LAYER_PATH
> or $INTERFACE_PATH are not set, they will simply be ignored.
>
> All of this with the caveat that $JUJU_REPOSITORY, $LAYER_PATH, and
> $INTERFACE_PATH can be provided / overridden on the CLI.
>
> On Thu, May 11, 2017 at 9:34 AM, Adam Israel
> wrote:
>
>> To confirm: Builds will be replaced by a charms directory, and deps moved
>> to ~/.cache/charm-build. If so, I'm +1 to that.
>>
>> On Thu, May 11, 2017 at 9:28 AM, Cory Johns
>> wrote:
>>
>>> Yes, that's what I'm proposing.
>>>
>>> On Thu, May 11, 2017 at 4:47 AM, Merlijn Sebrechts <
>>> merlijn.sebrec...@gmail.com> wrote:
>>>
It seems like deps should go under ~/.cache/charm-build/
+1
Now, to be clear, the structure you propose is something like the
following?
├── charms# $JUJU_REPOSITORY
│ ├── my-charm
│ ├── ...
├── interfaces# $INTERFACE_PATH
│ ├── ...
├── layers# $LAYER_PATH
│ ├── ...
2017-05-10 23:39 GMT+02:00 Cory Johns :
> There are separate env vars for layers and interfaces, and there
> should probably be CLI args as well. Perhaps instead of being required
> like the output dir, if they're not provided they just aren't used.
>
> It seems like deps should go under ~/.cache/charm-build/
>
> On Wed, May 10, 2017 at 3:36 PM, Merlijn Sebrechts <
> merlijn.sebrec...@gmail.com> wrote:
>
>> * Drop the "builds" portion of the output directory (that was mainly
>>> to distinguish it from the series portion).
>>>
>>
>> We still need to distinguish the charms from `deps` and possibly from
>> `layers` and `interfaces`.
>>
>> This is my $JUJU_REPOSITORY:
>>
>> ├── charms
>> │ ├── builds
>> │ ├── deps
>> │ ├── interfaces
>> │ ├── layers
>>
>>
>> 2017-05-10 20:03 GMT+02:00 Cory Johns :
>>
>>> Started on https://github.com/juju/charm-tools/pull/320, I'd like
>>> to bring this discussion to the list.
>>>
>>> The output directory for charm build can vary in seemingly
>>> unpredictable ways depending on how it is called, the environment, and
>>> the
>>> charm's metadata.yaml contents. This is due to historical reasons,
>>> primarily with how Juju 1.x worked and how charm paths worked prior to
>>> the
>>> advent of multi-series charms. However, now that 2.x and multi-series
>>> support are standard, I would like to push for simplifying the output
>>> directory, based on Merlijn's PR.
>>>
>>> Specifically, I'd like to push for the following changes:
>>>
>>> * Drop the series portion of the output directory (we recommend
>>> providing the series in the charm's metadata, making it redundant in the
>>> path).
>>> * Drop the "builds" portion of the output directory (that was mainly
>>> to distinguish it from the series portion).
>>> * Drop the current directory as a fallback option for the output
>>> directory (it causes more confusion than it saves).
>>>
>>> Thus, charm build would always require an output directory to be
>>> given either via --output-dir (-o) or via the $JUJU_REPOSITORY
>>> environment
>>> variable, and would always put the built charm in
>>> $output_dir/$charm_name
>>>
>>> Obviously, this is not backwards compatible, and may affect
>>> automated build systems, but I think it would be easy to adjust for and
>>> simplify things for everyone concerned.
>>>
>>> Thoughts? Objections?
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm
>>> an/listinfo/juju
>>>
>>>
>>
>
>>>
>>> --
>>> Juju mailing list
>>> Juju@lists.ubuntu.com
>>> Modify settings or unsubscribe
Re: [Review Queue] Elastisys Charmscaler Promulgated!
On 21 March 2017 at 13:00, Merlijn Sebrechts wrote: > Awesome stuff! > > Would it make sense to expose the autoscaling options over an > interface/relationship? So that you can connect the autoscaler to a charm > and the charm tells the autoscaler how it should be scaled > Yea! It would be really good to let developers decide which metrics is the most useful to look at when autoscaling their application, especially since that is one of the big strengths in Juju - letting the experts give you sane defaults. I've been juggling the idea about integrating the Juju metrics into the CharmScaler seeing how that would give the charmers an already existing interface to specify their application metrics. However, as it stands right now, Juju only collects those metrices every five minutes which obviously wouldn't be a sufficient rate for smooth autoscaling. > > > 2017-03-20 21:54 GMT+01:00 Simon Kollberg : > >> >> >> On 20 March 2017 at 18:13, Charles Butler >> wrote: >> >>> Greetings, >>> >>> I realized last week I had completed a review and failed to send an >>> update to the mailing list. As some of you may have heard on the Juju Show >>> that Elastisys released their Charm Scaler to the promulgated channel. >>> >>> >>> This was an easy +1 from me, with comprehensive test suites, and example >>> cases for auto-horizontal-scaling workloads based on CPU load. >>> >>> https://jujucharms.com/charmscaler/ >>> >>> >> Thanks a lot for the review, Charles! >> >> We're really looking forward to see the community use our autoscaler to >> increase performance and availability for all of the awesome charms out >> there and we hope the CharmScaler can become a great addition to the Juju >> ecosystem. The CharmScaler is very much in it's infancy when it comes to >> functionality but we are planning on extending it with a lot of features >> that is already available in the Elastisys platform such as support for >> more built-in and custom metrics, smarter scaling-algorithms and >> robustness. We also welcome PRs, feature requests and/or bug reports on the >> charm's GitHub page https://github.com/elastisys/layer-charmscaler . >> >> >>> This particular charm is near and dear to my own interests, as they have >>> published a POC bundle using Canonical Distribution of Kubernetes as the >>> subject matter. Enjoy horizontally scaled workers when you reach node >>> pressure thresholds on CPU. >>> >>> https://jujucharms.com/u/elastisys/autoscaled-kubernetes/0 >>> >> >> Seeing how easy Juju makes bundling charms together building and >> deploying the autoscaled Kubernetes was a sheer pleasure. To be honest, >> what took me the most time was creating a (sort of) nice look for the GUI. >> :) However, I think we should go one step further. Rather than having to >> create a completely new bundle every time you want to extend a "core" >> bundle with one or more charms, why not enable bundles in the bundle >> manifests? That way two or more bundles could be combined just like charms. >> I know I'm not the first one to bring this up, so if this has already been >> requested on the mailing-list excuse this and just count it as a +1! >> >> >>> >>> >>> Congratulations on your promulgation status to our friends >>> at Elastisys! I look forward to seeing the bundles this charm unlocks the >>> auto-scaling goodness thanks to tight integration with Juju. >>> >> >> We are very excited to see our charm getting the Juju stamp of approval! >> Thanks again. >> >> >>> >>> All the best, >>> >>> Charles >>> -- >>> Juju Charmer >>> Canonical Group Ltd. >>> Ubuntu - Linux for human beings | www.ubuntu.com >>> conjure-up canonical-kubernetes | jujucharms.com >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >>> an/listinfo/juju >>> >>> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm >> an/listinfo/juju >> >> > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Re: [Review Queue] Elastisys Charmscaler Promulgated!
On 20 March 2017 at 18:13, Charles Butler wrote: > Greetings, > > I realized last week I had completed a review and failed to send an update > to the mailing list. As some of you may have heard on the Juju Show that > Elastisys released their Charm Scaler to the promulgated channel. > > > This was an easy +1 from me, with comprehensive test suites, and example > cases for auto-horizontal-scaling workloads based on CPU load. > > https://jujucharms.com/charmscaler/ > > Thanks a lot for the review, Charles! We're really looking forward to see the community use our autoscaler to increase performance and availability for all of the awesome charms out there and we hope the CharmScaler can become a great addition to the Juju ecosystem. The CharmScaler is very much in it's infancy when it comes to functionality but we are planning on extending it with a lot of features that is already available in the Elastisys platform such as support for more built-in and custom metrics, smarter scaling-algorithms and robustness. We also welcome PRs, feature requests and/or bug reports on the charm's GitHub page https://github.com/elastisys/layer-charmscaler . > This particular charm is near and dear to my own interests, as they have > published a POC bundle using Canonical Distribution of Kubernetes as the > subject matter. Enjoy horizontally scaled workers when you reach node > pressure thresholds on CPU. > > https://jujucharms.com/u/elastisys/autoscaled-kubernetes/0 > Seeing how easy Juju makes bundling charms together building and deploying the autoscaled Kubernetes was a sheer pleasure. To be honest, what took me the most time was creating a (sort of) nice look for the GUI. :) However, I think we should go one step further. Rather than having to create a completely new bundle every time you want to extend a "core" bundle with one or more charms, why not enable bundles in the bundle manifests? That way two or more bundles could be combined just like charms. I know I'm not the first one to bring this up, so if this has already been requested on the mailing-list excuse this and just count it as a +1! > > > Congratulations on your promulgation status to our friends at Elastisys! > I look forward to seeing the bundles this charm unlocks the auto-scaling > goodness thanks to tight integration with Juju. > We are very excited to see our charm getting the Juju stamp of approval! Thanks again. > > All the best, > > Charles > -- > Juju Charmer > Canonical Group Ltd. > Ubuntu - Linux for human beings | www.ubuntu.com > conjure-up canonical-kubernetes | jujucharms.com > > -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: https://lists.ubuntu.com/mailm > an/listinfo/juju > > -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
Orchestration charms
Hello Juju people! I'm currently working on a charm with a some what special characteristics. We call it the CharmScaler. The purpose of the charm is to automatically scale the number of units of a charm depending on the current usage of the application. Much like the autoscaling in Kubernetes and AWS. To do this the charm utilizes the newly created Juju Python library. Just like you can control your own deployment with the Juju client, the CharmScaler is able to do operations on the controller it has access to. Giving charms privileges like this really opens up a whole new world of possibilities where in charms will be able to orchestrate other charms in numerous ways not possible before. Right now, the user needs to manually provide credentials (via the charm config) to the CharmScaler enabling it to connect and execute operations on the Juju controller. What I would love to see is a way to make certain charms have special access - some kind of "orchestrator charm privilege" where the necessary credentials needed by the python lib would be passed to the charm automagically. I really have the feeling having this kind of "orchestrator charm" functionality in Juju would benefit the community greatly. Though, I do think it should be something more ingrained in Juju itself rather than making developers come up with their own tricks to provide the charms with credentials. Let me know what you think! - Simon -- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
