text:
the sentence does not make sense

I've attempted to have it make more sense by removing the word 'is'.  Optionally, depending on the intended meaning, the sentence could read differently by leaving the word 'is' alone and changing the word 'through' to 'though'.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.
For 1.14 Features: set Milestone to 1.14 and Base Branch to dev-1.14
For Chinese localization, base branch to release-1.12
For Korean Localization: set Base Branch to dev-1.13-ko.
Help editing and submitting pull requests:
https://kubernetes.io/docs/contribute/start/#improve-existing-content.
Help choosing which branch to use:
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

/check-cla

Thanks for the PR @proth1!!!Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).
memo Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA.
It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

I signed the CLA. Thanks

/check-cla

Hey there! @proth1, looks like you haven't signed the CLA yet. Could I please have you do that? https://github.com/kubernetes/community/blob/master/CLA.md

sorry. I thought I had signed but now I have definitely signed the CLA.
Thanks,

Thanks for the PR @proth1 !!!!
I checked the update on https://deploy-preview-12673--kubernetes-io-master-staging.netlify.com/docs/concepts/services-networking/ingress/
I guess the intent was: An optional host. In this example, no host is specified, so the rule applies to all inbound HTTP traffic though the IP address is specified.
@zparnold could you please take a look at this PR.

/assign @chenopis

@chenopis could you please take a look at this PR and confirm the intent.

IMO， the fix is wrong

It looks to me as though the original indeed does not make sense, as the author points out, but the fix doesn't clear anything up, either. I don't know enough about Ingress to suggest the right fix, but page context suggests that without the optional host, traffic is routed through the default backend. With or without the fix, the doc as is also suggests that the HTTP IP address (specified in the Service spec?) is used in place of the optional host.

@proth1 @stewart-yu would it be more technically accurate if it was "the rule applies to all inbound HTTP traffic through the Kubernetes node"?

/hold
until feedback is addressed

/hold cancel
/lgtm
/approve
This fix is correct.


text:
New Linux Academy Content Added

Edit: Listed courses in alphabetical order & removed UTM from links.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.
For 1.14 Features: set Milestone to 1.14 and Base Branch to dev-1.14
For Chinese localization, base branch to release-1.12
For Korean Localization: set Base Branch to dev-1.13-ko.
Help editing and submitting pull requests:
https://kubernetes.io/docs/contribute/start/#improve-existing-content.
Help choosing which branch to use:
https://kubernetes.io/docs/contribute/start#choose-which-git-branch-to-use.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

checked the updates on: https://deploy-preview-12711--kubernetes-io-master-staging.netlify.com/docs/tutorials/online-training/overview/
/lgtm
/approve

source: gharchive/pull-request

repo: kubernetes/website

license_type: permissive

license_source: github-api


text:
changed the formatting of example-ingress.yaml

change the formatting of example-ingress.yaml file.
Raising PR for #14284

/lgtm
/approve


text:
Add content/es/docs/reference/glossary/application-developer.md

refs #13948

thanks @glo-pena

@glo-pena I'm happy to use GitHub suggestions is you like. :-D

/hold  Needs squashing b4 merge.
/assign @raelga

(squashed)

Accepted suggestions and squashed

Muchas gracias @ignasi35 !
Faltaría la confirmación de @glo-pena y lo publicamos!
/lgtm

/lgtm

Muchas gracias @ignasi35 and @glo-pena!
/approve

authors: glo-pena ignasi35 raelga


text:
WIP: storage: CSI inline volumes in beta

Kubernetes 1.16 graduates this feature to beta.
Related-to: https://github.com/kubernetes/website/pull/14704,
https://github.com/kubernetes/enhancements/issues/596

/hold
The feature has not been promoted to beta yet.

@pohly 👋 Please change the base from master to dev-1.16.
/milestone 1.16

/lgtm

/hold cancel
https://github.com/kubernetes/kubernetes/pull/82004 has been merged.
I also changed the base to dev-1.16. Do I also have to change master?

You should not need to update master

Page previews:
https://deploy-preview-15705--kubernetes-io-master-staging.netlify.com/docs/concepts/storage/volumes/
https://deploy-preview-15705--kubernetes-io-master-staging.netlify.com/docs/reference/command-line-tools-reference/feature-gates/

/lgtm

Once the 2 issues raised have been addressed, this can be merged.

@pohly This PR is deadline for merging is Sep 9.

@simplytunde: please have another look, I updated the PR.

Awesome @pohly . Thanks for all your work.
/lgtm

/approve

authors: kbhawkey msau42 pohly simplytunde zacharysarah


text:
Fix #14435 - Change federation documentation link to v2 in ingress.

Fixes - https://github.com/kubernetes/website/issues/14435

/lgtm

/approve

authors: daminisatya miteshskj


text:
fix kubectl docs #config overflow on large screens

fixes #22042

Specific preview: https://deploy-preview-22057--kubernetes-io-master-staging.netlify.app/docs/reference/generated/kubectl/kubectl-commands#config

/reopen
Oops, misclick.

/lgtm
/approve
Thanks @SaiHarshaK

authors: SaiHarshaK sftim


text:
[zh] add page: /zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/ fix 24086

add file: content/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity.md
translate the file from its english version

close #24086

tangqm,
All done, Thanks

/lgtm
/approve

authors: tengqm zhiguo-lu


text:
[id] Indonesian translation of page quality-service-pod

~This PR adds new Indonesian translation of
content/id/docs/tasks/configure-pod-container/quality-service-pod.md~
Part of #25025
This PR adds:

[X] new Indonesian translation of
content/id/docs/tasks/configure-pod-container/quality-service-pod.md

[X] example on /example/pods/qos as the page dependencies

sorry for the flaky test. I didn't know the page has dependencies. it seems ok now.

any chance this will get reviewed?
/cc @girikuncoro

@frbimo next time please bump in our slack channel if we are too slow to review, thanks again!

@frbimo next time please bump in our slack channel if we are too slow to review, thanks again!

hi @girikuncoro , thanks for the info. But seems i havent invited yet but thats ok.
ill just ping you here.

@girikuncoro any chance to get reviewed?

@girikuncoro any chance to get reviewed?

update as @habibrosyad suggested. kindly ask for final review.

update as @habibrosyad suggested. kindly ask for final review.

authors: frbimo girikuncoro


text:
Create 2016-04-00-Adding-Support-For-Kubernetes-In-Rancher.md

/approve


text:
ja: Fix the translation about nodeSelectorTerms of Node affinity

Node affinity の nodeSelectorTerms に関する記述で翻訳では真逆の説明がされています。

If you specify multiple nodeSelectorTerms associated with nodeAffinity types, then the pod can be scheduled onto a node if one of the nodeSelectorTerms can be satisfied.

誤:  nodeAffinity内で複数のnodeSelectorTermsを指定した場合、Podは全てのnodeSelectorTermsを満たしたNodeへスケジュールされます。
正:  nodeAffinity内で複数のnodeSelectorTermsを指定した場合、PodはいずれかのnodeSelectorTermsを満たしたNodeへスケジュールされます。

If you specify multiple matchExpressions associated with nodeSelectorTerms, then the pod can be scheduled onto a node only if all matchExpressions is satisfied.

誤:  nodeSelectorTerms内で複数のmatchExpressionsを指定した場合にはPodはいずれかのmatchExpressionsを満たしたNodeへスケジュールされます。
正:  nodeSelectorTerms内で複数のmatchExpressionsを指定した場合にはPodは全てのmatchExpressionsを満たしたNodeへスケジュールされます。

https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity

パックポートが可能ならお願いできるとありがたいです。

誤訳のご指摘ありがとうございます！
こちら対応のhistoryを確認して、バックポートの対応も行うようにします 🙏
/approve

ご対応ありがとうございます!
/lgtm

authors: inductor kakts superbrothers


text:
kubeadm upgrade to the latest patch release, not the latest stable

to fix a review comment in 29746:
kubeadm upgrade to the latest patch release, not the latest stable

/sig cluster-lifecycle

@sftim would you help to review this PR? Thanks a lot.

/assign @kbhawkey

Thank you, this is a follow-up to a comment in PR https://github.com/kubernetes/website/pull/29746#discussion_r711796974
/approve

authors: RinkiyaKeDad reylejano silenceshell


text:
[fr] update KubeCon date

/assign @remyleone

/lgtm
/approve

authors: Arhell remyleone


text:
[bn] Remove duplicate description paragraph from scheduling index page

Remove duplicate description paragraph from scheduling index page  in bangla version
tracking issue : #31677

/approve

/approve

/lgtm


text:
[zh-cn]sync kube-proxy-config.v1alpha1.md

content/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1.md

/lgtm

/approve

authors: my-git9 tengqm windsonsea


text:
apply templates/concept and fix code snippets

apply templates/concept
fix code snippets style
fix a dead link

preview is here
original

/approve
/lgtm

authors: chenopis makocchi-git


text:
fix the command output

fix the command output

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
For 1.12 Features: set Milestone to 1.12 and Base Branch to release-1.12
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Please delete this note before submitting the pull request.

/lgtm
/approve
Nice to have the sample outputs updated.


text:
Proposal for new maintainer in the project

I am proposing @amirmalka to be a maintainer in the project starting 2025

SGTM.  Why not as of right now?

SGTM. Why not as of right now?

As per the governance, we will vote for new maintainers in the quarterly meeting

I don't think that's particularly practical, I'll vote to change the governance if needed 😁

Welcome to Maintainer Club, Amir!

source: gharchive/issue

authors: craigbox slashben

repo: kubescape/project-governance


text:
Check for command-line tools on startup

Monokle currently expects kubectl and Helm to be installed/configured for corresponding functionality - to improve user experience we should:

check if they're installed/available on startup and show warning if they aren't
show "required tool not installed" errors when trying to perform depending actions in the UI (possibly with links to installation instructions?)

suggest to use shelljs.which to check if a tool is installed... also, we should do the check in the main thread (but can start it from the renderer after startup)

repo: kubeshop/monokle

license: MIT


text:
Modified Webpage

All the needed buttons are modified to align with symmetry and even some text size, color, position, weight is altered for betterment of webpage.
Fixes Issue
#151 #152
Changes proposed

Screenshots

Note to reviewers

can you share ss for different devices so show if it the PR is responsive or not

cc @Brijrajsinh01

can you share ss for different devices so show if it the PR is responsive or not

YES,

cc @Brijrajsinh01

Let me know if anything else is needed.

I need as for mobile view too

closing this cause this was already fixed

repo: kubesimplify/website


text:
Branch not shown in activity list of multi-branch pipeline

Versions Used
KubeSphere: v3.2.0-alpha.0

