Couchbase v1.0.0 upstream-community-operator install plan fails w/repeat count regexp parsing error

Attempt to create couchbase v1.0.0 upstream-community-operator install plan on OCP 3.11 with latest origin-operator-lifecycle-manager and updated OCP manifests fails w/regexp parsing error below:
 catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"time=\"2019-02-28T11:34:13Z\" level=warning msg=\"no  installplan found with matching manifests, creating new one\" id=6tpyu namespace=couchbase-test\n","stream":"stderr","time":"2019-02-28T11:34:13.042953747Z"} catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"time=\"2019-02-28T11:34:13Z\" level=info msg=syncing  id=6TftZ ip=install-pglww namespace=couchbase-test phase=\n","stream":"stderr","time":"2019-02-28T11:34:13.046178509Z"} catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"time=\"2019-02-28T11:34:13Z\" level=info msg=\"skip p rocessing installplan without status - subscription sync responsible for initial status\" id=6TftZ ip=install-pglww namespace=couchbase-test phase=\n","stream":"stderr","time":"2019-02-28T11:34:13.046203749Z"} catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"time=\"2019-02-28T11:34:13Z\" level=info msg=syncing  id=CAHyk ip=install-pglww namespace=couchbase-test phase=Installing\n","stream":"stderr","time":"2019-02-28T11:34:13.056421992Z"} catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"time=\"2019-02-28T11:34:13Z\" level=info msg=\"retryi ng couchbase-test/install-pglww\"\n","stream":"stderr","time":"2019-02-28T11:34:13.071293187Z"} catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"E0228 11:34:13.071162       1 queueinformer_operator. go:155] Sync \"couchbase-test/install-pglww\" failed: error creating csv couchbase-operator.v1.0.0: an error on the server (\"This request caused apiserver to panic. Look in the logs for details.\") has prevented the r equest from succeeding (post clusterserviceversions.operators.coreos.com)\n","stream":"stderr","time":"2019-02-28T11:34:13.071330938Z"} catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"time=\"2019-02-28T11:34:13Z\" level=info msg=syncing  id=cYJU+ ip=install-pglww namespace=couchbase-test phase=Failed\n","stream":"stderr","time":"2019-02-28T11:34:13.075067324Z"} catalog-operator-75c4bfcf59-j9ctt_openshift-operator-lifecycle-manager_catalog-operator-e1abc73ca1f136694e9069da67db15357d99ba43aa380071365889435a909e7d.log:{"log":"time=\"2019-02-28T11:34:13Z\" level=info msg=syncing  id=JIPHu ip=install-pglww namespace=couchbase-test phase=Failed\n","stream":"stderr","time":"2019-02-28T11:34:13.432394434Z"} master-api-localhost_kube-system_api-7bbb74f5bfa1af0a17cdec93e915657d8951c8e8a2baf5356a8efb8570f00978.log:{"log":"E0228 09:57:01.978287       1 wrap.go:34] apiserver panic'd on POST /apis/operators.coreos.com/v1alpha1/ namespaces/couchbase-test/clusterserviceversions: regexp: Compile(^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$): error parsing regexp: invalid repeat count: {0,16250}\n","stream":"stderr ","time":"2019-02-28T09:57:01.978443885Z"} master-api-localhost_kube-system_api-7bbb74f5bfa1af0a17cdec93e915657d8951c8e8a2baf5356a8efb8570f00978.log:{"log":"E0228 11:16:28.744381       1 wrap.go:34] apiserver panic'd on POST /apis/operators.coreos.com/v1alpha1/ namespaces/couchbase-test/clusterserviceversions: regexp: Compile(^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$): error parsing regexp: invalid repeat count: {0,16250}\n","stream":"stderr ","time":"2019-02-28T11:16:28.74448544Z"} master-api-localhost_kube-system_api-7bbb74f5bfa1af0a17cdec93e915657d8951c8e8a2baf5356a8efb8570f00978.log:{"log":"E0228 11:34:13.062078       1 wrap.go:34] apiserver panic'd on POST /apis/operators.coreos.com/v1alpha1/ namespaces/couchbase-test/clusterserviceversions: regexp: Compile(^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$): error parsing regexp: invalid repeat count: {0,16250}\n","stream":"stderr ","time":"2019-02-28T11:34:13.062193863Z"} master-controllers-localhost_kube-system_controllers-e0756e211ae5e63fcf77f6779c8ccf74f8cd10ca2e43943f71fd9e37addabc64.log:{"log":"E0228 09:48:59.343059       1 namespace_scc_allocation_controller.go:335] error syncing  namespace, it will be retried: Operation cannot be fulfilled on namespaces \"couchbase-test\": the object has been modified; please apply your changes to the latest version and try again\n","stream":"stderr","time":"20 19-02-28T09:48:59.343289485Z"} master-controllers-localhost_kube-system_controllers-e0756e211ae5e63fcf77f6779c8ccf74f8cd10ca2e43943f71fd9e37addabc64.log:{"log":"E0228 09:48:59.375021       1 namespace_scc_allocation_controller.go:335] error syncing  namespace, it will be retried: Operation cannot be fulfilled on namespaces \"couchbase-test\": the object has been modified; please apply your changes to the latest version and try again\n","stream":"stderr","time":"20 19-02-28T09:48:59.375165088Z"} master-controllers-localhost_kube-system_controllers-e0756e211ae5e63fcf77f6779c8ccf74f8cd10ca2e43943f71fd9e37addabc64.log:{"log":"I0228 11:29:10.832636       1 garbagecollector.go:408] processing item [operators.coreos .com/v1alpha1/InstallPlan, namespace: couchbase-test, name: install-z9pwc, uid: 4b3a08ba-3b4a-11e9-a352-024eeff82cec]\n","stream":"stderr","time":"2019-02-28T11:29:10.832848564Z"} master-controllers-localhost_kube-system_controllers-e0756e211ae5e63fcf77f6779c8ccf74f8cd10ca2e43943f71fd9e37addabc64.log:{"log":"I0228 11:29:10.842575       1 garbagecollector.go:521] delete object [operators.coreos.c om/v1alpha1/InstallPlan, namespace: couchbase-test, name: install-z9pwc, uid: 4b3a08ba-3b4a-11e9-a352-024eeff82cec] with propagation policy Background\n","stream":"stderr","time":"2019-02-28T11:29:10.842734206Z"} [root@ containers]#

What version of OLM is running? Also, if you're on 3.11 I'm guessing you aren't using Operator Hub to install the operator, so what steps are you following to install the operator?

I'm running OLM ocp/0.8.1 with a few manifest patches to work-around already reported issues including replacement of coreos/olm with openshift/origin-operator-lifecycle-manager:latest from last night. I'm also using the upstream-community-operators image built via https://github.com/operator-framework/community-operators/blob/master/upstream.Dockerfile. Finally, I'm running OCP 3.11.82.
The Web UI is not fully functional and as you mentioned no Operator Hub support. But the command-line seems to be working as expected other than this reported issue. I attempted to install the Couchbase operator using the OCP 3.11 OLM command-line instructions.

