text:
Ability to use same Pipeline with different Resources

(Discovered by @pivotal-nader-ziada while working on #177)
This issue is about deciding on the solution we prefer (see "possible solutions" below) and implementing the change.
Expected Behavior
A user should be able to take an existing Pipeline and run it against their own setup without
modifying the Pipeline itself, meaning using their own:

GitHub fork / branch (e.g. for PR testing)
Image registry
k8s cluster (to deploy to)

Actual Behavior
In the current implementation, to change (3), a user would create their own PipelineParams, so they would not need to change the Pipeline.
But to change (1) or (2), they would have to create new Resources with their specific configuration. Since Resources are bound in the Pipeline, this means they would need to change the Pipeline as well.
We are considering moving clusters out of PipelineParams and into a Resource type (#177), but this would mean that for a user to use their own cluster, they would again need to change the Pipeline.
Possible solutions
@pivotal-nader-ziada and I have prototyped 7 possible solutions in yaml in this branch.

We expand PipelineParams to include a generic list of keys and values, which can be templated
inside all types (e.g. Pipelines, Resources, etc.).
See example_option_1:

pipelines/kritis-resources.yaml contains templating for values like URL and revision
in the Resources

apiVersion: pipeline.knative.dev/v1alpha1
kind: PipelineResource
metadata:
 name: kritis-resources-git
 namespace: default
spec:
 type: git
 params:
 - name: url
   value: ${url}
 - name: revision
   value: ${revision}

pipelineparams.yaml contains the values for these params

    params:
    - name: resources.kritis-resources-git.url
      value: https://github.com/grafeas/kritis
    - name: resources.kritis-resources-git.revision
      value: master
    - name: resources.kritis-resources-test-git.url
      value: https://github.com/grafeas/kritis-test
    - name: resources.kritis-resources-image.url
      value: gcr.io/staging-image
    - name: resoruces.kritis-test-cluster.endpoint
      value: 'https://prod.gke.corp.com'

_This is very similar to option 3, the difference is that in this version we still have
Resource CRDs, which would need to be updated on any changes to PipelineParams.

PipelineParams can override values inside of Resources.
This would be basically the same as option 1, except limited to Resources instead of working
for any CRD.

Instead of declaring Resources as separate CRDs, we define them all inside PipelineParams
See example_option_3:

pipelineparams.yaml now contains all Resource definitions

    resources:
      - name: kritis-resources-git
        spec:
          type: git
          params:
          - name: url
            value: https://github.com/grafeas/kritis
          - name: revision
            value: master
      - name: kritis-resources-test-git
        spec:
          type: git
          params:
          - name: revision
            value: master
          - name: url
            value: https://github.com/grafeas/kritis-test
      - name: kritis-resources-image
        spec:
          type: image
          params:
          - name: url
            value: gcr.io/staging-image
      - name: kritis-test-cluster
        spec:
          type: cluster
          params:
          - name: endpoint
            value: 'https://prod.gke.corp.com'

Resources are no longer their own type of CRD

Instead of binding Resources in Pipeline, we bind them in PipelineRun (and TaskRun)
See example_option_4:

kritis-pipeline-run.yaml now contains all resource bindings

    taskSourceBindings:
    - name: unit-test-kritis
      inputSourceBindings:
      - key: workspace # bind to the name in the task
        resourceRef:
          name: kritis-resources-git
    - name: push-kritis
      inputSourceBindings:
        - key: workspace # bind to the name in the task
          resourceRef:
            name: kritis-resources-git
      outputSourceBindings:
        - key: builtImage # bind to the name in the task
          resourceRef:
            name: kritis-resources-image

pipeline/kritis.yaml still contains the passedConstraints so that it
can express the order

    tasks:
      - name: unit-test-kritis          # 1.  Run unit Tests
        taskRef:
          name: make
        params:
          - name: makeTarget
            value: test
      - name: push-kritis               # 2.  Build And Push Tests
        taskRef:
          name: build-push
        inputSourceBindings:
          - key: workspace
            passedConstraints: [unit-test-kritis]
        params:
          - name: pathToDockerfile
            value: deploy/Dockerfile
      - name: deploy-test-env           # 3. Finally Deploy to Test environment
        taskRef:
          name: deploy-with-helm
        inputSourceBindings:
          - key: workspace
            passedConstraints: [push-kritis]

Cons:

Resources are now handled in both the Pipeline and the PipelineRun

A combination of (4) + (2): if you want to override a value, you can do that by binding an overridden resource in (4).
We ruled this one out because we feel it is too confusing.

No PipelineParams; people need to change the Pipeline. Move the ServiceAccount and Result store information into the Pipeline itself.
See example_option_6:

The PipelineParams are gone, values are moved into pipeline/kritis.yaml

spec:
    tasks:
    ....
    serviceAccount: 'demoServiceAccount'
    results:
        runs:
          name: 'runsBucket'
          type: 'gcs'
          url: 'gcs://somebucket/results/runs'
        logs:
          name: 'logBucket'
          type: 'gcs'
          url: 'gcs://somebucket/results/logs'
        tests:
          name: 'testBucket'
          type: 'gcs'
          url: 'gcs://somebucket/results/tests'

The PipelineRun in invocations/kritis-pipeline-run.yaml now has very
little in it.

apiVersion: pipeline.knative.dev/v1alpha1
kind: PipelineRun
metadata:
  name: kritis-pipeline-run-12321312984
  namespace: default
spec:
    pipelineRef:
        name: kritis-pipeline
    triggerRef:
        type: manual

Cons:

Still need to change 2 things: create a Resource with the configuration you
want, and change the Pipeline to use that Resoruce

Either (1) or (2) but instead of using PipelineParams, use PipelineRun
and TaskRun.

I am currently leaning toward option (3).

Wov! Thanks for all the detailed examples and description.
That said, in my head the problem is:
We want to create multiple instances of same resource/artifact with one more different values.
Right now, in the CRD we are embedding the object instance information as well (in case of Git resource it is version, in case of Image its digest)
One approach would be to create CRD with revision being auto-populated by the system.
type Resource struct {
	Name string               `json:"name"`
	Type PipelineResourceType `json:"type"`
        URL string `json:"url"`
        // Revision is a version representing this object.
	// Populated by the system.
	// Read-only.
	// +optional
      Revision string
}
type GitResource struct {
    *Resource
}

And then, PipelineParameters will essentially be a list of Resource Versions used in the pipeline and few more special concepts like clusters etc.
I think this is essentially the first solution which you described.
But all that said, i am inclined to number 3. All parameters will be handled in the same way.

Right now, in the CRD we are embedding the object instance information as well (in case of Git resource it is version, in case of Image its digest)

This applies to all of the fields in each Resource, so for a Git Resource we are looking at:
type GitResource struct {
	Name string               `json:"name"`
	Type PipelineResourceType `json:"type"`
	URL  string               `json:"url"`
	// Git revision (branch, tag, commit SHA or ref) to clone.  See
	// https://git-scm.com/docs/gitrevisions#_specifying_revisions for more
	// information.
	Revision string `json:"revision"`
}

Particularly the URL would be of interest, e.g. for using forks (like github.com/knative/build-pipeline vs github.com/bobcatfish/build-pipeline)
And for an image we're looking at:
// ImageResource defines an endpoint where artifacts can be stored, such as images.
type ImageResource struct {
	Name   string               `json:"name"`
	Type   PipelineResourceType `json:"type"`
	URL    string               `json:"url"`
	Digest string               `json:"digest"`
}

Where again URL is a value likely to need to change, if I wanted to run against my own registry.

But all that said, i am inclined to number 3. All parameters will be handled in the same way.

kk I like 3 as well, I think we should go for it :D

If Resources were separate CRDs, it's possible that a user could add their own controllers for their specific types of reosurces :thinking:

I'm really fixated on this idea and plan to write up another issue to discuss it as soon as i can! Puts a bit of wrench in option (3) tho :J

The idea of allowing users to extend the system by adding their own resources is important, this flexibility can help drive adoption of our pipeline significantly. I do think it will requires more work to enable this anyways.
so now I'm leaning towards a combination of (4) and (6).
Moving the binding of the resources and the results to the pipelineRun will make it consistent with TaskRun
The user should flow the same constructs when running one task with a TaskRun or a pipeline with a PipelineRun, and we don't have any similar construct to PipelineParams for tasks
and since we already changed the Cluster to be a resource, the only thing in PipelineParams is the results, which I think should also move to the PipelineRun to be consistent with the TaskRun
Pros:

Pipelines and Tasks are consistent
one less CRD to worry about it
Pipeline, Task and Resource are for definition while PipelineRun and TaskRun are for running the tasks with the appropriate version

Cons:

user has to add the resource in both Pipeline and PipelineRun

(p.s. wrote up #238 about extensibility via Resources)

@pivotal-nader-ziada I'm also leaning toward (4) now that we talk about it more
Do you have any thoughts on how we can improve this situation where we now have to talk about Resources in both the Pipeline (b/c we have to express order) AND the PipelineRun?
For example in the Pipeline:
      - name: push-kritis               # 2.  Build And Push Tests
        taskRef:
          name: build-push
         inputSourceBindings:
          - key: workspace
            passedConstraints: [unit-test-kritis]
        params:
          - name: pathToDockerfile
            value: deploy/Dockerfile

And in the PipelineRun:
 - name: push-kritis
      inputSourceBindings:
        - key: workspace # bind to the name in the task
          resourceRef:
            name: kritis-resources-git
      outputSourceBindings:
        - key: builtImage # bind to the name in the task
          resourceRef:
            name: kritis-resources-image

My gut reaction is to suggest that we kill two birds with one stone, and tackle #137 by making the passedConstraint an attribute of the Task instead of the Resource, e.g. the first snippet in the above example would become:
      - name: push-kritis               # 2.  Build And Push Tests
        taskRef:
          name: build-push
          passedConstraints: [unit-test-kritis]
        params:
          - name: pathToDockerfile
            value: deploy/Dockerfile

This way the Pipeline itself only expresses the ordering.
Not sure if the Params should stay in the Pipeline in this design - @dlorenc has pointed out that params are looking more and more like Resources also.

The one issue I can think of regarding making passedConstraint on the task level is what if the one task has two inputs each one of them from a different previous task? I think the granularity of the passedConstraint on the resource makes building pipeline more powerful
but how about the following idea:

rename passedConstraint to dependsOn

pipeline
     - name: push-kritis
        taskRef:
          name: build-push
         inputSourceBindings:
          - key: workspace
            dependsOn: [unit-test-kritis]      # renamed from passedConstraint
        params:
          - name: pathToDockerfile
            value: deploy/Dockerfile

pipelineRun
- name: push-kritis
      inputSourceBindings:
        - key: workspace                        # bind to the name in the task
           version: dc6758e
      outputSourceBindings:
        - key: builtImage                       # bind to the name in the task
          # no version needed for output since it will still be created

not sure if output needs to be part of pipelineRun at all?

@pivotal-nader-ziada + @shashwathi and I talked some of this through today and came to some conclusions:

The version field would only let a user override some values in a Resource, not all of them, for example for a git resource you could change the commitish but not the repo (e.g. to point at a fork), and it's hard to say where to draw the line
We like the idea of having a user create a new Resource when they want to change a Resource
Due to the work that @shashwathi is doing on #148 it looks like we won't need to use the version field to pass metadata between Tasks when a Task depends on the output of another Task

Therefore we'd like to try out this design:

Resources instances are referred to in PipelineRuns (not Pipelines)
Pipelines still link Resources to tasks via passedConstraint (new name coming soon see #137)
We remove the version field

authors: bobcatfish pivotal-nader-ziada tejal29

repo: knative/build-pipeline


text:
Add eventing-istio to release-checklist

As per title

/cc @creydr

/lgtm

source: gharchive/pull-request

authors: pierDipi skonto

repo: knative/release

license_type: permissive

license_source: bigquery


text:
[master] Auto-update dependencies

Produced via:
./hack/update-deps.sh --upgrade && ./hack/update-codegen.sh
/assign lberk n3wscott
/cc lberk n3wscott

@mattmoor the build tests suggest a hack/update-codegen.sh is required, did something change with the move to gomod?  Thought that was a part of the bot's steps?

/lgtm
/approve

authors: lberk mattmoor n3wscott

repo: knative/sample-source

license_source: github-api


text:
add Aubergine example

#1

Thanks!

authors: angyvolin uwx

license: unlicense


text:
okcoin http 410

HTTP status code was not OK: 410    What is it?
si.mazi.rescu.HttpStatusIOException: HTTP status code was not OK: 410
at si.mazi.rescu.ResponseReader.read(ResponseReader.java:104)
at si.mazi.rescu.RestInvocationHandler.mapInvocationResult(RestInvocationHandler.java:175)
at si.mazi.rescu.RestInvocationHandler.receiveAndMap(RestInvocationHandler.java:163)
at si.mazi.rescu.RestInvocationHandler.invoke(RestInvocationHandler.java:119)
at com.sun.proxy.$Proxy90.getKlines(Unknown Source)
at org.knowm.xchange.okcoin.service.OkCoinMarketDataServiceRaw.getKlines(OkCoinMarketDataServiceRaw.java:311)
at org.knowm.xchange.okcoin.service.OkCoinMarketDataServiceRaw.getKlines(OkCoinMarketDataServiceRaw.java:294)
at com.ynlc.exmarket.controller.UserController.okCoinKLineChange(UserController.java:67)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:190)
at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:138)
at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:105)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:878)
at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:792)
at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:87)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:1040)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:943)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:1006)
at org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:898)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:626)
at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:883)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:733)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:53)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:100)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.springframework.web.filter.FormContentFilter.doFilterInternal(FormContentFilter.java:93)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)
at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:541)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1589)
at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

 Exchange okCoin = ExchangeFactory.INSTANCE.createExchange(OkCoinExchange.class.getName());
            OkCoinMarketDataServiceRaw marketDataService = (OkCoinMarketDataServiceRaw) okCoin.getMarketDataService();
            List<OkCoinKline> klines = marketDataService.getKlines(CurrencyPair.BTC_USDT, OkCoinKlineType.MIN1, System.currentTimeMillis());

