A task description/detail propery in tasks.json

Hi,
A workspace with a large number of tasks could do with a task description property. When selecting a task to run from the command palette, show the description of the selected task below the task.
This is also nice for the onboarding of new team members.

Once this is proposed we also need to change the tooltip in the npm explorer to behave better. (@egamma FYI)

Current:
	/**
	 * A structure that defines a task kind in the system.
	 * The value must be JSON-stringifyable.
	 */
	export interface TaskDefinition {
		/**
		 * The task definition describing the task provided by an extension.
		 * Usually a task provider defines more properties to identify
		 * a task. They need to be defined in the package.json of the
		 * extension under the 'taskDefinitions' extension point. The npm
		 * task definition for example looks like this
		 * ```typescript
		 * interface NpmTaskDefinition extends TaskDefinition {
		 *     script: string;
		 * }
		 * ```
		 *
		 * Note that type identifier starting with a '$' are reserved for internal
		 * usages and shouldn't be used by extensions.
		 */
		readonly type: string;

		/**
		 * Additional attributes of a concrete task definition.
		 */
		[name: string]: any;
	}

Proposal is to add:
            		readonly description?: string;

The description would be shown in the task quick pick with the task.

How will the description be shown? For example under or next to each task in the task list or when hovering over a task in the task list using a tool tip (to save space)?

It is shown in the quick pick detail spot:

The quick pick description spot is taken already by tasks in a multiroot workspace.
I ended up making the property detail and putting it on Task as it doesn't really belong in the definition.

I also added a setting to turn this off: "task.quickOpen.detail"

Reopening so that we don't forget to finalize this API.

@alexr00 The details are not shown all the time, for example, running the command "Tasks: Run build task" shows the details:

But running "Tasks: Configure task" doesn't show the details:

Good find, I have opened a bug to fix this: https://github.com/microsoft/vscode/issues/104911

@alexr00 I am trying to modify the detail of a task when I resolve it in TaskProvider::resolveTask, but I can't see this modification to be effective.
As I understood, the tasks that are read from the tasks.json file will be resolved first. I want to be able to modify the detail of such a task while resolving it only for the purpose of differentiating between the tasks that are detected and the tasks that are read from the tasks.json file (Note: I am not intending to modify the Json file).
However, when I modify the detail, I can't see the modification.
For example, the first 3 tasks are from tasks.json file and the next three are detected tasks (the current behavior is as below):

While resolving the tasks in resolveTask, I am modifying the detail , and I expect this modification to be effective (as below), but it is not.

To make the task quick pick (the list of tasks you show in your screen shots) as fast as possible, no tasks are resolved when the quick pick is shown. This means that only the stored data about a recently used task or the data from tasks.json is used.


[Button] Icon not vertically centred with text

Expected behavior

Expected icon to be vertically centred with Button text

Current behavior

Icon is not vertically centred with Button text

Possible solution

Steps to reproduce (for bugs)

Instantiate a Button with both text and an icon with height shorter than the height of the text
Observe that the icon floats at the top of the text rather than being vertically centred alongside it:

Context

Using the Button component with an Icon in our Phoenix-Dashboard project

Versions
| Button | 2.0.1 |

Hi, Caledonia. Can you please provide the code of your Button with the issue? Something like... <Button iconStart={<IconCloud />} size="jumbo">Jumbo</Button>.

Upload Favicon

Where uploadIcon is a function that returns an Icon component

Thanks!
Unfortunately, I still can’t tell what’s causing the issue. Is your repo public or on CA’s Enterprise GitHub?
If your repo isn’t sharable, I’m guessing it has to do with whatever the classes prop is doing.

This issue is not specific to my use case. If you go to http://mineral-ui.com/components/button and make the size of the icon in the example buttons smaller, say 5px, the Icon will also not be vertically centred alongside the text. The screenshot I included in this issue is from me doing that.

@calthomson Can you show a design example where a shrunk icon is desirable? That currently isn't planned for the design spec.

As long as we support passing in your own SVG's this is a problem we should fix, which sounds pretty easy. In the future when we have a style guide made public, it will be strongly encouraged to follow those guidelines.
Nice bug catch @calthomson

@asagray I agree that a shrunken icon is not a normal design choice. Here is a quick example of what I am seeing for my current Button:
Current:

Desired (align-items: center added):

@Mikewaite Thanks!

Just opened a PR with a fix. Thanks for making us aware!

@calthomson — This fix was just released with Button 4.0.2.


Allow class bound method works in app listener

(Describe the goal of this PR. Mention any related Issue numbers)
Category (place an x in each of the [ ])

[] slack_bolt.App and/or its core components
[ ] slack_bolt.async_app.AsyncApp and/or its core components
[ ] Adapters in slack_bolt.adapter
[ ] Document pages under /docs
[x] Others

Requirements (place an x in each [ ])
Please read the Contributing guidelines and Code of Conduct before creating this issue or pull request. By submitting, you are agreeing to those rules.

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.
[x] I've run ./scripts/install_all_and_run_tests.sh after making the changes.

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

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

Hi @liuyangc3, thanks a lot for taking the time to make this pull request.
Although your change is not yet complete, it gave me a great insight for fixing the issue #174 (This is the issue you were trying to resolve. I gave up fixing this a while ago but I just reopened it).
I sent another pull request #192 that resolves the issue for all patterns and added you to the co-authors in it (let me know if you don't want to be a co-author of the PR... hopefully not). Your contribution will be kept in the PR. Thus, please allow me to close this PR. If you have comments or feedback to #192, please feel free to write in. Thanks again for this contribution! 🙇

Hi @liuyangc3, thanks a lot for taking the time to make this pull request.
Although your change is not yet complete, it gave me a great insight for fixing the issue #174 (This is the issue you were trying to resolve. I gave up fixing this a while ago but I just reopened it).
I sent another pull request #192 that resolves the issue for all patterns and added you to the co-authors in it (let me know if you don't want to be a co-author of the PR... hopefully not). Your contribution will be kept in the PR. Thus, please allow me to close this PR. If you have comments or feedback to #192, please feel free to write in. Thanks again for this contribution! 🙇


res.cookie() doesn't set browser cookie on Production

res.cookie set browser cookie on localhost but doesn't set browser cookie after production and still I can find set-cookie in response header. I don't see any cors problem. I use Digitalocean App to deploy my node server.
res.cookie('ckstate', 'logged', {                 httpOnly: false,                  sameSite: router.get("env") === "development" ? true : "none",                  secure: router.get("env") === "development" ? false : true             })             .status(200)             .json(others)
Here is the POST request from my React client -
await axios.post(API_URL, user, { withCredentials: true })         .then(res => {             Auth.refreshAuth();             history.push('/');         })         .catch(err => {             console.log(err)             setMessage('Wrong Credentials. Try again.');         })

seems like you had another issue I tested it over express 4.17.1  and it worked well. Please explain with more detail

Closing due to no response.


No BidCoS-Interface available