/kind bug
/cc @kubesphere/sig-console
/priority medium

/area console

nightly20211011 did not have this problem, I close this issue for now.

repo: kubesphere/ks-devops


text:
feature: space framework supports kube-binding between producers and consumers of space functionality

Feature Description
kube-bind provides better isolation between consumers than the baseline Kubernetes API machinery.  It would be good if the space framework supported this better isolation between consumers of the space framework's functionality.
In other words, this is about the space manager being a kube-bind service provider.
Proposed Solution
Do it.
Want to contribute?

[ ] I would like to work on this issue.

Additional Context
No response

@effi-ofer is this something we 'must' address before sept 15th?

@clubanderson I don't think so.  Adding @ezrasilvera to the discussion.

we could live with this not being implemented on Sept 15th, but it will create more debt that we want to clear up within short order thereafter.

Moot.

authors: MikeSpreitzer clubanderson effi-ofer

repo: kubestellar/kubestellar


text:
:sparkles: reworked util.Key and the flow of the Binding controller

Summary
The goal of the previous pluggable-transport work was to switch to pluggable-transport given the existing code-base as grounding, with minimal acceptable changes. During this work, some of the binding workflow and object referencing (util.Key) became suboptimal and redundant for the new flow.
This PR:

Changes the structure (and name) of util.Key, keeping only necessary information to reference an object - that is without a copy of the deleted object when previously needed
Changes the flow of the binding controller: the reconciliation function does not try to retrieve the object being reconciled, but instead passes the new Key (ObjectIdentifier) to syncer functions, which retrieve the object and handle the case of the object being deleted as they should under the new logic

If a bindingpolicy is deleted, we update internal information
If a bindingpolicy is being deleted, we delete finalizer and update internal information
If a workload object is deleted, it is removed from all resolutions that contain it through a new function
If a workload object is being deleted, the previous (pluggable transport) flow is kept

Changes the resolver so that it maintains sets of ObjectIdentifiers, and no longer needs to use the GvkGvrMapper

This PR also:

Refactors loggers following @MikeSpreitzer recent updates (not to use Controller::logger)
Removes unused code

Fixes #1703

/hold
GvkGvrMapper's usage can be further refactored out of the code, which will mostly affect pkg/bindingpolicy.go and the interface/implementation of the mapper. The code can still be reviewed.

/unhold
@MikeSpreitzer pls review

I think the code would get even simpler if all the keying were based on GVR instead of GVK or GVK+R. Most of the Kubernetes libraries deal in GVR; some report both. While kubectl has the proble of user input that only has GVK, this controller does not. This controller is driven by discovery. The only time this controller has a GVK directly at hand without knowing the Resource is when processing an API object retrieved using the dynamic client. But that dynamic client has to be given the GVR before you get to any methods that deliver objects --- so the Resource is, in fact, already known.

@MikeSpreitzer addressed comments.

authors: MikeSpreitzer vMaroon


text:
Update create-cluster script to align with forkliftci

Forkliftci is now deploying mock services for ovirt, vmware and openstack, this PR align the UI ci to the forkliftci new features.

[x] patch services to expose ports outside the cluster ( ui development is done on localmachine )
[x] open new services ports in kind deployment
[x] when deploying the cluster, automatically also deploy kubevirt and forklift
[x] when deploying the cluster automatically install console + plugin ( at http://127.0.0.1:30080 )
[x] when deploying the cluster automatically install volume populator CRD
[x] remove now deprecated .dev plugin services from ci
[x] don't allow running the install console script if console already running

notes on running forkliftci:
# RUN in forkliftci repo code:
# ============================

# install mock ovirt and vmware servers on kind -
# run each line individually, and check for errors while running
bash ./cluster/providers/vmware/setup.sh
bash ./cluster/providers/ovirt/setup.sh

# install packstack on kind -
# for openstack server, you will also need to install nfs server locally
# NOTE: this will install the nfs package on your localmachine
#       and open the nfs server to the world
sudo bash ./cluster/providers/openstack/install_nfs.sh

# install packstack on kind
bash ./cluster/providers/openstack/setup.sh

# wait for packsrack to deploy, and then
# add networks and vms to openstack
bash ./cluster/providers/openstack/create_test_vms.sh

Screenshot:
Forkliftci providers in ready state:

I've noticed that we print errors while checking for resources. It would be nice to catch them as this makes difficult to search for real errors. Examples:

it will be nice to fix that in some future


text:
run kind env on a remote hosted docker

to make it work on a remote docker host :
edit the docker.service to allow TCP communication
systemctl edit docker.service
[Service]
ExecStart=
ExecStart=/usr/bin/dockerd -H fd:// -H tcp://0.0.0.0:2376

Signed-off-by: Evgeny Slutsky eslutsky@redhat.com

@eslutsky the script looks good, maybe besides replacing the hard-coded IP with environment variable but that's minor, but how about adding a readme that includes what you wrote in the description of the PR?

@eslutsky the script looks good, maybe besides replacing the hard-coded IP with environment variable but that's minor, but how about adding a readme that includes what you wrote in the description of the PR?
done,
I've removed the redundant script,   and added some logic to the existing build_and_setup_everything_bazel_manually.sh script.
also removed the need for the exposed docker socket by using docker over ssh .

@eslutsky the script looks good, maybe besides replacing the hard-coded IP with environment variable but that's minor, but how about adding a readme that includes what you wrote in the description of the PR?
I've removed the redundant script,   and added some logic to the existing build_and_setup_everything_bazel_manually.sh script.
also removed the need for the exposed docker socket by using docker over ssh .

authors: ahadas eslutsky


text:
Fix affiliation

Fixing affiliation

Thanks

repo: kubevela/community


text:
Backup and restore the Terraform state

We can build a command line tool to backeup and restore the Configuration Object and the Terraform state. The command line tool may have two subcommands: backup and restore.
The usage of the backup subcommand may like this:
$ tfc backup --help
Backup the Configuration Object, and if the configuration use the default Terraform kubernetes backend, backup the Terraform state too

Usage:
  tfc backup [OPTIONS] CONFIGURATION_NAME

Examples:

  tfc backup -d ./backup_dir configuration-oss-demo

Flags:
  -d, --dir string   Destination directory for saving the backed up files
  -h, --help         help for backup

Global Flags:
      --as string                      Username to impersonate for the operation
      --as-group stringArray           Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
      --cache-dir string               Default cache directory (default "/Users/loheagn/.kube/cache")
      --certificate-authority string   Path to a cert file for the certificate authority
      --client-certificate string      Path to a client certificate file for TLS
      --client-key string              Path to a client key file for TLS
      --cluster string                 The name of the kubeconfig cluster to use
      --context string                 The name of the kubeconfig context to use
      --insecure-skip-tls-verify       If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
      --kubeconfig string              Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string               If present, the namespace scope for this CLI request
      --password string                Password for basic authentication to the API server
      --request-timeout string         The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
  -s, --server string                  The address and port of the Kubernetes API server
      --tls-server-name string         Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used
      --token string                   Bearer token for authentication to the API server
      --user string                    The name of the kubeconfig user to use
      --username string                Username for basic authentication to the API server

The restore subcommand can be used to restore the Configuration Object and it will also restore the Terraform state if the configuration uses the default Terraform kubernetes backend.
When the retore subcommand works, it will accept a yaml file or dir. It fetches the configuration definations from the yaml file or the dir, and check if the configurations use the default kubernetes backend, if the configuration does, the restore subcommand will read the state.json file and restore the bakcend secret before resotring the configuration objects.
The usage of the restore subcommand may like this:
$ tfc restore --help
Restore the Configuration Object, and if the configuration use the default Terraform kubernetes backend, restore the Terraform state too

Usage:
  tfc restore OPTIONS

Examples:

  tfc restore -f ./configuration.yaml

Flags:
  -f, --from string   A file or a directory from where the command read the source definitions
  -h, --help          help for restore

Global Flags:
      --as string                      Username to impersonate for the operation
      --as-group stringArray           Group to impersonate for the operation, this flag can be repeated to specify multiple groups.
      --cache-dir string               Default cache directory (default "/Users/loheagn/.kube/cache")
      --certificate-authority string   Path to a cert file for the certificate authority
      --client-certificate string      Path to a client certificate file for TLS
      --client-key string              Path to a client key file for TLS
      --cluster string                 The name of the kubeconfig cluster to use
      --context string                 The name of the kubeconfig context to use
      --insecure-skip-tls-verify       If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
      --kubeconfig string              Path to the kubeconfig file to use for CLI requests.
  -n, --namespace string               If present, the namespace scope for this CLI request
      --password string                Password for basic authentication to the API server
      --request-timeout string         The length of time to wait before giving up on a single server request. Non-zero values should contain a corresponding time unit (e.g. 1s, 2m, 3h). A value of zero means don't timeout requests. (default "0")
  -s, --server string                  The address and port of the Kubernetes API server
      --tls-server-name string         Server name to use for server certificate validation. If it is not provided, the hostname used to contact the server is used
      --token string                   Bearer token for authentication to the API server
      --user string                    The name of the kubeconfig user to use
      --username string                Username for basic authentication to the API server

Let's discuss a typical restore scenario.
Assume that we have a configuration.yaml like the following, and we use the default Terraform kubernetes backend (the state.json will be sotred in the same cluster as the Configuration Object).
apiVersion: terraform.core.oam.dev/v1beta1
kind: Configuration
metadata:
  name: alibaba-oss-bucket-hcl
spec:
  hcl: |
    resource "alicloud_oss_bucket" "bucket-acl" {
      bucket = var.bucket
      acl = var.acl
    }

    output "BUCKET_NAME" {
      value = "${alicloud_oss_bucket.bucket-acl.bucket}.${alicloud_oss_bucket.bucket-acl.extranet_endpoint}"
    }

    variable "bucket" {
      description = "OSS bucket name"
      default = "vela-website"
      type = string
    }

    variable "acl" {
      description = "OSS bucket ACL, supported 'private', 'public-read', 'public-read-write'"
      default = "private"
      type = string
    }

  backend:
    secretSuffix: oss
    inClusterConfig: true

  variable:
    bucket: "vela-website-20211130-1900-51"
    acl: "private"

  writeConnectionSecretToRef:
    name: oss-conn
    namespace: default

After we apply the configuration.yaml, the cloud resource (the oss bucket named vela-website-20211130-1900-51) will be created, and we can check the status of the cofiguration:
$ kubectl get configuration.terraform.core.oam.dev
NAME                     STATE       AGE
alibaba-oss-bucket-hcl   Available   13s

Now, we can backup the configuration alibaba-oss-bucket-hcl and the terraform state to the local file system, and their filenames are configuration.back.yaml and state.back.json.
Next, we assume that the kubernetes cluster has a disaster and is no longer avaialbe. We need to restore the configuration  to a new kuberentes and don't recreate the cloud resource (the oss bucket is this scenario).
First, we should rebuild the Terraform backend. we can read the Terraform state from the state.back.json and write the data to a secret (whose name and namespace should be detectd by the configuration) in the new kubernetes cluster.
Second, we should restore the configuration object. We can just apply the configuration.back.yaml.

@loheagn What are the exact procedures for restoring the state?

First, we should rebuild the Terraform backend. we can read the Terraform state from the state.back.json and write the data to a secret (whose name and namespace should be detectd by the configuration) in the new kubernetes cluster.

@loheagn What are the exact procedures for restoring the state?

First, we should rebuild the Terraform backend. we can read the Terraform state from the state.back.json and write the data to a secret (whose name and namespace should be detectd by the configuration) in the new kubernetes cluster.

Read the cofiguration.back.yaml and get the meta (namespace and name) of the backend secret which should be created.

Read the state.back.json and use the content (the Terraform state) to build the backend secret. The data should have a key tfstate and the value is the encoded Terraform state string.

@loheagn What are the exact procedures for restoring the state?

First, we should rebuild the Terraform backend. we can read the Terraform state from the state.back.json and write the data to a secret (whose name and namespace should be detectd by the configuration) in the new kubernetes cluster.

Read the cofiguration.back.yaml and get the meta (namespace and name) of the backend secret which should be created.
Read the state.back.json and use the content (the Terraform state) to build the backend secret. The data should have a key tfstate and the value is the encoded Terraform state string.

Any executable commands for step 1 and 2. And how do you verify your restore is successful? Append any evidence for it please.

Hi, @zzxwill , I created a command tool to show how to resotre the state. You can review the code here.
You can just run go run main.go resotre -h for help. And I will add examples and the README later.

@loheagn Please also take a look at this requirement.

And how do you verify your restore is successful? Append any evidence for it please.

authors: loheagn zzxwill

repo: kubevela/terraform-controller


text:
Usernames with special characters mean user settings can't be accessed or updated

ConfigMap keys must be confined to the regex [-._a-zA-Z0-9]+
Usernames in OKD/openshift can have special characters such as @ (e.g. when provisioned through SSO, etc.)
kubevirt-user-settings is stored by username, and as such, errors occur accessing/updating settings when the logged-in user has non-confirming characters in their name.
e.g. the following request off to the API...
[{"op":"replace","path":"/data/me@example.com","value":"{\"quickStart\":{\"dontShowWelcomeModal\":true}}"}]

response
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "ConfigMap \"kubevirt-user-settings\" is invalid: data[me@example.com]: Invalid value: \"me@example.com\": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name',  or 'KEY_NAME',  or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')",
  "reason": "Invalid",
  "details": {
    "name": "kubevirt-user-settings",
    "kind": "ConfigMap",
    "causes": [
      {
        "reason": "FieldValueInvalid",
        "message": "Invalid value: \"me@example.com\": a valid config key must consist of alphanumeric characters, '-', '_' or '.' (e.g. 'key.name',  or 'KEY_NAME',  or 'key-name', regex used for validation is '[-._a-zA-Z0-9]+')",
        "field": "data[me@example.com]"
      }
    ]
  },
  "code": 422
}

I'm not sure if the console has access to the uid of the user object but that is alphanumeric, otherwise potentially usernames could be escaped prior to any setting operations?

Hi @GingerGeek thanks for opening the issue.
This have been fixed here. Can you please share which version you are using?

Hi,
I use Kubevirt via the HCO deployment on OKD.
The image of the console plugin pod is quay.io/kubevirt-ui/kubevirt-plugin@sha256:e79027973b09aac75860f267c7d7f830599978c38a081001f404b9a1c3d2990f which is still the latest image tagged with quay.io/kubevirt-ui/kubevirt-plugin:v4.14.0 - dated Sep 11th 2023. I can see there was a cherry pick back to the 4.14 branch, but I'm guessing this didn't seep through to the quay images and HCO operator?
Let me know if there's anything I can do to collaborate!

I think we should create a new tag on github to update the quay image with the latest 4.14
@metalice do you think is safe to create it from the HEAD of 4.14?

@upalatucci yes we should

there is quay.io/kubevirt-ui/kubevirt-plugin:v4.14.3 - closing this issue

authors: GingerGeek metalice upalatucci

repo: kubevirt-ui/kubevirt-plugin


text:
ServiceAccount Volume compatible with Bound ServiceAccount tokens

Is your feature request related to a problem? Please describe:
Yes, this request should be addressing the need to adapt to the Bound ServiceAccount tokens and projected volumes change.
Describe the solution you'd like:
Due to bound service account tokens, pod level tokens are expiring. Toda KubeVirt generates disk images for a token (http://kubevirt.io/api-reference/main/definitions.html#_v1_serviceaccountvolumesource), thus if it expires, then it's still visible inside the guest, because the token is not getting updated on the virtual disk.
We need to fix this.

Fix how we can do this with disks (i.e. unplug, replug)?
Deprecate the disk approach, and use a file-system (virtiofs) based approach which will always pass through the  current pod level token. Here we need to check that virtiofs can be used in a restricted pod.

I'd personally prefer #2104
Describe alternatives you've considered:
A clear and concise description of any alternative solutions or features you've considered.
Additional context:
Add any other context or screenshots about the feature request here.

/reopen
/remove-lifecycle rotten

This issue should have been addressed in https://github.com/kubevirt/kubevirt/pull/9432 since it allows to expose ServiceAccounts through virtiofs. Therefore, ServiceAccounts changes could be reflected in vmis without requiring to be rebooted. This PR does not deprecate the current ISO based systems, it just add this possibility.

@jcanocan While the above is true, an explicit feature gate is needed. We need to have a look if we can run virtiofs as non-root and without capabilities for these cases.

I have run some test without non-root and without capabilities in the virtiofs container, and the VMI is capable of reading the content of ConfigMaps, Secrets, DownwardAPI and ServiceAccounts.
Regarding the feature gate, are you suggesting to expose a separate feature gate from the VirtIOFSGate specifically for config volumes  i.e. ConfigMaps, Secrets, DownwardAPI and ServiceAccounts shared with virtiofs? e.g. VirtiofsConfigVolumes. If yes, should the user enable both (VirtIOFSGate and VirtiofsConfigVolumes) in order to share their volumes with virtiofs?

@jcanocan

I have run some test without non-root and without capabilities in the virtiofs container, and the VMI is capable of reading the content of ConfigMaps, Secrets, DownwardAPI and ServiceAccounts.

Sounds like upstream worth! Lets get this in.
For the latter we do not need new feature gate but any feature that requires virtiofs should be protected right now unless we get the virtiofs working without capabilites and root.

@jcanocan

I have run some test without non-root and without capabilities in the virtiofs container, and the VMI is capable of reading the content of ConfigMaps, Secrets, DownwardAPI and ServiceAccounts.

Sounds like upstream worth! Lets get this in.
For the latter we do not need new feature gate but any feature that requires virtiofs should be protected right now unless we get the virtiofs working without capabilites and root.

We could implement a mechanism to discriminate when a user tries to share a configVolume with virtiofs. In that case, we can deploy a non-root virtiofs container without capabilities. Moreover, AFAIK --sandbox option needs to be none.  I'm agree that this should be protected with a feature gate, is the existing VirtIOFSGate feature gate good enough in your opinion?

is the existing VirtIOFSGate feature gate good enough in your opinion?
Yes that is enough

/reopen

I think  the final bit would be to support live migration.

authors: fabiand jcanocan xpivarc

repo: kubevirt/kubevirt


text:
Fix perfscale buckets error

What this PR does
Before this PR:
There was an error setting up prometheus.Histogram buckets in operator-observability package
After this PR:
operator-observability version is updated to 0.0.14 which already has the bug fix

Fixes #
Why we need it and why it was done in this way
The following tradeoffs were made:
The following alternatives were considered:
Links to places where the discussion took place:
Special notes for your reviewer

Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.

[ ] Design: A design document was considered and is present (link) or not required
[ ] PR: The PR description is expressive enough and will help future contributors
[ ] Code: Write code that humans can understand and Keep it simple
[ ] Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
[ ] Upgrade: Impact of this change on upgrade flows was considered and addressed if required
[ ] Testing: New code requires new unit tests. New features and bug fixes require at least on e2e test
[ ] Documentation: A user-guide update was considered and is present (link) or not required. You want a user-guide update if it's a user facing feature / API change.
[ ] Community: Announcement to kubevirt-dev was considered

Release note

Fix perfscale buckets error

/test pull-kubevirt-e2e-k8s-1.27-sig-performance

/test pull-kubevirt-e2e-k8s-1.29-sig-performance

/test pull-kubevirt-e2e-k8s-1.27-sig-performance

/cc @enp0s3

@machadovilaca can you please describe what was the bug and the effects? It looks like due to this bug we are not getting any Histogram metrics in kubevirt?
Also, should this be a release blocker since the original code is in release v1.2?

@machadovilaca can you please describe what was the bug and the effects? It looks like due to this bug we are not getting any Histogram metrics in kubevirt?
Also, should this be a release blocker since the original code is in release v1.2?

@alaypatel07 Yes, this should be backported
Histogram metrics should still, but custom bucket definition was not being correctly configured, so we were using the default histogram buckets: https://github.com/prometheus/client_golang/blob/7ac90362b02729a65109b33d172bafb65d7dab50/prometheus/histogram.go#L265

@alaypatel07 were you able to verify that the values are back to normal in https://prow.ci.kubevirt.io/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/11264/pull-kubevirt-e2e-k8s-1.27-sig-performance/1758190792507133952 ?

/release-blocker release-1.2

/release-blocker release-1.2

/retest-required

/test pull-kubevirt-e2e-k8s-1.29-sig-monitoring

@alaypatel07: only kubevirt org members may request release block label

@alaypatel07 the release-blocker falsely claims that all KubeVirt org members are allowed, but only TopLevel approvers are allowed to issue /release-blocker command

/retest

/retest-required

@dhiller thanks a lot for checking. I'll ping one of maintainers next time I want to assign release blocker to an issue

/cherry-pick release-1.2


text:
tests, utils: Check events watcher type before casting

What this PR does / why we need it:
If the watcher events type is Error [1][2] the object inside it is a
metav1.Status instead of an event, this commit Fail the test
if this is the case.
[1] https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/client-go/tools/cache/reflector.go#L459-L465
[2] https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apimachinery/pkg/api/errors/errors.go#L98-L119
Closes #4239
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
This does not resolve the flakiness since we force the test to fail with Fail, we have to discover why we have sometimes
Error events at k8s-1.19
Release note:

NONE

@phoracek done

/hold
Let's also cast to v1.Status and print it, so we see what's there.

Keywords which can automatically close issues and at(@) mentions are not allowed in commit messages.
The list of commits with invalid commit messages:

6ff3a7a tests, utils: Check events watcher type before casting

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

You need to remove the 'Closes' comment in the commit message.

/test pull-kubevirt-e2e-k8s-1.19

/test pull-kubevirt-e2e-k8s-1.19

/retest

/test pull-kubevirt-e2e-k8s-1.19

/test pull-kubevirt-e2e-k8s-1.16

This seems to be the issue:
08:33:50: compilepkg: nogo: errors found by nogo during build-time code analysis:
08:33:50: /root/.cache/bazel/_bazel_root/6f347497f91c9a385dcd9294645b76e0/sandbox/processwrapper-sandbox/1504/execroot/__main__/tests/utils.go:368:10: Sprintf call has error-wrapping directive %w

I just noticed this failure here: https://prow.apps.ovirt.org/view/gs/kubevirt-prow/pr-logs/pull/kubevirt_kubevirt/4246/pull-kubevirt-e2e-k8s-1.16/1309399753045315584
Which leads me to thinking that this other error event might have occurred more often but only got through unnoticed somehow?

/test pull-kubevirt-e2e-k8s-1.19

/retest

/hold cancel

/retest

authors: dhiller qinqon rmohr xpivarc


text:
Fix hotplug race between detach and unmount.

Signed-off-by: Alexander Wels awels@redhat.com

What this PR does / why we need it:
This PR fixes a race condition between unmounting a file system volume and detaching a disk from the running VM. In certain conditions it would attempt to unmount before the disk was fully detached causing the unmount to error and preventing the VM sync from fully detaching. This moves the unmount to after the sync, so this race never happens.
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

/hold

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/test pull-kubevirt-e2e-k8s-1.17-rook-ceph

/retest

/hold cancel

/cherrypick release-v0.36

/test pull-kubevirt-e2e-k8s-1.17

/cherrypick release-0.36


text:
docs: Generate manifests after push images

What this PR does / why we need it:
Just a small update for the getting-started guide. After doing make && make push I was still having old images deployed in my test cluster. I think it worth to mention in the docs that the manifests should be rebuilt.
Bazel push images creates digest files in
bazel-bin/push-<image-name>.digest

The SHA sums are taken from those files and if the manifests are not regenerated after pushing they will contain the old sums.
Special notes for your reviewer:
Release note:

NONE

/lgtm
/approve

authors: rmohr vasiliy-ul


text:
Monitoring VMI Migration Phase Transition Times

What this PR does / why we need it:
This PR introduces a new VMI Migration status field that tracks phase transition timestamps. It also adds two new histogram metrics to help track how long it takes for phase transitions to occur.
This is similar the VMI phase transition metric introduced in the PR #5766, but for the VMI Migration object.
The new histogram metric kubevirt_vmi_migration_phase_transition_time_from_creation_seconds tracks now long since creation it took to transition to the current phase a VMI Migration is in. This would be useful if you wanted to track how long it takes for VMI Migration to go from Creation to Succeeded (completed).
Using variations of that query, we can create graphs that indicate how long it takes for VMIs to reach running, and which phase the VMI spends the most time in.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

Addition of kubevirt_vmi_migration_phase_transition_time_from_creation_seconds metric to monitor how long it takes to transition a VMI Migration object to a specific phase from creation time.

/cc @davidvossel @rthallisey could you please review this PR?

/retest

/retest

Code looks fine to me

/lgtm

/retest

/retest

authors: marceloamaral rthallisey


text:
[release-0.49] Improve non-root path handling

What this PR does / why we need it:
Manual cherry-pick of #8198 and #8268
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
The banncheck commits were omitted because they don't seem to work with this version of Bazel.
Since banncheck is in main and all backports come from there this should be fine.
It also makes this backport less intrusive.
Release note:

Improve path handling for non-root virt-launcher workloads

/hold

/hold cancel

/retest


text:
fix regex for kind/api-change labels

What this PR does / why we need it:
Fixes the labels for kind/api-change
Special notes for your reviewer:
Following the examples from upstream kubernetes documentation: https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#filters
Release note:

NONE

cc @rthallisey @rmohr

/lgtm
/approve

/retest

/ok-to-test

/retest-required

authors: alaypatel07 rmohr rthallisey


text:
Rewrites to VirtControllerRESTErrors* docs

Signed-off-by: Jiří Herrmann jherrman@redhat.com

@sradco LGTM

authors: apinnick jherrman

repo: kubevirt/monitoring


text:
Extend the push command

Change the push command to take two positional parameters:

The policy to be pushed (source)
The registry destination (destination)

This allows to push not only local files, but also policies that are
inside of the local storage.
This makes possible to push an upstream policy into a local registry.
Fixes https://github.com/kubewarden/kwctl/issues/41

The e2e tests are broken for other reasons, I'm going to fix them ASAP

@ereslibre: I've submitted some fixes. Once you're fine with the PR I'll squash and merge

repo: kubewarden/kwctl


text:
Fix iOS detection

Close #12

TY!

authors: dfcreative fliptheweb

repo: kudago/smart-app-banner

license: mit

license_source: bigquery


text:
blog: Add post on static site search with Lunr.js and Preact

Content here is WIP.

Rebased to incorporate #51 and other fixes on main.

repo: kujenga/website


text:
feat(widget): set window-icon

TkEasyGUI のロゴ(docs/image/logo-button.jpg)をDefault Window Icon として設定

Window Icon の指定機能追加

Window.set_icon を private に変更。
Windowの引数にiconが指定されなければ、TkEasyGUIのデフォルトロゴが指定。

import TkEasyGUI as eg

ICON = "./logo.png"

window = eg.Window("", layout = [[]], icon = ICON)

while window.is_alive():
  if window.read()[0] == eg.WIN_CLOSED:
    break

@lanius412 ありがとうございます！

repo: kujirahand/tkeasygui-python


text:
Publish as NPM package

npm install -g concava
concava --config=/path/to/config.js

This also makes using adapters easier. Instead of extending a ConCaVa Docker image, you'd simply make a Dockerfile likes this:
FROM node:5.11

WORKDIR /data
RUN npm install concava@1.0 concava-adapter-mysql@0.5 concava-adapter-mqtt@0.1

ENTRYPOINT /data/node_modules/.bin/concava
CMD "--config=/config.js"

And then:
docker build -t concava .
docker run -d -p 3000:3000 -v /path/to/config.js:/config.js:ro concava

Implementation steps:

Create bin/concava.js which uses Commander JS to provide a CLI
Add bin file to package.json for proper linking
Refactor src/server.js to provide a server interface like Express JS (with default middleware?)
Resolve #19 and allow adding converter and validator types

Export SensorData, SensorAttribute, Converter, Calibrator, Validator etc. Also export Server class - subclass of Express with preregistered middleware?

This also makes updating easier, for example:
docker exec -it concava bash
npm install concava@1.1
exit
docker-compose restart concava

repo: kukua/concava


text:
Future of ts-jest babel integration

Continuation of discussion in #221
This is where we look at how we want to handle babel in the future, default modules and hoisting mock statements.

Responding to comment:
What are 'edge cases' to us maintaining ts-jest is really the 'main case' for users encountering them. No one but these users are best placed to address these issues. What we should focus on, imo, is making it straightforward for users to tune ts-jest to suit their needs.
With that in mind, here's how I think ts-jest needs to evolve:
remove all special handling of synthetic defaults (or anything else). Just process the source code according to the tsconfig settings
create a hook that allows users to pass the output of tsc through any function they provide. The default version of this hook can use babel to address #227

Alright, so it seems like we both agree on one thing:
The default case, no matter how it's handled should per default

compile es6->commonJS modules if allowSyntheticDefaults is set to true
Hoist the jest.mock calls to the top

The two suggestions currently proposed are:

Have this be the default functionality. Use the skipBabel flag to opt out. If users want more customizations they'll have to write their own damn transformer.
Have a hook function that the users can overwrite somehow (point to it via globals?) Use a default hook if no custom hook is provided.

What do we see as the pros and cons of each, and are there other ways?

I'd put it like this

transpile typescript. No special handling for allowSyntheticDefaultImports or anything else. Just let tsc compile based on the tsconfig that the user has specified. This allows the user to get ts-jest to do exactly what they want.
hoist the jest.mock calls to the top

skipBabel won't be needed after this, right?
The hook can be invoked in a manner similar to how jest invokes its transformers. Users can specify a file that exports a function with a particular signature. If this is present, ts-jest will call it.
The question here is - how would this hook affect the use of babel for hoisting?

override the original babel call with the hook. This will make the hook responsible for hoisting
invoke the hook after hoisting. This will result in two calls to babel and be a bit slower
make this behavior configurable using skipBabel. This will increase the complexity of the ts-jest API but avoids the pitfalls of the previous two options

Whatever we choose to do, we need to document it well!

Definitely agree on the documentation.
Another alternative: I imagine the only thing people will want to do is do some sort of babel transpilation.
What if we simply use an existing .babelrc if it exists, and if not, default to simply hoisting the mock calls and transpile the default modules if needed? This way if people need specific configurations they can simply provide their own .babelrc, and otherwise we default to sensible defaults without having to implement a hook api.

What if we simply use an existing .babelrc if it exists, and if not, default to simply hoisting the mock calls and transpile the default modules if needed?

Wouldn't we be introducing babel related complexity in ts-jest by doing this? I personally don't know anything about babel and anything related that could morph into a maintenance issue scares me :)
The only reason we'd be using a default setup to hoist mock calls is because there isn't a typescript only alternative. I haven't really investigated that issue. If there's a way to do this without using babel, that'd be ideal.
It think it would be alright to use an existing .babelrc BUT only if we don't have to do anything more than invoke babel-jest with its.

otherwise we default to sensible defaults without having to implement a hook api

There are some concerns I have around this. How would we be able to decide what are 'sensible defaults'? What about users who need some sort of programmatic way of manipulating tsc's output in, for example, a customized pipeline. Something like this will come up - it always does :smile: The only long term solution seems (at least to me) to provide a way for users to hook into the process.
--
Basically, my preference would be to allow configuration for all things typescript and use a fixed setup for anything babel related. If this fixed setup doesn't work for someone, we can make it simple for them to create their own setup on top of ts-jest, using hooks.
That said, I can see the sense in allowing some sort of configurability for babel because some of the users might have to use babel out of necessity and not choice and they may not be familiar with babel.
What I propose is:

focus our current efforts on typescript compilation and using babel for hoisting (with no configurability)
structure the new ts-jest such that we can allow and support babel configuration in future, through a flag or some other mechanism. So, for example, what you've said about .babelrc can be taken care of. This can be done in small chunks, if required. If at any point there's enough knowledge and bandwidth with the maintainers of ts-jest to support babel related stuff, we can make it fully supported.

This would allow us, in the short term, to focus on getting the default ts-jest setup to work for cases that don't need babel related configuration. We won't spread ourselves too thin. Once we have that locked down, we can start work on making babel a first class option here.

