[Hawkular-dev] OpenShift Deployment

[Thomas Heute]

+1

On Thu, Nov 30, 2017 at 2:56 PM, Matthew Wringe <mwringe at redhat.com> wrote:

> Yeah, I think we should go with the all-in-one pod approach for now. If we
> discover certain use cases that wont work properly we can re-evaluate.
>
> On Thu, Nov 30, 2017 at 5:15 AM, Lucas Ponce <lponce at redhat.com> wrote:
>
>>
>>
>> On Thu, Nov 30, 2017 at 10:55 AM, Lucas Ponce <lponce at redhat.com> wrote:
>>
>>>
>>>
>>> On Mon, Nov 27, 2017 at 4:38 PM, Matthew Wringe <mwringe at redhat.com>
>>> wrote:
>>>
>>>> With the changes that are now going to include Prometheus, how do we
>>>> want to deploy this in OpenShift?
>>>>
>>>> We can have a few options:
>>>>
>>>> ALL-IN-ONE CONTAINER
>>>> We put both Hawkular Services and Prometheus in the same container.
>>>>
>>>> Pros:
>>>> - easy to deploy in plain docker (but this doesn't appear to be a
>>>> usecase we are targetting anyways)
>>>> - shares the same network connection (even localhost) and ip address
>>>> (eg but both services are on the different ports).
>>>> - Does't require any special wiring of components.
>>>> - Can share the same volume mount
>>>> - version of components can't get out of sync.
>>>>
>>>> Cons:
>>>> - workflow doesn't work nicely. Docker containers are meant to only run
>>>> a single application and running two can cause problems. Eg lifecycle
>>>> events would become tricky and require some hacks to get around things.
>>>> - can't independently deploy things
>>>> - can't reuse or share any existing Prometheus docker containers.
>>>>
>>>> ALL-IN-ONE POD
>>>> Hawkular Services and Prometheus are in their own containers, but they
>>>> are both deployed within the same pod.
>>>>
>>>> Pros:
>>>> - shares the same network connection.
>>>> - bound to the same machine (useful if sharing the same hostpath pv)
>>>> and don' need to worry about external network configurations (eg firewalls
>>>> between OpenShift nodes)
>>>> - pvs can be shared or separate.
>>>> - lifecycle events will work properly.
>>>>
>>>> Cons:
>>>> - lifecycle hooks will mean that both containers will have to pass
>>>> before either one will enter the ready state. So if Prometheus is failing
>>>> for some reason, Hawkular Services will not be available under the service.
>>>> - cannot independently update one container. If we need to deploy a new
>>>> container we will need to bring down the whole pod.
>>>> - are stuck with a 1:1 ratio between Hawkular Services and Prometheus
>>>>
>>>>
>>> One technical requeriment is that Hawkular Services needs to now where
>>> is Prometheus server at initialization.
>>>
>>
>> One technical requeriment is that Hawkular Services needs to *know* where
>> is Prometheus server at initialization.
>>
>> [Sorry, typing fast]
>>
>> So, I guess that all-in-one pod will simplify things on this case.
>>>
>>> I would start with this architecture first and harden the basic
>>> scenarios.
>>>
>>>
>>>>
>>>> SEPARATE PODS
>>>> Hawkular Services and Prometheus have their own separate pods.
>>>>
>>>> Pros:
>>>> - can independently run components and each component has its own
>>>> separate lifecycle
>>>> - if in the future we want to cluster Hawkular Services. this will make
>>>> it a lot easier and will also allow for running an n:m ratio between
>>>> Hawkular Services and Prometheus
>>>> - probably the more 'correct' way to deploy things as we don't have a
>>>> strong requirement for Hawkular Services and Prometheus to run together.
>>>>
>>>> Cons:
>>>> - more complex wiring. We will need to have extra services and routes
>>>> created to handle this. This mean more things running and more chances for
>>>> things to go wrong. Also more things to configure
>>>> - reusing a PV between Hawkular Services and Prometheus could be more
>>>> challenging (especially if we are using hostpath pvs). Updating the
>>>> Prometheus scrape endpoint may require a new component and container.
>>>>
>>>> _______________________________________________
>>>> hawkular-dev mailing list
>>>> hawkular-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> hawkular-dev mailing list
>> hawkular-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hawkular-dev/attachments/20171204/a236f499/attachment.html