Samples are not easy to consume due to usage of parent in pom

[wtrocki]

The idea of the samples should be that I should be able to grab folders outside repo and they should work. From a maintenance standpoint and verification that might be bad as repo possibly needs to depend on the compiled examples etc. but from the usage point of view there is some extra work need to get this working outside the repository.

This would be something that simple CLI/Maven Artifacts could fix. Happy to build CLI for java operator if needed and add some capability to generate operator.

[s-soroosh]

Thank you @wtrocki for bringing this topic up, indeed using the samples should be simpler than what it is. I agree with building an initiator to setup the project. It could be used to address #28 and the current issue. I would suggest we make a new repo for it rather than a new module here to ensure it's developed in an isolated environment and its releases not being dependent on the SDK releases.

What do you think @adam-sandor @csviri @metacosm?

[metacosm]

I'd argue that the samples should maybe be in a different repository. A generator to generate a skeleton operator would also help.

[adam-sandor]

Separate repos for each sample or single samples repo? I'd vote for single samples repo, so when the framework changes we can upgrade the samples with one PR.

[csviri]

The original idea was, when we started to extract the samples, that we have just a few simple samples, that supports only the development maybe some quick checking / testing, that sample works with the update. And other samples (which are more complex) should be extracted to a separate repo, I would say it's own. And there should be not too much of them.

[adam-sandor]

I think single repo for all (non-test) samples would be better. Easier to browse all the samples and easier to upgrade them on FW change.

[csviri]

That is true that is easier to upgrade them. So maybe the examples which are kind of showcases we should have in one repo. Question is what about the memcached, if the intention is to have it as a production ready operator, that should be a separate repo. Not sure if that is the intention.

[adam-sandor]

I don't think memcached will be a production ready operator and it should actually go into the repo in the operator-sdk with the other memcached samples.

[csviri]

@adam-sandor you mean a separate repo with the samples, or directly to the SDK?

[adam-sandor]

here https://github.com/operator-framework/operator-sdk-samples

[csviri]

Ok, now I'm completely lost how you mean this, let's discuss it maybe on next weekly.

[wtrocki]

Is weekly open for community. Would love to join as listener?

[s-soroosh]

+1 for a repo with samples and deprecate the tomcat-operator.

[adam-sandor]

@wtrocki please jump in our Discord channel (https://discord.gg/DacEhAy) you can find the invite as a pinned message in the general channel. You are very welcome to join the weeklys.

[adam-sandor]

This is my proposal:

.h4 java-operator-sdk/operator-framework/samples

• basic sample with all features used in some contrived way

.h4 java-operator-sdk/samples

• spring-boot
• quarkus
• mysql-schema (demonstrating managing external resources)
• tomat (demonstrating multiple controllers and Kubernetes resource management)
• webserver (competition to Tomcat, we should choose if we use this or the Tomcat sample)

.h4 operator-framework/operator-sdk-samples

• java-memcached

[metacosm]

@charlottemach you mentioned you were interested in taking this on during the last weekly call, is it still the case?