My attempt to create an etcd upstream-community-operators subscription fails with the same stack trace as the couchbase operator. The relevant master-api log is included below. Your feedback is much appreciated.
{"log":"I0301 11:15:29.732959       1 controller.go:597] quota admission added evaluator for: {operators.coreos.com subscriptions}\n","stream":"stderr","time":"2019-03-01T11:15:29.733119366Z"}
{"log":"I0301 11:15:29.733352       1 controller.go:597] quota admission added evaluator for: {operators.coreos.com subscriptions}\n","stream":"stderr","time":"2019-03-01T11:15:29.733448479Z"}
{"log":"I0301 11:15:29.752359       1 controller.go:597] quota admission added evaluator for: {operators.coreos.com installplans}\n","stream":"stderr","time":"2019-03-01T11:15:29.752524714Z"}
{"log":"I0301 11:15:29.752842       1 controller.go:597] quota admission added evaluator for: {operators.coreos.com installplans}\n","stream":"stderr","time":"2019-03-01T11:15:29.752948069Z"}
{"log":"I0301 11:15:29.783782       1 controller.go:597] quota admission added evaluator for: {operators.coreos.com clusterserviceversions}\n","stream":"stderr","time":"2019-03-01T11:15:29.783955897Z"}
{"log":"E0301 11:15:29.784341       1 runtime.go:66] Observed a panic: \"regexp: Compile(`^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$`): error parsing regexp: invalid repeat count: `{0,16250}`\" (regexp: Compile(`^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$`): error parsing regexp: invalid repeat count: `{0,16250}`)\n","stream":"stderr","time":"2019-03-01T11:15:29.78447938Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:72\n","stream":"stderr","time":"2019-03-01T11:15:29.784495821Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:65\n","stream":"stderr","time":"2019-03-01T11:15:29.784501891Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:51\n","stream":"stderr","time":"2019-03-01T11:15:29.784506721Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/asm_amd64.s:573\n","stream":"stderr","time":"2019-03-01T11:15:29.784510541Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/panic.go:502\n","stream":"stderr","time":"2019-03-01T11:15:29.784513861Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/regexp/regexp.go:240\n","stream":"stderr","time":"2019-03-01T11:15:29.784517021Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/values.go:142\n","stream":"stderr","time":"2019-03-01T11:15:29.784520101Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/validator.go:587\n","stream":"stderr","time":"2019-03-01T11:15:29.784523241Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/schema.go:139\n","stream":"stderr","time":"2019-03-01T11:15:29.784526301Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/object_validator.go:142\n","stream":"stderr","time":"2019-03-01T11:15:29.784529361Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/schema.go:139\n","stream":"stderr","time":"2019-03-01T11:15:29.784533011Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/slice_validator.go:61\n","stream":"stderr","time":"2019-03-01T11:15:29.784536311Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/schema.go:139\n","stream":"stderr","time":"2019-03-01T11:15:29.784544881Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/object_validator.go:142\n","stream":"stderr","time":"2019-03-01T11:15:29.784548241Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/schema.go:139\n","stream":"stderr","time":"2019-03-01T11:15:29.784551381Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/object_validator.go:142\n","stream":"stderr","time":"2019-03-01T11:15:29.784554382Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/github.com/go-openapi/validate/schema.go:139\n","stream":"stderr","time":"2019-03-01T11:15:29.784557421Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiextensions-apiserver/pkg/apiserver/validation/validation.go:46\n","stream":"stderr","time":"2019-03-01T11:15:29.784560451Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiextensions-apiserver/pkg/registry/customresource/validator.go:62\n","stream":"stderr","time":"2019-03-01T11:15:29.784563681Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiextensions-apiserver/pkg/registry/customresource/strategy.go:131\n","stream":"stderr","time":"2019-03-01T11:15:29.784567141Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/registry/rest/create.go:103\n","stream":"stderr","time":"2019-03-01T11:15:29.784570212Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/registry/generic/registry/store.go:326\n","stream":"stderr","time":"2019-03-01T11:15:29.784573251Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/registry/generic/registry/store.go:326\n","stream":"stderr","time":"2019-03-01T11:15:29.784576401Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/endpoints/handlers/create.go:174\n","stream":"stderr","time":"2019-03-01T11:15:29.784579382Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/endpoints/handlers/create.go:118\n","stream":"stderr","time":"2019-03-01T11:15:29.784582761Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/endpoints/handlers/rest.go:183\n","stream":"stderr","time":"2019-03-01T11:15:29.784585851Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/asm_amd64.s:2361\n","stream":"stderr","time":"2019-03-01T11:15:29.784588922Z"}
{"log":"E0301 11:15:29.784618       1 runtime.go:66] Observed a panic: \"regexp: Compile(`^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$`): error parsing regexp: invalid repeat count: `{0,16250}`\" (regexp: Compile(`^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$`): error parsing regexp: invalid repeat count: `{0,16250}`)\n","stream":"stderr","time":"2019-03-01T11:15:29.788415111Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:72\n","stream":"stderr","time":"2019-03-01T11:15:29.788429571Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:65\n","stream":"stderr","time":"2019-03-01T11:15:29.788440151Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:51\n","stream":"stderr","time":"2019-03-01T11:15:29.788445381Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/asm_amd64.s:573\n","stream":"stderr","time":"2019-03-01T11:15:29.788449741Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/panic.go:502\n","stream":"stderr","time":"2019-03-01T11:15:29.788453261Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters/timeout.go:105\n","stream":"stderr","time":"2019-03-01T11:15:29.788456602Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters/waitgroup.go:47\n","stream":"stderr","time":"2019-03-01T11:15:29.788460031Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788463631Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/endpoints/filters/requestinfo.go:39\n","stream":"stderr","time":"2019-03-01T11:15:29.788467321Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788470751Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters/wrap.go:41\n","stream":"stderr","time":"2019-03-01T11:15:29.788474011Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788477401Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/handlers.go:140\n","stream":"stderr","time":"2019-03-01T11:15:29.788481512Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788485171Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-apiserver/openshiftapiserver/configprocessing/cachecontrol.go:33\n","stream":"stderr","time":"2019-03-01T11:15:29.788488381Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788492332Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/webconsole_proxy.go:39\n","stream":"stderr","time":"2019-03-01T11:15:29.788495562Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788499041Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/webconsole_proxy.go:49\n","stream":"stderr","time":"2019-03-01T11:15:29.788502452Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788505852Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/patch_handlerchain.go:103\n","stream":"stderr","time":"2019-03-01T11:15:29.788509071Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947\n","stream":"stderr","time":"2019-03-01T11:15:29.788515402Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/handler.go:189\n","stream":"stderr","time":"2019-03-01T11:15:29.788519261Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:2694\n","stream":"stderr","time":"2019-03-01T11:15:29.788522562Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:3260\n","stream":"stderr","time":"2019-03-01T11:15:29.788525912Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/h2_bundle.go:5475\n","stream":"stderr","time":"2019-03-01T11:15:29.788529171Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/golang.org/x/net/http2/server.go:2053\n","stream":"stderr","time":"2019-03-01T11:15:29.788532392Z"}
{"log":"/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/golang.org/x/net/http2/server.go:2053\n","stream":"stderr","time":"2019-03-01T11:15:29.788535702Z"}
{"log":"/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/asm_amd64.s:2361\n","stream":"stderr","time":"2019-03-01T11:15:29.788539001Z"}
{"log":"E0301 11:15:29.785119       1 wrap.go:34] apiserver panic'd on POST /apis/operators.coreos.com/v1alpha1/namespaces/my-etcd/clusterserviceversions: regexp: Compile(`^(?:[A-Za-z0-9+/]{4}){0,16250}(?:[A-Za-z0-9+/]{2}==|[A-Za-z0-9+/]{3}=)?$`): error parsing regexp: invalid repeat count: `{0,16250}`\n","stream":"stderr","time":"2019-03-01T11:15:29.788543152Z"}
{"log":"goroutine 985186 [running]:\n","stream":"stderr","time":"2019-03-01T11:15:29.788547882Z"}
{"log":"runtime/debug.Stack(0x7830f60, 0xc429ce9960, 0x530dfbe)\n","stream":"stderr","time":"2019-03-01T11:15:29.788552032Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/debug/stack.go:24 +0xa7\n","stream":"stderr","time":"2019-03-01T11:15:29.788556112Z"}
{"log":"github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters.WithPanicRecovery.func1.1(0x4476a80, 0xc42cc3cd90)\n","stream":"stderr","time":"2019-03-01T11:15:29.788561112Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters/wrap.go:34 +0x74\n","stream":"stderr","time":"2019-03-01T11:15:29.788565632Z"}
{"log":"github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime.HandleCrash(0xc434f79910, 0x1, 0x1)\n","stream":"stderr","time":"2019-03-01T11:15:29.788571172Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apimachinery/pkg/util/runtime/runtime.go:54 +0xc7\n","stream":"stderr","time":"2019-03-01T11:15:29.788575012Z"}
{"log":"panic(0x4476a80, 0xc42cc3cd90)\n","stream":"stderr","time":"2019-03-01T11:15:29.788579113Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/runtime/panic.go:502 +0x229\n","stream":"stderr","time":"2019-03-01T11:15:29.788583432Z"}
{"log":"github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters.(*timeoutHandler).ServeHTTP(0xc42bf913a0, 0x7830f60, 0xc429ce9960, 0xc42c7a1a00)\n","stream":"stderr","time":"2019-03-01T11:15:29.788587472Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters/timeout.go:105 +0x404\n","stream":"stderr","time":"2019-03-01T11:15:29.788591342Z"}
{"log":"github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters.WithWaitGroup.func1(0x7830f60, 0xc429ce9960, 0xc42c7a1900)\n","stream":"stderr","time":"2019-03-01T11:15:29.788596682Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters/waitgroup.go:47 +0xd4\n","stream":"stderr","time":"2019-03-01T11:15:29.788601362Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc428efd3e0, 0x7830f60, 0xc429ce9960, 0xc42c7a1900)\n","stream":"stderr","time":"2019-03-01T11:15:29.788609583Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788613903Z"}
{"log":"github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/endpoints/filters.WithRequestInfo.func1(0x7830f60, 0xc429ce9960, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788619133Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/endpoints/filters/requestinfo.go:39 +0x181\n","stream":"stderr","time":"2019-03-01T11:15:29.788623973Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc428efd410, 0x7830f60, 0xc429ce9960, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788628473Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788632702Z"}
{"log":"github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters.WithPanicRecovery.func1(0x7830f60, 0xc429ce9960, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788637342Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/filters/wrap.go:41 +0x108\n","stream":"stderr","time":"2019-03-01T11:15:29.788641542Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc42bf913c0, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788646272Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788651163Z"}
{"log":"github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver.translateLegacyScopeImpersonation.func1(0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788655333Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/handlers.go:140 +0x264\n","stream":"stderr","time":"2019-03-01T11:15:29.788659703Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc42bf913e0, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788664343Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788668383Z"}
{"log":"github.com/openshift/origin/pkg/cmd/openshift-apiserver/openshiftapiserver/configprocessing.WithCacheControl.func1(0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788672532Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-apiserver/openshiftapiserver/configprocessing/cachecontrol.go:33 +0x1d7\n","stream":"stderr","time":"2019-03-01T11:15:29.788677543Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc428efd440, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788682112Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788686193Z"}
{"log":"github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver.withAssetServerRedirect.func1(0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788691253Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/webconsole_proxy.go:39 +0x6f\n","stream":"stderr","time":"2019-03-01T11:15:29.788695643Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc42bf91400, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788704673Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788709163Z"}
{"log":"github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver.withConsoleRedirection.func1(0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788713323Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/webconsole_proxy.go:49 +0x1a7\n","stream":"stderr","time":"2019-03-01T11:15:29.788717863Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc428efd470, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788722344Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788726543Z"}
{"log":"github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver.WithPatternPrefixHandler.func1(0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788731143Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/pkg/cmd/openshift-kube-apiserver/openshiftkubeapiserver/patch_handlerchain.go:103 +0x12e\n","stream":"stderr","time":"2019-03-01T11:15:29.788735773Z"}
{"log":"net/http.HandlerFunc.ServeHTTP(0xc428084f40, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788739873Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:1947 +0x44\n","stream":"stderr","time":"2019-03-01T11:15:29.788744133Z"}
{"log":"github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server.(*APIServerHandler).ServeHTTP(0xc428efd4d0, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788748963Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/k8s.io/apiserver/pkg/server/handler.go:189 +0x51\n","stream":"stderr","time":"2019-03-01T11:15:29.788753424Z"}
{"log":"net/http.serverHandler.ServeHTTP(0xc42a400000, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788758114Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:2694 +0xbc\n","stream":"stderr","time":"2019-03-01T11:15:29.788762654Z"}
{"log":"net/http.initNPNRequest.ServeHTTP(0xc439904a80, 0xc42a400000, 0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788766714Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/server.go:3260 +0x9a\n","stream":"stderr","time":"2019-03-01T11:15:29.788771534Z"}
{"log":"net/http.(Handler).ServeHTTP-fm(0x78267e0, 0xc4381e9de0, 0xc42c7a1800)\n","stream":"stderr","time":"2019-03-01T11:15:29.788775853Z"}
{"log":"\u0009/opt/rh/go-toolset-1.10/root/usr/lib/go-toolset-1.10-golang/src/net/http/h2_bundle.go:5475 +0x4d\n","stream":"stderr","time":"2019-03-01T11:15:29.788779793Z"}
{"log":"github.com/openshift/origin/vendor/golang.org/x/net/http2.(*serverConn).runHandler(0xc4317de1c0, 0xc4381e9de0, 0xc42c7a1800, 0xc42dc90ae0)\n","stream":"stderr","time":"2019-03-01T11:15:29.788783494Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/golang.org/x/net/http2/server.go:2053 +0x89\n","stream":"stderr","time":"2019-03-01T11:15:29.788787404Z"}
{"log":"created by github.com/openshift/origin/vendor/golang.org/x/net/http2.(*serverConn).processHeaders\n","stream":"stderr","time":"2019-03-01T11:15:29.788790874Z"}
{"log":"\u0009/builddir/build/BUILD/atomic-openshift-git-0.08bc31b/_output/local/go/src/github.com/openshift/origin/vendor/golang.org/x/net/http2/server.go:1787 +0x46b\n","stream":"stderr","time":"2019-03-01T11:15:29.788794114Z"}
{"log":"\n","stream":"stderr","time":"2019-03-01T11:15:29.788800534Z"}

Moving issue to OLM since it is not operator specific


.NET Standard 2.0 compatibility for ParallelExtensionsExtras

I propose downgrading ParallelExtensionsExtras to C# 7.3/.NET Standard 2.0 for the following reason:
UWP is in the dark ages and currently is restricted to no newer than .NET Std 2.0. There is hope that it will get a bump to a newer version in the future https://github.com/dotnet/standard/issues/1567, but as things stand right now .NET Std 2.0 is the way to go with no ETA for improvements.
This is particularly important for store apps and Xbox Creators Program apps (not Native).
A quick build test indicates that there are only 3 places in the code that use the new language features - two using declarations and a pattern match, which are relatively easily downgraded as per this experiment: https://github.com/Jaegermeiste/ParallelExtensionsExtras/commit/947bf6376a6977739a2d04c8bd5705b41efff172
Forgive any errors I may have made in unrolling the new syntax to the older - in any case I think the fundamental point of this Issue remains valid.
Is there any interest in this? Any particular reason to enforce 2.1 vs 2.0 that makes this a truly Bad Idea?

This should also ensure compatibility with legacy Framework applications  https://docs.microsoft.com/en-us/dotnet/standard/net-standard and Unity https://forum.unity.com/threads/net-standard-2-1.757007/


Link to Probabilistically Bounded Staleness (PBS) metric needs updating

