Update google api header

Now the gapic header has the following format:
Gapic only client: gl-java/{java_version} gapic/0.1.0 gax/0.0.27 grpc/1.0.1
Hand-written client: gl-java/{java_version} gccl/0.0.0 gapic/0.1.0 gax/0.0.27 grpc/1.0.1
The hand-written layer can override the top level token 'gapic/0.1.0' by setting the client name/version.

Add unit test

Current coverage is 71.17% (diff: 33.33%)

Merging #179 into master will increase coverage by 0.27%

@@             master       #179   diff @@
==========================================
  Files            62         62
  Lines          2454       2446     -8
  Methods           0          0
  Messages          0          0
  Branches        333        334     +1
==========================================
+ Hits           1740       1741     +1
+ Misses          615        604    -11
- Partials         99        101     +2

Powered by Codecov. Last update b50b5a8...32b9745

I'll review this soon. The design doc is not fully baked, since there are still a few unresolved concerns.

@bjwatson Friendly ping~

Thanks for the updates @shinfan. I'm reviewing now.

@bjwatson  PTAL

LGTM

Because the gccl version implies the gapic version for all source delivery
languages. When you switch Datastore to use GAPIC, then you'll know the
gccl version as of which that happened. (Of course we'll need to keep track
of this somehow)
You can add the gapic version to the header if you really want to, but be
aware that you're adding some server overhead to every call without
providing any additional information.
On Feb 9, 2017 10:13 AM, "garrettjonesgoogle"<EMAIL_ADDRESS>wrote:
@garrettjonesgoogle commented on this pull request.
In src/main/java/com/google/api/gax/grpc/InstantiatingChannelProvider.java
https://github.com/googleapis/gax-java/pull/179#pullrequestreview-21079127
:

private InstantiatingChannelProvider(
ExecutorProvider executorProvider,
CredentialsProvider credentialsProvider,
String serviceAddress,
int port,

 String clientLibName,

 String clientLibVersion,

 String serviceGeneratorName,

 String serviceGeneratorVersion) {

I still don't understand why we aren't retaining both the gapic version and
the gccl version when both are relevant. There is a particular scenario I
want recorded: Datastore as of now uses the legacy Google API Client stack,
thus it would have gccl and not gapic; but, when we switch it to using a
GAPIC client, then I want gccl and gapic to both appear.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/googleapis/gax-java/pull/179#pullrequestreview-21079127,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAcyy2Nd2KbdwteTqxXErxGBw9CA78GSks5ra1ddgaJpZM4Lrdvu
.

Because the gccl version implies the gapic version for all source delivery languages. When you switch Datastore to use GAPIC, then you'll know the gccl version as of which that happened.

(Of course we'll need to keep track
of this somehow)

That's the part that concerns me. I don't want to track this.

You can add the gapic version to the header if you really want to, but be aware that you're adding some server overhead to every call without providing any additional information.

But it actually is additional information - information that is otherwise a chore to uncover, because it requires digging up old source code revisions to find it out. Think of this scenario: there could be cases where we regenerate some GAPIC clients but not others, and thus for a particular gccl version, the gapic version depends on the API.

Oh and I forgot to mention the scenario of an API starting with GAPIC-only, then converting to having a handwritten layer. In that case, the gapic version would disappear and there would be no continuity.

@garrettjonesgoogle PTAL

LGTM


Update scalafmt-core, scalafmt-dynamic to 3.7.13

About this PR
📦 Updates

org.scalameta:scalafmt-core
org.scalameta:scalafmt-dynamic

from 3.7.4 to 3.7.13
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scalameta" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scalameta" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #307.


Respect return value of RecordHeader construction

https://github.com/opencypher/cypher-for-apache-spark/blob/3afbaabb55d6ec808e7b181f80911e332fef8aa1/src/main/scala/org/opencypher/caps/api/record/RecordHeader.scala#L201

Record header has been completely replaced.


Update google-cloud-bigquery to 1.127.6

Updates com.google.cloud:google-cloud-bigquery from 1.122.2 to 1.127.6.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.google.cloud", artifactId = "google-cloud-bigquery" } ]

labels: library-update, semver-minor

Superseded by #193.


Display task comments

Fixes #125
This PR adds the feature of displaying a task's comments at the bottom of the view single task template.
Changes you made

[x] Add get_comments method to Task model.
[x] Add tests to the above method.
[x] Add HTML to display each task's comments.

need to fix conflicts
Done

Fixed any conflicts, please CR again.


Incompatibility with Chunk Pregenerator

(Forge 1.12.2)
Generating a world with chunk pregenerator will result in all biomes being tagged as plains
How to reproduce:

Start a multiplayer server with chunk pregenerator and RoughlyEnoughIDs
Start the server and start pregeneration before a player logs on
after a few chunks have pregenerated, log into the multiplayer world and check the F3 menu to see the biome tags (All biomes should be labelled as plains)

I fixed the issue by updating from RTG 1.12.2 Preview to RTG Unofficial 1.0.2, however, I would need to do more testing to see if this error is still reproducible on Vanilla clients and servers. I would also recommend checking how REI handles chunk pregeneration tasks to avoid potential conflicts in the future.
Thanks for the good work guys! Really appreciate the work you guys are doing here! The mod seems to be significantly less buggy in contrast to other mods like Just Enough IDs and Not Enough IDs.

This bug occurs without RTG however. Any dimension in our server will result in a plains biome being generated instead.
Imagine wandering the Nether and seeing Grass and Sheep around Lol.
For the time being, we have to use the generation feature from Forge. Which is extremely slow but it does work.

still not working with Chunk Pregenerator

I just thought I'd link the original issue, which has some more info on the bug: https://github.com/DimensionalDevelopment/JustEnoughIDs/issues/42


Devfile samples generates broken Routes which use http instead of https

Which area this feature is related to?
Devfile samples
/kind bug

Which area this bug is related to?

/area registry
What versions of software are you using?
OpenShift 4.13.13
Bug Summary
Describe the bug:
I didn't check all the samples but at least those two:
https://github.com/devfile-samples/devfile-sample-code-with-quarkus.git
https://github.com/devfile-samples/devfile-sample-java-springboot-basic.git
result in broken Routes when used in OpenShift. The Routes are missing:
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

To Reproduce:

In Web Console go to the Developer perspective. Then "Add" and choice there the affected samples. After the app is build and deployed try to open the route. The route uses http:// instead of https://

Any workaround?
Manually modify the route and fix it by adding:
  tls:
    termination: edge
    insecureEdgeTerminationPolicy: Redirect

You can easily reproduce it in Dev Sandbox for OpenShift btw.

@alexeykazakov  Thanks for reporting this, we'll take a look into our registry stacks/samples.

I'm not sure what area it is.

Should be:
/area registry

Refinement date changed to October 27th for other high priority items, was previously October 20th.

Refinement date changed to October 27th for other high priority items, was previously October 20th.

Refinement date changed to November 3rd for other high priority items.

Refinement date changed to October 27th for other high priority items, was previously October 20th.

Refinement date changed to November 3rd for other high priority items.

Holding off on sizing until more details are able to gathered for refinement.

While working on the go-basic sample https://github.com/devfile-samples/devfile-sample-go-basic/pull/34, I discovered that the route is created by ODC from the devfile endpoint entry.
When ODC creates the Route it does not create an endpoint for tls when the secure: true or protocol: https is set as expected. After investigating this, it is found that when a uri is used instead of inlined the secure route parameter is always set to false: https://github.com/openshift/console/blob/170c455125d05b9b6c80b53e2e666617666fb80a/pkg/devfile/resources.go#L162
We'll need to patch this to match what is inplace for inlined: https://github.com/openshift/console/blob/170c455125d05b9b6c80b53e2e666617666fb80a/pkg/devfile/resources.go#L186
Once this is patch, then the changes I am making to the sample devfiles will resolve this issue.
cc: @alexeykazakov

Thanks for looking at this. Can you please create a JIRA for the console folks?

Thanks for looking at this. Can you please create a JIRA for the console folks?

I have created a JIRA issue for this: https://issues.redhat.com/browse/CONSOLE-3891
I will continue using this issue (devfile/api#1270) to track progress in patching the devfile samples.

For each sample, patching requires the addition of secure: true under the kubernetes component endpoint: https://github.com/devfile-samples/devfile-sample-go-basic/pull/35/commits/fcdefb788cc1df96db49ba2f7f18b9d8af9d58a6

List of PRs to enable TLS across community samples:

[ ] https://github.com/devfile-samples/devfile-sample-code-with-quarkus/pull/27
[X] https://github.com/devfile-samples/devfile-sample-java-springboot-basic/pull/40
[X] https://github.com/devfile-samples/devfile-sample-java-springboot-basic/pull/41
[X] https://github.com/devfile-samples/devfile-sample-python-basic/pull/39
[X] https://github.com/devfile-samples/devfile-sample-python-basic/pull/40
[X] https://github.com/devfile-samples/devfile-sample-go-basic/pull/34
[X] https://github.com/devfile-samples/devfile-sample-go-basic/pull/35
[ ] https://github.com/devfile-samples/devfile-sample-dotnet60-basic/pull/11
[ ] https://github.com/nodeshift-starters/devfile-sample/pull/41

Received approval on the final PR, will need help to merge this PR: https://github.com/nodeshift-starters/devfile-sample/pull/41#issuecomment-1904337280

@michael-valdron would advise to reach out on Slack for the node sample, if possible.

Sample changes are completed, there needs to be a fix applied to openshift/console: https://github.com/devfile/api/issues/1270#issuecomment-1865306305
Will provide a link to the continuing issue that will track this once it is ready.

Thanks for looking at this. Can you please create a JIRA for the console folks?

I have created a JIRA issue for this: https://issues.redhat.com/browse/CONSOLE-3891
I will continue using this issue (#1270) to track progress in patching the devfile samples.

Portion of console which this bug resides is maintained by Devfile Services team and the issue has been migrated to #1455 to track.
cc: @alexeykazakov


Removing the P icon on the title

Where would the code be to change the icon on the title, or to just remove it?

Sorry @dmccrevan
I am not sure what are you referring to... Do you mean the favicon?

Yes, I have my own facivon in static/img/ but for some reason the one that you had default is still appearing.

Hi @dmccrevan
The line you need to edit or remove is this https://github.com/biomadeira/sustain/blob/gh-pages/_layouts/layout.html#L9
Since you got a favicon of yours, the problem is just that your browser has cached the previous one... I guess you can try reload the page a few times as well as trying it on a different browser...
For chrome check https://productforums.google.com/forum/#!topic/chrome/zXlEW0ZFErY

I guess it was the cache issue...Clear cache extension for chrome didn't clear it i guess lol, thanks though! Really like sustain & vitae

Thanks @dmccrevan ;)


Response Headers Not Being Returned

I have setup the following expectation.  What I'm noticing is the mock server is returning a 200 and returning the response body.  However, the response headers are NOT being returned.
this.mockServerClient("localhost", 1080)
  .mockAnyResponse({
    "httpRequest" : {
      "method" : "GET",
      "path" : "/api/v1/location/steve"
    },
    "httpResponse" : {
      "body" : "some_response_body",
      "headers" : {
        "steve" : [ "hello" ]
      }
    }
  }).then(
      function(result: any) {
          console.log(`Everything is looking great!! ${result}`);
      },
      function(error: any) {
          console.log(`There was an error: ${error}`);
      }
  );

In this case, the "steve" header is not being returned as part of the response when I call the endpoint from Postman.  However, the response body ("some_response_body") is returned correctly.
If I set it up with the via REST instead, the headers are returned appropriately.  The code below works and the 'steve' header is returned when calling from Postman
curl -v -X PUT "http://localhost:1080/mockserver/expectation" -d '{
"httpRequest" : {
"method" : "GET",
"path" : "/api/v1/location/steve"
},
"httpResponse" : {
"body" : "some_response_body",
"headers" : {
"steve" : [ "hello" ]
}
}
}'
Any thoughts?

This was caused by the mockserver-client-node having a bug in the handling of the newer object format for headers.  This has now been fixed and pushed to the https://github.com/jamesdbloom/mockserver-client-node repo.  This will be released when I do the next release likely in around 2/3 weeks.


Fr/optional basic click

This project uses semver, please check the scope of this pr:

[ ] #patch# - backwards-compatible bug fix
[x] #minor# - adding functionality in a backwards-compatible manner
[ ] #major# - incompatible API change

CHANGELOG

Added the ability to disable a basic click. While basic click is nice, it is not always desirable. If you had a list of 100+ items and you accidentally clicked a item, you will unselect all.

:+1:


Online refinement

Sorry to bother you again. I want to know how to handle the border samples e.g. frame 0 or last frame in the sequence when you conduct online refinement. Should we discard these test samples?
Thanks a lot~

We will input two frame 0 since frame -1 does not exist.


feat(ui): exposing SDK version on graph cards

Context

With the addition of the SDK version on the graph runtime information, we were lacking a way to view it on the UI.
What

Testing

Contribution Checklist

[x] If the python-sdk was changed, please run make fmt in python-sdk/.
[x] If the server was changed, please run make fmt in server/.
[x] Make sure all PR Checks are passing.

@seriousben Thanks for the SS :)


