Secret Manager - Docker

Hey guys,
Any advice on best practices on using Secret Manager for local development and building with docker and running the container locally?

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

ID: 9c99993c-c983-6fda-6c3a-ce4ec8c1d5db
Version Independent ID: ba688ac2-e90e-fce5-f60d-40c2553c3efd
Content: Safe storage of app secrets in development in ASP.NET Core
Content Source: aspnetcore/security/app-secrets.md
Product: aspnet-core
Technology: aspnetcore-security
GitHub Login: @Rick-Anderson
Microsoft Alias: scaddie

You might try SO.


Allow automatic poison pill upgrade

Fixing Poison Pill Upgrade Bug
Setting olm.skipRange annotation will make sure older version (since 0.1.0) can be upgraded to the latest version.

/lgtm
/approve

/cherry-pick master

/cherry-pick master


Possible errors in eventlist.tsdl

I've discovered some possible errors in https://github.com/ARM-software/CMSIS-View/blob/main/tools/eventlist/docs/eventlist.tsdl while using this file as metadata, trying to open some CTF trace in Trace Compass.
I don't think I have permissions to make changes on this repo (can't create branch or pull request) so I am raising this issue instead.

Problem 1: Trace Compass could not understand trace type.
Solution 1: A plain-text metadata file must begin with /* CTF followed by the version number (1.8). So line 1 of this file should read /* CTF 1.8 */ (or similar). See https://diamon.org/ctf/#spec7.1 for details.

Problem 2: Trace Compass reported "ParseException: Type char has not been defined".
Solution 2: Added new type definition:
typealias integer {
    size = 8;
} := char;

(I assume size = 8 is correct)

Problem 3: Trace Compass reported "ParseException: Is not an integer: _info.length". Seems to be an issue with the EventRecordData struct line char data[_info.length];.
Solution 3: Currently unknown. Looking at the struct layouts, I think char data[_info._len.length]; is more correct, but still reports the same parse error "ParseException: Is not an integer: _info._len.length".

Regarding "Problem 3":
I have isolated the CTFTrace parser from the source code of Trace Compass (org.eclipse.tracecompass.ctf.core), so I can now fully debug the parsing of the metadata file.
When the parser reaches the expression _info.length, DeclarationScope.lookupIdentifierRecursive() does not resolve the first part of the identifier, _info.
This may be due to the nested structure of struct / variant v / struct EventRecordData. I will continue to investigate.

Looking at the examples here (https://diamon.org/ctf/#ex-minimal-packet-examples) I realise there is a lot more that's missing.
I temporarily replaced the offending expression _info.length with 1, as it seemed to be a distraction.
Added a minimal trace block:
trace {
    major = 1;
    minor = 8;
    byte_order = le;
};

Added an event block wrapping the main struct:
event {
    name = "trace_event";
    fields := struct {
        enum: uint16 { EventRecordData = 1, EventRecord2, EventRecord4 } tag;
        ...
    };
};

Now the TSDL parses correctly and the program attempts to open the CTF trace stream. Still doesn't work yet, but feels like some progress. I think the next steps may involve defining a packet header or something similar.

@SeanWoodArm - could you please update the issue with your latest findings. Do you have evidence for a bug in eventlist.tsdl or the way the format is stored/specified?

@SeanWoodArm, is this still relevant?

Apologies @jkrech, @JonatanAntoni, I turned off GitHub notifications so I have only just seen these comments.
This was related to some of the work I was doing while on secondment with OTG. I was investigating using Trace Compass / CTF for the Event Recorder feature in https://github.com/Arm-Debug/vscode-embedded-debug. I discovered that eventlist.tsdl does not strictly follow the CTF specification. However, this line of investigation was abandoned so I believe this is no longer relevant.

@SeanWoodArm, thanks for reporting back. Can you please double check and close this issue if appropriate?


License?

This repository lacks any licensing terms, or even a copyright statement. Is that intentional—because Mapzen intends to reserve all rights—or is it an oversight? I'm looking to deploy an instance of this, but it's not clear to me if that's permissible.

Oversight! MIT license, done:
https://github.com/mapzen/vector-datasource/commit/c96dcb542689b0f8c807cadc19629e799f3ae831
:)

:+1: Thank you!

If you have any questions about setting this up, let us know.


this.constructor is defined as "Function" resulting in property (static method name) does not exist on type 'Function'

this.constructor is defined as "Function" resulting in property (static method name) does not exist on type 'Function'.  My understanding is that "this.constructor" is the proper way to call a static method from an instantiated method.
TypeScript Version:  3.9.5

Search Terms:
"this.constructor" "property does not exist on type 'Function'"
Code
export ClassNameInterface {
  abstractMethod: ( classSpecificVariable: string ) => void;
}

export abstract class ClassName implements Partial< ClassNameInterface > {
  protected static method( classSpecificVariable ){
    this.abstractMethod();
  }
}

export class InheritedClassName implements ClassNameInterface {
  private classSpecificData = 'InheritedClassNameSpecificData'
  protected static abstractMethod( classSpecificVariable: string ){}
  public method(){
    return this.constructor.method( this.classSpecificData );
  }
}

Expected behavior:
this.constructor.method( this.classSpecificData ); is valid code
Actual behavior:
this.constructor.method( this.classSpecificData ); is highlighted as error.

Duplicate of https://github.com/microsoft/TypeScript/issues/3841


Configure 5th Edition OGL by Roll20 Companion API

Added Ammo Tracking
Added Spell Tracking
Added Death Save Tracking
Added !longrest [TOKENNAME]


[stable/fluentd] Use correct strategy for StatefulSets

