Malformed  throws error

<div ui-view></ui-view>
<div ui-view></ui-view>

causes:
Cannot read property '$$animLeave' of undefined

Note in ng 1.5.9 this logs to console but in 1.6.0 it logs "Possibly unhandled error in promise"
1.5
http://plnkr.co/edit/2beFjVogMk1zAZXH3vKq?p=preview
angular.js:14110 TypeError: Cannot read property '$$animLeave' of undefined
    at VM328 angular-ui-router.js:4024
    at processQueue (angular.js:16606)
    at angular.js:16622
    at Scope.$eval (angular.js:17913)
    at Scope.$digest (angular.js:17727)
    at angular.js:17952
    at completeOutstandingRequest (angular.js:6035)
    at angular.js:6314

1.6:
http://plnkr.co/edit/Y5etCjiGk1ehzx7ElYSy?p=preview
VM326 angular.js:14324 Possibly unhandled rejection: {}

I believe this is fixed in 1.0 via https://github.com/angular-ui/ui-router/pull/3164
I will backport this code and see if it fixes the issue in legacy branch.

^ Yep, backporting #3164 fixes the issue: http://plnkr.co/edit/GWE5NVnCWBVaksB3Y5KY?p=preview

Closed by 5be98e047a096012762096922a2756a0a0a0ea60


Add support for Laravel 7.0

This adds support for Laravel 7.0 and includes it in the test suite.
You might also consider removing support for the previous versions and tag a new major release that only supports Laravel 7.0+.

Thanks a lot.


Integration "time of use"

Is your feature request related to a problem? Please describe.
Would be cool to edit the "Timetable" over mqtt.
Describe the solution you'd like
Edit the "Time of use" over mqtt (like active power regulation).
Describe alternatives you've considered
Change it on the Display :(
Additional context
Did anyone else had a usecase for this?

greetings from austria
Mike

This would be awesome to use in combination with an dynamic energy price like tibber or awattar...
I hope this feature will be implemented

The tricky part is to identify the respective Modbus registers.
In the Deye docs I see that these registers could fit, but someone would have to confirm that, by at least reading them using the command line tool, as described here https://github.com/kbialek/deye-inverter-mqtt#reading-and-writing-raw-register-values

So you don't own an deye 12k or so yourself?
A complete tibber api Implementation would be awesome!
Maybe I can find the time tonight, if nobody is faster than me

So before trying to write values, i tried to read the values:

Thats the result.. any ideas?
Greetings

@finfin82 Assuming, that you have the time table configured, these register addresses do not work for your inverter.

@finfin82 Assuming, that you have the time table configured, these register addresses do not work for your inverter.
maybe i did something wrong?
i have a timetable configured - may be the registers are wrong?
Reading these values via the deye or solarman pro app works successful.

@finfin82 I found another Modbus registry spec here
Try reading these registers

Thats it! i will try to write sell power of 154 as well...

@kbialek well any progress here? does it make sense to support you in any way?
guess you will be faster implementing the timetable-settings now where we know the correct registers...
since python is far away from my mother tongue :-)
greetings and thank you for your time and for this great project!

@finfin82 No progress code-wise. I have other, more important topics to work on at the moment.

does it make sense to support you in any way?

Yes, you can think what could be the most desired time-table mqtt "API". I can propose two extreme options at the moment:

Fine-grained - Map each property (time, soc, etc...) to an individual mqtt command topic. This means that you have to publish multiple mqtt messages to update the whole table. On the other hand you can modify individual properties easily.
Coarse-grained - Map the entire table to a single mqtt command topic. Send a time-table JSON object in the mqtt message. Update entire table at once.

Well my tibber contract starts in June, so for my part there is no hurry.
I can imagine that there is a use case for both.
I'm using node red to fetch the tibber prices and can imagine to push the whole time table at once, cause I have the whole day available in one task.
There is a use case for manipulating single values as well.
So may be just implement the easiest way at first and add the more complex part when there is more time for that.
When you implement the settings, can you please make sure that there is a way of retry in case one single command fails... I have some crc errors from time to time. The next try works perfect then.
Thank you very much!

I've started working on it. There is a lot to be done, so be patient. I will implement the reading side first. So far I've imported updated HA definitions for deye_hybrid where ToU registers are already defined. The next step is to add registers used by your inverters. In case you are interested in the code changes, the PR is already opened https://github.com/kbialek/deye-inverter-mqtt/pull/138

@finfin82 @m1k3f15h What inverter models do you have exactly? What metric groups do you have set in the config?

good evening @kbialek my model is the 12K-SG04LP3 according to the manual.
my metrics: deye_sg04lp3,deye_sg04lp3_ups
thanks for your great work and infos about he PR... i will have a look next days
greetings

@finfin82 What metric group did you add to your config?

i added the deye_hybrid_timeofuse metric.
Just realized this was for another model defined?
here are my current settings:

Use deye_sg04lp3_timeofuse metric group

ahh just got it... mixed up something... sorry.
works perfect here is the output:

@finfin82 Can you really control at which day energy selling is enabled? This register's description indicates that such a feature might exist, however I couldn't find it in the inverter's manual https://www.deyeinverter.com/deyeinverter/2021/04/14/502012252【b】储能三相说明书sun-8-12k-sg04lp3-ver2.1-deye.pdf

@kbialek yes this feature came by one of the lated firmware-updates of the inverter and userinterface.
guess its only visible on the interface directly at the inverter... not even in those online-tools for editing settings
Not really necessary for our usecase but would make it complete.

@finfin82 @m1k3f15h What inverter models do you have exactly? What metric groups do you have set in the config?

Hy,
Inverter: SUN-12K-SG04LP3
Metric Groups: deye_sg04lp3, deye_sg04lp3_battery, deye_sg04lp3_ups, settings
Thanks for working on this feature request :)
mike

@kbialek just give me a ping when you need me to test something... Looking nice so far

awesome work!
i checked it out and was trying to send commands to those topics ..
here are my results as seen in mqtt-explorer... guess it didnt work ... but im sure im doing something wrong.
im using ubuntu do you have a suggestion for mqtt-client to use there?

@finfin82 please collect and share debug logs

debug.log
looks like there is some kind of race condition?!
says mqtt-client not connected but can successful publish timeofuse data.
my way to send the data is right? <-- just for the record and be sure?

@finfin82

looks like there is some kind of race condition?!

Yes. There is a race condition between establishing mqtt server connection and subscribing to the command topics. This is not a blocker and I will address this later.
I couldn't find write command in the debug log. Did you send it?

Yes I did, but couldn't find it... I made several attempts... Guess the subscription was not successful either. Even when there was no error...
Maybe the local class client get lost?
Just an idea... I had not enough time to have a look at the code
Greetings

@finfin82 I fixed the subscription race condition. Please try to send "write" again.

awesome, works perfect!
first i had some similar issues - then i realised, that there is my old deye-inverter-mqtt docker running that seemed to blocking the mqtt functionality.
i tested some of each kind... only manipulating the time didnt work - maybe there is a wrong register in the background?
should have been 148 for my inverter?
do you need a logging for that?
thanks again for your awesome work!

only manipulating the time didnt work

Collect and share debug logs

a bit longer log in line 609 you see the /timeofuse/time/1/command setting to 31
followed by the write command
the next read you can see its still 30
debug.log

@finfin82 Yes, you're right. For some reason value 31 is not processed by the inverter.
I've extracted modbus request and response frames from your log. They both look good. In the screenshot below, you can see that value 31 has been sent in the request.
Perhaps the inverter does some sort of rounding? What is the time granularity in the App or inverter UI?
Can you try to write register 148 (timeofuse/time/1) individually? Does any of those command have effect?
# Set 01:00
docker run --rm --env-file ./config.env deye-inverter-mqtt w 148 100

# Set 01:01
docker run --rm --env-file ./config.env deye-inverter-mqtt w 148 101

# Set 01:05
docker run --rm --env-file ./config.env deye-inverter-mqtt w 148 105

# Set 01:30
docker run --rm --env-file ./config.env deye-inverter-mqtt w 148 130

Request:

Response:

yep thats it, seems to be some kind of 5 minute grid.
first setting via commandline confirmed this - setting via mqtt works perfectly with this knowledge...
sorry for my bad debugging skills at this time - more to blame the lack of time these days...
guess we have a working release now?!
anybody here able to build a node-red automation including tibber api? :-)
will give it a try after chrismas i think.
@kbialek thank you very much - awesome work!

@finfin82 Nice! Now you owe me a tasty drink :laughing:

@finfin82 Beta image is ready for testing. Please check it out. ghcr.io/kbialek/deye-inverter-mqtt:2024.01.1-beta-1

@kbialek i tried every setting property - soc is not possible for me to test, since im running on BatV configuration.
seems to work perfect for me!
maybe @m1k3f15h could give it a try too?
thanks

@m1k3f15h hi mike, any time to test this release?
my instance is working fine

Hey guys
Sorry for my late response.
I was on holidays..
I hope i find some time in the next few days to test this great feature :)
Greetings
Mike

Hi all,
I have tested TimeofUse with SUN-12K-SG04LP3. It looks very good.
I will implement some variable loading based on tibber prices this week and will give feedback until end of the week.
Until now awesome work. Thanks a lot @kbialek !!!

@joe-678 nice! can you please share your solution how you integrated tibber in this context?

No problem. I have integrated my deye via mqtt running on a docker same as an node red implementation. For node red you can retrieve price info for tomorrow and with a solar production forecast for my PV(could also be integrated into node red) i would like to derieve estimated battery yield and then calculate how much I need to charge the battery and when it is the best time to do so. Not ready yet, but Friday I am moving to tibber ;-)

im thinking about a similar solution
maybe you can share your configuration... i still didnt manged to compose an according message from the detected shedule

I assume the feature is working well for you. I will release it tomorrow.

@kbialek yep working well for me, please let me know how to buy you a beer ;-)

@kbialek yep working well for me, please let me know how to buy you a beer ;-)

Okay, it's out. @finfin82 Just read the first line of the README :smile:

only one little "mistake" in the Readme:
{MQTT_TOPIC_PREFIX}/timeofuse/power/(1-6)/command --> say only 0-8000 works.. i tested 12000 (default of my inverter) --> also works great :)

