Matching Python types for return values of pvsystem.calcparams_*

[x] Partially addresses #1626 (first two checkboxes)
[x] I am familiar with the contributing guidelines
[x] Tests added
[ ] Updates entries in docs/sphinx/source/reference for API changes.
[x] Adds description and name entries in the appropriate "what's new" file in docs/sphinx/source/whatsnew for all changes. Includes link to the GitHub Issue with :issue:`num` or this Pull Request with :pull:`num`. Includes contributor name and/or GitHub username (link with :ghuser:`user`).
[x] New code is fully documented. Includes numpydoc compliant docstrings, examples, and comments where necessary.
[x] Pull request is nearly complete and ready for detailed review.
[x] Maintainer: Appropriate GitHub Labels (including remote-data) and Milestone are assigned to the Pull Request and linked Issue.

This PR addresses the observations about pvsystems.calcparams_* in #1626. These are that pd.Series return values can inherit the name of the pd.Series passed to the functions, and that the numeric return values (either scalar, np.ndarray, pd.Series) are not always the same Python type.
A helper function is added to pvlib/tools.py to get the first pandas index from a list of variables.

Thanks @reepoi!


Add Python 3 support while maintaining Python 2 compatibility

Coverage increased (+1.8%) when pulling 4ef132a55ee1159717efa813a3a4e2e775ebe512 on jni:py3k into 73ecff0329554c1756ce6ff2ee207e85b4ba51b2 on microscopium:master.

Coverage increased (+1.8%) when pulling e8e3c10ef8e343c50d583c5fddc209580fd45985 on jni:py3k into 73ecff0329554c1756ce6ff2ee207e85b4ba51b2 on microscopium:master.

Coverage increased (+1.8%) when pulling e8e3c10ef8e343c50d583c5fddc209580fd45985 on jni:py3k into 73ecff0329554c1756ce6ff2ee207e85b4ba51b2 on microscopium:master.

Boom! Expect to be tested on Python 3 from now on, @starcalibre! =D
Please review, and merge if you consider it ready! =)

Cool! This passes everything in my environment running Python 3.4 and current skimage master! Looks good to go..


Fix containing block detection for contain prop

Problem:
Previously isElementAContainingBlockForAbsolute would only return true if computedStyle.contain was equal to paint.  This comes from point 4. iv. of this MDN article.
But the Contain MDN Article has a broader definition:

If applied (with value: layout, paint, strict or content), this property creates:
A new containing block (for the descendants whose position property is absolute or fixed).
[...]

Moreover, the contain prop can take a list of words, so we need to replace the strict equality check with a  String.includes().
Fix:
isElementAContainingBlockForAbsolute returns true if computedStyle.contain contains any of layout, paint, strict or content