source: gharchive/issue

repo: knowm/XChange

license: MIT


text:
Added callbacks to insert/upsert/delete/update/save methods

Callbacks are called only if they are declared for model, otherwise are skipped.

Sorry for many commits, having problems with testing :)

I appreciate the work you've done here, but the problem with this approach is that it starts making the templates non-general purpose. In my opinion, the right way to accomplish this for your project if you need Go-level logic hooks on insert/update/delete, is to modify and create your own templates and version them/maintain them with the project they are being used for. xo is flexible enough that it is fairly easy / straight forward to use custom templates, which I would highly encourage doing for this use case.

repo: knq/xo

license: mit


text:
Implement DB schema in SQL

DB schema is outlined in our team drive. Implement this in SQL.

Assigning to myself as I've already started this.


text:
chore: integrate jison into webpack build

Description
Removes the original jison build process into the webpack build for consistency and improved local development.
How to test
run yarn test
1. run yarn test command
2. Wait for results

Success criteria: All tests should pass
run yarn dev
1. run yarn dev command
2. goto a web browser and open up http://localhost:9000/
3. open up browser console to check for errors

Success criteria:

none of the charts should fail to render
browser console shouldn't show any mermaid compile errors.

run yarn build
1. run yarn build command
2. Wait for build to complete

Success criteria: No build errors
run yarn release
1. run yarn release command
2. Open up the dist/index.html and change the mermaid script tag src to ./mermaid.min.js
3. Run yarn dev command (starts the server)
4. goto a web browser and open up http://localhost:9000/
5. open up browser console to check for errors

Success criteria:

none of the charts should fail to render
browser console shouldn't show any mermaid compile errors.

Pull Request Test Coverage Report for Build 876

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 47.767%

Totals

Change from base Build 871:
0.0%

Covered Lines:
2196

Relevant Lines:
4483

💛  - Coveralls

authors: coveralls sagea

repo: knsv/mermaid


text:
Implement in game exit menu

Description
Implement in game exit menu.
This is the menu where we're already in game and want to exit, we can either:

select character
open options and exit
exit

and maybe there was another one that I don't remember.
Tasks

[ ] Implement in game exit menu
[ ] Ensure that if the player is attacked, they need to wait 10 seconds as per official behavior

Note that @xGuTeK implemented this and is currently pending for a PR.

It was done here: https://github.com/ko4life-net/ko/pull/166


text:
translate

need Chinese translate！！！！！

'Kay, I'll try to write it, but it may be not so correct.

In fact, I have already translated it, but I don't know how to upload it to you. Should I directly package the jar for you or not?? I need you to give me permission for a project

I'm sorry for making this decision without permission. I was worried that I wouldn't be able to contact you, so I asked my friends. They taught me how to use fork to upload files, and I have no intention of infringing. I just want to use your mod in my modpack. I'm a beginner in this industry and I'm not sure about many things. If it causes any trouble for you, please contact me!!! I'm really sorry

Additionally, I encountered a crash while adjusting the weather to Stormy using instructions, and I am unsure of the reason. I hope it can be fixed

In the water, entering the water during a storm can cause collapse

Thanks a lot! You may open the pull request to push your translate to my repository with preservation of your copyright.
As for the error you found, can you describe it in more detail?

I think I've figured out what crash you're talking about. It was fixed in Seasons API  1.2-BETA-2

I understand, the bug has been fixed, and
DefaultTXTLangZH.zip
I don't know how to use GitHub. However, with the help of a friend, I forked your project and uploaded the source file. If possible, I will try to submit a Chinese translation directly here for you to update easily!

authors: RedTeaBaby kochkaev

repo: kochkaev/seasons-challenges


text:
New preloader on NFTs item details

We've passed @jkdizajn new kodadot v3 so we can update it new SVG preloader with https://github.com/kodadot/kodadot-presskit/tree/main/v3 and close on #1216  #1274

how to create branch here to create new PR
@yangwao

Can JSON also be used? I converted SVG graphics to JSON using LottieFiles.
Here is the result:
https://lottiefiles.com/web-player?lottie_url=https%3A%2F%2Fassets10.lottiefiles.com%2Fpackages%2Flf20_vlz0oz9b.json
and here is gif:

@yangwao @skwsccss

Version 2 (animated SVG)
https://user-images.githubusercontent.com/81104034/146267596-0dbbd792-79c9-4d63-a74a-101ac872d975.mp4

authors: jkdizajn skwsccss yangwao

repo: kodadot/nft-gallery


text:
NeoTabs in pages/stmn/create

after

#6231
is merged
use NeoTabs in pages/stmn/create

closed by #6453

authors: daiagi roiLeo


text:
nav bar display on different width

Thank you for your contribution to the KodaDot NFT gallery.
👇 _ Let's make a quick check before the contribution.
PR type

[ ] Bugfix
[ ] Feature
[x] Refactoring

What's new?

[x] PR closes #2770
[ ] <brief_description_of_what_I've_added>

Before submitting Pull Request, please make sure:

[x] My contribution builds clean without any errors or warnings
[x] I've merged recent default branch -- main and I've no conflicts
[x] I've tried to respect high code quality standards
[x] I've didn't break any original functionality
[x] I've posted a screenshot of demonstrated change in this PR

Optional

[x] I've tested it at </rmrk/collection/26902bc2f7c20c546a-1FVG7>
[x] I've tested PR on mobile and everything seems works
[ ] I found edge cases
[ ] I've written some unit tests 🧪

Had issue bounty label?

[x] Fill up your KSM address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot

[x] My fix has changed something on UI; a screenshot is best to understand changes for others.

Keep the width of the search bar at release 350px.

🕵♂   👁

🕵♂ 👁

Sorry, I'm not sure that, Is there anything unusual 😕

😍 Perfect, I’ve sent the payout
💵 $100 @ 172.86 USD/KSM ~ 0.579 $KSM
🧗 Caiv9TbPz68q5dC8EcHu5xKYPRnremimGzqmEejDFNpWWLG
🔗 0x5ca2847f46eb95a0de6ef0fb179059d1d0d19ae68f3ce83193cf467df184f96e
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues


text:
Dockerfile: COPY go.mod go.sum ./ error

Required check list:

[x] I'm gonna mark the checkboxes like this.
[ ] I didn't find in the repository's issues section similar bug.
[x] I understand, this is Open Source and not-for-profit product.
[ ] This is not about third-party project, framework, package or technology.

My environment:

OS (uname -a): Windows 10
Golang (go version): go1.16.7 windows/amd64

Describe the bug:
=> ERROR [builder 3/6] COPY go.mod go.sum ./                                            0.0s

[builder 3/6] COPY go.mod go.sum ./:

failed to compute cache key: "/go.sum" not found: not found

Steps to reproduce the behavior:

Create Dockerfile
Go to docker build -t fiber .
See error

Screenshots:

@rmdhfz hi!
Did you download all files from this repository by git clone before run docker build -t fiber .?
By the way, you do not need to run all commands manually, because repository has Makefile with all shortcuts. Try make docker.run for configuring all Docker containers and environment.

