[BUG] - input filename collision

Describe the bug
I don't know if you want to do anything about this, but right now there's no check in the sample sheet to see if two samples are named the same thing.
This is a user-generated error caused by the end user, which was me.
Impact
Fails at multiqc step.
To Reproduce
Have two samples named the same thing
Expected behavior
It failed at the last step, I don't know if you want it to fail before the workflow starts.
Screenshots
Workflow execution completed unsuccessfully
Error executing process > 'PHOENIX:PHOENIX_EXTERNAL:MULTIQC'

Caused by:
  Process `PHOENIX:PHOENIX_EXTERNAL:MULTIQC` input file name collision -- There are multiple input files for each of the following file names: 1326569_2_fastqc.zip, 1326569_1_fastqc.zip

Tip: you can replicate the issue by changing to the process work dir and entering the command `bash .command.run`

Logs
Additional context
I still think this is a user error, but I thought I would let you know.

Thanks for reporting this, probably best to address it so resources aren't wasted due to typos. Added a check for duplicate sample id and fastq files in commit fd6127f. Change will be in next release (v1.2.0).


Create a new window instead of a tab?

It would be nice to have the option to always create a new window instead of a new tab.
I changed the AppleScript slightly to allow this:
tell application "Finder"
	if (count of windows) > 0 then
		set thePath to target of front window
	else
		display dialog "There are no open Finder windows." with icon caution buttons {"OK"} with title "Open iTerm Here..."
		return
	end if
end tell

if not (exists thePath) then
	tell application "Finder" to set theName to name of front window
	display dialog "The location of the Finder window \"" & theName & "\" is not a real location (e.g. smart folder, search, network, trash, etc) and cannot opened in iTerm." with icon caution buttons {"OK"} with title "Open iTerm Here..."
	return
end if
set thePath to quoted form of POSIX path of (thePath as alias)

tell application "iTerm"
	-- Handles the case where iTerm is running but has no windows
	set createdWindow to false
	create window with default profile

	tell current session of current window
		write text "cd " & thePath & " && clear"
	end tell

	activate
end tell

And this works for me, but likely this should be packaged up as an option to the generation script...?

That's a good idea.  My workflow is to always a use a new tab, so that's what it does; but I can understand that some people might typically use windows instead of tabs.  I'll try to look into this at some point, but it might be a while.


get-msolserviceprincipal works only for home tenant

It would be very helpful to add a note that when calling the get-msolserviceprincipal cmd-let, the caller must be logged in using a native admin account in the corresponding AAD.
 I ended up spending quite some time trying to figure out why it wouldn't let me do any of the serviceprincipal operations in the XYZ tenant. Finally, I had to create a native (local) account in XYZ and add that account to the global admins. Then, having logged in using that account, I could run the cmd-lets successfully.
Please add a note about this to the document for this sample. (Basically saying that this is an admin operation and admin operations are supported only using a native account for the tenant.)
If you can, please also have the party that owns the doc at the link below add a "Note:" about this so that it can benefit an even broader audience:
http://technet.microsoft.com/library/jj151815.aspx
(A related request - it would also be handy to have a cmd-let that returns the tenantId of the tenants which the logged in user is associated with. :-) )
By the way, this sample is very neat. Helped me learn a lot of interesting things.

Thanks for tip! Definitely not intuitive.

Closing this issue as it's no longer relevant to the sample (which now does no longer use this cmd-let)


.readme-md

Checklist

[x] I've searched for similar issues.
[x] I'm using the latest version of HTTPie.

Minimal reproduction code and steps

Current result
…
Expected result
…

Debug output
Please re-run the command with --debug, then copy the entire command & output and paste both below:
$ http --debug <COMPLETE ARGUMENT LIST THAT TRIGGERS THE ERROR>
<COMPLETE OUTPUT>

Additional information, screenshots, or code examples
…

@maldito-dot please stop spamming on our repos.

honestly dont know hpw i am spamming ??


Use fallback if wasm compile fails

This is to address the issue in https://forum.playcanvas.com/t/unhandled-promise-rejection-compileerror-webassembly-module-problem/37038

After investigating a bit more I found the following:

when using the basis fallback script, the engine has a bug where it passes null instead of undefined to self.BASIS() in basis-worker.js. This causes the fallback to error and fail.
with the previous fix in place, the current build of basis.js fallback script fails to load due to a closure bug.
recompiling the basis module with latest toolchain and basis code fixes the issue.
the recompiled basis.wasm file is 50k larger
we can recover this size increase by removing support for pvr and atc. with this in place we save 150K on the wasm binary size.
but this change requires us to update the engine and remove support for the same. this change is great though and results in a bunch of code being removed.
I have made the above changes in this PR, but have tested none of it.

Since the latest version of basis transcoder supports HDR formats, we should add support for compressed HDR as part of this work. However that requires supporting BC7 texture formats, which @mvaligursky recently (today!) added to engine v2.
Since the user who originally opened the issue has found a workaround (using android instead of iphone), this PR will now be closed till we have time to complete the work and test it, most likely in engine v2.


[Question] Latest version do not support bootstrap v5

Hi, I try @formio/angular v5.3.0 work with angular 14 and boostrap 5.2.0 project could start success, but form builder icon can't display.
How can I make it works? Seek for your help thanks!!

@wenbin9 this item in progress right now. You can see https://github.com/formio/angular/pull/940. Thank you!


fix(scripts): add audit cli cache option

On some system latest audit version uses root folder as target
for cache output. Providing cache option to cli args fixes the issue

📦 Published PR as canary version: Canary Versions

:sparkles: Test out this PR locally via:
npm install<EMAIL_ADDRESS># or
yarn add<EMAIL_ADDRESS>

:rocket: PR was released in<EMAIL_ADDRESS>:rocket:


SRA Identity & Auth: [M3] AuthScheme Changes

Relevant issue(s):
Parent ticket: https://github.com/awslabs/aws-sdk-swift/issues/1119
Grandparent ticket: https://github.com/awslabs/aws-sdk-swift/issues/1095
Pre-existing ticket (used in Q4 planning): https://github.com/awslabs/aws-sdk-swift/issues/700
Summary
Milestone 3 of SRA Identity & Auth Project
* Add new interfaces / structs
    * AuthScheme struct
    * AuthOption struct
    * SelectedAuthScheme struct
    * AuthSchemeResolver protocol
    * AuthSchemeResolverParameters protocol
    * IdentityResolverConfiguration protocol
    * DefaultIdentityResolverConfiguration struct
* Update AWSServiceSpecificConfiguration - add AuthSchemes field and AuthSchemeResolver field for end-user customizations

PRs:

smithy-swift: https://github.com/smithy-lang/smithy-swift/pull/601
aws-sdk-swift: https://github.com/awslabs/aws-sdk-swift/pull/1174


Delete me

@federicocappellotto97 try wrapping the component with the NoSsr.
It's because of the last commit, which resolves an error with the maps script.
Otherwise, try loading the GoogleMap component with next/dynamic and passing { ssr: false } to the options.


Add more fields to the JSON generator, and add a method to return the non-serialized JSON object

@verhovsky any opinions on this?

Thanks

@verhovsky thanks for merging this. 🙏🏽
is there an ETA on when the next release will be?


(data) attribute duplicate in multiple example

<ng-select (data)="value"               [multiple]="true"               [items]="items"               [disabled]="disabled"               (data)="refreshValue($event)"
It's code from http://valor-software.com/ng2-select/ (multiple example), (data) appears 2 times.
Seems like (data)="value" do nothing. So it's a question, how to set initial value of multiselect?

ok, found it in issues below: [active] attribute to set initial, but what the purpose of (data)="value" in example?


Remove www. from domain names (at least in viewer)

When browsing for an archived website here: https://archive.fart.website/archivebot/viewer/domains/ -- I didn't expect "fanfiction.net" to be under "www.fanfiction.net".
www is the equivalent of "the" in a title -- it shouldn't be used in an index as it's not really part of the website's canonical name. Is it possible this might be implemented in the viewer only, with no other code changes required? Or whichever solution is best.

Can't you use the search box, though?

Nevermind, saw the context in #archiveteam-bs.
The problem with this is that www. is sometimes different from "normal". It's not common, but I've seen it before, although I can't remember what website it was (some type of forum). Non-www was a home page with a link to both the English one, and the www one (I don't remember what language the www one was, but it wasn't English). Something like that, at least.
But, if you are just suggesting that www.fanfiction.net should also be under F in addition to W, I think that would be OK. Maybe a maintainer can say whether this is doable. :-)