(it'd be nice to have tests for this 😇 )

(it'd be nice to have tests for this 😇 )

yeah it'd actually be pretty good to have tests for this, but the tests should be empirically checking if Chrome agrees with us.
So instead of a unit test approach, we should really make sure that if any of these cases are true, then the children's offsetParent matches our expectations. Maybe we could make it a FastCheck test too, so it could come up with random prop combinations for us


[HOTFIX][SQL] sparkSession can't be private.

What changes were proposed in this pull request?
This fixes the following errors.
-    @transient private val sparkSession: SparkSession,
+    @transient override val sparkSession: SparkSession,

Build Error
[error]  value sparkSession has weaker access privileges; it should not be private
[error]     @transient private val sparkSession: SparkSession,
[error]                            ^
[error] one error found
[error] (hivecontext-compatibility/compile:compileIncremental) Compilation failed

How was this patch tested?
Pass the Jenkins build.

cc @rxin .

Test build #56960 has started for PR 12684 at commit 1c8b246.

Thanks - actually I pushed directly to master just now. Can you close this?

Sure! Thank for quick fix. I found that when I rebase my PR.

Test build #56960 has finished for PR 12684 at commit 1c8b246.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

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

Merged build finished. Test PASSed.

Ur, @rxin .
Could you check that again?
[error] /Users/dongjoon/spark/sql/hivecontext-compatibility/src/main/scala/org/apache/spark/sql/hive/HiveContext.scala:50: super may not be used on value sparkSession
[error]     new HiveContext(super.sparkSession.newSession(), isRootContext = false)
[error]                           ^
[error] /Users/dongjoon/spark/sql/hivecontext-compatibility/src/main/scala/org/apache/spark/sql/hive/HiveContext.scala:54: super may not be used on value sparkSession
[error]     super.sparkSession.sessionState.asInstanceOf[HiveSessionState]
[error]           ^
[error] /Users/dongjoon/spark/sql/hivecontext-compatibility/src/main/scala/org/apache/spark/sql/hive/HiveContext.scala:58: super may not be used on value sparkSession
[error]     super.sparkSession.sharedState.asInstanceOf[HiveSharedState]
[error]           ^
[error] three errors found

It's a clean build after git clean -fdx.

Hah ok let me fix it for real.

OK pushed.

Thank you! :)

It works now! Thank you!


Crash: Game crash when loading/creating a new world

What were you doing when the crash occured? How can we replicate it?

Install Connector and Connector Extras along with their dependencies.
Install Paradise Lost and other mods.
Launch tha game.
Game would crash when loading a world.

Did it crash the client or server?
Client
Mod Version
Beta 2.2.3
Fabric API Version
Forgified Fabric API 0.92.2+1.11.8+1.20.1
Crash Report
https://pastebin.com/pqtcLVyu

Other mods
Mod list is available in the crash report.
Additional Information
Truncated latest.log: https://pastebin.com/RnGFDLLn

There are so many mods I'm not sure where to start, do you have any other dimension mods?

I'm going to chock this up to Sinytra weirdness. Liroth uses a Forge port of the custom portal API used by PL and is causing the Fabric version to act up when loading both through Sinytra.
Unfortunately I think you'll have to choose between PL or Liroth but they won't be able to coexist across Forge-Fabric

Using the Fabric version of Liroth seems to fix the issue, but that version is quite outdated compared to the forge one. But I guess I don't have any options anyway. Thanks for figuring out the problem though.


feat: add transparent theme for testing #191

Alaska Airlines Pull Request
Type of change:
Please delete options that are not relevant.

[x] New capability
[ ] Revision of an existing capability
[ ] Infrastructure change (automation, etc.)
[ ] Other (please elaborate)

Checklist:

[x] My update follows the CONTRIBUTING guidelines of this project
[x] I have performed a self-review of my own update

By submitting this Pull Request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Pull Requests will be evaluated by their quality of update and whether it is consistent with the goals and values of this project. Any submission is to be considered a conversation between the submitter and the maintainers of this project and may require changes to your submission.
Thank you for your submission!
-- Auro Design System Team
Summary by Sourcery
New Features:

Introduce a new transparent theme for testing purposes, including various color configurations for brand, base, icon, container, border, text, utility, background, tier, UI, and alert categories.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: jason-capsule42:x: Jason BakerJason Baker seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Start markdown

[ ] Turn  on Github Pages
[ ] Outline My portfolio
[ ] Introduce myself to the world


chore: Update chain typo types.ts

Problem solved
Fixed type "true" instead of "boolean"

PR-Codex overview
This PR updates the testnet property in the types.ts file from a hardcoded true value to a boolean type.
Detailed summary

Updated testnet property in types.ts to use a boolean type instead of hardcoded true.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@jnsdls you are correct. I'm trying to reuse a few things that is on the codebase like viem chains, I need to force a type "true" to handle these cases when try to reuse same code. Thx for asking

Could you share an example that currently doesn't work and will work with this change?

@jnsdls  I think would be very good if community make some pattern since there's almost same data from each chain.
import { baseSepoliaChain, baseChain, Chain } from './chains'; /// wagmi chains  +  additional dapp prop

export const mainnets = [baseChain];
export const testnets = [baseSepoliaChain];

export const allowedChains = (
  process.env.NEXT_PUBLIC_TESTNET_MODE === `1` ? testnets : mainnets
) as [Chain, ...Chain[]];

export const thirdwebChains = allowedChains.map((chain) => ({
  name: chain.name,
  id: chain.id,
  rpc: chain.rpcUrls.default.http[0],
  nativeCurrency: chain.nativeCurrency,
  testnet: chain.testnet as true, /// here weird approach
  blockExplorers: chain.blockExplorers?.default
    ? [
        {
          name: chain.blockExplorers.default.name!,
          url: chain.blockExplorers.default.url!,
          apiUrl: chain.blockExplorers.default.apiUrl!,
        },
      ]
    : [],
}));

@jnsdls Thirdweb says its work "side by side" with viem. So why not enjoy their code as well? I would love to hear from you about that

makes sense, this should today if you pass the chains from viem or wagmi into defineChain(<chain here>) from thirdweb
so I'd expect something like this to work, please let me know if it doesn't:
import { defineChain } from "thirdweb";
import { someChain } from "viem/chains"; // or wagmi, I believe the definitions are shared(?)

// transform `viem` chain definition into tw chain
const twChain = defineChain(someChain);

// then use the chain with thirdweb below

that said I agree with your overall sentiment of there needing to be more of a standard, in general one pain point I feel is that chain definitions are kind of all over the place, now obviously we're somewhat guilty of that here as well...
chain definitions in a nutshell
I don't yet know what to do about it. In the meantime please let me know if the above approach works for you!


2021-12-01

[ ] Tests added / passed
[ ] Passes black dask / flake8 dask

2021-12-01 update from dask/dask


Set content-type to STOMP ERROR frames

Not setting it to directly instantiated 1.0 frames though, as
content-type is not in the 1.0 spec. However the 1.0 spec does not
actually forbid headers outside of the spec so it shouldn't hurt if we
end up setting it for some frames sent over a 1.0 connection.

This is merged, close it please


can somebody explain the procedure for implementing the code??

I don't understand your question. Can you elaborate?


Preset concept should be moved to the "module" bounded context

A preset is collection of preselected modules that could be applied together, so it rather belong to the "module" bounded context.
It actually resides in the "project" bounded context, whereas this bounded context deals with an existing generated project: history of applied modules, download of the project, ...

I agree. I thought about that while I was doing it. I decided on my last commit to where it should go 😅
So it's going to be at the same place as the list of modules,  isn't it?

I agree. I thought about that while I was doing it. I decided on my last commit to where it should go 😅

😅 I also did not pay attention to that when I've reviewed the code. I saw that accidentally while looking for the best location for the automatic cleanup of generated projects (#10575)

So it's going to be at the same place as the list of modules,  isn't it?

I think it makes more sense. Alongside landscape stuff.


How to set state query param to custom identity server's url in azure portal?

Hello Team,
https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-oauth-code
In the above link i could see we can send any string to [state] query parameter and same will be returned back via response.
I have create custom identity provider in B2C. Now from my application,i have to pass some value via state query param to B2C , then B2C has to pass the same state query param to custom identity server.
I have to do some operations based on the values inside my custom identity server code.
How to configure or achieve via Azure Portal? Any different approach is also ok for me.

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

ID: f3e20651-5b2b-bd0b-dc92-a4a3643776ef
Version Independent ID: c9e25d10-4298-c95d-d24a-25a45c47e9ac
Content: Authorization code flow in Azure Active Directory B2C
Content Source: articles/active-directory-b2c/active-directory-b2c-reference-oauth-code.md
Service: active-directory
GitHub Login: @davidmu1
Microsoft Alias: davidmu

@vetrivelmp Thanks for your feedback! We will investigate and update as appropriate.

@vetrivelmp As far as I know it will not be a good idea to pass any fixed value as a State and it is recommended to use a randomly generated unique value to prevent cross-site request forgery attacks.  I think you can look into the Azure Active Directory B2C: Custom policies for your scenario, however, this is still in preview.

I assigned random value to state query param and I called B2C Authorize endpoint. B2C end point will call my custom identity server authorize endpoint. if i see state query param in custom identity server, this is totally different than what i sent from my application to B2C. Is there a way to do send same value to custom identity server from B2C?

@vetrivelmp For your specific scenario I suggest you please open a new MSDN forum post with the details and community will help address your query. Please refer to below link to MSDN forum to ask new question - https://social.msdn.microsoft.com/Forums/azure/en-US/newthread?category=windowsazureplatform&forum=WindowsAzureAD&prof=required.  Please provide the MSDN link over here so that I can help you getting answered.

@vetrivelmp We will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


Simplify generated visitors

Neither __FieldVisitor nor __Visitor need the __D: Deserializer type parameter.

This may contribute to #286 although I have not compared.

lgtm
@homu r+

:pushpin: Commit d5102a7 has been approved by oli-obk

:hourglass: Testing commit d5102a7 with merge d120539...

:sunny: Test successful - status


[Toolkit feature]: "bring mesh to me!" (When importing 3d Assets and they get spawned far away).

Contact Details (Optional)
No response
What is the context of the feature/improvement?
As the title says. Would love an option to teleport meshes/assets to my direct vicinity. Sometimes importing stuff gets spawned elsewhere rather than beside me. An option to bring it over would be neat! Nothing super important or anything, but a nice little quality of life improvement in some scenarios.
Please describe the feature/improvement?
As described above
What would be your solution? (optional)
...
Version
2024.1.1

Hello @PapaSlask Good news on this issue... it's actually being actively worked on. You can expect the tool in an upcoming release.
Internal ticket: REMIX-2422

This feature has been completed and is part of the 2024.3.0 release. Check out the notes here: https://docs.omniverse.nvidia.com/kit/docs/rtx_remix/latest/docs/remix-releasenote.html#features


How to calculate the mAP?

I find there is no score and only one pair of RP, so how to calculate the mAP?

We use the same AP as defined in the COCO dataset, which means we change the IoU threshold from 0.5 to 0.95 with 0.05 step size and calculate precision at these intervals.mAP is the average of all the classes.

Thanks for your reply.
But I stll don't understand how to calculate a single AP.  I don't know if I've made my point clear.  I mean that if I set the IoU as 0.5,  as far as I am concerned, the AP is to calculate the area under the PR polyline. But in this work, there is no score, and it only has one pair of PR. So how to calculate to area?

You calculate the precision at several IoU threshold and take the average. I suggest that you take a look at this article https://jonathan-hui.medium.com/map-mean-average-precision-for-object-detection-45c121a31173

@pqhieu I had the same doubts on how to calculate the AUC. Check this repository, it might help
https://github.com/rafaelpadilla/review_object_detection_metrics


mpv: 0.33 -> 0.33.1 (security fix)

Motivation for this change
mpv 0.33 has a security vulnerability. The relase notes in https://github.com/mpv-player/mpv/releases/tag/v0.33.1 recommends upgrading immediately.
Things done

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

[X] NixOS
[ ] macOS
[ ] other Linux distributions

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

Result of nixpkgs-review pr 118639 at ff4e2fa1 run on aarch64-linux 1

3 packages failed to build:

anki
ankisyncd
mnemosyne

1 package skipped due to time constraints:

plex-mpv-shim

14 packages built successfully:

celluloid
curseradio
hydrus
jellyfin-mpv-shim
jftui
minitube
mpc-qt
mpv-unwrapped
mpvScripts.mpris
python38Packages.mpv
python39Packages.mpv
qimgv
somafm-cli
sublime-music

Note that build failures may predate this PR, and could be nondeterministic or hardware dependent.
Please exercise your independent judgement.

Result of nixpkgs-review pr 118639 run on x86_64-darwin 1

4 packages marked as broken and skipped:

hydrus
jellyfin-mpv-shim
mpc-qt
sublime-music

3 packages failed to build:

anki
mnemosyne
plex-mpv-shim

5 packages built:

curseradio
mpv-unwrapped
python38Packages.mpv
python39Packages.mpv
somafm-cli

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

22 packages built:

anki
ankisyncd
celluloid
curseradio
hydrus
jellyfin-mpv-shim
jftui
minitube
mnemosyne
mpc-qt
mpv
mpv-unwrapped
mpvScripts.autoload
mpvScripts.mpris
plex-media-player
plex-mpv-shim
python38Packages.mpv
python39Packages.mpv
qimgv
somafm-cli
sublime-music
ytfzf

@tomberek 20.09 is also affected. ANy reason you didn't backport?

@tomberek 20.09 is also affected. ANy reason you didn't backport?

Not at all, I'd be okay to review a backport PR. Or, to put it another way; was there an expectation I'd create a backport PR?

The thing is, I would've expected that initiative from either the merger (i.e. you) or @cript0nauta since 20.09 seems also affected by this, but worries, IIRC the backporting guidelines aren't 100% clear on this :)
If you'd like to take care of this, you could do

