Primitive Instancing (via ie. Linked Duplicates)

Is your feature request related to a problem? Please describe.
Mesh modifications on imported glTF meshes do not get reflected on meshes that have constructed sourced from the same Primitives.
It's as if the glTF importer creates hard-copies of them everywhere, which does not fit my use case & doesn't seem like the right thing to do in general (?).
Describe the solution you'd like
I would like for changes that I make to imported Meshes in Blender, to be reflected for all other Meshes that use the Primitive that I modified.
The only difference in them (at least for my use case) would be the transformation matrix, ie. position, rotation, scale.
This might also be possible at the Mesh level since they can all be attached to an extra Node (?) which themselves contain an xform matrix. Not sure, I haven't looked at the glTF spec that much.
Blender supports Linked Duplicates. This can likely be implemented with this functionality.
Describe alternatives you've considered

Trying other 3D software packages that might support this.
Working on implementing this functionality myself (unlikely, got way too many projects going on)

Additional context
I could go into more detail but my use case is imported game levels that usually contain lots of instanced objects.
Thank you.

Instancing via linked duplicates is already implemented when nodes share same mesh data.
If you think this is not working for some cases, please attach a glb or gltf file that seems to not work properly. We will have a look.
Thanks!

Ahh, so the second thing about the Nodes I mentioned is implemented.
I only tried the former, which is Primitives being shared instead of Meshes.
Working example:
f_nightclub_exterior (16).zip
Not working example:
f_nightclub_exterior (17).zip

Quick clarification on this code — the gltf-transform Primitive type can be reused by multiple meshes, but in the glTF schema, copies are inlined with each mesh instance. The vertex data is not duplicated, so you end up with several meshes containing identical primitives, each referencing the same underlying accessors and materials:
"meshes": [
        {"name": "Mesh1", "primitives": [{"attributes": { "POSITION": 0 }, "material": 0}]},
        {"name": "Mesh2", "primitives": [{"attributes": { "POSITION": 0 }, "material": 0}]}
]

If you can reuse the entire mesh I would — that'll be simpler and more compact — but I suspect there's another reason to try support this in the Blender importer anyway. Consider:
"meshes": [
        {"name": "Mesh1", "primitives": [{"attributes": { "POSITION": 0 }, "material": 0}]},
        {"name": "Mesh2", "primitives": [{"attributes": { "POSITION": 0 }, "material": 1}]} // <-- different
]

We'd ideally import this as linked duplicate meshes, with unlinked materials. I'm not sure if that is supported here yet.


Movefocus dispatcher on floating windows

It would be great if floating windows get the movefocus dispatcher to work properly, following the direction parameter.
Cheers.

is current implementation enough?

is current implementation enough?

yeah, this is fixed, thanks !


itch: excessive logging ?

Just playing at the moment, but the log messages in the main Parse...() calls seem excessive. Typically an imported package shouldn't do it's own logging, should it?
I know I can fork and remove the log lines but perhaps a better way could be found?

@pgalbavy-itrs
Hello yes you're right generally a library shouldn't be logging, or should at least accept some logger from the user. I'll make some changes

@pgalbavy-itrs Thanks for the report. I've removed logging from the itch package now


TypeError: init() takes from 2 to 3 positional arguments but 4 were given

Changed logging to debug but nothing was caught.
I see this from the main.py:
INFO - /usr/bin/python3 INFO - Loading config file /opt/PlexAutoSkip/config/config.ini. INFO - Connected to Plex server BEAST using plex.tv account Traceback (most recent call last):   File "main.py", line 76, in <module>     intro_skipper.start(sslopt=sslopt)   File "/opt/PlexAutoSkip/resources/introSkipper.py", line 38, in start     self.listener = SSLAlertListener(self.server, self.processAlert, self.error, sslopt=sslopt)   File "/opt/PlexAutoSkip/resources/sslAlertListener.py", line 19, in __init__     super(SSLAlertListener, self).__init__(server, callback, callbackError) TypeError: __init__() takes from 2 to 3 positional arguments but 4 were given

Looks like you might be on an older version of the python-plexapi, they added the 4 parameters in November of 2021
15e011fd291ecfb7d9da1e1596cb421e74ec8b9f
Try updating using
pip install --upgrade plexapi

Added backwards compatibility and included a log message recommending updating if users encounter this issue, going to close this out for now but please reopen with any issues

pip install --upgrade plexapi resolved the issue.


VuePress in maintenance mode

The repo https://github.com/cypress-io/cypress-realworld-testing uses<EMAIL_ADDRESS>and according to README > Status

VuePress is now in maintenance mode. For a next-gen Vue-based SSG built on top of Vue 3 + Vite, check out VitePress.

To keep up maintainability of the learn.cypress.io site, it may be necessary to migrate cypress-realworld-testing to VitePress. At this time VitePress is available as a v1.0.0-rc.x version, so it may be too early to migrate, if only a release candidate version is available.

Closed due to no feedback.


cats-effect 3 Release Plan

Hi 👋
Thanks for the library! I can see in the README.md file

Support for Scala 3 and cats-effect 3 is available on master, but has not been released yet.

I wonder what are the plans for making a new release? Thanks in advance.

Hi there, the release is ready, but blocked on http4s doing a final release for cats-effect 3 and Scala 3, which is still pending. Once they are ready I will release within a few days.

http4s released on Friday, and Laika 0.18 for Scala 3 and cats-effect 3 is out today: https://github.com/planet42/Laika/releases/tag/0.18.0.
I'm closing this ticket now.


https://medium.com/@neerajs296

You want to add your news to this huge list!
That's great.  I'd love to add it.  If you can share where your content is I'd love to only link to it.  To do this I need the way to get the data.
If you have a RSS feed, that works best.  However if I have to get it differently I can do that too, I just need to know where this data is.

Title: https://medium.com/@neerajs296
Category:
RSS Link or Other Endpoint:

Added


Block Blob Size in GiB are rounded

Preflight Checklist

[X] I have installed the latest version of Storage Explorer.
[X] I have checked existing resources, including the troubleshooting guide and the release notes.
[X] I have searched for similar issues.

Problem
Would like to download the larger of two block blobs. I have to view the properties of each blob to determine which is larger.
Desired Solution
Would like additional precision on block blob sizes (2.123 GiB). Or a configuration item that lets me view the raw value with commas (ex: 2,123,123,123)
Alternatives and Workarounds
Right-click on each blob and scroll down to properties which is time consuming
Additional Context
I have a screenshot, but two blobs side-by-side show as 2 GiB but one is slightly larger than the other. I can't tell unless I open properties

An example of what the view looks like.

We will preserve two digits after the decimal point if the size is in a unit greater or equal to KiB in 1.32.0.

Thank you for the quick turn around on this! Much appreciated!


[Power Toys - Color Picker]: The name property must not contain any character in the private Unicode range for 'Activate Color picker' Text.

Microsoft PowerToys version
0.41.3
Running as admin

[ ] Yes

Area(s) with issue?
ColorPicker
Steps to reproduce
Test Environment:
OS: Windows 10 Version Dev
App version: 0.41.3
App name: PowerToys
Screen Reader: Narrator
Tool: Accessibility Insight for Windows
Repro Steps:

Launch Accessibility Insights for Windows tool.
Open Power Toys Settings App.
Navigate to "Color picker" list item and activate it.
Run Accessibility Insights for Windows tool.
Observe the issue.

User Impact  -> Priority 2
If the object role, state(s), properties, boundary, name, and description are not programmatically determinable, it would be difficult for the platforms that provide Accessibility APIs, and would in turn affect the screen reader dependent users to determine the object properties.
WCAG Reference:
https://www.w3.org/TR/WCAG21/#name-role-value
Note:
Issue is repro for "Open PowerToy Run" Text on PowerToy Run window.

✔ Expected Behavior
The name property must not contain any character in the private Unicode range for 'Activate Color picker' text.
Modify the Name property, removing all characters in the range U+E000 to U+F8FF and replace them with meaningful, standard text content.
❌ Actual Behavior
The name property must not contain any character in the private Unicode range for 'Activate Color picker' text.
Other Software
No response

Resolved with the release of v0.43.0. Thanks @niels9001!


:robot: Triggering CI on branch 'release-next' after synching to upstream/main

  * could not run steps: step e2e-aws-ocp-48 failed: failed to wait for the created cluster claim to become ready: timed out waiting for the condition

/test 48-e2e-aws-ocp-48

OCF Webhook is merging this PR


[SPARK-40941][K8S] Use Java 17 in K8s Dockerfile by default and remove Dockerfile.java17

What changes were proposed in this pull request?
This PR aims to use Java 17 in K8s Dockerfile by default and remove Dockerfile.java17.
Why are the changes needed?
To update for Apache Spark 3.4.0.
$ docker run -it --rm kubespark/spark:dev cat /etc/os-release | grep PRETTY
PRETTY_NAME="Ubuntu 22.04.1 LTS"

$ docker run -it --rm kubespark/spark:dev java -version | grep 64
OpenJDK 64-Bit Server VM Temurin-<IP_ADDRESS>+1 (build <IP_ADDRESS>+1, mixed mode, sharing)

Does this PR introduce any user-facing change?
Yes, but only the published docker images will get the latest OS (Ubuntu 22.04.1 LTS) and Java (17 LTS).
How was this patch tested?
Pass the CIs.

cc @Yikun

Could you review this, @viirya ?

Thank you so much, @viirya . Merged to master for Apache Spark 3.4.

Thanks, late LGTM.

Thank you, @Yikun .


bummi: Watch https://photoshopgo.info/

bummi requests the watch of the watch_keyword https://photoshopgo.info/. See the MS search here and the Stack Exchange search here.

https://photoshopgo.info/ has been seen in 0 true positives, 0 false positives, and 0 NAAs.

Superseded by #2936.


Fixing up links in some pages

Description
There are some link that have not been updated as per new folder structure
Screenshots
No response

/assign

@ephemeralshay go ahead


Add custom elements manifest analyzer

Related #388
This change is the start for adding a custom elements manifest.
Related to https://github.com/muxinc/media-chrome/discussions/158
A little downside of Media Chrome using constant variables is that the analyzer can't pick the attributes and events up automatically. An alternative is to use special JSDoc syntax to get these picked up.
https://custom-elements-manifest.open-wc.org/analyzer/getting-started/#supported-jsdoc
I added one example for the Airplay button.
~The custom function defineCustomElement() in Media Chrome was causing issues too, luckily this could be automated with a plugin.~ The analyzer expects customElements.define('my-el').

Otherwise, I'm lovin' it.

Me too. Very happy to see this getting movement!

todo(blocking): Add the manifest to our .gitignore

@cjpillsbury it's output in the dist folder 😉

A little downside of Media Chrome using constant variables is that the analyzer can't pick the attributes and events up automatically.

Should we not use constants in the places where the analyzer doesn't want them? It's not like those strings are gonna change.


mesa: backport patches to fix build on Darwin and 32-bit platforms

Description of changes
Fixes #274177 (hopefully). Also, made Darwin patches unconditional so we know when they don't apply (they didn't apply).
Things done

Built on platform(s)

[x] x86_64-linux
[x] i686-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

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

[ ] sandbox = relaxed
[ ] sandbox = true

[x] Tested, as applicable:

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

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

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

[x] Fits CONTRIBUTING.md.

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

It's not going to finish on ofborg.

OK, on the latest commit it builds for x86_64-linux and i686-linux locally, and for aarch64-darwin on the community builder. If anyone has more obscure targets to test, please do so now.

Master + just the Mesa changes from staging builds on aarch64-linux also.

@ofborg build mesa pkgsi686Linux.mesa

ofborg still times out trying to build a Darwin stdenv so I guess this is as good as we're going to get.


DEV-27670 document optional CheckRequest.language field (based off develop branch)

@replrep Sorry for the long wait, your changes are now merged and will be published together with the upcoming Platform release.


Schema.instrument is deprecated

See https://github.com/rmosolgo/graphql-ruby/pull/4771.
instrument is deprecated (to be removed in graphql-ruby 3.0) and should be replaced with trace_with.
Latest docs: https://graphql-ruby.org/queries/tracing.html

Fixed by https://github.com/Shopify/graphql-metrics/pull/87. I'll release a new version


Upgrade ember-test-utils dependency

Upgrade to the version release due to the resolution of https://github.com/ciena-blueplanet/ember-test-utils/issues/95

Closed via: https://github.com/ciena-frost/ember-frost-test/pull/37


YETUS-871. cleanup the junit output format

we should change the various CI config files we have that still refer to --junit-results-xml in the same PR.

Doh. Good catch.  I'll let it run through all of the CI systems in my fork to see what happens.

(!) A patch to the testing environment has been detected.
Re-executing against the patched versions to perform further tests.
The console is at https://builds.apache.org/job/yetus-github-multibranch/job/PR-70/1/console in case of problems.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Comment

:blue_heart:
reexec
2m 37s
Docker mode activated.

_ Prechecks _

:green_heart:
dupname
0m  0s
No case conflicting files found.

:green_heart:
@author
0m  0s
The patch does not contain any @author tags.

_ master Compile Tests _

:blue_heart:
mvndep
0m 15s
Maven dependency ordering for branch

_ Patch Compile Tests _

:blue_heart:
mvndep
0m  4s
Maven dependency ordering for patch

:green_heart:
shellcheck
0m  0s
There were no new shellcheck issues.

:green_heart:
shelldocs
0m  0s
There were no new shelldocs issues.

:green_heart:
whitespace
0m  0s
The patch has no whitespace issues.

:green_heart:
yamllint
0m  2s
There were no new yamllint issues.

_ Other Tests _

:green_heart:
asflicense
0m 15s
The patch does not generate ASF License warnings.

3m 35s

Subsystem
Report/Notes

Docker
Client=19.03.1 Server=19.03.1 base: https://builds.apache.org/job/yetus-github-multibranch/job/PR-70/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/yetus/pull/70

Optional Tests
dupname asflicense yamllint shellcheck shelldocs

uname
Linux c397f359a946 4.15.0-54-generic #58-Ubuntu SMP Mon Jun 24 10:55:24 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
precommit/src/main/shell/personality/yetus.sh

git revision
master / e8f542b

Max. process+thread count
45 (vs. ulimit of 2000)

modules
C: . precommit U: .

Console output
https://builds.apache.org/job/yetus-github-multibranch/job/PR-70/1/console

versions
git=2.7.4 maven=3.3.9 shellcheck=0.7.0 yamllint=1.12.1

Powered by
Apache Yetus 0.11.0-SNAPSHOT https://yetus.apache.org

This message was automatically generated.

Tested this on a variety of CI systems, all appear to be working as expected.

Thanks!


Parameter: orf-filter easy-taxonomy workflow

Hi,
I have a question about the parameter orf-filter in the easy-taxonomy workflow.
What is this filter exactly doing? And what is recommended? And is the filter on or off at 0?
Thanks in advance

The orf filter is the procedure in A2 in the paper:
https://academic.oup.com/view-large/figure/408303786/btab184f1.tif
It works well and speeds up taxonomic annotation of contigs by a lot, however for short reads it can falsely reject reads that otherwise might get a taxonomic label.

Thanks for the fast reply and the answer, I understand it now!


Productize System.Text.Primitives

[ ] Fix issues in parsing APIs: #1070
[ ] Fix issues in  formatting APIs: #1089
[ ] Fix issues in encoding APIs: #1091
[ ] Design and implement representation for UTF8 string/text
[ ] Design how we will support non-invariant culture creation
[ ] Review the APIs with globalization experts
[ ] Move System.Text.Primitives to corefx repo
[ ] Write solid documentation, blog, getting started guide

@joshfree, @terrajobst, @shiftylogic, @ahsonkhan, @botaberg, I added this issue to track overall work related productizing the System.Text.Primitives component. Feel free to add/tweak workitems.

Should we add cleaning up some of the outdated/unnecessary benchmark tests that are part of System.Text.Primitives here so we don't have 500+?

@ahsonkhan We can definitely remove some of the tests. I was thinking about removing all of the tests in InternalParserTests.tt and InternalParserPerfTests.cs. However, this will not remove any benchmarks from System.Text.Primitives since all benchmarks in InternalParserPerfTests are disabled. We may need to do something else to decrease the testing time. Doesn't most of the time come from the E2EPipelineTests? Can we split those out into a separate assembly?

I updated the issue with workitems that have been completed. The two that are not completed are the following:

[ ] Design APIs to create non-invariant/custom SymbolTables
[ ] Review the APIs with globalization experts

These two are not part of our 2.1 release. I will track them separately.


[BUG] - https://www.comrademao.com/ - Doesn't Work

https://www.comrademao.com/ - Doesn't work, due to new website.

Should be fixed now.


docs: update fields as they are optional

Thank you for helping make the Dapr documentation better!
Please follow this checklist before submitting:

[ ] Commits are signed with Developer Certificate of Origin (DCO - learn more)
[ ] Read the contribution guide
[ ] Commands include options for Linux, MacOS, and Windows within codetabs
[ ] New file and folder names are globally unique
[ ] Page references use shortcodes instead of markdown or URL links
[ ] Images use HTML style and have alternative text
[ ] Places where multiple code/command options are given have codetabs

In addition, please fill out the following to help reviewers understand this pull request:
Description
Docs updates given these changes
https://github.com/dapr/components-contrib/pull/3562/files
Issue reference

@sicoyle does this PR need to point to 1.15?

closing as i am fixing in a diff pr


Implement $set stage dsl

https://www.mongodb.com/docs/manual/reference/operator/aggregation/set/

I'd like to work on it :)


Support multiple enclosures

I 've found a podcast which is not working with CPod:
https://24.hu/feed/ziccer_24hu/
The issue is that each item in the rss has two enclosue tags (one image, and one audio). CPod seems to download the first one, so the audio is ignored. It would be cool if the audio enclosue could be downloaded.

Thanks for the issue and specifically pointing out the problematic RSS feed, that really helped. This should be fixed in 10afe8d1bb53d3d185a92c5cce1dee1b7c6c7b1f.


Added more validations for polling source and http source + documentation

Updated documentation:
Added a tutorial on how to setup your environment to develop this provider locally. (Feel free to change or add)
Functions added:
Resource http source:
Added TimeZone validation against Sumologic server
Resource polling source:
All fields in func resourceSumologicPollingSource() *schema.Resource are being validated against Sumologic Server.
File permissions changed
Environment variable changed back to EU
Removed logging
Renamed func to a more consistent one

It seems that I need to set the keys for Sumologic as you can see in the snippet below: (that's your PR when it passed)

In my PR I don't have any of these:

Is that right?

Correct. The problem is that because it's an encrypted value in Travis, it won't inject them when building a 'foreign' PR. If it would, you could submit a malicious PR which would expose it to the world.
If you want to run the tests yourself you should use your own account. I use a free account for that, to isolate it from my company's account.

Yeap, I understand.
I tested on my Travis account with my own Sumologic keys, and everything worked fine as you can see the output below:

However, I don't know how to pass in your tests as your keys are protected, of course. Also, I don't want to change your .travis.yml file with my encrypted keys. So, as my code seems all good, how do I proceed? Thanks!

There's a lot of noise caused by changing the permissions of a lot of files, could you fix that?

I'm taking a look at this tomorrow.

@josacar sorry for that man, I've got some issues with file permissions (have to change in order to test). In my perspective, this doesn't affect the code itself but affects the code reviewing indeed. But it's a lot of work now as I need to check file by file and change the permissions...still want me to change?

the problem is that affects reviewing and PR is not likely to be merged straight forward as this will be merged in master affecting the following changes.
Maybe we can revert back that commit or even rebase without that commit changing the file permissions.

Maybe we can help you with this task, don't worry.

@josacar I understand your point and agree, I will find just the files that I have changed and commit them, bringing back the original file permissions ;)

@shinitiandrei Appreciated, reach out if you need anything!

@shinitiandrei there's a conflict, could you take a look?

Hi guys, sorry I've been quite busy with my recent project at work and haven't got much time to this PR...I have looked how to reverse my commits or even rebase and in my perspective would take a good part of my time...
The easiest and smooth way for me, if you don't mind, I would close this PR and open a new one with the "real" changes. Is that all good? I can make it by today and tomorrow with your conflict change request as well ;)
Thanks guys!

That sounds like a simple solution. I like simple ;-)

Would be approximately about 5 to 7 commits with accurate comments about my changes*

Great. Thanks in advance.


[WIP] UnsafePointer conversion fixes.

Update for SE-0107: UnsafeRawPointer.
Some of this is pretty rough, but it's necessary to
keep the build working and land the raw vs. typed pointer feature.
As expected there are two major pain points:

CString vs. UTF8 types

NSData and company use pointer to UInt8 for untyped memory.

@parkera This is just a stop-gap to allow the build to succeed when we're ready to pull in the stdlib changes sometime today. I plan to go through over all these changes again later and find a cleaner way to handle things.

I'll update this after
https://github.com/apple/swift/pull/3832
Also, I noticed a stdlib dependency which hasn't been checked in yet, so this should not be merged.

Ok.

This passes 'build-script -R --llbuild --foundation --xctest -T' with the latest swift master.
I need this to proceed with changes on master.
Merging and keeping an eye on the bots.


OPM fails to create a pruned index image

Bug Report
What did you do?
Following the below linked documentation I'm attempting to create a custom pruned index image of 3 operators, but unfortunately not having much luck as it errors out mid process.
https://docs.openshift.com/container-platform/4.6/operators/admin/olm-restricted-networks.html
opm index prune \
    -f registry.redhat.io/redhat/redhat-operator-index:v4.6 \
    -p cluster-logging,elasticsearch-operator,metering-ocp \
    -t localhost:5000/olm/redhat-operator-index:v4.6
INFO[0000] pruning the index                             packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0000] Pulling previous image registry.redhat.io/redhat/redhat-operator-index:v4.6 to get metadata  packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0000] running /usr/bin/podman pull registry.redhat.io/redhat/redhat-operator-index:v4.6  packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0003] running /usr/bin/podman pull registry.redhat.io/redhat/redhat-operator-index:v4.6  packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0006] Getting label data from previous image        packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0006] running podman inspect                        packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0006] running podman create                         packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0006] running podman cp                             packages="[cluster-logging elasticsearch-operator metering-ocp]"
INFO[0017] running podman rm                             packages="[cluster-logging elasticsearch-operator metering-ocp]"
Error: open index_tmp_500513138/database/index.db: no such file or directory
Usage:
  opm index prune [flags]

