Enhancement: Enhancement template for new GitHub issues

I think it would be nice to have an extra template within our issues. One for creating new enhancement suggestions.
Here all the titles and Enhancement content within the issues list would be more uniform and could possibly be automatically labeled.
What do you think @.maintainers? 😄

Sounds like a solid idea @Jwaegebaert!

Nice suggestion @Jwaegebaert, we should look to standardise where it makes sense.
Do you have a suggestion as to what you would like to include in the template or a particular format?

@garrytrinder in broad terms, I was thinking of the following subjects to include within the template.

Version

Here they can specify the current CLI for M365 version they are using.

Desired enhancement

This can be used to give more context about the requested functionality

Options

This wouldn't be a required part, but here they can define the additional options that are required to fulfilll the enchancement.

Examples

Similar to the options. When new options are suggested, it would be nice to add a few related examples of how they can be used.

Great suggestion! Maybe we could also include a section called Affected command(s)?

The main challenge with enhancements is that they vary a lot. When we come up with a template, let's see if we can apply it to some of the enhancements that we already have without replacing/removing big parts of it.

The main challenge with enhancements is that they vary a lot.

Fair point, maybe it would be beter to change the wording to e.g. Enhance command. This could then narrow it a bit more for the user and allow us to create a template with more targeted questions/forms.

Enhancements aren't just for commands though. We can have enhancements that affect the runtime or the docs.

We can have enhancements that affect the runtime or the docs.

That's true. The reason I'm giving the example of Enhance command is mainly to narrow down the enhancement template we initially had. With the example referencing the command part of the CLI, we could then also create templates for runtime enhancements and/or documentation enhancements. This way we can add several new templates but each one of them can have specific questions related towards the topic.

People can always open a blank issue so there's that and we're not taking that option away indeed. If we can have a meaningful template for enhancing existing commands, then we should definitely do it.

People can always open a blank issue

That's indeed the easiest way to create an issue. Maybe this suggestion will make it a bit to complex for users when they want to suggest enhancements.

Maybe could create a template called Command enhancement. For other enhancements, they should open a blank issue because it will get too wide to fit into a template. Command enhancements are the most used type of enhancement I think.

Before we commit to this, could we share here an example of what would go in the template? It would make it clearer what we're looking at and help us decide if it's something we want to do or if the value add is too little to be meaningful.

Are we still interested in doing this? If not, let's close it to avoid keeping stale issues around.

Since it is difficult to agree on a template, it can be closed from me


Demonstrate the multiple choice element

Demonstrate the multiple choice element.
Sample Project ID: 975bf280-fd91-488c-994c-2f04416e5ee3
Content Type: Coffee
Element Name: Processing
Internal reference: DEL-680

Coffee processing has been replaced by taxonomy.
Multiple choice element is demonstrated on Hosted video -> video provider. E.g. https://github.com/Kentico/cloud-sample-app-react/blob/85fdcdb2f0f89be89a3ca09f2700b2b47d6b4724/src/Models/HostedVideo.js#L9


HEVC PPS parser

Good day!
This PR introduce Rec. ITU-T H.265 v5 (02/2018) compliant PPS parser for HEVC.
I decided to use non-uint types where standard set limits for values (this explicitly commented in code).
All 'Minus' values is kept as is. Unclear decisions and calculations commented with references to standard.
For now i copied your function ceilLog2. Maybe it should be placed in some separate utility packet?
Unfortunately i don't have variety of test data to check any of implemented extensions.

Hi @k-danil, Thanks for the PR. There is a lot of details in the HEVC PPS structure so I'm glad that you took the time to implement them. It will take me a little time to read through this PR and compare with the standard. I'll be back once I've done that.

Good day!
Some notices about this PR:

I took little to none efforts to optimise parser. Mostly it's just reference realisation from the standard.
I save every described data even 'reserved'.  My personal goal is preparing data to parse the HEVC slice header, but other field may be useful too someone who wants to write analyser.
parseColourMappingOctants() looks ugly on part of saving data to the map and i'm not sure how to do it better.
Code didn't validate the SPS, just parse.
I check on the reader errors in multiple places, but didn't sure about returning incomplete data to end user.
I take some notices from https://github.com/kaltura/nginx-vod-module/blob/master/vod/hevc_parser.c . All taken details checked with the standard before implementing.

PS Next PR will be on slice header parser ;)


Add (binary) field to (prover) stanzas

This mostly exposes the existing binary field from the Prover.t through the stanzas. If not provided, the binary field will be inferred from the cmd as before.
This is useful to define "template" provers that define a shared set of options in the cmd field and can be reused with inherits to target different versions of the same prover with these options.

Merci :)


feat: Copy method name from timeline cell

Is your feature request related to a problem?
I would like to be able to copy the method name from the tooltip in the timeline so that I can paste it into another document/or slack thread when discussing it.
Describe the solution you'd like
Right click cell in the timeline and see a context menu to copy the method name.
Describe alternatives you've considered
Navigate to the call stack and copy from there. (At present tho' if you copy from there you get the whole tree not just the text highlighted.
Additional context
Slack me if you want to discuss. :)

@tscottcertinia
You are right copy from call tree needs work, there is a ticket on the DB view to sort it out in general.
You can highlight text BUT do not release the mouse key then do ctrl+c, that will copy text from the row.
What is causing the issue is that the highlight is cleared on mouse up.
Copy from timeline is a good idea. We have a feature to add method names to the events on the timeline too.


Add Kyverno policy and audit results to the discovered policies table

Ref: https://issues.redhat.com/browse/ACM-15244

/cc @mprahl


Make sure the nametag appear in the bottom right corner of user foreground

Currently, the nametag seems to be floating:

But per design, it should appear in the bottom right corner:

It seems that the name tag moves when someone turn off and turn on the video again.

@kexinF Can you look into this? I think the change should happen inside functiondrawEverythingToImage in  lib/draw_badge_api.ts file.
I actually sometimes have trouble seeing the nametag badge at all, and will only see it after turning off and turning on my video (it will appear in the middle). I suspect the original placement is outside my window size. Can you make the position and size of the nametag relative to the user's window size?

Some other developers also had similar problem:
https://devforum.zoom.us/t/how-to-get-the-actual-size-of-the-video-rendered-in-canvas-because-i-found-that-the-size-specified-in-rendervideo-is-not-the-actual-rendered-width-and-height/54258/4
https://devforum.zoom.us/t/how-to-get-user-users-screen-size-to-draw-things/87912/6
I tried to detect the camera size using getmedia: https://developer.mozilla.org/en-US/docs/Web/API/MediaDevices/getUserMedia
It worked in the browser, but I don't think zoom app browser supports it.
Let's discuss other possible solutions in the meeting. @Shaomei

This is fixed by PR #90


Add builder OCI layout build context

Description
This change adds building images with OCI layout build contexts.
Testing

Added unit tests

Negative test cases

Added integration test (Linux only)

Test requires build functionality which excludes Windows platform testing.

Additional references

https://docs.docker.com/reference/cli/docker/buildx/build/#source-oci-layout
https://github.com/opencontainers/image-spec/blob/main/image-layout.md
https://docs.docker.com/build/exporters/oci-docker/
https://docs.docker.com/build/builders/drivers/docker-container/

Looks like my test needs a little more bake time. Looking into it now.

Got it. Just forgot to tag the image before running. Test now passes on nerdctl and Docker.

@austinvazquez left a few comments / nits, but otherwise looks fine.

Thanks @apostasie, taking a look now. :)


VIDEO - Stuck On "A config file was not found. Would you like to create one now?"

Unable to successfully run example "cheat tar" after installing on Windows 10.
Problem: When I run "cheat tar" it keeps returning "A config file was not found. Would you like to create one now?"
Here is a video I made where I show the exact steps I took while trying to install cheat on my Windows 10 machine.
Any help?

Hi, @parkershamblin
Thanks for the bug report.
I haven't meaningfully used Windows since the XP days, so I can't help personally, unfortunately. (I still need to assemble a Win10 machine for testing.) That being the case, I'll pin this ticket for visibility. Hopefully someone from the community will be able to help you out.

Hi, @chrisallenlane
I appreciate the help. :)
Looking forward to using your project once someone with a windows machine finds this issue.

Looking forward to using your project once someone with a windows machine finds this issue.

Hi @parkershamblin, @chrisallenlane,
I am the least likely person to submit a proper PR for a Windows application, and this is a workaround for git-bash shell, not Powershell or CMD.exe.
The company I work for just released production firmware for the Gateway/Routers we manufacture that replace MS Domain Controllers / Active Directory with all Open Source Software (Samba4, BIND, etc...) on an OpenWRT platform. This said, I was handed my first Windows laptop since Windows 98 to support our customers when they have AD issues.
I installed the Scoop package manager and during the install 7zip and Git are the first two packages that you install.  I noticed that  git-bash.exe  comes with 2.27.0.windows.1 - https://github.com/ScoopInstaller/Main/blob/master/bucket/git.json and in my attempt to find a comfortable workflow in a bash shell on Windows, I too saw the same error as you this morning. Here is how I quickly remediated the issue and am using cheat in my git-bash.exe shell.
cp cheat-windows-amd64.exe /usr/bin/
echo alias cheat='/usr/bin/cheat-windows-amd64.exe' >> $HOME/.bashrc
source $HOME/.bashrc
mkdir -p $HOME/.config/cheat && cheat --init > $HOME/.config/cheat/conf.yml

This is where I saw the error. Here are my steps to joy:
echo export CHEAT_CONFIG_PATH="$HOME/.config/cheat/conf.yml" >> $HOME/.bashrc
echo export CHEAT_PATH="$HOME/AppData/Roaming/cheat/cheatsheets/" >> $HOME/.bashrc
mkdir -p $HOME/AppData/Roaming/cheat/cheatsheets/personal
git clone https://github.com/cheat/cheatsheets.git $HOME/AppData/Roaming/cheat/cheatsheets/community
source $HOME/.bashrc

$ cheat
Usage:
  cheat [options] [<cheatsheet>]

Options:
  --init                  Write a default config file to stdout
  -c --colorize           Colorize output
  -d --directories        List cheatsheet directories
  -e --edit=<cheatsheet>  Edit <cheatsheet>
  -l --list               List cheatsheets
  -p --path=<name>        Return only sheets found on path <name>
  -r --regex              Treat search <phrase> as a regex
  -s --search=<phrase>    Search cheatsheets for <phrase>
  -t --tag=<tag>          Return only sheets matching <tag>
  -T --tags               List all tags in use
  -v --version            Print the version number
  --rm=<cheatsheet>       Remove (delete) <cheatsheet>

Examples:

  To initialize a config file:
    mkdir -p ~/.config/cheat && cheat --init > ~/.config/cheat/conf.yml

  To view the tar cheatsheet:
    cheat tar

  To edit (or create) the foo cheatsheet:
    cheat -e foo

  To edit (or create) the foo/bar cheatsheet on the "work" cheatpath:
    cheat -p work -e foo/bar

  To view all cheatsheet directories:
    cheat -d

  To list all available cheatsheets:
    cheat -l

  To list all cheatsheets whose titles match "apt":
    cheat -l apt

  To list all tags in use:
    cheat -T

  To list available cheatsheets that are tagged as "personal":
    cheat -l -t personal

  To search for "ssh" among all cheatsheets, and colorize matches:
    cheat -c -s ssh

  To search (by regex) for cheatsheets that contain an IP address:
    cheat -c -r -s '(?:[0-9]{1,3}\.){3}[0-9]{1,3}'

  To remove (delete) the foo/bar cheatsheet:
    cheat --rm foo/bar

@Benjamin-Connelly, I'm unable to test this, but thank you for the information :slightly_smiling_face:

Hi,
I'm not a GO expert, but could it be a line delimiter issue on Windows (\n vs. \r\n)?
Please have a look at the Prompt function in the installer package:
https://github.com/cheat/cheat/blob/master/internal/installer/prompt.go
reader.ReadString('\n') is used there, but then later
strings.TrimRight(ans, "\n") strips only the \n , but not the '\r' on Windows.
Therefore, false is always returned and no config file created.
strings.TrimRight(ans, "\r\n") should be used instead.
Just a guess...
What do you think?

@hbrands, while this is a possibility, I don't think this is the issue, simply because (to my knowledge) others are using cheat successfully on Windows, and this would, presumably, prevent them from doing so.
That said, to my embarrassment, I am still personally unable to test cheat on Windows. I've been relying entirely on the community to do this so far.
I haven't had much time to work on this project recently, because I've been rebuilding most of my computers in my (limited) free time. I think I'm about two weeks away from completing that effort. Fortunately, when that's complete, I'll finally have a Windows PC available for testing, and then will be able to take a deep-dive into this issue.
Once I have that lab machine available, I'll test your hypothesis. While my hunch is that the root cause lies elsewhere, line-endings are worth a look. They are indeed able to cause problems, and I'm not handling them in a particularly enlightened manner so far.

@chrisallenlane Thanks for your answer. Here is a small example that demontrates the problem on my maschine (Windows 10):
package main

import (
	"bufio"
	"fmt"
	"os"
	"strings"
)

func main() {

	// initialize a line reader
	reader := bufio.NewReader(os.Stdin)

	// display the prompt
	fmt.Print(fmt.Sprintf("%s: ", "(y/n) ?"))

	// read the answer
	ans, err := reader.ReadString('\n')
	if err != nil {
		return
	}

	// normalize the answer
	ans1 := strings.ToLower(strings.TrimRight(ans, "\n"))
	fmt.Println("First try:")
	switch ans1 {
	case "y":
		fmt.Println("Good! - Yes!")
	default:
		fmt.Println("Bad!")
	}

	// normalize the answer
	ans2 := strings.ToLower(strings.TrimRight(ans, "\r\n"))
	fmt.Println("Second try:")
	switch ans2 {
	case "y":
		fmt.Println("Good! - Yes!")
	default:
		fmt.Println("Bad!")
	}
}

The first try always outputs "Bad!" even if I type in "y".
The second try outputs "Good! - Yes!" correctly when I type in "y".
Is there a simple way to build cheat on a windows machine? Then I could try that out.
But I'm pretty sure now that this is the issue.

I just published cheat 4.2.4, which greatly improves Windows support. Please upgrade to that version and try again.
I'll optimistically close this ticket as resolved now, but feel free to re-open it if upgrading doesn't solve your problem.
Thanks.


JIRA Fix participate() so it doesn't create duplicates in different buckets

The previous code did a get_or_create() for the unique_attr, experiment_name and bucket fields.  So if get_or_create() was called a second time with the same unique_attr and experiment_name, but a different bucket value then it would create a new record.

LGTM :+1:

LGTM


Supporting mount.fuse for container rootfs

Hello, I'd like to use a read-only FUSE as the lowerdir to a overlayfs container rootfs. I wanted to discuss if containerd can support it generically, and thoughts about architecture; like who manages the lifecycle of the FUSE server.
Context
Containerd snapshotters do not actually mount(2), but instead produce a list of serialized mount.Mount:
https://github.com/containerd/containerd/blob/v1.2.7/mount/mount.go#L19-L30
The serialized mounts are mounted in two places:

Unpacking layers for snapshots in containerd:

https://github.com/containerd/containerd/blob/v1.2.7/diff/apply/apply.go#L75

Preparing rootfs in the shim:

https://github.com/containerd/containerd/blob/v1.2.7/runtime/v2/runc/service.go#L276-L285

(*mount.Mount).Mount on linux calls unix.Mount which calls syscall mount(2): https://github.com/containerd/containerd/blob/v1.2.7/mount/mount_linux.go#L290
Design
I got a hint from the design notes on FUSE mounts here: https://github.com/containerd/containerd/blob/v1.2.7/design/mounts.md#structure

We may want to further parameterize this to support mounts with various helpers, such as mount.fuse, but this is out of scope, for now.

I've seen a cvmfs snapshotter attempt that relies on cvmfs being mounted somewhere else, and then the snapshotter simply bind mounts it as the lowerdir of a forked overlay snapshotter.
I wanted to take another approach guided by the design note. Essentially we need to serialize the mount(2) arguments to mount a FUSE filesystem. So I made a POC that mounts a FUSE fs using containerd's serialized mounts here: https://github.com/hinshun/hellofs
	//  It's basically a `fusermount` port to golang.

	f, err := os.OpenFile("/dev/fuse", os.O_RDWR, 0666)
	if err != nil {
		return 0, err
	}
	fd = int(f.Fd())

	m := mount.Mount{
		Type:   fmt.Sprintf("fuse.%s", opts.Name),
		Source: opts.FsName,
		Options: []string{
			"nosuid",
			"nodev",
			fmt.Sprintf("fd=%d", fd),
			fmt.Sprintf("rootmode=%#o", syscall.S_IFDIR),
			fmt.Sprintf("user_id=%s", user.Uid),
			fmt.Sprintf("group_id=%s", user.Gid),
		},
	}

I've explained how FUSE works here:

https://github.com/hinshun/hellofs#fuse-overview

There are two open problems I'm encountering atm:

Who should open the control fd to /dev/fuse?
Who runs the FUSE daemon process that talks to the control fd?

Idea 1: FUSE server in snapshotter

Containerd manages lifecycle of FUSE server and /dev/fuse fd

Implement a generic FUSE snapshotter (somehow mixable with other snapshotters like overlay) that for any active snapshots:

Opens /dev/fuse to get control FD
Runs the FUSE server daemonization wrapper via /sbin/mount.<subtype> like how mount(8) does it
Returns the serialized FUSE mounts

It has the advantage that multiple containers using the same FUSE mounts are backed by the same FUSE server. But if containerd dies, then the shimmed containers won't have a rootfs anymore.
Idea 2: FUSE server in shim

Container shim manages lifecycle of FUSE server and /dev/fuse fd

Implement a generic FUSE snapshotter that for any snapshot:

Returns the serialized FUSE mounts without the fd=<control fd> option.

Implement/modify the shim such that:

If the mount type does not begin with prefix fuse. then:
a. Mount as usual
Else
a. Opens /dev/fuse to get control FD
b. Runs the FUSE server daemonization wrapper via /sbin/mount.<subtype> like how mount(8) does it
c. Adds option fd=<control fd> to the serialized FUSE mount.
c. Mount as usual

It has the advantage that if containerd dies, the shimmed container is self-contained and continues to work. The lifecycle of the container and its FUSE rootfs is the same. However, multiple containers using the same snapshot all have their own FUSE server.
Questions

Should FUSE lifecycle be managed:
a. Outside of containerd
b. By containerd FUSE snapshotter
c. By shim as a kind of a sidecar

Should the serialized mount.Mount be:
a. A bind mount from an already mounted FUSE
b. An actual fuse type mount

Should we have a Mounter plugin? Then implementers can control mounting semantics.

We have proxy snapshotters that you can implement your own snapshotter to do this.
You can see the documentation here: https://github.com/containerd/containerd/blob/ca714847936372d257dddbbabf79f9131da923d7/PLUGINS.md#proxy-plugins

This is similar to https://github.com/containerd/containerd/issues/2968.

Thank you for the references.
I'm happy to go off and implement a proxy snapshotter on my own, but I read this from your design documents: https://github.com/containerd/containerd/blob/v1.2.7/design/mounts.md#structure

We may want to further parameterize this to support mounts with various helpers, such as mount.fuse, but this is out of scope, for now.

Which led to me starting a conversation around containerd supporting mounts with helpers for mount.fuse. Curious if you had any additional thoughts on the topic?

It has the advantage that multiple containers using the same FUSE mounts are backed by the same FUSE server. But if containerd dies, then the shimmed containers won't have a rootfs anymore.

@hinshun
this should be able to mitigate by reparent your fuse daemon to pid1 , so that restart or shutdown containerd will not have affect with rootfs

By using a proxy snapshotter you could run it as a separate systemd service, outside of the lifecycle of containerd to ensure that fuse stays running during a restart/upgrade of containerd.  I believe it is the most robust way to handle something like this.


feat: add physical devices support

Description

Compliments the pr on minisim which allows it to display physical devices alongside the already virtual devices.
Fixes commands not working because wrong id is passed. Property ID does not exist on device, it is identifier. Currently pasting on android doesnt work on android becuase of this

Screencast
https://github.com/user-attachments/assets/ed13113f-7bf6-4251-a27e-ba3275f3a282
Checklist

[x] I read the extension guidelines
[x] I read the documentation about publishing
[x] I ran npm run build and tested this distribution build in Raycast
[x] I checked that files in the assets folder are used by the extension itself
[x] I checked that assets used by the README are placed outside of the metadata folder

@okwasniewski does this require a major version increment because it includes breaking change?

@itsramiel Yeah, I think we need to release MiniSim 0.9.0 and add a check in Raycast to advise users to update if they are running a lower version.

Could you add an entry in the CHANGELOG.md file? Here's our guidelines about that: Version History.

@pernielsentikaer update changelog. Does the format look right to you?

@okwasniewski I checked other extensions and it seems like they have no version in their package.json and the versioning docs also has no mention of the version field in the package.json. Do we need it?
Also how would you like to handle:

add a check in Raycast to advise users to update if they are running a lower version.

You already have an error view that displays and tell the user to update to latest when an error happens. I get it when running the extension with current released minisim version:

Can we keep it like that for now or how would you like to proceed?

The changelog looks good, awaiting @okwasniewski 🙂

