Code Monkey home page Code Monkey logo

bookkeeper-operator's Introduction

Pravega Build Status codecov License Version CII Best Practices

Pravega is an open source distributed storage service implementing Streams. It offers Stream as the main primitive for the foundation of reliable storage systems: a high-performance, durable, elastic, and unlimited append-only byte stream with strict ordering and consistency.

To learn more about Pravega, visit https://pravega.io

Prerequisites

  • Java 11+

In spite of the requirements of using JDK 11+ to build this project, client artifacts (and its dependencies) must be compatible with a Java 8 runtime. All other components are built and ran using JDK11+.

The clientJavaVersion project property determines the version used to build the client (defaults to 8).

Building Pravega

Checkout the source code:

git clone https://github.com/pravega/pravega.git
cd pravega

Build the pravega distribution:

./gradlew distribution

Install pravega jar files into the local maven repository. This is handy for running the pravega-samples locally against a custom version of pravega.

./gradlew install

Running unit tests:

./gradlew test

Setting up your IDE

Pravega uses Project Lombok so you should ensure you have your IDE setup with the required plugins. Using IntelliJ is recommended.

To import the source into IntelliJ:

  1. Import the project directory into IntelliJ IDE. It will automatically detect the gradle project and import things correctly.
  2. Enable Annotation Processing by going to Build, Execution, Deployment -> Compiler > Annotation Processors and checking 'Enable annotation processing'.
  3. Install the Lombok Plugin. This can be found in Preferences -> Plugins. Restart your IDE.
  4. Pravega should now compile properly.

For eclipse, you can generate eclipse project files by running ./gradlew eclipse.

Note: Some unit tests will create (and delete) a significant amount of files. For improved performance on Windows machines, be sure to add the appropriate 'Microsoft Defender' exclusion.

Releases

The latest pravega releases can be found on the Github Release project page.

Snapshot artifacts

All snapshot artifacts from master and release branches are available in GitHub Packages Registry

Add the following to your repositories list and import dependencies as usual.

maven {
    url "https://maven.pkg.github.com/pravega/pravega"
    credentials {
        username = "pravega-public"
        password = "\u0067\u0068\u0070\u005F\u0048\u0034\u0046\u0079\u0047\u005A\u0031\u006B\u0056\u0030\u0051\u0070\u006B\u0079\u0058\u006D\u0035\u0063\u0034\u0055\u0033\u006E\u0032\u0065\u0078\u0039\u0032\u0046\u006E\u0071\u0033\u0053\u0046\u0076\u005A\u0049"
    }
}

Note GitHub Packages requires authentication to download packages thus credentials above are required. Use the provided password as is, please do not decode it.

If you need a dedicated token to use in your repository (and GitHub Actions) please reach out to us.

