strange filesystem behaviour

I'm executing a mv command in a container:

mv /opt/expenses/web/node_modules_g/* /usr/lib/node_modules/

and getting back a series of "mv: will not create hard link" for fairly arbitrary (but consistent) pairings of files that are not hard links and do not seem to bear much relationship to each other - example:

mv: will not create hard link '/usr/lib/node_modules/grunt-cli/node_modules/.bin' to directory '/usr/lib/node_modules/bower/test'

I can probably provide the container this is happening in, if needed for debug.
'''
vagrant@vagrant-ubuntu-saucy-64:~$ docker run -i -t fe8d271e3318 /bin/bash
root@47894fcb1eed:/# ls -l /opt/expenses/web/node_modules_g
total 8
drwxr-xr-x 7 expenses expenses 4096 Mar  7 04:28 bower
drwxr-xr-x 6 expenses expenses 4096 Mar  7 04:28 grunt-cli
root@47894fcb1eed:/# ls -l /usr/lib/node_modules
total 4
drwxr-xr-x 9 root root 4096 Mar  7 00:04 npm
root@47894fcb1eed:/#
'''

For what's it's worth, running an additional "ls" in the target directory seems to be sufficient for the build to move on. Also works with a simple "sync" in the same RUN command. Sounds like a race condition that fails in certain conditions.
Still happening on 1.9.1, kernel 4.3.0-aufs.


fix global search for not text column

Fix error like:
SQLSTATE[22P02]: Invalid text representation: 7 ERROR: invalid input
syntax for integer: "abc"

I think this behaviour should be implemented in the columns, not the criteria provider.

Should we add options to column and remove filter class? Or add option to filters


Impact of SDK 3.0 and Lua 5.3 updates to NodeMCU

Hi @kmpm Peter,  I just wanted to reach out and coordinate what we are doing on the NodeMCU project itself.  This might interact with your uploaded tool, as @joysfera has raised in nodemcu/nodemcu-firmware#2948.
With effect from SDK 3.0, the Lua runtime uses pipes to buffer Lua input and output.  The SDK 2.x and prior versions only used the H/W uart buffers to buffer input whilst parsing input streams so it was extremely easy to overrun these.  Now the input driver dumps the interactive input lines into a fifo (in the Lua registry at stdin) using a high priority SDK task, and the interpreter reads this at low priority.  Likewise redirected output is also spooled to stdout.  This change has a few advantages:

It is now a lot harder to overrun the input session when connected to PuTTy, miniterm, telnet, etc.  You can happily paste in 50 lines of Lua as a single paste without it overrunning.  Overrun is still possible because the SDK is non-preemptive, but rarely happens.

Likewise printing is spooled and a separate printing task is scheduled to empty the Q. This means that applications like telnet.lua  have all of their output marshalling done for them and so can send back the output to the telnet client in decent network packet chunks.  Now error reports use the same mechanism so a telnet user can see Lua errors.  Printing now gets interleaved with other Lua tasks so it is far less likely that a lot of printing at the slower baudrates causes watchdog timeouts.

This makes the user experience a lot easier.  The downside of the input and output being buffered by default is that automated uploaders might get out of sync.
This is really just a heads-up, and to open a channel to the NodeMCU team.

Thanks for the info. Really great.
Just wish I had more time for this project :)

@TerryE, if you would be so kind, have a look at the lua parts in https://github.com/kmpm/nodemcu-uploader/blob/master/nodemcu_uploader/luacode.py
It works, but that is not the same as being correct :-)


WIP: 1.7pg-a1

@cheungpat, thanks for your PR! By analyzing the annotation information on this pull request, we identified @rickmak to be a potential reviewer


Regen signatures with new interface

Blocked on https://github.com/microsoft/typespec/pull/3929

:x: There is undocummented changes. Run chronus add to add a changeset or click here.
The following packages have changes but are not documented.

:x:@azure-tools/typespec-azure-core
:x:@azure-tools/typespec-azure-resource-manager

Show changes

You can try these changes here

🛝 Playground
🌐 Website
📚 Next docs


Where to start

If you want to start using this project, there is very little documentation to this powerful tool.
Here are few projects where to look for "usages":
https://github.com/tuya-cloudcutter/cloudcutter-universal/blob/master/cloudcutter/modules/dhcp/structs.py
https://github.com/tuya-cloudcutter/bk7231tools/blob/main/bk7231tools/analysis/kvstorage.py
https://github.com/libretiny-eu/ltchiptool/blob/master/uf2tool/models/partition.py

Thanks, I added these to the README.


No mesh in Godot file explorer

Installed this plugin, saved my .vox file in a folder called Models, but the folder seems empty in Godot. When I check with my file explorer, the .vox file is still there, but in Godot, no vox or mesh.
I'm running Godot v3.0.2, has the plugin broken in the latest version?

Hm. Weird. it works fine for me.
Could you check the console output for any errors?

I created a new project, imported the addon, and saved a .vox file inside the project folder. Here's all of the output:

And here's the contents of the project folder:

According to the first line of your output you are running a custom version or atleast a manually compiled version of godot. could you try and download the official one and test if the error persists?

Downloaded the official one and re-made the project as previously described. Output looks the same and the file structure is the same.

It's kind of concerning that nothing appears in the Godot file browser. Am I missing a step, isn't the importing an automatic process?

Oh. It was that yes, didn't realize you needed to do that manually. Sorry for wasting your time, and thanks for helping!


Remove embedded azdev (tools folder)

Now that azdev is published, begin removing the old versions of the tools that get installed when running dev_setup.py. This requires our CI scripts to transition to the public azdev.
THIS WILL ALSO REQUIRE CONCURRENT CHANGES TO EXTENSIONS REPO CI

[x] azdev style
[x] azdev test
[x] azdev cli-lint
[x] azdev verify license
[x] azdev verify document-map
[ ] azdev verify default-modules
[ ] azdev verify package
[ ] azdev verify commands
[ ] azdev verify module-load-perf
[ ] azdev verify load-all

@haroldrandom add to next Sprint.

We will make a plan for it

Related: azure-cli-extensions PR 1066

add to S171


Support for Thrift.

Thinking it would be great for users of thrift to do integration testing with VCRpy as well.
Thoughts?

does not look like this is possible any time soon?

@breerly @phoet Given that thrift uses httplib vcrpy should already work if you are using that transport. As for getting socket support, that would basically require a massive rewrite of vcrpy that patches a layer lower than we are currently patching.
Vcrpy focuses on HTTP testing. I don't think tcp level testing is likely to be added any time soon (or ever).

I've tested that this does work when using Thrift's HTTP transport.


Adds Shopware provider

Adding Shopware Template and Demo

@BrocksiNet thanks for extending and adding Shopware to the list. A couple of things to note:

We're trying to keep provider alphabetized. Can you adjust Shopware in the list.
We noticed some changes to the theme (header and search page), which is fine. Just know that the maintenance burden on your end might be a bit heavier when you pull in upstream updates, which I am sure you've thought of. Just saying it outloud. 😊

@manovotny The order is now alphabetic. And yes we added some more features like pagination and so on. Sure it will be a bit harder but I hope we can handle this. :joy:


Some icons appear to be missing or not using the new icons.

I've notice that the python icon is still using the default icon. And the Vue and poetry.lock icons are not showing at all.

This is in Pycharm Professional 2023.2.3

Thank you for the issue! I can reproduce this.

For the Vue Icon, this is an .ext missing in catppuccin/vscode-icons, I'll update that today
For the poetry.lock it doesn't seem that catppuccin/vscode-icons has an icons for this at the momemt. They solves this because they detect with VSCode that the language is Toml, then use the Tool icon instead, but it should definitely be a custom icon.
For Python however, that's strange as everything seems defined correctly. I suspect that our plugin is loaded before the Python plugin from JetBrains, and so the Python plugin replaces our icon. I'll check that

Not sure if this helps, but the python icon is changed in the tab of the opened file.

Really strange 😅 thanks for this info!
I won't be able to check this issue before this weekend, but it's one of the most important icons so I'll look at it as soon as possible

Hey! Ich have the same Problem with the .vue Files.

any Idea?

Yep, .vue are also mentioned in the OP comment!
I looked at this issue yesterday, and I think it will be harder to solve than expected. The solution seems to remove entirely the icon from the tree and replace it by a custom one, instead of patching the current ones. That's caused by some plugins who force their own icons.
If someone can look at this that would be really cool, but I will not have the time in the coming days.

@quentinguidee just what you suggested, I hope: https://github.com/catppuccin/vscode-icons/pull/63

Thanks! This should be updated with b0072e5219682dcdb2ef633014c9399b57b00bb1.
@sgoudham Could you already release that as a patch? As this icon seems to be highly requested

To add to this list: .razor icons also don't work:

@ricardoboss @CodingRuo @michael-farwell Vue should be fixed with the 1.1.0 that just released!


Server side pagination and sorting

Hello,
Is it possible to configure a table with server side pagination and sorting? Or implement a plugin to do so?
Thank you, your project looks very promising!

Sorry man,
For now, is not possible, but I think about it.
Thanks for the compliment and I hope this project is helping you.


.on not working

Trying to add a listener and not having any success. I'm using Vue 2.4.4 in development mode currently.
https://jsfiddle.net/g5ttw9qn/
   mounted () {         this.wishlist = Vue.ls.get('wishlist')         let updateWishlist = (val, oldVal, uri) => {             console.log('localStorage change', val);         }         Vue.ls.on('wishlist', updateWishlist)         console.log('mounted')     }

Hello, look at my example https://jsfiddle.net/Robin_ck/6x1akv1L/
it works great.
Also see my comment of the castel work of the events https://github.com/RobinCK/vue-ls#note

Thanks for the quick answer. I misunderstood how localStorage events run. They don't run in the same tab, I was expecting an event to fire on the same page. Also, I was setting the storage from my update method instead of using a watcher like you are doing in your example. Thanks again!

Hello, look at my example https://jsfiddle.net/Robin_ck/6x1akv1L/
it works great.
Also see my comment of the castel work of the events https://github.com/RobinCK/vue-ls#note

 this.$ls.on('counter', function(val) {..} Is never invoked. The example only works because the increment function increments the counter directly. So the example does not really show that the listener works

https://jsfiddle.net/27tk6evx/
on doesn't work if there is no tracking for the variable


Backup Data Corrupted On Restoration

my environment running ArangoDB
I'm using the latest ArangoDB of the respective release series:

[x] 3.1.16-1

On this operating system:

[x] Windows, version: 10

These are the steps to reproduce:

run arangodump on an OS X machine
run arangorestore on a Windows 10 machine, set create database to true
some data gets corrupted 🔢

Example Doc:
{
    "domain": "test.com",
    "uid": "b"
}

AQL Query:
for i in sites
filter i.domain == "test.com"
return i

NO RESULTS
but this one works:
for i in sites
filter i.uid == "b"
return i

so only domain is corrupted?!
what did I do that solved the problem?
I edited the doc and retyped test.com

How many documents are contained in the backup file for the sites collection?
Is it possible to provide the dump file? With that it would be much easier to tell whether the data is missing in the dump or somehow gets lost on restore, or if there is a completely different problem source.

the collection contained 2 docs
https://www.dropbox.com/s/s95sfo8q9cl472a/dump (2).zip?dl=0

I have imported the dump into a 3.1 successfully. And the sites collection has two documents after the import. The problem is the persistent index created on the collection. The AQL query you posted makes use of it, but it seems the index is not populated on restore. It seems that this only affects the persistent indexes, not any others.
I have pushed a fix for this into the 3.1 branch a few minutes ago. The fix will be included in 3.1.17.
For now, the workaround is to drop the persistent index after the restore and re-create it manually.


JavaComplete2 : TextChangedI feature needs vim version >= 7.4.143

Actual behavior (Required!)
when i write new java file show me:
JavaComplete2 : TextChangedI feature needs vim version >= 7.4.143
Press ENTER or type command to continue
Expected behavior (Required!)
write java code with vim without errors or warnings.
The steps to reproduce actual behavior (Required!)

use vundle to install this plugin
write "autocmd FileType java,jsp setlocal omnifunc=javacomplete#Complete" in .vimrc
use vim to open new file "test.java"

Environment (Required!)

OS:   ubuntu14.04
Vim version: VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Jan  2 2014 19:39:47)
Included patches: 1-52
Neovim version:

Q&A

Yes, I tried minimal .vimrc configuraion.
Yes, I have enabled logs with JCdebugEnableLogs and can put here content of JCdebugGetLogContent command, if you need.
Even, if you wish, I can set g:JavaComplete_JavaviDebug to 1, than set g:JavaComplete_JavaviLogfileDirectory, and put here server logs, too.

Screenshot (Optional)
The output of :redir and :message (Optional)

Fixed. Thanks.


Devspace command fails when cluster is not required

What happened?
When using devspace run a command that only uses echo errored with the message:
fatal error trying to load remote cache from current context and namespace: Unauthorized

What did you expect to happen instead?
Command to run as expected without depending on a kubernetes cluster.
How can we reproduce the bug?
First, remove or change your kube config so that it fails to connect to your cluster, but the cluster is still running. For example, to force a different but similar error for a kind cluster, comment out the certificate-authority-data under clusters for the cluster with name kind-kind.
For example:
~/.kube/config
apiVersion: v1
clusters:
...
- cluster:
    # certificate-authority-data: ...
    server: https://<IP_ADDRESS>:52617
  name: kind-kind
...

Create the following devspace.yaml:
version: v2beta1

commands:
  test: |-
    echo "Hello World"
...

Finally, run command
devspace run test

Local Environment:

DevSpace Version: [use devspace --version] devspace version 6.3.2
Operating System: mac
ARCH of the OS:ARM64
Kubernetes Cluster:
Cloud Provider: KinD
Kubernetes Version: [use kubectl version]

Client Version: v1.26.3
Kustomize Version: v4.5.7
Server Version: v1.25.4

Anything else we need to know?

Originally reported in the community slack


Fix JuliaLang/julia#10289

Don't try to store singleton objects on Julia versions that don't use memory to store them. This could cause a segfault when a singleton object was to be stored at the end of an object, since we'd write one byte too many. It didn't cause problems in other cases because we'd overwrite whatever we'd stored in that field when storing the next field.

Travis failure is in the JLDArchives/JLD00 code (because Top is no longer a type).

Coverage decreased (-0.38%) to 72.25% when pulling 13c981d7e87cdfb531782ebb8f1b25a0224bb5a5 on sjk/gc-segfault into b30a1fdd2494d9c29e16bce785e3f358efba86a8 on master.

Thanks for tackling this and so many other issues!


Updating deprecated kustomization fields.

Fixes https://github.com/rh-ecosystem-edge/kernel-module-management/issues/1187
/cc @yevgeny-shnaidman

/lgtm

/retest

/retest


unique executor_id

When starting a new node, or restarting a failed/finished node, we always it the executor_id of $nodekey (e.g. riak-default-3). This led to some subtle issues in the mesos ui, in that you could not access the sandbox of failed/finished nodes, because the links now pointed to the sandbox of the most recent instance of that node.
With this change, we tack a random UUID onto the executor_id every time, making it more unique in mesos.

This looks to be working without problem


Adjustments to latest ECDb changes for moving properties

ECDb is getting some updates for which we disabled schema changeset reverse/reinstate.
Raman asked me to update NextVersion and update the error message in imodeljs accordingly.
This goes after pull request https://dev.azure.com/bentleycs/iModelTechnologies/_git/imodel02/pullrequest/120522 in imodel02 which by the time of reading is probably merged already.
Please have a look at the change in BentleyError.ts! This is basically a breaking change, but a very obvious one... is this okay, or should I keep the old identifier instead to not break anybody?

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


Add tests for pull-request-diff

A lot more coverage in the diff parsing and fixed some issues with GitHub headers.

One small comment, otherwise LGTM!


Plumb GCP NetworkProjectID through ClusterDeprovision

Yet another miss from #2151
Also add some UT for these snowflake ClusterDeprovision fields for AWS, Azure, and GCP.
HIVE-2334

/assign @lleshchi

/test e2e-gcp

/assign @dlom
I'd like to get this landed tonight if possible. I've wasted enough of @ckandag's time already :crying_cat_face:

/lgtm


Use nullability with Kotlin: Android Basics in Compose

URL of codelab
In which task and step of the codelab can this issue be found?
Describe the problem
It seems that the final section that introduces the Elvis "?:", fails to have one final screen to show how it handles and assigns for a "null" value.
Steps to reproduce?

Go to...
Click on...
See error...

Versions
Android Studio version:
API version of the emulator:
Additional information
Include screenshots if they would be useful in clarifying the problem.

Could you please link the codelab and provide the exact location where you see this issue?

@InedibleGoose
Closing this issue, since there is no further issue description.
Please create a new one, if you need help.
All the best learning Android.


Ability to customize links

Is your feature request related to a problem? Please describe.
It would be nice if links can be customized the same way nodes are. For example, I really need to have double links grouping outward, but I cannot achieve that because the way the library is written, links are black boxes.

And ports are not enough because a) not very convenient, b) they can't be connected while initializing the data.

Not sure why you cannot connect while initializing. Define the links[ input: xx, output: yy]

Completely missed the fact that I can have ports in inputs, not just nodes. Thanks.


fix: set wcv2 wallet mobile support to only browser

Description
Currently, the web3 modal does not work in the Native ShapeShift app (though it does when using a mobile browser).
Update the wallet configuration accordingly.
Pull Request Type

[x] :bug: Bug fix (Non-breaking Change: Fixes an issue)
[ ] :hammer_and_wrench: Chore (Non-breaking Change: Doc updates, pkg upgrades, typos, etc..)
[ ] :nail_care: New Feature (Breaking/Non-breaking Change)

Issue (if applicable)
N/A
Risk
Testing
The WalletConnect wallet option should no longer appear as a wallet option in the native app.
Engineering
☝
Operations
☝
Screenshots (if applicable)
N/A

Current dependencies on/for this PR:

develop

PR #5405   👈

This comment was auto-generated by Graphite.


Minor patch

Cleaned up some comments
Fixed a typo
Commented out some relic functions that are not used anywhere. We should clean them in the next iteration

I'm merging it directly due to time constraints, and since the changes are minor.


[Enhancement] Ingress port mapping

Using k3s and docker-compose I can set a port binding for a node and the create an ingress using that to route into a pod ... lets say I bind port 8081:80, where port 80 is used by an nginx pod ... I can use localhost to reach nginx ..
http://localhost:8081
How can this be achieved using k3d ?

Maybe issue #6 is a relevant issue in this regard ? Though for port-forwarding the current recommended way of doing it is using kubectl port-forward

I would also opt for kubectl port-forward as @zeerorg said.
But, since ingress can in many cases be the only service that needs ports mapped to the host, I could imagine adding an extra flag to k3d create for ingress port mapping. E.g. k3d create --ingress-http 30080 --ingress-https 30443 for mapping http/https ports to the host system.
Or a single flag for mapping any arbitrary port.
WDYT

a working solution to specify the port forward during k3d creation would be indeed very helpful!

Unsurprisingly I can confirm that using kubectl port-forward does work, but ... I would still much prefer to define Ingress resources

but ... I would still much prefer to define Ingress resources

1+
the actual behavior looks rather inconvenient and insufficient  to me.
if it's possible forward the API network connectivity ports to the public network, it should be done resp. be configurable for ingress ports as well. without this feature k3d is IMHO hardly usable for serious work.

So I'd go with an additional (string-slice) flag like --extra-port <host:k3s> here.
No since it's most wanted to use this for ingress, it should be enough to expose the ports specified here on the server node, right?
Or we take a more sophisticated approach and extend it to --extraport <host:k3s:node>, where node can be either server, workers, all or <node name>.
Any opinions on that?

Being able to specify the node ‘role’ is more flexible if we are just talking about exposing ports in the general sense. I’m not sure I can think of a use case for using these for an Ingress object for Control Plane or Etcd (and as yet there is no separation of these roles - but that might happen in the future ?), but it’s still better to have the option. So here the prototype would be something like ...
—add-port :
Where  can be worker (default), controlplane, or etcd. (or just server if cp and etcd will always be combined)

i'm not sure, if it really makes sense, to search for a more abstract / future proof / complicated command line syntax in this particular case?
in fact, we just want to utilize same very simple docker-API "PortBindings" functionality in all of this cases -- isn't it?
i therefore would simply extended the usability of the existing -p/--port command line  -- i.e. make it usable multiple times [for API connectivity and an arbitrary list of ingress ports] and allow "container-port:host-port" pairs for usage scenarios with more than one instance in parallel. this would look rather similar to the expose syntax in dockers CLI resp. a natural and commonly expected simple wrapper behavior.

I agree with you @mash-graz that we could re-use the --port flag, but I think that right now it would break UX, since in the original sense --port X simply mapped port X to the K8s API port in the server container. This functionality we would break by introducing the --port c:h syntax, so we would at least need to find a transitional solution.
I also think like supported by @goffinf that it would be a good thing to narrow it down to node roles, where setting the role would be optional.
@goffinf: I think only --add-port <role>:<port> needs a notion of host and container port.
To stick to the docker syntax I'd go with --add-port <hostport>:<containerport>:role, say "map this port from my host to this port on those nodes".
@mash-graz: any idea how we could transition from our current --port <server-port> syntax to the syntax mentioned above? And would it fulfill your needs?

@iwilltry42 That works for me.

@iwilltry42

any idea how we could transition from our current --port  syntax to the syntax mentioned above? And would it fulfill your needs?

yes -- i also have some doubts concerning the backwards compatibility of such a change.
and indeed, an additional --add-port-option could solve this risk in a very reliable manner.
but is it really neccesarry?

if the -p/--port-option isn't specified on the command line it's interpreted just like a single usage of -p 6433, because s3d is hardly usable without exposing the kubernets API on the default port reachable from the public network.

all other useful invocations of this parameter will need the colon-notation, because they actual ingest port on the container network has to be specified anyway [only the port on host side, i.e. the number after the colon sign could be seen as optional in case of using the same port]. so we just would have to look for the colon-sign resp. differentiate between a single int argument and int:[int]-sequences

users should be even free to use crazy setups like.: k3d create  --server-arg=https-listen-port=8999 -p 8999:6433 (or similar) in the suggested -p/--port syntax without breaking the system logic.

nevertheless i could accept the  --add-port alternative just as well.

You know what? Why not both?
We could create a minor release of 1.x with the --add-port flag and a major release 2.0.0 (which can totally bring in breaking changes) with the extended --port flag.

You're right there, I didn't think of that...
I like you're suggestion with the api-port :+1:

if a working minor release could be realized with any usable solution, i'll be happy. :)
i don't want convince anybody, just help to find a working solution resp. rethink it from another point of view...

How about we change it to --api-port ,-a, which takes a string argument in the form of 'ip:host-port'?

that's an interesting amendment, because in some cases it could indeed make sense to bind the exposed API connectivity to just one specified host-IP/network instead of <IP_ADDRESS> for security reasons!

So to wrap things up, I'd suggest doing the following:
For the next minor release:

add --add-port option
hint on deprecation of --port and breaking change in next major version

For the next major release:

re-use --port, -p flag for generic port mapping in the style of --port <hostport>[:<containerport>][:<node roles>], where default for <node role> would be all and <containerport> would be same as <hostport> if left blank.
introduce --api-port, -a <hostport>[:<containerport>] with old functionality of --port flag

Any final comments on that?
@andyz-dev , are you already working on a PR for this? If not, I'd have time now :+1:

BTW: If you didn't already, you might want to consider joining our slack channel #k3d on https://rancher-users.slack.com :wink:

@iwilltry42  I already have --publish working, just polishing it before sending out the pull request. I will also rename it to --add-port.
I am not working on--api-port, nor on deprecating --port. Please feel free to take them up.

@andyz-dev Alright, I'll base the next steps on the results of your merge, so I don't have to deal with all the merge conflicts :grin:

hmmm... i really like the idea, to prevent the actual CLI behavior till the next major release in semantic versioning conformance, but nevertheless we should try to reduce the needed changes to the bare minimum.
i would:

add --publish  without a short option rigtht now for the ingress forwarding right now (=next minor release)
support --api-port/-a in parallel to the existing/deprecated --port/-p

in this case users could use the new syntax from now on and any revoke or redefinition of --port/-p at one of the next major releases shouldn't affected them.
btw: i was just looking again, how docker interprets all those possible colon separated variants:
https://docs.docker.com/engine/reference/run/#expose-incoming-ports
this myriad of variants is perhaps an overkill for our actual purpose, nevertheless i would at least try to stay somehow close and compatible to this well known conventions...

@mash-graz , yep, like that procedure :+1:
Awaiting @andyz-dev's PR now for --publish or --add-port and will base the other changes on top of that.
Regarding all the possibilities of port-mappings, I'm on your side there that we should stick close to what docker does. Though I'd really like to put the notion of node roles (or at some point in the future also node IDs) in there somehow so that we can specify which nodes should have those ports mapped to the host.

@iwilltry42 @mash-graz  O.K. I will stick with --publish for now, and add --add-port as its alias.

Regarding all the possibilities of port-mappings, I'm on your side there that we should stick close to what docker does. Though I'd really like to put the notion of node roles (or at some point in the future also node IDs) in there somehow so that we can specify which nodes should have those ports mapped to the host.

yes -- it definitely makes sense, to catch the different ways of exposing services in k8s by more adequate/selective forwarding strategies in the long run...

Thanks for the PR #32 @andyz-dev !
@goffinf and @mash-graz , maybe you want to have a look there as well :+1:

thanks @andyz-dev ! :+1:
that's a much more complex patch than expected.
please correct me, if i'm totally wrong, but i don't think, this forwarding of all worker nodes is necessary or useful for typical ingress/LoadBalancer scenarios -- e.g. when k3ds traefik default installation will be utilized. in this case, all the internal routing is already concentrated/bound to just on single IP-addr port pair within the docker context. we only have to forward it from this internal docker network to the real public outer world -- i.e. one of the more common networks of the host.
but again: maybe i'm totally wrong concerning this point? -- please don't hesitate to correct me!
but your approach could make some sense for some of the other network exposing modes of k8s.
although i would at least suggest 1000-steps as port offset in this case to minimize conflicts between other applications -- e.g. daemons listening on privileged standard ports (<=1024).

thanks @andyz-dev ! 👍
that's a much more complex patch than expected.

I feel the same way.  Any suggestion on how to simplify it?

please correct me, if i'm totally wrong, but i don't think, this forwarding of all worker nodes is necessary or useful for typical ingress/LoadBalancer scenarios -- e.g. when k3ds traefik default installation will be utilized. in this case, all the internal routing is already concentrated/bound to just on single IP-addr port pair within the docker context. we only have to forward it from this internal docker network to the real public outer world -- i.e. one of the more common networks of the host.

In the product we are working on, we need our LB to run on the worker nodes. For HA, we usually run more than 2 LBs.  I think there is a need to exposing ports on more than one worker nodes.
I agree with you that exposing ports on all works is overkill.  Would the "node role" concept proposed by @iwilltry42 work for you? May be we should add it soon.

but again: maybe i'm totally wrong concerning this point? -- please don't hesitate to correct me!
but your approach could make some sense for some of the other network exposing modes of k8s.
although i would at least suggest 1000-steps as port offset in this case to minimize conflicts -- e.g. other daemons listening on privileged standard ports (<=1024).

Notice we are only stepping the host ports.
May be we can add a --publish-stepping option. Then again,  this may be a moot point with "node role"

@mash-graz I agree with you there, it got way more complex than I first expected it to be.
But I cannot think of a simpler solution than what @andyz-dev did (good job!).
I already worked on combining his solution with the node role (and regexp validation of input), but it will make the whole thing even more complex (but also cool).
I'd go with an extended docker syntax like ip:hostPort:containerPort/protocol@node where only containerPort is mandatory and @node can be used multiple times (either node role or node name, while all is default).
For the port clashes I was thinking of something like a --auto-remap flag instead of doing it by default?
We could even go as far as automatically checking if ports are already being used with a simple net.Listen() to avoid crashes.

My 4 cents on complexity ... and forgive me for stating the obvious.
The experience for a Dev and for and Ops should be largely similar in terms of configuration and deployment as for any Kubernetes installation. This isn’t some ‘hello-world’ demo environment but intended to be ‘production ready’ at least for edge devices (although personally I don’t draw any distinction or try an pigeonhole k3d/k3s in that way).
In my case, and I suspect many others, I need to provide a local Kubernetes environment for all the application developer teams that are migrating existing apps into a micro-services / container based solutions architecture, and to support the majority of new apps that we build. For that environment to be genuinely useful we need to be able to use the same set of Kubernetes constructs to deploy and expose workloads and use the same automation thru build and deploy pipelines as we do for our hosted environments. Without that it will just create a misalignment which I suspect will relegate k3d to ‘just for demos and training’. That’s not what I need, there are plenty of those tools available already.
So a key aspect is being able to route external traffic into this local cluster through external load balancers and Ingress. That’s what we do ‘in the wild’, so that’s what we need to do here. I am aware we could use NodePort or host port mapping, but we don’t use that approach much, so for me, Ingress is the preferred option. I want to rock up to my local k3d cluster and run my cluster config scripts and my application helm install (the exact same ones I use in Production - give or take), and a few seconds later be doing Development work or running integration tests, whatever.
So .... from a complexity perspective, tool chain builders always get the most challenging work to do, but the benefit is to the thousands of others who consume the platform and don’t care how the magic happens and complain when it doesn’t or it behaves differently in some (sometimes small and acceptable) way. Such is the lot for those of us that build tools for others, but it’s the most exciting job of all.
Please don’t see this as a rant against k3d or the difficult choices in terms of what needs to be supported or not, and which features have priority. I am massively appreciative of the work and integrity of everyone who is contributing whether that’s code or comments. I just wanted to orient my ‘ask’ in such a way that clearly says that I don’t really want to be in a position of introducing k3d to my dev teams by starting off with all the things that it doesn’t support or worse, does support but completely differently to the next environment along.
Like many others we believe in the whole immutable concept ‘cool-ade’ and would be loathed to move from that position and maintain different solutions for the same ‘thing’.
HTHs
Fraser.

Thanks for the explanation @goffinf , but I think that you don't need to justify yourself.
I'm totally on your side there, I'd value functionality over complexity as well :+1:
Originally I built k3d from @zeerorg's idea, just because the other tools like kind, minikube, etc. didn't fulfill my needs for local development... so I guess we have similar needs there ;)

i think, we all agree on the perspective and criteria expressed by @goffinf. we just have to find a sufficient solution to realize this challenging demands also in practice.
i still see typical ingress and LB setups utillizing a single 'Endpoint'-entry as the most realistic usage scenario. this kind of simple one [external] port A -> one [docker] port B mapping should be therefore supported without to much confusing implementation overheap and rethinking on the users side.
maybe we could archive this goal by just stipulate the proposed role "master" instead of "all" as the default behavior to get just this simple one-to-one mapping for k3s. nevertheless i have my doubts, if this really works for multi master clusters and it also doesn't really correspond to the intended semantics of this role-notation.
if we really want to support other network exposing capabilities of k8s beside this relative simple one-to-one ingress scenarios, we may have indeed be forced to forward and map the ports from all worker nodes to the host. nevertheless is would see this kind of network access translation as more or less only unsefull for test and development purposes, because it differs to much from the internal topology and addressing. it's IMHO just a workaround to get access to more fancy k8s internals and networking exposing capabilities, but from my point of view it doesn't seem to be necessary for more common practical usage scenarios.
i also wouldn't underestimate all the necessary provisions to support dynamic changes in this case -- i.e. add and remove worker nodes -- and update the port mapping in a consistent manner during all this changes.
the same could be expressed for more demanding/exotic HA/LB setups, which IMHO can not be simple 'simulated' resp. transferred to docker environments and arbitrary bundles of incremented numbered ports, but would need at least multiply [virtual] IP endpoints on the host side as well to work as expected in this kind of translated contexts.
but again -- maybe i really don't get the point?

Merged PR #34 by @andyz-dev (Thank you!).
Pre-Release with the --publish/--add-port flags pushed: https://github.com/rancher/k3d/releases/tag/v1.2.0-beta.0

I will base my work of adding the notion of node roles on top of that.

thanks @iwilltry42 for this beta!
i'll try to test it tonight...
but could you please elaborate a little bit more about your idea concerning this "role" specifier?
should it be understood just as a kind of label based selection mechanism, which would e.g. allow to expose only ports for a subset of services, or is it more intended as a flag, which helps do handle the various available "Types" of k8s network exposure by different and in each case adequate means (e.g. selectively bind it only to the desired network within the docker context)?
its perhaps also useful to find a sufficient documentation string resp. explanation for the default behavior (i.e. when 'role' isn't explicitly specified).
thanks

You're welcome @mash-graz , but the credits should go to our new collaborator @andyz-dev who implemented it :+1:
The "role" specifier is nothing that complex. It's only to map ports only from certain types of nodes that you create with k3d. Let's call it node-specifier from  now on.
Then you could e.g. write --publish <IP_ADDRESS>:1234:4321/tcp@workers to map port 4321 from the worker nodes (containers in k3d) to localhost (for now by using the offset to avoid port clashes) or --publish 3333@k3d-mycluster-worker-1@k3d-mycluster-worker-2 to map 3333 from the two specified nodes to localhost. So the specifier could be either one of server, workers, all or <node-name>.
Default would then be all which makes the whole thing backwards compatible to what we have right now with the beta.
But feel free to drop suggestions on what you would expect :+1:

You're welcome @mash-graz , but the credits should go to our new collaborator @andyz-dev who implemented it +1

sorry -- i had the impression, that you merged improvements from your "new-publish" branch as well.
and frankly, i like those additional changes much more, than the original PR proposed by @andyz-dev, because his implementation IMHO simply ignores the specific needs of a sufficient k8s "ingress" handling.
concerning your node-specifier i'm still contemplating, if it looks useful/worthwhile to me?
at least it opens some capabilities, which simply couldn't realized otherwise...
nevertheless i would see a more sufficient consideration of the different expose variants and their proper handling as much more important. but i don't think, this can/should be handled/accomplished/intermixed with your proposed notation.

a few additional considerations concerning the security impact of this feature:
i don't think, we should forward/expose any network ports or network traffic, belonging to interfaces, which are conceptually understood as only internally accessible in k8s (e.g. bound to the ClusterIP).
only those network endpoints, which are intended as public accessible via ExternalIPs in k8s should be available outside of k3ds docker cage and forwarded by this feature! everything else should be still isolated from the outer world resp. only accessible via more sophisticated and secure mechanism, like kubectl proxy!
i think, we really should respect this very important general security requirement, otherwise we will make nonsense of k3ds main goal and work against the idea of reliable sandbox utilization.
k3d should be useful tool to encapsulate a working cluster installation and naturaly provide access to its public network endpoints -- just like the real thing! --, but it shouldn't go further and undermine important k8s security concepts.

I  like the node-specifier concept in general. I am fine with 'all', 'server' and 'workers'.  Since the  is something internally generated, user may not know what it is until it has been generated (In theory, we could even change the way it is generated from release to release). How about we also allow a number as a valid node name specifier.
For example, to create a five node cluster with the first two work nodes as ingress nodes, the k3d command line will look like:
k3d create --workers 4 --publish 8080:80@0@1
It will be shorter and easier to type as well.
For my eyes, the following is a bit easier to read than above:
k3d create --workers 4 --publish 8080:80[0,1]

hmm... i'm definitely not happy with all this questionable workarounds:
therefore a new proposal:
shouldn't we simply implement a command line option to enable the NetworkMode=host just as we could set it in dockers CLI.
unfortunately this docker feature isn't available resp. working on macOS and windows, but on linux it would make the cluster accessible from the outside on the common network device of the host system resp. use the public host IP as External-IP within k8s .
because k8s does almost only utilize private address space internally, this option wouldn't induce much harm -- i personally would say: less than dirty ambiguous port forwarding. nevertheless users could still enable all sorts of direct access to specific nodes and their ports from within k8s by well defined and already available control options in this case.
how do you think about this kind of alternative solution?

@mash-graz, I don't follow the objections raised above. So let me make an attempt to understand better. If the following are obvious, apologies in advance.
If  the main goal to implement one host port to one docker port for a k3s cluster.
The following should create the desired cluster:
$ k3d create --publish 8080:80
k3s by default comes with traefik ingress controller that listens on port 80. Ingress rules can be configured via the normal k8s way (i.e. via yaml file).  Once ingress is configured ,
$ curl http://localhost:8080/xxxxx .   should just work.
If one needs a larger cluster, but only one ingress node, something list the follow can work (needs @iwilltry42's changes to merge in).
$ k3d create --publish 8080:80@server --workers 5
If one needs a larger cluster, but two ingress nodes (for HA), then the following can work
$ k3d create --publish 8080:80@server@0 --workers 5
If the goal is to provide remote access to k3d cluster. The the following should work, assume the desired remote routable IP.
$ k3d create --publish :8080:80
On the other hand, if the goal is not to provide any remote access to the k3d cluster, but only use it for local development and testing
$ k3d create --publish <IP_ADDRESS>:8080:80
I understand and agree that node port and host port are not commonly used, but they are valid k8s configurations. To be honest, I don't see a down side in supporting them, in addition to the common use cases we mostly care about.
Or probably you have some other ingress use cases in mind?

I don’t have any objection to supporting nodeport and host port mapping. But I don’t think we should assume that they are the same as Ingress other than in a very generalised sense. I want to be able to support the Kubernetes Ingress object, not a simulation of it.
Currently in k3s (in its docker implementation), Ingress is only supported through a specific port mapping in the compose file and that doesn’t work if you have more than ONE worker. There is an open issue for that, which I was rather hoping that k3d would address given that it’s focus is the docker implementation specifically.
Some of the discourse above has started to venture into much more significant customisation and as others have said this is very likely to give rise to all sorts of edge cases to mange which would move k3d from being a light-Weight wrapper to k3s to something more uncomfortably substantial I think .. not sure .. but I see some early warning signs of creeping complexity.
I still think the role type has some legs since in many cases I don’t want to expose application ports on the server node.
Certainly some of @andyz-dev examples look pretty simple. I’m not 100% convinced about using a node ordinal (a name maybe ok though).

your explanation looks correct and plausible, but it still doesn't convince me anymore.
when we started this debate, i also simply thought, that this issue could be solved by a simple workaround and a few injected port forward instructions at least for trivial typical usage scenarios. but after watching your attempts, to stress this possibilities much wider and bypass lots of abstractions and indirection utilized by a clean k8s system, i simply had to change my mind. you somehow demonstrated convincingly why we shouldn't take this path...
if you look at the behavior of k3d without your patch on a linux system, you see, that it is already using ExternalIPs resp. providing access from the host via the docker0 bridge:
k3s$ kubectl get svc -n kube-system
NAME       CLUSTER-IP     EXTERNAL-IP    PORT(S)                      AGE
kube-dns   <IP_ADDRESS>     <none>         53/UDP,53/TCP,9153/TCP       3d
traefik    <IP_ADDRESS>   <IP_ADDRESS>   80:32448/TCP,443:31643/TCP   3d

and http access works, if you utilize this particular IP:
~$ wget -O- http://<IP_ADDRESS>
--2019-05-10 01:51:58--  http://<IP_ADDRESS>/
Connecting to <IP_ADDRESS>:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-05-10 01:51:58 ERROR 404: Not Found.

it's just a pity, that it is only listening on docker0 and not on our usual network, which would obviate the need for any further routing solution or redirection. but on the other hand, that exactly what we should expect and like about docker and similar sandboxing environments: it isolates the networks!
so it's really just a question, how we can overcome this particular behavior, without to much side effects and unforeseeable troubles. we don't need a super strong brute force approach, which bypasses most of k8s fundamental network principles, but a nice, clean and simple solution to just enable this communication between the public network and already designated external IP communication endpoints in k8s.
giving all this worries and dissatisfaction concerning port gambling solutions, i'm more and more thinking about this already expressed other alternative. it also looks like a more promising strategy to overcome dynamic changes and reconfiguration within the clusters, which can not be handled in a sufficient manner by our one shot docker configuration attempts.

@goffinf Thanks for the input. Is there a reference to the issue you mentioned on k3s not being able to support more than one ingress node? I'd like to take a closer look and make sure multiple node input works on k3d. We should probably also take a fresh look at the ingress from top down (instead of coding up) to make sure the end result works for the community.
@mash-graz  Thanks for the input, I do value them very much and the end solution will be better if we think about them collectively.  That's why @iwilltry42 made the pre-release available so that more folks can try it out and provide feed backs. FWIW, from tip of the master, on MAC OS, the show svc of traefik also gave the external IP of docker0,  (on MAC docker0 runs inside a VM, of course).  Sounds like you are already thinking of an alternative design, If helpful, I will be happy to continue the discussion (may be we can make use of the slack channel), or be a sounding board to help you flush out your design ideas.

Hey there, now that was a long read :grin:
I was a bit busy in the last days, but now I took the time to read through all the comments again to figure out what's the best thing to do.
So as far as I understand the main risk/concern in the current approach is that we expose ports with on each k3d node (containers) with an auto-offset on the host.
Since we often don't need this, this could just introduce security issues.
The main goal of this should be to support single hostport to single containerport bindings to e.g. allow ingress or LB port forwarding for local development.
Since the portmapping is the most flexible thing that we can do at creation time without too much engineering extra-overhead, I think we should stick with it, but in a different way then now.
I would still propose to enhance the docker notation with the node specifier, i.e. [<ip>:][<host-port>:]container-port[/<protocol>]@<node-specifier>, where container-port and node-specifier are mandatory (first change). The auto-offset of host ports would then be an optional feature (e.g. --port-auto-offset) and 1:1 port-mapping will be emphasized by enforcing the node-specifier in --publish.
Still, I think that @mash-graz idea of somehow connecting to the docker network is a super cool idea and I think that we might be able to support this at some point when we've had more time for researching it.
The network-mode=host feature we could add with a hint that it will only work for Linux users.
I think there are more people interested in this (#6).

After the first easy implementation, we can think of further getting rid of auto-offset, e.g. by allowing port ranges for host-port, so that we will generate a 1:1 mapping out of a single flag.
E.g.

we pass --workers 5 --publish 6550-6554:1234@workers to have port 1234 of each worker mapped to the host
We get <IP_ADDRESS>:6550:1234/tcp@worker-0, <IP_ADDRESS>:6551:1234/tcp@worker-1, ..., <IP_ADDRESS>:6554:1234/tcp@worker-4
Since this requires quite a bit more code and thoughts, I will keep it out of my initial PR.

thanks @iwilltry42 for preparing this patch!

So as far as I understand the main risk/concern in the current approach is that we expose ports with on each k3d node (containers) with an auto-offset on the host.
Since we often don't need this, this could just introduce security issues.
The main goal of this should be to support single hostport to single containerport bindings to e.g. allow ingress or LB port forwarding for local development.

yes -- that's more or less my point of view too. :)
we should really try to concentrate on this simple one-to-one port mapping (LB/ingress), although the more complex case (auto offset...) should be supported as good as possible.

I would still propose to enhance the docker notation with the node specifier, ... , where container-port and node-specifier are mandatory.
does it really make sense, to require the node-specifier as mandatory field?

if we understand the one-to-one port mapping case as the most common usage scenario, we can simple suppose it as the default mode of operation, as long as no other node specifier is explicitly given on the command line.
this would make it easier to use resp. needs less lengthy command line options in practice.
i still see the problem, how the one-to-one port mapping can be specified in an unambiguous manner by the proposed notation?
a ...@server will only work for single master clusters, but in the future, when k3s will finally be able to support multi master clusters as well, it unfortunately will not signify a unique node resp. a one-to-one mapping  anymore...
i guess, it's kind of fundamental misunderstanding or oversimplification, if we presuppose a congruence between docker container entities and k8s more complex network abstraction. both accomplish orthogonal goals by different means. utilizing port mappings/forwarding in workarounds to satisfy some practical access requirements, should be always seen as rather questionable and botchy cutoff.
there are already some interesting tools and improvements of kubectl port-forward available, which seem to solve similar kinds of network routing and node access in a comfortable and k8s idiosyncrasies respecting fashion:
https://github.com/txn2/kubefwd
https://github.com/flowerinthenight/kubepfm
they are most likely a more suitable choice, if one wants to handle demanding network access to remote clusters and k3s running within docker or VMs. in comparison with our docker specific approach this kind of solution comes with a few pros and cons:
pros:

much cleaner and unambiguous access to k8s services
works even in case of dynamic changes happening in the cluster

cons:

they need root privileges to forward privileged ports
it's a little bit less effective and slower in comparison to other variants of direct access
it can be only used, when the cluster is already running

The network-mode=host feature we could add with a hint that it will only work for Linux users.

yes, i still think this variant could be a worthwhile and extraordinary user friendly option on linux machines. i'll try to test it and prepare a PR for this feature as soon as possible.

I've had limited success with kubefwd, which I also thought might have some legs for this problem (having Kelsey Hightower endorse a product must give it some street creds I suppose). Anyway, my environment is Windows SubSystem for Linux (WSL). I appreciate that's not the case for everyone, but in corporates' its pretty common.
Running kubefwd in a docker container, even providing an absolute path to the kubeconfig just results in connection refused ...
docker run --name fwd -it --rm -v $PWD/.kube/config:/root/.kube/config txn2/kubefwd services -n default
2019/05/13 23:27:21  _          _           __             _
2019/05/13 23:27:21 | | ___   _| |__   ___ / _|_      ____| |
2019/05/13 23:27:21 | |/ / | | | '_ \ / _ \ |_\ \ /\ / / _  |
2019/05/13 23:27:21 |   <| |_| | |_) |  __/  _|\ V  V / (_| |
2019/05/13 23:27:21 |_|\_\\__,_|_.__/ \___|_|   \_/\_/ \__,_|
2019/05/13 23:27:21
2019/05/13 23:27:21 Version 1.8.2
2019/05/13 23:27:21 https://github.com/txn2/kubefwd
2019/05/13 23:27:21
2019/05/13 23:27:21 Press [Ctrl-C] to stop forwarding.
2019/05/13 23:27:21 'cat /etc/hosts' to see all host entries.
2019/05/13 23:27:21 Loaded hosts file /etc/hosts
2019/05/13 23:27:21 Hostfile management: Backing up your original hosts file /etc/hosts to /root/hosts.original
2019/05/13 23:27:21 Error forwarding service: Get https://localhost:6443/api/v1/namespaces/default/services: dial tcp <IP_ADDRESS>:6443: connect: connection refused
2019/05/13 23:27:21 Done...

I know that kubeconfig works ...
kubectl --kubeconfig=$PWD/.kube/config get nodes
NAME                       STATUS   ROLES    AGE     VERSION
k3d-k3s-default-server     Ready    <none>   6h38m   v1.14.1-k3s.4
k3d-k3s-default-worker-0   Ready    <none>   6h38m   v1.14.1-k3s.4
k3d-k3s-default-worker-1   Ready    <none>   6h38m   v1.14.1-k3s.4
k3d-k3s-default-worker-2   Ready    <none>   6h38m   v1.14.1-k3s.4

Using the binary was better and did work ...
sudo kubefwd services -n default

2019/05/14 00:32:44  _          _           __             _
2019/05/14 00:32:44 | | ___   _| |__   ___ / _|_      ____| |
2019/05/14 00:32:44 | |/ / | | | '_ \ / _ \ |_\ \ /\ / / _  |
2019/05/14 00:32:44 |   <| |_| | |_) |  __/  _|\ V  V / (_| |
2019/05/14 00:32:44 |_|\_\\__,_|_.__/ \___|_|   \_/\_/ \__,_|
2019/05/14 00:32:44
2019/05/14 00:32:44 Version 1.8.2
2019/05/14 00:32:44 https://github.com/txn2/kubefwd
2019/05/14 00:32:44
2019/05/14 00:32:44 Press [Ctrl-C] to stop forwarding.
2019/05/14 00:32:44 'cat /etc/hosts' to see all host entries.
2019/05/14 00:32:44 Loaded hosts file /etc/hosts
2019/05/14 00:32:44 Hostfile management: Original hosts backup already exists at /home/goffinf/hosts.original
2019/05/14 00:32:44 WARNING: No backing pods for service kubernetes in default on cluster .
2019/05/14 00:32:44 Forwarding: nginx-demo:8081 to pod nginx-demo-76d6b7f896-855r2:80

and a curl FROM WITHIN WSL works ...

curl http://nginx-demo:8081
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

HOWEVER ... http://nginx-demo:8081 is NOT available from the host (from a browser) itself unless you update the Windows hosts file to match the entry in /etc/hosts (WSL will inherit the Windows hosts file on start-up but doesn't add entries to it as it does with /etc/hosts) .... e.g.
You need to add this to /c/Windows/System32/drivers/etc/hosts (which is waht kubefwd added to /etc/hosts in this example)
<IP_ADDRESS>              nginx-demo nginx-demo.default nginx-demo.default.svc.cluster.local
In some ways this is WORSE that kubectl forward since at least there I can access the service on localhost:8081 without needing to mess with the Windows hosts file.
So TBH, neither of these is especially attractive to me even if they do leverage features native to the platform.
@iwilltry42 I'll try out your patch tomorrow (I have a bot of time of work).
I do agree with much that @mash-graz has said, but I'm minded to at least move forwards even if what is implemented now becomes redundant later on.

Running kubefwd in a docker container, even providing an absolute path to the kubeconfig just results in connection refused ...

 docker run --name fwd -it --rm -v $PWD/.kube/config:/root/.kube/config txn2/kubefwd services -n default
 ...
 2019/05/13 23:27:21 Error forwarding service: Get https://localhost:6443/api/v1/namespaces/default/services: dial tcp <IP_ADDRESS>:6443: connect: connection refused

I know that kubeconfig works ...

your kubeconfig seems to use an API server entry, which points to localhost:6443.
this will only work on your local machine and not for remote access to your cluster. using virtual machines envrionments or docker sandboxes, have to be seen as kind of remote access in this respect. localhost doesn't connect the same machine in this contexts...
just edit the server entry of your kubeconfig and use the IP of your machines network card instead.
concerning the mentioned windows hosts-file synchronization issues, i would answer: yes, it's just another dirty workaround.
but this mechanism does have same important advantages in practice too. faked name entries like this are nearly indispensable, if you have to develop and test services behind L7 reverseproxies resp. name based dispatching. just forwarding ports to arbitrary IPs doesn't work in this case.
but again: it's just another tricky workaround, and by no means a clean and exemplary solution. ;)

Thanks for the feedback!
@mash-graz  So you would make @server the default for the time that we don't have HA (= multiple masters) in k3s? As soon as we get HA mode, we could think of adding a loadbalancer in front so that we don't have multiple host ports open for the same ports on the master nodes.
Also, I'll have a look into the two projects you mentioned :+1:
@goffinf , maybe WSL2 will bring you some improvements soon :wink:

@mash-graz So you would make @server the default for the time that we don't have HA (= multiple masters) in k3s? As soon as we get HA mode, we could think of adding a loadbalancer in front so that we don't have multiple host ports open for the same ports on the master nodes.

yes -- i definitely would make it the default behavior!
it may look a little bit crazy and ignorant, that i'm still insisting on this particular little implementation detail, but i think it makes indeed an important difference for end-users. in most cases they'll only want to forward LB/ingress http/s access on standard port 80 and 443 on the host side -- that's at least my expectation -- , and this trivial usage scenario should be supported as simple as possible. it shouldn't need any unfamiliar and complex command line options and just work reliable and as expected by common mind out of the box.

Also, I'll have a look into the two projects you mentioned

this other alternatives do not render our port forwarding efforts redundant, because they are more designed to realize save remote access to a cluster, instead of just making ports accessible on the public network -- i.e. they accomplish a slightly different purpose --, nevertheless it's interesting to study, how they overcome some of the obstacles and ambiguities related to this forwarding challenge.

Your reasoning makes total sense @mash-graz , so I updated the default node to server in my PR #43

@mash-graz just following up with your comment ....

... your kubeconfig seems to use an API server entry, which points to localhost:6443. ... just edit the server entry of your kubeconfig and use the IP of your machines network card instead

Unfortunately that doesn't appear to work. No kubectl commands succeed with that amendment and WSL also crashes. Obviously the default for k3s is localhost.
I thought that I might be able to pass this via the bind-address server arg as you can with k3s,..
sudo k3s server --bind-address <IP_ADDRESS> ...
but I couldn't see anything in the k3d docs which suggests how k3s server args are exposed. Do you know ?

@iwilltry42 So I have installed v1.2.0-beta.1 and run k3d with this ...
k3d create --publish 8081:8081@server --workers 2
I can see port 8081 published on the server ..
docker container ls -a
CONTAINER ID        IMAGE                COMMAND                  CREATED              STATUS              PORTS                                            NAMES
c367af69df28        rancher/k3s:v0.5.0   "/bin/k3s agent"         59 seconds ago       Up 56 seconds                                                        k3d-k3s-default-worker-1
0211bedcfb27        rancher/k3s:v0.5.0   "/bin/k3s agent"         About a minute ago   Up 58 seconds                                                        k3d-k3s-default-worker-0
e30c8789d6da        rancher/k3s:v0.5.0   "/bin/k3s server --h…"   About a minute ago   Up About a minute   <IP_ADDRESS>:6443->6443/tcp, <IP_ADDRESS>:8081->8081/tcp   k3d-k3s-default-server

I have a deployment and service for nginx where the service is listening on 8081
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo
  labels:
    app: nginx-demo
spec:
#  type: NodePort
  ports:
    - port: 8081
      targetPort: 80
      name: http
  selector:
    app: nginx-demo

Would you expect to be able to successful call that service on 8081. If I try curl ...
curl http://localhost:8081 -v
* Rebuilt URL to: http://localhost:8081/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 8081 (#0)
> GET / HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.58.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host localhost left intact

What am I missing ?
Thanks
Fraser.

@mash-graz just following up with your comment ....

... your kubeconfig seems to use an API server entry, which points to localhost:6443. ... just edit the server entry of your kubeconfig and use the IP of your machines network card instead

Unfortunately that doesn't appear to work. No kubectl commands succeed with that amendment and WSL also crashes. Obviously the default for k3s is localhost.
I thought that I might be able to pass this via the bind-address server arg as you can with k3s,..
sudo k3s server --bind-address <IP_ADDRESS> ...
but I couldn't see anything in the k3d docs which suggests how k3s server args are exposed. Do you know ?

You can pass k3s server args to k3d using the --server-arg/-x flag.
E.g. k3d create -x "--bind-address <IP_ADDRESS>" or k3d create -x --bind-address=<IP_ADDRESS>

@iwilltry42 So I have installed v1.2.0-beta.1 and run k3d with this ...
k3d create --publish 8081:8081@server --workers 2
I can see port 8081 published on the server ..
docker container ls -a
CONTAINER ID        IMAGE                COMMAND                  CREATED              STATUS              PORTS                                            NAMES
c367af69df28        rancher/k3s:v0.5.0   "/bin/k3s agent"         59 seconds ago       Up 56 seconds                                                        k3d-k3s-default-worker-1
0211bedcfb27        rancher/k3s:v0.5.0   "/bin/k3s agent"         About a minute ago   Up 58 seconds                                                        k3d-k3s-default-worker-0
e30c8789d6da        rancher/k3s:v0.5.0   "/bin/k3s server --h…"   About a minute ago   Up About a minute   <IP_ADDRESS>:6443->6443/tcp, <IP_ADDRESS>:8081->8081/tcp   k3d-k3s-default-server

I have a deployment and service for nginx where the service is listening on 8081
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo
  labels:
    app: nginx-demo
spec:
#  type: NodePort
  ports:
    - port: 8081
      targetPort: 80
      name: http
  selector:
    app: nginx-demo

Would you expect to be able to successful call that service on 8081. If I try curl ...

With the Manifest above I wouldn't expect it to work, since NodePort is commented out, so no port is exposed on the node. But even then, NodePort range is 30000-32767, so one of those ports has to be set and exposed for it to work.

curl http://localhost:8081 -v
* Rebuilt URL to: http://localhost:8081/
*   Trying <IP_ADDRESS>...
* TCP_NODELAY set
* Connected to localhost (<IP_ADDRESS>) port 8081 (#0)
> GET / HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/7.58.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host localhost left intact

Added an Ingress (no change) ...
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-demo
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: nginx-demo
          servicePort: 8081

What am I missing ?

You didn't map the ports for ingress, so that wouldn't work as well. I'll create a demo for this :+1:

You can pass k3s server args to k3d using the --server-arg/-x flag.
E.g. k3d create -x "--bind-address <IP_ADDRESS>" or k3d create -x --bind-address=<IP_ADDRESS>

yes -- that's the correct answer to question, but i don't think, it will solve the troubles described by @goffinf.
it doesn't matter to which IP the k3s server API is bound inside the container, because from the outside it's always reached via this port forwarding internally specified by k3d (<IP_ADDRESS>:6443->6443/tcp) which maps it to all interfaces on the host side by this <IP_ADDRESS> notation. it should be therefore reachable on the host as https://localhost:6443 just as by using the public server name resp. one of the external IPs of the machine.
perhaps @goffinf is fighting some windows/WSL specific issues, but on linux i do not have any troubles to reach the API from outside of k3ds docker instance, neither locally on the host nor by remote  access, and it doesn't make a difference if kubectl is used or kubefwd.

@goffinf this is a simple example of what I tested with k3d (on Linux):

Create a cluster, mapping the ingress port 80 to localhost:8081
k3d create --api-port 6550 --publish 8081:80 --workers 2

Get the kubeconfig file
export KUBECONFIG="$(k3d get-kubeconfig --name='k3s-default')"

Create a nginx deployment
kubectl create deployment nginx --image=nginx

Create a ClusterIP service for it
kubectl create service clusterip nginx --tcp=80:80

Create an ingress object for it with kubectl apply -f

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - http:
      paths:
      - path: /
        backend:
          serviceName: nginx
          servicePort: 80

Curl it via localhost
curl localhost:8081/

That works for me.

@goffinf or the same using a NodePort service:

Create a cluster, mapping the port 30080 from worker-0 to localhost:8082
k3d create --publish 8082:30080@k3d-k3s-default-worker-0 --workers 2 -a 6550

...

Create a NodePort service for it with kubectl apply -f

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  ports:
  - name: 80-80
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: NodePort

Curl it via localhost
curl localhost:8082/

@iwilltry42 I can confirm that using the latest version (1.2.0-beta.2) that the Ingress example works as expected with WSL. I can use curl localhost:8081 directly from WSL and within a browser on the host.
Moreover Ingress works using a domain also. In this case I created the k3d cluster and mapped port 80:80 for the server (default) providing access to the Ingress Controller ..
k3d create --publish 80:80 --workers 2
...
docker container ls
CONTAINER ID        IMAGE                COMMAND                  CREATED             STATUS              PORTS                                        NAMES
eedb8c962387        rancher/k3s:v0.5.0   "/bin/k3s agent"         30 seconds ago      Up 27 seconds                                                    k3d-k3s-default-worker-1
96ca910c7949        rancher/k3s:v0.5.0   "/bin/k3s agent"         32 seconds ago      Up 29 seconds                                                    k3d-k3s-default-worker-0
e10a95dc10b4        rancher/k3s:v0.5.0   "/bin/k3s server --h…"   34 seconds ago      Up 32 seconds       <IP_ADDRESS>:80->80/tcp, <IP_ADDRESS>:6443->6443/tcp   k3d-k3s-default-server

Then defined the deployment, service and ingress as follows (noting the ingress now defines the host domain) ...
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-demo-dom
  labels:
    app: nginx-demo-dom
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-demo-dom
  template:
    metadata:
      labels:
        app: nginx-demo-dom
    spec:
      containers:
      - name: nginx-demo-dom
        image: nginx:latest
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: nginx-demo-dom
  labels:
    app: nginx-demo-dom
spec:
  ports:
    - port: 8081
      targetPort: 80
      name: http
  selector:
    app: nginx-demo-dom
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: nginx-demo-dom
  annotations:
    ingress.kubernetes.io/ssl-redirect: "false"
spec:
  rules:
  - host: k3d-ingress-demo.com
    http:
      paths:
      - backend:
          serviceName: nginx-demo-dom
          servicePort: 8081

Using curl the services was reachable ..
curl -H "Host: k3d-ingress-demo.com" http://localhost

<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

So congrats, the publish capability and Ingress are working fine and very naturally iro k8s. Great work
Regards
Fraser.

@iwilltry42 In your example which now appears on the github README, was there a reason you chose to use the --api-port arg (it doesn't seem to materially impact whether the example works or not, so I wasn't sure if you were showing that for some other reason ?)
k3d create --api-port 6550 ...

Hey @goffinf , thank you very much for your feedback and for confirming the functionality of the new feature!
No, it was just that 6443 is constantly in use on my machine and I just left it in there so that people see the --api-port flag instead of the --port flag which we want to "deprecate" (i.e. change functionality).
Do you think it's too confusing? Then I'd rather remove it :+1:

Haha, beat me to it. I was going to suggest that it would not be confusing if you added a note.
In general I prefer plenty of examples that show off one, or a small number of features, rather than a single example that has everything packed into it, especially where there might be a difference in behaviour for particular combinations. You’ve done that now, so that’s perfect.
Talking of documentation and examples, the question I asked a few days ago around passing additional server args is I think worth documenting (i.e. using —server-arg or -x) and provides an opportunity to talk briefly about the integration between k3d and k3s. I don’t know whether it’s possible to mirror every k3s arg or not (if that is the case you could simply link through to the k3s docs rather than repeat it all I guess) ?
I suspect others might also be interested in how, or indeed if, k3d will track the life-cycle of k3s and respond as/if/when new features are added or changed. IMO that’s an important consideration when selecting tools that app devs might adopt for a variety of reasons. Whilst everyone accepts the ephemeral nature of open source projects and, as in this case, if the user experience is relatively intuitive such that the skills investment isn’t high, it’s less of a concern, but ... it’s still nice to back tools that have a strong likelihood of a longer shelf-life and an active community. Just a thought.
I note the new FAQ section. Happy to help out here although I am aware of how important it is to ensure that all docs are accurate and up-to-date.

Well... with --server-arg you can pass any argument to the k3s server... but if it will work in the end, we cannot verify.
It'd be a huge amount of additional work to ensure/verify that all the k3s settings are working in a dockerized environment. E.g. to support the docker flag --docker for k3s, you'd have to put it in a dind image and/or pull through the docker socket from the host system.
Anyways, I'm totally in for adding additional documentation and would be super happy about your contributions to them, since you appear to be a very active user :)
Maybe we can come to the point where we'll be able to create a compatibility matrix for k3d and k3s :+1:

Precisely. I spend a good deal of time at my place of employment writing up a variety of docs, from best practice guides and standard prototypes to run books. I can’t claim to be brilliant at it, but I do recognise the importance of clear information which illustrate through descriptions and examples the key use cases, and, importantly set out the scope. The latter plays to your comment about any potential tie-in (or not) with k3s, since many no doubt view k3d as a sister project or one that implies some level of dependency. I think it would be good to set that out and the extent to which that is true, perhaps especially so as docker as a container run-time has somewhat less focus these days (you can take Darren’s comment about k3s ... of course I did a DinD implementation .. in a couple of ways I guess).
I have noted from our conversations and other issues, both here and on k3s and k3os (I tend to read them all since there is much to be learned from other people’s concerns, as well as an opportunity to help sometimes) that there is still a level of ‘hidden’ configuration that is not obvious. That is not to say it’s deliberate, it most often to do with the time available to work on new features vs. documenting existing ones, and of course an assumed level of (pre) knowledge.
Anyways, I am active because I think this project has merit and potential for use by me and my work colleagues. So anything I can do to help I will.
I note Darren commented recently that WSL2 and k3d would be a very satisfactory combination, and I agree. But, since we aren’t in the business of vapourware, there’s still much to offer without WSL2 imo.
I think the next non-rc release might provide a good moment to review docs and examples.

I'm looking forward to your contributions to k3d's docs :)
Maybe we can open a new issue/project for docs, where we can add parts, which users might like to see there :+1:
Anyways... I think this issue is growing a bit too big. I guess the main painpoint of this issue has been solved, right? So can it be closed then?

The network-mode=host feature we could add with a hint that it will only work for Linux users.
yes, i still think this variant could be a worthwhile and extraordinary user friendly option on linux machines. i'll try to test it and prepare a PR for this feature as soon as possible.

i finally could figure out an implementation of this alternative manner to expose the most common network access variants by a simple --host/--hostnetwork option and opened PR #53.
it has some pros (e.g. you don't have to specify all the ports resp. can be reconfigure them via k8s mechanism), but also cons (e.g. it will most likely only work on the linux platform).
in fact it's only exposing the server on the host network, because remapping multiply workers resp. their control ports on one machine isn't a trivial taskt. connecting the workers to server on the host network is also a bit tricky, because most of dockers internal name services do not work across different networks or aren't available on linux machines. i therefore had use the gateway IP of our custom network as workaround to reach the host...
i'm not sure, if it is really a useful improvement, after all this wonderful recent port mapping improvmenst, developed be @iwilltry42 and @andyz-dev, nevertheless i would be happy, if you could take a look at it.

Thanks for your PR @mash-graz , I just have to dig a bit deeper into the networking part to leave a proper review.

@iwilltry42 My thoughts exactly. This issue has served its purpose and an initial implementation has been delivered. Thank you. I am happy to close this down and raise any additional work as new issues.


Support publishing CLI when using CCM

@tamarrow I am going to merge this and see if it works during release/tagging.


typo

missing $ for the hotelName variable in welcomeMessage_string

Thanks for the PR.
Btw, best practices would require two separate PRs (the typo and the language addition).
Best regards


feat: Add prefer_sliver_prefix rule

🔗 Related Issues

None

🙌 What's Done

Add prefer_sliver_prefix rule

✍ What's Not Done

None

🖼 Image Differences

🤼 Desired Review Method

[ ] Correction Commit
[ ] Pair programming

[!NOTE]
It is possible that a reviewer's will may cause a method to be implemented that is not selected.

📝 Additional Notes

This rule ensures that class names are consistent and easily recognizable as returning a Sliver widget!
Pre-launch Checklist

[x] I have reviewed my own code.
[x] I have added tests that prove my fix is effective or that my feature works.
[x] I updated/added relevant documentation (doc comments with ///).

@riscait

Would a rule like "prefer_to_include_sliver_in_name" be better so that it is not limited to Prefix?
example: MyWidget.sliver() , MyExcellentViewWithSliver() , AltiveSliverWidget() .

Indeed, having some flexibility might be beneficial✍
Including the constructor could result in significant changes, so how about creating a separate improvement issue and having someone else handle it? 💭

Including the constructor could result in significant changes, so how about creating a separate improvement issue and having someone else handle it? 💭

Let's do that!

I created the following issue!
https://github.com/altive/altive_lints/issues/36


ShowMessageAsync Bounds issue

What steps will reproduce this issue?
First of all I love your work, its awesome!
I frequently use ShowMessageAsync() for popups.
Today I noticed that if you have a window (not maximized) and move said window out of the visible screen, the popup still takes the window's width as its size, but is moved into the visible part of the screen.
Happens when moving the window out in Y direction as well.
Expected outcome
I'd expect the popup to still be centered within the window instead of always displaying the control on screen.

Environment

MahApps.Metro 1.3.0
Windows 10
Visual Studio 2015
.NET Framework 4.5

@boatschl Do you mean the external Message? Can you make a screenshot?

Hi,
here is the screenshot: http://imgur.com/a/ApNpy
I moved the main window 50% out of the screen to the right, thus you see parts of my desktop. I use this code:
private static MahApps.Metro.Controls.MetroWindow Wnd()
{
return System.Windows.Application.Current.MainWindow as MahApps.Metro.Controls.MetroWindow;
}
public static Task ShowMessageBoxOkCancel_Async(string message, string title)
{
return Wnd().ShowMessageAsync(title, message, MessageDialogStyle.AffirmativeAndNegative);
}

@boatschl but your screenshot uses the external variant of the message dialog... cause I cannot reproduce this issue with the normal message box which is always shown inside the window.

@boatschl Any news?


Roles order by position

As @Kwoth mentioned in chat, .roles should order roles according to their corresponding positions in the discord server settings

done in 1.0


UI Functional Tests for launcher

What this PR do?

Add UI tests for launcher

Issue is tracked here:
https://openshift.io/openshiftio/Openshift_io/plan/detail/520

seems these tests can't be run on the ngx-launcher project and be specific to test the integration with fabric8-ui. Wouldn't it be better to have them "live" there?

seems these tests can't be run on the ngx-launcher project and be specific to test the integration with fabric8-ui. Wouldn't it be better to have them "live" there?

@edewit we can store username and password in semaphoreci and run tests on each PR after unit tests?

@edewit We're trying to ensure that ngx-launcher PRs are of high quality, plus the changes do not break its integration with fabric8-ui. If these tests reside in fabric8-ui, PR validation won't be possible and any integration failure detected would be very late.

Okay, but how would that work? Is there a process that updates fabric8-ui with the unreleased PR and then runs these tests? On our side we use dependabot to create a PR when there is a release of ngx-launcher and run the integration tests at that time. But if you wanted to have this notification earlier we could also do it with a webhook. But I feel that these test could better be on fabric8-ui. Just because people that make changes on this repo don't necessarily have to run all the integration tests of all the projects depending on this.

@rgarg1

PR validation won't be possible and any integration failure detected would be very late.

It certainly would be possible. We can have a webhook (if maintainers let us do so :)) and react on PR events to run our own tests in our own infra. This would let us know if incoming changes are affecting us, fabric8-ui, as the consumer of this upstream component. What @edewit is suggesting makes perfect sense for me.

@bartoszmajsak
This approach sounds promising to me. Let's talk about it later today. Thanks @edewit

After a quick look on this PR it seems that you are duplicating a lot of work that was already done in e2e UI tests and you are making the same mistakes that we did.

Long live transparency and collaboration ;)


Rename to gtvision

Codecov Report
Patch coverage: 100.00% and no project coverage change.

Comparison is base (e873863) 100.00% compared to head (2e01865) 100.00%.

:exclamation: Current head 2e01865 differs from pull request most recent head 0f00e4c. Consider uploading reports for the commit 0f00e4c to get more accurate results

Additional details and impacted files
@@            Coverage Diff            @@
##              main        #8   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files            2         2
  Lines            9         9
  Branches         1         1
=========================================
  Hits             9         9

Impacted Files
Coverage Δ

src/gtvision/transforms/factory.py
100.00% <ø> (ø)

src/gtvision/transforms/__init__.py
100.00% <100.00%> (ø)

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


don't sort keys

I think it's not necessary to sort the keys.
Also then there's no need for a special case for osx test here any more

I think it would be better to fix the test. Since the difference on OS X is probably due to different locale setting, the simplest way to correct the test would be to make sure same locale is used. I'd just change the expected value to expect="$(sort <<< "file1.txt"$'\n'"file 2.txt")". Unfortunately, I'm not a mac owner, so I can't test right now, but it should fix the problem and remove the need for special case.

@dolik-rce thanks, good idea!

Created a new PR with the suggestion from @dolik-rce


Create Unit test to assert properties observed by computed property

@notmessenger please address this to me as my current issue queue dwindled.


gnome.geary: fix build with vala 0.56

Description of changes

Things done

Built on platform(s)

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

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[ ] Fits CONTRIBUTING.md.

@ofborg build gnome.geary

@ofborg build gnome.geary

I admit I am too impatient to wait for the aarch64-linux build since ofborg is building webkitgtk and it always timeout. :crying_cat_face:


Add RDTSC and RDTSCP intrinsics

Is there a reason why there aren't in i386 ? That's where clang puts them:
https://github.com/llvm-mirror/clang/blob/a38ba9770a70056f9fdd6c71f819e5db45a105e4/lib/Headers/ia32intrin.h#L64
There doesn't seem to be an llvm feature to enable these conditionally, so I'd guess they are available on all x86 LLVM targets without exceptions.

TBQH, I just followed the BSWAP intrinsic, although I thought I looked at the Intel manual to see when it was supported.
Either way, you can assume I didn't know what I was doing ;-)

So _bswap also belongs in i386 :D
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/i386/ia32intrin.h
I'll move them there.


Allow more props to be rendered when not modified.

e.g. the checkbox labelText is limited to be used with the string proptypes, so there will be warnings when passing in a number, or a valid component.
As no modifications happen on the props and this is only something that gets rendered down the line, why limit its use? Use the proptype.node instead of proptype.string, proptype.number to allow anything that can be rendered to be passed in.
Everywhere in the code where props are simply being rendered without being modified, change the proptype from e.g. proptype.string, proptype.number to proptype.node

Heyo could you update your branch with the latest from master? Good by me otherwise though

Went ahead and kicked off the CI build with the new branch 👍

👍 ✅   Good to merge once the branch is updated

@marijohannessen should the commit follow our commit conventions? Not sure what needs to be used to trigger the publish step that @chrisdhanaraj has setup

Yeah the commit does, but on merge you can modify what it looks like. Unfortunately husky only kicks out commits done via command line


Add copy to clipboard for MFR part

There is copy to clipboard icon for the LCSC number, it would be useful to put this also for the MFR number.  Sometimes searching the LCSC number in EasyEDA doesn't work but MFR number does.

Implemented in 25e982c


Publishing Always Uses Local File System

In a multi-project build, I'm attempting to publish artifacts from a subproject.
For the root project—which I don't want published—I've disabled using these settings (based on a comment from frugalmechanic/fm-sbt-s3-resolver#29):
publishArtifact := false
publishTo := None
publish := {}
publishLocal := {}

For the subproject, I'm using:
publishMavenStyle := false
publishTo := Some("My Artifacts" at "s3://my-artifacts/")

The plugin is, of course, added to the project:
addSbtPlugin("com.frugalmechanic" % "fm-sbt-s3-resolver" % "0.12.0")

When publishing, I get this output:
sbt:my-project> sbt publish
[info] Loading global plugins from /Users/michaelahlers/.sbt/1.0/plugins
[info] Loading settings from plugins.sbt ...
[info] Loading project definition from /Users/michaelahlers/Projects/my-project/project
[info] Loading settings from build.sbt ...
[info] Set current project to my-project (in build file:/Users/michaelahlers/Projects/my-project/)
[info] Installing the s3:// URLStreamHandler via java.net.URL.setURLStreamHandlerFactory
[info] Using the existing Ivy URLHandlerDispatcher to handle s3:// URLs
[info] The s3:// URLStreamHandler is already installed
[info] Using the existing Ivy URLHandlerDispatcher to handle s3:// URLs
[info] :: delivering :: my-organization#my-subproject_2.12;1.0.0-SNAPSHOT :: 1.0.0-SNAPSHOT :: integration :: Sun Sep 10 14:55:08 MDT 2017
[info] 	delivering ivy file to /Users/michaelahlers/Projects/my-project/my-subproject/target/scala-2.12/ivy-1.0.0-SNAPSHOT.xml
[error] java.lang.UnsupportedOperationException: URL repository only support HTTP PUT at the moment
[error] 	at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:235)
[error] 	at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
[error] 	at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150)
[error] 	at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84)
[error] 	at sbt.internal.librarymanagement.ConvertResolver$LocalIfFileRepo.put(ConvertResolver.scala:369)
[error] 	at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
[error] 	at sbt.internal.librarymanagement.ConvertResolver$ChecksumFriendlyURLResolver.put(ConvertResolver.scala:121)
[error] 	at sbt.internal.librarymanagement.ConvertResolver$ChecksumFriendlyURLResolver.put$(ConvertResolver.scala:108)
[error] 	at sbt.internal.librarymanagement.ConvertResolver$$anonfun$defaultConvert$lzycompute$1$PluginCapableResolver$1.put(ConvertResolver.scala:168)
[error] 	at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216)
[error] 	at sbt.internal.librarymanagement.IvyActions$.$anonfun$publish$5(IvyActions.scala:492)
[error] 	at sbt.internal.librarymanagement.IvyActions$.$anonfun$publish$5$adapted(IvyActions.scala:491)
…
[error] (my-subproject/*:publish) java.lang.UnsupportedOperationException: URL repository only support HTTP PUT at the moment

The publishTo setting is correct:
sbt:my-project> show publishTo
[info] my-subproject/*:publishTo
[info] 	Some(My Artifacts: s3://my-artifacts)
[info] root/*:publishTo
[info] 	None

And the S3 resolver plugin is enabled:
sbt:my-project> plugins
In file:/Users/michaelahlers/Projects/my-project/
	…
	fm.sbt.S3ResolverPlugin: enabled in root, my-subproject
	…

Using SBT 1.0.1.
Is it trying to publish to the local file system (regardless my publishTo setting)? Any advice?
(Note the truncation, and anonymized identifiers where appropriate.)

This looks like a dupe of https://github.com/frugalmechanic/fm-sbt-s3-resolver/issues/38 which is solved by upgrading to SBT 1.0.4.
See if that helps.

Also, upgrade to version 0.13.0 which has a few SBT 1.0 related fixes.

Please re-open if this is still an issue.


Long polling doesn't handle flood errors

As the title suggests, the long polling class doesn't handle flood errors like it should (Delaying the next getUpdate request) and creates this:
Unhandled exception:
Long polling stopped: Too Many Requests: retry after 5
#0      LongPolling._poll (package:televerse/src/televerse/fetch/long_polling.dart:92:9)
<asynchronous suspension>
#1      LongPolling.start (package:televerse/src/televerse/fetch/long_polling.dart:62:7)
<asynchronous suspension>

Hey, thanks for reporting this. Have you passed an error handler method using the Televerse.onError method? Or is this issue happens even when the error handler is passed?
Let me know please :)

Okay, I get it. So, what about stopping the polling when a LongPolling exception happens, then awaits the user's onError handler, and then restarting the polling?
Do you think that will work?

This would probably do the trick, but i'd probably just handle it myself, as there are not many ways someone who uses the library would handle this (Meaning they would probably just handle it by sleeping the required time)

Thanks again, this behavior is added in this commit: 9c56dffa3038c82e3b1a00d6346b6d6e06ce1901.
Also, this is a minor breaking change as HttpException is now completely replaced with TelegramException. Telegram Exception contains the ResponseParameter object by which users can decide if they need to retry the request or not.
The auto-retry behavior is added to the LongPolling at its core now. When a retriable long polling exception is thrown, the polling will be stopped for the specified time and auto-restarts after it.
Thanks again for reporting this.

I'm very happy to had given you a little hand :)


Gave code hints a font

The code hints now have the same font as the actual source.

Hi @sir-ragna, concerning the font-family: 'Source Sans Pro', monospace, while I really like that typeface (I actually use it in Atom), I am wondering if it's a good idea to specify it as default in a font stack for a desktop as it's not a system font.
That would oblige us either to provide it as a webfont or embed it as a .ttf file in the setup.
What do you think?
Thanks!

Hi @sir-ragna,
I'm very happy about your contribution, I first really want to thanks you!
The ADXStudio is an integration project, it aggregate several sub-projects:

AskCmn
AskiaCore
ADXAPI
ADXShell
ADCUtil
AskiaScriptEditor (Extension of CodeMirror)

The project app/lib/codemirror is an external project (AskiaScriptEditor).
This project is shared between Design 5 (the editor in 'Routing' mode), AskiaTools (editor for script execution), AskiaVista (script mode for filter, calculated questions...) and soon Analyse.
I will probably make it open at some point to allows more re-usability and extension.
If you want to edit CSS for codemirror, the best place is in the app/themes/default/askia.css just add the selector and the rule you want to override.
If that modification could also be interesting for all other apps that uses AskiaScriptEditor (Design, AskiaTools, AskiaVista) then probably the best is to do the modification in the AskiaScriptEditor project (hosted in Askia organisation)
Could you please add the modification in the askia.css for the moment?
Thanks,
Mamadou

@uncleserb I was under the impression that this font was already used for the text in the editor. It is also already imported.
https://github.com/AskiaADX/ADXStudio/blob/f174bd6cbf09d341e63295743285f2766520dd6c/app/lib/codemirror/doc/docs.css#L1-L13
Without a monospace font the code hints just look ugly. It should at least by the same font as the text.

Not relying on external sources/OS for fonts is a good idea. I suggest local embedding in the project that use it. Since AskiaScriptEditor integrates in other Askia products I guess I better leave these changes to you.
@MamadouSy Thanks for the feedback.
I'll look into resubmitting a fix later. I'm running behind on the main branch atm.

Fair enough @sir-ragna! Had no idea CodeMirror uses SourceSans by default. In that case, go for it! I agree, we definitely cannot display a default serif in the code hinting.

Hi @sir-ragna,
I will add the modification in the AskiaScriptEditor itself.
I will close that pull request but keep your change.
Thanks you very very much.
In the next version, you'll appear on the list of contributors in both readme and about window.
Cheers.

Modification will be move on the AskiaScriptEditor project to be available in all Askia projects that uses it.