AMQP-700: ListenerEndpointRegistry: proper stop

JIRA: https://jira.spring.io/browse/AMQP-700
Previously, when an exception happens in the ListenerContainer.stop(Runnable) during applicationContext close,
The context waits exactly for the DefaultLifecycleProcessor#timeoutPerShutdownPhase, because callback.run() hasn't been called
and exception is bubbled to the DefaultLifecycleProcessor.
In addition, when exception happens on one of the RabbitListenerEndpointRegistry containers, the stop() for the rest hasn't been called.

Perform callback.run() in the finally of the AbstractMessageListenerContainer.stop(Runnable)
Wrap container.stop(Runnable) call in the RabbitListenerEndpointRegistry to try catch to log an exception and let other containers to perform their stop()

Cherry-pick to 1.6.x and 1.7.x

Merged as 0e9dee8c69d174549bf28f2fc192d36186528fcc
1.7.x: d8a5699b0f71ec8bfe184691b33b6d55bf6c9f2a
1.6.x: 471434f2a33184564283a7735ac15a7fc5ad08b7


Move locks to more granular locking than CPU count based

As detailed in issue #279, current lock scheme has hash
buckets that are count of CPUs. This causes a lot of contention
when parallel requests are made to the CSI plugin. To reduce
lock contention, this commit introduces granular locks per
identifier.
The commit also changes the timeout for gRPC requests to Create
and Delete volumes, as the current timeout is 10s (kubernetes
documentation says 15s but code defaults are 10s). A virtual
setup takes about 12-15s to complete a request at times, that leads
to unwanted retries of the same request, hence the increased
timeout to enable operation completion with minimal retries.
Tests to create PVCs before and after these changes look like so,
Before:
Default master code + sidecar provisioner --timeout option set
to 30 seconds
20 PVCs
Creation: 3 runs, 396/391/400 seconds
Deletion: 3 runs, 218/271/118 seconds

Once was stalled for more than 8 minutes and cancelled the run

After:
Current commit + sidecar provisioner --timeout option set to 30 sec
20 PVCs
Creation: 3 runs, 42/59/65 seconds
Deletion: 3 runs, 32/32/31 seconds
Fixes: #279
Signed-off-by: ShyamsundarR<EMAIL_ADDRESS>

Setup where the following tests were run:

Kubernetes 1.14.2 with, 1 master + 3 workers using k8s-cluster based setup.
Machine had 10 cores with 2 processors each, dedicated to running just this test.
Vagrant file from k8s-cluster repository was changed to increase the cpu count per vm instance to 4 and memory to 4GiB.

Performance numbers of master branch without the fix looks like below,
Table Legend:

PVC Count is the number of PVC requests create in parallel
Runs is the number of times the benchmark was executed
Time to Create (in seconds)/run is the total time taken to create PVC Count per run
Time to Delete (in seconds)/run is the total time taken to delete PVC Count per run

PVC Count
Runs
Time to Create (in seconds)/run
Time to Delete (in seconds)/run

20
3
396/391/400
218/271/118

NOTE: Runs for 100 and 200 PVC counts were not performed, as it was taking a long time to complete
Performance numbers with the provided fix looks like so,

PVC Count
Runs
Time to Create (in seconds)/run
Time to Delete (in seconds)/run

20
3
42/59/65
32/32/31

100
3
101/112/93
85/97/90

200
1
148
149

Reasons for performance loss with the current locking scheme:

As the number of locks were very low, and intended for threads consuming CPU resources, each lock was held for a longer duration causing other requests contending for the same lock to queue up.
Default timeout for gRPC requests (Create/Delete) was set at 10 seconds by the provisioner sidecar. Once a request is queued behind a lock, it accrues the delay of the prior PVC Create/Delete operation in terms of time to respond. This causes the provisioner to timeout and try the operation again after some interval (even though the first call would be processed by the CSI driver).
The retry duration between calls starts at 1s by default and is increased by a factor of 2 each time, hence when reaching retry counts of 5-6 the interval of wait by the provisioner itself is 16s-32s and so on. This, combined with the queuing and response delays causes larger time to completion of the request.
Finally, on the setup where the tests were executed, a single Create could take 8-15s to complete (similarly a delete could take about as much time). (This was one of the key reasons to increase the timeout in the sidecars, to accommodate slower setups)

Reasons for choosing current locking scheme:

Provided granular locking at the cost of a some additional CPU cycles, and CPU was not a bottleneck in the problem. Thus, addressed corner cases where lock hashes may even collide to give a lower system performance.
Cost to check a Created or Deleted volume is lesser than creating one or deleting one from scratch, hence retries were not much of a concern (yet)

Other optimization possibilities exist in the future to further reduce checking Created or Deleted volumes (pool/fs name and ID caching)

Increasing the provisioner timeout helps reducing retires, thus not (yet) needing a response broker like approach

What were the options to improve the locking scheme:

Just move the number of locks in the initialization of keymutex.NewHashed() from 0 to 128

This was attempted and the performance numbers were no different than the current scheme of granular locks
Numbers generated using this scheme (including setting provisioner timeout to 30s) is as follows,

PVC Count
Runs
Creates/run/sec
Deletes/run/sec

20
3
50/72/33
32/99/37

100
3
116/94/112
95/71/93

200
1
162
145

This scheme still can potentially have RPC requests queuing behind the same lock on hash collision, and hence, although simpler, is not used as the solution.

Use responsebroker as in Manila-CSI

Cost to check a volume is provisioned or already deleted, is lower than the initial create/delete operation and has other optimizations in the future (as noted earlier). Also, tweaking the provisioner timeouts, reduces the duplicate requests in the pipeline, avoiding the leverage a response cache provides at present.
Further response broker currently does not check exact request equivalence, and depends on request name equivalence only (just a note for the future)

Use golang sync.Map and possibly sync.Pool to optimize CPU utilization

These are along the lines of solutions like,

https://github.com/enfipy/locker/blob/master/locker.go
https://github.com/vburenin/nsync/blob/master/namedmutex.go

But are not chosen as these seem more premature optimizations based on current results using regular maps and locked access to the same.

@ShyamsundarR Are those create/delete times the total time to create/delete that many PVs or is that the average time per PV? I ask because creating 50 PVs in under a second is fine, but creating 20 PVs in 50 seconds is terrible.

@ShyamsundarR Are those create/delete times the total time to create/delete that many PVs or is that the average time per PV? I ask because creating 50 PVs in under a second is fine, but creating 20 PVs in 50 seconds is terrible.

Total time to create as many PVCs. IOW, it took 396 seconds to create 20 PVCs using existing master code. Does this explain the numbers?
Is there a better way to word this part of the table legend? "Time to Create (in seconds)/run is the total time taken to create PVC Count per run"
I do not want to state per PVC create time as 396/20, as the creation is/was not serial, but parallel in nature.

Yes, that explains the numbers. I'm just concerned about the speed since it seems really terrible (albeit way better thanks to this PR).
For comparison, here is me creating 20 1GiB images on the command-line in roughly 1 second total time:

$ time bash -c 'for x in seq 1 20; do echo $x ; ./bin/rbd create --image-feature layering image$x --size 1G; done'
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
real	0m1.016s
user	0m0.834s
sys	0m0.184s

Yes, that explains the numbers. I'm just concerned about the speed since it seems really terrible (albeit way better thanks to this PR).
For comparison, here is me creating 20 1GiB images on the command-line in roughly 1 second total time:

$ time bash -c 'for x in seq 1 20; do echo $x ; ./bin/rbd create --image-feature layering image$x --size 1G; done'
1

20
real	0m1.016s
user	0m0.834s
sys	0m0.184s

In the setup where I ran the tests the above takes,

@ShyamsundarR first of all thanks for this PR!
I have some general comments on this : That said, this PR mix the "timeout" of request via sidecar timeout argument and lock improvement. afacit, the performance numbers are captured with both are in place. If possible, I would like to split this and validate where it stand. The reason being, more granular level of analysis or fix is required especially dealing with performance numbers as the result can vary depending on the request type/setup..etc.
This also helps us to understand or validate the response broker type implementation which @gman0 did in manilla helps us to tackle the issues we could encounter.
Also, a validation with ONLY one type of request ( for ex: either create or delete) while measuring performance may not help much as shown in PR description/comment. We have to inject say "creation" , "deletion", "snapshot" ..etc in parallel to really see how we behave on lock holding and releasing...etc. Because thats one of the very possible scenario in a cloud or kubernetes kind of setup.
I can help to split the experiments or code, but IMO, we have to understand above scenarios before we make some changes in this area as its a critical path for serving requests.

