Hi Raghurama, > Does Juju controller monitor the cluster and request MaaS for a new machine if it detects one of the machines is gone?
No, it doesn't. > Even if this has to be done manually, I did not see a replace-machine option to Juju. There's no such functionality - either an operator needs to make a decision to do it or you need an automated system to do that depending on some custom logic. > Only add and remove units and machines. How does this work? Juju itself does not know anything about applications you deploy - any application-specific knowledge must be present in charms. What you are looking for is an orchestrator type of capability - it will be a layer on top of Juju or a charm with 'super cow powers' (namely, with admin access to a juju controller). A proof of concept would be a charmscaler from elastisys - it talks to a juju controller directly and scales based upon CPU usage from nodes collected via telegraf: https://github.com/elastisys/layer-charmscaler-base/blob/164d163b4104cc47dcb1a32019509ba3f61d91eb/config.yaml#L9-L28 https://github.com/elastisys/layer-charmscaler#how-the-charmscaler-operates https://jujucharms.com/u/elastisys/ https://github.com/elastisys/bundle-autoscaled-kubernetes https://jujucharms.com/u/elastisys/autoscaled-kubernetes/bundle/0 https://elastisys.com/cloud-platform-features/predictive-auto-scaling/ You could build your own orchestrator with help of https://github.com/juju/python-libjuju depending on your criteria. The whole system could look as follows: telegraf with your own juju input plugin -> prometheus alerts -> orchestrator -> juju controller The telegraf plugin would query juju and/or MAAS periodically to determine the number of non-failed workers and send those metrics to prometheus. Googling a little bit, I have found somebody's http server https://github.com/imgix/prometheus-am-executor that handles prometheus' alerts sent as HTTP requests. That kind of HTTP server could well hold your orchestration logic and use python-libjuju to perform the necessary add-unit-on-failure operations. To sum up: it is important to understand the difference between Juju and charms. Juju itself doesn't know anything about application-specific logic - charms do. Charm code is executed by Juju agents at certain events and this is where application-specific logic is actually executed. Any orchestration code must have admin access to the juju controller and contain subjective logic about how to scale-up or scale-down your application. https://github.com/juju/juju/blob/develop/doc/architectural-overview.md#juju-components I hope that helps. Best Regards, Dmitrii Shcherbakov Field Software Engineer IRC (freenode): Dmitrii-Sh On Fri, Sep 1, 2017 at 7:34 PM, Raghurama Bhat <rb...@proofpoint.com> wrote: > Any comments? > > > > Thanks, > > > > --Raghu > > > > *From: *<juju-boun...@lists.ubuntu.com> on behalf of Raghurama Bhat < > rb...@proofpoint.com> > *Date: *Thursday, August 31, 2017 at 8:07 AM > *To: *"juju@lists.ubuntu.com" <juju@lists.ubuntu.com> > *Subject: *Newbie Question: How do I replace a machine in a deployed > Model? > > > > Hi, > > > > I have a newbie question. I deployed a two node Kubernetes Core Cluster > using Juju into a MaaS Setup. Now if I one of the Machine has a hardware > failure, What is the process for replacing it with another machine? Does > Juju controller monitor the cluster and request MaaS for a new machine if > it detects one of the machines is gone? Even if this has to be done > manually, I did not see a replace-machine option to Juju. Only add and > remove units and machines. How does this work? > > > > Thanks, > > > > --Raghu > > -- > 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