What this PR does / why we need it:
Deployment object uses spec.strategy field to configure what happens when Pod template is updated. StatefulSet, however, uses spec.updateStrategy for the same purpose.
At the moment, if both .Values.autoscaling.enabled and .Values.persistence.enabled are true, the rendered manifest fails with
  Error: unable to build kubernetes objects from release manifest: error validating "": error validating data: [ValidationError(StatefulSet.spec): unknown field "strategy" in io.k8s.api.apps.v1.StatefulSet

This affects Helm 3. Helm 2 seems to rewrite strategy to updateStrategy.
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

Closing in favor of #20554


Expand read me

I added documentation about the documentLoader to the README, added information on key management services, and also removed a few TODOs. This is a DRAFT PR as I'm not sure on how good my understanding of this tech is.

The vc.createPresentation changes are using "type" and/or "suite" params, which I don't think exist?  Also consider the API changes in https://github.com/digitalbazaar/vc-js/pull/36.

The vc.createPresentation changes are using "type" and/or "suite" params, which I don't think exist? Also consider the API changes in #36.

it does check for type https://github.com/digitalbazaar/vc-js/blob/990151ae414dda77096cf732c1dd1045e71074c5/lib/vc.js#L318-L336
unless you explicitly pass in a full presentation yourself. The other PR can update the README with the changes when that happens.

Re type/suite, they are being passed to vc.createPresentation and are not documented options or used.  That snippet is checking a presentation object, not the options.

I think we should merge this documentation addition, and address @davidlehn's comments about the extendContextLoader in a separate issue.

@dmitrizagidulin @davidlehn 's concerns were addressed I added extendContextLoader to the example. @dlongley @davidlehn is it ok to rebase this into master?

Well... my concern was brushed over.  I think it's a wider problem and we can't sprinkle this sort of code everywhere.  As I was suggesting, I think the best solution is to just make jsigs do it's checks internally first, and then defer to whatever loader is passed in.  The newest code here is going to check jsigs loader, then the local app loader, then the jsigs loader again, then finally the default vc loader.  If that is going to be merged in please add an issue here and/or jsigs to correct this.

Well... my concern was brushed over. I think it's a wider problem and we can't sprinkle this sort of code everywhere. As I was suggesting, I think the best solution is to just make jsigs do it's checks internally first, and then defer to whatever loader is passed in. The newest code here is going to check jsigs loader, then the local app loader, then the jsigs loader again, then finally the default vc loader. If that is going to be merged in please add an issue here and/or jsigs to correct this.

not so sure brushed over is how I would have though of it, but yeah the example does result in duplicate calls to the same loader. It sounds like we need issue to discuss how loaders will resolve in general, but as it stands I think the example would be better than nothing or at least where the example started.


updated pkgs/applications/audio/sunvox/default.nix

Description of changes
updated version + zip URL + hash
(sunvox author had bumped the version and deleted the old URL)
Things done

Built on platform(s)

[v] x86_64-linux
[v] x86_64-darwin

[v] Tested basic functionality of all binary files (usually in ./result/bin/)

Done in #271789.


docs: fix typo in healthcare landing zone accelerator

Issue #, if available:
Description of changes:
Fixed a typo in a README
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Hello,
Thanks again for your contribution! This change is included in v1.4.0 of the solution.


Serbian language - update missing translations

Update _missing_translations_sr.json and _missing_translations_sr_Cyrl.json ( latin and cyrillic script )

Thanks!


[Event Request] codeunit 5940 ServContractManagement procedure CreateServHeader()

Please can you add the following event/code just before the call to Cust.CheckBlockedCustOnDocs as follows
OLD CODE...
Cust.CheckBlockedCustOnDocs(Cust, ServHeader2."Document Type", false, false);

NEW CODE...
IsHandled := false;
OnBeforeCheckBlockedCustOnDocsForServiceInvoice(ServHeader2, ServContract2, IsHandled);
if not IsHandled then
    Cust.CheckBlockedCustOnDocs(Cust, ServHeader2."Document Type", false, false);

The event publisher would be...
[IntegrationEvent(false, false)]
local procedure OnBeforeCheckBlockedCustOnDocsForServiceInvoice(var ServiceHeader: Record "Service Header"; ServContract2: Record "Service Contract Header"; var IsHandled: Boolean);
begin
end;

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 11061.


kilo and kibi for the same quantity

According to ISO 80000 defining International System of Quantities (ISQ):

The standard includes all SI prefixes as well as the binary prefixes kibi-, mebi-, gibi-, etc., originally introduced by the International Electrotechnical Commission to standardise binary multiples of byte such as mebibyte (MiB), for 10242 bytes, to distinguish them from their decimal counterparts such as megabyte (MB), for precisely one million (10002) bytes. In the standard, the application of the binary prefixes is not limited to units of information storage. For example, a frequency ten octaves above one hertz, i.e., 210 Hz (1024 Hz), is one kibihertz (1 KiHz).

(https://en.wikipedia.org/wiki/ISO/IEC_80000#Units_of_the_ISO_and_IEC_80000_series)
This collides with our current design of units. Right now we do not allow two different prefix families to be used for a quantity.
I am looking for ideas on how we should approach this issue.

Relates to #186,

I am looking for ideas on how we should approach this issue.

Wouldn't moving data units to isq work this out? As you've mentioned in another issue, data should be under isq.

IEC 80000 defines bit which can be used both with si::prefix and binary_prefix.

Additionally, according to https://en.wikipedia.org/wiki/ISO/IEC_80000#Units_of_the_ISO_and_IEC_80000_series:

In the standard, the application of the binary prefixes is not limited to units of information storage. For example, a frequency ten octaves above one hertz, i.e., 210 Hz (1024 Hz), is one kibihertz (1 KiHz).

Are you against moving the prefixes in data/prefixes.h to si/isq/prefixes.h?

No, this is not a problem. Currently, a names unit is defined as:
https://github.com/mpusz/units/blob/bbbb77286c03df3339b6a0b47145a4c618ac6759/src/include/units/unit.h#L94-L99
and it defines a prefix family designated to work with this specific unit.
A prefixed unit then has to provide a prefix from the same family:
https://github.com/mpusz/units/blob/bbbb77286c03df3339b6a0b47145a4c618ac6759/src/include/units/unit.h#L134-L140
It was meant to prevent exactly such issues but it seems there are some cases where the same unit (i.e. bit to hertz) can be used with prefixes from both families (SI and binary).

So, even though the data units should be moved to isq, their prefixes should continue to be of a different prefix family than si's prefixes?

Yes. The same applies to at least hertz.

We can try to fix it with some aliases or redefinitions of units but I do not think it is a proper solution. According to the ISO 80000, the same bit unit can be prefixed with a prefix of either family.

Until now I thought that those are defined by two separate standards and will effectively be different units in different namespaces.

You could solve it the value way. Add explicit ids to the prefix_family. For example, "si" and "si::data". Then, in addition to considering the same prefix family, consider that their qualified-id, if any, are the same. In this example, that'd be "si".

The main purpose to introduce prefix families was to not mix data and SI prefixes. As it seems we actually have to be able to mix those (and not only for the bit unit) then the need for such abstraction does not exist as there are no other commonly used prefix families.

Alternatively, we can put both decimal and binary prefixes to the same si family but again it removes the sense to have prefix family abstraction in the library.

Perhaps it makes sense to retain the prefix family. Consider the shipping prefix from https://mpusz.github.io/units/use_cases/extensions.html#enabling-a-unit-for-prefixing. Without a prefix family, otherwise identical prefixes from different libraries would clash.

Or maybe a named_unit should take a list of supported families?

After a longer thought, I decided to get rid of a prefix_family. Users should be allowed to specify their own prefixes and use them with any unit. If someone desires to create a prefix unit lorrybyte (https://mpusz.github.io/units/use_cases/extensions.html#enabling-a-unit-for-prefixing) it should be possible, even if for many others it does not have sense. It will also simplify the library as there will be fewer things to teach and learn....

Also, if SI does not specify prefixes for some units it does not mean that some users would not like to provide them so also no_prefix may be too limiting for some.


twitch-cli: 1.1.19 -> 1.1.20

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/project/twitch-cli/versions.
meta.description for twitch-cli is: The official Twitch CLI to make developing on Twitch easier
meta.homepage for twitch-cli is: https://github.com/twitchdev/twitch-cli
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 1.1.20 with grep in /nix/store/85d7lw7lxjvz02zrybz7xh325njvcp5x-twitch-cli-1.1.20
found 1.1.20 in filename of file in /nix/store/85d7lw7lxjvz02zrybz7xh325njvcp5x-twitch-cli-1.1.20

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
twitch-cli

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/85d7lw7lxjvz02zrybz7xh325njvcp5x-twitch-cli-1.1.20 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A twitch-cli https://github.com/r-ryantm/nixpkgs/archive/cac50294ee0211f15c40c65147ac9d59b5e135fe.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/85d7lw7lxjvz02zrybz7xh325njvcp5x-twitch-cli-1.1.20
ls -la /nix/store/85d7lw7lxjvz02zrybz7xh325njvcp5x-twitch-cli-1.1.20/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

twitch-cli

Maintainer pings
cc @BenediktBroich for testing.

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

1 package built:

twitch-cli


Howdy not working

Please describe the issue in as much detail as possible, including any errors and traces.
If your issue is a camera issue, be sure to also post the image generated by running sudo howdy snapshot.
How I wanted to run 'sudo howdy test' it appeared to me:
Traceback (most recent call last):   File "/usr/bin/howdy", line 109, in <module>     import cli.test   File "/usr/lib/security/howdy/cli/test.py", line 17, in <module>     config.read(path + "/../config.ini")   File "/usr/lib/python3.10/configparser.py", line 698, in read     self._read(fp, filename)   File "/usr/lib/python3.10/configparser.py", line 1086, in _read     raise MissingSectionHeaderError(fpname, lineno, line) configparser.MissingSectionHeaderError: File contains no section headers. file: '/usr/lib/security/howdy/cli/../config.ini', line: 5 'dismiss_lockscreen = true\n'

I've searched for similar issues already, and my issue has not been reported yet.
Linux distribution (if applicable): Manjaro Linux
Howdy version (sudo howdy version): 2.6.1

Your config file is malformed: "File contains no section headers."
Please fix the file yourself or purge and reinstall Howdy to get a fresh one


Simulinnewagent

moving tools to the multiagents branch.

im sorry what is this branch name??? Simulinnewagent??

haha it was my way of shortening "Simulation tools in the new agent scheme with the multiagents"


Train 193

#1724 ("Bumped the Mesos package to fix the Mesos web UI sandbox links.")
#1729 ("Added an --rpath to Mesos builds")
#1730 ("[1.10] Unregister node in epmd on start")
#1744 ("Bump to the latest marathon 1.5")

@mesosphere-mergebot bump-ee

Reviews on the branch itself are already welcome, but of course the CI result is decisive.


React Native - How to give this Curve Direction same as image

@nihgwu @msand @SpencerLynn @zgordon01 @kevkevinpal   I am trying to create a donut pie chart in react-native where curve should be in clock direction. I achieved most of it to fulfil the requirement using plugin https://github.com/nihgwu/react-native-pie but I am not finding a way to change the direction.
If anyone has played around with this component then please suggest the code changes to meet the expected UI.
anyone please help me

not sure worked on this a while ago but I'm pretty sure I only coded it for one direction since that's all we needed it for. Feel free to contribute if you figure out a way to make it go the other direction


CORE-15386 Modify ledger named queries main query to simplify post processing

Overview
The main query for ledger named queries has been modified so the post processing can be simpler.
Test plan
Existing unit, e2e tests. Testing the query manually for multiple database scenarios.

Change looks good to me.
Discussed with @nkovacsx to do similar changes to the findUnconsumedStates and resolveStates which will greatly simplify our code.

We may well change these as part of the multi-DB work anyway, but the SQL will be pretty much identical (assuming we use HQL instead of entities to find) so probably not wasted work.


Add patches to resolve CVE-2024-24786 in external-provisioner

Description of changes:
Fixes CVE-2024-24786
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/lgtm
/approve


Update and prepare for the 0.3.5 release.

Summary
This brings the ecms_patternlab to version 0.3.5, the ecms_profile to version 0.3.3 and prepares the changelog for the 0.3.5 tag.
Metadata

Question
Answer

Did you use a meaningful pull request title?
yes

Did you apply meaningful labels to the pull request?
yes

Did you perform a self review first?
yes

Documentation reflects changes?
no

CHANGELOG reflects changes?
yes

Unit/Functional tests reflect changes?
n/a

Did you perform browser testing?
no

Risk level
Low

Relevant links
RIG-6

Let it roll!
/approved


[v1.4.x] fix Makefile for rpkg (#13590)

Attempt to fix failing CI for R-Pkg on 1.4.x branch.
Cherry-picks : https://github.com/apache/incubator-mxnet/pull/13590
Sample failure : http://jenkins.mxnet-ci.amazon-ml.com/blue/organizations/jenkins/incubator-mxnet/detail/PR-14156/3/pipeline/

Did not fix the issue.


[IOTS-438] dm_enrollment table is not updated with the correct owner name on re-enrollment

dm_enrollment table is not updated with the correct owner name on re-enrollment.  Reproduction steps :  Enroll the first user to emm via ios agent (simon.elbaz) Disenroll the first user Enroll a second user on the same device via ios agent (kevin.fontaine) Current behavior : The table dm_enrollment is not updated with the correct owner : owner "simon.elbaz" The emm console doesn't display the correct user : owner "simon.elbaz" Expected behavior The table dm_enrollment should be updated with the correct owner. (kevin.fontaine) The emm console should display the correct owner "kevin.fontaine"Reference: https://wso2.org/jira/browse/IOTS-438

This is fixed and tested, hence closing


Change SignIn/SignUp for Register/SigIn

I feel that "SigIn" and "SignUp" are very confusing.
So I read this article and basically this is a little table resume about this:

I want to change this in my fork and make more easy for the user. Do you like to change it in the telescope project?

Lets see what the community think about this ;-)
...for your fork you might have a look at customizing the button texts

mmm...,
actually the AT forms already use register/sign in.
is it so only a problem with the nav bar?

I think it's a good change too :+1:

@splendido  About this, Can I change only the HTML or is necessary another change to implement it?

If you're referring to the nav bar, I guess it's only the text displayed there.
...is it picked up from this line?
Se perhaps it's only the i18n file to be updated?
...pushing it further on, we could set up the sign up route here to get the /register path:
AccountsTemplates.configureRoute('signUp', {
    path: '/register',
});

@splendido PR in #722 with the changes :-)

Lets see the comment about register/registering there.
...Btw, I'm not native English

Done :)


Verify local image with Cosign

Question
Hi,
I want to pull an image from a repo, and verify my locally pulled image in my local docker cache, NOT directly against the public repo.
Is that possible? I can't identify a CLI option to enable this?

A workflow like the following should accomplish much the same:
$ IMAGE=$(docker image inspect cgr.dev/chainguard/static -f '{{index .RepoDigests 0}}')
$ cosign verify $IMAGE --certificate-identity 'https://github.com/chainguard-images/images/.github/workflows/release.yaml@refs/heads/main' --certificate-oidc-issuer 'https://token.actions.githubusercontent.com'

Part of the issue is that pulling the image causes the digest to change, so you can't really verify the signatures against the local image.

Reading through that link, it seems that only images which use a v1 manifest will cause the digest to change.
What if there is a scenario where someone is performing a man-in-the-middle attack? By verifying the locally downloaded image, we can be sure that the image we downloaded is exactly the same as the image in the repo, and the exact image we were intended to download.
It's not too dissimilar to having yum use a GPG key to verify a package after it has been downloaded.

Reading through that link, it seems that only images which use a v1 manifest will cause the digest to change.

Lots of popular registries/images are still using v1 manifests:
$ docker pull alpine
$ docker image inspect alpine -f 'local={{.Id}} repo={{index .RepoDigests 0}}'
local=sha256:d74e625d91152966d38fe8a62c60daadb96d4b94c1a366de01fab5f334806239 repo=alpine@sha256:ff6bdca1701f3a8a67e328815ff2346b0e4067d32ec36b7992c1fdc001dc851

In general, your local Docker daemon functions quite different from a registry; most of the tricks Cosign uses to, e.g., store signatures require the full registry API. I'm personally optimistic that most of the standardization work in OCI will move us in the direction of enabling Cosign-like workflows directly on your local Docker (or Podman) daemon but that will take some time.

What if there is a scenario where someone is performing a man-in-the-middle attack? By verifying the locally downloaded image, we can be sure that the image we downloaded is exactly the same as the image in the repo, and the exact image we were intended to download.

Docker digests help with that: if you pull by digest, you get integrity checking during download. So the workflow:

resolve digest
check signature
pull by digest

will handle MITM attacks.

It's not too dissimilar to having yum use a GPG key to verify a package after it has been downloaded.

But isn't it better not to download the bad package in the first place? You can verify a signature over an artifact digest, and only then download the artifact. If the digest doesn't match (due to MITM or some other condition), you can reject the artifact during download.
This is how The Update Framework (TUF) handles this issue and it has a couple nice side-effects: one is that if an image pull completes successfully, we know that the signature was verified. So you don't have to figure out which local images are/are not trusted.

To be clear, we've left this issue open because we agree with you that there should be better workflows for local Docker images with Cosign. Don't interpret my arguing as trying to defend the status quo, just explaining why we haven't (1) prioritized this workflow (there are passable workarounds, and in a Kubernetes context, which has been a big focus thus far, a registry-centric verification flow works) and (2) why it's not a straightforward matter to implement.
Unfortunately we've got to work with the reality of how Docker is implemented, and if we recommend a workflow that doesn't work a large portion of the time that's worse than nothing IMO. We're hopeful that future work in OCI will make the situation a little better: https://github.com/sigstore/cosign/issues/2516
CCing my resident OCI experts to see if they have any ideas for how to make this better: @sudo-bmitch @jdolitsky @imjasonh

Thanks for the detailed information @znewman01.
I will review and come back if I have any further questions :)

Commenting to ensure the stale label gets removed.

Commenting to ensure the stale label gets removed.

Lots of popular registries/images are still using v1 manifests:
$ docker pull alpine
$ docker image inspect alpine -f 'local={{.Id}} repo={{index .RepoDigests 0}}'
local=sha256:d74e625d91152966d38fe8a62c60daadb96d4b94c1a366de01fab5f334806239 repo=alpine@sha256:ff6bdca1701f3a8a67e328815ff2346b0e4067d32ec36b7992c1fdc001dc851

There might be some confusion here. Everything uploaded to Hub has been on v2 manifests for quite a long while now, a lot of registries are phasing out v1 support entirely. That's separate from the docker v2 to OCI media type transition that's been happening lately in tools like buildkit.
The image ID in docker is the digest of the config blob. It's unique since it contains the layer digests, but one level too low for cosign. The RepoDigest is the one you want. It's tracking the hash of the image on the registry, and it's a list since you may have pushed/pulled from multiple registries, and there may be a few digests for the manifest list and the separate platform specific manifest. Docker started tracking this a while back and it's reasonable for cosign to depend on it for any docker specific workflows.
$ docker pull alpine
...

$ docker image inspect alpine -f 'local={{.Id}} repo={{index .RepoDigests 0}}'
local=sha256:7e01a0d0a1dcd9e539f8e9bbd80106d59efbdf97293b3d38f5d7a34501526cdb repo=alpine@sha256:7144f7bab3d4c2648d7e59409f15ec52a18006a128c733fcff20d3a4a54ba44a

$ crane manifest alpine@sha256:7144f7bab3d4c2648d7e59409f15ec52a18006a128c733fcff20d3a4a54ba44a | jq .mediaType
"application/vnd.docker.distribution.manifest.list.v2+json"

In general, your local Docker daemon functions quite different from a registry; most of the tricks Cosign uses to, e.g., store signatures require the full registry API. I'm personally optimistic that most of the standardization work in OCI will move us in the direction of enabling Cosign-like workflows directly on your local Docker (or Podman) daemon but that will take some time.

You wouldn't be able to sign an image locally (though I'd really like to get there). But you can verify that a local image is the same as the one on the registry and verify or sign that image on the registry using the RepoDigest value in docker.


chore: pydantic fastapi upgrade

What type of PR is this? (check all applicable)

[x] Refactor
[x] Feature
[ ] Bug Fix
[x] Optimization
[ ] Documentation Update
[ ] Community Node Submission

Have you discussed this change with the InvokeAI team?

[x] Yes
[ ] No, because:

Description
feat(api): chore: pydantic & fastapi upgrade
Upgrade pydantic and fastapi to latest.

pydantic~=2.4.2
fastapi~=103.2
fastapi-events~=0.9.1

Big Changes
There are a number of logic changes needed to support pydantic v2. Most changes are very simple, like using the new methods to serialized and deserialize models, but there are a few more complex changes.
Invocations
The biggest change relates to invocation creation, instantiation and validation.
Because pydantic v2 moves all validation logic into the rust pydantic-core, we may no longer directly stick our fingers into the validation pie.
Previously, we (ab)used models and fields to allow invocation fields to be optional at instantiation, but required when invoke() is called. We directly manipulated the fields and invocation models when calling invoke().
With pydantic v2, this is much more involved. Changes to the python wrapper do not propagate down to the rust validation logic - you have to rebuild the model. This causes problem with concurrent access to the invocation classes and is not a free operation.
This logic has been totally refactored and we do not need to change the model any more. The details are in baseinvocation.py, in the InputField function and BaseInvocation.invoke_internal() method.
In the end, this implementation is cleaner.
Invocation Fields
In pydantic v2, you can no longer directly add or remove fields from a model.
Previously, we did this to add the type field to invocations.
Invocation Decorators
With pydantic v2, we instead use the imperative create_model() API to create a new model with the additional field. This is done in baseinvocation.py in the invocation() wrapper.
A similar technique is used for invocation_output().
Minor Changes
There are a number of minor changes around the pydantic v2 models API.
Protected model_ Namespace
All models' pydantic-provided methods and attributes are prefixed with model_ and this is considered a protected namespace. This causes some conflict, because "model" means something to us, and we have a ton of pydantic models with attributes starting with "model_".
Forunately, there are no direct conflicts. However, in any pydantic model where we define an attribute or method that starts with "model_", we must tell set the protected namespaces to an empty tuple.
class IPAdapterModelField(BaseModel):
    model_name: str = Field(description="Name of the IP-Adapter model")
    base_model: BaseModelType = Field(description="Base model")

    model_config = ConfigDict(protected_namespaces=())

Model Serialization
Pydantic models no longer have Model.dict() or Model.json().
Instead, we use Model.model_dump() or Model.model_dump_json().
Model Deserialization
Pydantic models no longer have Model.parse_obj() or Model.parse_raw(), and there are no parse_raw_as() or parse_obj_as() functions.
Instead, you need to create a TypeAdapter object to parse python objects or JSON into a model.
adapter_graph = TypeAdapter(Graph)
deserialized_graph_from_json = adapter_graph.validate_json(graph_json)
deserialized_graph_from_dict = adapter_graph.validate_python(graph_dict)

Field Customisation
Pydantic Fields no longer accept arbitrary args.
Now, you must put all additional arbitrary args in a json_schema_extra arg on the field.
Schema Customisation
FastAPI and pydantic schema generation now follows the OpenAPI version 3.1 spec.
This necessitates two changes:

Our schema customization logic has been revised
Schema parsing to build node templates has been revised

The specific aren't important, but this does present additional surface area for bugs.
Performance Improvements
Pydantic v2 is a full rewrite with a rust backend. This offers a substantial performance improvement (pydantic claims 5x to 50x depending on the task). We'll notice this the most during serialization and deserialization of sessions/graphs, which happens very very often - a couple times per node.
I haven't done any benchmarks, but anecdotally, graph execution is much faster. Also, very larges graphs - like with massive iterators - are much, much faster.
Related Tickets & Documents
I'm sure there are some that are indirectly related but can't think of them.
QA Instructions, Screenshots, Recordings
This definitely needs thorough smoke testing.
You'll need to update with pip install -e ".[dev,test]" to test this.
Added/updated tests?

[x] Yes
[ ] No

This PR is ready for review and testing.
The whole application should function exactly as it did before (albeit a bit faster). There are no new features or user-facing behaviour changes, but there is a good amount of internal logic changed to accomodate pydantic v2.

Please do not update this branch by merging main into it. It will likely break the branch.

Let's get this in!


Create playbook for deployment

Start with a single simple playbook.
It should create the basic resources for the deployment.

:tada: This issue has been resolved in version 1.0.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


caboose, eclectical (logical-conflict)

This pull request was generated by the 'mq' tool

/trunk merge


Make CLASS optional?

One short-term fix to the CLASS distribution/installation issue could be to make calls to CLASS optional, e.g. through a preprocessor directive: This would allow casual CCL users to check out the functionality of CCL (except for getting power spectra from CLASS), and while keeping the full functionality for users who already have CLASS installed/are willing to install it for CCL.
In practice, it would be possible to modify ccl_power.c such that include "class.h", and routines from "ccl_free_class_structs" through "ccl_cosmology_compute_power_class" are optionally included, with an alternate version for "ccl_cosmology_compute_power_class" that raises an exception if CCL attempts to call CLASS when it is not linked.
This would be very simple to implement on the C level. @damonge, do you know whether it would be an easy modification to autotools to check whether CLASS is installed, and set the preprocessor directive accordingly?
Please comment if you think this is bad style, or can think of a better short-term solution!

PR #295, which has an independent installation script for CLASS, has now been merged. It's slightly different than the approach suggested here, but it solves our license (PR #231) issues. Should we close this issue then?

Agreed. We'll leave this open for now.

Once the python integration is done, this should be supported.


feat(all): add ruff as default linter and additional clean up

🗒 Description
Pre-dominantly adds ruff as our default linter to replace flake8, black & isort. Extra clean-up items are mentioned below.
🧑💻 .vscode
The settings.recommended.json has be split into 2 files:

settings.json: locked config that users of the repo MUST use.
.settings.local.recommended.json: settings that users can change, for example python testing extension related.

💥 Removal of tf
It seems relevant for us to deperate tf now. Most repo users are familiar with the uv fill etc approach now.
📜 Ruff Related Docstring Changes
A large portion of the diff comes from changes to the python docstrings, via:

One-line docstring should fit on one lineRuff D200
First line of docstring should be in imperative mood: "Handles all fill CLI flag pre-processing."Ruff D401
First line should end with a periodRuff D400

✅ Fixes to noqa: and TODO:
Those that can be fixed now are updated!

With a new linter its seems logical to enforce python docstring standards from now on. Note the warnings appear within VSCode and additionally when running tox.
🔗 Related Issues
https://github.com/ethereum/execution-spec-tests/issues/811
✅ Checklist

[ ] All: Set appropriate labels for the changes.
[ ] All: Considered squashing commits to improve commit history.
[ ] All: Added an entry to CHANGELOG.md.
[ ] All: Considered updating the online docs in the ./docs/ directory.

@spencer-tb could we rebase this to main please? I think it would make it easier to spot issues in the CI if we include the fixes from #905


SVG content is not centered/correctly panned when scale is < 1

Hello.
As you can see in this jsfiddle:
https://jsfiddle.net/pLhb419u/
... when the scale amount is < 1, the svg is resized in the left top corner. Is there a way to fix this (or at least a work around) so to see the picture resized at the mouse position or at least centered?
Thanks for your great work!

Thank you. You're right. I will try to fix it.

v0.3.0 has been released to fix this bug. Please give it a try.

Hello. Doesn't work yet in this way: when scale is < 1 you can't pan the drawing.
Check this:
https://jsfiddle.net/rqcn8vo5/1/
Also: I suggest you to add borders in your examples, both in the drawing and in the container. Otherwise it's impossible to figure what's happening.
Also: I suggest you to have a look at this:
https://github.com/timmywil/panzoom
with the 'overflow' property set, which creates scrollbars. It will help you in understanding how to manage the discussed case

OK, panning is implemented when scale < 1 on v0.4.0. Thank you.


Degeneracies for 180 degree rotations

Currently many solvers are degenerate for exactly 180 degree rotations. This should either be fixed, or at least documented.

In case a degeneracy is observed, you could randomly rotate the scene and run the solver again.

Which solver are degenerate for these rotations? I think the ones using cayley parametrization should be ok by contruction, right?

Most of the solvers that rely on the 3Q3 solver degenerates for exactly 180 degree rotations. This seems to be mostly a problem with synthetic data, as shifting the GT rotation by some epsilon (I tried 0.001 radians), seems to fix it.
You can try this by adding
pose.R << -1.0, 0.0, 0.0, 0.0, -1.0, 0.0, 0.0, 0.0, 1.0;
to setup_random_pose in the benchmarking code. I think the problem partly stems from the automatic variable selecting in RE3Q3 not working as intended.
Adding a random rotation should fix the problem as well. I will do some testing with this to see how much of performance loss it is. If you force affine change of variables in the 3Q3 code it also becomes stable, though I think this should be more expensive, so I will benchmark this as well.

I added a random rotations for all RE3Q3 solvers (see f0ca0d076d3ede9730dfece05890e120f46684a8). There is some runtime penalty, but I think it is an acceptable trade-off. Possibly we could add compile-time flags to disable it later.
There is still an issue with the upright solvers that rely on the Weierstrass substitution to parameterize the rotations. I will implement the same for these later.

This seems to be solved, expect for upright solvers for which there is another issue #7


Cow: Watch thesimpleindian.com

Cow requests the watch of the watch_keyword thesimpleindian\.com. See the MS search here and the Stack Exchange search in text, in URLs, and in code.

thesimpleindian\.com has been seen in 1 true positive, 0 false positives, and 0 NAAs.

Approved by Nick in Charcoal HQ


Please make it more visible what is source and what is target

Hi,
I always find myself coming back to check if source is the server or is it target.
Please make it more visible/TL;DR.
Best thing would be if add tooltips in VS.

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

ID: e2e2ddbb-512d-fe28-55c2-bfc4ff8aad73
Version Independent ID: 9b7770d7-7f5d-3cb7-c619-a5cd23b5da09
Content: Resolve Git merge conflicts - Azure Repos
Content Source: docs/repos/git/merging.md
Product: devops
Technology: devops-code-git
GitHub Login: @apawast
Microsoft Alias: sdanie

It looks like you've encountered an issue with the product itself, rather than an issue with the documentation. To make sure it gets in front of the right people, please submit your bug here.


Requirements

Description
(Originally taken from: Requirements google doc)
Zulip Terminology Stream Text Mining Project
Base Zulip bulletin board application is supported by a REST API that can be interrogated (?) via Python scripts.  Bots can be configured via Python to provide real-time monitoring as well. Text mining of the terminology stream in the FHIR Zulip community bulletin board to discover trends regarding use of terminologies and terminology services within the HL7 FHIR community.
Objective of this exercise is to review the history of the content and activity Terminology stream.
Task list

[ ] 1. Code systems: counts and date ranges
[ ] 2. HL7 Product families: counts and date ranges
[ ] 3. FHIR terminology resources: counts and date ranges
[ ] 4. FHIR terminology operations: counts and date ranges
[ ] 5. Indicators of JIRA activity: counts and date ranges
[ ] 6a. Average length of threads
[ ] 6b. Identify outlier threads in terms of length
[ ] 6c. Threads lacking adequate resolution
[ ] 6d. Frequency variance
[ ] 6e. Activity variance

Task details
(Refer to for more info, especially for 1-5: Requirements google doc)
6a. Average length of threads
Determine average length (in days / wells / months) in terminology stream threads.
6b. Identify outlier threads in terms of length
Identify outliers in length - longer running threads
Possible solutions:
For this, can aggregate all thread lengths (i.e. in terms of number of messages) and report 2 different classes of identifiers: (i) 1 standard deviation away from norm, and (ii) 2 standard deviations.
6c. Threads lacking adequate resolution
Identify those topics with (i) many responses (not necessarily with longer length, but will likely be one of these as well) that (ii) do not have some sort of resolution.  Will require iterative review with SME (Davera or others)
Possible solutions:
(i) Many responses: Can potentially be defined as 1 standard deviation away from mean.
(ii) Lacking resolution: This would likely be too time consuming to automate; so should go with suggestion of SME review. However, we could programmatically automate / aid this analysis, perhaps, by re-reading the analytical output. The output (likely a CSV file) could have 1+ codified curator columns, where data will be manually entered by SMEs. Then, that information could be re-read if further programmatic analysis is needed.
6d. Frequency variance
For each of the count categories (1-4) above, when is the occurrence of these topics, when are they more frequent / less frequent
6e. Activity variance
Date-base counts for all topics indicating activity levels: when is the stream more active / less active
Additional info
Links

Requirements google doc
Chat URL: http://chat.fhir.org
Zulip API docs: https://zulip.com/api/rest

@DaveraGabriel FYI

We will assign this task to Rohan Hurer.

#example of nlp keyword search that might be useful:
get_ipython().system('pip3 install --user nltk flashtext')
nltk.download('punkt')
from flashtext import KeywordProcessor
keyword_processor = KeywordProcessor()
keyword_dict = {
"codesystem": ["DICOM","SNOMED", "LOINC", "ICD10CM", "ICD10PCS", "NDC", "RxNorm" ],
"HL7Productfamilies": ["CDA", "C-CDA", "V3", "Version3"],
"TerminologyResources": ["ConceptMap", "CodeSystem","ValueSet","Terminology Service","TerminologyCapabilities", "NamingSystem", "Coding", "Code", "CodeableConcept"],
"Operations": ["$lookup", "$validate-code", "$subsumes", "$find-matches", "$expand", "$validate-code", "$translate", "$closure"]
}
keyword_processor.add_keywords_from_dict(keyword_dict)
keyword_processor.extract_keywords('zulip activities based on code system, HL7Product family, Terminology Resources and Operations')

options
query topics one a a time: [, , ...]
query  topics after concatenating them together: <all_topics>


Yield options instead of options[:label] for label_text

This gives more flexibility when overriding label_text
E.g.
config.label_text = lambda { |label, required, options| label_text =  "#{required} #{label}"; options[:icon] ? fa_icon(options[:icon], :text => label_text) : label_text }

The old explicit_label functionality can still be used
config.label_text = lambda { |label, required, options| explicit_label = options[:label].present? }
``

Thank you so much for the pull request. Unfortunately this is a breaking change and I don't see a compiling reason to accept it. It is already possible to do what you want using a custom label component and I think this is the way to go.

Thanks for the feedback. I was trying to find a way to what I need to do using a custom component as you suggested but I couldn't find a clean way to do it.
I want to use all of labels I18n lookup functionality, but add an icon with the translation text as the label. This worked fine before when I had the html for the label and icon directly in the translation yml files. However simple_form now escapes this html.
I need the following HTML:
*  អ៊ីម៉ែល

Basically I just need to replace the translated email text with:  អ៊ីម៉ែល
This would work perfectly if I could set config.label_text = lambda { |label, required, options| label_text =  "#{required} #{label}"; options[:icon] ? fa_icon(options[:icon], :text => label_text) : label_text }.
Failing that how can I cleanly use a custom label component with all the same functionality as the built in label component?

You can either open the label component and change the label_text method as your wish or you can create a new component that includes the actual label component and inherit all the behavior.

Ok so I have to monkey patch label_text or make a new component and include the actual label component. If I make a new label component then I have to create a new wrapper that contains exactly the same content as the label wrapper and replace ba.use :label with ba.use :custom_label. This just seems a bit overkill when we have the label_text lambda.
I like the idea of the label_text lambda which can be overridden for this exact purpose. It would just be better if we could yield to it with the options instead of options[:label].present?. Anyway I understand that this is a potentially breaking change if people have overridden this block in their applications.
Would you accept the pull request if I add options as a 4th argument and check the arity of the proc before calling it?

In fact I regret for not having options as the third argument since the beginning. But using a wrapper based config like a custom component seems better to me that using a global config like label_text.
If we can think in a good deprecation strategy I'm more willing to merge the PR changing the third argument to be options @carlosantoniodasilva WDYT?

For a deprecation strategy, we could call the proc with the options as the third arguement, catch any exception, show a deprecation warning and then call it again with the old options[:label].present?. Thoughts?

Well, I'm gonna this PR. Case this still an issue and someone wants to work on it, feel free to reopen.


Bevy Log Output to Files

What problem does this solve or what need does it fill?
Bevy log can output to console, but I don't know of a way to easily output this to the filesystem as well.
It seems to me that this would be a common use case, where an app could log what happens to a file for later inspection (especially if it crashes for some reason).
What solution would you like?
I'm imagining an interface something like this:
// Either use a RollingFileAppender that you can configure yourself, or just simply output to some path...
// Maybe someone can think of better options...
enum FileLogger {
    Rolling(RollingFileAppender),
    Path(PathBuf),
}

app.insert_resource(LogSettings {
    ...
    file: vec![
        "log1".into(),
        tracing_appender::rolling::hourly("logs", "log_prefix").into(),
    ]
});

