4:35 a.m.
+1
On Thu, Nov 30, 2017 at 2:56 PM, Matthew Wringe <mwringe(a)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(a)redhat.com> wrote:
>
>
> On Thu, Nov 30, 2017 at 10:55 AM, Lucas Ponce <lponce(a)redhat.com> wrote:
>
>>
>>
>> On Mon, Nov 27, 2017 at 4:38 PM, Matthew Wringe <mwringe(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>>>
>>>
>>
>
> _______________________________________________
> hawkular-dev mailing list
> hawkular-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hawkular-dev
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev