Re: Intermittent service interruption on jujucharms.com

[Jeff Pihach]

The jujucharms.com interruption has been resolved. Thanks for your patience!

On Tue, Mar 21, 2017 at 2:13 PM, Jeff Pihach 
wrote:

> Hi everyone,
>
> We're working on a resolution for those experiencing intermittent service
> interruption with jujucharms.com. This only affects jujucharms.com and
> does not affect Juju CLI operations like creating models and deploying
> charms/bundles.
>
> Sorry for the inconvenience.
>
>
>
-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Intermittent service interruption on jujucharms.com

[Jeff Pihach]

Hi everyone,

We're working on a resolution for those experiencing intermittent service
interruption with jujucharms.com. This only affects jujucharms.com and does
not affect Juju CLI operations like creating models and deploying
charms/bundles.

Sorry for the inconvenience.
-- 
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!

[Merlijn Sebrechts]

PS: The in-page links in your README don't work in the charm store because
of this bug: https://github.com/juju/juju-gui/issues/2650
If you want' add a :+1: to that bug so they know I'm not the only one using
such links ;)

PPS: I saw *"By using the Elastisys CharmScaler, you agree to its license
and privacy statement."* at the bottom of your readme. You might want to
look at the "terms" feature. https://jujucharms.com/docs/2.1/developer-terms

2017-03-21 14:10 GMT+01:00 Merlijn Sebrechts :

> The issue I see here is that there is much more momentum behind stuff like
> Nagios. It would be great if you could just plug this into existing
> monitoring/metrics solutions.
>
> I see the Charm has some Nagios-related config options and relations, is
> there some documentation about how this charm integrates with Nagios?
>
> 2017-03-21 13:36 GMT+01:00 Simon Kollberg :
>
>>
>>
>> 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
> 

Re: [Review Queue] Elastisys Charmscaler Promulgated!

[Merlijn Sebrechts]

The issue I see here is that there is much more momentum behind stuff like
Nagios. It would be great if you could just plug this into existing
monitoring/metrics solutions.

I see the Charm has some Nagios-related config options and relations, is
there some documentation about how this charm integrates with Nagios?

2017-03-21 13:36 GMT+01:00 Simon Kollberg :

>
>
> 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!

[Simon Kollberg]

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!

[Rick Harding]

The question there is how different businesses will have different rules. I
think it makes sense for a relation to describe what the charm author
thinks is useful parameters/etc and maybe some default scaling config but I
think that different folks will have different tastes to this. Especially
as workloads are deployed on different sized instances in the cloud.

I think that having things as a relation is much more interesting when we
have relation config so that the charms can define some standard
definitions and the user making the relation can tweak how they work in
practice.

On Tue, Mar 21, 2017 at 8:01 AM Merlijn Sebrechts <
merlijn.sebrec...@gmail.com> 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
>
>
> 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/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: [Review Queue] Elastisys Charmscaler Promulgated!

[Merlijn Sebrechts]

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


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

Re: monitoring your production juju controllers

[Rick Harding]

Jacek, let's talk on the mongodb exporter sometime. I tried to get it
running but was unable to figure out how to get it to talk to the juju
mongodb. All I could get out of it was generic connection errors.

The relation thing you note is interesting. There's talk on the roadmap of
exposing controllers as relatable applications which makes a lot of this
easier as controllers can then just expose a prometheus endpoint and it
would do things like allow placing the Telegraf subordinate without first
using the Ubuntu charm as a relation endpoint.

As for the Grafana datasource, no reason at all. I just walked through
setting it up and I missed the relation there. I'll have to test that out
and update the article. Thanks for the heads up!


On Tue, Mar 21, 2017 at 5:01 AM Jacek Nykis 
wrote:

> On 20/03/17 18:04, Rick Harding wrote:
> > During The Juju Show #8 [1] last week we talked about how to setup your
> > controllers to be provide metrics through Prometheus to Grafana to keep
> > an eye on those controllers in production.
> >
> > I put together a blog post [2] about how to set it up, configure Juju,
> > and links to the sample json for an out of the box dashboard to use.
> > Give it a try and let me know what you would add to keep an eye on your
> > own production Juju.
> >
> > Rick
> >
> > 1: https://www.youtube.com/watch?v=tjp_JHSZCyA
> > 2: http://mitechie.com/blog/2017/3/20/operations-in-production
>
> Hi,
>
> We also added mongodb exporter [0] for more in depth mongodb metrics. It
> currently requires manual set up because juju mongo does not support
> relations but once that is done it works great!
>
> I have one question about your article - is there any specific reason
> you configure grafana datasource by hand as opposed to using
> "grafana-source" relation? This should work just fine:
>
> juju add-relation prometheus:grafana-source grafana:grafana-source
>
> Jacek
>
> [0] https://github.com/dcu/mongodb_exporter
>
> --
> 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: Can't juju deploy p2.xlarge in aws/us-east-1

