Elasticsearch example

[JosephSalisbury]

Fixes https://github.com/giantswarm/inago/issues/192

[JosephSalisbury]

@giantswarm/cena @puja108 your thoughts, please and thank you <3

[codecov-io]

Current coverage is 61.14%

Merging #214 into master will increase coverage by +0.24% as of f77b00b

Powered by Codecov. Updated on successful CI builds.

[puja108]

Made some comments inline.

Also wanted to brush two more issues that I'm not 100% sure about:

1. We say Inago is especially fit for managing groups of unit files. However, what we're showing here is actually only slices of one single unit file, not a group. Would it be a lot of work to extend this to a complete ELK?
2. Why do we need to run elasticsearch on fleet with Inago? What do we gain compared to running it on a higher level orchestration framework like appd or k8s etc.?

[xh3b4sd]

Responding to @puja108's notes.

We say Inago is especially fit for managing groups of unit files. However, what we're showing here is actually only slices of one single unit file, not a group.

This shows that the concepts are still not clear. In fact the single unit file represents a group. It is only that this group only consists of one unit. We thought this is sufficient for an example to show what is possible with Inago.

Would it be a lot of work to extend this to a complete ELK?

IMO this examples show some functionality. When we want to have some recipes that people simply can run then we can do that. It seems to not be clear what we want to achieve here. Should the focus be on Inago or some other open source tool? This question is important to answer. As I understood it the goal of this task here was to show functionality of Inago. Showing the use of third party open source tools for my understanding is a different thing. Further such recipes are going to be massive because of the amount of components needed to setup things. We cannot simply use our internal images in all cases and need to prepare lots of things to get this working for the public.

Why do we need to run elasticsearch on fleet with Inago? What do we gain compared to running it on a higher level orchestration framework like appd or k8s etc.?

For me this is flexibility and easy. appd and k8s require additional setups and more preparation work. Then the result would be nearly the same I guess. Further you only have unit files. Plain and simple. No other fancy definition needs to be known. So Inago provides the same with less overhead. When it later comes to more sophisticated use cases like user management or locking actions when multiple people work together on something Inago is not going to be sufficient anymore with its current state. And here even appd then requires more tools around it to accomplish such things. Personally I cannot say much about k8s in this direction.

[puja108]

@xh3b4sd I do get your points and you are right with your response, if just looking at showing Inago functionality.

I think it is still not clear what we want to show with this example. If it's just functionality then this is totally fine.

My thing is that from a product perspective we need to be clear about what Inago will be for and what it won't be for. From my point of view Inago won't be a developer-facing tool, but rather a ops-facing one, something that helps ops deploy infrastructure (modules). That is why I kind of want external people who look at this repo to know why we chose this example.

To be clear, I'm ok with having this example as is, but I'd like to get some more opinions on the general goal that we're after with this. @teemow @zeisss?

[xh3b4sd]

I think it is still not clear what we want to show with this example.

+1

From my point of view Inago won't be a developer-facing tool

To be honest. When I think about having some application I develop I would consider Inago to deploy my stuff. It is easy and it works quite well. The only pain is hustling with plain unit files. So some configuration management is missing. What I personally would like to prevent when wanting to get something done is certain amount of required knowledge. For appd and k8s I need to know how to setup and how to use and how it fits my stuff. Both tools are living in there own universe where devil hides in the dirty details. I really don't care about such things when I want to deploy my application. The same applies to Inago but the Inago universe is way more straight forward. But again, when it comes to monitoring, logging, user-management, etc. Inago is not a good fit. It is only that I certainly don't care about these things when being a single developer only wanting to orchestrate his application.

[JosephSalisbury]

yo @puja108 / @xh3b4sd - mind having another look? i think i've addressed all the points you raised

[xh3b4sd]

Lets simply go with this. LGTM