Hi @leonsio I followed your suggestion and started using the branch-develop.
I installed everything with yahm-ui and everything was ok.
Then I went into the lxc container and I didn't see the rfd daemon.
I tried to start it manually and I get the follow error:
/var/log # /bin/rfd -f /etc/config/rfd.conf -l 0 -c
2017/04/14 21:30:22.914 <Info> BidCoS-Service started
2017/04/14 21:30:22.915 <Info> XmlRpc Server is listening on TCP port 2001
2017/04/14 21:30:22.916 <Warning> opendir(/etc/config/firmware//) failed
2017/04/14 21:30:22.917 <Debug> CCU2CommController::init() - Legacy initialization.
2017/04/14 21:30:24.554  RX SERIAL: fd 00 16 03 06 05 3a 58
2017/04/14 21:30:24.555  RX SERIAL: 00 36 f7 86 10 4f c2 65
2017/04/14 21:30:24.556  RX SERIAL: 00 00 00 0a 30 c7 0f 00
2017/04/14 21:30:24.557  RX SERIAL: 00 dd 53
2017/04/14 21:30:24.557  RX FRAME: 03 06 05 3a 58 00 36 f7 86 10 4f c2 65 00 00 00 0a 30 c7 0f 00 00
2017/04/14 21:30:24.557  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Unknown command type: 03  (hex).
2017/04/14 21:30:24.557 <Debug> () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/14 21:30:27.918 <Debug> () CCU2CommController::startCoprocessorApp(): Trying to start coprocessor application
2017/04/14 21:30:28.418  CCU2CommController::startCoprocessorAppThreadFunction(): Send start command
2017/04/14 21:30:28.418  CCU2CommController::SendSystemCommdand()
2017/04/14 21:30:28.418  CCU2CommController::SendSystemCommdand() sending: fd 00 03 00 00 03 18 0a
2017/04/14 21:30:28.421  RX SERIAL: fd 00 02 ff 00 02 00
2017/04/14 21:30:28.421  RX FRAME: ff 00
2017/04/14 21:30:28.421  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Message too small: 2 bytes.
2017/04/14 21:30:28.421 <Debug> () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/14 21:30:29.419 <Debug> () CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.

2017/04/14 21:30:31.419  CCU2CommController::startCoprocessorAppThreadFunction(): Retrying to send start command
2017/04/14 21:30:31.419  CCU2CommController::startCoprocessorAppThreadFunction(): Send start command
2017/04/14 21:30:31.419  CCU2CommController::SendSystemCommdand()
2017/04/14 21:30:31.419  CCU2CommController::SendSystemCommdand() sending: fd 00 03 00 01 03 9e 09
2017/04/14 21:30:31.421  RX SERIAL: fd 00 02 ff 01 82 05
2017/04/14 21:30:31.422  RX FRAME: ff 01
2017/04/14 21:30:31.422  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Message too small: 2 bytes.
2017/04/14 21:30:31.422 <Debug> () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/14 21:30:32.420 <Debug> () CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.

2017/04/14 21:30:32.919 <Fatal error> CCU2CommController::init(): Init failed. Cannot start coprocessor application.
2017/04/14 21:30:32.919  CCU2CommController::SendSystemCommdand()
2017/04/14 21:30:32.920  CCU2CommController::SendSystemCommdand() sending: fd 00 04 00 02 0a 00 3d 10
2017/04/14 21:30:32.922  RX SERIAL: fd 00 02 ff 02 82 0f
2017/04/14 21:30:32.923  RX FRAME: ff 02
2017/04/14 21:30:32.923  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Message too small: 2 bytes.
2017/04/14 21:30:32.923 <Debug> () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/14 21:30:33.921 <Debug> () CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.

2017/04/14 21:30:33.921 <Error> () CCU2CommController::setCSMACAEnabled(): Error disabling CSMA/CA.
2017/04/14 21:30:33.922 <Error> No BidCoS-Interface available
2017/04/14 21:30:33.923 <Warning> Error initializing interfaces

The script /etc/init.d/hm-mod-rpi-pcb status is executed correctly at the start time:
● hm-mod-rpi-pcb.service - LSB: Enables GPIO 18 as reset Interface for HM RF Module for Raspberry
   Loaded: loaded (/etc/init.d/hm-mod-rpi-pcb)
   Active: active (exited) since Fri 2017-04-14 23:27:18 CEST; 6min ago
  Process: 270 ExecStart=/etc/init.d/hm-mod-rpi-pcb start (code=exited, status=0/SUCCESS)

Apr 14 23:27:18 raspberrypi systemd[1]: Starting LSB: Enables GPIO 18 as reset Interface for HM RF Module for Raspberry...
Apr 14 23:27:18 raspberrypi hm-mod-rpi-pcb[270]: Enables GPIO 18 as Reset Interface for Homematic RF wireless module: Enables GPIO 18 as Re...-UART...
Apr 14 23:27:18 raspberrypi hm-mod-rpi-pcb[270]: Preparing GPIO for HM-MOD-UART done!Reseting PCB.
Apr 14 23:27:18 raspberrypi systemd[1]: Started LSB: Enables GPIO 18 as reset Interface for HM RF Module for Raspberry.

Any idea?

And in the /var/log/hmserver.log file in the container:
Apr 14 23:48:53 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [Timer-1] Could not register BidCos-RF_java
Apr 14 23:48:57 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-0] SYSTEM ADVICE: long-lasting deployment, check deployment configuration - currently deployed 15 out of 17
Apr 14 23:48:57 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-6] SYSTEM ADVICE: pre-conditions for deployment of LocalServerFirmwareUpdateInitialization still not met - check deployment configuration  (still unfulfilled: [connector.open])
Apr 14 23:48:57 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-2] SYSTEM ADVICE: pre-conditions for deployment of LegacyInitializion still not met - check deployment configuration  (still unfulfilled: [connector.open])
Apr 14 23:48:58 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [Timer-1] Could not register BidCos-RF_java
Apr 14 23:49:03 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [Timer-1] Could not register BidCos-RF_java
Apr 14 23:49:04 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-6] SYSTEM ADVICE: pre-conditions for deployment of LocalServerFirmwareUpdateInitialization still not met - check deployment configuration  (still unfulfilled: [connector.open])
Apr 14 23:49:04 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-2] SYSTEM ADVICE: pre-conditions for deployment of LegacyInitializion still not met - check deployment configuration  (still unfulfilled: [connector.open])

While the homematic gui is accesible but with no BidCos-RF.

You are coming from raspberrymatic? It flashes dualcoprocessor firmware. Enable homematic ip module or reflash the firmware

Am 14.04.2017 um 23:50 schrieb zioalex<EMAIL_ADDRESS>And in the /var/log/hmserver.log file in the container:
Apr 14 23:48:53 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [Timer-1] Could not register BidCos-RF_java
Apr 14 23:48:57 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-0] SYSTEM ADVICE: long-lasting deployment, check deployment configuration - currently deployed 15 out of 17
Apr 14 23:48:57 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-6] SYSTEM ADVICE: pre-conditions for deployment of LocalServerFirmwareUpdateInitialization still not met - check deployment configuration  (still unfulfilled: [connector.open])
Apr 14 23:48:57 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-2] SYSTEM ADVICE: pre-conditions for deployment of LegacyInitializion still not met - check deployment configuration  (still unfulfilled: [connector.open])
Apr 14 23:48:58 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [Timer-1] Could not register BidCos-RF_java
Apr 14 23:49:03 de.eq3.ccu.bidcos.dispatcher.BidCosRpcDispatcher ERROR [Timer-1] Could not register BidCos-RF_java
Apr 14 23:49:04 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-6] SYSTEM ADVICE: pre-conditions for deployment of LocalServerFirmwareUpdateInitialization still not met - check deployment configuration  (still unfulfilled: [connector.open])
Apr 14 23:49:04 de.eq3.cbcs.vertx.management.VertxManager WARN  [vert.x-eventloop-thread-2] SYSTEM ADVICE: pre-conditions for deployment of LegacyInitializion still not met - check deployment configuration  (still unfulfilled: [connector.open])
While the homematic gui is accesible but with no BidCos-RF.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

If you installed homematic ip module take a look at /dev/mmd_bidcos and /dev/ttyS0 they should be present on host and inside lxc.
Maybe you must enable this devices for lxc
        lxc-device -n yahm  add /dev/mmd_bidcos
        lxc-device -n yahm  add /dev/ttyS0

This is my first release with homematic ip. It contains some bugs ;)

Hi @leonsio yes I came from Raspberrymatic. What does it mean that I have to reflash the firmware? Do you mean the Funkmodul FW?
However I tried as you suggested and checked the device files.
The only missed was the /dev/ttyS0 while the other were already present:
lrwxrwxrwx    1 root     root             7 Apr 14 21:24 /dev/mmd_bidcos -> ttyAMA0
crw-------    1 root     root      204,  64 Apr 14 21:27 /dev/ttyAMA0

I also tried to install the homematic-ip module but it fails after downloading the kernel source but I cannot find any log regarding the failure. However the rfd daemon, still, fails to start.
I am trying to understand how to flash the FW and which FW :-D

So I tried with the eq3configcmd command from inside the container:
/opt # eq3configcmd update-coprocessor -p /dev/ttyS0  -c -se -d /firmware/
2017/04/15 14:07:17.332 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2017/04/15 14:07:17.332 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2017/04/15 14:07:19.333 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2017/04/15 14:07:19.333 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2017/04/15 14:07:21.333 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2017/04/15 14:07:21.333 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2017/04/15 14:07:22.333 <Error> CoprocessorUpdate::startApplication():Could not start Coprocessor application.

or
/opt # eq3configcmd update-coprocessor -p /dev/ttyS0  -c -u -d /firmware/
2017/04/15 14:09:00.877 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2017/04/15 14:09:00.877 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2017/04/15 14:09:02.886 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2017/04/15 14:09:02.886 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2017/04/15 14:09:04.886 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2017/04/15 14:09:04.886 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2017/04/15 14:09:05.886 <Error> CoprocessorUpdate::startApplication():Could not start Coprocessor application.

2017/04/15 14:09:05.886 <Error> Could not start Application, maybe no application on device, do update with dummy Version: 0.0.0

2017/04/15 14:09:05.886 <Info> Update necessary, installed: 0.0.0, avaiable 2.8.3

2017/04/15 14:09:06.886 <Info> CCU2CommControllerMod::sendSystemCommand(): failed
2017/04/15 14:09:06.886 <Error> CCU2CommControllerMod::performIdentify(): Unable to determine coprocessor state.
2017/04/15 14:09:09.387 <Info> CCU2CommControllerMod::sendSystemCommand(): failed

No way. I think the module is not correctly initialized at the host level.

I have some bugs in my script. Remove all if $? -eq 0 checks and let the script run (or replace 0 with 1 )
This should compile the kernel an build all modules. I will fix this in the next commit

Am 15.04.2017 um 15:43 schrieb zioalex<EMAIL_ADDRESS>Hi @leonsio yes I came from Raspberrymatic. What does it mean that I have to reflash the firmware? Do you mean the Funkmodul FW?
However I tried as you suggested and checked the device files.
The only missed was the /dev/ttyS0 while the other were already present:
lrwxrwxrwx    1 root     root             7 Apr 14 21:24 /dev/mmd_bidcos -> ttyAMA0
crw-------    1 root     root      204,  64 Apr 14 21:27 /dev/ttyAMA0
I also tried to install the homematic-ip module but it fails after downloading the kernel source but I cannot find any log regarding the failure. However the rfd daemon, still, fails to start.
I am trying to understand how to flash the FW and which FW :-D
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

so I have updated my script
try to run it with
yahm-module -m homematic-ip -f -v enable

the script is building ne kernel based on actual configuration but with PL011 shared module
after it, eq3_char_loop and bcm2835_raw_uart modules will be compiled and installed.
only with this modules you will be able to use your rpi-hm module (Funkmodul) with homematic. I think it is not possible to downgrade the firmware of the Funkmodul without this modules. so you can install raspberrymatic and manually downgrade the firmware, or you can try to run my script, with new kernel and modules installed, all should be run with homematic-ip support.
try to compile a new kernel without PL011 support, other steps are trivial
if you wish I can help you with teamweaver session

@leonsio thank you very much for your support. I really appreciate it.
I am trying now with the latest patch. Now the kernel is building. Let's see.
At the moment..just Frohe Ostern :-)

Oky we have now something better to see :-)
/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -u  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:17.725 <Info> Version: 2.2.1

2017/04/16 06:43:17.725 <Info> Update necessary, installed: 2.2.1, avaiable 2.8.4

2017/04/16 06:43:44.174 <Info> Firmwareupdate successfull

/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -v  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:52.700 <Info> Version: 2.8.4

# eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -se
2017/04/16 07:53:15.585 <Info> SerialNumber: NEQ1331777

But still the rfd daemon doesn't run properly!
2017/04/16 07:49:07.027 <Debug> () CCU2CommController::startCoprocessorApp(): Trying to start coprocessor application
2017/04/16 07:49:07.528  CCU2CommController::startCoprocessorAppThreadFunction(): Send start command
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand()
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand() sending: fd 00 03 00 00 03 18 0a
2017/04/16 07:49:07.530  RX SERIAL: fd 00 02 ff 00 02 00
2017/04/16 07:49:07.531  RX FRAME: ff 00
2017/04/16 07:49:07.531  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Message too small: 2 bytes.
2017/04/16 07:49:07.531 <Debug> () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/16 07:49:08.529 <Debug> () CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.

I retried also with a clean LXC container but the result in the same.

Please post output from ls -al /dev from LXC AND Host (raspberry)
Check if pl011 module is shared.

Am 16.04.2017 um 09:53 schrieb zioalex<EMAIL_ADDRESS>Oky we have now something better to see :-)
/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -u  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:17.725  Version: 2.2.1
2017/04/16 06:43:17.725  Update necessary, installed: 2.2.1, avaiable 2.8.4
2017/04/16 06:43:44.174  Firmwareupdate successfull
/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -v  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:52.700  Version: 2.8.4
eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -se
2017/04/16 07:53:15.585  SerialNumber: NEQ1331777
But still the rfd daemon doesn't run properly!
2017/04/16 07:49:07.027  () CCU2CommController::startCoprocessorApp(): Trying to start coprocessor application
2017/04/16 07:49:07.528  CCU2CommController::startCoprocessorAppThreadFunction(): Send start command
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand()
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand() sending: fd 00 03 00 00 03 18 0a
2017/04/16 07:49:07.530  RX SERIAL: fd 00 02 ff 00 02 00
2017/04/16 07:49:07.531  RX FRAME: ff 00
2017/04/16 07:49:07.531  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Message too small: 2 bytes.
2017/04/16 07:49:07.531  () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/16 07:49:08.529  () CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.
I retried also with a clean LXC container but the result in the same.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

I will try to explain you, why your setup is not working
With the normal firmware
Rfd communicate with /dev/ttyAMA0
With homematic-ip firmware your have 2 kernel modules:

bcm2835-raw-uart
eq3_char_loop

First of all you need to start multimacd daemon, this will load eq3_char_loop module (/dev/eq3loop) and create two dev devices
/dev/mmd_bidcos		used for homematic communication. (rfd)
/dev/ttyS0		used for homematic-ip. (hmipserver.jar)
Dmesg output
[90355.127728] eq3loop: created slave ttyS0
[90355.130855] eq3loop: created slave mmd_bidcos
[96140.107958] eq3loop: eq3loop_open_slave() mmd_bidcos
In the configuration without homematic-ip, you can find a symlink from /ttyAMA0 to /dev/mmd_bidcos, with homematic-ip this should be native device.
That you have to do is
On host

Check if pl011 module is shared: modinfo amba_pl011
check if bcm2835-raw-uart and eq3_char_loop are loaded -> /dev/bcm2835-raw-uart and /dev/eq3loop are present
Take a look on multimacd.conf /etc/config in LXC and /etc/init.d/S60multimacd . (Coprocessor Device Path = /dev/bcm2835-raw-uart replace uart device if needed)
Start /etc/init.d/S60multimacd inside LXC, you must find some messages in dmesg (like above)
Remove symlink from /dev/mmd_bidcos
In host system you will find /dev/mmd_bidcos and /dev/ttyS0
Pass throw the devices to container

lxc-attach -n yahm -- rm -rf /dev/ttyS0
lxc-attach -n yahm -- rm -rf /dev/mmd_bidcos
8 start rfd

Am 16.04.2017 um 09:53 schrieb zioalex<EMAIL_ADDRESS>Oky we have now something better to see :-)
/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -u  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:17.725  Version: 2.2.1
2017/04/16 06:43:17.725  Update necessary, installed: 2.2.1, avaiable 2.8.4
2017/04/16 06:43:44.174  Firmwareupdate successfull
/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -v  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:52.700  Version: 2.8.4
eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -se
2017/04/16 07:53:15.585  SerialNumber: NEQ1331777
But still the rfd daemon doesn't run properly!
2017/04/16 07:49:07.027  () CCU2CommController::startCoprocessorApp(): Trying to start coprocessor application
2017/04/16 07:49:07.528  CCU2CommController::startCoprocessorAppThreadFunction(): Send start command
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand()
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand() sending: fd 00 03 00 00 03 18 0a
2017/04/16 07:49:07.530  RX SERIAL: fd 00 02 ff 00 02 00
2017/04/16 07:49:07.531  RX FRAME: ff 00
2017/04/16 07:49:07.531  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Message too small: 2 bytes.
2017/04/16 07:49:07.531  () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/16 07:49:08.529  () CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.
I retried also with a clean LXC container but the result in the same.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/leonsio/YAHM/issues/109#issuecomment-294338967, or mute the thread https://github.com/notifications/unsubscribe-auth/AAwBF1x25fBfWtuyVDN6G9B69PTBpi5Qks5rwckJgaJpZM4M-Hl3.

Hi i have uploaded some bugfixes
In you have recompiled your Kernel without pl011 Module. Everything Else should run without Problems
Von meinem iPad gesendet

Am 16.04.2017 um 09:53 schrieb zioalex<EMAIL_ADDRESS>Oky we have now something better to see :-)
/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -u  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:17.725  Version: 2.2.1
2017/04/16 06:43:17.725  Update necessary, installed: 2.2.1, avaiable 2.8.4
2017/04/16 06:43:44.174  Firmwareupdate successfull
/firmware/HM-MOD-UART # eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -v  -d /firmware/HM-MOD-UART/
2017/04/16 06:43:52.700  Version: 2.8.4
eq3configcmd update-coprocessor -p /dev/ttyAMA0    -c -se
2017/04/16 07:53:15.585  SerialNumber: NEQ1331777
But still the rfd daemon doesn't run properly!
2017/04/16 07:49:07.027  () CCU2CommController::startCoprocessorApp(): Trying to start coprocessor application
2017/04/16 07:49:07.528  CCU2CommController::startCoprocessorAppThreadFunction(): Send start command
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand()
2017/04/16 07:49:07.528  CCU2CommController::SendSystemCommdand() sending: fd 00 03 00 00 03 18 0a
2017/04/16 07:49:07.530  RX SERIAL: fd 00 02 ff 00 02 00
2017/04/16 07:49:07.531  RX FRAME: ff 00
2017/04/16 07:49:07.531  CCU2CoprocessorCommand::CCU2CoprocessorCommand(): Message too small: 2 bytes.
2017/04/16 07:49:07.531  () CCU2CommController::handleIncomingSerialFrame(): Command not parseable.
2017/04/16 07:49:08.529  () CCU2CommController::waitForCoProcessorResponse(): Timeout while waiting for response.
I retried also with a clean LXC container but the result in the same.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

i have found anther "bug", after you have recompiled the kernel, you must remove pl011 module
mv /lib/modules/4.4.50-v7+/kernel/drivers/tty/serial/amba-pl011.ko /root && depmod -a

after it, reload eq3loop and bcm2835-raw-uart modules and restart multimacd, you will find mmd_bidcos module under /dev

HI @leonsio Finally it's working :-D Thanks for you explanation.
The multimacd daemon is running in the LXC while the device file /dev/eq3loop  was not present in the LXC container. I had to update the coprocessor dev file in the /etc/config/multimacd.conf to point zo /dev/bcm2835-raw-uart .
Debugging the multimacd with
/bin/multimacd -f /etc/config/multimacd.conf -l 0 -c

I found out that also  the  /dev/bcm2835-raw-uart device was not present in the container
So in additional to the step you suggested
lxc-device -n yahm  add /dev/mmd_bidcos

I had to do also the following:
lxc-device -n yahm  add /dev/bcm2835-raw-uart
lxc-device -n yahm  add /dev/eq3loop

Now is working and I am readding my components.
I learned a lot on how it is working although It is not completely clear all the daemon's relationship. Please can you point to the right documentation...if any.
Thanks a lot.


adi_sdp_k1: Enable usb cdc support

This PR adds support for usb cdc on the adi sdp k1.
the PR includes:

patch to fix to avoid disabling ULPI clk in case of external ULPI phy.
DT changes to enable ulpi phy and usb udc on sdp_k1.

Validated using a sdp_k1 revE using the  samples/subsys/usb/cdc_acm application: the board enumerates correctly on a linux pc, and opening the ttyACMx
device we are able to see the characters that are echoed back.

DNM until @erwango reviewed clock changes.

Hi @ahaslam2  -- can you please rebase your change to pick up the recent modifications around "hardware model v2"?


Throw InvalidConfigException when 'roles' isn´t an array

Q
A

Is bugfix?
/no

New feature?
yes

Breaks BC?
no

Tests pass?
yes

Throw InvalidConfigException when 'roles' isn´t an array. Would have saved me a lot of debugging time.
This is another approach to https://github.com/yiisoft/yii2/pull/13168 .

@thyseus Why the framework needs an additional check considering the documentation clearly states we should only use array of the roles?
    /**
     * @var array list of roles that this rule applies to. Two special roles are recognized, and
     * they are checked via [[User::isGuest]]:
     *
     * - `?`: matches a guest user (not authenticated yet)
     * - `@`: matches an authenticated user
     *
     * If you are using RBAC (Role-Based Access Control), you may also specify role or permission names.
     * In this case, [[User::can()]] will be called to check access.
     *
     * If this property is not set or empty, it means this rule applies to all roles.
     */
    public $roles;

Would have saved me a lot of debugging time.