How many PVs did we end up having in the system? It's unclear to me. If we are doing 200 in parallel, and it took us 162 seconds overall to complete the initial 200, I assume there were many more created in parallel, right? To me it'd be easier to understand something like:
"To create 1000 PVs in total with 200 PVC requests in parallel took X seconds to complete" and "To create 1000 PVs in total with 10 PVC requests in parallel took X seconds to complete" kind of measurements.

@ShyamsundarR first of all thanks for this PR!
I have some general comments on this : That said, this PR mix the sidecar timeout argument and lock improvement. afacit, the performance numbers are captured with both are in place. If possible, I would like to split this and validate where it stand invidually. The reason being, more granular level of analysis or fix is required especially dealing with performance numbers as the result can vary depending on the request type/setup..etc.
This also helps us to understand or validate the response broker type implementation which @gman0 did in manilla to tackle the issues we could encounter.
Also, a validation with ONLY one type of request ( for ex: either create or delete) while measuring performance may not help much . We have to inject say "creation" , "deletion", "snapshot" ..etc in parallel to really see how we behave on lock holding and releasing...etc. Because thats one of the very possible scenario in a cloud or kubernetes kind of setup.
I can help to split the experiments or code, but IMO, we have to understand above scenarios before we make some changes in this area as its a critical path for serving requests.

@humblec My intention was to focus on the single lock that we are contending on and fix the same.
Also, during the fix the issue of response time per request was causing a problem, which is why I moved the side car timeouts as well.
The lock is granular, so combining operations will not impact each other with the fix.
Snapshots have a whole different problem as noted in this comment

How many PVs did we end up having in the system? It's unclear to me. If we are doing 200 in parallel, and it took us 162 seconds overall to complete the initial 200, I assume there were many more created in parallel, right?

I created the PVC Count number of PVCs (as in the tables provided) in parallel and measured the time it takes to complete the same.
scripts to create and delete PVCs are as below:
create-perf.sh.txt
delete-perf.sh.txt

To me it'd be easier to understand something like:
"To create 1000 PVs in total with 200 PVC requests in parallel took X seconds to complete" and "To create 1000 PVs in total with 10 PVC requests in parallel took X seconds to complete" kind of measurements.

The above was not the test that I performed, hence cannot summarize the results as such. What can be summarized from the provided numbers is "To create PVC Count PVCs in parallel it took Time to create(in seconds) time"

Also, during the fix the issue of response time per request was causing a problem, which is why I moved the side car timeouts as well.

@ShyamsundarR my point is, lets split or track the timeout fix separately and may be do a validation whether that helps in performance or to avoid some contention.

Also, during the fix the issue of response time per request was causing a problem, which is why I moved the side car timeouts as well.

@ShyamsundarR my point is, lets split or track the timeout fix separately and may be do a validation whether that helps in performance or to avoid some contention.

I have captured the reasons in text in this comment under the titles,

"Reasons for performance loss with the current locking scheme"
"Reasons for choosing current locking scheme"

But I guess you need numbers instead of text. Let me see what I can generate in my day and post it here.

The commit also changes the timeout for gRPC requests to Create
and Delete volumes, as the current timeout is 10s (kubernetes
documentation says 15s but code defaults are 10s). A virtual
setup takes about 12-15s to complete a request at times, that leads
to unwanted retries of the same request, hence the increased
timeout to enable operation completion with minimal retries.

@ShyamsundarR I am trying to figure out "only increasing" the timeout helps to improve the performance or not ? so I was asking can we see how the performance looks only with the "timeout" change.

@humblec Here are the requested numbers.
Scripts used:
create-perf.sh.txt
delete-perf.sh.txt
Only timeout changes against master code (IOW, just adding the timeout options to code --timeout=30s --retry-interval-start=500ms)
NOTE: Only a single run as time taken is far longer
20 PVC created in parallel took 544 seconds
20 PVC deleted in parallel took 194 seconds
Notes:

Time for create got stuck in the last 5 PVCs as I could see then contending for the same lock, from the logs, and with exponential backoff in Kube.

Creation rate looked as below
./create-perf.sh 20
Creation Start time:
Thu Jun 27 11:15:28 EDT 2019
persistentvolumeclaim/rbd-pvc-iter-20 created
persistentvolumeclaim/rbd-pvc-iter-19 created
persistentvolumeclaim/rbd-pvc-iter-18 created
persistentvolumeclaim/rbd-pvc-iter-17 created
persistentvolumeclaim/rbd-pvc-iter-16 created
persistentvolumeclaim/rbd-pvc-iter-15 created
persistentvolumeclaim/rbd-pvc-iter-14 created
persistentvolumeclaim/rbd-pvc-iter-13 created
persistentvolumeclaim/rbd-pvc-iter-12 created
persistentvolumeclaim/rbd-pvc-iter-11 created
persistentvolumeclaim/rbd-pvc-iter-10 created
persistentvolumeclaim/rbd-pvc-iter-9 created
persistentvolumeclaim/rbd-pvc-iter-8 created
persistentvolumeclaim/rbd-pvc-iter-7 created
persistentvolumeclaim/rbd-pvc-iter-6 created
persistentvolumeclaim/rbd-pvc-iter-5 created
persistentvolumeclaim/rbd-pvc-iter-4 created
persistentvolumeclaim/rbd-pvc-iter-3 created
persistentvolumeclaim/rbd-pvc-iter-2 created
persistentvolumeclaim/rbd-pvc-iter-1 created
Done moved up 1
Thu Jun 27 11:15:33 EDT 2019
Done moved up 2
Thu Jun 27 11:15:45 EDT 2019
Done moved up 4
Thu Jun 27 11:15:46 EDT 2019
Done moved up 5
Thu Jun 27 11:15:48 EDT 2019
Done moved up 6
Thu Jun 27 11:16:00 EDT 2019
Done moved up 7
Thu Jun 27 11:16:01 EDT 2019
Done moved up 8
Thu Jun 27 11:16:06 EDT 2019
Done moved up 9
Thu Jun 27 11:16:07 EDT 2019
Done moved up 10
Thu Jun 27 11:16:12 EDT 2019
Done moved up 11
Thu Jun 27 11:16:40 EDT 2019
Done moved up 13
Thu Jun 27 11:16:41 EDT 2019
Done moved up 14
Thu Jun 27 11:16:51 EDT 2019
Done moved up 15
Thu Jun 27 11:16:53 EDT 2019
NOTE: First 15 got created in 85 seconds
Done moved up 16
Thu Jun 27 11:22:01 EDT 2019
Done moved up 17
Thu Jun 27 11:22:25 EDT 2019
Done moved up 19
Thu Jun 27 11:24:31 EDT 2019
Done moved up 20
Thu Jun 27 11:24:32 EDT 2019
Creation End time:
Thu Jun 27 11:24:32 EDT 2019
NOTE: last 5 took the rest of the time as they were contending on the same lock.

Further data on only using locks and no changes to timeouts.
Only granular locks and notimeout changes with the current PR (although this was not requested)
20 PVC created in parallel took 139/102/137 seconds in each create run (3 in total)
200 PVC created in parallel took 224 seconds (single run)
20 PVC deleted in parallel took 38/60/98 seconds in each delete run (3 in total)
200 PVC deleted in parallel took188 seconds (single run)

@ShyamsundarR thanks for fetching the details separately. What I see here is, with just timeout change the operations are faster for first 15 requests, from there on, it crawl. Not sure how that happens , ie if the lock is good enough for "15" parallel requests, I was expecting it should work for next set too :). Btw, the create or delete script introduce a sleep in each iteration, so I am not sure we can call these samples as 'parallel` requests.

@ShyamsundarR thanks for fetching the details separately. What I see here is, with just timeout change the operations are faster for first 15 requests, from there on, it crawl. Not sure how that happens , ie if the lock is good enough for "15" parallel requests, I was expecting it should work for next set too :). Btw, the create or delete script introduce a sleep in each iteration, so I am not sure we can call these samples as 'parallel` requests.

If you are referring to the scripts in this comment, then the sleep (of 1 second) is to check how many PVCs are in the bound state (post create issued) and how many PVs are deleted (post delete issued). This happens post issuing the creates or deletes in a tight loop above and does not impede the parallelism.

How many PVs did we end up having in the system? It's unclear to me. If we are doing 200 in parallel, and it took us 162 seconds overall to complete the initial 200, I assume there were many more created in parallel, right? To me it'd be easier to understand something like:
"To create 1000 PVs in total with 200 PVC requests in parallel took X seconds to complete" and "To create 1000 PVs in total with 10 PVC requests in parallel took X seconds to complete" kind of measurements.

How many PVs did we end up having in the system? It's unclear to me. If we are doing 200 in parallel, and it took us 162 seconds overall to complete the initial 200, I assume there were many more created in parallel, right? To me it'd be easier to understand something like:
"To create 1000 PVs in total with 200 PVC requests in parallel took X seconds to complete" and "To create 1000 PVs in total with 10 PVC requests in parallel took X seconds to complete" kind of measurements.

@mykaul looks like you reposted your comment, my original answer to this is here

added DNM label jus to avoid merging

nit: https://github.com/ceph/ceph-csi/pull/443/files#r298987001
other than that LGTM

Addressed the nit. @Madhu-1 PTAL.

@humblec PTAL

@ShyamsundarR @Madhu-1 I am doing final review , will get back soon.

I will remove the targetpath and attachlocks in other PRs. Rest of the discussions here can be taken up in a follow up PR.
LGTM.


Global Availability

Hello do we have any idea of when this great solution will become GA ?

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

ID: 77f273ec-aed5-1f65-0b6d-87240765d3e0
Version Independent ID: d195959f-5742-7d94-f4f5-e70c0f0581e7
Content: Azure SQL Analytics solution in Azure Monitor - Azure Monitor
Content Source: articles/azure-monitor/insights/azure-sql.md
Service: azure-monitor
Sub-service: logs
GitHub Login: @danimir
Microsoft Alias: danil

@Aurel-Bruno Thank you for reaching out , will check with our Internal Product team to get additional information on the GA time line and update you accordingly.

The product group at this point does not have plans to GA SQL Analytics. We do intend to keep the product alive for a foreseeable future until new or a better product is available. As such, you are advised not to take a strong dependency on products in public preview. Thank you.

Thanks for this information.  Is it possible to have a list of the recommended alert to setup to efficiently monitor the availability and health of azure databases?


[feature] ordering OneToMany collections

I saw a bit of discussion in #157...
I have a 'Rig' and it has a collection of 'Gpus'...
Rig {
  gpus = new Collection<Gpu>(this);
}

Gpu {
  index: number;
}

I'd like the collection to be returned ordered by gpu.index / asc.
Seems like this could be done in the database, but I think it might also be interesting to be able to have Collection have a builder pattern such that I could do:
gpus = Collection.sort(myCustomSortMethod).build<Gpu>(this);
That sort could then be run on Collection.add so everything is always sorted.
Thoughts?