The problem with this is that www. is sometimes different from "normal". It's not common, but I've seen it before, although I can't remember what website it was (some type of forum).

Working protocol/subdomain difference example (as of 2022-12-10 19:08:23 UTC):

http://scoobypanel.com/ - Inaccessible.
https://scoobypanel.com/ - Inaccessible.
http://www.scoobypanel.com/ - Redirects to https://www.scoobypanel.com/.
https://www.scoobypanel.com/ - Returns its homepage.

I know there are other instances of this—some returning vastly different pages or redirecting to other domains—but no further examples come to mind at the moment. I will update this message when I come across more (if I remember to do so, that is, haha).
To add further insult to injury, I have come across instances of prefixes such as www2., www3., www49., etc. Should these appear with the results as well? I assume, however, it may be rather unlikely one is looking for these variations without specifying them beforehand.

…if you are just suggesting that www.fanfiction.net should also be under F in addition to W, I think that would be OK.

I, too, agree with this implementation.


improve startup speed of topview and other views

With the current configuration of MSS for the campaign, a start of TopView takes a noteable moment.
We have to optimizing initializing of parameters.
Probably it is faster to read all sections instead one by one, or to read more than one section by the config_loader.

The config_loader is not often called in this view, we have to look on the modules imported.

90% of the initialization time of the topview window is by self.mpl.canvas.init_map. I have also tried moving this to after the window is created but it doesn't seem to work. Is there something we can do about this?

Indeed this is an issue with the time Basemap needs to generate the requested map.

It is possible to just start the topview without the map and load it in the background like @aravindm711 suggested.
However I am unsure if it isn't aesthetically better to just wait for everything to load.

likly on the choosen map section and also the kind of projection it will take shorter or longer.
Should we show to the user that he clicked the button by a fast progressbar ?

If this did time span did not much exceed, we have to live with it.


optional string field with string min/max options set wrong meta in veevalidate

I'm not sure if this is a valibot problem, but it could be.
Valibot version 0.27
I make a record of the scheme like this:
const deviceSchema = object({
  imsi: imsi(),
  imei: optional(string([
    minLength(1, 'Необходимо ввести IMEI'),
    minLength(15, 'IMEI должен быть не менее 15 цифр'),
  ])),
  description: optional(string()),
})

Next, I use the scheme in conjunction with veevalidate:

const { handleSubmit, meta, errors, defineField, resetForm } = useForm<tDevice>({
  validationSchema: toTypedSchema(deviceSchema),
})

And I get that meta does not have the correct flag if the imei does not meet the length requirements, despite the fact that the field is optional.
I assume that the scheme in which the optional field has length requirements (or others) does not work correctly.
But this is just a guess.

Feel free to try it out in our playground: https://valibot.dev/playground/

Yes - this is problem with veevalidate
In valibot playground all looks OK


PowerShell Notebooks should give users an option to load the $Profile

The code cells in PowerShell Notebooks currently pass the -NoProfile switch to PowerShell.exe or pwsh when they are executed.  This makes sense as a default since it makes the execution time faster.  However, PowerShell Notebook should have an option for the user to specify that they intend for the $Profile to be loaded (basically removing the -NoProfile switch prior to execution).

By default it should still be -NoProfile so that Notebooks will work for all users but an option is a good idea

Can't you just use the PS Extension to control the profile loading or not?
powershell.enableProfileLoading


Control Parallel Git Invocation

This PR ensures that we will ever run git commands in serial against a given working directory. Controlling per directory means that concurrent tests from various service areas will still be able to work alongside each other.
@benbp what do you think about this? I like that it is entirely atomic to the class. When we move this guy to a common core, this functionality should definitely merge IMO.

@scbedd @hallipr also has some task queue logic built up, but it's a little more dependent on external services which we don't want here (though the task queue message provider could be local). Looks good though.

Added in further feedback from and the repo tests are passing using the new methodology!


Adding Mime warning to fsck

RELEASE_NOTES=[ENHANCEMENT] fsck now detects leftover Mime secrets
RELEASE_NOTES=[BUGFIX] fsck won't correct recipients without --decrypt

Codecov Report

Merging #1695 (04e7acb) into master (fb2553b) will decrease coverage by 0.07%.
The diff coverage is 29.41%.

@@            Coverage Diff             @@
##           master    #1695      +/-   ##
==========================================
- Coverage   57.31%   57.25%   -0.07%
==========================================
  Files         205      205
  Lines        9806     9819      +13
==========================================
+ Hits         5620     5621       +1
- Misses       3526     3539      +13
+ Partials      660      659       -1

Impacted Files
Coverage Δ

internal/secrets/kv.go
67.16% <0.00%> (-3.15%)
:arrow_down:

internal/secrets/mime.go
0.00% <0.00%> (ø)

internal/secrets/plain.go
57.50% <0.00%> (-1.47%)
:arrow_down:

internal/secrets/yaml.go
68.92% <0.00%> (-0.94%)
:arrow_down:

internal/store/leaf/fsck.go
50.00% <45.45%> (-4.39%)
:arrow_down:

Continue to review full report at Codecov.

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

Codecov Report

Merging #1695 (04e7acb) into master (fb2553b) will decrease coverage by 0.07%.
The diff coverage is 29.41%.

@@            Coverage Diff             @@
##           master    #1695      +/-   ##
==========================================
- Coverage   57.31%   57.25%   -0.07%
==========================================
  Files         205      205
  Lines        9806     9819      +13
==========================================
+ Hits         5620     5621       +1
- Misses       3526     3539      +13
+ Partials      660      659       -1

Impacted Files
Coverage Δ

internal/secrets/kv.go
67.16% <0.00%> (-3.15%)
:arrow_down:

internal/secrets/mime.go
0.00% <0.00%> (ø)

internal/secrets/plain.go
57.50% <0.00%> (-1.47%)
:arrow_down:

internal/secrets/yaml.go
68.92% <0.00%> (-0.94%)
:arrow_down:

internal/store/leaf/fsck.go
50.00% <45.45%> (-4.39%)
:arrow_down:

Continue to review full report at Codecov.

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

I should have thought of using type assertions, sorry for that.
Done.

I should have thought of using type assertions, sorry for that.
Done.


dhcpd ipv4 - fix gui config to accept multiple subnets and/or answer requests from relay servers

Can it be reviewed until merge conflicts issues. It's the third time I rewrite this.

Leave it as is for now, I'm going to review it and let you know. After it's reviewed you rebase your fork and we get it merged.

Hi, we tryed your files today.
But the dhcpd.conf which was created did not load.
All networks are as pools under one subnet, in the old version you crate a subnet per pool.
Maybe you can take a look.
Regard niko

rbgarga, how about to bring this pull request into the master ?

Any progress on this issue?

Hey, how does it look? Don't tell me, the finished work will go to waste

After discuss privately with @marcelloc he agreed to submit a fresh patch, tested on 2.3, and I'll review it as soon as it lands here

Was this feature ever merged?

We're in a position where we are trying to configure DHCP as described above, and we were slightly surprised that it is not presently possible! Can someone post a link to the fresh PR where we can track the status?