Oh okay I forgot I've added it. I need few more days to release new version of MiniSim.
Can we hold with this PR for a little bit longer? I will ping you once it's ready to merge

Sure 🔥


Fix example .armadactl.yaml

┆Issue is synchronized with this Jira Task by Unito

@zuqq I was thinking of removing this example structure section from armadactl as if you take a look at other command-line tools such sections are not present there basically it will look good if we can remove this and if it doesn't have any use, I also opened a PR for this but I just saw yours and thought about telling you about this


feat(KONFLUX-782): a GitHub App to react to PR comments

I've tested this PR and can confirm that this GH App successfully updates the PR comments when the Prow job:

Failed while creating the cluster
Failed while installing Konflux on the cluster
Failed while running the E2E tests on the cluster


USHIFT-957: [release-4.13] Port Getting Started instructions to use RHEL 9.2 and MicroShift 4.13

Backport of #1845
Closes USHIFT-957

/lgtm

/label jira/valid-bug


installation: Update RHEL installation script

With this instead of using Docker-EE, we are retrieving Docker
from the server repositories.
Fixes #1016
Signed-off-by: Gabriela Cervantes<EMAIL_ADDRESS>

lgtm

lgtm


Update Player Bio “brandi-1”

Automatically generated by Netlify CMS

👷 Deploy Preview for dynamic-cheesecake-5fbd8b processing.

Name
Link

🔨 Latest commit
54a509fb281df5fc8cbd6ea53fd20b6bdd1e023d

🔍 Latest deploy log
https://app.netlify.com/sites/dynamic-cheesecake-5fbd8b/deploys/632633000eb1dd0008013927


Twilio conversion to audio/x-mulaw with a sample rate of 8000 and base64 encoded

Somebody could help how can I convert PCM Int16Array to Twilio's format? I've trying for a while now but just can't get it right.

You can set the input and output audio format in the session settings to g711_ulaw and it works with twilio

Thanks, appreciate it. Did you have success setting it up with the openai-realtime-api-beta?
This is how I am updating the Realtime client session:
this.client.updateSession({
      turn_detection: { type: "server_vad" },
      input_audio_transcription: { model: "whisper-1" },
      output_audio_format: "g711_ulaw",
    });

It is successfully updated:
sessionConfig: {
    modalities: [ 'text', 'audio' ],
    instructions: 'O seu conhecimento é até 2023-10. Você é um assistente útil,  espirituoso e amigável. Aja como um humano, mas lembre-se de que você não é um humano e que não pode fazer coisas humanas no mundo real. Sua voz e personalidade devem ser calorosas e envolventes. Você deve falar em português do Brasil e não usar sotaques ou dialetos regionais, apenas a linguagem padrão. Fale rapidamente.',
    voice: 'alloy',
    input_audio_format: 'pcm16',
    output_audio_format: 'g711_ulaw',
    input_audio_transcription: { model: 'whisper-1' },
    turn_detection: { type: 'server_vad' },
    tools: [],
    tool_choice: 'auto',
    temperature: 0.8,
    max_response_output_tokens: 4096
  }

But the output is still returning PCM Int16Array:
event.item['formatted']['audio']:  Int16Array(12200) [
      -1, 32511,   -130,     -1,  32382,  32382,  32382,  32382,
   32382, 32382,  32125,  32125,  32125,  32125,  32125,  32125,
   32382,  -130,     -1,     -1,     -1,  32382,  32126,  32125,
   31868, 31868,  31868,  31868,  32124,  31868,  31868,  31611,
   31611, 31611,  32124,  32381,  32382,  32382,  32382,  32382,
    -130,    -1,     -1,  32126,  31612,  31611,  31354,  31866,
   32380, -1027,  -2825,  -4111,  -4113,  -3601,  -2830,  -3084,
   -4111, -4626,  -4114,  -1806,  31230,  28788,  29039,  31092,
    -643,  -516,  31614,  31097,  31097,  30585,  28018,  25961,
   25187, 25955,  28265,  -1671,  -5906,  -6938,  -4377,  26491,
   22365, 21845,  23640,  29542,  -4614,  31988,  21857,  18509,
   18503, 25423, -13346, -16959, -17990, -18760, -19531, -18509,
  -11844, 18794,  18239, -13999,
  ... 12100 more items
]

so the pcm16 format is 16-bit integers, and it's at 24kHz. u-law is 8-bit unsigned integers, and it's at 8kHz
So, you have to downsample to 8 kHz from 24 khz (e.g. take every third value, for a naive implementation), and then use a package like alawmulaw to do the conversion since it's non-trivial.
The SDK doesn't natively support G.711 u-law 8khz; it's implemented to assume pcm16 is being used.
See my comment https://github.com/openai/openai-realtime-api-beta/issues/8#issuecomment-2411857042 on #8

@themarcosf yep I have an example working. But there's also an example from twilio https://github.com/twilio-samples/speech-assistant-openai-realtime-api-node

@themarcosf yep I have an example working. But there's also an example from twilio https://github.com/twilio-samples/speech-assistant-openai-realtime-api-node

Is it possible to post your sample as well. Twilio sample is very bare-bone

I can post my patched version of the client that's specifically for mu-law 8khz

I did butcher a version to support the formatted audio option when its changed to mulaw (g711_ulaw).
This allows the audio playback from the conversation item.formatted.audio


CVI 001 - Cluster Self Provisioning

This PR contains the MVP of the self-serving / self-provisioning cluster.
TODO: Complete the PR description
meanwhile, add your review/comments as PR comments

Missing. Spotted from the review. Thank you all :)

[ ] destroy subcommands requires confirmation.
[ ] consider renaming the update command to apply.
[ ] Implement init --reset flag to recreate the terraform project.
[ ] Add alternative way to pass the --token. Add FURYCTL_TOKEN.
[ ] Improve terraform code to pin terraform provider versions.
[ ] Implement furyctl {bootstrap,cluster} template to output a sample yml to let the user modify it easily.
[ ] Move the backend configuration option from the .conf file to backend.tf.
[ ] Fix imperative variables on aws bootstrap provisioner
[ ] Add a secrets directory along with .gitattributes to encrypt that folder out of the box if the client has git-crypt installed.
[ ] Consider a command that creates a cluster.yml file from the bootstrap output.
[ ] Change the cluster provisioner to accept a file path to read the public key instead of pasting the public key content.
[ ] Clean (somehow) the env variables starting by TF_VAR as they can affect the current behaviour of the furyctl
[ ] preflight checks (maybe terraform validate¿?) before return 0 on init commands. (Check the executor parameters)

PS:

Destroy command is not asking for permission to proceed 😱
Why we are using modules from https/github and not locally via vendor folder?

PS:

Destroy command is not asking for permission to proceed 😱
Why we are using modules from https/github and not locally via vendor folder?

First of all, thank you @nutellinoit for taking the time to test this PR :)
I'll try to answer some points:

I want to see what Applying terraform project is doing
By default, you don't see terraform output. We wanted to hide what's under the roof. Anyway, you've got two different ways to see terraform logs:

As you know, furyctl creates a directory with all the terraform project. Inside it, there is a logs directory with all the logs. You can open a new terminal then tail that file.
If you run the same command with --debug, terraform output is available during the execution of the command.

The idea is to (try) to forget about terraform, at the same time, if we need to look or understand what is happening, there is a way to inspect it :)
Don't know if it makes sense.

First of all, thank you @nutellinoit for taking the time to test this PR :)
I'll try to answer some points:

I want to see what Applying terraform project is doing
By default, you don't see terraform output. We wanted to hide what's under the roof. Anyway, you've got two different ways to see terraform logs:

As you know, furyctl creates a directory with all the terraform project. Inside it, there is a logs directory with all the logs. You can open a new terminal then tail that file.
If you run the same command with --debug, terraform output is available during the execution of the command.

The idea is to (try) to forget about terraform, at the same time, if we need to look or understand what is happening, there is a way to inspect it :)
Don't know if it makes sense.

(personal opinion) I don't like the "update" command, i prefer an "apply" command
Ye... I didn't want to be "so" terraform. I copied some of the kops experience. Anyway, if more people want it to be renamed, I can do it :)

(personal opinion) I don't like the "update" command, i prefer an "apply" command
Ye... I didn't want to be "so" terraform. I copied some of the kops experience. Anyway, if more people want it to be renamed, I can do it :)

I would like to trigger init command multiple times before the first terraform apply, to check inside the folder if everything is as i expect. Something like furyctl bootstrap/cluster init --reset can do the job.

🤔 it could be a good idea. What do you expect from this flag? A complete remove and recreate directory?
It could be a good idea to discard "possible" manual modification. Does it make sense to you?

I would like to trigger init command multiple times before the first terraform apply, to check inside the folder if everything is as i expect. Something like furyctl bootstrap/cluster init --reset can do the job.

🤔 it could be a good idea. What do you expect from this flag? A complete remove and recreate directory?
It could be a good idea to discard "possible" manual modification. Does it make sense to you?

Add on the documentation how to create a github token and which scopes are needed
About 🔝
The token is something we are going to create for the paid customers. Anyway, it could make sense to document it somehow. Just take in mind that the token is something a paid customer will receive after payment.

Add on the documentation how to create a github token and which scopes are needed
About 🔝
The token is something we are going to create for the paid customers. Anyway, it could make sense to document it somehow. Just take in mind that the token is something a paid customer will receive after payment.

Possibility to use an env var like GITHUB_TOKEN or something similar

Possibility to use an env var like GITHUB_TOKEN or something similar

Missing providers pinning best practice on main.tf, also missing default region setting

That's something we have to work on, for sure. Thanks for popping it up

Missing providers pinning best practice on main.tf, also missing default region setting

That's something we have to work on, for sure. Thanks for popping it up

It's not easy to copy/paste from the doc, to create a bootstrap.yml file. I would like a furyctl bootstrap template command with an example.

Yes! I was thinking about it too. I'll do, it makes totally sense.

It's not easy to copy/paste from the doc, to create a bootstrap.yml file. I would like a furyctl bootstrap template command with an example.

Yes! I was thinking about it too. I'll do, it makes totally sense.

It's not clear what vpn.subnetCIDR should contain. As far as i understood, must be one of the previous created subnets

This is something described and available in the aws bootstrap provisioner docs: http://kfd-docs-feature-update-furyctl.surge.sh/docs/cli-reference/furyctl/provisioners/aws-bootstrap/#configuration
It is the subnet CIDR for the VPN. It must be different from the two networks the VPN is connecting

It's not clear what vpn.subnetCIDR should contain. As far as i understood, must be one of the previous created subnets

This is something described and available in the aws bootstrap provisioner docs: http://kfd-docs-feature-update-furyctl.surge.sh/docs/cli-reference/furyctl/provisioners/aws-bootstrap/#configuration
It is the subnet CIDR for the VPN. It must be different from the two networks the VPN is connecting