Tests pass! ;-) Must be a better way...
	async getRig(id: string, populate: boolean = true): Promise<Rig | null> {
		const foundRig = await this.em.findOne(Rig, {id: id}, {populate});
		if (foundRig) {
			if (foundRig.gpus) {
				const items = sortBy(foundRig.gpus.getItems(), ['index']);
				foundRig.gpus.set(items);
			}
			return foundRig;
		}
		return null;
	}

Must be a better way

I think you could simply extend Collection class yourself and implement this directly in add/set methods.
Sounds more like an extension than something to be in the core. Also you could re-use the orderBy attribute instead of using custom sort callback, that way it would be consistent - that is something I can imagine being implemented directly in the Collection class.
Btw I am planning to enhance the collection wrapper so it can be paginated and filtered, something similar like doctrine has. Can't find the right docs right now but they do support same API for both fetched and non-fetched collections.

I think the better way is to be able to specify the sort order in the database query on the populated collection.

I think the better way is to be able to specify the sort order in the database query on the populated collection.

Not sure what you mean, that is what is in place right now, or not? Or you mean to be able to have the collection ordered differently, based on how you query the owning entity?

I would love something like this:
this.em.findOne(Rig, id, {populate, orderBy: {gpus: {index: 'asc'}}})

Maybe I'm confused, but when I tried that, it didn't work. It put the order by on the initial query for the rig, not the query for the gpus collection.

The thing is that every entity is loaded via one query (where in ...). So your example would load Rig entity, ordered by gpu's index property. But then, the gpus collection population would fire another query without this orderBy (with orderBy based on the collection's attribute if provided).
But this could be (hopefully) propagated down to the query that loads the collection, I am fine with that.

"So your example would load Rig entity, ordered by gpu's index property."
It is a findOneById, there is no order on Rig and definitely not an order based on the gpu's index.
So unless I'm not understanding something, the logic should absolutely be to push/propagate the order by down to the Gpu query since that is what I'm effectively asking for in the orderBy clause.

It is a findOneById, there is no order on Rig and definitely not an order based on the gpu's index.

Check the query log to see what's happening. It is findOne but you specify orderBy. Under the hood, findOne is just find + limit(1). And this is how currently nested where/orderBy works. It is just about the top level query, but again, it could be propagated, for orderBy it makes sense, not totally sure if it's ok for where as well (e.g. I can imagine problems with partially populated collections).
There is some discussion about current implementation in the issue you mentioned (#157). This is how populate works right now: https://mikro-orm.io/nested-populate/

I did check the query and see what is happening... that is why I wrote: "It put the order by on the initial query for the rig, not the query for the gpus collection."

I think you could simply extend Collection class yourself and implement this directly in add/set methods.

Nope, thanks to the ObjectHydrator. =( It should use the implementation defined in the entity...

You could extend hydrator too :)

Interesting... sure, but why not just use the collection that is already on the property? no need to create a new one.

Also, I'd want to refactor the ObjectHydrator to have a protected method for creating the collection.

Well you cant use the one on entity as that is created from constructor, which is not used internally when creating entities from database records.

Could define the right one to use in the @OneToMany annotation?

Yeah factory method on decorator, I’m fine with that.

Propagating of where and orderBy to populated queries is available for testing in 3.0.0-alpha.24.

Very sexy...
return this.em.findOne(Rig, id, {populate, orderBy: {gpus: {index: QueryOrder.ASC}}});
[query] select e0.* from Gpuase0left joinRigase1one0.rig=e1.idwheree0.rigin ('1') group bye0.idorder bye0.index asc [took 0 ms]
Now I can delete the in memory sorting code and I can return the promise up to apollo, instead of having to await it in the resolver.

Go ahead and close it if you want.

Yeah I don't like the idea of doing some magic in Collection.add(), one can always easily sort things before adding to collection, or when updating, you can use set to replace the whole collection with new sorted items. Let's close this now, I might add something like Collection.sort() later though, when enhancing the collection wrapped. Was thinking about adding some basic array helpers there so one can directly work with the collection like with array:
const col = new Collection(...);
const found = col.getItems().find(i => i.foo === 'bar'); // current approach
const found = col.find(i => i.foo === 'bar'); // future?

I am thinking about find/map/sort/reverse/forEach/has methods (I would go for has instead of includes probably).

Collection helpers would be nice, but not a deal breaker since it is easy enough to just work on the array. People should just be using the database to get what they need since that is what it is good for.

The ultimate goal would be to support both things with same api.


backspace crash on certain nested delims

pressing backspace here crashes
Screenshot 2024-11-03 at 11.52.29 PM

still happens post 1ffeaaa9


pageserver: expose prometheus metrics for startup time

Problem
Currently to know how long pageserver startup took requires inspecting logs.
Summary of changes
pageserver_startup_duration_ms metric is added, with label phase for different phases of startup.
These are broken down by phase, where the phases correspond to the existing wait points in the code:

Start of doing I/O
When tenant load is done
When initial size calculation is done
When background jobs start
Then "complete" when everything is done.

Checklist before requesting a review

[ ] I have performed a self-review of my code.
[ ] If it is a core feature, I have added thorough tests.
[ ] Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
[ ] If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

[ ] Do not forget to reformat commit message to not include the above checklist

We should add these metrics to ... list of global metrics somewhere in the python regress suite. Those tests are quite the mess, we assert metrics in two different files and there are easy failures, but a global metric is not bad. I will have to do the same for #4892.
Feel free to look into #4813 as well.
I'll link this to some observability epic.


Redesign select alert

Have iOS select options slide in from the bottom
Same alert api, just different css and animation

Hello! We are moving our feature requests to a new feature request doc. I have moved this feature request to the doc and because of this I will be closing this issue for now. Thanks for using Ionic!


SEND CAPABILITY IDS TO LXC

Sending capability ids instead of capability names ot LXC for --cap-add and --cap-drop.
Also fixed tests.
Docker-DCO-1.1-Signed-off-by: Abin Shahab<EMAIL_ADDRESS>(github: ashahab-altiscale)

@jfrazelle @crosbymichael @unclejack @dineshs-altiscale

@ashahab-altiscale Thanks so much for the continual effort of fixing the tests :)
Do you think there is a way to check the output differently for these so that it works for lxc as well, because it looks like they should be passing:
--- FAIL: TestRunCapDropCannotMknod (0.87s)
	docker_cli_run_test.go:962: <nil> ok

--- FAIL: TestRunCapDropCannotMknodLowerCase (1.11s)
	docker_cli_run_test.go:977: <nil> ok

--- FAIL: TestRunCapDropALLCannotMknod (1.14s)
	docker_cli_run_test.go:992: <nil> ok

--- FAIL: TestRunCapAddALLDropNetAdminCanDownInterface (1.13s)
	docker_cli_run_test.go:1064: <nil> ok

--- FAIL: TestRunUnPrivilegedCannotMount (1.10s)
	docker_cli_run_test.go:1096: <nil> ok

Odd, they all passed for me. I will have to  check how its failing in
Jenkins. Can you send me a link?
On Jan 17, 2015 2:26 PM, "Jessie Frazelle"<EMAIL_ADDRESS>wrote:

@ashahab-altiscale https://github.com/ashahab-altiscale Thanks so much
for the continual effort of fixing the tests :)
Do you think there is a way to check the output differently for these so
that it works for lxc as well, because it looks like they should be passing:
--- FAIL: TestRunCapDropCannotMknod (0.87s)
docker_cli_run_test.go:962:  ok
--- FAIL: TestRunCapDropCannotMknodLowerCase (1.11s)
docker_cli_run_test.go:977:  ok
--- FAIL: TestRunCapDropALLCannotMknod (1.14s)
docker_cli_run_test.go:992:  ok
--- FAIL: TestRunCapAddALLDropNetAdminCanDownInterface (1.13s)
docker_cli_run_test.go:1064:  ok
--- FAIL: TestRunUnPrivilegedCannotMount (1.10s)
docker_cli_run_test.go:1096:  ok
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387204.

Oh I tested locally not on Jenkins. I am on Debian with Btrfs, but idk if
that could have anything to do with it.
On Sat, Jan 17, 2015 at 2:47 PM, Abin Shahab<EMAIL_ADDRESS>wrote:

Odd, they all passed for me. I will have to check how its failing in
Jenkins. Can you send me a link?
On Jan 17, 2015 2:26 PM, "Jessie Frazelle"<EMAIL_ADDRESS>wrote:

@ashahab-altiscale https://github.com/ashahab-altiscale Thanks so
much
for the continual effort of fixing the tests :)
Do you think there is a way to check the output differently for these so
that it works for lxc as well, because it looks like they should be
passing:
--- FAIL: TestRunCapDropCannotMknod (0.87s)
docker_cli_run_test.go:962:  ok
--- FAIL: TestRunCapDropCannotMknodLowerCase (1.11s)
docker_cli_run_test.go:977:  ok
--- FAIL: TestRunCapDropALLCannotMknod (1.14s)
docker_cli_run_test.go:992:  ok
--- FAIL: TestRunCapAddALLDropNetAdminCanDownInterface (1.13s)
docker_cli_run_test.go:1064:  ok
--- FAIL: TestRunUnPrivilegedCannotMount (1.10s)
docker_cli_run_test.go:1096:  ok
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387204.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387892.

Its not an issue with output. Its just not working. If you want to dig more
into this, you can tell lxc where to log and the log level(in
lxc/driver.go). I am thinking if I should create a patch with that feature,
which would be enabled only in debug mode.
On Jan 17, 2015 2:49 PM, "Jessie Frazelle"<EMAIL_ADDRESS>wrote:

Oh I tested locally not on Jenkins. I am on Debian with Btrfs, but idk if
that could have anything to do with it.
On Sat, Jan 17, 2015 at 2:47 PM, Abin Shahab<EMAIL_ADDRESS>wrote:

Odd, they all passed for me. I will have to check how its failing in
Jenkins. Can you send me a link?
On Jan 17, 2015 2:26 PM, "Jessie Frazelle"<EMAIL_ADDRESS>wrote:

@ashahab-altiscale https://github.com/ashahab-altiscale Thanks so
much
for the continual effort of fixing the tests :)
Do you think there is a way to check the output differently for these
so
that it works for lxc as well, because it looks like they should be
passing:
--- FAIL: TestRunCapDropCannotMknod (0.87s)
docker_cli_run_test.go:962:  ok
--- FAIL: TestRunCapDropCannotMknodLowerCase (1.11s)
docker_cli_run_test.go:977:  ok
--- FAIL: TestRunCapDropALLCannotMknod (1.14s)
docker_cli_run_test.go:992:  ok
--- FAIL: TestRunCapAddALLDropNetAdminCanDownInterface (1.13s)
docker_cli_run_test.go:1064:  ok
--- FAIL: TestRunUnPrivilegedCannotMount (1.10s)
docker_cli_run_test.go:1096:  ok
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387204.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387892.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387954.

