incompatibility between branches of release-2.0 and master

I was having some incompatibility issues between release-2.0 branch and master branch in client-go. Just submitting issues here and inquiring more info on releases. Here are some example issues:

"k8s.io/client-go/pkg/labels" doesn't exist anymore. We use some methods like labels.Everything(), labels.SelectorFromSet().

"k8s.io/client-go/pkg/api/unversioned" doesn't exist anymore. We decode unversioned.Status{} from watch stream, use unversioned.TypeMeta/ListMeta for object/listObject, use unversioned.LabelSelector for "extensions/v1beta1".ReplicaSet, etc.

"k8s.io/client-go/pkg/types" and "k8s.io/client-go/pkg/api/meta/metatypes" doesn't exist anymore. Use types.UID and meattypes.OwnerReference .

Importing unfound packages: "k8s.io/client-go/pkg/api/meta", "k8s.io/apimachinery/pkg/openapi" .

What's the plan for client-go on this? Is client-go gonna release 3.0 for k8s 1.6?
And what's the plan for maintaining each releases? It seems like release-2.0 has issues as mentioned in https://github.com/kubernetes/client-go/issues/66 but there wasn't any answer or releases to import fixes from upstream for it.

Go back to the alpha tag: https://github.com/kubernetes/client-go/tree/v2.0.0-alpha.1/pkg/labels
I think client-go head is broken right now because we moved these packages into the apimachinery repo.

@deads2k

Go back to the alpha tag: https://github.com/kubernetes/client-go/tree/v2.0.0-alpha.1/pkg/labels

alpha is broken due to https://github.com/kubernetes/client-go/issues/66

I think client-go head is broken right now because we moved these packages into the apimachinery repo.

What is the future plan?

Labels is moving into the apimachinery repo, unversioned is becoming meta (I think). These things do actually exist in client-go, under the vendor/ directory. I guess you can get them from there for the moment. I don't have a plan yet because these client-go problems caught me by surprise earlier today. I don't know yet if we will fix this in a 2.x.x branch or if we'll have to cut a 3.x.x to solve this.

Were these not being pulled from the client-go vendor dir?

@lavalamp

under the vendor/ directory.

Hrm... I think the convention is that library does not vendor its dependencies in go.

Yes, that is the convention. But if we remove it, you'll have no way of getting the revision of k8s.io/apimachinery that the client depends on--and we expect to change this relatively often initially.

We could fake deresolve them into client-go, but I'm pretty sure david hit a case where we either have common apimachinery in kube between client-go and master, or we can't use client-go in kubernetes.

@lavalamp

you'll have no way of getting the revision of k8s.io/apimachinery

If client go has any hard dependency versioning requirement, can we simply document them?
I am actually fine with copying that hash or versioning string into the version system my project uses. I think it would be OK for most others since it is pretty much a go convention.

We could fake deresolve them into client-go, but I'm pretty sure david hit a case where we either have common apimachinery in kube between client-go and master, or we can't use client-go in kubernetes.

If we make copies, then the code becomes incompatible again and it's impossible untangle dependencies.  client-go has a logical dependency upon the API machinery which makes it work and expressing that dependency makes sense.  The level of API machinery vendored into the client-go will always work with client-go and will be listed in the godeps.json file.

@deads2k

then the code becomes incompatible again and it's impossible untangle dependencies.

Can you explain more? I do not understand this.

The level of API machinery vendored into the client-go will always work with client-go and will be listed in the godeps.json file.

How do you expect this to work for projects that depend on client-go? What is the vendoring process do you suggest?

I think it's not clear so let me just add that release-2.0 branch hasn't had a 2.0.0 tagged yet. We've only released alphas of 2.0. So you will probably have a better time if you stay on the 1.5.0 tag.

@lavalamp

But if we remove it, you'll have no way of getting the revision of k8s.io/apimachinery that the client depends

OK... I looked at the k8s.io/apimachinery repo. It seems that apimachinery itself is not even versioned, is unstable. If we want the client go to be stable, we need its dependencies to be stable first. Releasing a stable release that depends on a very unstable but critical component seems risky to me.

OK... I looked at the k8s.io/apimachinery repo. It seems that apimachinery itself is not even versioned, is unstable. If we want the client go to be stable, we need its dependencies to be stable first. Releasing a stable release that depends on a very unstable but critical component seems risky to me.

Not entirely true.  In order for client-go to be stable it must vendor a guaranteed level of apimachinery and there have to be bug fixes in whatever branch/tag is used.  As long as the actual commit is retrievable by a vendoring tool and we continue to provide fixes, we only need to be compatible for the interface types here.  If there's a contract break, we could simply ripple down here to another version.

To put this in perspective, when client-go straight up copied things like k8s.io/kubernetes/pkg/runtime, you were already vulnerable to any change to what was considered to be an internal library and if we had to make a significant change, it would simply ripple out here.  Exactly as this recent vendoring made more obvious.

When we were copying those things, they didn't escape the package boundaries and changes were completely invisible to users of client-go. Now that we're moving to multiple repos, those dependencies DO escape the client-go repo and users are impacted.

As long as the actual commit is retrievable by a vendoring tool and we continue to provide fixes

From vendoring perspective is OK. But from the stability perspective, it is not. If apimachinery fixes a bug, then client-go that vendors the old commit hash is "unstable".

From vendoring perspective is OK. But from the stability perspective, it is not. If apimachinery fixes a bug, then client-go that vendors the old commit hash is "unstable".

That was already happening, you just didn't know it.  The copy and mutate mechanism for building this repo did exactly the same thing, it was just more silent.

@deads2k
Just because it's been wrong all the time doesn't mean keep doing it is right.
For client-go user, he wouldn't expect vendoring unstable, non-guaranteed repo into production.

@deads2k
Just because it's been wrong all the time doesn't mean keep doing it is right.
For client-go user, he wouldn't expect vendoring unstable, non-guaranteed repo into production.

Well, I think there's confusion about the state we're starting from.  This hasn't introduced new entropy.  It has made it possible to see that the entropy that already existed is there.  If we all understand the starting state (regardless of what previous claims were), we can talk about what needs to happen to get to the desired state without thinking we can simply "go back" and everything will work.

@deads2k

That was already happening, you just didn't know it.

Now I know that. And I begins to feel the instability. If we agree it is unstable, we can start to find a way to stabilize it. If you feel it is stable, then I disagree, and I have to sort it out with you on it since you are working on apimachinery. I think it is VERY important to make apimachinery stable at the first place.

I think it is VERY important to make apimachinery stable at the first place.

This statement I agree with and I think that recognition of our problems is the first step.  I want API machinery stable and we are actively working it.  However, I'm not sure its a one release kind of problem.
Pinning a particular interface level towards the end of 1.6 would at least make it possible to track changes in a way that wasn't possible before.  It may also mean that these versions change more than we'd like for the short term.

Pinning a particular interface level towards the end of 1.6 would at least make it possible to track changes in a way that wasn't possible before. It may also mean that these versions change more than we'd like for the short term.

OK. Good to know. Basically this means the client-go should not release 2.0 until the end of 1.6 when apimachinery is somewhat stable. Or we will probably face api break, and need to bump major version.

client-go release-2.0 is tracking k8s release-1.5 branch, where the apimachinery moves hadn't occurred yet, so its API is stable.
client-go master branch is tracking k8s master, we'll solve the dependency issues in the master branch. Then, we'll cut a client-go 3.0 when k8s release-1.6 occurs.

Has something actually changed about a public interface? We shouldn't bump
the major version number unless it's necessary.
On Wed, Jan 18, 2017 at 6:12 PM, Chao Xu<EMAIL_ADDRESS>wrote:

client-go release-2.0 is tracking k8s release-1.5 branch, where the
apimachinery moves hadn't occurred yet, so its API is stable.
client-go master branch is tracking k8s master, we'll solve the dependency
issues in the master branch. Then, we'll cut a client-go 3.0 when k8s
release-1.6 occurs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/70#issuecomment-273662322,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglt38a8aajn4T-5h43ZLJaBcv-FGiks5rTsZ1gaJpZM4LmOty
.

Also does that mean we should tag something as 2.0.0, so there's something
stable for users to grab?
On Thu, Jan 19, 2017 at 10:52 AM, Daniel Smith<EMAIL_ADDRESS>wrote:

Has something actually changed about a public interface? We shouldn't bump
the major version number unless it's necessary.
On Wed, Jan 18, 2017 at 6:12 PM, Chao Xu<EMAIL_ADDRESS>wrote:

client-go release-2.0 is tracking k8s release-1.5 branch, where the
apimachinery moves hadn't occurred yet, so its API is stable.
client-go master branch is tracking k8s master, we'll solve the
dependency issues in the master branch. Then, we'll cut a client-go 3.0
when k8s release-1.6 occurs.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/70#issuecomment-273662322,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglt38a8aajn4T-5h43ZLJaBcv-FGiks5rTsZ1gaJpZM4LmOty
.

I'm waiting for https://github.com/kubernetes/test-infra/pull/1733 to be merged. That will let the client-go/release-2.0 branch pick up the bug fixes merged to kubernetes/release-1.5, so that https://github.com/kubernetes/client-go/issues/66 will be solved. I plan to tag 2.0.0 after that.

