Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add the ability to run the OSS version #80

Open
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

narek01
Copy link

@narek01 narek01 commented May 5, 2024

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
Copy link

JoshuaJackson-jobvite commented Jun 11, 2024

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
Copy link

@bobotimi @renesch-de @lisadurant ping x2.

@renesch-de
Copy link
Contributor

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
Copy link

@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
Copy link
Contributor

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
Copy link

JoshuaJackson-jobvite commented Jul 10, 2024

@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.

  • Self hosted Artifactory: 4k/year ~332/month with unlimited users
  • Cloud hosted Artifactory: potentially 150/month (very limited for artifact transfer size etc)
  • Codeartifact and related cloud native solutions 0.05/gb + standard external transfer costs (varies)

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Q/A Does Sonatype Nexus Repository no more support any non pro version?
5 participants