As alternative option you can use JitPack (https://jitpack.io/#pravega/pravega) to get pre-release artifacts.

Quick Start

Read Getting Started page for more information, and also visit sample-apps repo for more applications.

Running Pravega

Pravega can be installed locally or in a distributed environment. The installation and deployment of pravega is covered in the Running Pravega guide.

Support

Don’t hesitate to ask! Contact the developers and community on slack (signup) if you need any help. Open an issue if you found a bug on Github Issues.

Documentation

The Pravega documentation is hosted on the website: https://pravega.io/docs/latest or in the documentation directory of the source code.

Contributing

Become one of the contributors! We thrive to build a welcoming and open community for anyone who wants to use the system or contribute to it. Here we describe how to contribute to Pravega! You can see the roadmap document here.

About

Pravega is 100% open source and community-driven. All components are available under Apache 2 License on GitHub.

bookkeeper-operator's People

Contributors

alfred-landrum avatar amit-singh40 avatar anishakj avatar co-jo avatar craneshiemc avatar dependabot[bot] avatar leapsky avatar nikolay-t avatar nishant-yt avatar pbelgundi avatar prabhaker24 avatar realaaronwu avatar rwx42 avatar srisht avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

bookkeeper-operator's Issues

Allow ingestion of user defined env vars in Bookie containers

Description

User should be able to create a config map with K:Vs and provide the name of the same in the manifest. Operator should plug this config map into the bookie pods so the variables defined there-in are available inside Bookie containers

Importance

must-have

Allow Deploying Bookkeeper Operator Chart In TestMode

Description

Some non-production features are behind TestMode. It would be nice to be able to set that in the values when installing the chart.

Importance

For running small BK instances in say minikube or small deploys

Location

charts

Suggestions for an improvement

Allow setting TestMode through a values flag.

Bookkeeper Operator should send an event if it is not able to delete metadata from zookeeper when BK cluster is deleted

Description

When Bookkeeper cluster is deleted, the operator attempts to delete BK metadata from zookeeper. If connection to ZK fails or we're not able to delete this metadata for some reason, we just log an error in Bookkeeper logs and do not notify the admin/user that we failed to delete this metadata in any other way.

Importance

should-have

Location

reconcileFinalizer() method.

Suggestions for an improvement

Send a K8s "Error" event when we fail to delete metadata from zookeeper, similar to the events send on Upgrade/Rollback failure.

Invalid JVM Options for JDK 11 (Bookkeeper +4.11)

Description

Bookkeeper operator does not work with Bookkeeper 4.11.x. The reason is that Bookkeeper 4.11.x switched to JDK 11 and some of the JVM options used in the Bookkeeper Operator (i.e.,

"-XX:+UseCGroupMemoryLimitForHeap",
) are invalid for JDK 11.

Importance

Must-have.

Location

JVM Options of Bookkeeper.

Suggestions for an improvement

Either add -XX:+IgnoreUnrecognizedVMOptions as a JVM option or adapt the JVM options depending on the Bookkeeper version being deployed.

Bookie failing to restart with InvalidCookieException

Description

Bookies enter CrashLoopBackOff state after a few hours of running longevity.
Also while specifying LedgerDirectories for bookkeeper as a comma-separated list of directories (ledgerDirectories: "/bk/ledgers/l0,/bk/ledgers/l1,/bk/ledgers/l2,/bk/ledgers/l3"), the following directory structure is observed inside the bookkeeper pod, which which have caused the issue

$ ls /bk/ledgers/
l0  l0,  l1  l2  l3

Importance

blocker

Allow non-valid image versions to be used in non-production environments

Description

Currently, there doesn't seem to be an easy way to use the Boperator charts (without modifying them) with Bookkeeper versions that are not already part of the version matrix. There should be a way to deploy those operators in such a way to skip that validation for development purposes (without modifying the charts)

Importance

must have

Location

charts

Making timeouts on readiness and liveness probes configurable

Description

Currently we are using some fixed value to configure the various timeouts (i.e. failureThreshold, initialDelaySeconds, periodSeconds, successThreshold, timeoutSeconds) for the readiness and liveness probes of the bookie pods.

Importance

should have

Location

pkg/controller/bookkeepercluster/bookie.go

Suggestions for an improvement

It would be better if we can give users the option to provide values for the various timeout values for the readiness and liveness probes from the bookkeeper manifest, and default values for these could be used if the user does not specify any value.

Fix the inconsistencies with the webhook cert name

Description

Currently there is an inconsistency with the webhook cert name when the certificate needs to be generated by the charts by setting .Values.webhookCert.generate: true

Importance

Not a blocker since there is a workaround by setting the webhookCert.certName to match the name of the certificate created by the charts
https://github.com/pravega/bookkeeper-operator/blob/master/charts/bookkeeper-operator/templates/certificate.yaml#L18

Location

charts

Allow bookkeeper size to be 1

Description

Pravega-operator has support to specify zookeeper cluster size to be 1 but not for bookkeeper. Even the Pravega controller and segment store can have size 1. We have a need for bookkeeper size to be reduced to 1 as well:
We would like:

pravega_cluster:
   pravega_replicas:
      controller: 1
      segment_store: 1
      zookeeper: 1
      bookkeeper: 1

Importance

Pravega cluster is deployed to small footprint environments. Unless we restrict the size of the cluster for each of controller, segment_store, zookeeper and bookkeeper, the deployment does not go through due to shortage of cpu, memory etc. The error we get is "Insufficient cpu" or "OutOfMemory" leading to large number of pod restarts. The option to reduce the replicas help us even more given that the resource usages for pravega cluster is significant by default.

Location

The code affected by this change is internal.

Suggestions for an improvement

The bookkeeper.go file sets the default size to 3 whenever the size is smaller than 3. Instead it should continue to set the default if the size is smaller than 1 so that the minimum size specifiable is 1.

Make Pod Disruption Budgets Configurable

Description

Current Bookkeeper poddisruption budgets prevent bookkeeper pods from evicting if the number of bookkeeper pods are greater than the number of nodes.

Importance

nice_to_have

Location

bookkeeper.go

Suggestions for an improvement

Make the PDB configurable i.e allow updation of maxUnavailable for bookkeeper.

Improve unit test coverage for Bookkeeper Operator

Description

Current code coverage is < 50%. Low code coverage hinders with robust testing of changes and and does not allow us to fail fast.

Importance

must have

Suggestions for an improvement

Add more tests to cover all possible code paths such that we get better code coverage.

Bookkeeper operator to manage the pravega-bookkeeper cluster

Description

(Describe the feature, bug, question, proposal that you are requesting)

Importance

(Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have))

