This is exactly what I was looking for! Thank you so much for this! This is a great way to integrate Juju with Mesos so you get the best of both worlds...
2015-12-01 12:45 GMT+01:00 Nicolas Thomas <[email protected]>: > > > On Mon, Nov 30, 2015 at 7:54 PM, Merlijn Sebrechts < > [email protected]> wrote: > >> Hi Samuel >> >> >> Thanks for your answer! >> >> The injection Charm sounds interesting. So Juju manages both k8s and the >> services running on top of k8s? Do you have an example you can show me? >> > > Better than that a full "dangerous demo" > https://www.youtube.com/watch?v=Q_370CUw5Yk > > And the corresponding bundle to test it on any cloud: > https://jujucharms.com/u/tads2015dataart/tads2015-demo/21 > > The only thing (provided by Truephone) missing is the actual phone number > to the platform link (you can use SIP or SIP Trunk service supported by > Telscale).. > > Enjoy > > > >> > However, monitoring is an expression of the operation and not the >> model, therefore "can not" be operated by Juju. >> >> Can you explain this a bit more? What do you see as model, what do you >> see as operation, and how do actions and hooks fit into this? >> >> > The true real life monitoring is best done from the workload perspective > (sessions, trends, link to generic cpu/ram metrics) .. It comes after you > model your architecture and must not dictate the way you model. > > BUT Juju have an API allowing to use cleanly modelled scale out > capabilities in Juju to react to your monitoring (this can vary from test, > benchmark, prod, etc...) this is what the demo does if Mesos start to reach > the limits juju extend mesos (and dependencies), same if way underused.. > > Hope this makes the intent clearer.. > > > >> > Scaling should not depend on Juju either in our current vision. It's >> not an expression of a model, but rather of how to operate the model. >> >> If I understand correctly, the model (Charms) should specify how a >> service can scale, and an external entity (the user or another service) >> should specify when those scaling actions should be called? >> >> I'd like for bundles to be able to specify a lot more about the >> "macroservice" they deploy. So you could run "juju add-unit" on a bundle, >> and it would scale the required services. Ofcourse, this will have to be a >> lot "smarter" because each macroservice has a number of different ways to >> scale. I think a lot of this functionality can be accomplished if a bundle >> would be able to have actions or hooks... Another use-case would be to >> upgrade all charms in a bundle to versions that are known to work together, >> although I think this is currently possible using the deployer... >> >> >> >> Kind regards >> Merlijn Sebrechts >> >> >> 2015-11-30 16:13 GMT+01:00 Samuel Cozannet <[email protected] >> >: >> >>> Adding Artyom from DataArt who has a lot of very clever ideas about this >>> and recently created a cool autoscaling demo. >>> >>> I'm interested in any follow up given to your work. I share your >>> frustration at containers systems using a so called "orchestration" when >>> the orchestration is really some basic hooks. >>> The consequence of these systems is a total absence of portability >>> between techs (moving from k8s to Swarm or worse Mesos requires a lot of >>> rewriting the core and even sometimes rebuild some of the containers to >>> adapt to the service discovery APIs). Something that Juju wants to address >>> really well. >>> >>> My path so far is to create specific injection charms for k8s and others >>> (Swarm so far). By talking only to the current leader, you kind of create >>> this abstraction you are talking about. >>> That means you can then expose configuration to scale out & in the >>> service by calling the Juju API to reconfigure the service itself. >>> Not a complete solution, but a starting point. The issue with it is that >>> to comply with Juju models, I have to create an injection charm per app, >>> which is additional work on top of containerizing for example. >>> The LXD provider will certainly help in that space, even more when/if >>> LXD become first class citizen in "Container Orchestration Tools". >>> >>> As for monitoring, some charms expose monitoring hooks that can be >>> consumed by other specialized services. As a consequence you can easily >>> integrate not only with service spawned by Juju, but also external systems. >>> However, monitoring is an expression of the operation and not the model, >>> therefore "can not" be operated by Juju. >>> >>> Scaling should not depend on Juju either in our current vision. It's not >>> an expression of a model, but rather of how to operate the model. >>> Therefore, this task should stay outside of Juju, even if it can be >>> operated via Juju's APIs (scale out / in, potentially rolling upgrades in >>> the future). >>> >>> ++ >>> Sam >>> >>> >>> >>> >>> -- >>> Samuel Cozannet >>> Cloud, Big Data and IoT Strategy Team >>> Business Development - Cloud and ISV Ecosystem >>> Changing the Future of Cloud >>> Ubuntu <http://ubuntu.com> / Canonical UK LTD <http://canonical.com> / >>> Juju <https://jujucharms.com> >>> [email protected] >>> mob: +33 616 702 389 >>> skype: samnco >>> Twitter: @SaMnCo_23 >>> [image: View Samuel Cozannet's profile on LinkedIn] >>> <https://es.linkedin.com/in/scozannet> >>> >>> On Mon, Nov 30, 2015 at 2:47 PM, Merlijn Sebrechts < >>> [email protected]> wrote: >>> >>>> Hi all >>>> >>>> >>>> I'd like to start a discussion about how Juju can fit into cluster >>>> managers like Apache Mesos and Kubernetes. >>>> >>>> Currently, Juju fits nicely into this story as a way to setup these >>>> cluster managers. Payloads continue on that idea with Juju as a manager of >>>> a cluster manager. However, I'm a lot more interested in Juju on top of a >>>> cluster manager, where the cluster manager would be a provider Juju uses to >>>> deploy services on. >>>> >>>> Juju provides an awesome way to model complex services in a modular and >>>> re-usable way. The relationships allow for much more complex interactions >>>> between services than what the "service discovery" in Kubernetes and Mesos >>>> allows. Service discovery allows for a service to say "I need the IP's of >>>> these services" but that's pretty much it. No flexible adaptable >>>> infrastructure where services change their behavior depending on what they >>>> are connected to. It basically stems from the same mindset that brought us >>>> tools like Chef and Puppet: One company with a big dev team that creates >>>> services for internal use only. >>>> >>>> >>>> - Cluster managers are very good at scheduling "dumb" workloads. >>>> They're a datacenter kernel, they don't care what runs in the >>>> container. At >>>> best, they provide a way for two containers to communicate (service >>>> discovery). >>>> >>>> >>>> - Juju is very good at configuring applications. It changes >>>> services depending on how they are connected. Juju for the most part >>>> doesn't care where services run, only how they are connected. >>>> >>>> >>>> Combine these two and you could get an awesome PaaS that can run a lot >>>> more than "dumb" 12-factor apps. It bothers me to see frameworks like >>>> Kubernetes use the terminology "service orchestration" when all they do is >>>> connect static services. Juju is on to something with its dynamic >>>> relations, but it seems not many people have caught on... >>>> >>>> I see two possible paths to integrate Service Orchestration with >>>> Cluster management (scheduling): >>>> >>>> >>>> - *Support cluster managers in Juju as providers.* This might be >>>> hard to do since Juju's units require an OS-level container, not a >>>> process >>>> container. Step 1 would be LXD support in Mesos/Kubernetes? >>>> >>>> >>>> - *Write cluster management extensions on top of Juju.* Basically >>>> recreate the scheduling, failover and scaling functionality of >>>> Kubernetes/Mesos in Juju. There seem to be some people in the Juju >>>> ecosystem who are working on their own version of this. I've seen some >>>> people who are trying to automate the up/down scaling of services. >>>> Maybe it >>>> might be good to bundle these efforts and make a generic framework for >>>> this? >>>> >>>> Juju can encapsulate installation and configuration best-practices. >>>> Wouldn't it be great if Juju could encapsulate monitoring, scaling and >>>> scheduling best-practices too? Maybe by making bundles smarter? (Just >>>> imagine: a Hadoop bundle with builtin monitoring and scaling that scales >>>> the workers up/down depending on the need) >>>> >>>> *Now I'm curious to see what you guys think about this. *Do you think >>>> there is a need to integrate Juju with "datacenter kernels"? What is >>>> Canonical's vision about this? What does the community think? >>>> >>>> >>>> >>>> Kind regards >>>> Merlijn Sebrechts >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> Juju mailing list >>>> [email protected] >>>> Modify settings or unsubscribe at: >>>> https://lists.ubuntu.com/mailman/listinfo/juju >>>> >>>> >>> >> >> -- >> Juju mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> > > > -- > Best Regards, > Nicolas Thomas > http://insights.ubuntu.com/?p=889 > EMEA Solution Architect Canonical > GPG FPR: D592 4185 F099 9031 6590 6292 492F C740 F03A 7EB9 >
-- Juju mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
