text:
Apply license header and checkstyle

This applies Gradle plugins to apply license header and checkstyle. License header and IntelliJ / checkstyle config are copied from the AWS SDK.
Most code changes are license addition and whitespace. Sometimes, I cleaned up code that otherwise would cause checkstyle to fail, e.g.,

private ObjectMapper mapper = ... -> private static final ObjectMapper MAPPER =
Deprecate utility classes without a private constructor. While it's really unlikely that users call them, it's not impossible so we should fix in a major release. As these utilities are for the SDK they should be internal anyways so just went ahead and deprecated them. We'll probably deprecate a lot more stuff that users probably don't use in an effort to reduce surface for v3.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thanks - while waiting on the license plugin, I went ahead and disabled it for now. Enabling license is quite simple and automated while checkstyle is much harder so will go ahead and merge just that in for now to prevent drift.

source: gharchive/pull-request

repo: aws/aws-xray-sdk-java

license_type: permissive

license_source: github-api


text:
When controller downloads new bundle, state is not set

Fresh install of the package controller and it downloaded a new bundle and did not set the state to inactive
% k get packages,packagebundles,packagebundlecontrollers -A
NAMESPACE       NAME                                               STATE
eksa-packages   packagebundle.packages.eks.amazonaws.com/v1-21-8
eksa-packages   packagebundle.packages.eks.amazonaws.com/v1-22-5   active (upgrade available)

some error messages in log, not sure if they matter, maybe the webhook just hadn't started yet
1.6523846470133932e+09	ERROR	controller.packagebundlecontroller	Reconciler error	{"reconciler group": "packages.eks.amazonaws.com", "reconciler kind": "PackageBundleController", "name": "eksa-packages-bundle-controller", "namespace": "eksa-packages", "error": "creating new package bundle: Internal error occurred: failed calling webhook \"vpackagebundle.kb.io\": Post \"https://eks-anywhere-packages-eks-anywhere-packages-webhook-service.eksa-packages.svc:443/validate-packages-eks-amazonaws-com-v1alpha1-packagebundle?timeout=10s\": dial tcp 10.110.224.24:443: connect: connection refused"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
1.6523846474863873e+09	ERROR	controller.packagebundlecontroller	Reconciler error	{"reconciler group": "packages.eks.amazonaws.com", "reconciler kind": "PackageBundleController", "name": "eksa-packages-bundle-controller", "namespace": "eksa-packages", "error": "creating new package bundle: Internal error occurred: failed calling webhook \"vpackagebundle.kb.io\": Post \"https://eks-anywhere-packages-eks-anywhere-packages-webhook-service.eksa-packages.svc:443/validate-packages-eks-amazonaws-com-v1alpha1-packagebundle?timeout=10s\": dial tcp 10.110.224.24:443: connect: connection refused"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227
1.65238464794669e+09	ERROR	controller.packagebundlecontroller	Reconciler error	{"reconciler group": "packages.eks.amazonaws.com", "reconciler kind": "PackageBundleController", "name": "eksa-packages-bundle-controller", "namespace": "eksa-packages", "error": "creating new package bundle: Internal error occurred: failed calling webhook \"vpackagebundle.kb.io\": Post \"https://eks-anywhere-packages-eks-anywhere-packages-webhook-service.eksa-packages.svc:443/validate-packages-eks-amazonaws-com-v1alpha1-packagebundle?timeout=10s\": dial tcp 10.110.224.24:443: connect: connection refused"}
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem
	sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:266
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	sigs.k8s.io/controller-runtime@v0.11.1/pkg/internal/controller/controller.go:227

source: gharchive/issue

repo: aws/eks-anywhere-packages


text:
Support multi-version doc site

What would you like to be added: Support multi-version doc site
Why is this needed:
Currently, our doc site only supports single version (see screenshot below).

However, I would like to request multi-version support for a couple reasons:

from supporting customer perspective: while we roll out newer versions, our doc site will also get updated to drop off out-of-date contents, while they can still be beneficial to many users;
from UI perspective: when I see a version drop-down button like above, I expect it to be a list of versions that I can select from.

Duplicate of https://github.com/aws/eks-anywhere/issues/1729. Updated 1729 description and closed this issue.

repo: aws/eks-anywhere


text:
failed govc validations: GOVC_URL is not  set or is empty: false

What happened:
$export EKSA_VSPHERE_USERNAME="eksa@vsphere.local"
$export EKSA_VSPHERE_PASSWORD='********'
$ eksctl anywhere create cluster --filename prod-dc1-mgmt-eksa-cluster.yaml -v 9
2024-11-01T17:32:10.157ZV6Executing command{"cmd": "/usr/bin/docker version --format {{.Client.Version}}"}
2024-11-01T17:32:10.190ZV6Executing command{"cmd": "/usr/bin/docker info --format '{{json .MemTotal}}'"}
2024-11-01T17:32:10.372ZV4Reading bundles manifest{"url": "https://anywhere-assets.eks.amazonaws.com/releases/bundles/50/manifest.yaml"}
2024-11-01T17:32:10.402ZV4Using CAPI provider versions{"Core Cluster API": "v1.5.2+aa5216f", "Kubeadm Bootstrap": "v1.5.2+79ab319", "Kubeadm Control Plane": "v1.5.2+f9414f0
", "External etcd Bootstrap": "v1.0.9+4c9d17a", "External etcd Controller": "v1.0.14+500606a", "Cluster API Provider VSphere": "v1.7.0+481f58e"}
2024-11-01T17:32:10.509ZV5Retrier:{"timeout": "2562047h47m16.854775807s", "backoffFactor": null}
2024-11-01T17:32:10.509ZV2Pulling docker image{"image": "public.ecr.aws/eks-anywhere/cli-tools:v0.18.0-eks-a-50"}
2024-11-01T17:32:10.509ZV6Executing command{"cmd": "/usr/bin/docker pull public.ecr.aws/eks-anywhere/cli-tools:v0.18.0-eks-a-50"}
2024-11-01T17:32:11.151ZV5Retry execution successful{"retries": 1, "duration": "642.214177ms"}
2024-11-01T17:32:11.152ZV3Initializing long running container{"name": "eksa_1730482330509753200", "image": "public.ecr.aws/eks-anywhere/cli-tools:v0.18.0-eks-a-50"}
2024-11-01T17:32:11.152ZV6Executing command{"cmd": "/usr/bin/docker run -d --name eksa_1730482330509753200 --network host -w /home/eksadmin/ng911-eksa-iac -v /var/run/do
cker.sock:/var/run/docker.sock -v /home/eksadmin/ng911-eksa-iac:/home/eksadmin/ng911-eksa-iac -v /home/eksadmin/ng911-eksa-iac:/home/eksadmin/ng911-eksa-iac --entrypoint sleep public.ecr.aws
/eks-anywhere/cli-tools:v0.18.0-eks-a-50 infinity"}
2024-11-01T17:32:11.358ZV4Task start{"task_name": "setup-validate"}
2024-11-01T17:32:11.358ZV0Performing setup and validations
2024-11-01T17:32:11.358ZV4Tasks completed{"duration": "192.189µs"}
2024-11-01T17:32:11.358ZV3Logging out from current govc session
2024-11-01T17:32:11.358ZV-2Closer failed{"closerType": "*dependencies.Dependencies", "error": "govc returned error when logging out: failed govc validations: GOVC_URL is not
set or is empty: false"}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x128 pc=0x2986857]

goroutine 1 [running]:
github.com/aws/eks-anywhere/pkg/providers/vsphere.SetupEnvVars(0x0)
github.com/aws/eks-anywhere/pkg/providers/vsphere/envars.go:29 +0x157
github.com/aws/eks-anywhere/pkg/providers/vsphere.(*vsphereProvider).SetupAndValidateCreateCluster(0xc000ac4a00, {0x3894470, 0xc00012e010}, 0xc000a1fac0)
github.com/aws/eks-anywhere/pkg/providers/vsphere/vsphere.go:305 +0xc5
github.com/aws/eks-anywhere/pkg/workflows.(*SetAndValidateTask).providerValidation.func1()
github.com/aws/eks-anywhere/pkg/workflows/create.go:190 +0xb2
github.com/aws/eks-anywhere/pkg/validations.(*Runner).Run(0xc0004fe2e8?)
github.com/aws/eks-anywhere/pkg/validations/runner.go:24 +0x42
github.com/aws/eks-anywhere/pkg/workflows.(*SetAndValidateTask).Run(0xc000aed410?, {0x3894470, 0xc00012e010}, 0xc000af3c20)
github.com/aws/eks-anywhere/pkg/workflows/create.go:177 +0x365
github.com/aws/eks-anywhere/pkg/task.(*taskRunner).RunTask(0xc000b16270, {0x3894470, 0xc00012e010}, 0xc000af3c20)
github.com/aws/eks-anywhere/pkg/task/task.go:159 +0x463
github.com/aws/eks-anywhere/pkg/workflows.(*Create).Run(0xc000b97c50, {0x3894470, 0xc00012e010}, 0xc000a1fac0, {0x385f960?, 0xc0004fe2d8}, 0x0?)
github.com/aws/eks-anywhere/pkg/workflows/create.go:69 +0x312
github.com/aws/eks-anywhere/cmd/eksctl-anywhere/cmd.(*createClusterOptions).createCluster(0x5094780, 0x509b780, {0x0?, 0x0?, 0x0?})
github.com/aws/eks-anywhere/cmd/eksctl-anywhere/cmd/createcluster.go:256 +0x10fe
github.com/spf13/cobra.(*Command).execute(0x509b780, {0xc0008d40c0, 0x4, 0x4})
github.com/spf13/cobra@v1.6.1/command.go:916 +0x862
github.com/spf13/cobra.(*Command).ExecuteC(0x50a1940)
github.com/spf13/cobra@v1.6.1/command.go:1044 +0x3bd
github.com/spf13/cobra.(*Command).Execute(...)
github.com/spf13/cobra@v1.6.1/command.go:968
github.com/spf13/cobra.(*Command).ExecuteContext(...)
github.com/spf13/cobra@v1.6.1/command.go:961
github.com/aws/eks-anywhere/cmd/eksctl-anywhere/cmd.Execute()
github.com/aws/eks-anywhere/cmd/eksctl-anywhere/cmd/root.go:65 +0x54
main.main()
github.com/aws/eks-anywhere/cmd/eksctl-anywhere/main.go:29 +0x125

What you expected to happen: Cluster creation runs successfully
How to reproduce it (as minimally and precisely as possible):  I'm not sure why this is happening.  I've created at least 6 other cluster successfully using this version of EKSA
If I manually set the GOVC_URL variable, then it will ask for GOVC_DATACENTER, and eventually GOVC_INSECURE.  If I set those, then it will skip straight to the segmentation violation without any error messages from govc.
Here is the relevant datacenter section of the yaml file
---
apiVersion: anywhere.eks.amazonaws.com/v1alpha1
kind: VSphereDatacenterConfig
metadata:
  name: prod-dc1-mgmt
spec:
  datacenter: DC1
  insecure: true
  network: /DC1/network/EKSA_managment_network
  server: 10.2.2.18
  thumbprint: ""

Environment:

EKS Anywhere Release: v0.18.0
EKS Distro Release: Ubuntu 22.04 LTS

Closing this issue.  It's fixed already in EKSA v0.21.0 and now throws a proper error message telling you what part of the yaml file is missing or invalid.


text:
Update BRANCH_NAME to release-0.13

y submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

/approve


text:
aws-iam-authenticator project updates 1.26 to 1.30 only

Description of changes:
aws-iam-authenticator project updates from 1.26 to 1.30 only
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

/approve

repo: aws/eks-distro


text:
Nodes hitting max-volume limit still considered eligible for pods by Karpenter?

Version

Karpenter: v0.10/1

Kubernetes: v1.22.6-eks-7d68063
Background
We have certain workloads that mount a lot of PVCs to our EC2 nodes. Because these EC2 nodes are Nitro nodes, they share their "attachment limits" between ENI and EBS volumes. To try to minimize the situation where we run out of ENIs because of EBS volume mounts, we pass in --volume-attach-limit=15 to our aws-ebs-csi-driver chart, expecting that the chart will set the "attachable-volumes-aws-ebs" status on the nodes to 15. However, as I have reported in https://github.com/kubernetes-sigs/aws-ebs-csi-driver/issues/1258, we still see that value set to 39.
Expected Behavior
To some extent, I expect that Karpenter should be able to monitor for all reasons why a pod may not be scheduled onto a host ... and once it has not been scheduled for long enough, it should try to launch new hardware if one of the provisioners matches the general requirements for the pod.
In this specific case, I expect Karpenter to fully understand the way the aws-ebs-csi-driver works and honor whatever max-volume setting we have applied.
Actual Behavior
When our nodes have available CPU and Memory, but have hit the 15 volume limit, we expect that Karpenter will understand this and know that it needs to scale up new hardware. However, instead we see the controller go into a loop where it just keeps indicating that these pods should be scheduled against the "existing  capacity":
2022-06-02T00:24:18.865Z	INFO	controller	Batched 15 pod(s) in 10.000533501s	{"commit": "10fc37b"}
2022-06-02T00:24:18.875Z	INFO	controller	0 pod(s) will schedule against new capacity, 15 pod(s) against existing capacity	{"commit": "10fc37b"}
2022-06-02T00:24:18.875Z	INFO	controller	Waiting for unschedulable pods	{"commit": "10fc37b"}

Here is the pod-event log:
Warning  FailedScheduling   6s (x2 over 22s)  default-scheduler   0/13 nodes are available: 1 Too many pods, 1 node(s) had taint {kubernetes.io/arch: arm64}, that the pod didn't tolerate, 1 node(s) were unschedulable, 5 node(s) exceed max volume count, 5 node(s) had taint {nd.group-name: kube-system}, that the pod didn't tolerate.

After trying this out for a few hours and poking around, we had to roll back to allowing our partner (spot.io) to launch hardware and temporarily disable Karpenter.
Steps to Reproduce the Problem

Use EKS 1.22, Karpenter v0.10.6, and Bottlerocket v1.7.2 AMIs to spin up a Kubernetes cluster.
Install the aws-ebs-csi-driver chart, and set the max-volume limit to something low (say, 5)
Install Karpenter with provisioning that allows it to launch very large hosts that have plenty of CPU/Memory.
Spin up a bunch of pods with PVC requirements ... but with very low CPU/Memory requirements.
Watch Karpenter decide not to scale up the hardware.

cc @tzneal

Related to #919

@tzneal,
Regarding the scheduling... as I understand the documentation, Karpenter only schedules pods on to hardware that it launched. If I understand that correctly, then in this case the log messages that Karpenter is printing out are a little misleading ... they imply that Karpenter is trying to schedule the pod onto existing hardware, but I think it's actually trying to let the kube-scheduler do that, right?
It seems like after some timeout period, we could let Karpenter go ahead and scale up ... eg, if a pod is unscheduled for more than XX minutes (obviously configurable), then if Karpenter thinks it can launch new hardware to solve the problem, it should do that. Would that be a reasonable short term fix?
Another short-term fix would be to take a configuration parameter (env variable, etc) that lets us tell Karpenter how many volumes can be assigned to a node. Since AWS has already decided that automatically determining that is hard**, it seems reasonable to have the same decision here for a cluster administrator.
** Nitro Nodes make life pretty difficult here... because ENIs and EBS volumes pull from the same capacity pool, so the actual dynamic value of capacity is very complicated to deal with because it is always changing. Yet, Nitro nodes are the standard for all new EC2 types at this time, and so I don't see this pattern changing any time soon. Given that, a hard-coded setting that we can apply to set the max-volume-limit per node seems like a reasonable approach to me.

@tzneal Any further thoughts here? This issue is preventing us from being able to roll out Karpenter unfortunately. We have it all set up and ready to go to do some side by side testing in our production clusters, but we can't with this issue in place. :/

Sorry @diranged , I was on vacation and out last week. I'll be looking into this issue in more detail.

No worries at all, hope it was a good one! Thanks for getting back to me..

:+1: awesome, thank you!

authors: diranged tzneal

repo: aws/karpenter


text:
feat: Check for auth failures in liveness and readiness probes

Fixes #3351
Description
How was this change tested?

Does this change impact docs?

[ ] Yes, PR includes docs updates
[ ] Yes, issue opened: #
[ ] No

Release Note

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Can you include a description for this PR?

Awesome work, thanks for the contribution! 🎉  Just some comments and some questions to settle on

Thanks for the review @jonathan-innis! I'll take a look at it again some time next week. I've been caught up in work lately 😅

authors: ellistarn jonathan-innis kevinmingtarja


text:
Permission Error

kubectl logs --follow -n kube-system csi-secrets-store-secrets-store-csi-driver-knkbc -c secrets-store
The k8s secret sync does not seem to be working....
Ran into this error E1103 15:04:34.473126       1 reflector.go:138] pkg/mod/k8s.io/client-go@v0.21.1/tools/cache/reflector.go:167: Failed to watch *v1.Secret: failed to list *v1.Secret: secrets is forbidden: User "system:serviceaccount:kube-system:secrets-store-csi-driver" cannot list resource "secrets" in API group "" at the cluster scope and unable to figure what exactly needs to be done.

Figured out...
helm upgrade --install -n kube-system --set syncSecret.enabled=true csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver
Default
https://github.com/kubernetes-sigs/secrets-store-csi-driver/blob/221ef44211750661b2407e608ff707517d7a940a/charts/secrets-store-csi-driver/values.yaml#L186-L188

Figured out...
helm upgrade --install -n kube-system --set syncSecret.enabled=true csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver
Default
https://github.com/kubernetes-sigs/secrets-store-csi-driver/blob/221ef44211750661b2407e608ff707517d7a940a/charts/secrets-store-csi-driver/values.yaml#L186-L188

hmm. I have turned on syncSecret.enabled, but still have same error
 I0129 02:22:14.771879       1 exporter.go:35] "initializing metrics backend" backend="prometheus"

 I0129 02:22:14.793056       1 main.go:182] starting manager

 I0129 02:22:14.894887       1 secrets-store.go:46] "Initializing Secrets Store CSI Driver" driver="secrets-store.csi.k8s.io" version="v1.3.0" buildTime="2022-12-13-20:41"

 I0129 02:22:14.930138       1 server.go:121] "Listening for connections" address="//csi/csi.sock"

 I0129 02:22:15.893990       1 request.go:601] Waited for 1.04026038s due to client-side throttling, not priority and fairness, request: GET:https://10.100.0.1:443/apis/monitoring.coreos.com/v1alpha1?timeout=32s

 I0129 02:22:16.085495       1 nodeserver.go:365] node: getting default node info

 I0129 02:23:22.811678       1 nodeserver.go:359] "Using gRPC client" provider="aws" pod="nginx-deployment-k8s-secrets-66d5f46844-l99jb"

 E0129 02:23:23.302524       1 nodeserver.go:242] "failed to mount secrets store object content" err="rpc error: code = Unknown desc = Failed to fetch secret from all regions: /kone/govplt/elasticache/secret" pod="default/nginx-deployment-k8s-secrets-66d5f46844-l99jb"

 I0129 02:23:23.302641       1 nodeserver.go:88] "unmounting target path as node publish volume failed" targetPath="/var/lib/kubelet/pods/0bc06bcd-716a-4511-8e72-cc43334a4d8a/volumes/kubernetes.io~csi/secrets-store-inline/mount" pod="default/nginx-deployment-k8s-secrets-66d5f46844-l99jb"

 I0129 02:23:23.915727       1 nodeserver.go:359] "Using gRPC client" provider="aws" pod="nginx-deployment-k8s-secrets-66d5f46844-l99jb"

authors: mafeifan vitarkah


text:
Would the GPU execution time will restart? ?

I have been also facing the problem I trained my model halfway yesterday and thought the remaining GPU time would restart today as well. After yesterday's training, I had only 45 mins left for GPU usage. Will it get renewed today?
As I need more time to train the model efficiently and then validate and predict using my model?

as i know is 24 hours after u started it, just write what time u started it

Thank you @kadalio3 , the GPU time restarts after 24 hours. If you cannot get next 4 hours despte 24 hours, please let us know.

Thanks it worked . Though instead of 24 hours I had to wait 26 hours.

repo: aws/studio-lab-examples


text:
Type Checking correction, indentation correction

*Issue #271 *
Description of changes:

changing type checking for using isinstance
indentation correction
replacing set creation from list to directly set creation

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Job PR-275-1 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-275/1/index.html

Dear autogloun team,
I am reviewing the source codr of aoutgloun to understand how it works. And noticed that in many aspects code is a not clean enough interms of pep8 which is the python standard.  For correcting them do we need always to have a open issue ?
Regards,
Razmik
On Sat, 8 Feb 2020 at 12:11, Sheng Zhanotifications@github.com wrote:
Job PR-275-1 is done.
Docs are uploaded to http://autogluon-staging.s3-website-us-west-2.amazonaws.com/PR-275/1/index.html
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

Hi Razmik,
Thanks greatly for your help!
In regards to corrections, you do not need to open an issue first before sending a fix PR, but if you would like to open an issue for them, feel free. Note that we intentionally don't follow the max characters / line PEP8 standard, at least for the current time.
Best,
Nick

Hi Nick,
Thanks for response.
I will continue contributing.
Regards,
Razmik
On Mon, 10 Feb 2020 at 20:45, Nick Ericksonnotifications@github.com wrote:
Hi Razmik,
Thanks greatly for your help!
In regards to corrections, you do not need to open an issue first before sending a fix PR, but if you would like to open an issue for them, feel free. Note that we intentionally don't follow the max characters / line PEP8 standard, at least for the current time.
Best,
Nick
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

authors: Innixma razmikmelikbekyan szha

repo: awslabs/autogluon


text:
Pytorch ML Training Job on EKS with GPUs, orchestrated by airflow