[John Meinel]

Preferring a VPC if there is a single one that exists, even if it isn't
flagged as "default" for a region would probably be reasonable, and
probably not a lot of effort. If there are multiple, I wonder if we could
refuse to bootstrap/add-model unless one is specified.

John
=:->


On Tue, Mar 21, 2017 at 3:04 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Mon, Mar 20, 2017 at 10:17 PM Junien Fridrick <
> junien.fridr...@canonical.com> wrote:
>
>> And once/if you have no Classic instance running in a region, you should
>> file a ticket to AWS Support asking for a default VPC creation. Once
>> it's done, you don't need to supply the VPC ID anymore.
>>
>> Could juju maybe be instructed to use a VPC if and only if a single VPC
>> exist in a region, without specifying its ID ? For example, --config
>> "force-vpc=true" or something.
>>
>
> Yes we could do that. I'd like to go a bit further; what I would like to
> have happen is:
>
> 1. juju will use the VPC specified in config, if any
> 2. else, Juju will look for a VPC called (say) "juju-default-vpc"
> 3. else, Juju will create a VPC with the same name, if it can*, and use
> that
> 4. else, Juju will use the default VPC, if available
> 5. else, bootstrap/add-model will fail
>
> The outcome being that Juju will then *always* use VPC, and the user
> shouldn't need to do a thing. This would also allow the provider to be
> cleaned up (assuming there's a migration path for existing deployments),
> and new features to be implemented more easily (e.g. support for EFS).
>
> Everyone on the team is currently fully booked, so I can't give you an
> estimate of when that'll come to fruition yet. We could do everything
> except have Juju fail pretty easily I would think.
>
> * "if it can", because there are pretty severe limits on the number of
> VPCs you can create: 5 per region.
>
> Cheers,
> Andrew
>
>
>> On Thu, Mar 16, 2017 at 08:04:22AM -0400, Tim Van Steenburgh wrote:
>> > A. That was it. After passing --config "vpc-id=vpc-924fc7f6" to
>> `juju
>> > bootstrap`, I can now deploy p2 instance types. Thanks Andrew!
>> >
>> > On Thu, Mar 16, 2017 at 4:21 AM, Samuel Cozannet <
>> > samuel.cozan...@canonical.com> wrote:
>> >
>> > > Aaah whaow. I have a default VPC myself, so that may explain the
>> problem
>> > > Tim is having. Early adopters problem!!
>> > >
>> > >
>> > > --
>> > > Samuel Cozannet
>> > > Cloud, Big Data and IoT Strategy Team
>> > > Business Development - Cloud and ISV Ecosystem
>> > > Changing the Future of Cloud
>> > > Ubuntu   / Canonical UK LTD 
>> /
>> > > Juju 
>> > > samuel.cozan...@canonical.com
>> > > mob: +33 616 702 389
>> > > skype: samnco
>> > > Twitter: @SaMnCo_23
>> > > [image: View Samuel Cozannet's profile on LinkedIn]
>> > > 
>> > >
>> > > On Thu, Mar 16, 2017 at 9:17 AM, Andrew Wilkins <
>> > > andrew.wilk...@canonical.com> wrote:
>> > >
>> > >> On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet <
>> > >> samuel.cozan...@canonical.com> wrote:
>> > >>
>> > >>> I am using the default settings, no change as far as I know to what
>> Juju
>> > >>> would do by default.
>> > >>>
>> > >>
>> > >> What Juju will do depends on what is available in your EC2 account.
>> Not
>> > >> all EC2 accounts were born alike.
>> > >>
>> > >> If your account has a default VPC, that will be used by Juju. In that
>> > >> case, you'll have p2 instance types available. I expect this to be
>> the case
>> > >> for most people - all accounts created since 2013-12-04 will have a
>> default
>> > >> VPC.
>> > >>
>> > >> If you've got an older account, then you may or may not have a
>> default
>> > >> VPC. If you do not, then Juju will fall back to EC2 Classic. In that
>> case,
>> > >> no p2 instance types.
>> > >>
>> > >> Cheers,
>> > >> Andrew
>> > >>
>> > >>
>> > >>> --
>> > >>> Samuel Cozannet
>> > >>> Cloud, Big Data and IoT Strategy Team
>> > >>> Business Development - Cloud and ISV Ecosystem
>> > >>> Changing the Future of Cloud
>> > >>> Ubuntu   / Canonical UK LTD <
>> http://canonical.com> /
>> > >>> Juju 
>> > >>> samuel.cozan...@canonical.com
>> > >>> mob: +33 616 702 389
>> > >>> skype: samnco
>> > >>> Twitter: @SaMnCo_23
>> > >>> [image: View Samuel Cozannet's profile on LinkedIn]
>> > >>> 
>> > >>>
>> > >>> On Thu, Mar 16, 2017 at 8:52 AM, Andrew Wilkins <
>> > >>> andrew.wilk...@canonical.com> wrote:
>> > >>>
>> > >>> On Tue, Mar 14, 2017 at 8:48 PM Tim Van Steenburgh <
>> > >>> tim.van.steenbu...@canonical.com> wrote:
>> > >>>
>> > >>> 2.1.1 juju client and controller, controller bootstrapped in
>> > >>> aws/us-east-1:
>> > >>>
>> > >>> juju deploy ./kubernetes-worker --constraints
>> "instance-type=p2.xlarge" kubernetes-worker-gpu
>> > >>> Deploying charm "local:xenial/kubernetes-worker-1".
>> > >>> ERROR cannot add application "kubernetes-worker-gpu": 

Re: Can't juju deploy p2.xlarge in aws/us-east-1

[John Meinel]

Preferring a VPC if there is a single one that exists, even if it isn't
flagged as "default" for a region would probably be reasonable, and
probably not a lot of effort. If there are multiple, I wonder if we could
refuse to bootstrap/add-model unless one is specified.

John
=:->


On Tue, Mar 21, 2017 at 3:04 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Mon, Mar 20, 2017 at 10:17 PM Junien Fridrick <
> junien.fridr...@canonical.com> wrote:
>
>> And once/if you have no Classic instance running in a region, you should
>> file a ticket to AWS Support asking for a default VPC creation. Once
>> it's done, you don't need to supply the VPC ID anymore.
>>
>> Could juju maybe be instructed to use a VPC if and only if a single VPC
>> exist in a region, without specifying its ID ? For example, --config
>> "force-vpc=true" or something.
>>
>
> Yes we could do that. I'd like to go a bit further; what I would like to
> have happen is:
>
> 1. juju will use the VPC specified in config, if any
> 2. else, Juju will look for a VPC called (say) "juju-default-vpc"
> 3. else, Juju will create a VPC with the same name, if it can*, and use
> that
> 4. else, Juju will use the default VPC, if available
> 5. else, bootstrap/add-model will fail
>
> The outcome being that Juju will then *always* use VPC, and the user
> shouldn't need to do a thing. This would also allow the provider to be
> cleaned up (assuming there's a migration path for existing deployments),
> and new features to be implemented more easily (e.g. support for EFS).
>
> Everyone on the team is currently fully booked, so I can't give you an
> estimate of when that'll come to fruition yet. We could do everything
> except have Juju fail pretty easily I would think.
>
> * "if it can", because there are pretty severe limits on the number of
> VPCs you can create: 5 per region.
>
> Cheers,
> Andrew
>
>
>> On Thu, Mar 16, 2017 at 08:04:22AM -0400, Tim Van Steenburgh wrote:
>> > A. That was it. After passing --config "vpc-id=vpc-924fc7f6" to
>> `juju
>> > bootstrap`, I can now deploy p2 instance types. Thanks Andrew!
>> >
>> > On Thu, Mar 16, 2017 at 4:21 AM, Samuel Cozannet <
>> > samuel.cozan...@canonical.com> wrote:
>> >
>> > > Aaah whaow. I have a default VPC myself, so that may explain the
>> problem
>> > > Tim is having. Early adopters problem!!
>> > >
>> > >
>> > > --
>> > > Samuel Cozannet
>> > > Cloud, Big Data and IoT Strategy Team
>> > > Business Development - Cloud and ISV Ecosystem
>> > > Changing the Future of Cloud
>> > > Ubuntu   / Canonical UK LTD 
>> /
>> > > Juju 
>> > > samuel.cozan...@canonical.com
>> > > mob: +33 616 702 389
>> > > skype: samnco
>> > > Twitter: @SaMnCo_23
>> > > [image: View Samuel Cozannet's profile on LinkedIn]
>> > > 
>> > >
>> > > On Thu, Mar 16, 2017 at 9:17 AM, Andrew Wilkins <
>> > > andrew.wilk...@canonical.com> wrote:
>> > >
>> > >> On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet <
>> > >> samuel.cozan...@canonical.com> wrote:
>> > >>
>> > >>> I am using the default settings, no change as far as I know to what
>> Juju
>> > >>> would do by default.
>> > >>>
>> > >>
>> > >> What Juju will do depends on what is available in your EC2 account.
>> Not
>> > >> all EC2 accounts were born alike.
>> > >>
>> > >> If your account has a default VPC, that will be used by Juju. In that
>> > >> case, you'll have p2 instance types available. I expect this to be
>> the case
>> > >> for most people - all accounts created since 2013-12-04 will have a
>> default
>> > >> VPC.
>> > >>
>> > >> If you've got an older account, then you may or may not have a
>> default
>> > >> VPC. If you do not, then Juju will fall back to EC2 Classic. In that
>> case,
>> > >> no p2 instance types.
>> > >>
>> > >> Cheers,
>> > >> Andrew
>> > >>
>> > >>
>> > >>> --
>> > >>> Samuel Cozannet
>> > >>> Cloud, Big Data and IoT Strategy Team
>> > >>> Business Development - Cloud and ISV Ecosystem
>> > >>> Changing the Future of Cloud
>> > >>> Ubuntu   / Canonical UK LTD <
>> http://canonical.com> /
>> > >>> Juju 
>> > >>> samuel.cozan...@canonical.com
>> > >>> mob: +33 616 702 389
>> > >>> skype: samnco
>> > >>> Twitter: @SaMnCo_23
>> > >>> [image: View Samuel Cozannet's profile on LinkedIn]
>> > >>> 
>> > >>>
>> > >>> On Thu, Mar 16, 2017 at 8:52 AM, Andrew Wilkins <
>> > >>> andrew.wilk...@canonical.com> wrote:
>> > >>>
>> > >>> On Tue, Mar 14, 2017 at 8:48 PM Tim Van Steenburgh <
>> > >>> tim.van.steenbu...@canonical.com> wrote:
>> > >>>
>> > >>> 2.1.1 juju client and controller, controller bootstrapped in
>> > >>> aws/us-east-1:
>> > >>>
>> > >>> juju deploy ./kubernetes-worker --constraints
>> "instance-type=p2.xlarge" kubernetes-worker-gpu
>> > >>> Deploying charm "local:xenial/kubernetes-worker-1".
>> > >>> ERROR cannot add application "kubernetes-worker-gpu": 

Re: monitoring your production juju controllers

[Jacek Nykis]

On 20/03/17 18:04, Rick Harding wrote:
> During The Juju Show #8 [1] last week we talked about how to setup your
> controllers to be provide metrics through Prometheus to Grafana to keep
> an eye on those controllers in production. 
> 
> I put together a blog post [2] about how to set it up, configure Juju,
> and links to the sample json for an out of the box dashboard to use.
> Give it a try and let me know what you would add to keep an eye on your
> own production Juju. 
> 
> Rick
> 
> 1: https://www.youtube.com/watch?v=tjp_JHSZCyA
> 2: http://mitechie.com/blog/2017/3/20/operations-in-production

Hi,

We also added mongodb exporter [0] for more in depth mongodb metrics. It
currently requires manual set up because juju mongo does not support
relations but once that is done it works great!

I have one question about your article - is there any specific reason
you configure grafana datasource by hand as opposed to using
"grafana-source" relation? This should work just fine:

juju add-relation prometheus:grafana-source grafana:grafana-source

Jacek

[0] https://github.com/dcu/mongodb_exporter



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

Re: Can't juju deploy p2.xlarge in aws/us-east-1

[Samuel Cozannet]

Isn't this spending time on a problem that will tend to disappear (and is
probably already only like 0.1% of the user base)?

Not sure it's worth the effort. Just specify Juju requires a VPC in the
docs, and explain exactly how to fix it (call AWS...) and there you go. No
code, problem solved.

++
Sam


--
Samuel Cozannet
Cloud, Big Data and IoT Strategy Team
Business Development - Cloud and ISV Ecosystem
Changing the Future of Cloud
Ubuntu   / Canonical UK LTD  / Juju

samuel.cozan...@canonical.com
mob: +33 616 702 389
skype: samnco
Twitter: @SaMnCo_23
[image: View Samuel Cozannet's profile on LinkedIn]


On Tue, Mar 21, 2017 at 12:04 AM, Andrew Wilkins <
andrew.wilk...@canonical.com> wrote:

> On Mon, Mar 20, 2017 at 10:17 PM Junien Fridrick <
> junien.fridr...@canonical.com> wrote:
>
>> And once/if you have no Classic instance running in a region, you should
>> file a ticket to AWS Support asking for a default VPC creation. Once
>> it's done, you don't need to supply the VPC ID anymore.
>>
>> Could juju maybe be instructed to use a VPC if and only if a single VPC
>> exist in a region, without specifying its ID ? For example, --config
>> "force-vpc=true" or something.
>>
>
> Yes we could do that. I'd like to go a bit further; what I would like to
> have happen is:
>
> 1. juju will use the VPC specified in config, if any
> 2. else, Juju will look for a VPC called (say) "juju-default-vpc"
> 3. else, Juju will create a VPC with the same name, if it can*, and use
> that
> 4. else, Juju will use the default VPC, if available
> 5. else, bootstrap/add-model will fail
>
> The outcome being that Juju will then *always* use VPC, and the user
> shouldn't need to do a thing. This would also allow the provider to be
> cleaned up (assuming there's a migration path for existing deployments),
> and new features to be implemented more easily (e.g. support for EFS).
>
> Everyone on the team is currently fully booked, so I can't give you an
> estimate of when that'll come to fruition yet. We could do everything
> except have Juju fail pretty easily I would think.
>
> * "if it can", because there are pretty severe limits on the number of
> VPCs you can create: 5 per region.
>
> Cheers,
> Andrew
>
>
>> On Thu, Mar 16, 2017 at 08:04:22AM -0400, Tim Van Steenburgh wrote:
>> > A. That was it. After passing --config "vpc-id=vpc-924fc7f6" to
>> `juju
>> > bootstrap`, I can now deploy p2 instance types. Thanks Andrew!
>> >
>> > On Thu, Mar 16, 2017 at 4:21 AM, Samuel Cozannet <
>> > samuel.cozan...@canonical.com> wrote:
>> >
>> > > Aaah whaow. I have a default VPC myself, so that may explain the
>> problem
>> > > Tim is having. Early adopters problem!!
>> > >
>> > >
>> > > --
>> > > Samuel Cozannet
>> > > Cloud, Big Data and IoT Strategy Team
>> > > Business Development - Cloud and ISV Ecosystem
>> > > Changing the Future of Cloud
>> > > Ubuntu   / Canonical UK LTD 
>> /
>> > > Juju 
>> > > samuel.cozan...@canonical.com
>> > > mob: +33 616 702 389
>> > > skype: samnco
>> > > Twitter: @SaMnCo_23
>> > > [image: View Samuel Cozannet's profile on LinkedIn]
>> > > 
>> > >
>> > > On Thu, Mar 16, 2017 at 9:17 AM, Andrew Wilkins <
>> > > andrew.wilk...@canonical.com> wrote:
>> > >
>> > >> On Thu, Mar 16, 2017 at 3:57 PM Samuel Cozannet <
>> > >> samuel.cozan...@canonical.com> wrote:
>> > >>
>> > >>> I am using the default settings, no change as far as I know to what
>> Juju
>> > >>> would do by default.
>> > >>>
>> > >>
>> > >> What Juju will do depends on what is available in your EC2 account.
>> Not
>> > >> all EC2 accounts were born alike.
>> > >>
>> > >> If your account has a default VPC, that will be used by Juju. In that
>> > >> case, you'll have p2 instance types available. I expect this to be
>> the case
>> > >> for most people - all accounts created since 2013-12-04 will have a
>> default
>> > >> VPC.
>> > >>
>> > >> If you've got an older account, then you may or may not have a
>> default
>> > >> VPC. If you do not, then Juju will fall back to EC2 Classic. In that
>> case,
>> > >> no p2 instance types.
>> > >>
>> > >> Cheers,
>> > >> Andrew
>> > >>
>> > >>
>> > >>> --
>> > >>> Samuel Cozannet
>> > >>> Cloud, Big Data and IoT Strategy Team
>> > >>> Business Development - Cloud and ISV Ecosystem
>> > >>> Changing the Future of Cloud
>> > >>> Ubuntu   / Canonical UK LTD <
>> http://canonical.com> /
>> > >>> Juju 
>> > >>> samuel.cozan...@canonical.com
>> > >>> mob: +33 616 702 389
>> > >>> skype: samnco
>> > >>> Twitter: @SaMnCo_23
>> > >>> [image: View Samuel Cozannet's profile on LinkedIn]
>> > >>> 
>> > >>>
>> > >>> On Thu, Mar 16, 2017 at 8:52 AM, Andrew Wilkins <
>> > >>> andrew.wilk...@canonical.com> wrote:
>> > >>>
>> > >>> On Tue, Mar