Sounds good to me. On Tue, Dec 10, 2019 at 3:47 PM Simon Weng <[email protected]> wrote:
> System process, in the form of container, can still work side by side with > the spout and bolt container, because they are in the same pod, sharing the > same Linux kernel and networking space, they’re seeing each other on > localhost. They can even share the same file system as long as they share > the same volume. > > On Tue, Dec 10, 2019 at 6:37 PM Ning Wang <[email protected]> wrote: > > > One image sounds good to me. > > > > The two ideas are interesting. Heron system processes are designed to > work > > in the same container of worker instances so is might be tricky to > > separate. That being said, there are definitely things to improve. > > > > On Tue, Dec 10, 2019 at 1:07 PM SiMing Weng <[email protected]> > wrote: > > > > > Hi, guys: > > > > > > I think it indeed makes sense to narrow down to a single base image. > > > Regarding which variant to choose, it boils down to any > > platform-dependent > > > component in Heron, I can only think of native StreamManager as far as > I > > > know. I’m sure others on the team knows better than I. > > > > > > Also, it may sounds a long shot, but I’d like to throw the idea here. > > > Currently, we containerize Heron as an all-in-one image, which is huge > > and > > > serves as something like a VM image. Ideally, we should containerize > each > > > component and make them slim, then it becomes easier to contribute > > > to/maintain/release. > > > > > > Then even more ambitiously, on k8s cluster, what if we make it possible > > to > > > deploy individual Spout/Bolt also as container inside each pod, with a > > > bunch of side-car container, such as StreamManger, etc, rather than > > > managing the individual process manually in our Executor. This k8s > native > > > approach would open a whole lot possibility, such as easier log > > aggregation > > > by existing open source tools, auto scaling/self-tuning with k8s > operator > > > pattern. I think the process-based stream processing nature of Heron > > gives > > > itself a unique advantage to be used in containerized environment, > > compared > > > to thread-based peers. > > > > > > Cheers, > > > > > > SiMing Weng > > > > > > > On Dec 10, 2019, at 2:11 PM, Josh Fischer <[email protected]> > wrote: > > > > > > > > I think we should settle on one "official" version for the community > to > > > > support. I would like to hear from other users on the list as to > > which > > > > image it is we keep supporting moving forward. I don't think we have > > > > enough bandwidth or resources to support 5 different versions of > Heron > > > in > > > > a container. > > > > > > > > On Tue, Dec 10, 2019 at 1:53 AM Ning Wang <[email protected]> > > wrote: > > > > > > > >> Hi, everyone, > > > >> > > > >> When I was working on this PR ( > > > >> https://github.com/apache/incubator-heron/pull/3411), Josh raised > up > > a > > > >> question about the docker images supported by Heron. There are 5 > > images > > > >> configured: centos7, debian9, ubuntu 14.04, 16.04 and 18.04. > > > >> > > > >> Questions to discuss: > > > >> - It could be a burden to maintain all of them. Do you feel it is > > > necessary > > > >> to support all of them? Or is there another one we should have? > > > >> - For ubuntu, do we really need 3 versions? > > > >> > > > >> Regards, > > > >> --ning > > > >> > > > > > > > > > -- > Sent from Gmail Mobile >
