search

sonatype / nxrm3-ha-repository

Repository for YAML configuration files for Nexus Repository Manager High Availability Feature
17 stars 23 forks source link

Add the ability to run the OSS version #80

Open narek01 opened 5 months ago

narek01 commented 5 months ago

At this moment it is not possible to run OSS version of Nexus using this chart. This is described in issue #70

It can be fixed by adding .Values.secret.license.enabled to values.yaml which allows to place -Dnexus.loadAsOSS=true option instead of providing licence file (-Dnexus.licenseFile=${LICENSE_FILE}).

resolves #70

JoshuaJackson-jobvite commented 3 months ago

As there is no clear Codeowners here...tagging folks who have committed: @bobotimi @renesch-de @lisadurant this is a pr that would be very beneficial overall to users given that its been stated that the sonatype team wants to maintain 1 chart for the use cases, but not supporting the OSS version in this chart forces folks to fork, and or try and stay up to date with these changes.

Can you all review this and update if it needs adjustments to get merged for a new release?

Also a Codeowners or contributing.md would be ideal as well.

JoshuaJackson-jobvite commented 3 months ago

@bobotimi @renesch-de @lisadurant ping x2.

renesch-de commented 3 months ago

Thank you for tagging me. Unfortunately, I am not a code owner for this repository. Based on my experience, I recommend filing this suggestion via the ideas portal instead. This will ensure that it gets the proper visibility and attention from the relevant maintainers.

For reference, please include the details and link to this pull request when you submit your idea. You can submit your suggestion here: https://ideas.sonatype.com

Best regard's

JoshuaJackson-jobvite commented 3 months ago

@renesch-de you've committed to the repo, so I hope you might know who is the actual owners are. Its a bit ridiculous when there's an open pr by community contributors wanting to provide added functionality/capabilities and avoid forking behaviors that result in support requests that create more load for the sonatype support team that are challenging to diagnose/fix. Empowering the community to contribute and enhance the capabilities of what for many is a key technology should be getting encouraged (as noted by the open nature of the helm repo here).

lisadurant commented 2 months ago

Hi @JoshuaJackson-jobvite

I apologize for responding to this so late. Please know we have heard you and are actively discussing how to improve our coordination with the community.

Unfortunately, we do not currently support or plan to support using a Helm chart for OSS. After reviewing the root causes of customer support tickets, it’s very clear that using kubernetes to manage an application with an embedded database is a leading cause of corruption, outages and data loss. This is why we stopped distributing our legacy helm chart last year. If you need to use Helm to manage your deployment, we recommend using Repository Pro with an external database to avoid these issues.

I will add some improved messaging to our READMEs to prevent further confusion, and we will continue to discuss other ways we can improve this experience.

JoshuaJackson-jobvite commented 2 months ago

@lisadurant thank you for the reply on this, and the clarity you've brought to this ask/request. I can completely understand the desire/behaviors to reduce efforts on our partners in support and datastores in kubernetes is always challenging to get correct, and with varying behaviors between implementations of k8s its an impossible task to get right.

Repository pro can be an option but at ~400/month minimal charges, (12 dollars a user * 35 minimum users), and no real viable alternative other than "well go run your own azure/aws/gcp instance and run it not on k8s" for the opensource solution it will tend to drive folks towards other solutions instead of the platform play that sonatype is going for.

As we look at this, while it might not be apples to apples in many cases and I'll concede that. However when you look at things out there in a similar "artifact" source for multiple repos you have things such as.

A single platform for managing your supplychain risks etc is valuable, but to get there, you first need to get them for 1 product and solution to build up as they grow. Currently for many companies this even seemingly small monthly charge can be seen as a large expenditure and they'll look into alternatives that have yes a human capital cost that is often hidden.

So really the ask is how can we get to a point..that doing pro is a no brainer for most folks?

outside of that yep please make clear that there is 0 intention to support the OSS in any way and if the community really wants to run it in k8s, they'll need to build/manage the setup outside of any support from sonatype.