This is clearly your fault of misusing the framework classes.

I am all for improving error messages that are unclear but in this case:
 PHP Warning – yii\base\ErrorException
Invalid argument supplied for foreach()

in /home/cebe/dev/yiisoft/yii2/framework/filters/AccessRule.php  at line 142

...

foreach($this->roles as $role) {

...

It points to AccessRule -> $this->roles so you could directly check what you set there.

Ok, i agree to dismiss this change.


nftables implementation

Signed-off-by: Serguei Bezverkhi<EMAIL_ADDRESS>WIP InterceptRuleMgr implementation based on nftables

@sbezverk: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@rlenglet  -- Looks like my comments to make a pkg or lib were ignored on that PR.  I disagree we should follow that model.  (https://github.com/istio/istio/blob/master/tools/istio-iptables/main.go)
I think I agree with the spirit of what you're saying but putting stuff like this under istio/istio/tools is bad practice, IMO.  It's not really usable in CNI under the new InterceptRuleMgr interface we're adding other than to just invoke it as a shell program like istio-iptables.sh is done today.  I think the model to propogate is a go pkg / lib model.
I was envisioning the istio/cni having packages like what @sbezverk is making and being able to build alternate cmd bins that can be used in an istio-init container.  The PR for golang istio-iptables conflated the details of the iptables setup with the executable part that takes in commandline/ env params.  If the iptables stuff was split out into a lib (maybe in istio/cni) then that executable in istio/istio could import it and call it.

@tiswanso I completely agree with your comments about the Go lib in istio/istio. But IMHO this is not a good reason for not fixing and moving the Go lib in istio/istio and working in that repo.

@rlenglet -- I think it's debatable whether these type of libs should live in istio/istio or istio/cni.  But in the interest of getting something done I don't think we should make @sbezverk suffer the code reorg pain in multiple repos just because the other PR went in.  His intention is to add a mechanism for optional nfttables usage in the cni.  Trying to get a reorg of code in the istio/istio megarepo is way more painful to try and get going at the same time.

btw, I think this will be WIP for a while so this is fine for working on nfttables until there's confidence about wanting this to be in some branch somewhere.

I'd like to avoid a fork of the istio-init code. This is one of the most critical piece of code in Istio since it's the only code that runs as root on the node. Having a duplicate implementation would increase the risk of security issues.

@rlenglet @tiswanso I am totally ok to reorg once the code is ready. To make the code ready, would be very helpful if you start looking at the code, its logic etc.
Here is the resulting nf tables generated by the code for ipv4 and ipv6:
[root@centos-nft-1-576ff7cd79-n2ktp /]# nft list table istio_ipv4 -n -a
table ip istio_ipv4 {
        set istio_ssh_excl_ipv4 {
                type inet_service
                flags constant
                elements = { ssh }
        }

        set b7f0c48e-1602-4e4c-b9af-552ecea87245 {
                type inet_service
                flags constant
                elements = { 15020 }
        }

        set 64512448-2ed0-4db9-910a-5a0c0692795e {
                type inet_service
                flags constant
                elements = { http-alt, 9080 }
        }

        chain istio_prerouting_ipv4 {
                type nat hook prerouting priority 0; policy accept;
                ip protocol tcp goto istio_inbound_ipv4 # handle 18
        }

        chain istio_output_ipv4 {
                type nat hook output priority 0; policy accept;
                ip protocol tcp goto istio_outbound_ipv4 # handle 17
        }

        chain istio_inbound_ipv4 {
                tcp dport @istio_ssh_excl_ipv4 return # handle 8
                tcp dport @64512448-2ed0-4db9-910a-5a0c0692795e goto istio_redirect_ipv4 comment "" # handle 16
        }

        chain istio_outbound_ipv4 {
                ip daddr <IP_ADDRESS> return comment "" # handle 9
                skuid 1337 return comment "" # handle 10
                skgid 1337 return # handle 11
                tcp dport @b7f0c48e-1602-4e4c-b9af-552ecea87245 return # handle 13
                goto istio_redirect_ipv4 comment "" # handle 14
        }

        chain istio_redirect_ipv4 {
                counter packets 2 bytes 120 # handle 20
                ip protocol tcp redirect to :15001 comment "" # handle 6
        }
}

[root@centos-nft-1-576ff7cd79-n2ktp /]# nft list table ip6 istio_ipv6 -n -a
table ip6 istio_ipv6 {
        set istio_ssh_excl_ipv6 {
                type inet_service
                flags constant
                elements = { ssh }
        }

        set 5ab03da6-a0cd-4377-8011-241e6c573367 {
                type inet_service
                flags constant
                elements = { 15020 }
        }

        set 77823867-f16c-49de-84f4-b81f34753bb2 {
                type inet_service
                flags constant
                elements = { http-alt, 9080 }
        }

        chain istio_prerouting_ipv6 {
                type nat hook prerouting priority 0; policy accept;
                ip6 nexthdr tcp goto istio_inbound_ipv6 # handle 18
        }

        chain istio_output_ipv6 {
                type nat hook output priority 0; policy accept;
                ip6 nexthdr tcp goto istio_outbound_ipv6 comment "" # handle 17
        }

        chain istio_inbound_ipv6 {
                tcp dport @istio_ssh_excl_ipv6 return # handle 8
                tcp dport @77823867-f16c-49de-84f4-b81f34753bb2 goto istio_redirect_ipv6 comment "handle 16
        }

        chain istio_outbound_ipv6 {
                ip6 daddr ::1 return # handle 9
                skuid 1337 return comment "handle 10
                skgid 1337 return # handle 11
                tcp dport @5ab03da6-a0cd-4377-8011-241e6c573367 return comment "handle 13
                goto istio_redirect_ipv6 comment "" # handle 14
        }

        chain istio_redirect_ipv6 {
                ip6 nexthdr tcp redirect to :15001 comment "" # handle 6
        }
}

Tested both Redirect and TProxy,  both work.

@sbezverk Can you give more details? What Linux kernel version have you used?

@rlenglet 4.15 for normal redirect, ubuntu 18.04 and 5.0.21 to tproxy mode

@sbezverk Right, so tproxy will require a very recent kernel.
And maybe even a specific module or option to be set in the kernel, right?
So unless the admin runs such a kernel, I suppose the CNI plugin will fail with a cryptic error message when the mode is set to TPROXY? Can you post a comment with the specific error message when that happens?
If that message is hard to understand, please add a user-friendly error message when that fails.
And also add a check in the daemon set to check whether TPROXY nftables support is enabled on the worker node, and log at WARNING level so that users can debug that more easily.

@rlenglet no options in kernel requires, anything above 4.18 will support tproxy. I already check for nf_tables modules and return error which will appear in kubelet's log. For detecting tproxy, there is no good solution, other than rely on kernel version.

@sbezverk: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@sbezverk: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lint_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lint_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lint_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lint_cni

e2e_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test e2e_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lint_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lint_cni

e2e_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test e2e_cni

lintmodern_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lintmodern_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk would you be kind enough to force push?  I have removed circleci from the checks and the checks have undergone some pretty significant changes since your last push.  It would be nice to push this over the finish line, or atleast get it in a state where it may be reviewed.
Cheers
-steve

@rlenglet @howardjohn reading through the review comments is the "forking issue" having to do with the reality that @sbezverk has created a derivative work of nftables based upon the google nftpables library?  I think that is a poor reason to stop progression on this PR.
Additionally, we should have a more stringent policy on the introduction of third party dependencies possibly reviewed by the TOC.  There are sustainability and licensing concerns with importing third party libraries (and their transitive dependencies).  We must ensure that dependencies are well maintained and don't introduce sustainability or licensing issues in the future.
@geeknoid FYI ^
Cheers
-steve

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lint_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lint_cni

lintmodern_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lintmodern_cni

e2e_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test e2e_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lint_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lint_cni

e2e_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test e2e_cni

lintmodern_cni
85591f00aa606460dd940d325715a60cc31dc03e
link
/test lintmodern_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lint_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lint_cni

lintmodern_cni
85591f00aa606460dd940d325715a60cc31dc03e
link
/test lintmodern_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk please do not check in the vendor directory.  The cni repo no longer requires implementations to be vendored.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lint_cni
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test lint_cni

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sdake lint is failing on a non this pr related check. Not sure how I could fix it.

@rlenglet @howardjohn reading through the review comments is the "forking issue" having to do with the reality that @sbezverk has created a derivative work of nftables based upon the google nftpables library? I think that is a poor reason to stop progression on this PR.

I've been very clear that this should be done in istio/istio so we have a single Golang implementation of the iptables script, instead of two. This change would actually be more useful in istio/istio than in istio/cni, because CNI can use the worker node's nftables iptables wrapper transparently without any code changes. istio-init can't do that and needs a code / packaging change to use nftables.

Any argument that /tools/iptables in istio/istio is not flexible enough to integrate this change is moot. That package is being refactored and should be able to accommodate an nftables implementation.

@rlenglet - I know you have been clear on your position,  but your position is not universally shared.   Other have been clear that forcing @sbezverk to refactor and fix issues due to the way istio/istio implemented the golang iptables is holding new work hostage due to previous bad decisions.   We have to find some middle ground to allow improvements like this to go in without forcing all previous poor choices to be fixed.

@rlenglet nftables is NOT iptables so placing nftables in istio/iptables does not make too much sense.
current implementation of iptables in istio/iptables is a separate executable. How do you plan to use it in istio-cni? Also there is no any interface defined for iptables which could be replaced by other mechanism driver implementation as nftables for example.
I have nothing against placing nftables in istio repo, but not in the form how iptables is used currently.

forcing @sbezverk to refactor and fix issues

I'm not forcing anyone to do anything. That refactoring effort is underway and @sbezverk has not been contributing to it.

@rlenglet - sounds like that is a good middle ground.   I will ping on slack to find a pointer to that work.

See https://github.com/istio/istio/pull/17044 which removes the cleanup code from the iptables script, which will simplify it and the Golang implementation a bit.
See also @abhide's https://github.com/istio/istio/pull/16837. This work is still in progress. The goal is to introduce more abstractions into the code to make it more unit-testable, and also to move to iptables-restore.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

lint_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lint_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

/retest

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

lint_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lint_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sdake lint is failing on a non this pr related check. Not sure how I could fix it.

@sbezverk I will take a look.  I have been changing around how ci works in this repo - and may have busted something.

/test lint_cni

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

lint_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lint_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@rlenglet no options in kernel requires, anything above 4.18 will support tproxy. I already check for nf_tables modules and return error which will appear in kubelet's log. For detecting tproxy, there is no good solution, other than rely on kernel version.

Relying on the kernel version for detection is unsuitable.  Some distros (such as centos) backport bug fixes and add enhancements but may have an older kernel version.

@sbezverk: The following tests failed, say /retest to rerun them all:
Test name	Commit	Details	Rerun command
cni-lint-master	6b034ae link /test cni-lint-master
cni-e2e-master	6b034ae link /test cni-e2e-master
lintmodern_cni	8ad28db link /test lintmodern_cni
lint_cni	8ad28db link /test lint_cni

@sbezverk if this is what you mean, most of these can be ignored.  This PR has been outstanding since june, and many of the targets for CI have changed.  As a result, some of those will report errors (because prow has a defect in this area), rather than just dropping of the list of CIs.  Prow is not Zuul sadly.
As for cni-lint, not sure why the linter is faling.  Have asked @geeknoid to take a look at it - he has been doing all of the lint improvements.
Cheers
-steve

The lint failure is due to the fact new dependencies are being added to the repo, and one of those dependencies doesn't have a known license type. The offending module (github.com/koneu/natend) will need to be added to the white list in common/config/license-lint.yml. This file should be changed in the istio/common-files repo first, and then propagated into this repo.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

lint_cni
decb680940ce9355651eb809ca91da2c5cca00a1
link
/test lint_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@geeknoid removed lock file and push PR to update license whitelist
https://github.com/istio/common-files/pull/96

This looks interesting. Red Hat's Istio deployments are all using nftables, but through the iptables-nftables wrapper. This PR would make Istio CNI use nftables directly. Plus, since it calls the API directly instead of resorting to running the iptables binary, it should be much more performant. We'd definitely like to see this or a similar nftables solution merged.

@sbezverk does nftables default on or off?

@duderino yep, it is off and to turn it on it has to be explicitly requested.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

lint_cni
4c5af4a3470ff17b862589837306df11952fb4f6
link
/test lint_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

lint_cni
4c5af4a3470ff17b862589837306df11952fb4f6
link
/test lint_cni

gencheck_cni
4c5af4a3470ff17b862589837306df11952fb4f6
link
/test gencheck_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@sbezverk: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

cni-lint-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-lint-master

cni-e2e-master
6b034aef7a33d34f419651394de0cca7eaef8432
link
/test cni-e2e-master

lintmodern_cni
8ad28dbe179e16fb891815dfd31caab2b823a758
link
/test lintmodern_cni

lint_cni
4c5af4a3470ff17b862589837306df11952fb4f6
link
/test lint_cni

gencheck_cni
9e555ecbe1f2a37d5e2e0e82085254151f90741a
link
/test gencheck_cni

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

I understand @rlenglet 's point about consolidating the code in one single place and thats the right way to go. That said, I personally dont think we need to make istio/istio as the home base for that code. We intentionally kept the CNI as a separate repo so that others can use it as well. Given that goal, we should move the iptables code into the cni and import it in istio/istio, and not the other way around. If we are not interested in keeping this main code out of Istio, then we should fold the entire CNI into istio/istio and not keep it as a separate project.
Either way, we need to get to just a single source of truth for this critical code. Lets discuss this in the networking meeting on thursday and get this work unblocked.

I see that it is not worth to waste more time in convincing google that nftables implementation has a right to exist. Closing this pr.


FFM stops working after using LibreOffice for a while

While typing in LibreOffice yabai sometimes reports the following messages:
EVENT_HANDLER_WINDOW_CREATED: LibreOffice 26594  EVENT_HANDLER_WINDOW_DESTROYED: LibreOffice 26594  EVENT_HANDLER_WINDOW_CREATED: LibreOffice 26595  EVENT_HANDLER_WINDOW_DESTROYED: LibreOffice 26595  EVENT_HANDLER_WINDOW_CREATED: LibreOffice 26596  EVENT_HANDLER_WINDOW_DESTROYED: LibreOffice 26596
After that FFM does not work anymore and windows can be moved around freely:

This seems to be happening when LibreOffice suggests a word completion. Apparently the suggestion itself is a window and while typing it keeps getting created and destroyed.

I tested this some more and can't reproduce it anymore.
Not sure if it's gone for good or the reason is something else but I'll close this for now.


Uncaught SyntaxError: Invalid regular expression: /[\n\r\u2028\u2029]/: Regular expression too large

Not sure what happened, all of a sudden Webpack is throwing the following error on the dev server on npm start. Nothing changed in the webpack config for React Scripts:
Uncaught SyntaxError: Invalid regular expression: /[\n\r\u2028\u2029]/: Regular expression too large
The error is coming from chunk.js, which is not something I'm touching during development and its with the following line:
var reNewLine = /[\n\r\u2028\u2029]/g;
I've tried removing and reinstalling node modules, upgraded downgraded React and react-scripts and react dom, I've tried switching node versions with nvm, and I've tried reverting back to an earlier branch commit where I knew the app was loading fine. Nothing works. Was working on app components and then this error just started popping up randomly.
Help!!! Lol

Node.js downgrade to v14 helped me.

That doesn’t solve this issue for me. I’m already running Node 14.8. The issue is with the regex interpreter for Chrome > 95. It works fine on Chrome 91.
Sent from my iPhone

On Jan 18, 2022, at 9:35 AM, tspiechaczek @.***> wrote:

Node.js downgrade to v14 helped me.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you authored the thread.

This is a bug in v8, https://groups.google.com/g/v8-reviews/c/9BbASYhUAmQ

@bluehymn, thank you for this! Great find.


Backport: Unable to add node driver master

https://github.com/rancher/rancher/issues/20796

Validated on the latest master (06/14/2019)
Able to add custom driver : Linode
https://github.com/linode/docker-machine-driver-linode/releases/download/v0.1.8/docker-machine-driver-linode_linux-amd64.zip
UI: https://linode.github.io/rancher-ui-driver-linode/releases/v0.2.0/component.js
logs:
Download https://github.com/linode/docker-machine-driver-linode/releases/download/v0.1.8/docker-machine-driver-linode_linux-amd64.zip
2019/06/14 16:39:50 [INFO] Found driver docker-machine-driver-linode
2019/06/14 16:39:50 [INFO] Copying management-state/machine-drivers/18206b37b5529c1138ddc9fe568a803b03ae3c39ebb8abe4ae1934aef49ba4bc-docker-machine-driver-linode => /opt/drivers/management-state/bin/docker-machine-driver-linode-tmp
2019/06/14 16:39:50 [INFO] uploading linodeConfig to nodeconfig schema
2019/06/14 16:39:50 [INFO] uploading linodeConfig to nodetemplateconfig schema
2019/06/14 16:39:50 [INFO] uploading linodecredentialConfig to credentialconfig schema

UI:


Scrap HMR and just use nodemon when watching build

What
HMR broke again 🙄
We have been having constant issues with hot-module-reloading not
working or breaking whenever we make unrelated changes.
This gives up on the HMR approch and instead uses nodemon to watch the
dist dir and restart the server whenever it changes. This has a tiny
delay compared to HMR and will mean the server connection gets dropped momentarily but at least it actually works.
A nodemon webpack plugin is used to make the config simpler.
How to review

Run it locally
Try changing a njk template or something
watch it restart the server

Who can review
Not @chrisfarms

This works really well for me, but unless I am misunderstanding node require (which wouldn't be the first time), nodemon-webpack-plugin is always required, but it will only be installed in dev.

In package.json it is defined in the devDependencies section. It is also required in the config file that is used by webpack, which is only to be run on your local machine or the build CI. In production it will not be loaded nor installed :)

Ok cool, thanks for explaining :)


Add missing docker dependencies for go-algorand.

Closes https://github.com/algorand/indexer/issues/614.

Codecov Report

Merging #615 (87110d4) into develop (70257be) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff            @@
##           develop     #615   +/-   ##
========================================
  Coverage    48.07%   48.07%
========================================
  Files           25       25
  Lines         3800     3800
========================================
  Hits          1827     1827
  Misses        1694     1694
  Partials       279      279

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 70257be...87110d4. Read the comment docs.


Fix nevents

This fixes the strange situation where there is less data in signal1.bin than there are events in the xml files.  Eg. when the amp dies in the middle of recording.

can I close this? it's empty

I think I fixed the commits, there should be 3 small changes.  Sorry I'm not super familiar with branches etc.

which I now notice are in the other branch too, so you can close this one...


Always shouldBlockPulsarProducer is false if do not set the system property

https://github.com/apache/pulsar/blob/156b4be4a1bd55a9f9a6b25c3a46836236cc1390/pulsar-client-kafka-compat/pulsar-client-kafka/src/main/java/org/apache/kafka/clients/producer/PulsarKafkaProducer.java#L172
expect not use Boolean.getBoolean method

The issue had no activity for 30 days, mark with Stale label.

Closed as stale. Please create a new issue if it's still relevant to the maintained versions.
IIRC we don't have this module anymore.


IdentityMap Request Context fails in NestJS app when using app.setGlobalPrefix

Describe the bug
When adding app.setGlobalPrefix('api'); to the bootstrap function in my NestJS main.ts file MikroORM does no longer properly handle request context for the identity map and it gives the error: Using global EntityManager instance methods for context specific actions is disallowed. The moment I remove app.setGlobalPrefix('api') everything works fine again.
Stack trace
[11:13:14 PM] File change detected. Starting incremental compilation...
2023-08-04 01:13:14
2023-08-04 01:13:14 [11:13:14 PM] Found 0 errors. Watching for file changes.
2023-08-04 01:13:14
2023-08-04 01:13:14 Debugger listening on ws://<IP_ADDRESS>:9229/51438209-c42b-4c53-bee1-0445a63b865e
2023-08-04 01:13:14 For help, see: https://nodejs.org/en/docs/inspector
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [NestFactory] Starting Nest application...
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] MikroOrmModule dependencies initialized +14ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] PassportModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] JwtModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] ConfigHostModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] ConfigModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] GraphQLSchemaBuilderModule dependencies initialized +2ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] GraphQLModule dependencies initialized +1ms
2023-08-04 01:13:15 [info] MikroORM version: 5.7.14
2023-08-04 01:13:15 [discovery] ORM entity discovery started, using TsMorphMetadataProvider
2023-08-04 01:13:15 [discovery] - processing 3 files
2023-08-04 01:13:15 [discovery] - processing entity User (/app/dist/src/user/user.entity.js)
2023-08-04 01:13:15 [discovery] - using cached metadata for entity User
2023-08-04 01:13:15 [discovery] - processing entity OrderItem (/app/dist/src/order/entities/order-item.entity.js)
2023-08-04 01:13:15 [discovery] - using cached metadata for entity OrderItem
2023-08-04 01:13:15 [discovery] - processing entity Order (/app/dist/src/order/entities/order.entity.js)
2023-08-04 01:13:15 [discovery] - using cached metadata for entity Order
2023-08-04 01:13:15 [discovery] - entity discovery finished, found 3 entities, took 29 ms
2023-08-04 01:13:15 [info] MikroORM successfully connected to database app on postgresql://postgres:*****@postgres:5432
2023-08-04 01:13:15 [query] select 1 from pg_database where datname = 'app' [took 1 ms, 1 result]
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] MikroOrmCoreModule dependencies initialized +49ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] MikroOrmModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] AppModule dependencies initialized +1ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] OrderModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] UserModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [InstanceLoader] AuthModule dependencies initialized +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [RoutesResolver] AppController {/api}: +6ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [RouterExplorer] Mapped {/api, GET} route +1ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [RoutesResolver] AuthController {/api/auth}: +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [RouterExplorer] Mapped {/api/auth/login, POST} route +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [RouterExplorer] Mapped {/api/auth/protected, GET} route +0ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [GraphQLModule] Mapped {/graphql, POST} route +36ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM     LOG [NestApplication] Nest application successfully started +1ms
2023-08-04 01:13:15 [Nest] 311  - 08/03/2023, 11:13:15 PM   ERROR [ExceptionsHandler] Using global EntityManager instance methods for context specific actions is disallowed. If you need to work with the global instance's identity map, use `allowGlobalContext` configuration option or `fork()` instead.
2023-08-04 01:13:15 ValidationError: Using global EntityManager instance methods for context specific actions is disallowed. If you need to work with the global instance's identity map, use `allowGlobalContext` configuration option or `fork()` instead.
2023-08-04 01:13:15     at Function.cannotUseGlobalContext (/app/node_modules/.pnpm/@mikro-orm+core@5.7.14_@mikro-orm+postgresql@5.7.14_@mikro-orm+seeder@5.7.14/node_modules/@mikro-orm/core/errors.js:95:16)
2023-08-04 01:13:15     at SqlEntityManager.getContext (/app/node_modules/.pnpm/@mikro-orm+core@5.7.14_@mikro-orm+postgresql@5.7.14_@mikro-orm+seeder@5.7.14/node_modules/@mikro-orm/core/EntityManager.js:1123:44)
2023-08-04 01:13:15     at SqlEntityManager.findOne (/app/node_modules/.pnpm/@mikro-orm+core@5.7.14_@mikro-orm+postgresql@5.7.14_@mikro-orm+seeder@5.7.14/node_modules/@mikro-orm/core/EntityManager.js:302:25)
2023-08-04 01:13:15     at AppController.index (/app/src/app.controller.ts:11:26)
2023-08-04 01:13:15     at /app/node_modules/.pnpm/@nestjs+core@10.1.2_@nestjs+common@10.1.2_@nestjs+platform-express@10.1.2_reflect-metadata@0.1.13_rxjs@7.8.1/node_modules/@nestjs/core/router/router-execution-context.js:38:29
2023-08-04 01:13:15     at InterceptorsConsumer.intercept (/app/node_modules/.pnpm/@nestjs+core@10.1.2_@nestjs+common@10.1.2_@nestjs+platform-express@10.1.2_reflect-metadata@0.1.13_rxjs@7.8.1/node_modules/@nestjs/core/interceptors/interceptors-consumer.js:12:20)
2023-08-04 01:13:15     at /app/node_modules/.pnpm/@nestjs+core@10.1.2_@nestjs+common@10.1.2_@nestjs+platform-express@10.1.2_reflect-metadata@0.1.13_rxjs@7.8.1/node_modules/@nestjs/core/router/router-execution-context.js:46:60
2023-08-04 01:13:15     at /app/node_modules/.pnpm/@nestjs+core@10.1.2_@nestjs+common@10.1.2_@nestjs+platform-express@10.1.2_reflect-metadata@0.1.13_rxjs@7.8.1/node_modules/@nestjs/core/router/router-proxy.js:9:23
2023-08-04 01:13:15     at Layer.handle [as handle_request] (/app/node_modules/.pnpm/express@4.18.2/node_modules/express/lib/router/layer.js:95:5)
2023-08-04 01:13:15     at next (/app/node_modules/.pnpm/express@4.18.2/node_modules/express/lib/router/route.js:144:13)

