Update Makefile

Add command to Makefile to see if the usr/local/bin directory exists before installation. If it does not, it will be created.

This is a big help – thank you! Are we able to make that directory, ensuring it has the correct permissions? If not, we might be better off printing an error and exiting – "/usr/local/bin could not be found – please create it, then move .build/release/IgniteCLI to /usr/local/bin/ignite manually", for example.

I tested on my mac and MacBook Air and was able to create the bin directory as long as sudo was used. I also tested and created different folders in the same spot and was able to successfully install ignite using the script.

And if sudo isn't used? If we're going to create /usr/local/bin, we might want to use whoami first, for example, to check whether the user has permission to make it or not.

I can run 'whoami' and it will tell me who is logged in but doesn't tell me if I have permissions to the folders as needed. I found an example where you can run 'sudo whoami' but that requires the user to put in their password. Not ideal in my opinion but could work. That would return if they have root or not. If they do, then they could create the /usr/local/bin directory without sudo being needed. Otherwise, it would just default to a message that says for them to create it manually and move .build/release/IgniteCLI to /usr/local/bin/ignite per your original comment.
Thoughts?
I very much appreciate the conversation and education with this. I am really enjoying trying to figure this out. However, I have a side question...
Where can I best learn what commands are available to utilize and how to do this scripting? I wouldn't have known 'whoami' but after you mentioned it, I was able to Google it and see some scripts. I looked through the makefile (didn't know these existed until this project) and I am still trying to figure out the meaning of the @(install line.
I have found other articles but many refer to python or ubuntu or other languages that I have never learned. I want to learn, just need to know where to start.
Thank you for all your help and comments.

What I was thinking is that if whoami returns "root" then we're safe to create the directory; I don't believe sudo would be required for that. However, on reflection I'm wondering whether we should 1) check if the directory exists, 2) if it doesn't, attempt to create it, and 3) if creating it fails, bail out and tell the user they are missing a /usr/local/bin directory. Something like https://stackoverflow.com/a/16633130 ought to help.
As to where you can learn more about the various command-line tools, I have a book called Beyond Code that covers it as 1/4 of the book 🙂   I learned my skills through a much older book called Unix Power Tools.

Updated the makefile. If the user can create the /usr/local/bin directory, then it will be created and the installation will complete. If the directory can't be created, the installation will be stopped with an error 126 (permissions).
Thank you so much for the reading information. I am a HWS+ subscriber so I went straight to Beyond Code. I am also going to check out the Unix Power Tools book you mention. With all of this, I am starting to understand a little bit more of what is happening.

This looks perfect to me – thank you!


When an invalid pipeline is specified, 404 needs to be returned

But instead 500 with message No db service found is returned.

Invalid resources now return 404.


Fix onchain logic

Fix logic where it bails (though traceError ) due to invalid input. If invalid input's received, the validator should always validate to False instead of bailing with error. Also trace calls aren't supposed to be used in production environment. They are only for testing purpose.
There's also format changes that's a result of stylish-haskell. Please let me know if you are happy with the formatter, I can revert the format changes. That said, I see this as overall an improvement to the format.

Will reopen PR.


Duplicated notifications

I get the same notifications twice whenever I fire an event from BE.
I'm using SSR mode
I managed to make it work by deleting one part of the code from the file<EMAIL_ADDRESS>messaging.onBackgroundMessage((payload) => {
      console.log("[firebase-messaging-sw.js] Received background message ", payload);

      self.registration.showNotification(
      payload.notification.title,
      payload.notification);
  });

I have no idea why, but it works normally without that line.

Apparently, background notifications are automatically shown. Thanks for the issue.


"No more Flycheck errors" when highlighted errors are visible

Sometimes intero buffers enter a bad state, where errors/warnings are shown with red squiggly lines but M-g n gives "No more Flycheck errors", also shown in *Messages* as:
user-error: No more Flycheck errors

And when a buffer enters that state I don't know how to fix it. I've been having this for a while without insights as to its cause.

I think that's because flycheck doesn't circle round and start from the beginning again. Your errors are probably above your cursor?

That's annoying but it's not that, sorry for the ambiguous report. Errors
are after the cursor.
On Sep 27, 2016 09:57, "Chris Done"<EMAIL_ADDRESS>wrote:

I think that's because flycheck doesn't circle round and start from the
beginning again. Your errors are probably above your cursor?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/commercialhaskell/intero/issues/268#issuecomment-249793088,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AARsqBmEDXm-Fu77x2fiFqQqJPbvkxshks5quMxfgaJpZM4KBE1q
.

Just happened again, but while M-g n doesn't work, C-c ! n works fine.
The first is bound to (next-error &optional ARG RESET), the second to (flycheck-next-error &optional N RESET). Should I file a ticket with flycheck?
FWIW: I also seem to have noticed this state is triggered when trying to do a jump right after a change that introduces warnings.
Some other times, doing a change means that new warnings are shown briefly and then all warnings disappear, but that is fixed by reloading the file (with M-x revert-buffer).

Working around this with https://gist.github.com/Blaisorblade/c7349438b06e7b1e034db775408ac4cb for now. I'm an Elisp noob.

Just happened again, but while M-g n doesn't work, C-c ! n works fine.

Paging @lunaryorn on this—this happened with flycheck integration normally enabled (that is, with flycheck-standard-error-navigation set to t). That is, M-g n gives "No more Flycheck errors" when C-c ! n from the same point jumps to the next error. How can this happen?


chore: exmaple for add sketch clean command

不合并，只是个示例

Codecov Report

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

@@           Coverage Diff           @@
##           master     #148   +/-   ##
=======================================
  Coverage   26.17%   26.17%
=======================================
  Files         106      106
  Lines        2189     2189
  Branches      592      592
=======================================
  Hits          573      573
  Misses       1305     1305
  Partials      311      311

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 7682211...b5f345c. Read the comment docs.


[SPARK-35928][BUILD] Upgrade ASM to 9.1

What changes were proposed in this pull request?
This PR aims to upgrade ASM to 9.1
Why are the changes needed?
The latest xbean-asm9-shaded is built with ASM 9.1.

https://mvnrepository.com/artifact/org.apache.xbean/xbean-asm9-shaded/4.20
https://github.com/apache/geronimo-xbean/blob/5e0e3c0c6463f5b1e29185bdd9c2366c38371aa0/pom.xml#L67

Does this PR introduce any user-facing change?
No.
How was this patch tested?
Pass the CIs.

Could you review this please, @srowen and @viirya ?

Thank you, @viirya .
Merged to master.

I'm probably missing something - we don't have / need Jenkins tests, just the Github Actions? I just couldn't see test results here, or for the Chill change.

Seems Jenkins was not working before. (it works now)
@dongjoon-hyun @srowen I think we can watch Jenkins dashboard closely to make sure this pass Jenkins.

Thank you for review, @srowen . Yes, during the weekend, Jenkins was down.
For GitHub Action result, you can see the following at the last commit.

https://github.com/dongjoon-hyun/spark/actions/runs/981869239

For the Jenkins result, I'll monitor as @viirya suggested.

Thank you @dongjoon-hyun.

Here is some update. Although the Jenkins status is super noisy due to the timeout, we got the green light for the following at least.

Maven with Hadoop 2.7/Java11: https://amplab.cs.berkeley.edu/jenkins/view/Spark QA Test (Dashboard)/job/spark-master-test-maven-hadoop-2.7-jdk-11/
SBT with Hadoop 3.2: https://amplab.cs.berkeley.edu/jenkins/view/Spark QA Test (Dashboard)/job/spark-master-test-sbt-hadoop-3.2/

I'll update here when I collect more info.


Feat: Improving Footer UI

Describe the feature
Hi @Suchitra-Sahoo , the footer is looking so empty because of much empty space between logos and the arrow. So adding a website title/logo in between would make it a complete footer.
Add ScreenShots

I would like to add the feature and improve the footer interface. I ensure that I will make it responsive on all devices. Kindly assign me this task I want to contribute to this project under GSSoC'24.
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

Kindly assign this issue to me i can add theme change section in footer and back to main menu button as well as social media handle that can contribute in seeking more number of attention of people

Please assign this task to me under GSSOC'24

I would love the opportunity to contribute and work on this project.
Could you please assign the issue to me? I’m eager to dive in and make a meaningful impact. Thank you for considering my request!


Upgradeable proxy

@NouDaimon Let's remove the Base contract layer, and make all contracts abstract.
Files needed:

UpgradeableProxy.sol
UpgradeableProxyStorage.sol
UpgradeableProxyOwnable.sol
UpgradeableProxyMock.sol
UpgradeableProxyOwnableMock.sol

UpgradeableProxyOwnable should inherit from OwnableInternal, but should not set owner at any point.  For this reason, it should be abstract.


[Android, core] No way to get screen size before InitWindow or at least InitWindow with a window that matches the screen size

I think the title described the problem quite well.
I want to InitWindow with the screen size on Android (width: 0, height: 0) does not work. I can't get it through EGL, raylib forces EGL upon itself, and same with APP_CMD_INIT_WINDOW event.

To elaborate InitWindow(0, 0, ...) works for the width (Or so it seems like it), but the height is not correct, maybe it has something to do with the rounded corners of the screen?

The problem is, from what I've gathered online, the only 2 ways to get the display size is from the APP_CMD_INIT_WINDOW event and from when you initalize EGL. If there are other ways let me know!
Also, it seems to me you completely ignored the fact that InitWindow(0, 0, ...) by design creates a window at the size of the display, but it doesn't seem to work correctly, I'm pretty sure it has to do with the rounded corners of the screen, since it's known for causing lots of issues.

@DeexCoding Display size is queried at APP_CMD_INIT_WINDOW, called at InitWindow() when CORE.Android.app->window is already available, it's not possible to query display size before... In any case, I modified GetMonitorWidth() and GetMonitorHeight() to try to query for display size before InitWindow(). Please, let me know if it works.
The calls used are the Android NDK provided ones so if the results returned are not the expected ones, it's a NDK/Platform related issue.
Also note, every mobile device and Android version could behave completely different on display size query, I'm afraid this functionality is very platform-dependant, really difficult to find a good solution for all platforms.

Alright, I found the issue, it wasn't raylib after all.
If you go into Settings -> Display -> Full screen apps, you can select your app and enable fullscreen mode for it. Other apps seem to force this somehow, but there are a few exceptions that just have it enabled by default. If I enable this by hand everything-display-size works.
I still have no idea how to force it/enable it by default. (please help) (Maybe it is something like full-screen immersive mode? I can not find it)
Querying display size before InitWindow does not work. But the functionality of querying display size with GetMonitorWidth and GetMonitorHeight was still a great addition that came out of this.


Add license/copyright header for each files

Currently, there is no license/copyright header for widl-nan codes. We need add them in.

I just checked the files and found out that this one can be closed directly.


AVD needs to enable the PIM protocols for SVIs on the single leaf

Issue Summary
In AVD model for EVPN multicast, "If switch is standalone or A-A MH, enables "ip igmp" on the SVI." The mcast who has active source on the vlan wouldn't work properly, until manually enabling PIM protocol by "pim ipv4 sparse-mode". Below is the detailed explanation.
Currently AVD model has this Mcast behavior difference between MLAG and Single Leaf switch? https://avd.sh/en/stable/roles/eos_designs/docs/input-variables.html#network-services
Enable L3 Multicast for all SVIs and l3vlans within Tenant.
...
# - When enabled on an SVI:
#      - If switch is part of an MLAG pair, enables "pim ipv4 sparse-mode" on the SVI.
#      - If switch is standalone or A-A MH, enables "ip igmp" on the SVI.
#      - If "ip address virtual" is configured, enables "pim ipv4 local-interface" and uses the diagnostic Loopback defined in the VRF
# - Requires evpn_multicast to also be set to true.
One of the customers said the EVPN_L3_Multicast not working on the single Leaf until he has to manually enable the "pim ipv4 sparse-mode" on the AVD generated SVIs.
Per the detailed troubleshooting notes in the TAC case #575699, https://tac.aristanetworks.com/case/case_reader/575699,
" We observed interface vlan143 had "ip igmp" configured. We changed the config to "pim ipv4 sparse-mode" and observed the mroute details were populated successfully and the issues were observed to be resolved.
ip igmp is generally used when we need to only accept the flooded traffic and pim-sparse mode is used when we need to move multicast traffic across L3 networks."
We need to fix the AVD behavior to enable the PIM under SVIs on the single leaf scenario just like what it does for MLAG pair.
Thanks,
Xianghui
Which component(s) of AVD impacted
eos_cli_config_gen
How do you run AVD ?
Ansible CLI (with virtual-env or native python)
Steps to reproduce
No response
Relevant log output
No response
Contributing Guide

[X] I agree to follow this project's Code of Conduct

Had a discussion with @Devroy Peterson, who has clarified and confirmed the right behavior for AVD to generate the different cfg for the single vtep vs the mlag vtep. He will input his notes in the TAC case #575699.
The issue will be closed at this point.


Add JustList: {sws}

Sws project is an easy implementation of web pages on hosts that the user can easily have a web page with a few clicks.
This is the strategy in the TRC-20 network.

Sorry, your issue will be closed as you did not submit your information in the correct format.


refactor(app,app-shell,app-shell-odd): support updating both ot2 and flex

The current app stack supports only one kind of update file and path. In internal-releases, we reuse that code for flex by pointing it at flex update media and flex robots... which just means the internal-release app can't update OT-2s with the automatically-distributed releases.
This PR changes that by

Downloading both ot-2 and flex update files, separately
Keeping them around separately (in the app data dir)
Keeping track of them in redux separately

Including changing selectors to require specifying a robot name so we can get the right kind of update

Pulling what kind of robot is getting updated from state when you start to update, and using the code paths previously only taken by user file robot updates (with the browse button) for everything

Note: This PR changes the download location for robot updates to be targeted on new infrastructure for flex launch. Specifically,

internal-release robot software at ot3-development.builds.opentrons.com (sorry about the url, it's old). Flex builds can be seen here: https://ot3-development.builds.opentrons.com/ot3-oe/releases.json and OT-2 builds can be seen here: https://ot3-development.builds.opentrons.com/ot2-br/releases.json
release robot software at builds.opentrons.com. This infra isn't up yet, but we can still merge this if we want

Also, I renamed all the redux and app-shell stuff from buildroot to robot-update. Sorry. It's contained in a single commit that you can skip when reviewing. The view layer is all the same still.
Review Requests

I'm not a very frequent typescript dev so please point out stuff that I'm doing wrong
Pay particularly close attention to the epics in app/src/redux/robot-update and see if I'm doing things write; in general, as with a lot of our old react/redux code, the behavior of the actual update (as separate from displaying the right screens and such) is all driven via redux so this is pretty important
Like I mentioned above, one thing I did here is rename all the redux and app-shell stuff from buildroot to robot-update, which touches Like A Billion files. However, I did keep it in one commit, so browse the pr commit by commit and you'll be able to skip it.

Testing
This has to be tested... a lot. And I haven't, which is why this just a draft. The testing looks like this:

[x] Make sure we automatically download both ot-2 and flex updates from the internet on desktop internal-release from internal-release
[x] Ditto ditto ditto release
[x] Make sure we automatically download flex updates on ODD internal release
[x] Ditto ditto ditto release
[x] Make sure we select the right files in redux on the desktop for flex
[x] Ditto ditto ditto ot-2
~[ ] Ditto ditto ditto balena (?) We can maybe drop this~
[x] Once all that stuff is good go through the upgrade/downgrade/reinstall logic

Other notes

just synced irl:
for the ot-3 project it looks like the correct artifacts get downloaded, but for the robot-stack things don't work because the release infra isn't up yet. we're gonna wait to merge till the release infra for the robot stack is up

i didn't get to test file uploads on the flex but i think i went through everything else and it... works? wow.

Ye of little faith!


Targets should inherit "errorMatch" from default target

I have several targets with different build configurations. For each one I need to copy the "errorMatch" property in order for it to take effect. Would be great if they could fallback to the default one.

The different commands are not really connected. The fact that one can be specified on the top level, and others in the targets subsection serves only one purpose: If you only want one target it should be easy to do so. There is no relation between targets and I want to keep it that way.
This was also discussed in detail in #89 (where the topic was chained targets).
Thanks for the suggestion though.


How to avoid WHERE geom IS NOT NULL clause in pg function?

Why do we have WHERE geom IS NOT NULL clause in the following pg function which I copied from here?
CREATE OR REPLACE
    FUNCTION function_zxy_query(z integer, x integer, y integer)
    RETURNS bytea AS $$
DECLARE
  mvt bytea;
BEGIN
  SELECT INTO mvt ST_AsMVT(tile, 'function_zxy_query', 4096, 'geom') FROM (
    SELECT
      ST_AsMVTGeom(
          ST_Transform(ST_CurveToLine(geom), 3857),
          ST_TileEnvelope(z, x, y),
          4096, 64, true) AS geom
    FROM table_source
    WHERE geom && ST_Transform(ST_TileEnvelope(z, x, y), 4326)
  ) as tile WHERE geom IS NOT NULL;

  RETURN mvt;
END
$$ LANGUAGE plpgsql IMMUTABLE STRICT PARALLEL SAFE;

Although no row in my postgis table has a NULL geom cell, I'm getting a lot of NULL values (most likely the reason why whoever wrote the above function added this where clause).
My Question is why/how can I have a NULL geom coming out of ST_AsMVTGeom()? What should I do on my db end to avoid geoms getting NULL during ST_AsMVTGeom() step?

my guess is that you have polygons or polylines (but not points) - so when ST_AsMVTGeom converts it to a given tile, the geometry might become so small that it disappears for a given zoom level - thus NULL.  In theory, ST_AsMVT should remove any such rows from the result - or else it simply wouldn't be a valid MVT (each MVT feature must have some geometry)

That makes total sense to me; and yes, there are a lot of very small polygons and polylines. Also, I didn't notice this behavior when tested against point features.
So, it all lines up; although will do further tests. Closing the issue for now. Thanks a lot.


[BUG] Failure to create a volume on a retry since v1.1.1

Describe the bug
We started upgrading our production clusters from v1.1.0 to v1.1.1 and found several issues. The root issue is timeouts (causing even a detach to last for tens of minutes) on CSI operations while and after undergoing the engine upgrades. We can't pin the cause of this yet, but the timeouts uncovered another easily traceable issue.
When creating a new volume and the first attempt fails due to a timeout, the second attempt (as an automatic retry) fails in the CSI provisioner with the following error:
E0524 17:29:20.796731       1 controller.go:939] error syncing claim "63b55846-8795-41f6-8cbf-986a7a402ccf": failed to provision volume with StorageClass "longhorn-db": rpc error: code = AlreadyExists desc = CreateVolume: cannot change volume size from 109051904 to 107374183