where log output would be duplicated in the console and all FileLogger configurations.
What alternative(s) have you considered?
I currently have a working workaround in an app where I disabled the LogPlugin, and substituted my own that's exactly the same except that I replaced the let subscriber... line with:
let file_appender = tracing_appender::rolling::hourly("logs", "log"); // This should be user configurable
let (non_blocking, worker_guard) = tracing_appender::non_blocking(file_appender);
let file_fmt_layer = tracing_subscriber::fmt::Layer::default()
    .with_ansi(false) // disable terminal color escape sequences
    .with_writer(non_blocking);
app.insert_resource(worker_guard); // have to keep this from being dropped

let subscriber = subscriber.with(fmt_layer).with(file_fmt_layer);

So it'd be nice if this were built in so I don't have to duplicate the LogPlugin code.

Since Bevy delegates logging to the tracing and tracing-subscriber crates (at least, on most platforms), shouldn't implementing tracing sinks/subscribers best left to user code, and instead Bevy to expose what's necessary for users to do so?
It seems that implementing file logging internally in Bevy is opening the door to more asks in the same vein (logging to networked file, logging to remote networked host, logging to syslogd, etc.), with all the variants/options each user may want for their app. Not to mention the extra per-platform work.
I'm not disagreeing file logging is needed (I agree that's important to have), but rather how we get there. Instead of the proposed approach, can we rather expose what's necessary for you @samcarey or someone else to simplify writing a file output customized to your use case? What is LogPlugin missing or what is it doing that forced you to avoid/replace it? Is it a matter of exposing the underlying tracing object(s)?

Exposing what's necessary would work for me!
In order to factor out my file-logging-specific code, I could imagine having a field on the LogSettings struct like extra_layers: Vec<tracing_subscriber::fmt::fmt_layer::Layer>.
Then the LogPlugin could do something like
for layer in settings.extra_layers.iter() {
    subscriber = subscriber.with(layer);
}

Would that interface be general enough to cover most other cases like you mentioned?

I would like to be able to add arbitrary layers to Bevy's tracing subscriber. While logging to files is nice, I would also like to direct trace messages to the console, for example. In that sense, #5342 would be insufficient...

An alternative might be to raise an event on trace.

I'm also interested!

This isn't wholly complete just yet, but the ability to customize the subscriber (added in #10822) seems to allow for this.


feat(web): 404 page

Current dependencies on/for this PR:

main

PR #68   👈

This stack of pull requests is managed by Graphite.

Merge activity

Dec 11, 12:17 AM: @@ToastedDev started a stack merge that includes this pull request via Graphite.


Cannot run homebridge with webos.tv plugin

Hi everybody,
Can anyone help with issue on raspberry pi? I am trying to configure and run homebridge with webos-tv plugin on my raspberry pi, but without success. I still get an error:
TypeError: Cannot read property 'indexOf' of undefined
at API.accessory (/usr/local/lib/node_modules/homebridge/lib/api.js:50:11)
at Server._loadAccessories (/usr/local/lib/node_modules/homebridge/lib/server.js:297:42)
at Server.run (/usr/local/lib/node_modules/homebridge/lib/server.js:91:38)
at module.exports (/usr/local/lib/node_modules/homebridge/lib/cli.js:59:10)
at Object. (/usr/local/lib/node_modules/homebridge/bin/homebridge:17:22)
at Module._compile (module.js:569:30)
at Object.Module._extensions..js (module.js:580:10)
at Module.load (module.js:503:32)
at tryModuleLoad (module.js:466:12)
at Function.Module._load (module.js:458:3)
Any ideas, how to solve this, or what is wrong?
Thanks a lot to everyone!!

I do not think that this has anything to do with this plugin. At least the error which you posted does not look like that...

Solved now. Mixture of mistakes made. Thanks.


Change default environment variable behaviour

Resolves #45

Moves environment variable configuration from set-env.sh to environment-variables in the root of the repository
Updates to all scripts to include change
Updates to documentation for Cluster creation with new tables for variables, including variable name, description and default values
Adds content to "Before you begin" describing the default cluster deployment configuration, and how to update

/gcbrun

Prechecks Complete - Ready for review

/gcbrun

Please run the terraform fmt command against the /terraform/cluster_build directory and then resubmit the Pull Request. It is required that terraform fmt be executed against all Terraform configuration files in order to provide consistency across the repo.

/gcbrun

Prechecks Complete - Ready for review

Will re-open


fix: increase name after timeout

Seeing this timeout on multiple environments and Node.js versions so have given it an extra 5s.
Also increases the browserNoActivityTimeout to give the dht.query test time to fail but pass anyway - previously the browserNoActivityTimeout wasn't taking into account the extra 60s allocated to the before hook, so I just added it here.

Sorry @diasdavid jenkins seems to be running these tests again...they passed here before I submitted the PR https://ci.ipfs.team/blue/organizations/jenkins/IPFS%2Fjs-ipfs-api/detail/fix%2Fincrease-name-after-timeout/2/pipeline - hopefully they'll pass again!

go-ipfs PubSub still doesn't love us:

I'm hoping it does now with the upgrade to interface-ipfs-core


Use Unix-Sockets instead of TCP via localhost

Could save CPU-Cycle and allow a nicer namespace

Has anybody an idea how to configure gstreamer to accept a IPC socket as source?

replacing the command TCP connection with an IPC socket was easy: I've created IPCSingleConnection and IPCMultiConnection which work mostly like the TCP pendants
also could manage ffmpeg to send output to ICP sockets with the unix:// prefix in output the URI

voctocore accepts the ffmpeg output via ICPSingleConnection which forwards the data via fdsrc to the gstreamer pipeline. That seem to work - like before with TCP.
The voctogui however is using tcpclientsrc directly in the gstreamer pipeline which I currently can not replace by a IPC source.
I think I will have to use IPCSingleConnection in voctogui as well and then hand the read data into gstreamer using an 'fdsrc' like the core is doing it.
Any better ideas, any suggestions?

I don‘t know if this would be useful at all. As far as I can tell, the TCP Stack on modern Kernels is so efficient (especially when communicating via loopback), that there‘s no gain in using ipc or unix sockets.
I would suggest to just close this issue.

Really? Quite possible, but I would prefer to do a simple test with two pipelines connected via TCP vs. ICP to get some evidence.

Sidenote: we have seen high levels of interrupts (see itop). While I would be surprised if they went down significantly when switching to Unix sockets, it's also another thing worthy of investigation. The number of interrupts. not CPU usage, seems to be the bottleneck in some scenarioes.

My :fire: CPU :fire: burns when using voctomix! But I'll take a look into itop.
Thinking in long terms: What about a voctogui which starts it's own internal voctocore in a local situation? With a little rearranging of code it should be easy to just implement a complete pipeline from the sources to the outputs without any TCP or ICP between. That may save context switches.

You can reduce the resolution to 192x108 Pixels or even lower. I often do this during development.
I don’t see a benefit from merging the two together, at least not in a c3voc-style setup.

I don’t see a benefit from merging the two together, at least not in a c3voc-style setup.

I see.

"""
We wanted a small videomixer core-process, whose sourcecode can be read and
understand in about a weekend. All Sources (Cameras, Slide-Grabbers) and
Sinks (Streaming, Recording) should be separate Processes..... All sources
and sinks should be able to die and get restarted without taking the core
process down.
"""
https://github.com/voc/voctomix/tree/master/voctocore#design-goals
Keeping it rock solid is important.   More important than running on slower
CPUs.
On Wed, Apr 25, 2018 at 8:50 AM, Patrick Hoffmann<EMAIL_ADDRESS>wrote:

I don’t see a benefit from merging the two together, at least not in a
c3voc-style setup.
I see.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/voc/voctomix/issues/38#issuecomment-384293971, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AABauUflcsM0oEV1x0560UHVptbmyF9lks5tsH9AgaJpZM4G8ASP
.

--
Carl K

@danimo said Sidenote: we have seen high levels of interrupts (see itop).
My theory is that they result from the de-/interleave-elements and the resulting higher number of queue-elements required for the multi-audio setup. I think this might get better when we would incorporate the GstInterpipe-Elements, which can handle multiple audio streams natively. I'll document my current findings in #58 and would encourage to continue this discussion over there.

When do you think the RidgeRun Interpipes should replace inter tcpip connections?

this thread is kind of outdated. The pipline was rewritten in the meantime and we have no interpipes anymore.
Currently this also means we have no recoonects on TCP inputs which we hope to address by SRT inputs.
Can you describe shortly your usecase for the TCP sources, i would love to have requirements for future dev

I've been successful in implementation use of the recent fallbacksrc plugin (from the rust plug-ins). Now on a loss or dropped connection, a video image (uri) is displayed until the source is reestablished. I added a urlsource. Handles http, rstp sources and possibly SRT. Internally it uses the uridecode3 plugin and sone magical pad probe and other pad related switching.
I've removed the no signal code from AV source.

@SonnyWalkman Thank you for your comment. That fallbacksrc plugin might or might not help our headless tcp source use case at https://fosdem.org !

No worries,
I can post a code snippet. The only issue I have is when the main source drops and switches to fallback uri, I get warning from fallbacksrc. I need to workout how to silence there red warnings.


First task

-registered roles in graphql
-modified user schema
-created guard
Signed-off-by: niesyto<EMAIL_ADDRESS>First enounter with backend, so it's probably not correct, created draft pull request just to show I'm intrested in this project, just more with frontend tasks

Thanks for draft! Glad you are interested, I will not make any comments to your code now, if it's all right with you. The second task will include frontend.


Play song from Album feature

It would be great to have a feature to play a specific song from an album as multiple versions of same song can be in different albums.
I can see that song by artist is present and album by artist.
An intent for song from album would be good alternative if not able to find the song by artist.

Hey,
I think that's a great idea and I'll look at adding it in.  Thanks for the suggestion!


[keyvault] - sync 7.3 stable changes to 7.4-preview.1

This PR manually syncs 7.3 stable into 7.4-preview.1 branch
Changelog
Add a changelog entry for this PR by answering the following questions:

What's the purpose of the update?

[ ] new service onboarding
[ ] new API version
[ ] update existing version for new feature
[ ] update existing version to fix swagger quality issue in s360
[ ] Other, please clarify

When are you targeting to deploy the new service/feature to public regions? Please provide the date or, if the date is not yet available, the month.
When do you expect to publish the swagger? Please provide date or, the the date is not yet available, the month.
If updating an existing version, please select the specific language SDKs and CLIs that must be refreshed after the swagger is published.

[ ] SDK of .NET (need service team to ensure code readiness)
[ ] SDK of Python
[ ] SDK of Java
[ ] SDK of Js
[ ] SDK of Go
[ ] PowerShell
[ ] CLI
[ ] Terraform
[ ] No refresh required for updates in this PR

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of "no breaking changes"
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

Applicability: :warning:
If your changes encompass only the following scenarios, you should SKIP this section, as these scenarios do not require ARM review.

Change to data plane APIs
Adding new properties
All removals

Otherwise your PR may be subject to ARM review requirements. Complete the following:

[ ] Check this box if any of the following apply to the PR so that label "WaitForARMFeedback" will be added automatically to begin ARM API Review. Failure to comply may result in delays to the manifest.

Adding a new service
Adding new API(s)
Adding a new API version
-[ ] To review changes efficiently, ensure you are using OpenAPIHub to initialize the PR for adding a new version. More details, refer to the wiki.

[ ] Ensure you've reviewed following guidelines including ARM resource provider contract and REST guidelines. Estimated time (4 hours). This is required before you can request review from ARM API Review board.

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If any of the following scenarios apply to the PR, request approval from the Breaking Change Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in a stable version
[ ] Removing properties in a stable version
[ ] Removing API version(s) in a stable version
[ ] Updating API in a stable or public preview version with Breaking Change Validation errors
[ ] Updating API(s) in public preview over 1 year (refer to Retirement of Previews)

Action: to initiate an evaluation of the breaking change, create a new intake using the template for breaking changes. Addition details on the process and office hours are on the Breaking change Wiki.
Please follow the link to find more details on PR review process.

Swagger comparison between stable/7.3 in main and your PR: https://portal.azure-devex-tools.com/tools/diff/eyJzb3VyY2VVcmwiOiJodHRwczovL2dpdGh1Yi5jb20vQXp1cmUvYXp1cmUtcmVzdC1hcGktc3BlY3MvYmxvYi9tYWluL3NwZWNpZmljYXRpb24va2V5dmF1bHQvZGF0YS1wbGFuZS9yZWFkbWUubWQiLCJ0YXJnZXRVcmwiOiJodHRwczovL2dpdGh1Yi5jb20vbWFvcmxlZ2VyL2F6dXJlLXJlc3QtYXBpLXNwZWNzL2Jsb2IvYWxpZ24tcHJldmlldzEtd2l0aC1tYWluL3NwZWNpZmljYXRpb24va2V5dmF1bHQvZGF0YS1wbGFuZS9yZWFkbWUubWQiLCJzb3VyY2VUYWciOiJwYWNrYWdlLTcuMyIsInRhcmdldFRhZyI6InBhY2thZ2UtcHJldmlldy03LjQtcHJldmlldy4xIn0=

@lmazuel can you help merge this? The python SDK generation isn't reporting back status. Though, @weshaggard or @kurtzeborn, looking at the checks - which all completed - it seems this might be another case of an older branch (this was created a while ago) requiring a check that no longer exists by the name it was known. Could you also just fix the branch policy to not require this seemingly absent pipeline? I could then merge, or feel free while  you're in here.


Plans to move away from Skype desktop API?

Hi @RReverser,
I setup hubot-skype4com today and it works great. I got this message, however, in the Skype client...

Clicking the link to the FAQs takes you to https://support.skype.com/en/faq/FA12349/skype-says-my-application-will-stop-working-with-skype-in-december-2013-why-is-that, which says that they are retiring the Skype Desktop API at the end of 2013.
As a result of this, do you have any plans on switching to Skype URIs or some other way of getting Hubot to communicate with Skype?

Can you tell the alternative of skype4com? They have rewritten the latest version with electron and this API does not work with the new version.

sfm222: Did you get any alternative of Skype4com?


CONT MAINT: Revise when and how to use astropy Tables

During the workshop at aas240 multiple participants run into the issue of when to convert a list of services to an astropy table. This practically means to review when to use the list comprehensions in our example sets as they e.g. kept doing following those examples to create lists of individual services but then they lose the option of to_table(), OTOH if they convert it to a Table they may lose access to some of the metadata.

I think addressing https://github.com/astropy/pyvo/issues/477 would take away some of the confusions we run into at that previous workshop, so I would suggest considering closing this once that issue is fixed upstream.

To my knowledge this hasn't been raised again by a participant, and we indeed cleaned up the repr confusion between astropy and pyvo. So I'm inclined to close the issue, but please reopen if this or similar questions come up again at the workshop.


enable async/await on handlers ( old school )

Same as the other pull request to allow async handlers for express.
This one is a simple old school solution in case support for older versions is needed...

Thanks! Because this would be a breaking change (folks are currently returning promises from handlers and not expecting that they will next() on reject), can you reimplement this against the 5.0 branch and open a new PR?


Redirect quickstart.html

closes #536

Waiting for "linters and checkers" run (but not full test, obvs.)


Issues witk k8s 1.28

Hi!,
Maybe someone can help me, I've update my k8s homelab to version 1.28.1 (from 1.27.4) and I'm getting the following error on pods that rely on HPE CSI driver:
MountVolume.MountDevice failed for volume "pvc-b6b9bb0e-a422-49d8-a79a-3034d1a719c1" : kubernetes.io/csi: attacher.MountDevice failed to create newCsiDriverClient: driver name csi.hpe.com not found in the list of registered CSI drivers
Looking at the CSI node pod I see the following:
I0829 13:23:31.219372       1 main.go:166] Version: v2.6.1
I0829 13:23:31.219406       1 main.go:167] Running node-driver-registrar in mode=registration
I0829 13:23:31.219794       1 main.go:191] Attempting to open a gRPC connection with: "/csi/csi.sock"
I0829 13:23:31.219814       1 connection.go:154] Connecting to unix:///csi/csi.sock
I0829 13:23:33.325192       1 main.go:198] Calling CSI driver to discover driver name
I0829 13:23:33.325203       1 connection.go:183] GRPC call: /csi.v1.Identity/GetPluginInfo
I0829 13:23:33.325205       1 connection.go:184] GRPC request: {}
I0829 13:23:33.328070       1 connection.go:186] GRPC response: {"name":"csi.hpe.com","vendor_version":"1.3"}
I0829 13:23:33.328107       1 connection.go:187] GRPC error:
I0829 13:23:33.328112       1 main.go:208] CSI driver name: "csi.hpe.com"
I0829 13:23:33.328128       1 node_register.go:53] Starting Registration Server at: /registration/csi.hpe.com-reg.sock
I0829 13:23:33.328254       1 node_register.go:62] Registration Server started at: /registration/csi.hpe.com-reg.sock
I0829 13:23:33.328303       1 node_register.go:92] Skipping HTTP server because endpoint is set to: ""
I0829 13:23:33.674712       1 main.go:102] Received GetInfo call: &InfoRequest{}
E0829 13:23:33.674741       1 main.go:107] "Failed to create registration probe file" err="open /var/lib/kubelet/plugins/csi.hpe.com/registration: no such file or directory" registrationProbePath="/var/lib/kubelet/plugins/csi.hpe.com/registration"
I0829 13:23:33.674748       1 main.go:109] "Kubelet registration probe created" path="/var/lib/kubelet/plugins/csi.hpe.com/registration"
I0829 13:23:33.711252       1 main.go:120] Received NotifyRegistrationStatus call: &RegistrationStatus{PluginRegistered:true,Error:,}
CIS controller logs:
I0829 13:21:48.488722       1 feature_gate.go:245] feature gates: &{map[]}
I0829 13:21:48.488765       1 csi-provisioner.go:150] Version: v3.3.0
I0829 13:21:48.488770       1 csi-provisioner.go:173] Building kube configs for running in cluster...
I0829 13:21:48.489029       1 connection.go:154] Connecting to unix:///var/lib/csi/sockets/pluginproxy/csi.sock
I0829 13:21:49.489960       1 common.go:111] Probing CSI driver for readiness
I0829 13:21:49.489971       1 connection.go:183] GRPC call: /csi.v1.Identity/Probe
I0829 13:21:49.489974       1 connection.go:184] GRPC request: {}
I0829 13:21:49.492126       1 connection.go:186] GRPC response: {}
I0829 13:21:49.492160       1 connection.go:187] GRPC error:
I0829 13:21:49.492166       1 connection.go:183] GRPC call: /csi.v1.Identity/GetPluginInfo
I0829 13:21:49.492167       1 connection.go:184] GRPC request: {}
I0829 13:21:49.492520       1 connection.go:186] GRPC response: {"name":"csi.hpe.com","vendor_version":"1.3"}
I0829 13:21:49.492542       1 connection.go:187] GRPC error:
I0829 13:21:49.492553       1 csi-provisioner.go:217] Detected CSI driver csi.hpe.com
I0829 13:21:49.492559       1 connection.go:183] GRPC call: /csi.v1.Identity/GetPluginCapabilities
I0829 13:21:49.492561       1 connection.go:184] GRPC request: {}
I0829 13:21:49.492965       1 connection.go:186] GRPC response: {"capabilities":[{"Type":{"Service":{"type":1}}}]}
I0829 13:21:49.493028       1 connection.go:187] GRPC error:
I0829 13:21:49.493034       1 connection.go:183] GRPC call: /csi.v1.Controller/ControllerGetCapabilities
I0829 13:21:49.493036       1 connection.go:184] GRPC request: {}
I0829 13:21:49.493460       1 connection.go:186] GRPC response: {"capabilities":[{"Type":{"Rpc":{"type":1}}},{"Type":{"Rpc":{"type":2}}},{"Type":{"Rpc":{"type":3}}},{"Type":{"Rpc":{"type":5}}},{"Type":{"Rpc":{"type":6}}},{"Type":{"Rpc":{"type":7}}},{"Type":{"Rpc":{"type":8}}},{"Type":{"Rpc":{"type":9}}}]}
I0829 13:21:49.493732       1 connection.go:187] GRPC error:
I0829 13:21:49.493776       1 csi-provisioner.go:286] CSI driver supports PUBLISH_UNPUBLISH_VOLUME, watching VolumeAttachments
I0829 13:21:49.494197       1 controller.go:732] Using saving PVs to API server in background
I0829 13:21:49.494354       1 reflector.go:221] Starting reflector *v1.PersistentVolumeClaim (15m0s) from k8s.io/client-go/informers/factory.go:134
I0829 13:21:49.494364       1 reflector.go:257] Listing and watching *v1.PersistentVolumeClaim from k8s.io/client-go/informers/factory.go:134
I0829 13:21:49.494375       1 reflector.go:221] Starting reflector *v1.VolumeAttachment (1h0m0s) from k8s.io/client-go/informers/factory.go:134
I0829 13:21:49.494384       1 reflector.go:257] Listing and watching *v1.VolumeAttachment from k8s.io/client-go/informers/factory.go:134
I0829 13:21:49.494458       1 reflector.go:221] Starting reflector *v1.StorageClass (1h0m0s) from k8s.io/client-go/informers/factory.go:134
I0829 13:21:49.494464       1 reflector.go:257] Listing and watching *v1.StorageClass from k8s.io/client-go/informers/factory.go:134
I0829 13:21:49.594383       1 shared_informer.go:285] caches populated
I0829 13:21:49.594405       1 shared_informer.go:285] caches populated
I0829 13:21:49.594410       1 shared_informer.go:285] caches populated
I0829 13:21:49.594417       1 controller.go:811] Starting provisioner controller csi.hpe.com_debian-k8s_1b5149f8-ad9c-40d7-960e-4f4fa491b433!
I0829 13:21:49.594441       1 volume_store.go:97] Starting save volume queue
I0829 13:21:49.594467       1 clone_controller.go:66] Starting CloningProtection controller
I0829 13:21:49.594502       1 clone_controller.go:82] Started CloningProtection controller
I0829 13:21:49.594538       1 reflector.go:221] Starting reflector *v1.PersistentVolume (15m0s) from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:845
I0829 13:21:49.594549       1 reflector.go:257] Listing and watching *v1.PersistentVolume from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:845
I0829 13:21:49.594566       1 reflector.go:221] Starting reflector *v1.StorageClass (15m0s) from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:848
I0829 13:21:49.594575       1 reflector.go:257] Listing and watching *v1.StorageClass from sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:848
I0829 13:21:49.694728       1 shared_informer.go:285] caches populated
I0829 13:21:49.694801       1 controller.go:860] Started provisioner controller csi.hpe.com_debian-k8s_1b5149f8-ad9c-40d7-960e-4f4fa491b433!
I0829 13:28:56.596768       1 reflector.go:559] sigs.k8s.io/sig-storage-lib-external-provisioner/v8/controller/controller.go:848: Watch close - *v1.StorageClass total 8 items received
I0829 13:29:00.500862       1 reflector.go:559] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.VolumeAttachment total 8 items received
It was working fine with 1.26 & 1.27.
Thank you!