To Reproduce
Steps to reproduce the behavior:

Setup a NestJS app with MikroORM installed
Add app.setGlobalPrefix('api'); to the NestJS bootstrap function in main.ts
Inject the EntityManager inside the AppController and call this.em.find(...) inside a route function of that controller.

Expected behavior
I would expect MikroORM to behave the same with and without using app.setGlobalPrefix.
Additional context
Using it within a NestJS application.
Versions
5.7.14

Dependency
Version

node
20-slim

typescript
5.1.6

mikro-orm
5.7.14

nestjs
10.1.2

This example app is doing that and works just fine. You will need to provide complete repro for this.
https://github.com/mikro-orm/nestjs-realworld-example-app/blob/master/src/main.ts#L8

I faced the same problem

Probably related: https://github.com/nestjs/nest/issues/11572

Closing as this should be addressed in next nest version via https://github.com/nestjs/nest/pull/13337

Closing as this should be addressed in next nest version via nestjs/nest#13337

Unfortunately it didn't fix the issue.
The error is still present when using setGlobalPrefix()

ValidationError: Using global EntityManager instance methods for context specific actions is disallowed. If you need to work with the global instance's identity map, use allowGlobalContext configuration option or fork() instead.

Yeah I am aware of that, still it doesnt change the fact that this is a bug in nest.


