[Hawkular-dev] OpenShift Deployment

[Jay Shaughnessy]

On 11/30/2017 5:15 AM, Lucas Ponce wrote:
>
>
> On Thu, Nov 30, 2017 at 10:55 AM, Lucas Ponce <lponce at redhat.com 
> <mailto:lponce at redhat.com>> wrote:
>
>
>
>     On Mon, Nov 27, 2017 at 4:38 PM, Matthew Wringe
>     <mwringe at redhat.com <mailto: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.
>

I would also suggest we go with this architecture.  I don't actually see 
the cons as very bad at all.  Because of the tight-coupling of S-P it is 
not particularly worthwhile to have one up and one down. I think in 
general the S and P containers should be considered a single instance of 
hawkular server.  But running them as separate containers still makes 
sense for the reasons listed as cons in the all-in-one option.

>
>
>         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 <mailto:hawkular-dev at lists.jboss.org>
>         https://lists.jboss.org/mailman/listinfo/hawkular-dev
>         <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/20171130/b60e9e2a/attachment-0001.html