Okay, thank you @koddr

authors: koddr rmdhfz

repo: koddr/tutorial-go-fiber-rest-api


text:
Update function el_click

I ran into a problem here while using the player in a nested element: offsetLeft doesn't always calculate the distance from the edge of the page, sometimes it just calculates the distance to the edge of its parent element (or from the parent element to the edge? I'm not certain). Anyway I believe that the getBoundingClient method I used here is compatible with more contexts — at the very least it fixed the problem I was having.

Hey @zachy9, thanks for the fix! 👍

you're welcome, thanks for the cool code

repo: kodedninja/microne


text:
Jupyter permission error

Person 1 has initiated the first run of the workflow. The Nbconvert (Jupyter Notebook) template has S permissions for/from it. Others who start the workflow cannot use this template, and the error below occurs.
Permission of .snakemake/conda/04ed4593/share/jupyter/nbconvert/templates/html:
drwx--S--- 2 alex covidseq 4.0K Feb 9 22:56 html
Error:
PermissionError: [Errno 13] Permission denied: '/.snakemake/conda/04ed4593/share/jupyter/nbconvert/templates/html/conf.json'
Possible solution: Usage of scripts instead of notebooks.

temp fix chmod 2775 .snakemake/conda/04ed4593/share/jupyter/nbconvert/templates/html

@mbargull can you have a look at this? It seems like the nbconvert package writes into its own installation directory during runtime, adding folders into the template directory. Am I right?