Flags:
  -i, --binary-image opm        container image for on-image opm command
  -c, --container-tool string   tool to interact with container images (save, build, etc.). One of: [docker, podman] (default "podman")
  -f, --from-index string       index to prune
      --generate                if enabled, just creates the dockerfile and saves it to local disk
  -h, --help                    help for prune
  -d, --out-dockerfile string   if generating the dockerfile, this flag is used to (optionally) specify a dockerfile name
  -p, --packages strings        comma separated list of packages to keep
      --permissive              allow registry load errors
  -t, --tag string              custom tag for container image being built

Global Flags:
      --skip-tls   skip TLS certificate verification for container image registries while pulling bundles or index

I do appear to have a 'index_tmp_500513138' directory created but no 'database' sub directory, only 'merged'.
What did you expect to see?
A new local pruned image
What did you see instead? Under which circumstances?
No image, and the above listed error
Environment

opm version
Version: version.Version{OpmVersion:"v1.14.3-5-gf6e5d92", GitCommit:"f6e5d9281f335472dda7110fca2c710794c97fb5", BuildDate:"2020-10-06T13:13:12Z", GoOs:"linux", GoArch:"amd64"}

oc version
Client Version: 4.6.1

podman --version
podman version 1.6.4

Additional context
Let me know if you require any further details and i'm happy to provide them.

Raised Bugzilla for tracking: https://bugzilla.redhat.com/show_bug.cgi?id=1894167
Will close this issue.


[stable/heartbeat] deployment support

What this PR does / why we need it:

add deployment support (like metricbeat)

Which issue this PR fixes
(optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged)

fixes #

Special notes for your reviewer:
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md

I was in the process of doing the same thing.
Thanks !
Heartbeat shouldn't necessarily be a DaemonSet.


Convert 'routine vector' to 'routine seq'

This pull request merges in some changes indicates that functions are sequential versus vector.  This change will decrease execution time by approximately 8%.  This also adds a verification namelist for the ASD03 configuration

@johnmauff I have updated the README-GPU.md and Makefile files to include instructions about how to use the new Makefile. Hope it looks better now and let me know if you think more changes are needed for other files.


heaty v0.12.0 does not find my thermostat by the "new entity id"

Hi again
Just upgraded to Heaty v0.12.0.
Heaty does not find my thermostat if I use the reference to "new entity id", for instance "climate.termostat_guestroom_heating". This worked with Heaty v0.11.0.
If I use the original entity "climate.thermofloor_as_heatit_thermostat_tf_021_heating_2", Heaty works.
It also find my door sensor and responds to door actions. But it do not  set the temp back to the original.
I also get a warning that the thermostat doesn't seem to support the operation mode "Heat". Please check your config!
I know my thermostat supports the mode Heat. It supporta Heat, Energy Heat, and Off. Its a Heatit Z-wave Plus Thermostat.
regards
Heaty thermostat scheduling
heaty_minimal:
module: hass_apps_loader
class: HeatyApp
off_temp: 5
window_sensor_defaults:
delay: 10
open_state: "on"
rooms:
Gjesterom:
thermostats:
climate.thermofloor_as_heatit_thermostat_tf_021_heating_2:
schedule:
# From Monday to Friday, set temperature to 22.0 °C from 05:00 to 09:00 and from 14:30 to 23:00.
- { temp: 19.0, start: "00:00", end: "04:59", weekdays: 1-5, weeks: "1-22, 32-52" }
- { temp: 22.0, start: "05:00", end: "08:59", weekdays: 1-5, weeks: "1-22, 32-52" }
- { temp: 19.0, start: "09:00", end: "14:29", weekdays: 1-5, weeks: "1-22, 32-52" }
- { temp: 22.0, start: "14:30", end: "22:59", weekdays: 1-5, weeks: "1-22, 32-52" }
- { temp: 19.0, start: "23:00", end: "23:59", weekdays: 1-5, weeks: "1-22, 32-52" }
# On weekends, set temperature to 22.0 °C from 05:00 to 23.00
- { temp: 19.0, start: "00:00", end: "04:59", weekdays: "6,7", weeks: "1-22, 32-52" }
- { temp: 22.0, start: "05:00", end: "22:59", weekdays: "6,7", weeks: "1-22, 32-52" }
- { temp: 19.0, start: "23:00", end: "23:59", weekdays: "6,7", weeks: "1-22, 32-52" }
# At all other times, set temperature to 19 °C.
- { temp: 5.0 }
  window_sensors:
    binary_sensor.doorsensor_gjesterom:

Log:
pi@hassbian:~ $ /home/pi/appdaemon/bin/appdaemon -c /home/homeassistant/.homeassistant
2018-03-05 00:17:17.563345 INFO AppDaemon Version 2.1.12 starting
2018-03-05 00:17:17.564007 INFO Configuration read from: /home/homeassistant/.homeassistant/appdaemon.yaml
2018-03-05 00:17:17.702602 INFO Starting Apps
2018-03-05 00:17:17.902356 INFO Got initial state
2018-03-05 00:17:17.903893 INFO Loading Module: /home/homeassistant/.homeassistant/apps/hass_apps_loader.py
2018-03-05 00:17:17.951567 INFO Loading Object heaty_minimal using class HeatyApp from module hass_apps_loader
2018-03-05 00:17:18.453620 INFO heaty_minimal: --- heaty v0.12.0 initialization started
2018-03-05 00:17:18.486885 INFO heaty_minimal: --- Heaty id is: 'default'
2018-03-05 00:17:18.498942 WARNING heaty_minimal: !!! [Gjesterom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Thermostat doesn't seem to support the operation mode Heat, supported modes are: ['Heat (Default)', 'Cool', 'Off', 'Energy Heat']. Please check your config!
2018-03-05 00:17:18.524010 INFO heaty_minimal: --> [Gjesterom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 5.0.
2018-03-05 00:17:18.630169 INFO heaty_minimal: <-- [Gjesterom] Temperature set to 19.0.
2018-03-05 00:17:18.642376 INFO heaty_minimal: --- Initialization done
2018-03-05 00:17:18.642849 INFO App initialization complete
2018-03-05 00:17:18.643605 INFO Dashboards are disabled
2018-03-05 00:17:18.643924 INFO API is disabled
2018-03-05 00:17:18.657290 INFO Connected to Home Assistant 0.64.3
2018-03-05 00:17:19.510951 INFO heaty_minimal: --> [Gjesterom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 19.0.
2018-03-05 00:17:41.024364 INFO heaty_minimal: --> [Gjesterom] Window has been opened.
2018-03-05 00:17:41.031743 INFO heaty_minimal: <-- [Gjesterom] Turning heating off due to an open window.
2018-03-05 00:17:41.049390 INFO heaty_minimal: <-- [Gjesterom] Temperature set to 5.0.
2018-03-05 00:17:42.556920 INFO heaty_minimal: --> [Gjesterom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 5.0.
2018-03-05 00:18:03.024479 INFO heaty_minimal: --> [Gjesterom] Window has been closed.

Hi
I just reverted back to hass-apps v0.20180221.0 and downgraded voluptuous to 0.10.5.
Everthing is working as normal, exept the warnig about not supportinh Heat mode.
pi@hassbian:~ $ /home/pi/appdaemon/bin/appdaemon -c /home/homeassistant/.homeassistant
2018-03-05 00:29:03.739651 INFO AppDaemon Version 2.1.12 starting
2018-03-05 00:29:03.740254 INFO Configuration read from: /home/homeassistant/.homeassistant/appdaemon.yaml
2018-03-05 00:29:03.889075 INFO Starting Apps
2018-03-05 00:29:04.095399 INFO Got initial state
2018-03-05 00:29:04.096971 INFO Loading Module: /home/homeassistant/.homeassistant/apps/hass_apps_loader.py
2018-03-05 00:29:04.147097 INFO Loading Object heaty_minimal using class HeatyApp from module hass_apps_loader
2018-03-05 00:29:04.620170 INFO heaty_minimal: --- heaty v0.11.0 initialization started
2018-03-05 00:29:04.650871 INFO heaty_minimal: --- --- Heaty id is: 'default'
2018-03-05 00:29:04.660348 WARNING heaty_minimal: !!! !!! [Gjesterom] Thermostat climate.thermofloor_as_heatit_thermostat_tf_021_heating_2 doesn't seem to support the operation mode 'Heat', supported modes are ['Heat (Default)', 'Cool', 'Off', 'Energy Heat']. Please check your config!
2018-03-05 00:29:04.668979 INFO heaty_minimal: --- --- Getting current temperatures from thermostats.
2018-03-05 00:29:04.683466 INFO heaty_minimal: --- --> [Gjesterom] Received target temperature 19.0 from thermostat.
2018-03-05 00:29:04.770848 INFO heaty_minimal: --- <-- [Gjesterom] Temperature set to 19.0.
2018-03-05 00:29:04.788347 INFO heaty_minimal: --- Initialization done
2018-03-05 00:29:04.788881 INFO App initialization complete
2018-03-05 00:29:04.789868 INFO Dashboards are disabled
2018-03-05 00:29:04.790300 INFO API is disabled
2018-03-05 00:29:04.802816 INFO Connected to Home Assistant 0.64.3
2018-03-05 00:29:34.024843 INFO heaty_minimal: --- --> [Gjesterom] Window opened.
2018-03-05 00:29:34.032291 INFO heaty_minimal: --- <-- [Gjesterom] Turning heating off due to an open window.
2018-03-05 00:29:34.043687 INFO heaty_minimal: --- <-- [Gjesterom] Temperature set to 5.0.
2018-03-05 00:29:35.501338 INFO heaty_minimal: --- --> [Gjesterom] Received target temperature 5.0 from thermostat.
2018-03-05 00:29:57.021928 INFO heaty_minimal: --- --> [Gjesterom] Window closed.
2018-03-05 00:29:57.029850 INFO heaty_minimal: --- <-- [Gjesterom] Temperature set to 19.0.
2018-03-05 00:29:59.584045 INFO heaty_minimal: --- --> [Gjesterom] Received target temperature 19.0 from thermostat.

Hi,
Can you please put your configs and shell sessions inside code blocks? It's difficult to read them this way. Thanks.
Regarding the operation mode. Heaty actually tells you what modes are supported by your specific thermostat. The mode should be Heat (Default). Apart from that. your current setup doesn't work reliably, because Heaty won't be able to turn a thermostat on after it was off when it doesn't know the correct operation modes. It also re-sends temperature changes redundantly in this case. So please fix the operation mode and you should be good to go.
Regarding your second question. The way entities are fetched from Home Assistant hasn't been changed between 0.11 and 0.12. AppDaemon is responsible for this job. Since you didn't show me what Heaty tells you when running with v0.12.0 I can't tell you more. Sorry. But I'm pretty sure that it'll work when you fix the wrong operation mode name.
Please tell me how it went.
Best regards
Robert

Hi
Added to the app.yaml solved the Warning message about operation mode.
thermostat_defaults:
opmode_heat: Heat (Default)
This is with Hass_Apps v0.20180221.0 and voluptuous 0.10.5

Can you please upgrade and tell me whether it's working with the latest version as well?

Status before upgrading.  All functions are working:
Temperature is set back to normal if a door is closed.
pi@hassbian:~ $ /home/pi/appdaemon/bin/appdaemon -c /home/homeassistant/.homeassistant
2018-03-07 11:59:55.252395 INFO AppDaemon Version 2.1.12 starting
2018-03-07 11:59:55.253003 INFO Configuration read from: /home/homeassistant/.homeassistant/appdaemon.yaml
2018-03-07 11:59:55.392613 INFO Starting Apps
2018-03-07 11:59:55.952029 INFO Got initial state
2018-03-07 11:59:55.953449 INFO Loading Module: /home/homeassistant/.homeassistant/apps/hass_apps_loader.py
2018-03-07 11:59:56.090223 INFO Loading Object heaty_minimal using class HeatyApp from module hass_apps_loader
2018-03-07 11:59:56.500838 INFO heaty_minimal: --- heaty v0.11.0 initialization started
2018-03-07 11:59:56.576309 INFO heaty_minimal: --- --- Heaty id is: 'default'
2018-03-07 11:59:56.589251 INFO heaty_minimal: --- --- Getting current temperatures from thermostats.
2018-03-07 11:59:56.602625 INFO heaty_minimal: --- --> [Guestrom] Received target temperature 16.0 from thermostat.
2018-03-07 11:59:56.620854 INFO heaty_minimal: --- --> [Main_bathroom] Received target temperature 24.0 from thermostat.
2018-03-07 11:59:56.639253 INFO heaty_minimal: --- --> [Childrens_bathroom] Received target temperature 24.0 from thermostat.
2018-03-07 11:59:56.657552 INFO heaty_minimal: --- --> [Malin_bedroom] Received target temperature 18.0 from thermostat.
2018-03-07 11:59:56.675523 INFO heaty_minimal: --- --> [1st_floor] Received target temperature 24.0 from thermostat.
2018-03-07 11:59:56.680388 INFO heaty_minimal: --- <-- [1st_floor] Propagating the change to all thermostats in the room.
2018-03-07 11:59:56.687047 INFO heaty_minimal: --- <-- [1st_floor] Temperature set to 24.0.
2018-03-07 11:59:56.715195 INFO heaty_minimal: --- --> [Kaysa_bedroom] Received target temperature 17.0 from thermostat.
2018-03-07 11:59:56.733180 INFO heaty_minimal: --- --> [Laundry] Received target temperature 20.0 from thermostat.
2018-03-07 11:59:57.071023 INFO heaty_minimal: --- <-- [Guestrom] Temperature set to 16.0.
2018-03-07 11:59:57.091399 INFO heaty_minimal: --- <-- [Main_bathroom] Temperature set to 24.0.
2018-03-07 11:59:57.111080 INFO heaty_minimal: --- <-- [Childrens_bathroom] Temperature set to 24.0.
2018-03-07 11:59:57.130218 INFO heaty_minimal: --- <-- [Malin_bedroom] Temperature set to 18.0.
2018-03-07 11:59:57.149336 INFO heaty_minimal: --- <-- [1st_floor] Temperature set to 24.0.
2018-03-07 11:59:57.183729 INFO heaty_minimal: --- <-- [Kaysa_bedroom] Temperature set to 17.0.
2018-03-07 11:59:57.203772 INFO heaty_minimal: --- <-- [Laundry] Temperature set to 20.0.
2018-03-07 11:59:57.219972 INFO heaty_minimal: --- Initialization done
2018-03-07 11:59:57.220410 INFO App initialization complete
2018-03-07 11:59:57.221174 INFO Dashboards are disabled
2018-03-07 11:59:57.221502 INFO API is disabled
2018-03-07 11:59:57.233727 INFO Connected to Home Assistant 0.64.3
2018-03-07 12:00:18.033067 INFO heaty_minimal: --- --> [Guestrom] Window opened.
2018-03-07 12:00:18.042025 INFO heaty_minimal: --- <-- [Guestrom] Turning heating off due to an open window.
2018-03-07 12:00:18.051018 INFO heaty_minimal: --- <-- [Guestrom] Temperature set to 5.0.
2018-03-07 12:00:19.310932 INFO heaty_minimal: --- --> [Guestrom] Received target temperature 5.0 from thermostat.
2018-03-07 12:00:41.024346 INFO heaty_minimal: --- --> [Guestrom] Window closed.
2018-03-07 12:00:41.031961 INFO heaty_minimal: --- <-- [Guestrom] Temperature set to 16.0.

Status after upgrading. Most functions seems to work, but temperature is NOT set back to normal if a door is closed.
apps.yaml.txt

pi@hassbian:~ $ /home/pi/appdaemon/bin/appdaemon -c /home/homeassistant/.homeassistant
2018-03-07 12:09:41.372159 INFO AppDaemon Version 2.1.12 starting
2018-03-07 12:09:41.372824 INFO Configuration read from: /home/homeassistant/.homeassistant/appdaemon.yaml
2018-03-07 12:09:41.524305 INFO Starting Apps
2018-03-07 12:09:42.091125 INFO Got initial state
2018-03-07 12:09:42.092585 INFO Loading Module: /home/homeassistant/.homeassistant/apps/hass_apps_loader.py
2018-03-07 12:09:42.237416 INFO Loading Object heaty_minimal using class HeatyApp from module hass_apps_loader
2018-03-07 12:09:42.654602 INFO heaty_minimal: --- heaty v0.12.1 initialization started
2018-03-07 12:09:42.735920 INFO heaty_minimal: --- Heaty id is: 'default'
2018-03-07 12:09:42.762974 INFO heaty_minimal: --> [Childrens_bathroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_8] Received target temperature 24.0.
2018-03-07 12:09:42.872392 INFO heaty_minimal: --> [Kaysa_bedroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_6] Received target temperature 17.0.
2018-03-07 12:09:42.954975 INFO heaty_minimal: --> [1st_floor] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_4] Received target temperature 24.0.
2018-03-07 12:09:42.961044 INFO heaty_minimal: <-- [1st_floor] Propagating the change to all thermostats in the room.
2018-03-07 12:09:43.002420 INFO heaty_minimal: <-- [1st_floor] Temperature set to 24.0.
2018-03-07 12:09:43.097077 INFO heaty_minimal: --> [Main_bathroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_9] Received target temperature 24.0.
2018-03-07 12:09:43.189853 INFO heaty_minimal: --> [Malin_bedroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_7] Received target temperature 18.0.
2018-03-07 12:09:43.271934 INFO heaty_minimal: --> [Guestrom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 16.0.
2018-03-07 12:09:43.336689 INFO heaty_minimal: --> [Laundry] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_10] Received target temperature 20.0.
2018-03-07 12:09:43.479384 INFO heaty_minimal: <-- [1st_floor] Temperature set to 24.0.
2018-03-07 12:09:43.576139 INFO heaty_minimal: --- Initialization done
2018-03-07 12:09:43.576579 INFO App initialization complete
2018-03-07 12:09:43.577399 INFO Dashboards are disabled
2018-03-07 12:09:43.577747 INFO API is disabled
2018-03-07 12:09:43.591746 INFO Connected to Home Assistant 0.64.3
2018-03-07 12:10:14.093127 INFO heaty_minimal: --> [Guestrom] Window has been opened.
2018-03-07 12:10:14.119079 INFO heaty_minimal: <-- [Guestrom] Turning heating off due to an open window.
2018-03-07 12:10:14.216776 INFO heaty_minimal: <-- [Guestrom] Temperature set to 5.0.
2018-03-07 12:10:15.300331 INFO heaty_minimal: --> [Guestrom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 5.0.
2018-03-07 12:10:42.025220 INFO heaty_minimal: --> [Guestrom] Window has been closed.

Ok, I'll investigate this further and get back to this issue.

Bugfix release is out. Please upgrade and confirm that it's working. Thanks.

Seems to work now :-)
pi@hassbian:~ $ /home/pi/appdaemon/bin/appdaemon -c /home/homeassistant/.homeassistant
2018-03-07 15:01:40.545039 INFO AppDaemon Version 2.1.12 starting
2018-03-07 15:01:40.545661 INFO Configuration read from: /home/homeassistant/.homeassistant/appdaemon.yaml
2018-03-07 15:01:40.696763 INFO Starting Apps
2018-03-07 15:01:41.256643 INFO Got initial state
2018-03-07 15:01:41.258173 INFO Loading Module: /home/homeassistant/.homeassistant/apps/hass_apps_loader.py
2018-03-07 15:01:41.373665 INFO Loading Object heaty_minimal using class HeatyApp from module hass_apps_loader
2018-03-07 15:01:41.760052 INFO heaty_minimal: --- heaty v0.12.2 initialization started
2018-03-07 15:01:41.840272 INFO heaty_minimal: --- Heaty id is: 'default'
2018-03-07 15:01:41.867150 INFO heaty_minimal: --> [Malin_bedroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_7] Received target temperature                    18.0.
2018-03-07 15:01:41.949965 INFO heaty_minimal: --> [Main_bathroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_9] Received target temperature                    24.0.
2018-03-07 15:01:42.045777 INFO heaty_minimal: --> [Childrens_bathroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_8] Received target tempera                   ture 24.0.
2018-03-07 15:01:42.151909 INFO heaty_minimal: --> [Guestrom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 5.0.
2018-03-07 15:01:42.215698 INFO heaty_minimal: --> [Kaysa_bedroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_6] Received target temperature                    17.0.
2018-03-07 15:01:42.298601 INFO heaty_minimal: --> [1st_floor] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_4] Received target temperature 24.0                   .
2018-03-07 15:01:42.304673 INFO heaty_minimal: <-- [1st_floor] Propagating the change to all thermostats in the room.
2018-03-07 15:01:42.345682 INFO heaty_minimal: <-- [1st_floor] Temperature set to 24.0.
2018-03-07 15:01:42.439556 INFO heaty_minimal: --> [Laundry] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_10] Received target temperature 20.0.
2018-03-07 15:01:42.504312 INFO heaty_minimal: <-- [Malin_bedroom] Temperature set to 21.0.
2018-03-07 15:01:42.531334 INFO heaty_minimal: <-- [Main_bathroom] Temperature set to 26.0.
2018-03-07 15:01:42.554073 INFO heaty_minimal: <-- [Childrens_bathroom] Temperature set to 26.0.
2018-03-07 15:01:42.575548 INFO heaty_minimal: <-- [Guestrom] Temperature set to 17.0.
2018-03-07 15:01:42.596994 INFO heaty_minimal: <-- [Kaysa_bedroom] Temperature set to 21.0.
2018-03-07 15:01:42.657757 INFO heaty_minimal: <-- [1st_floor] Temperature set to 24.0.
2018-03-07 15:01:42.691670 INFO heaty_minimal: --- Initialization done
2018-03-07 15:01:42.692168 INFO App initialization complete
2018-03-07 15:01:42.693128 INFO Dashboards are disabled
2018-03-07 15:01:42.693720 INFO API is disabled
2018-03-07 15:01:42.705817 INFO Connected to Home Assistant 0.64.3
2018-03-07 15:01:44.962455 INFO heaty_minimal: --> [Guestrom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 17.0.
2018-03-07 15:01:45.416570 INFO heaty_minimal: --> [Kaysa_bedroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_6] Received target temperature                    21.0.
2018-03-07 15:01:45.544513 INFO heaty_minimal: --> [Malin_bedroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_7] Received target temperature                    21.0.
2018-03-07 15:01:45.624974 INFO heaty_minimal: --> [Childrens_bathroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_8] Received target tempera                   ture 26.0.
2018-03-07 15:01:45.778740 INFO heaty_minimal: --> [Main_bathroom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_9] Received target temperature                    26.0.
2018-03-07 15:02:35.029209 INFO heaty_minimal: --> [Guestrom] Window has been opened.
2018-03-07 15:02:35.037636 INFO heaty_minimal: <-- [Guestrom] Turning heating off due to an open window.
2018-03-07 15:02:35.056197 INFO heaty_minimal: <-- [Guestrom] Temperature set to 5.0.
2018-03-07 15:02:36.315997 INFO heaty_minimal: --> [Guestrom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 5.0.
2018-03-07 15:03:06.025635 INFO heaty_minimal: --> [Guestrom] Window has been closed.
2018-03-07 15:03:06.047997 INFO heaty_minimal: <-- [Guestrom] Temperature set to 17.0.
2018-03-07 15:03:07.338539 INFO heaty_minimal: --> [Guestrom] [climate.thermofloor_as_heatit_thermostat_tf_021_heating_2] Received target temperature 17.0.

Great. Have a nice day!


run this pattern locally,but it cannot reproduce

hello
Can you tell which version the vscode_IBM_Blockchain uses?

Always using the latest version of vscode_IBM_Blockchain
@C-PIG

but vscdoe_ibm_blockchain1.0.16--1.0.20 don't work in vscode1.40.x

Using VSCode 1.42.1
IBM Blockchain Platform 1.0.20
aot-bc-space-cargo-api$ node -v
v8.9.0
aot-bc-space-cargo-api$ npm -v
6.11.3
aot-bc-space-cargo-api$ docker -v
Docker version 19.03.5, build 633a0ea
aot-bc-space-cargo-api$ docker-compose --version
docker-compose version 1.25.2, build 698e2846
yes I have seen that issue before - but it is all working fine on my system.

@horeaporutiu
Are you using a Mac system? Or Linux system?

Why can't the docker-compose.yml configuration file be produced correctly? Is this a problem with the  Blockchain Platform plugin?
`
command: orderer
ports:
- :
`
Port specified as empty

if you do docker ps do you see a container for the orderer node? something that looks like this?

@C-PIG

when I instantiate a smart contract(voterContract@7.0.0)，it is wrong。
How can I solve this problem, thank you

did you follow these steps  ? https://github.com/IBM/evote/blob/master/docs/run-local.md#step-3-import-install-and-instantiate-contract
i.e. import, install, and then instantiate?
if this doesn't work properly, teardown your fabric network, and then bring it up again. It should work if you start the process over. I've tested this part a couple of days ago using VSCode version 1.39.

closing due to inactivity


Fix: Removed commented code in create_test.go

Issue #106

Make the changes in the dev branch and raise PR - https://github.com/paypal/junodb/blob/dev/docs/contributing.md#contributing-to-junodb

Make the changes in the dev branch and raise PR - https://github.com/paypal/junodb/blob/dev/docs/contributing.md#contributing-to-junodb

Okay

sent a new PR, that's why closing this one.
New PR:  #139


More portable gmp detection

I'm a git newb (long time hg user), so maybe I didn't do this correctly?
python2 setup.py build
/usr/lib/python2.7/site-packages/setuptools/dist.py:285: UserWarning: Normalizing '0.7.5post2' to '0.7.5.post2'
normalized_version,
running build
running build_py
package init file 'pythran/pythonic/init.py' not found (or not a regular file)
Copying nt2 and its dependencies
Trying to compile GMP dependencies.
cc -c /tmp/tmpRDi32_.c -o tmp/tmpRDi32_.o
cc tmp/tmpRDi32_.o -lgmp -o a.out
[nbecker@nbecker7 pythran]$ git branch

(HEAD detached at origin/fix/gmp-detection)
master

On Thu, Jun 23, 2016 at 06:19:03AM -0700, ndbecker wrote:

I'm a git newb (long time hg user), so maybe I didn't do this correctly?
python2 setup.py build
/usr/lib/python2.7/site-packages/setuptools/dist.py:285: UserWarning: Normalizing '0.7.5post2' to '0.7.5.post2'
normalized_version,
running build
running build_py
package init file 'pythran/pythonic/init.py' not found (or not a regular file)
Copying nt2 and its dependencies
Trying to compile GMP dependencies.
cc -c /tmp/tmpRDi32_.c -o tmp/tmpRDi32_.o
cc tmp/tmpRDi32_.o -lgmp -o a.out
[nbecker@nbecker7 pythran]$ git branch

(HEAD detached at origin/fix/gmp-detection)
master

looks good to me :-) thanks!

problem is it needs to either build with g++ or add -lstdc++, it's trying to build with cc, which won't work for c++

yes, that's why I chaned the test case to be a plain C test case so that we don'"t run into your issue


XML output is truncated

Fixes #6299

Maps do not support adding KVs to it with the square bracket. We've been doing it wrong and this type signature is confusing to get this working.
This change don't break anything we do internally and just solidifies the way we use this API in the actual typing.

Synced offline with @kburtram - we send these settings automatically anyway - there's no reason for me to write my own code to handle it.
The code that already handles the configuration changes is located here:
https://github.com/microsoft/vscode-languageserver-node/blob/master/client/src/client.ts#L2228-L2252


Fix updating cgiSetVariable variables (issue #998)

Fix #998

I saw this one as well - as @Gerben100 already found, it happens because we send a pointer into cgiSetVariable() which is already in form variables, freeing it first, then using the freed pointer for strdup().
We can dupe the string before sending it into cgiSetVariable(), since admin.cgi is one-shot binary and memory will be clean up after exit, but @Gerben100 looks more operation efficient. I'm not sure what are implications from not-generating a new memory if the pointer is already under value of variable available in form_vars - looks ok to me...

OK, the issue is being caused by cgiGetTextField to not duplicate the returned string like cgiGetVariable does.
[master 34819b710] Make sure we duplicate strings returned by cgiGetTextField, just as we do for cgiGetVariable (Issue #999)
[2.4.x eb34f2698] Make sure we duplicate strings returned by cgiGetTextField, just as we do for cgiGetVariable (Issue #999)


Add the libtock_unittest::fake::Driver trait.

I will add individual interfaces (Allow, Command, and Subscribe) in the future, as they all have their own design work to do.
I also added a document explaining why Rc is used so extensively, and how we avoid unclear ownership and cyclic references. I'm a bit concerned I'm overusing Rc here, but I'm having trouble finding a better design.

bors r+


Thresholds:  enable users to choose reference thresholds but auto-detect 208 vs 218ppm

Currently functionality is to just apply the 218 ppm thresholds to everything. Desired functionality:
(1) GX pipeline reads in RF excitation frequency (it already is doing this in some way, since it appears in the report)
(2) Based on frequency, either (a) use existing 218ppm values or (b) use @sl609 's new thresholds for 208ppm.
NOTE: The frequency may not always be exactly 218ppm, so will have an allowable range of ±2ppm: either 216-220ppm or 206-210ppm.
When there is no frequency specified, we can just default to 218ppm, but the system should throw a warning in the report that says "Warning: Unrecognized Excitation Frequency."

Update to my original description:
@sl609 to provide Andrew with 208ppm numbers
AND 218ppm (which happen to be derived from 208ppm)
Please see Sup's ATS abstract and MRM paper in work

Agreed at IAT meeting to implement ability for users to provide their own reference distributions if desired, but maintain functionality to auto-select 218 vs 208 ppm  based on RF excitation frequency.


Implement new custom metadata feature at PHP SDK

We've added this, as well as some other minor enhancements in v2.6.0, please let me know if you have any questions.


Editor theme flashing of light mode on change

Whenever you navigate to a specific problem on the platform and change the editor theme, there's a quick "flash" of white when changing the themes.
I theorize it might have something to do with the way we're currently handling defaults, but I'll have to investigate. It also could be a classic issue of the editor theme state not being set until the page hydrates. This thought is because after you change the theme for the first time, it begins switching like normal.
Steps to reproduce:

Go to a problem
Select the theme

(must be a light theme to a dark theme and vice versa)

Flash happens

Added a commit in the revamp which addresses this issue, it's all fixed now once this merges.


chore(deps): update dependencies

Types of changes

[x] Chore (a non-breaking change which is related to package maintenance)
[ ] Bug fix (a non-breaking change which fixes an issue)
[ ] New feature (a non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Description
This PR updates all dependencies.
Checklist:

[ ] My change requires an update to the official documentation.
[x] All TSDoc comments are up-to-date and new ones have been added where necessary.
[x] All new and existing tests are passing.

Codecov Report

Merging #81 (5a1c878) into main (414434b) will decrease coverage by 17.54%.
The diff coverage is 100.00%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@             Coverage Diff             @@
##             main      #81       +/-   ##
===========================================
- Coverage   98.39%   80.85%   -17.54%
===========================================
  Files          13       13
  Lines         934      935        +1
  Branches       61       61
===========================================
- Hits          919      756      -163
- Misses         15      179      +164

Files Changed
Coverage Δ

src/PrismicNextImage.tsx
54.76% <100.00%> (-45.24%)
:arrow_down:

... and 6 files with indirect coverage changes

Closing in favor of an updated PR.


ExtModel reads some forcings multiple times

Describe the bug
When reading in an ExtModel, I see some duplicate forcings.
The ext file contains:
[boundary]
quantity=dischargebnd
locationfile=../../../boundary_conditions/Lek.pli
forcingfile=../../../boundary_conditions/flow/rmm_rivdis_meas_20070101_20140101_MET.bc

[boundary]
quantity=dischargebnd
locationfile=../../../boundary_conditions/Waal.pli
forcingfile=../../../boundary_conditions/flow/rmm_rivdis_meas_20070101_20140101_MET.bc

[boundary]
quantity=dischargebnd
locationfile=../../../boundary_conditions/Maas.pli
forcingfile=../../../boundary_conditions/flow/rmm_rivdis_meas_20070101_20140101_MET.bc

[boundary]
quantity=salinitybnd
locationfile=../../../boundary_conditions/rmm_zeerand_v3.pli
forcingfile=../../../boundary_conditions/transport/rmm_zeesal_30years_v3.bc

[boundary]
quantity=temperaturebnd
locationfile=../../../boundary_conditions/rmm_zeerand_v3.pli
forcingfile=../../../boundary_conditions/transport/rmm_zeetemp_astronomic_v2.bc

ExtModel has five 'forcings' but the first three bc models all have three forcingobjects, which are the same for all three bc models:
boundary 1 of 5: ..\..\..\boundary_conditions\flow\rmm_rivdis_meas_20070101_20140101_MET.bc
forcing 1 of 3: Lek_0001 (timeseries) (dischargebnd)
forcing 2 of 3: Waal_0001 (timeseries) (dischargebnd)
forcing 3 of 3: Maas_0001 (timeseries) (dischargebnd)
boundary 2 of 5: ..\..\..\boundary_conditions\flow\rmm_rivdis_meas_20070101_20140101_MET.bc
forcing 1 of 3: Lek_0001 (timeseries) (dischargebnd)
forcing 2 of 3: Waal_0001 (timeseries) (dischargebnd)
forcing 3 of 3: Maas_0001 (timeseries) (dischargebnd)
boundary 3 of 5: ..\..\..\boundary_conditions\flow\rmm_rivdis_meas_20070101_20140101_MET.bc
forcing 1 of 3: Lek_0001 (timeseries) (dischargebnd)
forcing 2 of 3: Waal_0001 (timeseries) (dischargebnd)
forcing 3 of 3: Maas_0001 (timeseries) (dischargebnd)
boundary 4 of 5: ..\..\..\boundary_conditions\transport\rmm_zeesal_30years_v3.bc
forcing 1 of 6: rmm_zeerand_0001 (timeseries) (salinitybnd)
forcing 2 of 6: rmm_zeerand_0032 (timeseries) (salinitybnd)
forcing 3 of 6: rmm_zeerand_0033 (timeseries) (salinitybnd)
forcing 4 of 6: rmm_zeerand_0110 (timeseries) (salinitybnd)
forcing 5 of 6: rmm_zeerand_0111 (timeseries) (salinitybnd)
forcing 6 of 6: rmm_zeerand_0147 (timeseries) (salinitybnd)
boundary 5 of 5: ..\..\..\boundary_conditions\transport\rmm_zeetemp_astronomic_v2.bc
forcing 1 of 1: rmm_zeerand_0001 (astronomic) (temperaturebnd amplitude)

I guess this happens because the bc file contains data for three rivers, which are coupled to one pli in three blocks. However, I would say this is not expected behaviour.
To Reproduce
The dependency dfm_tools is optional but it helps with plotting.
from pathlib import Path
from hydrolib.core.io.mdu.models import ExtModel
import matplotlib.pyplot as plt
plt.close('all')

use_dfm_tools = False
if use_dfm_tools:
    from dfm_tools.hydrolib_helpers import forcingobject_to_dataframe

file_extnew = Path(r'p:\11206813-006-kpp2021_rmm-2d\C_Work\31_RMM_FMmodel\computations\model_setup\run_206_HYDROLIB\RMM_bnd_5bnds.ext')
ext = ExtModel(file_extnew)

ext_boundaries = ext.boundary
for iEB, extbnd in enumerate(ext_boundaries):
    extbnd_filepath = extbnd.forcingfile.filepath
    print(f'boundary {iEB+1} of {len(ext_boundaries)}: {extbnd_filepath}')
    extbnd_forcings = extbnd.forcingfile.forcing
    fig,ax = plt.subplots(figsize=(12,6))
    leglabels_new = []
    for iEBF, forcing in enumerate(extbnd_forcings):
        print(f'forcing {iEBF+1} of {len(extbnd_forcings)}: {forcing.name} ({forcing.function}) ({forcing.quantityunitpair[1].quantity})')
        if use_dfm_tools:
            forcing_pd = forcingobject_to_dataframe(forcing)
            ax.set_title(f'{extbnd_filepath}')
            pc = forcing_pd.plot(ax=ax) #TODO: see CMEMS_interpolate_example.py for pcolormesh in case of verticalpositions
            leglabels = pc.get_legend_handles_labels()[1]
            leglabels_new.append(f'{forcing.name} ({forcing.function}) {leglabels[-1]}')
    ax.legend(leglabels_new)
    fig.tight_layout()

Expected behavior
I would expect the forcingdata to be present once instead of in this case three times. In the kernel the pli name decides which forcingblock is read from the ext file I think.
Version info (please complete the following information):

OS: Windows 10 and Spyder
Version: hydrolib-core main branch

I verified that the file is indeed loaded 3 seperate times.
We could introduce caching or lazyloading for these specific files or for all files in general.
We do need to look into edge cases for this, e.g. how would caching affect the user if they try to load a file they adjusted in the same script.
Will discuss with @rhutten

Edge cases for caching --> problem with bigger files:

What to do when a file is bigger than x mb or gb (t.b.d.) (memory issues --> segmentation fault)

To do:

Research how big files are handled with caching -> e.g. can be tested.

prototype
I made a simple prototype which caches the data from the file into a dictionary based on the filepath.
It checks if the file has changed based on a checksum and rereads it based on that, else it will return the cached data.
class CachedPathData():

    _file_data : Dict
    _checksum : str

    @property
    def file_data(self) -> Dict:
        return self._file_data

    @property
    def checksum(self) -> str:
        return self._checksum

    def __init__(self, filepath : Path, file_data : Dict) -> None:
        self._file_data = file_data
        self._checksum = FileChecksumCalculator.calculate_checksum(filepath)

    def checksum_changed(self, filepath : Path) -> bool:
        return self.checksum != FileChecksumCalculator.calculate_checksum(filepath)

class Singleton:
    _instance = None

    def __new__(cls, *args, **kwargs):
        if not cls._instance:
            cls._instance = super().__new__(cls, *args, **kwargs)
        return cls._instance

class FileDataCacheLoader(Singleton):
    _loaded_files: Dict[Path, Any] = {}

    def load(self, filepath: Path, parse: Callable[[], Dict]) -> Dict:
        cached_data : CachedPathData= self._loaded_files.get(filepath, None)

        if cached_data is None or cached_data.checksum_changed(filepath):
            file_data = parse(filepath)
            cached_data = CachedPathData(filepath, file_data)
            self._loaded_files[filepath] = cached_data

        return cached_data.file_data

    def clear(self):
        self._loaded_files.clear()
        self._instance = None

class FileChecksumCalculator:
    @staticmethod
    def calculate_checksum(filepath: Path):
        sha256_hash = sha256()
        with open(filepath, "rb") as file:
            for chunk in iter(lambda: file.read(4096), b""):
                sha256_hash.update(chunk)
        return sha256_hash.hexdigest()

The ParsableFileModel has its load updated like this.
    _file_data_cache_loader = FileDataCacheLoader()

    def _load(self, filepath: Path) -> Dict:
        # TODO Make this lazy in some cases so it doesn't become slow
        if filepath.is_file():
            return self._file_data_cache_loader.load(filepath, self._parse)
        else:
            raise ValueError(f"File: `{filepath}` not found, skipped parsing.")

External packages which can be used


Can I reduce the scope of a SAS token to only device streams?

I'm generating SAS tokens using a service key that are scoped to a single device using this URI:
{iot-hub-name}.azure-devices.net/devices/{deviceId}
This seems to work, but is there something I can add to that URI to limit access to only device streams, similar the example on the security page that scopes the token to only cloud-to-device messages:
.../devices/{deviceId}/messages/events
I'm giving these tokens to end users and I want to only allow device streams access.
see this about SAS tokens https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-security#scope-iot-hub-level-credentials

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 31cd2f69-1c17-95fe-49b7-f1ad2705e8ba
Version Independent ID: 3fa1a754-75a7-5dcd-1892-b76fea68cd19
Content: Azure IoT Hub device streams (preview)
Content Source: articles/iot-hub/iot-hub-device-streams-overview.md
Service: iot-hub
GitHub Login: @robinsh
Microsoft Alias: robinsh

@larsonmpdx Thanks for the feedback! We are currently investigating and will update you shortly.

@larsonmpdx I'm afraid that fine grained access control is currently not supported. I passed your feedback to the engineering team.
You could also create an entry in the Azure IoT User Voice so other customers can up-vote your feature request and help the team prioritize it.

thanks. I made this user voice entry:
https://feedback.azure.com/forums/321918-azure-iot/suggestions/39020902-fine-grained-access-control-for-iot-device-streams

@larsonmpdx Thanks for your providing your valuable feedback!


ci(bueno,headless,atomic): add caching

https://coveord.atlassian.net/browse/KIT-2282
In this PR, I added Nx caching to bueno, headless, and atomic by defining their tasks in their respective project.json files.
Here are the outputs of npm run build at the root of a clean repo.

First run (6 mins)
	Second run (4 mins)
	Third run (1 min)

As you can see in the above table, some tasks are failing to cache properly on the first run, and only use the cache on the third run. Specifically:

headless:cached:build:doc
atomic:cached:build:stencil
atomic:cached:build:storybook

I've been investigating these for hours and wasn't able to make their cache work. Using more specific executors may fix this, so I'll try it out locally. If you see anything that you suspect could cause this, please do comment about it, even if it's a far stretch.
Even with the above errors, a significant amount of time is saved.
How targets work
In order to understand this PR, you need to understand how Nx's targets work. I will write it here since Nx's documentation is a bit complicated.
Targets are like package.json scripts, except they are defined in project.json and are more powerful. Here's what a target may look like:
"cached:build:doc:extract": {
  "dependsOn": ["cached:build:definitions"],
  "inputs": [
    "{projectRoot}/scripts/extract-documentation.mjs",
    "{projectRoot}/config/api-extractor/**",
    "{projectRoot}/dist/definitions/**"
  ],
  "outputs": ["{projectRoot}/temp"],
  "executor": "nx:run-commands",
  "options": {
    "command": "node ./scripts/extract-documentation.mjs",
    "cwd": "packages/headless"
  }
}

Targets can depend on other targets using the dependsOn property. Targets can be cached by using the inputs and outputs property. Targets will run an executor with the options we give it (e.g., nx:runs-commands simply runs command(s)).
My understanding is that Nx runs targets like so:
Non-cached targets:

If the target has dependencies (dependsOn), always run them first.
Run the target's executor.

Cached targets:

If the target has dependencies (dependsOn), always run them first, regardless of whether inputs changed or not.
Calculate a single hash for all the files matched by the inputs globs.

If there's no inputs glob, inherit the inputs defines in {workspaceRoot}/nx.json, or inherit the default named input (which defaults to {projectRoot}/**/*).

If there's an existing cache matching the calculated hash, apply it.

Warning: applying the cache will not only add new directories or files, it may delete some.

If there's no existing cache matching the calculated hash, run the target then add all files or directories from outputs to the cache.

Approaches
In this PR, I made various small choices, which I will explain here.
Small targets
I decided to make every target as small as possible. Instead of having one big build target, I created several smaller targets.
To make refactoring easier, I also tried to make every target as self-contained as possible, strictly defining their own dependencies, inputs and outputs. Consequently, some target may redundantly have the same dependency as one of their deeper dependencies, but I think it's easier to read this way, and Nx is smart enough not to run the dependency multiple times.
However, I don't see examples of this in Nx's documentation; they seem to generally make a single big build and test target.
Here are the pros of having smaller tasks:

Easier cache debugging

Instead of the cache failing for the entire build target, it fails for a specific sub-target, which narrows down where the issue can be.

Clear ownership of files

We can easily identify what command is responsible for generating a file, and what command requires what file.

More parallelism

For instance, when running npm run build at the root of the repo, atomic:cached:build:locales is run in parallel with bueno:cached:build:esbuild, which is a more efficient use of computing resources.

Easily convertible from/to executors

What Nx's executors do is generally equivalent to a single of our sub-targets. With this approach, we can easily convert from/to executors if we need/want to.

Independent dev targets
For now, I made dev targets (and :watch targets) not have any dependencies.
If dev targets depend on parent dev targets, then only their parent will be run because the parent dev target technically never "finishes". I want to fix this in a separate PR by using executors.
If dev targets depend on parent build targets, then we can't run multiple of them in parallel, which is the workflow defined in the root package.json's dev:atomic script.
Tests caching
I chose to cache unit tests since their results should always be the same for a given input. This makes it easy to, for instance, lazily run nx run-many --target=test and have it test only affected projects. This will be mostly useful if/when we make the CI share its cache.
I chose not to cache e2e and integration tests, since both can be flaky and give different outcomes when re-run.
Targets-only
I decided to extract all scripts out of package.json into targets (most often using the nx:run-commands executor) so that:

only scripts which are relevant for us to run during development are available in package.json files.
all of a project's tasks logic resides in one place (the project.json file).

If we really need to run sub-tasks, we can still do that by using nx run (e.g., nx run atomic:\"some:task\").
Executor choices
There are several executors available we can use. For instance:

@nrwl/jest:jest

Runs a project's tests using Jest.

@nrwl/esbuild:esbuild

Builds a project using ESBuild.

@nrwl/js:tsc

Builds a project using Typescript's TSC.

@nrwl/linter:eslint

Lints a project (optionally fixing).

@nrwl/storybook:build

Builds storybook.

@nrwl/storybook:storybook

Serves storybook in dev mode.

@nrwl/web:dev-server

Builds then serves a generic web project.

@nxext/stencil:* (unofficial)

Builds, serves, tests Stencil

For this PR, I chose to stick to run-commands because:

It's easier to review.

Less changes in the PR, and the commands are pretty much the same as they were in package.json.

It's easier to revert out of Nx if we need to.

JSUI uses Gulp, which is harder to maintain, and reverting out of it would be very difficult.

It's more predictable.

We already know what the commands do. Some executors take complex configurations, and could have unexpected side-effects.

I made an exception for the jest executor because it's configured identically to the command line and at some point I wanted to divide it into Executor configurations. However, this isn't very important, and I can change it to a nx:run-commands if you want.
Moved external-builds
Prior to this PR, Headless was building a dev/browser version of itself directly in the Atomic src directory. I noticed that Nx was inconsistently choosing to cache or not to cache those files, which I thought was the source of some caching issues I had, so I replaced packages/atomic/src/external-builds with packages/headless/www.
This change did not fix the issues I had, but in the spirit of making projects as self-contained as possible, I decided to keep this change.

Closing this. I will instead make multiple PRs where I do individual tasks instead of whole projects.


Recursive get and list for Consul KV

Pack consul
Status

pack extension

Description

Added consul.list action to get a list of Keys from consul under a given  key
Added Recursive lookup for consul.get action.
Both list and get use the same python runner with additional recurse, and listing
parameters with appropriate defaults.

Checklist (tick everything that applies)

[x] Metadata: pack.yaml, icon, structure (required for new packs)
[x] Version bump (required for changed packs)
[x] Code linting (required, can be done after the PR checks)
[ ] Tests (not required but really recommended)

keys it is.... What was I thinking!!! ;-)

Merged, thanks!


Exit1on download error

As I mentioned in https://github.com/lightpohl/podcast-dl/pull/17 I use a systemd timer to start podcast-dl.
But I realized that my favorite podcast is uploaded often on Thursday mornings, but quite some times on Thursday evenings or even on Friday or Saturday. Either I set my timer on Sunday than I can be sure that the podcast is uploaded already. Or I just retry to download it every three hours until it succeeds by using following:
Restart=on-failure
RestartSec=10800

However systemd's Restart=on-failure just works with exit codes other than zero. So this pull request is one way to achieve this :)

Just realized that this was way to quick&dirty. See #27


Fix OpenJDK default settings so as to use less memory.

Set CONTAINER_INITIAL_PERCENT to something small by
default, rather than 100%. Setting it to 100% results in -Xms==-Xmx
which is bad as it tells the GC that it's fine to use at least the max amount.
Thus it'll never attempt to return pages to the OS which it would otherwise do when
-Xms is set to something small. That's memory other containers could use.
Use -Dsun.zip.disableMemoryMapping=true as this saves some percent
on memory. The added (performance) cost for class loading is negligible.
Set -XX:MinHeapFreeRatio and -XX:MaxHeapFreeRatio to more aggressive values. This together with a low -Xms will make the GC do the right thing.
Set -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap unconditionally
as this tells the JVM that physical memory is determined by the cgroup limit (not just the heap). There are some off-heap structures which might get sized wrongly without that option.

This saves about 29% of used VmRSS over the old config for my testing. 388MB on average for the old settings. 274MB on average for the new settings. See:

The old settings produced this java command in the container:
$ java -XX:+UseParallelGC -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -Xms256m -Xmx256m -Duser.home=/var/lib/jenkins -Dfile.encoding=UTF8 -jar /usr/lib/jenkins/jenkins.war

The new settings produce this java command in the container:
 $ java -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -Xms17m -Xmx256m -Duser.home=/var/lib/jenkins -Dsun.zip.disableMemoryMapping=true -Dfile.encoding=UTF8 -jar /usr/lib/jenkins/jenkins.war

@bparees @gabemontero Please have a look.

[test]

@bparees / @jupierce / @smunilla - separate from updating the plugin versions (love that new job :-) )a new jenkins image for rhel will not be created unless we explicitly request it now, right?
@bparees - I'm assuming we want this to be post 3.7, so it can soak through a full release cycle.

And of course we want the PR test to confirm jenkins with the JDK we currently install comes up OK with these new options.

@jerboaa - both here and in you associated fabric8 PR, I was unable to infer what kind of traffic or activity was being induced against Jenkins when you were gathering your measurements.
If I just missed it, apologies (and could you give me an explicit pointer?).
Otherwise, could you elaborate?
Among other things, some capacity planning type concerns have emerged from our customer activity.
Of course, a lot of that depends on the details of the job :-)
But we are thinking of at least providing some sort of base example.  Perhaps the particulars of your test runs could be input into that.
thanks

@gabemontero Yes, a new Jenkins version is still manual, but @smunilla is going to be working on a job for it as well.

On Wed, Oct 11, 2017 at 10:46 AM, Justin Pierce<EMAIL_ADDRESS>wrote:

@gabemontero https://github.com/gabemontero Yes, a new Jenkins version
is still manual, but @smunilla https://github.com/smunilla is going to
be working on a job for it as well.

Thanks for the confirmation, and cool deal on the upcoming job

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/jenkins/pull/396#issuecomment-335835488,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbadBfuXtbJQUdUuHZrUS2V3Z0T41o1ks5srNTQgaJpZM4P1Yq9
.

@jerboaa - both here and in you associated fabric8 PR, I was unable to infer what kind of traffic or activity was being induced against Jenkins when you were gathering your measurements.
If I just missed it, apologies (and could you give me an explicit pointer?).
Otherwise, could you elaborate?
Among other things, some capacity planning type concerns have emerged from our customer activity. >Things like "I'll run 50 pipeline jobs concurrently, so how big should my heap be?"
Of course, a lot of that depends on the details of the job :-)
But we are thinking of at least providing some sort of base example. Perhaps the particulars of your >test runs could be input into that.

The testing for this and for fabric8 was different. For fabric8 I've used 3 jenkins pipeline builds ins succession of the vertx booster example.
For this PR it was manually adding a maven job which built this 3 times in succession:
http://icedtea.classpath.org/mirror/git/thermostat-ng-web-gateway/
Nothing fancy, watched console output of the first one. It's not super-scientific, but it's something. I've tried to be consistent for both runs and results seem repeatable.
I haven't done any experiments as to how the memory should increase per additional concurrent pipeline job. I suppose this can be empirically tested.

https://github.com/openshift/jenkins/blob/master/slave-base/contrib/bin/run-jnlp-client#L76-L115 needs the same treatment while we're doing this.

Right. FWIW, slave-maven should get some options for running java with good options too. Can this be done in a separate patch or this one as well?

Right. FWIW, slave-maven should get some options for running java with good options too. Can this be done in a separate patch or this one as well?

slave-maven inherits from slave-base, they should be using the same java invocation to launch the jenkins slave process, so you should only need to change slave-base.
i'd rather do it all in this PR so we have one PR that updates all the JVM settings at once, given the changes should be very similar.

@bparees - I'm assuming we want this to be post 3.7, so it can soak through a full release cycle.

@gabemontero yeah.

On Thu, Oct 12, 2017 at 9:11 AM, Ben Parees<EMAIL_ADDRESS>wrote:

@bparees requested changes on this pull request.
In 2/contrib/s2i/run
https://github.com/openshift/jenkins/pull/396#discussion_r144283697:

@@ -152,6 +150,10 @@ if [ ! -z "${CONTAINER_CORE_LIMIT}" ]; then
JAVA_CORE_LIMIT="-XX:ParallelGCThreads=${CONTAINER_CORE_LIMIT} -Djava.util.concurrent.ForkJoinPool.common.parallelism=${CONTAINER_CORE_LIMT} -XX:CICompilerCount=2"
fi

+if [ -z "${JVM_ARGS}" ]; then

JVM_ARGS="-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true"
+fi

Looks like you could reuse the JAVA_OPTS env var we already support for
this (today it looks like JAVA_OPTS doesn't get set by us, only by the
user, so you could make this the default value for it now).
In 2/contrib/s2i/run
https://github.com/openshift/jenkins/pull/396#discussion_r144283888:

fi

if [ -z "$JAVA_GC_OPTS" ]; then
note - MaxPermSize no longer valid with v8 of the jdk ... used to have -XX:MaxPermSize=100m

JAVA_GC_OPTS="-XX:+UseParallelGC -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m"

JAVA_GC_OPTS="-XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m"

is the metaspace one of the things that's runed by the cgroup limits
setting? can we get rid of that argument here? it's been a source of pain
as noted by @gabemontero https://github.com/gabemontero and others.

Yeah @jerboaa suggested just that in
https://github.com/fabric8-services/fabric8-tenant-jenkins/pull/30#issuecomment-336090860
I think it is a simply a recommendation we inherited somewhere along the
way ... perhaps it has outlived its usefulness.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/jenkins/pull/396#pullrequestreview-68917712,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbadA86GMPGxPevnVsKF4LMUuEG8DN1ks5srhAagaJpZM4P1Yq9
.

slave-maven inherits from slave-base, they should be using the same java invocation to launch the jenkins slave process, so you should only need to change slave-base.

i'd rather do it all in this PR so we have one PR that updates all the JVM settings at once, given the changes should be very similar.

I'm not sure. It is my understanding that the maven slave would need to have some MAVEN_OPTS set so that forked java processes get the right options.

I'm not sure. It is my understanding that the maven slave would need to have some MAVEN_OPTS set so that forked java processes get the right options.

i'm +1 on doing maven_opts changes in a separate PR, i just meant the slave-base changes should be in this one (and it looks like you've done that).

have we actually confirmed that the JDK we're installing in our image has the -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap options?  (not sure if it'll throw an error if it's an unknown option?)

It complains if you supply an unknown option.
On Thu, Oct 12, 2017 at 11:47 AM, Ben Parees<EMAIL_ADDRESS>wrote:

have we actually confirmed that the JDK we're installing in our image has
the -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap
options? (not sure if it'll throw an error if it's an unknown option?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/jenkins/pull/396#issuecomment-336179608,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbadK2EnVvvQ3AP1OXfAYDrE452V7hNks5srjSjgaJpZM4P1Yq9
.

have we actually confirmed that the JDK we're installing in our image has the -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap options? (not sure if it'll throw an error if it's an unknown option?)

Builds java-1.8.0-openjdk-<IP_ADDRESS>-3.b12 and up have that option. Current builds are 1.8.0-144.

OK, updated as requested. I've done another run. This time I get ~35% less memory than the old config. 388MB old, 249MB new. The truth is probably around 30%.
Old java command:
$ java -XX:+UseParallelGC -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=40 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -XX:MaxMetaspaceSize=100m -Xms256m -Xmx256m -Duser.home=/var/lib/jenkins -Dfile.encoding=UTF8 -jar /usr/lib/jenkins/jenkins.war

New java command:
 $ java -XX:+UseParallelGC -XX:MinHeapFreeRatio=5 -XX:MaxHeapFreeRatio=10 -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Xms17m -Xmx256m -Duser.home=/var/lib/jenkins -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap -Dsun.zip.disableMemoryMapping=true -Dfile.encoding=UTF8 -jar /usr/lib/jenkins/jenkins.war

Graph looked like this:

Good to go now?

thanks @jerboaa, lgtm.
@gabemontero i think we want to merge this post-3.7.  I'm thinking about creating the 3.7 branch now so we can go ahead and merge this into master, unless you anticipate significant additional changes for 3.7 that will be annoying to backport to two branches?

On Mon, Oct 16, 2017 at 5:51 AM, Ben Parees<EMAIL_ADDRESS>wrote:

thanks @jerboaa https://github.com/jerboaa, lgtm.
@gabemontero https://github.com/gabemontero i think we want to merge
this post-3.7. I'm thinking about creating the 3.7 branch now so we can go
ahead and merge this into master, unless you anticipate significant
additional changes for 3.7 that will be annoying to backport to two
branches?

Agreed on post 3.7, and no major changes anticipated.
thanks @jerboaa !

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/openshift/jenkins/pull/396#issuecomment-336837461,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADbadCCxdyT8txQ0v4UTGB5ubKdITHkrks5ssycUgaJpZM4P1Yq9
.

fyi ... @csrwng just hit a metaspace OOM tuning issue trying to run Jenkins with 64bit and > 4GB container with some CD team work ... I'm having him set JAVA_CG_OPTS to remove our setting of MaxMetaSpace ... so some real use validation of our decision here may be forthcoming soon :-)

For my test, removing the MaxMetaSpace has gotten rid of the Metaspace OOM errors and now Jenkins is functional with the 64-bit JVM (it was not responsive before)

[merge]

[merge]

@jerboaa for this workload do you think there is there any benefit in setting -Xms vs leaving it unset?  I'm wondering if it's possible to remove that code in the Jenkins scripts?

@jim-minter The default of -Xms or -XX:InititialHeapSize is 1/64 or 1/InitialRAMFraction. So if you leave it out you'll get roughly 1/64 = 1.5% for -Xms. This patch had it at 7%. I would think it should be fine to remove it.

Thanks @jerboaa.  Another question: you mention that without -XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap "some off-heap structures might get sized wrongly" - please could you provide me an example?

@jim-minter Examples are Metaspace and card tables of the GC.
-XX:+UseCGroupMemoryLimitForHeap tells the JVM to base all of its sizings on the cgroup memory limit. For example if the physical memory is 32 GB and the cgroup limit is 500MB, then the -XX:+UseCGroupMemoryLimitForHeap switch will tell the JVM that it's sufficient to size the GC card tables for 500MB of memory, not 32 GB. Note that you can simulate this behaviour outside of docker via setting -XX:MaxRAM=n where n is the container limit.

Many thanks for the additional detail @jerboaa !


[KFNBC]: Last user selection is not remembered (if they don't submit the page)

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
If I go to the spawner and select options which are different from the defaults, and then reload the page, I will be brought back to the default settings
Expected Behavior
User's last selection always persists across page loads
Steps To Reproduce
Go to spawner
Select anything that isn't default (e.g. Size from Small to Medium or Minimal Python image)
Reload page
Workaround (if any)
No response
OpenShift Version
No response
Openshift Version
No response
What browsers are you seeing the problem on?
No response
Open Data Hub Version
No response
Relevant log output
No response

@lugi0 Hi, this design is a little bit different from JupyterHub, we don't record the lastSelectedImage and lastSelectedSize when the user selects them, because that will cause too many API calls, instead, we only change the value when the user clicks Start server button.
Should we change this behavior to make it the same as JupyterHub? @samuelvl

@andrewballantyne I think this also applies to the case in which the user actually spawned the server.
It is the case for the Tensorflow image at the very least.

Sorry, you're saying you are starting a server and NOT getting your selection remembered @lugi0 ? Because that'd be a bug -- it should remember what you selected on start server button

Actually, I'm seeing inconsistent behaviour. For a couple of times it didn't work, and when I clicked on Hub Control Panel from within the JL instance, it would get me to a Page not found error page in the dashboard instead of the control panel.
Now I've been trying again with other images (as well as the tensorflow image) and I don't get that Page not found error anymore, and my last selection is remembered.
The only thing I can think of is that an image was being rebuilt while this was happening, but I'm not sure what it could have to do with it

Yes, I can reproduce it, when a build is ongoing the Hub Control Panel will redirect to a Page Not Found and the last selection won't be remembered

I don't know if you want me to open a new bug for Hub Control Panel redirecting to Page Not Found, it seems like a separate issue

@lugi0 When you get the 404, can you hold down your back browser button and get the URL to the previous page? I think we keep it in your history when we send you to 404. On Chrome that requires the "show history" and right clicking on the url and "copy link address".
The url should contain your username (translated if it had invalid k8s name characters). If your username is not in the user state we have, we cannot reform your username and collect all related user data at this time -- so we kick you to 404.
We should be able to improve this once we keep the notebook around and use it as a source of truth for user data (https://github.com/opendatahub-io/odh-dashboard/issues/387)
It is the same issue likely... we are failing to find your former state. It is currently stored in your ODH Dashboard Config (in the status field) -- feel free check out that status to give anymore information on what data we are using. It is likely a data issue and not a coding issue.

I believe the URL it tries to redirect me to is:
https://rhods-dashboard-redhat-ods-applications.apps<MY-CLUSTER>.rl7o.s1.devshift.org/notebookController/ldap-2dadmin4/home

Not sure what to look for in the odhdashboardconfig CRD, this is what I have in the status field:
status:
  conditions:
    - type: NamesAccepted
      status: 'True'
      lastTransitionTime: '2022-08-02T11:46:09Z'
      reason: NoConflicts
      message: no conflicts found
    - type: Established
      status: 'True'
      lastTransitionTime: '2022-08-02T11:46:09Z'
      reason: InitialNamesAccepted
      message: the initial names have been accepted
  acceptedNames:
    plural: odhdashboardconfigs
    singular: odhdashboardconfig
    kind: OdhDashboardConfig
    listKind: OdhDashboardConfigList
  storedVersions:
    - v1alpha

Sorry, the ODH Dashboard Config IN your dashboard namespace... the CR, not the CRD.

Correct, we don't know who you are so we can't un-translate the name in the URL back to your state. This is a wonky setup today and should improve when we go to using Notebooks as a source of truth -- because your Notebook will have everything we need to associate you back to it.

For the dev who codes it:
We'll likely implement this via localStorage & make use of the existing hook to pull that information and use it in the Spawner page

As we move forward, this only impacts the initial users who also do not submit the notebook creation. We'll handle what options they have to them via other features as we progress. This issue will become obsolete before we can implement the transient user who doesn't want to submit but wants to store their selection.


Fix hazelcast network config

Fix hazelcast network config to use only one port
Ref: https://docs.hazelcast.org//docs/latest/manual/html-single/index.html#port

build this

deploy this

Thanks :)


Issue with Browser Instructions

Hi,
README.md points to the following scripts for loading js-beautify in the browser:
<script src="https://cdn.rawgit.com/beautify-web/js-beautify/1.6.4/js/lib/beautify.js"></script>
<script src="https://cdn.rawgit.com/beautify-web/js-beautify/1.6.4/js/lib/beautify-css.js"></script>
<script src="https://cdn.rawgit.com/beautify-web/js-beautify/1.6.4/js/lib/beautify-html.js"></script>

I think the URL should have v1.6.4 for the branch name instead of 1.6.4.
In addition, I think it would be helpful to mention that the scripts load function html_beautify, etc. as that wasn't obvious to me when I was trying to use the scripts.  (I ended up reading the source to find the function name).

Cool, could you put in a PR with those changes?


Wrap element in DebugCreator into WeakReference, to prevent leaks in debug mode.

This seems to me to be treating a symptom rather than the underlying bug. Why is a layer alive with a pointer to an Element that is long gone? Does that mean the Layer's debug data is out of date? Would someone inspecting the layer tree not want to see this Element? And if not, what Element would they want to see instead? And why isn't what we're exposing?

From offline discussion - it'd be really good to know what's retaining these DebugCreator objects.
If the retaining objects are Layers, then we should check if the layers are getting disposed. If they are, they probably need to be nulling out their debugCreator field in dispose. If they're not, we need to figure out why.

From offline discussion - it'd be really good to know what's retaining these DebugCreator objects.
If the retaining objects are Layers, then we should check if the layers are getting disposed. If they are, they probably need to be nulling out their debugCreator field in dispose. If they're not, we need to figure out why.

Here is the retaining path I got for the gallery: /1464643415-_HashMapEntry/243027135-StatefulElement/1801536403-_NotificationNode/278532993-_NotificationElement/370712559-SingleChildRenderObjectElement/1040365597-RenderIndexedSemantics/1664721964-RenderRepaintBoundary/3329278007-LayerHandle/4157549721-OffsetLayer/2923703610-PhysicalModelLayer/2236930093-DebugCreator/650437893-SingleChildRenderObjectElement/

I suspect the problem is either that debugCreator is not getting set properly or it's not getting cleared on layer disposal...

should it still be DebugCreator responsibility to guarantee that it will not hold the object from being GCed, no matter what owners of DebugCreator are doing?

The DebugCreator class is just a wrapper around Element that has an opinionated toString, I don't think it's its responsibility to do anything special about GC. Literally nothing else in the entire framework does anything relating to GC, so this would be a very surprising place to start doing something. :-)
As Dan says, this is an ownership/lifetime issue. If we get the logic right, we don't need to worry about GC at all.

@Hixie , thanks.
I will dig deeper to figure out what can be the root issue here.

Got some new cases and created issue for further investigation: https://github.com/flutter/flutter/issues/107338

(triage) @polina-c based on the discussion above, can we close this one?

(triage) @polina-c based on the discussion above, can we close this one?

Closed.