The link (https://pbs.cs.berkeley.edu/) in the Monitor Probabilistically Bounded Staleness (PBS) metric section needs to be updated as it now redirects to https://adept.eecs.berkeley.edu/ which is incorrect.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 30408ba6-333d-6fe5-0df2-e545f6422ba4
Version Independent ID: 7fccbe15-a6f4-7777-293b-ff6d105567c5
Content: Manage consistency in Azure Cosmos DB
Content Source: articles/cosmos-db/sql/how-to-manage-consistency.md
Service: cosmos-db
Sub-service: cosmosdb-sql
GitHub Login: @markjbrown
Microsoft Alias: mjbrown

@griffinbird Thank you for the feedback. We are actively investigating and will get back to you soon.

@griffinbird Thanks for reporting this issue. We have made the changes through a PR which could take few days to go live.
We will now proceed to close this thread. If there are further questions regarding this matter, please comment and we will gladly continue the discussion.


Mitigates CVE-2021-45046

Need to update the dependency version, or to filter by using 'formatMsgNoLookups'.
This vulnerability isn't strickly easy to exploit, but an EVCC can send this encoded payload to the EVSE, and trigger the bug during even in the first supportedAppProtocolReq state:
80027123DB53732349D363230B81D1797BC123DB437B9BA2730B6B2BE97261A2517199B33BC98B0B9B6B09B311BB119B198BBBD3B3CB33B9B38BA9731B0B730B93CBA37B5B2B7399731B7B697B0BE8020000280040

There is 2.17.1 already in https://github.com/SwitchEV/RISE-V2G/blob/master/RISE-V2G-Shared/pom.xml
	<dependency>
	    <groupId>org.apache.logging.log4j</groupId>
	    <artifactId>log4j-api</artifactId>
	    <version>2.17.1</version>
	</dependency>
	<dependency>
	    <groupId>org.apache.logging.log4j</groupId>
	    <artifactId>log4j-core</artifactId>
	    <version>2.17.1</version>
	</dependency>


Fix vite href for nested entry points

In the case where there are entry points not in the root, the link href is not correct.

Adds relative path handling for entry points in folders and nested folders
Adds examples for entry point in folder and subfolder

Hey @Applelo wondering if I could ping you for a review. 🙏🏼

I was on vacation eating pastas and pizzas. I look into it asap.


ValueError when trying to encode time variable in a NetCDF file with CF convensions

# Imports
import numpy as np
import xarray as xr
import pandas as pd
from glob import glob

# files to be concatenated
files = sorted(glob(path + str(1988) + '/V250*'))
# corrected dates
dates = pd.date_range(start=str(yr), end=str(yr+1), freq='6H', closed='left')

ds_test = xr.open_mfdataset(files[:10], combine='nested', concat_dim='time', decode_cf=False)
# correcting time
ds_test.time.values=dates[:10]
# fixing encoding
ds_test.time.attrs['units'] = "Seconds since 1970-01-01 00:00:00"

# preview of the time variable
print(ds_test.time)

> <xarray.DataArray 'time' (time: 10)>
array(['1988-01-01T00:00:00.000000000', '1988-01-01T06:00:00.000000000',
       '1988-01-01T12:00:00.000000000', '1988-01-01T18:00:00.000000000',
       '1988-01-02T00:00:00.000000000', '1988-01-02T06:00:00.000000000',
       '1988-01-02T12:00:00.000000000', '1988-01-02T18:00:00.000000000',
       '1988-01-03T00:00:00.000000000', '1988-01-03T06:00:00.000000000'],
      dtype='datetime64[ns]')
Coordinates:
  * time     (time) datetime64[ns] 1988-01-01 ... 1988-01-03T06:00:00
Attributes:
    calendar:       proleptic_gregorian
    standard_name:  time
    units:          Seconds since 1970-01-01 00:00:00

ds_test.to_netcdf(path+'test.nc')

>ValueError: failed to prevent overwriting existing key units in attrs on variable 'time'.
 This is probably an encoding field used by xarray to describe how a variable is serialized.
To proceed, remove this key from the variable's attributes manually.

Expected Output
Correctly encode time such that it saves the file by correctly converting value of time according to the reference units. I have the flexibility of dropping CF-conventions as long as time values are correct but it would also be nice to have a solution which keeps the CF-conventions intact.
Problem Description
I'm trying to concatenate netcdf files which have CF conventions mentioned in their global attributes. These files have an incorrect time dimension which I try to fix with the code above.  It seems that some existing encoding is preventing from writing the files back. But when I print the encoding, it doesn't show any such clashing units. I'm not sure if this is a bug or a wrong usage issue. Thus, any usage help on how to correctly encode time such that it saves the time values by correctly converting according to the reference units is much appreciated.
# More diagnostics on the encoding
print(ds_test.encoding)
>{'unlimited_dims': {'time'},
 'source': '/file/to/path/V250_19880101_00'}

# checking any existing time
print(ds_test.time.encoding)
>{}

# another try on setting time encoding
ds_test.time.encoding['units'] = "Seconds since 1970-01-01 00:00:00"
# writing the file gives the same ValueError as above
ds_test.to_netcdf(path+'test.nc')

# ncdump output of one of the files
>netcdf V250_19880101_06 {
dimensions:
	lon = 720 ;
	lat = 361 ;
	lev = 1 ;
	time = UNLIMITED ; // (1 currently)
variables:
	float lon(lon) ;
		lon:long_name = "longitude" ;
		lon:units = "degrees_east" ;
		lon:standard_name = "longitude" ;
		lon:axis = "X" ;
	float lat(lat) ;
		lat:long_name = "latitude" ;
		lat:units = "degrees_north" ;
		lat:standard_name = "latitude" ;
		lat:axis = "Y" ;
	float lev(lev) ;
		lev:long_name = "hybrid level at layer midpoints" ;
		lev:units = "level" ;
		lev:standard_name = "hybrid_sigma_pressure" ;
		lev:positive = "down" ;
		lev:formula = "hyam hybm (mlev=hyam+hybm*aps)" ;
		lev:formula_terms = "ap: hyam b: hybm ps: aps" ;
	float time(time) ;
		time:units = "hours since 1988-01-01 06:00:00" ;
		time:calendar = "proleptic_gregorian" ;
		time:standard_name = "time" ;
	float V(time, lev, lat, lon) ;
		V:long_name = "unknown (please add with NCO)" ;
		V:units = "unknown (please add with NCO)" ;
		V:_FillValue = -999.99f ;

// global attributes:
		:Conventions = "CF" ;
		:constants_file_name = "P19880101_06" ;
		:institution = "IACETH" ;
		:lonmin = -180.f ;
		:lonmax = 179.5f ;
		:latmin = -90.f ;
		:latmax = 90.f ;
		:levmin = 250.f ;
		:levmax = 250.f ;
		:history = "Fri Sep  6 15:59:17 2019: ncatted -a units,time,o,c,hours since 1988-01-01 06:00:00 -a standard_name,time,o,c,time V250_19880101_06" ;
		:NCO = "4.7.2" ;
data:

 time = 6 ;
}

Output of xr.show_versions()

INSTALLED VERSIONS
------------------
commit: None
python: 3.7.4 (default, Aug 13 2019, 20:35:49)
[GCC 7.3.0]
python-bits: 64
OS: Linux
OS-release: 5.0.0-23-generic
machine: x86_64
processor: x86_64
byteorder: little
LC_ALL: None
LANG: en_US.UTF-8
LOCALE: en_US.UTF-8
libhdf5: 1.10.4
libnetcdf: 4.6.1
xarray: 0.13.0
pandas: 0.25.3
numpy: 1.18.1
scipy: 1.3.2
netCDF4: 1.4.2
pydap: None
h5netcdf: None
h5py: None
Nio: None
zarr: None
cftime: <IP_ADDRESS>
nc_time_axis: None
PseudoNetCDF: None
rasterio: None
cfgrib: None
iris: None
bottleneck: None
dask: 2.9.2
distributed: 2.9.3
matplotlib: 3.1.0
cartopy: 0.17.0
seaborn: 0.9.0
numbagg: None
setuptools: 44.0.0.post20200106
pip: 19.3.1
conda: None
pytest: None
IPython: 7.11.1
sphinx: None

hey,avatar, thanks for your examples. I'm wondering that problem has figured out or not .   I have met the same problem.
I'm appreciated for any help.

The following works (using assign_coords() instead of time.values=). I think you also forgot a str in date_range.
import numpy as np
import xarray as xr
import pandas as pd

files = ['ds_1.nc', 'ds_2.nc']

ds_test = xr.open_mfdataset(files, combine='nested', concat_dim='time', decode_cf=False)
yr = 1988 # year
dates = pd.date_range(start=str(yr), end=str(yr+1), freq='6H', closed='left')
ds_test.assign_coords(time=dates[:2])
ds_test.time.encoding['units'] = "seconds since 1970-01-01 00:00:00"
ds_test.time.encoding['calendar'] = "proleptic_gregorian"
ds_test.to_netcdf('ds_1_2.nc')

The following works as well:
ds_test = xr.open_mfdataset(files, combine='nested', concat_dim='time')
ds_test.time.encoding['units'] = "seconds since 1970-01-01 00:00:00"
ds_test.to_netcdf('ds_1_2.nc')

However, what does indeed not work is the following
ds_test = xr.open_mfdataset(files, combine='nested', concat_dim='time')
ds_test.time.attrs['units'] = "seconds since 1970-01-01 00:00:00"
ds_test.to_netcdf('ds_1_2.nc')

which I don't entirely understand, because ds_test.time.encoding is empty. So maybe there is an encoding hidden somewhere, but I couldn't find it.

I was receiving this same error when converting a pandas dataframe's time strings to datetime using:
df['TIME'] = pd.to_datetime(df['index'] + ' ' + df['t']) #index contains date at t contained time
df = df.set_index(['TIME'])
and then converting to dataset using:
dxr = df.to_xarray()
dxr.TIME.attrs['units'] = 'Days since 1950-01-01 00:00:00 UTC'
dxr.to_netcdf('DT_NetCDF.nc')
which resulted in the error:
ValueError: failed to prevent overwriting existing key units in attrs on variable 'TIME'. This is probably an encoding field used by xarray to describe how a variable is serialized. To proceed, remove this key from the variable's attributes manually
To correct the datetime encoding and allow for the netcdf to be written using dxr.to_netcdf I included the utc arg in pd.to_datetime:
df['TIME'] = pd.to_datetime(df['index'] + ' ' + df['t'], utc = True)
Apologies that this does not address the OP's issue directly though there may be some workaround using a similar function (or others receiving the same error code while trying to get CF compliant netcdfs to work).

@mathause
thanks for your suggestions. Your first solution works fine for correcting the time data stored in the array. I also don't understand why ds_test.time.encoding is empty and yet, its the reason for an error while saving it. Maybe its a bug?
@Chan-Jer  Another work around which I used was to set the correct time value using cdo's settime function.

I got a similar error message when opening a Zarr store with datetime64 time values, where I tried to set the "calendar" attribute on the time axis (the attribute was unset in the original store).   I've found some xarray code that appears to treat the "calendar" and "units" time attributes as special, and it essentially prevents users from setting or changing these values, even when those values are not present:
From xarray/coding/times.py:
class CFDatetimeCoder(VariableCoder):
    def __init__(self, use_cftime=None):
        self.use_cftime = use_cftime

    def encode(self, variable, name=None):
        dims, data, attrs, encoding = unpack_for_encoding(variable)
        if np.issubdtype(data.dtype, np.datetime64) or contains_cftime_datetimes(
            variable
        ):
            (data, units, calendar) = encode_cf_datetime(
                data, encoding.pop("units", None), encoding.pop("calendar", None)
            )
            safe_setitem(attrs, "units", units, name=name)
            safe_setitem(attrs, "calendar", calendar, name=name)

        return Variable(dims, data, attrs, encoding)

The initial issue seems to be sorted out, by overwriting/setting the needed keys in encoding instead of attrs. If you still have issues with this, please open a new issue with MCVE. Thanks!


Contract caller of equip can cause unequipped items to be lost

Currently, when equipping to a slot that is already occupied, the inventory contract makes an internal _unequip call. If the equip operation was initiated by a contract which the NFT is staked to, then the unequipped item is return to the staking contract rather than the NFT owner. This issue is similar to what ERC721 solved with IERC721Receiver.onERC721Received.

Discussed this a bit more in the Inventory group. We considered allowing a callback function to be passed to equip, but rejected this idea due to security concerns related to elevated permissions potentially granted to Inventory. What we landed on was a safeEquip (similar to safeTransferFrom on erc721). This will allow contract clients of the Inventory to handle the assets that are potentially orphaned by equipping over top of an existing item.

@zcstarr Did I miss anything important from our discussion yesterday?

I think this nails it, the other consideration that pushed us towards this is that more people will use smart contract accounts in the future so that rules out automatic detection of EOA vs. smart contract code.
So this will give people the option of choosing the option that works for their ecosystem, either you implement the callback at the address and call safeEquip, or you don't because you don't need to .


Thoughts on testing strategy

Should this repo encourage a certain way of unit/integration testing? Should this be documented in the README? Since the goal seems to be to have an opinionated view into express server development it could be in place.
Here are some thoughts on the topic:
Integration tests
In the repository this example is inspired by, all tests are really integration tests and there are no real unit tests. As in any API test will have to

Spin up the server
Seed the database
Call an API and evaluate response

and during this operation we have many other imported functions and database queries that have to work perfectly together. There is nothing wrong with this per-se (even though maybe it could be improved or simplified), but it could be argued that those type of tests should be moved under the integration tests folder
Unit testing
There could be a way to split every task into a separate unit-testable function and take testing "as close to iron as possible". This would include

Testing any functionality, be that a API provider or a service as a simple function with an input, output and maybe side effects
Mock all dependencies and other used functions
Mock all possible inputs (like request or response objects)
Test for valid outputs
Test for side effects and that external function calls have been called with proper parameters

In a OOP paradigm this is rather simple to achieve with something like
// mocks
classInstance.doTaskB = jest.fn()
// run function
const returnValue =classInstance.toTaskAAndCallB()
// evaluate response
expect(returnValue).toEqual(something)
expect(classInstance.doTaskB).toHaveBeenCalledWith(something)

This can be more tricky for functional programming, but there are ways such as import mocking
discussed here
This will require some thinking to accomplish, but if we were to do this we should accomplish easy to write and maintain unit tests for the project.

Agreed, I believe I have an example test in each folder for unit and integration tests. The integration tests run the familiar supertest against the express app.js, while the the unit test folder so far only tests service functions in the services folder. I don't want to encourage overtesting, so my thinking right now is that for the most part integration tests are most useful against the apis (does this api do what I expect) and unit tests are most useful against service/utility functions (does this function return what I expect)

My broader point on the testing strategy might need some playing around. I might propose this later again once I schedule some time to test it myself.


Fix ProjectN build break

We need to specify SkipImportRoslynProps because we don't want to include the props file from a bogus file path below, but we do want the 8.0 LangVersion treatment in ProjectN. Since this line is temporary until Roslyn decides that 8.0 is in fact the latest version, I don't feel too bad about this.

@MattGal would it be possible to roll back the WASM machines again? We're hitting the emsdk issue again :(.

@MichalStrehovsky done, sorry about that!  We're hoping to have the machines fixed soon, it's just been a giant list of weird problems to fix the image.

Thank you!


carp can rotate thrusters

Description
real

funny

not funny when a carp turns all the thrusters around and murders a family who cant escape


[Feature] Extending sorting functionality for list with string elements

Sorting lists with string elements
Resolves: #636
What's Changed:
Nothing modified, or breaking changes. Sort functionality is now extended to sort the list of strings also.
(not supports heterotypic lists).

Type of Change:

[ ] Bug fix
[ x] New feature
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)

Housekeeping:

[x ] Tests have been updated to reflect the changes done within this PR (if applicable).
[ x] Documentation has been updated to reflect the changes done within this PR (if applicable).

Screenshots (If Applicable):

Thanks for this!


Traditional Chinese translation

As a native speaker of Simplified Chinese there has to be a lot of mistakes and misuse of words in this translation, but in the current version of this PR it's perfect for Simplified Chinese speakers to understand.
Feel free to contribute actual Trad. Chinese translation over this one.

Should update this with the new better server browser localisation

Updated with the merged server browser build.

Updated with the merged server browser build.

Have you tested this successfully in-game? For some reason portuguese, german and tradicional chinese are defaulting to english translations.

請問如何更改語言，貌似我用了不行

遊戲安裝繁體中文試試

遊戲安裝繁體中文試試