Found myself needing this yesterday, I assume it is still not supported? Found a dirty workaround in the meantime (I haven't tested it yet) https://happy-coder.com/2014/06/27/pfsense-custom-dhcpd-configuration/

Any progress on this feature?

I need this too. Thank you for the happy coder workaround, but it's going to be very careful upgrading :-(

Need this too. Would be greate to see this feature in the near future.

+1 for using this

+1 for this basic functionality...

+1 for this basic functionality...

+1 also

+1 what happened to this request?

+1  official merge would be very much helpful it can really simplify messy setup example in my case, I have more than 25 vlans, creating 25+ vlan interfaces on pfsense and enabling DHCP on each interface is really tedious job practically, what if there are many more vlans.
From last few years I have been waiting for this feature as everything is relayed through  switch as a DHCP relay to single DHCP server in my case.
The day it gets merged I will migrate from ISC DHCP to pfsense.
Any updates on feature implementation ?


Initial Term and Taxonomy support

This adds the initial functionality for Terms and Taxonomies.
The Term model behaves very much like the Post model, and instances can be created and worked with in very much the same way.
The term class also provides a similar query builder syntax, for querying and Terms of the model's type.
Targets #4 and #5, no taxonomy builder.. yet.

Changes Unknown when pulling 389e228e6a8a40629b8f3b6fa8ce9b6ff499a926 on feature/term into ** on master**.

Changes Unknown when pulling 9179267ebb9cc436cd45bd73d6b59980e3eb1e47 on feature/term into ** on master**.

Changes Unknown when pulling 9179267ebb9cc436cd45bd73d6b59980e3eb1e47 on feature/term into ** on master**.

Changes Unknown when pulling d56cb0fa6135fa43c5d6e6c8dc845242aa277586 on feature/term into ** on master**.

Changes Unknown when pulling bda531085b879a4461adbc697017382b4ec2cc37 on feature/term into ** on master**.


Concurrent Web Requests Timeout

Need to add external facing repro instructions, but the TL;DR is that when launching react applications and probably anything that makes concurrent requests to an application ends up being deadlocked(?) and requiring a new connection to start getting traffic again.

Fixed by https://github.com/jaredallard/localizer/commit/6fa2c77d02978964aee4ed30a61324f3f8aa2682


Convert // comments to /* */ comments

Hey
I know other project does not like /* */ and convert to //.
Any special reason for this issue?

// was introduced with C99. C89 only supports /* */, and it's something that the integrator can't override.

I see your point. Agree.

I will check it.


Bug serializing QRM/QCM-RF instruments and precision errors

There was a bug serializing the instruments QbloxQRMRF and QbloxQCMRF. An attribute out_offsets was dumped into the saved runcard file for those instruments when those do not have that particular attribute. Encountered this bug testing a corner case where you build_platform then save_platform and build_platform again. A new test was added on this PR to cover this corner case.
This PR solves a precision error with decimals, now the save_platform is correctly saving the platform on the runcard maintaining the same precision. Covered in the previously mentioned test.

Thanks @GuillermoAbadLopez looks good for me too!


when running the QuickStart readflow, AWS CLI doesn't accept "theshire" as a Region

when running manually the QuickStart, when you get to the part where you need to register your asset to localstack,
configuring REGION as "theshire" produces an error -
"An error occurred (InternalError) when calling the PutObject operation (reached max retries: 2): exception while calling s3.PutObject: 'theshire' is not a valid AWS region name for s3"

@aradhalevy can you please provide the version of the aws client you use? Thanks


Update MintableToken.sol: Issue #513

function mint() will now revert on being called with an amount equaling zero. Fix Issue #513

Thanks for the contribution @nedodn, but I'm closing this PR due to the discussion on #513.


Feature/hand poses

test hand grabbing with different poses on grabbable objects

mistake -wanted to pull request to dev


transaction from http api call

I want do transaction from http api, for example: I want transfer from http api but not cleos program.
any suggestion ?

Of course we will consider the security. and user will pass the private key from http

eosjs does this.

Yes, use eosjs, or you can use the rpc api


MGPU CPP tests fail when RMM is used.

It appears rmm doesn't handle setDevice very well. I can pass the test if I set CUDA_VISIBLE_DEVICES=0. Without limiting the number of devices, the testxgboost would run into CUDA invalid memory error.

We might just document it. Managing a pool with arbitrary set device seems brittle.


When someone turns on E2E in a room, the composer padlock doesn't immediately switch from unlocked to locked

Cannot reproduce


Fetching language distribution of repositories of a particular user

The objective is to fetch details of the repositories of a particular user to gain an insight into the coding habits of the user. The significance of this data is huge as this will be used frequently in upcoming versions of this app. :yellow_heart:

This feature has been implemented in the form of a 3D pie chart. Pie chart has been preferred to bar graph as it provides an intuitive sense of part of the whole contribution.


No error messages when attempting to review creation of new VMs in existing hostpool.

Hi all.
I attempted to add VMs to an existing hostpool, one  which I've added to before. However, when using the same settings as last time during the review and create point the following message is displayed:
"Required parameters are missing. Please complete all required form fields."
All form fields are correctly added to the system. The workspace name is set to none, which seems strange. However I have no place to add this.
Also, note that the application group and workspaces ARE set up and connected properly.

@mikal768 Please help with the link of document on which above document feedback request is created.
Under this repository we want to make sure any issue is linked to a doc so we can help others that may be having the same issue.

@mikal768 Please help with the link of document on which above document feedback request is created.
Under this repository we want to make sure any issue is linked to a doc so we can help others that may be having the same issue.

https://docs.microsoft.com/en-us/azure/virtual-desktop/expand-existing-host-pool

@mikal768 Apologies in delayed response.
I reached out to internal team for checking on this, this issue is related to portal framework change (not WVD specific) and this was fixed.
Request you to retry and see if you are still hitting the issue.
Incase you are still seeing the issue, then we would recommend to open a support case to get this checked.

@mikal768
Hope the provided information is helpful.
We will now close this issue. If there are further questions regarding this, please tag me in a comment. I will reopen it and we will continue the discussion.
Incase if you need any help opening support case, please add your comment here, I will help opening a support case if required.


Very slow to connect debugger

Tested versions
v4.3.dev6.mono.official [89850d553]
System information
Godot v4.3.dev6.mono - Windows 10.0.17763 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2060 (NVIDIA; <IP_ADDRESS>49) - AMD Ryzen 9 5950X 16-Core Processor (32 Threads)
Issue description
I'm print time in _physics_process.

look at output int the GIF, it take about 15s then start print.

Steps to reproduce
In my project, it always take long time to print or debug (use a other pc was this isssue too).
but I can't found a MRP, maybe it was because my project was too large or too much gds. it about 3G.
Minimal reproduction project (MRP)
None

This is very hard to evaluate with the details you've given, more details are probably required to do anything with this, like what tool you're using to debug, what setup, etc.

very like https://github.com/godotengine/godot/issues/93104
before run a scene, it save scene first. and I'm test for only save scene. it freeze a while.

Fixed by #93147.


helm3 - --timeout flag ignored

Output of helm version:
version.BuildInfo{Version:"v3.0", GitCommit:"", GitTreeState:"", GoVersion:"go1.12.9"}

Output of kubectl version:
Client Version: version.Info{Major:"1", Minor:"13", GitVersion:"v1.13.9", GitCommit:"3e4f6a92de5f259ef313ad876bb008897f6a98f0", GitTreeState:"archive", BuildDate:"1970-01-01T00:00:01Z", GoVersion:"go1.11.6", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.2", GitCommit:"c97fe5036ef3df2967d086711e6c0c405941e14b", GitTreeState:"clean", BuildDate:"2019-10-15T19:09:08Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
Minikube, self-hosted Kubernetes
I have such job:
apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
  annotations:
    "helm.sh/hook": pre-install,pre-upgrade
    "helm.sh/hook-delete-policy": hook-succeeded
spec:
  template:
    metadata:
      name: db-migrate
    spec:
      restartPolicy: Never
      containers:
        - name: migrade-exmple
          image: alpine:latest
          command: ["sleep", "300"]

I install chart with:
helm upgrade --install myname . --timeout 3000s

After 60s no matter what in the timeout flag I get:
Release "myname" does not exist. Installing it now.
Error: failed pre-install: watch closed before UntilWithoutRetry timeout

@bacongobbler can you help with reviewing this issue?

have you looked at #2025? Most issues related to timeouts closing early are due to some external factor. In most cases it's the load balancer fronting the Kubernetes API server closing the connection.
Let us know if you find something.

@bacongobbler had locked in #2025 it is not it. First I am running this installation on local minikube what and there cant be any issues with the network (during all my interaction with it there weren't any).
Second, my error message is Error: failed pre-install: watch closed before UntilWithoutRetry timeout what says about pre-install hook timeout. And more - it happens directly after 60s what is the default timeout, that why I think that timeout flag is ignored.

@novoxudonoser This looks like it might be the same issue as #2918. It looks like that fix delivered in PR #6014 for Helm 2 was not ported to Helm 3. I have pushed #7217 for Helm 3 fix.

The #7217 fixes this issue. @bacongobbler you were right the issue was about TCP timeout of the load balancer, but still, it was a bug cause no "heartbeats" while waiting for hook where send.


[typescript] Update class keys

Follow up to #10644

@lukePeavey Hopefully, we have been taking care of all the TypeScript changes I have forgotten in the latest release. Thank you


feat: Change from KDIS_SOURCE_DIR to CMAKE_CURRENT_SOURCE_DIR

The value of KDIS_SOURCE_DIR is not set and can cause UB. Moreover it can cause strange inclue errors while using"auto-tools" like CPM.
From:
https://github.com/karljj1/kdis/blob/3cdfc0fb37872dbf070e43c77c7dfff8fa26a8a4/KDIS/CMakeLists.txt#L36
To:
SET(BASE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/KDIS)

It's been a long time since I touched this, ill have to look through it and see what its purpose was.
Im happy to take a PR to change it.

I'll create a PR 🥳


Framework pages style issue

Hi @housseindjirdeh
Right Now all framework pages have a minor style issue.
It seems like it is a container height problem. The little footer is also massing up because of this.

Thanks :)

Thanks for logging this @PraveenPal4232 :)
So this should have been resolved by #, but I most probably fiddled around with the container heights after that causing it to overflow on certain screens 😅