https://github.com/jupyter/nbconvert/pull/1028
introduced
https://github.com/jupyter/nbconvert/blame/6.0.7/nbconvert/exporters/templateexporter.py#L545
which is used on the reported nbconvert/templates/html (sub) path.
It ignores the set umask and uses 0o700 (no read/write/execute for group or others) unconditionally.
Also, it is not only the environment's path (given by
https://github.com/jupyter/jupyter_core/blob/4.7.1/jupyter_core/paths.py#L164
and
https://github.com/jupyter/jupyter_core/blob/4.7.1/jupyter_core/paths.py#L132
) that might be created that way but also ones in ~/.local/share (which is the only one that's fine) and, if you run as the root user you might also get unreadable system-wide folders due to
https://github.com/jupyter/jupyter_core/blob/4.7.1/jupyter_core/paths.py#L127-L130
.

Long story short: Upstream nbconvert should remove that ensure_dir_exists(path, mode=0o700) (and, if needed, replace it by something else which does not use fixed mode) for paths coming from jupyter_core.paths.jupyter_path.

However, I don't know why the environment's path has been used in the case reported by @thomasbtf. Going by the logic from
https://github.com/jupyter/jupyter_core/blob/4.7.1/jupyter_core/paths.py#L127-L130
this would happen JUPYTER_PATH is explicitly set to that path or JUPYTER_PREFER_ENV_PATH is set. Maybe the user's ~/.local/share/jupyter/nbconvert/templates/html directory wasn't writeable and the environment's path was used as a fallback?
I can't tell, unfortunately.
(Partially because the workflow didn't finish locally and I got these errors:

[Wed Feb 24 17:58:32 2021]
rule plot_strains_pangolin:
    input: results/tables/strain-calls/a.strains.pangolin.csv
    output: results/plots/strain-calls/a.strains.pangolin.svg
    log: logs/plot-strains-pangolin/a.log
    jobid: 103
    wildcards: sample=a

[Wed Feb 24 17:58:32 2021]
Error in rule plot_strains_pangolin:
    jobid: 103
    output: results/plots/strain-calls/a.strains.pangolin.svg
    log: logs/plot-strains-pangolin/a.log (check log file(s) for error message)
    conda-env: /home/u1/snakemake-workflow-sars-cov2/.snakemake/conda/9421407d

RuleException:
ImportError in line 149 of /home/u1/snakemake-workflow-sars-cov2/workflow/rules/strain_calling.smk:
cannot import name 'Application' from partially initialized module 'traitlets.config' (most likely due to a circular import) (/opt/conda/envs/x/lib/python3.9/site-packages/traitlets/config/__init__.py)
  File "/opt/conda/envs/x/lib/python3.9/site-packages/snakemake/executors/__init__.py", line 2326, in run_wrapper
  File "/home/u1/snakemake-workflow-sars-cov2/workflow/rules/strain_calling.smk", line 149, in __rule_plot_strains_pangolin
  File "/opt/conda/envs/x/lib/python3.9/site-packages/nbformat/__init__.py", line 109, in writes
  File "/opt/conda/envs/x/lib/python3.9/site-packages/traitlets/log.py", line 19, in get_logger
  File "/opt/conda/envs/x/lib/python3.9/site-packages/snakemake/executors/__init__.py", line 568, in _callback
  File "/opt/conda/envs/x/lib/python3.9/concurrent/futures/thread.py", line 52, in run
  File "/opt/conda/envs/x/lib/python3.9/site-packages/snakemake/executors/__init__.py", line 554, in cached_or_run
  File "/opt/conda/envs/x/lib/python3.9/site-packages/snakemake/executors/__init__.py", line 2357, in run_wrapper
[Wed Feb 24 17:58:32 2021]
Finished job 104.
61 of 67 steps (91%) done
Activating conda environment: /home/u1/snakemake-workflow-sars-cov2/.snakemake/conda/f30b4daa
Activating conda environment: /home/u1/snakemake-workflow-sars-cov2/.snakemake/conda/9421407d
[Wed Feb 24 17:58:35 2021]
Finished job 18.
62 of 67 steps (93%) done
[NbConvertApp] ERROR | Notebook JSON is invalid: Additional properties are not allowed ('id' was unexpected)

Failed validating 'additionalProperties' in code_cell:

On instance['cells'][0]:
{'cell_type': 'code',
 'execution_count': None,
 'id': 'attempted-colony',
 'metadata': {'tags': ['snakemake-job-properties']},
 'outputs': ['...0 outputs...'],
 'source': '\n'
           '######## snakemake preamble start (automatically inserted, do '
           'n...'}
[Wed Feb 24 17:58:40 2021]
Finished job 54.
63 of 67 steps (94%) done
Shutting down, this might take some time.
Exiting because a job execution failed. Look above for error message
Complete log: /home/u1/snakemake-workflow-sars-cov2/.snakemake/log/2021-02-24T174641.019759.snakemake.log

(I also got a SSL cert error midway and restarted the workflow after replacing defaults::ca-certificates with conda-forge::ca-certificates in Snakemakes' environment -- I'm not sure if that was just a fluke or not.)

)

Maybe it can be configured differently?

Until the issue is fixed upstream, maybe you can try to set the JUPYTER_PATH environment variable to a path the workflow created beforehand (with a mode less strict than 0o700).

https://github.com/jupyter/nbconvert/issues?q=TemplateExporter+PermissionError
shows similar issues regarding multi-user and concerning the same files.
But those issues aren't very terse, so TL;DR on my part for today :/.

We just merged https://github.com/koesterlab/snakemake-workflow-sars-cov2/issues/39 which may fix this issue.
I would be interested in knowing if this improves the situation for you.

It may be required for you to acctually remove the conda/04ed4593/share/jupyter/nbconvert/templates/html/ directory.

authors: SylvainCorlay johanneskoester mbargull thomasbtf


text:
Cannot extract LoRA from the inpainting model.

loading SD model : /content/models/v1-5-pruned-emaonly.safetensors
loading u-net: <All keys matched successfully>
loading vae: <All keys matched successfully>
loading text encoder: <All keys matched successfully>
loading SD model : /content/models/sd-v1-5-inpainting.ckpt

Gets up to here, then just exists without printing any error message.

Ok, I got this error after trying a .safetensors version of the inpainting model:
loading SD model : /content/models/v1-5-pruned-emaonly.safetensors
loading u-net: <All keys matched successfully>
loading vae: <All keys matched successfully>
loading text encoder: <All keys matched successfully>
loading SD model : /content/models/sd-v1-5-inpainting.safetensors
╭───────────────────── Traceback (most recent call last) ──────────────────────╮
│ /content/sd-scripts/networks/extract_lora_from_models.py:189 in <module>     │
│                                                                              │
│   186   parser = setup_parser()                                              │
│   187                                                                        │
│   188   args = parser.parse_args()                                           │
│ ❱ 189   svd(args)                                                            │
│   190                                                                        │
│                                                                              │
│ /content/sd-scripts/networks/extract_lora_from_models.py:45 in svd           │
│                                                                              │
│    42   print(f"loading SD model : {args.model_org}")                        │
│    43   text_encoder_o, _, unet_o = model_util.load_models_from_stable_diffu │
│    44   print(f"loading SD model : {args.model_tuned}")                      │
│ ❱  45   text_encoder_t, _, unet_t = model_util.load_models_from_stable_diffu │
│    46                                                                        │
│    47   # create LoRA network to extract weights: Use dim (rank) as alpha    │
│    48   if args.conv_dim is None:                                            │
│                                                                              │
│ /usr/local/lib/python3.9/dist-packages/library/model_util.py:876 in          │
│ load_models_from_stable_diffusion_checkpoint                                 │
│                                                                              │
│    873   converted_unet_checkpoint = convert_ldm_unet_checkpoint(v2, state_d │
│    874                                                                       │
│    875   unet = UNet2DConditionModel(**unet_config).to(device)               │
│ ❱  876   info = unet.load_state_dict(converted_unet_checkpoint)              │
│    877   print("loading u-net:", info)                                       │
│    878                                                                       │
│    879   # Convert the VAE model.                                            │
│                                                                              │
│ /usr/local/lib/python3.9/dist-packages/torch/nn/modules/module.py:2041 in    │
│ load_state_dict                                                              │
│                                                                              │
│   2038 │   │   │   │   │   │   ', '.join('"{}"'.format(k) for k in missing_k │
│   2039 │   │                                                                 │
│   2040 │   │   if len(error_msgs) > 0:                                       │
│ ❱ 2041 │   │   │   raise RuntimeError('Error(s) in loading state_dict for {} │
│   2042 │   │   │   │   │   │   │      self.__class__.__name__, "\n\t".join(e │
│   2043 │   │   return _IncompatibleKeys(missing_keys, unexpected_keys)       │
│   2044                                                                       │
╰──────────────────────────────────────────────────────────────────────────────╯
RuntimeError: Error(s) in loading state_dict for UNet2DConditionModel:
        size mismatch for conv_in.weight: copying a param with shape
torch.Size([320, 9, 3, 3]) from checkpoint, the shape in current model is
torch.Size([320, 4, 3, 3]).

I'm guessing it's just not possible for some reason?

Tried being clever by merging them so they'd be the same format, (inpaint+base weighted sum 99%) and using that as --model_org, but it seems you cannot extract a LoRA even if both --model_org and --model_tuned are inpainting models.

Unfortunate, it would have been a lot more convenient to just have an inpainting LoRA rather than having to merge every model to make a matching inpainting model. Thanks for your response.

repo: kohya-ss/sd-scripts


text:
Update README.md

fixing a minor spelling mistake :D

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

authors: CLAassistant cwhits

repo: kolide/kolide-quickstart


text:
AccountEntry

:information_source:  This issue is part of the Epic #14
Objective
Implement the account entry type.
Checklist

[ ] Signers list type
[ ] Account entry type

Closed in favor of #69 .


text:
Added Rackspace DNS

Thank you for contributing to sewer.
Every contribution to sewer is important to us.
You may not know it, but you have just contributed to making the world a more safer and secure place.
Contributor offers to license certain software (a “Contribution” or multiple
“Contributions”) to sewer, and sewer agrees to accept said Contributions,
under the terms of the MIT License.
Contributor understands and agrees that sewer shall have the irrevocable and perpetual right to make
and distribute copies of any Contribution, as well as to create and distribute collective works and
derivative works of any Contribution, under the MIT License.
Now,
What(What have you changed?)
Added rackspace dns support
Why(Why did you change it?)
It's what I use and it's part of this issue:
https://github.com/komuw/sewer/issues/59

hi @m4ldonado .
Thanks for contributing.

Could you add some tests? Have a look at https://github.com/komuw/sewer/tree/master/sewer/dns_providers/tests
to see how the other DNS providers are tested.

Also add rackspace to the README; https://github.com/komuw/sewer/blob/master/README.md

@komuw Thanks for the pointers.  Will do

Will update Readme now

hi @komuw,
Sorry this took a while - I've replicated some of the tests from the test directory. I'm happy to add anything else that's missing

@m4ldonado thanks!
this is now in the latest release:

https://pypi.org/project/sewer/0.6.0/
https://github.com/komuw/sewer/releases/tag/0.6.0

repo: komuw/sewer


text:
Complete @mbrand01's refactor to use the Node TLS module

This is nearly all @mbrand1's work, from #84 and #86, plus a few commits I've added at different points.
Since #86, I added one commit, c2449dfb679b9f805c951df54e80c818f4711250, which updates the test suite to expect and test for the presence of the root certificate in each site's chain (even if the site doesn't directly serve it).
Closes #84, as it's mooted by this one.

This is now deployed: https://shaaaaaaaaaaaaa.com/check/ipv6.google.com

Oops, meant to cc @mbrand1 on this thread, used the wrong handle above.

repo: konklone/shaaaaaaaaaaaaa


text:
Open new small pane from input URL

URL と項目名を入力して、スモールペインを開けるようにしたい。
いちいち preferences から設定するのが面倒なので。

スモールペイン限定ですか？ミドルペインでMeetsを開いているのでミドルペインでもURL開けたらうれしいなあ

全ペイン対応できそうならしてしまいたいですなぁ

#47 にて対応

authors: fruitriin konoyono

repo: konoyono/okadash


text:
merge from template-coveralls

package.json

chore(deps): add ^8.3.21 remove ^8.3.20 (devDependencies.npm-pkgbuild)

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

npm package (@latest dist-tag)
v5.0.105
GitHub release

Your semantic-release bot :package::rocket:

repo: konsumation/konsum


text:
Speed up CLI startup by loading SecureRandom only when needed

SecureRandom loads OpenSSL and takes 20ms+
rb(main):001:0> require 'securerandom'
require 'digest.so' in 0ms
require 'openssl.so' in 5ms
require 'openssl/bn' in 0ms
require 'openssl/pkey' in 0ms
require 'openssl/cipher' in 1ms
require 'stringio' in 0ms
require 'openssl/config' in 1ms
require 'openssl/digest' in 0ms
require 'openssl/x509' in 1ms
require 'openssl/buffering' in 1ms
require 'io/nonblock' in 0ms
require 'openssl/ssl' in 12ms
require 'openssl' in 24ms
require 'securerandom' in 24ms

The authenticate_after_deploy hook was loading it preemptively, slowing any CLI spin up by said 20ms+.

Not needed if 1.2.3 is buried. The more complex version targeted to 1.3.0 in #2335 already includes this.

repo: kontena/kontena


text:
fix(toolbar): improve toolbar items layout

This PR swaps Level layout for Split in the filter toolbar area for PlansTable and SelectVMsForm. For the PlansTable, the "Create plan" button ends up moving to be right aligned. I think we can achieve the old layout but I'll need to use a fancier layout strategy, like a Grid implementation. Let me know if it's a big deal, otherwise this should patch up the display issue just fine.
Lastly, I fixed a small issue where an Alert wasn't being announced to screen reader users.
Should help close https://github.com/konveyor/forklift-ui/issues/218

I think @vconzola had a strong opinion that the create button should be left-aligned there with the filters, maybe we do need that grid.

@mturley that's correct - button should be on the left, next to the filters.

authors: mturley seanforyou23 vconzola

repo: konveyor/forklift-ui


text:
Support ImageStream in Deployment

Description
DeploymentConfig is not recommended by Openshift/Red Hat. It is meant to be used only in certain situations.
DeploymentConfig might also be deprecated at some point.
Proposal
Add support for using ImageStreams in Deployments:
https://developers.redhat.com/blog/2019/09/20/using-red-hat-openshift-image-streams-with-kubernetes-deployments/
Just need to add some annotations.
This also allows BuildConfig to work with Deployment.

If there is customer requirements for this feature, we can consider it. For now, it can be achieved using customizations.

authors: HarikrishnanBalagopal ashokponkumar


text:
sgame与koolss冲突？

koolss运行正常，尝试使用sgame，安装后就出现国外访问PD，间歇性可访问，查看TinyfecVPN说明作者是切了翻墙这个口，所以是SGame导致了访问不能的问题？Sgame不管运行与否ss都无法正常工作，卸载后立刻恢复正常

不能同时开启！

repo: koolshare/ledesoft


text:
[BUG] descheduler evict Pod error

What happened:
I0602 15:08:53.003630       1 recorder.go:103] events "msg"="Warning"  "message"="Failed evict Pod \"prod/bd-prod-lumberjack-streaming-7587d86d45-4v4lc\" caused by Eviction in version \"v1\" cannot be handled as a Eviction: no kind \"Eviction\" is registered for version \"policy/v1\" in scheme \"k8s.io/kubernetes/pkg/api/legacyscheme/scheme.go:30\"" "object"={"kind":"PodMigrationJob","name":"7e1aaa37-d8ec-444b-92d2-8d153dd0f7d1","uid":"2addaab6-58fb-40d8-bd67-8646ec5eb369","apiVersion":"scheduling.koordinator.sh/v1alpha1","resourceVersion":"4265598"} "reason"="Evicting"
I0602 15:08:53.115431       1 controller.go:265] begin process MigrationJob 78c0bfae-38fe-4fe8-97cf-78d80f24a30c

descheduler error
What you expected to happen:
How to reproduce it (as minimally and precisely as possible):
Anything else we need to know?:
Environment:

App version: descheduler 1.2
Kubernetes version (use kubectl version): v1.21.7
Install details (e.g. helm install args):
Node environment (for koordlet/runtime-proxy issue):

Containerd/Docker version:
OS version:
Kernal version:
Cgroup driver: cgroupfs/systemd

Others:

as we talked, in k8s v1.21.x, there is no eviction registered in policy/v1beta1. Only the k8s version has the problem.

repo: koordinator-sh/koordinator


text:
Support values defined via env variables

When no value found then with help of '-e' the environment can be looked
up for values.

Hi folks, not sure how useful you'll find it. Myself I needed to consolidate all my custom configuration, env variables proved to be the most straightforward way, hence the modification. Enjoy.

repo: kopeio/kexpand


text:
return selected indices

We would like to return the selected indecies as well when doing select with top K. Please have a look

@younik thanks for the help. I push the change to fix typo and tests.

Looks good! Many thanks @oddoking for contributing!

authors: oddoking younik

repo: kora-labs/chromax


text:
Support for cross-cluster resource retrieval and retrieving of multiple resource types

Hi, I found this multi-cluster dashboard project, I really like the functionality and interface of this dashboard, I think clusterpedia can extend this project to support cross-cluster resource retrieval, and can retrieve multiple resource types simultaneously.
Clusterpedia is a cncf sandbox project for complex retrieval of resources across clusters.
The clusterpedia is compatible with Kubernetes OpenAPI, everyone can get a quick overview of clusterpedia’s basic functionality through https://github.com/clusterpedia-io/clusterpedia#usage-samples
Clusterpedia upport for importing Kubernetes 1.10+, and use Collection Resource to retrieve different types of resources, such as Deployment, DaemonSet, StatefulSet
$ kubectl get collectionresources
NAME            RESOURCES
any             *
workloads       deployments.apps,daemonsets.apps,statefulsets.apps
kuberesources   .*,*.admission.k8s.io,*.admissionregistration.k8s.io,*.apiextensions.k8s.io,*.apps,*.authentication.k8s.io,*.authorization.k8s.io,*.autoscaling,*.batch,*.certificates.k8s.io,*.coordination.k8s.io,*.discovery.k8s.io,*.events.k8s.io,*.extensions,*.flowcontrol.apiserver.k8s.io,*.imagepolicy.k8s.io,*.internal.apiserver.k8s.io,*.networking.k8s.io,*.node.k8s.io,*.policy,*.rbac.authorization.k8s.io,*.scheduling.k8s.io,*.storage.k8s.io

Would you like kore-dashboard to provide cross-cluster resource retrieval and retrieval of multiple resource types through Clusterpedia?

thanks.
it's a good suggestion.
I just read the clusterpedia github "readme.md".
We reviewed it at the design stage, but we couldn't find the right solution at the time, so we are currently developing it by ourselves using ConfigMap.
I thinks that it is necessary to consider.

get help from "https://translate.google.com"

I believe the cooperation between projects will make kcore-dashboard and clusterpedia better.
If there are any questions or ideas, we can always communicate.

authors: Iceber itnpeople


text:
Fix datasource-gap in subgraph for zero context

I found that in some cases when one or both of ctx_left and ctx_right are zero, the subgraph method produces wrong datasource-gap edges.
More precisely, the issue occurs when node_ids contains token nodes with non-overlapping contexts and either of the following hold true:

exactly one of ctx_left and ctx_right is zero
both ctx_left and ctx_right are zero and the token nodes in node_ids are not sorted by position in the text

Due to the non-overlapping contexts, datasource-gap edges should be produced. However, in case 1, they are produced between the wrong nodes and in case 2, they are not produced at all.
In the ANNIS web UI, this can lead to different kinds wrong behavior. To reproduce,

import the subtok.demo corpus,
select "Show context in: tokens",
set "Left Context" to 0 and Right Context to 2,
a) search for tok & tok & #2 .4,4 #1 -> tokens are displayed in the wrong order,
or b) search for tok & tok & #1 .4,4 #2 -> search hangs and selecting a "Base text" causes the app to crash

Screenshot for a)