Location

(Where is the piece of code, package, or document affected by this issue?)

Suggestions for an improvement

(How do you suggest to fix or proceed with this issue?)

Invalid JVM Options for JDK 11

Description

Bookkeeper operator does not work with Bookkeeper 4.11.x. The reason is that Bookkeeper 4.11.x switched to JDK 11 and some of the JVM options used in the Bookkeeper Operator i.e., AggressiveOpts, PrintGCDateStamps and MaxRAMFraction are either deprecated or invalid for JDK 11.

Importance

must have

Location

pkg/controller/bookkeepercluster/bookie.go

Suggestions for an improvement

Deprecated option XX:MaxRAMFraction can be replaced with XX:MaxRAMPercentage

BK_AUTORECOVERY environment variable set by the operator does not take effect.

Description

Irrespective of whether the user sets auto-recovery in bookkeeper manifest to true or false the configuration property "autoRecoveryDaemonEnabled" is never set in bk_server.conf, because it is not translated as was done here: https://github.com/pravega/pravega/pull/3192/files/a6db0235fe32b09dbe641649ee64311df6bc970e

Steps to reproduce

  1. Deploy bookkeeper cluster and log-in to a bookie pod and check the value of property autoRecoveryDaemonEnabled inside bk_server.conf
    The value is not be set, where as it should be set to "true" given that autorecovery defaults to true in bookkeeper manifest.
  2. In bookkeeper manifest, set autorecovery=false and post deployment check autoRecoveryDaemonEnabled inside bk_server.conf. Again it is not set.

All in all the Environment Variable "BK_AUTORECOVERY" set by the operator is not taking effect.

Importance

must-have

Provide the supported upgrade Versions as configuration to webhook

Description

Currently the supported versions map is hard-coded and that can be a real problem, when using images from test/prod environments or apache/bookkeeper images.

Importance

must-have

Suggestion for improvement
The supported upgrade paths can be provided via a config map to the validating webhook.

Add support to provide a custom upgrade path to a test version

Description

Currently the bookkeeper operator provides support to install a test version which has not yet been released and is therefore not a part of the supported versions config map. However, there is no way today to supply a custom upgrade path in the supported versions configmap, which could allow testing out any upgrade paths including to non released versions.

Importance

This issue is not a blocker as there is a workaround to achieve this by editing the bk-supported-versions configmap. However it is something that we should definitely add support for.

Location

charts

Suggestions for an improvement

We could add two values under test mode, fromVersion and toVersion.

Bookkeeper Operator does not handle bookkeeper upgrade in a one by one fashion

Description

Bookkeeper Operator adopts an OnDelete upgrade strategy to handle bookkeeper upgrade in which bookkeeper pods are brought down one at a time and the updated pod comes back up. However in Bookkeeper Operator 0.1.3-rc0, it has been observed that multiple bookkeeper pods are being brought down when an upgrade is triggered, which might be detrimental.

Importance

must have

Location

pkg/controller/bookkeepercluster/upgrade.go

Unable to set bookkeeperJVMOptions

Attached is our bookkeeper.yaml. The deployment goes fine. However, none of the parameters in the bookkeeperJVMOptions are being set.

bookkeeper.yaml.txt

For example we are expecting the "-XX:MaxDirectMemorySize=8g"]

However, it's still set at 1g:

[root@pravega-bookie-0 bookkeeper]# env | grep BOOKIE
BOOKIE_MEM_OPTS=-Xms1g -XX:MaxDirectMemorySize=1g -XX:+ExitOnOutOfMemoryError -XX:+CrashOnOutOfMemoryError -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp/dumpfile/heap -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:MaxRAMFraction=2