Looking at the CSI node pod I see the following:

Can you check the CSI driver pod. This is the log for the registrar, which looks ok.
I've tested v1.28 so it shouldn't be a problem. What does kubectl get csidrivers look like?

"kubectl get csidrivers" looks good to me:

I'm attaching the hpe-csi-driver log which is quite big.
hpe-csi-driver.log
Thank you!

This is peculiar. I haven't seen this before and the logs doesn't reveal any clues. Can you do a restart of the controller and node driver? kubectl rollout restart -n hpe-storage ds/hpe-csi-node deploy/hpe-csi-controller and see if it bites? If you create a new new PVC, does the same issue persist?

Yes, really strange. I might have messed up something without knowing it. Restarting the controller did not help but creating new PVCs seems to work.
Thanks again for your support!

I've been playing around a little more and now I come to the following on the CSI driver:
time="2023-08-29T23:29:11Z" level=error msg="GRPC error: rpc error: code = Internal desc = Failed to stage volume Data_K8s_pvc-375cf244-c723-40a0-bc6d-59a9631a8564, err: rpc error: code = Internal desc = Error creating device for volume Data_K8s_pvc-375cf244-c723-40a0-bc6d-59a9631a8564, err: device not found with serial 6589cfc000000b3f51a0d014e297a74f or target " file="utils.go:73"
I deleted reinstalled TrunasCSP from scratch and deleted al PVCs. After that I provisioned a single PVC as a test on k8s version 1.27.4. All looks good so far, deleting the pod get's it recreated and claimind the existing PVC.
It seems that the problem starts after upgrading to 1.28.1. Rolling back to a previous snapshot of the k8s VM (v 1.27.5) also manifests the above issue. The PVC is the same, before and after the upgrade so there should be no mismatch there, at least from the TrueNAS/Storage side.

The message err: device not found with serial 6589cfc000000b3f51a0d014e297a74f  indicates that the worker node is unable to find the mpath device on the node. The CSI node log you attached prior did not have these messages so maybe that was from a different node in the cluster?

It really sounds odd, given there are no finalizers. Keep this thread
posted.
On Wed, Aug 30, 2023, 6:47 AM msilcher @.***> wrote:

Strange thing is that I'm working on a single node lab. Also on version
1.28 pods that have PVCs attached get stuck on "terminating" when I delete
them (no "finalizers" are holding them back, I checked). I'll continue to
investigate as it is probably something related to my specific scenario.
—
Reply to this email directly, view it on GitHub
https://github.com/hpe-storage/truenas-csp/issues/43#issuecomment-1699224035,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVTK2E3T3YRDAHNTY33YR3XX475JANCNFSM6AAAAAA4C65TT4
.
You are receiving this because you commented.Message ID:
@.***>

New issue with small disks (100Mb):
MountVolume.MountDevice failed for volume "pvc-e5eac187-be0f-48a7-9a26-0bedef795b8a" : rpc error: code = Internal desc = Failed to stage volume Data_K8s_pvc-e5eac187-be0f-48a7-9a26-0bedef795b8a, err: failed to mount device /dev/mapper/mpatht, Error creating filesystem xfs on device with serialNumber 6589cfc00000020ddc79c3a1c9beeaa2, unable to create filesystem: xfs with args [/dev/mapper/mpatht]. Error: command mkfs.xfs failed with rc=1 err=specified blocksize 4096 is less than device physical sector size 8192 switching to logical sector size 512 Filesystem must be larger than 300MB. Usage: mkfs.xfs /* blocksize / [-b size=num] / config file / [-c options=xxx] / metadata / [-m crc=0|1,finobt=0|1,uuid=xxx,rmapbt=0|1,reflink=0|1, inobtcount=0|1,bigtime=0|1] / data subvol / [-d agcount=n,agsize=n,file,name=xxx,size=num, (sunit=value,swidth=value|su=num,sw=num|noalign), sectsize=num / force overwrite / [-f] / inode size / [-i perblock=n|size=num,maxpct=n,attr=0|1|2, projid32bit=0|1,sparse=0|1,nrext64=0|1] / no discard / [-K] / log subvol / [-l agnum=n,internal,size=num,logdev=xxx,version=n sunit=value|su=num,sectsize=num,lazy-count=0|1] / label / [-L label (maximum 12 characters)] / naming / [-n size=num,version=2|ci,ftype=0|1] / no-op info only / [-N] / prototype file / [-p fname] / quiet / [-q] / realtime subvol / [-r extsize=num,size=num,rtdev=xxx] / sectorsize / [-s size=num] / version */ [-V] devicename  is required unless -d name=xxx is given.  is xxx (bytes), xxxs (sectors), xxxb (fs blocks), xxxk (xxx KiB), xxxm (xxx MiB), xxxg (xxx GiB), xxxt (xxx TiB) or xxxp (xxx PiB).  is xxx (512 byte blocks).
I used the same manifests some time ago without issues, maybe new versions of TrueNAS (or Debian) complain now. Not really critical though.

You can specify a different filesystem, ext3/ext4 has less overhead IIRC.

Regarding the original issue, it seems related to cri-o 1.28.0. I did a test upgrading k8s to 1.281 but staying with previous cri-o version (1.27.1) and there are no issues. After upgrading cri-o 1.27.1 to 1.28.0 problems start. I've attached a extract of the kubelet log where I see "unmount" issues. Besides unmount issues, which I belive is related to the pods stuck in terminating, I also observe that pods mount volumes but do not see any data on them (as they were starting from scratch).
I'll keep digging.
kubelet.log

Also seeing this on csi-provisioner log:
E0902 16:27:40.008434       1 controller.go:1512] delete "pvc-c6271b5f-fbbd-4e5d-8a49-9b624fa2f1ae": volume deletion failed: persistentvolume pvc-c6271b5f-fbbd-4e5d-8a49-9b624fa2f1ae is still attached to node debian-k8s
E0902 16:27:40.008434       1 controller.go:1512] delete "pvc-75a3aca1-9f49-4c87-a1d0-292c7ee14199": volume deletion failed: persistentvolume pvc-75a3aca1-9f49-4c87-a1d0-292c7ee14199 is still attached to node debian-k8s
W0902 16:27:40.008459       1 controller.go:989] Retrying syncing volume "pvc-c6271b5f-fbbd-4e5d-8a49-9b624fa2f1ae", failure 8
E0902 16:27:40.008473       1 controller.go:1007] error syncing volume "pvc-c6271b5f-fbbd-4e5d-8a49-9b624fa2f1ae": persistentvolume pvc-c6271b5f-fbbd-4e5d-8a49-9b624fa2f1ae is still attached to node debian-k8s

Did you manage to resolve this? TrueNAS CSP v2.4.0 have a good track record on v1.28.

