MINOR: Introduce ProducerIdGenerator trait

ProducerIdManager is an existing class that talks to ZooKeeper directly.  We won't have ZooKeeper when using a Raft-based metadata quorum, so we need an abstraction for the functionality of generating producer IDs.  This PR introduces ProducerIdGenerator for this purpose, and we pass an implementation when instantiating TransactionCoordinator rather than letting TransactionCoordinator.apply() itself always create a ZooKeeper-based instance.
More detailed description of your change,
if necessary. The PR title and PR message become
the squashed commit message, so use a separate
comment to ping reviewers.
Summary of testing strategy (including rationale)
for the feature or bug fix. Unit and/or integration
tests are expected for any behaviour change and
system tests should be considered for larger changes.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Only test failure is a known flaky test: https://issues.apache.org/jira/browse/KAFKA-7940

This one looks good to me...

JDK 8 build exited (JDK 11 and 15 passed), so restarted the PR builder.

Weird, red build again. Restarted it once again.

Two unrelated flaky failures:

Build / JDK 15 / org.apache.kafka.connect.integration.RebalanceSourceConnectorsIntegrationTest.testMultipleWorkersRejoining
Build / JDK 8 / org.apache.kafka.connect.integration.BlockingConnectorTest.testBlockInSinkTaskStart


Reference panel layout breaks when narrow with Display and Buttons categories

Bug Description
Reference panel layout breaks when it is narrow with Display and Buttons categories.
How To Reproduce
Steps to reproduce the behaviour:

Go to 'https://python.microbit.org/v/beta'
Make the Reference panel narrow
Select Display or Buttons
See error as in screenshot

Expected behaviour
Works the same as other categories.
Screenshots

Environment
Desktop (please complete the following information):

OS: [e.g. iOS] Windows 10
Browser [e.g. chrome, safari] Chrome
Version [e.g. 22] 100.0.4896.127

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

Relates to #638 prehaps?

Fix merged. It should be on beta in < 10 mins. You can also try it via the link on #708.


Connection pooling

IBM-Swift/Swift-Kuery#16
Implementation of Connection pooling. The pool management is based on the code written by @djones6.

Codecov Report

Merging #66 into master will decrease coverage by 4.3%.
The diff coverage is 0%.

@@            Coverage Diff             @@
##           master      #66      +/-   ##
==========================================
- Coverage   93.06%   88.76%   -4.31%
==========================================
  Files          35       38       +3
  Lines        3116     3267     +151
==========================================
  Hits         2900     2900
- Misses        216      367     +151

Impacted Files
Coverage Δ

Sources/SwiftKuery/ConnectionPoolConnection.swift
0% <0%> (ø)

Sources/SwiftKuery/ConnectionPool.swift
0% <0%> (ø)

Sources/SwiftKuery/ConnectionPoolOptions.swift
0% <0%> (ø)

Continue to review full report at Codecov.

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


starting fails

Some things are deprecated, and should be updated I guess. Such an awesome project, should be kept alive.
Environment

Kitto version: 0.9.1

Elixir / Hex version (mix hex.info):
Hex:    0.15.0
Elixir: 1.8.1
OTP:    21.2.7
     Built with: Elixir 1.3.4 and OTP <IP_ADDRESS>

Node / NPM version (node -v) (npm -v):

➜  app1 node -v
v11.11.0
➜  app1 npm -v
6.7.0

Operating system:
mac os

Current behavior
Generated app1 app
11:56:20.033 [info] Starting Kitto server, listening on <IP_ADDRESS>:4000
11:56:20.071 [warn] Setting Ranch options together with socket options is deprecated. Please use the new map syntax that allows specifying socket options separately from other options.
/Users/tomaz/razvoj/elixir/dashboards-Kitto/app1/node_modules/webpack-cli/bin/convert-argv.js:138
const webpackConfigurationValidationErrors = validateSchema(webpackConfigurationSchema, options);
^
TypeError: validateSchema is not a function
at processConfiguredOptions (/Users/tomaz/razvoj/elixir/dashboards-Kitto/app1/node_modules/webpack-cli/bin/convert-argv.js:138:48)
at module.exports (/Users/tomaz/razvoj/elixir/dashboards-Kitto/app1/node_modules/webpack-cli/bin/convert-argv.js:132:10)
at Object. (/Users/tomaz/razvoj/elixir/dashboards-Kitto/app1/node_modules/webpack-dev-server/bin/webpack-dev-server.js:92:55)
at Module._compile (internal/modules/cjs/loader.js:799:30)
at Object.Module._extensions..js (internal/modules/cjs/loader.js:810:10)
at Module.load (internal/modules/cjs/loader.js:666:32)
at tryModuleLoad (internal/modules/cjs/loader.js:606:12)
at Function.Module._load (internal/modules/cjs/loader.js:598:3)
at Function.Module.runMain (internal/modules/cjs/loader.js:862:12)
at internal/main/run_main_module.js:21:11
Expected behavior
server is listening, but nothing is shown.... exept few black dots on top left corner ul -> li without content.
Is there any fast fix for this? or project is more or less unmaintained?
Best,
Tomaz

Hi @ulutomaz thanks for opening this issue.
For the deprecation warning there is a quick fix and I'll push it in the following days.
Now for the Webpack error it's hard to estimate it at the moment. A solution could be to use an older version of node / npm. Unfortunately it's not easy to keep up with the pace of node releases to ensure compatibility.

Is there any fast fix for this? or project is more or less unmaintained?

I don't understand the use of or in the above sentence. It is maintained in the sense that I do my best to provide security updates and respond to critical issues.

This probably warrants more investigation than the little that I did. However, here is what worked for me (where "worked" is a very bare minimum of "I could view the sample"):
From perusing Stack Overflow posts, and comparing them to my output and code spelunking, it seemed a webpack, webpack-cli, webpack-dev-server version mismatch issue of some sort. I borrowed a solution from this SO post, resulting in my fixing a few versions in my package.json to specific versions, removing node_modules/, and running npm install again.
  "devDependencies": {
    "webpack-dev-server": "2.9.7",
    "webpack-cli": "2.0.10"
  },
  "dependencies": {
    "kitto": "file:deps/kitto",
    "webpack": "3.10.0",
    // ...
  }

Then I had some webpack config issues.
First, on line 24 of webpack.config.js, I changed the empty string to '*'. This was a stab in the dark, though a slightly, maybe halfway, kinda educated guess sorta stab in the dark. It moved me on to the next issue.
On line 25, I changed modulesDirectories to modules.
Then, in the loaders section, I added the suffix -loader to every one. Every. One.
    loaders: [
      { test: /\.css$/, loaders: ['style-loader', 'css-loader'] },
      { test: /\.scss$/, loaders: ['style-loader', 'css-loader', 'sass-loader'] },
      { test: /\.jsx?$/, loaders: ['babel-loader?cacheDirectory'] },
      {
        test: /\.(svg|png|jpe?g|gif)(\?\S*)?$/,
        loader: 'url-loader?limit=1000&name=images/[name].[ext]'
      },
      {
        test: /\.(eot|woff|woff2|ttf)(\?\S*)?$/,
        loader: 'url-loader?limit=1000&name=fonts/[name].[ext]'
      },
      {
        test: require.resolve('jquery-knob'),
        loader: "imports-loader?require=>false,define=>false,this=>window"
      },
      {
        test: PATHS.d3,
        loader: "script-loader"
      },
      {
        test: require.resolve('rickshaw'),
        loader: "scriptuloader"
      }
    ]

Now mix kitto.server runs, and I can view the sample dashboard. Hooray!
Hopefully this is helpful to someone else. I think there's a better solution with regards to locking webpack, et al versions. This is working for me for now, though.

Thank you very much @mileszs for your investigation. I'll spend some time to ensure the mix generator always produces a package.json and webpack config which works out of the box.

@zorbash No sweat, man.  Actually, technically I'm involved in a webpack-based React app on a daily basis and I still mostly just used Stack Overflow to get a half-solution here. Haha. Hopefully it's still at least half-useful. :-)

@mileszs Finally someone who gets me 😅
I have a branch where I'm making attempts to have it working with the latest version of webpack, but I'm not there yet. I'm even having thoughts of ditching webpack completely, or starting over the FE part from part using the most recent guides.


Add severity granularity options for tests

Feature
Feature description
I would like to be able to assign a severity level to a given test.  For semantic clarity, I suggest these align with typical Python log levels of INFO, WARN, and ERROR.  I would like to be able to configure schema.yml to set a particular test as one of those levels, to distinguish tests that should be regarded as game-breaking if they fail from tests that are relevant, but not critical.
version: 2
models:
- name: some_table
  columns:
  - name: a_really_important_field
    tests:
    - not_null:
        severity: ERROR
  - name: some_foreign_key
    tests:
    - not_null
    - relationships:
        severity: INFO
        field: provider_id
        to: ref('some_other_table')
  - name: a_supposedly_enum_field
    tests:
    - accepted_values:
        severity: WARN
        values:
        - Foo
        - Bar

Who will this benefit?
This would be particularly helpful for people using Sinter.  Today, any test failure in Sinter causes the job running dbt test to report an Error state.  There are many "anomalies" that dbt test can detect that I want to know about, but don't rise to the level of wanting to consider them "errors".

@rsmichaeldunn thanks for the feature request! I think this is a good idea.
I've also been thinking about setting a max_error attribute for schema tests, so eg. < 10 failures wouldn't trigger an error, but would instead be surfaced as a warning.
I think that max_error and severity are both useful and not mutually exclusive. Do you have any opinions on if max_error would be useful too? And if so, do you imagine the two working together? I'm thinking something like "warn for less than 10 instances of a faulure, but throw an error if it's more than that"

+1 to this feature request.
Having ERROR andWARN levels make would be great, with tests defaulting to the ERROR level. How would the INFO level differ from WARN?
@drewbanin If level is set to WARN, there can be a max_error defined where the level changes from WARN to ERROR. Would be great if max_error could be defined on an absolute or a relative (to total rows) basis to account for growing data sets. Maybe the INFO level should be a test which has no threshold and will never return an error?

There might not be a relevant distinction between INFO and WARN and I'm happy to leave that to the design sensibilities of more skilled developers than I.
I can see the usefulness of a threshold beyond which a WARN becomes an ERROR but one pitfall there might be how that threshold is defined.  It'd be nice if a proportional figure could be specified, e.g. if >0.5% of records violate, then ERROR.