Check if 0.33 is a release with lots of breaking changes (if not, we can just go to 0.33.1 on 20.09) or try to identify the patch with the fix and try to apply it to 0.32 on 20.09
How to file a backport is described in https://nixos.org/manual/nixpkgs/stable/#submitting-changes-stable-release-branches. If you're not entirely confident on how do this, I'd suggest to not push directly to release-20.09, but open a PR against it.

In case you're unsure about this (in the future for instance), it's always fine to either ask the package maintainers (or the contributor who opened the PR) whether or not to backport or ask the NixOS/backports group for assistance.
Does this answer your question? :)

Check if 0.33 is a release with lots of breaking changes (if not, we can just go to 0.33.1 on 20.09) or try to identify the patch with the fix and try to apply it to 0.32 on 20.09

The commit fixing the vulnerability is https://github.com/mpv-player/mpv/commit/d0c530919d8cd4d7a774e38ab064e0fabdae34e6. I confirmed that I can cherrypick it into v0.32. Adding this patch to 20.09 looks like the most sensible decision.


[FEATURE] Rework the model/texture of the Old Champions Remains

Is your feature request related to a problem? Please describe.

Theres no specific problem with it, It just simply doesnt look worthy of being in the mod when compared to other entities.

Describe the solution you'd like

I think it could have a completely new design, it might require some new abilities too idk, but the Abyss Watcher boss from Dark Souls 3 has a pretty fitting look for this boss, they are also in a grave just like OCHR, they also use a sword.

Describe alternatives you've considered

If you dont like the Abyss Watchers, I think the Death Knights from Elden Ring or Slave Knight Gael with a few changes might be good also.
Additional context
Here are a few jmages of the 3 bosses I mentioned:
Slave Knight Gael

Abyss Watchers

Death Knight

I see your point, however it strays away from my original view of the character. The boss is kinda supposed to look like a basic draugr/skeleton type of guy. The idea is that the true soul of the Fallen Icon was cast away and looked for a new host. It stumbled upon an old grave and possessed it's body. This is the reason why it looks basic, it is possessed by the Frenzied Shade, which also looks kinda plain due to me wanting it to look as much as a soul as possible. It is not meant to be a big final guy like The Decaying King, it is supposed to be a middle-step to get to the Fallen Icon boss fight.
Before I reworked his move-set, he only had like 2 unique attacks, a thrust and a shield bash. Other than that, he just ran at you like any other mob and whacked at you with his sword. It wasn't really interesting so I re-made the fight and added lot's of other cool attacks.
I am planning on adding at least 1 other major boss that comes after the Day Stalker and Night Prowler, where the design will be heavily inspired by Abyss Watchers, Gael and other nimble. but hard hitting sword fighters with big spectacle attacks. It will be a long while before I get to make that one though, I am only in the idea phase of it's move-set.
Again, I appreciate your feedback, but it will also just take too much time. Like you mentioned, I'd have to remake all the animations to fit the new model, and then re-program all the attacks so they also are synced with the animations. I am happy with how he currently looks. If other people decided to rework the model, I'd be happy to check it out and consider pursuing this further, but I will not remake him myself.

I completely understand, thanks for the "spoiler", Im curious how that boss will turn out, and also thank you for the quick answer.


NEST does not deserialize failure's from task api response

NEST/Elasticsearch.Net version: 7.17
Elasticsearch version: 7.17
.NET runtime version: 6.0.4
Operating system version: macOS monterery
Description of the problem including expected versus actual behavior: Nest is not able to deserialize task api failure response properly. Though Elastic search return error cause and reason but NEST does not deserialize errorCause and reason and only provide headers and index name. Nest only return below error and hide all the reason and errorCause.
{
"cause": {
"headers": {}
},
"id": "NQBhAGYAOQAwAGUAMgAxAC0ANABkAGMAYQAtADUAOAA4ADYALQBiADcAMgAzAC0ANABjAGQAYQA2AGYAZQAzADIANwA4ADIAXwA4AGMAYQA0ADMAYQAxAGQALQA2ADgAMwA3AC0ANAA2AGIANwAtAGEAMgAzAGUALQBhADMAMgAzAGUANAA5AGYAZQBmADUAMQA=",
"index": "temp_index1",
"status": 400,
"type": "_doc"
}
Please fix it.
Steps to reproduce:

create an ES task which fails and have some failure in the task response.
fetch task status with task api ex var task = elasticClient.Tasks.GetTask("");
var response =  task.GetResponse()
print response
though ES gives actual reason and error cause but when you deserialize ReindexOnServerResponse you dont find reason and errorCause.

Expected behavior
NEST should deserialize errorCause and reason from Error Obejct like below
"failures" : [
{
"index" : "temp_index1",
"type" : "_doc",
"id" : "1",
"cause" : {
"type" : "mapper_parsing_exception",
"reason" : "failed to parse field [keyword_1] of type [date] in document with id '1'. Preview of field's value: 'somesubject'",
"caused_by" : {
"type" : "illegal_argument_exception",
"reason" : "failed to parse date field [somesubject] with format [strict_date_optional_time||epoch_millis]",
"caused_by" : {
"type" : "date_time_parse_exception",
"reason" : "Failed to parse with all enclosed parsers"
}
}
},
"status" : 400
}
]
Response deserialize by NEST
{
"cause": {
"headers": {}
},
"id" : "1",
"index": "temp_index1",
"status": 400,
"type": "_doc"
}
Provide ConnectionSettings (if relevant):
Provide DebugInformation (if relevant):