Deletion of LongTermStorage to be handled by bookkeeper-operator

Description

LongTermStorage's deletion is required as part of a redeployment of bk-cluster( that is once the pravega cluster and bk-cluster are deployed and we undeploy them and when we redeploy them) in that case for the i/o to work. this is needed as otherwise, the controller will point to the wrong metadata entries and because of which i/o will fail with a 503 error...additionally in case the user doesn't want to remove his LongTermStorage what he can do is while redeploying he can deploy using a different LongTermStorage and in case he is using the same LongTermStorage bk-operator should give the necessary warnings.

Importance

nice to have

Location

while deleting the bookkeeper cluster bk-operator should delete the LongTermStorage and in case the user wants don't want to delete LongTermStorage bk-operator should give warning to the user to use another pvc as using the same LongTermStorage will cause issues this can be done in the bookkeepercluster_controller.go

Suggestions for an improvement

In the bookkeepercluster_controller.go while we are removing the zk metadata we can additionally remove the LongTermStorage as well.

Bookkeeper pods do not come up if storage size for index/journal/ledger volume claim templates is not mentioned

Description

The default value of the index, journal and ledger volume claim templates are applied only if the entire volume claim templates is undefined. However if a few fields within the volume claim template have been mentioned by the user and volume size is not mentioned, no default value gets assigned to it thereby causing a failure in the coming up of the bookkeeper pods.

Importance

should have

Location

pkg/apis/bookkeeper/v1alpha1/bookkeepercluster_types.go

BK Operator Chart has wrong version

Description

Chart/app version for BK operator chart 0.1.3 is wrong

Importance

Should have.

Location

charts/bookkeeper-operator/Chart.yaml

Suggestions for an improvement

Fix it.

Ability to resize PVCs

Description

Currently PVCs created for journal,ledger,index volumes in Bookkeeper cannot be resized and for lifetime of the Pravega deployment the PVCs will continue to be pf the same size

Importance

should-have

Ensure ledgers are appropriately re-replicated in case of bookkeeper scale-down

Description

When bookies are scaled down below the write-quorum, it is possible to have under-replicated ledgers as a result. This use-case however has not been handled.

Importance

must have

Location

pkg/controller/bookkeepercluster/bookkeepercluster_controller.go

Suggestions for an improvement

The following command can be used before scaling down the bookkeeper PVCs

$ bin/bookkeeper shell decommissionbookie

Need to add OpenApiSchemaValidation

Description

Need to add OpenApiSchemaValidation

Importance

should-have

Location

changes should be added to the crd file in the deploy and charts template folder

Suggestions for an improvement

Use operator-sdk generate crds command to generate new crd.

Webhook skips version validation

Description

When the bookkeeper operator is installed via charts, the webhook does not do version validation as expected. Also if a correct/valid certificate has not been provided to the webhook at the time of installation, it should prompt the appropriate error message instead of allowing installation of any pravega version without doing the version validation.

Importance

must have

Location

charts

Provide support for configuring block owner deletion for PVC's

Description

Currently, Block owner deletion is always set as true for PVC's . If the statefulset controller is not having permission to set finalizers on PVCs , creation of the persistent volume claims is failing

Importance

Nice to have

Location

bookkeepercluster_types.go

Suggestions for an improvement

Make Block owner deletion configurable for PVCs

Add Ut coverage for bookkeepercluster_controller.go and upgrade.go files

Description

We don't have any unit test coverage for bookkeepercluster_controller.go and upgrade.go files

Importance

Nice to have.

Location

Test files should be added in the pkg folder

Suggestions for an improvement

Add bookkeepercluster_controller_test.go and upgrade_test.go files in the pkg/controller folder

Unable to upgrade from bookkeeper 0.7.1 to 0.9.0

Description

Due to version configmap not allowing separate from/to for test versions
(Describe the feature, bug, question, proposal that you are requesting)
We have https://github.com/pravega/pravega-operator/blob/master/charts/pravega-operator/values.yaml#L29 but that only works for straight installs https://github.com/pravega/pravega-operator/blob/master/charts/pravega-operator/templates/version_map.yaml#L26

Importance

Upgrade from 0.7.1 to 0.9.0 is broken
(Indicate the importance of this issue to you (blocker, must-have, should-have, nice-to-have))