I am also pretty confused with k8s.io/apimachinery/pkg/runtime vs k8s.io/client-go/pkg/runtime, are these two supposed to become one eventually or nobody should be using k8s.io/apimachinery yet?

Ok, looks like k8s.io/client-go/pkg/runtime is not part of this repo any more, I should probably stick to master.

runtime package is going to eventually live in k8s.io/apimachinery.
On Fri, Jan 27, 2017 at 11:26 PM, Ilya Dmitrichenko <
<EMAIL_ADDRESS>wrote:

Ok, looks like k8s.io/client-go/pkg/runtime is not part of this repo any
more, I should probably stick to master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/70#issuecomment-275832843,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAnglvUJUjR_S7KbzdaMvEcS7Xqv07_Zks5rWu2ugaJpZM4LmOty
.

Runtime is already partly living in k8s.io/apimachinery. We are working
through the k8s.io/kubernetes code base, detangling everything. Code which
has clean dependencies is moved of to the staging repos.
The consequence of this iterative approach is that we have to live with
half-finished transitions of packages for a while (pkg/api, pkg/runtime,
pkg/api/meta, pkg/util are promiment examples).
Rule of thumb:

use the code in k8s.io/apimachinery and k8s.io/apiserver
consider the k8s.io/kubernetes counterparts of half-finished packages as
legacy in their current location
avoid client-go/pkg/* as these are copies only.

Moreover, those packages needed by client-go are copied from
k8s.io/kubernetes into client-go (that's how client-go has been set up for
a number of months). That's why for the time being we still have a
client-go copy of this legacy generic code there. We are working towards
getting rid of this, leading to a much easier to understand packaging
structure again. This should answer your question, Ilya.
Best regards,
Stefan
On Sat, Jan 28, 2017 at 9:27 PM, Daniel Smith<EMAIL_ADDRESS>wrote:

runtime package is going to eventually live in k8s.io/apimachinery.
On Fri, Jan 27, 2017 at 11:26 PM, Ilya Dmitrichenko <
<EMAIL_ADDRESS>wrote:

Ok, looks like k8s.io/client-go/pkg/runtime is not part of this repo any
more, I should probably stick to master.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<https://github.com/kubernetes/client-go/issues/
70#issuecomment-275832843>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAnglvUJUjR_
S7KbzdaMvEcS7Xqv07_Zks5rWu2ugaJpZM4LmOty>

.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/kubernetes/client-go/issues/70#issuecomment-275872481,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAskC6vDZBsO3W6992q-Xhk6yYdcVzzZks5rW6S5gaJpZM4LmOty
.

Please take a look at the current README. Hopefully this is clearly documented at this point.


make service protection an option

For testing purposes it can be useful to trigger the install of kuadrant service protection manually. To support this I have added a var MGC_DEPLOY_SERVICE_PROTECTION it default to true and will install service protection by default. If false it will still install OLM but wont create a managedaddon resource to install kuadrant in the spoke clusters
Verfication
set the following envars on top of the normal quickstart
export MGC_BRANCH=optional-service-protection
export MGC_DEPLOY_SERVICE_PROTECTION=false
run the quick start.
verify the kuadrant-system namespace is not created and no managedclusteraddon resources are created.
install kuadrant service protection manually
create a catalogsource in the hub cluster
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: kuadrant-operator
  namespace: olm
spec:
  displayName: Kuadrant
  grpcPodConfig:
    securityContextConfig: restricted
  image: quay.io/kuadrant/kuadrant-operator-catalog:0.4.0-rc1
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 60m

create a managedclusteraddon resource in the managed cluster namespace
apiVersion: addon.open-cluster-management.io/v1alpha1
kind: ManagedClusterAddOn
metadata:
  annotations:
    addon.open-cluster-management.io/values: '{"CatalogSource":"kuadrant-operator", "Channel":"preview"}'
  name: kuadrant-addon
  namespace: kind-mgc-control-plane
spec:
  installNamespace: open-cluster-management-agent-addon

you should see kuadrant is now installed using the preview channel and new catalog source

👀

one suggestion to fix an error

export MGC_BRANCH=optional-service-protection
export MGC_DEPLOY_SERVICE_PROTECTION=false

kubectl --context kind-mgc-control-plane get managedclusteraddon -A
No resources found

kubectl --context kind-mgc-control-plane get operators kuadrant-operator -n kuadrant-system -o yaml
Error from server (NotFound): operators.operators.coreos.com "kuadrant-operator" not found

k  get ns kuadrant-system
Error from server (NotFound): namespaces "kuadrant-system" not found

Looks fine.
Not sure i totally understand the point of creating a separate quick start script now though if it has so many optional paths. I would have thought the point of it was it was simple and consistent in what it was doing.

yeah it is a fair point. Perhaps this is not actually needed. Instead to not use service protection you could follow the "existing cluster install"

closed as we don't actually need this after all and it increases the complexity of the quick start and testing it


Data process

Thank you for sharing your work！！I was stuck in the data preprocessing section while training,What are the files placed in the path ,split path and output in the data folder?

Hi @wenzhangqiao, thank you for your interest in our work!
Can you elaborate more on which part of the code are you interested in but confused about?

Thank you for sharing your work！！I was stuck in the data preprocessing section while training,What are the files placed in the path ,split path and output in the data folder?

Please，did you solve this problem？

Hi @wenzhangqiao, thank you for your interest in our work! Can you elaborate more on which part of the code are you interested in but confused about?

hi, he step of [Data Preparation]，i have followed https://github.com/wilburOne/ACE_ERE_Scripts and got the csv.
But about the next step: Save the event data into .txt files, process the .txt file and save as Torch TensorDataset, I don't know what you mean by "event data into .txt files" here, thanks!

Hi @wenzhangqiao, thank you for your interest in our work! Can you elaborate more on which part of the code are you interested in but confused about?

hi, he step of [Data Preparation]，i have followed https://github.com/wilburOne/ACE_ERE_Scripts and got the csv. But about the next step: Save the event data into .txt files, process the .txt file and save as Torch TensorDataset, I don't know what you mean by "event data into .txt files" here, thanks!

Hi @wenzhangqiao，感谢您对我们工作的关注！你能详细说明你对代码的哪一部分感兴趣但又感到困惑吗？嗨

，在[数据准备]的步骤中，我已经关注了https：//github.com/wilburOne/ACE_ERE_Scripts并获得了CSV。但关于下一步：将事件数据保存到.txt文件中，处理.txt文件并保存为Torch TensorDataset，我不知道你在这里所说的“事件数据到.txt文件”是什么意思，谢谢！

Hello,"Have you solved this problem yet?"


Fix the location of extra templates

fixes the issue #136

rerun tests

@asyedham Can you please explain what you are trying to do?

rerun tests

@asyedham the CI test is failing. please look that

@masco Fixed it

Closing this as we no longer use firstboot.yml playbook


[SPARK-34060][SQL][FOLLOWUP] Preserve serializability of canonicalized CatalogTable

What changes were proposed in this pull request?
Replace toMap by map(identity).toMap while getting canonicalized representation of CatalogTable. CatalogTable became not serializable after https://github.com/apache/spark/pull/31112 due to usage of filterKeys. The workaround was taken from https://github.com/scala/bug/issues/7005.
Why are the changes needed?
This prevents the errors like:
[info]   org.apache.spark.SparkException: Job aborted due to stage failure: Task not serializable: java.io.NotSerializableException: scala.collection.immutable.MapLike$$anon$1
[info]   Cause: java.io.NotSerializableException: scala.collection.immutable.MapLike$$anon$1

Does this PR introduce any user-facing change?
Should not.
How was this patch tested?
By running the test suite affected by https://github.com/apache/spark/pull/31112:
$ build/sbt -Phive-2.3 -Phive-thriftserver "test:testOnly *AlterTableDropPartitionSuite"

Test build #134107 has started for PR 31197 at commit 81d6786.

Test build #134107 has started for PR 31197 at commit 81d6786.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38691/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38691/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38691/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38691/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/38691/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/38691/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134107/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134107/

Test build #134124 has started for PR 31197 at commit d26ea30.

Test build #134124 has started for PR 31197 at commit d26ea30.

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38707/

Kubernetes integration test starting
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38707/

According to the original patch, do we need this for master/3.1/3.0 ...

@dongjoon-hyun Yes

According to the original patch, do we need this for master/3.1/3.0 ...

@dongjoon-hyun Yes

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38707/

Kubernetes integration test status failure
URL: https://amplab.cs.berkeley.edu/jenkins/job/SparkPullRequestBuilder-K8s/38707/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/38707/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder-K8s/38707/

Test build #134124 has finished for PR 31197 at commit d26ea30.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #134124 has finished for PR 31197 at commit d26ea30.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134124/

Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/134124/

Thank you, @MaxGekk . Merged to master/3.1/3.0.

Thank you, @MaxGekk . Merged to master/3.1/3.0.

Do you think if we can have a way for us to prevent this kind of regression, @cloud-fan , @HyukjinKwon , @MaxGekk ?

Do you think if we can have a way for us to prevent this kind of regression, @cloud-fan , @HyukjinKwon , @MaxGekk ?

Also, cc @gatorsmile

Also, cc @gatorsmile

I think it's a bug fixed in Scala 2.13. Once we upgrade, it will prevent permanently I guess.

I think it's a bug fixed in Scala 2.13. Once we upgrade, it will prevent permanently I guess.

I think we cannot drop 2.12 easily in Apache Spark 3.x line like Hadoop 2.7.x.

I think we cannot drop 2.12 easily in Apache Spark 3.x line like Hadoop 2.7.x.


Headless Chrome is slow with canvas without --disable-gpu

Puppeteer v1.7.0 doesn't include --disable-gpu by default on OS X when launching
healdess browser.
On my MacBook Pro 2017, the following script yields 10x time difference between two launches: with and without --disable-gpu flag. it is much faster to run with --disable-gpu.
We should either fix --disable-gpu upstream or bring it back by default.
const pptr = require('puppeteer');

(async () => {
  const browser = await pptr.launch({
    //args: ['--disable-gpu'],
  });
  const page = await browser.newPage();
  await page.setContent(`
    <canvas width=800px height=800px></canvas>
  `);

  console.time('eval');
  await page.$eval('canvas', canvas => {
    const ctx = canvas.getContext('2d');
    ctx.setTransform(2, 0, 0, 2, 0, 0);
  });
  console.timeEnd('eval');
  await browser.close();
})();

This is fixed in Puppeteer v1.8.0.


Fix FrozenError in ws-server.rb

Launching examples/SimpleTest/ws-server.rb and tap 'Write Text' on the test iPhone app, following log are printed by ws-server.rb and the connection is closed with an error:
$ ruby ws-server.rb
WebSocket connection open
origin: http://localhost:8080
headers: {"Host"=>"localhost:8080", "Sec-WebSocket-Version"=>"13", "Sec-WebSocket-Extensions"=>"permessage-deflate; client_max_window_bits; server_max_window_bits=15", "Origin"=>"http://localhost:8080", "Connection"=>"Upgrade", "Sec-WebSocket-Key"=>"cnhidXdpaW9wYnlpc2htcw==", "Upgrade"=>"websocket"}
message from client: hello there!
[error] can't modify frozen String
Connection closed

By commenting out the error handler, I got details:
$ ruby ws-server.rb
WebSocket connection open
origin: http://localhost:8080
headers: {"Connection"=>"Upgrade", "Upgrade"=>"websocket", "Host"=>"localhost:8080", "Origin"=>"http://localhost:8080", "Sec-WebSocket-Key"=>"bGZ3cWJ0b3dzYmVycnNwcA==", "Sec-WebSocket-Version"=>"13", "Sec-WebSocket-Extensions"=>"permessage-deflate; client_max_window_bits; server_max_window_bits=15"}
message from client: hello there!
Connection closed
Traceback (most recent call last):
	10: from ws-server.rb:4:in `<main>'
	 9: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in `run'
	 8: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/eventmachine-1.2.7/lib/eventmachine.rb:195:in `run_machine'
	 7: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/em-websocket-0.5.1/lib/em-websocket/connection.rb:76:in `receive_data'
	 6: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/em-websocket-0.5.1/lib/em-websocket/handler.rb:47:in `receive_data'
	 5: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/em-websocket-0.5.1/lib/em-websocket/framing07.rb:118:in `process_data'
	 4: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/em-websocket-0.5.1/lib/em-websocket/message_processor_06.rb:52:in `message'
	 3: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/em-websocket-0.5.1/lib/em-websocket/connection.rb:18:in `trigger_on_message'
	 2: from ws-server.rb:22:in `block (3 levels) in <main>'
	 1: from /Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/em-websocket-0.5.1/lib/em-websocket/connection.rb:161:in `send_text'
/Users/ohara/.rbenv/versions/2.6.1/lib/ruby/gems/2.6.0/gems/em-websocket-0.5.1/lib/em-websocket/connection.rb:161:in `force_encoding': can't modify frozen String (FrozenError)

The reason of this is trying to modify an immutable string.
This PR resolve this issue by making a mutable copy of the immutable string.

Thanks @yamoridon !


Duplicate Wiki create during clone process

Hi @alexc-MSFT we have deployed the Request a Team app and have noticed that duplicate wiki's are being created when we clone an existing team even though the source channel has a single wiki.  The first wiki tab errors out with 'We're having trouble with showing your Wiki right now. Please try again later.' when you click on it, the second wiki tab seems to configure when you click on it.

Thanks

@SPB21 Yes i too even got the same issue. Reported the same to @alexc-MSFT  He is looking into the issue.


Electron 1.8 is out

Time to upgrade! :)

Sweet!
@chabou:  Did more testing with dependabot: https://github.com/MindTooth/hyper/pulls?q=is%3Apr+is%3Aclosed
They all merge with success on Travis.  It pulled in 20 updates.

@MindTooth Thank you very much for your insights. We definitely need to decide to use something like this!


Adding tenantId

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[v] Other, please clarify - adding missing field to one of new connectors

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific langauge SDKs and CLIs that must be refreshed after the swagger is published.

[v] SDK of .NET (need service team to ensure code readiness)
[v] SDK of Python
[v] SDK of Java
[v] SDK of Js
[v] SDK of Go
[v] PowerShell
[v] CLI
[v] Terraform
[] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

/azp run


Palindrome using stacks

Hi!
In the above issue by using the concept of stacks we can check whether string is palindrome or not.
Please can you assign me the issue. @avinash201199

They are not considering dsa,cp,algorithm repository :(
all the pr will not be considered in hacktoberfest but your contribution will be for lifetime, this will help many students to practice dsa .
Thank you for your contribution :)

He bro please assign this problem to me .
Because i already solved this

Added to the repository successfully!


Error with Prisma v18.2: can't find prisma.schema

I updated Prisma version from 18.1 to 18.2, and then try to deploy Prisma to zeit/now and got an error.
$ prisma2 generate
$ Error: Can't find schema.prisma
$ error Command failed with exit code 1.

The most interesting thing is that this is not a call of prisma2 generate from my package.json, but a call somewhere from a Prisma.
Does Prisma has its own postinstall hook for prisma2 generate? Because it is called immediately after the dependencies of another package are installed.

Hey @ephor, thanks for your issue. Do you get this output during the deployment itself? Can you share more context, so we can understand what is triggering it?

Installing build runtime...
Build runtime installed: 579.839ms
Installing build runtime...
Looking up build cache...
Build runtime installed: 650.919ms
Looking up build cache...
Build cache found [238.64 kB, 908 files]
Build cache unpacked: 766.049ms
Installing dependencies...
yarn install v1.17.3
Build cache found [79.29 MB, 23609 files]
Build cache unpacked: 3174.690ms
[1/4] Resolving packages...
Installing dependencies...
[2/4] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/api ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^3.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/api > graphql-yoga ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/api > graphql-yoga ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>|| ^0.11.3 || ^0.12.0 || ^0.13.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > @babel/plugin-proposal-nullish-coalescing-operator ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > @babel/plugin-proposal-optional-chaining ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.3 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > next ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/api > graphql-yoga > apollo-server-express ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>|| ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > apollo-boost > apollo-link-error ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/api > graphql-yoga > apollo-server-express > apollo-server-core ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>- 0.13.x".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/api > graphql-yoga > apollo-server-express > apollo-server-core ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>- 0.13.x".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/api > graphql-yoga > apollo-server-express > apollo-server-core ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>- 0.13.x".
warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-f99d7ae8-a3d5-479f-98ba-7d5efc98be39 > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency "graphql@*".
[4/4] Building fresh packages...
success Saved lockfile.
$ prisma2 generate
Error: Can't find schema.prisma
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
Error: Exited with 1
    at ChildProcess.child.on (/zeit/922cd6377aef4b37/.build-utils/.builder/node_modules/@now/next/dist/index.js:46408:24)
    at emitTwo (events.js:126:13)
    at ChildProcess.emit (events.js:214:7)
    at maybeClose (internal/child_process.js:925:16)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:209:5)
worker exited with code 20 and signal null
yarn install v1.17.3
[1/4] Resolving packages...
[2/4] Fetching packages...
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
info<EMAIL_ADDRESS>The platform "linux" is incompatible with this module.
info<EMAIL_ADDRESS>is an optional dependency and failed compatibility check. Excluding it from installation.
[3/4] Linking dependencies...
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/api ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^3.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/api > graphql-yoga ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/api > graphql-yoga ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>|| ^0.11.3 || ^0.12.0 || ^0.13.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > @babel/plugin-proposal-nullish-coalescing-operator ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > @babel/plugin-proposal-optional-chaining ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.3 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > apollo-boost ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > next ><EMAIL_ADDRESS>has unmet peer dependency "<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/api > graphql-yoga > apollo-server-express ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>|| ^0.10.0 || ^0.11.0 || ^0.12.0 || ^0.13.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > apollo-boost > apollo-link-error ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>|| ^0.12.0 || ^0.13.0 || ^14.0.0".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/api > graphql-yoga > apollo-server-express > apollo-server-core ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>- 0.13.x".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/api > graphql-yoga > apollo-server-express > apollo-server-core ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>- 0.13.x".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/api > graphql-yoga > apollo-server-express > apollo-server-core ><EMAIL_ADDRESS>has incorrect peer dependency<EMAIL_ADDRESS>- 0.13.x".
warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web > react-apollo ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency<EMAIL_ADDRESS>warning "workspace-aggregator-8e330a2f-4a1e-4bbc-89b8-1ffb60292aec > @xxxxxx/web ><EMAIL_ADDRESS>has unmet peer dependency "graphql@*".
[4/4] Building fresh packages...
success Saved lockfile.
$ [ "$RUN_POSTINSTALL" = 'true' ] && yarn generate:safe && npm run migrate:safe && npm run seed:safe || exit 0
yarn run v1.17.3
$ [ "$RUN_GENERATE" = 'true' ] && yarn generate:prisma && yarn generate:nexus || exit 0
$ yarn run prisma2 generate --schema prisma/schema.prisma
$ /zeit/4f910dfe/node_modules/.bin/prisma2 generate --schema prisma/schema.prisma

Generating Photon.js to ./../../node_modules/@prisma/photon
Done in 6.29s

$ ts-node --transpile-only src/schema
Done in 9.54s.
npm WARN lifecycle The node binary used for scripts is /tmp/yarn--1576247419506-0.42899090107247306/node but npm is using /node10/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

><EMAIL_ADDRESS>migrate:safe /zeit/4f910dfe/apps/api
> [ "$RUN_MIGRATIONS" = 'true' ] && yarn migrate || exit 0

yarn run v1.17.3
$ yarn run prisma2 lift up
$ /zeit/4f910dfe/node_modules/.bin/prisma2 lift up
🏋 lift up

All migrations are already applied
Done in 4.59s.
npm WARN lifecycle The node binary used for scripts is /tmp/yarn--1576247419506-0.42899090107247306/node but npm is using /node10/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

><EMAIL_ADDRESS>seed:safe /zeit/4f910dfe/apps/api
> [ "$RUN_SEEDS" = 'true' ] && yarn seed || exit 0

yarn run v1.17.3
$ ts-node prisma/seed
{ user1:
   { id: 'ck448gm1s0000rzrgchmhuwun',
     email<EMAIL_ADDRESS>     password:
      '$2b$10$ZjONRZAxqX2pLoPax2xdcuzABTUEsFanQI6yBYCRtzpRiU4/X1uIu',
     name: 'Alice' },
  user2:
   { id: 'ck448gn1o0002rzrgigbyf0y6',
     email<EMAIL_ADDRESS>     password:
      '$2b$10$o6KioO.taArzboM44Ig85O3ZFZYZpR3XD7mI8T29eP4znU/.xyJbW',
     name: 'Bob' } }
Done in 4.92s.
Done in 57.86s.
Using TypeScript 3.7.3 (local user-provided)
Error: apps/api/src/generated/nexus.ts(13,11): error TS2304: Cannot find name 'NexusPrisma'.
apps/api/src/generated/nexus.ts(14,12): error TS2304: Cannot find name 'NexusPrisma'.

Build completed. Populating build cache...
Build cache uploaded [79.28 MB]: 1407.844ms
done
done```

Looks like you are using yarn workspaces. Can you please tell me whether prisma2 is installed in the root or it is installed as a dependency of a subpackage
We need to test the monorepo deployment setup with zeit and prisma2.

@pantharshit00 I ran into the same issue and am also using yarn workspaces and building on zeit/now. For me, prisma2 was installed in the root. I will try to see if using the nohoist option from workspaces fixes the issue.

Can you please tell me whether prisma2 is installed in the root or it is installed as a dependency of a subpackage

it is installed as a dependency of a subpackage

How to fix this?

I've added the following to now.json and seems to be working with 2.0.0-preview019:
{
  "build": {
    "env": {
      "NOW_BUILDER": ""
    }
  }
}

Hi,
I tried reproducing this but I was unable to do so. I was successfully able to deploy and it is working fine: https://prisma2-yarn-monorepo.now.sh/
Here is the code that I used: https://github.com/harshit-test-org/prisma2-zeit-now-yarn-workspace
I didn't used the above workaround. So someone can please point me to a working reproduction of this.

Here's a minimal reproduction repo:
https://github.com/dimitarnestorov/next-prisma-monorepo

I looked at your reproduction, you are executing the generate command with frontend as cwd:
// packages/frontend/package.json
"scripts": {
    "dev": "next",
    "build": "yarn workspace backend generate && next build",
    "start": "next start"
  },

Our CLI tries to resolve schema.prisma from cwd, when this command is executed, it tries to look for schema file in frontend directory. Instead, run this from the backend folder instead.

Ah yes, you're using process.env.INIT_CWD. What's your opinion on switching to process.cwd()?

@pantharshit00 I will send you a repro tomorrow.

Ah yes, you're using process.env.INIT_CWD. What's your opinion on switching to process.cwd()?

We actually try to resolve using process.cwd() giving it the first preference. Looks like now handles the command execution differently so these values are assigned different there.
Source code of our resolution logic:
https://github.com/prisma/prisma2/blob/d81ff142fcef145cde896ac9e914cfe43089ecc0/cli/cli/src/getSchema.ts#L14

I will send you a repro tomorrow.
Thanks @momakes :)

Alright, dialed it back a notch.
I just added a postinstall script on the backend to run prisma2 generate and got the same issue. Updated https://github.com/dimitarnestorov/next-prisma-monorepo

https://github.com/momakes/prisma0182-monorepo-bug

Ok, I can confirm this bug now. I was reproducing this and wasn't able to remove the postinstall hook no matter what. Then I checked the code and sure enough we were mutating the package.json when NOW_BUILDER is set. So I talked internally on why we are doing this and explanantion is as following:
Now caches the node_modules folder. Then on every deploy they reexecute yarn install. If there was no change in the package.json, the posinstall hook of Photon doesn’t get reexecuted. Therefore, if we are in a Now environment, we add prisma2 generate to the postinstall hook of the users main package.json to fix this behavior. We also created an issue in yarn to track this: https://github.com/yarnpkg/yarn/issues/7762
We should just make this thing fail silently and fix this workspace bug. For now you can opt out of this behaviour by setting NOW_BUILDER to "" as pointed out by @dimitarnestorov above. Thanks everyone for having patience on this 🙌


Added actions from #57321 to the 'No Settings Found'-message

This PR contains a first suggestion for adding the two actions for clearing all filters and clearing the search to the 'No Settings Found'-message on the settings-search as described in #57321.
The first one is only shown, if there are actually any filters active. The second one is always shown.
I am not sure how to deal with the translations here, since I was not able to find similar, already translated texts I added new ones. If this is not the correct way, please help me here.
As I am new to the codebase I am also not sure, whether the approach with the disposables array is the right one. Is there any documentation about the life cycle of the editor parts available?

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.:x: NiclasvanEyk sign nowYou have signed the CLA already but the status is still pending? Let us recheck it.


Example for Sprite

Hey,
I don't really like using this place for help and not bugs etc... but I'm really struggling get a sprite to display. Does someone have an example of working with a simple sprite?
Currently I have something similar to:
<sprite visible={true} position={new THREE.Vector3(0, 0, 0)} key={"sprite_" + index}>
    <spriteMaterial side={THREE.DoubleSide} color={0xffffff}>
        <texture url={element.image} />
    </spriteMaterial>
</sprite>

I don't get any errors, but the sprite doesn't appear at all. The url is a valid url and works fine on a meshBasicMaterial on a plane.
Any help would be great.
------- EDIT -------
I get an error in chrome console that mentions:
THREE.WebGLRenderer: Texture marked for update but image is incomplete

Not sure if that is related at all?

There is an example of sprite use with react-three-renderer in this stackoverflow question
https://stackoverflow.com/questions/39236107/sprite-labels-with-react-three-renderer-mvce-included


ARROW-6335: [Java] Improve the performance of DictionaryHashTable

when comparing two entries in the dictionary hash table, it is more efficient to compare the index directly, rather than using Objects.equals, because they are both ints.

Codecov Report

Merging #5178 into master will increase coverage by 2.38%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #5178      +/-   ##
==========================================
+ Coverage   87.36%   89.75%   +2.38%
==========================================
  Files         909      682     -227
  Lines      122252   101825   -20427
  Branches     1437        0    -1437
==========================================
- Hits       106807    91394   -15413
+ Misses      15083    10431    -4652
+ Partials      362        0     -362

Impacted Files
Coverage Δ

r/src/recordbatch.cpp

r/R/Table.R

go/arrow/math/uint64_amd64.go

r/src/symbols.cpp

rust/datafusion/src/execution/projection.rs

rust/datafusion/src/execution/filter.rs

rust/arrow/src/csv/writer.rs

rust/datafusion/src/bin/main.rs

go/arrow/ipc/file_reader.go

js/src/builder/index.ts

... and 518 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6cbaf72...0769c3c. Read the comment docs.

+1, thanks.


Add ability to change advertise IP.

This PR implements ability to change advertise IP of a single-cluster node. This allows users implement scenarios where they want to deliver their pre-installed and pre-configured clusters as a full virtual appliance such as Amazon AMI or VMWare OVF/OVA.
How it works
It introduces a new operation which I called "reconfigure" (potentially, it can also be used to reconfigure more stuff than just IP/hostname). It comes with its own plan/FSM/etc and is basically a lightweight install that runs on top of the existing cluster state and regenerates all configuration and secrets, then starts all services. Runtime/application phases are not executed b/c everything has been installed during original install (and is kinda the point of this feature).
The hard part was figuring out all the stuff that needs to be repaired on the node in order to accommodate the changed IP address. I've split those in two phases - "pre-cleanup" which is executed right away before reconfiguring anything, and "post-cleanup" which fixes stuff once we have Kubernetes. Things like removing lingering network interfaces, cleaning up old packages in both local and cluster states, recreating pods and so on. I tried to put proper descriptions on respective phase executors to explain what they do and why.
Implementation notes
I tried to take as many shortcuts as I could to keep it simple. For example, since we're dealing with a single-node, there's no agent and everything runs locally. Also, since "reconfigure" is basically a lightweight "install" operation, it reuses a lot of the installer logic, plan generation and so on.
Additional
Also introduced a couple of new commands:
$ gravity system stop [--disable]
$ gravity system start [--enable]

which stop/start our systemd services on the node. For convenience as they're needed for reconfiguration (see the included docs for more info).

@a-palchikov @knisbet Think I've addressed all/most of your guys feedback and the feedback I got from the product team. See the latest commit if you're interested in the changes but here's the gist of stuff worth mentioning:

UX changed a bit. There's no gravity reconfigure command anymore - instead, a user uses gravity start --advertise-addr=xxx command to start the node with a new IP. Under the hoods it still does the "reconfigure" operation. Also, the stop command is just gravity stop now (not a system subcommand).
No more requirement to have the original installer present on the node.
Fixed bad progress output that would duplicate timestamps.
Fixed an issue with installer intermittently failing to connect to the process.
Originally I used to use the "site-export" package to determine the state of the cluster in the absence of the running cluster, which is problematic for numerous reasons. Now I've changed this to instead have the process periodically sync its cluster state to the local backend and use that.

@knisbet - with IP address not being present on the node - this is actually checked for and if I give --advertise-addr=<IP_ADDRESS> on my machine, it correctly returns an error. If it still happens for you (or if I misunderstood the issue), might be worth investigating.

@r0mant Also, the corresponding enterprise PR seems to be missing.


parameters.yml not symlinked on FreeBSD

I just updated a symfony app that used capifony with capistrano 2.
I use all the default values without adding parameters.yml to the :linked_files.
For some reason the symlink is not created. The app will deploy and use the non-shared file under app/config/parameters.yml.
The command is executed:
Running /usr/bin/env [ -f /usr/local/www/apache24/noexec/foobar/shared/app/config/parameters.yml ] as<EMAIL_ADDRESS>DEBUG [95af9b97] Command: [ -f /usr/local/www/apache24/noexec/foobar/shared/app/config/parameters.yml ]
The following message is used by Symfony itself, not Capistrano, I think:
> Incenteev\ParameterHandler\ScriptHandler::buildParameters
DEBUG [a9e4aa32] 	Creating the "app/config/parameters.yml" file
When I add :linked_files as mentioned in https://github.com/capistrano/symfony/issues/11#issuecomment-44615251:
set :linked_files, [fetch(:app_path) + '/config/parameters.yml']

I get:
Incenteev\ParameterHandler\ScriptHandler::buildParameters
Script Incenteev\ParameterHandler\ScriptHandler::buildParameters handling the post-install-cmd event terminated with an exception

  file_put_contents(app/config/parameters.yml): failed to open stream: Permission denied

Are there any sepcial privileges to allow symlinking? Does the :webserver_user require sudo?
Never had problems with the default configuration on Debian. Maybe this is a FreeBSD issue. For instance there is no www-data User or group on this server. The group is vuser.
I've encountered many problems with Capistrano with FreeBSD. Problems with setfacl (https://github.com/capistrano/symfony/issues/40), default bash (https://github.com/capistrano/symfony/issues/24) and others. Maybe there is a problem with symlinks in general too:
http://www.freebsddiary.org/ln.php

Did you configure these settings accordingly :
# Name used by the Web Server (i.e. www-data for Apache)
set :file_permissions_users, ['www-data']

# Name used by the Web Server (i.e. www-data for Apache)
set :webserver_user,        "www-data"

?

The directory on our FreeBSD server have the vuser group by default, not the typical apache www-data. This is the config I tried:
# Name used by the Web Server (i.e. www-data for Apache)
set :file_permissions_users, ['vuser']

# Name used by the Web Server (i.e. www-data for Apache)
set :webserver_user,        "foobar"

set :permission_method,     :acl
set :use_set_permissions,   true

What are the requirements for user and group to make it work? I could ask our provider about the best settings.

set :webserver_user,        "foobar"

Why isn't it vuser ?

What are the requirements for user and group to make it work? I could ask our provider about the best settings.

I don't know, I banged my head myself with a similar ACL issues the other day, and decided to limit the use of ACLs through capistrano to the cache directory, which is the only www-data-writable-dir that is not linked in shared.

The provider suggest to use web instead of www-data:
# Name used by the Web Server (i.e. www-data for Apache)
set :file_permissions_users, ['web']

# Name used by the Web Server (i.e. www-data for Apache)
set :webserver_user,        "web"

The symlinks seem to work. Unfortunately I get a permission error:
> Incenteev\ParameterHandler\ScriptHandler::buildParameters
Script Incenteev\ParameterHandler\ScriptHandler::buildParameters handling the post-install-cmd event terminated with an exception

  [ErrorException]
  file_put_contents(app/config/parameters.yml): failed to open stream: Permission denied

What kind of permissions are need here? As I mentioned I can't run acl for setting permissions - siee issue https://github.com/capistrano/symfony/issues/40.

At the bottom line I switch to chmod using my regular user I use for SSH auth. No need to switch to web then. But some other issues with permissions on the cache folder and logs/prod.log.
I recently changed them to 0777 to be able to deploy.
Acl can not be used on FreeBSD with the current command:
SYMFONY_ENV=prod /usr/bin/env setfacl -Rm

setfacl: illegal option -- R
I will create a new issue on the capistrano project.


Combine .js and .css into one folder, make per-website stuff into folders to allow bundling of themes

Title says almost all - I want to set up things like ~/.firefox/facebook.com/ with the folder containing a main.js and a main.css etc for easy and convenient theme bundling.
I know this is a little beyond the initial scope of the extension, but the recent addition of css made things a little unwieldy if you're trying to tie stuff together.

Also useful if you want to keep multiple .js files separated by functionality.

hmmm, so it would just load in all .js and .css files it finds in the folder? What about the order to load them in?

Alphabetical order sounds good enough. You can always prefix the file names ... 01-something.js, 02-something-else.js ...

I would like to work on this. Can someone point in the right direction?


Emmet CSS # character

VSCode Version: 1.30.1
OS Version: Windows 10 Pro x64

Emmet doesn't works correct after trying to type character #.
Steps to Reproduce:

Type bd1#s.
Press Tab.

Emmet must type border: 1px #000 solid;, but it doesn't.

Does this issue occur when all extensions are disabled?: Yes

Is this a valid emmet abbreviation? Can you point me to the docs?

https://docs.emmet.io/css-abbreviations/
Yes, check the first paragraph in Color values section. There is similar expression: bd5#0s. It does not works too in the editor.

OK, it seems to work that way in Atom...

Please make a normal "emmet" in css files.
When i write dib, then should write display: inline-block and now it is writing box-decoration-break:
and so with many rules.

@RiodeJaneiroo Are you on insider version by any chance? It seems this is broken in Insiders but not 1.31.1.

@octref no, stable version. This setting helped me
{   "key": "tab",   "command": "-acceptSelectedSuggestion" }

This issue was already started in december 2018 on version 1.30.1.
It's now 5th of june 2019 and we're in version 1.34.0 of VS Code, but unfortunately emmet abbreviations like 'bd1#s' still don't work in VS Code.
It would be nice if this could get some love and attention, because these css emmet abbreviation really speed up the workflow of a front-end developer a lot and so are very welcome! Thanks!

I have confirmed that vscode-emmet-helper can now expand the abbreviation properly, but I think there's still an issue with some code in this repo, so I can't call this fixed yet.

I have confirmed that vscode-emmet-helper can now expand the abbreviation properly, but I think there's still an issue with some code in this repo, so I can't call this fixed yet.

Created a PR https://github.com/microsoft/vscode-emmet-helper/pull/46 fixing this

Created a PR microsoft/vscode-emmet-helper#46 fixing this

Thanks!


Test with kitchen-dokken and be explicit about the required Chef version

Test in travis with kitchen-dokken and the latest chef/chef docker image.

Assuming the tests all pass this should be good for a review @tduffield @schisamo @scotthain


Hover over bars in threshold filtering and see those values (genetic distances)

As a User I want to be able to hover of the bars in the filtering threshold so I  can see those distances and know which ones to select more easily.
##Acceptance Criteria
Given a fasta file of sequencers, a newick file, or distance matrix and go to the filtering threshold in global settings, I want to hover my pointer over a bar in the histogram and see what that distance is without clicking on the bar.
This would require moving the pop-up message that shows what the filtering threshold is for.

See issue https://github.com/CDCgov/MicrobeTrace/issues/617

@roxycintron @mossy426 , this feature works for me with both TN93 as well as SNP edgelists.  I am able to hover over histogram and change thresholds successfully. This is in PROD- just tried it.

In DEV/PROD, if the file is a node list with aligned sequences and you use TN93, then it doesn't work. I confirmed it's working with SNP edge list. Will need to test all file types again after bug fix.


Add option to wrap model.createRecord in runloop

Summary
This PR adds the ability for users to opt into wrapping a model.createRecord in an Ember run loop. This is to avoid this error: "You have turned on testing mode, which disabled the run-loop's autorun." encountered in older versions of Ember.
Changes

Added a Codeshift options section to the documentation to explain how to use the new option, what it does, and why you might need to use it
Added the ability to pass in jscodeshift options for a test. This is done via an input test naming convention - the-test-name.option1=foo.option2=bar.input.js
Cleaned up the code a bit in the createModel section so its easier to read. This was accomplished by putting the nested 'j' calls in a named functions, and then calling those functions later.

p.replace(createRecordExpression(createRecordArg));

// instead of
p.replace(
  j.callExpression(
    j.memberExpression( //....
 ));

Dependencies
Depends on and branched off of #116

what do you think about having something like a setup-model-test2.options.json file instead of encoding the options in the filenames?


[Function worker] Load ServiceConfiguration from file, not from Worke…

…rConfig
Motivation
Currently, it is not possible to pass custom configuration to a function worker for use in an Authentication or Authorization plugin. In order to support plugins created by end users, we need to make sure that configurations passed in at function worker initialization are passed through to the ServiceConfiguration. This PR seeks to make it possible to pass in those arbitrary configurations.
Modifications
Update the FunctionWorkerStarter class to generate the ServiceConfiguration by reading it in from a file instead of building the class by converting the WorkerConfig to the ServiceConfiguration.
Alternative Solution
We could also change how we generate the WorkerConfig. It is currently created by reading the config file into the class using an ObjectMapper. This does not really follow the general paradigm that Pulsar uses to generate config classes (at least the paradigm that I've noticed) where we use the PulsarConfigurationLoader class to load a config from a file. However, I am not sure that we want to remove the WorkerConfig.load method, given that it appears well tested.
I'm open to this solution as well. Please let me know what you think.
Verifying this change
There are not currently tests validating this configuration logic. I'm happy to add a test, but I'm not sure where to add it. Please let me know how to proceed here.
Note that the only change in behavior here is that the ServiceConfiguration class will now have fields that were not present in the WorkerConfig. Previously, these fields would have been dropped when we created the WorkerConfig. As such, while this change will technically introduce changes to the configuration in the ServiceConfiguration class, it is only changing configuration for fields not present in the WorkerConfig.
Additionally, one potential difference could also come from differences in default values between the WorkerConfig and the ServiceConfiguration. There could be conflicts now, or in the future, that could make it confusing to figure out which configuration is actually applied. This might be worth adding test coverage.
Note, also, that the ServiceConfigruation added in this PR is only used to configure the AuthenticationService and the AuthorizationService.
Does this pull request potentially affect one of the following parts:
If yes was chosen, please highlight the changes

Dependencies (does it add or upgrade a dependency): no
The public API: no
The schema: no
The default values of configurations: possibly
The wire protocol: no
The rest endpoints: no
The admin cli options: no
Anything that affects deployment: yes (custom configuration)

Documentation
For contributor
For this PR, do we need to update docs?
I don't think additional documentation is needed because I think this change will make pulsar's configuration work as expected.
For committer
For this PR, do we need to update docs?

If yes,

if you update docs in this PR, label this PR with the doc label.

if you plan to update docs later, label this PR with the doc-required label.

if you need help on updating docs, create a follow-up issue with the doc-required label.

If no, label this PR with the no-need-doc label and explain why.

@freeznet @nlu90 please review it when you have time.

@eolivelli - thanks for your feedback. I should be able to add tests tomorrow or Friday.

How about add the missing fields into the WorkerConfig?

How about add the missing fields into the WorkerConfig?

@nlu90 - this isn't an option because the fields are for extensions created by users. Note that the ServiceConfigruation already has a map for arbitrary config. The WorkerConfig does not have this map. An alternate solution could instead add the map to the WorkerConfig, but I'm not sure how that would impact a function worker's runtime.

/pulsarbot run-failure-checks

@jerrypeng @srkukarni @freeznet @nlu90 - PTAL. This change lets users configure function workers with custom configs that are not members of the WorkerConfig class. Thanks.

First of all, this ticket should be marked as doc-required as it introduces a different behavior to load customized settings.
Secondly, the worker is designed to load settings from the worker file config, not from the broker file config. I don't think we should change the constructor to pass in another broker service configuration object. Why can't we access the underlying key/value map from the worker config object?

@sijie
I agree that this patch must be marked with release/note-required as it is an important change to be noted.
IIUC this patch here are are not reading the broker.conf file, but we are reading the worker configuration file using ServiceConfiguration.
The previous approach was to reconstruct the ServiceConfiguration from the workerConfig
    private ServiceConfiguration getServiceConfiguration() {
        ServiceConfiguration serviceConfiguration = PulsarConfigurationLoader.convertFrom(workerConfig);
        serviceConfiguration.setClusterName(workerConfig.getPulsarFunctionsCluster());
        return serviceConfiguration;
    }

So the behaviour should be the same and in the future we won't be able to maintain the PulsarConfigurationLoader.convertFrom(workerConfig) conversion.

@sijie and @nlu90 - I've answered your questions below.

First of all, this ticket should be marked as doc-required as it introduces a different behavior to load customized settings.

This change makes it possible to load customized settings for the AuthenticationService and the AuthorizationService. It only affects these classes and the classes they load (like custom plugins). It does not introduce a different behavior, but rather fixes the missing ability to add custom settings to the properties map in the ServiceConfiguration object. In all other pulsar components, the ServiceConfiguration is loaded so that the properties map contains all custom fields from the loaded yaml config file.

Secondly, the worker is designed to load settings from the worker file config, not from the broker file config. I don't think we should change the constructor to pass in another broker service configuration object.

This PR does not change which file is loaded. It only changes how the ServiceConfiguration object is constructed.

Why can't we access the underlying key/value map from the worker config object?

We cannot access the key/value map from the worker config because of how the WorkerConfig is initialized. The FunctionWorkerStarter reads in the yaml file and converts it to a WorkerConfig object by calling WorkerConfig.load(workerArguments.configFile);. The load method is defined here:
    public static WorkerConfig load(String yamlFile) throws IOException {
        if (isBlank(yamlFile)) {
            return new WorkerConfig();
        }
        ObjectMapper mapper = new ObjectMapper(new YAMLFactory());
        return mapper.readValue(new File(yamlFile), WorkerConfig.class);
    }

This is the only implementation of the PulsarConfiguration interface that uses an ObjectMapper to convert the yaml into the object. The only fields that are deserialized and populated into the WorkerConfig are fields that are explicitly named in the WorkerConfig class. The properties map in the WorkerConfig is empty. The other PulsarConfiguration implementations are initially loaded by calling a method from the PulsarConfigurationLoader class. That class's underlying logic is to read all fields from the configuration yaml into the Properties map and then it uses reflection to properly populate any fields of the config class that share the same name as keys in the properties object.
As @eolivelli pointed out, the current workflow for constructing the ServiceConfiguration was to use the PulsarConfigurationLoader method named convertFrom. This method maps declared fields to declared fields as follows:
    public static ServiceConfiguration convertFrom(PulsarConfiguration conf, boolean ignoreNonExistMember) throws RuntimeException {
        try {
            final ServiceConfiguration convertedConf = ServiceConfiguration.class.newInstance();
            Field[] confFields = conf.getClass().getDeclaredFields();
            Arrays.stream(confFields).forEach(confField -> {
                try {
                    Field convertedConfField = ServiceConfiguration.class.getDeclaredField(confField.getName());
                    confField.setAccessible(true);
                    if (!Modifier.isStatic(convertedConfField.getModifiers())) {
                        convertedConfField.setAccessible(true);
                        convertedConfField.set(convertedConf, confField.get(conf));
                    }
                } catch (NoSuchFieldException e) {
                    if (!ignoreNonExistMember) {
                        throw new IllegalArgumentException("Exception caused while converting configuration: " + e.getMessage());
                    }
                } catch (IllegalAccessException e) {
                    throw new RuntimeException("Exception caused while converting configuration: " + e.getMessage());
                }
            });
            return convertedConf;
        } catch (InstantiationException e) {
            throw new RuntimeException("Exception caused while converting configuration: " + e.getMessage());
        } catch (IllegalAccessException e) {
            throw new RuntimeException("Exception caused while converting configuration: " + e.getMessage());
        }
    }

Given that the properties field in the WorkerConfig is empty, the properties field in the newly created ServiceConfiguration is empty too, which means custom configs are not available. This is the central problem I am solving.

If you can point out specifically which field is missing, we can take a close look at the impact.

In the functions worker, the ServiceConfiguration is only used to configure the AuthenticationService and the AuthorizationService. Both of these services can load custom plugins that users create. Custom plugins need custom configuration. It is not an option to add the specific fields to the WorkerConfig or even the ServiceConfiguration because these custom plugins are arbitrary by definition.

I'm in favor of adding this map into WorkerConfig instead of introducing a second configuration.

Can you clarify what you mean when you say "second configuration"? There are already two configuration classes in the Worker class. I am simply changing how the ServiceConfiguration class is constructed.
Alternative Solution
As I mentioned in the initial description, we could alternatively change how we load the WorkerConfig. Using the PulsarConfigurationLoader would populate properties field in the WorkerConfig, which would mean calling the convertFrom method would lead to a properly constructed ServiceConfiguration.
I am fine with loading the WorkerConfig in a new way, but I am not familiar enough with the functions worker to know if this is a safe change. At worst, it could result in new fields being present in the worker config's properties map, which would mean some configurations that were previously ignored are suddenly honored. My change carries a similar kind of risk, but its impact is more limited. It will only affect custom configuration of the AuthenticationService and the AuthorizationService.
Additionally, given that WorkerConfig.load is well tested, I assumed that its construction with an ObjectMapper was intentional and that we would not want to change it.

@jerrypeng - thank you for taking a look. It seems to me that solution 2 is more consistent with the way the broker and proxy load their configurations. Let me know what you think.

Simply have the custom AuthenticationProvider / Authorization provider read from another config file during initialization.  You control the code for these custom plugins so you can do whatever you want in them.  This is custom code so it would also make sense that they have custom configs load from custom config files.

I don't think this solution is consistent with the way that the AuthenticationProvider and the AuthorizationProvider interfaces are written and documented. If an implementation is expected to read its own config from a file, why does the framework pass in a ServiceConfiguration when calling the initialize method?
https://github.com/apache/pulsar/blob/b8dce10a88cc186897fa600f3595b10c4af61b8c/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authentication/AuthenticationProvider.java#L39-L47
https://github.com/apache/pulsar/blob/b8dce10a88cc186897fa600f3595b10c4af61b8c/pulsar-broker-common/src/main/java/org/apache/pulsar/broker/authorization/AuthorizationProvider.java#L87-L97
Further, the broker and proxy components already load their configurations in such a way that they pass arbitrary configuration to the authn/authz providers. It seems appropriate to me that the function worker should load configuration in the same way as the broker and proxy components. (In this PR, I only modified the way that the function worker loads the config for the authn/authz providers to align with the broker and proxy. I mention other approaches above.)

Add a map in WorkerConfig for configs that are not explicitly declared and they can get passed into the plugins.

This map already exists. It is the properties map, as defined in the PulsarConfiguration interface. We can populate this map by initializing the WorkerConfig class using the PulsarConfigurationLoader. I describe why I didn't initially use this solution above, but I am happy to modify this PR to use this solution, if that solution is more appropriate.

I just checked the logic of PulsarConfigurationLoader.convertFrom. It is different from PulsarConfigurationLoader.create. convertForm does a clear job of checking and setting fields. But create just load it as a properties bag.
I agreed with what Jerry commented in https://github.com/apache/pulsar/pull/11468#pullrequestreview-731062476

I just checked the logic of PulsarConfigurationLoader.convertFrom. It is different from PulsarConfigurationLoader.create. convertForm does a clear job of checking and setting fields. But create just load it as a properties bag.

You are right. I hadn't noticed that the file formatting was different between the broker config (.conf) and the function worker config (.yml). I had been working as if the files were interchangeable.
Sorry for the confusion @jerrypeng and @sijie, and thank you for your feedback.
Closing this PR, as it is already possible to pass custom configuration in to the ServiceConfiguration via the WorkerConfig. It can be passed in the properties map in the functions_worker.yml file. Here is a sample:
properties:
  myCustomConfig: "some-custom-value"

The Object Mapper will put those values in the WorkerConfig's properties map. When the WorkerConfig is converted to the ServiceConfiguration, the properties map is properly converted, and the arbitrary configuration is available.

makes sense


animbits cache manager pre script option

Have a option to select a script to run before caching will start.
This would help to set the character in the right setting for caching.
So the script needs to run before each character is cached. So the manager should provide the script with which character is going to be cached so it can set the right setting for that character.

Hello @liudger
I will try to add this.


Hitting line width limit when parsing config into set commands

Hey!
I'm attempting to parse a configuration and hitting a limit when attempting to parse vlan members.
On some interfaces we have A LOT of VLANs being tagged. We do on an trunked interface using VLAN members.
example:
            family ethernet-switching {
                interface-mode trunk;
                vlan {
                    members [ vlan666 vlan1103 vlan1105 vlan1112 vlan1116 vlan1127 vlan1128 vlan1132 vlan1134 vlan1138 vlan1139 vlan1140 vlan1147 vlan1148 vlan1150 vlan1152 vlan1153 vlan1154 vlan1157 vlan1159 vlan1160 vlan1162 vlan1164 vlan1165 vlan1166 vlan1168 vlan1169 vlan1170 vlan1171 vlan1172 vlan1173 vlan1175 vlan1176 vlan1177 vlan1188 vlan1190 vlan1192 vlan1196 vlan1197 vlan1198 vlan1200 vlan1201 vlan1202 vlan1203 vlan1204 vlan1205 vlan1206 vlan1210 vlan1211 vlan1212 vlan1216 vlan1217 vlan1218 vlan1219 vlan1226 vlan1227
                    vlan1228 vlan1232 vlan1233 vlan1253 vlan1261 vlan1262 vlan1263 vlan1265 vlan1272 vlan1273 vlan2140 vlan2190 ];
                }
            }

As you can see from the output above junos seems to drop the configuration onto a new like when configuration lines hit a certain length in characters.
The members line is around 532 characters long and at that point it continues the vlan members list on new line.
The example above is taken from the juniper archive feature and this seems to be something that the junos OS is doing itself.
When we run this through junoser, because the line ends in a new-line rather than semi-colon, it throws an error in this case.
/usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:52:in `block in process': ERROR: unknown statement:  members [ vlan666 vlan1103 vlan1105 vlan1112 vlan1116 vlan1127 vlan1128 vlan1132 vlan1134 vlan1138 vlan1139 vlan1140 vlan1147 vlan1148 vlan1150 vlan1152 vlan1153 vlan1154 vlan1157 vlan1159 vlan1160 vlan1162 vlan1164 vlan1165 vlan1166 vlan1168 vlan1169 vlan1170 vlan1171 vlan1172 vlan1173 vlan1175 vlan1176 vlan1177 vlan1188 vlan1190 vlan1192 vlan1196 vlan1197 vlan1198 vlan1200 vlan1201 vlan1202 vlan1203 vlan1204 vlan1205 vlan1206 vlan1210 vlan1211 vlan1212 vlan1216 vlan1217 vlan1218 vlan1219 vlan1226 vlan1227 (RuntimeError)
        from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:39:in `each'
        from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:39:in `process'
        from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/display/set.rb:14:in `transform'
        from /usr/local/bundle/gems/junoser-0.5.5/lib/junoser/cli.rb:26:in `display_set'
        from /usr/local/bundle/gems/junoser-0.5.5/exe/junoser:46:in `<top (required)>'
        from /usr/local/bundle/bin/junoser:25:in `load'
        from /usr/local/bundle/bin/junoser:25:in `<main>'

If I manually edit the problematic config file and remove the new line it seems to work.
Is there any way to account for a new line potentially being within VLAN members?

Sorry for my late response. I'm looking into this.

Thanks Shintaro, for what it's worth we ended up getting around this issue using some awk commands on the config to concat large lines correctly before we parse it with Junoser.  No immediate rush to resolve this as it's probably a rare occurrence.

Thank you @Jypear, I've published v0.5.6 with the fix. Hoping it works for you.
$ junoser -v
0.5.6

$ cat config
interfaces xe-0/0/0 {
    unit 0 {
        family ethernet-switching {
            interface-mode trunk;
            vlan {
                members [ vlan666 vlan1103 vlan1105 vlan1112 vlan1116 vlan1127 vlan1128 vlan1132 vlan1134 vlan1138 vlan1139 vlan1140 vlan1147 vlan1148 vlan1150 vlan1152 vlan1153 vlan1154 vlan1157 vlan1159 vlan1160 vlan1162 vlan1164 vlan1165 vlan1166 vlan1168 vlan1169 vlan1170 vlan1171 vlan1172 vlan1173 vlan1175 vlan1176 vlan1177 vlan1188 vlan1190 vlan1192 vlan1196 vlan1197 vlan1198 vlan1200 vlan1201 vlan1202 vlan1203 vlan1204 vlan1205 vlan1206 vlan1210 vlan1211 vlan1212 vlan1216 vlan1217 vlan1218 vlan1219 vlan1226 vlan1227
                vlan1228 vlan1232 vlan1233 vlan1253 vlan1261 vlan1262 vlan1263 vlan1265 vlan1272 vlan1273 vlan2140 vlan2190 ];
            }
        }
    }
}

$ junoser -c config
$

Thanks @codeout I'll look to test this asap and let you know.

@codeout Sorry for the delay. v0.5.6 confirmed to have fixed this issue for us.


Async Worker without --allow-net=deno.land

Im working with Async bcrypt but always need the --allow-net option with "deno.land" even when i save in cache the dependencies (explicitly i run deno cache --unstable<EMAIL_ADDRESS>previously trying to force the cache)
Have some option to avoid the call to "deno.land" in execution time and use the cache? Or i'm missing something?
I think in:

Apps without internet access
Developments where can't use "deno.land" in --allow-net option by security reasons in execution time
Because 'deno.land' will be down at these time.

Thanks for your support!

Hi,
Do you have your Deno updated to the latest?

You should not have any problems after #20 has been merged. Since this PR removes every dependency.


How to learn ZLM link leads to duolingo

When following the How to learn ZLM link, my browser ended up at a main page of Duolingo service

duplicate, sorry


fix bug in feature fraction

@guolinke I think AppVeyor stalled (still waiting for 4 hours already).


Storage: Fix ZFS block volume shrink regression

Only use unsafe resize when operating on block backed filesystem volumes.
Caused by 5c4f1109bcb984e7bac5ffcd41d47ead9852b37d
Fixes test failures: https://jenkins.linuxcontainers.org/job/lxd-test-storage-vm/backend=zfs,restrict=master/1431/console

Thanks, just need to wait jenkins to pass.

jenkins: test this please


Adding Multiple task causes the title disappear

Describe the bug
Adding Multiple task causes the title overflow
To Reproduce
Steps to reproduce the behavior:

adding multiple task
See error

Expected behavior
Adding multiple task ,list should overflow in y direction not the title
Screenshots

@Anshgrover23 i know how to solve this issue, please assign this to me

https://github.com/Groverio/To-Do-List/pull/98 @Anshgrover23, i have opened the pr kindly review it
Thankyou


Added Features "Backport"

Hello!
I have seen that you have implemented a config in your 2.0 update! What is that config all about? What can you do with it? Also, is there any chance that you will update the mod for versions like 1.20.0/1/2? Because I have a modpack already, so sadly I cant just use the 1.20.3 version which offers a config.

These are all the configuration settings available in version 3.0:

Are there any specific settings you need? I don't really want to backport the configuration unless someone would actually use it.


Tachyons sass flexbox issue

I opened this PR in the tachyons-sass repository but no one seems to be monitoring or responding to it.  Is this a better place to file issues?
https://github.com/tachyons-css/tachyons-sass/pull/31

What was the reason for closing this issue?

It's not appropriate for this repo and we don't need duplicates.


[TBD]: Implement pending offences background app

Proposed changes
Implements background behaviour, round, and payload for synchronizing the pending offences.
Fixes
n/a
Types of changes
What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

[ ] Non-breaking fix (non-breaking change which fixes an issue)
[ ] Breaking fix (breaking change which fixes an issue)
[x] Non-breaking feature (non-breaking change which adds functionality)
[ ] Breaking feature (breaking change which adds functionality)
[ ] Refactor (non-breaking change which changes implementation)
[ ] Messy (mixture of the above - requires explanation!)

Checklist
Put an x in the boxes that apply.

[x] I have read the CONTRIBUTING doc
[x] I am making a pull request against the main branch (left side). Also you should start your branch off our main.
[x] Lint and unit tests pass locally with my changes
[ ] I have added tests that prove my fix is effective or that my feature works
[ ] I have locally run services that could be impacted and they do not present failures derived from my changes
[ ] Public-facing documentation has been updated with the changes affected by this PR. Even if the provided contents are not in their final form, all significant information must be included.
[ ] Any backwards-incompatible/breaking change has been clearly documented in the upgrading document.

Further comments
n/a

The failing test on Windows is because the timegm returns the time in milliseconds instead of seconds as in other platforms.
The issue is only present on the test, not the actual code, as the timegm is used to generate the timestamps to feed the hypothesis builds strategy.
A condition to check for the platform should be added there and divide the timestamp by 1000 if on Windows, however, we leave this test failing for now.


"Last 7 days" does not actually show last 7 days

shlink-web-client version
4.2.1
How do you use shlink-web-client
https://app.shlink.io
Current behavior

selecting "Last 7 days" at the current time (UTC 4:20 PM Monday, October 14, 2024 Coordinated Universal Time (UTC)) show 2024-10-07 to 2024-10-15. This has been a longstanding issue where the date seems to always show 1 day ahead of the selected time period. The same issue occurs on the other date periods (eg: last 30 days and last 90 days).
This issue isn't a regression as I believe it has always worked like this.
Expected behavior

I expect the "Last X days" period to actually show the last X days (eg: for today that would be 2024-10-7 to 2024-10-14)
Minimum steps to reproduce
Go to any url on app.shlink.io and view the visits by time and select any of the "Last X days" periods

The dates in the URL do not match the dates in the "By time" graph
url looks like this
...list?startDate=2024-10-07T00%3A00%3A00-04%3A00&endDate=2024-10-14T23%3A59%3A59-04%3A00

meanwhile the "By time" graph shows

Then it's probably an issue when converting timezones in the server. Probably nothing is wrong in the client.
What timezone did you set in your Shlink instance?

What timezone did you set in your Shlink instance?

The server uses and has always used UTC time. Checking config/params/generated_config.php includes 'TIMEZONE' => null,
So seems like a web client bug.

What timezone did you set in your Shlink instance?

The server uses and has always used UTC time. Checking config/params/generated_config.php includes 'TIMEZONE' => null,
So seems like a web client bug.

It's probably worth checking if the dates forwarded to the API do not match the ones displayed in the client URL query params, but other than that, and if they do match, it does seem like a server issue. Nothing indicates it's the client.
A similar issue was reported a while ago, which was reproducible when the client was using a timezone behind the server one (like in your case). I thought I got it fixed, but I guess I may have missed something.
I'll transfer this to Shlink's main repository and continue investigating once I have a moment.


update java

Codecov Report

Merging #155 into master will decrease coverage by 0.2%.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             master     #155      +/-   ##
============================================
- Coverage     96.76%   96.55%   -0.21%
  Complexity       95       95
============================================
  Files            19       15       -4
  Lines          1235      901     -334
  Branches         68       68
============================================
- Hits           1195      870     -325
+ Misses           35       29       -6
+ Partials          5        2       -3

Flag
Coverage Δ
Complexity Δ

#csharp
95.29% <ø> (ø)
0 <ø> (ø)
:arrow_down:

#go
?
?

#java
99.05% <ø> (ø)
95 <ø> (ø)
:arrow_down:

#node_js
100% <ø> (ø)
0 <ø> (ø)
:arrow_down:

Impacted Files
Coverage Δ
Complexity Δ

baseclient/go/service/baseclient.go

baseclient/go/service/config.go

baseclient/go/utils/util.go

baseclient/go/utils/assert.go

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24ff102...2470659. Read the comment docs.


Add support for server-side key generation to keys REST API [PR 2/8]

Added support to the keys endpoints for server-side generation of a new
client key  Validates to ensure that either public_key or
create_key is provided, and will fail with a 400 if both are provided.
If a key is generated (PUT or POST body contains "create_key":true)
it will be returned as "private_key": "$KEY" in the response JSON. If it
is not requested, a valid public key must be sent and the private_key
field will not be sent in the response body.
This is implemented under API v0, since it was an additive change.
2/ 8 I've split these into separate PRs to make the changes clearer, but am currently planning to merge all 8 down into master as a unit.
/ping @chef/lob

+1 looks good. see if you can remove that one clause tho

:+1: let's get this shipped so I can update my chef-client object code to use it.


max is not working properly in time scale v2.7.0

Current Behavior
I set max value in time scale it working fine when dataset has 2 and more values otherwise behaviour unexpected.
Why it is behaving like this.
Steps to Reproduce (for bugs)
Dataset with 2 and more values
https://jsfiddle.net/657fxL8r/7/
Dataset with 1 value.
https://jsfiddle.net/657fxL8r/8/
Environment

Chart.js 2.7.0:

I think this is related to source: 'labels'. CC @simonbrunel @benmccann for a better answer

I believe source: 'labels' was the default in 2.6.0, so if it is related to that it's unlikely to be a new issue

What is the behavior you expect? The labels do not go beyond the max specified, so it's not clear to me that there's a bug here

@benmccann I know labels is not beyond with max but ticks is dependent on max. In second fiddle when I have only one dataset ticks is not depending on max. I am expecting when I set max to one year and unit : 'month' then ticks should be 12 and bar will show only one tick that is not happening here when I have only one dataset. See the different of both fiddle.

will show only one tick that is not happening here

I'm not understanding your explanation of what you expect the behavior to be. When I click https://jsfiddle.net/657fxL8r/8/ I see only one tick

@benmccann this fiddle https://jsfiddle.net/657fxL8r/8/ showing one one tick its right but bar width is not correct. See another fiddle https://jsfiddle.net/657fxL8r/7/  Here bar width is right.
I want bar width same as fiddle2.

Yes, I agree that is strange.
I believe @nagix was working on a solution for that

Any solution


Put the Vault chart and the Operator Chart under CI as well

Also:

transit-unseal example (probably the most complex demonstration of the project)

Print(input("enter your name :-1: "))


22988 - Fixed the Amalgamation Corp Type Bug

Issue #: /bcgov/entity#22988
Description of changes:

Added the computed corp type when primary business is continued in

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the bcrs-entities-create-ui license (Apache 2.0).

/gcbrun

Temporary Url for review: https://business-create-dev--pr-728-rdomavzf.web.app

Try:
https://business-create-dev--pr-728-rdomavzf.web.app/amalg-short-information?id=TQMmue0hhd&accountid=3040

/gcbrun

Temporary Url for review: https://business-create-dev--pr-728-rdomavzf.web.app

/gcbrun

@severinbeauvais added unit tests and updated the packages. Is it ok to merge now?
Thanks!

Temporary Url for review: https://business-create-dev--pr-728-rdomavzf.web.app

/gcbrun

Temporary Url for review: https://business-create-dev--pr-728-rdomavzf.web.app