Can't use "go run github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen" to generate the code

When I use  go run github.com/oapi-codegen/oapi-codegen/v2/cmd/oapi-codegen， it report the error:

But when I use oapi-codegen（version: 2.4.1）, everything is ok.

Yep, this is related to https://github.com/oapi-codegen/oapi-codegen/issues/1702 - please update, or downgrade your version of kin-openapi :+1:


Shutdown Mongo sever properly

This commit ensures that MongoDB server is shutdown properly
before any call to start/restart it. This avoids the PebbleChangeError
exception that is raised when the Pebble attempts to SIGKILL MongoDB
and it still fails to shutdown.

Looks good, but needs tests?

I hope it is ok if I pick this up later (probably needs some integration tests since this requires a real workload). Created a ticket for it : https://github.com/canonical/mongodb-operator/issues/24 .

Merging to fix problem for @desrod


Replace extern with FOUNDATION_EXPORT

This is the standard way of defining an umbrella header. Just don't remove the Foundation import, again!

Thanks! :+1:


Fix max_ex_value constraint.

The constraint was not exclusive. This is now fixed.

While answering @raddevon's question about max_ex_value constraint I realized that the constraint in std is actually not exclusive (min_ex_value was fine though).

Ooops, forgot to bump catalog version after changing std library.


POC of template receiver and processor

Summary
This POC revisits the idea exposed in the https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/26312 to use a receiver to render templates as a mechanism to distribute reusable configurations. Templates are similar to OTEL collector configuration files, with placeholders for variables.
This POC includes the following components:

pkg/templates with helper code to work with templates in other components.
extension/filetemplateextension with an extension that can be used by other components to obtain templates from local disk.
processor/templateprocessor processor that is composed by instantiating processors from a template.
receiver/templatereceiver receiver that is composed by instantiating receivers and processors from a template.

Open questions:

Should we explicitly declare dependencies of each template?
Should we version templates? Would it depend on the source?