It leads to a volume never reporting a successful provisioning even though it was created in Longhorn.
We managed to trace the logic and it happens due to volume size rounding in the CreateVolume function that never gets persisted to the original volume spec. So when a retry happens it finds the created volume through the LH API, but fails validation as the requested size differs (not rounded).
This should be easy to fix by rounding the size before trying to find it in LH.
Validation check:
https://github.com/longhorn/longhorn-manager/blob/ac065a8deb96193ffec142bcc7e7345615b57b8d/csi/controller_server.go#L115-L119
Volume size rounding:
https://github.com/longhorn/longhorn-manager/blob/ac065a8deb96193ffec142bcc7e7345615b57b8d/csi/controller_server.go#L192-L193
To Reproduce
Steps to reproduce the behavior:

Create a new PV(C) with requested size that's not a multiple of 2*1024*1024 (e.g. 107374183)
Make a first LH volume creation request fail somehow (in our case timeouts)
See the reported error that never goes away

Expected behavior
The CSI operations should be retried with idempotency.
Log
W0524 17:29:20.796712       1 controller.go:916] Retrying syncing claim "63b55846-8795-41f6-8cbf-986a7a402ccf", failure 7                                                                                │
│ E0524 17:29:20.796731       1 controller.go:939] error syncing claim "63b55846-8795-41f6-8cbf-986a7a402ccf": failed to provision volume with StorageClass "longhorn-db": rpc error: code = AlreadyExists desc = CreateVolume: cannot change volume size from 109051904 to 107374183                                          │
│ I0524 17:29:20.796751       1 event.go:281] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"test-lh", UID:"63b55846-8795-41f6-8cbf-986a7a402ccf", APIVersion:"v1", ResourceVersion:"303698001", FieldPath:""}): type: 'Warning' reason: 'ProvisioningFailed' failed to provision volume wi │
│ I0524 17:31:28.799565       1 controller.go:562] CreateVolumeRequest {Name:pvc-63b55846-8795-41f6-8cbf-986a7a402ccf CapacityRange:required_bytes:107374183  VolumeCapabilities:[mount:<fs_type:"ext4" > access_mode:<mode:SINGLE_NODE_WRITER > ] Parameters:map[numberOfReplicas:3 recurringJobs:[{"cron":"10 */12 * * *","n │
│ I0524 17:31:28.799649       1 event.go:281] Event(v1.ObjectReference{Kind:"PersistentVolumeClaim", Namespace:"default", Name:"test-lh", UID:"63b55846-8795-41f6-8cbf-986a7a402ccf", APIVersion:"v1", ResourceVersion:"303698001", FieldPath:""}): type: 'Normal' reason: 'Provisioning' External provisioner is provisioning │
│ I0524 17:31:28.799632       1 connection.go:183] GRPC request: {"capacity_range":{"required_bytes":107374183},"name":"pvc-63b55846-8795-41f6-8cbf-986a7a402ccf","parameters":{"numberOfReplicas":"3","recurringJobs":"[{\"cron\":\"10 */12 * * *\",\"name\":\"backup\",\"retain\":2,\"task\":\"backup\"}]","staleReplicaTime │
│ I0524 17:31:28.808656       1 controller.go:1051] Final error received, removing PVC 63b55846-8795-41f6-8cbf-986a7a402ccf from claims in progress

Environment:

Longhorn version: 1.1.1
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): Rancher App
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: EKS 1.17

Number of management node in the cluster: unknown
Number of worker node in the cluster: 25

Node config

OS type and version: EKS-optimized Amazon Linux 2
CPU per node: varies
Memory per node: varies
Disk type(e.g. SSD/NVMe): NVMe
Network bandwidth between the nodes: varies

Underlying Infrastructure (e.g. on AWS/GCE, EKS/GKE, VMWare/KVM, Baremetal): AWS
Number of Longhorn volumes in the cluster: 400+

Additional context
Although it's an issue in itself, this wouldn't be triggered without the timeouts, which are causing us significant issues (successfully getting a new PVC attached can take an hour) while upgrading the engines on production. This seems to come out of the scale as we couldn't reproduce it on a much smaller scale staging clusters. It doesn't seem to be related to the available resources as no OOM, throttling, iowaiting happens. The issue seems to temporarily resolve after rolling the longhorn-manager DaemonSet in the cluster. It even persists after stopping the engine upgrade. After the upgrade is complete it seems to work fine.
We'll try to reproduce this in an isolated environment and report findings in a separate issue/Slack before upgrading the rest of our clusters.

@excieve Thanks for reporting. We are working on a fix and trying to figure out a workaround if possible. The fix will be backported into v1.1.2 as well.

@yasker The workaround for the size mismatch so far is to specify the volume size request that is a multiple of 2*1024*1024 in bytes.
As for the general slow down during the automatic engine upgrade that originally caused it — it seems regularly restarting longhorn-manager pods during the process does it.

@excieve Regularly restarting the longhorn-manager pods? I don't think we've seen that. Do you have a support bundle you can share? (though the mgr will be started so it's possible there won't be much left we can see).

@excieve
I am looking into this issue. Could you provide us a support bundle for investigation?

@excieve
Regrading to the timeout during automatic engine upgrade process, what was the value you set for the setting Concurrent Automatic Engine Upgrade Per Node Limit?
I was able to produce the slow attaching/detaching behavior with a big a value for the setting Concurrent Automatic Engine Upgrade Per Node Limit (e.g., 20). However, if the value is small (e.g., 2 or 3) I don't see the problem. See below for more details.
Reproduce steps:

install Longhorn v1.1.0 in a 3 nodes cluster
Create 25 volumes. (I use the Python client to quickly create 25 volumes )
attach 20 volumes (vol1 to vol20) to node-1
Upgrade Longhorn to v1.1.1
Set Concurrent Automatic Engine Upgrade Per Node Limit to 20
Wait for the auto engine upgrade process to start
Attach the vol21 to node-1
I observer that it takes 96 seconds for vol21 to finish attaching
If I set Concurrent Automatic Engine Upgrade Per Node Limit to 2 in the step 5, I observer that it only takes 10s for the vol21 to finish attaching

The above behavior makes sense because when Concurrent Automatic Engine Upgrade Per Node Limit is set to a high value, Longhorn try to upgrade many volumes at the same time and it consume resources on the nodes. See more at here
If you didn't set a big value for the setting Concurrent Automatic Engine Upgrade Per Node Limit, then it could be something else. I have scanned over the automatic engine upgrade code base but haven't found anything suspicious. I will continue to investigate when receive your response.

Hi @excieve , we're on track to release v1.1.2 with the fix by the end of the month. When we have an RC build for v1.1.2, would you willing to try it to confirm that the issue has been fixed?

Verified with Longhorn-master and Longhorn- v1.1.2-head - 06/14/2021
Validation - Pass
With the test steps provided with https://github.com/longhorn/longhorn/issues/2624#issuecomment-857173510, I was able to see the problem with v1.1.1.
This is working fine with Longhorn-master and longhorn v1.1.2-head.

When we have an RC build for v1.1.2, would you willing to try it to confirm that the issue has been fixed?

@yasker We're still gradually rolling out 1.1.1 across the fleet. So far we've only encountered this issue in one (largest) cluster out of 3 upgraded, which was manually "fixed". I'm not sure how to reliably test the RC with this fix unless this issue pops up on the other clusters later.
We've done our own internal load testing on a dedicated cluster and couldn't reproduce the observed timeouts with a similar number of nodes and volumes, so we're still unsure how to get into the same state that triggered this size bug to begin with. Perhaps there were some external factors at that time. We'll keep observing while we roll out 1.1.1 and report if this reoccurs.

@yasker @PhanLe1010 We encountered issues with engine upgrades on another larger cluster again :/ I've posted the details in Slack.

Slack link https://cloud-native.slack.com/archives/CNVPEL9U3/p1621918309019000

One issue shouldn't track 2 different bugs.
This issue is tracking the rounding bug. The slow volume operations bug is tracked at https://github.com/longhorn/longhorn/issues/2697
Closing this one


[Feature Request] Open external links as target "New Window"

Describe the feature you'd like
I like the default for internal links that they use the same browser tab. However I think if you're clicking on an external link (and it is not yet #1620 visually distinguished) my expectation for it are that it opens a new browser tab instead of using the "dedicated BookStack" tab.
Describe the benefits this feature would bring to BookStack users
Not sure how common my perspective is, but I think the proposed feature doesn't violate expectations.

Thanks for the suggestion @bandresen,
Currently users have control of this via the editor so it gets a little more complicated when we have to officially take that into account. In addition, I remain very apprehensive to alter the existing behaviour of the content that users have put into their BookStack instance.
I think the above workaround covers this kind of use-case perfectly well, and could be easily altered for other requirements such as adding noreferrer or noopener attributes. Thanks for providing @james-geiger.
Therefore closing this.

While I agree the provided workaround is sufficient to get the functionality, it lacks discoverability. Seeing a simple check box for this in the settings UI is more discoverable than someone having to google the solution, which isn't guaranteed to lead here.
I would personally still appreciate seeing this built in.

I couldn't help but notice that the option is now in BookStack v23.12.2 however, it's not working.  I still had to use the code above to get my external links to open in a new tab.  This sort of functionality is very common in wikis and the like; it's a wonder why it wasn't implemented sooner.

In the image above, I have checked the correct option, saved/closed that window and then saved/closed the editor window but the link wouldn't open into another window/tab.  In fact, when I went back in to edit how the link behaves, it was set back to current window.

Hello @BAndresen,
You could accomplish this by placing the following script in your "Custom HTML Head" field in BookStack settings:
<script>
  document.addEventListener("DOMContentLoaded", function(){
    var links = document.links;

    for (var i = 0, linksLength = links.length; i < linksLength; i++) {
       if (links[i].hostname != window.location.hostname) {
           links[i].target = '_blank';
       }
    }
  });
</script>

Brilliant script! If I may, I'd suggest a slight change:
``
That way if user specifically wants the links to open in same window they can specify it in the HTML view.


pipeline: Document what features need to be extracted and added to the database columns

This task is about documenting what features should be extracted that are useful to performing data analysis tasks.

This is superseeded by the use of ooni/data


[Bug]: 'Sent Bitcoin' screen shows wrong address

Describe the bug
The address shown in the 'Sent Bitcoin' activity page is not the address sent to, it is my address from the previous transaction.
Reproduce

Go to '...'
Click on '....'
Scroll down to '....'
See error

Screenshots / Recording

txid: b9cc7d252ec52c3371637ca34faff3deab3a2a9eb627c5ed7c19ad2b07a37011
Operating system
Android 13 TKQ1.221114.001
Bitkit version
v130 d8f96e7d6475d2eef04ae08f9d9dd2c8894a8218
Log output
No response

UI needs to respect the CPFP here and not update the output address, I can take this.

This address field comes from beignet and has wrong value without any CPFP

This address field comes from beignet and has wrong value without any CPFP

I can't reproduce this with a normal transaction (without CPFP)

Nope, it is mine

Verified with 033edb4a46ff8d407baa25587cd5d86f6fc9c6c3 that the address field has now been removed.


Error 500: Failed to fetch dynamically imported module

Error since today: Failed to load module script: Expected a JavaScript module script but the server responded with a MIME type of "text/html". Strict MIME type checking is enforced for module scripts per HTML spec.

can you try to press ctrl+f5, the cache might stuck

Already tried that. Cleared the whole app cache, but no success.

Same problem. Tried to clear cache, reset account in settings - nothing happened.

You can try to press this to clear the cache, its different based on the browser

CTRL+F5
SHIFT+F5
CTRL+SHIFT+R

Yes I know that and on top I cleared everything with this:

Yeah I just cleared the cache from the server, should be working as usual (maybe you need to wait for some minutes)

It's working again for me. Thank you for looking into this!


Disable view collector

See discussion: https://github.com/lonnieezell/forum-example/discussions/178

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.08%) to 78.766%

Totals

Change from base Build<PHONE_NUMBER>:
0.08%

Covered Lines:
2029

Relevant Lines:
2576

💛  - Coveralls


Bugfix/1299/finance/invoice download with invoice number in new tab

#1299
Description
Invoice File will be  downloaded with invoice number after opening invoice in new tab.

This branch contains some additional changes which were not supposed to be merged, so closing this branch.


Remove runtests target

Subject of the issue
The runtests target was added in #1475 without much fanfare. I tried to find any discussion about its rationale but didn't see any so I'm not sure what its proponents would say about it.
I propose we remove it for the following reasons:

It increases build times. No matter what, each build must run the tests. That means a no-op incremental build actually takes a few seconds since it has to run the tests even though no code has changed. As we add more tests, this build time penalty gets bigger and bigger.
It's non-standard. I'm not aware any CMake project that does this. It's a bit surprising to have the tests get automatically run when all you did was ask CMake to build the project.
It does not produce color output. Running ctest will give you nicely colored output but the runtests target due to it using add_custom_command only produces a monochromatic output making it a bit harder to parse.
It's additional code to maintain. It's not particularly difficult to maintain, but it's a non-zero cost nonetheless.

Because our use of OpenCppCoverage on Windows ties into runtests, some work will be required to extract that code from the build scripts into the CI pipeline but I believe this is a solvable problem.

Another reason to remove it: running tests quickly opens and closes a few windows now that we have tests about that. I think it might be okay when explicitly running the tests but it seems surprising otherwise.
A simple solution at first is to remove runtests target from the default target, simply remove ALL from add_custom_target here.

See https://github.com/SFML/SFML/pull/2430

After working on #2442 I have come to see why having a runtests target can be useful in many situations.
Regarding points 1. and 2.: That is just a matter of removing runtests from ALL like I did in #2442. Once that is done you will be able to manually control when to run tests yourself.
Regarding point 3.: ctest would only be able to produce colour output in consoles that support it. This assumes that the normal way developers would want to run tests is by having a separate console open to run tests in. This might be the case for people working in Unix environments, but I myself would personally find it awkward to have a console separate from my main IDE on e.g. Windows just to run tests in.
Not many IDEs have first-party (or even add-on) support for running tests using ctest. In these cases removing the runtests target is equivalent to forcing people to invoke ctest through out-of-IDE means or some in-IDE console. I can imagine that this can become quite annoying quite fast (because I am one of those people). In the current state with the runtests target, people can choose how they want to run ctest. If they want colour, great, separate console window. If they don't care about colour, just build the runtests target and check if it passes. Removing something in order to support a feature by giving users less freedom doesn't sound right to me.
Also, because the question was asked in #2430, I always refer to local coverage reports when writing tests. It helps to know if I am moving in the right direction without having to push after every incremental change. Although CI is practically free, we shouldn't take it for granted and push too gratuitously. The best way to reduce CI build times is by not pushing at all.
When profiling an executable, every bit helps to improve the expressiveness and precision of the coverage data. In order to do this, the compiler and linker have to be instructed to generate additional information that can be used after profiling is complete. See here and here. This is why I added CMake support for generating coverage instrumentation. Moving this functionality out of CMake is not technically possible and removing it would lead to worse coverage data.
Moving testing and coverage functionality out of CMake and into ci.yml would have the effect that anybody who wants to run tests or compute coverage would have to do the legwork themselves for something that worked perfectly fine in the past (granted I support removing runtests from ALL since this makes sense). If at some point we wanted to compute coverage on BuildBot as well I would have to reproduce the ci.yml configuration there too.
The majority of the concerns in this issue can be addressed by the simple change of removing runtests from ALL. This is a change I can support, completely removing runtests would be a bit too extreme for me.

Not many IDEs have first-party (or even add-on) support for running tests using ctest. In these cases removing the runtests target is equivalent to forcing people to invoke ctest through out-of-IDE means or some in-IDE console.

I don't think this is true. You can just as easy build the default test target as you can our custom runtests target. Nothing is more difficult about using Test and the test target than our bespoke recreation of that.

Moving testing and coverage functionality out of CMake and into ci.yml would have the effect that anybody who wants to run tests or compute coverage would have to do the legwork themselves for something that worked perfectly fine in the past (granted I support removing runtests from ALL since this makes sense).

This doesn't have to be true. We can easily define a CMake preset for code coverage that can be used locally and in CI. That makes it very simple to enable all the flags required to enable coverage without having to bake that into our build scripts.

I see your point now. The runtests target is not the problem. The problem I have is two fold. First is the fact that tests are automatically run. That is easily fixed by removing it from the all target. My second issue is the fact that we have code coverage stuff baked into the build scripts when it's better off being external to the build.
We can keep the runtests target. I'll eventually get around to amending #2430 to keep that target around for you.


Support alias for the Schema and Message

Schema and message should support different names/alias while performing SerDe. Like ObjectMapper has  @JsonAlias and @JsonProperty. Probably we can use the same feature as Pulsar Schemas use ObjectMapper internally.

I see your problem.
but we have to find some way in order to abstract from Jackson Mapper because relying on Jackson Mapper will add an hard dependency for Pulsar.
in the case of Avro it is fine to support their annotations because we are supporting Apache Avro.
but in this case Pulsar supports  JSON in general and not Jackson Mapper, that is a specific library.

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


Graph: Enable the user to travel around and zoom

Depending on the viewport size, not all nodes might fit so the user should be able to travel around.
Also, some nodes might be hard to inspect, if they are small or if they are in a crowd. So it would be nice to enable zooming.
Example: https://observablehq.com/@d3/drag-zoom?collection=@d3/d3-drag

Need to fix some bugs related to the initial positioning of the graph
Add a cursor that tells the user he can move cursor: move ?
Update the tooltip positioning when user zooms or drags

d6f6882280291848dff12b7d16850a97fc82f93a


Build status after creating an environment from a Docker build context

Is your feature request related to a problem? Please describe.
According to the docs of creating an env. from a docker build context

Azure Machine Learning will start building the image from the build context when the environment is created. You can monitor the status of the build and view the build logs in the studio UI.

Note, the status of the build is not available in other formats apart from going to the studio UI. This makes it very difficult if I want to automate this environment creation in some CI jobs, as the CI jobs would simply succeed without checking the build status. As the environment is the basis for running some scripts/components/pipelines in AML, it essentially blocks the automation using CI jobs, but one has to fall back to manual processes.
Describe the solution you'd like
Add a method to check the build status of the env, e.g., check_build_process(max_time=800) to check the build process for maximal 800 seconds. If the build succeeds within the max time, it will return True.
Describe alternatives you've considered
I have tried the validate method. But it doesn't return anything on whether an environmental build is successful.
Another alternative is to treat the environment build as a component in one pipelines, but there are 1) no docs on this topic that I can refer to; 2) I doubt if this is really necessary to introduce another level of complexity.
Additional context
This feature is rather more important for creating an environment from a Docker build context, as building docker containers might be an error-prone process.

