Re: [infinispan-dev] The future of Infinispan Docker image

2017-11-07 Thread Gustavo Fernandes 
IMHO we should ship things like scripts, external modules, drivers, etc
with the server itself, leaving the least amount of logic in the Docker
image.

What you are proposing is the opposite: introducing a templating engine
that adds a level of indirection to the Docker image (the Dockerfile is
generated) plus
it grabs jars, modules, scripts, xmls, etc from potentially external
sources and does several patches to the server at Docker image creation
time.

WRT the docker hub, I think it could be used with Concreate by using hooks,
I did a quick experiment of a Dockerhub automated build having a
dynamically generating a Dockerfile in [1], but I guess
the biggest question is if the added overall complexity is worth it. I'm
leaning towards a -1, but would like to hear more opinions :)

[1] https://hub.docker.com/r/gustavonalle/dockerhub-test/

Thanks,
Gustavo

On Tue, Nov 7, 2017 at 3:14 PM, Sebastian Laskawiec 
wrote:

> Hey!
>
> Together with Ryan we are thinking about the future of Infinispan Docker
> image [1].
>
> Currently we use a single Dockerfile and a bootstrap script which is
> responsible for setting up memory limits and creating/generating (if
> necessary) credentials. Our build pipeline uses Docker HUB integration
> hooks, so whenever we push a new commit (or a tag) our images are being
> rebuilt. This is very simple to understand and very powerful setup.
>
> However we are thinking about bringing product and project images closer
> together and possibly reusing some bits (a common example might be Jolokia
> - those bits could be easily reused without touching core server
> distribution). This however requires converting our image to a framework
> called Concreate [2]. Concreate divides setup scripts into modules which
> are later on assembled into a single Dockerfile and built. Modules can also
> be pulled from other public git repository and I consider this as the most
> powerful option. It is also worth to mention, that Concreate is based on
> YAML file - here's an example of JDG image [3].
>
> As you can see, this can be quite a change so I would like to reach out
> for some opinions. The biggest issue I can see is that we will lose our
> Docker HUB build pipeline and we will need to build and push images on our
> CI (which already does this locally for Online Services).
>
> WDYT?
>
> Thanks,
> Sebastian
>
> [1] https://github.com/jboss-dockerfiles/infinispan/tree/master/server
> [2] http://concreate.readthedocs.io/en/latest/
> [3] https://github.com/jboss-container-images/jboss-
> datagrid-7-openshift-image/blob/datagrid71-dev/image.yaml
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

[infinispan-dev] The future of Infinispan Docker image

2017-11-07 Thread Sebastian Laskawiec 
Hey!

Together with Ryan we are thinking about the future of Infinispan Docker
image [1].

Currently we use a single Dockerfile and a bootstrap script which is
responsible for setting up memory limits and creating/generating (if
necessary) credentials. Our build pipeline uses Docker HUB integration
hooks, so whenever we push a new commit (or a tag) our images are being
rebuilt. This is very simple to understand and very powerful setup.

However we are thinking about bringing product and project images closer
together and possibly reusing some bits (a common example might be Jolokia
- those bits could be easily reused without touching core server
distribution). This however requires converting our image to a framework
called Concreate [2]. Concreate divides setup scripts into modules which
are later on assembled into a single Dockerfile and built. Modules can also
be pulled from other public git repository and I consider this as the most
powerful option. It is also worth to mention, that Concreate is based on
YAML file - here's an example of JDG image [3].

As you can see, this can be quite a change so I would like to reach out for
some opinions. The biggest issue I can see is that we will lose our Docker
HUB build pipeline and we will need to build and push images on our CI
(which already does this locally for Online Services).

WDYT?

Thanks,
Sebastian

[1] https://github.com/jboss-dockerfiles/infinispan/tree/master/server
[2] http://concreate.readthedocs.io/en/latest/
[3]
https://github.com/jboss-container-images/jboss-datagrid-7-openshift-image/blob/datagrid71-dev/image.yaml
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Re: [infinispan-dev] Counters and their configurations in Infinispan server (DMR)

2017-11-07 Thread Vladimir Blagojevic 
Hi everyone,

Here is most of the implementation with example use outlined in
https://github.com/infinispan/infinispan/pull/5570

Would you please review it as I am not an expert in DMR and I need one now
:-)

Regards,
Vladimir

On Fri, Nov 3, 2017 at 8:58 AM, Vladimir Blagojevic 
wrote:

> Thanks Galder and Pedro. I'll implement them as you suggested!
> Cheers
> On 2017-11-03 6:02 AM, Galder Zamarreño wrote:
>
> At first glance, I'd agree with Pedro.
>
> On 2 Nov 2017, at 16:07, Pedro Ruivo 
>  wrote:
>
> Hi,
>
> IMO, I would separate the concept of counter and configuration.
>
> Even if an user doesn't create many counters, I think most of them will
> share the same configuration. As a bad example, if you want to counter
> oranges and apples, you're going to use the same configuration...
> probably :)
>
> In addition, it is symmetric to the cache DMR tree. This would reduce
> the learning curve if the user is already used to cli (i.e create caches).
>
> Cheers,
> Pedro
>
>
>
> On 02-11-2017 12:33, Vladimir Blagojevic wrote:
>
> Hey guys,
>
> How do you anticipate users are going to deal with counters? Are they
> going to be creating a lot of them in their applications, say dozens,
> hundreds, thousands?
>
> I am asking because I have a dilemma about their representation in DMR
> and therefore in the admin console and potentially wider. The dilemma is
> related to splitting the concepts and the mapping between counter
> configuration and counter instances. On one end of the possible spectrum
> use, if users are going to have many counters that have the same
> configuration then it makes sense to delineate the DMR concept of the
> counter configuration and its counter instance just like we do for
> caches and cache configuration templates. We deal with cache
> configurations as templates; one could create hundreds of caches from
> the same template. Similarly, we can do with counters. On the other end
> if users are going to create very few counters then it likely does not
> make much sense to separate counter configurations from its instance,
> they would have one to one mapping. For each new counter, users would
> just enter counter configuration and launch an instance of a
> corresponding counter.
>
> The first approach saves resources and makes large counter
> instantiations easier while the second approach is easier to understand
> conceptually but is inefficient if we are going to have many counter
> instance.
>
> Thoughts?
>
> Vladimir
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
>
> ___
> infinispan-dev mailing 
> listinfinispan-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> ___
> infinispan-dev mailing list
> infinispan-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
___
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev