Added basic support for plugins on nodes #71

DandyDeveloper · 2021-09-28T08:06:30Z

Description

Adds the ability to define plugins. This will enable a basic bash script on the opensearch container to install the plugins.

Unfortunately, we cannot manage this in an initContainer because the directory in question by default has plugins AND would be overwritten if we defined it as a new volume.

Issues Resolved

fixes [Enhancement][Opensearch] Support OpenSearch Prometheus Exporter #50

Check List

Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

into feature/dandydev/add-prometheus-exporter-support

DandyDeveloper · 2021-09-28T08:13:43Z

@mprimeaux Side question for this, do we want to be adding additional CI values to enable the explicit functionality that we'd want to pick up problem on?

In this case, I have it disabled by default, but ideally we want the CI picking up problems if this is enabled.

mprimeaux · 2021-09-28T11:16:02Z

@mprimeaux Side question for this, do we want to be adding additional CI values to enable the explicit functionality that we'd want to pick up problem on?

In this case, I have it disabled by default, but ideally we want the CI picking up problems if this is enabled.

@DandyDeveloper I do think it is best to reason through the set of CI values files needed to maximize the "code coverage" of the chart. Might be worth time to first define the MECE model of areas to test and then creating a values file for each.

DandyDeveloper · 2021-09-28T13:12:53Z

@mprimeaux We can define the model, or maybe simplify things into a basic list of "scenarios" and then try and build out the numerous values that encompasses all those scenarios?

Or, would is there a better way to do this?

I don't know how best to translate an MECE model into a helm chart series to "tests" (Without spending more time then should be spent making it).

mprimeaux · 2021-09-29T15:56:33Z

@DandyDeveloper I agree starting with a basic set of scenarios is a great way to start. We can then deal with next-level granularity in the spirit of iterative progression.

Perhaps starting with the top-level configurations might be a way forward. For example,

single-stack, IPv4
single-stack, IPv6
dual-stack
et al

I'll start reasoning through a "MECE'fied" model but without much thought, some categories might be:

Security (i.e. none, LDAP, OIDC, et al).
Ingress (i.e. enabled, disabled, internal ingress, external ingress)
Network Topology (i.e. single-stack, dual-stack, IPv4, IPv6, zen discovery enabled, zen discovery disabled)
Cluster Orientation (i.e. range of replica sizes)
etc

There are quite a few options with security_admin with respect to the related configuration files so we can go wild if not too careful but, in the end, it would be nice to have greater than 90% coverage of the Helm chart keeping in mind that we aren't specifically testing the upstream OpenSearch distribution but there is a natural overlap.

Perhaps we have a CI-specific values file for each scenario but that also directly relates to test duration in the actions workflow. Might be good to see if we can collapse the CI-specific values files once we understand the decompose to the breadth of tests.

Thoughts?

DandyDeveloper · 2021-09-30T01:33:07Z

@mprimeaux Lets move this to an issue and get another PR out for this.

I think I can add some basic attributes to the CI for this to run a reasonable test on my specific addition here.

mprimeaux · 2021-09-30T01:34:26Z

@DandyDeveloper Agreed.

into feature/dandydev/add-prometheus-exporter-support

DandyDeveloper · 2021-09-30T02:05:48Z

@mprimeaux @TheAlgo I need some thumbs.

FYI I got rid of comments in the ci-values because they were just unnecessarily verbose. I imagine a number of the values are also redundant.

mprimeaux · 2021-09-30T02:14:26Z

@DandyDeveloper LGTM

mprimeaux · 2021-09-30T02:15:37Z

@DandyDeveloper when we finally merge PR #75 then all changes other than chart-related will not cause linting and testing to trigger.

charts/opensearch/values.yaml

into feature/dandydev/add-prometheus-exporter-support

DandyDeveloper · 2021-10-04T01:02:33Z

@TheAlgo Think we're good for your thumbs now.

DandyDeveloper · 2021-10-04T01:03:18Z

@smlx @peterzhuamazon Need one of you to approve as well per the repo requirements.

smlx · 2021-10-04T07:57:46Z

I don't have write access, so I don't think my approval will help 🙂

TheAlgo · 2021-10-04T16:38:21Z

@TheAlgo Think we're good for your thumbs now.

Yes we are good now.

TheAlgo

One small thing. the chart version needs to be bumped right? 😄

DandyDeveloper · 2021-10-05T06:30:43Z

@TheAlgo Done

peterzhuamazon · 2021-10-05T21:47:51Z

I dont have any objections on this. Looks good to me.
However, many PRs right now all have 1.0.5 version we needs to find a way to get this work.

DandyDeveloper · 2021-10-06T01:52:27Z

@peterzhuamazon We need to be a little "faster" at getting thing in I think. Alternatively, maybe we could make a feature branch that'll get merged upstream every X period?