Screenshot for b)

The reason is that create_subgraph_for_iterator relies on the tokens in the iterator being sorted by position in the text, which is not always the case.
While new_overlapped_nodes_iterator does sort the tokens, new_subgraph_iterator prepends node_ids, which may break the sorting.
As a fix, I changed new_subgraph_iterator to only prepend those node_ids that aren't tokens. This should be sufficient, because the ones that are tokens are already yielded by new_overlapped_nodes_iterator. As a consequence, all tokens yielded by new_subgraph_iterator are now sorted.
An alternative fix I considered is to keep adding all node_ids, but to append them after overlapped_nodes. This would have been the least invasive fix, but it would have made the contract of new_subgraph_iterator harder to understand: The tokens it yields wouldn't necessarily be sorted. Only when ignoring all but the first occurrence of each token would they be sorted, which just happens to be enough for how create_subgraph_for_iterator is implemented.

The Clippy error is unrelated to my changes, it just so happened that yesterday's release of Rust 1.77 came with a new lint that's warn-by-default.

Thanks a lot for the fix and the test case! It seems that the contracts of the subgraph iterators are quite complex right now, mostly due to that they also need to work properly with multiple segmentation. The proposed fix seems to be the best variant, but we have to make sure to always include the matched tokens in the overlapped iterator as well.

authors: matthias-stemmler thomaskrause

repo: korpling/graphANNIS


text:
Unknown values on some parameters

I used the add on since a long time with hassio, updating to 104.1 I started to get some "unknown" for parameters that were correctly used in the past.
These are the parameters I am getting back from add-on:

sensor.ups_battery | unknown
sensor.ups_battery_shutdown | 5
sensor.ups_battery_timeout | 0
sensor.ups_cable_type | USB Cable
sensor.ups_daemon_info | 3.14.14 (31 May 2016) unknown
sensor.ups_driver | USB UPS Driver
sensor.ups_hostname | a722577e-apcupsd.local.hass.io
sensor.ups_input_voltage | unknown
sensor.ups_input_voltage_high | unknown
sensor.ups_input_voltage_low | unknown
sensor.ups_load | unknown
sensor.ups_mode | Stand Alone
sensor.ups_model | unknown
sensor.ups_name | APC UPS
sensor.ups_output_voltage | unknown
sensor.ups_shutdown_time | 3
sensor.ups_startup_time | 2020-09-17 16:31:45 +0200
sensor.ups_status | COMMLOST
sensor.ups_status_data | 001,018,0465
sensor.ups_status_date | 2020-09-17 16:31:55 +0200
sensor.ups_time_left | unknown

Currently i am running Hassio 104.4 with addon version 1.9

I'm similarly getting unknown for input_voltage_high, input_voltage_low, and output_voltage but I do get correct values for everything else, including battery and time_left.

I have made the decision to archive this repository. Please see the README for more information.

repo: korylprince/hassio-apcupsd


text:
Cherry Pick: support plugin options for templete

What type of PR is this?

/kind feature
What does this PR do?

Which issue(s) does this PR fix?

Fixes #
Special notes for your reviewer:

Does this PR introduce a user-facing change?

NONE

/lgtm

authors: OrangeBao duanmengkk

repo: kosmos-io/kosmos


text:
Update sbt-coveralls to 1.3.5

Updates org.scoverage:sbt-coveralls from 1.3.2 to 1.3.5.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scoverage", artifactId = "sbt-coveralls" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.scoverage", artifactId = "sbt-coveralls" }
}]

labels: sbt-plugin-update, early-semver-patch, semver-spec-patch, commit-count:1

Superseded by #59.

repo: kostjas/spark-google-spreadsheets


text:
mysql索引选择

是否考虑增加 mysql 的 force index 和 ignore index 的语法？

有兴趣可以考虑自己实现，Ktorm 是可扩展的

有兴趣可以考虑自己实现，Ktorm 是可扩展的

repo: kotlin-orm/ktorm


text:
Turning Kotlin warnings to errors

Description
For ensuring good quality of each changes, we would like to turn warnings from the Kotlin compiler to errors.
Here's a StackOverflow discussion about this subject.
Checklist

[ ] Update the configuration of the Kotlin compiler.
[ ] Test it locally.
[ ] Update the Unreleased section in the changelog.

The compiler warns when:

a deprecated function is used
a parameter is never used.

Interestingly enough, it doesn't report a warning when there is a private or an internal function that is not used...

repo: kotools/types


text:
Change log level when files are not found

For CI purposes, when files are not found the process should continue without any hassle.

Hi, thanks for the contribution and your patience with this PR.
I understand the needs behind it, but I'm afraid I can't it merge just like that because there are people expecting mark to fail if the given files not found. Can we add an optional flag to introduce this behavior that you want?

Thank you for the feedback @kovetskiy, I will add a new flag for it and keep the old behavior as default

Thanks!

authors: kovetskiy mmiranda

repo: kovetskiy/mark


text:
Check applyPatch handling of case where both old and new file have no trailing newline

I didn't think about this when writing https://github.com/kpdecker/jsdiff/pull/533 and suspect I broke something. Needs fixing before release.

(I was prompted to think about this scenario because https://github.com/kpdecker/jsdiff/issues/531 was coincidentally opened recently.)

repo: kpdecker/jsdiff


text:
Contact form goes over the send button when typing text (mobile)

This bug cannot be reproduced anymore (tested on iPhone and Android)


text:
out of memory errors leading to other errors

Today's notifications have some weird errors in them. Looking at the logs, it looks like these OOM errors sometimes cause other problems due to (I think) the AGI script returning "".
Prod has memory now, I didn't try an outgoing call, but the incoming line works.
Looks like something not necessarily related to asterisk used up memory, hopefully temporarily?
DO logs/graphs might have hints.
NB these timestamps are 3 hours late due to an unrelated issue.
[Jul 13 00:39:18] WARNING[32311][C-000008ba] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:52:59] WARNING[32372][C-000008be] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:53:01] WARNING[32372][C-000008be] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:53:04] WARNING[32372][C-000008be] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:22] WARNING[32427][C-000008bf] pbx.c: Background requires an argument (filename)
[Jul 13 00:59:22] WARNING[32427][C-000008bf] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:34] WARNING[32429][C-000008c0] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:35] WARNING[32429][C-000008c0] pbx.c: Background requires an argument (filename)
[Jul 13 00:59:35] WARNING[32429][C-000008c0] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:38] WARNING[32430][C-000008c1] pbx.c: Background requires an argument (filename)
[Jul 13 00:59:38] WARNING[32430][C-000008c1] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:43] WARNING[32431][C-000008c2] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:44] WARNING[32431][C-000008c2] pbx.c: Background requires an argument (filename)
[Jul 13 00:59:44] WARNING[32431][C-000008c2] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:45] WARNING[32432][C-000008c3] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:46] WARNING[32432][C-000008c3] pbx.c: Background requires an argument (filename)
[Jul 13 00:59:46] WARNING[32432][C-000008c3] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:47] WARNING[32433][C-000008c4] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 00:59:48] WARNING[32434][C-000008c5] pbx.c: Background requires an argument (filename)
[Jul 13 00:59:48] WARNING[32434][C-000008c5] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 01:01:12] WARNING[32448][C-000008c6] pbx.c: Background requires an argument (filename)
[Jul 13 01:01:12] WARNING[32448][C-000008c6] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 01:48:54] WARNING[32539][C-000008c7] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 01:49:01] WARNING[32539][C-000008c7] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 01:50:05] WARNING[32550][C-000008c8] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 01:50:37] WARNING[32551][C-000008c9] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 01:51:16] WARNING[32552][C-000008ca] res_agi.c: Failed to fork(): Cannot allocate memory
[Jul 13 01:51:40] WARNING[32553][C-000008cb] res_agi.c: Failed to fork(): Cannot allocate memory

random crap was happening on the box including kernel panics, hopefully none of the longrunning processes without a real supervisor died, but we know about that problem already. Festival didn't die, at least.

repo: kra/futel-installation


text:
Add 'Mojolicious::Guides::Testing' tutorial. Resolves #1111

Summary
This is a testing tutorial meant to be included in the Mojolicious::Guides
Motivation
This PR is in response to #1111
References
https://github.com/kraih/mojo/issues/1111
Notes
It's a little weak in some areas (WebSockets, HTML/XML parsing come to mind) and I don't cover file uploads at all. I'm willing to continue work on it as needed.

I started with this as a section in the cookbook as originally described, but found that it got big really fast. I think having a cookbook section may still be valuable.

This is a lot to review, yay! 😃

This will be very helpful "if and when" I get to writing a Mojo app - thumbs up!

👍
My only question is: why didn't this exist sooner? I've been trying to be better at TDD and to encourage my coworkers to do the same. This is an awesome introduction—I found a lot of features in Test::Mojo that I didn't know I needed. :-) Definitely mades TDD with Mojolicious friendlier and easier to start. The existing documentation in Test::Mojo is great as a reference, but really lacks the guide qualities this document provides.

The testing guide needs to be referenced from Mojolicious::Guides too.

Overall i like this guide very much, outstanding work. Just a few style nitpicks and the final section, which uses a concept i do not like and don't think we should encourage.

Regarding Test::Mojo extensions, we've decided to add a more broad mechanism to Mojo::Base with Role::Tiny. That means roles will look just like the ones for Test::Mojo::WithRoles.
package Test::Mojo::Role::Location;
use Role::Tiny;

sub location_is {
  my ($t, $value, $desc) = @_;
  $desc ||= "Location: $value";
  local $Test::Builder::Level = $Test::Builder::Level + 1;
  return $t->success(is($t->tx->res->headers->location, $value, $desc));
}

1;

But their application will be slightly different.
my $t = Test::Mojo->with_roles('Test::Mojo::Role::Location')->new('MyApp');
$t->get_ok('/')
  ->status_is(302)
  ->location_is('http://mojolicious.org')
  ->or(sub { diag 'Must have been Joel!' });

Mentioning is in case you want to prepare a section before we add the feature in the next few days. 😃

#1120 will get applied later today or tomorrow, so Role::Tiny is definitely the way to go for Test::Mojo extensions from now on.