Hi @ZhiliangWu - Thanks for opening an issue. We'll take a look asap!
@azureml-github - Can you take a look?

Hi @swathipil, thanks for investigating this! If you need more input from my side, just let me know.

Right now we don't have this exposed.  Thanks for the feedback, I added one feature ask into our internal backlog and will review it.

@banibrata Thanks for adding this. Let me know if you need more input from my side.

@banibrata-de Is this already completed? Any docs on how it works?


Adding Loading Animation to layout.jsx

Related Issue
Closes #1242

Description
This pull request adds loading animation information to enhance the user experience while data is being fetched. The loading animation is applied to relevant components, providing visual feedback to users during loading processes.
Changes:

Added a Preloader component that displays a loading animation while data is being fetched.
Integrated the Preloader component into various sections where loading occurs, such as movie cards and dialogs.
Utilized CSS styles and animations to create an aesthetically pleasing loading animation.

Screenshots
https://github.com/rohansx/informatician/assets/85815172/ea33327d-d914-4c34-8f1a-6811915d1948
Checklist

[x] My code adheres to the established style guidelines of the project.
[x] I have included comments in areas that may be difficult to understand.
[x] My changes have not introduced any new warnings.
[x] I have conducted a self-review of my code.

@crocmons @rohansx  please review and merge my pull request