Location

https://github.com/pravega/pravega-operator/blob/master/charts/pravega-operator/templates/version_map.yaml#L26
(Where is the piece of code, package, or document affected by this issue?)

Suggestions for an improvement

we can add two values under test mode.  A "fromVersion" and "toVersion".
0.9.0 to 0.9.0

(How do you suggest to fix or proceed with this issue?)

Investigate Bookkeeper disruption cases

Description

We need to investigate and implement an action plan to cover all BookKeeper disruption cases. Some disruption cases that come to my mind are:

Graceful termination. The BK pod receives a TERM signal to gracefully shutdown. Some situations that cause this are:
kubectl drain to remove a node from the K8 cluster.
kubectl delete pod to delete a particular Bookkeeper pod, probably accidentally.
Scale down event.
Unexpected termination. This kind of disruptions will give pods no chance to gracefully terminate. Examples are hardware errors, VM deletion, hard evictions, etc.
For graceful terminations, we may want to run a pre-delete hook, preStop handler in K8 terminology, to make sure that ledgers stored in that Bookie are rereplicated before it is shut down. Probably by running a Bookkeeper manual recovery process.

For unexpected terminations, we may want to rely on Bookkeeper's autorecovery feature and the pod disruption budget to prevent a second pod graceful termination until the terminated pod is rescheduled and recovered.

Importance

must-have

Suggestions for an improvement

Data issues caused because of a pod being unavailable for more than a certain time period should be handled by AutoRecovery.
Currently Bookkeeper auto-recovery is enabled by operator, but its execution frequency, trigger and efficiency is governed by the some configurable properties which need to be tuned to decide how long we want to tolerate data loss before kick starting the recovery process.
Note that the recovery process has its own execution overhead, so we may want to strike a balance between data loss and performance overhead the recovery process would add.
This could also vary from usecase to usecase and hence should be configurable.

For details of Auto Recovery process see: https://bookkeeper.apache.org/docs/4.7.3/admin/autorecovery/#autorecovery

Some Configuration Properties that impact auto-recovery:

auditorPeriodicBookieCheckInterval - The time interval between auditor bookie checks, in seconds. The auditor bookie check, checks ledger metadata to see which bookies should contain entries for each ledger. If a bookie that should contain entries is unavailable, then the ledger containing that entry is marked for recovery. Defaults to once per day.
auditorPeriodicCheckInterval - The time interval, in seconds, at which the auditor will check all ledgers in the cluster. By default this runs once a week. Defaults to once per week.
lostBookieRecoveryDelay - How long to wait, in seconds, before starting autorecovery of a lost bookie. Defaults to 0.
underreplicatedLedgerRecoveryGracePeriod - The grace period (in seconds) for underreplicated ledgers recovery. If ledger is marked underreplicated for more than this period then it will be reported by placementPolicyCheck in Auditor. Setting this to 0 will disable this check. Default is 0.

Missing Cert-Manager Requirement

Description

The readme doesn't list cert-manager as a requirement for deploying with helm. Nor a note to deploy a cert to get the operator working.

Install silently fails as a result.

Importance

Should have

Location

Readme

Suggestions for an improvement

Expand instructions.

Bookkeeper Spec parameters for options and jvm options are not updatable at runtime

Description

Currently, changes to JVMOptions and options do not take effect during runtime we need to support those for the user to be able to change these fields on runtime.

Importance

should-have

Location

Bookkeepercluster_controller.go

Suggestions for an improvement

Following improvements are needed

Restructure the reconcile logic and add reconcile for configmap
Allow upgrade for config map for any change in either JVMOption or Option
Change the validation webhook to not allow the changes that are not supported

Tune BK auto-recovery settings with respect to the configuration best suited for Pravega specific use-cases

Description

Ensure the settings related to bookkeeper auto-recovery are fine-tuned to work best with Pravega cluster's use-cases.

Importance

must-have

Location

Moved from pravega-operator: pravega/pravega-operator#235

Suggestions for an improvement

The following are the auto-recovery settings in Bookkeeper which need to be considered:

Auto Recovery Settings

  • autoRecoveryDaemonEnabled
  • digestType
  • passwd
  • enableDigestTypeAutodetection

Placement settings

  • ensemblePlacementPolicy
  • reppDnsResolverClass
  • networkTopologyScriptFileName
  • networkTopologyScriptNumberArgs
  • minNumRacksPerWriteQuorum
  • enforceMinNumRacksPerWriteQuorum