I'll try to get something together for it.
On Thu, Aug 10, 2017 at 07:18:52AM -0700, Sebastian Riedel wrote:

#1120 will get applied later today or tomorrow, so Role::Tiny is definitely the way to go for Test::Mojo extensions from now on.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
https://github.com/kraih/mojo/pull/1118#issuecomment-321565008

--
Scott Wiersdorf
scott@perlcode.org

It's funny you bring this up because that's exactly what I was going to try when I had a little more time :)
I think the existing location_is example is good enough to get people started.
Any additional things you (or anyone else) would like to see in the tutorial?

Ok, maybe I'll put it back in as a second "advanced" example or something, that also blends attributes from Mojo::Base to illustrate how those two things can play together.

Good catch.

I think the guide is good now. Will give the community a little more time for proofreading and then merge tomorrow.

Looks like we might not be able to merge after all. The newly added role composition section is a blocker for me. The code examples are just too ugly. I'll step back again until the dust has settled.

reverted

Allright, lets consider the guide frozen now, so we can wrap it up. Just typo and formatting fixes from now on.

100% ok by me.

And merged. 🎉 🍰 🎈  http://mojolicious.org/perldoc/Mojolicious/Guides/Testing

authors: ashton314 csjewell kraih scottw

repo: kraih/mojo


text:
Add usePreferredColorScheme hook

Motivation
Dark mode is getting increasingly popular. Developers may want to track the color scheme preference of users.
Basic example
const preferredColorScheme = usePreferredColorScheme();

Details