@rohansx @crocmons  conflict resolved ,please merge my pull request

@rohansx @crocmons conflict resolved again,please merge my pull request to avoid conflicts


Update: Anaconda.Anaconda3 version 2021.11

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Resolves #36706

Microsoft Reviewers: Open in CodeFlow

@wingetbot waivers Add Validation-Domain

After upgrading Anaconda using winget (winget upgrade --all --source winget) I am now getting this:

Is this a known issue?
How could I go about fixing?

Hmm, thats weird, i was going to say it changed install location, however when i tested it did install to C:\Users\User\anaconda3\
PS M:\> C:\Users\User\anaconda3\Scripts\conda.exe
usage: conda-script.py [-h] [-V] command ...

conda is a tool for managing and deploying applications, environments and packages.

Options:

positional arguments:
  command
    clean        Remove unused packages and caches.
    compare      Compare packages between conda environments.
    config       Modify configuration values in .condarc. This is modeled after the git config command. Writes to the
                 user .condarc file (C:\Users\User\.condarc) by default.
    create       Create a new conda environment from a list of specified packages.
    help         Displays a list of available conda commands and their help strings.
    info         Display information about current conda install.
    init         Initialize conda for shell interaction. [Experimental]
    install      Installs a list of packages into a specified conda environment.
    list         List linked packages in a conda environment.
    package      Low-level conda package utility. (EXPERIMENTAL)
    remove       Remove a list of packages from a specified conda environment.
    uninstall    Alias for conda remove.
    run          Run an executable in a conda environment. [Experimental]
    search       Search for packages and display associated information. The input is a MatchSpec, a query language
                 for conda packages. See examples below.
    update       Updates conda packages to the latest compatible version.
    upgrade      Alias for conda update.