欸豆，痾，我是裝繁體的欸，還是是我安裝問題?

Have you tested this successfully in-game? For some reason portuguese, german and tradicional chinese are defaulting to english translations.

It seems to be encoding format problem, these localization files all using UTF-8 instead of UTF-16 LE

weird, northstarcn repo uses utf-8 and it works fine

Have you tested this successfully in-game? For some reason portuguese, german and tradicional chinese are defaulting to english translations.

It seems to be encoding format problem, these localization files all using UTF-8 instead of UTF-16 LE
You're right, I got portuguese and german working by converting to UTF-16 LE. I'll convert the rest and add this notice to the wiki. Thanks.

@zestybaby can you reencode this file so I can merge?

tip: check if the git setting core.auto_crlf=true is causing issues (its default on windows and sometimes it can cause issues with some files)

@abarichello Updated as requested, sorry for the inconvenience.

@abarichello Updated as requested, sorry for the inconvenience.

No problem, merged through the command line at: https://github.com/R2Northstar/NorthstarMods/commit/0a2978236c1557a08ae41bffa13c81909b2bd106.
Thanks!


Improvement: Allow OpenAPI Event Bus address to be specified for an entire API tag

Describe the feature
it occurs to me that the way in which RouterBuilder.mountServicesFromExtensions() functions may not be "optimal". Right now, each operation can have a different eventbus address, but in practice that makes no sense. Operations would be associated with a Tag/API grouping, and as such would likely use the same eventbus address for the whole Tag/API group.
For example, when I instantiate my services and bind them, it's binding a whole API and not individual operations.
Seems like it would make more sense to have the evenbus address associated with the Tag definition in OpenAPI Spec. Kinda like:
---
openapi: 3.0.2
info:
  title: My App
  version: 1.0.0
  description: My Application
servers:
  ## SNIP . . .
tags:
  - name: system
    x-vertx-event-bus: services.system
  - name: bills
    x-vertx-event-bus: services.bills
  - name: income
    x-vertx-event-bus: services.income
  - name: cashflow
    x-vertx-event-bus: services.cashflow

I believe this could be implemented in addition to the existing functionality in order to maintain backward compatibility and allow for additional flexibility.
Use cases
This will enhance the ability of Vert.x to be the bases for low-code API implementations based on OpenAPI contracts.
Contribution
I will work with @pmlopes to help implement this improvement.

So, if understand it right, you would prefer to not see all the repetition we currently have:
openapi: 3.0.0
info:
  version: 1.0.0
  title: Test spec for OpenAPI3ServiceProxiesTest
  license:
    name: Apache 2.0 License
paths:
  /testC:
    post:
      operationId: test_ -C_
      tags:
        - anotherTest
      x-vertx-event-bus:
        address: anotherAddress
        method: testC
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/Payload"
      responses:
        200:
          description: ok
  /testD:
    post:
      operationId: testD
      tags:
        - anotherTest
      x-vertx-event-bus:
        address: anotherAddress
        method: testD
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/Payload"
      responses:
        200:
          description: ok
components:
  schemas:
    Payload:
      type: object
      properties:
        hello:
          type: string
        name:
          type: string
      required:
        - hello
        - name
      additionalProperties: false

The
x-vertx-event-bus:
  address: anotherAddress
  method: testC

And rely on a tag to pick that adress and compute the method from the operationID, right?

Yes, I think that would be a great option. Then from a generated class with @WebApiServiceGen, I could use ServiceBinder with that and just iterate over the tags to bind those classes to the event bus. Otherwise, I have to try to iterate over every operation in the OpenAPI structure. I will look at putting together a PR and tests for the changes. Thanks for the pointer to the function!


Cow: Watch itsolutions4u.co

Cow requests the watch of the watch_keyword itsolutions4u\.co. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

itsolutions4u\.co has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Nisse Engström in Charcoal HQ


Allow Exceeding Windows 250 character limit

Do you want to request a feature or report a bug?
Feature
What is the current behavior?
Will not work if SerializationFolderPathMaxLength+ 8 + MaxItemNameLengthBeforeTruncation > 250
Desired Behavior
Ability to set even longer lengths or not be artificially restricted and then display error message when exception is thrown due to path length being an issue and to enable long path length on our OS.
Option name ideas:
Rainbow.Sfs.DisablePathLengthChecks  or Rainbow.Sfs.AllowUnlimitedPathLength
Please mention your Sitecore version, Rainbow version, and if also using Unicorn, your version of that too.
9.0.2 and 2.01

We've had this feature debated a lot of times, and we continue to re-evaluate it every... 3-4 months or so. The problem is not just Rainbow, it's also the surrounding tooling. Enabling a setting such as this will make it so that you HAVE to deploy to Windows Server 2016 (AND have the same limitation disabled). Then there are concerns around the GIT for Windows client (last checked, it did not support the extended path length), Zip tools and so on.
We are getting to the point where it might be feasible to release this as an option. I plan to look into this in the early new year.

2012 and 2016. They both support long paths you just need to enable them either through group policy or registry key.
It would make more sense to allow developers to shoot themselves in the foot in the first place, just give them a warning when they do.
It wouldn't take much for this, just change this line here:
https://github.com/SitecoreUnicorn/Rainbow/blob/1645394f83bb5b006421b890da268fcc518e8c20/src/Rainbow/Storage/SerializationFileSystemTree.cs#L733
Alternatively you could make an easier way to override that

I'm not 100% if this would apply but AFAIK you can get windows tooling to exceed the path-length limit: https://stackoverflow.com/a/22575737/1296597

I'm in support of at least having the option to override this via a config switch or value so that there's a way forward for the increasing number of us that are on Windows Server 2016 or even 2012 with the registry/policy suggested above.  Especially with a lot of our clients on Azure even lately.


no longer limit  tasks/sapnote/2777782/05-disable-thp.yml to x86_64 only.

Disabling THP is not limited to x86_64, according to SAP note 2777782.

Solved in pull request #26 .


Warning related to TUI commands

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug
While using a TUI command, it is giving following warning:
###########################
pyfluent.tui WARNING: Currently calling the TUI commands in a generic manner. Please run python codegen/allapigen.py from the top-level pyfluent directory to generate the local TUI commands classes.
##########################

What does it mean?
It says "Please run python codegen/allapigen.py from the top-level pyfluent directory"

I am using a virtual environment. Where do I run the above command?

📝 Steps to reproduce

Use a TUI command:
#################
fluent_session.tui.define.units("length", "in")
#################

It will print the warning:
######################
pyfluent.tui WARNING: Currently calling the TUI commands in a generic manner. Please run python codegen/allapigen.py from the top-level pyfluent directory to generate the local TUI commands classes.
######################

💻 Which operating system are you using?
 To use pyfluent with Fluent 24.1, it is recommended to do a developer setup following these steps.

Thank you @mkundu1 for your comments. So as I understand, this warning will not appear for a released PyFluent version. Is that correct understanding?

@mkvani small correction: it is not the PyFluent version that matters in this case, it is the Fluent version. You are correct that "this warning will not appear for a released Fluent version".
Once Fluent 2024 R1 is released, we will include the required API files in PyFluent, and warnings like this won't come up when using latest PyFluent with Fluent 2024 R1

Thank you @raph-luc !


panic: assignment to entry in nil map

Troubleshooting

[x] I've searched discuss.bitrise.io for possible solutions.
Which version of the step is effected? 2.0.0 and 2.0.1
Is the issue reproducible with the latest version? YES
Does the issue happen sporadically, or every time? EVERY TIME
Is the issue reproducible locally by following our local debug guide? NOT APPLICABLE

Useful information

FAQ
devcenter.bitrise.io

Issue description

After updating the step from v1, with the required values filled*, the step always fails with panic: assignment to entry in nil map. It works perfectly with v1. The info.plist file is located in ./XXX/Resources/Info.plist. Bundle version is filled.
*The required values are:

$BITRISE_PROJECT_PATH
$BITRISE_SCHEME
$BITRISE_BUILD_NUMBER

None of these have changed, and everything works fine again if we go back to v1.x.x of the step.
Bitrise info

Build URL: https://app.bitrise.io/build/13fd76e4-a1d9-4ba8-8a0a-a47eca303318
Bitrise Support enabled: YES
Log:

Input:
- project_path: XXX/XXX.xcodeproj
- scheme: XXX-preprod
- target:
- configuration:
- build_version: 147
- build_version_offset: 0
- build_short_version_string:
[13:12:56] Locating built project for xcode project: XXX/XXX.xcodeproj, scheme: XXX-preprod
Read XXX-dev scheme in 0s.
Read XXX-integration scheme in 0s.
Read XXX-preprod scheme in 0s.
Read XXX-prod scheme in 0s.
[13:12:56] Located built project for scheme: XXX-preprod
The version numbers are stored in the plist file.
panic: assignment to entry in nil map
goroutine 1 [running]:
github.com/bitrise-steplib/steps-set-xcode-build-number/step.updateVersionNumbersInInfoPlist(0x14000158000, {0x0?, 0x1400001607f?}, {0x0?, 0x0?}, 0x0?, {0x0, 0x0})
	/var/folders/yy/6kcn9mkd5svdbqnznwf474f00000gn/T/bitrise1978469106/step_src/step/step.go:141 +0xe0
github.com/bitrise-steplib/steps-set-xcode-build-number/step.Updater.Run({{0x100959638, 0x14000012470}, {{0x100959658, 0x14000012480}}, {0x10095ced8, 0x1400007f2f0}}, {{0x1400002002d, 0x13}, {0x1400001607f, 0xc}, ...})
	/var/folders/yy/6kcn9mkd5svdbqnznwf474f00000gn/T/bitrise1978469106/step_src/step/step.go:70 +0x134
main.run()
	/var/folders/yy/6kcn9mkd5svdbqnznwf474f00000gn/T/bitrise1978469106/step_src/main.go:31 +0x2b0