(personal opinion) I don't like the "update" command, i prefer an "apply" command

I am agree with @nutellinoit , update is something that doesn't match with the action, so should be better apply because it is the real thing that is gonna happen after have executed that command :D

(personal opinion) I don't like the "update" command, i prefer an "apply" command

I am agree with @nutellinoit , update is something that doesn't match with the action, so should be better apply because it is the real thing that is gonna happen after have executed that command :D

The s3 backend is not written inside the backend.tf file, but on some other .conf file. I want to be able to run the terraform project without furyctl

Ok, you can still run the terraform code with the created .conf file. Anyway, I agree moving that part to the backend.tf file.

The s3 backend is not written inside the backend.tf file, but on some other .conf file. I want to be able to run the terraform project without furyctl

Ok, you can still run the terraform code with the created .conf file. Anyway, I agree moving that part to the backend.tf file.

I don't like the imperative approach here, i would like to have all these variables on a tfvar file. This way i can check them during the init phase. This unlocks also the possibility to run terraform inside the bootstrap folder.

Ye... I did imperative in the bootstrap process, but we can do as furyctl cluster does, creating a tfvar file. It makes sense to have it aligned.

I don't like the imperative approach here, i would like to have all these variables on a tfvar file. This way i can check them during the init phase. This unlocks also the possibility to run terraform inside the bootstrap folder.

Ye... I did imperative in the bootstrap process, but we can do as furyctl cluster does, creating a tfvar file. It makes sense to have it aligned.

Secrets should be in a secrets folder, eg furyagent.yml

I would like to have a default .gitattributes file with all the secrets folders configured for git-crypt (plug and play) , or a command to to that

Yes! I'll do.

Secrets should be in a secrets folder, eg furyagent.yml

I would like to have a default .gitattributes file with all the secrets folders configured for git-crypt (plug and play) , or a command to to that

Yes! I'll do.

Possibility to use an env var like GITHUB_TOKEN or something similar

I would rather prefer something like GITHUB_TOKEN or CVS_TOKEN  (control version system) then FURYCTL_TOKEN, because in this case is the token that you need to interact with github not with something related to furyctl.

Possibility to use an env var like GITHUB_TOKEN or something similar

I would rather prefer something like GITHUB_TOKEN or CVS_TOKEN  (control version system) then FURYCTL_TOKEN, because in this case is the token that you need to interact with github not with something related to furyctl.

To be able to reduce errors, i would like to use some furyctl bootstrap output cluster eks command that creates for me a cluster.yml file with the outputs from the bootstrap project.

🤔 It could be a good idea not sure how to tackle it, but for sure makes sense

To be able to reduce errors, i would like to use some furyctl bootstrap output cluster eks command that creates for me a cluster.yml file with the outputs from the bootstrap project.

🤔 It could be a good idea not sure how to tackle it, but for sure makes sense

dmzCIDRRange cannot be a single CIDR, we need an array.

In that case, we need to start a new discussion about this parameter. Currently, the cluster uses the fury-eks-installer witch uses a standard interface.
https://github.com/sighupio/fury-eks-installer/blob/master/modules/eks/variables.tf#L21-L24

dmzCIDRRange cannot be a single CIDR, we need an array.

In that case, we need to start a new discussion about this parameter. Currently, the cluster uses the fury-eks-installer witch uses a standard interface.
https://github.com/sighupio/fury-eks-installer/blob/master/modules/eks/variables.tf#L21-L24

I don't like the approach of pasting the public key, i would like to use a filepath and read the content with terraform

Makes sense!

I don't like the approach of pasting the public key, i would like to use a filepath and read the content with terraform

Makes sense!

I don't like the approach of pasting the public key, i would like to use a filepath and read the content with terraform

Totally agree. Moreover, can be used a reference to github users array, as was done for the bootstrap.yaml.

I don't like the approach of pasting the public key, i would like to use a filepath and read the content with terraform

Totally agree. Moreover, can be used a reference to github users array, as was done for the bootstrap.yaml.

nodePools version cannot be empty or null, otherwise you get an Error: Your query returned no results. Please change your search criteria and try again.

🤔 it should be addressed in the installer first: https://github.com/sighupio/fury-eks-installer

nodePools version cannot be empty or null, otherwise you get an Error: Your query returned no results. Please change your search criteria and try again.

🤔 it should be addressed in the installer first: https://github.com/sighupio/fury-eks-installer

Can i manage aws-auth? I don't want the installer to do that for me

You'll. We have to release a new version of the eks installer, then enable it in furyctl. So yes, you will

Can i manage aws-auth? I don't want the installer to do that for me

You'll. We have to release a new version of the eks installer, then enable it in furyctl. So yes, you will

Destroy command is not asking for permission to proceed 😱

TOTALLY AGREE! TODO with some urgency :)

Destroy command is not asking for permission to proceed 😱

TOTALLY AGREE! TODO with some urgency :)

To be able to reduce errors, i would like to use some furyctl bootstrap output cluster eks command that creates for me a cluster.yml file with the outputs from the bootstrap project.

As i suggested the best way should be tagging the resources created by the bootstrap and then, reference them automatically in the cluster.yaml without having to fill it in granular way.

To be able to reduce errors, i would like to use some furyctl bootstrap output cluster eks command that creates for me a cluster.yml file with the outputs from the bootstrap project.

As i suggested the best way should be tagging the resources created by the bootstrap and then, reference them automatically in the cluster.yaml without having to fill it in granular way.

Why we are using modules from https/github and not locally via vendor folder?

I thought it was easier that way. Buy maybe we can consider the other way (vendor).

Why we are using modules from https/github and not locally via vendor folder?

I thought it was easier that way. Buy maybe we can consider the other way (vendor).

Possibility to use an env var like GITHUB_TOKEN or something similar

I would rather prefer something like GITHUB_TOKEN or CVS_TOKEN (control version system) then FURYCTL_TOKEN, because in this case is the token that you need to interact with github not with something related to furyctl.

Today we are using GITHUB that's true. A client doesn't have to know where the module comes from.
Also, we can host the modules under a private fileserver with other auth methods. This is why I think it would be better if we name the env variable as FURYCTL_TOKEN.

Possibility to use an env var like GITHUB_TOKEN or something similar

I would rather prefer something like GITHUB_TOKEN or CVS_TOKEN (control version system) then FURYCTL_TOKEN, because in this case is the token that you need to interact with github not with something related to furyctl.

Today we are using GITHUB that's true. A client doesn't have to know where the module comes from.
Also, we can host the modules under a private fileserver with other auth methods. This is why I think it would be better if we name the env variable as FURYCTL_TOKEN.

I don't like the approach of pasting the public key, i would like to use a filepath and read the content with terraform

Totally agree. Moreover, can be used a reference to github users array, as was done for the bootstrap.yaml.

This will require to modify the installer. We can talk about it along with the multiple cidr ranges feature

I don't like the approach of pasting the public key, i would like to use a filepath and read the content with terraform

Totally agree. Moreover, can be used a reference to github users array, as was done for the bootstrap.yaml.

This will require to modify the installer. We can talk about it along with the multiple cidr ranges feature

From @lzecca78 , I've got:

During the bootstrap init step the procedure throws an error if you already have TF_VAR* environment variables defined globally

Not sure how to tackle this problem, but it is a problem for sure. Adding to the list

During the bootstrap yaml setup is not evidenced which lines need to be changed manually and are not explained with what needs to be changed.

Ye, maybe we have to improve the docs and it would be better once we completed the furyctl cluster template stuff.

During the bootstrap update step the procedure creates the bootstrap directory even if the remote state bucket doesn’t exist.

Maybe we can add some kind of pre-flight checks. 🤔 how to do it?

From @lzecca78 , I've got:

During the bootstrap init step the procedure throws an error if you already have TF_VAR* environment variables defined globally

Not sure how to tackle this problem, but it is a problem for sure. Adding to the list

During the bootstrap yaml setup is not evidenced which lines need to be changed manually and are not explained with what needs to be changed.

Ye, maybe we have to improve the docs and it would be better once we completed the furyctl cluster template stuff.

During the bootstrap update step the procedure creates the bootstrap directory even if the remote state bucket doesn’t exist.

Maybe we can add some kind of pre-flight checks. 🤔 how to do it?

Maybe we can add some kind of pre-flight checks. 🤔 how to do it?

Is not complicated imho. Depending on the adapter (s3 or others) we can implement providers to check if that bucket exists or not in the preflight check, and imho, the same provider can takes in charge the task of creating it if is missing and if the user want (a boolean value that allow the automation of this task)

Maybe we can add some kind of pre-flight checks. 🤔 how to do it?

Is not complicated imho. Depending on the adapter (s3 or others) we can implement providers to check if that bucket exists or not in the preflight check, and imho, the same provider can takes in charge the task of creating it if is missing and if the user want (a boolean value that allow the automation of this task)

Ye, maybe we have to improve the docs and it would be better once we completed the furyctl cluster template stuff.

about this i suggest to have a seed.yml file in which the user put all the stuff needed but the template flag creation, so all the information will be there in a single point

Ye, maybe we have to improve the docs and it would be better once we completed the furyctl cluster template stuff.

about this i suggest to have a seed.yml file in which the user put all the stuff needed but the template flag creation, so all the information will be there in a single point

Hello,
I add my 2 cents. I will focus more on the overall design rather than implementation details and small improvements. The suggestions made by @nutellinoit and @lzecca78 were already super helpful in this last part.
What I like

Automation. It automates some cumbersome parts of the delivery part.
Standardization. It enforces a standard way of the delivery for the initial common parts.
Simplicity. Now it has some rough edges that can be improved, but overall the process seems very smooth.

What I don't like

Terraform code is hidden.  The terraform code has a secondary role in documenting the infrastructure; the new documentation becomes the boostrap.yml and cluster.yml. However, the logic of the module "hides" the output terraform code of the infrastructure.
Increase abstraction. We add another layer of abstraction; now we have terraform -> terraform modules -> fury modules -> furyctl logic. This layer is yet another thing to maintain and a new possible source of bugs.
Not DRY. It doesn't solve (yet) one of the problems that terraform has: code repetition across multiple environments. I have to do furyctl bootstrap furyctl cluster across various environments to get 98% of the same code across all of them.

Hello,
I add my 2 cents. I will focus more on the overall design rather than implementation details and small improvements. The suggestions made by @nutellinoit and @lzecca78 were already super helpful in this last part.
What I like

Automation. It automates some cumbersome parts of the delivery part.
Standardization. It enforces a standard way of the delivery for the initial common parts.
Simplicity. Now it has some rough edges that can be improved, but overall the process seems very smooth.

What I don't like