I'll try again thanks
On Saturday, January 17, 2015, Abin Shahab<EMAIL_ADDRESS>wrote:

Its not an issue with output. Its just not working. If you want to dig
more
into this, you can tell lxc where to log and the log level(in
lxc/driver.go). I am thinking if I should create a patch with that
feature,
which would be enabled only in debug mode.
On Jan 17, 2015 2:49 PM, "Jessie Frazelle"<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

Oh I tested locally not on Jenkins. I am on Debian with Btrfs, but idk
if
that could have anything to do with it.
On Sat, Jan 17, 2015 at 2:47 PM, Abin Shahab<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

Odd, they all passed for me. I will have to check how its failing in
Jenkins. Can you send me a link?
On Jan 17, 2015 2:26 PM, "Jessie Frazelle"<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

@ashahab-altiscale https://github.com/ashahab-altiscale Thanks so
much
for the continual effort of fixing the tests :)
Do you think there is a way to check the output differently for
these
so
that it works for lxc as well, because it looks like they should be
passing:
--- FAIL: TestRunCapDropCannotMknod (0.87s)
docker_cli_run_test.go:962:  ok
--- FAIL: TestRunCapDropCannotMknodLowerCase (1.11s)
docker_cli_run_test.go:977:  ok
--- FAIL: TestRunCapDropALLCannotMknod (1.14s)
docker_cli_run_test.go:992:  ok
--- FAIL: TestRunCapAddALLDropNetAdminCanDownInterface (1.13s)
docker_cli_run_test.go:1064:  ok
--- FAIL: TestRunUnPrivilegedCannotMount (1.10s)
docker_cli_run_test.go:1096:  ok
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387204.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387892.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387954.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70388916.

Jessie,
What do you see if you try this: docker run --cap-add=ALL
--cap-drop=NET_ADMIN busybox sh -c 'ip link set eth0 down && echo ok'
(replace the docker binary with one created from "make binary" in my
branch)?
Abin
On Sat, Jan 17, 2015 at 3:25 PM, Jessie Frazelle<EMAIL_ADDRESS>wrote:

I'll try again thanks
On Saturday, January 17, 2015, Abin Shahab<EMAIL_ADDRESS>wrote:

Its not an issue with output. Its just not working. If you want to dig
more
into this, you can tell lxc where to log and the log level(in
lxc/driver.go). I am thinking if I should create a patch with that
feature,
which would be enabled only in debug mode.
On Jan 17, 2015 2:49 PM, "Jessie Frazelle"<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

Oh I tested locally not on Jenkins. I am on Debian with Btrfs, but idk
if
that could have anything to do with it.
On Sat, Jan 17, 2015 at 2:47 PM, Abin Shahab<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

Odd, they all passed for me. I will have to check how its failing in
Jenkins. Can you send me a link?
On Jan 17, 2015 2:26 PM, "Jessie Frazelle"<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

@ashahab-altiscale https://github.com/ashahab-altiscale Thanks
so
much
for the continual effort of fixing the tests :)
Do you think there is a way to check the output differently for
these
so
that it works for lxc as well, because it looks like they should
be
passing:
--- FAIL: TestRunCapDropCannotMknod (0.87s)
docker_cli_run_test.go:962:  ok
--- FAIL: TestRunCapDropCannotMknodLowerCase (1.11s)
docker_cli_run_test.go:977:  ok
--- FAIL: TestRunCapDropALLCannotMknod (1.14s)
docker_cli_run_test.go:992:  ok
--- FAIL: TestRunCapAddALLDropNetAdminCanDownInterface (1.13s)
docker_cli_run_test.go:1064:  ok
--- FAIL: TestRunUnPrivilegedCannotMount (1.10s)
docker_cli_run_test.go:1096:  ok
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387204.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387892.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387954.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70388916.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70389084.

Actually, please also make sure there are no old docker images lurking
around. I got the same errors, but once I cleared the old images,
everything was fine. Ideally this tests should run in a machine with only
busybox.
Abin
On Sat, Jan 17, 2015 at 8:39 PM, Abin Shahab<EMAIL_ADDRESS>wrote:

Jessie,
What do you see if you try this: docker run --cap-add=ALL
--cap-drop=NET_ADMIN busybox sh -c 'ip link set eth0 down && echo ok'
(replace the docker binary with one created from "make binary" in my
branch)?
Abin
On Sat, Jan 17, 2015 at 3:25 PM, Jessie Frazelle<EMAIL_ADDRESS>
wrote:

I'll try again thanks
On Saturday, January 17, 2015, Abin Shahab<EMAIL_ADDRESS>wrote:

Its not an issue with output. Its just not working. If you want to dig
more
into this, you can tell lxc where to log and the log level(in
lxc/driver.go). I am thinking if I should create a patch with that
feature,
which would be enabled only in debug mode.
On Jan 17, 2015 2:49 PM, "Jessie Frazelle"<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>> wrote:

Oh I tested locally not on Jenkins. I am on Debian with Btrfs, but
idk
if
that could have anything to do with it.
On Sat, Jan 17, 2015 at 2:47 PM, Abin Shahab <
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

Odd, they all passed for me. I will have to check how its failing
in
Jenkins. Can you send me a link?
On Jan 17, 2015 2:26 PM, "Jessie Frazelle" <
<EMAIL_ADDRESS><javascript:_e(%7B%7D,'cvml','notifications@github.com');>>
wrote:

@ashahab-altiscale https://github.com/ashahab-altiscale Thanks
so
much
for the continual effort of fixing the tests :)
Do you think there is a way to check the output differently for
these
so
that it works for lxc as well, because it looks like they should
be
passing:
--- FAIL: TestRunCapDropCannotMknod (0.87s)
docker_cli_run_test.go:962:  ok
--- FAIL: TestRunCapDropCannotMknodLowerCase (1.11s)
docker_cli_run_test.go:977:  ok
--- FAIL: TestRunCapDropALLCannotMknod (1.14s)
docker_cli_run_test.go:992:  ok
--- FAIL: TestRunCapAddALLDropNetAdminCanDownInterface (1.13s)
docker_cli_run_test.go:1064:  ok
--- FAIL: TestRunUnPrivilegedCannotMount (1.10s)
docker_cli_run_test.go:1096:  ok
—
Reply to this email directly or view it on GitHub
<
https://github.com/docker/docker/pull/10152#issuecomment-70387204>.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387892.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70387954.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70388916.

—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70389084.

@jfrazelle Any feedback on this?

so sorry, going back through it all now

I am running them again here so it is easier to show you the output I am seeing https://jenkins.dockerproject.com/job/LXC PR Test/label=ubuntu-aufs-lxc/1/console

welp the tests work there so great :)

LGTM

LGTM

Thanks @jfrazelle. So is https://jenkins.dockerproject.com/job/LXC PR Test a permanent set of jobs that I can check for my pull requests? The drone.io console logs are always from a native driver build I think.

Not permanent, but I will probably trigger it if you open more PRs :)
On Mon, Jan 19, 2015 at 10:05 AM, Abin Shahab<EMAIL_ADDRESS>wrote:

Thanks @jfrazelle https://github.com/jfrazelle. So is
https://jenkins.dockerproject.com/job/LXC PR Test a permanent set of
jobs that I can check for my pull requests? The drone.io console logs are
always from a native driver build I think.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70535980.

But yes, the tests it runs are a better representation than drone, which
uses the native graph driver, eventually we hope, once all tests pass
across lxc is to run these on every PR so we can be sure no additions to
the code base  break the lxc execdriver as well.
On Mon, Jan 19, 2015 at 10:15 AM, Jessica Frazelle<EMAIL_ADDRESS>wrote:

Not permanent, but I will probably trigger it if you open more PRs :)
On Mon, Jan 19, 2015 at 10:05 AM, Abin Shahab<EMAIL_ADDRESS>wrote:

Thanks @jfrazelle https://github.com/jfrazelle. So is
https://jenkins.dockerproject.com/job/LXC PR Test a permanent set of
jobs that I can check for my pull requests? The drone.io console logs
are always from a native driver build I think.
—
Reply to this email directly or view it on GitHub
https://github.com/docker/docker/pull/10152#issuecomment-70535980.

@ashahab-altiscale is this good to be merged?

@crosbymichael yes it is ready to merge.

OK, thanks!
LGTM


nextcloud: restrict web server support to nginx; stop sharing nginx user/group; improve setup service

Things done
(This description is heavily outdated. Plans changed a lot due to the discussions. See below)

user and group used by all nextcloud related services are now unified and configurable. If nginx is enabled, the group will be forced to nginx and an error is raised if group is set manually.
nginx is enabled by default now. (In favor of having a working default configuration)
phpfpm also uses configured nextcloud user + group
In the setup service instead of mkdir + chown now install is used to setup the directories.
This has the disadvantage that the group of nextcloud cannot be changed anymore on an existing installation without having to fix the ownership of files manually. But it think chowning all files on every single startup is bad since it's a very intense operation and can take very long depending on the amount of files stored. Also the chown operation itself might not be allowed depending on the filesystem. I for example use a sshfs mount for my nextcloud files where this fails

fixes #69261
fixes #48881

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[x] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Did anyone of you test what happens when deploying this configuration to an existing Nextcloud instance? Also, what's supposed to happen if cfg.user changes (or someone switches e.g. from nginx to httpd?).

please check https://github.com/NixOS/nixpkgs/pull/93584/commits/6ee30041327343137bab79cf924eac1a17ad0d5c.

removed optons cfg.user, cfg.groups
add option serverUser which is required when not using nginx
add serverUser to nextcloud group
set user/group to "nextcloud" for nextcloud services
make setup-service non-root

Did not yet implement a solution for fixing group ownership of files for existing installations. Your suggestions are welcome.

@DavHau for context how are you trying to run nginx? caddy?

Sorry my description of what I changed was not very precise.
All nextcloud services now use the user and group "nextcloud" (hard-coded). The web server user must therefore be part of the the nextcloud group.
The webserver user can be configured via cfg.serverUser.
This user will be automatically added to the nextcloud group and it will be used for listen.owner of phpfpm. Also its group will automatically be used for listen.group
cfg.serverUserdefaults to the nginx user if nginx is enabled. Otherwise it must be specified manually.
An example configuration using nginx would be:
(if nothing specified nginx will be enabled and its user added to the nextcloud group)
{ pkgs, ... }:
{
  networking.firewall.allowedTCPPorts = [80];
  services.nextcloud = {
    enable = true;
    hostName = "<IP_ADDRESS>";
    config.adminpass = "test";
    package = pkgs.nextcloud19;
  };
}