ok, let's prioritize this one for 0.13.0 if possible. Spec:
version: 2
models:
- name: some_table
  columns:
  - name: a_really_important_field
    tests:
    - not_null:
        severity: ERROR | WARN

By default, the severity for a test is ERROR, but it can optionally be set to WARN.  This pairs nicely with #1243 (warnings as errors, prioritized in this release). There's some more work that could be done here for sure -- the ability to specify a maxerror or tags are both compelling, but let's make separate issues for those features if still desired.
The one caveat with this approach is that severity looks like a test argument here. That means that schema tests can no longer accept an arg called severity. I don't love this, but I'm unsure how else we can specify severity levels at a test-specific scope. The alternative would be to make severity levels apply to the whole model/column, but that sort of misses the mark IMO.
If this poses a problem (either technically, or just in kudginess), we can pick a dbt-specific name that shouldn't collide with user test args, like or _severity or __severity__. I think both of these are bad names, but open to discussing alternatives if folks have any opinions.
cc @cmcarthur @rsmichaeldunn @dwallace0723 @JasonGluck

An alternative that I've proposed and will work on, to sidestep the arg confusion issue:
version: 2
models:
- name: some_table
  columns:
  - name: a_really_important_field
    tests:
    - not_null, severity=ERROR | WARN

You can imagine adding a max_error= on the end of that as well.


Update onnx.proto for int4

Update onnx.proto from https://github.com/onnx/onnx/blob/main/onnx/onnx.proto

@lakhinderwalia  please fix the format failure

@lakhinderwalia please fix the format failure

We should be ignoring this file since it's coming from onnx.

Exception didnt work. @causten we should just merge it in. Since the format is done on a diff this wont affect other PRs.


collection.index not working on MongoDB 3.4

When trying to create  / ensure index on MongoDB 3.4
(sample code:
var my_collection= db.get('my_collection_name');
my_collection.index({some_field_name:1}, function (err) {...});
)
I'm getting MongoError: The field 'fields' is not valid for an index specification.
The same code works on MongoDB 3.2

+1, would be great to get this fixed, otherwise need to use the underlying mongo driver


Autolayout Constraints

I am not sure if this issue is because of a tableviewcell or something I missed in the documentation.  I can't seem to get a TVC to work in a Nib file once I add AutoLayoutConstraints.

Samples will be added to the project, but for now you can take a look at the #21 and the sample I've uploaded at the end. This will help you.


Flaky Test from NativeMemoryAllocationTests

Flaky test is coming from  https://github.com/opensearch-project/k-NN/actions/runs/11113230012/job/30877097217?pr=2167
Tests with failures:
888 tests completed, 3 failed, 223 skipped
 - org.opensearch.knn.index.memory.NativeMemoryAllocationTests.testIndexAllocation_closeBlocking
 - org.opensearch.knn.index.memory.NativeMemoryAllocationTests.classMethod

 REPRODUCE WITH: gradlew ':test' --tests "org.opensearch.knn.index.memory.NativeMemoryAllocationTests" -Dtests.seed=9A46305B6CCE0712 -Dtests.security.manager=false -Dtests.locale=en-US -Dtests.timezone=Etc/UTC -Druntime.java=21

 gradlew ':test' --tests "org.opensearch.knn.index.memory.NativeMemoryAllocationTests" -Dtests.seed=9A46305B6CCE0712 -Dtests.security.manager=false -Dtests.locale=en-US -Dtests.timezone=Etc/UTC -Druntime.java=21

 gradlew ':test' --tests "org.opensearch.knn.index.memory.NativeMemoryAllocationTests.testIndexAllocation_closeBlocking" -Dtests.seed=9A46305B6CCE0712 -Dtests.security.manager=false -Dtests.locale=tt -Dtests.timezone=Europe/Ljubljana -Druntime.java=21