Terraform code is hidden.  The terraform code has a secondary role in documenting the infrastructure; the new documentation becomes the boostrap.yml and cluster.yml. However, the logic of the module "hides" the output terraform code of the infrastructure.
Increase abstraction. We add another layer of abstraction; now we have terraform -> terraform modules -> fury modules -> furyctl logic. This layer is yet another thing to maintain and a new possible source of bugs.
Not DRY. It doesn't solve (yet) one of the problems that terraform has: code repetition across multiple environments. I have to do furyctl bootstrap furyctl cluster across various environments to get 98% of the same code across all of them.

And P.S. Great work Angel as always 👏

And P.S. Great work Angel as always 👏

@nutellinoit About:

Change the cluster provisioner to accept a file path to read the public key instead of pasting the public key content.
Im having mixed feelings with this action. I don't know if we must implement this "additional" logic on top of the installer.

I mean...
The eks installer: https://github.com/sighupio/fury-eks-installer/tree/master/modules/eks#inputs has the ssh public key as an RSA key instead of a file path.
Then furyctl uses the installer under the hood exposing the variables as a yaml file (1:1).
data/provisioners/cluster/eks/main.tf
module "fury" {
  source = "github.com/sighupio/fury-eks-installer//modules/eks?ref=v1.2.0"

  cluster_name    = var.cluster_name
  cluster_version = var.cluster_version
  network         = var.network
  subnetworks     = var.subnetworks
  dmz_cidr_range  = var.dmz_cidr_range
  ssh_public_key  = var.ssh_public_key
  node_pools      = var.node_pools
  tags            = var.tags
}

IMHO, adding this (simple) logic on furyctl covers a problem on the installer. So maybe we have to reconsider deprecate that field/attribute on the installer appending a new one: ssh_public_key_path then incorporate that change in furyctl.
Let me know if you didn't understand it.

@nutellinoit About:

Change the cluster provisioner to accept a file path to read the public key instead of pasting the public key content.
Im having mixed feelings with this action. I don't know if we must implement this "additional" logic on top of the installer.

I mean...
The eks installer: https://github.com/sighupio/fury-eks-installer/tree/master/modules/eks#inputs has the ssh public key as an RSA key instead of a file path.
Then furyctl uses the installer under the hood exposing the variables as a yaml file (1:1).
data/provisioners/cluster/eks/main.tf
module "fury" {
  source = "github.com/sighupio/fury-eks-installer//modules/eks?ref=v1.2.0"

  cluster_name    = var.cluster_name
  cluster_version = var.cluster_version
  network         = var.network
  subnetworks     = var.subnetworks
  dmz_cidr_range  = var.dmz_cidr_range
  ssh_public_key  = var.ssh_public_key
  node_pools      = var.node_pools
  tags            = var.tags
}

IMHO, adding this (simple) logic on furyctl covers a problem on the installer. So maybe we have to reconsider deprecate that field/attribute on the installer appending a new one: ssh_public_key_path then incorporate that change in furyctl.
Let me know if you didn't understand it.

I was also thinking, can we put some version pinning on the underlying modules used by furyctl? For example, fury-eks-installer v1.2.0 somewhere.

I was also thinking, can we put some version pinning on the underlying modules used by furyctl? For example, fury-eks-installer v1.2.0 somewhere.

I was also thinking, can we put some version pinning on the underlying modules used by furyctl? For example, fury-eks-installer v1.2.0 somewhere.

Yes, we are already doing it. Currently, im updating eks provisioner :)

I was also thinking, can we put some version pinning on the underlying modules used by furyctl? For example, fury-eks-installer v1.2.0 somewhere.

Yes, we are already doing it. Currently, im updating eks provisioner :)

you will

I've implemented this feature :)
You can figure out how to use it by running the following command:
$ furyctl cluster template --provisioner eks
kind: Cluster
metadata:
  name: 'nameOfTheProject # Used to identify your resources'
  labels:
    boolLabel: true
    yourLabel: 'yourValue # You Can add as much labels as you required. You can add
      bool, string, number values'
spec:
  version: '1.18 # EKS Control plane version'
  network: 'vpc-id1 # Identificator of the VPC'
  subnetworks:
  - 'subnet-id1 # Identificator of the subnets'
  dmzCIDRRange: <IP_ADDRESS>/8. Required. Network CIDR range from where cluster control
    plane will be accessible
  sshPublicKey: sha-rsa 190jd0132w. Required. Cluster administrator public ssh key.
    Used to access cluster nodes.
  nodePools:
  - name: my-node-pool. Required. Name of the node pool
    version: 1.18. Required. null to use Control Plane version.
    minSize: 0
    maxSize: 1
    instanceType: t3.micro. Required. AWS EC2 isntance types
    maxPods: 110
    volumeSize: 50
    labels:
      environment: 'dev. # Node labels. Use it to tag nodes then use it on Kubernetes'
    taints:
    - key1=value1:NoSchedule. As an example
    subnetworks:
    - subnet-1
    - '# any subnet id where you want your nodes running'
    tags:
      myTag: 'MyValue # Use this tags to annotate nodepool resources. Optional'
  tags:
    myTag: 'MyValue # Use this tags to annotate all resources. Optional'
  auth:
    additionalAccounts:
    - "777777777777"
    - "88888888888"
    - '# Additional AWS account numbers to add to the aws-auth configmap'
    users:
    - username: 'user1 # Any username'
      groups:
      - system:masters
      - '# Any K8S Group'
      userarn: 'arn:user:7777777... # The user ARN'
    roles:
    - username: 'user1 # Any username'
      groups:
      - system:masters
      - '# Any K8S Group'
      rolearn: 'arn:role:7777777... # The role ARN'
executor:
  path: '/your/terraform/binary # Set this value if you need to use an already installed
    terraform binary'
  version: '0.12.29 # Set this value to download a specific terraform version. If
    version and path is not specified, latest terraform version will be downloaded'
  state:
    backend: 'local # Specify your backend configuration. local is the default one.
      https://www.terraform.io/docs/configuration/backend.html'
    config:
      path: 'workdir/terraform.state # Set the backend configuration parameter. this
        path attribute works with the local backend.'
provisioner: eks

Thanks!

you will

I've implemented this feature :)
You can figure out how to use it by running the following command:
$ furyctl cluster template --provisioner eks
kind: Cluster
metadata:
  name: 'nameOfTheProject # Used to identify your resources'
  labels:
    boolLabel: true
    yourLabel: 'yourValue # You Can add as much labels as you required. You can add
      bool, string, number values'
spec:
  version: '1.18 # EKS Control plane version'
  network: 'vpc-id1 # Identificator of the VPC'
  subnetworks:
  - 'subnet-id1 # Identificator of the subnets'
  dmzCIDRRange: <IP_ADDRESS>/8. Required. Network CIDR range from where cluster control
    plane will be accessible
  sshPublicKey: sha-rsa 190jd0132w. Required. Cluster administrator public ssh key.
    Used to access cluster nodes.
  nodePools:
  - name: my-node-pool. Required. Name of the node pool
    version: 1.18. Required. null to use Control Plane version.
    minSize: 0
    maxSize: 1
    instanceType: t3.micro. Required. AWS EC2 isntance types
    maxPods: 110
    volumeSize: 50
    labels:
      environment: 'dev. # Node labels. Use it to tag nodes then use it on Kubernetes'
    taints:
    - key1=value1:NoSchedule. As an example
    subnetworks:
    - subnet-1
    - '# any subnet id where you want your nodes running'
    tags:
      myTag: 'MyValue # Use this tags to annotate nodepool resources. Optional'
  tags:
    myTag: 'MyValue # Use this tags to annotate all resources. Optional'
  auth:
    additionalAccounts:
    - "777777777777"
    - "88888888888"
    - '# Additional AWS account numbers to add to the aws-auth configmap'
    users:
    - username: 'user1 # Any username'
      groups:
      - system:masters
      - '# Any K8S Group'
      userarn: 'arn:user:7777777... # The user ARN'
    roles:
    - username: 'user1 # Any username'
      groups:
      - system:masters
      - '# Any K8S Group'
      rolearn: 'arn:role:7777777... # The role ARN'
executor:
  path: '/your/terraform/binary # Set this value if you need to use an already installed
    terraform binary'
  version: '0.12.29 # Set this value to download a specific terraform version. If
    version and path is not specified, latest terraform version will be downloaded'
  state:
    backend: 'local # Specify your backend configuration. local is the default one.
      https://www.terraform.io/docs/configuration/backend.html'
    config:
      path: 'workdir/terraform.state # Set the backend configuration parameter. this
        path attribute works with the local backend.'
provisioner: eks

Thanks!

Besides all the things already highlighted by @nutellinoit and @lzecca78, I would like to add the following:
* avoid using a shared `sighup` user for the bastion (even though with multiple SSH keys)

This is something already implemented in the furyagent ssh user feature.
This feature creates a robot account (with is configurable) then adds ssh public keys from a welknown provider. Currently GitHub is being used.

* in the bootstrap phase, add an option to skip creation of the VPC and use a customer-provided one

This is something that has to be enable first in the provisioner. It could makes sense.

* in the bootstrap phase, add an option to tweak the number of bastions create (which could also be 0)

Again, this is something that has to be enable first in the provisioner. It could makes sense.

I've mixed feelings about dumping the terraform code and allowing to fiddle with it, I think the aim of this work is to create an opinionated way to create Kubernetes clusters. Everything else should be handled with a separate Terraform project with a separate state.

The idea is to let use show the code, but the furyctl tool is always overriding the terraform code to avoid missconfigurations (intended or not).

Also, what about adding an apiVersion to the YAML files? I agree that right now is just overkill but in the future might well be put to good use.

Ye... I had it in the first iteration, but i don't know if it makes sense currently

Besides all the things already highlighted by @nutellinoit and @lzecca78, I would like to add the following:
* avoid using a shared `sighup` user for the bastion (even though with multiple SSH keys)

This is something already implemented in the furyagent ssh user feature.
This feature creates a robot account (with is configurable) then adds ssh public keys from a welknown provider. Currently GitHub is being used.

* in the bootstrap phase, add an option to skip creation of the VPC and use a customer-provided one

This is something that has to be enable first in the provisioner. It could makes sense.

* in the bootstrap phase, add an option to tweak the number of bastions create (which could also be 0)

Again, this is something that has to be enable first in the provisioner. It could makes sense.

I've mixed feelings about dumping the terraform code and allowing to fiddle with it, I think the aim of this work is to create an opinionated way to create Kubernetes clusters. Everything else should be handled with a separate Terraform project with a separate state.

The idea is to let use show the code, but the furyctl tool is always overriding the terraform code to avoid missconfigurations (intended or not).

Also, what about adding an apiVersion to the YAML files? I agree that right now is just overkill but in the future might well be put to good use.

Ye... I had it in the first iteration, but i don't know if it makes sense currently

I've addressed almost all the points. At least those that I consider relevant for the MVP release.
Tomorrow I'll update the docs, meanwhile, I suggest to re-review the project :)
If I miss something relevant, ping me without any doubt

I've addressed almost all the points. At least those that I consider relevant for the MVP release.
Tomorrow I'll update the docs, meanwhile, I suggest to re-review the project :)
If I miss something relevant, ping me without any doubt

I am adding this cvi doc to continue with the furyctl self-provisioning feature to add GKE / Google Cloud provisioners.


Add accepted values from source schema test

Description & motivation
I found myself doing a SELECT DISTINCT(blah) FROM BOOM and using that to add an accepted_values test. For obvious reasons, that's suboptimal, so I threw together this schema test.

Checklist

[x] I have verified that these changes work locally
[x] I have updated the README.md (if applicable)
[x] I have added tests & descriptions to my models (and macros if applicable)

Hmm, why not use a relationships test for this?

Relationship test would work, but I always think of a relationship test as an actual relationship between entities. I feel like making it explicit that the datatype is some enum(ish) populated from some other source is a bit more explicit.

Hmm, I see your point.
I think when we start using "relationships" to render information like an ERD, it would be valid to have a separate test (though, it would be my hope that we don't just rely on the presence of a test to build this information).
I'm a little hesitant to add this code as it is functionally the same as the relationships test. As a result I'm going to close this issue.


IBM i: /QOpenSys automatically being excluded

java -jar /home/q1wwt/logpresso-log4j2-scan-2.1.2.jar /QOpenSys
Logpresso CVE-2021-44228 Vulnerability Scanner 2.1.2 (2021-12-17)
Scanning directory: /QOpenSys (without /QOpenSys)
Scanned 0 directories and 0 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 0.00 seconds

@ptkelly13 Would you retry with --exclude-fs none option?

That took care of it.  Thanks much!

java -jar /home/q1wwt/logpresso-log4j2-scan-2.1.2.jar --exclude-fs none  /QOpenSys
Logpresso CVE-2021-44228 Vulnerability Scanner 2.1.2 (2021-12-17)
Scanning directory: /QOpenSys
Scanned 11516 directories and 107782 files
Found 0 vulnerable files
Found 0 potentially vulnerable files
Found 0 mitigated files
Completed in 7.80 seconds

--exclude-fs none resolves.


Finished docs on case sensitivity (#9), and add some examples.

Hope this helps.

Codecov Report

Merging #1023 into master will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master    #1023   +/-   ##
=========================================
  Coverage     94.37%   94.37%
  Complexity      443      443
=========================================
  Files             2        2
  Lines          6418     6418
  Branches       1717     1717
=========================================
  Hits           6057     6057
  Misses           93       93
  Partials        268      268

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 9662c3b...a3614ae. Read the comment docs.

@jerrylususu Nice work!
Thank you very much!


Add ReviewMonitor by @RishabhTayal

[x] Project URL: https://github.com/RishabhTayal/ReviewMonitor
[x] Update contents.json instead of README
[x] One project per pull request
[x] Avoid iOS or open-source in description as it is assumed
[x] Use this commit title format if applicable: Add app-name by @github-username
[x] Use approved format for your entry

Thank you!

@RishabhTayal Hi! To show swift instead of objc, you should add the next "tags": [ "swift" ] in contents.json for your app. Also, for more information you can read this.

Yup sorry about this - feel free to open a pull request, or I will fix it later
Sent with GitHawk

Fixed

@dkhamsing Thanks.
Sent with GitHawk


Higher authority error in WPF with .NetCore3.1

When I use OnScreenKeyBoard.Open(), I got an error says : System.ComponentModel.Win32Exception: operation required need to upgrade.  And I ran program with ADMIN, it still don't work.
I tried with .Net Framework4.7.2, it works fine. does anyone know how to solve this problem with .NetCore? Please.

I finded solution for this. 1.7.0-beta.1 version will fix it and also brings 1909 Windows support

Thanks, you are so great, I couldn't find solution in last 2 days...


[Eris-Client] Bytecode X deployed at address Y, Block Z

Problem: Verification in Eris-PM, down the line, how do we ensure that these values are in Block X at the specified address. This is critical for contract verification.
Solution: Simple function that returns whether or not bytecode X was deployed at address Y, Block Z for this chain.

Why does it matter which blockheight the values were changed in; also pretty sure that that information is already accessible with some work, but just looking for some more context.

Verify that youre working on the proper contract.

That the bytecode deployed at address x at block y was this bytecode is very useful for formal verification.

Get block at height X, Get address and done. This is pms job to orchestrate not clients'. Client isn't built to give every single helper needed to do the things. It is built to provide a low level golang access to DBs functionality. Some processing and further calling is almost always required. But those will need to happen at the pm level or wherever the library is being used.


Add support for ABI guessing

we should take a look at: https://github.com/shazow/whatsabi
it could be useful for non-verified contracts.
it looks like it can work totally standalone, just providing the contract code, but we should be careful and take a deeper look at their code to make sure we are not introducing any external dependencies/calls.

that is an interesting one to take a look @sealer3

Cool idea. We can use our own 4bytes lookups instead of the external service.

Whatsabi only has ethers listed as a dependency, and indeed we can just ask whatsabi for the function selectors and do the lookups ourselves.
I have a basic version working which needs polishing. The function selector does not include the return value types in its hash, so 4bytes does not have the return values, and the Read Contract interface can't decode return values. So this is one usability issue.


Runs a terraform destroy on modules while deleting. Some rearangement…

… and cleanup of the install/uninstall code

Looks good!


[Hub Generated] Review request for Microsoft.Maps/Microsoft.Maps to add version preview/1.0

This is a PR generated at OpenAPI Hub. You can view your work branch via this link.
Changelog
Please ensure to add changelog with this PR by answering the following questions.

What's the purpose of the update?

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

When you are targeting to deploy new service/feature to public regions? Please provide date, or month to public if date is not available yet.
When you expect to publish swagger? Please provide date, or month to public if date is not available yet.
If it's an update to existing version,  please select SDKs of specific language and CLIs that require refresh after swagger is published.

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

Contribution checklist:

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

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

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
[ ] Ensure to copy the existing version into new directory structure for first commit (including refactoring) and then push new changes including version updates in separate commits. This is required to review the changes efficiently.
Adding a new service

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

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

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from Breaking Change Review Board as defined in the Breaking Change Policy.

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

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

@john35452: This needs to be structured accordingly to https://github.com/Azure/azure-rest-api-specs/pull/14871 since Weather service will be under its own client.

@john35452: This needs to be structured accordingly to #14871 since Weather service will be under its own client.

Thanks for the remind! Currently, this PR is used to check schema with PM for now.
We will move files to weather client directory after #14871 is merged.

Thanks for the remind! Currently, this PR is used to check schema with PM for now.
We will move files to weather client directory after #14871 is merged.

@john35452: Also keep in mind the changes introduced:

Common definitions were moved into https://github.com/Azure/azure-rest-api-specs/blob/master/specification/maps/data-plane/Common/preview/1.0/common.json, so ClientId, ResponseFormat(JSONFormat) parameters in path should reference the common definitions.
SubscriptionKey is not needed as explicit parameter and is rather set in securityDiffinitions: https://github.com/Azure/azure-rest-api-specs/blob/0b8ad3639180cfd04c880544275f18a6601c2226/specification/maps/data-plane/Weather/preview/1.0/weather.json#L32-L37

@john35452: thanks, saw the https://github.com/Azure/azure-rest-api-specs/pull/15351

@JeffreyRichter - the service is already deployed and this pr adds three 3 endpoints to swagger to align with the service.
In an offline sync map engineer mentioned - the APIs for Azure Maps have been live for a few years, hence these changes aren't really breaking - the service APIs haven't changed, and there are no SDK released.

@@JeffreyRichter could you provide the breaking change approval if there are no concerns?

 Is this matching service behavior or does the serviced want to make this change in which case it should be done in a new api-version?

I approved this because I just read your first note. But, this seems like a bunch of breaking changes pushed on to customers. Service teams shouldn't just deploy new API contract changes and then update their swagger saying that this is NOW matching service behavior in order to get approval.

@anuchandy, @JeffreyRichter: this should not be merged, superseded by https://github.com/Azure/azure-rest-api-specs/pull/15351

So, should I approve #15351?
If so, I'm hesitant to because of the removed property. See https://github.com/Azure/azure-rest-api-specs/pull/15351/checks?check_run_id=3218460533

@JeffreyRichter:
To clarify, the removal of host parametrization is intentional (https://github.com/Azure/azure-rest-api-specs/pull/15351/files#diff-434f5529f9a095a3d6a4e2520ab5b7067f710bcb75ce41788533eb6fcf0976e2R7), as it was added by mistake previously and should not appear in map clients except creator.
However this has been already addressed in a seperate PR: https://github.com/Azure/azure-rest-api-specs/pull/15386, we can remove it here in order not cause 1007 - RemovedClientParameter and then there should not be any other concerns to approve https://github.com/Azure/azure-rest-api-specs/pull/15351 ?

Since this PR is targeted at Microsoft.Map directory which is in the old directory structure, and we need to add our new change to client directory now.
So I raise another PR for this change.
https://github.com/Azure/azure-rest-api-specs/pull/15351
https://portal.azure-devex-tools.com/branch/john35452/azure-rest-api-specs/dev-maps-Weather-1.0...master/
Thanks a lot and sorry for confusing!


Outdated News Section

The news sections on the homepage contains zero updates since over 2 years.

netlifycms.org/

@ShalokShalom perhaps Netlify is not interested anymore. Because there are a lot of pull requests and issues without response

Netlify CMS is now Decap CMS. More news will follow!


[Question][LineChart][FlSpot] How can I print x and y values of FlSpots?

I would like to know how to print the x and y values for FlSpots from a List of FlSpots.
Iman posted an answer at this link:
https://stackoverflow.com/questions/60281061/how-to-assign-an-array-to-spots-in-fl-chart-in-flutter/61987521#61987521
When I try to print the FlSpot values from the answer Iman gave with "print(spots)", my console returns:
I/flutter (19814): [FlSpot, FlSpot, FlSpot, FlSpot, FlSpot, FlSpot, FlSpot]
How can I instead receive the x and y coordinates of each FlSpot and not just the data type? It would be helpful to know how to do this so I can double-check my FlSpot values in the Console during testing.

Got it.
each Dart object has a toString method that you can override.
If you don't override it, dart uses a default implementation (that prints the data type). Otherwise, it prints what you define in your overridden method.
Now I suggest you read about it. Then you can fork this repo and make the change. Then create your PullRequest and I will merge it to the master.
Also, I encourage you to attend to the Hacktoberfest and they count your PullRequest to gift a swag to you.
Thanks!

Thank you for your response! I will research that to learn more about it and make the change 👍
Oh I didn't know about Hacktoberfest but I looked it up and it looks really exciting, I just signed up! This will be my first time contributing to open source. I'll create a pull request soon, thanks!


CORE-8958 centralize platform versions

Introduce net.corda.libs.platform.PlatformVersion and use it.

@relyafi

I do wonder if it would be more appropriate to have the definition in corda-api, but I'm guessing it isn't used there currently.

We can move it there later if it proves to be needed.
I think it is more prudent to introduce it in runtime-os first.


build(deps): update Angular to v17.3.5

#393  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite


WIP for Issue #487

Resolves #487
Description

Type of change

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to not work as expected)
This change requires a documentation update
Documentation update

How Has This Been Tested?

Screenshots

Hey @jash-kothari I really like how you started this PR! Is there any help you need or anything we can do to help you get this across the finish line? Please let us know if the changes that were requested don't make sense or you need additional feedback.

@seanmarcia Hi need your help in writing test cases for mailer.I dont have any idea about writing test cases for mailers.

Hi @jash-kothari, thanks for tackling this issue!
There are a few changes I'd like to see before this branch gets merged:

[x] In the PR description, include step-by-step instructions (including any necessary configuration steps) for how to verify your code changes and confirm behavior is good
[ ] Add a simple spec that runs through the happy path for how this feature might get used
[x] Make sure rubocop is passing (run rubocop -a to see failures and recommendations for how to fix)

I'll be able to give more concrete suggestions for code improvements once those first two are done.
Again, thanks for your hard work on this PR - it's going to make a big difference in the lives of our hard-working diaper banks' staff!


Enable the use of FragmentDefinition constants within blocks

Is your feature request related to a problem? Please describe.
While fragments are backed when you use heredoc syntax and parse by storing in a constant, using the constant in a block will fail with a "}" (RCURLY) GraphQL::ParseError.
For example, for the following fragment:
HumanFragment = graphlient.parse <<-'GRAPHQL'
  fragment on Human {
    name
    homePlanet
  }
GRAPHQL

Using it like this will work:
HerosQuery = graphlient.parse <<-'GRAPHQL'
  {
    luke: human(id: "1000") {
      ...HumanFragment
    }
    leia: human(id: "1003") {
      ...HumanFragment
    }
  }
GRAPHQL

graphlient.query(HerosQuery)

However, when using blocks, we clearly cannot use ...HumanFragment. Using the constants themselves will fail with a parsing error.
graphlient.query {
  luke: human(id: "1000") {
    HumanFragment
  }
  leia: human(id: "1003") {
    HumanFragment
  }
}

The error:
        11: from ruby/Ruby26-x64/lib/ruby/gems/2.6.0/gems/graphlient-0.6.0/lib/graphlient/client.rb:37:in `query'
        10: from ruby/Ruby26-x64/lib/ruby/gems/2.6.0/gems/graphlient-0.6.0/lib/graphlient/client.rb:15:in `parse'
         9: from ruby/Ruby26-x64/lib/ruby/gems/2.6.0/gems/graphql-client-0.18.0/lib/graphql/client.rb:186:in `parse'
         8: from ruby/Ruby26-x64/lib/ruby/gems/2.6.0/gems/graphql-2.0.14/lib/graphql.rb:46:in `parse'
         7: from ruby/Ruby26-x64/lib/ruby/gems/2.6.0/gems/graphql-2.0.14/lib/graphql.rb:58:in `parse_with_racc'
         6: from parser.y:480:in `parse'
         5: from parser.y:466:in `parse_document'
         4: from ruby/Ruby26-x64/lib/ruby/gems/2.6.0/gems/graphql-2.0.14/lib/graphql/tracing.rb:90:in `trace'
         3: from parser.y:470:in `block in parse_document'
         2: from ruby/Ruby26-x64/lib/ruby/2.6.0/racc/parser.rb:259:in `do_parse'
         1: from ruby/Ruby26-x64/lib/ruby/2.6.0/racc/parser.rb:259:in `_racc_do_parse_c'
parser.y:538:in `on_error': Parse error on "}" (RCURLY) at [4, 13] (GraphQL::ParseError)

Describe the solution you'd like
I think that to be aligned with the backing gem (graph-client) those constants should be usable within the block structure that graphlient offers.
HumanFragment.class
#GraphQL::Client::FragmentDefinition

^ They belong to a well known class. So perhaps they could be just transformed to ...HumanFragment, so when Graph::Client.parse kicks in, finds them the way it expects?
Describe alternatives you've considered
Besides what is already offered in the back gem graphql-client, there isn't anything in graphlient that allows to use fragments with blocks (unless I completely missed this point). The only reference to fragments is this issue, and the solution was by not using blocks.
Additional context
I think that the above is pretty clear. You may see this is useful or you may see it is not or have another better/easier idea to support fragments. But I do not think the above can be missunderstood.

Good idea, try to implement it?

@dblock you're right. Needs to call Graphlient::Query#method_missing and using the constant HumanFragment as is will delegate to the GraphQL::Client.
Well, although the below deviates from the sym convention that you took for parameters, this worked fine:
graphlient.query {
  luke: human(id: "1000") {
    ___HumanFragment
  }
  leia: human(id: "1003") {
    ___HumanFragment
  }
}

And in Graphlient::Query, adding this line in the private append_method:
      node = node.to_s.gsub("___", "...").to_sym if node.to_s.start_with?("___")

Perhaps you got a better idea? (it supports fragments by just adding 1 line)

I have actually applied a patch using the above approach.
To support namespaces on fragments
module Fragment
  Human = graphlient.parse <<-'GRAPHQL'
    fragment on Human {
      name
      homePlanet
    }
  GRAPHQL
end

an additional convention is necessary. Double underscore __ for double colons ::, by adding this as first line of the append_method private method of Graphlient::Query:
      node = node.to_s.gsub("___", "...").gsub("__", "::").to_sym.to_sym if node.to_s.start_with?("___")

The above allows for this usage:
graphlient.query {
  luke: human(id: "1000") {
    ___Fragment__Human
  }
  leia: human(id: "1003") {
    ___Fragment__Human
  }
}

Which will become the below string in Graphlient::Client#parse before GrapQL::Client#parse is called:
query {
  luke: human(id: "1000") {
    ...Fragment::Human
  }
  leia: human(id: "1003") {
    ...Fragment::Human
  }
}

Make a PR and we can talk it over there?

@dblock  hmmm, I haven't tried but I was thinking if it wouldn't be cleaner to just
module GraphQL
  class Client
    class FragmentDefinition
      self.to_s
        "...#{name}"
      end
    end
  end
end

I will give it a try and see if that works

https://github.com/ashkan18/graphlient/pull/94

@rellampec should we close this?


Allow KeySelectors to implement ResultTypeQueryable

getUnaryOperatorReturnType() does already call ResultTypeQueryable if available.

Without the change, I'm getting the following error, even though my KeyExtractor implements ResultTypeQueryable:
Exception in thread "main" java.lang.IllegalArgumentException: The types of the interface org.apache.flink.api.java.functions.KeySelector could not be inferred. Support for synthetic interfaces, lambdas, and generic types is limited at this point.
	at org.apache.flink.api.java.typeutils.TypeExtractor.getParameterType(TypeExtractor.java:640)
	at org.apache.flink.api.java.typeutils.TypeExtractor.getParameterTypeFromGenericType(TypeExtractor.java:664)
	at org.apache.flink.api.java.typeutils.TypeExtractor.getParameterType(TypeExtractor.java:627)
	at org.apache.flink.api.java.typeutils.TypeExtractor.validateInputType(TypeExtractor.java:686)
	at org.apache.flink.api.java.typeutils.TypeExtractor.getUnaryOperatorReturnType(TypeExtractor.java:235)
	at org.apache.flink.api.java.typeutils.TypeExtractor.getKeySelectorTypes(TypeExtractor.java:189)
	at org.apache.flink.api.java.typeutils.TypeExtractor.getKeySelectorTypes(TypeExtractor.java:183)
	at org.apache.flink.api.java.operators.JoinOperator$JoinOperatorSets.where(JoinOperator.java:871)
	at flink.generators.programs.TPCHGeneratorExample.main(TPCHGeneratorExample.java:55)
	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:483)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)

It's a bug in line 689. The input validation tries to get the generic parameters that are not available, in this case the validation should be skipped.

Do you want to fix it or should I do it?

I can create a fix for that.

Cool, thank you

So, this pull request can be closed?

I'll close it.
I've filed a jira for the issue and assigned it to @twalthr: https://issues.apache.org/jira/browse/FLINK-1471

I would advocate to adding this one as well as a fallback option.
I have a situation where I want to use KeySelector that might return Java TupleXX instances parameterized with Scala types, e.g.:
class SelectFoo extends KeySelector[Tuple3[Int, Int, String], Tuple3[Int, String]] {
    override def getKey(v: Tuple3[Int, Int, Int]) = new Tuple2(v.f0, v.f2)
}
``

Even though in this cases  the generic parameters are available, the Scala types cannot be inferred because the actual type field type parameters are erased by Scala and  are seen only as java.lang.Object from the Java reflection API.

I think that this StackOverflow article explains my problem.

I looked into your issue. Scala has a very strange behavior at this point. I don't know why it converts Int to Object. The TypeExtractor gets Tuple3<Object, Object, String> which results in an input mismatch exception which is correct. If you take Integer instead of Int everything works fine.
@aljoscha do you have an idea?

Nope, sorry, also have no Idea why this is happening.

I think that this only happens for the primitive types. I think this is by design.
If you want to inspect generic parameters, Scala forces you to use the Scala reflection API. There is no way around that.


Write to --download-archive file but don't download

Checklist

[x] I'm asking a question
[x] I've looked through the README and FAQ for similar questions
[x] I've searched the bugtracker for similar questions including closed ones

Question
Is it possible to use --download-archive while also not downloading videos?
For example, say there's a very large playlist, I don't want to download any video, I only want to fill my --download-archive file, to be able to download every new video after this.
It feels like --skip-download or --get-id should do that, but they don't.

Not possible.


Broken home page

Dashboard on introduction page is not functional, css and designing needed to add pomodoro timer. Also need to fix the menu bar on the left