Thanks for raising this @jeetuthakur. I'll look into this and see if we can add the missing properties to support this in a future release.

Hi, @jeetuthakur. I just took a proper look at this and everything seems to work as expected on my end and I'm unable to reproduce. Each failure has a Cause property which includes the full Error object which includes the CausedBy and Reason properties.
Here's the code I used:
var client = new ElasticClient();
var response = await client.Tasks.GetTaskAsync("NV5pzcN3S4-4hvmLnnYeTQ:2391076");
var reindex = response.GetResponse<ReindexOnServerResponse>();

Here is the locals window showing the expected data on the object.

Can you expand on your scenario so I can understand the issue you are facing?

Hi, @jeetuthakur. Just checking in to see if this is still a valid issue and if so, can you please provide more information?

Hi Steve,
Thanks for looking into this and sorry for replying so late but i was on
vacation.
Yes, I can see the failures in debugger but when i deserialize the object
to print the same info in logs then i do not see any failure or
reason/cause and those objects are empty.
please see attached screenshot.
On Thu, Apr 21, 2022 at 7:23 AM Steve Gordon @.***>
wrote:

Hi, @jeetuthakur https://github.com/jeetuthakur. Just checking in to
see if this is still a valid issue and if so, can you please provide more
information?
—
Reply to this email directly, view it on GitHub
https://github.com/elastic/elasticsearch-net/issues/6235#issuecomment-1105285141,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACY22KIP4KTLL5XXY6ICVI3VGFQGZANCNFSM5RYGMH4Q
.
You are receiving this because you were mentioned.Message ID:
@.***>

I'm going to close this as the use case is not supported.


Broken Link

"New stakeholder" page loads 'NoneType' error

Reviewed ticket and confirmed link is working in dev; added a new stakeholder and new contact with no issues (Test Case: Indonesia Training Delivery)


CNV CallSegments: tag doc and give example command

Pending questions
For CallSegments, the --legacy parameter needs clarification.

Is python ReCapSeg the main legacy data?
Can folks use non-python ReCapSeg? Other data?
Why is there a "NOTE" that the output is in the tool's format? Is there reason to expect a different format? I'd like to omit this note. Is that okay?

--legacy,-LEG:Boolean         (Advanced) Assume that the input seg file is using the legacy format (e.g. generated by
                              python ReCapSeg).  NOTE:  The output will be in the format used by this program -- i.e. no
                              preservation of legacy field names, etc.  Default value: false. Possible values: {true,
                              false}

Answers to questions:

Is python ReCapSeg the main legacy data?

Yes

Can folks use non-python ReCapSeg? Other data?

There is no such thing as non-python ReCapSeg data.  If you have data in the same format as ReCapSeg you can use it.  The tool is agnostic of how it was generated.

Why is there a "NOTE" that the output is in the tool's format? Is there reason to expect a different format? I'd like to omit this note. Is that okay?

I think that is okay.


[Bug]: ReadAllFiles does not fully read gzipped files from GCS

What happened?
Since the refactor of gcsio (2.52?) ReadAllFiles does not fully read gzipped files from GCS. Part of the file will be correctly returned but rest will go missing.
I presume this is caused by the fact that GCS performs decompressive transcoding while _ExpandIntoRanges uses the GCS objects metadata to determine the read range. This means that the file size we receive is larger than the maximum of the read range.
For example, a gzip on GCS might have a file size of 1 MB and this will be the object size in the metadata. Thus the maximum of the read range will be 1 MB. However, when beam opens the file it's already decompressed by GCS so the file size will be 1.5 MB and we won't read 0.5 MB out of it thus causing data loss.
Issue Priority
Priority: 1 (data loss / total loss of function)
Issue Components

[X] Component: Python SDK
[ ] Component: Java SDK
[ ] Component: Go SDK
[ ] Component: Typescript SDK
[ ] Component: IO connector
[ ] Component: Beam YAML
[ ] Component: Beam examples
[ ] Component: Beam playground
[ ] Component: Beam katas
[ ] Component: Website
[ ] Component: Spark Runner
[ ] Component: Flink Runner
[ ] Component: Samza Runner
[ ] Component: Twister2 Runner
[ ] Component: Hazelcast Jet Runner
[ ] Component: Google Cloud Dataflow Runner

Thanks for reporting. Agree this is a P1 bug as it causes data loss.

Is it possible to provide a working example that reproduce the issue, which could help triage.

@shunping FYI

Is it possible to provide a working example that reproduce the issue, which could help triage.

@Abacn I don't have a working example however the steps to reproduce are:

Upload a gzip file to GCS. Make sure that the unzipped file is large enough, e.g a few MB.
Create a beam pipeline using Python SDK that reads the file from 1. using RealAllFromText.
Print or write the output of ReadAllFromText.
Observe that the file is not fully read.

So I double checked and there are differences between your example and our case.