dune: Add --display=short build flag

Description of changes
Add the --display=short flag to dune's mkDerivation (and backport it to coq).
This allows the user to get an idea of where the build process is currently at, as with other build systems.
Things done

Built on platform(s)

[X] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[~] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[X] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

What's the use case for this? To me it seems like it is adding unnecessary noise to the build. If a build fails, Dune should be giving error messages as to why it failed and that is typically the only times we inspect the logs via nix. If the build succeeded, what is the point of inspecting the logs?

Looks like an unnecessary mass rebuild. If you have a use case, you can make a local override.

IIRC --display short will only output after a build step has completed anyway, so even if your build is hanging it won't be faithful to the actual file that coq is stuck on.
There are a few solutions to understanding why a build is stalling.

You can add a set timeout in the CI and afterwards inspect the _build/log that dune generates. This should be available in the artifacts for the failed nix derivation, nix will probably even tell you where to find them if it was interrupted (I can't recall though). That log will contain all the information about the commands that Dune was able to run, but not the command that was running during the interrupt.
Instead of building the project itself via nix, you can use nix only for the dependencies and have a more elaborate build setup for the project. There you can pass whatever options you want, including --display and you could even ask Dune to dump a flamegraph of the build at the end so you can inspect the bottlenecks.
Building locally, you can inspect the currently running processes. Basically, look for coqc. If you can somehow replicate such a monitor in the CI that might be useful.

The problem I am seeing is that for most OCaml and Coq projects, having a silent Dune is not a problem, and generally is preferred, since it makes log inspection easier. Therefore it seems like overreach to change this option for everybody given that this is an issue with your CI.


Remove Nubbin & Close X From Color Picker

The DSR Color Picker should match the SLDS Color Picker (https://www.lightningdesignsystem.com/components/color-picker/).
The items below should be tweaked (this is not an exhaustive list).

Remove the nubbin from the DSR Color Picker and move the Popover up to match the SLDS Color Picker
Remove the close x in the upper right corner of the DSR Color Picker.
Make the DSR Color Picker tab text size larger (i.e. 13px, visual redline from 220 SLDS).
Make the DSR Color Picker selected tab's blue bar thicker (i.e. 3px, visual redline from 220 SLDS).
Make the DSR Color Picker gray bar under the tabs thinner (i.e. 1px, visual redline from 220 SLDS).
Make the DSR Color Picker swatches on the default tab larger (i.e. 20px x 20px, visual redline from 220 SLDS, probably due to gray border). Retain the border for the transparent swatch but make it rgb(201, 199, 197).
Make the DSR Color Picker selected swatch treatment match on both tabs. Remove all current selected swatch styling and add a 1px black border on the inside of the swatch with a 1px white border on the inside of the black border for all swatches. See examples below.

Image Below Shows Blue Selected

Image Below Shows Transparent Selected

@interactivellama I may need to go through this and do an engineering spec if anything is not straightforward.

I would like to work on this issue.
I have some question, before starting.

Remove the close x in the upper right corner of the DSR Color Picker.

can I add prop closeIcon: PropTypes.bool in popoverwhich will decide whether to show x icon.

Remove the nubbin from the DSR Color Picker and move the Popover up to match the SLDS Color Picker

I don't really understand this! :(

Make the DSR Color Picker tab text size larger (i.e. 13px, visual redline from 220 SLDS).

can I add props labelSize: PropTypes.number in tab component?

Make the DSR Color Picker selected tab's blue bar thicker
Make the DSR Color Picker gray bar under the tabs thinner

I can't really figure this out can anyone help me out with this?

Make the DSR Color Picker swatches on the default tab larger

Looks like this is already done.

I would like to work on this issue.
I have some question, before starting.

Remove the close x in the upper right corner of the DSR Color Picker.

can I add prop closeIcon: PropTypes.bool in popoverwhich will decide whether to show x icon.

Remove the nubbin from the DSR Color Picker and move the Popover up to match the SLDS Color Picker

I don't really understand this! :(

Make the DSR Color Picker tab text size larger (i.e. 13px, visual redline from 220 SLDS).

can I add props labelSize: PropTypes.number in tab component?

Make the DSR Color Picker selected tab's blue bar thicker
Make the DSR Color Picker gray bar under the tabs thinner

I can't really figure this out can anyone help me out with this?

Make the DSR Color Picker swatches on the default tab larger

Looks like this is already done.

I would like to work on this issue

@kwilloughby-sf These issues should be fixed now http://design-system-react-components.herokuapp.com/?selectedKind=SLDSColorPicker&selectedStory=Default&full=0&addons=1&stories=1&panelRight=0&addonPanel=storybook%2Factions%2Factions-panel

Thanks for the heads up @interactivellama. I do see a few discrepancies between my mockups and Storybook. I will create a new issue. For example, the transparent item should still have a gray border when it's unselected.


Non-admin reviewers need to be able to review all works in their admin set

Descriptive summary
Hyrax 1-0-Stable branch workflow process does not give a non-admin user the ability to approve anything other than public works.
It is possible that there is a way to manage this that I didn't find (through permissions on the admin set perhaps?) but if so, the steps need to be clearly documented, and a user should not be allowed to be assigned the reviewer role without the correct permissions.
Rationale
Only the admin user has the review submissions menu. Other users with the approving role can only approve by clicking the link to the work in the notifications.  I don't know whether the review submissions menu allows the approving role to have access to view works they are otherwise not authorized to see, but they definitely can't access them via the link in the notification.
Expected behavior
If a user has the approving role, they should be able to view and approve the work.
Actual behavior
The user cannot view or review a work unless it is public.
Spreadsheet of details from testing of workflows on both stable and master branches.
Steps to reproduce the behavior
The gist shows the steps taken, and the highlighted line shows the point where this issue was reached.
Related work
https://github.com/projecthydra-labs/hyrax/issues/882

Need to add the ability to grant "read" authority according to workflow state.

@laritakr I was just going to mark this as a blocker based on our use cases, is there a reason you removed the blocker label?  I would be in support of keeping it.

@mark-dce I had originally set it as a blocker, but . I removed it because I am evaluating the behavior in more detail, and working to identify all of the issues and determine if there are workarounds.
At that point, I assumed we would determine for sure what all of the blockers are. But yes, I'm fine with calling it a blocker for now since I haven't finished that analysis yet. I'll replace the tag.

In the master branch, reviewers are able to review private works if they also were assigned the "viewer" role. There should be some changes in master which can be ported to the 1-0-Stable branch to make this workable.

This is related to https://github.com/projecthydra-labs/hyrax/pull/761, which has gone cold.

I'm trying to unstick #761. Pushed a small change and created a new issue about a potential redesign based on what @jeremyf suggested. Hoping we can get this change in soon and revisit the latter thereafter.


Improvement: Enhanced Documentation for npm and Gulp Tasks

In this PR, I have made improvements to the documentation regarding the npm and Gulp tasks used in the project. The changes include:

Adding clear headings to organize the content.
Grouping related npm scripts and Gulp tasks together for easier reference.
Providing detailed descriptions of what each script or task does.
Using code formatting for command-line instructions to make them stand out.
Clarifying the purpose of each section to provide context for users.
Reformatting command-line commands for better readability.

These changes aim to enhance the clarity and structure of the documentation, making it easier for users to understand and work with the project's tasks.

Can any of the maintainers please have a look at the PR and merge it if the changes are found relevant?

Hi @adarsh-jha-dev - I've added this to our workflow so the team can take a look at it. Thanks for submitting!


Test Case failure

Test cases stopped working not sure of the root cause.
Failed Test Case dependecies and their versions
dep init
Locking in v1.6.0 (004e3cb) for transitive dep github.com/stretchr/testify
Locking in v3 (e307989) for transitive dep gopkg.in/yaml.v3
Locking in v1.0.0 (792786c) for transitive dep github.com/pmezard/go-difflib
Locking in v1.1.1 (8991bc2) for transitive dep github.com/davecgh/go-spew
Locking in master (627f964) for transitive dep golang.org/x/net
Using ^0.28.2 as constraint for direct dep github.com/gruntwork-io/terratest
Locking in v0.28.2 (a8cc331) for direct dep github.com/gruntwork-io/terratest
Locking in master (279210d) for transitive dep golang.org/x/crypto
Locking in master (6fdc65e) for transitive dep golang.org/x/sys

go test -v
test/vendor/github.com/gruntwork-io/terratest/modules/shell
vendor/github.com/gruntwork-io/terratest/modules/shell/command.go:161:84: undefined: io.StringWriter
FAIL	test [build failed]
================================================

Successfully Test cases and their dependencies and versions.

dep init
Locking in master (7e3656a) for transitive dep golang.org/x/net
Locking in v1.5.1 (3ebf1dd) for transitive dep github.com/stretchr/testify
Locking in v1.0.0 (792786c) for transitive dep github.com/pmezard/go-difflib
Locking in v2.3.0 (0b1645d) for transitive dep gopkg.in/yaml.v2
Locking in v1.1.1 (8991bc2) for transitive dep github.com/davecgh/go-spew
Using ^0.27.2 as constraint for direct dep github.com/gruntwork-io/terratest
Locking in v0.27.2 (dac0027) for direct dep github.com/gruntwork-io/terratest
Locking in master (06a226f) for transitive dep golang.org/x/crypto
Locking in master (417ce23) for transitive dep golang.org/x/sys
[Pipeline] sh
dep ensure
[Pipeline] sh
go test -v
The Test cases work.
================================================

The same exact test case passed for Terragrunt version v0.27.2 whereas it fails now v0.28.2.

Please upgrade your go version to at least 1.12. io.StringWriter was introduced in go 1.12.
Since v0.16.0, we've switched to using go modules. With this switch, we've standardized our internal testing of terratest to target go 1.13+. We don't plan on testing or supporting older versions of go, so your options are to either update your go version, or lock your versions to 0.27.2.


Write tool to verify we have tests for all apis

We should write a simple tool to check that we have tests for all public apis and that they are organized according to our test plan/policy

This is no longer necessary now that Swift 2 can generate test code coverage.


Have a way to identify if a GraphEntry was executed or not

If I run and then display the dag with Graph.Analyze I can see if it failed or not, but I have no idea if it was executed or not.
Would really love to be able to check if it was run or not directly by doing something like
for i, layer := range g.Analyze() {
		for _, op := range layer {
			fmt.Printf("%s -> %t\n",op.Name, op.Finished/Executed)
		}
}

good point!


introduce camunda-bpm-spring-boot-configuration

We should move the yaml/properties setup of ProcessEngineConfiguration to a separate module. I would love to use this kind of config for non-spring-boot projects

i close this one, Oliver rejected it and we can reopen in jira if needed


[Kic2.0] Fix kic image deployment failure #1486

What this PR does / why we need it:
time="2021-07-04T00:42:35Z" level=error msg="Reconciler error" error="secrets "controller-token-tdslg" is forbidden: User "system:serviceaccount:kong:kong-serviceaccount" cannot update resource "secrets" in API group "" in the namespace "metallb-system"" logger=controller-runtime.manager.controller.secret name=controller-token-tdslg namespace=metallb-system reconciler group= reconciler kind=Secret
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #
#1480
#1421
Special notes for your reviewer:
PR Readiness Checklist:
Complete these before marking the PR as ready to review:

[ ] the CHANGELOG.md release notes have been updated to reflect any significant (and particularly user-facing) changes introduced by this PR

Do we know where the attempt to edit controller-token-tdslg is coming from? I haven't encountered that before and am not sure where/why the controller would need to edit a Secret. I'm not clear on the link between it and the changes proposed here.
Historically we haven't had any system to automatically infer the admin API URL from a Service or similar, and hadn't had any plans to add one, as directly providing a URL has been sufficient. Can you elaborate on why you added it? The proposal here makes several decisions we wouldn't want (always using HTTP and sending traffic through an Ingress rather than to a Service over the intra-cluster network) that the URL avoids.
Manifests we planned to handle in #1256, though that's more about building out new kustomize helpers than just providing a manifest--the existing 1.x manifests should work fine for now.

#1256

Do we know where the attempt to edit controller-token-tdslg is coming from? I haven't encountered that before and am not sure where/why the controller would need to edit a Secret. I'm not clear on the link between it and the changes proposed here.
Historically we haven't had any system to automatically infer the admin API URL from a Service or similar, and hadn't had any plans to add one, as directly providing a URL has been sufficient. Can you elaborate on why you added it? The proposal here makes several decisions we wouldn't want (always using HTTP and sending traffic through an Ingress rather than to a Service over the intra-cluster network) that the URL avoids.
Manifests we planned to handle in #1256, though that's more about building out new kustomize helpers than just providing a manifest--the existing 1.x manifests should work fine for now.

Please ignore the specific error messages (sorry for that example details) since different ones pop up when debugging deployment. The purpose of this PR is to unblock controller manager in cluster deployment with appropriate configuration which is illustrated in the yaml and readme file.
The points of the Kong Admin API URL is to remove hardcode ip address (publishStatusAddress) and leverage environment variable retrieving service information. Understand the previous configuration due to controller and proxy are in the same namespace and same pods. Now, we have the flexibility to de-couple them in 2.0

unblock controller manager in cluster deployment with appropriate configuration which is illustrated in the yaml and readme file.

I was trying to understand what issue we had there though--if there is some error that appears, we'd want to understand why it occurs to ensure we're adding a fix. I wasn't aware of any, as when I test the controller 2.0.0-alpha.1 image with the current chart and the all-in-one manifests we have in https://github.com/Kong/kubernetes-ingress-controller/tree/main/deploy/single it does deploy successfully. I am aware of issues with the RBAC config and lack of UDPIngress in the existing examples, but I don't think they cause failures (we just can't update finalizers and have to disable UDPIngress), and we planned to update that elsewhere (#1256 and https://github.com/Kong/charts/pull/364). The rest of the manifests that we had for 1.x do still work with 2.x.

The points of the Kong Admin API URL is to remove hardcode ip address (publishStatusAddress) and leverage environment variable retrieving service information. Understand the previous configuration due to controller and proxy are in the same namespace and same pods.

This sounds related to the work in https://github.com/Kong/kubernetes-ingress-controller/pull/1451, correct? fe24a710b41ea07d48688f9290706309d8762ea3 should have already given us what we need there. publishStatusAddress should remain: it serves as a user override for Ingress status addresses when they know there network topology doesn't let the controller effectively determine the correct address information (similar to the Service clusterIP setting), as an alternative to --publish-service.
That doesn't have any interaction with the admin API, as we're only concerned with the proxy for Ingress status. We shouldn't need any additional admin API logic--while building configuration from a Service instead is viable, it doesn't really give us anything obvious over requesting a URL instead (since we don't need to look up endpoints or obtain other detailed information about the Service), and our documentation all already refers to the existing --kong-admin-url flag.

Just a note: the manifest template probably overlaps with https://github.com/Kong/kubernetes-ingress-controller/pull/1500

unblock controller manager in cluster deployment with appropriate configuration which is illustrated in the yaml and readme file.

I was trying to understand what issue we had there though--if there is some error that appears, we'd want to understand why it occurs to ensure we're adding a fix. I wasn't aware of any, as when I test the controller 2.0.0-alpha.1 image with the current chart and the all-in-one manifests we have in https://github.com/Kong/kubernetes-ingress-controller/tree/main/deploy/single it does deploy successfully. I am aware of issues with the RBAC config and lack of UDPIngress in the existing examples, but I don't think they cause failures (we just can't update finalizers and have to disable UDPIngress), and we planned to update that elsewhere (#1256 and Kong/charts#364). The rest of the manifests that we had for 1.x do still work with 2.x.

The points of the Kong Admin API URL is to remove hardcode ip address (publishStatusAddress) and leverage environment variable retrieving service information. Understand the previous configuration due to controller and proxy are in the same namespace and same pods.

This sounds related to the work in #1451, correct? fe24a71 should have already given us what we need there. publishStatusAddress should remain: it serves as a user override for Ingress status addresses when they know there network topology doesn't let the controller effectively determine the correct address information (similar to the Service clusterIP setting), as an alternative to --publish-service.
That doesn't have any interaction with the admin API, as we're only concerned with the proxy for Ingress status. We shouldn't need any additional admin API logic--while building configuration from a Service instead is viable, it doesn't really give us anything obvious over requesting a URL instead (since we don't need to look up endpoints or obtain other detailed information about the Service), and our documentation all already refers to the existing --kong-admin-url flag.

unblock controller manager in cluster deployment with appropriate configuration which is illustrated in the yaml and readme file.

I was trying to understand what issue we had there though--if there is some error that appears, we'd want to understand why it occurs to ensure we're adding a fix. I wasn't aware of any, as when I test the controller 2.0.0-alpha.1 image with the current chart and the all-in-one manifests we have in https://github.com/Kong/kubernetes-ingress-controller/tree/main/deploy/single it does deploy successfully. I am aware of issues with the RBAC config and lack of UDPIngress in the existing examples, but I don't think they cause failures (we just can't update finalizers and have to disable UDPIngress), and we planned to update that elsewhere (#1256 and Kong/charts#364). The rest of the manifests that we had for 1.x do still work with 2.x.

The points of the Kong Admin API URL is to remove hardcode ip address (publishStatusAddress) and leverage environment variable retrieving service information. Understand the previous configuration due to controller and proxy are in the same namespace and same pods.

This sounds related to the work in #1451, correct? fe24a71 should have already given us what we need there. publishStatusAddress should remain: it serves as a user override for Ingress status addresses when they know there network topology doesn't let the controller effectively determine the correct address information (similar to the Service clusterIP setting), as an alternative to --publish-service.
That doesn't have any interaction with the admin API, as we're only concerned with the proxy for Ingress status. We shouldn't need any additional admin API logic--while building configuration from a Service instead is viable, it doesn't really give us anything obvious over requesting a URL instead (since we don't need to look up endpoints or obtain other detailed information about the Service), and our documentation all already refers to the existing --kong-admin-url flag.

Agree that both publish-service and PublicStatusAddress should retain as it is, which was covered by https://github.com/Kong/kubernetes-ingress-controller/pull/1509 and https://github.com/Kong/kubernetes-ingress-controller/pull/1451. It is unrelated to the KIC individual deployment yaml
KIC does need KongAdminAPI for configuration communication,
https://github.com/Kong/kubernetes-ingress-controller/blob/main/railgun/manager/run.go#L96
Current configuration way https://github.com/Kong/kubernetes-ingress-controller/pull/1500/files#L90 assumes all modules are in the same node and having static port (8444), this will break if we deploy controller and proxy separately. The function retrieve Admin ip and port through namespace and name configuration. https://github.com/Kong/kubernetes-ingress-controller/pull/1487/files#diff-786a1651aa544e8c2f84a32b474758ecb0f8e6c5d9d745b5f643d3d786bc57c4R152

The assumptions in the various all-in-one YAMLs are by design: those are intentionally opinionated configurations for a select few common configurations (OSS or Enterprise, either with or without a database). They use a single Pod with one Kong container and a controller container because that topology is simple to manage, suitable for many users (especially those that don't have a known reason to use some other topology), and has security benefits for OSS (placing the controller in the same Pod means you don't need to expose the admin API, which is a simple means of securing it without RBAC).
If you want another topology, we currently instruct you to use the chart or to build your own manifests by hand. That stems from a combination of historical reasons (when we started providing manifests, Helm was fairly mature and both Kustomize and Operators were new) and capacity (we have limited resources to maintain deployment tools, so have not built out more complex Kustomize manifests or a non-Helm Operator). We don't provide plain manifests for topologies other than single-Pod because there are so many of them (you can basically mix and match any of the ~12 options covered in the chart documentation, and even the chart doesn't commit to handling all topologies in their entirety--many require multiple releases).
That all said, I still don't think we gain anything by building admin API information from a Service rather than providing a URL, and introduces new problems (which aren't solved here yet):

Using a Service name/namespace doesn't remove the requirement to indicate where the Service resides when it's not local (you're providing namespace/svc-name instead of K8S DNS svc-name.namespace for the URL hostname).
Using a Service requires a code solution for determining the protocol and appropriate port, which are currently encoded directly in the URL. This would likely require additional constraints on the Service (we'd need a known name scheme for the HTTP and HTTPS admin ports).
Using a Service is not compatible with the localhost admin API approach, which we want to support for its simple security model.
Backwards compatibility with the existing URL flag requires that we add code to negotiate between the two options.

IMO we'd only want to add the Service option if we had some functionality that required interactions with the Kubernetes API (e.g. we want to get endpoint information or need to edit its metadata for some reason), and I don't think we have any such functionality proposed. Between that and the other points above, I'd recommend we close this and continue the manifest changes separately in #1500 and other issues attached to #1256.

#1500

The assumptions in the various all-in-one YAMLs are by design: those are intentionally opinionated configurations for a select few common configurations (OSS or Enterprise, either with or without a database). They use a single Pod with one Kong container and a controller container because that topology is simple to manage, suitable for many   ##users (especially those that don't have a known reason to use some other topology), and has security benefits for OSS (placing the controller in the same Pod means you don't need to expose the admin API, which is a simple means of securing it without RBAC).

[Jimin] No doubt about all-in-one benefits - simplicity. Stick to design, the Kong Admin TLS option https://github.com/Kong/charts/blob/main/charts/kong/values.yaml#L117 provides the scalability to allow other components  access the service either in cluster or out of the cluster with security. Also, from standardization point of view, each component/service/controller deploy separately provides the topology management flexibility, rather than simplicity.

If you want another topology, we currently instruct you to use the chart or to build your own manifests by hand. That stems from a combination of historical reasons (when we started providing manifests, Helm was    ###fairly mature and both Kustomize and Operators were new) and capacity (we have limited resources to maintain deployment tools, so have not built out more complex Kustomize manifests or a non-Helm Operator). We don't provide plain manifests for topologies other than single-Pod because there are so many of them (you can basically mix and match any of the ~12 options covered in the chart documentation, and even the chart doesn't commit to handling all topologies in their entirety--many require multiple releases).

[Jimin] OK. ATM, most users are using HELM style deployment, users might not be familiar with kubectl tool deployment. I think the kubectl apply -f resource.yaml tool gives user the options to modify resources (namespace etc) on the fly - easy. Yes, we also need consider the chart compitablity.

That all said, I still don't think we gain anything by building admin API information from a Service rather than providing a URL, and introduces new problems (which aren't solved here yet):

[Jimin] Either from service, or URL, the point is to avoid hardcode configuration - localhost:8444; <IP_ADDRESS>:8001. Need also use the deployment configuration if there is .

Using a Service name/namespace doesn't remove the requirement to indicate where the Service resides when it's not local (you're providing namespace/svc-name instead of K8S DNS svc-name.namespace for the URL hostname).

[Jimin] We can use svc-name.namespace if the Admin is deployed from a cloud provider with valid HostName as external IP. Thats a valid point - both IP and HostName.  Will change accordingly.

Using a Service requires a code solution for determining the protocol and appropriate port, which are currently encoded directly in the URL. This would likely require additional constraints on the Service (we'd need a known name scheme for the HTTP and HTTPS admin ports).
[Jimin] Yes, we need the function ConfigService to discover what protocol is supported, and thus use it accordingly.

Using a Service is not compatible with the localhost admin API approach, which we want to support for its simple security model.
Backwards compatibility with the existing URL flag requires that we add code to negotiate between the two options.

[Jimin] we do provide well-defined compatibility https://github.com/Kong/kubernetes-ingress-controller/pull/1487/files#diff-777c5b378220515f6b692537382429104081d22a761062c7e2f0919e6c0d1757R221
If  in-cluster deployment does not specify any configuration (very likely use the one POD topology), the default localhost will be maintained.

IMO we'd only want to add the Service option if we had some functionality that required interactions with the Kubernetes API (e.g. we want to get endpoint information or need to edit its metadata for some reason), and I don't think we have any such functionality proposed. Between that and the other points above, I'd recommend we close this and continue the manifest changes separately in #1500 and other issues attached to #1256.
[Jimin] I think this PR and #1500 provides different solutions to different use cases which direct us to k8s standardization.  I would suggest to de-duplication and merge them accordingly.

Had offline discussion with  @mflendrich, also @rainest's input  - users get used to helm charts for deployment mainly ATM.
We'd better fix helm charts deploying proxy and controller separately, and use this yaml deployment as a backup for who get used to kubectl tool and our developer folks.
Change the PR to WIP.

unblock controller manager in cluster deployment with appropriate configuration which is illustrated in the yaml and readme file.

I was trying to understand what issue we had there though--if there is some error that appears, we'd want to understand why it occurs to ensure we're adding a fix. I wasn't aware of any, as when I test the controller 2.0.0-alpha.1 image with the current chart and the all-in-one manifests we have in https://github.com/Kong/kubernetes-ingress-controller/tree/main/deploy/single it does deploy successfully. I am aware of issues with the RBAC config and lack of UDPIngress in the existing examples, but I don't think they cause failures (we just can't update finalizers and have to disable UDPIngress), and we planned to update that elsewhere (#1256 and Kong/charts#364). The rest of the manifests that we had for 1.x do still work with 2.x.

[Jimin] @rainest here is the answer to the question "what issue we had there", update 1.3.x all-in-one as a base
https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/master/deploy/single/all-in-one-dbless.yaml
or using  https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/e1846684cc23ae5d7530fcb16f4545773908ccc5/deploy/single/all-in-one-postgres.yaml
w/ updating udpingress (CRD, and updating following

apiGroups:

configuration.konghq.com
resources:
udpingresses/status
verbs:
update)

deployment throws following following error messages
time="2021-07-09T01:19:57Z" level=error msg="Reconciler error" error="secrets "default-token-m5gft" is forbidden: User "system:serviceaccount:kong:kong-serviceaccount" cannot update resource "secrets" in API group "" in the namespace "metallb-system"" logger=controller-runtime.manager.controller.secret name=default-token-m5gft namespace=metallb-system reconciler group= reconciler kind=Secret

The points of the Kong Admin API URL is to remove hardcode ip address (publishStatusAddress) and leverage environment variable retrieving service information. Understand the previous configuration due to controller and proxy are in the same namespace and same pods.

This sounds related to the work in #1451, correct? fe24a71 should have already given us what we need there. publishStatusAddress should remain: it serves as a user override for Ingress status addresses when they know there network topology doesn't let the controller effectively determine the correct address information (similar to the Service clusterIP setting), as an alternative to --publish-service.
That doesn't have any interaction with the admin API, as we're only concerned with the proxy for Ingress status. We shouldn't need any additional admin API logic--while building configuration from a Service instead is viable, it doesn't really give us anything obvious over requesting a URL instead (since we don't need to look up endpoints or obtain other detailed information about the Service), and our documentation all already refers to the existing --kong-admin-url flag.

unblock controller manager in cluster deployment with appropriate configuration which is illustrated in the yaml and readme file.

I was trying to understand what issue we had there though--if there is some error that appears, we'd want to understand why it occurs to ensure we're adding a fix. I wasn't aware of any, as when I test the controller 2.0.0-alpha.1 image with the current chart and the all-in-one manifests we have in https://github.com/Kong/kubernetes-ingress-controller/tree/main/deploy/single it does deploy successfully. I am aware of issues with the RBAC config and lack of UDPIngress in the existing examples, but I don't think they cause failures (we just can't update finalizers and have to disable UDPIngress), and we planned to update that elsewhere (#1256 and Kong/charts#364). The rest of the manifests that we had for 1.x do still work with 2.x.

The points of the Kong Admin API URL is to remove hardcode ip address (publishStatusAddress) and leverage environment variable retrieving service information. Understand the previous configuration due to controller and proxy are in the same namespace and same pods.

This sounds related to the work in #1451, correct? fe24a71 should have already given us what we need there. publishStatusAddress should remain: it serves as a user override for Ingress status addresses when they know there network topology doesn't let the controller effectively determine the correct address information (similar to the Service clusterIP setting), as an alternative to --publish-service.
That doesn't have any interaction with the admin API, as we're only concerned with the proxy for Ingress status. We shouldn't need any additional admin API logic--while building configuration from a Service instead is viable, it doesn't really give us anything obvious over requesting a URL instead (since we don't need to look up endpoints or obtain other detailed information about the Service), and our documentation all already refers to the existing --kong-admin-url flag.

Agree that both publish-service and PublicStatusAddress should retain as it is, which was covered by #1509 and #1451. It is unrelated to the KIC individual deployment yaml
KIC does need KongAdminAPI for configuration communication,
https://github.com/Kong/kubernetes-ingress-controller/blob/main/railgun/manager/run.go#L96
Current configuration way https://github.com/Kong/kubernetes-ingress-controller/pull/1500/files#L90 assumes all modules are in the same node and having static port (8444), this will break if we deploy controller and proxy separately. The function retrieve Admin ip and port through namespace and name configuration. https://github.com/Kong/kubernetes-ingress-controller/pull/1487/files#diff-786a1651aa544e8c2f84a32b474758ecb0f8e6c5d9d745b5f643d3d786bc57c4R152

tl;dr the permissions failures are because the controller wanted to add finalizers, and couldn't after I removed resource-wide edit permissions. There are subresource permissions that we could add instead to fix this, but we no longer need them following the removal of finalizers in #1522.
@ccfishk are you still seeing deploy failures with latest next? For testing/pending completion of #1256 1.x manifests should work with:
kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/next/railgun/config/crd/bases/configuration.konghq.com_udpingresses.yaml
sed -e "s/name: manager-role/name: kong-ingress-clusterrole/g" railgun/config/rbac/role.yaml | kubectl apply -f -

These errors:
time="2021-07-09T01:19:57Z" level=error msg="Reconciler error" error="secrets "default-token-m5gft" is forbidden: User "system:serviceaccount:kong:kong-serviceaccount" cannot update resource "secrets" in API group "" in the namespace "metallb-system"" logger=controller-runtime.manager.controller.secret name=default-token-m5gft namespace=metallb-system reconciler group= reconciler kind=Secret

come from adding finalizers to resources, which is a metadata update. We originally had broader permissions on resources, and I reduced permissions on most resources to get,list,watch (read-only) earlier to try and match 1.x (for lack of any known reason that we now needed edit permissions also): https://github.com/Kong/kubernetes-ingress-controller/blob/2.0.0-alpha.2/railgun/hack/generators/controllers/networking/main.go#L398-L400
We no longer will need those since we've removed finalizers in https://github.com/Kong/kubernetes-ingress-controller/pull/1522
There's a bit of (possible) inaccuracy in the kubebuilder examples, where https://book.kubebuilder.io/reference/using-finalizers.html indicates you should have full edit permissions on the resource for finalizers, but it looks like those aren't necessary. You can handle the finalizer RBAC needs with update,create,delete on the <resource>/finalizer subresource instead of the parent resource.
If we were to continue using them, we'd want to add that to the kubebuilder RBAC tags in the railgun/hack/generators/controllers/networking/main.go template. We wouldn't want to modify the deployment manifests directly, as the next run of the manifest generator (make generate followed by make manifests) would wipe that out, and wouldn't want to use the permissions proposed here (those would grant the controller superuser rights; we want it to only have the permissions it actually needs).

tl;dr the permissions failures are because the controller wanted to add finalizers, and couldn't after I removed resource-wide edit permissions. There are subresource permissions that we could add instead to fix this, but we no longer need them following the removal of finalizers in #1522.
@ccfishk are you still seeing deploy failures with latest next? For testing/pending completion of #1256 1.x manifests should work with:
kubectl apply -f https://raw.githubusercontent.com/Kong/kubernetes-ingress-controller/next/railgun/config/crd/bases/configuration.konghq.com_udpingresses.yaml
sed -e "s/name: manager-role/name: kong-ingress-clusterrole/g" railgun/config/rbac/role.yaml | kubectl apply -f -

These errors:
time="2021-07-09T01:19:57Z" level=error msg="Reconciler error" error="secrets "default-token-m5gft" is forbidden: User "system:serviceaccount:kong:kong-serviceaccount" cannot update resource "secrets" in API group "" in the namespace "metallb-system"" logger=controller-runtime.manager.controller.secret name=default-token-m5gft namespace=metallb-system reconciler group= reconciler kind=Secret

come from adding finalizers to resources, which is a metadata update. We originally had broader permissions on resources, and I reduced permissions on most resources to get,list,watch (read-only) earlier to try and match 1.x (for lack of any known reason that we now needed edit permissions also): https://github.com/Kong/kubernetes-ingress-controller/blob/2.0.0-alpha.2/railgun/hack/generators/controllers/networking/main.go#L398-L400

[Jimin] AFAIK, finalizer only applied for resource deletion, we apply finalizer for KIC ingress we created. If your operation include all namespaces/any resources, might be associated to this error.  Not sure why only got this complain at that moment, would like to take one more look/dig into my case.

We no longer will need those since we've removed finalizers in #1522
There's a bit of (possible) inaccuracy in the kubebuilder examples, where https://book.kubebuilder.io/reference/using-finalizers.html indicates you should have full edit permissions on the resource for finalizers, but it looks like those aren't necessary. You can handle the finalizer RBAC needs with update,create,delete on the <resource>/finalizer subresource instead of the parent resource.
If we were to continue using them, we'd want to add that to the kubebuilder RBAC tags in the railgun/hack/generators/controllers/networking/main.go template. We wouldn't want to modify the deployment manifests directly, as the next run of the manifest generator (make generate followed by make manifests) would wipe that out, and wouldn't want to use the permissions proposed here (those would grant the controller superuser rights; we want it to only have the permissions it actually needs).
[Jimin] aware of the permission scope - it is not Kong's cluster, user's cluster. Agree restrict permission is good. thansk.

https://github.com/Kong/kubernetes-ingress-controller/blob/2.0.0-alpha.2/railgun/hack/generators/controllers/networking/main.go#L398-L400

Not sure why only got this complain at that moment, would like to take one more look/dig into my case.

Some of the errors from controller-gen reconciler code are unfortunately rather opaque--they tell you they're trying to edit an object and failed, but not the specific edit and/or where in the code it logged the error.
Don't actually recall how I realized the finalizers were the culprit last week. I observed that adding
- apiGroups:
  - whatever
  resources:
  - whatever/finalizers
  verbs:
  - update
  - create
  - delete

to roles cleared it, but forget why I thought to do that--I think it was reading through the generated reconciler and seeing which successful logs appeared and checking what client actions it took after. Doing that is rather tedious.

Close this atm according to discussion last Friday.


add QR codes for links in display

since it's much simpler

decided to go in a different direction


Incorrect handling of TSV result set format

For the TSV result set format the following expressions are handled incorrectly:

Variable names are not parsed correctly.  Specifically, the first character (i.e., ?) should be skipped.
IRI terms are not parsed correctly.  Specifically, the first (i.e., <) and last (i.e., >) characters should be skipped.

Example of a TSV result set serialization:
?s	?p	?o
<http://localhost/misc/UnknownDocument>	<http://www.w3.org/1999/02/22-rdf-syntax-ns#type>	<http://xmlns.com/foaf/0.1/Document>

hmm, YASR doesnt support TSV. Did you request TSV by setting the accept header? In that case, it's the SPARQL endpoint that screws this up ;)

aahh, misunderstood, thought this was about exporting to TSV (which we don't support). Instead, it's about parsing TSV responses from endpoints.


Prevent poly color path when translating batches than are non-poly

A previous fix for poly colors (#43498) had caused a regression in the rect behaviour, this PR re-enables proper translation of rect batches.
Fixes #43673
Fixes #43677

Thanks!


Add localization support for button captions of the thumbnail viewer

The captions of the thumbnail viewer are not localized by leftArrowTitle and rightArrowTitle. I found the following 2 lines of code for further reference:

https://github.com/jossmac/react-images/blob/1241e81d877655cab78aa4ea3edb4e2bc258d260/src/components/PaginatedThumbnails.js#L107
https://github.com/jossmac/react-images/blob/1241e81d877655cab78aa4ea3edb4e2bc258d260/src/components/PaginatedThumbnails.js#L124

@kripod v1 will allow consumers to replace any component, please see #199

Closing this for now, please comment if you'd like it reopened.


Register 0.2.18

@JuliaRegistrator register
Ready for new Mods.

Registration pull request created: JuliaRegistries/General/96365
Tip: Release Notes
Did you know you can add release notes too? Just add markdown formatted text underneath the comment after the text
"Release notes:" and it will be added to the registry PR, and if TagBot is installed it will also be added to the
release that TagBot creates. i.e.
@JuliaRegistrator register

Release notes:

## Breaking changes

- blah

To add them here just re-invoke and the PR will be updated.
Tagging
After the above pull request is merged, it is recommended that a tag is created on this repository for the registered package version.
This will be done automatically if the Julia TagBot GitHub Action is installed, or can be done manually through the github interface, or via:
git tag -a v0.2.17 -m "<description of version>" e9660b0cf8ce787d987260e17212ad62e5db360c
git push origin v0.2.17


Web interface for SearchGPT

I have been enjoying this application for an hour and I though it would be fitting to run SearchGPT as a standalone web app where someone just places their API ID in one form, then write their prompts. Great for researchers and code noobs!

Done! https://searchgpt.perrysahnow.com (Note it might not be up at the time of posting, I'm having some issues getting my websocket demo to run on the server hosting I have access to, mainly due to issues with chromedriver on a low performance VPS)
Source is at: https://github.com/perrys25/searchgpt-demo


Allow setting up a client-server environment using a ROS1 alike environment variable

Now a simple client-server discovery strategy using UDP can be specified by setting an environment variable
ROS2_AUTO_CLIENT_SERVER or FASTDDS_AUTO_CLIENT_SERVER to IPAddress:port where the port is optional (if not given a default one of 11311 is used).
For example <IP_ADDRESS>, <IP_ADDRESS>:3253 or <IP_ADDRESS> are well formed.
If both set, Ros variable has precedence over FastDDS one.
The first participant with an interface that matches the IPAddress will try to reserve the UDP port given. If not able
to reserved it, a server presence is assumed and the participant becames a client.
If the participant attributes specifies a different mechanism from simple discovery the ROS_AUTO_CLIENT_SERVER and FASTDDS_AUTO_CLIENT_SERVER are ignored.
Note that if the server participant is killed and no new participant is created the clients will remain orphan. One
workaround is make the Domain create a new server whenever the server is killed but this is open to discussion.

Build status:

Linux
Mac
Windows

Build status:

Linux
Mac
Windows


Hosting ignore rules missing the functions

firebase.json is missing the rule to ignore functions for hosting:
https://codelabs.developers.google.com/codelabs/firebase-web/#11
  "hosting": {
    "public": "./",
    "ignore": [
      "firebase.json",
      "database-rules.json",
      "storage.rules"
    ]
  }

Whereas the actual file has it:
https://github.com/firebase/friendlychat-web/blob/master/web/firebase.json#L5-L7.json
The risk is that people overwrite firebase.json with code from the doc and end up pushing functions to cloud storage. It's OK for a test project, but if they take the bad habit and start pushing their source (eg authentication functions), in production that might be problematic.

Just added it! Thanks for pointing this out @maxcorbeau


build error when installing via luarocks

% luarocks install sqlite
Installing https://luarocks.org/sqlite-v1.0.0-0.src.rock

sqlite v1.0.0-0 depends on luv (1.41.1-0 installed)

Error: Build error: Failed installing /lua/sqlite/tbl/cache.lua in /home/raven/.local/lib/luarocks/rocks-5.3/sqlite/v1.0.0-0/lua/sqlite/tbl/cache.lua: /lua/sqlite/tbl/cache.lua: No such file or directory

Indeed it's a bug, I got similar fail cp: cannot stat '/lua/sqlite/utils.lua': No such file or directory I'm looking into it

@les-citrons thanks for reporting. It should now be fixed. Try to rerun the command.
I'm going to keep this open until I fix the issue for future release.

ah thanks! it does work now!


Ngaski doc edits

Removal of all hyperledger instances.  @angrbrd @binhn - I updated some of the API section in Prot Spec, but there are paths, etc... that still need your attention.

Signed-off-by: Nick Gaski -<EMAIL_ADDRESS>

@nickgaski please rework to remove the merge conflict


Add unit test to cover force preferred replica election

#14 highlighted that we have no coverage of scenarios when preferred replica is changed.

Resolved as part of #14 unit tests.