main.main()
	/var/folders/yy/6kcn9mkd5svdbqnznwf474f00000gn/T/bitrise1978469106/step_src/main.go:17 +0x1c

Steps to reproduce

Update the step to 2.0.1 with the default values.
Run the workflow.

check INFOPLIST_FILE setting
-  INFOPLIST_FILE = "$(SRCROOT)/xxx/Info.plist";
+  INFOPLIST_FILE = xxx/Info.plist;

remove $(SRCROOT)

So plist_path is still there, but now only visible directly in bitrise.yml :
- set-xcode-build-number@2:
        inputs:
        - target: ''
        - plist_path: XXX/Resources/Info.plist

I tried various paths, none work.
Relative to the root folder, we have:

XXX/XXX.xcodeproj
XXX/XXX/Resources/Info.plist

The name that I hide behind XXX is the exact same in all places.

check your xcodeproj settings
$ cat xxx.xcodeproj/project.pbxproj | grep INFOPLIST_FILE

if has $(SRCROOT)，remove it
set-xcode-build-number@2 now does not accept a plist_path argument as input.

Removing ${SRCROOT} in the xcodeproj worked, thanks.

Solved in version 2.0.4
Changes:
https://github.com/bitrise-steplib/steps-set-xcode-build-number/pull/44
https://github.com/bitrise-steplib/steps-set-xcode-build-number/pull/46


Option to Print Failure to Console?

Issue Description - Option to Print failure to console
I'm currently doing performance test, and finding it hard to trace the failure from failure message received on client side. I'm using headless server, so there's no way to trace it like a web UI do.
Expected Behaviour
Logging failure to file whenever get non 200 response code
Actual behavior
I also checked the code, and find out that print_error_log only called when locust is shutting down, and it will print all the errors. Will be nice if we could get the failure logged to file.

use the --logfile option when starting Locust.

You could achieve this by hooking into the request_failure event. Add this to your lcoustfile:
from locust.events import request_failure

def on_request_failure(request_type, name, response_time, exception, **kwargs):
    print("%s %s failed: %s" % (request_type, name, exception))

request_failure += on_request_failure

I'm not sure this is a common enough use-case to warrant it as an extra built-in locust feature.


fix: Workspace check toggle, creds scanning

https://github.com/amp-labs/connectors/pull/714

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#710
#720  👈
#712 : 2 other dependent PRs (#661 , #713 )
#711
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @Cobalt0s and the rest of your teammates on  Graphite

@laurenzlong the changes are identical to what you have approved here https://github.com/amp-labs/connectors/pull/714
Could you approve it again?
I had to open alike PR because of messing up graphite merging chain.


As a user, I want to see a member's primary or best name prominently and also see other known names or so that I can recognize them and see how they were listed in the archival materials.

Notes for testing

names in the member list display should look as they did before
on individual member detail page, the all caps title at the top should be a first name last version of the sort_name; check someone with a different sort name than name and check someone without a comma in the sort name(suggestions: test Claude Cahun and Bryher)
on individual member detail page, the full name from the name field in the database should be displayed in the biographical section

dev notes

[x] add firstname_last method
[x] use firstname_last for h1 and html title on member detail pages and membership activities pages
[x] add full name with variants (name property) to biographical section on member details
[x] adjust styles so name is not hidden on member details page

YES, the names in the member list look as they did before
YES, on the individual member detail pages, the all caps title at the top is the first name last version of the SORT NAME. Checked Bryher, Claude Cahun, Simone de Bretteville. In all cases the ALL CAPS TOP name correctly lists First Name Last Name of the sort name.
YES, in the individual member detail page the full name from the name field in the database is displayed in the bio section. Checked Bryher, Claude Cahun, Simone de Bretteville again: see screenshot for de Bretteville. I'm not sure I listed her full NAME right, but I followed our notes from the last meeting.


I have a question for background

hello guys i keep trying to submit my app but reviewer said " please revise your app to provide audible content to the user while the app is in the background or remove the "audio" setting from the UIBackgroundModes key"
but i have no UIBackgroundModes key... it automatically generate YoutubePlayerKit in background

how can i fixed ?  I want to use that player ...

Hmm.. I don't have any UIBackgroundModes... how can i remove that .. :(


feat(docker): Prep master for docker deploys

[x] I have read freeCodeCamp's contribution guidelines.
[x] My pull request has a descriptive title (not a vague title like Update index.md)
[x] My pull request targets the master branch of freeCodeCamp.

This pull request:

preps the master branch for a docker deploy. There will be no production Dockerfiles in this repository, they will be held in freecodeCamp/production-docker-build
does not enable/update any development docker environment previously working
adds an api linting script
does not commit any api linting change as the diff would be too noisy

The effect on the contributor should be minimal, nothing beyond normal branch maintenance (git pull --rebase, npm install et al)

does this PR resolve this issue as well?
#35030

Nope. Its unrelated to local docker setups.


Support GHC 9.6.1 and base <IP_ADDRESS>.

Tracker for upstream tickets:

https://github.com/obsidiansystems/commutative-semigroups/pull/10
https://github.com/obsidiansystems/commutative-semigroups/issues/11

