Suggestions #34
offspringer
started this conversation in
Ideas
Replies: 1 comment
-
|
@offspringer I ran into the same issues myself so I created a new chart that includes standard features as well as consolidates community and enterprise editions. All of the problems you listed are addressed in the new chart (PR #35). Check out the chart README for more info on new features. If you're interested, give the release candidate a try. helm repo add hoppscotch https://jonathanfoster.github.io/hoppscotch-helm-charts/
helm install hoppscotch hoppscotch/hoppscotch --version=0.1.0-rc.1 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
First and foremost, congratulations on the product you've developed. As a software engineer, I understand how complex it can be to deliver a robust solution, especially when the proposed solution is used by other developers. I've been following Hoppscotch for some time and couldn't help but notice the evolution, particularly with the release of this HELM chart, which facilitates on-premises delivery.
However, when I tried to install it experimentally in a controlled environment, I encountered numerous difficulties. I'd like to share them with you in the best of intentions, promoting a technical debate about new features.
At the chart parameterization level, more options should be considered (a good example is the ingress-controller chart, which is rich in possibilities). Here are some examples of the problems I had:
a. Consider using an existing service account, as I may not necessarily want or be able to create a new one;
b. Parameterize Docker secrets;
c. Parameterize securityContext for all containers (it's possible that companies may want to restrict options in this tag for security reasons, such as runAsUser, runAsNonRoot, allowPrivilegeEscalation, or readonlyRootFilesystem);
d. As I couldn't run the container, I'n not sure if write permission is required, but if it is, it would be interesting to include parameterized volume mounts to support securityContext;
e. Secret creation should not fail just because I didn't define properties for some third-party authentication methods that I may not use;
f. Ingress name could also be parameterized for better identification.
As for the migrations, they were a deal-breaker for me, at least for now. Perhaps due to my lack of knowledge about Prisma, but the current mechanism doesn't seem to anticipate some scenarios:
a. offline mode: it could be possible to run migrations even without internet access;
b. Proxy: it could be possible to specify a proxy (normally, corporate environments are limited in this regard);
c. Customization of NPM registry: for the same reason as the previous item, many environments opt for customized repository solutions.
In conclusion, thank you very much! I wish the project all the best and look forward to seeing it evolve.
Beta Was this translation helpful? Give feedback.
All reactions