A configuration for an alternative webserver could  look like this:
{ pkgs, ... }:
{
  networking.firewall.allowedTCPPorts = [80];
  services.nextcloud = {
    enable = true;
    hostName = "<IP_ADDRESS>";
    config.adminpass = "test";
    package = pkgs.nextcloud19;

    # disable nginx and set serverUser
    nginx.enable = false;
    serverUser = "caddy";

    # caddy config
    ...
  };
}

@DavHau by having a configurable web server user in this module it seems we're just circling back around to https://github.com/NixOS/nixpkgs/issues/93070.
@Ma27 I suggest we remove the nginx.enable option entirely and just take it as a given: this module is for nginx only.

removed option nextcloud.nginx.enable. Nginx is now the only supported web server.
modified nextcloud-setup service to fix group ownership of nextcloud files if they don't match.
All installations prior to this PR will be fixed by this. (changed from nginx -> nextcloud).

Things done:

deprecated services.nextcloud.nginx.enable option via mkRemovedOptionModule
replaced chown with chgrp
fixed tests by removing use of option services.nextcloud.nginx.enable
use mkDefault for services.nginx.enable

We should mention this in our release-notes. When having a big library in your nextcloud, the chown will take some time, so admins should be aware of this before deploying the new config.

I don't think this will be necessary. Up until this point the setup service always did a chown an all nextcloud files on each startup. Therefore the new implementation doesn't bring any performance drawbacks compared to the old one.

This broke then manual: log. Plz fix, kthxbye. Or wait for a 10-12h, then I'll probably get around to it myself.

@ajs124: Fixed in 1365b9ac700aabe8dc959e9897bc1376e416c553.

Thanks @ajs124 .
@Ma27 I thought we still wanted to improve the phrase The nextcloud module dropped support for other webservers than nginx..
But now the PR has already been merged. Should I make another commit ontop of this PR and repopen it?

@aszlig @ajs124 sorry for that!
@DavHau yeah feel free to do that :) Otherwise I'll take care of this next week.

Just for the record, this PR caused another regression in #95259 which got fixed in fddeb7cb73096786de8e59a8502cf3ae523bd694.
I'm fully aware that I merged this too early which is why I want to openly apologize to everyone who went into trouble because of the (now fixed) regressions I caused with the merge!

Hello,
I have read the manual on how to use a different webserver for nextcloud.
However, I don't really get why, to prevent nginx being configured for nextcloud, it is now necessary to completely disable nginx.
What if, I want to have the nginx service enabled for something else while still wanting to use, let's say httpd, as the web server for nextcloud ?
Thank you in advance for the clarification :)


IM Support

Shall it support IM?

What is IM?

Hi @joaquinicolas, thank you for your inquiry. It would be great if eventually this library supported the entire Zoom v2 API! If you are interested in contributing this feature, I would be happy to review a pull request. This is likely the fastest way to see this feature implemented.


feat: add RBACOwnable to implement Ownable with RBAC

🚀 Description
Implement the Ownable API using RBAC

excluding the owner() public getter because we're not saving that address in contract storage, only their permissions

TODO

[ ] rebase on #868 and add emit and update solidity pragma

[x] 📘 I've reviewed the OpenZeppelin Contributor Guidelines

[x] ✅ I've added tests where applicable to test my new functionality.

[x] 📖 I've made sure that my contracts are well-documented.

[x] 🎨 I've run the JS/Solidity linters and fixed any issues (npm run lint:all:fix).

I'm not sure we should go this way. When we talked I was thinking of throwing Ownable away entirely: replacing the permissions mechanism for e.g. MintableToken with a "minter" role, instead of an owner.
I haven't thought about it too much yet and I'm not sure exactly what it would look like.

 Like the bouncer contract in another PR, or crowdsales, etc. It's the simplest permissions layer. I agree that there should be an RBACMintable that has minting-specific language (although the implementation won't be much different from this RBACOwnable) that we can use in MintableToken and MintableERC721Token

closing because RBACOwnable doesn't provide enough advantages over existing Ownable. Probably worth re-discussing in the future when we may want to replace Ownable with RBAC entirely across the board.


Add institution configuration options

This PR adds InstitutionConfigurationOptions to the SamlToken. The options are set whenever a user has been authenticated and are exposed to Twig via global parameters.
This can only be merged when a stable MiddlewareClientBundle release is required through composer, offering the InstitutionConfigurationOptions API.
Note: commit history has been rebased to make more sense, yet Github show it chronologically

Travis is failing (as it should), because we are not depending on a stable Middleware-clientbundle release.

Let some early feedback :wink:

:-1:

@DRvanR

:+1:


Unhelpful error message "Suspicious TODO in line "