Thanks. README updated. I took the original value from the modbus protocol documentation, but obviously it depends on the inverter max power.


build: Don't fail for 32 bit builds because of static_assert check

A static_assert was added recently as part of PR #3898, which assures that the size of a TileID is a multiple of 8 bytes. But on architectures with 32 bit pointers, this assertion fails. Which is not quite what we want, because the code isn't wrong if the struct isn't a multiple of 8 bytes; it's just less efficient. And we don't want to fail for 32 bit arch.
Bottom line: only do this check to ensure we're in the most efficient case if we're 64 bits. Nobody's expecting highest performance on a 32 bit machine anyway.
Fixes #4001

Thanks!


ConnectionClose error

HttpClient throws an ArgumentException when setting the DefaultRequestHeaders.ConnectionClose property.
I removed the process of setting the HttpWebRequest.Connection property for the error (see also: https://msdn.microsoft.com/en-us/library/system.net.httpwebrequest.connection.aspx ).

Hi @clown,
After our first release of this library (which is based on the Mono implementation), Microsoft open sourced their own implementation of System.Net.Http. I'm thinking about bringing over that code to replace the entire current implementation. I haven't made a final decision on this yet, so I'll still evaluate this pull request in the meantime. :smile:


Associate school to all local authorities

Jira ticket URL
https://dfedigital.atlassian.net/browse/TEVA-2143
Changes in this PR:
First step in that ticket is to have local authorities associated with maintained and non-maintained schools

Review app deployed to https://teaching-vacancies-review-pr-3103.london.cloudapps.digital


unit tests to travis

https://github.com/IBM-Bluemix/gp-angular-client/tree/master/test
add these to travis…

Actually, I'm not sure how to run this test. So, document.


Version 0.14 parent issue

This issue outlines the main new functionality to be added in version 0.14. The definitive list of issues for 0.14 is the milestone. More detailed issues for some of the features below will be added when work on 0.14 begins:

Upgrade to Java 11 and ensure can build with Java 17

Closing as 0.14 has been released.


Creating a data model

Task Description
Describe the task to be completed.
Technical Considerations
Include any technical considerations including architecture (e.g. API), required libraries, etc.
Additional Considerations
Any supplemental information including unresolved questions, links to external resources, screenshots, etc.

Proposed:
{
organizer: ID of the organizer
user: ID of the user
event: ID of the event
message: text
timestamp: Unix seconds
}


[ React Migration ] Implement the "Contact Us" button functional

Hi there,
This issue is open to anyone who wants to contribute and is specific to the "reactdev" branch, where we are currently working on migrating the project to React.
The request is to mae the Contact Us button working and redirect to a functional page, ensuring it follows the same pattern and design as the main project. It's important to maintain consistency with the project's structure. Additionally, if possible, we would like tests to be written using vitest in order to achieve 100% test coverage.
If you have any questions or need further clarification, feel free to ask. We appreciate your willingness to help with this task.

What's up Ramon? If you don't mind, I would like to be in charge of this issue. Do you agree?

PR: https://github.com/akshitagupta15june/PetMe/pull/812
Still getting used to collaborate on open-source projects, so appreciate if you could provide some guidance.
Tnx!

Hello @fernando-mashimo ! Yes, sure!! Go ahead =)

PR: #812 Still getting used to collaborate on open-source projects, so appreciate if you could provide some guidance. Tnx!

You did great! Thank you so much for your contribution =)


[Idea]: Bot that automatically verifies PRs which add new playlist(s) to the registry

Hey Mack! I'm toying with an idea of writing a bot that, as the title suggests, would verify new registry entries' validity (if there are any in a pull request). It would follow this algorithm for each file:
flowchart TD
    A((START))
    A --> B
    B{File name contains query parameters?}
    B -->|Yes| C
    C[Let Q be the file name without the parameters]
    C --> E
    B ---->|No| D
    D[Let Q be the original file name]
    D --> E
    E{Playlist with an ID equal to Q exists?}
    E --> |Yes| F
    F{Q equals the file name?}
    F --> |Yes| Z
    F --> |No| G
    G[/Request file name change/]
    G --> Z
        E --> |No| G
    Z((END))

Note: By file name with query parameters I mean a file name like 2vpAyuy9HOTPjygPl63QuH?si=3f7d3884baa44c0e.
I guess there are some other edge cases I didn't handle in that flow chart and I can't think of any as we speak, but I believe this graph outlines a decent concept for validating all new entries. Not really sure if I'll have the bandwidth to write such bot myself, given that I've started grinding away for my finals in May next year. But once I do find some time, I'll at least try looking into appropriate resources.
What do you think of this idea? By offloading the chore of verifying and integrating new entries into the archive onto such bot, you'll certainly speed up the entire process by enabling users to react to change requests (if issued) about a minute or so after opening their PRs. Manual review would serve as a fallback mechanism if automated checks were to fail for whatever reason.

What do you think of this idea?

This idea sounds great! I'll leave this issue open until one of us implements it, though I don't plan on doing so any time soon.

@mackorone, I'm stuck at home with a very sore throat, so I might as well give writing this bot a shot.

@mackorone, I'm stuck at home with a very sore throat, so I might as well give writing this bot a shot.

Ok, so the only thing I need to figure out right now is granting the right permissions, because at the moment, my bot is unable to merge PRs even though I'm pretty sure I've granted it everything it needs... anyway, I'll get back to you once I've got the whole thing working as intended.

@mackorone, I'm stuck at home with a very sore throat, so I might as well give writing this bot a shot.

Ok, so the only thing I need to figure out right now is granting the right permissions, because at the moment, my bot is unable to merge PRs even though I'm pretty sure I've granted it everything it needs... anyway, I'll get back to you once I've got the whole thing working as intended.

Sorry if I'm double-pinging you, but in case my first mention didn't notify you: It's alive

@mackorone, ICYMI: https://github.com/maciejpedzich/bot-testing-ground/pull/21

@mackorone, ICYMI: maciejpedzich/bot-testing-ground#21

Oh, actually I've missed your reactions... apparently, GitHub doesn't notify you about them (for better or for worse). Anyway, let me know once you've added the GitHub app to your repo, so that I can deploy the live version and close this issue!

@mackorone, ok so the partial downtime cause has been identified, and it shouldn't affect the bot too much... it's time for a launch test! I'm closing the issue now, thank you for the opportunity once again!


Docker build fails with ERROR: The predicates below are not defined scasp_main:tty_size/2

Hello @JanWielemaker
Starting today I started to get docker build failures
17.18 % ERROR: The predicates below are not defined. If these are defined
17.18 % ERROR: at runtime using assert/1, use :- dynamic Name/Arity.
17.18 % ERROR:
17.18 % ERROR: scasp_main:tty_size/2, which is referenced by
17.18 % ERROR:  /swish/pack/sCASP/prolog/scasp/main.pl:293:14: 1-st clause o
17.18 % f scasp_main:print_answer/3
17.18 % ERROR: scasp_model:tty_size/2, which is referenced by
17.18 % ERROR:  /swish/pack/sCASP/prolog/scasp/model.pl:190:14: 2-nd clause of scasp_model:print_model/2
17.18 % gmake[1]: *** [Makefile:4: all] Error 1
17.18 % gmake[1]: Leaving directory '/swish/pack/sCASP'
17.18 ERROR: -g pack_rebuild(sCASP): Process "process(/usr/bin/gmake,[])": exit status: 2

Even old build which used to pass started to fail.
scasp submodule is set up as a link to master.
I couldn't easily rewind it to previous versions.
tty_size should be availabe, I'm not sure why it complains.

Sorry, my bad.
I was confused how git submodule works.
Can be fixed by updating sCASP git submodule


Box around social media icon

Does any one notice in the current version of minima, the soical media icons are surrounded by a box? It's not like the style in the screentshot. I'm new to minima and jekyll. Does anyone know how to get rid of this box?
(You can see this effect just by clicking the preview)

Check the old commit and found it.


retry pathMode

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: chenfli
If they are not already assigned, you can assign the PR to them by writing /assign @chenfli in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

:star: PR built and available in a preview environment chenfli-nodejs3-pr-11 here

:star: PR built and available in a preview environment chenfli-nodejs3-pr-11 here

:star: PR built and available in a preview environment chenfli-nodejs3-pr-11 here

/meow

@chenfli:

In response to this:

/meow

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

/woof

/meow space

@chenfli:

In response to this:

/meow space

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

/meow train

@chenfli: Bad category. Please see https://api.thecatapi.com/api/categories/list

In response to this:

/meow train

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

/meow girls

@chenfli: Bad category. Please see https://api.thecatapi.com/api/categories/list

In response to this:

/meow girls

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

/meow funny

@chenfli:

In response to this:

/meow funny

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

/assign chenfli

@chenfli: you cannot LGTM your own PR.

In response to this:

/lgtm

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

/lgtm

/woff space

:star: PR built and available in a preview environment chenfli-nodejs3-pr-11 here

/pony


DSMapStudio Crashing upon duplicating an enemy

As per title, DSMapStudio will crash if I try to duplicate an enemy of any kind, in any place of the map in DSR.
EDIT: this also appears to be happening upon doing Create -> Parts -> Enemy, but not for Objects
Downgrading to DSMapStudio 1.10.0 works fine.
Full Crash Log:
DSMapStudio Version 1.11.1
Value cannot be null. (Parameter 'destinationArray')
at System.Array.Copy(Array, Array, Int32)
at StudioCore.MsbEditor.Entity.DeepCopyObject(Object obj) in ./src/StudioCore/MsbEditor/Entity.cs:line 284
at StudioCore.MsbEditor.Entity.Clone() in ./src/StudioCore/MsbEditor/Entity.cs:line 306
at StudioCore.MsbEditor.MapEntity.Clone() in ./src/StudioCore/MsbEditor/Entity.cs:line 1458
at StudioCore.MsbEditor.CloneMapObjectsAction.Execute() in ./src/StudioCore/MsbEditor/Action.cs:line 390
at StudioCore.MsbEditor.ActionManager.ExecuteAction(Action a) in ./src/StudioCore/MsbEditor/ActionManager.cs:line 55
at StudioCore.MsbEditor.MsbEditorScreen.OnGUI(String[] initcmd) in ./src/StudioCore/MsbEditor/MsbEditorScreen.cs:line 989
at StudioCore.MapStudioNew.Update(Single deltaseconds) in ./src/StudioCore/MapStudioNew.cs:line 1343
at StudioCore.MapStudioNew.Run() in ./src/StudioCore/MapStudioNew.cs:line 368
at DSMapStudio.Program.Main(String[]) in ./src/Studio.App/DSMapStudio/Program.cs:line 36

