Matt,
I have not been intimately involved with hawkular dev due to other obligations. I'm
curious about your use case, running metrics as an independent app... as I always thought
metrics, inventory, alert, etc are to meant to be assembled together.
Ah, sorry I forgot to respond to this last week.
All that we need in OpenShift for now is just the Hawkular Metrics part,
we don't need the other components (at least not yet). There is also the
problem where the other components are not setup to be run in a cluster yet.
In terms of how things are meant to be run in the future, I am not sure
if we would have a single application running all of Hawkular, or have
it more modular with multiple pods running different components.
I would be happy to assist with the Dockerhub build steps. Let's have a chat early
next week?
Basically I just need whomever is in control of the CI build process and
in charge of the Hawkular docker hub account to help out with this since
I don't have access to those accounts.
Ideally we should just use the maven build setup and not the current
docker hub automated build but if the docker hub automated build setup
is easier to get things up and running then it might be good to use that
for now.
I will see if I can ping you on irc about all of this.
- Matt
Viet
----- Original Message -----
From: "Matt Wringe" <mwringe(a)redhat.com>
To: hawkular-dev(a)lists.jboss.org
Sent: Thursday, April 23, 2015 6:35:24 AM
Subject: Re: [Hawkular-dev] Hawkular Metrics Openshift Containers
On 22/04/15 10:16 AM, Matt Wringe wrote:
> On 22/04/15 09:18 AM, Matt Wringe wrote:
>> On 20/04/15 09:57 AM, Viet Nguyen wrote:
>>> Matt,
>>> I was the last person who worked on that Docker build for Hawkular-metrics.
Yes, it is obsolete and can be removed.
>>>
>>> FYI there's an automated Docker build of Kettle in DockerHub and a
continuous deployment to a Kubernetes cluster
>>>
>>> Docker Hub:
>>>
https://registry.hub.docker.com/u/hawkular/hawkular/
>>>
>>> CI Pipeline:
>>>
https://docs.google.com/presentation/d/14zqOHOvXAB4uN7W_fWOub3ZD6txiS_Vp9...
>> I went through and have the docker images being built using a docker
>> maven plugin. So during the maven build, you can create the image and
>> push it out to a registry.
>>
>> It works great on a local machine, one maven build and I have the docker
>> images and kubernetes application zip created. But looking at how the
>> current CI is done, it might not have been the best solution (it would
>> require the credentials of the docker hub user to be added into the CI
>> setup somewhere).
>>
>> It might make more sense to do it the way the current CI is setup with
>> the kettle builds. Anyone have any preferences?
> Either way, the CI build way is also easy to setup. You would just need
> to sets these up with the official accounts and add in the automated
> build hooks:
>
>
https://registry.hub.docker.com/u/mwringe/docker-hawkular-cassandra/
>
https://github.com/mwringe/docker-hawkular-cassandra
>
>
https://registry.hub.docker.com/u/mwringe/docker-hawkular-metrics/
>
https://github.com/mwringe/docker-hawkular-metrics
We really need to get this setup as part of the build so that we can
hand off the containers and kubernetes application. I can't set this up
myself as we need whomever is able to access the CI builds and docker
hub account to perform the setup.
I have proposed two different setups, and they both should work for the
CI builds: We can either build it via the maven plugin in the CI builds,
or we can use the existing docker hub automated builds (like what is
done with the kettle docker images).
The only thing about the maven build is that we need to store the user
credentials in the CI configuration somewhere and need access to a
machine capable of performing docker image builds.
Everything else in the maven build is handled much better (everything
kept in one place, versions are automatically updated, names are kept in
sync between the docker images and kubernetes applications, can easier
push out to different docker registries, much better developer
experience for local builds, etc).
The docker hub automated builds are probably faster to setup right now
though since we already know we have everything working for it.
Note: the maven docker setup is not going away, we need that for
developer builds (either locally or pushing out to developer own docker
hub account). The docker hub automated builds are essentially useless
from a developer's perspective, but they work fine for CI builds.
>>> Viet
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: "Matt Wringe" <mwringe(a)redhat.com>
>>> To: hawkular-dev(a)lists.jboss.org
>>> Sent: Friday, April 17, 2015 3:44:12 PM
>>> Subject: [Hawkular-dev] Hawkular Metrics Openshift Containers
>>>
>>> I have a new subproject in Hawkular Metrics which sets up creating
>>> components for Openshift/Fabric8
>>> (
https://github.com/hawkular/hawkular-metrics/pull/200).
>>>
>>> There are 3 main parts
>>>
>>> Cassandra: creates a custom seed provider to support
>>> ReplicationControllers in Kubernetes, creates a folder/zip archive which
>>> can be used to generate a Docker image. It may make sense to move the
>>> Cassandra parts out to a separate project.
>>>
>>> Hawkular Metrics: creates a folder/zip archive which can be used to
>>> generate a Docker image
>>>
>>> Kubernetes: pulls everything together into a single kubernetes
>>> application. Can be used to deploy an application zip into fabric8 (via
>>> drag and drop in the web console or via the maven plugin) or deploy all
>>> the components into Openshift via the kubernetes.json configuration file.
>>>
>>> The docker images are not created and deployed to a docker registry as
>>> part of the build, it will just create a folder where you can run the
>>> docker build from. None of the maven docker plugins I looked at seemed
>>> to really work properly, so its still a manual process to do the build
>>> (and push to a registry). Its something which needs to be improved.
>>>
>>> The Cassandra service currently only supports adding new nodes to a
>>> cluster and not removing them via the ReplicationController. This is due
>>> to the replication factor being set to be 1 by default (which means when
>>> a node is removed, so is the data it contained).
>>>
>>> I believe the docker subproject of hawkular metrics is obsolete and can
>>> be removed
>>> (
https://github.com/hawkular/hawkular-metrics/tree/master/docker), but
>>> someone please correct me if I am wrong. It's scripts are referring to
>>> the console which no longer exists as part of the project.
>>>
>>> - Matt
>>> _______________________________________________
>>> 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