In teamed/xockets-layer#1036, we got the following error message:
INFO: "reading src/main/resources/xsl/stats/layout.xsl..."
/var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd/source.rb:144:in `rescue in puzzles': ["in ./src/main/resources/xsl/stats/layout.xsl", #<PDD::Error: Suspicious TODO in line #36>] (PDD::Error)
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd/source.rb:142:in `puzzles'
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd.rb:97:in `block (3 levels) in xml'
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd.rb:96:in `each'
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd.rb:96:in `block (2 levels) in xml'
    from /var/lib/gems/2.2.0/gems/nokogiri-<IP_ADDRESS>/lib/nokogiri/xml/builder.rb:391:in `call'
    from /var/lib/gems/2.2.0/gems/nokogiri-<IP_ADDRESS>/lib/nokogiri/xml/builder.rb:391:in `insert'
    from /var/lib/gems/2.2.0/gems/nokogiri-<IP_ADDRESS>/lib/nokogiri/xml/builder.rb:375:in `method_missing'
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd.rb:95:in `block in xml'
    from /var/lib/gems/2.2.0/gems/nokogiri-<IP_ADDRESS>/lib/nokogiri/xml/builder.rb:293:in `initialize'
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd.rb:93:in `new'
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/lib/pdd.rb:93:in `xml'
    from /var/lib/gems/2.2.0/gems/pdd-0.15.1/bin/pdd:90:in `<top (required)>'
    from /usr/local/bin/pdd:23:in `load'
    from /usr/local/bin/pdd:23:in `<main>'

It turns out, it was complaining about a puzzle that looks like the following:
                 @todo 1033:30min Below there are two style sections...

The problem here is that the format is wrong. It lacks a # character before the ticket number and should start with "@todo #1033:30min. However, the error message is unhelpful (why is a TODO "suspicious"?). The error should state something useful, similar to:
At line 36, formatting is incorrect in TODO starting with "@todo 1033:30min"...

@yegor256 please dispatch this issue

@carlosmiranda I think it's better now: 8bd5a91

@rultor release, tag is 0.15.2

@rultor release, tag is 0.15.2

@yegor256 OK, I will release it now. Please check the progress here

@rultor release, tag is 0.15.2

@yegor256 Done! FYI, the full log is here (took me 4min)


Constraint proper cleanup/destruction

In recent builds for controllers I noticed crashes when switching tabs. I found this to be related to constraints trying to cleanup.
First with RemoveConstraint but later even with Raw.module.destroy()
For now I've commented out the removal function but it needs to be determined the best way to do this.
Asked on the Jolt Discussions Here.

See this comment
Constraints need to be destroyed BEFORE bodies are removed.
Will probably need a constraint register on the PhysicsSystem checks for bodies when they remove themselves to test if they belong to existing constraints.
Maybe that should also be on the body-state itself?


Improve documentation for table pagination

Widget: Table
Feature: Server Side Pagination
https://docs.appsmith.com/widget-reference/table
And some tooltips on the property pane of a table.

Problem description
Explanations given for the feature could be clearer. So the users find it easier to implement it in their tables.
Example of some properties:

Total Record Count
From the tooltip, it's not very clear what this property actually does. A lot of the information could be moved to the docs, in my opinion.

Also the documentation is missing for "Total Record Count" property.

onPageSizeChange - missing documentation

Server side pagination (Docs)
"Use this property when your table data is being bound to an API / Query".
This line could be removed and replaced with more useful information. (Suggestions below)

Describe the improvement
The critical information the user needs to know, in order to implement server side pagination is as follows:

Total number of pages is decided by two factors pageSize and Total Records Count. (Not addressed in the documentation)
Understand pageSize is an internal property, that changes with table and row heights. (This is addressed in the documentation)
Total Records Count has to be set. Else the pages will not stop once we reach the last record. (Not addressed)
API/Queries need to use pageNo and pageSize and will have to be called on OnPageChange and OnPageSizeChange (Addressed heavily in tooltips, could be shifted to docs instead)

(Please add to this if I have missed/misunderstood something)

Suggested changes

Total Record Count

Change to tooltip: “Used to limit number of pages to a finite number" / "Stops pagination once the table reaches the last record."
Change to docs: Same as above + “pageSize is the other factor that decides the number of pages to be generated

e.g. Total records = 50, PageSize = 10. Number of pages will be 5.”

Add documentation for "OnPageSizeChange"

Server side pagination (Suggested changes to docs):

Enables you to implement pagination by limiting the number of results fetched per API / Query request.
Use pageNo (Page number) and pageSize to configure API/Query params accordingly
Call the API/Query, OnPageChange and OnPageSizeChange

Server side pagination (tooltip): "Fetch only the records required for a page. (Requires appropriate API/Query configuration)"

P.S. Also consider reviewing other tooltips and documentations pertaining paginations, which may not be mentioned here.

Can I do this job

Additional internal discussion about this -  https://theappsmith.slack.com/archives/CGBPVEJ5C/p1643702368121879

Reach: 250 in last 6 months
Impact: High

Properties - TableRowCount and onPageSizeChange added and available on docs.appsmith.com.

Feedback for docs only - https://docs.appsmith.com/core-concepts/displaying-data-read/display-data-tables#pagination
Thought process

Are the pre-requisites clear - PageSize, PageNo, Using the same query
Is the process clear - Each step broken down for the table

Items noted

Currently there's no information on what PageSize and PageNo are in the page we need to link it or expand on it
We need to show the steps sequentially on how to configure pagination we are talking about it on a high level. A video will help better here

Switch on Server side pagination
Update the query
Bind the onPageChange event to the same query
Add a new query for total record count
Bind the result to total record count

onPageSizeChange - This should be a separate section as this can only work when the developer is resizing the table. This has indirect impact on pagination and can be mentioned in the table's documentation rather than here.

CC - @jnikhila @Pranay105

@danciaclara - Please share pointers on the above.

@danciaclara Did we manage to do this?

@Rishabhkaul - This will be worked about as part of the Rehaul project and is in the pipeline to be picked up.
CC: @Pranay105 - FYI, when you start working on this ticket.


docs: if OPENFGA_LIST_OBJECTS_MAX_RESULTS=0, no limit

Description
Fixes for ListObjects:

Undo a change made in https://github.com/openfga/openfga/pull/733 - if ListObjectsMaxResults is 0, we make a results channel of size 1, not 0.
Fix goroutine leak that can happen if the main goroutine exits and the child goroutines attempt to write an error, previously they became blocked in this line or this line. (This is verifiable through https://github.com/uber-go/goleak)
Document that if ListObjectsMaxResults is 0, there is no limit in the number of results returned

Review Checklist

[ ] I have clicked on "allow edits by maintainers".
[x] I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
[x] The correct base branch is being used, if not main
[ ] I have added tests to validate that the change in functionality is working as expected

Hi @miparnisari and @jon-whit.
We've been experimenting with OpenFGA at Cochlear and we'd like to appreciate the amazing work you've been doing. It's awesome to see this how this project's evolving.
On a more codebase related question: How are you ensuring you return all data when OPENFGA_LIST_OBJECTS_MAX_RESULTS is set to 0?
I couldn't find any test case that validates that flow.
Also, that setting doesn't seem to work for me. I'm happy to help and contribute with a fix if that's the case.
Thank you!

@jcbertolucci Thanks for the kind words! In regards to your bug report, you're right, I just tested it locally and I get 0 results. :( Opened https://github.com/openfga/openfga/issues/1044

Thanks heaps @miparnisari.


Feat/custom property url

New custom property type - URL.

Task linked: TECH-3231 Implement new custom properties for CRMs


website is not proper responsive

Describe the bug
The responsiveness gets disrupted within a width of 1140px, and a horizontal scrollbar appears when scrolling from left to right.

i want to work on this issue please assign me

#1308


Dots spinner shows extra lines on iOS

Ionic version:
[x ] 1.x
I'm submitting a ...
[x] bug report
Current behavior:
When using the 'dots' spinner with ionicLoading, the svg shows tiny 'lines' right below or next to the last dot. This only occurs on iOS. See screenshot.

Steps to reproduce:
Create an ionic app based on the code below (or use the plnkr). I also have an Ionic View app which I can share.
Note: this issue ONLY occurs in a 'real' iOS app. It does not occur in the plunkr, not even when run in Safari on iOS.
Plunker:
https://plnkr.co/edit/JcDkKbjL4CmqUJJIorMz?p=preview
Related code:
app.js:
app.constant("$ionicLoadingConfig", {
    template: "<ion-spinner icon=\"dots\"></ion-spinner>"
});

controller:
.controller('HomeCtrl', function($ionicLoading) {
  $ionicLoading.show();
})

custom styles:
.loading-container .loading {
  background-color: transparent;
}

.spinner {
  stroke: #fff;
  fill: #fff;
}

.spinner svg {
  width: 96px;
    height: 96px;
}

.backdrop {
  background-color: #222;
}

Ionic info:
Ionic CLI Version: 2.1.18
Ionic App Lib Version: 2.1.9
ios-deploy version: Not installed
ios-sim version: Not installed
OS: Windows 8.1
Node Version: v5.5.0
Xcode version: Not installed

Thanks for opening an issue with us, we will look into this.

Hello, sorry just realized this was an Ionic 1 issue, because of this I am going to be moving it to our v1 issues repo. Thanks!

This issue was moved to driftyco/ionic-v1#205


Unable to use https://github.com/exupero/saveSvgAsPng/blob/gh-pages/src/saveSvgAsPng.js as source

Hi,
I am using saveSvgAsPng to generate a file to read the contents of the svg. In my code i have used "https://rawgit.com/exupero/saveSvgAsPng/gh-pages/saveSvgAsPng.js" as the script source to access "svgAsDataUri". When i run the page where the link mentioned above is used it throws "Refused to execute script from 'https://rawgit.com/exupero/saveSvgAsPng/gh-pages/saveSvgAsPng.js' because its MIME type ('') is not executable, and strict MIME type checking is enabled." I tried with the below URL as well. Still i was getting the same when click the save link on the page.
https://github.com/exupero/saveSvgAsPng/blob/gh-pages/src/saveSvgAsPng.js .
Could you please me with the how should i go with this. Thanks in Advance.
Thanks,
Harish S

You can link directly to the source script with this URL: http://exupero.org/saveSvgAsPng/src/saveSvgAsPng.js
That's an ES6 file, so if you need ES5 compatibility, you'll need to get the module from NPM.


Add "How to use" to README.md

Any kind of instructions might be helpful - regarding how to run (I guess it's "build on your own" as there are no binaries linked), and how the UI works.

Hey! There are binaries, please check the Releases section and choose the correct binary for your OS

You're right. I'm not used to looking for that section on GitHub yet.

Even though this is not what the OP meant, I do believe there should be a small list of steps on how to configure your project to work with sidekick. The old repo had it.

There are some instructions on how to get up and running at https://github.com/leoafarias/sidekick/blob/main/INSTALLING.md


[K8S] Show more details for pod/container status in application error

:mag: Description
Now the information for k8s app error is too short and confuse.
For example:
App Id: spark-8d04e31b6c9540f6952fde81fcc4e19f
App State: FAILED
App Diagnostic: kyuubi-spark-2c7d0d5a-c25b-4b36-bcd0-250c97c90025-driver/spark-kubernetes-driver[Error]

We need to provide more information to help debug.
For PodStatus:
    public String toString() {
        return "PodStatus(conditions=" + this.getConditions() + ", containerStatuses=" + this.getContainerStatuses() + ", ephemeralContainerStatuses=" + this.getEphemeralContainerStatuses() + ", hostIP=" + this.getHostIP() + ", initContainerStatuses=" + this.getInitContainerStatuses() + ", message=" + this.getMessage() + ", nominatedNodeName=" + this.getNominatedNodeName() + ", phase=" + this.getPhase() + ", podIP=" + this.getPodIP() + ", podIPs=" + this.getPodIPs() + ", qosClass=" + this.getQosClass() + ", reason=" + this.getReason() + ", resize=" + this.getResize() + ", startTime=" + this.getStartTime() + ", additionalProperties=" + this.getAdditionalProperties() + ")";
    }

For ContainerState:
    public String toString() {
        return "ContainerState(running=" + this.getRunning() + ", terminated=" + this.getTerminated() + ", waiting=" + this.getWaiting() + ", additionalProperties=" + this.getAdditionalProperties() + ")";
    }

In this pr, we show the PodStatus or ContainerState directly and provide more useful information.
Issue References 🔗

This pull request fixes #
Describe Your Solution 🔧
Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change.
Types of changes :bookmark:

[ ] Bugfix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Test Plan 🧪
Behavior Without This Pull Request :coffin:
Behavior With This Pull Request :tada:
Related Unit Tests

Checklist 📝

[ ] This patch was not authored or co-authored using Generative Tooling

Be nice. Be informative.

Codecov Report
Attention: 14 lines in your changes are missing coverage. Please review.

Comparison is base (8c3f471) 61.12% compared to head (f8152e7) 61.02%.
Report is 1 commits behind head on master.

Files
Patch %
Lines

...kyuubi/engine/KubernetesApplicationOperation.scala
0.00%
10 Missing :warning:

.../java/org/apache/kyuubi/client/util/JsonUtils.java
0.00%
4 Missing :warning:

Additional details and impacted files
@@             Coverage Diff              @@
##             master    #6053      +/-   ##
============================================
- Coverage     61.12%   61.02%   -0.11%
  Complexity       23       23
============================================
  Files           623      623
  Lines         37186    37195       +9
  Branches       5040     5041       +1
============================================
- Hits          22730    22698      -32
- Misses        12003    12042      +39
- Partials       2453     2455       +2

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

merged to 1.9.0, thanks


various bugs when iterating over list literals

There's a print statement in the first function that should print 0 and 1. Instead it prints 1 on both iterations.
In the second function there's a loop over [0, 1]. Changing that to [5, 4] causes a segmentation fault.
Using latest commit from master.
pythran:
import math
import numpy

#pythran export inc (
#   int, int, int,
#   bool [],
#   bool
#)
def inc (
    b, c, y,
    t,
    m
):
    ta = ftc (
        b, c, y,
        t,
        m
    )

    gis = 0.
    tno = numpy.empty(shape = (2))
    for cnum in ([0,1] if m else [0]):
        tno[cnum] = 123.
    for cnum in ([0,1] if m else [0]):
        print (cnum)                            # prints 1 both times
        gis += 123.

    ret = gis - ta

    return ret

#pythran export ftc (
#   int, int, int,
#   bool [],
#   bool
#)
def ftc (
    b, c, y,
    t,
    m
):
    cin = [7,8]

    ed = []
    for cnum in [0,1]:                          # change [0,1] to [5,4] ---> segfault
        if b < 5:
            ed.append (456.)
        else:
            ed.append (0.)

    ret = 0.

    if (c + y) < 65 and t[y] and m and cin[1] is not None:
        ret += 543.21

    return ret

runner:
import numpy
from test import inc

m = True
b = 60
c = 60
t = numpy.asarray([False] * 30)
y = 14

inc (
    b, c, y,
    t,
    m
)

It's a bug in range computation, I'll investigate that. Thanks for reporting!


Fix #202

So the reason it does that is because whenever the component property (v-model) changes render() will create a new, different component, which will have to be mounted. Now the solution is to place all render logic inside setup. setup should however return a function which returns the element.
So, instead of doing this,
render() {
  return h(...)
}

We do the following,
setup() {
  return () => h(...)
}

This way the component will be created only once.
Related issue which I faced a year ago: https://github.com/vuejs/vue-next/issues/3235#issuecomment-779308808
I see some few other places where you return the element inside render. I think we should use setup instead. Just let me know and I will do the changes.

I started by putting render functions as return from setup. But if I recall got some issues with reactivity.
Don't remember the circumstances so it might have been a problem in my code
Another possible solution might be to calculate the id in the setup and pass that to the render function.
But for me this fix is ok

If you got issues with reactivity then I am not sure if we should merge this PR. Could you maybe try to remember what component were you coding at that time?

For me this fix is ok. if you can run the samples from the docs, because those are my test cases as well when I build the BFormGroup

So the reason it does that is because whenever the component property (v-model) changes render() will create a new, different component, which will have to be mounted. Now the solution is to place all render logic inside setup. setup should however return a function which returns the element.
So, instead of doing this,
render() {
  return h(...)
}

We do the following,
setup() {
  return () => h(...)
}

This way the component will be created only once.
Related issue which I faced a year ago: vuejs/vue-next#3235 (comment)
I see some few other places where you return the element inside render. I think we should use setup instead. Just let me know and I will do the changes.

Return in setup function is the correct behavior, could you make the necessary changes in the other files, please?

Sure!

I think I found the reactivity issue. So in BOverlay you have this,
let $overlay: any = ''

if (props.show) {
....
$overlay = h(...)
}

Assuming we have placed all render logic inside setup, when props.show is toggled then overlay element will not be shown because inside setup the component is created only once and all the logic have been ran already. Now to fix this, all we need is to wrap the logic inside a function,
function getOverlay() {
  if(!props.show) return null

  return h(...)
}

Of course, we can use also computed, ref as we need as these functions will run whenever the dependency changes.
This is critical one to work with. We have to verify each and every component is working as expected manually (since we don't have tests for all components) after moving all logic inside setup. At this moment, I am sorry I cannot work on this as it might require a lot of time.

Reading the docs, I think your assumption is not correct. Please note, this is not meant to be a harsh comment, we both just want to understand how things work.
According to my interpretation of the docs and my testing (and again I could be completely wrong ...)

Returning a render function from setup is the same as defining it separately in the options API
The only difference is that you have access to the reactive state and the parameters given to setup (props, slots, emit, ...)
Returning from setup means that you define the render function. It doesn't mean that it will be run only once.
The render function does not make a new component each time it is run, it renders the component in html. The virtual dom compares the newly created html and with make updates to the dom where needed.

To test this, I updated the Overlay component to be returned from the setup and after changing all references to "this" and make sure to use .value when accessing refs or computed, everything worked like it used to. I did not have to wrap the "if props.show" in a getOverlay function.
The original problem with the FormGroup id being recreated is that the id is calculated within the render function. Meaning that with each render, a new id was calculated. The only logic within a render function should be to render the html, so calculating the id within render was definitely wrong.
I'll update the components that user render function so that the render function is returned from the setup
There are not that many components that use render, most use templates

BIcon, BOverlay, BPagination, BTransition are the only components using the render from options api
BProgressbar, Btable already return render from setup

Hey that's okay. We all learn new things everyday. Maybe my comment on saying that component would be created every time was false. Maybe I mixed things up with the issue I was facing in past. I apologize for that.
Although I am surprised the overlay issue worked for you. Maybe I did something wrong it didn't work for me at all.

Why doesn't it work for me lol?
https://user-images.githubusercontent.com/91611516/139668992-3050d2f5-e5e8-4945-b258-104b4204d75a.mov
This is the code. I just moved render logic to setup and replaced computed/refs with .value.
<script lang="ts">
import ColorVariant from '../../types/ColorVariant'
import {toFloat} from '../../utils/number'
import {computed, defineComponent, h, PropType, resolveComponent} from 'vue'
import {normalizeSlot} from '../../utils/normalize-slot'
import BTransition from '../BTransition/BTransition.vue'

const POSITION_COVER = {top: 0, left: 0, bottom: 0, right: 0}
const SLOT_NAME_DEFAULT = 'default'
const SLOT_NAME_OVERLAY = 'overlay'

interface ISlotScope {
  spinnerType: string | null
  spinnerVariant: string | null
  spinnerSmall: boolean
}

export default defineComponent({
  name: 'BOverlay',
  components: {BTransition},
  props: {
    bgColor: {type: String, required: false},
    blur: {type: String, default: '2px'},
    fixed: {type: Boolean, default: false},
    noCenter: {type: Boolean, default: false},
    noFade: {type: Boolean, default: false},
    // If `true, does not render the default slot
    // and switches to absolute positioning
    noWrap: {type: Boolean, default: false},
    opacity: {
      type: [Number, String],
      default: 0.85,
      validator: (value: number | string) => {
        const number = toFloat(value, 0)
        return number >= 0 && number <= 1
      },
    },
    overlayTag: {type: String, default: 'div'},
    rounded: {type: [Boolean, String], default: false},
    show: {type: Boolean, default: false},
    spinnerSmall: {type: Boolean, default: false},
    spinnerType: {type: String, default: 'border'},
    spinnerVariant: {type: String, required: false},
    variant: {type: String as PropType<ColorVariant>, default: 'light'},
    wrapTag: {type: String, default: 'div'},
    zIndex: {type: [Number, String], default: 10},
  },
  emits: ['click', 'hidden', 'shown'],
  setup(props, {emit, slots}) {
    const computedRounded = computed(() =>
      props.rounded === true || props.rounded === ''
        ? 'rounded'
        : !props.rounded
        ? ''
        : `rounded-${props.rounded}`
    )

    const computedVariant = computed(() =>
      props.variant && !props.bgColor ? `bg-${props.variant}` : ''
    )

    const computedSlotScope = computed(() => ({
      spinnerType: props.spinnerType || null,
      spinnerVariant: props.spinnerVariant || null,
      spinnerSmall: props.spinnerSmall,
    }))

    const defaultOverlayFn = (scope: ISlotScope) =>
      h(resolveComponent('BSpinner'), {
        type: scope.spinnerType,
        variant: scope.spinnerVariant,
        small: scope.spinnerSmall,
      })

    let $overlay: any = ''

    if (props.show) {
      const $background = h('div', {
        class: ['position-absolute', computedVariant.value, computedRounded.value],
        style: {
          ...POSITION_COVER,
          opacity: props.opacity,
          backgroundColor: props.bgColor || null,
          backdropFilter: props.blur ? `blur(${props.blur})` : null,
        },
      })

      const $content = h(
        'div',
        {
          class: 'position-absolute',
          style: props.noCenter
            ? {...POSITION_COVER}
            : {top: '50%', left: '50%', transform: 'translateX(-50%) translateY(-50%)'},
        },
        normalizeSlot(SLOT_NAME_OVERLAY, computedSlotScope.value, slots) ||
          defaultOverlayFn(computedSlotScope.value) ||
          ''
      )

      $overlay = h(
        props.overlayTag,
        {
          class: [
            'b-overlay',
            {
              'position-absolute': !props.noWrap || (props.noWrap && !props.fixed),
              'position-fixed': props.noWrap && props.fixed,
            },
          ],
          style: {
            ...POSITION_COVER,
            zIndex: props.zIndex || 10,
          },
          onClick: (event: MouseEvent) => emit('click', event),
          key: 'overlay',
        },
        [$background, $content]
      )
    }

    const getOverlayTransition = () =>
      h(
        BTransition,
        {
          noFade: props.noFade,
          name: 'fade',
          appear: true,
          onAfterEnter: () => emit('shown'),
          onAfterLeave: () => emit('hidden'),
        },
        {default: () => $overlay}
      )

    if (props.noWrap) return getOverlayTransition()

    const wrapper = h(
      props.wrapTag,
      {
        'class': ['b-overlay-wrap position-relative'],
        'aria-busy': props.show ? 'true' : null,
      },
      [h('span', normalizeSlot(SLOT_NAME_DEFAULT, {}, slots)), getOverlayTransition()]
    )
    return () => wrapper
  },
})
</script>