Replaced broken notification alert button with Log In avatar in branch v1.1 (don't merge yet)

added list-items.js for drawer items in left menu bar. Linked login and signup page to home page.


a problem with dependency on solidus frontend

Hi,
in the gemspec there is a dependency on solidus, and solidus includes backend, frontend, core and api.
This is a problem when you do not want frontend gem added.
Would it be possible to replace the dependency on solidus with one on core only, something like here:
https://github.com/Xpitality/solidus_signifyd/blob/master/solidus_signifyd.gemspec#L24
Or if you know of any way of not having frontend included from solidus, that would be great too.
Thanks!

Yes, in the gemspec we should probably kill the solidus dependency in favor of just core, backend and api. This is on our list already for one of our projects, but if you felt like submitting a pull request we'd be happy to consider it.

I just realized you had a PR already for this. Could you rebase it perhaps?

sure, here it is

Thanks


Display friendly message if port is in use

Environment Details

Helidon Version: 0.10.0
Helidon SE
JDK version:
OS:
Docker version (if applicable):

Problem Description
When a Helidon app starts and finds that it cannot bind to a port in use, it aborts without reporting a friendly message to the user. We should detect the condition and print a message explaining the conflict.
Steps to reproduce
Using quickstart-se and having a process already listening to 8080 (default port).

The cause is now printed as part of the error message.


Add new Announcement blog and clean up old links and blogs

closes: #ISSUE_Number

Change logs
This pr includes 3 commits:

Add Announcement Blog on Cloudberry joins ASF Incubator
Clean up old blogs, some of them have old links that cannot be visited anymore. So remove all the old blogs directly.
Update old links, names, and logos to the new links, new ASF names, and new logo files.

The clean-up work has been in progress, will have more PRs coming.
Contributor's checklist
Here are some reminders before you submit your pull request:

Make sure that your Pull Request has a clear title and commit message. You can take the Git commit template as a reference.
Sign the Contributor License Agreement as prompted for your first-time contribution (One-time setup).
Learn the code contribution and doc contribution guides for better collaboration.
Make sure that your changes deployment preview is successful.
List your communications in the GitHub Issues or Discussions (if has or needed).
Feel free to ask for the @cloudberrydb/doc team or other people to help review and approve.

Screenshots
Website:

New blog:

For the website preview, it seems that it doesn't work now: cloudberry.staged.apache.org.
Maybe we need to run the copy command to copy the output to the asf-staged branch in the workflow file - https://infra.apache.org/project-site.html.

Using .asf.yaml with a Git repository, once you have your generated web site committed and pushed to a branch, you can set up a staging web site to test your changes before publishing them to your main web site.
To do so, add or edit .asf.yaml in the staging branch (where the build output is generated) and add the following (assuming your staging branch is asf-staging):
Upon commits to this branch, your staging web site will appear with the latest output at: https://$project.staged.apache.org/ For more details, see .asf.yaml.

FYI: I review the content locally by following the instructions in the README.md

Hi Ed,

On the release page, do we need to indicate that all releases available thus far were made available prior to joining Apache incubation.

Do you mean the release pages on GitHub or the website?
I already added the notes This is not an Apache release! to the old release pages on the website, like: https://cloudberry.apache.org/docs/releases/release-1.6.0/.  If looks good, will add the notes in the GitHub release pages.

Hi Ed,

On the release page, do we need to indicate that all releases available thus far were made available prior to joining Apache incubation.

Do you mean the release pages on GitHub or the website?
I already added the notes This is not an Apache release! to the old release pages on the website, like: https://cloudberry.apache.org/docs/releases/release-1.6.0/. If looks good, will add the notes in the GitHub release pages.

Ahhh ... I see the note. It was too small :) Maybe make the note more prominent. When we have our initial Apache release, I'm guessing we will remove these legacy releases.
I do like the idea of adding a similar not to the GitHub releases as well.

Cool. Already update the release pages with the notes.

The website looks much better. Great work!


hydra-proxy: explicitly listen on ipv6 addresses

As reported in https://github.com/NixOS/nixos-org-configurations/issues/284 hydra is not currently accessible over ipv6 even though a AAAA record is published.
Apache is currently listening on only ipv4 addresses. This PR explicitly adds [::] to the listen address config so that ipv6 will be fully supported.
After change in test vm:

closes #284

Nope.
Oct 19 16:01:51 rhea systemd[1]: Stopped Apache HTTPD.
Oct 19 16:01:51 rhea systemd[1]: Starting Apache HTTPD...
Oct 19 16:01:51 rhea httpd[2789412]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:443
Oct 19 16:01:51 rhea httpd[2789412]: (98)Address already in use: AH00072: make_sock: could not bind to address [::]:80
Oct 19 16:01:51 rhea httpd[2789412]: (98)Address already in use: AH00072: make_sock: could not bind to address <IP_ADDRESS>:80
Oct 19 16:01:51 rhea httpd[2789412]: no listening sockets available, shutting down
Oct 19 16:01:51 rhea httpd[2789412]: AH00015: Unable to open logs
Oct 19 16:01:51 rhea systemd[1]: httpd.service: Control process exited, code=exited, status=1/FAILURE
Oct 19 16:01:51 rhea systemd[1]: httpd.service: Failed with result 'exit-code'.
Oct 19 16:01:51 rhea systemd[1]: Failed to start Apache HTTPD.

What else listens on 80/443 on that machine?


Open external content in default browser

Fixes #2045

LGTM.  There is a merge conflict between this and #2049.  I tried to fix it myself, but I don't appear to have access to push to this branch.

Conflict resolved. Can you please re-review, @brianrob. Thanks.


Small typo fix in comments

The PR includes a very small typo fix in core.py and reach.py.

Thanks!


Option for column names as header row?

I was wondering how difficult it'd be to add an option to print a header row of column names as the first row of the file.  I looked over the code a bit, but my knowledge of python is sparse.

:+1:

Same thoughs. Brilliant work but I wish it could add the column headers as well. Or the best would be:
One SQL file > multiple csv files with each table in one!!!! :+1:


Need a parameter to clear/rebuild resource cache

Prerequisites

[X] Write a descriptive title.
[X] Make sure you are able to repro it on the latest version
[X] Search the existing issues.

Summary
Currently this can be done only manually by deleting the file, e.g.:
rm C:\Users\Andrew\AppData\Local\dsc\PSAdapterCache.json
This is not optimal user experience.
Steps to reproduce
run dsc.exe
Expected behavior
NA

Actual behavior
NA

Error details
No response
Environment data
v1

Version
v1
Visuals
No response

This was fixed by #468 .


Add python 3 to travis

I just noted that travis only covered 2.7, so I quickly added 3.5 and 3.6. Checks out just fine, no issues.

Thanks @DanielLenz, perhaps @fjaviersanchez  can review?

@elisachisari This is good! Feel free to merge :)


Upgrade Jetty dependency

The RDF4J server is still using Jetty 7.0.2v2010 (released in 2010 and EOL).
The Eclipse Jetty project recommends using Jetty 9.x (Jetty 8 is also EOL), which requires at least Java 8, so the suggestion is to use 9.4.12

@barthanssens due to the upgrades of Spring and the servlet api  (see #1343) we may need to give this some priority - I am getting test failures with nosuchmethoderrors when running the compliance tests (which still use jetty 7, servlet api 2.5). I'm going to pick this up, let me know if you have any objections or comments :)

thanks, and of course no objections :-)


Training Error

Thanks authors for the amazing work.
I got this error when run the training:
2023-01-28 06:14:22 - vall_e.utils.trainer - INFO - GR=0;LR=0 -
New epoch starts.
/opt/conda/envs/valle/lib/python3.10/site-packages/torch/utils/data/dataloader.py:554: UserWarning: This DataLoader will create 8 worker processes in total. Our suggested max number of worker in current system is 4, which is smaller than what this DataLoader is going to create. Please be aware that excessive worker creation might get DataLoader running slow or even freeze, lower the worker number to avoid potential slowness/freeze if necessary.
  warnings.warn(_create_warning_msg(
Traceback (most recent call last):
  File "/opt/conda/envs/valle/lib/python3.10/runpy.py", line 196, in _run_module_as_main
    return _run_code(code, main_globals, None,
  File "/opt/conda/envs/valle/lib/python3.10/runpy.py", line 86, in _run_code
    exec(code, run_globals)
  File "/workspace/vall-e/vall_e/train.py", line 128, in <module>
    main()
  File "/workspace/vall-e/vall_e/train.py", line 119, in main
    trainer.train(
  File "/workspace/vall-e/vall_e/utils/trainer.py", line 155, in train
    stats = engines.step(feeder=train_feeder, batch=batch)
  File "/workspace/vall-e/vall_e/utils/engines.py", line 171, in step
    raise e
  File "/workspace/vall-e/vall_e/utils/engines.py", line 133, in step
    maybe_loss_and_engine_stats = feeder(
  File "/workspace/vall-e/vall_e/train.py", line 39, in train_feeder
    _ = model(
  File "/opt/conda/envs/valle/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "/opt/conda/envs/valle/lib/python3.10/site-packages/deepspeed/utils/nvtx.py", line 11, in wrapped_fn
    return func(*args, **kwargs)
  File "/opt/conda/envs/valle/lib/python3.10/site-packages/deepspeed/runtime/engine.py", line 1836, in forward
    loss = self.module(*inputs, **kwargs)
  File "/opt/conda/envs/valle/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "/workspace/vall-e/vall_e/vall_e/ar.py", line 49, in forward
    return super().forward(
  File "/workspace/vall-e/vall_e/vall_e/base.py", line 428, in forward
    self.proms_emb(proms_list),
  File "/opt/conda/envs/valle/lib/python3.10/site-packages/torch/nn/modules/module.py", line 1194, in _call_impl
    return forward_call(*input, **kwargs)
  File "/workspace/vall-e/vall_e/vall_e/base.py", line 269, in forward
    x = einsum("l k d, n l k -> n d", w, x)
  File "/opt/conda/envs/valle/lib/python3.10/site-packages/torch/functional.py", line 378, in einsum
    return _VF.einsum(equation, operands)  # type: ignore[attr-defined]
RuntimeError: CUDA error: CUBLAS_STATUS_INVALID_VALUE when calling `cublasGemmStridedBatchedExFix( handle, opa, opb, m, n, k, (void*)(&falpha), a, CUDA_R_16F, lda, stridea, b, CUDA_R_16F, ldb, strideb, (void*)(&fbeta), c, CUDA_R_16F, ldc, stridec, num_batches, CUDA_R_32F, CUBLAS_GEMM_DEFAULT_TENSOR_OP)`

My torch version is 1.13.1, and gpu information:
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 450.142.00   Driver Version: 450.142.00   CUDA Version: 11.5     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|                               |                      |               MIG M. |
|===============================+======================+======================|
|   0  Tesla T4            On   | 00000000:00:1E.0 Off |                    0 |
| N/A   23C    P8    11W /  70W |      0MiB / 15109MiB |      0%      Default |
|                               |                      |                  N/A |
+-------------------------------+----------------------+----------------------+

Do you know how to remove this error?

solved. I downgraded torch to 1.11.0