Improve 3rd party dependant Kamelets

[squakez]

Not sure why, but we have a few Kamelets depending on third party API which are unreliable and IMO, should not slip into any official distribution. For example, Beer-source, Chuck Norris, etc... Although they are fun for demoes (I personally created the beer-source , but I did not upload it to the official catalog), I don't think they should be officially available in any Apache distribution. I'd suggest to review more in general as I can see also maybe Bitcoin may be using some service we do not control and may be confused as production ready by the final users (see apache/camel-k#5528). If we want to keep them, I'd suggest to put into a different folder in order to clarify the "non-productive" intent.

[oscerd]

We cannot move them in a different folder, because otherwise they won't appear in the documentation and this will require some hacks on the maven plugin. What we can do is labeling them with a different level of support.

[davsclaus]

This is the wrong way to look at this.

The kamelet you point to is using a timer to call a http endpoint. That can always fail, and the way to look at this is to consider if the kamelet can be improved instead.

In this case the kamelet is using a timer, which is too basic. If you change it to use scheduler instead then this component has built-in support for not reporting READY until the first success message on startup.

[oscerd]

Updated title.

[squakez]

I think that, for security reason as well we should not rely on providers we don't know. My point, more than on the failure itself, is that we don't know at any given point in time in the future the kind of content that those API will distribute. And certainly we cannot stay there to monitor. IMO, for security, we'd better remove them from the catalog at all and we can leave to a folder that is not published neither documented.

[oscerd]

We should blacklist also http kamelets, because we don't know what endpoint we are going to invoke... Those Kamelets are just for development purpose, if camel-k is using the catalog, camel-k could filter what the project wants to include and what not. It's part of the ecosystem, but it's a consumer.

[squakez]

No, I'm not complaining about them to be part of Camel K, but to be in the same bucket of "official" components. What I wanted to raise is that the following sentence "Those Kamelets are just for development purpose" is something most users are (unfortunately) ignoring. I think that we must be aware of that and prevent them to misuse by mixing production-ready components with non-prod ones.