I.E. feature-1.5 -> people branch from this and PRs get merged upstream into that feature branch?

@smlx @mprimeaux Just floating ideas, because Peter is right, there's a lot of contributions floating. The current process only works with less frequent user contributions. Otherwise it can be overwhelming and users may forget their PRs after we've asked for another update.

mprimeaux · 2021-10-06T02:36:09Z

@DandyDeveloper I agree and why I posted a similar question here. While chart testing and releasing is appropriate, I think we should consider a branching strategy that increases the community's overall velocity.

In the referenced post, I'm trying to briefly 'take a step' back so we can 'take two steps forward', if you get my drift.

smlx · 2021-10-06T12:58:59Z

However, many PRs right now all have 1.0.5 version we needs to find a way to get this work.

I think the rate of churn will slow once the chart matures. In the meantime maintainers can bump version numbers as required when merging.

mprimeaux · 2021-10-06T13:56:48Z

@smlx @DandyDeveloper Let's compartmentalize into the two related tracks of discussion from #79 and here. I believe these are:

Track 1: Branching Strategy: I think the predominant question to answer here is do the maintainers want to introduce long-live release branches? My vote is an absolute "yes".

Track 2: Version Automation: I think Conventional Commits is a good thing. How the implementation in GitHub Actions workflow is implemented, in part, may depend on the decisions (output) of Track 1. For example, will PRs to main be treated any differently than PRs to the long-lived release branches. If the answer is simply 'no' then that's fine but we can at least reach a consensus so it's covered. The main branch would be treated simply as the next version or edge branch.

peterzhuamazon · 2021-10-06T19:17:06Z

@smlx @DandyDeveloper Let's compartmentalize into the two related tracks of discussion from #79 and here. I believe these are:

Track 1: Branching Strategy: I think the predominant question to answer here is do the maintainers want to introduce long-live release branches? My vote is an absolute "yes".

Track 2: Version Automation: I think Conventional Commits is a good thing. How the implementation in GitHub Actions workflow is implemented, in part, may depend on the decisions (output) of Track 1. For example, will PRs to main be treated any differently than PRs to the long-lived release branches. If the answer is simply 'no' then that's fine but we can at least reach a consensus so it's covered. The main branch would be treated simply as the next version or edge branch.

I would personally vote for Track1, we can create a dev branch to let people keep contributing without version issues. Then maintainer can create PRs with bumped version from dev merge to main in much slower pace.

This will not stop people use charts with most cutting edge feature, while have possibility of unstable-ness, but also enjoy stable releases over time.

Also, we just released 1.1.0 yesterday so we got to act fast.

@smlx @DandyDeveloper @TheAlgo if no objections I will merge this PR from @DandyDeveloper and create a dev branch.

Thanks.

mprimeaux · 2021-10-06T19:25:32Z

@peterzhuamazon Regarding Track 1, in essence, the main branch would be the latest "edge" or "develop" branch with the release branches being the long-lived stables ones to which the maintainers would issue PRs at a slower pace.

If you and the other maintainers decide to go this route then this would likely require us to make a few changes to the GitHub Actions workflow. But let's discuss that once the other maintainers come back to you.

Here is an example from Kubernetes. You can see the Feature PRs are issued against master / main.

peterzhuamazon · 2021-10-06T19:27:47Z

@peterzhuamazon Regarding Track 1, in essence, the main branch would be the latest "edge" or "develop" branch with the release branches being the long-lived stables ones to which the maintainers would issue PRs at a slower pace.

If you and the other maintainers decide to go this route then this would likely require us to make a few changes to the GitHub Actions workflow. But let's discuss that once the other maintainers come back to you.

Here is an example from Kubernetes. You can see the Feature PRs are issued against master / main.

I used to work in an env where main is treated as stable for a few years.
But also fine with treating main as the dev branch.

In that case we can introduce 1.0, 1.1, 1.2 branch to host all the 1.0.x, 1.1.x, 1.2.x stable versions.

mprimeaux · 2021-10-06T19:32:38Z

@peterzhuamazon

In that case we can introduce 1.0, 1.1, 1.2 branch to host all the 1.0.x, 1.1.x, 1.2.x stable versions.

FWIW, I think 1.x and 2.x is best to for the simple reason that Semantic Versioning 2.0 mandates the major version be incremented with breaking changes. This means the community can introduce new, non-breaking features and defect commits on fewer branches than if we have 1.1, 1.2, and so on.

peterzhuamazon · 2021-10-06T20:37:30Z

@peterzhuamazon

In that case we can introduce 1.0, 1.1, 1.2 branch to host all the 1.0.x, 1.1.x, 1.2.x stable versions.