optional arguments:
  -h, --help     Show this help message and exit.
  -V, --version  Show the conda version number and exit.

conda commands available from other packages:
  build
  content-trust
  convert
  debug
  develop
  env
  index
  inspect
  metapackage
  pack
  render
  repo
  server
  skeleton
  token
  verify

Could you have installed it Machine wide before? aka had 2 installations? (Since it doesn't uninstall the previous one)
Can you check if its installed to C:\ProgramData\Anaconda3?

Can you check if its installed to C:\ProgramData\Anaconda3?

No that one doesn't exist and iirc never existed.
However C:\Users\User\anaconda3 is gone, and that one definitely did exist before.
I've found that Anaconda is very fragile in general.
I've lost count of how many times I've had to reinstall it for various reasons.
Thinking of moving to docker + pip-tools because of it.


possible to flush tracing periodically ?

Hello, I found some Python package signal handling will break python for example this
and this
pressing ctrl-c just terminates whole python, leave viztracer no chance to dump tracing, I wonder if viztracer can periodically flush tracing to disk, or have some external control method (say, handle a SIGUSR or check some special filepath periodically) to immediately dumping all trace ?

As long as you don't crash Python or use os._exit(), viztracer should have a chance to dump trace. Even if you hooked SIGINT or SIGTERM.
Periodically dumping trace is a huge performance impact and should only be done explicitly by users. SIGUSR is only available on Linux and is already used for legacy attaching.
Is there a real usage or this is hypothetical?

question is that with some package running, ctrl-c do crash whole python even without viztracer.
it's a long-running process, with async logic, run for a day, and ctrl-c doesn't give any backtrace, thus I need some tracing method to inspect what's happening (near realtime).  my first try is to insert some logging and convert them to chrome trace, but that's not scalable.
then I found viztracer may resolve my problem, run it as
python -m viztracer my_script

after some running time,   ctrl-c still crashes everything and nothing saved. I can confirm viztracer do dumping trace before my script ctrl-c at early time ( but during that time my script won't crash by ctrl-c so I can already inspect backtrace, thus viztracer doesn't help)
trigger dump in my code maybe also possible, but I have some question for it:

is it possible to call viztracer dump if I run script by python -m viztracer ?
if 1 is impossible, is viztracer dump function thread safe, so I can call it from other thread ? because of possible hang problem, main thread may be blocked so call dump from main thread is not ideal

I didn't view the logic of viztracer and am not sure if this is reasonable, maybe viztracer can stream tracing output (maybe just intermediate format, user can convert it to final trace format offline), this has some advantages:

don't need to keep all the trace, save memory
can view the program process continuously, instead of waiting for the whole program to finish.
chrome tracing will show 'unfinished' block if tracing don't have corresponding E mark, so it help debugging hang problem (since we can view it during process still running , it can quickly find the hang point)

People have different definitions for "crashing" - if your program exit with a C-level error(SegFault), that should be reported to CPython. If it exits with an exception, that could be handled by viztracer (and not a CPython defined crash).
I can help with the viztracer related question though:

Yes, it's possible to dump data even if you run your script with the command line tool. In your code, just do:

from viztracer import get_tracer

def save():
    tracer = get_tracer()
    tracer.save()

def your_function():
    ...
    # Dump the data
    save()

save() should be thread-safe because it will turn off the collecting first. There's also a forked version - fork_save() - that would fork first then do the saving.

Not streaming the output is a design choice - for performance. Users are using viztracer for profiling a lot, so performance is critical. Writing to disk cost too much time to do.

ok I'll take a try, Thank you for this. and is fork_save work under windows ?

It should work - not a lot of users actually use that feature even though it's been tested.


Could not chdir to home directory /nashome/b/bv: Permission denied

❯ kinit<EMAIL_ADDRESS>Password for<EMAIL_ADDRESS>❯ ssh<EMAIL_ADDRESS>...
Could not chdir to home directory /nashome/b/bv: Permission denied
------------------------------------------------------------------------------
                     ..::Powered by ECF-SSI::..

   Hostname: dunegpvm02.fnal.gov         OS Release: SLF 7.9 (Nitrogen)
         IP: <IP_ADDRESS>                  Subnet: <IP_ADDRESS>

     Kernel: 3.10.0-1160.25.1                  Arch: x86_64
        RAM: 9.60 GiB                          Swap: 2.00 GiB
      Cores: 4                              Virtual: rhev

 SSH Logins: 5                             Load Avg: 0.77 1.06 1.18

       Help: https://ssiwiki.fnal.gov/wiki/Interactive_Server_Facility
------------------------------------------------------------------------------
-bash: /nashome/b/bv/.bash_profile: Permission denied
-bash-4.2$ pwd
/

The solution is to kinit<EMAIL_ADDRESS>on the remote end after login.  This will immediately give access to $HOME though of course for the immediate session, the normal shell setup is still not active.
This access grant seems to "stick" so a subsequent ssh to the same remote host will give access to $HOME. But, I had to repeat this for every gpvmXX (for dune and uboone).
Note, this doesn't seem to have anything to do with kinit -f.  After the remote kinit, I am able to do a simple kinit locally and connect.

This happens occasionally, when kinit -f in fact doesn't forward your kerberos fitter.

This issue is avoided if you kinit and then log in with the following set of flags
ssh -YKX

You can also add this to your .ssh/config on your local machine to achieve the same functionality, as well as allow you to simply type ssh duneXY to log in to your desired version
 1 Host dune01
  2         HostName dunegpvm01.fnal.gov
  3
  4 Host dune02
  5         HostName dunegpvm02.fnal.gov
  6
  7 Host dune03
  8         HostName dunegpvm03.fnal.gov
  9
.... (skipping extra lines)
 34 Host dune11
 35         HostName dunegpvm11.fnal.gov
 36
 37 Host dune12
 38         HostName dunegpvm12.fnal.gov
 39
 40 Host dune0* dune1*
 41         User calcuttj
 42         ForwardX11 yes
 43         ForwardX11Trusted yes
 44         GSSAPIDelegateCredentials yes
 45

It is not advisable to run kinit on a remote machine on a regular basis, although I've seen advice that if you have to do it once in a while (say to rescue a session with an expired ticket and you need to save some work), then not to get too worried.  Even though the connection may be encrypted end to end, it is still possible for a malicious actor to steal a password.  Many years ago, someone installed a keylogger on one of the CDF interactive servers.  It collected several users' passwords before being discovered.  We just changed our passwords after being notified about it.

If you find your Kerberos tickets are not being forwarded correctly, make sure that you are using the OS kinit executable (/usr/bin/kinit). In particular conda is known to provide its own copy that does not work properly.