Juju and cluster managers (like mesos)

Tue Dec 1 12:52:35 UTC 2015

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  <nicolas.thomas at canonical.com>:

>
>
> On Mon, Nov 30, 2015 at 7:54 PM, Merlijn Sebrechts <
> merlijn.sebrechts at gmail.com> 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 <samuel.cozannet at canonical.com
>> >:
>>
>>> 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>
>>> samuel.cozannet at canonical.com
>>> 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 <
>>> merlijn.sebrechts at gmail.com> 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
>>>> Juju at lists.ubuntu.com
>>>> Modify settings or unsubscribe at:
>>>> https://lists.ubuntu.com/mailman/listinfo/juju
>>>>
>>>>
>>>
>>
>> --
>> Juju mailing list
>> Juju at lists.ubuntu.com
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20151201/a5cb73c5/attachment.html>