Nice explanation Tom.
In addition to that, we will be able to run these containers in multiple
pods within
a kubernetes cluster when being used for an actual use case (production).
This way, it will be easy to deploy, scale and manage.
Under those conditions, we may be able to run one component
Ahh, good to hear. Please fix…why would this break though since it worked
before?
From: Tom Barber
Reply-To: "dev@oodt.apache.org"
Date: Monday, October 15, 2018 at 4:40 PM
To: "dev@oodt.apache.org" , Chris Mattmann
Subject: Re: [jira] [Created] (OODT-997) JAXRS endpoints broken
Hi folks,
I’m mocking and stubbing out ideas for a React based OPSUI.
Its not designed to reinvent the wheel, but modernise, allow easier
theming/branding, be modular for people wanting to embed specific
components into apps and so on.
I have plans in my head for a couple of extra screens for
Hmm its a ClassNotFound exception.
If I update CXF to the latest 3.2.6 it works without any changes to my
deployment.
On 15 October 2018 at 23:13:34, Chris Mattmann (mattm...@apache.org) wrote:
You’re missing an env var, see here:
https://github.com/apache/drat/wiki/Installation#bash
You’re missing an env var, see here:
https://github.com/apache/drat/wiki/Installation#bash
FMPROD*
Cheers,
Chris
From: "Tom Barber (JIRA)"
Reply-To: "dev@oodt.apache.org"
Date: Monday, October 15, 2018 at 3:12 PM
To: "dev@oodt.apache.org"
Subject: [jira] [Created] (OODT-997)
Tom Barber created OODT-997:
---
Summary: JAXRS endpoints broken
Key: OODT-997
URL: https://issues.apache.org/jira/browse/OODT-997
Project: OODT
Issue Type: Bug
Reporter: Tom Barber
internally as they only 1 process they should run with very little
overhead.
I can vouch also though that IO certainly sucks really really badly on my
Mac compared to linux box, and if SK reads this I'm sure he can also relay
some docker horror stories on Mac.
On Mac it's better since they got
Interesting OK. B/c the more containers for me on my local laptop
typically eat up way more memory and CPU…but maybe that’s just
me on a Mac lol
From: Tom Barber
Reply-To: "dev@oodt.apache.org"
Date: Monday, October 15, 2018 at 9:44 AM
To: Imesha Sudasingha , Chris Mattmann
Cc:
Also don’t forget, Docker containers, don’t ship Kernel’s etc and all the
system stuff, which is what keeps them lightweight.
On 15 October 2018 at 17:43:37, Tom Barber (t...@spicule.co.uk) wrote:
Not at all and if you want to run OODT on Kubernetes for example, that
would be how you’d do it,
Not at all and if you want to run OODT on Kubernetes for example, that
would be how you’d do it, that way you can upgrade, scale, restart and fail
components without the entire stack falling over.
In terms of disk space, don’t forget each image is built on layers, so for
example, openjdk-8 on
Isn’t an image per component really heavyweight?
From: Tom Barber
Date: Monday, October 15, 2018 at 8:26 AM
To: Imesha Sudasingha
Cc: dev , Chris Mattmann
Subject: Re: OODT docker builds
Why aren’t we doing so?! :)
Lack of cycles and young kids ;)
I’ll take a stab at it
Why aren’t we doing so?! :)
Lack of cycles and young kids ;)
I’ll take a stab at it and see where we get to outside of RADIX to get the
stack in distinct containers and then we’ll look at integrating it into the
main build then.
Tom
On 15 October 2018 at 13:07:56, Imesha Sudasingha
Yes. Agree with you. That is something I have been planning to ask you for
long; why aren't we doing so.
I like the idea of having a docker image per component and as you suggested
we can create docker-compose
or kubernetes setup for deployments. I like that direction ;-)
As an starting point, we
I was thinking about the outputs. Currently everything is 1 docker file
which is fine for some deployments and not for others.
In the RADIX build we should also build individual containers for each
component. For the deployment we could also have a docker-compose file and
a K8S Helm setup so that
14 matches
Mail list logo