What am I missing?

Your code indeed does not work.
If you look at my code in PR #206, you see that I create the helper render variable in the main render function
so instead of
const defaultOverlayFn = (scope: ISlotScope) =>
      h(resolveComponent('BSpinner'), {
        type: scope.spinnerType,
        variant: scope.spinnerVariant,
        small: scope.spinnerSmall,
      })
...
return () => wrapper

I do
return () => {
    const defaultOverlayFn = (scope: ISlotScope) =>
        h(resolveComponent('BSpinner'), {
          type: scope.spinnerType,
          variant: scope.spinnerVariant,
          small: scope.spinnerSmall,
        })
   ....
   return wrapper
}

You're code gives warnings in the console
[Vue warn]: setup() should not return VNodes directly - return a render function instead.
So you are basically returning the VNodes directly instead of a function that creates VNodes

I get no such error in console and I do return a render function () => wrapper.
I think your solution worked because you placed the logic inside the render function. So as you said above instead of doing the following,
const defaultOverlayFn = (scope: ISlotScope) =>
      h(resolveComponent('BSpinner'), {
        type: scope.spinnerType,
        variant: scope.spinnerVariant,
        small: scope.spinnerSmall,
      })
...
return () => wrapper

You did,
return () => {
    const defaultOverlayFn = (scope: ISlotScope) =>
        h(resolveComponent('BSpinner'), {
          type: scope.spinnerType,
          variant: scope.spinnerVariant,
          small: scope.spinnerSmall,
        })
   ....
   return wrapper
}

Which means the function will be called everytime component needs to re-render which in this case is props.show.


add Backd skin

Hi! What is your PR about?

[x] Add or edit a skin
[ ] Add a custom domain for your space
[ ] Add an alias to migrate your space

@gokaiorg Thanks! Have added it 😄

@gokaiorg Thanks! Have added it 😄

@chase-manning You will need to add also the skin name in the export default object line 270 in the index.js file.

@gokaiorg Thanks! Have added it 😄

@chase-manning You will need to add also the skin name in the export default object line 270 in the index.js file.

@gokaiorg
Sorry! Thanks have added that!

@gokaiorg I think this one should be good to go now! 🚀


command 'extension.handleEnter' not found

In style.css folder when i try do go to next line by pressing enter, there is being written ''command 'extension.handleEnter' not found''

/needsMoreInfo including version, platform and whether the Start Extension Bisect command identifies an extension as causing the problem.

extension.handleEnter is a command that comes from an extension. You can find out which extension it is by using the Start Extension Bisect command, as described by @gjsjohnmurray

Thanks!
пт, 19 нояб. 2021 г., 13:25 Martin Aeschlimann @.***>:

extension.handleEnter is a command that comes from an extension. You can
find out which extension it is by using the Start Extension Bisect command,
as described by @gjsjohnmurray https://github.com/gjsjohnmurray
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/vscode/issues/137463#issuecomment-973859525,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AWMC2VP2U4BTMEUYKPKDVZ3UMYCXLANCNFSM5IKINHYA
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.


Updated setup.py to force install of redtoregext

I have updated setup.py to force install of redtoregext module which is needed for both pygrib and/or ncepgrib2.

Don't see why this is necessary - can you elaborate on the problem?  redtoreg.so seems to install fine for me.

This is for when a user just wants to install the ncepgrib2 module.

Bringing my fork up to date


No view LOs for Johann, Master of the Graphql Recipe Cookview

This is no-go; we'll integrate on the mainline w/ no-view-los coming second.


Feature request: National list on competitor page

When looking at Live results I am often interested in seeing the results of other people from my Country. In that respect it would be great to have result list or summary for all competitors for a country in the /competitors page

I think we shouldn't show results on the competitors page, because then we effectively need to show all results from the competition. But I'm open to improving the page to allow sorting/searching by nationality.


Cannot read property '0' of undefined in the ui-tree

Here is my code ..

@rintaun @gilluminate
when i add new data in the list i am getting error..

Most of the time you get this error when you forgot to change the ng-model="" to the $scope property
Wrong example:

Correct example:

Good luck

Closing this issue due to inactivity. See #815 for more information.
Please create a new issue is this still occurs with the current version of the component.


Allow setting aria-label, aria-labelledby and aria-describedby on Popup

Feature Request
Problem description
It is not possible to set aria-label, aria-labelledby and aria-describedby attributes on the popup slot of the Popup component
Proposed solution
Allow seting aria-label, aria-labelledby and aria-describedby attributes on the popup slot of the Popup component - use aria-label, aria-labelledby, aria-describedby props for that

This is now possible.