thank you 1.10.0 version is better for me now :)


Add Ecosystem homepage for partnerships

We need to add the Hummgbot logo somewhere on the website. Reminder to Rebecca.
Tasks

[ ] Overhaul apps and tools so it is Ecoystem Home
[ ] Rework the filters so we have fewer filters for the apps and instead a filter for integrations etc

[ ] Integrations
[ ] Wallets
[ ] dApps
[ ] Analytics
[ ] Validators
[ ] Build on Vega

[ ] Add logos with the projects below and some blurb on a hover
[ ] Add some more tiles for the stuff like build etc which dont have a tile yet
[ ] Add the top 3 to a section on the homepage

Ecosystem & Integrations
New blurb for the top
Ethereum
Logo

Blurb
Vega supports bridging of any ERC20 token onto the network, so long as that token has been proposed and approved via on-chain governance.
Tile link
https://ethereum.org/
Hummingbot
Logo (might want to get this approved with them)

or

Blurb
Run pre-built automated strategies or compose your own with Hummingbot on Vega.
Tile link
https://hummingbot.org/
Chainlink
Logo

Blurb
Any price feed available via Chainlink can be used to drive a market on the network through the protocol's flexible Ethereum oracles framework.
Tile link
https://chain.link/
Uniswap
Logo

Blurb
The Vega network can source prices from any Uniswap pool by using this community created smart contract during market creation.
Tile link
https://app.uniswap.org/
TradingView
Logo

Blurb
TradingView powered charts available in some versions of Console alongside Vega's own open source chart software.
Tile link
https://www.tradingview.com/
Metamask
Logo

Blurb
Connect to Console or Governance apps using the Vega MetaMask Snap for quick and pain free onboarding to the Vega network.
Tile link
https://metamask.io/
Pyth
Logo

Blurb
Vega's latest Ethereum L2 oracles, powered by Pyth, provide accurate and timely price feeds for highly effcient markets.
Tile link
https://pyth.network/
Gnosis
Logo

Blurb
Gnosis offers low fee, high efficiency infrastructure for provision of pricing feeds as part of Vega's Ethereum L2 oracles framework.
Tile link
https://www.gnosis.io/
Arbitrum
Logo

Blurb
Arbitrm offers low fee, high efficiency infrastructure for provision of pricing feeds as part of Vega's Ethereum L2 oracles framework.
Tile link
https://arbitrum.io/
Validators
Logo

Blurb
Visit the Governance app to browse the validators on the Vega network, stake your VEGA tokens, and participcate in Governance
Tile link
https://governance.vega.xyz/

[ ] Ethereum wording should mention oracle data sourcing too
[ ] Pyth wording is inaccurate and implies that EVM data sourcing is powered by Pyth, where actually Pyth is an option for EVM RPC (and Ethereum mainnet) data sourcing when and if Pyth data is pushed to a contract on the relevant chain and markets are created or updated to reference the Pyth contract.

I'd suggest a little info box about the results when the integrations filter is selected (like the one for the governance filter) that reminds people that these are integrations between the Vega network, dapps, or some specific markets and other networks/projects/protocols/software and that they don't necessarily imply official partnerships or permission.

@JonRay15 can you confirm the categorisation of each of the following (they can be more than 1):
Ethereum -> Integration
Hummingbot -> build?
Chainlink -> analytics
Uniswap -> d'apps?
Trading view -> analytics
Metamask -> wallets
Pyth -> integrations
Gnosis -> integrations
Arbiturm -> ingtegrations
Validators -> d'app?


Tool tip doesn't have the full representation of the url

Description:
The tooltip for the bellow code will not appear correctly.
http:Client clientEP = new("http://www.mocky.io");
- Reason
SourceGen assumes that // in the code is a comment.

Steps to reproduce:
Open Example  hello_world_client.bal
Affected Versions:
0.992.0-m2-SNAPSHOT

Issue is no longer valid for Swan Lake release. Hence, closing it.

Issue is no longer valid for Swan Lake release. Hence, closing it.


Fixed Firefox.yml

the line i changed caused an issue because the file that should be deleted did not exist

I notest that #437 is the same pull request


Let's Educate website (Fully Responsive)

Description 📜
Added a project of website for promoting education in society and providing education stuffs and information for making more and more people educated around the world.
Fixes #1139

Type of change 📝
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this

[x] Add a new project
[] Modified or enhanced the existing projects
[] Improve the readme of any project

Domain of Contribution 📊

[x] Project using HTML, CSS & JS

Checklist ✅
Please delete options that are not relevant. In order to tick the check box just put x inside them for example [x] like this

[x] I have performed a self-review of my own code or work.
[x] I have commented on my code, particularly in hard-to-understand areas.
[x] My changes generate no new warnings.
[x] I'm GSSoC'22 contributor

Screenshots / Gif (Recommended) 📸

@amyra98 please review my PR


Added Toggle section with two varieties of toggle switches / updated credits to reflect addition

feat: Added Toggle section with two varieties of Toggle switches (Normal and Full)
fix: #52 Re-numbered the ComponentCard's data id's

please create a seperate pr for component data issue, otherwise it will have to stay if we want to make changes in toggle component.
it's always better to divide pr on the basis of tasks

Sounds good, I removed that from this PR and I will create a new PR for that issue. Let me know if you have any other comments on this code.

I just pulled in the updated ComponentCards id numbering into this PR and updated the new toggle id number.

just reviewed the PR here are two improvements:

can we remove the full toggle, it doesn't matches with normal toggle.
instead of adding in ui, add toggle in components/PreviewCode folder


Update bootstrap to version 4.3.1

Close https://github.com/myyasuda/sphinxbootstrap4theme/issues/4
cc @chaoflow

@sigistardust Thanks a lot! This works for us.


Updates and impact on metrics

Good point raised by @microbit-carlos below. Discussion required on the best direction to take.

Once we release V3 as beta, how often would we expect to deploy with updates?
The metrics currently create a new category based on the Editor version, so right now in alpha each category only contains a few days of data.
In a slow release schedule, like what we had with V2, that has worked fine, but maybe we want to change it in V3? As an option, we could only create a new category when we make changes to the metrics (or new UI widgets are added, which might add new metrics)?

I'm tempted to just hardcode this to "Python Editor V3" for the foreseeable future.


incomplete restart of integration after host restart

custom_component/hahomematic version :
0.36.3
Home Assistant version (if applicable):
Version	core-2022.3.3
Installationstyp	Home Assistant OS
Python-Version	3.9.9
Betriebssystemfamilie	Linux
Betriebssystem-Version	5.10.92-v8
Host-Betriebssystem	Home Assistant OS 7.4
Supervisor-Version	supervisor-2022.01.1
Installierte Add-ons	Terminal & SSH (9.3.0), File editor (5.3.3), Node-RED (11.0.4), ESPHome (2022.2.6), Samba Backup (5.0.0), Grafana (7.4.1), RaspberryMatic CCU (<IP_ADDRESS>20226), Glances (0.14.2)
Do you use tls? no
Do you use callback?  no
Do you use username and password? yes
Which interfaces do you use?  browser edge Win 11
Describe the bug
After a full OS restart of the Homeassistant OS  the CCU devices are loaded correctly, however  even after waiting >10 minutes, the system variables are marked as "unavailable" in "History". After a additional  core restart, they are then also available again.
To Reproduce
Steps to reproduce the behavior:

Restart HAS OS
Wait till Raspberrymatic is fully loaded
Check System Variables in History
Restart HAS CORE
Recheck system variables in History

Screenshots

Please add logs.

The config LOG states  "Es gibt keine neuen Probleme!"
the core LOg has a warning and nothing more; , but this might be normal:
2022-03-08 16:31:19 WARNING (SyncWorker_1) [homeassistant.loader] We found a custom integration hahm which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
de838cd8-raspberrymatic-2022-03-08.log

I need the HA logs before restart.
Click on full logs (not only the abstract).

CoreLog.txt
die o.k ? oder weitere ?

Ich schau mal.

Should be fixed with 0.36.4

Just performed a restart of the host. I’d like to confirm, the issue has been resolved.  Thank you


UMUI/Rose Extracts on scratch space

resolution_fixed   |    by<EMAIL_ADDRESS>
Put UM_OUTDIR on /dev/udb
Might be in the UMUI job settings - have the standard jobs put them in the right place

Issue migrated from trac:30 at 2024-01-31 17:10:40 +1100

<EMAIL_ADDRESS>commented

Follow up with Say

<EMAIL_ADDRESS>changed status from new to assigned

<EMAIL_ADDRESS>commented

I've added space for users at /scratch/users

<EMAIL_ADDRESS>commented

We need to allow users to write to /scratch, which is currently not possible.

<EMAIL_ADDRESS>commented

I'd suggest using the directory: "/scratch/$USER/UM_OUTDIR".
I had a look at this with Say, and it's probably a bit clunky to try and hard wire it in. I think it makes sense to just use this in our standard jobs, and encourage users to set this in their jobs.

<EMAIL_ADDRESS>changed owner from `` to pfu599

<EMAIL_ADDRESS>commented

Milestone accessdev v1.0 deleted

<EMAIL_ADDRESS>commented

For this ticket, we just need to add documentation so people migrating their jobs from accesscollab or cherax change the extract directory to use '/scratch/users/$USER/UM_OUTDIR'
This has been added to https://trac.nci.org.au/trac/access/wiki/umuiUserGuide

<EMAIL_ADDRESS>removed milestone (was accessdev v1.0)

<EMAIL_ADDRESS>changed status from assigned to closed

<EMAIL_ADDRESS>changed resolution from `` to fixed


Rename procfile worker restart command

To match what the Procfile worker is defined as in puppet.
See https://github.com/alphagov/govuk-puppet/pull/7583

 (3) [Tech debt] Use only publishing api to preload items


feat: add nested query if data schema is passed down

Issue #, if available:
Description of changes:

allow studio component renderer to accept a generic data schema
on collections render if the data schema is passed and the selected model has a hasMany relationship include the nested query

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Codecov Report

Merging #514 (a2fea7c) into tagged-release/forms-and-views (e36f81d) will increase coverage by 0.14%.
The diff coverage is 100.00%.

@@                        Coverage Diff                         @@
##           tagged-release/forms-and-views     #514      +/-   ##
==================================================================
+ Coverage                           88.36%   88.50%   +0.14%
==================================================================
  Files                                  67       67
  Lines                                2380     2410      +30
  Branches                              628      634       +6
==================================================================
+ Hits                                 2103     2133      +30
  Misses                                273      273
  Partials                                4        4

Impacted Files
Coverage Δ

...react/lib/react-studio-template-renderer-helper.ts
93.75% <100.00%> (+0.59%)
:arrow_up:

...gen-ui-react/lib/react-studio-template-renderer.ts
92.04% <100.00%> (+0.42%)
:arrow_up:

packages/codegen-ui/lib/generic-from-datastore.ts
98.27% <100.00%> (+0.12%)
:arrow_up:

Continue to review full report at Codecov.

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


error: Couldn't set HW parameters

When svar is launched, I have the following error:
error: Couldn't set HW parameters: Set all possible ranges: Operation not permitted
Any suggestion?

If you are using hardware PCM directly, try to use with plug ALSA plugin which should convert between svar parameters and hardware. Also, can you post your svar invocation, and output from arecord --dump-hw-params with the same device?

@arkq Hi, this software looks very useful! I am running into the same error. I'm having trouble figuring out how to enable the plug plugin for Alsa. I asked CodeLlama and it said: amixer cset numid=<PLUGIN> <VALUE> Could you please tell me the command to enable plug?


Fix filenames of artifacts

kicad-cli exports sheets as <project-name>-<sheet-title>.svg. The frontend expects <sheet-filename>.svg.
This pull request uses the sch_pages file to rename the former into the latter.
For example, if I have a project called Blinky and a sheet with the filename led_drivers.kicad_sch but the name LED Drivers, kicad-cli will save this to Blinky-LED Drivers.svg instead of led_drivers.svg.
I think this is what you tried to do with:
for kicad_sch in \"${SVG1_DIR_PATH}\"/*; do
    rename "s/${proj_name_1}-//g" "${kicad_sch}"
done

but that only works if the title matches the filename.
For me these often do not match. I like to keep my filenames in snake case and my titles with capitalization and spaces.

I like this way better indeed. But something made me not use the file name. I can remember why. I want to test this a bit before merging it.

Could you try to add something for me here in this PR?
When you hover the mouse over the pages on the front end, it would be good to have the file_path which is the second column of the sch_pages. Then we are going to have a second piece of information with the tooltip.

But something made me not use the file name. I can remember why.

One consequence of using the file name is that if you use the same hierarchical sheet in multiple places, it will only show up once. This could cause unnecessary diffs too since the reference designators will change between instances.
I only renamed the svgs to match the file name because that's what the frontend is requesting according to the 404s in the network tab of dev tools.
I am not sure how this tooltip information gets to the frontend or how to change it. Could you give me a hint?

I am not sure how this tooltip information gets to the frontend or how to change it. Could you give me a hint?

When using Kicad 5 only, the tooltips are the file path but for Kicad 6/7 they are just the filename.
I have these 2 repos if you want to compare the result.

multisheet-kicad-5
multisheet-kicad-6

There is this insert_pages_html (page 160) function that creates those tooltips.
I thought this would be a related issue, but since it is not something generated here, let's address this in a new PR, later.

@leoheck if that tooltip is being addressed in a future PR, do you think this can be merged?

 I did not merge this because I am not sure it works everywhere and because sometimes it puts messages on my screen. So I am not sure it is working fine yet.

Which kind of messages does it put and can I help to test it more thoroughly?

You have to test on other repositories.
--
Leandro Heck
On Wed, Apr 5, 2023 at 6:13 PM Marcel Robitaille @.***>
wrote:

Which kind of messages does it put and can I help to test it more
thoroughly?
—
Reply to this email directly, view it on GitHub
https://github.com/leoheck/kiri/pull/79#issuecomment-1498168975, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAJX7YG3QLOLX63VM4YD7OTW7XOBPANCNFSM6AAAAAAWN23ANA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hey, I am closing this PR. your work was merged externally.
Could you check using the main branch if it is still working for you? It looks good to me tho.

Thank you for the donation. Today is my birthday and it was a nice coincidence.

What a nice coincidence. I'm glad I put it off so long then


User model (AUTH_USER_MODEL) customization impossible

Impossible de override the AUTH_USER_MODEL.
If I do it, the migrate process fails with this stack trace:
Applying shop.0001_initial...Traceback (most recent call last):
  File "manage.py", line 10, in <module>
    execute_from_command_line(sys.argv)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 364, in execute_from_command_line
    utility.execute()
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 356, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/core/management/base.py", line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/core/management/base.py", line 330, in execute
    output = self.handle(*args, **options)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/core/management/commands/migrate.py", line 204, in handle
    fake_initial=fake_initial,
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/executor.py", line 115, in migrate
    state = self._migrate_all_forwards(state, plan, full_plan, fake=fake, fake_initial=fake_initial)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/executor.py", line 145, in _migrate_all_forwards
    state = self.apply_migration(state, migration, fake=fake, fake_initial=fake_initial)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/executor.py", line 244, in apply_migration
    state = migration.apply(state, schema_editor)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/migration.py", line 119, in apply
    operation.state_forwards(self.app_label, project_state)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/operations/models.py", line 91, in state_forwards
    list(self.managers),
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/state.py", line 105, in add_model
    self.reload_model(app_label, model_name)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/state.py", line 166, in reload_model
    self._reload(related_models)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/state.py", line 199, in _reload
    self.apps.render_multiple(states_to_be_rendered)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/state.py", line 323, in render_multiple
    model.render(self)
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/migrations/state.py", line 626, in render
    body,
  File "/home/myproject/website/venv/lib/python3.6/site-packages/django/db/models/base.py", line 158, in __new__
    raise TypeError("%s cannot proxy the swapped model '%s'." % (name, base_meta.swapped))
TypeError: CustomerProxy cannot proxy the swapped model 'website_auth.User'.

This is due to this code in shop.0001_initial.py migration
if 'email_auth' in settings.INSTALLED_APPS:
   dependencies.append(('email_auth', '0001_initial'))
   customer_bases = ('email_auth.user',)
else:
   dependencies.append(('auth', '0001_initial'))
   customer_bases = ('auth.user',)

Unless there is an alternative I missed, that make impossible:

to embed django-shop to an existing project who already override the Django User model.
to customize the django user model by AUTH_USER_MODEL setting

Thanks for the report. I agree. In general, reusable apps should not depend on a specific AUTH_USER_MODEL implementation.
Sadly, I won't have time to work on a clean solution for this in the near future. Not sure if @jrief will. If you would like to make a proposal yourself, please go ahead.

@fmipsylone
django-SHOP's initial intention was to give users the possibility to override AUTH_USER_MODEL.
However, sadly this has never been been tested, because everybody used the email_auth implementation, which is almost the same as Django's auth, but allows to use the email address.

Unless there is an alternative I missed, that make impossible:

to embed django-shop to an existing project who already override the Django User model.

You should probably patch the migration files to fit your needs. If done generically, I will accept a pull request.

to customize the django user model by AUTH_USER_MODEL setting

Django-SHOP's philosophy is to allow users to override every model. Therefore additional fields should go to the Customer model rather than the User model. They are related through a 1:1 relation. This btw. is the recommended way to extend the User model. Read https://docs.djangoproject.com/en/1.11/topics/auth/customizing/#extending-the-existing-user-model
The docs furthermore states: "Changing AUTH_USER_MODEL after you’ve created database tables is significantly more difficult since it affects foreign keys and many-to-many relationships, for example."

I'm not in a position to create a pull request right now, but changing the else clause to this worked for me:
        dependencies.append((settings.AUTH_USER_MODEL.split('.')[0], '0001_initial'))
        customer_bases = (settings.AUTH_USER_MODEL,)

There's probably a better way to do it with a couple extra settings.


Exclude setup/teardown code from measurements

Hi,
It would be great to exclude setup/teardown code from benchmark measurements.
Using callgrind rather than cachegrind looks like it allows you to zero and dump the counters at particular points in the program. This can be done on the command line with --zero-before=my_fn and --dump-after=my_fn. It looks like counting can be turned on/off programatically as well.
callgrind also supports cache simulation with the same command line options and has a similar output file format, in particular with summary and events lines.
It looked to me like this would allow you to skip setup and teardown code.

Another strategy I'm experimenting with is running two versions - one that just performs the setup, the other performs the setup and run. I hypothesise that the delta is attributable to the run.


fixed javadoc of constructors in DescriptiveStatistics

as preparation for #12

Coverage increased (+0.005%) to 90.178% when pulling 4236cacc6d1d5af997529778953f088ea2d1b49c on krichter722:javadoc_fixes into 657b1b49da5ea1593dd7f950eae99a88a8ada87a on apache:master.

travis failed twice (see build 190.2 and build 190.2) due to This test can fail randomly due to sampling error with probability 0.01.. Imo this can be merged or the test should be improved/it's fail rate be reduced.

Coverage decreased (-0.03%) to 90.147% when pulling 851c9041c6f3b2be38be761f68314abd279967d4 on krichter722:javadoc_fixes into 657b1b49da5ea1593dd7f950eae99a88a8ada87a on apache:master.

Since I accidentally included a commit I need to rebase. After master seem a bit outdated and causes a lot of test failure which a dev recommended to overcome by using 3.6.1 on JIRA and develop doesn't build I'm officially confused - knowing that this might well be the cause of lack of maintainers for the project.
Which branch should I rebase on in order to get this quite trivial improvement merged as soon as possible?

rebased on master

replaced by #54


i18n plugin