FWIW, I think 1.x and 2.x is best to for the simple reason that Semantic Versioning 2.0 mandates the major version be incremented with breaking changes. This means the community can introduce new, non-breaking features and defect commits on fewer branches than if we have 1.1, 1.2, and so on.

I just feel like 1.x and 2.x is too broad and not fine-grain enough.
Does 1.x always pointed to the latest 1.x OpenSearch version as well?
If the chart only support 1.1+ but some user want to install 1.1.0 then 1.x branch would have issues.

Just thinking.

mprimeaux · 2021-10-06T20:41:40Z

Yes, 1.x is always the latest 1.x version of the charts. This also gives a consumer the option to stick with 1.x as per a 'yet to be defined' deprecation policy or go up to the next version knowing there are breaking changes.

The reason why I think 1.0.x and 1.1.x might be a bit too granular is because, for example, if we apply a critical fix to 1.x then we now need to apply the changes to multiple branches.

I suspect @smlx, @DandyDeveloper, and @TheAlgo might want to express their opinions. I sincerely appreciate the "thinking" around this so we all end up in a better spot.

smlx · 2021-10-07T01:30:02Z

Meta: This PR thread is going way off track - maybe it should be moved to a discussion?

IMO long lived release branches have many issues.

The first is versioning. If you have multiple long lived release branches how do you accurately follow SemVer without conflicting versions?

The second is complexity for contributors. Imagine I'm a contributor who submits a PR with a fix. Which branch do I submit it to? And how long until I can use the fix in a released chart? With the current single branch the answers are main and "as soon as it is merged" thanks to release automation. With long lived release branches the answers are much less clear. This is a huge disincentive for contributors.

Third is complexity for maintainers. This repository already struggles to review and merge PRs in a timely manner. Is AWS going to employ several more people to manage maintenance across half a dozen independent release branches?

Fourth is tooling: you're going to be fighting it and adding lots of complexity to CI to implement long-lived release branches.

I would personally vote for Track1, we can create a dev branch to let people keep contributing without version issues. Then maintainer can create PRs with bumped version from dev merge to main in much slower pace.

Why would you want to go from fast fully-automated releases to slow, manual releases? If a PR is merged, shouldn't that code be released immediately? And if the concern is that new code is not adequately tested, then the answer is to improve CI, not to slow down the release process.

DandyDeveloper · 2021-10-07T01:31:09Z

We really need a Slack or Zulip channel for these discussions :)

mprimeaux · 2021-10-07T01:32:23Z

💯 and we're even in an unrelated PR discussing it :)

TheAlgo · 2021-10-11T10:06:12Z

Meta: This PR thread is going way off track - maybe it should be moved to a discussion?

IMO long lived release branches have many issues.

The first is versioning. If you have multiple long lived release branches how do you accurately follow SemVer without conflicting versions?

The second is complexity for contributors. Imagine I'm a contributor who submits a PR with a fix. Which branch do I submit it to? And how long until I can use the fix in a released chart? With the current single branch the answers are main and "as soon as it is merged" thanks to release automation. With long lived release branches the answers are much less clear. This is a huge disincentive for contributors.

Third is complexity for maintainers. This repository already struggles to review and merge PRs in a timely manner. Is AWS going to employ several more people to manage maintenance across half a dozen independent release branches?

Fourth is tooling: you're going to be fighting it and adding lots of complexity to CI to implement long-lived release branches.

I would personally vote for Track1, we can create a dev branch to let people keep contributing without version issues. Then maintainer can create PRs with bumped version from dev merge to main in much slower pace.

Why would you want to go from fast fully-automated releases to slow, manual releases? If a PR is merged, shouldn't that code be released immediately? And if the concern is that new code is not adequately tested, then the answer is to improve CI, not to slow down the release process.

I am in favour of this approach completely. CI improvement is a good suggestion. Let's not stop agile development.

TheAlgo · 2021-10-11T10:07:34Z

@DandyDeveloper for now until we have a final call on the release, can you resolve the conflicts and bump the PR so that we can merge this feature. Thanks

…port

DandyDeveloper · 2021-10-11T10:13:07Z

@TheAlgo Done.

TheAlgo · 2021-10-11T10:18:59Z

@peterzhuamazon @smlx @mprimeaux Can you all please have a look so that we can get this through?

smlx · 2021-10-11T11:58:58Z

I haven't tested it but it looks fine. I'd really like to see some way of using an initcontainer for this, although I recognise it isn't very easy right now.

* Adding support for plugins & Prometheus support. * Updated annotations * Add support for plugin installation * Bumping chart patch. * Bumping again post merge with origin * Linting fixes. * Adding to CI. Updating changelog. * Possibly fixing linting issues. * Updating plugin * Increment chart again * Bumping chart patch. * CHANGELOG Updates