Purpose and use-cases of the new components
The main purpose of templates is to provide an abstraction to share configurations intended to observe specific applications and services.
Templates are interpreted by components created with this purpose. Two main components are implemented for that, a receiver and a processor. They can use extensions to discover templates.
These components are intended to be used with minimal configuration, so users can leverage templates without extensive knowledge of the OTEL collector. The minimal configuration users need to provide is one or more sources of templates, configured as extensions, the name of the templates and the parameters it needs.
The use of receiver as the main component to use templates will allow to leverage any other feature built for receivers, such as autodiscover features.
The main use case is the distribution of configurations for specific services, these configurations include receivers and processors, and pipelines to indicate how the receivers and processors have to be combined. A single template can include multiple pipelines, users can chose which ones to use.
Find below an example template, mostly copied from the one in https://github.com/open-telemetry/opentelemetry-collector/issues/8372.
receivers:
  prometheus:
    config:
      scrape_configs:
        - job_name: 'couchbase'
          scrape_interval: 5s
          static_configs:
            - targets: ${var:endpoints}
          basic_auth:
            username: ${var:username}
            password: ${var:password}
          metric_relabel_configs:
            # Include only a few key metrics
            - source_labels: [ __name__ ]
              regex: "(kv_ops)|\
                (kv_vb_curr_items)|\
                (kv_num_vbuckets)|\
                (kv_ep_cursor_memory_freed_bytes)|\
                (kv_total_memory_used_bytes)|\
                (kv_ep_num_value_ejects)|\
                (kv_ep_mem_high_wat)|\
                (kv_ep_mem_low_wat)|\
                (kv_ep_tmp_oom_errors)|\
                (kv_ep_oom_errors)"
              action: keep

processors:
  filter:
    # Filter out prometheus scraping meta-metrics.
    metrics:
      exclude:
        match_type: strict
        metric_names:
          - scrape_samples_post_metric_relabeling
          - scrape_series_added
          - scrape_duration_seconds
          - scrape_samples_scraped
          - up

  metricstransform:
    transforms:
      # Rename from prometheus metric name to OTel metric name.
      # We cannot do this with metric_relabel_configs, as the prometheus receiver does not
      # allow metric renames at this time.
      - include: kv_ops
        match_type: strict
        action: update
        new_name: "couchbase.bucket.operation.count"
      - include: kv_vb_curr_items
        match_type: strict
        action: update
        new_name: "couchbase.bucket.item.count"
      - include: kv_num_vbuckets
        match_type: strict
        action: update
        new_name: "couchbase.bucket.vbucket.count"
      - include: kv_ep_cursor_memory_freed_bytes
        match_type: strict
        action: update
        new_name: "couchbase.bucket.memory.usage.free"
      - include: kv_total_memory_used_bytes
        match_type: strict
        action: update
        new_name: "couchbase.bucket.memory.usage.used"
      - include: kv_ep_num_value_ejects
        match_type: strict
        action: update
        new_name: "couchbase.bucket.item.ejection.count"
      - include: kv_ep_mem_high_wat
        match_type: strict
        action: update
        new_name: "couchbase.bucket.memory.high_water_mark.limit"
      - include: kv_ep_mem_low_wat
        match_type: strict
        action: update
        new_name: "couchbase.bucket.memory.low_water_mark.limit"
      - include: kv_ep_tmp_oom_errors
        match_type: strict
        action: update
        new_name: "couchbase.bucket.error.oom.count.recoverable"
      - include: kv_ep_oom_errors
        match_type: strict
        action: update
        new_name: "couchbase.bucket.error.oom.count.unrecoverable"
      # Combine couchbase.bucket.error.oom.count.x and couchbase.bucket.memory.usage.x
      # metrics.
      #- include: '^couchbase\.bucket\.error\.oom\.count\.(?P<error_type>unrecoverable|recoverable)$$'
      #  match_type: regexp
      #  action: combine
      #  new_name: "couchbase.bucket.error.oom.count"
      - include: '^couchbase\.bucket\.memory\.usage\.(?P<state>free|used)$$'
        match_type: regexp
        action: combine
        new_name: "couchbase.bucket.memory.usage"
      # Aggregate "result" label on operation count to keep label sets consistent across the metric datapoints
      - include: 'couchbase.bucket.operation.count'
        match_type: strict
        action: update
        operations:
          - action: aggregate_labels
            label_set: ["bucket", "op"]
            aggregation_type: sum

  transform:
    metric_statements:
    - context: datapoint
      statements:
        - convert_gauge_to_sum("cumulative", true) where metric.name == "couchbase.bucket.operation.count"
        - set(metric.description, "Number of operations on the bucket.") where metric.name == "couchbase.bucket.operation.count"
        - set(metric.unit, "{operations}") where metric.name == "couchbase.bucket.operation.count"

        - convert_gauge_to_sum("cumulative", false) where metric.name == "couchbase.bucket.item.count"
        - set(metric.description, "Number of items that belong to the bucket.") where metric.name == "couchbase.bucket.item.count"
        - set(metric.unit, "{items}") where metric.name == "couchbase.bucket.item.count"

        - convert_gauge_to_sum("cumulative", false) where metric.name == "couchbase.bucket.vbucket.count"
        - set(metric.description, "Number of non-resident vBuckets.") where metric.name == "couchbase.bucket.vbucket.count"
        - set(metric.unit, "{vbuckets}") where metric.name == "couchbase.bucket.vbucket.count"

        - convert_gauge_to_sum("cumulative", false) where metric.name == "couchbase.bucket.memory.usage"
        - set(metric.description, "Usage of total memory available to the bucket.") where metric.name == "couchbase.bucket.memory.usage"
        - set(metric.unit, "By") where metric.name == "couchbase.bucket.memory.usage"

        - convert_gauge_to_sum("cumulative", true) where metric.name == "couchbase.bucket.item.ejection.count"
        - set(metric.description, "Number of item value ejections from memory to disk.") where metric.name == "couchbase.bucket.item.ejection.count"
        - set(metric.unit, "{ejections}") where metric.name == "couchbase.bucket.item.ejection.count"

        - convert_gauge_to_sum("cumulative", true) where metric.name == "couchbase.bucket.error.oom.count"
        - set(metric.description, "Number of out of memory errors.") where metric.name == "couchbase.bucket.error.oom.count"
        - set(metric.unit, "{errors}") where metric.name == "couchbase.bucket.error.oom.count"

        - set(metric.description, "The memory usage at which items will be ejected.") where metric.name == "couchbase.bucket.memory.high_water_mark.limit"
        - set(metric.unit, "By") where metric.name == "couchbase.bucket.memory.high_water_mark.limit"

        - set(metric.description, "The memory usage at which ejections will stop that were previously triggered by a high water mark breach.") where metric.name == "couchbase.bucket.memory.low_water_mark.limit"
        - set(metric.unit, "By") where metric.name == "couchbase.bucket.memory.low_water_mark.limit"

pipelines:
  metrics:
    receiver: prometheus
    processors:
      - filter
      - metricstransform
      - transform

Example configuration for the component
Using the template receiver:
extensions:
  file_templates: # <--- This extension is used to discover templates from a local directory.
    path: "./templates"

receivers:
  template/couchbase:
    name: "couchbase" # <--- This is the name of the template.
    parameters:
      endpoints: [localhost:8091]
      username: Administrator
      password: foobar

exporters:
  debug:
    verbosity: detailed

service:
  extensions: [file_templates]
  pipelines:
    metrics:
      receivers: [template/couchbase]
      exporters: [debug]

Using the template processor:
extensions:
  file_templates:
    path: "./templates"

receivers:
  prometheus/couchbase:
    config:
      scrape_configs:
        - job_name: 'couchbase'
          scrape_interval: 5s
          static_configs:
            - targets: [localhost:8091]

processors:
  template/couchbase:
    name: "couchbase"

exporters:
  debug:
    verbosity: detailed

service:
  extensions: [file_templates]
  pipelines:
    metrics:
      receivers: [prometheus/couchbase]
      processors: [template/couchbase]
      exporters: [debug]

Telemetry data types supported
These are generic components that support any data type provided by other components.
Is this a vendor-specific component?
It is not vendor-specific.
Code owners
Elastic?
Sponsor
Elastic?
Additional context
This proposal is a follow-up of https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/26312 and https://github.com/open-telemetry/opentelemetry-collector/issues/8372.

This looks really promising! I think having the templates as a receiver solves two main issues compared to the  "Converter" approach:

Receiver creator: A template receiver could be included in a receivercreator configuration.
Forward connector: The template receiver does not rely on the collector having the "forward" connector in its pipeline.


SRE-35 haskell overhaul

This is the overhaul of Haskell for cardano-ledger along the lines of cardano-node PR #507.

@craigem Is this ready for review?


Chrome and Firefox - Reopen Closed Tab - New Incognito Window

Please can you add the shortcuts for

Reopen Closed Tab
New Incognito Window

For the Chrome and Firefox browsers ? That hotkeys are populars.
Thanks

What key bind do you want to use?

Reopen Closed Tab : ctrl+shift+T
New Incognito Window : ctrl+shift+N
Thanks.

I've added these settings in v10.21.5.
Please enable them.

(You can find firefox version by searching "PC Style Firefox".)

Thanks for the answer Tekezo!
Only a few details:

"New Incognito Window" is a different action of "New Window" you can see for yourself in the browser -> File (menu)

"Reopen Closed Tab" is a different action of "New Tab".


Moving the index.js file from the reducers folder to the store folder causes a 404

Node version: 6.2.2
npm version: 3.9.5
Operating system: OS X El Capitan
Command line used: terminal
Steps to reproduce: Moving the index.js file from the reducers folder to the store folder causes a 404 when getting localhost:3000. This is of course after changing all the imports to match the new structure. No errors appear in the console either (lint or otherwise)

To clarify, index.js belongs in the reducers folder because it's the root reducer. That said, since this isn't an issue with Slingshot working out of the box, it's a better question for StackOverflow.


Add test cases for ViewModel

It's currently not needed, since our ViewModel doesn't have any logic to test. We will write tests when our ViewModel starts growing and becomes complex


[feature] Declarative Command System for Kotlin and Java Kelp Apps

Is your feature request related to a problem? Please describe.
Currently for complex commands you need to create lots of classes. My Command System uses a Brigadier like Builder.
Describe the solution you'd like
I can implement the logic for my system myself in Kelp and create a pull request for it.
Additional context
Here's the link to my system: https://github.com/DSeeLP/Kommon/tree/development/command