Create the i18n plugin.  It should initially behave like dojo's and RequireJS's i18n plugin.  (Later, we'll likely add a feature to prefetch / inject strings that may be stored and/or retrieved by an alternative mechanism.  For instance, a project could use this feature to preload a customized bundle for a particular client or OEM.)

copying @asilvas

The current requireJS function returns a collection of strings, but I think it would be cool if it was a REF with strings as a property. Maybe a REF to some singleton class, so that var i18n = REF.getInstance(). Then we could do things like i18n.setLocale(code) and i18n.getString(key) and attach events like i18n.bind("localeChanged",onLocaleChanged)

Some of the solutions I have seen, offer a substitution/template scheme built into i18n.
imho templating should be left out because its easy enough to fetch the value, then compile in a template function from underscore/mustache/etc/etc/etc
_.template(i18n.getString("foo"),{bar:bar});
As templating solutions get stronger and more feature rich (conditionals and so forth) any built in support for it here would just get in the way.

I've often dreamed of being able to switch the locale without a reload.  Seems like we've just about got all of the components in @cujojs to do that now.  I'll put a bit more thought into that.  Sounds like a very cool idea! :)
-- John

Hello,
FYI.
I use RequireJS's i18n plugin with curl in my application and they work fine together. The only little problem/drawback I’ve encountered is that the plugin doesn’t allow to use properly a deep (more than 2 levels, i.e. menu.text.item1 instead of menu_text.item1) hierarchy of messages that isn’t fully translated for all alternative locales. In other words, if you have menu.text.item1 and menu.text.item2 in root bundle and only menu.text.item1 in a specific translation bundle then you won’t have menu.text.item2 from root bundle as default text (menu.text.item2 will be undefined). It is because plugin’s mixin function isn’t recursive.
Denis

That's great to hear, @gamtiq!  I am glad it works!  -- John


Fixes #276: Produces corrupt assembly if HideStrings=true and assembl…

…y does not contain any string literals

 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.

Please sign CLA.


How do I use spinner on Same page on different areas ?

Hi there!
Thanks for your interest in vue-simple-spinner! You can see an example of multiple spinners on the same page by visiting this JsFiddle examples page: http://jsfiddle.net/dzwillia/kc5ka8zu
Hope that helps!


chore(deps): upgrade dependencies

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-main" workflow

Codecov Report

Merging #483 (2bfefef) into main (0157db0) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #483   +/-   ##
=======================================
  Coverage   95.69%   95.69%
=======================================
  Files           1        1
  Lines         395      395
  Branches       42       42
=======================================
  Hits          378      378
  Misses         17       17

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Add a test dependency on python3-pytest.

It is required to run the tests that are here.

CI:

Linux
Linux-aarch64
Windows


igdm stop working - empty window

Last 24hrs the igdm doesn't work. Just an empty window.
Here is the output
$ npm start

><EMAIL_ADDRESS>start /home/user/APPS/igdm
> gulp build && electron .

[15:02:24] Using gulpfile ~/APPS/igdm/gulpfile.js
[15:02:24] Starting 'html'...
[15:02:25] Finished 'html' after 219 ms
[15:02:25] Starting 'build'...
[15:02:25] Finished 'build' after 14 μs
Checking for update
Update for version 2.4.2 is not available (latest version: 2.4.2, downgrade is disallowed.

Refer to #235 . Everyone is having the same problem


reconnect if the connection dropped

Hello, I am new to SMPP with golang. Can you please show how to reconnect if the connection dropped. Appreciate your feedback.

@sidawymaher The way I managed it is this:
defer func() { //catch or finally
    if err := recover(); err != nil { //catch
	fmt.Fprintf(os.Stderr, "Exception: %v\n", err)
	app.Initialize(config)
    }
}()
app.Initialize(config)

Where I intialize the bind in app.Initialize(config) and throw a panic whenever the connection drops.


Validate message format in producer

KafkaJS won't raise any errors if the message doesn't have a value attribute and this might be hard to debug.
Messages without value (e.g: { key: 'key1'}) should raise an error.

This happened again now. It was being called with:
// This was being AVRO encoded, which made it less obvious
const message = { foo: 'bar' }

await producer.send({
  topic,
  messages: [message],
})

Which led to messages being pushed with key and value null.


chore: add contribution guidelines

Summary
This adds a CONTRIBUTINGmd file that will assist new people with coontributing to the library.

Checklist:

[ ] This PR has been tested

[ ] The documentation has reflected the changes
[ ] The code has been linted and formatted

[ ] This PR fixes an issue
[ ] This PR adds a new feature
[ ] This PR adds a breaking change
[x] This PR is NOT a code change (e.g. documentation, README, ...)

sorry

apology accepted


fall guys got a new update pls fix it

fall guys got a new update pls fix it the offsets and all changed

done


fix(chain redirects): Follow up: Changing network in navbar always redirects to Landing page

Thank you for your contribution to the KodaDot - One Stop Shop for Polkadot NFTs.
👇 __ Let's make a quick check before the contribution.
PR Type

[x] Bugfix
[ ] Feature
[ ] Refactoring

Context

[x] Closes #6678
[x] Fixes: wallet address not updating after chain change

Did your issue had any of the "$" label on it?

[x] Fill up your DOT address: Payout

Community participation

[x] Are you at KodaDot Discord?

Screenshot 📸
Profile Page

Transfer Page

Identity Page

Copilot Summary

🤖 Generated by Copilot at 11de2ef
Added chain-specific features for identity and transfer pages. useChainRedirect composable and permision.config.ts file handle the logic and configuration of showing or hiding these features and redirecting users to the appropriate chain.

🤖 Generated by Copilot at 11de2ef

To support different chains with ease
They added some configs and keys
With useChainRedirect
They can now detect
The page type and availability

got one last small thing that is not working yet , when clicking on the identity button on the sidebar/modal it wont close it , will fix that asap

Hey @hassnian,
Things are super low here for me atm(canary not loading, balances not loading), so, i don't know if that's why this is occurring:
(identity field persists even if i don't have identity on that chain and deposit value also stays unchanged after chain change)
https://github.com/kodadot/nft-gallery/assets/36627808/99627bbc-7189-42e8-9207-78cd55c908c7
transfer page working nicely ✔
profile page working nicely ✔

@prury

pls try the identity page again , everything should work , let me know if you find any issues
can we create a new issue for the sidebar bug , when clicking on the identity button , the sidebar doesn't close, I know It's a small one but is not related to this pr

thanks

Tested on https://deploy-preview-6688--koda-canary.netlify.app/

Transfer - OK
Onchain identity - OK
Teleport - ❌
Profile - OK
Explore - OK
Drops - ❌

Tested on https://deploy-preview-6688--koda-canary.netlify.app/

Transfer - OK
Onchain identity - OK
Teleport - ❌
Profile - OK
Explore - OK
Drops - ❌

on it

@EthVlad a question, let's say i'm on the Drops page on the Kusama Asset hub and i change chains, where it should lead me to?
i could not stay in the same page because i've just changed chain and it would have to point the to the drop page in the changed chain. does it make sense?

1. pls try the identity page again , everything should work , let me know if you find any issues

Done, it works! ty, sent you a message on telegram about the sidebar bug

@prury pls try again

For me, this is too complex. I prefer this way:
Handle only if the pages are under pages/_prefix, else, redirect it to home (/${newPrefix}). So the pages component not under pages/_prefix by default will be redirected to home.
Let's say we want to support /identity. I prefer to move that component from pages/identity.vue to pages/_prefix/identity.vue
if (route.params.prefix) {
  // if (route.name === "prefix-u-id") handle address cross chain here
  // if ("prefix-gallery-id" || "prefix-collection-id") redirect to home
  // else replace just the prefix
  router.push({
    params: {
      prefix: newChain,
    },
    query: route.query,
  })
} else {
  router.push({
    path: `/${newChain}`,
  })
}

If some of the pages under pages/_prefix is still not supported in some chain, I prefer to put the onBeforeMount() handle in the pages component. For example, I put this code in pages/_prefix/drops/index.vue
onBeforeMount(() => {
  // list not supported prefix handle it here
  if (urlPrefix.value === 'bsx' || urlPrefix.value === 'ksm') {
    router.push('/')
  }
})

Or, if the pages are expected only specified in some chain, I prefer to put that outside /pages/_prefix. For example, pages/bsx/offers.vue

@prury Oh I see that drops page is only on Kusama hub. I thought it might be related to specific chain or all unified. In that case its ok that it leads to LP.

@prury had to change some code, feel free to test if everything works :D

Follow up about this one, then?
https://codeclimate.com/github/kodadot/nft-gallery/pull/6688

pay 50 usd
builds

😍 Perfect, I’ve sent the payout
💵 $50 @ 4.76 USD/DOT ~ 10.504 $DOT
🧗 16faLfsywwNATaEfbH2ah75dn6ZmctQWpMS5G4KFhbmj5hnD
🔗 0x3067b20fe709e088a09d27a07b251c3b049c8f737f55fd58616319fa54298406
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues

@yangwao I think something went wrong with the payout 👀

pay 50 usd

😍 Perfect, I’ve sent the payout
💵 $50 @ 4.77 USD/DOT ~ 10.482 $DOT
🧗 16faLfsywwNATaEfbH2ah75dn6ZmctQWpMS5G4KFhbmj5hnD
🔗 0x61e6e80c3cd9270ca425cf9ad6ecf889fe9c3c2b9bcb37d0223734070269599a
🪅 Let’s grab another issue and get rewarded!
🪄 github.com/kodadot/nft-gallery/issues

@yangwao I think something went wrong with the payout 👀

yeah we are caching balances too much and I was topping up balance on bot, yet wasn't that much on address, so it failed and than failed in cascade here :)
would be nice to check balances on sidebar and check for that like at least once per 30 seconds?


Dealing with Host failures

I'm currently exploring non functional testing on a POC environment we have stood up using rancher.
I've done a simple test to force power off one of the hosts rancher is managing, this however has highlighted a few issues. I've had a search on the issues list but couldn't find much covering them.
Expected Outcome:
I expected the host to be marked offline and i expected the services to maintain their scale by spinning up containers on other available hosts.
Actual Outcome:
Rancher detected the failure very quickly and marked the host in red with a message of 'reconnecting'.
However:

Services didn't attempt to maintain scale across other hosts, no new containers were spun up.
Applications view and infrastructure view still view the containers with a hollow green circle suggesting they are running fine.

Summary
From a user experience, I'd expect a host failure to be somewhat more highlighted within the GUI and i'd expect the containers which no longer exist to be highlighted in some fashion so i can quickly understand the impact of the failure. As a sidepoint and perhaps other ticket it would be nice to have a simple status traffic lights for services running through the load balancers.
From a service recovery point of view, i'd like to be able to configure the behaviour of rancher-server here in how it manages failure scenarios. A fairly safe non aggressive default should be fine and then allow the user to customise it to their requirements.  It's an area of functionality that needs careful considerations of the logic, that said it's also something that's critical as we are assessing rancher against tools such as vSphere / MS VMM.

I've been told that we should actually be seeing containers restart on other hosts, i'm wondering if there is something wrong with our configuration. All of our containers have health checks on the container and at the loadbalancer level. Example below, some config
Audit:
  restart: always
  labels:
    io.rancher.container.hostname_override: container_name
  tty: true
  image: registry:5000/aud:65
  stdin_open: true
  volumes:
    - /home/rancher/env_config/rt/tomcat/catalina.sh:/usr/share/secure_tomcat/bin/catalina.sh
    - /home/rancher/gluster:/mnt/gluster
    - /home/rancher/env_config/rt:/home/***_user/***
  links:
    - IAM-Database:***
    - LB-***:LB-***
    - LB-***:LB-***

@Rucknar Let me explain in detail how we manage host and service failures.  In short, you want to add service health checks to get the behavior you want.
Host Failures
When a host goes down we lose the connection to the agent.  Since the agent is not accessible we mark that agent as "reconnecting".  At this time all we know is that we can't talk to the host.  The host could be running, but experiencing a network partition or such.  You can reproduce this situation by just running docker stop rancher-agent.   The host is really fine, but Rancher can't talk to it.
Determining if a host is really in fact down is a sufficiently hard problem to solve in a generic fashion.  The approach we take at the moment is that we don't actually try to determine the host state.  We rely instead on service state to for determining if we should act on a failture.
Service Health Check
For each service you can add a TCP or HTTP based health check.  It's in the Advanced section on the create dialog.  We rely on these health check to determine if a service is bad.  How this works is when you enable health checks we run the health check monitor on up to 3 remote servers.  So if service A in running on Host 1, we set up health monitors from H2, H3, and H4.
When Host 1 goes down we loose connection to the agent, so you see "reconnecting".  We don't move the services to a bad state at this time.  That is why you still see green circles.  Once all three health monitors can no longer hit the service, we then decide the service is bad and will start reconciliation.

Thanks @ibuildthecloud I've updated my last response with the rancher-compose config for the same service (forgot before sorry). I presume that's the same level of service check? I created a dummy service just now and it looks to be correct.

Even after set the host as "inactive", API tell the container is still in state "running".

I would suggest a "yellow" state for services running on hosts that are in state "reconnecting", to flag a potential issue. I argue that it's equally bad to assume the services on a lost host are up and running just as much as they're gone.
The service checks are a good remedy to get out of this, and also the only way for rancher to base any decisions on scheduling wise, but for the UI, to get a feeling for the current state, it would be nice to highlight this condition.

@kaos but I guess it is that way right now. If a host is reconnecting the color changes of that host (kind of red). But regarding of the running containers, their state should not change, because reconnecting host does not mean that containers are affected. Only that maybe something is interrupting communication between agent and server. If something is wrong with the container their health checks will tell (as mentioned from ibuildthecloud).
That said I figure changing the color of all running container could be misinterpreted if there is actually nothing wrong happening. And also I rather keep the color yellow for something like response time is going critical (or equally).

Regarding the host, it clearly shows that it's not connected. It could perhaps be slightly clearer but it's enough for a user of the system to be alerted to the fact there is a potential failure at some level. Personally i'd rather it was more descriptive but that's a minor gripe.
Regarding the containers, if were unable to contact the host, we can assume their is an issue at some level, we just don't know what level. Perhaps the use of an exclamation mark that when you hover over states 'The host this container is running on is currently not contactable' would help here.
Currently it's assumed that it's running and doesn't highlight this in the interface, assumptions either way  will always lead to confusion, we just need to alert the user there is an issue that warrants further investigation.
I'm going to deploy a simple web app and re-test the above scenario. We don't currently have the services scale being maintained, aka containers aren't spinning up when a host fails. I need to understand if this is a configuration issue or a bug.

@fentas well, in my case, something caused all running containers on a host to go extinct, including the rancher agent instance. Being a lab environment, we haven't setup any health checks, so they all looked fine, until you browse the infrastructure side of things, you see that, aaahh, the agent isn't connected.. Now, each and every container doesn't really have to be marked any special way, but some sort of indication that the system is not 100% ok would be nice, regardless of which page you're at.
I like the idea from @Rucknar that there could be an additional hint, like an exclamation mark, or something, that indicates there may be some issue with the host the container is running on..
Also consider the possibility that not all services may have a TCP socket where you can check its health..

Yeah, the last is important. At some level, a service may exist as outbound only, not inbound, but it is critical. What if I have a batch reporting service that generates reports every 60 minutes and then dumps them somewhere else? It expects no input, has no TCP port, but it has to be managed to be up as much as anything else.
If this were old-school process management, I would rely on a monitor that checks the process, and then a monitor checking the host. If either fails, fail it over.
How would I replicate that here?

This is an interesting issue to solve. I don't see any way to generally solve this right, from ranchers perspective. As there may be any number of underlying issues, the most likely being: network down, agent down or host down. Which action to take would be application/deployment specific, so I'm inclined to suggest that the health checks available is extended to take into account these extra conditions, along with the desired action to take on each one. There is of course a problem to determine the difference between if the host or network is down. But given a few extra facts, like reference hosts to determine network status, should be able to help. Then it would be flexible at least, for how your rancher setup would handle these various scenarios on a per service level.

Actually, Rancher already has taken a stance on it. Rancher has an algorithm for determining if a service is down. It is treated as down if it is unreachable via tcp/http (whatever you defined in the health check) from 3 independent rancher agents.
Why can the same algorithm not be used for the host? Have each rancher agent, in addition to user-defined health checks, check the health of another agent. If it is unreachable, it is down.
If that algorithm is good enough for health checks on the service, why not for health check on the host?

To add (I just posted on the forum), we had health checks set up with Rancher-managed IP, it still didn't fail over.
Can we get a more detailed explanation of how health checks work, how to investigate and debug them? I want to see the health checks running, see their output, see why/how they determine that a service is up or down. Obviously in this case the health check is not successfully running and/or detecting failure.

Some useful discussion but to bring this slightly back on-track as i believe i'm seeing a bug.
I've done a re-test with a simple web app & loadbalancer running across two physical hosts. I've terminated one physical host (hard power off) and the application hasn't responded to restore scale.
docker-config.yml
WebsiteLB:
  restart: always
  ports:
  - 80:80
  labels:
    io.rancher.scheduler.global: 'true'
  tty: true
  image: rancher/load-balancer-service
  links:
  - WebServiceV1:WebServiceV1
  stdin_open: true
WebServiceV1:
  restart: always
  labels:
    io.rancher.container.hostname_override: container_name
  tty: true
  image: tutum/hello-world
  stdin_open: true

rancher-config.yaml
WebsiteLB:
  scale: 1
  load_balancer_config:
    description: Loadbalancer for website testing.
    name: WebsiteLB config
WebServiceV1:
  scale: 12
  health_check:
    port: 80
    interval: 2000
    unhealthy_threshold: 3
    response_timeout: 2000
    request_line: GET / HTTP/1.0
    healthy_threshold: 2

Here is the host showing as offline.

Here is the app, impossible to tell anything is wrong and it hasn't restored the services elsewhere.

What process health checks these containers? Is it on the host they run on?

@Rucknar There is one caveat you have to be careful of, don't know if this applies, but I'll just give you a heads up.  When we schedule the health check clients we never put in the same host as the container.  The health check client is the component that does the port/http ping check.  If we put it on the same host, we can never know the health check failed.  We schedule up to 3 clients if we can (this requires at least 4 hosts).
There is one exception though, if you only have one host, then we put it on the same machine.  So I just wanted to confirm that when you started this test did you have one host?  Then deploy some containers, add another host, deploy more.  In that scenario health checks will not work properly.
Besides that, it does sound like there could be a bug.  We'd have to try to reproduce on our side.
Right now I would say Rancher is pretty conservative when it comes to recovering from failure.  Other container system are more aggressive in spinning up new container based on "fuzzy" failure information.  Meaning that there is good indication that the service is gone, but they don't really know.  I think our conservative nature comes from our background in running persistent workloads.
I'm wondering if Rancher should have different policies for how to recover applications.  One can be aggressive where we don't wait for an absolute indication of failure, the other could be something more tailored to persistent work loads that require strong guarantees before taking action.

@ibuildthecloud what does that mean, "schedule the health checks on the same host as the container"? The health checks are a Rancher-wide thing, aren't they? How do you "schedule" them?

@deitch When you create a health check on a container/service that is running on host A, we then try to find 3 hosts that are not host A to run the healthcheck from.  So hosts B, C, D will be configured to ping your container/service on host A.  The health check scheduling refers to which host we decide to checks on.

@ibuildthecloud this is when using two hosts and failing one of those two, I've tested with 3 and got the same result.

@Rucknar thanks.  We will definitely look into this, sounds like a bug.
ping @alena1108 @sangeethah

@ibuildthecloud ok so you mean internally.
How do I look at logs of what the health check is trying to do? In our case, we had 3 agent hosts + server, set up a service with scale=1, the container is running sshd, set up a health check to port 22, and killed docker on the one host. The health check kept showing running.
I am not sure how to recreate it, but I can cause it to happen in our environment. Tell me what to look for to get debug output and I am more than happy to walk it through.

@deitch We don't expose this information well in the API/UI, we should.  @alena1108 @sangeethah Can you share SQL statements to run to check the state of the health checks that are running and where they are running from.

There is similar issue whet we are not able to mark instance unhealthy since the host in which the instance was running was also included as one of the host to monitor its health -
https://github.com/rancher/rancher/issues/1917

I wish I could give you access to our environment, but behind firewalls, etc. Consider me your smart-hands. Tell me how to see the checks, last checks, and where they log output.

@deitch , This sql command should list health state reported by each of the hosts that is assigned to monitor instance's health:
select * from healthcheck_instance_host_map where healthcheck_instance_id=(select id from healthcheck_instance where instance_id=<instance id>);

Is there some sort of log where I can see in real time as the health checks are performed, and what they see?

What is <instance_id> in this case? Is it the instance as shown by docker ps? How do I find it?

You can do a "View In API" and you will be see id. It would be in the format , 1i ,  would be the instance id.

<instance_id> would be the numeric ID rancher assigns to each container.. Go to the container in the UI, and it's the end of the URL, not including the 1i.  e.g. /infra/containers/1i42 -> 42.

OK, got it. It looks like right now in our environment the host is down, the health check is defined, and I have the ID. So I am going to check the sql now.

Hmm...
mysql> select * from healthcheck_instance_host_map where healthcheck_instance_id=(select id from healthcheck_instance where instance_id='122');
+----+------+------------+----------------------------+--------------------------------------+-------------+--------+---------------------+---------+-------------+------+-------------------------+---------+--------------------+--------------+
| id | name | account_id | kind                       | uuid                                 | description | state  | created             | removed | remove_time | data | healthcheck_instance_id | host_id | external_timestamp | health_state |
+----+------+------------+----------------------------+--------------------------------------+-------------+--------+---------------------+---------+-------------+------+-------------------------+---------+--------------------+--------------+
| 19 | NULL |         10 | healthcheckInstanceHostMap | c69c1f28-de56-483f-8b54-57e2dca7f464 | NULL        | active | 2015-09-24 07:01:22 | NULL    | NULL        | {}   |                       9 |       5 |               NULL | healthy      |
| 20 | NULL |         10 | healthcheckInstanceHostMap | c9dc003c-6a57-426e-ac3c-4009b0b704bf | NULL        | active | 2015-09-24 07:01:22 | NULL    | NULL        | {}   |                       9 |       2 |<PHONE_NUMBER> | unhealthy    |
+----+------+------------+----------------------------+--------------------------------------+-------------+--------+---------------------+---------+-------------+------+-------------------------+---------+--------------------+--------------+
2 rows in set (0.01 sec)

So running select * from hosts; shows that 5 and 2 are 2 of the 3 known hosts (the third is where the service container was running), both are fine and have state active.
What next?

In your case , 2 hosts - 5 and 2 where assigned to monitor this instance health and host id -5 was not able to detect the state of the instance as being unhealthy.  We expect all the hosts to report the state of instance as being "unhealthy"  to mark the state of the instance as "unhealthy".

Right, so you know what my next question is. Why did host 5 not succeed in marking it as unhealthy?
BTW, I concur with what the commenter said earlier: there needs to be a way to choose how aggressive an algorithm you want.

FWIW, docker ps | grep rancher on host 2:
# docker ps | grep rancher
019931dad304        rancher/agent-instance:v0.4.1                                "/etc/init.d/agent-in"   13 hours ago        Up 13 hours         <IP_ADDRESS>:500->500/udp, <IP_ADDRESS>:4500->4500/udp   b0999a69-98bb-4fb1-b935-55e8712cfe83
018a7f7fa8d7        rancher/agent:v0.8.2                                         "/run.sh run"            7 days ago          Up 13 hours                                                        rancher-agent

and on host 5:
# docker ps | grep rancher
b200a4f9e813        rancher/agent:v0.8.2                                         "/run.sh run"            3 days ago          Up 3 days                               rancher-agent

host 5 is not able to mark the host healthy because there is no Network Agent running.
Workaround can be to start a network agent in this host , by deploying an instance in this host.
After this , host should be able to mark the state as "unhealthy".
This bug that we do not have a network agent running on a host ,that should be monitoring health for instances needs to be addressed.

So you are saying:

the rancher-agent should have started the network agent
the network agent would have monitored the health
because the rancher-agent failed, it didn't know my health check failed
the rancher server/agent should have known no network agent is running

In other words, rancher agent failed its own health check, but didn't alert or fix itself (failed silently) and so my health check also failed silently? Shouldn't rancher know and handle these issues?
Or are you saying that is the bug, and it is known and will be fixed?

1/2/4: Yes.  3: Sort of, it didn't exactly "fail".. The bug is that nothing currently schedules the creation of a Network Agent if there isn't already one on the host chosen for the health check.
@alena1108 it also seems wrong that the health_state is defaulted to healthy here instead of initializing when the state was obviously never set by an actual check.  If it wasn't marked healthy the state would have shown degraded and it would have been more obvious that something was wrong.

@vincent99 I don't agree. Look at it from a user's perspective:

I scheduled a health check
The health check isn't running but the system says it is

That is all that matters. The fact that part of the components are running (server and agent) and part not (network-agent) is not of much interest except in debugging.
The proximate bug may be that "nothing currently schedules the creation of a Network Agent if there isn't already one on the host chosen for the health check." But the fundamental problem is that a crucial component of the system - one which can lead to a cascade of errors, like in this case - can fail (or not start) without the system being any the wiser.
I would've assumed it works like this:

server knows all of its hosts, speaks to and checks on those agents
if any agent is unreachable, the entire host on which that agent runs and all of its dependencies are treated as unreachable (or "in error" or whatever you want to call it).
each agent should be checking regularly all of its own dependencies, e.g. network agent (although personally, I would have rolled it into a single agent container).
each agent should restart its dependencies if needed, and report on their state to the server
if the server does not have a positive assessment of a dependency, it should treat it as missing and reschedule dependencies on those. So if I do not have a positive assessment of a network agent, create the health check elsewhere or, at the very least, remove this node's status from the algorithm

In the meantime, though:

When is this scheduled to be fixed?
What can I do to work around this?

I don't relish the idea of building my own container monitoring system and then using the API to force it to move elsewhere.

This is GitHub, we're talking about the code.  All I meant is the issue is not in rancher/agent because it was never told to create the Network Agent and the health check state didn't "fail" because nothing existed to update it.  The root issue is that cattle never told the host to create a Network Agent (it would download it's config containing the check definition on startup), and additionally some other factors made this situation undetectable.

server knows all of its hosts, speaks to and checks on those agents
if any agent is unreachable, the entire host on which that agent runs and all of its dependencies are treated as unreachable (or "in error" or whatever you want to call it).

rancher/agent (which communicates with the rancher/server, creates/destroys containers, etc) on each host connects to the server.  If the agent is not connected the host will show "reconnecting" state.
This does not provide any information as to whether the host is actually still ok or not, as the agent can be disconnected for a variety of reasons while the host and containers on it are still fine.  For example, while upgrading the agent itself, or there is a network partition separating the server from host(s).

each agent should be checking regularly all of its own dependencies, e.g. network agent (although personally, I would have rolled it into a single agent container).

They are not "dependencies" per se.  The rancher/agent tells docker to run containers.  One of those can be the Network Agent (the image is rancher/agent-instance) which provides the IPSec point-to-point network and healthchecks for containers on those networks.  Though not exposed today, there could be multiple separate networks and therefore multiple Network Agents per host.

each agent should restart its dependencies if needed, and report on their state to the server

This is "turtles all the way down".  Now you need something to check that the checker that checks that the agent is up is still checking, ad infinitum.

if the server does not have a positive assessment of a dependency, it should treat it as missing and reschedule dependencies on those. So if I do not have a positive assessment of a network agent, create the health check elsewhere or, at the very least, remove this node's status from the algorithm

The health checks report their state to the server in the table you were looking at.  The external_timestamp is the last time it was reported.  The checker should be considered down if the time is "too old".  Like having a check for the checker, sans turtles.

When is this scheduled to be fixed?

Likely next week's release, but since this thread just worked out the root cause this afternoon we (@alena1108, @ibuildthecloud and I) haven't yet gotten together to evaluate what changes need to be made, their scope, or the priority of each.  Particularly given the workaround is fairly straightforward (below).
There are several things to look into:

[ ] Scheduling a health check doesn't ensure that a Network Agent is scheduled on the host to run it
[ ] The default health state is apparently healthy instead of initializing
[ ] The external_timestamp is null but that check state was apparently still considered valid.  Is the timestamp actually used in the evaluation?
[ ] Is there logic to reschedule a health check to another host when an agent is disconnected? A host is deleted?  A network agent is deleted?  The timestamp isn't updated in "a while"?
[ ] Is the state unhealthy in the API when 1, 2, or 3 checks fail?  (I think it's 3).  Maybe there should be an intermediate healthState in the API for mixed or something if there is disagreement between the check states.
[ ] Should the number of checks scheduled and the threshold for unhealthy be options?  (global settings, or part of the healthcheck definition?)  Maybe people like flapping and want rescheduling on a single failure, or want to be really sure and want to run checks from every host and wait until they all fail.

What can I do to work around this?

Deploy a container on every host so that a Network Agent will be created.  An easy way would be to create a service with global scale ("Always run one instance of this container on every host") using a small image like busybox that does nothing.

That's a pretty detailed answer, thanks.

This is "turtles all the way down". Now you need something to check that the checker that checks that the agent is up is still checking, ad infinitum.

It is, but at a certain point you just say, "that's it." So rancher needs agents? It checks on them. Rancher needs health checks, which use network agents? It checks that they are up.
The trap we fell into here isn't that scheduling a health check doesn't necessarily start a network agent; that is a bug, nice debugging on it. The core issue is depending on something and not checking its existence from the one service we know has to be up: rancher server, which needs to know proactively that an agent and necessary components are up.

The health checks report their state to the server in the table you were looking at. The external_timestamp is the last time it was reported. The checker should be considered down if the time is "too old". Like having a check for the checker, sans turtles.

Like that approach.  Let it check (e.g. timestamps) with enough frequency to be satisfied, and if it sees a problem, try to resolve it or, at the very least, flag it.
In your terms: the server is the bottom turtle.

Deploy a container on every host so that a Network Agent will be created.

Do you mean a container "with rancher-managed networking", right? I have a container running on every host, but it has host networking, so it didn't trigger it.
If it will come out patched next week, that works for us. Flag here if you have a beta you want me to try. More than happy to help.

Yes a container with managed network.
Hmm, there's another one.  We probably can't offer health checks for every network mode, 3 other random hosts don't necessarily have a way to reach the container.

You mean if a container isn't using rancher-managed networking? Yes, I raised that earlier. And if you have a container that has not open ports, e.g. a batch processor that goes to a data source every 10 mins, gathers data, and sends out a report (I can think of lots of examples).
In this case, the classic way to monitor is by process. We really need a health check that involves monitoring the process via rancher-agent (or process-agent spinoff, or similar).

@vincent99 Submitted a pull request for the docs, just added in a little more detail about health checking based on this conversation, easier to read for others than this thread!

Thanks @Rucknar for the docs about details on health checks. We've incorporated them into the docs site at http://docs.rancher.com/rancher/concepts/health-checks/

@deniseschannon I saw you closed it. There still was an open discussion about using the "health check algorithm" (up to 3 independent hosts monitoring the agent), and if all 3 fail, then to treat the entire host and all its containers as down, and thus maintain scale by moving the containers to other hosts.
This is necessary so that services that cannot have tcp-based health checks (no IP, no inbound services, etc.) can be managed by Rancher as well.

@deitch The issue you are discussing is a duplicate of this: https://github.com/rancher/rancher/issues/1917

@deniseschannon I don't think it is. I am not discussing the issue with currently defined tcp-based health checks failing. I am talking about being able to manage the state of a Service's containers even without tcp-based health checks at all. Since the agent already exists, and can monitor the containers locally and thus know their state(s), they should be able to act as their own local health-checkers, and their state, in turn, can be determined by other agents.

+1 for that last description @deitch , very clear (and something I'd like to see :)

The state and health of the rancher/agent is not a good proxy for the condition of a host of the user containers on it.
The agent already does keep track of the state of the containers on the host.  If a container stops it will be reported up, the UI will show it stopped, it will be restarted according to the restart policy (which defaults to always for services), etc.  That is all part of the native docker integration so that we know about docker runs or docker stops performed on the host.
What it sounds like you want but is missing is a way to use the container state as a "health check" and cause it to be rescheduled to another host instead of just restarted.  To be useful this would have to have some different options like consider it unhealthy if it stopped X times in Y seconds.l, we can't go shuffling containers every time they restart.
Or you can add a small http daemon inside the container of a process thar otherwise would not have one, to do some checking and reports a health state out.  Monitoring that a process is still running is pretty coarse and not really all that helpful.  It doesn't tell you that the process is successfully still doing anything other than existing; it could be hung, deadlocked, unable to connect to a dependency, out of disk space, etc.  An actual check to e.g. watch a logfile for a line showing that your report was sent out in the last 10 minutes is much more valuable.

Also we still have an open bug where no failover of any type works. I'm happy to raise another ticket for this and leave this to the discussion but that was the tickets original purpose.

or you can add a small http daemon inside the container of a process

@vincent99 that isn't very realistic. Almost no one is going to add an http daemon, with all its attendant overhead, management, security risks, performance tests, everything, just to do a 200 check! Who is going to want to rebuild and reconfigure their container for that? They will say, "if a tool cannot monitor process liveness, it is missing something basic."
I used to run enterprise management at a very large firm. I brought in the modern host and process monitoring (pre-container days). I brought in tcp monitoring tools too, for E2E. But that was later. First, I needed to fundamentally know and manage processes: is it running? How well is it running is something I worried about after I had covered the basic "blocking and tackling" of processes.
Don't get me wrong; I love Rancher. I put a lot of effort into it, recommended it, so I have some reputation on the line. And I think one of its strongest assets is the sheer speed of iteration of the team. But I am ask if we get what customers do: the fundamental unit of deployment, and therefore of health, is the container. If the container is up, all is good; if it is not, all is not. If you do not know the state of the container, have an algorithm that resolves the uncertainty.
Just about every customer on this discussion and the one on the Rancher forum said:

I created a service (without health checks)
I set scale=1
I killed the host, Rancher didn't move it over. What is broken?

People expect the container monitor and manager built into the orchestrator to watch the container because it just makes sense. Heck, that is what every cluster management system always has done. I used to do it with Veritas 20+ years ago. Not working that way violates the principle of least surprise.
Allow me to put it in product management terms. Do you want to say, "Rancher is awesome for managing all your services across a multi-host cluster"? Or do you want to say "Rancher is awesome for managing all your services across a multi-host cluster, except for services that do not have a listening http or tcp port open, which, by the way, is a major portion of enterprise services (and hence containers), so go find some other orchestrator to manage it"?
When you ask potential customers to either change their software to fit your monitoring, or do some additional engineering to create monitors, they will look elsewhere.

Monitoring that a process is still running is pretty coarse and not really all that helpful.

I disagree and agree completely. Monitoring that a process is still running is pretty coarse... but it is extraordinarily helpful. This is the very basic level of monitoring. Everything else - TCP checks, logfile checks, etc. - are all at the next level. It is fabulous that Rancher gives us customers the opportunity to use a more intelligent level of monitoring, but start with the basics.
I love a good steak, it is great it is on the menu, but if I am eating here three times a day, make sure you offer a salad, sandwiches and soup before you offer steak.
Ok, I think I have made my point (probably too many times). Let me summarize:

Rancher's TCP health checks are great, but they miss the very basic level of monitoring and management
Customers expected failover to work the way I described, not the way it actually functions.
Rancher is damn cool but has a gaping hole at the basic level for one of its fundamental tasks, while most of the logic for filling that hole already exists. Why drive customer to something else?

@Rucknar I think your issue has become intertwined with lots of discussion. Could you please create a new ticket for your issue that you are still seeing?
@deitch Similarly, I wonder if it'd be better to create a new ticket for what you are looking for regarding. "I am talking about being able to manage the state of a Service's containers even without tcp-based health checks at all. Since the agent already exists, and can monitor the containers locally and thus know their state(s), they should be able to act as their own local health-checkers, and their state, in turn, can be determined by other agents."

Thanks @deniseschannon I've done that now.

Good idea @deniseschannon; done. See https://github.com/rancher/rancher/issues/2195

@deniseschannon @vincent99 going back to what we agree was a bug, quote from @vincent99 :+1:

Scheduling a health check doesn't ensure that a Network Agent is scheduled on the host to run it

Do we have a targeted release for fixing it?

@deitch I've just created an issue for the
"Scheduling a health check doesn't ensure that a Network Agent is scheduled on the host to run it"
It's #2287
I'm going to close this issue as it's hard to track exactly what we're trying to fix. I believe we've created separate issues for everyone who has chimed in. For any other issues, please open a new issue.

Thanks, @deniseschannon

I am still having an issue, even with the workaround. I am opening a new issue.

What I've found so far is that starting a rancher-compose deployment with s3 based builds places a heavy network demand on the rancher server machine and causes random node disconnections. The same deployment with images placed in a local registry runs smoothly without any issues because rancher server machine has spare bandwitdh to talk to other nodes. I am using rancher server 0.56. Hope this might help some of the issues pointed out here.

@jmcarbo What you're seeing/describing is related to this issue: https://github.com/rancher/rancher/issues/2137

I feel like Rancher's current behaviour handles this really badly. The entire point of rancher/docker/scaling is that if I have a problem with part of the system, it shouldn't bring the entire site down. It's entirely self defeating. Plus the fact that after a huge amount of digging, it doesn't actually seem to be possible to add a healthcheck to an existing service. You have to clone/recreate the service.

I am wondering if there is a saner way, e.g. to use the autopilot pattern with Rancher.


Collect element power telemetry data

Adds element.power command support to gather element Power telemetry.

@RackHD/corecommitters @zyoung51 @tannoa2 @keedya @uppalk1

+1


Not able to detect documents on white table.

Its not detecting white paper (ex:Bank Cheque) on white table.

There must be a certain amount of contrast to detect the edges of a document.

Please verify the cam scanner app (iOS), which is able to do that .


Line 926: Failed to escape sandbox.

using beta 36, have tried a number of times. rebooted, yet still get this error.
stops about here:
[*] Escaping Sandbox... [*] error reading kernel @0x56007a2064207178 [*] myProcAddr = 0x0000000000000000 [*]  __assert(9:ISADDR(myProcAddr))@JailbreakViewController.m:926[jailbreak]
@jakeajames do you think you could offer insight, since if i recall correctly you did sandbox patches?

okay, i added some debug lines of my own and it's solved??? added this at line 924 and 925
LOG("myPid= " ADDR, myPid); LOG("AAA= " ADDR, get_proc_struct_for_pid(myPid));

have not closed because i would still like insight into why this randomly happened and then stopped. @jakeajames ?

Restart and click jailbreak again

Hi, I am getting this error even after using beta 43, I have iphone X 64 GB, and using IOS 12.1.1 beta 3

I have a similar issue, on my X on 12.1.2(16C104) :
Errno: 9
Filename: JailbreakViewController.m
Line:884
Function: jailbreak
Description,: Failed to escape sandbox.```

I've tried many betas like @Regaily and still none of them worked.


basic auth dialog

Can't find a way to fill the user/password in the basic authentication dialog in the browser:

Any idea ?

Okay that didn't take too long to figure out.
You need to use Authorization header:
const puppeteer = require('puppeteer');

const user = 'myuser';
const pass = 'mypass';

const headers = new Map();
headers.set(
  'Authorization',
  'Basic ' + new Buffer(`${myuser}:${mypass}`).toString('base64')
);

(async () => {
  const browser = await puppeteer.launch({ headless: false });
  const page = await browser.newPage();
  await page.setExtraHTTPHeaders(headers);
  await page.goto('https://example.com');

  // browser.close();
})();

Could have been more elegant, but works...

For the reference: a more elegant approach is suggested in #426

@aslushnikov  when I use , it shows "page.authenticate is not a function"

For me, it did not work with Map, :
const auth = new Buffer(`${user}:${pass}`).toString('base64');
await page.setExtraHTTPHeaders({
    'Authorization': `Basic ${auth}`
});
page.on('request', request => console.log(`Request: ${request.resourceType}: ${request.url} (${JSON.stringify(request.headers)})`));

@Aaronphy page.authenticate(credentials) is only available since 0db6165d7389df6f1a3a4c09fcf1d338bc3351a2 . There was no new release since this was added. You could install the latest master with
npm i --save https://github.com/GoogleChrome/puppeteer.git
or wait for puppeteer > v0.10.2

@konstantinblaesi Thank you, have been trying to get this to work all morning and couldn't figure out why it wasn't working... It may be nice to have Since vX.Y on the docs