Depends on useMedia (#9)

the PR above implements this hook ^ #12

@cmoog Thanks for your work! Unfortunately, I'm still not sure whether this hook should be generic or specialized for dark mode. If the latter approach gets used, then a simplistic approach could be chosen if the user has no-preference over the color scheme:
const isDarkModeEnabled = useDarkMode(true /* default value if there is no preference */);

On the other hand, there might be more color scheme additions in the future, and the name useDarkMode has no hint about it being only a preference retrieval hook.

@kripod I'm thinking it's best to keep it generic and leave it to the consumer to resolve the value to a boolean. For example, isDarkMode can be trivially implemented by the consumer as follows
const isDarkMode = usePreferredColorScheme() === 'dark';

@cmoog Thanks for your work once again! If you decide to send a pull request again, please assign yourself to the corresponding issues and use magic keywords to auto-close the issue for which your pull request was created.

authors: cmoog kripod

repo: kripod/standard-hooks


text:
[ENHANCEMENT] Refactoring of all the md: to sm:

Description
We can aim for default classes (mobile), sm (tablet), lg (desktop if explicitly required), and lets refactor all the other classes if it were using md.
Current Behavior
The current codebase uses the md: prefix for classes to define styling and behavior, presumably targeted at medium-sized devices. The specific styling associated with these classes may be tailored for devices with a medium screen size, such as tablets or devices in a certain resolution range.
Proposed Enhancement
The proposed enhancement involves refactoring the existing codebase to improve class naming conventions and create a more consistent structure. The main changes include:
Replacing all instances of md: with sm: to better reflect the intended target, focusing on small to medium-sized devices.
Use Case
The sm: classes, replacing the existing md: classes, would be employed for tablet-sized devices, providing a tailored layout and styling for this category.
Blockers
No response
Additional Information/ Attachments
No response

Description
We can aim for default classes (mobile), sm (tablet), lg (desktop if explicitly required), and lets refactor all the other classes if it were using md.
Current Behavior
The current codebase uses the md: prefix for classes to define styling and behavior, presumably targeted at medium-sized devices. The specific styling associated with these classes may be tailored for devices with a medium screen size, such as tablets or devices in a certain resolution range.
Proposed Enhancement
The proposed enhancement involves refactoring the existing codebase to improve class naming conventions and create a more consistent structure. The main changes include:
Replacing all instances of md: with sm: to better reflect the intended target, focusing on small to medium-sized devices.
Use Case
The sm: classes, replacing the existing md: classes, would be employed for tablet-sized devices, providing a tailored layout and styling for this category.
Blockers
No response
Additional Information/ Attachments
No response

@krishnaacharyaa Hi sir i texted you from discord can you please assign me this issue under GSSoC'24? I would like to work on it.

Sure @Chelseasingla1 Please let me know the ETA and kindly keep in mind the contributing guidelines

Sure @Chelseasingla1 Please let me know the ETA and kindly keep in mind the contributing guidelines

@krishnaacharyaa Okay sir, I will try to submit it by this afternoon only.

repo: krishnaacharyaa/wanderlust


text:
Parkinson's disease indicator

I would like to add a project for Parkinson's disease classification.

@sudipg4112001 there is already a notebook and a model for pakinson disease.

repo: kritikaparmar-programmer/HealthCheck


text:
Build and push SNAPSHOT operator images

Type of change

Enhancement / new feature

Description
We have a PR beginning to add system tests for the operator but we want to pull an operator image from quay. This PR starts publishing snapshot operator images to quay.
Note that we need a quay repo and to update some variables in github actions.
Additional Context
Why are you making this pull request?
Checklist
Please go through this checklist and make sure all applicable tasks have been done

[ ] Write tests
[ ] Update documentation
[ ] Make sure all unit/integration tests pass
[ ] Make sure all Sonarcloud warnings are addressed or are justifiably ignored.
[ ] If applicable to the change, trigger the system test suite.  Make sure tests pass.
[ ] If applicable to the change, trigger the performance test suite. Ensure that any degradations to performance numbers are understood and justified.
[ ] Ensure the PR references relevant issue(s) so they are closed on merging.
[ ] For user facing changes, update CHANGELOG.md (remember to include changes affecting the API of the test artefacts too).

NOTE:  You must be a member of @kroxylicious/developers to trigger the system test and performance test suites.  If you are not part of this group, comment on the PR requesting a trigger, tagging @kroxylicious/developers.

tested on my fork with a snapshot push https://github.com/robobario/kroxylicious/actions/runs/12385213726
will try pushing up a tag

currently the operator manifests refer to quay.io/kroxylicious/operator:latest, wondering if we should publish x.y.z-SNAPSHOT and latest or pick one way.

currently the operator manifests refer to quay.io/kroxylicious/operator:latest, wondering if we should publish x.y.z-SNAPSHOT and latest or pick one way.

I generally think using latest is a poor call but I think that ship has sailed and it’s expected. Let’s do both

alrighty, it now emits both tags

and here's an example tag push build showing it currently doesn't push anything on tag push

I've have pushed up moving the build into the Dockerfile to align it with the proxy image (move the maven build into the image). To do this I've lifted the Dockerfile up into the top dir since it needs to have the whole maven project in it's context. I think that if we left it in the kroxylicious-operator directory it would surprise people that docker build . fails.

currently failing https://github.com/robobario/kroxylicious/actions/runs/12402177592 , looks like building with --projects xyz --also-make is causing trouble, I don't think it's aware it needs to build to bom. I'll have it do a full build of the project for now.

authors: SamBarker robobario

repo: kroxylicious/kroxylicious


text:
Update favicon

Update favicon to something like your github avatar instead of the vercel icon.
Github Avatar: https://avatars.githubusercontent.com/u/91655303?v=4
I can try to help you on this.

You changed your avatar, so this is outdated ig.


text:
[Facelift] Toggle Traffic Lights show junction status

The tool now displays all eligible crossings with greyed out traffic light icon
The tool now displays nodes with TL on with a white traffic light icon.
Hover blue circle shows current hovered node (old behaviour)
Additional filter added, only roads are allowed for traffic lights, should ignore rail, metro etc.
[Bonus] optimized distance calculations in all tools where they used magnitude for each node/segment instead of sqrMagnitude

Contributes to #523

Love the concept, much clearer to see what the state of each junction is.
However, could we use a simpler design for the lights icon? Something like the vanilla game uses - where disabled is round cornered grey rectangle, and enabled is black with coloured lights?

We absolutely can. I need to find how to get the Texture2D from the game, and to know its size (aspect ratio). Or create exact same looking texture.

I think Mod Tools might have some way to extract textures and dump them to disk.
Ronyx made this video about dumping textures - not sure if it covers the vanilla junction icons tho: https://www.youtube.com/watch?v=nzJK77BU2Lg
There are also some tools listed here: https://cslmodding.info/dump/#unity-assets-bundle-extractor
I think @krzychu124 also found some way to dump all textures in the game.

I have installed dump textures mod once, the output might still be somewhere on my drives.

@aubergine10 In any case the traffic light icon is the same icon used in the new concept for the main menu buttons. Which is why it looks closer to new proposed TM:PE style, and further away from the game style.

Would it be worth trying the simplified design for the new menu buttons also?

Yes if you can replace round button with square, and slap on the new textures it might give an impression of how it will work together.
I can show some mighty paint skills and smash them together.

Speaking of flat button, I tried altering the normal button as you suggested, but was thwarted by this method:

All I need to do is change color value between those calls. But.. I don't seem to be able to override that in a custom class. So I tried digging deeper, but things just get worse, with internal and protected methods/properties in the UIInteractiveComponent class which in turn relies upon an internal struct of the UISprite class.
Maybe it's just my lack of C# knowledge, but it seems that the person who created the C:SL UI framework has specifically designed it in such a way to obstruct people from creating custom or tangibly modified interactive elements.
My current half-baked solution is to extend UIPanel and create two UISprite inside it during instantiation, but even then the way panels work is so utterly obtuse that it would be difficult to overlay the two sprites or introduce some internal padding between the background and foreground sprites. Hence me attempting to use UIButton instead. This UI framework gives me PTSD.

Let's agree on the style then.

We liked how the main menu looks and this will be the new style. If the answer is yes, I have a prototype of a canvas UI which will grow into a separate PR updating the main menu.
Do we use the new style icons on overlays too, or prefer the old style game icons? If the answer on 2 is yes, we will need to find another icon collection to pick the icons from.

Changed TL textures to use standard TL on/off texture from the game
Added a timer texture for nodes with timed TL

Looks nice, maybe icon is a bit too small. I know, I know it's still bigger than vanilla toggle 😃


text:
typealias.typeName.name is mismatch?

Environment
Sourcery
$ sourcery --version
0.10.1

Swift
$ swift --version
Swift: Apple Swift version 4.0.3 (swiftlang-900.0.74.1 clang-900.0.39.2)
Target: x86_64-apple-macosx10.9

Input Swift
struct Training {
    typealias Sentence = String
    typealias Sentences = [String]

    let sentence: Sentence
    let sentences: Sentences
}

Template Stencil
{% for struct in types.structs %}
{% for key,value in struct.typealiases %}
{{ key }}, {{ value.typeName.name }}
{% endfor %}
{% endfor %}

Output
Sentence, String
Sentences, String <- should be outputed [String] ?

I tried binary of built master, it works correctly!! :wrench:
I hope nexe release 🚀

repo: krzysztofzablocki/Sourcery


text:
Fixes information being lost when extending unknown type more than once

Just a minor regression I've encountered while upgrading to 1.3.2 😊

@krzysztofzablocki added!


text:
Could I run Inference Service without model ?

/kind bug
What steps did you take and what happened:

Could I run Inference Service without model ? like a API function

What did you expect to happen:
import argparse
from typing import Dict
from kserve import Model, ModelServer

class Comp1(Model):
    def __init__(self, name: str):
        super().__init__(name)
        self.name = name
        self.model = None
        self.ready = True

    def predict(self, payload: Dict, headers: Dict[str, str] = None) -> Dict:
        data = payload["query"]["a"]
        return {"a": data}

if __name__ == "__main__":
    comp = Comp1("comp1")
    ModelServer().start([comp])

ERROR: failed to launch: determine start command: when there is no default process a command is required

After packaging, i did test app using docker. But it wasn't operate well.
It is not bug. but i wanna use sequence process without model. my project is not required 3 of 4 stages

For Example, Inference stage1 (X) - stage2 (X) - stage3 (O, required model) - stage4
I just wanna use like multiple transformer !

i'll wait answer or solution. Thank you

@ChaejinE Yes, You can run the model server without a model https://github.com/kserve/kserve/blob/215e58378849d153a034b083701435a725a87675/python/sklearnserver/sklearnserver/main.py#L42C4-L43C40.
Have you specified entrypoint / cmd in your dockerfile ?

@sivanantha321 No, But i wanna know that (use CMD ENTRYPOINT).
Well, Running without a model is to transfer empty list to kserve server ?

@sivanantha321 No, But i wanna know that (use CMD ENTRYPOINT).
Well, Running without a model is to transfer empty list to kserve server ?

Yes, by providing an empty list, you can run the server without the model. However, some endpoints may not work (e.g) /predict. The error you are getting is because of not specifying CMD or ENTRYPOINT

@ChaejinE I am not sure. What is the use case of hitting predict endpoint without a model ?

@ChaejinE I am not sure. What is the use case of hitting predict endpoint without a model ?

Yeah, My use case is NeRF model..
It is different from other models
Its inference processes are independent each other
Stages consist of video download - model train/inference - 3d mesh postprocess etc...
So i wanna make inference servicr and use inference graph included not required model stage

i choose inference graph

repo: kserve/kserve


text:
🛑 Orchestra is down

In 137e50d, Orchestra (http://issue.chelsea.kt.co.kr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Orchestra is back up in 7af5f17.

repo: kt-chelsea/status


text:
🛑 MatterMost is down

In ea8e5cf, MatterMost (http://chat.chelsea.kt.co.kr/login) was down:

HTTP code: 0
Response time: 0 ms

Resolved: MatterMost is back up in b032f4b.


text:
Remove redundant environment configs from usage examples

No need to set  TERM=dump explicitly, it's already set by default for JVM based builds.
See: travis-ci/travis-build#240

Thanks!


text:
Enable to run optimize command by non-root user

Currently, optimize command requires root privilege. We should enable to run it by non-root user.
It is mainly because optimize command uses overlayfs to make rootfs environment for a container. fuse-overlayfs would be good alternative for overlayfs.

Ubuntu and Debian 10 support real overlayfs

authors: AkihiroSuda ktock

repo: ktock/remote-snapshotter


text:
Github Pipeline (if using Pages)

Create full github pipeline for deployment if we end up using GitHub pages to host. Issues might occur due to necessity for two servers (backend, frontend).

I've used vercel in the past to deploy a separate backend and frontend for free.

repo: ktpbu/ktpdatabase


text:
keep-alive

I'm sorry, how should keep-alive be supported? In https://github.com/ktquez/vue-head/blob/master/vue-head.js is no mention of "deactivated". If I have a
		<keep-alive include="find">
			<router-view></router-view>
		</keep-alive>

then the component "find" appears for the first time, head.title.inner of "find" gets set, but if I navigate to some other component, which does not even have .head defined in the component, the head.title.inner of "find" just stays, even though the deactivated() hook of "find" is clearly fired.

Sorry for the delay, you can try $emit('updateHead') when the route is modified

$emit('updateHead')  fires on mounted hook?

repo: ktquez/vue-head


text:
configHotReload of FluentbitAgent ignores imagePullSecrets

Describe the bug:
I created a FluentbitAgent like this:
apiVersion: logging.banzaicloud.io/v1beta1
kind: FluentbitAgent
metadata:
  name: default
  namespace: logging
spec:
  configHotReload:
    image:
      imagePullSecrets:
        - name: some-pull-secret
      repository: internal.registry.example/ghcr/kube-logging/config-reloader

The configured pull secret was not part of the pod spec for fluentbit and thus the config-reloader image could not be pulled.
Expected behaviour:
I expected that the configured pull secret appears as part of the pod spec for fluentbit pods and that the config-reloader image is pulled through our internal image registry.
Steps to reproduce the bug:

Apply FluentbitAgent with configHotReload using at least one image.imagePullSecrets
Look at spec of running fluentbit pods whether the pull secret appears

Additional context:
none
Environment details:

Kubernetes version (e.g. v1.15.2): 1.29
Cloud-provider/provisioner (e.g. AKS, GKE, EKS, PKE etc): kubeadm
logging-operator version (e.g. 2.1.1): 4.8.0
Install method (e.g. helm or static manifests): helm
Logs from the misbehaving component (and any other relevant logs): none
Resource definition (possibly in YAML format) that caused the issue, without sensitive data: see above

/kind bug

Hello @sebhoss
This was fixed and merged. It will be included in the next release.
In the meantime, you can pass your imagepullsecret for configReloader in the fluentbit one: spec.image.imagepullsecrets.

@aslafy-z thanks a lot for the quick response!

thx @aslafy-z !

authors: aslafy-z pepov sebhoss

repo: kube-logging/logging-operator


text:
hack,charts,manifests: Update the manual OLM metering manifests.

This updates our manual olm manifests for deploying Metering. The CatalogSourceConfig has been a depreciated object for a while now, so that's been replaced with using a ConfigMap-based CatalogSource implementation. Note: there's currently no ConfigMap that gets templated, but there is a ./hack/create-upgrade-configmap.sh script that achieves the same functionality that can be renamed/generalized in down the line.

Overriding valid-bz label - this is just for QE testing.

repo: kube-reporting/metering-operator


text:
fix issue 209

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #209
Special notes for your reviewer:

/lgtm

/approve

authors: ErikJiang hangscer8 yanggangtony

repo: kubean-io/kubean


text:
fix: Long time installation continues even after uninstallation done

What type of PR is this?
/kind bug

What this PR does / why we need it
Which issue(s) this PR fixes

Fixes #
Special notes for your reviewer

need merge #303  first

repo: kubebb/core


text:
Add security information

What type of suggestions?
Missing Information
What page is concerned?
No response
What is the issue?
from @johndietz:
We should at minimum strive to provide clarity to our community about the steps we have taken to secure our platform tools and security posture. for example vault and atlantis each have guidance that we have followed for securing their implementations, but that's not at all transparent to an end user.
a security section needs to be added to our docs as part of the documentation overhaul.
Code of Conduct

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

This will become important as more companies will do some security audit of kubefirst before implementing it.

repo: kubefirst/docs


text:
Updated org.yaml to add me as member

I had raised an issue regarding implement Kubeflow fairing from Kubeflow pipeline.
That was confirmed by Kubeflow core dev team. I have raised 2 PRs to resolve this issue.
I would like to join Kubeflow GitHub Org to connect and contribute more.
References:
kubeflow/pipelines#3742
kubeflow/fairing#494
kubeflow/manifests#1180
kubeflow/fairing#495

/assign @jlewi

/ok-to-test
/lgtm
/approve

repo: kubeflow/internal-acls


text:
Replace reconciler implementation with kubeflow/common JobController

In #1144, we upgrade Kubernetes to v1.16.x and update kubeflow/common to v0.3.1 which is good.
The next step, we plan to replace reconciler implementation with kubeflow/common's JobController.
in v0.3.1, I expose ReconcileJob, ReconcilePod and ReconcileService methods and if TF can not use common implementation, it's fine to override the methods and customize logic.

I think it is a high-priority feature for the next release.
/priority p1

@Jeffwan
Do you have the bandwidth for this enhancement?

Yeah. I can definitely help on that. @ChanYiLin Said he is interested in it. I will check with him and see if he's comfortable to make the change.

Thanks
/assign @Jeffwan @ChanYiLin

Any concrete plan on this yet? @Jeffwan @ChanYiLin

I will start working on it this week, it might take 1~2 weeks
and maybe @Jeffwan can help me to check it functions well the end of next week?

@ChanYiLin Sounds good. Feel free to pin me for any help.

@ChanYiLin Should we close this now?

I think we can /cc @ChanYiLin

Yes, we can close this now.
This issue has been resolved here #1171

authors: ChanYiLin Jeffwan gaocegege terrytangyuan

repo: kubeflow/tf-operator


text:
Upgrade Go version to v1.20

What this PR does / why we need it:
I upgraded Go version to v1.20.
Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):
Fixes #
Checklist:

[ ] Docs included if any changes are user facing

Pull Request Test Coverage Report for Build 5723032849

0 of 0   changed or added relevant lines in 0 files are covered.
17 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.2%) to 40.18%

Files with Coverage Reduction
New Missed Lines
%

pkg/controller.v1/mpi/mpijob_controller.go
2
80.12%

pkg/controller.v1/mxnet/mxjob_controller.go
6
61.92%

pkg/controller.v1/paddlepaddle/paddlepaddle_controller.go
9
61.54%

Totals

Change from base Build 5719511557:
-0.2%

Covered Lines:
3846

Relevant Lines:
9572

💛  - Coveralls

authors: coveralls tenzen-y

repo: kubeflow/training-operator


text:
Update website for Kubeflow v1.0.1

https://github.com/kubeflow/kfctl/releases/tag/v1.0.1

/assign

repo: kubeflow/website


text:
remove distribution docs from kubeflow.org

Currently, we host distribution-specific docs on the kubeflow.org website, and they are very rarely updated.
I believe we can improve kubeflow by only linking to external docs for distributions under the Getting Started/Installing Kubeflow page, as will be done in PR https://github.com/kubeflow/website/pull/2611.
This has some significant benefits:

We wont implicitly be endorsing any specific distribution
We get out of the way for distributions to update their docs (for example, a distribution may need more than one release per major kubeflow version like 1.2, 1.3, but right now they can only have one version)
It starts the process of distinguishing who is an "official/certified" distribution (that is, we will only link to "official/certified" distributions in Getting Started/Installing Kubeflow, once we have a process for verification).

If we want to do this, we should set a date (before the 1.4 release), after which we will be removing any remaining distribution docs from kubeflow.org.

@RFMVasconcelos @Bobgy @cvenets @joeliedtke @animeshsingh, what are your thoughts?

/priority p2

Bumping for bot, we still need to remove distribution docs from kubeflow.org.

/priority p3

/remove-priority p2

I am closing this issue in preference of: https://github.com/kubeflow/website/issues/3074


text:
fix typo

https://github.com/kubeflow/website/issues/2874

/assign @RFMVasconcelos


text:
Investigating NFS and External Storage Integration with ownCloud

Howdy @mcapuccini  and @andersla. As per our recent DevOps Meeting, we'd like to investigate integration of NFS and external storage Integration with ownCloud.
From their web site there seems to be positive signals for such goal:

EXTERNAL STORAGE
With ownCloud, you can also leverage pre-existing storage: FTP, Swift, S3, Dropbox and more. Administrators are able to decide whether to store the most sensitive data on-premises and less sensitive data in the cloud while making all of your files available through a single interface and enabling compliance with your chosen security and governance policies.

and this might include also NFS although not entirely sure yet.
Here are some useful links:

Configuring External Storage via GUI

Configuring External Storage via conf file.

Cheers.

Other hints to be investigate:
Frontend: mounting OwnCloud's volume as a persistent volume in Kubernetes (if basically it can be exposed as a NFS)
Backend: how owncloud can write persistent data (one idea is by using Object Storage)

repo: kubenow/KubeNow


text:
add subnet.spec.u2oInterconnectionIP

[ ] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Examples of user facing changes:

Features
Bug fixes
Docs
Tests

Which issue(s) this PR fixes:
Fixes #2888
WHAT

🤖 Generated by Copilot at 2cf2a80
This pull request adds a new feature to allow specifying a static IP address for the underlay to overlay interconnection for a subnet. It also updates the validation, reconciliation, and e2e tests for this feature. It modifies the SubnetSpec and SubnetStatus schemas in the types.go, kube-ovn-crd.yaml, and crd.yaml files to add a new field U2OInterconnectionIP.

🤖 Generated by Copilot at 2cf2a80

Sing, O Muse, of the cunning engineers who devised
A way to link the underlay and overlay networks with ease
By adding to the SubnetSpec a field of great renown
The U2OInterconnectionIP, the glory of the cloud

HOW

🤖 Generated by Copilot at 2cf2a80

Add a new field U2OInterconnectionIP to the SubnetSpec struct to specify a static IP address for the underlay to overlay interconnection for a subnet (link)
Add a new field u2oInterconnectionIP to the SubnetStatus schema to store the IP address of the logical router port that connects the underlay and overlay networks for a subnet (link, link)
Update the custom resource definition of the subnet with the new field in crd.yaml and kube-ovn-crd.yaml (link, link)
Validate the U2OInterconnectionIP field in the ValidateSubnet function and check if it is contained in the subnet CIDR (link)
Enqueue a subnet for reconciliation when the U2OInterconnectionIP field has changed in the enqueueUpdateSubnet function (link)
Clear the U2OInterconnectionIP field if the U2OInterconnection field is false and set the changed flag to true in the formatSubnet function (link)
Allocate and release the static or dynamic IP address for the underlay to overlay interconnection for a subnet in the reconcileU2OInterconnectionIP function (link)
Avoid unnecessary errors when deleting the pods, subnets, and vpc in the AfterEach block (link)
Test the U2OInterconnectionIP feature by changing the IP address twice and verifying the connectivity in the It block (link)
Check the version of the kube-ovn controller and verify the U2OInterconnectionIP field in the subnet spec and status in the checkU2OItems function (link, link)

Need backport to 1.9

authors: changluyi oilbeater

repo: kubeovn/kube-ovn


text:
chart: support Talos Linux

Pull Request

[ ] Make sure you have followed Kube-OVN Code Style.

What type of this PR
Examples of user facing changes:

Features
Bug fixes
Docs
Tests

Add support for installing Kube-OVN on Talos Linux
It also requires https://github.com/kubeovn/kube-ovn/pull/3585 to work
Which issue(s) this PR fixes
Fixes #(issue-number)
WHAT
copilot:summary
copilot:poem
HOW
copilot:walkthrough

@zhangzujian thanks, PR rebased

Please resolve the conflict.

Please resolve the conflict.
Sure, done

authors: kvaps zhangzujian


text:
server.Server: cleanup of public functions

- What I did
deleted or unexposed public functions that were not used outside of server.Server
- How I did it
- How to verify it
- Description for the changelog

/test all

/retest

authors: rhatdan runcom vbatts

repo: kubernetes-incubator/cri-o


text:
add once flag to exit loop after first sync

--once terminates the program after first sync.
@ideahitme I'm currently writing a simple integration test where I need this functionality. However, the busy loop at the end of the program still seems odd to me.

IMO instead of closing the stopChan it should rather trigger RunOnce from controller. This way it relies on the internal implementation of the controller, which is not the best solution IMO

That does make a lot of sense, indeed ^^

@ideahitme updated

authors: ideahitme linki

repo: kubernetes-incubator/external-dns


text:
Consider adding "convert" options to up/down

In 7349dc9 i'm proposing adding --emptyvols to the up/down operations. This raises a bigger question on whether we should enable passing the other convert options so that they can be used with up/down - this can be useful, but maybe not something we want to do.

@dustymabe I think kompose down doesn't need to have --emptyvols option
$ $ kompose down --help
NAME:
   kompose down - Delete instantiated services/deployments from kubernetes

USAGE:
   kompose down [command options] [arguments...]

OPTIONS:
   --emptyvols	Use Empty Volumes. Don't generate PVCs

There is a bigger question.
If you are deleting object for kompose down, how you know what objects should deleted?
If user deployed using kompose up that there is  PersisntentVolumeClaim and if --emptyvols was used than there is no PVC.
Easiest solution in the case of PVC might be to always try delete PVC (basicaly always assume down --emptyvol)  and don't report error if there is no PVC. But this assumes that user won't create PVC with same name convention that is Kompose using, otherwise we delete PVC that wasn't created by Kompose.

Right. It's because there is no clue in docker-compose file that lets us know if pvc was created or not. From UX perspective kompose down --emptyvols looks a bit of weird.
Should we automatically/transparently add a kompose label for pvc to the original docker-compose file once user chooses to create pvc object ? OR should we update the strategy of generating pvc by adding label ?

From UX perspective kompose down --emptyvols looks a bit of weird.
Agreed it is weird. We should force user to think about such thinks.

Should we automatically/transparently add a kompose label for pvc to the original docker-compose file once user chooses to create pvc object ? OR should we update the strategy of generating pvc by adding label ?

Annotating controller with additional information about what was used for conversion might be in general great idea. Other think that we could do is to actually inspect controller object and find out if it uses PVC or not. But i don't know how complicated this might be

for kompose down we could use labels that were applied to each element that was created during "up" to bring the application down. so it's possible we don't have to do a "conversion" at all, just inspect for labels and delete everything that has that label

for kompose down we could use labels that were applied to each element that was created during "up" to bring the application down. so it's possible we don't have to do a "conversion" at all, just inspect for labels and delete everything that has that label

I was thinking about this also, but what if user deploys two different application (docker-compose.yml files) to one namespace?

we could:
1 - try to use a unique name
2 - collision avoidance - if you try to "up" and there is a label conflict with the label you are going to use and a label that already exists, then error out and tell the user.

to improve doing down, we should label artifacts at creation time saying that those artifacts were created using kompose, then while deleting we only delete things that has those label?
that label could look like this:
kompose-project-name: <project_name>
or something better than above label so that we can query things that were created using kompose and we delete only artifacts for current project and not other project kompose generated objects.

@surajssd what is <project_name>?
How about we do it like this:
Lets use io.kompose.service: <service_name> label to label all objects that are related to given service.
Use this also for PVC.
During down, delete all object related to given service using this label as selector.

@kadel we can delete object based on label in kubernetes using

@kadel I agree on using io.kompose.service: <service_name> and then we delete the object using that label. There is cli command for doing that kubectl delete <object> --selector=io.kompose.label=<service_name>, still need to figure out the api calls, but one issue I faced was it sometimes doesn't works :(

@kadel with <project_name> I was thinking of having a single label on all resources. As opposed to labeling service wise. So that we can delete everything in one go!
With each service having different labels we will have to loop over the service names to delete the artifacts.

Had a discussion with @kadel and we found out that there is a function SelectorFromSet()
in kubernetes which returns a Selector (or Label) which will match exactly the given Set (in our case it is io.kompose.service), making use of that we can find all the objects associated with the given Selector (or Label) and can further do the delete operation.

Was going to type this in the PR but here goes:
@kadel @procrypt
So I think this is awesome and amazing code @procrypt
What I'd like to discuss though, is should we really be putting these labels in when we convert?
Honestly, most of our users simply convert, look at the conversion and then kubectl create/apply it..
With this PR, we're adding selectors as well as a metadata section that includes creationTimeStamp as well as a label, making an already-long Kubernetes yaml file even longer.
The point of this PR is to implement kompose down so it deletes based on the label.
What I'm getting at is should we "hide" these labels and implement them ONLY when the user kompose up's?

authors: cdrage dustymabe kadel ngtuna procrypt surajssd

repo: kubernetes-incubator/kompose


text:
Remove discontinued kubelet option --reconcile-cidr if kube_network_plugin=="cloud"

Is this a BUG REPORT or FEATURE REQUEST? (choose one):
BUG REPORT
Option --reconcile-cidr has been discontinued since kubernetes 1.6, so it should be removed from roles/kubernetes/node/templates/kubelet.j2
Patch available at https://github.com/Lastpixl/kubespray/commit/c0b927a9887bb806cebe8c48a32e8c9fee3043d1 - tested, deploys correctly.
Opening an issue, and not a pull request, as per CONTRIBUTING.md.

@Lastpixl can you open a PR to fix this?

@mattymo Sure. PR #1568

authors: Lastpixl mattymo

repo: kubernetes-incubator/kubespray


text:
Fixed "network_plugin" variable

fixes #2800

ci check this

ci check this

Please rebase from master

authors: Atoms dvazar woopstar