I see your point about the complexity.
I think a sensible default is always to hoist, and I think a sensible default is to transpile modules if allowSyntheticDefault is set to true. I think these are the correct defaults for almost everyone.
I feel like if people need a customized pipeline they're welcome to create their own preprocessor that runs through ts-jest and then theirs afterwards. I'm a little wary if we allow people to add their own custom hooks, then helping them with that aspect is going to fall on our shoulders.
I like your way forward - I still feel like we should transpile the ES6 modules per default as well, however.
(Also we need to resolve how we'll handle the fact that babel currently wrecks our coverage (#211) - do you have any good ideas? I still think copying over the source code from babel-jest, modifying it a little and using that is our best bet.)

could you clarify what you mean by

transpile modules if allowSyntheticDefault is set to true

Yes - sorry. I mean create the synthetic default imports - exactly as we do currently.

I actually think it's the other way around. If we allow configurability, supporting that becomes our job (sort of). If users write their own hook, it's clear that'll be their responsibility. As things mature, we could even provide sample hooks for common scenarios

I think we agree. We both want to minimize configurability, as to not support it - I think maybe we should leave this debate for later?

For the basic setups, coverage actually works well. We have tests that check that.c

Yes, except they currently break with allowsynthethicdefaultimports
What do you mean by For the basic setups, coverage actually works well. We have tests that check that. I think once we minimize the exposed surface area, the linked issue will take care of itself. ?

What's the harm in importing and using babel jest for hoisting? In the worst case, if they change their API, we can pin down an old version. Till then, we can get all updates/fixes directly from there
Normally I think it'd be an excellent idea - except that it breaks the coverage, and the only fix around it I see, is to modify a few line, or mock a function in babel-core.

What other alternatives do you see?

I mean create the synthetic default imports - exactly as we do currently.

ok. What I meant was we stop handling synthetic defaults in a special manner.

We both want to minimize configurability, as to not support it - I think maybe we should leave this debate for later?

That makes sense. We can try to converge on something a bit later.

Yes, except they currently break with allowsynthethicdefaultimports. What do you mean by For the basic setups, coverage actually works well. We have tests that check that. I think once we minimize the exposed surface area, the linked issue will take care of itself. ?

I mean that the current code is too brittle. Specially handling parts like synthetic defaults and babel introduce complexity that can lead to subtle, hard to find bugs. Once me make the processing pipeline simpler (based on this discussion), bugs like these will fall into one of the following categories:

simpler to debug and fix if the fix lies in ts-jest
clear that the fix lies outside ts-jest (in jest, babel-jest or in something like the coverage processor)

the only fix around it I see, is to modify a few line, or mock a function in babel-core.

I didn't consider this when making my previous post. In this case, copying and modifying the bit we need makes sense. Although we should treat that code as part of ts-jest and not a fork that needs to be kept in sync. Is that feasible?

ok. What I meant was we stop handling synthetic defaults in a special manner.

I see, how do you want to handle the transition period between not having the hook architecture / whatever in place, and removing the special handling? This transpilation I think, is vital to a lot of peoples use cases - it definitely is to mine.

I mean that the current code is too brittle. Specially handling parts like synthetic defaults and babel introduce complexity that can lead to subtle, hard to find bugs. Once me make the processing pipeline simpler (based on this discussion), bugs like these will fall into one of the following categories:

simpler to debug and fix if the fix lies in ts-jest
clear that the fix lies outside ts-jest (in jest, babel-jest or in something like the coverage processor)

I don't necessarily agree the code is too brittle, but I do agree that a simpler processing pipeline would be nicer. However I think we need to consider a lot of the complexity comes from us using babelJest in a way it is not meant to be used.

I didn't consider this when making my previous post. In this case, copying and modifying the bit we need makes sense. Although we should treat that code as part of ts-jest and not a fork that needs to be kept in sync. Is that feasible?

Yeah I think that could work, but we'll introduce a lot of dependencies. I'm okay with this.

I see, how do you want to handle the transition period between not having the hook architecture / whatever in place, and removing the special handling? This transpilation I think, is vital to a lot of peoples use cases - it definitely is to mine.

Whatever we choose to do, we should allow the current setup to work as well. For a few versions, we can keep the current pipeline the default so that it doesn't break anything. At the same time, we show a message telling users about the impending change. We'll have a flag for users to switch between the current pipeline and the new pipeline. After a few versions, we can make the new pipeline the default one.

I don't necessarily agree the code is too brittle, but I do agree that a simpler processing pipeline would be nicer. However I think we need to consider a lot of the complexity comes from us using babelJest in a way it is not meant to be used.

We agree there. It is the babel-jest related part that makes the code brittle - because of how it is currently done.

Yeah I think that could work, but we'll introduce a lot of dependencies. I'm okay with this.

as am I

Alright, so currently what we want to do moving forward in the short-term is to:

Grab a copy of babel-jest into ts-jest, so we have full control, and are able to fix #211
Make the babel transpilation seperate from the preprocessor, but simply called after the tsc transpilation
And skippable by SkipBabel
Maintain the current default behaviour, but also hoist jest.mock calls.
Then find out what the optimal migration plan is.

Does this seem like an okay short term strategy ?

yup!

I will see if I can get around to it in a reasonable timeframe :)

we can share the workload - I'm sure none of us have time to work on it full time :)

https://github.com/kulshekhar/ts-jest/tree/new-pipeline ?

Yes - excellent!

So porting the babel pipeline was actually really easy. I've done it in the branch. I've started the foundation for a hook architecture of some sort, but as agreed on, it's a WIP.
This should allow us to hopefully start fixing some babel related issues.

I think I closed this by mistake. I have merged the #236 in.

Do we still need this issue open? I don't think we have anything babel related to look at any more apart from the useBabelRC flag (that has its own open issue)

Agreed.

authors: GeeWee kulshekhar

repo: kulshekhar/ts-jest


text:
Create the Kuma in Production section

Created the new Kuma in Production section in the dev nav based on the Kuma IA rework here: https://docs.google.com/spreadsheets/d/1bdYIFK4RdoOGfunEd1txj8se9bR_6F55aoP3r52rDjc/edit#gid=1809471940
Moved and renamed files per the spreadsheet.
Since they are single sourced, updated the 2.0 and 2.1 nav files to point to the files that I moved with src.
Docs ticket: DOCU-2857

Did you sign your commit? Yes Instructions
Have you read Contributing guidelines? Yes

Marking as a draft because I still have some questions that need to be resolved before this can be merged.

❗ This shouldn't be merged until the corresponding Mesh PR (I'll link it here once it's created) is merged otherwise it will break docs in the Mesh side.

@lahabana can you re-do the review?

@cloudjumpercat kuma does support /latest/ but we redirect them to the corresponding version here.
From the logs:

Redirecting /docs/latest/policies/mesh/ to /docs/latest/production/mesh/ added here
Redirecting /docs/latest/production/mesh/ to /docs/2.1.x/production/mesh/ expected based on the latest -> version

Which means that the redirects are working.
It looks like the file app/_src/policies/mesh.md was renamed to app/_src/production/mesh.md. However, the URL hasn't changed, at least not for 2.1.x and the previous versions.  So all those work just fine, they don't need/use the redirect.
However, It did change for dev though, which means that for the next release, it will make sense to have the redirect (we should also add the correct canonical URLs but that is a different story).
We could remove it and create a ticket or something so that we remember to add it back for the next release.
It fails now because latest is 2.1.x and that version still generates the old URL, but because of the redirects chain mentioned above, it ends up generating the wrong URL and returning a 404.
Does that make sense?

@cloudjumpercat that's correct