Description of changes:
This pull request adds an example manifest for training ml models using airflow, eks, FSx Lustre, and gpu instances. We leverage Pytorch in this example for training the model.
The manifest can be deployed with and adapted for training any ML model on AWS:
seedfarmer apply manifests/ml-training-on-eks/deployment.yaml
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@kevinsoucy. With the current configuration, this module won't be able to deploy.
The fsx-on-eks integration module requires an EKS namespace to deploy to
The ml-on-eks module has a dependency on the fsx-on-eks integration module and also creates the namespace.

@kevinsoucy. With the current configuration, this module won't be able to deploy.
The fsx-on-eks integration module requires an EKS namespace to deploy to The ml-on-eks module has a dependency on the fsx-on-eks integration module and also creates the namespace.

I've added fix for this issue.

LGTM!


text:
Add macro for AWS_RETURN_WITH_POSTCONDITION and use it

Description of changes:
The current way we handle postconditions ends up with a series of AWS_POSTCONDITION calls, followed by a return foo statement.  This can make the code feel cluttered, and can make it hard to tell at a glance whether

all the postconditions are in the proper place, directly before a return
Whether all the returns have similar postconditions.

Since postconditions should be tightly tied to returns, it makes sense to have a macro that combines the two.  This PR proposes such a macro, and trials it on one module (hash-table)
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

The downstream issue is due to the bug fixed in https://github.com/awslabs/aws-c-common/pull/451

Personally, I think this makes the code less readable.
but looks like this was merged a second ago...

authors: danielsn graebm

repo: awslabs/aws-c-common


text:
s3.to_parquet does not take the catalog id into account for partition creation

Bug description
When using s3.to_parquet with partitions columns and a specific catalog_id, the partition is not created on the Glue catalog.
Adding the parameter catalog_id in the call of  catalog.add_parquet_partitions solved the issue.

Fix released on version 1.9.4

authors: igorborgest sl-antoinelaborde

repo: awslabs/aws-data-wrangler


text:
Refactor and modularize tests

In this PR, the tests have been refactored, rearranged, and de-duplicated.
Tests should be have the layout similar with the backend .
This PR depends on the changes  #643
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Left mainly minor comments.
I double-checked the imports and verified that no cross imports are happening between module tests.
Tests are green locally, disabling the modules 1 by 1 properly exclude the respective test suites :)

I will merge this after merging the frontend into modularization-main

authors: dbalintx nikpodsh

repo: awslabs/aws-dataall


text:
MQTT Communication

Hi Greg,
I have deployment up and running with more components. Now we are in the phase of communication and i have a doubt about the following step:
We can use the MQTT Integration to connect Home Assistant directly to AWS IoT Core. Firstly create a Thing representing Home Assistant, and obtain the device certificate, private key and CA certificate.
The question is:
Do I have to create a new certificate inside the "Thing" and then download and move it to the location where the secret folder is located?
Thanks!

Hi. Have you tried to follow the instructions here?
https://github.com/awslabs/aws-greengrass-labs-component-for-home-assistant#aws-iot-core
So with that approach I am suggesting to add it to the secret.

Greg,
Thats what i'm talking about... My doubt is if i have to had two Things for one Greengrass core device...
Thanks again.

Hello @tinchom,
Yes you should have 2 different things. One for Greengrass, one for home assistant in this case.

Thanks Mike.
Last question (i think):
Its possible to see the home-assistant activity in aws IoT core portal (MQTT test client)?
My hw is Raspberry Pi with Sonoff anthena Zigbee and wireless open door sensor.
We would like to know if its possible to see that activity (open/close) in the end point devices.
Thanks again!
Martin

If the home assistant MQTT client is publishing messages to IoT Core, then you'd see those if you subscribe to the appropriate topics in the test client. I personally do not know what topics would be relevant, but I'm sure that home assistant would document those.

authors: MikeDombo gregbreen tinchom


text:
fix(parameters): appconfig return type to str in internal function

fix return type to bytes in internal function from string to bytes.

Thanks a lot Ran! I'll look into it tomorrow morning

Bringing the discussion we're having on Slack so we can track the history afterwards @whardier, and to make sure the problem is well understood and we don't accidentally create another one.
Based on your transform issue report, we seem to have two issues not one -- please correct me if I misunderstood it:
Transform
Problem. By default AppConfig returns bytes not str as the interfaces suggest.
Fix. We need to update transform_value function signature to also accept bytes value and handle it accordingly (avoid double decoding if it's bytes) - This function isn't documented despite being public (it shouldn't, oversight during the review), so it will not be a breaking change either way.
Return types
Problem. AppConfig implementation of _get interface from BaseProvider uses a different return type which creates subtle bugs like these. Not surprisingly in the public documentation, we provide an example and explicitly call out get_app_config return type as bytes.
Fix. We will need _get to also return bytes. For another PR, we should do a proper solution in doing function overload to handle transform return types correctly.

Codecov Report

Merging #877 (eaebc8b) into develop (0348bd6) will decrease coverage by 0.01%.
The diff coverage is 100.00%.

@@             Coverage Diff             @@
##           develop     #877      +/-   ##
===========================================
- Coverage    99.90%   99.88%   -0.02%
===========================================
  Files          118      118
  Lines         5126     5129       +3
  Branches       571      573       +2
===========================================
+ Hits          5121     5123       +2
  Misses           2        2
- Partials         3        4       +1

Impacted Files
Coverage Δ

aws_lambda_powertools/metrics/metric.py
100.00% <100.00%> (ø)

aws_lambda_powertools/utilities/parameters/base.py
100.00% <100.00%> (ø)

.../utilities/data_classes/cognito_user_pool_event.py
99.73% <0.00%> (-0.27%)
:arrow_down:

Continue to review full report at Codecov.

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

Leaving other issues for posterity as there could be some other subtle bugs

aws_lambda_powertools/utilities/parameters/base.py: note: In member "get_multiple" of class "BaseProvider":
aws_lambda_powertools/utilities/parameters/base.py:158:64: error: Incompatible types in assignment (expression has type "Dict[str, str]", variable has type "Dict[str, Union[str, bytes, Dict[Any, Any], None]]")  [assignment]
                values: Dict[str, Union[str, bytes, dict, None]] = self._get_multiple(path, **sdk_options)
                                                                   ^
aws_lambda_powertools/utilities/parameters/base.py:158:64: note: "Dict" is invariant -- see https://mypy.readthedocs.io/en/stable/common_issues.html#variance
aws_lambda_powertools/utilities/parameters/base.py:158:64: note: Consider using "Mapping" instead, which is covariant in the value type
aws_lambda_powertools/utilities/parameters/base.py:164:13: error: Incompatible types in assignment (expression has type "str", variable has type "Tuple[str, Optional[str]]")  [assignment]
                for (key, value) in values.items():
                ^
aws_lambda_powertools/utilities/parameters/base.py:165:51: error: Argument 1 to "get_transform_method" has incompatible type "Tuple[str, Optional[str]]"; expected "str"  [arg-type]
                    _transform = get_transform_method(key, transform)
                                                      ^
aws_lambda_powertools/utilities/parameters/base.py:169:24: error: Invalid index type "Tuple[str, Optional[str]]" for "Dict[str, Union[str, bytes, Dict[Any, Any], None]]"; expected type "str"  [index]
                    values[key] = transform_value(value, _transform, raise_on_transform_error)
                           ^
aws_lambda_powertools/utilities/parameters/base.py:169:47: error: Argument 1 to "transform_value" has incompatible type "Union[str, bytes, Dict[Any, Any], None]"; expected "str"  [arg-type]
                    values[key] = transform_value(value, _transform, raise_on_transform_error)
                                                  ^
aws_lambda_powertools/utilities/parameters/base.py:173:16: error: Incompatible return value type (got "Dict[str, Union[str, bytes, Dict[Any, Any], None]]", expected
"Union[Dict[str, str], Dict[str, Dict[Any, Any]], Dict[str, bytes]]")  [return-value]
            return values
                   ^
aws_lambda_powertools/utilities/parameters/ssm.py: note: In member "get" of class "SSMProvider":
aws_lambda_powertools/utilities/parameters/ssm.py:90:5: error: Signature of "get" incompatible with supertype "BaseProvider"  [override]
        def get(
        ^
aws_lambda_powertools/utilities/parameters/ssm.py:131:16: error: Incompatible return value type (got "Union[str, List[Any], Dict[Any, Any], bytes, None]", expected "Union[str, List[Any], Dict[Any, Any], bytes]")  [return-value]
            return super().get(name, max_age, transform, force_fetch, **sdk_options)
                   ^

repo: awslabs/aws-lambda-powertools-python


text:
[Feature]: Replace AWS.Credentials new instance creation with the credentials object

Self-service

[ ] I'd be willing to implement this feature

Problem
The new instance creation of AWS.Credentials class is not replaced.
Examples
import AWS from "aws-sdk";

// credentials object as options
const creds = new AWS.Credentials({
  accessKeyId: 'akid',
  secretAccessKey: 'secret',
  sessionToken: 'session',
});

import AWS from "aws-sdk";

// credentials as options
const creds = new AWS.Credentials('akid', 'secret', 'session');

Solution
Replace new instance with Credentials object with a comment that it's the best guess from codemod.
const creds = {
  accessKeyId: 'akid',
  secretAccessKey: 'secret',
  sessionToken: 'session',
};

Alternatives
Wait for JS SDK v3 to provide fromStatic credential provider https://github.com/aws/aws-sdk-js-v3/issues/5452
Additional context
Examples usages in production:

https://github.com/ToolJet/ToolJet/blob/bea8d1bd25075503e0873ddc74a0b271be1ce071/plugins/packages/amazonses/lib/index.ts#L80-L87
https://github.com/transloadit/uppy/blob/43178f1c4f7369b4275c4e7aa6b7cdc827ff8420/bin/upload-to-cdn.js#L112-L115

https://github.com/askrella/whatsapp-chatgpt/blob/3096f7db393a3b5a4e1cd70c64349909b7f9cc8e/src/providers/aws.ts#L10

repo: awslabs/aws-sdk-js-codemod


text:
Upgrade actions in GitHub Actions workflows

Motivation and Context
This PR upgrades our GitHub Action workflows to fix various deprecations for #649:

Node 12 deprecation
::set-output deprecation

Additionally, actions-rs seems to be no longer maintained and is stuck on Node 12, so references to it were replaced with dtolnay/rust-toolchain.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

The canary passes with the latest changes: https://github.com/awslabs/aws-sdk-rust/actions/runs/3431866756

repo: awslabs/aws-sdk-rust


text:
chore(release): 1.137.0

See CHANGELOG

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v1
Commit ID: 646308fd4ae2ed28f583cb8eebf864be6f7224da
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 646308fd4ae2ed28f583cb8eebf864be6f7224da
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v1
Commit ID: 4206aca59e789a397946c9811b1e115ea906ca5c
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 4206aca59e789a397946c9811b1e115ea906ca5c
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v1
Commit ID: 4206aca59e789a397946c9811b1e115ea906ca5c
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 4206aca59e789a397946c9811b1e115ea906ca5c
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: 6d44750970e7acf20eb30cec08c9199675ea6d2a
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v1
Commit ID: 6d44750970e7acf20eb30cec08c9199675ea6d2a
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: cbdc26bfa1cb6930d9ef9e0dbcb6d4be5e5dd786
Result: FAILED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v1
Commit ID: cbdc26bfa1cb6930d9ef9e0dbcb6d4be5e5dd786
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v2
Commit ID: d9806641ff28d85e3e9b1cde76fe5908b6bddc16
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

AWS CodeBuild CI Report

CodeBuild project: githubautobuild-for-cdk-v1
Commit ID: d9806641ff28d85e3e9b1cde76fe5908b6bddc16
Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

repo: awslabs/aws-solutions-constructs


text:
Test horizontal scaling of Ray Worker Pods

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

What is the outcome that you are trying to reach?

Scale test to verify that Ray Serve replicas and Ray worker Pods can horizontally scale.
Describe the solution you would like
Develop a test script that will send concurrent request to the RayServe Inference endpoint for the StableDiffusion model.
Verify that new nodes and pods are created once the HTTP request limit specified in the RayServe configuration is reached.

Describe alternatives you have considered

Additional context
This exercise is to ensure Ray Serve replicas and Pods can scale based on number of concurrent HTTP requests.

https://github.com/ray-project/ray/issues/44361

repo: awslabs/data-on-eks


text:
Link to CircleCi build is broken

Link to CircleCi is broken

just in case someone is landing here using some search engine....  the new link seems to be: https://circleci.com/gh/awslabs/fargatecli

authors: smoell vicendominguez

repo: awslabs/fargatecli


text:
Cannot find target group nor listener when setting up load balancer

Describe the bug
Followed the steps to build a load balancer, getting two errors from the alb-ingress-gateway pod:
"error"="failed to reconcile listeners due to failed to reconcile rules due to ListenerNotFound: One or more listeners not found
followed by
msg"="Reconciler error" "error"="failed to reconcile targetGroups due to failed to reconcile targetGroup tags due to TargetGroupNotFound: Target groups
Steps To Reproduce
On an ec2 instance with the eksctl minimum privelages follow this guide https://github.com/awslabs/kubeflow-manifests/tree/v1.3-branch/distributions/aws/examples/vanilla#connect-to-your-kubeflow-cluster
Then to setup load balancer:
https://github.com/awslabs/kubeflow-manifests/issues/67#issuecomment-1032128251
Expected behavior
First error i had was to do with the kf-admin-eu-west-1 not having an OIDC provider url but that was my fault because the $OIDC_PROVIDER_URL didnt export properly.
The two named errors listed above occured once I sorted that and the endpoint for the load balancer is inaccessible
Environment

Kubernetes version: 1.19
Using EKS: latest
AWS service targeted None, vanilla but setting this up on an ec2 instance

Screenshots

Additional context

Never mind, these errors were occurring because the health checks for the target group were failing, changed the success code to 302 and it works.

repo: awslabs/kubeflow-manifests


text:
[Testing in Progress] Create and provide EFS CSI driver policy to blueprints addons

Which issue is resolved by this Pull Request:
Resolves #717
Description of your changes:
The default IAM policy created for the EFS CSI driver service account is does not contain all the required permissions mentioned here.
The Terraform install was updated to create a policy using the above URL and pass that policy as an input to the Blueprints Addons module, in which the EFS CSI driver module would use the policy as an input when creating the IAM role for the EFS CSI driver service account.
Testing:
Tested both manual deployment and modified auto setup script cases.
Auto setup script diff:
ubuntu@ip-172-31-21-105:~/tf-efs/kubeflow-manifests$ git diff tests
diff --git a/tests/e2e/utils/auto-efs-setup.py b/tests/e2e/utils/auto-efs-setup.py
index 13866535..af331100 100755
--- a/tests/e2e/utils/auto-efs-setup.py
+++ b/tests/e2e/utils/auto-efs-setup.py
@@ -14,8 +14,8 @@ def main():

     verify_prerequisites()

-    setup_iam_authorization()
-    setup_efs_driver()
+    # setup_iam_authorization()
+    # setup_efs_driver()
     setup_efs_file_system()
     setup_efs_provisioning()

Verified notebook and volumes were created:

PVC yaml:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    pv.kubernetes.io/bind-completed: 'yes'
    pv.kubernetes.io/bound-by-controller: 'yes'
    volume.beta.kubernetes.io/storage-provisioner: efs.csi.aws.com
    volume.kubernetes.io/selected-node: ip-10-0-107-16.us-west-2.compute.internal
    volume.kubernetes.io/storage-provisioner: efs.csi.aws.com
  creationTimestamp: '2023-05-03T23:07:43+00:00'
  finalizers:
    - kubernetes.io/pvc-protection
  managedFields:
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        'f:spec':
          'f:accessModes': {}
          'f:resources':
            'f:requests':
              .: {}
              'f:storage': {}
          'f:storageClassName': {}
          'f:volumeMode': {}
      manager: OpenAPI-Generator
      operation: Update
      time: '2023-05-03T23:07:43+00:00'
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        'f:metadata':
          'f:annotations':
            .: {}
            'f:volume.kubernetes.io/selected-node': {}
      manager: kube-scheduler
      operation: Update
      time: '2023-05-03T23:07:44+00:00'
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        'f:metadata':
          'f:annotations':
            'f:pv.kubernetes.io/bind-completed': {}
            'f:pv.kubernetes.io/bound-by-controller': {}
            'f:volume.beta.kubernetes.io/storage-provisioner': {}
            'f:volume.kubernetes.io/storage-provisioner': {}
        'f:spec':
          'f:volumeName': {}
      manager: kube-controller-manager
      operation: Update
      time: '2023-05-03T23:07:45+00:00'
    - apiVersion: v1
      fieldsType: FieldsV1
      fieldsV1:
        'f:status':
          'f:accessModes': {}
          'f:capacity':
            .: {}
            'f:storage': {}
          'f:phase': {}
      manager: kube-controller-manager
      operation: Update
      subresource: status
      time: '2023-05-03T23:07:45+00:00'
  name: tf-efs-auto-script-volume
  namespace: kubeflow-user-example-com
  resourceVersion: '126178'
  uid: e09f5782-61bb-49d7-bf67-d975f2e15870
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: efs-sc
  volumeMode: Filesystem
  volumeName: pvc-e09f5782-61bb-49d7-bf67-d975f2e15870
status:
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  phase: Bound

Storage class configuration:
ubuntu@ip-172-31-21-105:~/tf-efs/kubeflow-manifests$ kubectl get sc -o yaml
apiVersion: v1
items:
- allowVolumeExpansion: true
  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{},"name":"efs-sc"},"mountOptions":["tls"],"parameters":{"directoryPerms":"700","fileSystemId":"fs-07bf42ce7f10f6b20","gid":"100","provisioningMode":"efs-ap","uid":"1000"},"provisioner":"efs.csi.aws.com","reclaimPolicy":"Delete","volumeBindingMode":"WaitForFirstConsumer"}
    creationTimestamp: "2023-05-03T23:03:45Z"
    name: efs-sc
    resourceVersion: "123612"
    uid: 426dd9fa-0014-43d6-83fb-85b682b5fb63
  mountOptions:
  - tls
  parameters:
    directoryPerms: "700"
    fileSystemId: fs-07bf42ce7f10f6b20
    gid: "100"
    provisioningMode: efs-ap
    uid: "1000"
  provisioner: efs.csi.aws.com
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer
- apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"storage.k8s.io/v1","kind":"StorageClass","metadata":{"annotations":{"storageclass.kubernetes.io/is-default-class":"true"},"name":"gp2"},"parameters":{"fsType":"ext4","type":"gp2"},"provisioner":"kubernetes.io/aws-ebs","volumeBindingMode":"WaitForFirstConsumer"}
      storageclass.kubernetes.io/is-default-class: "false"
    creationTimestamp: "2023-05-03T19:43:30Z"
    name: gp2
    resourceVersion: "84473"
    uid: 9ea8c1ec-5030-467d-895d-4df6cbc9d4d0
  parameters:
    fsType: ext4
    type: gp2
  provisioner: kubernetes.io/aws-ebs
  reclaimPolicy: Delete
  volumeBindingMode: WaitForFirstConsumer
kind: List
metadata:
  resourceVersion: ""

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Thank you @rrrkharse for jumping on this!
If the only changes to the auto script is commenting these two lines :
# setup_iam_authorization()
# setup_efs_driver()

Then maybe we could introduce a flag to the auto script (is_terraform_deployment) or something similar (false by default) that we could pass as true if using terraform as deployment option?
if not is_terraform_deployment:
    setup_iam_authorization()
    setup_efs_driver()

Also, is it normal that no service account is created when using terraform? Where is the policy being used exactly when we use terraform and comment those two lines?

Shouldnt we fix the upstream instead? should be quick

re:auto script, We can introduce generic flag like --skip-driver-installation instead of terraform-deployment for anyone who has installed driver already

@surajkota By curiosity, how is the policy being used if there is no service account created? (setup_iam_authorization is commented)

Service account and IAM Role is created for the controller, are you asking where the code for that is in terraform?

@surajkota Ok so the EFS policy created by the terraform deployment is being used by the controler SA? Just looking to understand what replaces the IAM setup of the autoscript when using terraform.

Its implemented in upstream in eks-blueprints. EFS driver module uses helm add on module, which uses IRSA module
IRSA configuration for EFS CSI driver is defined here - https://github.com/aws-ia/terraform-aws-eks-blueprints/blob/main/modules/kubernetes-addons/aws-efs-csi-driver/main.tf#L24-L50

auto script might also be depending on eksctl related tags for getting cluster related info like subnets etc. that might need to be changed to using describe_cluster instead or some other generic way

@surajkota I see, are you sure that's an issue for the EFS script? I don't see any usage of a tag to query any information.
I see describe_cluster being used.

I just meant to give a headsup for potential issues. looks like that's in rds-s3 script(works only with specific cdk or eksctl tags on subnet), efs script was fixed in https://github.com/awslabs/kubeflow-manifests/pull/185/files
efs script does check for eksctl being installed on the system, I think we should remove those tools verification since its part of prerequisites and is duplicate code across multiple scripts.
Ideally we would have terraform module for this in future which would make it easy to change file system attributes post creation and address clean up via terraform with no additional code