That's a great idea. I have just looked a bit through Brigadier and KommonCommand and it's both really intuitive to understand. If you can, I would appreciate a pull request with the new command system.
Will it also be able to manipulate existing commands that have not created by the current plugin like it is in Brigadier?

Resolved in #60


Experimental document block

I'm the maintainer of react-native-ART-doc, how can I contribute this part to API list?

Right now, the docs only list components and APIs that ship with core React Native.
At some point in the future, it might make sense to include docs for components that are not part of core - especially if we split out frequently used components into their own modules - but at this point in time I recommend hosting the docs in your library's own GitHub repo.


"OSError: [Errno 121] Remote I/O error" on subsequent runs

I'm trying to run the code from Adafruit documentation as well as a slight modification below (to try and deinit the I2C /shrug) on a Raspberry Pi.
import busio
import board
import adafruit_shtc3

with busio.I2C(board.SCL, board.SDA) as i2c:
    sht = adafruit_shtc3.SHTC3(i2c)
    print("Temperature: %0.1f C Humidity: %0.1f %%rH" % sht.measurements)

The first time I run this after the sensor is connected it works fine:
$ ./shtc3.py
Temperature: 28.1 C Humidity: 47.0 %rH

However all subsequent runs throw OSError: [Errno 121] Remote I/O error until the sensor is disconnected and reconnected.
 $ ./shtc3.py
Traceback (most recent call last):
  File "./shtc3.py", line 12, in <module>
    sht = adafruit_shtc3.SHTC3(i2c)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_shtc3.py", line 93, in __init__
    self.reset()
  File "/usr/local/lib/python3.7/dist-packages/adafruit_shtc3.py", line 120, in reset
    self._write_command(_SHTC3_SOFTRESET)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_shtc3.py", line 103, in _write_command
    i2c.write(self._buffer, start=0, end=2)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_bus_device/i2c_device.py", line 102, in write
    self.i2c.writeto(self.device_address, buf, start=start, end=end)
  File "/usr/local/lib/python3.7/dist-packages/busio.py", line 115, in writeto
    return self._i2c.writeto(address, memoryview(buffer)[start:end], stop=stop)
  File "/usr/local/lib/python3.7/dist-packages/adafruit_blinka/microcontroller/generic_linux/i2c.py", line 49, in writeto
    self._i2c_bus.write_bytes(address, buffer[start:end])
  File "/usr/local/lib/python3.7/dist-packages/Adafruit_PureIO/smbus.py", line 308, in write_bytes
    self._device.write(buf)
OSError: [Errno 121] Remote I/O error

This seems like a similar issue for a different sensor: https://github.com/adafruit/Adafruit_CircuitPython_MLX90393/issues/8

In case this is helpful, i2cdetect output before and after running the script is the same.
$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: 70 -- -- -- -- -- -- --

@aurimasv Unfortunately the SHTC3 will not reconnect via I2C after an initial connection unless it is power cycled by disconnecting and reconnecting power.
I've spend quite a while looking for solutions to no avail, so I've updated the guide documentation to mention this behavior. I'm going to close this ticket as a known issue as a 'wontfix' but really it means "cantfix".
Should one of us find a solution, we'll gladly re-open or at least mention the fix here.


[AppTemplate][AdoptionTool]

Docs Build status updates of commit 69aeb6d:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

msteams-platform/samples/app-templates.md
:white_check_mark:Succeeded
View

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel

This PR should close PR #3042


pippo.ro is not available

Hi,
I'm sure you must have noticed pippo.ro is not what it say it is. Anyway to get it back?
B/w, thanks a bunch for this really good framework.
Thanks
Aymer

I can see it back up and running. Thanks!

Thank you for reporting the problem.
It's a pleasure for me to see that some people consider this web framework valuable.


Instrument the Cardano Haskell node to start at a specific point.

Either by:

Forcing a rollback to specifying point by deleting chunks from the immutable db.
Bootstrapping from a Mithril snapshot.

Possible, look at the work done as part of Mithril as there might already be tools covering that.

FWIW I have worked a while ago on the part of ouroboros-consensus code that manipulates the DB, writing a tool to dump an arbitrary block in JSON format. I could revive that branch and implement that feature on top of this tool, or adapting/enhancing one of the existing tools (eg. db-analyzer?)

That would be quite handy for benchmarks and tests moving forward. As we will want to compare precise execution paths on both Haskell's cardano-node & Amaru.
Do you have enough information from this thin ticket or shall we perhaps bring that as a topic on the agenda of a next Amaru design planning session?

Closed and content integrated in the milestone: Client Node - Dolos integration and architecture choices


create a bigger size volume from existing data source

if the newly requested volume is cloned from the existing snapshot, we need to check the request volume size is greater then the snapshot/parent-volume or not, if it is greater than the snapshot we need to
resize the requested volume to a new size.
Signed-off-by: Madhu Rajanna<EMAIL_ADDRESS>Logs after resizing the volume info

parent vol info

rbd image 'pvc-21c9a16f-456c-11e9-9814-525400dd375f':
	size 1 GiB in 256 objects
	order 22 (4 MiB objects)
	id: 8eb0643c9869
	block_name_prefix: rbd_data.8eb0643c9869
	format: 2
	features: layering
	op_features:
	flags:
	create_timestamp: Wed Mar 13 08:43:53 2019

resized volume info

rbd image 'pvc-63f2f902-456d-11e9-9814-525400dd375f':
	size 10 GiB in 2560 objects
	order 22 (4 MiB objects)
	id: 8f0a2ae8944a
	block_name_prefix: rbd_data.8f0a2ae8944a
	format: 2
	features: layering
	op_features:
	flags:
	create_timestamp: Wed Mar 13 08:52:54 2019
	parent: rbd/pvc-21c9a16f-456c-11e9-9814-525400dd375f@csi-rbd-pvc-21c9a16f-456c-11e9-9814-525400dd375f-snap-289d7f24-456c-11e9-a34f-0242ac11000e
	overlap: 1 GiB

@rootfs @gman0 PTAL

Fixes: #257

cc @j-griffith

imo, the snap restore size is totally up to the storage backend, external provisioner does not need to revalidate the size. @xing-yang any input? thanks

@j-griffith can you please review this PR?

imo, the snap restore size is totally up to the storage backend, external provisioner does not need to revalidate the size. @xing-yang any input? thanks

@xing-yang would really happy to get your input on this one.

https://github.com/ceph/ceph-csi/pull/258#issuecomment-472439666
@Madhu-1 In the provisioner check, we did say that the CSI plugin needs to handle expansion if volume size is bigger than snapshot size.  So it depends on whether the plugin supports resize or not.
https://github.com/kubernetes-csi/external-provisioner/blob/master/pkg/controller/controller.go#L630
@gnufied can you take a look of the resize part?

#258 (comment)
@Madhu-1 In the provisioner check, we did say that the CSI plugin needs to handle expansion if volume size is bigger than snapshot size. So it depends on whether the plugin supports resize or not.
https://github.com/kubernetes-csi/external-provisioner/blob/master/pkg/controller/controller.go#L630
@gnufied can you take a look of the resize part?

I'd like to see what @gunfied says on this, but my opinion is that we should create the volume and then do the expansion for the user.  It looks like we can do the expansion so we should just implement it that way.

@j-griffith Is it enough to resize RBD volume? Does the volume's file system is also expanded to accommodate new size or that must happen separately?

@gnufied this is Volume resize of a cloned volume from the snapshot which is not mounted yet, yeah as this is just a PVC creation is should be enough I think
@j-griffith any comments?

Let me summarize this effort with a better summary:
First of all, this PR may be better titled to "create a bigger size volume from existing data source' instead of 'resize rbd volume'.
What the code do here is this
*) Clone/ create a volume from an existing source  with bigger size and we reach there in 2 steps:

Create a clone volume from existing snapshot.
Increase the size of the volume to the requested size.

Hope this clear some dust. :)  @xing-yang @gnufied @j-griffith
As a second thing, the question comes in, ie do we need "fs" expansion while we  expand the volume?
My understanding is that, If the volume is mounted and used in pod, the expansion has to be performed on FS level. This need to be considered here @Madhu-1 .
@Madhu-1 , from code review pov, the check of the size can be outside snapshot function and it can be performed for any data source ie volume or snapshot and rest of the code can fall in.

@humblec updated PR PTAL

@Madhu-1 can you correct the Travis ?

So, who does file system resizing in this case? The file system resizing still needs to happen and without that, expanded space won't be available to pod/workload. I don't see it being addressed.

So, who does file system resizing in this case? The file system resizing still needs to happen and without that, expanded space won't be available to pod/workload. I don't see it being addressed.

@gnufied there are 2 choices, either we can address both data source (snapshot and volume ) here or address one which is snapshot data source. You are correct that we need fs expansion, but if we are only addressing snapshot data source via this PR, we are still good without fs expansion as snapsource is floating around without being attached to the pod.

@humblec okay but what is the point of expanding the volume here when it won't be expanded when used by a pod? I think, we may have to handle this when a snapshot is restored to a larger volume. This can be done by setting pvc.Status.Capacity to snapshot size(smaller value) and pvc.Spec.Capacity to user requested size(larger value) and pv.Spec.Capacity to user requested value assuming - ceph returns the volume after expansion.
Above condition will automatically trigger expansion on the node. cc @xing-yang

closing this one as its already addressed in https://github.com/ceph/ceph-csi/pull/1244


Modifying the Sphinx dependency version

After a discussion with @jorgepiloto, the way to fix it seems to impose Sphinx==5.3.0 and ansys-sphinx-theme==0.8.2.

What was the issue here?

The new ansys-sphinx-theme version is not yet compatible with Sphinx 6>=. So, updating the ansys-sphinx-theme implies going back to 5.3.0. There are incompatibility issues with the pydata-theme we are extending on our own theme.

I see... Thank you Robert!

FYI - once we are compatible with Sphinx 6>= we will let people now =)