@slonka Could you review this again when you have the time? The only failing link is the one you mentioned ( https://chat.kuma.io/) that would be expected to fail.

authors: cloudjumpercat fabianrbz slonka

repo: kumahq/kuma-website


text:
[GSSoC'23] Music Guess Game Completed

PR Description 📜
Title - Music Guess Game
Technology used - HTML, CSS and JS
Fixes #1509

Mark the task you have completed ✅

[x] I follow CONTRIBUTING GUIDELINE & CODE OF CONDUCT of this project.
[x] I have performed a self-review of my own code or work.
[x] I have commented my code, particularly in hard-to-understand areas.
[x] My changes generates no new warnings.
[x] I have followed proper naming convention showed in CONTRIBUTING GUIDELINE
[x] I have added screenshot for website preview in assets/images
[x] I have added entries for my game in main README.md
[x] I have added README.md in my folder
[x] I have added working video of the game in README.md (optional)
[x] I have specified the respective issue number for which I have requested the new game.

Add your screenshots(Optional) 📸
https://github.com/kunjgit/GameZone/assets/114330097/cfb182b7-f129-4ac1-8a72-0c88573e61c7

Thank you soo much for contributing to our repository 💗

@kunjgit  I have added all the changes please review my pull request and merge it into the main branch for a successful contribution under GSSoC'23

Thank you  @Avdhesh-Varshney , for your valuable time and contribution in our GameZone 💗.
It’s our GameZone, so Let’s build this GameZone altogether !!🤝
Hoping to see you soon with another PR again 😇
Wishing you all the best for your journey into Open Source🚀

@kunjgit please add the labels to this pull request. This pull request is not comes on the leaderboard.
Please add the labels as soon as possible.

@kunjgit please add labels. This pr is not comes on the leaderboard.

@kunjgit this pr have merged 2 weeks but still you have not addes labels on this pr. So, that's why this pr is not shown on the leaderboard.
I requested to add label on this pr to come on the leaderboard.

@kunjgit @gurjeetsinghvirdee please add labels on this pr

authors: Avdhesh-Varshney kunjgit

repo: kunjgit/GameZone


text:
gittea x509: certificate signed by unknown authority

when i try to push an image from ansible build docker i get the above error.
docker push git.example.com/fvargas/awx-custom-ee:latest

Gitea is not container registry.

authors: fvargasfrank kurokobo


text:
WebpackError: ReferenceError: window is not defined

When building with GatsbyJS I get this error:

"window" is not available during server side rendering.

WebpackError: ReferenceError: window is not defined
Here's what Gatsby has to say about it:
https://www.gatsbyjs.org/docs/debugging-html-builds/
I'd like to import:
import log from 'loglevel';
import remote from 'loglevel-plugin-remote';

but I need to do it like this:
const log = typeof window !== 'undefined' ? require('loglevel') : null;
const remote = typeof window !== 'undefined' ? require('loglevel-plugin-remote') : null;

This has also been reported for loglevel pimterry/loglevel#146

I noticed that this is not happening for loglevel so I closed pimterry/loglevel#146, but it is happening for loglevel-plugin-remote.
One way to debug:
Install gatsby-cli globally.
gatsby new gatsby-starter-default https://github.com/gatsbyjs/gatsby-starter-default
cd gatsby-starter-default
yarn add loglevel-plugin-remote

In src/pages/index.js add import 'loglevel-plugin-remote';
gatsby build

const win = window;

if (!win) {
  throw new Error('Plugin for browser usage only');
}

https://github.com/kutuluk/loglevel-plugin-remote/blob/master/src/remote.js#L1-L5
Error in error code. But the result is correct - throw an exception in a non-browser environment.

You should not connect the plugin during ssr or connect another plugin that will write logs directly to a file on the server.

const remote = typeof window !== 'undefined' ? require('loglevel-plugin-remote') : null;
Thanks for raising this issue, the above code snippet provided by you helped me hack around the error in my Next.js app.

authors: aman-godara-ria kutuluk webjay

repo: kutuluk/loglevel-plugin-remote


text:
allow pass customized filename for exporting csv

@Juiced66
This PR enables a customized filename for exporting devices to csv file #353.
please review, thanks!

Hi ! Thank you for contributing ! We will review it monday and get back to you !

Can you please target 2-dev branch, I think we will not release it directly but we can try it in next beta !

sure, will change target to dev branch

@Juiced66 the target of PR has been changed to 2-dev. please check, thanks!

repo: kuzzleio/kuzzle-device-manager


text:
about the testing and training

Thanks for your great contribution!
I have a question for testing and training part
You described "We use 1-fold cross-validation and
each sequence is considered as a fold, that is, consider one
sequence as a test set and the others as training sets"
And I understood the LoopClosureDetection based 00,02,05,07,08 sequnce
Could you please tell me in details about which sequnce you used for the 1fold cross validation for testing and training?
Hoping for your reply.
Thanks a lot.

Thanks for your interest!
For example, assume we have 6 sequences (00, 02, 05, 06, 07, 08) in total for the KITTI dataset. Now we can choose 02 as testing data and the others (00, 05, 06, 07, 08) as training data. Basically, each sequence can be chosen as testing data while the remaining other sequences as training data.
Hope it is clear and please feel free to post your confusion.

Thanka a lot!
You guys are so kind and brilliant
浙大牛逼


text:
[UBN] Cannot pass loading screen due to DM API?

Users cannot access the app because the DM api is erroring out.

Resolved d77cba6dee491bfc59c82dbe994a021743904f90


text:
Not working propperly

I believe the extension is not currently being able to propperly infer the code block.Also behaves differently in MacOS (creates lew line in editor) vs. Ubuntu (runs line, but fails to run complete block).

You haven't provided any reproducible example, so I can't do anything with this.
If it behaves differently across platforms, that's entirely out of my hands, as I'm using the platform-independent APIs provided by vscode

authors: kylebarron monteirotorres

repo: kylebarron/vscode-jupyter-python


text:
README: Avoid logging for transient containers

according to paranoid.md. This does make the command line a bit longer but seems to offer a more secure setup for the occasional user who only follows the README. I haven't added any explanations to keep it short.

I think this is fine, thanks!

authors: krlmlr kylemanna

repo: kylemanna/docker-openvpn


text:
SmartPost and additional Service Codes

Added service codes for USPS Domestic and USPS International as well as calls to GetServiceCodes. A client had the need to only accept certain service codes, so we can pull all the service codes via providers and let them exclude. The GetServiceCodes accomplished that.
The better change is added a new provider called FedExSmartPostProvider. Since this required a few changes and it only returns 1 rate due to the change, it will require a call to the Rate API with the FedExProvider to get all but SmartPost and then a follow up call with the FedExSmartPostProvider to get SmartPost rate(s).

@StephenPAdams Thanks! 👍  I am on vacation this week and will take a look next week when I get back -- unless @Soulfire86 wants to review/merge?

No problem! Looks like it's just you @kylewest! Hope you had a great vacay. :)

hey @StephenPAdams,
vacation was great but came back to the real world way behind. looking through your code today and I can't get the fedex tests (regular and smartpost) to pass due to an authentication error. I confirmed my fedex credentials are correct so I'm at a bit of a loss. If I run the sample app with production credentials I get FedEx rates but no SmartPost rates (probably because I don't know which hubId to use.
can you confirm that tests are passing with your test credentials?

Kyle

@kylewest close #31 when this is merged.

@kylewest welcome back! For SmartPost, you need to use your production hubId that is designated to you by FedEx upon request of SmartPost functionality. If not using production, you'll need to use the test hubId (5531) that FedEx mandates per their documentation.
I can confirm this works for my production credentials as I've been using in our staging environment for the last month or so without issue.

@StephenPAdams does it work for you in development though? Here are the unit test results with FedExUseProduction = false

When I switch to FedExUseProduction = true the regular FedEx works but SmartPost does not (because I don't have SmartPost AFAIK).

For reference, here is master:

Issue 1: In master, FedEx was testing in production which shouldn't be the case but I didn't notice. You set it up to test in development which is correct, but now the tests are failing. If it works for you I will get in touch with FedEx to figure out why my credentials aren't working. If it doesn't work for you we'll have to do some digging.
Issue 2: Something in this PR broke the RateManagerFactory (probably the extra base class). I think we just need to update the where in RateManagerFactory: line:17 to exclude your base class. Should be relatively easy.
Let me know about Issue 1 above and we'll take it from there. Thanks for all your work on this.
Kyle

@kylewest #1 works fine here. Do you want to try using my FedEx test credentials? I can email you directly if you want to give them a go.

@StephenPAdams, no, that's OK. I have an email into FedEx developer support to figure it out. Just need to get the tests passing so the build passes and I can push to NuGet. Hopefully I will hear back today and we can get this wrapped up.
Again, thanks for all the help.

MERGED. 👍
Also closes #37 and closes #40.

After fighting with appveyor for a while, deployed v0.9.5.61 to NuGet.

authors: StephenPAdams kylewest

repo: kylewest/DotNetShipping


text:
Security issues when downloading

Receiving a security message that I am unable to bypass when attempting to download.  Downloading as the admin does not work either.  Currently running Win10.

It looks to be an issue with your ClickOnce trust permissions. Here is a link with a solution that resets them back to default: https://superuser.com/a/1488786

Worked like a charm, thanks!
From: kylewill0725 @.>
Sent: Thursday, May 13, 2021 9:10 AM
To: kylewill0725/EDPirateMissionTracker @.>
Cc: jmunoz2141 @.>; Author @.>
Subject: Re: [kylewill0725/EDPirateMissionTracker] Security issues when downloading (#11)
It looks to be an issue with your ClickOnce trust permissions. Here is a link with a solution that resets them back to default: https://superuser.com/a/1488786 . Let me know if this resolves it.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/kylewill0725/EDPirateMissionTracker/issues/11#issuecomment-840665181 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AUB62NGZDXUEFMDACUK6WVTTNP2XLANCNFSM442ZJWHQ .  https://github.com/notifications/beacon/AUB62NBT3UM7IPLN6J67J23TNP2XLA5CNFSM442ZJWH2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOGINYQXI.gif


text:
User can get randomly created GitHub secret key

Description
When user installs GitHub Connector, he specifies repositories he want to connect to. Then, we generate secret key used to set up webhooks. User should be able to get this key, if he wants to create another webhook manually.
AC

[ ] Move secret generation to helm chart
[ ] Prepare instructions how to get the key with one command

kubectl get deployments. -n {NAMESPACE} {DEPLOYMENT_NAME} -o jsonpath='{.spec.template.spec.containers[0].env[3].value}'

repo: kyma-incubator/hack-showcase


text:
Secret Creation is no longer missing DNS Providers

Description

Changes proposed in this pull request:

Adjust getResourceDefs usage
Bind missing translations for git repos
Make it even better by adding resource type in the dropdown.
ALSO fix #1574

Related issue(s)
Closes #1585 , closes #1574

/retest

/retest

/retest

/test pre-busola-integration-test-k3s-namespace

/retest

/retest

/retest

/test pre-busola-local

/test pre-busola-smoke-test-docker

repo: kyma-project/busola


text:
🛑 senoshaidodelasmanos.bogach.es is down

In d434267, senoshaidodelasmanos.bogach.es (https://senoshaidodelasmanos.bogach.es/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: senoshaidodelasmanos.bogach.es is back up in 46e61cd after 11 minutes.

repo: kyryl-bogach/upptime


text:
General Questions

Due diligence

[X] I have done my due diligence in trying to find the answer myself.

Topic
Other / All
Question
Hello! It looks like an incredible mode! I have a few questions about it:

What’s the base architecture/model?
How can I fine-tune it both using text-only and text-to-speech and speech-to-speech (like on a custom voice) in google colab?
Tokenizer type? How can I add some new tokens?
Is it STT, too?
Can it recognize images?
It is supported somewhere else, like llama cpp?

See the paper for details on the architecture.
We don't provide support for fine-tuning yet, though we plan on having some at some point, see the FAQ.
Text tokenizer is sentencepiece, not sure how one would add tokens there.
Moshi is the conversational agent so only does speech to speech. The fundation model and overall process can be used for STT though as mentioned in the paper.
No support for vision at the moment.
Not sure, you will probably have to search for this.

authors: LaurentMazare yukiarimo

repo: kyutai-labs/moshi


text:
feat: more model based validation

Explanation
More model based validation.

/cherry-pick release-0.2

repo: kyverno/chainsaw


text:
Add kindpod specifics

Added clarifications when matching managed/umanaged Pods. Link to discussion

@rdavyd I understand that you would like some clarification on how the auto-gen controller will work for Pods and also a reminder note in the Selecting Resources page. I will take these ideas and figure out a way to put them into the docs in a more integrated way. I think this will be easier than trying to alter your PR, so although I'm closing it, this will go into a task for the next docs update. Thanks for bringing this up.

authors: chipzoller rdavyd

repo: kyverno/website


text:
Add lazy loading for chat

With this thing main chat bundle should be loaded only when user clicked on chat icon
I.e. it helps achieve zero loading time impact on the main site

Mine


text:
Differences between ppr branch and the main branch

Hi Gengshan, thanks for your great work!
I have some questions about the differences between ppr branch and the main branch.

I found that the design of delta_skin in ppr branch and the main branch is different. You remove the time_embedding and add the normalization of xyz_bone in ppr branch. So what is the advantage of this design?
And is the loss weight setting in ppr branch more advanced than the main branch?
Thanks!

Hi Chaoyue, sorry for the late reply. The main branch is similar to BANMo's implementation: delta_skin_t = f(X_t,code_t). The PPR branch represents delta skinning weights as a function of its local bone coordinates: delta_skin = f(X_bone-1, ...X_bone-B), similar to A-NeRF. The ones in the PPR branch are more articulation-dependent / less time-dependent and should generalize better.
The PPR weighting should be better in general. But I did observe it is less stable. Still need some time to verify before a merge.

Hi Gengshan, thanks for your explanation!

authors: ChaoyueSong gengshan-y


text:
kubernetes_manifest cannot be deployed together with argoCD CRD

kubernetes_manifest resources is checked before applying. The problem here is that since ArgoCD CRD is not deployed yet kubernetes does not know Kind: Application which is defined in kubernetes_manifest resource.
Workaround: in first Terraform run set self_managed to false, and kubernetes_manifest will not be applied. In the second run set self_managed to true. This will work.
It did not work with kubernetes provider v2.4.1

Solved in module refactor in #9

authors: Thumbiceq martinhaus

repo: lablabs/terraform-helm-argocd


text:
Feature: Helm command migration

Which command or component
Since that sealos could run cloud image which packed with a helm chart, I would like to have helm list / history / rollback feature on sealos
sealos list
sealos history
sealos rollback
Detailed description of the feature

show helm list

sealos list

NAME 	NAMESPACE	REVISION	UPDATED                             	STATUS  	CHART        	APP VERSION
mysql	demo     	2       	2022-09-19 13:42:42.637858 +0800 CST	failed  	mysql-9.2.0  	8.0.29
redis	demo     	1       	2022-09-06 17:32:36.091464 +0800 CST	deployed	redis-16.9.11	6.2.7

show history

sealos history mysql

1       	Tue Sep  6 17:00:26 2022	superseded	mysql-9.1.0	8.0.29     	Install complete
2       	Mon Sep 19 13:42:42 2022	failed    	mysql-9.2.0	8.0.29     	Upgrade "mysql" failed: cannot patch "mysql" with kind StatefulSet: StatefulSet.apps "mysql" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', and 'updateStrategy' are forbidden

rollback revision

Since the mysql revisoin 2 has problem, I would like to rollback to revision 1
sealos rollback mysql 1

it's for application management, in fact , i want all helm comamnd feature:
sealos uninstall app

sealos run app --helm-set key1=values1

sealos run app -f values.yaml

The cilium cli command line tool does this with --helm-set
cilium install --chart-directory charts/cilium --helm-set kubeProxyReplacement=strict,k8sServiceHost=apiserver.cluster.local,k8sServicePort=6443

if sealos support this , it will be a big feature , and it let sealos be able to run all helm application.
now sealos can not build nfs-csi ceph-csi cloud image, Because these applications require many custom parameters similar to IP addresses.

sealos not care about helm or other command line.
sealos will use application actions to manage applications, user can define his own actions like uninstall rollback backup recover migration and so on.
https://github.com/labring/sealos/issues/1259

authors: fanux john-deng willzhang

repo: labring/sealos


text:
Licence

We want to create an nf-core module based on palom. Currently, no information on the licence of this repository is available (though others e.g., Ashlar, have an MIT licence). It would be very helpful if you could decide on a licence so that the software can be more widely used.
Thanks in advance!

Thank! Closing with 33f5a054d66f7aaf0490d33ea24b0e4c1e9ada62

authors: Yu-AnChen gesavoigt

repo: labsyspharm/palom


text:
Feature/unify tables Closes #4

Applied the missing quotes as suggested in the issue.
Also ignored MacOS auto generated files because Apple...

thanks
closes #4

authors: bergmul lachlandeer

repo: lachlandeer/snakemake-econ-r


text:
update for React 17.x

Using new versions of React, I get this warning:
backend.js:6 Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-async-component-lifecycle-hooks for details.

Move data fetching code or side effects to componentDidUpdate.
If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at: https://fb.me/react-derived-state
Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will work. To rename all deprecated lifecycles to their new names, you can run npx react-codemod rename-unsafe-lifecycles in your project source folder.

Please update the following components: SockJsClient
It's important update the funcions so you can use React 17.x

Fixed in another PR

authors: flashboss lahsivjar

repo: lahsivjar/react-stomp


text:
[CI/CD] integrate GitHub actions

description

integrate GitHub actions into this project

could you please assign this issue to me, thanks!

authors: depapp laidudum

repo: laidudum/api-automation-boilerplate


text:
Produce html report of sayg results

players draw
Somerset super league

#
team1
v
team2

1
---
v
---

2
---
v
---

Board: 1
Gender: Men / Women
Date: /date/
Match log

Team
1

Dart
average

Player
L
AD
GS
SL
100+
140+
180
T
Player
Team
GD
1
...
50

1

2

Team
2

Dart
average

Player
L
AD
GS
SL
100+
140+
180
T
Player
Team
GD
1
...
50

1

2

Summary

match no
Team 1player
legs won
total tons
100+
140+
180
player daverage
Team 2player
legs won
total tons
100+
140+
180
player average

1

total

total

Rounded
average
0

Rounded
average
0

Darts 4
windows average
0

Darts 4
windows average
0

Match report
| | | Team 1 | | | | | | | | | |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Set | Average | Players Name | Leg | 1 | ... | 12 | AD | GD | SL | Tons |

players draw
Somerset super league

#
team1
v
team2

1
---
v
---

2
---
v
---

Board: 1
Gender: Men / Women
Date: /date/

Match log

Team
1

Dart
average

Player
L
AD
GS
SL
100+
140+
180
T
Player
Team
GD
1
...
50

1

2

Team
2

Dart
average

Player
L
AD
GS
SL
100+
140+
180
T
Player
Team
GD
1
...
50

1

2

Summary

match no
Team 1player
legs won
total tons
100+
140+
180
player daverage
Team 2player
legs won
total tons
100+
140+
180
player average

1

total

total

Rounded
average
0

Rounded
average
0

Darts 4
windows average
0

Darts 4
windows average
0

Match report
| | | Team 1 | | | | | | | | | |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Set | Average | Players Name | Leg | 1 | ... | 12 | AD | GD | SL | Tons |


text:
Fix undefined behaviour in split

We should not be calling std::string::back on an empty string.
Closes #825

@ldicker83: See if this fixes the debug assertion you were getting.
May be able to avoid: https://github.com/OutpostUniverse/OPHD/pull/762

Definitely fixes the debug assertion. Simpler change than I suggested too. :D Gonna go ahead and merge this change set.

license: Zlib


text:
LambCI badge URL missing

I've tried to follow the guide on how to add the lambci badge for the build but I think I missed some steps.
I see in the readme.md the following URLs:
Branch log: https://<bucket>/<project>/branches/master/<somehash>.html
Branch status img: https://<bucket>/<project>/branches/master/<somehash>.svg

But In my log I've got only the Branch Log with no Branch status img line.
Looking into S3 I do not find the svg file: does it mean I have to programmatically copy the SVG file in my build script? Or maybe there's an option I missed to enable it?

@dej611 are you looking at a branch build or a pull request build? The URL only shows up on branch builds (doesn't typically make sense to have a badge for a PR)
If you push to master, the URL should show up there

My bad, I made confusion as our main branch has a different name from master, therefore I thought for some strange reason to look at the builds folder.
I think you can close this one now. Thanks.

By all means – if it's resolved you can close it! 👍

repo: lambci/lambci


text:
"Edit activity by pressing e": fix (IMPORTANT)

Ouch, big ouch 🙈

@lamby please please can you release and publish this bugfix? Pressing any key while on the activity page redirects you to editing
Really sorry about that.
On new features, I'll use them for a few days before submitting PR.

Google wasn't letting me until now. Now done.

authors: Strajk lamby

repo: lamby/strava-enhancement-suite


text:
🛑 vipgifts.net is down

In 79166df, vipgifts.net (https://vipgifts.net) was down:

HTTP code: 567
Response time: 740 ms

Resolved: vipgifts.net is back up in 42460b9.

repo: lanen/bs-site


text:
🛑 rexingsports.cn is down

In e2e2f30, rexingsports.cn (https://www.rexingsports.cn) was down:

HTTP code: 567
Response time: 901 ms

Resolved: rexingsports.cn is back up in ea080ea.


text:
🛑 vipgifts.net is down

In 39fb9fa, vipgifts.net (https://vipgifts.net) was down:

HTTP code: 567
Response time: 611 ms

Resolved: vipgifts.net is back up in 75f453c after 19 minutes.


text:
🛑 vipgifts.net is down

In de3a909, vipgifts.net (https://vipgifts.net) was down:

HTTP code: 567
Response time: 701 ms

Resolved: vipgifts.net is back up in deb72a5 after 18 minutes.


text:
🛑 vipgifts.net is down

In 2b8ecab, vipgifts.net (https://vipgifts.net) was down:

HTTP code: 567
Response time: 792 ms

Resolved: vipgifts.net is back up in 27bbb44 after 25 minutes.


text:
Issue using openai v1.6.1

(base) ➜  singularity-bowtie2 git:(main) ✗ painy comment
Changed files: README.md
Traceback (most recent call last):
  File "/home/icaoberg/miniconda3/bin/painy", line 8, in <module>
    sys.exit(main())
             ^^^^^^
  File "/home/icaoberg/miniconda3/lib/python3.11/site-packages/painy/main.py", line 97, in main
    msg = get_commmit_message(diff_str)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/icaoberg/miniconda3/lib/python3.11/site-packages/painy/comment.py", line 44, in get_commmit_message
    response = model.get_response(prompt=diff_str)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/icaoberg/miniconda3/lib/python3.11/site-packages/painy/chat.py", line 40, in get_response
    response = openai.ChatCompletion.create(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/icaoberg/miniconda3/lib/python3.11/site-packages/openai/lib/_old_api.py", line 39, in __call__
    raise APIRemovedInV1(symbol=self._symbol)
openai.lib._old_api.APIRemovedInV1:

You tried to access openai.ChatCompletion, but this is no longer supported in openai>=1.0.0 - see the README at https://github.com/openai/openai-python for the API.

You can run `openai migrate` to automatically upgrade your codebase to use the 1.0.0 interface.

Alternatively, you can pin your installation to the old version, e.g. `pip install openai==0.28`

A detailed migration guide is available here: https://github.com/openai/openai-python/discussions/742

Issue with the latest version of painy using openai == 1.6.1.

@icaoberg Yeah, the problem now there is no specified version in requirements.txt, I will add it soon, also I'll migrate it to langchain from my temporary solution. As a temporary solution please install openai==0.28, sorry for the confusion, it's a very small project that hasn't gotten a lot of attention.

@lanesket no biggies I realized this change in openai has affected many projects, not just yours. I will open a PR for your

@icaoberg I've migrated tool to langchain in order not to create my own solution based on OpenAI. Try it now, hope everything is solved.

authors: icaoberg lanesket

repo: lanesket/painy


text:
Resources page

Resources that need to find a home on the website:

https://planner.langaracs.tech

course availability (https://docs.google.com/spreadsheets/d/1au-d_-j5VrDwNvTFUHbp8WI_URfDc9lGSvi1eUiTJXE/edit#gid=0)

course outlines (see #course-outlines channel on discord)

user-contributed notes for courses

Jon's transfer guide

other transfer guides (https://old.reddit.com/r/langara/wiki/index)

other transfer resources (slides from the transfer panels)

It might be better to split into a resources page and transfer information page.

closed by b848cd7
(only took 10 months...)

repo: langaracpsc/langaracpsc-next


text:
community: fix milvus auto_id insertions

Description: remove auto id field from insertion list in Milvus,
Issue: None,
Dependencies: None,
Twitter handle: matpbo

cc @fzliu

authors: baskaryan matpb

repo: langchain-ai/langchain


text:
Prem AI langchain integration (migrating PR from org account to personal account)

Prem SDK integration in LangChain
This PR adds the integration with PremAI's prem-sdk with langchain. User can now access to deployed models (llms/embeddings) and use it with langchain's ecosystem. This PR adds the following:
This PR adds the following:

[x]  Add chat support
[X]  Adding embedding support
[X]  writing integration tests

[X]  writing tests for chat
[X]  writing tests for embedding

[X]  writing unit tests

[X]  writing tests for chat
[X]  writing tests for embedding

[X]  Adding documentation

[X]  writing documentation for chat
[X]  writing documentation for embedding

[X] run make test
[X] run make lint, make lint_diff
[X]  Final checks (spell check, lint, format and overall testing)

Hi @baskaryan, I am getting lot of mypy type errors when I was running make lint, so do I have to put type: ignore at every places?

Hi @baskaryan, thanks for the quick review and approval, I am getting lot of mypy type errors when I was running make lint, so do I have to put type: ignore at every places?

most of the mypy failures seem like valid errors, so we should fix them (the error message should tell you what the issue is)

Hi @baskaryan, thanks for the quick review and approval, I am getting lot of mypy type errors when I was running make lint, so do I have to put type: ignore at every places?

most of the mypy failures seem like valid errors, so we should fix them (the error message should tell you what the issue is)

I am just seeing those now, reason was because I explicitly added the package in poetry file, lemme fix that and push again.

Hi @baskaryan, thanks for the quick review and approval, I am getting lot of mypy type errors when I was running make lint, so do I have to put type: ignore at every places?

most of the mypy failures seem like valid errors, so we should fix them (the error message should tell you what the issue is)

Hi, yes I just tried to fix it, can you approve to run the workflow, thanks

Almost there, got some checks failing in the docs, I used make format for this and tried to reproduce the error with make lint_package (the command which was used to run the checks and failing in CI). However I could not reproduce that. Let's see. However other tests are passing.

Hi @ccurme, can you please check this PR whenever you find some time, would be awesome to re-iterate (if any checks failing) as soon as possible and get this merged.
Thanks

Thank you for the merge.

authors: Anindyadeep baskaryan


text:
Added support for Nebula Chat model

Description: Added support for Nebula Chat model in addition to Nebula Instruct
Dependencies: N/A
Twitter handle: @Symbldotai

@eyurtsev I have resolved all your comments barring docs. We do not support tool calling and structured output at this time. Could you please point me to the file where I should note this, for it to appear appropriately in the table?

@eyurtsev I have resolved all your comments barring docs. We do not support tool calling and structured output at this time. Could you please point me to the file where I should note this, for it to appear appropriately in the table?

don't need to add nebula to the table but would be nice to have a separate page for it at docs/docs/integrations/chat/nebula.ipynb, like this for example: https://python.langchain.com/v0.2/docs/integrations/chat/cohere/

@eyurtsev @baskaryan I have added the documentation. Please let me know if there's anything else required

@eyurtsev @baskaryan I have added the documentation. Please let me know if there's anything else required

not passing lint yet. you can run formatting and linting locally with
cd libs/community
poetry install --with lint,typing
make format
make lint

@baskaryan done

Hi @baskaryan is there anything else needed on our end for the final deployment?

Hi @baskaryan @eyurtsev any update on this deployment? The preview looks good, and I think we haven't had any updates in a month. Please let me know if something is needed on my end

@eyurtsev @baskaryan we have an urgent need for this integration, would be very grateful if this merge can be made at the earliest

@eyurtsev @baskaryan could you please tell us what the blocker is, for the merge?

@eyurtsev @baskaryan @ccurme Folks, could you please let us know if/what blocker there is that needs to be addressed for you to merge this? We have customers blocked on this, and need to get the integration in. Thank you!

eyurtsev baskaryan ccurme Folks, could you please let us know if/what blocker there is that needs to be addressed for you to merge this? We have customers blocked on this, and need to get the integration in. Thank you!

CI is blocked on the following:
Docs not matching template:

Document /home/runner/work/langchain/langchain/docs/docs/integrations/chat/symblai_nebula.ipynb does not match the ChatModel Integration page template. Please see https://github.com/langchain-ai/langchain/issues/22296 for instructions on how to correctly format a ChatModel Integration page.

Mypy / typing errors:

langchain_community/chat_models/symblai_nebula.py:35: error: Incompatible types in assignment (expression has type "Union[str, List[Union[str, Dict[Any, Any]]]]", variable has type "str")  [assignment]
langchain_community/chat_models/symblai_nebula.py:135: error: Incompatible types in assignment (expression has type "str", variable has type "Dict[str, Any]")  [assignment]
langchain_community/chat_models/symblai_nebula.py:172: error: Incompatible types in assignment (expression has type "str", variable has type "Dict[str, Any]")  [assignment]
langchain_community/chat_models/symblai_nebula.py:217: error: Incompatible types in assignment (expression has type "str", variable has type "Dict[str, Any]")  [assignment]
langchain_community/chat_models/symblai_nebula.py:252: error: Incompatible types in assignment (expression has type "str", variable has type "Dict[str, Any]")  [assignment]

@ktalamad @sharmisthasg I got this over but needed to do a small refactor and add ignore a type error. Please take a look and test.

@ccurme thanks for the merge, I was able to test the integration! https://python.langchain.com/v0.2/api_reference/community/chat_models/langchain_community.chat_models.symblai_nebula.ChatNebula.html - this link currently gives a 404, is this something that needs to be added on our end? Is it possible to remove it from the docs while the link is broken?

Hi @sharmisthasg, the link should work now that the API docs have built. The content there is determined by the docstring for ChatNebula. You can submit new PRs if you'd like to edit the content at all (feel free to tag me for review).

authors: baskaryan ccurme ktalamad sharmisthasg


text:
chore(ULIDs): Changing uuids to uuid1 for database performance

UUIDs should be uuid1,uuid6,uuid7 or even better snowflakeIDs

our convention is uuid4, we'll likely stick with that


text:
Style: Parts of the mendable AI popup are inaccessible on smaller devices.

My device has a 1366 x 768 display. The fixed position on one of the parents of the Mendable AI dialog causes it not to scroll to the bottom where the input box is. The only way I can scroll further is to zoom out on my screen.
Here's an image of where the scroll stopped when I tried scrolling to the bottom.

CC @nickscamara can you have a look?

@jacoblee93 yep! Just opened a ticket on our end.

repo: langchain-ai/langchainjs


text:
S3 File Loader:Endpoint is missing in configuration

Checklist

[X] I added a very descriptive title to this issue.
[X] I included a link to the documentation page I am referring to (if applicable).

Issue with current documentation:
According to the current configuration https://api.js.langchain.com/interfaces/langchain_document_loaders_web_s3.S3LoaderParams.html
The current configuration is:
const loader = new S3Loader({
  bucket: "my-document-bucket-123",
  key: "AccountingOverview.pdf",
  s3Config: {
    region: "us-east-1",
    credentials: {
      accessKeyId: "AKIAIOSFODNN7EXAMPLE",
      secretAccessKey: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    },
  },
  unstructuredAPIURL: "http://localhost:8000/general/v0/general",
  unstructuredAPIKey: "", // this will be soon required
});

So is it possible to configure the endpoint, which is optional?
Idea or request for content:
After querying @aws-sdk/client-s3, I am convinced that endpoint is an optional configuration.
export interface ClientInputEndpointParameters {
    region?: string | Provider<string>;
    useFipsEndpoint?: boolean | Provider<boolean>;
    useDualstackEndpoint?: boolean | Provider<boolean>;
    endpoint?: string | Provider<string> | Endpoint | Provider<Endpoint> | EndpointV2 | Provider<EndpointV2>;
    forcePathStyle?: boolean | Provider<boolean>;
    useAccelerateEndpoint?: boolean | Provider<boolean>;
    useGlobalEndpoint?: boolean | Provider<boolean>;
    disableMultiregionAccessPoints?: boolean | Provider<boolean>;
    useArnRegion?: boolean | Provider<boolean>;
    disableS3ExpressSessionAuth?: boolean | Provider<boolean>;
}

The API reference documentation is automatically generated based on the source code. However, we are aware it has some limitations, especially around showing types for externally imported types/interfaces, like the one we see in this file: S3ClientConfig.
Is this issue regarding the API ref documentation not showing the types that S3ClientConfig interface contains, or something else? I just checked and it is possible to pass endpoint to the s3Config object of this class.

You can configure it through s3Config.endpoint, the ClientInputEndpointParameters you mentioned is a subset of S3LoaderParams['S3Config'].
Example:
new S3Loader({
  bucket: "my-document-bucket-123",
  key: "AccountingOverview.pdf",
  s3Config: {
    region: "us-east-1",
    endpoint: "your endpoint",
    credentials: {
      accessKeyId: "AKIAIOSFODNN7EXAMPLE",
      secretAccessKey: "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    },
  },
  unstructuredAPIURL: "http://localhost:8000/general/v0/general",
  unstructuredAPIKey: "", // this will be soon required
});

@lawetis

@jeasonnow  Thanks a lot, this was my problem and didn't notice.

authors: bracesproul jeasonnow lawetis