Fixed (in principle) by #64, but leaving this issue open until it's possible to add GHC 9.6.1 to the CI build matrix.
(It's currently not possible to build with GHC 9.6.1 without also specifying --allow-newer, as some dependencies still require base < 4.18.)

Fixed by #79.


Restrict AD RPC traffic to specific port still supported for Windows Server 2016 and higher?

Is the method to restrict Active Directory RPC traffic to a specific port still supported for Windows Server 2016 and higher? The article (SupportArticles-docs/support/windows-server/identity/restrict-ad-rpc-traffic-to-specific-port.md ) only mentions Windows Server 2012 R2.

Thanks. @TaekeK. I am investigating this and will reply later.

I confirmed that this article applies to later versions of Windows Server. I have edited the article. Thank you for the feedback.


Docs about 'host' parameter is wrong. port parameter ignored. Error returned when timeout is also wrong.

When connecting to a remote AMQP server, the configuration explained in the docs is not working.

The host setting must be populated by the pair host:port
The port setting is completely ignored.
If the connection is via HTTPS then the ssl setting should be set to true. This is not wrong but not well documented.

Moreover, when the plugin cannot connect to the server (because any of the parameters are wrong or any other issue) and times out, you get the following error:
RabbitMQ connection error, will retry. {:error_message=>"Connection to localhost:5672 refused", :exception=>"MarchHare::ConnectionRefused"}

which is completely false and misleading.

@Erni
Hi. Did you manage to find a workaround?

Thank you, this worked for me.

A fix in upstream connection mixin (https://github.com/logstash-plugins/logstash-mixin-rabbitmq_connection/commit/447b41f823c913cc425068e2d781cae70bb02a3e) was unfortunately not ever consumed by this stand-alone plugin.
Since development of this plugin is now continuing as a part of the RabbitMQ Integration Plugin, I have opened a PR there to absorb the fix in future releases; please feel free to comment about your backport requirements if you aren't running Logstash 6.5+ (which is required for Integration Plugins):
https://github.com/logstash-plugins/logstash-integration-rabbitmq/pull/12


update to sequelize v4

check instanceof on the prototype see
https://github.com/sequelize/sequelize/pull/5877
update dependencies

+1 for this pull.

Created package sequelize-to-joi temporarily. @dan-nyanko

Thanks for the PR, sorry I missed it until now. Going to bump version to v2 and publish it up

Oh, thank you sir.

Sequelize is now 4.8. I don't know if there's any relevant change, but as I cannot check right now, I'm pointing out.

I think it should be alright. Nothing stood out in their changelog, but feel free to add an issue if any problems crop up


[Android] Creating an Custom Animated Shimmer Effect Jetpack Compose

Creating an Animated Shimmer Effect in Jetpack Compose
Introduction
In this tutorial, I'm going to show the reader how to implement an Animated Shimmer effect in android applications using a modern UI toolkit Jetpack Compose. The shimmer effect gives the impression of extra light on the desired areas of the face. It makes the app look radiant and get a beautiful glow. Usually, the shimmer effect is used to show that the app is loading some data which maybe from the internet. When data is loaded, the shimmer effect stops and the user can get a view of the items that were being loaded.
Key takeaways

Implementing Shimmer Effect in Jetpack Compose
Creating Shimmer Grid Items
How to customize time, color, and Animate the Shimmer effect

Article quality
My topic is unique in that most of the written articles on the Jetpack Compose Shimmer Effect uses libraries. In this article, I will show the reader on how to create the Shimmer Effect by writing code only without using any library.
References
https://developer.android.com/jetpack/compose/animation

Seems like a helpful topic. Let's ensure that it adds value to the community. Thanks

Closed #5070 via #5753


Table unused created in IndexedDB

Have you read the FAQ and checked for duplicate open issues? Yes
What version of Shaka Player are you using? 2.5.9
Can you reproduce the issue with our latest release version? Yes
Can you reproduce the issue with the latest code from master? Yes
Are you using the demo app or your own custom app? Both
If custom app, can you reproduce the issue using our demo app? Yes
What browser and OS are you using?
Chrome 80 macOS Catalina
What did you do?

Load https://shaka-player-demo.appspot.com/demo/
Check IndexedDB in the devtools
See the database tables
What did you expect to happen?
The tables are: manifest-v3, segment-v3
What actually happened?

The tables are: manifest-v3, segment-v3, session-ids
The table session-ids is not used, so it shouldn't be created

This is working as intended.  The session-ids store is created when we initialize / upgrade our storage system.  It is used to store session IDs that are pending release after deleting offline content.
Some persistent license sessions must have their release confirmed with the license server, and should not be deleted until an acknowledgement message has been received.  But we don't want to keep the full content just to store a session ID, so those pending-release session IDs get their own object store.
IndexedDB only allows you to create object stores on upgrade or creation of the database.  So if we might potentially need the session-ids store, we must create it early.
I hope this helps clarify!

Thanks for your explanation!

Happy to help!


Feature/refetch

This PR is to merge the changes necessary to implement the Traffic Ops related changes for the Refetch Blueprint (PR 5910).
TLDR; Modified the /jobs endpoints for Traffic Ops to take an InvalidationType string that must be either 'REFRESH' or 'REFETCH'. There was some extra work around this modification, but that was its primary purpose.
The changes primarily fall on schema changes for the database and Traffic Ops API changes. Currently this is targeting Traffic Ops API 4.0.
TO Database:

Remove unused tables and columns (job_status table, job_agent table, various columns in the job table)
Modify the data within the job table to reflect the new schema and goal (e.g. remove the keyword column and change the parameters column to ttl_hr, etc.)
~TODO/Outstanding: Update app/db/seeds.sql and app/db/patches.sql to account for db schema changes~ Done

TO API:

Add v4.0 InvalidationJob endpoints and structs to accomplish the requirements in the blueprint/refetch goals.
Modify the previous endpoints to ensure compatibility with the DB schema changes

TO clients:

Modify the v4 clients to take advantage of the TO v4.0 API and tc structs
Ensure the tests pass

TP:

Modify TP to use the stable (3.1) version of the /jobs endpoint

T3C (formerly ORT):

Slight modification to ensure tests pass with the DB schema

Documentation:

TODO/Outstanding: Want to ensure we are actually going to merge this into v4.0 before modifying all the documentation to reflect this.

Which Traffic Control components are affected by this PR?

Documentation
Traffic Control Cache Config (T3C, formerly ORT)
Traffic Control Client
Traffic Ops
Traffic Portal

What is the best way to verify this PR?

To test whether REFETCH works specifically or not, you will need to set the parameter refetch_enabled to true for the global config file in the DB parameter table. Otherwise only REFRESH jobs will be allowed.
The TO database migration scripts will need to be run to ensure the transition from a previous schema works to the new. This is accomplished by using the db/admin utility as outlined here.
Once the DB migration has taken place, the Traffic Ops client API integration tests can be run. You will need TO to be up and running with the to_test database set up as described here.

To test all currently supported APIs (ensures backwards compatibility as well) you can do something akin to:

cd github.com/apache/trafficcontrol/traffic_ops/testing/api
# default location is github.com/apache/trafficcontrol/traffic_ops/testing/api/conf/traffic-ops-test.conf
go test --cfg <location for your test config> ./...

To test only the invalidation job specific changes for API 4.0 you could run something akin to:

cd github.com/apache/trafficcontrol/traffic_ops/testing/api/v4
# default location is github.com/apache/trafficcontrol/traffic_ops/testing/api/conf/traffic-ops-test.conf
go test -run Jobs --cfg <location for your test config>

Once the Traffic Ops Integration tests confirm the new and previous implementations of the /jobs endpoints still work then you can proceed to running and testing the TP integration tests still work. This will verify that TP is utilizing the previous stable version of the TO API (v3.1) and not the new /jobs endpoints.
Ensure a local version of TO is up and running with the correct DB schema. This should already be the case based on the TO client integration tests from before.
Ensure Traffic Portal is building and running as outline (here)[https://traffic-control-cdn.readthedocs.io/en/latest/development/traffic_portal.html#traffic-portal].

By default, the TP integration tests are set up to run against CIAB. If you're running this locally you will need to modify the config file located at github.com/apache/trafficcontrol/traffic_portal/test/integration/config.json. The params section will need to be modified:

  "params": {
    "apiUrl": " https://localhost:8443/api/4.0",
    "baseUrl": "https://localhost:9090",
    "login": {
      "username": "admin",
      "password": "twelve12"
    },

Where
apiUrl = Running Traffic Ops API URL (This can and should be set to 4.0)
baseUrl = Running Traffic Portal URL
login.username = existing administrator account username
login.password = existing administrator account password
You can also, optionally, remove the --headless flag to see the integration tests as they run in Chrome Browser

cd github.com/apache/trafficcontrol/traffic_portal/test/integration
npm i
npm run start-webdriver
npm run test

PR submission checklist

[x] This PR has tests
[ ] This PR has documentation - This is delayed for the time being until accepted or rejected in the current RC (6.0) for ATC.
[ ] This PR has a CHANGELOG.md entry - This is delayed for the time being until accepted or rejected in the current RC (6.0) for ATC.
[x] This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Biggest thing that stood out to me was the CRUDer rearing its ugly head again

This PR doesn't appear to be using the CRUDer any more than the original /jobs implementation. It still uses it for Read it appears, but create, update, and delete are all as CRUDer-free as the prior version. I'm guessing the prior version functions were mostly just copied then modified to work with the new changes we want.

I guess it's not fair to expect him to do more work than he needs to. It's just so terrible right now I can't believe he thought any of it was worth keeping.

I think the DB migrations may need to be updated to a more recent timestamp: traffic_ops/app/db/migrations/2021081321025500_refetch.down.sql
Because there have been other migrations that have come in with more recent timestamps, this one won't be run in dev environments that have already run those more recent migrations.

TP integration test failure appears to be a transient issue unrelated to this PR, merging ahead.


Integrating FCM or PubSub Push

I'm facing problems using the Dart fcm_push or the pubsub push in gcloud. I installed the gcloud, googleapis and googleapis_auth dependencies, and set up the ServiceAccountCredentials to get the AuthClient, and everything seems to be done right, however I get this uncaught exception in the log:
ReferenceError: XMLHttpRequest is not defined
at /user_code/build/node/main.dart.js:9351:7
I just can't get past that, no matter what I tried. Is there a trick I'm missing, or a better way to push notifications to subscribers or user token ids using this interop?  Here is my pubsub.yaml:
dependencies:
  firebase_functions_interop: ^1.0.0
  fcm_push: ^1.3.1
  gcloud: ^0.6.0+4
  googleapis: ^0.53.0
  cron: ^0.2.2

dev_dependencies:
  build_runner: ^1.0.0
  build_node_compilers: ^0.2.0
  googleapis_auth: '>=0.2.3 <0.3.0'

and my relevant imports:
import 'package:fcm_push/fcm_push.dart' as fcm;
import 'package:googleapis_auth/auth_io.dart' as auth;
import 'package:http/http.dart' as http;
import 'package:gcloud/pubsub.dart' as pubsub;

and my code to init the client:
auth.AuthClient client;
pubsub.PubSub pubSub;
fcm.FCM cloudMessaging;

  var credentials = auth.ServiceAccountCredentials.fromJson(r'''
{
  "type": "service_account",
  "project_id": "....",
  "private_key_id": "....",
//Taken from key credentials json download
}
''');
  var scopes = pubsub.PubSub.SCOPES;
  print("Init 1 - auth client Metadata");
  client = await auth.clientViaServiceAccount(credentials, scopes);
  //client = await auth.clientViaMetadataServer();
  print("Init 2 - Getting pubSub");
  pubSub = new pubsub.PubSub(client, "functions");

Everything builds/deploys correctly, except in the log with the client auth, or try to do a cloudMessaging.send() I get that pesky XMLHttpRequest is not defined error that I can't find anything about fixing.  Has anyone else been able to send push notifications from their Firebase Functions trigger?  Seems like it would be a common use case, any help would be appreciated, thanks..

I'm still trying to figure this out, I really don't want to redo all my code in the JavaScript.  There's gotta be a way to send Firebase Cloud Messaging from here, that's my whole purpose of needing to run a Firebase Functions server to send notifications.  Any ideas?

It does seem like messaging is missing from the admin class here

I'm not sure I understand the problem here. Do you have a cloud function which should send a PubSub message?
If you're using googleapis packages I'll likely need to implement Node.js specific googleapis_auth client, because it looks like only supports dart:io and web browser HTTP clients.
Of course, it would be nice to add FCM support to firebase_admin_interop so that we can use Firebase SDKs directly.

Yeah, that's what I'm waiting for myself

I had hoped the native dart plugins would have been compatible, but I'm realizing the interop trick having to translate to node.js calls.. It would be nice if it was a builtin function for sure.  I don't know if pubsub is easier to impliment or Cloud Messaging, I could go with either for pushing notification to a channel group or individual Firebase UIDs.  Whatever's easier to hack together, it's that missing piece to get my app functional.  If I can help, lemme know, but this part of code gets daunting... Thanks.

Did anyone here manage to send a push message from dart in a Firebase function? I really hope I do not have to redo all my code using Javascript.


Rollout #123

Rollout #123

 canary - Complete
uswest - Pending (run after canary)
useast - Pending (run after canary)


Password input sample not working

Password input sample fails on latest release and locally with latest bits
http://localhost:5000/samples/05.custom-components/f.password-input/index.html

After investigation, this one will be fixed once the CDN is reverted back to 4.7.1

4.7.1 has been redeployed to CDN and I confirmed this sample as working again.


Curated feeds owned by organizations cannot be managed

When we added the organizations feature, we forgot to add curated feed management to the permissions service.
We should add curated feeds to the permissions service.
https://github.com/NuGet/NuGetGallery/blob/166d4c21134c11f0800aa7e0f0026a53cc583d48/src/NuGetGallery/Controllers/CuratedFeedsController.cs#L36
https://github.com/NuGet/NuGetGallery/blob/166d4c21134c11f0800aa7e0f0026a53cc583d48/src/NuGetGallery/Controllers/CuratedPackagesController.cs#L39
https://github.com/NuGet/NuGetGallery/blob/166d4c21134c11f0800aa7e0f0026a53cc583d48/src/NuGetGallery/Controllers/CuratedPackagesController.cs#L67
https://github.com/NuGet/NuGetGallery/blob/166d4c21134c11f0800aa7e0f0026a53cc583d48/src/NuGetGallery/Controllers/CuratedPackagesController.cs#L99
https://github.com/NuGet/NuGetGallery/blob/166d4c21134c11f0800aa7e0f0026a53cc583d48/src/NuGetGallery/Controllers/CuratedPackagesController.cs#L130

We are removing curated feeds management, so this won't be necessary. //cc @joelverhagen


Pass all BUILDKITE env vars through

Previously we only passed ones from this list, but there are quite a few
conditional vars that can be useful.

Thanks!


Add model outlining

Add a rasterizer which can draw outlines and glows around models and make the following plugins use it:

Npc indicators
Slayer
Rogues' den
Devtools
Object markers

The performance of a 1px outline with a solid color is a little better than the performance of a 8px glow, but both generally runs with decent fps. The performance is similar to the convex hull. In general whichever one has less pixels that needs changing is the one that runs faster.
The outliner also simulates a model render which can make it slower than the convex hull whenever the thing that is being outlined occupies a lot of pixels on the screen.

when i try using this on my local build i get a AbstractMethodError for br.DrawOutline() do i have to do anything special/differant when building if there are changes to mixins ? or is this caused by something else

You have to have access to the injector, which is no longer open source to build mixin changes.

oh alright hope this gets merged soon then looks really nice imo much better than the current highlighting options

added in #13791


Support non-integer values for cpu

Moving cpu_shares from attr_reader to attr_accessor means that the cpu_shares=
method in lib/centurion/service.rb is not called and instead the cpu_shares
value is set directly.
MES-102
@actaeon Please review!

Since this isn't merging into master, let's :ship: .
Make sure to clean up tests before submitting PR into master. :)


open data and open data = IP resources

Collect resources on open data, and especially how IP considerations might affect open data choices
cc @stephwright who offered to help

http://data.research.cornell.edu/content/intellectual-property

an introduction to IP & RDM, US centric, add'l resources that  may be of interest at bottom of page
of particular interest may be:
http://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.1002235
"Sharing Research Data and Intellectual Property Law: A Primer"

Thanks @stephwright :)

Hope they're useful :)


Fix reference to WebGL context.

:tada: This has been pushed live to https://developers.google.com/web/


Add documentation for building, running and testing benchcab

Building
Dependencies

conda env

Dev-Dependencies

black, ruff

module load conda
conda env create --file .conda/benchcab-dev.yaml
conda activate benchcab-dev
pip install --user -e .

mkdocs

pip install -r mkdocs-requirements.txt

If using on Gadi, use ssh port forwarding
sh -L 8000:localhost:8000<EMAIL_ADDRESS>
mkdocs serve

Running
Follow the user guide
Testing

pytest, mypy
Integration tests

/bin/bash benchcab/data/test/integration.sh

Comparing Models

netcdf, cdo

I think we use nccmp for doing bitwise comparisons between model outputs. I don't think we use cdo?

@ccarouge could you clarify which module we use for doing bitwise comparisons?


Merge updates that have been made to astropy/package-template into NEI

Different from #30 since I used the command line for this.

Hello @namurphy! Thanks for submitting the PR.

In the file ah_bootstrap.py, following are the PEP8 issues :

Line 22:80: E501 line too long (80 > 79 characters)
Line 87:1: E722 do not use bare except'
Line 127:1: E722 do not use bare except'
Line 136:1: E402 module level import not at top of file
Line 138:1: E402 module level import not at top of file
Line 139:1: E402 module level import not at top of file
Line 141:1: E402 module level import not at top of file
Line 142:1: E402 module level import not at top of file
Line 207:80: E501 line too long (88 > 79 characters)
Line 212:80: E501 line too long (80 > 79 characters)
Line 213:80: E501 line too long (80 > 79 characters)
Line 484:80: E501 line too long (81 > 79 characters)
Line 486:80: E501 line too long (83 > 79 characters)
Line 504:80: E501 line too long (80 > 79 characters)
Line 548:80: E501 line too long (80 > 79 characters)
Line 599:80: E501 line too long (81 > 79 characters)
Line 603:80: E501 line too long (81 > 79 characters)
Line 625:80: E501 line too long (80 > 79 characters)
Line 628:80: E501 line too long (80 > 79 characters)
Line 632:80: E501 line too long (81 > 79 characters)
Line 675:80: E501 line too long (83 > 79 characters)
Line 676:80: E501 line too long (83 > 79 characters)
Line 680:80: E501 line too long (80 > 79 characters)
Line 689:80: E501 line too long (82 > 79 characters)
Line 690:80: E501 line too long (83 > 79 characters)
Line 698:80: E501 line too long (81 > 79 characters)
Line 751:80: E501 line too long (82 > 79 characters)
Line 781:1: E302 expected 2 blank lines, found 1
Line 815:5: E303 too many blank lines (2)
Line 886:1: E302 expected 2 blank lines, found 1
Line 897:5: E722 do not use bare except'

In the file docs/conf.py, following are the PEP8 issues :

Line 6:80: E501 line too long (80 > 79 characters)
Line 18:80: E501 line too long (80 > 79 characters)
Line 35:80: E501 line too long (89 > 79 characters)
Line 54:1: E265 block comment should start with '# '
Line 102:1: E265 block comment should start with '# '
Line 107:1: E265 block comment should start with '# '
Line 119:1: E265 block comment should start with '# '
Line 123:1: E265 block comment should start with '# '
Line 128:1: E265 block comment should start with '# '
Line 132:1: E265 block comment should start with '# '
Line 145:80: E501 line too long (80 > 79 characters)
Line 174:80: E501 line too long (88 > 79 characters)
Line 181:80: E501 line too long (80 > 79 characters)

In the file nei/__init__.py, following are the PEP8 issues :

Line 15:1: E302 expected 2 blank lines, found 1
Line 18:1: E305 expected 2 blank lines after class or function definition, found 1
Line 18:80: E501 line too long (89 > 79 characters)
Line 19:80: E501 line too long (111 > 79 characters)

In the file setup.py, following are the PEP8 issues :

Line 28:80: E501 line too long (89 > 79 characters)
Line 29:80: E501 line too long (107 > 79 characters)
Line 34:1: E402 module level import not at top of file
Line 35:1: E402 module level import not at top of file
Line 44:1: E402 module level import not at top of file
Line 46:1: E402 module level import not at top of file
Line 47:1: E402 module level import not at top of file
Line 139:80: E501 line too long (99 > 79 characters)
Line 151:1: E124 closing bracket does not match visual indentation


Removing Sponsor Logo Makes Campaign Inaccessible

Current Behavior
When a campaign's sponsor is removed from the "name" field of a campaign (under edit > sponsors and partners), the "view" tab shows an error like the one shown below, for both logged in admins and unauthorized users.
Desired Behavior
Removing content from any previously populated field should not produce an error.
Steps to Replicate
Go to a campaign with a sponsor in the sponsors and partners field. Remove by deleting the text in the "name" field. Save the campaign.
Why This Matters
Most pressingly, a suite of campaigns is no longer sponsored, and the sponsor's logo needs to be removed.
Relevant Screenshots
Field:

After content is removed from field:

Currently seen on prod on:
https://www.dosomething.org/campaigns/not-same-old-story and https://www.dosomething.org/us/campaigns/past-picture-perfect

Currently seen on prod on:
https://www.dosomething.org/campaigns/not-same-old-story and https://www.dosomething.org/us/campaigns/past-picture-perfect

Possibly related to: https://github.com/DoSomething/phoenix/issues/4916 and https://github.com/DoSomething/phoenix/pull/4917

Possibly related to: https://github.com/DoSomething/phoenix/issues/4916 and https://github.com/DoSomething/phoenix/pull/4917

also potentially related to this bug we have with video fields #949
when field collection fields are removed the actual values in the db remain causing a an is_empty check to pass when it shouldn't

So the issue there was that @namimody should've clicked 'Remove' button instead of just deleting everything in the "Name" field, see at the bottom of the screenshot:
https://staging.dosomething.org/us/node/1173/edit/add/en/en-global

However, now when few nodes are broken, I can't fix the partners fields:
https://www.dosomething.org/node/5565/edit/
The edit page fails for me on production (it works on staging though).
I will push the a code change that prevents this from happening.


Fix warnings

Turn on -Wall, -Wextra, and -Werror, and fix all of them
Marking LCM C++ bindings, lcm_coretypes.h, generated test data (because
it contains LCM C++ bindings) as system includes so we don't fail the
build on warnings in them (which do exist).
The build should both now be warning-free (except for third-party
code), and fail if new warnings appear.
Reviewers: hayk-skydio,bradley-solliday-skydio,nathan-skydio
Topic: sym-warnings

Reviews in this chain:
└https://github.com/symforce-org/symforce/pull/222 Fix warnings

#
head
base
diff
date
summary

0
becb8e24
716befd8
diff
Sep 14 1:27 AM
58 files changed, 286 insertions(+), 78 deletions(-)

Merged by 6d1c918d7f4a0f645e68be8fd060754d16c1c408


Images are not showing up in HTML file

Hello,
After upgrading from 2.1.0 to 2.2.1, the HTML report on our CI is not showing any images/screenshots.

It's seem to be a regression issue caused by https://github.com/XCTestHTMLReport/XCTestHTMLReport/pull/253 where the image's relative path has been replaced by the absolute path (please refer to the relevant changes).
Steps to reproduce:

Downloads sample.xcresult and run xchtmlreport -r <path-to-enclosing-folder>/sample.xcresult
Open index.html and verify the images are showing up
Rename the enclosing folder, open index.html and verify the images are now broken

It's not only happening to images but also all other attachments.


BIGTOP-2550: Update juju hadoop bundle for Juju 2.0 and Xenial

Update README with xenial and juju2 instructions.  Callout juju1 equivalent commands where applicable.
Colocate apps that can live together (eg: RM and NN) to cut down on required machine resources.  Note this colocation in the readme.
Bump charm revisions to include newly built charms from BIGTOP-2548.

ASF gitbot didn't link this PR to the jira.  I think that's because I didn't title it correctly at the onset.  Closing out to make a new one.

Duped PR.  See #150.