Auditor settings

  • auditorPeriodicBookieCheckInterval
  • auditorPeriodicCheckInterval
  • auditorLedgerVerificationPercentage
  • lostBookieRecoveryDelay
  • storeSystemTimeAsLedgerUnderreplicatedMarkTime

Replication Worker settings

  • rereplicationEntryBatchSize
  • openLedgerRereplicationGracePeriod
  • rwRereplicateBackoffMs

BK upgrade fails when cluster is deployed in default ns and operator in non-default ns

Description

Bookkeeper cluster upgrade fails with the following error message when the bookkeeper cluster and bookkeeper operator are deployed in different namespaces

Message: configmaps "bk-pravega-bk-bookie" is forbidden: User "system:serviceaccount:new:bookkeeper-operator" cannot update resource "configmaps" in API group "" in the namespace "default"

Importance

must-have

Bookkeeper operator fails to install when used as a Helm dependency

Description

When specified as a dependency of a Helm chart, the Bookkeeper Operator fails to install due to CRD's not being installed.

apiVersion: v2
name: my-name
description: My description
type: application
version: 0.1.0
appVersion: 0.1.0
dependencies:
  - name: bookkeeper
    version: "0.7.1"
    repository: "https://charts.pravega.io"
  - name: bookkeeper-operator
    version: "0.1.3"
    repository: "https://charts.pravega.io"
...

Helm cannot find the relevant CRD's because they have not yet been installed, so fails with the following error:

Error: unable to build kubernetes objects from release manifest: [unable to recognize "": no matches for kind "BookkeeperCluster" in version "bookkeeper.pravega.io/v1alpha1", unable to recognize "": no matches for kind "PravegaCluster" in version "pravega.pravega.io/v1beta1", unable to recognize "": no matches for kind "ZookeeperCluster" in version "zookeeper.pravega.io/v1beta1"]

The CRD template file has the conditional statement which prevents kubectl apply -f https://raw.githubusercontent.com/pravega/bookkeeper-operator/master/charts/bookkeeper-operator/templates/bookkeeper.pravega.io_bookkeeperclusters_crd.yaml:

error: error parsing https://raw.githubusercontent.com/pravega/bookkeeper-operator/master/charts/bookkeeper-operator/templates/bookkeeper.pravega.io_bookkeeperclusters_crd.yaml: json: line 0: invalid character '{' looking for beginning of object key string

This is equally applicable to the Pravega and Zookeeper CRD's - I'll raise separate issues for those.

Importance

This is a must have for packaging Pravega as part of a larger application.

Location

charts/bookkeeper-operator/templates/bookkeeper.pravega.io_bookkeeperclusters_crd.yaml

Suggestions for an improvement

CRD's can be included in a crd directory and Helm will apply these first. The CRD's could also be provided in a separate Helm chart but I wouldn't find this particularly useful due to not being able to specify a dependency application order. https://helm.sh/docs/chart_best_practices/custom_resource_definitions/

Alternatively, the CRD could be provided as a release artefact that can be installed before running Helm with crd.create=false:

kubectl apply -f https://github.com/pravega/bookkeeper-operator/releases/download/0.1.3/bookkeeper-operator.crds.yaml

Bookkeeper chart does not expose logging configs.

Description

Bookkeeper chart currently does not allow users to set bookkeeper logging configs such as levels and logging file appenders, etc.

Importance

must-have

Location

charts/bookkeeper

Suggestions for an improvement

expose chart settings like bookkeeper.logging.level and bookkeeper.logging.appender to set logging behaviour of bookkeeper.

znodes not deleted when bk cluster deployed in non-default namespace

Description

The bookkeeper operator fails to delete metadata from zookeeper pods when the bookkeeper cluster is deployed in a non-default namespace.

Importance

must have

Location

pkg/controller/bookkeepercluster

Suggestions for an improvement

(How do you suggest to fix or proceed with this issue?)

Create charts to install bookkeeper operator and bookkeeper cluster

Description

Currently manual deployment of bookkeeper operator and bookkeeper cluster works. However creating the charts would make the deployment easier.

Importance

must-have

Location

Inside charts directory

Suggestions for an improvement

(How do you suggest to fix or proceed with this issue?)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.