@TheAlgo

* Add new documentations to helm-charts repo (#1) * Add new documentations to helm-charts repo * Replace devops with helm charts keywords * Grammar improvements * Update README * Add issue templates and fix readme typos (#3) * Add issue templates and fix readme typos * Replace component name with chart name * Replace OS/Version to the Helm/Kube versions * Replace OS/Version to the Helm/Kube versions * Migrate helm charts from opensearch-devops repo (#7) * Adding a new folder to host Helm related code * Helm Chart for OpenSearch (#4) * Create basic structure of OpenSearch helm chart * Add templates and change values * Change statefulset and configmap to resolve indentation issue * Fix issues in templates * Fix typos in statefulset.yaml * Add multinode deployment feature * Update version to reflect the OpenSearch version * Add explicit security configuration * Update values.yaml * Create placeholder README.md * Minimum masters should be 3 * Add YAML support for config. sysctl vm.mem fix. * Fixing PSP. Adding better sysctl logic. * Adding ref for systctl * PSP False by default * Disable HTTP SSL by default for Demo. * Fix Chart version to sync with OpenSearch Version * Change cluster name and enable SSL by default Co-authored-by: Aaron Layfield <[email protected]> * fix: give networkpolicy objects a unique name (#16) This fixes the problem of installing this chart multiple times in the same namespace and having the network policy name conflict. * fix: use the stable chart appVersion as image tag by default (#17) Using :latest by default is going to lead to clusters with version skew as pods schedule onto new nodes. So use a stable tag instead. * OpenSearch Dashboards Helm Chart (#10) * Scaffold OpenSearch Dashboards Helm Chart * Fix error for connection refused * Add RBAC functionality * Add security configurations in the chart * Address issues and comments * Fix templates * Disable SSL by default * Address comments for beautification * Address comments * chore: update demo config section (#24) This snippet doesn't make sense in a kubernetes statefulset. * added secretMounts to values.yaml w/ example config (#29) Co-authored-by: johannes.reppin <[email protected]> * Change persistence config to make it more coherent w/ other helm charts (#33) Co-authored-by: johannes.reppin <[email protected]> * add Volumes and change broken (!) yaml indentation (#31) Co-authored-by: johannes.reppin <[email protected]> * support for current ingress apiVersion (#47) * Helm Chart Fixes for Env variables and volumes (#35) * Helm Chart Fixes for Env variables and volumes The opensearch-dashboards chart failed to render correctly when utilizing the extraEnvs flag, caused by incorrect indentation. The opensearch chart failed to render when utlizing the secrets for the security config, this was due to them being in the env section. This pull request reqolves both issues, verified via running helm template with the minumal values files included here: ```yaml envFrom: - secretRef: name: kibana-secrets extraEnvs: - name: TENANT_ID valueFrom: secretKeyRef: name: kibana-secrets key: tenantID ``` ```yaml securityConfig: enabled: true configSecret: "security-config" internalUsersSecret: "internal-users-config" rolesMappingSecret: "roles-mapping-config" rolesSecret: "roles-config" ``` * Updating paths in sts to be dynamic Updating the paths specified in the sts for opensearch to utilize .Values.opensearchHome to allow for dynamic paths, with a default of `/usr/share/opensearch` which should be sufficient for most users. * Fixing config path in opensearch-dashboards (#38) * Fixing config path in opensearch-dashboards The manifests rendered by the Helm chart place the user provided config into the incorrect directory. This simply updates that location to the correct path and updates the values.yaml file to use the correct default config file so that the user provided setting override the defaults. * Updating cert paths to opensearch-dashboards Cert paths also need to utilize new filesystem location for opensearch-dashboards config. * Resolves issue with securityConfig path (#41) * Resolves issue with securityConfig path Issue #39 This updates the securityConfig path in values to use the correct value for opensearch. * Fixing bad auto formatting Removing unneeded indentation/newlines. * Fixing missed auto formatting errors * resolve issue about .Values.opensearchHome (#52) refer to this: opensearch-project/opensearch-devops@fe831db#commitcomment-55395428 Error Msg: nil pointer evaluating interface {}.opensearchHome * Fix helm chart can not be deployed without ssl (#56) * Fixing issue exposed by changes in #38 After switching the name of the config file, and removing the shadowing between the default (from the docker container opensearch-dashbaords.yaml) and the default from the helm chart (dashboards.yaml) there is an issue with the certs that are attempting to be used. In order for this to work with the defaults, disabled TLS verification will be needed, and then disabling TLS to remain in line with the defaults. I added a commented out section showing what could potentially be used as TLS config if the user chooses to enable it. * Using conventional yaml formatting for ssl config Moving comments around to follow relevant code and utilizing nested yaml format rather than dot format. * Changing Folder name to Charts * Change deafult configuration for dashboards * Update securityconfig.yaml to remove extra spaces Co-authored-by: Barani <[email protected]> Co-authored-by: Aaron Layfield <[email protected]> Co-authored-by: Scott Leggett <[email protected]> Co-authored-by: Johannes Reppin <[email protected]> Co-authored-by: johannes.reppin <[email protected]> Co-authored-by: paltryeffort <[email protected]> Co-authored-by: hgoscenski-imanage <[email protected]> Co-authored-by: Nagle Zhang <[email protected]> * chore: remove redundant line from yaml (#18) * fix: remove buggy labels template (#20) The opensearch-dashboards.standard did not properly escape chart version, and anyway we should be using the same set of standard labels as all the other templates. * fix: use absolute path to opensearch-keystore binary (#27) It is not in $PATH. * chore: use consistent indentation in opensearch templates (#24) * Fix typo in comment (#10) * fix: make secretMount parameters required (#22) This fixes the case where a parameter on one of the items is silently missing. * fix: avoid line containing only spaces in rendered template (#23) * fix!: update name of JAVA_OPTS variable (#39) ES_JAVA_OPTS has been renamed in Opensearch to OPENSEARCH_JAVA_OPTS. * chore: use consistent indentation in opensearch-dashboards templates (#25) * Add TheAlgo and DandyDeveloper as the new maintainers of the repo (#47) * Add DandyDeveloper as the new maintainer of the repo * Add TheAlgo as part of the maintainer list * Modify majorVersion fallback logic (#21) * feat: modify majorVersion fallback logic * Look in both .Values.imageTag and .Chart.AppVersion before falling back to a default value. * Use the built-in semver parsing function. * Don't ignore the version for non-opensearch images. * fix: use fallback major version 1 instead of 7 Opensearch is currently version 1.x. 7 seems to be a remnant of Elasticsearch. * fix securityConfigSecrets.config.data secrets mount plus permissions (#9) Fix securityConfigSecrets.config.data secrets mount plus permissions * Add README for OpenSearch (#48) * Add README for OpenSearch * Address comments * Add support for Helm chart linting and releasing. (#46) * - Added support for the Helm chart testing action. - Added support for the Helm chart releaser action. - Fixed minor lint issues in Helm chart values files. * Added support for testing in addition to linting. * - Relaxed event triggers on GitHub actions workflow for lint and test. - Now using `ubuntu-latest` for GitHub runner references. - Added `maintainers` to all charts. - Incremented patch version for each chart. * - Added title for Installation * - Added missing helm update step in installation. * fix: use consistent k8s API semver comparison logic (#19) This is required to work around bugs in the version string returned by kubernetes distros such as EKS and GKE, where they have invalid Semantic Version strings. See helm/helm#3810. * Fix README.md (#60) * Enable Helm chart release (#61) * - Added change logs for the opensearch and opensearch-dashboards Helm charts. - Amended README files to reflect the intended installation and usage. - Incremented the version numbers to 1.0.2 for both Helm charts in adherence to linting rules and Semver 2. * - Modified OpenSearch chart description * - Reverted to previous chart installation instructions until we can verify the new method succeeds. * Helm Chart Releaser Trigger Fix (#73) * - Incremented Helm charts to ensure the releaser workflow triggers a difference. * - Added the `workflow_dispatch` option for manually pushing action workflows. * Remove stale README (#57) * Incorrect indentation for `extraVolumeMounts`, `extraEnvs`, `envFrom` in `statefulset.yaml`. (#80) * Changes - Fixes incorrect indentation for `extraVolumeMounts`, `extraEnvs`, and `envFrom`. * Changes: - Increment version of the opensearch dashboards chart until PR #75 is merged. * - Amended CHANGELOGs * enable setting docker registry for all images (#70) * Added basic support for plugins on nodes (#71) * Adding support for plugins & Prometheus support. * Updated annotations * Add support for plugin installation * Bumping chart patch. * Bumping again post merge with origin * Linting fixes. * Adding to CI. Updating changelog. * Possibly fixing linting issues. * Updating plugin * Increment chart again * Bumping chart patch. * CHANGELOG Updates * Use the correct master configuration for majorVersion 1 (#69) * fix: use the correct master configuration for majorversion 1 * chore: bump opensearch chart version * Amended installation instructions (#81) * Amended installation instruction and relaxed linting and testing workflow triggers. * Minor typographic error. * - Reverted linting and testing trigger globbing. * - Added path globbing. * - Removed path globbing. * Revert "- Amended CHANGELOGs" This reverts commit e0ab178. * - Bumped chart versions. - Amended CHANGELOGs. * Incremented opensearcn chart version to 1.0.8 * - Added specific references to the underlying charts folder from the root-level README. - Addressed clarifications from @TheAlgo. * - Modified change log for the OpenSearch Helm chart. * Use a per-install name for securityconfig secret (#41) * feat: per-install name for securityconfig secret Give the securityconfig secret an autogenerated unique name to facilitate installing the chart multiple times in the same namespace. This helps with the common case of sharing the securityconfig between multiple instantiations of this chart to construct an Opensearch cluster. * feat: update logic to handle externally defined secrets See the comments describing how this is intended to work. * chore: bump opensearch chart version * chore: add securityConfig to README * Rework labels in Opensearch chart to match standard recommendations (#37) * feat: rework labels to match standard recommendations https://helm.sh/docs/chart_best_practices/labels/#standard-labels https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/ * chore: bump opensearch chart version * Add missing helm install commands in README (#90) * Adding a DCO Check related workflow (#101) * add missing labels key into roles.yaml (#99) * add missing labels key into roles.yaml * Apply suggestions from code review Co-authored-by: Oliver Hartl <[email protected]> Co-authored-by: Oliver Hartl <[email protected]> * fix: fix env and envFrom indentation when using keystore value. (#103) * fix: fix env and envFrom indentation when using keystore value. * fix: Chart version bump needed by CI * FIX: Issue 105 - RBAC enabled (#106) * - Added missing `labels:` stanza delimeter to role.yaml to address the failure when RBAC is enabled. * - Renamed CI values file for testing RBAC enabled. * - Indented template line to asthetically match. * - Incremented OpenSearch chart version to 1.2.2 to accommodate another PR. * - Amended CHANGELOG as per review. * Add option to disable initContainer chown update (#102) * Add option to disable initContainer chown update * True default, not false. * Remove trailing spaces * Updating CHANGELOG and README * Change appVersion of OpenSearch and Dashboards chart (#114) * Updating Latest API Versions for Ingress and Pod Policies (#94) * Updating Latest API Versions for Ingress and Pod Policies * chart version bump * 1.21 for Policy APIs * Attempting to use kind + GHA matrix for testing various k8s versions Co-authored-by: Aaron Layfield <[email protected]> Co-authored-by: Dhiraj Kumar Jain <[email protected]> * Fix deprication warnings about node.roles. Now roles described as a list (#124) * add values for fsgroup-volume image (#127) * add values for fsgroup-volume image * Increment the Chart version and update the Changelog * Add version 1.3.1 to CHANGELOG.md * fix: Handle log4j2 not being yaml (#110) and chart bump. (#123) * fix: Handle log4j2 not being yaml (#110) and chart bump. * Including tpl changes * Adding log4j example. * Adding some documentation AND updated per comment.s * Use project name and clarify from/to. * Explicitly document that config must be YAML multiline strings. * Cast as string for use with tpl. * Because this would be really annoying. * fix: Handle log4j2 not being yaml (#110) and chart bump to 1.4.0. Co-authored-by: Aaron Layfield <[email protected]> * [Dashboards] Add extraVolumes and extraVolumeMounts (#128) * Remove whitespace in DN (#130) * Update Chart.yaml * Remove whitespace in dn. * update changelog. * update changelog and chart version. * Updating the copyright header to reflect the apache-2.0 license (#134) * Updating the copyright header to reflect the apache-2.0 license * Update opensearch dashboards version and changelogs Co-authored-by: Peter Zhu <[email protected]> * Fix node.roles environment variable (#137) * Fix node.roles environment variable * forgotten version bump * Fix url to values.yaml in README.md in opensearch chart (#139) * Fix url to values.yaml in README.md in opensearch chart * Make URL to values.yaml in README.md more consistent (with reference section) * Increment the Chart version and update the Changelog * Update version of opensearch chart after resolving merge conflict Co-authored-by: Dmytro Gorbunov <[email protected]> * FEATURE: Add support for IngressClassName (#149) * Added support for the `ingressClassName` field. The `kubernetes.io/ingress.class` annotation was deprecated in Kubernetes 1.18. * - Fixed trailing spaces as per chart lint rules. * docs: fix typo (#152) * docs: fix typo * Bump version * Add changelog * Add changelog Co-authored-by: Peter Zhu <[email protected]> * Removed root-level CHANGELOG.md since each chart maintains their own (#165) changelog. * Change helm notes as the pod label key has changed (#148) * Change helm notes as the pod label key has changed * bump version * update CHANGELOG.md * resolve conflicts * bump version & update changelog * fix: deprecated api migration versions (#162) build: add changelog & bump version * Updated OpenSearch appVersion to 1.2.1 (#164) * Updated OpenSearch appVersion to 1.2.0 * Fixed CHANGELOG.MD * Updated to OpenSearch 1.2.1 * Fixed version Co-authored-by: Derek Diaz <[email protected]> * prefer .Chart.AppVersion by default (#175) Do not specify `imageTag` in the default `values.yaml` to use .Chart.AppVersion by default Fixes #177 * Add notes about default install in README Signed-off-by: Sébastien Lehuédé <[email protected]> * Add notes about default install in README Signed-off-by: Sébastien Lehuédé <[email protected]> * Change version number * Change version number Signed-off-by: Peter Zhu <[email protected]> * Remove additional files Signed-off-by: Peter Zhu <[email protected]> * Remove additional files Signed-off-by: Peter Zhu <[email protected]> Co-authored-by: Peter Zhu <[email protected]> Co-authored-by: Dhiraj Kumar Jain <[email protected]> Co-authored-by: Barani <[email protected]> Co-authored-by: Aaron Layfield <[email protected]> Co-authored-by: Scott Leggett <[email protected]> Co-authored-by: Johannes Reppin <[email protected]> Co-authored-by: johannes.reppin <[email protected]> Co-authored-by: paltryeffort <[email protected]> Co-authored-by: hgoscenski-imanage <[email protected]> Co-authored-by: Nagle Zhang <[email protected]> Co-authored-by: Avery Khoo <[email protected]> Co-authored-by: alborotogarcia <[email protected]> Co-authored-by: Michael Primeaux <[email protected]> Co-authored-by: Kenan Erdogan <[email protected]> Co-authored-by: Oliver Hartl <[email protected]> Co-authored-by: Paul LESUR <[email protected]> Co-authored-by: Hayden Fuss <[email protected]> Co-authored-by: Sebor <[email protected]> Co-authored-by: Kersten Schlosser <[email protected]> Co-authored-by: sastorsl <[email protected]> Co-authored-by: Rémi BUTET <[email protected]> Co-authored-by: sebas-intellegens <[email protected]> Co-authored-by: Barani <[email protected]> Co-authored-by: Tomas Odehnal <[email protected]> Co-authored-by: Dmytro Gorbunov <[email protected]> Co-authored-by: Dmytro Gorbunov <[email protected]> Co-authored-by: Michael Kriese <[email protected]> Co-authored-by: davidshtian <[email protected]> Co-authored-by: Michael Rödel <[email protected]> Co-authored-by: Derek Diaz Correa <[email protected]> Co-authored-by: Derek Diaz <[email protected]> Co-authored-by: K3A <[email protected]> Co-authored-by: Peter Zhu <[email protected]>

DandyDeveloper added 4 commits September 20, 2021 16:19

Adding support for plugins & Prometheus support.

92d273a

Updated annotations

1afd0c7

Add support for plugin installation

1ad6feb

Bumping chart patch.

b06f95e

DandyDeveloper requested a review from TheAlgo September 28, 2021 08:08

DandyDeveloper added 3 commits September 28, 2021 17:08

Merge branch 'main' of https://github.com/opensearch-project/helm-charts

560d792

into feature/dandydev/add-prometheus-exporter-support

Bumping again post merge with origin

266479f

Linting fixes.

3fc00d3

DandyDeveloper added 3 commits September 30, 2021 10:43

Merge branch 'main' of https://github.com/opensearch-project/helm-charts

2a14605

into feature/dandydev/add-prometheus-exporter-support

Adding to CI. Updating changelog.

aabe534

Possibly fixing linting issues.

0617866

TheAlgo reviewed Oct 1, 2021

View reviewed changes

charts/opensearch/values.yaml Outdated Show resolved Hide resolved

DandyDeveloper added 2 commits October 4, 2021 10:02

Updating plugin

f050925

Merge branch 'main' of https://github.com/opensearch-project/helm-charts

56f33d2

into feature/dandydev/add-prometheus-exporter-support

TheAlgo requested changes Oct 4, 2021

View reviewed changes

Increment chart again

1602746

TheAlgo requested a review from peterzhuamazon October 5, 2021 13:44

peterzhuamazon mentioned this pull request Oct 6, 2021

Weekly Community Engagement on 2021/09/28 - 2021/10/11 opensearch-project/opensearch-build#636

Closed

Merge branch 'main' into feature/dandydev/add-prometheus-exporter-sup…

5790586

…port

DandyDeveloper added 2 commits October 11, 2021 19:14

Bumping chart patch.

fdb6f2f

CHANGELOG Updates

b648c63

peterzhuamazon approved these changes Oct 11, 2021

View reviewed changes

peterzhuamazon merged commit 8aaa89e into opensearch-project:main Oct 11, 2021

BionIT mentioned this pull request Oct 27, 2022

allow adding plugins and change defaultmode for opensearch dashboards #342

Merged

3 tasks

BionIT mentioned this pull request Dec 8, 2022

[Backport 1.x]allow adding plugins and change defaultmode for opensearch dashboards #359

Closed

3 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added basic support for plugins on nodes #71

Added basic support for plugins on nodes #71

DandyDeveloper commented Sep 28, 2021

DandyDeveloper commented Sep 28, 2021 •

edited

Loading

mprimeaux commented Sep 28, 2021 •

edited

Loading

DandyDeveloper commented Sep 28, 2021

mprimeaux commented Sep 29, 2021 •

edited

Loading

DandyDeveloper commented Sep 30, 2021

mprimeaux commented Sep 30, 2021

DandyDeveloper commented Sep 30, 2021 •

edited

Loading

mprimeaux commented Sep 30, 2021

mprimeaux commented Sep 30, 2021

DandyDeveloper commented Oct 4, 2021

DandyDeveloper commented Oct 4, 2021

smlx commented Oct 4, 2021

TheAlgo commented Oct 4, 2021

TheAlgo left a comment •

edited

Loading

DandyDeveloper commented Oct 5, 2021 •

edited

Loading

peterzhuamazon commented Oct 5, 2021

DandyDeveloper commented Oct 6, 2021

mprimeaux commented Oct 6, 2021 •

edited

Loading

smlx commented Oct 6, 2021

mprimeaux commented Oct 6, 2021 •

edited

Loading

peterzhuamazon commented Oct 6, 2021 •

edited

Loading

mprimeaux commented Oct 6, 2021

peterzhuamazon commented Oct 6, 2021

mprimeaux commented Oct 6, 2021

peterzhuamazon commented Oct 6, 2021

mprimeaux commented Oct 6, 2021

smlx commented Oct 7, 2021

DandyDeveloper commented Oct 7, 2021

mprimeaux commented Oct 7, 2021 •

edited

Loading

TheAlgo commented Oct 11, 2021

TheAlgo commented Oct 11, 2021

DandyDeveloper commented Oct 11, 2021

TheAlgo commented Oct 11, 2021

smlx commented Oct 11, 2021 •

edited

Loading

Added basic support for plugins on nodes #71

Added basic support for plugins on nodes #71

Conversation

DandyDeveloper commented Sep 28, 2021

Description

Issues Resolved

Check List

DandyDeveloper commented Sep 28, 2021 • edited Loading

mprimeaux commented Sep 28, 2021 • edited Loading

DandyDeveloper commented Sep 28, 2021

mprimeaux commented Sep 29, 2021 • edited Loading

DandyDeveloper commented Sep 30, 2021

mprimeaux commented Sep 30, 2021

DandyDeveloper commented Sep 30, 2021 • edited Loading

mprimeaux commented Sep 30, 2021

mprimeaux commented Sep 30, 2021

DandyDeveloper commented Oct 4, 2021

DandyDeveloper commented Oct 4, 2021

smlx commented Oct 4, 2021

TheAlgo commented Oct 4, 2021

TheAlgo left a comment • edited Loading

Choose a reason for hiding this comment

DandyDeveloper commented Oct 5, 2021 • edited Loading

peterzhuamazon commented Oct 5, 2021

DandyDeveloper commented Oct 6, 2021

mprimeaux commented Oct 6, 2021 • edited Loading

smlx commented Oct 6, 2021

mprimeaux commented Oct 6, 2021 • edited Loading

peterzhuamazon commented Oct 6, 2021 • edited Loading

mprimeaux commented Oct 6, 2021

peterzhuamazon commented Oct 6, 2021

mprimeaux commented Oct 6, 2021

peterzhuamazon commented Oct 6, 2021

mprimeaux commented Oct 6, 2021

smlx commented Oct 7, 2021

DandyDeveloper commented Oct 7, 2021

mprimeaux commented Oct 7, 2021 • edited Loading

TheAlgo commented Oct 11, 2021

TheAlgo commented Oct 11, 2021

DandyDeveloper commented Oct 11, 2021

TheAlgo commented Oct 11, 2021

smlx commented Oct 11, 2021 • edited Loading

DandyDeveloper commented Sep 28, 2021 •

edited

Loading

mprimeaux commented Sep 28, 2021 •

edited

Loading

mprimeaux commented Sep 29, 2021 •

edited

Loading

DandyDeveloper commented Sep 30, 2021 •

edited

Loading

TheAlgo left a comment •

edited

Loading

DandyDeveloper commented Oct 5, 2021 •

edited

Loading

mprimeaux commented Oct 6, 2021 •

edited

Loading

mprimeaux commented Oct 6, 2021 •

edited

Loading

peterzhuamazon commented Oct 6, 2021 •

edited

Loading

mprimeaux commented Oct 7, 2021 •

edited

Loading

smlx commented Oct 11, 2021 •

edited

Loading