@surajkota great, yes I was aware for rds-s3.
I think once this PR is merged maybe the doc should be updated to remove the manual steps recommendation or at least reword it so it doesn't sound like auto script won't work for terraform.
I agree with you, ideally in the future EFS should be part of the terraform deployment so that it's easy to cleanup.
I created an issue to keep track of this feature request ( #713 )

https://github.com/awslabs/kubeflow-manifests/pull/731

authors: AlexandreBrown rrrkharse surajkota


text:
Support "excludeOus" parameter for Security Services

Is your feature request related to a problem? Please describe.
For customers leveraging a single LZA environment for both sensitive/protected and innovation/exploratory workloads, it would be great to be able to exclude certain OUs from AWS Security Hub, Detective, GuardDuty, and Inspector in order to reduce cost and operational overhead.
Describe the feature you'd like
Support excludeOus  parameter in LZA security-service.yaml for AWS Security Hub, Detective, GuardDuty, and Inspector.

Sandbox accounts are still valid targets to attackers and having no security services enabled seems folly to me. Instead I'd prefer support of selectively enabling/disabling controls/services/standards on an account/ou basis. The standards are good practise but it's clear many of the controls are overhanded for earlier dev accounts and it just causes noise. The current option is to disable and replace these controls with our own.

repo: awslabs/landing-zone-accelerator-on-aws


text:
usage-guide: fix s2n_mode comment about S2N_CLIENT

Resolved issues:
None
Description of changes:
According to examples in bin/s2nc.c s2n can act as a client. now.
So this comment about server only behaviour is no longer correct.
Call-outs:
None
Testing:
Generated markdown preview looks correct
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Codecov Report

Merging #2274 into main will increase coverage by 42.15%.
The diff coverage is 84.00%.

@@             Coverage Diff             @@
##             main    #2274       +/-   ##
===========================================
+ Coverage   38.57%   80.73%   +42.15%
===========================================
  Files         164      265      +101
  Lines       12626    17875     +5249
===========================================
+ Hits         4871    14431     +9560
+ Misses       7755     3444     -4311

authors: codecov-commenter noxiouz


text:
[FEATURE] Support viewing & exporting manifest/group/module outputs

Is your feature request related to a problem? Please describe.
When developing a module that depends on a different module for it's inputs, for instance an EC2 module that needs the VPC ID from the optional/networking module, it is hard to develop now knowing which outputs from the networking module have been created.
Describe the solution you'd like
Add CLI support for viewing the input/output values for an already deployed manifest. E.g.
cli describe manifest/deployment.yaml
Outputs all of the inputs/outputs of the already deployed modules for that manifest  (with actual resolved values)
cli describe manifest/deployment.yaml --group foo
Describes inputs/outputs of the already deployed group foo (with actual resolved values)
cli describe manifest/deployment.yaml --group foo --module bar
Describes inputs/ouputs of the already deployed module bar for group foo with the actual resolved values.
BONUS Feature:
Additional command for exporting the values from module output into local environment variables
cli describe manifest/deployment.yaml --group foo --module bar --export-local-env
Shows and outputs the variables into my local environment variables. This was I can run cdk synth on the module under development and wire up it's dependencies as it will be available in CodeBuild.
Describe alternatives you've considered
Additional context
When developing inter dependent modules, understanding the output of an already deployed module allows me to more easily design the inputs for the module under development.

We currently have the ability to list/display the module outputs:
seedfarmer list moduledata -d <deployment> -g <group> -m <module>
Please confirm this is what you need?

repo: awslabs/seed-farmer


text:
Correctly load client or server specific decorators from classpath

The current approach that attempts to downcast never worked; all Rust
decorators were being loaded, and the cast was doing nothing, because
the generic type parameter is erased at runtime.
Attempting to downcast a generic class C<T> to C<U> where U: T is
not possible to do in Kotlin (and presumably all JVM-based languages)
at runtime. Not even when using reified type parameters of inline
functions. See https://kotlinlang.org/docs/generics.html#type-erasure
for details.
This commit thus goes for another approach, suggested in the linked
Stack Overflow question 0: add a method to the loaded classes that
signals at runtime the generic type parameter (ClientCodegenContext or
ServerCodegenContext) they can work with, in order to filter them.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@Velfi
failures:

---- test_async_std_runtime_timeouts stdout ----
thread 'test_async_std_runtime_timeouts' panicked at 'actual = 506.378614ms, expected = 500ms', sdk/s3/tests/alternative-async-runtime.rs:120:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

failures:
    test_async_std_runtime_timeouts

repo: awslabs/smithy-rs


text:
Out of memory exception after releasing GPUs in epoch 0

Hello,
How can I diagnose the out-of-memory error below? It's not clear to me why it's happening at that location but I suspect something was trying to perhaps(?) create a copy of a very large ndarray. I've searched for other sockeye memory error issues and this doesn't appear to be a CUDA /GPU memory issue at first glance. How can we better diagnose the source of this error?
We are training on a dedicated DGXA100 server with 2TB of RAM and 8 A100 GPUs with 80Gb of GPU RAM each. The sockeye training is the only process running (apart from other NVIDIA & system services) so most of the system RAM is free and nothing else is consuming the GPUs. If you look at the GPU RAM usage below, most GPUs are at ~87% and the last one at ~35%
Here are the logs:
[2022-07-13:15:46:23:INFO:sockeye.training:call] E=0 B=79700	s/sec=433.90 tok/sec=12816.83 u/sec=0.07	ppl=374.235978
[2022-07-13:15:46:30:INFO:sockeye.training:call] E=0 B=79750	s/sec=480.49 tok/sec=11463.11 u/sec=0.07	ppl=374.079897
[2022-07-13:15:46:38:INFO:sockeye.training:call] E=0 B=79800	s/sec=475.42 tok/sec=10885.53 u/sec=0.06	ppl=373.886276
[2022-07-13:15:46:47:INFO:sockeye.training:call] E=0 B=79850	s/sec=389.05 tok/sec=10893.50 u/sec=0.06	ppl=373.733448
[2022-07-13:15:46:55:INFO:sockeye.training:call] E=0 B=79900	s/sec=442.24 tok/sec=10866.43 u/sec=0.06	ppl=373.558397
[2022-07-13:15:47:02:INFO:sockeye.training:call] E=0 B=79950	s/sec=435.77 tok/sec=11598.26 u/sec=0.07	ppl=373.405683
[2022-07-13:15:47:11:INFO:sockeye.training:call] E=0 B=80000	s/sec=396.52 tok/sec=11712.64 u/sec=0.06	ppl=373.273127
[2022-07-13:15:47:27:INFO:root:save_parameters] Saved params to "/model/model1/params.00004"
[2022-07-13:15:47:27:INFO:sockeye.training:_create_checkpoint] Checkpoint [4]	Updates=800 Epoch=0 Samples=5541888 Time-cost=3414.015 Updates/sec=0.059
[2022-07-13:15:47:27:INFO:sockeye.training:_create_checkpoint] Checkpoint [4]	Train-ppl=373.273127
[2022-07-13:16:00:52:INFO:sockeye.training:_evaluate] Checkpoint [4]	Validation-ppl=300.643071	Validation-bleu=0.013280	Validation-chrf=0.222014	Validation-rouge1=0.170945	Validation-rouge2=0.027774	Validation-rougel=0.130451	Validation-length-ratio-mse=1.131029	Validation-avg-sec-per-sent=0.090980	Validation-decode-walltime=765.779070
[2022-07-13:16:00:52:INFO:sockeye.training:_determine_improvement] Validation-perplexity improved to 300.643071 (delta=125.811331).
[2022-07-13:16:00:52:INFO:sockeye.training:_update_best_params] '/model/model1/params.best' now points to 'params.00004'
[2022-07-13:16:01:36:INFO:sockeye.training:_save_trainer_states] Saved optimizer states to "/model/model1/mx_optimizer_best.pkl"
[2022-07-13:16:01:36:INFO:sockeye.training:_save_lr_scheduler] Saved 'LearningRateSchedulerPlateauReduce(reduce_factor=0.90, reduce_num_not_improved=8, num_not_improved=0, base_lr=0.0005, lr=0.0005, warmup=0, warmed_up=True)' to '/model/model1/lr_scheduler_best.pkl'
[2022-07-13:16:01:36:INFO:sockeye.utils:log_gpu_memory_usage] GPU 0: 74253/85198 MB (87.15%) GPU 1: 74306/85198 MB (87.22%) GPU 2: 74314/85198 MB (87.23%) GPU 3: 74109/85198 MB (86.98%) GPU 4: 74260/85198 MB (87.16%) GPU 5: 74283/85198 MB (87.19%) GPU 6: 74272/85198 MB (87.18%) GPU 7: 30400/85198 MB (35.68%)
[2022-07-13:16:02:17:INFO:sockeye.training:_save_trainer_states] Saved optimizer states to "/model/model1/tmp.training_state/mx_optimizer_last.pkl"
[2022-07-13:16:02:17:INFO:sockeye.training:_save_lr_scheduler] Saved 'LearningRateSchedulerPlateauReduce(reduce_factor=0.90, reduce_num_not_improved=8, num_not_improved=0, base_lr=0.0005, lr=0.0005, warmup=0, warmed_up=True)' to '/model/model1/tmp.training_state/lr_scheduler_last.pkl'
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 7.
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 6.
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 5.
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 4.
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 3.
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 2.
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 1.
[2022-07-13:16:04:03:INFO:sockeye.utils:exit] Releasing GPU 0.
[2022-07-13:16:04:03:ERROR:root:exception_hook] Uncaught exception
Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 192, in _run_module_as_main
return _run_code(code, main_globals, None,
File "/usr/lib/python3.8/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/usr/local/lib/python3.8/dist-packages/sockeye/train.py", line 1151, in
main()
File "/usr/local/lib/python3.8/dist-packages/sockeye/train.py", line 906, in main
train(args)
File "/usr/local/lib/python3.8/dist-packages/sockeye/train.py", line 1146, in train
training_state = trainer.fit(train_iter=train_iter, validation_iter=eval_iter, checkpoint_decoder=cp_decoder)
File "/usr/local/lib/python3.8/dist-packages/sockeye/training.py", line 242, in fit
did_grad_step = self._step(batch=train_iter.next())
File "/usr/local/lib/python3.8/dist-packages/sockeye/training.py", line 352, in _step
loss_func.metric.update(loss_value.asscalar(), num_samples.asscalar())
File "/usr/local/lib/python3.8/dist-packages/mxnet/ndarray/ndarray.py", line 2590, in asscalar
return self.asnumpy()[0]
File "/usr/local/lib/python3.8/dist-packages/mxnet/ndarray/ndarray.py", line 2568, in asnumpy
check_call(_LIB.MXNDArraySyncCopyToCPU(
File "/usr/local/lib/python3.8/dist-packages/mxnet/base.py", line 246, in check_call
raise get_last_ffi_error()
mxnet.base.MXNetError: Traceback (most recent call last):
File "../src/ndarray/../operator/tensor/./../mxnet_op.h", line 1120
Name: Check failed: err == cudaSuccess (2 vs. 0) : mxnet_generic_kernel ErrStr:out of memory

Ok, thanks! Starting the conversion now.

repo: awslabs/sockeye

license_source: bigquery


text:
How can I set SNSTemplate to not auto create SNS Topics?

If I try sending a notification to a Topic that doesn't exist, I'd like it error instead of creating it.
The docs mention defining this bean, but TopicsListingTopicArnResolver doesn't seem to exist.
@Bean
public TopicArnResolver topicArnResolver(SnsClient snsClient) {
    return new TopicsListingTopicArnResolver(snsClient);
}

TopicsListingTopicArnResolver will be released in next iteration (RC2 coming soon).
I do believe though that non existing topic is rather an edge case, and the application usually does not have permission to create topics so this would result in exception.
Listing topics on application adds an overhead, so ideally you don't need to use it.
Unfortunately, both are hacky workarounds that compensate for missing bits in AWS SDK.

authors: maciejwalkowiak mikelhamer

repo: awspring/spring-cloud-aws


text:
refactor: extract ownership management into sharable interface

AXE-6811

Codecov Report
Attention: Patch coverage is 93.38235% with 9 lines in your changes missing coverage. Please review.

Project coverage is 88.70%. Comparing base (017d421) to head (f8bfc6c).

Files with missing lines
Patch %
Lines

contracts/axelar-gas-service/src/contract.rs
0.00%
3 Missing :warning:

contracts/axelar-operators/src/contract.rs
0.00%
3 Missing :warning:

contracts/interchain-token-service/src/contract.rs
0.00%
3 Missing :warning:

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #97      +/-   ##
==========================================
- Coverage   89.23%   88.70%   -0.53%
==========================================
  Files          43       44       +1
  Lines        2936     2878      -58
==========================================
- Hits         2620     2553      -67
- Misses        316      325       +9

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

authors: cgorenflo codecov-commenter

repo: axelarnetwork/axelar-cgp-soroban


text:
Social share image uses old logo

GM. Looks like the social share image at http://axelarscan.io/interchain|axelarscan.io/interchain is still has the old, old Axelar logo. Or, could this be a caching issue in Telegram?
Slack Message

updated the preview via @webpagebot telegram bot.

authors: canhtrinh nrsirapop

repo: axelarnetwork/axelarscan-ui

license: MIT


text:
Support /comment/ syntax

Some people are used to JavaDoc /** */ doc blocks. Maybe enable them?
See for example https://stackoverflow.com/q/22440543/638546

Note that JSDoc ignores blocks that start with /* or /*** or more asterisks. See https://jsdoc.app/about-getting-started.html

This feature probably requires a new parsing stage, such that the first stage collects all comment blocks, regardless of whether they contain the earmark or not and regardless of the commenting style used.
Additional benefit in this that disabled blocks, like yamdog blocks inside /* */ would be ignored correctly.

repo: axelpale/yamdog


text:
Show 'Folder already exists' in Duplication Dialog

Is your feature request related to a problem? Please describe.
When I duplicate a folder, I don't know if there's already a folder with the same name. If there is, pressing enter results in a message saying, Refusing to overwrite existing directory. Then, I have to repeat the same process.
Describe the solution you'd like
In the duplication dialog, it should show something like Folder already exists

@axelrindle You can manage error messages more efficiently.
Here's an example.
Folder name cannot be empty (Press 'Escape' to cancel)

You can also add File already exists to let the user know beforehand if he should proceed.

repo: axelrindle/vscode-duplicate


text:
[feat] App Circuit Utils for Keccak Coprocessor

Encoding for VarLenBytesVec and FixLenBytesVec.

Left some minor comments, but LGTM.
BTW just to sanity check: the choice of little endian for keccak byte -> word but big endian for poseidon u64 -> big word was just practical right? I thought about it and it didn't seem there were any issues with leading or trailing zeros because we encode the length.

@jonathanpwang  Why is u64 -> big word big-endian? let's say bytes is [0x01, 0x02, .., 0x18]. Then it's [0x0807060504030201, 0x0f0e0d0c0b0a09, 0x1817161514131211] -> 0x18171615141312110f0e0d0c0b0a090807060504030201. It's always little endian.

Ah ok, I misread because you had the fold iterator.

authors: jonathanpwang nyunyunyunyu


text:
Fix dockerfile

@lukasmalkmus I'm so sorry! I just noticed that we can't run it as nonroot!
2023-08-10T13:54:16.212 app[91857559c17998] nrt [info] {"level":"info","ts":1691675656.2120683,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:71","msg":"starting","release":"0.6.0","revision":"edef102","build_date":"2023-08-09T11:41:52Z","build_user":"goreleaser","go_version":"go1.20.7"}

2023-08-10T13:54:16.212 app[91857559c17998] nrt [info] {"level":"info","ts":1691675656.2124286,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:106","msg":"started"}

2023-08-10T13:54:16.212 app[91857559c17998] nrt [info] {"level":"error","ts":1691675656.2128325,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:113","msg":"create server","error":"listen tcp :601: bind: permission denied"}

2023-08-10T13:54:16.213 app[91857559c17998] nrt [info] {"level":"warn","ts":1691675656.2129228,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:60","msg":"stopped"}

This affects all users using latest, so I think it needs a quick release!

I deployed with the exact same image I fixed, and it works as expected. The last time I tested it, I overlooked this issue because I used a multistage build to run the application in a slightly different setup from this repository.
2023-08-10T13:59:45.417 app[91857559c17998] nrt [info] 2023/08/10 13:59:45 listening on [fdaa:2:1571:a7b:17c:5275:2a9c:2]:22 (DNS: [fdaa::3]:53)

2023-08-10T13:59:45.436 app[91857559c17998] nrt [info] {"level":"info","ts":1691675985.4362023,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:71","msg":"starting","release":"0.6.0","revision":"edef102","build_date":"2023-08-09T11:41:52Z","build_user":"goreleaser","go_version":"go1.20.7"}

2023-08-10T13:59:45.436 app[91857559c17998] nrt [info] {"level":"info","ts":1691675985.4365556,"logger":"axiom-syslog-proxy","caller":"cmd/cmd.go:106","msg":"started"}

2023-08-10T13:59:45.437 app[91857559c17998] nrt [info] [13:59:45.43] info axiom-syslog-proxy@logs/input udp.go:18 Started UDP server on udp:[::]:514

2023-08-10T13:59:45.437 app[91857559c17998] nrt [info] [13:59:45.43] info axiom-syslog-proxy@logs/input tcp.go:23 Started TCP server on tcp:[::]:601

2023-08-10T14:00:46.215 app[91857559c17998] nrt [info] 2023/08/10 14:00:46 ingested 1 event(s)

Argh, damit. But happens to the best.
We are still pre v1.0.0 so let's merge this, release v0.6.1 and call it a day :)

Yeah, that sounds good to me. It's good to see that the image size is now under 10MB, resource efficiency is improved, and the security holes that can be attacked are much smaller.

I can confirm again that it's working correctly! Thank you so much for the release!

authors: lukasmalkmus smorimoto

repo: axiomhq/axiom-syslog-proxy


text:
Feature request: grouping messages by various criteria (sender, originating server, etc)

The use case is this: our development team shares a single instance of mailpit, but we each test different apps that are sending messages in, and when one developer goes in to view their messages, they'd rather not see messages from the other developer's testing efforts.  Sometimes, if only one developer is needing to test at a given time, they can check with the others and then delete all the older messages, giving themselves a clean slate, but if 2 people are testing at the same time this is not possible.
The idea would be to have a filter on the left side, that would dynamically group messages by different criteria, like sender email address, originating server, subject substring or other things that might be available in the headers of each mail, which would allow dev teams to partition their view of the inbox.  This would also be part of the url so one could bookmark their unique view to remove the other developer's messages.
Thanks!

Hi @wesyah234 . This sounds to me like something that can already be handled by existing tagging. You would either need to provide an X-Tags email header to auto-tag, or alternatively start your Mailpit instance with word/phrase matches defined.
Alternatively, you could just search for something specific (ie: the hostname) and bookmark the search URL.
Does this do what you need?

Wow, that's a cool feature, and I think it will definitely help us.  I'll play with it a bit.  I'll have to get my sysadmin to allow me to start and stop the instance to test things out with that --tag parameter but I think it might be useful for us.
Just trying out the basic search and then bookmark option. I had a few issues:

Can I do "OR" matching?
per this, Can I search ANY mail header? like (Received:) or just the ones listed (to,from,subject, etc)

Reason being: certain developers might have email coming from a certain server, identified by the Received: header, and this would be handy (along with OR capability) to be able to craft a search string specific for the messages that developer is interested in.

Mailpit uses SQLite for storage, and whilst SQLite is perfect for this use (small, embedded and relatively fast), it's not advanced like some Gmail/Google database backend, so there are some limits.

There is no OR functionality (that becomes very complicated to parse and database-heavy to search) - there is only include ("search this") and exclude (!"exclude this" or -"exclude this"). You can however specify tags multiple times in the Mailpit startup flags (--tag 'host1="1.2.3.4" host1="2.3.4.5"') to handle your "OR" situation as you would then just filter by that tag (this is the solution you are probably after).
The search does not include all mail headers (there are just too many which would clutter the database and pollute search results) ~ those prefixes you see there are the only ones stored & indexed. The fulltext search (ie: not prefixed by to: etc) also includes Reply-To and Return-Path, but not hostnames etc

The "word/phrase matches" used in --tag is a 1:1 match on the entire message including headers, so provided you know the hostname then you can tag it as it arrives, and I believe this is the solution you are after.
There is one "catch" you should be aware of though - whilst Mailpit does live load new messages (websockets) as they arrive, this does not apply to filtered views, only the inbox itself. Searches are (in comparison to the inbox) very heavy and slow, so if the server and the browser had to calculate whether each arriving message matches a current search it would cause all sorts of issues. The search needs to be re-run to load new matching messages, or the tag clicked again (tags are effectively just searches, but are much faster to look up than a regular search). I may at some point add live loading to tag views, however I can foresee all kinds of complications and performance issues, so I don't think this will happen any time soon, it at all.
I hope this helps....

Thank you very much for the detailed explanation of how this all works!
The live loading of filtered views would be really nice but we can deal with hitting refresh on the browser.
Being able to search on any header would be nice as well but we can look at using --tag for this.
OR searching would also be nice in the UI but we can also look at using --tag for this.
Thanks again for the help.

One more idea, maybe when you perform a search, it shows up on the left side like the tags do when you apply a tag. This would avoid the need to bookmark a search and be more consistent with the tag behavior.

I appreciate the ideas, but I believe this would be counterintuitive and not logical to the end user. Filtering by a tag is actually just the same as searching, except the tag is highlighted (active) in the side nav. So if I was to search for a tag and a particular word at the same time, with your logic both a tag would be highlighted as well as something else (eg "search results") which would only appear when searching.
I chose to follow the same UI logic as Gmail, and try to keep the UI as simple as possible.
To achieve what you are after (effectively a refresh of a search), you can just submit the search again as it is already filled in with what you are searching for.

I'm just thinking of something like below.  Just like every tag you add becomes a clickable quick action on the left, it would be helpful for every search you perform (maybe not "tag" based searches) also becomes a clickable quick action on the left.

Thank for the suggestion, but I do not think this is a feasible/good idea. The moment you start doing custom searches the search values can get very long, and there will be potentially a lot of them. This, together with the fact that one ultimately does a lot of searching without realising it, sometimes in combination with tags, I think it will clutter the UI for very little benefit.
What problem exactly are you trying to solve with your suggestion?

repo: axllent/mailpit


text:
lua part:  Sprite3DMaterial => MeshMaterial UNDER 3d/CCMeshMaterial.h

Should be renamed
see axmol/RENAMED_TYPES.md

@halx99
No time to adapt.
Plz close it

repo: axmolengine/axmol


text:
⚖ Register Validator:  MELLIFERA

Network Choice
dentrite-1
Who are you?
As a small team our main focus to a small number of projects that will bring big value to the web3 world. With this approach, we can make unique contributions which required by specific projects (explorers, monitoring tools, web apps). Our developer experience in web3 can be found on our GitHub. https://github.com/mellifera-labs
Also, we had experience providing infrastructure such as IBC, RPCs, restapis, snapshots, state sync.
Community  builder in namada and developer and spec champion in Lava network
Delegator address
axone1cvclz3u9zrpfvrhymds9pjp63x94wcujv95zxf
gentx
{"body":{"messages":[{"@type":"/cosmos.staking.v1beta1.MsgCreateValidator","description":{"moniker":"MELLIFERA","identity":"8F3D842B29B89CC5","website":"https://mellifera.network","security_contact":"team@mellifera.network","details":"Empowering blockchain security and contributing to cosmos ecosystem with technical expertise"},"commission":{"rate":"0.050000000000000000","max_rate":"0.200000000000000000","max_change_rate":"0.010000000000000000"},"min_self_delegation":"1","delegator_address":"","validator_address":"axonevaloper1cvclz3u9zrpfvrhymds9pjp63x94wcujuscsut","pubkey":{"@type":"/cosmos.crypto.ed25519.PubKey","key":"kQCXF8CQHpypKL1guZpCneDerETIbERkUMLAVcFZOoE="},"value":{"denom":"uaxone","amount":"1000000000000"}}],"memo":"f30b33834ddcb95051ab4d0fed9ae85c09b44a44@65.108.100.31:26656","timeout_height":"0","extension_options":[],"non_critical_extension_options":[]},"auth_info":{"signer_infos":[{"public_key":{"@type":"/cosmos.crypto.secp256k1.PubKey","key":"A2th+gbEJJNf/gbCXyWDCBxYZ5k2nYoi1n8YvQS9BftU"},"mode_info":{"single":{"mode":"SIGN_MODE_DIRECT"}},"sequence":"0"}],"fee":{"amount":[],"gas_limit":"200000","payer":"","granter":""},"tip":null},"signatures":["4ucgiB13u6fSg1LPTfR4pFWe2T1dIfNsCQQqpx7bInV1fduYNwDnPtV7/uJ4iReSpbAyjZCjJhX74l6ftCAzbQ=="]}

😉 Here is the corresponding PR: https://github.com/axone-protocol/networks/pull/796

Done 😉 https://github.com/axone-protocol/networks/pull/796

authors: RuslanGlaznyov amimart bot-anik

repo: axone-protocol/networks


text:
Remove ulift

/cc @tsao-chi

bors r+

repo: aya-prover/aya-dev


text:
RPi Box with yLib

version of RPi box with lib

https://github.com/ayaromenok/p3dEmbeddedBoxes


text:
Jenkins conditional release

Would you consider adding this to your Jenkinsfile. Allows for specific make targets to be built, and for github uploads to be skipped. By adding two more parameters and setting the defaults as indicated it will behave exactly as it does now. I find it useful for when wanting just a minimal pinebook build, or xenial-mate-pinebook build, without having to build all the others.
If you're happy with this I'll push another PR for the rock64 build script also, as I've done the same for it.

Since you mention Groovy style... your acceptance of a later commit that changes the stage syntax to stage('release') { } etc ?? Since the current syntax is giving deprecation warnings in the jenkins logs... I have it knocking around in my offline git repo, but haven't pushed it to github yet... indents and all ;)

Yes. Use brackets for stage :)
On Tue, 20 Jun 2017 at 11:55, Peter notifications@github.com wrote:

Since you mention Groovy style... your acceptance of a later commit that
changes the stage syntax to stage('release') { } etc ?? Since the current
syntax is giving deprecation warnings in the jenkins logs... I have it
knocking around in my offline git repo, but haven't pushed it to github
yet... indents and all ;)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/ayufan-pine64/linux-build/pull/14#issuecomment-309704769,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACTpQRDmvyUMEJwxjBwPToGG12VCKwxIks5sF5cdgaJpZM4N9yYc
.

Beautiful ;) I'll do that as a separate PR then once this one is squared away, so to not pollute the purpose of this one ;)

authors: ayufan pfeerick

license: mit


text:
@ayumiymk 有关lexicon search的问题

@ayumiymk 请教一下lexicon search的问题; 我现在的应用是识别发票上的打印文字, 我目前训练了一个文字识别模型,文字识别率在84%; 发票上的文字主要是药品名称和治疗方法名称, 现在我想构建一个词库, 然后采用lexicon search的方法提高文字识别率; 由于发票上的文字经常挨着,而且没有标点符号分隔(比如药品名称左右分别和编号或规格信息挨着), 这样需要自己分词, 分词完后我采用lexicon search的方法来查找词库中匹配的词; 现在的问题是有些发票上识别错的药品名称能够通过lexicon search纠正识别错误, 但也有些识别正确的药品名称会弄错; 我目前所用的lexicon search 方案是调用fuzzywoozy库的extract()函数, 这个函数会计算待查药品名称和词库中的词语之间的edit distance, 并给出一个score;不知道你在采用lexicon search时有没有遇到类似问题?

您好，可以加了联系方式沟通下么？有个地方我没太懂，比如IIIT5K这个数据集，官网只给了一个lexicon.txt，但是很多论文里面都是使用了lexicon50，lexicon1K，请问这个内部是怎么操作的呢？这俩是从lexicon.txt拆分出来的么？如何构建的

@ayumiymk 请教一下lexicon search的问题; 我现在的应用是识别发票上的打印文字, 我目前训练了一个文字识别模型,文字识别率在84%; 发票上的文字主要是药品名称和治疗方法名称, 现在我想构建一个词库, 然后采用lexicon search的方法提高文字识别率; 由于发票上的文字经常挨着,而且没有标点符号分隔(比如药品名称左右分别和编号或规格信息挨着), 这样需要自己分词, 分词完后我采用lexicon search的方法来查找词库中匹配的词; 现在的问题是有些发票上识别错的药品名称能够通过lexicon search纠正识别错误, 但也有些识别正确的药品名称会弄错; 我目前所用的lexicon search 方案是调用fuzzywoozy库的extract()函数, 这个函数会计算待查药品名称和词库中的词语之间的edit distance, 并给出一个score;不知道你在采用lexicon search时有没有遇到类似问题?

您好，可以加了联系方式沟通下么？有个地方我没太懂，比如IIIT5K这个数据集，官网只给了一个lexicon.txt，但是很多论文里面都是使用了lexicon50，lexicon1K，请问这个内部是怎么操作的呢？这俩是从lexicon.txt拆分出来的么？如何构建的

@DongfeiJi 我没有用过IIIT5K的数据集,我使用的我这边项目里的数据集.

在有字典的时候，我是先使用beam search的方法去得到初步的识别结果，然后再在字典中去找编辑距离最小的作为最终的识别结果。用这种方法的话，如果你能确保你的字典里有正确的识别结果，那么是不可能把正确的识别结果弄错的。

@ayumiymk  你说的我有些明白了，我之前识别输出的一些药品名在字典里面没有，这可能导致用lexicon　ｓearch出现错误的输出；那如果我的字典不能涵盖所有的药品名，应该如何避免把正确的结果识别错误？

你可以借助一下识别的得分。设置一个阈值，识别得分低于阈值的，才使用字典；高于阈值的，就直接使用识别结果。
因为通常识别错误的样本，得分都不是很高。

@ayumiymk 谢谢回复

authors: DongfeiJi ayumiymk wenston2006


text:
Test Internet Speed not working

Test Internet Speed is not working,
 module 'speedtest' has no attribute 'Speedtest'

@flyingsonu122  u have to do pip install speedtest-cli not pip install speedtest , then this issue will be fixed.


text:
Add cronjob to remove old images from App Server

Overview
Sets up a cronjob that runs docker system prune  daily on the app server. This should help speed up builds on the app server, and keep Travis from timing out.
Changes

Update cloud-init script to write out /etc/cron.d/docker-prune, which prunes docker images daily
Install vim on the app server, which has no text editor at all
Stop the ECS service, and disable upstart service by commenting out the start on configuration parameter.
Undo the work in #77 that turns up travis logging. It's no longer necessary, and is actually so verbose that deployments are not visible in the travis console logs.

Checklist

[x] PR has a name that won't get you publicly shamed for vagueness
~- [ ] Files changed in the PR have been yapf-ed for style violations~

Demo
Optional. Screenshots, curl examples, etc.
Notes
Optional. Ancillary topics, caveats, alternative strategies that didn't work out, anything else.
Testing Instructions

See travis builds:

https://travis-ci.org/azavea/district-builder-dtl-pa/builds/428312569
https://travis-ci.org/azavea/district-builder-dtl-pa/builds/428351521

SSH into Staging App server. Verify that crontab exists and that ECS isn't running.

$ ssh -A -l ec2-user bastion.staging.pa.districtbuilder.azavea.com

# SSH into App server
$ ssh pa.districtbuilder.internal
[ec2-user@ip-10-0-0-179 ~]$ sudo status ecs
ecs stop/waiting
[ec2-user@ip-10-0-0-179 ~]$ sudo status ecs^C
[ec2-user@ip-10-0-0-179 ~]$ sudo cat /etc/cron.d/docker-prune
@daily root docker system prune -af --filter "until=168h"
[ec2-user@ip-10-0-0-179 ~]$ sudo vim test.txt

Closes #76

This is ready for another pass. I ran into some problems stopping the ECS service with cloud-init; ECS was unable to start completely so the upstart service was stuck restarting, even though it had been overridden/disabled. Instead of using the .override file, I just renamed the service definition to ecs.conf.disabled so that ECS never starts in the first place.

Thanks @pcaisse!

I can't figure out how to exit the editor!

:q! should do the trick next time 👍

repo: azavea/district-builder-dtl-pa


text:
Missing 'package' key attribute on element package at AndroidManifest.xml:10:5-54

I'm facing this issue on v3.0.1
C:\flutter-sdk\flutter\.pub-cache\hosted\pub.dartlang.org\upi_india-3.0.1\android\src\main\AndroidManifest.xml:10:5-54 Error: 	Missing 'package' key attribute on element package at AndroidManifest.xml:10:5-54
Can you tell me whats going wrong? Its urgent and I'm not able to make a build.

You need to upgrade your Android Gradle plugin 4.1+
This is due to new privacy policy of package visibility for Android 11+ Check this for more information
Thanks for bringing this to my attention. I will update the readme.


text:
SharedStateType: add FinalAltitude

Adds final altitude to SharedStateType.
Also in a second commit, auto-formatting and fixing clippy warnings, if this is not desirable, I can remove it.

Looks good to me!

authors: caspianmerlin globin

repo: azimuth-radar/fsd-interface


text:
[ENG-20991] fix return on bootstraps

Fix return from undefined to null on bootstrap when fetch to S3 has invalid credentials.
Include a message from console.log, to show on RTE and to specify the error when there was some problem on fetch assets on S3

I have read the CLA Document and I hereby sign the CLA

authors: MagnunAVFAzion enicio

repo: aziontech/azion-framework-adapter


text:
refactor: reduce try statements when ref comb obj

Builds on the PR for MSI remote references (#603) by refactoring the coalesce block that has multiple nested try statements to only a single try statement.

We wont merge it as looks like the refactoring is not catching modifcations on plan phases.

authors: GlennChia arnaudlh

repo: aztfmod/terraform-azurerm-caf


text:
Improve azurerm_windows_virtual_machine Resource Name Length up to 64 characters

Since Azure Resource Manager (ARM) was introduced, the possible length of a windows vm resource name is up to 64 characters.
At the moment this is not possible because the naming provider does it restrict to max. of 15 characters.
Either if we use the "passthrough" or "clean_input" option it is not possible to go up to the max of 64 characters.
In the naming provider this should be increased to the maximum of 64 characters, in order to have the maximum available.
While the azurerm_windows_virtual_machine  name resource is used for the host-/computername too, the max. length of 15 characters for this property should be restricted directly in referencing modules itself.  It may be achievable with the substr() function of terraform

Closing as merged and released in 1.2.21

repo: aztfmod/terraform-provider-azurecaf


text:
🛑 azuma doa: Mailing Service is down

In 4bf2b88, azuma doa: Mailing Service (https://azuma-health.tech/health/doa-mailing) was down:

HTTP code: 0
Response time: 0 ms

Resolved: azuma doa: Mailing Service is back up in b16a965 after 58 minutes.

repo: azuma-healthtech-public/uptime-prd


text:
nx_azure_iot_json_writer_append_property_with_double_value doesnt return meaningful failure errors

As outlined in https://github.com/azure-rtos/getting-started/discussions/337, the customer had a hard to diagnosing the returned error from his call to the json writer as it returned a generic error NX_AZURE_IOT_SDK_CORE_ERROR.
Upon investigation, it seems that this function swallows all errors from the embed c-sdk. In this case the user was unable to know that they had exceeded the memory buffer, even though this is reported back to nextduo, until he debugged into the function.
The preference would be to map the underlying c-sdk errors codes to netxduo errors codes and return these to the customers.

Thanks @ryanwinter for reporting this issue, we will check it.

Closing. Created internal task for investigation.

authors: bo-ms ryanwinter

repo: azure-rtos/netxduo


text:
mark zoom as not movable

moving $HOME/.zoom and setting $SSB_HOME doesn't really do anything since the next run of zoom re-creates the $HOME/.zoom dir with similar contents

Thank you!


text:
Dot after "function" inside a generator doesn't throw

Input Code

function* foo() {
  (function.fn() {});
}

https://astexplorer.net/#/gist/4a6290c9416046ef323f5cef1202e28f/latest
Babylon/Babel Configuration

The functionSent plugin must be disabled.
Expected Behavior

It should throw
Current Behavior

The dot is ignored
Your Environment

software
version

Babylon
7.0.0-beta.16

Hey @nicolo-ribaudo! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.
If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

authors: hzoo nicolo-ribaudo

repo: babel/babylon


text:
MODIFICATION: Files Area

The 'Files' area needs to be modified to be a dropdown selection of the potential files with the functions adjusting to that dropdown selection. Right now, the real estate is very tight and has no room for additional files. There are most likely more files coming with expanded functionality.

This will be made available in the next release:

This is available as of v2024.10.29.1540


text:
Clarify some text strings

Hi, I thought these would make the meanings of these hints more clear (e.g., "Automatically add bookmarks" to me sounds like new bookmarks would be created).  Thanks for your work on this!

Thank you, I agree with you about the wording there :)

authors: JimB-Dev babyman

repo: babyman/quick-tabs-chrome-extension


text:
🛑 SM Service is down

In d96f6a6, SM Service (http://smservice.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SM Service is back up in 9145c29 after 24 minutes.

repo: bachmannschumacher/upptime


text:
🛑 SM Service is down

In d18f16f, SM Service (http://smservice.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: SM Service is back up in 6cb5025.


text:
added  datetimepicker

added datepicker for Contract maker

закрываю - не работает на мобильных
приступил к поиску другой библиотеки

repo: backmeupplz/fondu


text:
🐛 Bug Report: [Regression] Members list empty when there are confirmed members

📜 Description
The members list on the Group view is empty even though we can see there are members by looking at the User view
👍 Expected behavior
The member list should be populated with the proper members
👎 Actual Behavior with Screenshots
The member list is empty for all Groups. For example "Breanna Davidson" is part of Team A - https://demo.backstage.io/catalog/default/user/breanna.davison. When you look at Team A the member list is empty- https://demo.backstage.io/catalog/default/group/team-a
👟 Reproduction steps

Create a backstage instance
View a Group

Notice: the member list is empty
📃 Provide the context for the Bug.
This is a regression as we previously could see the members of the group in this view
🖥 Your Environment
OS:   Darwin 23.1.0 - darwin/arm64
node: v18.18.2
yarn: 3.5.0
cli:  0.25.0-next.1 (installed)
backstage:  1.21.0-next.2

Dependencies:
  @backstage/app-defaults                                     1.4.6-next.1
  @backstage/backend-app-api                                  0.5.8, 0.5.9-next.1
  @backstage/backend-common                                   0.19.9, 0.20.0-next.1
  @backstage/backend-defaults                                 0.2.8-next.1
  @backstage/backend-dev-utils                                0.1.2
  @backstage/backend-openapi-utils                            0.1.1-next.1
  @backstage/backend-plugin-api                               0.6.7, 0.6.8-next.1
  @backstage/backend-tasks                                    0.5.12, 0.5.13-next.1
  @backstage/catalog-client                                   1.4.6, 1.5.0-next.0
  @backstage/catalog-model                                    1.4.3
  @backstage/cli-common                                       0.1.13
  @backstage/cli-node                                         0.2.0
  @backstage/cli                                              0.25.0-next.1
  @backstage/config-loader                                    1.5.3
  @backstage/config                                           1.1.1
  @backstage/core-app-api                                     1.11.2-next.1
  @backstage/core-compat-api                                  0.0.1-next.1
  @backstage/core-components                                  0.13.9-next.1
  @backstage/core-plugin-api                                  1.8.1-next.1
  @backstage/e2e-test-utils                                   0.1.0
  @backstage/errors                                           1.2.3
  @backstage/eslint-plugin                                    0.1.4-next.0
  @backstage/frontend-plugin-api                              0.4.0-next.1
  @backstage/integration-aws-node                             0.1.8
  @backstage/integration-react                                1.1.22-next.1
  @backstage/integration                                      1.7.2, 1.8.0-next.1
  @backstage/plugin-api-docs                                  0.10.2-next.2
  @backstage/plugin-app-backend                               0.3.56-next.1
  @backstage/plugin-app-node                                  0.1.8-next.1
  @backstage/plugin-auth-backend-module-atlassian-provider    0.1.0-next.1
  @backstage/plugin-auth-backend-module-gcp-iap-provider      0.2.2-next.1
  @backstage/plugin-auth-backend-module-github-provider       0.1.5-next.1
  @backstage/plugin-auth-backend-module-gitlab-provider       0.1.5-next.1
  @backstage/plugin-auth-backend-module-google-provider       0.1.5-next.1
  @backstage/plugin-auth-backend-module-oauth2-provider       0.1.5-next.1
  @backstage/plugin-auth-backend-module-oauth2-proxy-provider 0.1.0-next.0
  @backstage/plugin-auth-backend-module-okta-provider         0.0.1-next.1
  @backstage/plugin-auth-backend                              0.20.1-next.1
  @backstage/plugin-auth-node                                 0.4.1, 0.4.2-next.1
  @backstage/plugin-badges-backend                            0.3.5-next.1
  @backstage/plugin-badges                                    0.2.52-next.1
  @backstage/plugin-catalog-backend-module-github             0.4.6-next.1
  @backstage/plugin-catalog-backend                           1.15.1-next.1
  @backstage/plugin-catalog-common                            1.0.18
  @backstage/plugin-catalog-graph                             0.3.2-next.1
  @backstage/plugin-catalog-node                              1.5.0, 1.5.1-next.1
  @backstage/plugin-catalog-react                             1.9.2-next.1
  @backstage/plugin-catalog                                   1.16.0-next.2
  @backstage/plugin-cost-insights-common                      0.1.2
  @backstage/plugin-cost-insights                             0.12.17-next.1
  @backstage/plugin-events-node                               0.2.17-next.1
  @backstage/plugin-explore-backend                           0.0.18-next.1
  @backstage/plugin-explore-common                            0.0.2
  @backstage/plugin-explore-react                             0.0.34-next.1
  @backstage/plugin-explore                                   0.4.14-next.1
  @backstage/plugin-github-actions                            0.6.9-next.1
  @backstage/plugin-graphiql                                  0.3.1-next.2
  @backstage/plugin-home-react                                0.1.6-next.1
  @backstage/plugin-home                                      0.6.0-next.1
  @backstage/plugin-org                                       0.6.18-next.1
  @backstage/plugin-permission-common                         0.7.10
  @backstage/plugin-permission-node                           0.7.18, 0.7.19-next.1
  @backstage/plugin-permission-react                          0.4.18-next.1
  @backstage/plugin-proxy-backend                             0.4.6-next.1
  @backstage/plugin-scaffolder-common                         1.4.3
  @backstage/plugin-search-backend-module-catalog             0.1.12-next.1
  @backstage/plugin-search-backend-module-explore             0.1.12-next.1
  @backstage/plugin-search-backend-module-techdocs            0.1.12-next.1
  @backstage/plugin-search-backend-node                       1.2.12-next.1
  @backstage/plugin-search-backend                            1.4.8-next.1
  @backstage/plugin-search-common                             1.2.8
  @backstage/plugin-search-react                              1.7.4-next.1
  @backstage/plugin-search                                    1.4.4-next.2
  @backstage/plugin-tech-radar                                0.6.11-next.2
  @backstage/plugin-techdocs-backend                          1.9.1-next.1
  @backstage/plugin-techdocs-node                             1.11.0-next.1
  @backstage/plugin-techdocs-react                            1.1.14-next.1
  @backstage/plugin-techdocs                                  1.9.2-next.2
  @backstage/plugin-todo-backend                              0.3.6-next.1
  @backstage/plugin-todo                                      0.2.32-next.1
  @backstage/plugin-user-settings                             0.7.14-next.2
  @backstage/release-manifests                                0.0.11
  @backstage/test-utils                                       1.4.6-next.1
  @backstage/theme                                            0.5.0-next.0
  @backstage/types                                            1.1.1
  @backstage/version-bridge                                   1.0.7

👀 Have you spent some time to check if this bug has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
No, but I'm happy to collaborate on a PR with someone else

Did some digging into this as it got mentioned on Discord and seemed odd: https://discord.com/channels/687207715902193673/1179775361366626345. I've been able to confirm that it works in the current 1.20.3 release so it must be a change in one of the 1.21.0-next.x releases
From my very basic investigation if I console.log the membersList.items from this line I get and empty array:https://github.com/backstage/backstage/blob/701fdd4cad7b602a160d989adfa29cabe25b82cc/plugins/org/src/components/Cards/Group/MembersList/MembersListCard.tsx#L178

repo: backstage/backstage