We use content encoding gzip while saving our files to GCS, you don't have encoding specified
This leads us to using ReadAllFromText with parameter compression_type=CompressionTypes.UNCOMPRESSED since the downloaded file seems to be already uncompressed (it doesn't work with CompressionTypes.AUTO), as in gcs policy
This further results in reading only fragment of the file

Furthermore, after removing encoding type from our file and using CompressionTypes.AUTO on it worked properly.
To get you example to represent our situation please add content encoding gzip to your file metadata.

For quick patch we use following solution:
class ReadAllFromTextNotSplittable(ReadAllFromText):
    """This class doesn't take advantage of splitting files in bundles because
    when doing so beam was taking compressed file size as reference resulting in
    reading only a fracture of uncompressed file"""

    def __init__(self, *args, **kwargs):
        super().__init__(*args, **kwargs)
        self._read_all_files._splittable = False

What does your medadata look like?
I tried this:

Then I got this error:
ERROR:apache_beam.runners.common:Error -3 while decompressing data: incorrect header check [while running '[6]: Read File from GCS/ReadAllFiles/ReadRange']

This is expected, as I mentioned earlier
This leads us to using ReadAllFromText with parameter compression_type=CompressionTypes.UNCOMPRESSED since the downloaded file seems to be already uncompressed (it doesn't work with CompressionTypes.AUTO), as in gcs policy
I presume while downloading file from GCS it's already decompressed, hence the error of decompression in Beam.

I see.
# standard libraries
import logging

# third party libraries
import apache_beam as beam
from apache_beam import Create, Map
from apache_beam.io.textio import ReadAllFromText
from apache_beam.options.pipeline_options import PipelineOptions
from apache_beam.transforms.combiners import Count

logger = logging.getLogger()
logger.setLevel(logging.INFO)

elements = [
    # "gs://apache-beam-samples/gcs/bigfile.txt.gz",
    # "gs://apache-beam-samples/gcs/bigfile_with_encoding.txt.gz",
    "gs://apache-beam-samples/gcs/bigfile_with_encoding_plain.txt.gz",
]

options = PipelineOptions()

with beam.Pipeline(options=options) as p:
    (
        p
        | Create(elements)
        | "Read File from GCS"
        >> ReadAllFromText(
            compression_type=beam.io.filesystem.CompressionTypes.UNCOMPRESSED
        )
        | Count.Globally()
        | "Log" >> Map(lambda x: logging.info("Total lines %d", x))
    )

This only loads 75,601 lines.
#19413 could be related for uploading the file to GCS.

.take-issue

Have we reproduced this?

Yes, see my above link: https://github.com/apache/beam/issues/31040#issuecomment-2081172626

Is there a hope of a fix for 2.57.0 cherry pick? I would guess this is a longstanding issue so getting it fixed in a very thorough way for 2.58.0 is actually the best thing to do. I recall we had decompressive transcoding bugs in the past. So we should make sure we really get it right this time. And the user can mitigate by configuring GCS to not do the transcoding.

Moved this to 2.58.0. Thanks!

Has any progress been made on this?

Has any progress been made on this?

Moved to 2.60.0

Has there been any progress on this? This is starting to become a blocker for us.

https://github.com/apache/beam/issues/31040#issuecomment-2072118260 does not work for you?

#31040 (comment) does not work for you?

That's what I was using prior until we realised this method was causing part of the data we were reading to be skipped. Basically same problem as here https://github.com/apache/beam/issues/31040#issuecomment-2081172626

This issue came up and was fixed in the Java SDK file IO many years ago, so we should have some reference material to work with. I am trying to find it.
And presumably also related to #18390.

Pick up this issue again. I confirm that I am able to reproduce the problem with code in https://github.com/apache/beam/issues/31040#issuecomment-2081172626

I briefly debugged the issue, it seems that file is accessed with decompressive transcoding  (https://cloud.google.com/storage/docs/transcoding#decompressive_transcoding).
I checked the metadata of the GCS file in use, and the result is as follows.
$ gcloud storage objects describe gs://apache-beam-samples/gcs/bigfile_with_encoding_plain.txt.gz
acl:
...
bucket: apache-beam-samples
content_encoding: gzip
content_type: text/plain
crc32c_hash: /REfiQ==
creation_time: 2024-04-27T20:19:48+0000
...
metageneration: 1
name: gcs/bigfile_with_encoding_plain.txt.gz
size: 7635685
storage_class: STANDARD
storage_class_update_time: 2024-04-27T20:19:48+0000
storage_url: gs://apache-beam-samples/gcs/bigfile_with_encoding_plain.txt.gz#1714249188497359
update_time: 2024-04-27T20:19:48+0000

The size field shows the size of the gzip file. The original file size prior to gzip should be 10100000.
$ wc bigfile_with_encoding_plain.txt
  100000<PHONE_NUMBER>0000 bigfile_with_encoding_plain.txt

Just check around. It seems GCS decompressive transcoding causes some similar issues elsewhere.

https://github.com/piskvorky/smart_open/issues/422
https://github.com/apache/opendal/issues/5070

The range is determined by the size obtained from GCSIO (https://github.com/apache/beam/blob/d7502fa73b153a81d73bf5d658e1b6a7ae0747c6/sdks/python/apache_beam/io/gcp/gcsfilesystem.py#L339, https://github.com/apache/beam/blob/d7502fa73b153a81d73bf5d658e1b6a7ae0747c6/sdks/python/apache_beam/io/gcp/gcsio.py#L477), which in turn called GCS Python Client Library google-cloud-storage.
The size property in the Blob object there comes from "Content-Length". (https://cloud.google.com/storage/docs/json_api/v1/objects)


utm 0.7.0 not available on conda-forge

UTM 0.7.0 does not exist on conda forge.

conda search utm
Loading channels: done
# Name                       Version           Build  Channel
utm                            0.4.2          py27_0  conda-forge
utm                            0.4.2          py35_0  conda-forge
utm                            0.4.2          py36_0  conda-forge
utm                            0.5.0            py_0  conda-forge
utm                            0.6.0    pyh9f0ad1d_0  conda-forge

It looks like there was an MR for it #4 but it failed to build: https://github.com/conda-forge/utm-feedstock/runs/1454082361.

@Turbo87 @snowman2

@ocefpaf are you able to restart the failed azure pipeline?

Argh. Missed this. Restarting now!

Done: https://anaconda.org/conda-forge/utm/files?version=0.7.0
The CDN should sync in ~50 min and it will be available in the channel sortly.


Simpler README, most content in docs

Please ensure that your pull request adheres to our contribution guidelines. Thank you!

Created in error. Apologies.


finish-mobile-version project

I have created a pull request for the "mobile_version" branch in the second portfolio project.

I have created a pull request for the "mobile_version" branch in the first Portfolio project. This pull request includes the following changes..
Adding the Images folder to the directory
Removing all unused commented code
checking and fixing License link workability
README. md file modification

As requested by the reviewer I kindly made changes on the following activities

README links workability
LICENSE link (MIT)


user12986714: Watch<PHONE_NUMBER>

user12986714 requests the watch of the watch_number<PHONE_NUMBER>. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

Approved by Daniil in Charcoal HQ


itwinjs.org @see links to learning documentation are broken

Examples:

https://www.itwinjs.org/reference/core-common/imodels/imodel/eceflocation/
https://www.itwinjs.org/reference/core-backend/elements/informationpartitionelement/

Appears to be the result of an undocumented typedoc json output schema change from v0.25.13 to v0.26.0.

This fix is now released. As always, a hard browser refresh may be needed to see the change for a bit.


fix jekyll 3.0 path error

in jekyll 2.x permalink: /:categories/:year/:month/:day/:title = /categories/year/month/day/title/
but in jekyll 3.x  permalink: /:categories/:year/:month/:day/:title = /categories/year/month/day/title
add / to fix it

This issue has caused my blog comment to have been lost, Because the path has changed.

fix it,common on!!!

@yanhaijing If you use duoshuo, you can set duoshuo's dada-thread-key.
So comments is not path related.
You can see my blog http://isay.me

@Treri thank you,i set data-url to fix it,but the question is a queistion,i think need /  end of path


Add kustomize overlays

Pull request checklist

Pull request type

Please check the type of change your PR introduces:

[ ] Bugfix
[x] Feature Enhancement
[ ] Test Automation
[ ] Code Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Community Operator listing
[ ] Other (please describe):

What is the current behavior?

One default directory contains a default kustomization
What is the new behavior?

The default overlay has been replaced with an overlays directory that allows multiple kustomizations.
How risky is this change?

[x] Small, isolated change
[ ] Medium, requires regression testing
[ ] Large, requires functional and regression testing

@tychristensen can you please update the file config/manifests/kustomization.yaml as well with ../overlays/default to ensure make bundle works.

@nitishkumar4 I fixed that kustomization and altered the kustomize command in the bundle target so that it would override the image correctly. I think make bundle is working normally now but didn't any thorough testing.

Thanks for making changes @tychristensen. Should we change IMAGE_TAG_BASE ?= quay.io/ibm-spectrum-scale/ibm-spectrum-scale-csi-operator to IMAGE_TAG_BASE ?= cp.icr.io/cp/spectrum/scale/csi/ibm-spectrum-scale-csi-operator as well in /operator/Makefile

We should not change IMAGE_TAG_BASE since you guys want quay when you GA (or at least that was my understanding).
go vet is failing with the following message:
../../go/pkg/mod/sigs.k8s.io/json@v0.0.0-20211020170558-c049b76a60c6/internal/golang/encoding/json/encode.go:1249:12: sf.IsExported undefined (type reflect.StructField has no field or method IsExported)
../../go/pkg/mod/sigs.k8s.io/json@v0.0.0-20211020170558-c049b76a60c6/internal/golang/encoding/json/encode.go:1255:18: sf.IsExported undefined (type reflect.StructField has no field or method IsExported)

I think this might be because this requires golang 1.17 and the operator is using golang 1.16. I'm still investigating what needs to be done to resolve this.

I have fixed this PR so that it is now using the 5.1.3 RC2 images.
@madhuthorat I will be removing the overrides from CNSA soon (not sure when). If you need CNSA to be using specific images please use operator/config/overlays/cnsa/kustomization.yaml to specify the image locations/digests.

@nitishkumar4 I included the changes for make manifests generate bundle but it looks like there is something wrong with the go module that is preventing make from running successfully. I think this should be addressed in a separate PR because it would be to many unrelated changes to include in this PR.

@nitishkumar4 I included the changes for make manifests generate bundle but it looks like there is something wrong with the go module that is preventing make from running successfully. I think this should be addressed in a separate PR because it would be to many unrelated changes to include in this PR.

Using Go1.17 should fix this.

Closing as Amol Raised #715 for the same


Fixed timestamp to datetime conversion for values with fractional seconds before the epoch

The timestamp_XX_to_datetime functions all panic with "invalid or out-of-range datetime" on conversions of values with fractional seconds before the epoch (where the timestamp becomes negative).
For these timestamps (pre-epoch, fractional secs) the  (v % <scale_factor>) as u32 formulation is not valid, as

the result is a negative number
... which causes integer wraparound via as u32
... which then leads to a panic, as we can't init with billions of microseconds (for example).

This PR allows pre-epoch conversions with fractional seconds to be handled correctly, and adds some new tests to provide the missing coverage.

Thanks @alexander-beedie. Great fix. :+1:


bootstrap.sh

While I may have some idea about what bootstrap.sh means, others may not. Please write a better PR description

To be honest I wasn't really sure what I'm suppose to do
I went over the first challenge but didn't exactly understand what my part is
Anyway I'm still waiting for the Django PR to be sent and approved before I start my part


Stage2 mono builds fail while building fsharp due to using R2R

The mono stage2 builds go looking for crossgen2 while building fsharp but that package doesn't get built with a mono runtime (because mono can't use the r2r format).
The PublishReadyToRun properties added in https://github.com/dotnet/fsharp/pull/16860 should be made conditional to not apply when the vmr is built with --use-mono-runtime.
cc @ViktorHofer @MichaelSimons @omajid

Fixed by https://github.com/dotnet/fsharp/pull/17300.


refactor, extract method support

Closing as out of scope of current NTVS project. We likely would try to leverage TypeScript to implement this functionality.


xHyper-V - Fixes to Examples

Pull Request (PR) description

Changed all references to $vhdPath where used as a static variable to $sampleVhdPath to remove confusion with named configuration parameters.
Replaced all uses of the parameter $baseVhdPath with references to $vhdPath for clarity

This Pull Request (PR) fixes the following issues:

Potential confusion between named parameters and variable containing sample value
Identical value represented with different parameter name between examples
$vhdPath is not defined within the scope of the Sample_EndToEndXHyperV_RunningVM configuration

This change is

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

Codecov Report

Merging #133 into dev will not change coverage.
The diff coverage is n/a.

@@         Coverage Diff         @@
##            dev   #133   +/-   ##
===================================
  Coverage    71%    71%
===================================
  Files         9      9
  Lines      1032   1032
  Branches     12     12
===================================
  Hits        733    733
  Misses      287    287
  Partials     12     12

Build fails are on unmodified files that do not reference the modified example file.

@PlagueHO I just saw your request to be tagged in here (this is the more minor of the two)

@Chirishman  Can I get you to do a pull from the dev branch to get the tests to pass (I just merged a fix in there for it). I'll get through the review of this one after that.

@BrianFarnhill Done

Thanks @Chirishman ! Looks like @BrianFarnhill is back on deck anyway! :grin: @BrianFarnhill - I wasn't sure you were the repo maintainer for this one either - but assumed you picked it up because no one else had.

@PlagueHO I'm happy to keep it warm until someone else steps up. You looking to add another module to your list? ;-)

Hahaha @BrianFarnhill :grin: but yes, I plan to pick this one up once I've finished the move of xComputerManagement to HQRM (nearly there). I'll wait till next year thought right :wink:

 but will just need a merge from PowerShell/dev to resolve conflicts. Happy with the way the rest of it looks though.

Reviewed 1 of 1 files at r1, 4 of 4 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved, some commit checks failed.

Comments from Reviewable

Conflicts resolved, should be good to go!

Review status: :shipit: all files reviewed at latest revision, all discussions resolved, all commit checks successful.

Comments from Reviewable


Added docker-compose directory

added two sub-directories to this directory one for ansible-compose and openshift import

To try out the application with Ansible:
docker-compose.yaml
msa_env_export

I pushed everything in a squashed commit in a branch called compose: https://github.com/redhat-helloworld-msa/helloworld-msa/tree/compose
So I'm closing this PR. You can send more PRs to that branch. Once we have everything in its place we can merge it to the master branch.


Sound and Victory triggers need to be able to have targets, too

Currently, it is impossible to make a sound trigger or victory trigger be activated by one of its targets, because they cannot have targets in my library (but it is possible in the game).

Fixed in commit https://github.com/ultrako/LevelXML/commit/ae4de50ca4e0fff51d0b2df9460b5a2a233f0fc1


Middle mouse button causes zooming in in 2D view

Godot version
v4.0.3.rc2.official [2ac4e3bb3]
System information
Windows 10
Issue description
I have a Logitech G502 mouse. Scroll wheel is also the middle button. Scroll wheel can be toggled to two different modes. Scrolling is either done in steps or in a continuous "free" mode.
Pressing middle mouse button sometimes causes involuntary zooming in, if the middle mouse button is pressed just after zooming by scroll wheel.
It doesn't matter, which scroll mode (stepped/free) of this mouse is used.
The initial zooming direction by wheel doesn't matter, the involuntary zooming is always in.
This problem doesn't happen with v3.5.2.stable.official [170ba337a]
Steps to reproduce

Open 2D view of any scene
Use mouse scroll wheel to zoom either in or out
Immediately after zoom in/out, press middle button (which is also the scroll wheel)
Problem: The view starts zooming in
Stop pressing the middle button, zooming in stops
Press middle button again
Problem: The view starts zooming in again

Minimal reproduction project
N/A

This still sounds like a hardware issue (have myself encountered this with mouse that has this feature) and difference being scroll threshold on 3.x

I configured the middle button click to another of this mouse's (Logitech G502) button. The problem doesn't occur when I click that button quickly after zooming. So the problem seems to occur only when the same physical button is used for zooming (scroll wheel) and panning (middle button).

So then it's because you accidentally scroll when you click

It is possible, but then it also is impossible to avoid. I'm normally using stepped mode where the wheel noticeably clicks when you scroll in either direction. I tried a few online mouse wheel testers and they did not detect any scrolling when I just clicked the mouse wheel. Clicking the mouse wheel doesn't cause any scrolling for example in vscode either. It may be possible that when the scroll wheel is touched the mouse sends some tiny values of scrolling and applications, Godot 3.6 including, just ignore those small values. If that is the case, I would recommend adding similar filtering of small scrolling values also to Godot 4.

If that is the case, I would recommend adding similar filtering of small scrolling values also to Godot 4.

Godot does not support high-precision scrolling on Windows. The issue is that you're accidentally trigger horizontal mouse wheel scrolling, and the editor interprets this as vertical scrolling when no horizontal scrolling is available. I can confirm that pressing the left/right mouse wheel scroll buttons will cause the 2D editor to zoom in 4.0.2 but not in 3.5.2 on Linux.

The issue is that you're accidentally triggering horizontal mouse wheel scrolling when clicking the middle mouse button, and the editor interprets this as vertical scrolling when no horizontal scrolling is available. I can confirm that pressing the left/right mouse wheel scroll buttons will cause the 2D editor to zoom in 4.0.2 but not in 3.5.2 on Linux (using a Logitech G903).

I can confirm that too. When I disabled horizontal scrolling from mouse wheel, the problem didn't occur anymore.

I have encountered the same issue on MacOS. Very annoying, happens very often. I don't need scrolling with mouse wheel when Cmd button is pressed so adding just a setting to disable zooming in script editor with mouse would be enough.


[BUG] Chart uninstall job failed: BackoffLimitExceeded

Describe the bug (🐛 if you encounter this issue)
I cannot uninstall the longhorn chart, with helm. Installation is successful, I can create, attach, detach, delete volumes through UI without issues. Everything is functional.
To Reproduce
Install chart:
# uname -a
Linux chronos 5.15.76-v8+ #1597 SMP PREEMPT Fri Nov 4 12:16:41 GMT 2022 aarch64 GNU/Linux
# helm version
version.BuildInfo{Version:"v3.10.3", GitCommit:"835b7334cfe2e5e27870ab3ed4135f136eecc704", GitTreeState:"clean", GoVersion:"go1.18.9"}

# helm repo add longhorn https://charts.longhorn.io
# helm repo update longhorn
# helm search repo longhorn
NAME             	CHART VERSION	APP VERSION	DESCRIPTION
longhorn/longhorn	1.4.0        	v1.4.0     	Longhorn is a distributed block storage system ...

# helm upgrade --install longhorn longhorn/longhorn --create-namespace \
    --namespace longhorn-system --set service.ui.type='LoadBalancer' \
    --set service.ui.loadBalancerIP='<IP_ADDRESS>' --wait
Release "longhorn" does not exist. Installing it now.
NAME: longhorn
LAST DEPLOYED: Mon Jan  2 17:40:51 2023
NAMESPACE: longhorn-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Longhorn is now installed on the cluster!

Please wait a few minutes for other Longhorn components such as CSI deployments, Engine Images, and Instance Managers to be initialized.

/var/lib/longhorn directory tree:
# ls -lah /var/lib/longhorn
total 24K
drwxr-xr-x  5 root root 4.0K Jan  2 17:42 .
drwxr-xr-x 28 root root 4.0K Jan  2 17:41 ..
drwxr-xr-x  3 root root 4.0K Jan  2 17:42 engine-binaries
-rw-r--r--  1 root root   51 Jan  2 17:41 longhorn-disk.cfg
drwxr-xr-x  2 root root 4.0K Jan  2 17:41 replicas
drwxr-xr-x  2 root root 4.0K Jan  2 17:42 unix-domain-socket

Uninstall chart:
# helm uninstall longhorn --namespace longhorn-system --debug
uninstall.go:95: [debug] uninstall: Deleting longhorn
client.go:310: [debug] Starting delete for "longhorn-uninstall" Job
client.go:128: [debug] creating 1 resource(s)
client.go:540: [debug] Watching for changes to Job longhorn-uninstall with timeout of 5m0s
client.go:568: [debug] Add/Modify event for longhorn-uninstall: ADDED
client.go:607: [debug] longhorn-uninstall: Jobs active: 0, jobs failed: 0, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 1, jobs failed: 0, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 1, jobs failed: 1, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 1, jobs failed: 1, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 1, jobs failed: 1, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
client.go:607: [debug] longhorn-uninstall: Jobs active: 0, jobs failed: 1, jobs succeeded: 0
client.go:568: [debug] Add/Modify event for longhorn-uninstall: MODIFIED
Error: job failed: BackoffLimitExceeded
helm.go:84: [debug] job failed: BackoffLimitExceeded
helm.sh/helm/v3/pkg/kube.(*Client).waitForJob
	helm.sh/helm/v3/pkg/kube/client.go:603
helm.sh/helm/v3/pkg/kube.(*Client).watchUntilReady.func1
	helm.sh/helm/v3/pkg/kube/client.go:571
k8s.io/client-go/tools/watch.UntilWithoutRetry
	k8s.io/client-go@v0.25.2/tools/watch/until.go:80
k8s.io/client-go/tools/watch.UntilWithSync
	k8s.io/client-go@v0.25.2/tools/watch/until.go:153
helm.sh/helm/v3/pkg/kube.(*Client).watchUntilReady
	helm.sh/helm/v3/pkg/kube/client.go:558
helm.sh/helm/v3/pkg/kube.(*Client).WatchUntilReady.func1
	helm.sh/helm/v3/pkg/kube/client.go:347
helm.sh/helm/v3/pkg/kube.batchPerform.func1
	helm.sh/helm/v3/pkg/kube/client.go:419
runtime.goexit
	runtime/asm_arm64.s:1270

Once the uninstall command executed, I cannot upgrade the chart, yet everything is functional into UI:
# helm upgrade --install longhorn longhorn/longhorn --create-namespace \
    --namespace longhorn-system --set service.ui.type='LoadBalancer' \
    --set service.ui.loadBalancerIP='<IP_ADDRESS>' --debug
history.go:56: [debug] getting history for release longhorn
upgrade.go:142: [debug] preparing upgrade for longhorn
Error: UPGRADE FAILED: "longhorn" has no deployed releases
helm.go:84: [debug] "longhorn" has no deployed releases
UPGRADE FAILED
main.newUpgradeCmd.func2
	helm.sh/helm/v3/cmd/helm/upgrade.go:201
github.com/spf13/cobra.(*Command).execute
	github.com/spf13/cobra@v1.5.0/command.go:872
github.com/spf13/cobra.(*Command).ExecuteC
	github.com/spf13/cobra@v1.5.0/command.go:990
github.com/spf13/cobra.(*Command).Execute
	github.com/spf13/cobra@v1.5.0/command.go:918
main.main
	helm.sh/helm/v3/cmd/helm/helm.go:83
runtime.main
	runtime/proc.go:250
runtime.goexit
	runtime/asm_arm64.s:1270

Expected behavior
Chart should be uninstalled.
Log or Support bundle
supportbundle_39ef92a0-7eaa-4d39-b80d-a2e3bf2d150e_2023-01-02T23-29-09Z.zip
Environment

Longhorn version: 1.4.0
Installation method (e.g. Rancher Catalog App/Helm/Kubectl): helm
Kubernetes distro (e.g. RKE/K3s/EKS/OpenShift) and version: k3s v1.25.4+k3s1

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

Node config

OS type and version: RaspiOS Lite 64bit
CPU per node: 4
Memory per node: 8G
Disk type(e.g. SSD/NVMe): SSD
Network bandwidth between the nodes:

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

cc @c3y1huang @longhorn/qa

@fmunteanu
Setting deleting-confirmation-flag is not set to true
Please refer to https://longhorn.io/docs/1.4.0/deploy/uninstall/#prerequisite.

@fmunteanu as @derekbit said this is intended, but feel free to reopen this if you still encounter this issue after enabling deleting-confirmation-flag. Thanks.

@derekbit @innobead thank you for the useful information. I still think we should look at the install error message I posted, it might be relevant? After the failed uninstall, I should still be able to perform an upgrade.

I see your point it's more about after failed uninstall, you tried to upgrade the installed chart with a new setting, but it failed instead. Ideally, it should work correctly w/o any impact from the previous failed uninstall.
cc @PhanLe1010 @longhorn/qa

@innobead correct, not sure if this issue should be re-opened. I expected the chart to be bumped to version 2. This is a fresh install, so I simply re-deployed another fresh cluster.

After failing to uninstall the chart, the revision history will be removed from helm stats, so you need to roll back it first via hel rollback to continue managing the installed helm chart. However, after the failed uninstall, your longhorn is intact as you see, because helm just removed the history but nothing really deleted.
For the detailed doc, please check https://longhorn.io/docs/1.4.0/deploy/uninstall/#troubleshooting, or if more interested, can check our original ticket, https://github.com/longhorn/longhorn/issues/4509#issuecomment-1278206383.
This is expected helm behavior due to its current design, even though it's not quite straightforward because I believe we all think that should be atomic w/o removing the revision history or even requiring running the rollback command.

I can't uninstall it, And I get this error
Diagnostics:
  kubernetes:helm.sh/v3:Release (longhorn-dev):
    error: 1 error occurred:
    	* job failed: BackoffLimitExceeded

Here is the installation code with chart and Pulumi:
https://github.com/omidraha/Pulumi-Example/blob/main/longhorn/longhorn.py#L157
kubectl get pods -n longhorn-system
NAME                                                READY   STATUS    RESTARTS   AGE
longhorn-ui-7dbc865f65-rv479                        1/1     Running   0          216d
longhorn-ui-7dbc865f65-wxvzf                        1/1     Running   0          216d
longhorn-manager-nhxfg                              1/1     Running   0          216d
longhorn-driver-deployer-59d54bf65d-kjxtz           1/1     Running   0          216d
csi-attacher-54fd9f464-qx95c                        1/1     Running   0          216d
csi-attacher-54fd9f464-6tqwj                        1/1     Running   0          216d
csi-attacher-54fd9f464-hpwp5                        1/1     Running   0          216d
csi-snapshotter-6cd46d96c7-9hs26                    1/1     Running   0          216d
csi-resizer-7b78d7bd7c-s8nqw                        1/1     Running   0          216d
csi-snapshotter-6cd46d96c7-vpfgh                    1/1     Running   0          216d
csi-snapshotter-6cd46d96c7-tktf8                    1/1     Running   0          216d
csi-resizer-7b78d7bd7c-hdmjt                        1/1     Running   0          216d
csi-provisioner-75f5767bff-447d2                    1/1     Running   0          216d
csi-provisioner-75f5767bff-kg5xm                    1/1     Running   0          216d
csi-provisioner-75f5767bff-bpkwg                    1/1     Running   0          216d
csi-resizer-7b78d7bd7c-n8fsl                        1/1     Running   0          216d
longhorn-csi-plugin-gzgnt                           3/3     Running   0          216d
instance-manager-354ebe2825b4355bd751d1092b6a7285   1/1     Running   0          216d
engine-image-ei-68f17757-w5v97                      1/1     Running   0          216d
longhorn-uninstall-l6vbd                            0/1     Error     0          26m
longhorn-uninstall-kz8n6                            0/1     Error     0          25m

I cannot set this parameter:
Any idea ?
# kubectl -n kube-system patch settings.longhorn.io deleting-confirmation-flag --type='merge' -p '{"value":"true"}'

Error from server (InternalError): Internal error occurred: failed calling webhook "validator.longhorn.io": failed to call webhook: Post "https://longhorn-admission-webhook.kube-system.svc:9502/v1/webhook/validation?timeout=10s": no endpoints available for service "longhorn-admission-webhook"


labels: respect Set after Del in Builder

The implementations are not symmetric between Set() and Del(), so we must be careful. Add a test for this.
Also make the slice implementation consistent re slices.Contains.
Fixes #12283

Can you rebase to release-2.44 ? We should cherry pick to 2.43 and release-2.43-stringlabels too.

I have rebased to release-2.44, changed the target of the PR, and also added a test in relabel package based on the original issue report.


Beautifyer merge

@doktoric plz review

Jenkins build failed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2293/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/2294/


Update internal instructions with new reference file names

Closes #498
Does what it says: Another pass over internal instructions to update reference cell type file names and documentation.
Any feedback on wording? I didn't really see other spots to update, but please let me know if/where I missed any spots.

Ready for another look! There was much fighting with the pre-commit hook here, so sorry about the whitespace-heavy diff (recommended to turn off whitespace!).
I caught another area in the middle of the docs which still referenced add-celltypes.nf, so I cleaned that area up and bullet-ified the text. I generally left inline comments here to explain some of the changes I made on this round, as well as one question about a sentence that I think can go. Let me know how it looks now!

Section moved! Let me know how it looks to you now!

Just noting this commit https://github.com/AlexsLemonade/scpca-nf/pull/555/commits/04bea4dd3877ff63ed56499f4ff558c21e6f04f1 will close #530

Getting closer evermore!

Noting this discussion - let's make sure we're on board to possibly change the hooks here vs reverting and circling back.
https://github.com/AlexsLemonade/scpca-nf/issues/566#issuecomment-1813168593
easier viewing:


Add numpy like indexing to core and slice

Found a weird edge case, you can technically specify a 1 pixel wide dimension like this with the 150:151:

This returns a valid Slice and should work perfectly fine. It's just weird that this is allowed but you couldn't do the same thing by specifying only 150 instead of 150:151. I'm not sure how to deal with this.
If we make sure the difference is more than 1 then we're setting an arbitrary minimum size of 2, which feels really weird. I'm leaning most towards keeping this behavior, but this creates an inconsistency with not being allowed to use an int that would do the same thing.
The reason this technically works is that my_core[150:151, 150:300, 11 // 2] creates a data array with shape (1, 150) where my_core[150:151, 150:300, 11 // 2] creates a data array with shape (150,)

I made it so the end index must come after the start index on all axes. This prevents reversing an axis via indexing. I want some feedback on what people think about this.
The rationale was that the data should stay mostly the same when indexing, and reversing might be confusing. Thinking about it now it's probably more confusing if it doesn't let you, but there are good error messages for it.

I made it so a step isn't allowed when indexing, so no taking every other value or something. I think this makes sense, but would like to double check if anyone can think of valid use cases.

Found a weird edge case, you can technically specify a 1 pixel wide dimension like this with the 150:151

Allow this behavior, have some priority to assign which axes a slice is taken/which dimension is removed.

Found a weird edge case, you can technically specify a 1 pixel wide dimension like this with the 150:151

Allow this behavior, have some priority to assign which axes a slice is taken/which dimension is removed.

Tried adding handling for this by converting excess integer indices into 1-width slices. This turned out to be more complex and hard to document. After discussion with the team we've decided not to handle these cases.


fix(deps): update terraform ibm to latest for deployable architectures

This PR contains the following updates:

Package
Type
Update
Change

ibm (source)
required_provider
patch
1.71.1 -> 1.71.2

Release Notes

IBM-Cloud/terraform-provider-ibm (ibm)
v1.71.2
Compare Source
Bugfixes

Tags support config aggregator & Bug fix for settings api (5783)
fix(partner center sell): fix patch nested fields (5785)

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

/run pipeline

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

GitHub release
v2.8.1

Your semantic-release bot :package::rocket:


Notification Center session tracking unreliable

Right now it tries to instrument a VTO in order to obtain visibility events from within a view.  This approach has proved unreliable.
Instead couple it with the containing activity's lifecycle.

Ah this was fixed long ago.