This PR(#2139) is trying to fix this flaky testing.
In which, it changed its way to read a lock first then followed by calling close().
    public void testIndexAllocation_closeBlocking() throws InterruptedException, ExecutionException {
        // Prepare mocking and a thread pool.
        WatcherHandle<FileWatcher> watcherHandle = (WatcherHandle<FileWatcher>) mock(WatcherHandle.class);
        ExecutorService executorService = Executors.newSingleThreadExecutor();

        // Enable `KNN_FORCE_EVICT_CACHE_ENABLED_SETTING` to force it to block other threads.
        // Having it false will make `IndexAllocation` to run close logic in a different thread.
        when(clusterSettings.get(KNN_FORCE_EVICT_CACHE_ENABLED_SETTING)).thenReturn(true);
        NativeMemoryAllocation.IndexAllocation blockingIndexAllocation = new NativeMemoryAllocation.IndexAllocation(
            mock(ExecutorService.class),
            0,
            0,
            null,
            "test",
            "test",
            watcherHandle
        );

        // Acquire a read lock
        blockingIndexAllocation.readLock();

        // This should be blocked as a read lock is still being held.
        Future<?> closingThread = executorService.submit(blockingIndexAllocation::close);

        // Check if thread is currently blocked
        try {
            closingThread.get(5, TimeUnit.SECONDS);
            fail("Closing should be blocked. We are still holding a read lock.");
        } catch (TimeoutException ignored) {}

        // Now, we unlock a read lock.
        blockingIndexAllocation.readUnlock();
        // As we don't hold any locking, the closing thread can now good to acquire a write lock.
        closingThread.get();

        // Waits until close
        assertTrue(blockingIndexAllocation.isClosed());
        executorService.shutdown();
    }

PR(https://github.com/opensearch-project/k-NN/pull/2139) fixed the timing issue.
We can close this and reopen issue if it is still reoccuring.
But at least, in the PR, the failed testing now has passed.


abracadabra: 2.2.2 -> 2.2.4

Description of changes
Bugfix release: https://github.com/KejPi/AbracaDABra/releases
Things done
Tested with an RTLSDR

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
23.11 Release Notes (or backporting 23.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 251466 run on x86_64-linux 1

1 package built:

abracadabra


Ability to control the Microsoft.Resources/deployments apiVersion

Is your feature request related to a problem? Please describe.
The Microsoft.Resources/deployments apiVersion, that is emitted for modules, is hardcoded:
https://github.com/Azure/bicep/blob/0d3b8a624e2ef4769f64b4bd263f649d08e85562/src/Bicep.Core/Emit/TemplateWriter.cs#L28
We have noticed that this az cli change broke az cli in certain, non-public clouds, where the new apiVersion was not (yet) available. This issue is about preventing same thing with bicep (if ever).
Describe the solution you'd like
For a module definition have a way to specify the apiVersion for the deployments.

We discussed exposing the ability to do this, but we really would like to avoid it. We are not planning to update the apiVersion for nested deployments used for modules and would regard that as a significant breaking change. This is a relatively old apiVersion and it should reliably be deployed everywhere. Thoughts?

Yeah, in which cloud was the api version unavailable?

My opinion is that it's actually a benefit that we control the API version - it gives us more flexibility to safely make API changes while avoiding breaking changes in Bicep.
As you mentioned, we do 100% need to ensure that we don't bump this version without first supporting that API version across all national clouds.

This was related to a national cloud. If you take the burden of ensuring that whenever you upgrade that api version it's already available everywhere, this issue can be closed. az cli has a really nice paste of changes, but it lacks a back-compat valve.

Mildly related to #5304


Different results CUDA - CPU

Results are very different using CUDA or CPU...
This is just an example:
tyod-216-2 Subtitles - CPU & CUDA.zip
Of course CUDA is like 10x faster or more. But it seems sometimes it just misses a lot. Sometimes there are parts on the video with people clearly talking and there isn't a single subtitle line for a long time...    is this due to the duration of the files?

#3

Referring to issue #3

Mmmm...   do you mean it will be fixed also in version 0.3?

@Milincho It should be fixed by v3.0 If vad and ve are open


Parser - Add discard flag to function call AST nodes

There should be a flag indicating that the return value of a function should be discarded for a particular call. This should result in an OP_POP instruction being generated after the function call code.

Return values of function calls where the immediate parent of the function call AST node is a scope node are discarded by inserted a OP_POP instruction after the function call code.


Generating SDK from the TypeSpec commit

Generating SDK from the latest commit from TypeSpec PR : https://github.com/Azure/azure-rest-api-specs/pull/30416

API change check
APIView has identified API level changes in this PR and created following API reviews.
azure-ai-translation-document

/azp run python - translation - tests


CHANGE: Removes non-project git-ignore entries.

Anything that is not project-specific does not belong in the project's .gitignore but in the global git ignore file.

Partially agree... 🚢

Yeah... I know what you mean... on the one hand it easier to just make a git broad spectrum ignore file, on the other it is better to educate people to do the right thing.
A few employers ago I decided to always go for educate and just endure the occasional commit accident.

I can support that approach 😃


MPI test for AD global_oce_latlon

What changes does this PR introduce?
feature
What is the current behaviour?
verification/global_oce_latlon did not have an MPI version
What is the new behaviour

verification/global_oce_latlon has an MPI version, only AD code is tested.
requires adjustment of data.grdchk

Does this PR introduce a breaking change?
No
Other information:
Suggested addition to tag-index

verification/global_oce_latlon: make MPI tests possible

It would be nice if we could add a test for AD-ggl90 for the TAF version.
We can do it here, or wait for @hajsong to sort out the Langmuir code and then do with Langmuir code in the corresponding PR. @jm-c what do you think?

@mjlosch One comment: I run the TAF-AD test on this experiment and it works nicely, identical AD grad (from grdchk) and only minor changes to AD-monitor. The forward grad (from grdchk) have changed a little bit (now 7 matching digits) but this was expected. I would prefer to update the TAF output (even if we don't really need to) to have the updated domain decomposition in the reference output, this way it's a bit easier for future comparison. Do you agree ?

Yes, let's update the TAF output.
I'll wait for changes in ggl90_mixinglength.F (#755) to add a AD-ggl90-test, so that we can already include the Langmuir code in the test.

Will merge this (small) PR very soon (later today ?).


iOS Issues

Webview launches with "Success" but only with a white empty page which then launches Safari.

After closing the webview, you cannot open it again.

webview.Show(
    url,
    function onSuccess(){
      console.log('Success');
      app.hideLoading();
    },
    function onError(error){
      console.log('Error opening presentation.');
    }
);

Got same behavior.

just comment out

it will work as expect.


object: add DBus signal

Signed-off-by: Filipe Laíns<EMAIL_ADDRESS>

@nojocodex can you have a look and test?

@nojocodex can you have a look and test?


nginx+apache+wp-rocket

Hello, Maxime!
Thank you for your config, I was surprised when I found completely prepared file :)
My hosting server works with nginx+apache so I wasn't sure if I configure all in a right way...
I'd like to hear your recommendation for current setup or just check my nginx config:
server {
        listen 80;
        server_name my.site www.my.site;
        location / {
        proxy_pass         http://<IP_ADDRESS>:8080/;
        proxy_redirect     off;
        proxy_set_header   Host             $host;
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $remote_addr;
        proxy_set_header Range "";
        client_max_body_size       10m;
        client_body_buffer_size    128k;
        proxy_connect_timeout      90;
        proxy_send_timeout         90;
        proxy_read_timeout         90;
        proxy_buffer_size          4k;
        proxy_buffers              4 32k;
        proxy_busy_buffers_size    64k;
        proxy_temp_file_write_size 10m;
        }

        # Deny files starting with a . (dot)
        location ~ /\. {
        deny all;
        }
        location ~* \.(jpg|jpeg|gif|png|ico|css|zip|tgz|gz|rar|bz2|doc|xls|exe|pdf|ppt|txt|tar|wav|bmp|rtf|js)$ {
        root /home/d_i180;

         # Add Rocket-Nginx configuration (of course !!)
            include rocket-nginx.conf;
        }
}

Hello,
You might want to look at the WordPress configuration in the documentation found here:
https://github.com/maximejobin/rocket-nginx/wiki/Nginx-configuration-for-WordPress
Many of the directives found in your file could be at a higher level.  That way, you won't have to copy/paste them for each and every site.
Thank you.


Update convertToVector3 - handle similar objects

In case the Vector3 instanceof doesn't match, but the object still has {x,y,z} values

Please check if the PR fulfills these requirements

[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features)
No doc change needed

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
Kind of a bugfix/code hardening

What is the current behavior? (You can also link to an open issue here)
If an object fails the instanceof check(which is currently happening for me, likely a webpack issue), it attempts to grab array values that don't exist, passing undefined to the constructor giving you a Vector3 of [0,0,0].

What is the new behavior (if this is a feature change)?
passing in a Vector3-like object will be properly converted to a Vector3

Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
It is technically breaking if you were using it wrong, but no behavior change for the expected inputs.

Nice, tested and LGTM, tests are always nice, thanks for the contrib!

:tada: This PR is included in version 4.20.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Add annotations to nodes for BGP Peering "Config" type

Packet has two types of switches in their fleet today. (With possibly more to come) These types today are Juniper and Arista.
These switches require different BGP peering options. In order for MetalLB to know the peering options, we'll need to add annotations to the nodes to specify which options are needed for peering.
The API that is hit is: https://api.packet.net/devices/<Instance_Id>/bgp/neighbors
The result looks like this:
{
  "bgp_neighbors": [
    {
      "address_family": 4,
      "customer_as": 65000,
      "customer_ip": "<IP_ADDRESS>",
      "md5_enabled": false,
      "md5_password": null,
      "multihop": false,
      "peer_as": 65530,
      "peer_ips": [
        "<IP_ADDRESS>"
      ],
      "routes_in": [
        {
          "route": "<IP_ADDRESS>/25",
          "exact": false
        }
      ],
      "routes_out": []
    }
  ],
  "device": {
    "href": "/devices/a9660769-d216-4bab-9068-8e5763e7f962"
  }
}

@deitch
@vielmetti
^^

The packngo dependency is noted at https://github.com/packethost/packngo/issues/176

Note the API docs at https://www.packet.com/developers/api/bgp/#bgp-getBgpNeighborData - which could use more detail in support of this implementation.

packngo has it merged in. The PR for getting annotations support into metallb is open at https://github.com/metallb/metallb/pull/593, and has the annotations supported listed here:
	MyASN    string `yaml:"my-asn"`
 	ASN      string `yaml:"peer-asn"`
 	Addr     string `yaml:"peer-address"`
 	Port     string `yaml:"peer-port"`
 	HoldTime string `yaml:"hold-time"`
 	RouterID string `yaml:"router-id"

Which of those do we need to add annotations for that are new? We already add annotations for MyASN, ASN, Addr. Is it just the rest there?

Update: we depend on metallb for how its speaker does BGP session setup and announcements. They currently do not have support for enabling multihop. The BGP message code is here

@pereztr5 mentioned that BGP sessions between MetalLB and the ToR router should work without the need to specify multihop.
One more thing to note about Arista switches is that they require static routes to be added in addition to the BGP session + loopback interface configuration. It should be done like this:
ip route add $peer-IP via $PRIVATE-IPV4-GATEWAY-address dev bond0
ip route add $peer-IP via $PRIVATE-IPV4-GATEWAY-address dev bond0

Peering IPs can be retrieve from the api.packet.net/devices/<instance_id>/bgp/neighbors API endpoint or metadata service though i did run into an instance today where the BGP neighbors object was completely missing from the metadata.

We also discovered that Calico does not allow IPs in the range of link-local address space (169.254. 0.0/16 (<IP_ADDRESS> – 169.254. 255.255)) which the Arista peering IPs fall under so the BGP session does not work between Calico and the ToR as done in this repo:
https://github.com/packet-labs/kubernetes-bgp

We switched ccm to using the appropriate endpoint in #62
However, we are keeping this open, since it still doesn't work with new switches, e.g. in ny5. See this comment, will repaste below.

(reposted from #62 to continue the discussion here)
The advertised routes do not show up in the Packet dashboard, and nothing gets through (obviously).
The Packet API endpoint for getting packet info succeeded. Here is what I got for one of them (ignoring the irrelevant pointers to other fields):
	{
		AddressFamily: 4,
		CustomerAs: 65000,
		CustomerIP: "<IP_ADDRESS>",
		Md5Enabled: false,
		Md5Password: "",
		Multihop: true,
		PeerAs: 65530,
		PeerIps: []string len: 2, cap: 4, [
			"<IP_ADDRESS>",
			"<IP_ADDRESS>",
		],
		RoutesIn: []github.com/packethost/packngo.BGPRoute len: 5, cap: 6, [
			(*"github.com/packethost/packngo.BGPRoute")(0xc000b14090),
			(*"github.com/packethost/packngo.BGPRoute")(0xc000b140a8),
			(*"github.com/packethost/packngo.BGPRoute")(0xc000b140c0),
			(*"github.com/packethost/packngo.BGPRoute")(0xc000b140d8),
			(*"github.com/packethost/packngo.BGPRoute")(0xc000b140f0),
		],
		RoutesOut: []github.com/packethost/packngo.BGPRoute len: 0, cap: 0, [],
}

I set the announcer to use just the first address <IP_ADDRESS>, which should be enough? The metallb config is pretty much the same on all nodes:
    peers:
    - my-asn: 65000
      peer-asn: 65530
      peer-address: <IP_ADDRESS>
      peer-port: 0
      hold-time: ""
      router-id: ""

Here are the logs from the metallb speaker:
{"caller":"bgp_controller.go:232","event":"updatedAdvertisements","ip":"<IP_ADDRESS>","msg":"making advertisements using BGP","numAds":1,"pool":"default/my-nginx","protocol":"bgp","service":"default/my-nginx","ts":"2020-07-14T10:31:49.493215005Z"}
{"caller":"main.go:246","event":"serviceAnnounced","ip":"<IP_ADDRESS>","msg":"service has IP, announcing","pool":"default/my-nginx","protocol":"bgp","service":"default/my-nginx","ts":"2020-07-14T10:31:49.493362204Z"}
{"caller":"main.go:249","event":"endUpdate","msg":"end of service update","service":"default/my-nginx","ts":"2020-07-14T10:31:49.493510105Z"}
{"caller":"bgp.go:58","error":"dial \"<IP_ADDRESS>:179\": timeout","localASN":65000,"msg":"failed to connect to peer","op":"connect","peer":"<IP_ADDRESS>:179","peerASN":65530,"ts":"2020-07-14T10:32:03.287379901Z"}
{"caller":"bgp.go:58","error":"dial \"<IP_ADDRESS>:179\": timeout","localASN":65000,"msg":"failed to connect to peer","op":"connect","peer":"<IP_ADDRESS>:179","peerASN":65530,"ts":"2020-07-14T10:32:21.297377411Z"}
{"caller":"bgp.go:58","error":"dial \"<IP_ADDRESS>:179\": timeout","localASN":65000,"msg":"failed to connect to peer","op":"connect","peer":"<IP_ADDRESS>:179","peerASN":65530,"ts":"2020-07-14T10:32:47.307370212Z"}

@c0dyhi11 @enkelprifti98, what are we missing?

Luca mentioned to me that using only one of the peer IPs means you're announcing to only one of the ToR so you don't get redundancy.
Regarding the error from the BGP speaker log, did you add a static route?
ip route add $peer-IP via $PRIVATE-IPV4-GATEWAY-address dev bond0

so you don't get redundancy.

Understood. More than happy to change it around to work with both (redundancy) once we can get it working with at least one. :-)

did you add a static route?

No, I did not. I didn't understand that is necessary. That would complicate things. That needs to be done on each host? Is that because it is using the 169.254.x.x address?

Correct it has to be done on any host doing a BGP session. I don't fully know the reasoning behind but I would assume that's why.
When I was testing yesterday I was not learning/announcing any routes until I added the static route as suggested by Tony and the NetOps team.

Let me see if I get this. In original DCs (or those with our original switches), we needed to:

Derive the gateway
Use the gateway as the BGP peer

In the new ones, we:

Derive the gateway
Use the BGP API endpoint to get the peer
Use the peer
Add a route to the local routing table that sets the previously-derived gateway as the route to the peer

Is that right? Did it just get significantly more complicated?

Yep that sounds correct to me. That's why I have been very against it :)

@enkelprifti98 we have no way to do this right now, and I don't see an easy way forward.
The ccm runs in a Deployment with a single instance running, as it should be, as it is a control loop (or, in dev mode, locally on your desktop connected to a cluster). The only thing running on each node is a DaemonSet of the metallb speakers, which:

creates the session with the upstream BGP peer
announces any routes

That is it. It is a very lightweight process. It doesn't even update the IP into the localhost to accept them (kube-proxy does that, as it uses IPs that are on the Service).
Adding specific routes on the host just for the upstream BGP peers is so unique that it is unlikely to get accepted upstream into metallb's speaker; I doubt anyone else using metallb is doing it that way.
I see several ways to do this, all of which are complicated:

try to upstream changes for this into metallb (chances are low)
create our own binary and container image and DaemonSet just to manage these routes. That is a lot of work and maintenance.

I don't really see a way forward.
Is there any reason we use that non-routable IP such that it requires changes on host, instead of a known, public or even private address?

Though the setup is different than what you are doing with MetalLB here. When I setup a MinIO cluster with Bird2 in NY5 I did not have to add any static route to get BGP working… Below is some debug output.
<EMAIL_ADDRESS>[~]
# lsb_release -d
Description:	Ubuntu 20.04 LTS

<EMAIL_ADDRESS>[~]
# bird --version
BIRD version 2.0.7

<EMAIL_ADDRESS>[~]
# ip route
default via <IP_ADDRESS> dev bond0 onlink
<IP_ADDRESS>/31 dev bond0 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/31 dev bond0 proto kernel scope link src <IP_ADDRESS>
<IP_ADDRESS>/16 dev docker0 proto kernel scope link src <IP_ADDRESS> linkdown

<EMAIL_ADDRESS>[~]
# cat /etc/bird/bird.conf
log syslog all;

router id from "bond0" <IP_ADDRESS>/8;

protocol device {
  scan time 10;
}

protocol direct {
  ipv4;
  interface "lo";
}

protocol kernel {
  merge paths;
  persist;
  scan time 20;
  ipv4 {
    import none;
    export none;
  };
}

protocol bgp neighbor_v4_1 {
  local as 65000;
  graceful restart;
  multihop;
  neighbor <IP_ADDRESS> as 65530;
  password "x";
  ipv4 {
    export filter {accept;};
    import filter {reject;};
  };
}

protocol bgp neighbor_v4_2 {
  local as 65000;
  graceful restart;
  multihop;
  neighbor <IP_ADDRESS> as 65530;
  password "x";
  ipv4 {
    export filter {accept;};
    import filter {reject;};
  };
}

@deitch Justin's comment is very interesting as it might explain the theory of "it depends on the BGP speaker to properly use the default route"
When I was doing my testing in NY5, I was using bird instead of bird2 and ubuntu 18.04 if the OS has any effect on this behavior...
Justin is using Ubuntu 20.04 with bird2 and it's working for him without adding the static routes.

Yup @jhead-slg ; it is because you have this line:
router id from "bond0" <IP_ADDRESS>/8;

That (I believe) explicitly sets the source route, so it is using the private IP.
Now that Tim explained how this works (not 2.5 hrs ago), as long as the announcer can be configured to:

use the correct source IP
have a large enough packet TTL

then it will work correctly.
bird has both of those; metallb has one but not the other. We are working on getting the other in place. But we do see a road forward now.

See also this metallb issue

This issue can be closed.

We add all of the peers onto the annotations, and it is added to the metallb configmap.
We add the src IP for connecting with peers to the annotations, as of #122 .

There is nothing ccm can do about the actually using the src IP. That depends on metallb or kube-vip or something else consuming it.


.inc file extension

I'm opening this issue to have a single place to solve the .inc situation. It can replace #1770 and should give it more visibility (so that people don't open pull requests to add this extension to X language anymore).
@arfon sent me 1,000 .inc files from this search results. I then used this Python script to identify the languages based on a few heuristic rules:

Language
Number in the 1,000
Estimate of the real number

Assembly
563
4,504,000

Pascal
320
2,560,000

C++
79
632,000

PHP
21
168,000

Clarion
14
112,000

MySQL
2
16,000

HTML
1
8,000

JavaScript
0
0

TeX
0
0

The estimates are based on the fact that there are 8,000,000 .inc files on GitHub and the count is on 1,000 files. They are gross estimates, especially for the language with few occurrences, since they were made from only 1,000 samples.
I'm not really sure what conclusions to draw from the small numbers (MySQL, HTML, JavaScript and TeX). We would need a much bigger corpus of samples to get representative results for these languages. Maybe it would be best to try to target these languages directly with a search (and a corpus of samples) for each of them. We can also only add the 4 first languages (or even only the 2 first) and see latter for the rest (users will probably come complaining if other languages should be added).
@arfon @bkeepers What do you think?
NB: I included the last 4 languages in my script because I saw a few .inc files matching them previously.

Participating.

SourcePawn also uses .inc files:

https://github.com/alliedmodders/sourcemod/tree/master/plugins/include
https://github.com/alliedmodders/amxmodx/tree/master/plugins/include

They're most likely to be in include folder relative to .sp or .sma file.

@xPaw How common would you say the native and forward keywords are in SourcePawn? (I'm trying to identify keywords I could use to find SourcePawn files.)

They're very common, but not guaranteed to be in every file. Maybe @dvander can say more.

OpenGL: https://github.com/search?q=extension%3Ainc+uniform+varying

By the way, the number of .inc files has grown from 8M to 9,6M in 24 days.

Let's not forget the samples in #1268

One of "native", "forward", "stock", or "public" would be in almost any SourcePawn .inc file.

This search will find more assembly files: extension:inc NOT php mov OR jmp OR lda OR globl.

This search will find more assembly files: extension:inc NOT php mov OR jmp OR lda OR globl.

@larsbrinkhoff Thanks!

So, I finally turned this into a pull request and here are the results:
                    | PHP        | SourcePawn | Assembly   | C++       | Pascal     | HTML       | SQL        |

------------------------|------------|------------|------------|-----------|------------|------------|------------|
862 PHP samples        | 98.79% | 0.89%      |            |           | 0.32%      |            |            |
952 SourcePawn samples | 0.05%      | 98.89% |            | 1.06%     |            |            |            |
898 Assembly samples   | 0.29%      |            | 99.24% | 0.27%     | 0.20%      |            |            |
787 C++ samples        |            | 0.26%      |            | 9.74% |            |            |            |
808 Pascal samples     | 0.19%      |            | 0.16%      | 1.20%     | 98.46% |            |            |
897 HTML samples       | 0.56%      | 1.30%      | 0.64%      | 1.81%     | 0.42%      | 95.27% |            |
938 SQL samples        | 0.26%      |            |            |           |            |            | 99.74% |
It looks to me like heuristic rules won't be needed for .inc :-)
@arfon This is ready for review ;)

Epic effort @pchaigno - this is awesome :zap:
Given the coverage here of languages (and the classifier accuracy) I think this should be good to go. Would love a :+1: from @bkeepers here too for completeness.

Wow, I'm impressed the results are that accurate.  I'm :+1:.
This actually got me thinking that it would be interesting to add an extended test suite that runs against these other corpuses and ensures they match a certain threshold.

Wow, I'm impressed the results are that accurate.

Yep, I am too. I added more samples than usually so that's one way to explain it but I'm afraid we could be overfitting. Although, only C++/SourcePawn/Pascal really needed more samples. C++ vs. SourcePawn needed more samples because only a handful of keywords are different. If there's overfitting somewhere I'd expect it to be for Pascal...

This actually got me thinking that it would be interesting to add an extended test suite that runs against these other corpuses and ensures they match a certain threshold.

Sounds like a good idea to me. That would be in a separate PR right? Should we open an issue to track progress on that idea?

Sounds like a good idea to me. That would be in a separate PR right? Should we open an issue to track progress on that idea?

:+1:

:+1: thanks @pchaigno.

Please add Makefile to the set of languages which can have a .inc suffix.  For that matter, a file named "Makefile.inc" should probably be automatically classified as "Makefile" without even considering other options.
Right now github is telling me that Tarsnap/spiped's Makefile.inc is a sourcepawn file! https://github.com/Tarsnap/spiped/search?l=sourcepawn


using redux-thunk instead of sagas

can we use redux-thunk instead of saga in this boilerplate

sure, why not. First, you'll need to remove redux-saga as described in the docs, and then integrate redux-thunk. Do that in app/store.js, and that's it.

i have an alternative version of this question. can someone educate me on why redux saga was chosen over redux thunk? i am familiar with thunk and not saga. to my eyes it seems like it is because saga uses generator functions "that can be paused" and so this works well with the goal of react-boilerplate of being offline first. maybe this is silly because thunk might be able to do the same? thanks. i'll happily learn redux saga but i like to know a little more about the motivations behind the technical choices you have made.

@sw-yx If you search in the issues section you'll find a ton of content on that :smile:

@Avi98 closing since this is not an issue with RBP. Feel free to continue discussion/ask questions. Thanks!

for some reason i only got notification of this now. github is weird. thanks @KarandikarMihir


How to get the data for Dow/Nasdaq?

New to this, I will dig into it while someone may possibly provide me an answer, thanks!
Please label this as a question only, thanks!

You can use ibGateway to connect to Interactive Brokers and get stock price data for Dow/Nasdaq or futures price data of the two indexes on CME.
You may also use shzdGateway to connect to Shanghai Zhida Futures for futures data.


Update config.json to match new specification

For the past three years, the ordering of exercises has been done based on gut feelings and wild guesses. As a result, the progression of the exercises has been somewhat haphazard.
In the past few months maintainers of several tracks have invested a great deal of time in analyzing what concepts various exercises require, and then reordering the tracks as a result of that analysis.
It would be useful to bake this data into the track configuration so that we can adjust it over time as we learn more about each exercise.
To this end, we've decided to add a new key exercises in the config.json file, and deprecate the problems key.
See exercism/discussions#60 for details about this decision.
Note that we will not be removing the problems key at this time, as this would break the website and a number of tools.
The process for deprecating the old problems array will be:

Update all of the track configs to contain the new exercises key, with whatever data we have.
Simultaneously change the website and tools to support both formats.
Once all of the tracks have added the exercises key, remove support for the old key in the site and tools.
Remove the old key from all of the track configs.

In the new format, each exercise is a JSON object with three properties:

slug: the identifier of the exercise
difficulty: a number from 1 to 10 where 1 is the easiest and 10 is the most difficult
topics: an array of strings describing topics relevant to the exercise. We maintain
a list of common topics at https://github.com/exercism/x-common/blob/master/TOPICS.txt. Do not feel like you need to restrict yourself to this list;
it's only there so that we don't end up with 20 variations on the same topic. Each
language is different, and there will likely be topics specific to each language that will
not make it onto the list.

The difficulty rating can be a very rough estimate.
The topics array can be empty if this analysis has not yet been done.
Example:
"exercises": [
  {
    "slug": "hello-world" ,
    "difficulty": 1,
    "topics": [
        "control-flow (if-statements)",
        "optional values",
        "text formatting"
    ]
  },
  {
    "difficulty": 3,
    "slug": "anagram",
    "topics": [
        "strings",
        "filtering"
    ]
  },
  {
    "difficulty": 10,
    "slug": "forth",
    "topics": [
        "parsing",
        "transforming",
        "stacks"
    ]
  }
]

It may be worth making the change in several passes:

Add the exercises key with the array of objects, where difficulty is 1 and topics is empty.
Update the difficulty settings to reflect a more accurate guess.
Add topics (perhaps one-by-one, in separate pull requests, in order to have useful discussions about each exercise).

I'm handling this one.
Do I have commit rights directly on the repo or we do it via a pull-request.
I do not mind any of the methods, just for clarification.

Do I have commit rights directly on the repo or we do it via a pull-request.

You've been invited to have commit on the repo, but that may have ended up in your spam folder.

@celavek I forgot to say: in general I try to make pull requests when there are other maintainers involved, as this helps people keep up to date.

OK, got it.
I checked my spam and I have not found any e-mail, sorry.

I'll resend it. Give me a sec.

There's no resend mechanism, it looks like. Do you see the invitation if you go to https://github.com/exercism ?

OK. All set. Thanks!

This is taken care of. There's more that could be done to optimize the track for the v2 prototype, but I think we should open new issues to improve that in response to testing on the prototype.


Fully support CSV endpoints

This PR adds public documentation for the group members and competition details CSV endpoints.
Added methods to the typescript client for calling these endpoints as well.

Ok, the server version bump is reverted.


Can not open more than 2-3 tabs browser in dev mode

Version
2.11.0
Reproduction link
https://auth0.nuxtjs.org/
Steps to reproduce
Example-Auth0 (https://github.com/nuxt/example-auth0)
I had copied this example repos to local and register like README setup file.

I still have no idea yet. But I'll try to research config in dev mode
What is expected ?
I want dev mode can open many tabs like pro mode
What is actually happening?
In dev mode, can not open more than 3 tabs browsers

This bug report is available on Nuxt community (#c47)

Same issue, but I cannot open more than two tabs in dev mode.
I use nuxt SSR, and when tabs are more than two, ajax request will be pending until one of the three tabs is closed =(

This will be fixed with Nuxt V2.13


Improve listing performance by using go-git

Contributes to https://github.com/go-gitea/gitea/issues/491.
This is rebased version of my changes which switch most of the read-only repository access logic to use go-git. We have been running version of Gitea with these changes in production environment for several months so it received some stress testing.
It's becoming harder to maintain this as separate branch so it would be nice if someone can take it over and upstream the changes.
Updating the go-git.v4 vendor module should bring some more performance improvements.

Not sure how to update the vendor modules. make vendor followed by make test-vendor still prints a lot of diffs on my local machine.

Not sure how to update the vendor modules. make vendor followed by make test-vendor still prints a lot of diffs on my local machine.

@filipnavara you have to commit the following changes after make vendor.

go.mod
vendor/modules.txt

After that, make test-vendor will stop complaining.
I fetched this PR and tested with the above steps.

Thanks, I will try that.

@typeless Unfortunately that didn't work for me. I suspect it has to do something with my local setup. I updated Go, but that alone didn't help.

@filipnavara
I uploaded my changes at https://github.com/typeless/gitea/tree/6478. It passes make test-vendor.

Codecov Report

Merging #6478 into master will increase coverage by 0.78%.
The diff coverage is 64.32%.

@@            Coverage Diff             @@
##           master    #6478      +/-   ##
==========================================
+ Coverage    39.4%   40.19%   +0.78%
==========================================
  Files         393      403      +10
  Lines       53271    54015     +744
==========================================
+ Hits        20992    21710     +718
- Misses      29292    29302      +10
- Partials     2987     3003      +16

Impacted Files
Coverage Δ

modules/git/signature.go
0% <ø> (-64%)
:arrow_down:

modules/git/sha1.go
73.91% <ø> (+23.91%)
:arrow_up:

modules/context/repo.go
58.28% <0%> (-0.12%)
:arrow_down:

routers/repo/editor.go
28.94% <100%> (+0.26%)
:arrow_up:

routers/repo/view.go
42.71% <100%> (+0.63%)
:arrow_up:

modules/git/tree_blob.go
82.92% <100%> (+1.84%)
:arrow_up:

modules/git/repo_commit.go
44.79% <100%> (-1.39%)
:arrow_down:

routers/repo/issue.go
36.72% <100%> (+0.29%)
:arrow_up:

modules/git/repo_tag.go
63.36% <100%> (+6.8%)
:arrow_up:

modules/git/repo_branch.go
83.09% <100%> (+8.09%)
:arrow_up:

... and 49 more

Continue to review full report at Codecov.

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

@filipnavara I've just resolved the git conflicts.

convertPGPSignature feels wrong. The payload and signature is on the commit header, so when we read the commit it should be available at that point. We shouldn't have to reconstruct it - it seems fragile to do so. Is it definitely the case that go git doesn't provide it?

@zeripath There are better ways to get it for sure. Go-git actually offers an API to verify the signature against a key which is the preferred way. I tried to use it last week, but I could not get the PGP key payload wrapped right. Other than that it's possible to get the raw object data, but then you have to strip the PGP signature out of it. I basically copied the internal function from go-git that was used for the verification and I planned to clean it up later.

getFileHashes() could be startlingly inefficient for a lot of files in the same sub folders.
I don't know how this function is used but if you're using it to look at the above you need to reconsider.
If you were working with a lot of files in sub folders you need to sort your list and walk it.

@zeripath @filipnavara We are now storing the full armored gpg key for export (need re-import of previous key as we haven't stored enough to re-build the full armored key). We could maybe re-write the gpg check to use the Verify go-git method with the new armored key storage and simplify the implementation but that another big change to maybe done in separate PR.

getFileHashes() could be startlingly inefficient for a lot of files in the same sub folders.

@zeripath The original implementation was so inefficient that most of the time Gitea page loads just timed out on my repository. I rewrote it significantly. It's not optimal yet, but it first looks up the common Git tree and then follows further to look up tree entries for individual files. It does that in-process and keeps all the Git objects cached, so it's pretty fast.

We are now storing the full armored gpg key for export (need re-import of previous key as we haven't stored enough to re-build the full armored key). We could maybe re-write the gpg check to use the Verify go-git method with the new armored key storage and simplify the implementation but that another big change to maybe done in separate PR.

That will make it significantly easier. Once https://github.com/src-d/go-git/pull/1104 is merged and new go-git propagated I can make the change.

@filipnavara yeah I recognize that - in 6505 I also attacked that code. This is a lot better -but the inefficiency I see is if you're asking for a lot of files in the same subfolders then you're going to be wasting a lot of calls. You might not be doing that, if so the suggested optimization won't improve things - however if you are then this should be changed.
A terminal example, getFileHashes(..., []string{"0/1/2/3/4/5/6/7/8/9/0/.../100/1",...,"0/1/2/3/4/5/../100/100"}) will be highly inefficient under this code. But if it's never expected that you'd do this then it's ok.

 It will still hit the GIT object cache and perform reasonably well. I do recognize that it could be optimized further, but I focused on the most visible code paths first.

Anyway that should be done in other PR, this one is already large so let's get this in first :)
@lunny ping ;)

There are two tests expectedContent changed but tests PASS before and now. That's so strange. Otherwise I will give my LGTM. @filipnavara thanks for your brilliant changes.

@filipnavara the rails home page will spend 11s on my macOS but before this commit 2s.

@lunny Can you give me a link to the Git repository? I'll try to reproduce it locally.

https://github.com/rails/rails

I think maybe you missed commit counting cache in this PR.

I do get pretty abysmal times on that repository on Windows (~12-13 seconds). I'll investigate it.

I assume the regression you are seeing happens because I dropped supported for the cache introduced in https://github.com/go-gitea/gitea/pull/6045. It's relatively trivial to bring it back and I hope to test and submit a patch soon.

@filipnavara I don't think so because #6045 is not merged yet. As I know, for a big repo. Commits counting and Last Commit of every file or folder will spend most time when loading repo home page. I think maybe because you missed Commits counting which introduced on https://github.com/go-gitea/gitea/pull/2774

@lunny Right. I did remove the usage of LastCommitCache in GetCommitsInfo though. I'll submit a patch to add it back, but it could not explain this.
I am pretty sure I didn't mess with the commit counting. I'll profile it and figure out what is wrong.

Just a small update: The profile clearly shows the time is spent in GetCommitsInfo. It seems to hit some degenerate path in either my algorithm or go-git. I keep working on finding the underlying issue, but this may take some time to understand what is going on.

@filipnavara thanks, you are doing great work! Really appreciate it :+1:

Thanks for all the positive comments! I managed to find a flaw in my algorithm that severly degraded performance on repositories with huge number of merge commits. I'm testing a fix now and hope to submit it soon.

Update: I am still tracking down the regression, but I managed to close in on it a bit.
Draft PR #6686 significantly improves the speed on repositories containing massive amount of merge commits. The first commit in the PR fixes one correctness issue and speeds up the loads for cases where there are mostly new files. If I delete the ".yardopts" file (9 year old file in the root directory) I can load the listing in 2 seconds (compared to over 4 seconds before this PR). Second commit in the PR introduces optimization for reducing the search space in case of many merge commits. On stock Rails repository together it brings over 30% improvement for the listing times.
Second problem is actually something I tried to tackle before and that's enormous amount of I/O in go-git when loading relatively small objects. This was mostly caused by unnecessary seeks throwing away buffered input and then re-reading it again. Due to some correctness issues my previous fix didn't apply to delta-encoded objects. Unfortunately this seems to be hit very hard on traversing the tree/commit history. Naïve fix by changing this line to allow deltas reduces the loading time by another 40% to around 5s.

I have a WIP branch with few go-git fixes at https://github.com/filipnavara/gitea/tree/go-git-perf-fixes (directly in the vendor module directory for now). It contains PR #6686 + some optimizations to go-git. On my machine that's enough to push it to around 4 - 4.5 seconds on the root of the Rails repository. There's still room for some improvement but I wanted to address the low-hanging fruit first.
For the root directory it's now similar to the performance I got before #6478. That may not necessarily be good enough since invoking git is super slow on Windows by comparison. For subdirectories it's significantly faster.
Here are results from the profiler for the above branch and for a state before PR #6478: https://gist.github.com/filipnavara/0777cdeeba07f469314e4c05185fa29d
Notice that the expensive listing operation on before- profile is over 7 seconds! Yet I am fairly certain that the displayed page load time was around 4.6s.

Notice that the expensive listing operation on before- profile is over 7 seconds! Yet I am fairly certain that the displayed page load time was around 4.6s. It may be some quirk or a clever parallelization I missed.

That's actually it. I was actually comparing apples to oranges. The previous implementation did parallelization on the maximum number of CPUs which is how it managed to achieve the speed. While that's a beneficial in some cases (like a site with no load) the trade off comes with higher disk access and lower actual throughput under load.
Obviously I can do that with the new algorithm too by partitioning the set of input entries into groups and then for each of these groups running the history algorithm in parallel. It may yield better results in some cases but it's unlikely to be a good idea under higher load.

go-git fixes are submitted.

 :-)
Turns out that I was not the only person who noticed the performance shortcomings in go-git and started fixing them. I hope the pending PRs will get processed in timely manner. My latest measurements were with src-d/go-git#1119, src-d/go-git#1121, src-d/go-git#1123, src-d/go-git#1124, src-d/go-git#1125, src-d/go-git#1126 applied. Together they allow me to load the root of Rails repository in little less than 3 seconds (about 50% improvement compared to currently released version).
With pregenerated commit graph file (#6701) it drops to 1.7 second.
I was actually worried that I caused some serious performance regression for some scenarios and that this PR, or part of it, would have to be reverted. I'm now fairly certain that should not be necessary. Thanks for feedback from everone.

@filipnavara I don't fell boring about what you are doing, but very thanks for your effort on that. I will try https://github.com/filipnavara/go-git/tree/wip-perf ASAP.

I have tested your wip-perf branch. The time on rails root page spent 2.5s ~ 4s and on release/v1.8 it's 2.3s. It's significant branch. But I found there are some different last commit display between two implements.
Notice: I'm using an old rails repository.
v1.8 :

branch wip-perf :

@lunny Can you share the commit hash of the HEAD you are looking at? I believe this is result of my last tweaks which I compared to GitHub behavior.

The last commit id is 5abe612b0d on that rails repository.

GitHub displays the same thing as you have on the wip-perf screenshot: https://github.com/rails/rails/tree/5abe612b0d
It boils down to the treatment of merge commits on directories. I don't have hard preference on either one, but I would not consider it a bug.

The time on rails root page spent 2.5s ~ 4s and on release/v1.8 it's 2.3s.

Keep in mind that these are numbers with basically no load. The go-git version of the code is single-threaded and uses algorithmic parallelization only. The previous version was massively multi-threaded and used all the CPUs and quite probably more I/O as well.
At the moment go-git is not as optimized in reading as the native git but it gets really close (with the recently merged patches and the ones in the pipeline). When there are no old commits in the listing then go-git handily beats the old version. The Rails repository has a file in the root of the repository that was not modified for 8 years. On Windows the go-git version still beats git on this due to overhead of process launches and the massive amount of I/O.
Algorithmically computing the newest commit for this file means that all those 8 years of commit objects have to be loaded from disk. That's true for both go-git and git. The approach with go-git however loads these objects only once and resolves the newest commits for all the files along the way.
Aside from the general go-git speed-ups I would like to implement the support for git commit-graph files. It's additional data that has to be generated, but it offers significant speed up. It is specifically designed to solve the problem of history traversal and it will greatly help things like generating branch ahead/behind numbers (https://github.com/go-gitea/gitea/pull/6695).

@filipnavara It seems all above pipeline PRs on go-git merged. Could you send a PR from your wip-perf branch?

@lunny don't we need to wait official go-git release for the vendor module to get updated? (I can ask the go-git guys to make one)

@filipnavara It seems all above pipeline PRs on go-git merged. Could you send a PR from your wip-perf branch?


Service Connection > Service Hooks

The Permissions state "Service Connections" for Azure DevOps, but shouldn't this be Service Hooks?
And this doc isn't clear about how to set those permissions. Read-permissions aren't to hard, but the service hook permission is very specific and how to grand them is not quit clear. I have found only the Project Administrator to be enough, but maybe a role with less permissions would do.

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

ID: 83c90e64-b615-711f-a53d-fc76606e2ecd
Version Independent ID: 2d164036-6886-4440-50f7-369f99f41cea
Content: Source Control integration in Azure Automation
Content Source: articles/automation/source-control-integration.md
Service: automation
GitHub Login: @georgewallace
Microsoft Alias: gwallace

It's awesome to see there are cmlets out there to automate this. Is it possible to use a service connection instead of a PAT token for automating the process using PowerShell cmdlet? If so would we just pass the service principal password/key as the token? We really don't want to have all of our sync jobs tied to a personal account.

@jzuchora87 Sorry for the delay. At this time you can only use a PAT.

I'm sorry, but I'm not sure why my issue was closed? My question has not been answered in the update in the doc or in this thread?

@ba4bes sorry for the confusion. Your issue was closed by the PR to update the doc. We had discussed earlier in your thread in regards to the permissions and using the cmdlets to limit the permissions needed. This is all in the doc. The original question about the service hooks was answered as I mentioned it is service connections as that is what is described in the permissions needed in the doc. What question are you still having so I can making sure to answer it.   Excuse any typos as this is from a phone.

I'm still not sure what the minimum permission role is for an account in Azure DevOps to set up this connection (with autosync). I use the Project Administrator role now and I want to make sure that's the minimum level needed, as this is a role that has a lot of other permissions in the project


Website changes

Pull request checklist
Please check if your PR fulfills the following requirements:

[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been reviewed and added / updated if needed (for bug fixes / features)
[ ] Build was run locally and any changes were pushed
[ ] Lint has passed locally and any fixes were made for failures

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[x] Documentation content changes
[ ] Other (please describe):

What is the current behavior?

Issue Number: N/A
What is the new behavior?

Does this introduce a breaking change?

[ ] Yes
[ ] No

Other information

Changes for integrating docusaurus to publish github pages for cocuhbase plugin.
Example of published documentation:
https://pratap-akhand.github.io/couchbase-plugin/docs/Overview


Database Transactions.

General
Added transactions within the AuthController, Seeder and tests to ensure database transactions are fulfilled atomically. The seeder now also contains some simple logs to ensure process is being made and allow the caller to understand execution time and "failing" points.
Reference: (Trello)
Notes

Fixed a test that was not doing as it was stating
Simplified object comparing using mocha deep equal and _.pick from lodash.

OAuth testing seems to be passing regardless of the values atm anyway since the token being created does not match the token being checked afterwards, i'm going to fix this now.


update kf-server json parse

remove extra JSON parse since genienlp has been updated.

I had a similar fix in #421 that I just merged, I think this is superseded now.

L

I had a similar fix in #421 that I just merged, I think this is superseded now.

Looks good!


Update README.md

@KapilKumar7 please accept my pr and label it for hacktoberfest

Thanks for the Contribution.


text mentions wrong color of the sphere

"This creates a yellow sphere one meter in radius, placed four meters in front of the camera." - the sphere is red color.

Thanks for catching this. fixed.


winget upgrade: Display count of available upgrades

Description of the new feature/enhancement

winget upgrade checks for available upgrades. My suggestion is to also display their count.

Example:
Currently:
Name                      Id                              Version     Available   Source
----------------------------------------------------------------------------------------
Ubisoft Connect           Ubisoft.Connect                 121.0.10451 124.2.10565 winget
Vim                       vim.vim                         8.2         8.2.3313    winget
Epic Games Launcher       EpicGames.EpicGamesLauncher     <IP_ADDRESS>   <IP_ADDRESS>    winget

My suggestion:
Name                      Id                              Version     Available   Source
----------------------------------------------------------------------------------------
Ubisoft Connect           Ubisoft.Connect                 121.0.10451 124.2.10565 winget
Vim                       vim.vim                         8.2         8.2.3313    winget
Epic Games Launcher       EpicGames.EpicGamesLauncher     <IP_ADDRESS>   <IP_ADDRESS>    winget

3 upgrades available.

Seems reasonable.   Anyone want to code it up?  :)


Use user_role over users == plaintiff

When you are directly comparing the users to the plaintiffs, DA will try to gather both of the objects. This is fine if users is plaintiffs, but if the users are the defendants instead, it will trigger a infinite loop screen, since other_parties has been set to plaintiffs, and it's trying to gather plaintiffs before being able to fill other_parties.
Additionally, uses user_role instead of user_ask_role, which will always ask for the user's role in the case, even if it's a form that always done from one side, or we can detect what side of the case the user is on (as with e-filing).
Would like to do some additional testing with this on the dev server, but that might take a bit, since I don't know which interviews to test with. I'll make sure the ALAffidavit and the interpreter notice work correctly.
A minimal reproduction, with 57ee87e496109ba8f2c7c7175991cea38eb86100: Saying that you are a defendant will result in an error screen.
include:
  - docassemble.AssemblyLine:assembly_line.yml
---
mandatory: True
code: |
  users.gather()
  other_parties.gather()

Results in the Following error:

There appears to be an infinite loop. Variables in stack are x.first.
...
Needed definition of other_parties[0].name.first at 0.33673s
Tried to ask question at 0.33724s
(from ql_baseline.yml)
sets:

other_parties[i].name.first
other_parties[i].name.last
other_parties[i].name.middle
other_parties[i].name.suffix
id: names of opposing parties
question: |
% if users==plaintiffs:
Name of ${ ordinal(i) } defendant or respondent in this
matter
% else:
Name of ${ ordinal(i) } plaintiff or petitioner in this matter
% endif
fields:
code: |
other_parties[i].name_fields(person_or_business='unsure')

(repeated)

Doesn't happen with this PR.

Additional tests:

ALAffidavitOfIndigency uses list collect, which this doesn't seem to affect, as the error isn't present with current AssemblyLine either. No change in behavior for this PR though
With the interpreter notice, ran into this issue: https://github.com/SuffolkLITLab/docassemble-Interpreternotice/issues/19. Currently, you just can't be defendant, even though it asks you directly (because user_ask_role is encoded in the interview and it shouldn't). The bigger issue is that it's marked as al_form_type = "starts_case" which I don't think is the case. Will have to fix that additionally.

Any other ideas of interviews on AL that should be tested? @nonprofittechy   A lot of these problems are also related to https://github.com/SuffolkLITLab/docassemble-AssemblyLine/issues/181, just to link these two issues.

Quick ping on this @nonprofittechy, is there any other interviews or anything else that you think should be tested?

We need to figure out the impact of this change on existing forms that "correctly" directly trigger user_ask_role, and people who directly set user_role in the interview order block, as happens in the Weaver's default output.

Started this a bit (found one issue in the Weaver), but I'm not sure testing just Weaver stuff is good enough here, and all changes will likely break someone.
Our own documentation is inconsistent on if you should directly set user_role or user_ask_role. The definition on user_role says you should directly set it, but "Setting the form type" says you should directly set user_ask_role. Additionally, I'm realizing that ILAO's appearance commonly uses user_ask_role in it's logic.
So we can't rely on existing interviews to look like they come straight out of the weaver. Specifically, we can't rely on people having 1) gone through the weaver correctly, and 2) ever having fixed their code from the weaver if they went through incorrectly. If that's the case, this will break someone's interview, because user_role could be magically set from the Weaver, but never be used in the interview itself (it seems that none of AL actually uses the result of user_role right now, it would just show up in the output form likely). This PR would switch all their logic from depending on user_ask_role to user_role, which would break them.
To avoid all of this, I think I will just change the variable in this PR to be user_started_case, which is used in other logic. If someone is misusing user_started_case in their interview, their interview is currently broken. It doesn't solve for e-filing, but I guess I'll just have to deal with that case by case, avoiding user_role.

Ready for another review. The only logic change now is from:
%if users == plaintiffs:

to
%if user_started_case:

Since user_started_case sets plaintiffs = users in the question library, this PR will make no additional semantic changes to existing interviews. I did add some comments discouraging the use of user_role in interviews, since we are using it less and less on the back end in favor of user_ask_role and user_started_case.


[BUG] Volume with robustness is unknown is not reflect under Volume page

Describe the bug
When attached note got deleted, the Unkown volume state is not shown.
To Reproduce
Steps to reproduce the behavior:

Create a volume 1
Attach volume to node A
Update the replica count of volume 1 to 1
Delete all replicas and keep only one replica that is not on the same node with the volume 1
Delete the node A from kubectl or kubernetes dashboard
Goto the longhorn volume UI
Click into volume 1
Following error message will shown

fail to list snapshot: cannot get client for volume pvc-61195983-4b27-42a7-8b1e-e8238552b63e: engine is not running

Expected behavior
Detail of volume 1 is reflecting the Unkown state instead of attached and giving error of other situation(supposedly, the volume state should > snapshot status)
Manually reattach volume 1 to other working node can resolve the volume healthiness to normal.
Environment

Longhorn version: v1.1.3-rc1, master-head, v1.1.2
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): kubectl
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: rke1 v1.18

Number of management node in the cluster: 1
Number of worker node in the cluster: 3 + 1

Additional context
$ kubectl describe volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 -n longhorn-system is showing relevant event info:
Events:
  Type     Reason              Age                From                               Message
  ----     ------              ----               ----                               -------
  Normal   Detached            24m                longhorn-volume-controller         volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 has been detached
  Normal   Start               24m                longhorn-kubernetes-pv-controller  Persistent Volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 started to use/reuse Longhorn volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6
  Warning  DetachedUnexpectly  21m                longhorn-volume-controller         Engine of volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 dead unexpectedly, reattach the volume
  Normal   Remount             21m                longhorn-volume-controller         Volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 requested remount at 2021-11-22T10:30:13Z
  Normal   Detached            21m                longhorn-volume-controller         volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 has been detached
  Normal   Attached            21m (x2 over 24m)  longhorn-volume-controller         volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 has been attached to ip-A-B-C-D
  Warning  Unknown             2m49s              longhorn-volume-controller         volume pvc-5f0cd541-d28c-40f8-a42e-0a2cb4aec7a6 robustness is unknown

Related issue: #1451

@kaxing After waiting for sometime, did the error go?

@khushboo-rancher the "Attached" state remain quite a bit time(around 30mins) from the UI, hence the error can be reproduced easily by click into the volume detail page.
I will double check the http/wss responses.

The response from /v1/volumes still shows attached,

(expand to see the full json of the unkown volume)
        {
            "accessMode": "rwo",
            "actions":
            {
                "activate": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=activate",
                "attach": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=attach",
                "cancelExpansion": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=cancelExpansion",
                "detach": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=detach",
                "engineUpgrade": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=engineUpgrade",
                "pvCreate": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=pvCreate",
                "pvcCreate": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=pvcCreate",
                "recurringUpdate": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=recurringUpdate",
                "replicaRemove": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=replicaRemove",
                "snapshotBackup": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=snapshotBackup",
                "snapshotCreate": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=snapshotCreate",
                "snapshotDelete": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=snapshotDelete",
                "snapshotGet": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=snapshotGet",
                "snapshotList": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=snapshotList",
                "snapshotPurge": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=snapshotPurge",
                "snapshotRevert": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=snapshotRevert",
                "updateDataLocality": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=updateDataLocality",
                "updateReplicaCount": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f?action=updateReplicaCount"
            },
            "backingImage": "",
            "backupStatus":
            [],
            "conditions":
            {
                "restore":
                {
                    "lastProbeTime": "",
                    "lastTransitionTime": "2021-11-23T08:59:57Z",
                    "message": "",
                    "reason": "",
                    "status": "False",
                    "type": "restore"
                },
                "scheduled":
                {
                    "lastProbeTime": "",
                    "lastTransitionTime": "2021-11-23T08:59:57Z",
                    "message": "",
                    "reason": "",
                    "status": "True",
                    "type": "scheduled"
                },
                "toomanysnapshots":
                {
                    "lastProbeTime": "",
                    "lastTransitionTime": "2021-11-23T08:59:57Z",
                    "message": "",
                    "reason": "",
                    "status": "False",
                    "type": "toomanysnapshots"
                }
            },
            "controllers":
            [
                {
                    "actualSize": "0",
                    "address": "",
                    "currentImage": "longhornio/longhorn-engine:v1.1.3-rc1",
                    "endpoint": "",
                    "engineImage": "longhornio/longhorn-engine:v1.1.3-rc1",
                    "hostId": "c1-worker2",
                    "instanceManagerName": "instance-manager-e-adfe6ed8",
                    "isExpanding": false,
                    "lastExpansionError": "",
                    "lastExpansionFailedAt": "",
                    "lastRestoredBackup": "",
                    "name": "pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f-e-d539e617",
                    "requestedBackupRestore": "",
                    "running": false,
                    "size": "12582912"
                }
            ],
            "created": "2021-11-23 08:59:51 +0000 UTC",
            "currentImage": "longhornio/longhorn-engine:v1.1.3-rc1",
            "dataLocality": "disabled",
            "disableFrontend": false,
            "diskSelector": null,
            "engineImage": "longhornio/longhorn-engine:v1.1.3-rc1",
            "fromBackup": "",
            "frontend": "blockdev",
            "id": "pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f",
            "kubernetesStatus":
            {
                "lastPVCRefAt": "",
                "lastPodRefAt": "",
                "namespace": "default",
                "pvName": "pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f",
                "pvStatus": "Bound",
                "pvcName": "simple-pvc-2",
                "workloadsStatus": null
            },
            "lastAttachedBy": "",
            "lastBackup": "",
            "lastBackupAt": "",
            "links":
            {
                "self": "http://<IP_ADDRESS>:30707/v1/volumes/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f"
            },
            "migratable": false,
            "name": "pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f",
            "nodeSelector": null,
            "numberOfReplicas": 1,
            "purgeStatus": null,
            "ready": true,
            "rebuildStatus":
            [],
            "recurringJobs": null,
            "replicas":
            [
                {
                    "address": "<IP_ADDRESS>",
                    "currentImage": "longhornio/longhorn-engine:v1.1.3-rc1",
                    "dataPath": "/var/lib/longhorn/replicas/pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f-d3c0b1ee",
                    "diskID": "38852b59-dacc-4aae-bc63-666dfe17fcf4",
                    "diskPath": "/var/lib/longhorn/",
                    "engineImage": "longhornio/longhorn-engine:v1.1.3-rc1",
                    "failedAt": "",
                    "hostId": "c1-worker1",
                    "instanceManagerName": "instance-manager-r-6bbd632e",
                    "mode": "",
                    "name": "pvc-180265a8-f69a-47c9-b89a-7fc48cbae35f-r-414dc9b3",
                    "running": true
                }
            ],
            "restoreRequired": false,
            "restoreStatus":
            [],
            "revisionCounterDisabled": false,
            "robustness": "unknown",
            "shareEndpoint": "",
            "shareState": "",
            "size": "12582912",
            "staleReplicaTimeout": 2880,
            "standby": false,
            "state": "attached",
            "type": "volume"
        }

If I leave the volume long enough the node down icon will be shown next to the volume,

When click into it, will actually show as Unkown,

This is not a bug because its replica actually still running, but its engine missing so needs users' intervention to fix it.
As @khushboo-rancher said, there is an icon showing the volume having some problem due to its engine/frontend, so the message is also correct and healthy status shows unknown correctly.

@kaxing Any other concerns actually?

@innobead Just a slightly thing to be improved here: the "state" in volume list and the volume page are not consistent.
Checking with frontend dev at the moment.

@smallteeths This should be fixed in the master and 1.1.x branches as well. Thanks.


Release 2022.11.29

This release adds the following PRs:

#41
#42
#43
#44

:tada: This PR is included in version 1.4.1 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Fixed and added new test for documents.

This is a conflict with #25.

I think it's not be actual after this commit https://github.com/ongr-io/MagentoConnectorBundle/pull/48


Add gas timeout to blocks and transactions

customer: @mariari
performer:
deadline:
estimated:
started:
actual:
completed:
confirmed:
dependencies:

[ ]
supersedes:

Gas limits should be added to block execution, and transactions submitted.
This is another kind of failure case and changes how failures work in the current system.
@juped and @agureev are the best contact for this particular issue

This one shall be the quick and dirty one, we need another more proper issue for specs compliance etc.


Project is been created placed under --no-prompt sub-folder

VS Code: 1.18.1
Ionide-fsharp 3.13.0
Repro Steps

Open a Folder in VS Code
Run the F#: New Project command
Press [Enter] to select console
Press [Enter] for the Project Directory
Type a Project Name

Expected
A folder with the Project Name is added to the root of the Open Folder.
Actual
A folder with the Project Name is added to a folder called --no-prompt in the root of the Open Folder.
Workaround
Move the project folder from --no-prompt to the root yourself and delete --no-prompt.
Edit the following line from the fsproj file:
<Import Project="..\..\.paket\Paket.Restore.targets" />
to
<Import Project="..\.paket\Paket.Restore.targets" />

added PR #654 to fix this

This is still an issue for me.
Ionide: 3.18.2
VS Code: 1.22.1
Dotnet SDK: 2.1.103
Mono: <IP_ADDRESS>

Same here ^^


[cypress] fix accessing a cross-origin frame error

CATEGORY
Choose one

[ ] Bug Fix
[ ] Enhancement (new features, refinement)
[ ] Refactor
[ ] Add tests
[x] Build / Development Environment
[ ] Documentation

SUMMARY
Cypress dashboard tests randomly show
Error: Blocked a frame with origin "https://*******.com" from accessing a cross-origin frame.

This issues is reported here, and it also gave a solution:
https://github.com/cypress-io/cypress/issues/1951
TEST PLAN
CI
REVIEWERS
@mistercrunch @michellethomas

Codecov Report

Merging #7552 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master   #7552   +/-   ##
======================================
  Coverage    65.2%   65.2%
======================================
  Files         433     433
  Lines       21433   21433
  Branches     2360    2360
======================================
  Hits        13975   13975
  Misses       7338    7338
  Partials      120     120

Continue to review full report at Codecov.

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

Now I'm wondering if chromeWebSecurity would ever catch relevant security issues, and that setting it to false we may miss out on that?
How about only disabling it for the scope of this test? https://docs.cypress.io/guides/references/configuration.html#Cypress-config

The cross-origin frame error seems only happens for dashboard test: user save-as a new copy, server-side response a new dashboard id, and page should redirect to new dashboard.
According to https://docs.cypress.io/guides/guides/web-security.html#Disabling-Web-Security, it is a JavaScript Redirects. dashboard was not redirect to subdomain or new domain, but cypress still show error randomly.
According to solution suggested by cypress, Set chromeWebSecurity to false in cypress.json and we’ll take care of the rest., i am not sure scope config will work, but i can still change to see if it will work.

Next time we see this test flake again maybe we can set it to false globally

Superseded by #7538

@mistercrunch you close this by accident?


IsSet unsupported type

Hello!
I have been looking everywhere for an answer, and it seems like every variant of this issue is specific to the theme in question. I have no idea what I need to fix when I get the following error:
WARNING: calling IsSet with unsupported type "ptr" (*hugolib.PageOutput) will always return false.
Any help on what to edit?

I'm experiencing the same issue

It's just a warning, not an error, per sé.

I'm a bit late to the discussion but just in case someone is in the same point. Check this:
https://github.com/LiaungYip/plain-blog/issues/2
In hugo-code-editor-theme/layouts/partials/head.html:
 {{ if isset . "Description" }} to {{ if .Description }}.
And it should be ok :).


Display logo on community details and associated mission pages

The community model should be extended to include a logo, which could be displayed on the community details page as well as the details of missions that are assigned to a community.
Images should be uploaded to the service and hosted (same as e.g. mission banner images, also depending on https://github.com/MorpheusXAUT/slotlist-backend/issues/4). The related backend task is https://github.com/MorpheusXAUT/slotlist-backend/issues/9.
Since this requires more work, the feature will probably not be included in the 1.0.0-beta release, but a later version.

Tasks

[x] Add image upload to community creator
[x] Add image upload to community edit modal
[x] Display logo on community details page
[x] ~Display logo on associated mission details page~

The mission's detail page can already contain multiple images as well as lots of information - trying to add the community's logo on there somewhere would probably overload it even more.
Closed for now unless a super fancy solution/implementation just pops up by chance during future development.


Add support to insert virtio-blk devices

This PR gives the users two ways to insert virtio-blk devices:

Insert before VMM launched. The parameter is --virblks '[{"drive_id":"testblk","device_type":"RawBlock","path_on_host":"/path/to/test.img","is_root_device":false,"is_read_only":false,"is_direct":false,"no_drop":false,"num_queues":1,"queue_size":1024}]'.

Insert hotplug devices after VMM launched. The parameter is --hotplug-virblks '[{"drive_id":"testblk","device_type":"RawBlock","path_on_host":"/path/to/test.img","is_root_device":false,"is_read_only":false,"is_direct":false,"no_drop":false,"num_queues":1,"queue_size":1024}]'

Both of these parameters receive an array of BlockDeviceConfigInfo in the format of JSON to make them more configurable.
Fixes: openanolis#19

@wllenyj Hi, could please you help with the cargo deny issue?

@wllenyj Hi, could please you help with the cargo deny issue?

Fixed by #21, please rebase.

Thanks very much!


Improve next step UI

After a user creates a questionnaire, they are funnelled to create a record. This UI is quite large and imposing. Try to achieve the same thing with less distraction

 Onboarding 2.0


ValueError related to numpy.dtype size change in spaCy course environment

While running the code in the course always getting some ValueError: numpy.dtype size changed, may indicate binary incompatibility. Expected 96 from C header, got 88 from PyObject , it's coming everytime when the exercise is related to code (not MCQ or any-other)
To see the actual error , just go to any exercise which involve coding , for example one of the way to reproduce the error -
Navigate to the spaCy Advanced NLP course section on "Loading Pipelines." (chapter 1 , 7th section named - Loading Pipeline )
Click on show solution and it will autofill the code correctly , it's not a big issue coz the correct solution is still visible but it would be good if code runs smooth , for better user and learning experience.
Run the correct code.
Full Error :
ValueError                                Traceback (most recent call last)
Cell In[1], line 28
14 msg = msg
15 solution = blacken("""import spacy
16
17 # Load the "en_core_web_sm" pipeline
(...)
25 # Print the document text
26 print(.)""")
---> 28 import spacy
30 # Load the "en_core_web_sm" pipeline
31 nlp = ____
File /srv/conda/envs/notebook/lib/python3.10/site-packages/spacy/init.py:11
8 setup_default_warnings()  # noqa: E402
10 # These are imported as part of the API
---> 11 from thinc.api import prefer_gpu, require_gpu, require_cpu  # noqa: F401
12 from thinc.api import Config
14 from . import pipeline  # noqa: F401
File /srv/conda/envs/notebook/lib/python3.10/site-packages/thinc/api.py:2
1 from .config import Config, registry, ConfigValidationError
----> 2 from .initializers import normal_init, uniform_init, glorot_uniform_init, zero_init
3 from .initializers import configure_normal_init
4 from .loss import CategoricalCrossentropy, L2Distance, CosineDistance
File /srv/conda/envs/notebook/lib/python3.10/site-packages/thinc/initializers.py:4
1 from typing import Callable, cast
2 import numpy
----> 4 from .backends import Ops
5 from .config import registry
6 from .types import FloatsXd, Shape
File /srv/conda/envs/notebook/lib/python3.10/site-packages/thinc/backends/init.py:8
5 import threading
7 from .ops import Ops
----> 8 from .cupy_ops import CupyOps, has_cupy
9 from .numpy_ops import NumpyOps
10 from ._cupy_allocators import cupy_tensorflow_allocator, cupy_pytorch_allocator
File /srv/conda/envs/notebook/lib/python3.10/site-packages/thinc/backends/cupy_ops.py:19
17 from .. import registry
18 from .ops import Ops
---> 19 from .numpy_ops import NumpyOps
20 from . import _custom_kernels
21 from ..types import DeviceTypes
File /srv/conda/envs/notebook/lib/python3.10/site-packages/thinc/backends/numpy_ops.pyx:1, in init thinc.backends.numpy_ops()
ValueError: numpy.dtype size changed, may indicate binary incompatibility. Expected 96 from C header, got 88 from PyObject

It's actually coming across all 4 chapters , for chapter 3 and 4 it would be good if this internal compiler of spacy gets fix , coz there are indeed some complex code exercise. @maintainers @ines

Good Day,
Just corroborating r4plh's comment.
I am also experiencing the same issue detailed.
Looking forward to its rectification as it is indeed a great resource.
Thanks for the continued support!

Course is actually great @ines hats off! , It teaches all the basics , but really need to get through exercises in chapter 3 and 4 , would be better if one can submit the code and check then and there instead of copy and pasting the whole to personal ide , for best user experience.


Update SolveSetup.py

Not sure how this one PY file is used to separate the three separate pages under Setup in the API doc. Somehow it must though!

I'm starting to merge this as 15 active PRs seems like a lot and I'm sure the build machine wants something to do on the weekend.


Column Header Size

Hi, how can I set the size of the text in the header line of my list view via json?

You can check the official document here: Use view formatting to customize SharePoint.
Unfortunately, there is not a way to customize the column header of list view using JSON formatting.
As a workaround, we can use SPFx Applications Customiser to inject the custom CSS style to achieve it.
The CSS style as below:
.ms-DetailsList-headerWrapper .ms-DetailsHeader-cell{
	font-size:18px !important;
}

The SPFx solution is here: SPFx Applications Customiser CSS Injection

Dennis Guo
Microsoft SharePoint Community Support

I caution the use of the workaround listed above... that is definitely not supported & falls under the "DOM manipulation" category as it relies on CSS classes that are subject to change.


Line Chart vs. 2015 - skipLabels: data series without label for each point

Hi,
I would like to know if someone has made a skipLabels option for the 2015 version of Line Chart?
r043v made one for the 2013 version:
https://github.com/nnnick/Chart.js/issues/12
https://github.com/r043v/Chart.js/commit/6b2a9fd61c8d393e3d1b4bdd275a3533178a4102
I need the same thing but for the 2015 version.
Thanks!

Yeah same here

Version 2.0 of chart.js (currently in alpha) has similar functionality.
In the config you can specify a function on a scale to filter labels. If you return an empty string the grid line will still draw. If you return null or undefined the grid line will not draw.
A sample file demonstrating this is: https://github.com/nnnick/Chart.js/blob/v2.0-dev/samples/line-x-axis-filter.
In JSBin form

Thanks for the answers. How close is Chart.js 2.0 to completion? What are the known bugs, if any? I'm thinking of going straight for that one.

@tannerlinsley is already using it in production. There are definitely some bugs, but I'd say we're pretty close to getting a beta out the door. The biggest features left to do are to allow passing arbitrary data to the elements (so that it can be used in the template function) and allowing easy hiding of datasets.
Some of the bugs from v1.0 remain such as the resizing issues & sizing when the canvas is display: none. We are trying to get those fixed before release.


update purescript-echarts

update purescript-echarts

I'm sure this is fine but I'll wait for Travis to pass and then merge it... not sure what's taking so long for it to actually start the build!

Yes, it's weird. Is there anything I can do?

I don't think so, it seems to be an issue with Travis. I tried cancelling the job and restarting it, but no luck.
I'll merge it now anyway, I checked it out locally and the build succeeded, so :+1:

Thanks