No, I narrowed it down to cri-o 1.28.x but not luck so far. I ended up reporting the bug but no feedback so far (https://github.com/cri-o/cri-o/issues/7308).
I tested the new HPE CSI driver 2.4.0 (togheter with TruenaNAS 2.3.10) but the issue persists, downgrading cri-o to 1.27.1 and recreating the PVCs fixes the issue.
All is related to a "not emty directory" which provokes the provisioner not to release the volume, therefore the pod stays forever in terminating state:
kubernetes.io/csi: Unmounter.TearDownAt failed to clean mount dir [/var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io-csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount]: kubernetes.io/csi: failed to remove dir [/var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io-csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount]: remove /var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io~csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount: directory not empty

Is there anything in the actual directory or is there a race condition?
On Tue, Oct 10, 2023, 1:34 AM msilcher @.***> wrote:

No, I narrowed it down to cri-o 1.28.x but not luck so far. I ended up
reporting the bug but no feedback so far (cri-o/cri-o#7308
https://github.com/cri-o/cri-o/issues/7308).
I tested the new HPE CSI driver 2.4.0 (togheter with TruenaNAS 2.3.10) but
the issue persists, downgrading cri-o to 1.27.1 and recreating the PVCs
fixes the issue.
All is related to a "not emty directory" which provokes the provisioner
not to release the volume, therefore the pod stays forever in terminating
state:
kubernetes.io/csi http://kubernetes.io/csi: Unmounter.TearDownAt failed
to clean mount dir
[/var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io-csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount]:
kubernetes.io/csi http://kubernetes.io/csi: failed to remove dir
[/var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io-csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount]:
remove
/var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io
http://kubernetes.io~csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount:
directory not empty
—
Reply to this email directly, view it on GitHub
https://github.com/hpe-storage/truenas-csp/issues/43#issuecomment-1754695701,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABVTK2BTSQUPVVHDACOQ37TX6UCCZAVCNFSM6AAAAAA4C65TT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJUGY4TKNZQGE
.
You are receiving this because you commented.Message ID:
@.***>

Is there anything in the actual directory or is there a race condition?
…
On Tue, Oct 10, 2023, 1:34 AM msilcher @.> wrote: No, I narrowed it down to cri-o 1.28.x but not luck so far. I ended up reporting the bug but no feedback so far (cri-o/cri-o#7308 <cri-o/cri-o#7308>). I tested the new HPE CSI driver 2.4.0 (togheter with TruenaNAS 2.3.10) but the issue persists, downgrading cri-o to 1.27.1 and recreating the PVCs fixes the issue. All is related to a "not emty directory" which provokes the provisioner not to release the volume, therefore the pod stays forever in terminating state: kubernetes.io/csi http://kubernetes.io/csi: Unmounter.TearDownAt failed to clean mount dir [/var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io-csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount]: kubernetes.io/csi http://kubernetes.io/csi: failed to remove dir [/var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io-csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount]: remove /var/lib/kubelet/pods/9e70d42e-fead-4c03-900f-e0f0fe61e64e/volumes/kubernetes.io http://kubernetes.io~csi/pvc-4c72b78c-5333-49bb-8061-28f545a48f89/mount: directory not empty — Reply to this email directly, view it on GitHub <#43 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABVTK2BTSQUPVVHDACOQ37TX6UCCZAVCNFSM6AAAAAA4C65TT6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJUGY4TKNZQGE . You are receiving this because you commented.Message ID: @.>

I recall there was a single file related to the "mount config" or something similar. I really need to check again but I'm on a business trip for the whole week. I could confirm in a few days though.

Just as a follow up: the issue is related to cri-o in its latest versions. They have proposed a fix which will come out in the next version (https://github.com/cri-o/cri-o/issues/7308 & https://github.com/cri-o/cri-o/pull/7428).
I've tested it with a patched static build they provided and it works fine!
Thanks!!

Please re-open if it resurface.


Can you add a watch for animation events in children elements

I found an interesting issue... Lets say I have two side by side areas Main Area (A) and Sidebar (B). A & B have match height applied to them.
However inside A, is an FAQ list. It simply lists out a number of questions, but the answers are set to display:none in css.
When the user clicks on a question, the answer calls jquery slideDown(). This changes the height of the content in A. But since A had the height explicitly set, it doesn't change.
Can you simply add another watch for any of the child elements completing an animation, and resize again?
Something to the effect of...
$(":animated").promise().done(function() {
matchHeight._update(true, event);
});

+1

+1  We have a hidden child div that appears on hover that is taller than the parent container.  It would rock if we could set the height of the child div that is hidden by display: none

@bitlost Can anyone provide some jsfiddle examples of your use case?
@mikezielonka Hidden children should already be supported by the plugin, is that not working?

I'll leave this up for a while if someone wants to take a look - https://goo.gl/IFL6hc
The main content area and sidebar are using matchheight. If you click on the form send button without filling any fields, a hidden message will appear and slide over the footer text.
I might just try and disable matchheight for certain screen widths as I only need it when the sidebar becomes absolutely positioned, but it should show the issue.


Nesting layouts

Is there a way to nest a layout inside of another? For example:
default.hsb
-- postLayoout.hbs
---- {{{body}}}

Thanks in advance.

Not that's built into this package. You'd have to do this manually using partials and/or block helpers.
What's different between your default.hbs and postLayout.hbs layouts?

The postLayout.hbs has some specific UI elements just for a page that has a post. So, the article would be yield in that postLayout. The postLayout then would be yield in the default layout (the actual page with the doctype, header and footer

@omarfouad Hey, did you mange to nest the layouts like you desired? I am trying the same, any tips on how this can be done? Thanks!

@Ghosh No, I used an alternative called here: https://github.com/barc/express-hbs

+1. Nesting is a good thing.


WOCCatalog: Location: Latitude/Longitude figures are swapped

Open WOCCatalog app in x86 and select Location. Allow for precise location.
Expected: appropriate latitude/longitude
Actual: Latitude and longitude are swapped.
Redmond output example:

@andrejo-msft - is this a regression?

LOL.
@rajsesh-msft I don't think this is a regression: check out the code!
        [locVal setText:[NSString stringWithFormat:@"Longitude: %.3f        Latitude: %.3f        ",
                                                   location.coordinate.latitude, location.coordinate.longitude]];

Yup. It's just a problem that we appear to have missed with our eyes for a while.

@DHowett-MSFT So, switch the variables or the text? Here is an interesting read:
http://stackoverflow.com/questions/7309121/preferred-order-of-writing-latitude-longitude-tuples


nvs: implement Non-volatile Storage cache

It's an attempt to solve performance issues which we observe when using Settings over NVS: https://github.com/zephyrproject-rtos/zephyr/issues/45591.
The NVS data lookup time grows linearly with the number of allocation table entries to walk through, meaning that if
some data pair in the NVS changes frequently, access to other data pairs that change rarely can take a lot of time.
It is particularly visible when the NVS is used as the settings backend since the backend needs to perform multiple NVS reads to find a requested key.
Implement a simple cache that stores an address of the most recent ATE for all NVS IDs that fall into the given cache
position. CRC8/16 is used as a hash function used to distribute NVS IDs across the cache entries.
The cache entries are only invalidated when an NVS sector is erased as part of the garbage collector task.
Signed-off-by: Damian Krolik<EMAIL_ADDRESS>

@Laczen I added unit tests for the change. They helped me discover that the previous code was missing skipping 0xffff ids. Please take another look.

@Laczen I added unit tests for the change. They helped me discover that the previous code was missing skipping 0xffff ids. Please take another look.

Nice, good that you added the unit tests. For me the proposed PR is ok, to avoid having to revisit the PR I will add the approval after maintainers have reviewed.
@nvlsianpu, @de-nordic, could you have a look?


Android: NFC can lock up in addNdefFormatableListener after a write

This may be user error since I cannot find an example of how to transform NdefFormatable tags into Ndef tags.
I modified the provided Ionic read example to listen instead for addNdefFormatableListener and in that callback wrote a record out to turn it into an Ndef format tag.  This first sequence is successful. That NFC tag will be Ndef and will have the correct record.
Repeat these steps with another NFC tag that is NdefFormatabe, you get a beep but no callback. In the code snippet below, no In callback alert will be fired the second time, and NFC is now no longer working on the device. Other tools, such as "NFC Tools" will no longer work. You have to turn off NFC, wait, then turn it back on. So perhaps there's user error by me in what can be done in this callback and this is not the correct way to change it to Ndef format.
It was easy to return an Ndef tag to an NdefFormatable one again by using the Format memory option in the NFC Tools Android application.
Thanks for the library, it's been great for my Live Action Roleplaying sign-in application on iOS and Android.
phonegap-nfc 1.0.4 "NFC"
        $ionicPlatform.ready(function() {
            nfc.addNdefFormatableListener(function (nfcEvent) {
              alert('In callback ' );
              console.log(JSON.stringify(nfcEvent.tag, null, 4));
              $rootScope.$apply(function(){
                  angular.copy(nfcEvent.tag, tag);
                  // if necessary $state.go('some-route')
              });
              var message = [
                ndef.uriRecord("https://google.com")
              ];
              nfc.write(message, function(ok) {
                alert('Write ok' );
              }, function(error) {
                alert('Write error ' + JSON.stringify(message));
              });
        }, function () {
              console.log("Listening for NdefFormatable Tags.");
          }, function (reason) {
              alert("Error adding NFC Listener " + reason);
          });

        });

With Android you need to have multiple listeners to do this. Use both addNdefListener and addNdefFormattableListener. Android will call the most specific listener for the tag. It's also ok to use one function to handle events from both callbacks.
FWIW the listener functions don't work well with the Ionic wrappers since the error can be called multiple times. IMO you're much better off using the callbacks directly for this.
You might be able to do everything using readerMode with one observable. I'll be adding wrappers for readerMode to Ionic soon.

Thanks @don


Unidata 17.1.1 windows

What is the purpose of this PR?  I believe the three commits you are attempting to merge from unidata_17.1.1-windows already exist in unidata_17.1.1.

You may disregard that.  That was an error on my part.
Thanks,
Allan
On Mon, Mar 19, 2018 at 8:09 AM Michael James<EMAIL_ADDRESS>wrote:

What is the purpose of this PR? I believe the three commits you are
attempting to merge from unidata_17.1.1-windows already exist in
unidata_17.1.1.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/Unidata/awips2/pull/213#issuecomment-374205636, or mute
the thread
https://github.com/notifications/unsubscribe-auth/Abn2zUBeekO7_awW2Ba9O_2fUKCEZO2bks5tf64NgaJpZM4SvkPx
.

--
Richard A Diegan III


But why do I set img_dim: to 32 and image_size to 256? AssertionError: Input height (42) doesn't match model (32). Isn't that the 32 pixels I'm expected to enter? Why did I change to 32 and expect me to enter 42?

Here is the code in my configuration file. Why does img_dim: set to 32 and image_size to 256 cause this problem? AssertionError: Input height (42) doesn't match model (32). Then I set img_dim: to 42 and image_size to 256, which results in an AssertionError: Input height (32) doesn't match model (42). What is the reason for this?The code's not working. Can you help me? Thank you so much!
train_steps: 10 #400_000
sample_vis_n: 1
video_frames: 0
batch_size: 1 #20
image_size: 256 #1024
num_classes: -1
target: model_zigma.ZigMa
params:
img_dim: 32
in_channels: 4
patch_size: 2
embed_dim: 768
depth: 24
scan_type: zigzagN8

Here is the code in my configuration file. Why does img_dim: set to 32 and image_size to 256 cause this problem? AssertionError: Input height (42) doesn't match model (32). Then I set img_dim: to 42 and image_size to 256, which results in an AssertionError: Input height (32) doesn't match model (42). What is the reason for this?The code's not working. Can you help me? Thank you so much! train_steps: 10 #400_000 sample_vis_n: 1 video_frames: 0
batch_size: 1 #20 image_size: 256 #1024 num_classes: -1
target: model_zigma.ZigMa params: img_dim: 32 in_channels: 4 patch_size: 2 embed_dim: 768 depth: 24 scan_type: zigzagN8

These are my run instructions：accelerate launch  --num_processes 1 --num_machines 1  --mixed_precision fp16    train_acc.py  model=s1024_zigzag8_b2_old  use_latent=0   data=facehq_1024  ckpt_every=10_000 data.sample_fid_n=5_000 data.sample_fid_bs=4 data.sample_fid_every=10_000  data.batch_size=1   note=_

image_size: 256
img_dim: 32
image_size should alwasy be 8x of the img_dim, this is the requirement from the AutoEncoder.

image_size: 256 img_dim: 32
image_size should alwasy be 8x of the img_dim, this is the requirement from the AutoEncoder.

Yes, I set it like this: image_size: 256; img_dim: 32. But why is this a problem? AssertionError: Input height (42) doesn't match model (32). Is there something I'm not doing right? Thanks for answering!

We follow previous works: LDM, please check taht paper for details:
https://github.com/CompVis/latent-diffusion

We follow previous works: LDM, please check taht paper for details:
https://github.com/CompVis/latent-diffusion

Thanks for your answer. I'll check it out


reconfiguring postal after install

I've already installed postal. However now I made some changes to postal.yml file. I dont know how can I reconfigure it now.

After changes have been made to the config file, you will have to restart Postal to get it to apply.
I think you can use postal restart from the command line.