12:38 a.m.
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
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.
6:17 a.m.
I seem to remember at some point in a meeting recently John Doyle saying
that we had a large number of JON customers with small implementations and
a few customers with really large JON implementations. So I'm wondering,
would it make sense to have more than one option since once size probably
won't fit all?
Smaller implementation (monitoring handful of servers) - ALL-IN-ONE
POD - Hawkular
Services and Prometheus are in their own containers, but they are both
deployed within the same pod. For ease of use and upgrade for customers
with a smaller monitoring footprint.
Large implementation (monitoring thousands of servers) - SEPARATE PODS
- Hawkular
Services and Prometheus have their own separate pods. To allow larger
customers to scale up the n:m ratio between Hawkular Services and
Prometheus to meet their needs, and upgrade the components separately as
needed.
JULIE STICKLER
TECHNICAL WRITER
Red Hat
<https://www.redhat.com/>
Westford – 3S353
jstickle(a)redhat.com T: 1(978)-399-0463-(812-0463) IRC: jstickler
On Mon, Nov 27, 2017 at 10:38 AM, 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
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
3:35 a.m.
Right now the plan is to have 1 Hawkular Services for 1 Prometheus, so if
you need to scale up you will need to deploy another instance of these two
components.
We could in the future move to supporting an m:n ratio for Hawkular
Services and Prometheus, but this can get a bit tricky to handle and is not
something we are seriously considering at the moment.
I would really rather not have one type of setup for small deployments and
another setup for larger deployments. Its going to add in extra work to
make sure both setups perform properly, and to figure out how to migrate
from one setup to another (eg someone starts out small and grows, so they
now need to move to the large setup).
On Mon, Nov 27, 2017 at 4:17 PM, Julie Stickler <jstickle(a)redhat.com> wrote:
I seem to remember at some point in a meeting recently John Doyle
saying
that we had a large number of JON customers with small implementations and
a few customers with really large JON implementations. So I'm wondering,
would it make sense to have more than one option since once size probably
won't fit all?
Smaller implementation (monitoring handful of servers) - ALL-IN-ONE POD - Hawkular
Services and Prometheus are in their own containers, but they are both
deployed within the same pod. For ease of use and upgrade for customers
with a smaller monitoring footprint.
Large implementation (monitoring thousands of servers) - SEPARATE PODS - Hawkular
Services and Prometheus have their own separate pods. To allow larger
customers to scale up the n:m ratio between Hawkular Services and
Prometheus to meet their needs, and upgrade the components separately as
needed.
JULIE STICKLER
TECHNICAL WRITER
Red Hat
<https://www.redhat.com/>
Westford – 3S353
jstickle(a)redhat.com T: 1(978)-399-0463-(812-0463) IRC: jstickler
On Mon, Nov 27, 2017 at 10:38 AM, 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
>
>
> 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
6:55 p.m.
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.
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
7:15 p.m.
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
>
>
10:49 p.m.
On 11/30/2017 5:15 AM, Lucas Ponce wrote:
On Thu, Nov 30, 2017 at 10:55 AM, Lucas Ponce <lponce(a)redhat.com
<mailto:lponce@redhat.com>> wrote:
On Mon, Nov 27, 2017 at 4:38 PM, Matthew Wringe
<mwringe(a)redhat.com <mailto:mwringe@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(a)lists.jboss.org <mailto:hawkular-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
10:56 p.m.
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
7:35 p.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
5:11 a.m.
Going with the all-in-one pod approach, there is also the question of how
many volumes we want to use.
We can have everything in one volume with multiple directories (eg /p8s,
/hawkular-inventory, etc). This would make it easier to install as we only
have to have one directory to deal with.
Of we could have multiple volumes, one for Hawkular Services and one for
Prometheus. This might give us some more flexibility in the future, but I
can't see why we would need this extra complexity at the moment.
Any thoughts on this? Or maybe some perspective I am missing?
On Mon, Dec 4, 2017 at 5:35 AM, Thomas Heute <theute(a)redhat.com> wrote:
+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
>
>
_______________________________________________
hawkular-dev mailing list
hawkular-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hawkular-dev
6:09 a.m.
If we use a single shared volume, I'd be a little worried about Prometheus
data filling up all the space and causing problems in the hawkular-services
container. We've seen some runaway Prometheus storage issues in open shift.
On Dec 5, 2017 2:13 PM, "Matthew Wringe" <mwringe(a)redhat.com> wrote:
Going with the all-in-one pod approach, there is also the question of how
many volumes we want to use.
We can have everything in one volume with multiple directories (eg /p8s,
/hawkular-inventory, etc). This would make it easier to install as we only
have to have one directory to deal with.
Of we could have multiple volumes, one for Hawkular Services and one for
Prometheus. This might give us some more flexibility in the future, but I
can't see why we would need this extra complexity at the moment.
Any thoughts on this? Or maybe some perspective I am missing?
On Mon, Dec 4, 2017 at 5:35 AM, Thomas Heute <theute(a)redhat.com> wrote:
+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
>
>
_______________________________________________
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
6:27 a.m.
On Tue, Dec 5, 2017 at 4:09 PM, Paul Gier <pgier(a)redhat.com> wrote:
If we use a single shared volume, I'd be a little worried about
Prometheus
data filling up all the space and causing problems in the hawkular-services
container. We've seen some runaway Prometheus storage issues in open shift.
One component eating all the space of the other is something we might want
to be worried about.
Prometheus considers its metrics storage to not be durable and that is our
stance with Hawkular Services as well.
The only thing we can really do is to give recommendations to users for how
much storage they should need. Since we are tightly coupling Hawkular
Services with Prometheus, it might be easier to just keep them together and
give the recommendation for both running.
On Dec 5, 2017 2:13 PM, "Matthew Wringe" <mwringe(a)redhat.com> wrote:
Going with the all-in-one pod approach, there is also the question of how
many volumes we want to use.
We can have everything in one volume with multiple directories (eg /p8s,
/hawkular-inventory, etc). This would make it easier to install as we only
have to have one directory to deal with.
Of we could have multiple volumes, one for Hawkular Services and one for
Prometheus. This might give us some more flexibility in the future, but I
can't see why we would need this extra complexity at the moment.
Any thoughts on this? Or maybe some perspective I am missing?
On Mon, Dec 4, 2017 at 5:35 AM, Thomas Heute <theute(a)redhat.com> wrote:
> +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
>>
>>
>
> _______________________________________________
> 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
7:57 a.m.
For now, at this point in time, I vote for simplicity above things like scalability
issues. Let's make it simple and easy for people to try this stuff out. Worry about
Prometheus filling up a volume when we actually have people using this at a scale where
that actually will be a real problem.
$0.02 deposited.
----- Original Message -----
On Tue, Dec 5, 2017 at 4:09 PM, Paul Gier < pgier(a)redhat.com >
wrote:
If we use a single shared volume, I'd be a little worried about Prometheus
data filling up all the space and causing problems in the hawkular-services
container. We've seen some runaway Prometheus storage issues in open shift.
One component eating all the space of the other is something we might want to
be worried about.
Prometheus considers its metrics storage to not be durable and that is our
stance with Hawkular Services as well.
The only thing we can really do is to give recommendations to users for how
much storage they should need. Since we are tightly coupling Hawkular
Services with Prometheus, it might be easier to just keep them together and
give the recommendation for both running.
On Dec 5, 2017 2:13 PM, "Matthew Wringe" < mwringe(a)redhat.com > wrote:
Going with the all-in-one pod approach, there is also the question of how
many volumes we want to use.
We can have everything in one volume with multiple directories (eg /p8s,
/hawkular-inventory, etc). This would make it easier to install as we only
have to have one directory to deal with.
Of we could have multiple volumes, one for Hawkular Services and one for
Prometheus. This might give us some more flexibility in the future, but I
can't see why we would need this extra complexity at the moment.
Any thoughts on this? Or maybe some perspective I am missing?
On Mon, Dec 4, 2017 at 5:35 AM, Thomas Heute < theute(a)redhat.com > wrote:
+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.
5:17 a.m.
Hi all,
TL;DR: Technically it's ALL-IN-ONE POD but make HawkularService an option aka
"sidecar" container
Would our team also look at providing Prometheus (without HS) as the defacto choice for
OpenShift?
What I'm proposing is still technically an ALL-IN-ONE pod option. However, instead of
looking at (Prometheus + HS) as a monolithic solution we can position HS as an enhancement
to the plain vanilla Prometheus. This add-on sidecar[1] approach can satisfy both
Middleware users and non-middleware community users who may not necessarily need
HawkularServices. Let's say I want to use library X and X only comes with X+Y (which
will cost me CPU and RAM resources) I may be less inclined to use the library.
[1] more on "sidecar" containers
http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns...
Viet
----- Original Message -----
From: "Matthew Wringe" <mwringe(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Monday, November 27, 2017 7:38:50 AM
Subject: [Hawkular-dev] OpenShift Deployment
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
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
11:09 p.m.
On Wed, Dec 6, 2017 at 3:17 PM, Viet Nguyen <vnguyen(a)redhat.com> wrote:
Hi all,
TL;DR: Technically it's ALL-IN-ONE POD but make HawkularService an option
aka "sidecar" container
I believe the 'sidecar' container concept is more used for when you have a
main container and then a small container to add in some functionality (eg
auth proxy, metric agent, etc)
In our case it would just be a pod with two containers which are tightly
coupled.
Would our team also look at providing Prometheus (without HS) as the
defacto choice for OpenShift?
For Hawkular Services, we will have our own Prometheus which is private to
our needs. Someone will not be able to use our pod and optionally only use
Prometheus from it.
What I'm proposing is still technically an ALL-IN-ONE pod option. However,
instead of looking at (Prometheus + HS) as a monolithic solution we can
position HS as an enhancement to the plain vanilla Prometheus. This add-on
sidecar[1] approach can satisfy both Middleware users and non-middleware
community users who may not necessarily need HawkularServices. Let's say I
want to use library X and X only comes with X+Y (which will cost me CPU and
RAM resources) I may be less inclined to use the library.
We are not entertaining this idea and conceptually its closer to having
Hawkular Services as the main container and p8s as the side car container.
If someone wants middleware monitoring, they have to use our pod with
Hawkular Services and p8s. Its important that we control how our own p8s
instance works and to prevent someone from modifying it to their own
purposes (it would be too difficult to handle all the different scenarios
here).
If someone wants p8s for something other than middleware monitoring, then
they will have to use a different p8s pod.
[1] more on "sidecar" containers
http://blog.kubernetes.io/2015/06/the-distributed-
system-toolkit-patterns.html
Viet
----- Original Message -----
From: "Matthew Wringe" <mwringe(a)redhat.com>
To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org>
Sent: Monday, November 27, 2017 7:38:50 AM
Subject: [Hawkular-dev] OpenShift Deployment
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
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
3:38 a.m.
Clarification: I'm not suggesting an Assemble-Your-Own solution whereby the users
independently install Prometheus then Hawkular Services.
Rather what I'm proposing is somewhat analogous to Fedora model. We want to be the
community leader in Prometheus on OpenShift and on top of that our expertise in Middleware
monitoring brings values to Middleware users by providing our Prometheus++ solution (core
Prometheus + Middleware monitoring enhancement).
If someone wants p8s for something other than middleware
monitoring, then they will have to use a different p8s pod.
Let me flip that inside out if I may. If someone wants to contribute to P8S other than
Middleware monitoring, then they will have to go to a different project. With that I feel
we may be missing a huge opportunity here. A large community of P8s users will go
elsewhere to contribute. We'll be on our own island.
I'm bringing up the sidecar approach because naturally it imposes loose-coupling
between P8s and HS even when the two are in the same pod.
Viet
----- Original Message -----
From: "Matthew Wringe" <mwringe(a)redhat.com>
To: "Discussions around Hawkular development"
<hawkular-dev(a)lists.jboss.org>
Sent: Thursday, December 7, 2017 6:09:34 AM
Subject: Re: [Hawkular-dev] OpenShift Deployment
On Wed, Dec 6, 2017 at 3:17 PM, Viet Nguyen < vnguyen(a)redhat.com > wrote:
Hi all,
TL;DR: Technically it's ALL-IN-ONE POD but make HawkularService an
option aka "sidecar" container
I believe the 'sidecar' container concept is more used for when you have a main
container and then a small container to add in some functionality (eg auth proxy, metric
agent, etc)
In our case it would just be a pod with two containers which are tightly coupled.
Would our team also look at providing Prometheus (without HS) as
the defacto choice for OpenShift?
For Hawkular Services, we will have our own Prometheus which is private to our needs.
Someone will not be able to use our pod and optionally only use Prometheus from it.
What I'm proposing is still technically an ALL-IN-ONE pod option.
However, instead of looking at (Prometheus + HS) as a monolithic
solution we can position HS as an enhancement to the plain vanilla
Prometheus. This add-on sidecar[1] approach can satisfy both
Middleware users and non-middleware community users who may not
necessarily need HawkularServices. Let's say I want to use library >X and X only
comes with X+Y (which will cost me CPU and RAM
resources) I may be less inclined to use the library.
We are not entertaining this idea and conceptually its closer to having Hawkular Services
as the main container and p8s as the side car container.
If someone wants middleware monitoring, they have to use our pod with Hawkular Services
and p8s. Its important that we control how our own p8s instance works and to prevent
someone from modifying it to their own purposes (it would be too difficult to handle all
the different scenarios here).
If someone wants p8s for something other than middleware monitoring, then they will have
to use a different p8s pod.
[1] more on "sidecar" containers
http://blog.kubernetes.io/2015/06/the-distributed-system-toolkit-patterns...
Viet
----- Original Message -----
From: "Matthew Wringe" < mwringe(a)redhat.com >
To: "Discussions around Hawkular development" < hawkular-dev(a)lists.jboss.org
>
Sent: Monday, November 27, 2017 7:38:50 AM
Subject: [Hawkular-dev] OpenShift Deployment
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
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.
5:54 a.m.
On Fri, Dec 8, 2017 at 1:38 PM, Viet Nguyen <vnguyen(a)redhat.com> wrote:
Clarification: I'm not suggesting an Assemble-Your-Own solution
whereby
the users independently install Prometheus then Hawkular Services.
Rather what I'm proposing is somewhat analogous to Fedora model. We want
to be the community leader in Prometheus on OpenShift
No we don't. This is not the goal of Hawkular Services and has never been
our goal.
Hawkular Services is about being able to monitor and manage middleware
servers. Thats our purpose.
We are a consumer of Prometheus and using it as our metrics solution. In
the past this was done using Hawkular Metrics. And in the future we might
switch to some other metrics solution.
We are currently using Prometheus as a tool. That is it.
There are other teams working on the Prometheus experience in OpenShift,
and we will be working with them. We will be reusing as much as possible
their containers, scripts and configurations. Its these teams whose goal is
the community leadership of running Prometheus on OpenShift, not us.
and on top of that our expertise in Middleware monitoring brings
values to
Middleware users by providing our Prometheus++ solution (core Prometheus +
Middleware monitoring enhancement).
>If someone wants p8s for something other than middleware
>monitoring, then they will have to use a different p8s pod.
Let me flip that inside out if I may. If someone wants to contribute to
P8S other than Middleware monitoring, then they will have to go to a
different project.
Yes of course, they will go to the OpenShift team working directly with
Prometheus. Just as we are.
With that I feel we may be missing a huge opportunity here. A large
community of P8s users will go elsewhere to contribute. We'll be on our
own island.
I'm bringing up the sidecar approach because naturally it imposes
loose-coupling between P8s and HS even when the two are in the same pod.
Viet
----- Original Message -----
From: "Matthew Wringe" <mwringe(a)redhat.com>
To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org>
Sent: Thursday, December 7, 2017 6:09:34 AM
Subject: Re: [Hawkular-dev] OpenShift Deployment
On Wed, Dec 6, 2017 at 3:17 PM, Viet Nguyen < vnguyen(a)redhat.com > wrote:
>Hi all,
>TL;DR: Technically it's ALL-IN-ONE POD but make HawkularService an option
aka "sidecar" container
I believe the 'sidecar' container concept is more used for when you have a
main container and then a small container to add in some functionality (eg
auth proxy, metric agent, etc)
In our case it would just be a pod with two containers which are tightly
coupled.
>Would our team also look at providing Prometheus (without HS) as
>the defacto choice for OpenShift?
For Hawkular Services, we will have our own Prometheus which is private to
our needs. Someone will not be able to use our pod and optionally only use
Prometheus from it.
>What I'm proposing is still technically an ALL-IN-ONE pod option.
> However, instead of looking at (Prometheus + HS) as a monolithic
>solution we can position HS as an enhancement to the plain vanilla
>Prometheus. This add-on sidecar[1] approach can satisfy both
>Middleware users and non-middleware community users who may not
>necessarily need HawkularServices. Let's say I want to use library >X and
X only comes with X+Y (which will cost me CPU and RAM
>resources) I may be less inclined to use the library.
We are not entertaining this idea and conceptually its closer to having
Hawkular Services as the main container and p8s as the side car container.
If someone wants middleware monitoring, they have to use our pod with
Hawkular Services and p8s. Its important that we control how our own p8s
instance works and to prevent someone from modifying it to their own
purposes (it would be too difficult to handle all the different scenarios
here).
If someone wants p8s for something other than middleware monitoring, then
they will have to use a different p8s pod.
[1] more on "sidecar" containers
http://blog.kubernetes.io/2015/06/the-distributed-
system-toolkit-patterns.html
Viet
----- Original Message -----
From: "Matthew Wringe" < mwringe(a)redhat.com >
To: "Discussions around Hawkular development" <
hawkular-dev(a)lists.jboss.org >
Sent: Monday, November 27, 2017 7:38:50 AM
Subject: [Hawkular-dev] OpenShift Deployment
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
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
3:54 p.m.
I see a lot of confusion on that thread.
Prometheus is a quite an internal detail for Hawkular Services/CloudForms
We happen to also have a team working on Prometheus directly working with
various consumers such as OpenShift and Fuse.
On Fri, Dec 8, 2017 at 9:54 PM, Matthew Wringe <mwringe(a)redhat.com> wrote:
On Fri, Dec 8, 2017 at 1:38 PM, Viet Nguyen
<vnguyen(a)redhat.com> wrote:
> Clarification: I'm not suggesting an Assemble-Your-Own solution whereby
> the users independently install Prometheus then Hawkular Services.
>
> Rather what I'm proposing is somewhat analogous to Fedora model. We want
> to be the community leader in Prometheus on OpenShift
No we don't. This is not the goal of Hawkular Services and has never been
our goal.
Hawkular Services is about being able to monitor and manage middleware
servers. Thats our purpose.
We are a consumer of Prometheus and using it as our metrics solution. In
the past this was done using Hawkular Metrics. And in the future we might
switch to some other metrics solution.
We are currently using Prometheus as a tool. That is it.
There are other teams working on the Prometheus experience in OpenShift,
and we will be working with them. We will be reusing as much as possible
their containers, scripts and configurations. Its these teams whose goal is
the community leadership of running Prometheus on OpenShift, not us.
> and on top of that our expertise in Middleware monitoring brings values
> to Middleware users by providing our Prometheus++ solution (core Prometheus
> + Middleware monitoring enhancement).
>
> >If someone wants p8s for something other than middleware
> >monitoring, then they will have to use a different p8s pod.
>
> Let me flip that inside out if I may. If someone wants to contribute to
> P8S other than Middleware monitoring, then they will have to go to a
> different project.
Yes of course, they will go to the OpenShift team working directly with
Prometheus. Just as we are.
> With that I feel we may be missing a huge opportunity here. A large
> community of P8s users will go elsewhere to contribute. We'll be on our
> own island.
>
> I'm bringing up the sidecar approach because naturally it imposes
> loose-coupling between P8s and HS even when the two are in the same pod.
>
>
> Viet
>
>
>
> ----- Original Message -----
> From: "Matthew Wringe" <mwringe(a)redhat.com>
> To: "Discussions around Hawkular development" <
> hawkular-dev(a)lists.jboss.org>
> Sent: Thursday, December 7, 2017 6:09:34 AM
> Subject: Re: [Hawkular-dev] OpenShift Deployment
>
> On Wed, Dec 6, 2017 at 3:17 PM, Viet Nguyen < vnguyen(a)redhat.com > wrote:
>
>
> >Hi all,
>
> >TL;DR: Technically it's ALL-IN-ONE POD but make HawkularService an
> option aka "sidecar" container
>
> I believe the 'sidecar' container concept is more used for when you have
> a main container and then a small container to add in some functionality
> (eg auth proxy, metric agent, etc)
>
> In our case it would just be a pod with two containers which are tightly
> coupled.
>
>
>
> >Would our team also look at providing Prometheus (without HS) as
> >the defacto choice for OpenShift?
>
> For Hawkular Services, we will have our own Prometheus which is private
> to our needs. Someone will not be able to use our pod and optionally only
> use Prometheus from it.
>
>
>
> >What I'm proposing is still technically an ALL-IN-ONE pod option.
> > However, instead of looking at (Prometheus + HS) as a monolithic
> >solution we can position HS as an enhancement to the plain vanilla
> >Prometheus. This add-on sidecar[1] approach can satisfy both
> >Middleware users and non-middleware community users who may not
> >necessarily need HawkularServices. Let's say I want to use library >X
> and X only comes with X+Y (which will cost me CPU and RAM
> >resources) I may be less inclined to use the library.
>
> We are not entertaining this idea and conceptually its closer to having
> Hawkular Services as the main container and p8s as the side car container.
>
> If someone wants middleware monitoring, they have to use our pod with
> Hawkular Services and p8s. Its important that we control how our own p8s
> instance works and to prevent someone from modifying it to their own
> purposes (it would be too difficult to handle all the different scenarios
> here).
>
> If someone wants p8s for something other than middleware monitoring, then
> they will have to use a different p8s pod.
>
>
>
> [1] more on "sidecar" containers
> http://blog.kubernetes.io/2015/06/the-distributed-system-
> toolkit-patterns.html
>
>
> Viet
>
>
>
>
> ----- Original Message -----
> From: "Matthew Wringe" < mwringe(a)redhat.com >
> To: "Discussions around Hawkular development" <
> hawkular-dev(a)lists.jboss.org >
> Sent: Monday, November 27, 2017 7:38:50 AM
> Subject: [Hawkular-dev] OpenShift Deployment
>
> 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
>
>
> 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
2339
days inactive
2354
days old
16 comments
8 participants
participants (8)
-
Jay Shaughnessy -
John Mazzitelli -
Julie Stickler -
Lucas Ponce -
Matthew Wringe -
Paul Gier -
Thomas Heute -
Viet Nguyen