text:
OpenSSL barfs on critical crlDistributionPoint extensions that are critical

This occurs with 1.0.1e.
Given a CA and an identity certificate with crlDistributionPoint extensions, openssl correctly fetches the CRL and detects revocation when the crlDistributionPoint extension is marked non critical, but barfs when the crlDistributionPoint extension is marked critical.
I thought this might have something to do with it being marked critical implying scope segmentation, but I made sure that my CRL has the matching Issuing Distribution Point extension.

does this also happen in current versions?

No response from original submitter. 1.0.1 only receives security fixes, so if this only impacts 1.0.1 it will not be fixed. Closing.

This is still an issue on 1.0.2k
The actual error with openssl verify is:
error 34 at 0 depth lookup:unhandled critical extension
-ignore_critical makes it go away, but that's obviously wrong.

OpenSSL does not handle crlDistributionPoint.  Therefore it is doing the right thing.

authors: mattcaswell richsalz rylarson zviratko


text:
opensslconf.h and opensslv.h include each other

The subject line says it all.  These two files should be untangled somehow.  One option, probably the simplest (I spent a bit of time trying to do it and failed) is to merge opensslv.h into opensslconf.h.in and make the first one just be a one-liner that includes the second one.

Hmmm, how about something less disruptive?  We could move all the API compat stuff to opensslv.h, that way it won't need to include opensslconf.h

I couldn't make that work, but you're smarter than I, so go for it :)
On the other rand, right now each file includes the other, so the simpler change won't break user-code that depends on that.

I've a question: have you observed an actual issue, such as compilation going berzerk, dependency errors or something like that?  I.e., pragmatically speaking, is there anything more concrete than your own sense of what's right and beautiful?
I'm asking 'cause this can be observed:
opensslv.h:
#ifndef HEADER_OPENSSLV_H
# define HEADER_OPENSSLV_H

...

# include <openssl/opensslconf.h>

...

#endif                          /* HEADER_OPENSSLV_H */

opensslconf.h:
#include <openssl/opensslv.h>

#ifndef HEADER_OPENSSLCONF_H
# define HEADER_OPENSSLCONF_H

...

#endif                          /* HEADER_OPENSSLCONF_H */

In other words, at least one of the includes is done under the protection of guards, and that prevents inclusion loops.  Can you see a scenario where that prevension is circumvented?

Scenario 1:

someone includes opensslv.h
opensslv.h defines HEADER_OPENSSLV_H
opensslv.h includes opensslconf.h

opensslconf.h includes opensslv.h, whose contents are ignored because of HEADER_OPENSSLV_H
opensslconf.h defines HEADER_OPENSSLCONF_H
opensslconf.h finishes

opensslv.h finishes

Scenario 2:

someone includes opensslconf.h
opensslconf.h includes opensslv.h

opensslv.h defines HEADER_OPENSSLV_H
opensslv.h includes opensslconf.h

opensslconf.h includes opensslv.h, whose contents are ignored because of HEADER_OPENSSLV_H
opensslconf.h defines HEADER_OPENSSLCONF_H
opensslconf.h finishes

opensslv.h finishes

opensslconf.h is skipped over because the earlier inclusion by opensslv.h defined HEADER_OPENSSLCONF_H

So yeah, there are a couple of levels of inclusion, but nothing that makes it loop endlessly.
Worth fixing, or shall we invoke the "it works, don't fix it!" mantra?

Worth fixing, or shall we invoke the "it works, don't fix it!" mantra?

Feel free to close the issue if you don't want to address it.
I found it trying to add a guard to the other header file.  It "stuck out" that there was no guard there, and then I fell down the rabbit-hole trying to fix it.

I found it trying to add a guard to the other header file

Uhmmmm, which "other header file" are you referring to?

Oh never mind.  I was hopelessly lost.  Just close this darn thing if you don't care.

Yeah, I think I'll do so.  "It works, don't fix it!" is a good mantra at times.
Of course, if we do find a concrete case where it doesn't work, it will be time to revisit the issue.

Hmmm, how about something less disruptive? We could move all the API compat stuff to opensslv.h, that way it won't need to include opensslconf.h

@richsalz was right, it i causing problems.  And @levitte's first reaction would have bee the appropriate solution.
Fix is now in #9623.

source: gharchive/issue

authors: levitte mspncp richsalz

repo: openssl/openssl

license_type: permissive

license_source: github-api


text:
Don't ignore ASN1 when checking for undocumented symbols

When we run "make doc-nits" (which happens during travis runs) it will
complain if we add any new symbols that aren't documented. However it
was suppressing anything starting with ASN1. There's no reason why we
should allow ASN1 symbols to go undocumented any more than any others.
Therefore we remove that exception.

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

Ping?

Knowing which of these isn't documented seems like a good idea.

Darn. PR #10942 went in and added a new and undocumented ASN1 function with the promise from @levitte that he would add the docs real soon. Until that happens we need to add that function to missingcrypto.txt in this PR to avoid a "make doc-nits" failure.
@paulidale (or anyone) please can you reconfirm?

Travis red cross is not relevant.
Ping?

Pushed. Thanks.

source: gharchive/pull-request

authors: mattcaswell paulidale


text:
s_server: fix read_from_terminal behavior

s_server closes accept socket and then terminates after reading EOF from
terminal.
This commit fixes this behavior: now, the only proper way to do that is
explicit q or Q command.
CLA: trivial

well this is useful for automated testing, and it's easy to quit with Ctrl+C


text:
Ignoring auto generated files

Building project on windows creates several auto generated files. Added these files to ignore list to prevent marking repository as dirty.

The current .gitignore file seems to include all of these (except /ms/uptable.*), so this PR can be closed.

@ghedo do we need /ms/updtable.* added?

I don't know, I don't have any Windows machine so I can't check. But I guess that if it hasn't been added so far (while the others have) it probably isn't needed.

But if you do add it, you may want to look at #337 as well, while you are at it.

authors: ENikS ghedo richsalz


text:
various kdfs: Always reset buflen after clearing the buffer

This applies a similar fix as #17164 to other KDF implementations.
This applies to both master and 3.0 branches.

There is too much boilerplate code in these :(

Yup, KDFs could do with some common code

24 hours has passed since 'approval: done' was set, but as this PR has been updated in that time the label 'approval: ready to merge' is not being automatically set.  Please review the updates and set the label manually.

Merged to master and 3.0 branches. Thank you for the review.

authors: levitte openssl-machine t8m


text:
Don't call ossl_assert on the result of bn_wexpand

bn_wexpand can fail as the result of a memory allocation failure. We should not be calling ossl_assert() on its result because it can fail in normal operation.
Found via the reproducible error injection in #21668

Pushed. Thanks.


text:
Ensure cmd from fuzz buffer is always valid

The quic-srtm fuzzer uses a loop in which an integer command is extracted from the fuzzer buffer input to determine the action to take, switching on the values between 0 and 3, and ignoring all other commands.  Howver in the failing fuzzer test case here: https://oss-fuzz.com/testcase-detail/5618331942977536
The buffer provided shows a large number of 0 values (indicating an SRTM add command), and almost no 1, 2, or 3 values.  As such, the fuzzer only truly exercises the srtm add path, which has the side effect of growing the SRTM hash table unboundedly, leading to a timeout when 10 entries need to be iterated over when the hashtable doall command is executed.
Fix this by ensuring that the command is always valid, and reasonably distributed among all the operations with some modulo math.
Introducing this change bounds the hash table size in the reproducer test case to less than half of the initially observed size, and avoids the timeout.
Fixes openssl/project#679

I don't see how this fixes anything. As far as I can see, it can still generate as many add commands as it wants. And the other values seem to be ignored anyway.

See #24831 where a similar issue in the lcidm is addressed in a different way.

This pull request is ready to merge

merged

authors: kroeckx mattcaswell nhorman openssl-machine


text:
fips: remove drgb_no_trunc_dgst IG withdrawn

fips: remove drgb_no_trunc_dgst IG withdrawn
IG D.G moved to W.2 and has withdrawn status. Meaning any approved
hash, including truncated ones, are allowed.
Remove all of drbg_no_trunc_dgst support, as it is now
irrelevant. Leave history note in EVP_RAND manpages, as a hint as to
why some hashes might not work with 3.1.1 - 3.4 fips providers.

Changes update

OTC: Removing the command option is a breaking change.  Should it be allowed?

Kick CIs

I see cross-testing failures. I am not familiar with them.
Do I need to create 3.x-branch specific pull requests that limit EVP tests of truncated DRBGs to the v3.1.1 - v3.4  range only?
Or is it a false negative, because cross-test used master-tip test suite, rather than the PR-tip test suite?
Test Summary Report
-------------------
30-test_evp.t                         (Wstat: 256 Tests: 123 Failed: 1)
  Failed test:  63
  Non-zero exit status: 1
Files=327, Tests=4230, 142 wallclock secs (10.62 usr  1.12 sys + 372.99 cusr 83.07 csys = 467.80 CPU)

Do I need to create 3.x-branch specific pull requests that limit EVP tests of truncated DRBGs to the v3.1.1 - v3.4 range only?

This is the usual way.  Removing the tests is another possibility which is tempting here (but wait to see if that's a wider opinion).

Or we could just leave it as it is.. There is really not much reason to use these anyway.
It wasnt too long ago that this was added.

Yeah, we would at least need to keep the command line option as no-op.

I very much doubt anyone uses the command line option.  It's fairly recent and rather pointless.

OTC: We want to keep the restriction unless there is compelling reason to allow the truncated hashes.

Ack, then unapproved service indicator should be removed in favor of simple runtime check. As at this point it is a user choice (or compile time choice) which is approved either way.

authors: paulidale slontis t8m xnox


text:
chore: misc changes

Checklist

[ ] documentation is added or updated
[ ] tests are added or updated

This pull request is ready to merge

Partially squashed and merged to the master branch. Thank you for your contribution.

authors: openssl-machine t8m willmafh


text:
Memory bounds checking in asn1 code.

Check that sprint, strcpy don't overflow.
Avoid some strlen operations when the previous sprintf return value can be used.
Also fix the undefined behaviour *(long *)x = y when x isn't a long or character pointer.
ISO/IEC 9899:1999 6.5/7 for the details.

Fixes pushed.

H-m-m-m-m... I feel that I have to rise kind of objection to [at least] rationale behind replacing *(long *)x = y with memcpy. I mean rationale is to counter undefined behaviour. Well, formally speaking memcpy doesn't really cut it. The change kind of suggests that we are working with kind of "wire" data, i.e. pieces of data payload that is or is to be delivered by some inter-peer communication means. But[!] if this was actually case, then we wouldn't be able to assume that data is arranged in host byte order. I mean surrounding code is written under assumption that data comes in host byte order, isn't it? And consequently we have to assume that producer or consumer of this data is application code in same process context, not some "wire" data. But in such case behaviour is rendered undefined only if original and assumed types are different. Which in turn means that memcpy would be as inappropriate. [And that COPY_SIZE thing actually makes it apparent, doesn't it?]
Just in case for reference. This kind of contradicts concerns I've risen in #3701. Well, yes, but there is difference between first impressions/reactions and conclusions you can draw after actually contemplating the problem. This is such case...
Now question also is if there are any possible objections to the implementation. Is there possibility that it falls victim of type-punning thing? I mean when optimizing compiler rearranges references to object "arguing" that these are incompatible types and hence can't overlap? Basically what I'm saying is if one should use union here [to ensure that compiler doesn't rearranges references]?

authors: dot-asm paulidale


text:
Guard against DoS in name constraints handling.

This guards against the name constraints check consuming large amounts
of CPU time when certificates in the presented chain contain an
excessive number of names (specifically subject email names or subject
alternative DNS names) and/or name constraints.
Name constraints checking compares the names presented in a certificate
against the name constraints included in a certificate higher up in the
chain using two nested for loops.
Move the name constraints check so that it happens after signature
verification so peers cannot exploit this using a chain with invalid
signatures. Also impose a hard limit on the number of name constraints
check loop iterations to further mitigate the issue.
Thanks to NCC for finding this issue. Fix written by Martin Kreichgauer.
Reviewed-by: Rich Salz rsalz@openssl.org
Reviewed-by: Andy Polyakov appro@openssl.org
(Merged from https://github.com/openssl/openssl/pull/4393)
(cherry picked from commit 8545051c3652bce7bb962afcb6879c4a6288bc67)
Resolved conflicts:
crypto/x509v3/v3_ncons.c
test/recipes/25-test_verify.t

It was suggested that this should be applied to 1.1.0, but question also is if 1.0.2 deserves it.

Oh! Commit message will have to be adjusted to reflect this merge request...

I think the NC code in 1.0.2 was basically broken, but if you can cherry-pick I approve that too

if you can cherry-pick I approve that too

It wasn't a coincidence that I wrote "deserve" and not "cherry-pick". This code definitely won't cherry-pick into 1.0.2, but it doesn't answer the question: if this protection is worth considering even in 1.0.2 context. I.e. irregardless cherry-pick-ability.

I suppose it should be fixed in 1.0.2

And this one still needs approval :-)

Reformat pushed...

Ping @levitte.

authors: dot-asm richsalz


text:
Fix race condition in TLSProxy (1.1.0)

Normally TLSProxy waits for the s_server process to finish before
continuing. However in cases where serverconnects > 1 we need to keep the
s_server process around for a later test so we continue immediately. This
means that TAP test output can end up being printed to stdout at the same
time as s_server is printing stuff. This confuses the test runner and can
cause spurious test failures. This commit introduces a small delay in cases
where serverconnects > 1 in order to give s_server enough time to finish
what it was doing before we continue to the next test.
Fixes #4129
This is the 1.1.0 version of #4660.

[x] tests are added or updated

Pushed. Thanks.


text:
Some doc fixes

Fixes #6606.
Also, fixed some L<> style errors that I found.
Not going to backport.

I'm going to wait on merging this (@paulidale approved it) until @levitte is okay with it.

Merged, thanks for the feedback/improvements.


text:
[ci_gen_kustomize_values]Add support to VA2 NFV network-values

This changes to add support to kustomize VA2 NFV network values for OCP nodes.
As a pull request owner and reviewers, I checked that:

[x] Appropriate testing is done and actually running
[x] Appropriate documentation exists and/or is up-to-date:

[x] README in the role
[x] Content of the docs/source is reflecting the changes

Hey @Jaganathancse is this patch still required?

Hey @Jaganathancse is this patch still required?

yes, please review.

Hey @Jaganathancse is this patch still required?

yes, please review.

Okay, do you have a test project patch testing this and example output from the j2?

Hey @Jaganathancse is this patch still required?

yes, please review.

Okay, do you have a test project patch testing this and example output from the j2?

this is just duplication similar like ovs dpdk sriov scenario.

Not needed anymore as the common template does the job for ovs-dpdk-sriov and these two templates are identical to that one.

authors: Jaganathancse lewisdenny pablintino


text:
Remove edpm_ssh_known_hosts role from configure_os.yml

The role can be removed from configure_os.yml once the
dataplane-operator PR merges to use the new playbook.
Depends-On: https://github.com/openstack-k8s-operators/dataplane-operator/pull/712
Signed-off-by: James Slagle jslagle@redhat.com

closed in favor of https://github.com/openstack-k8s-operators/edpm-ansible/pull/584


text:
DNM: Convert edpm-ansible to a collection

!!!! WIP !!!!
Do not merge!
This is an attempt to convert this project to an ansible collection, so it could be installed by ansible-galaxy without using python setuptools. It could also packaged more easily (due to spec ansible-macros).

recheck

recheck

recheck


text:
Added EDPM based Zuul jobs

It adds following jobs which will run against dataplane operator.:

ansibleee-operator-content-provider job which will build the operator and meta operator images and push it to local registry. The job will be paused to serve as a registry.
ansibleee-operator-crc-podified-edpm-deployment is the child job which will pull the required meta operator images from content provider. The Zuul will pass the necessary vars to the child job.

Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/171

/retest

recheck


text:
[zuul] Add telemetry-operator-multinode-autoscaling-tempest job

This is a first pass, creating a tempest job based on neutron-operator. This change runs the neutron tempest tests to establish that the environment is configured correctly for tempest tests.
Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/1110
Depends-On: https://github.com/openstack-k8s-operators/ci-framework/pull/1116
Depends-On:  https://github.com/openstack-k8s-operators/openstack-operator/pull/644
Depends-On: https://github.com/openstack-k8s-operators/tcib/pull/132
Depends-On: https://github.com/openstack-k8s-operators/telemetry-operator/pull/301
Depends-On: https://review.opendev.org/c/openstack/releases/+/907406
Depends-On: https://review.rdoproject.org/r/c/rdoinfo/+/51721

recheck

recheck

recheck
I update the PR description to add a dependency

recheck

recheck

recheck
Failure was in deploying dataplane nodes

recheck
The dependant change has been fixed

recheck
The job failed because of an undefined var; I typoed the name of the var in the dependant patch.
The tempest molecule job has been re-enabled in ci_framework pr1065.

recheck
ci-framework change is passing molecule, meaning the image gets successfully built

recheck
merge conflict resolved

recheck

recheck
timeout waiting for edpm nodes to deploy

recheck

Recheck
Dependant patch was updated

I understand the need for a fix, but please try to work upstream to fix telemetry-tempest-plugin. The version can be updated but you need to do that in RDO, so that the packing propagates to the image we use.

That is my intention, I've been adding workarounds so I can focus on getting the tests to run.
I intend to clear all the workarounds before this merges.

check-rdo

There are a lot of workarounds, but I understand why they're there and I know there is work being done to eventually get rid of them. The configuration looks good to me.

This is blocked until the promotion job passes.
https://review.rdoproject.org/zuul/builds?pipeline=openstack-periodic-container-antelope-centos9&skip=0
At that point, a new container should be available with the expected changes.

Merge Failed.
This change or one of its cross-repo dependencies was unable to be automatically merged with the current state of its repository. Please rebase the change and upload a new patchset. Warning: Error merging github.com/openstack-k8s-operators/telemetry-operator for 284,03754e13c5cf5cfdb9f473ca9b0fb284e3c96ee1

The content provider job failed to run for https://github.com/openstack-k8s-operators/telemetry-operator/pull/301 .
It is running again now, so this status should clear up.
I won't recheck anything here, sicne I still expect them to fail until https://github.com/openstack-k8s-operators/tcib/pull/132 change propagates (details about)

The change from https://github.com/openstack-k8s-operators/tcib/pull/132 has propogated!
I don't expect this to pass yet as the dependant PR, which adds the autoscaling job, is not passing.
I am trying to resolve the issues with the autoscaling job #301 and will rebase this PR once the issues are resolved

Build failed (check pipeline).  Post recheck (without leading slash)
to rerun all jobs. Make sure the failure cause has been resolved before
you rerun jobs.
https://review.rdoproject.org/zuul/buildset/203091a3f54345119607403ea5c36b3e
:heavy_check_mark: openstack-k8s-operators-content-provider  SUCCESS in 1h 31m 58s
:heavy_check_mark: podified-multinode-edpm-deployment-crc  SUCCESS in 1h 07m 06s
:x: telemetry-operator-multinode-autoscaling-tempest  FAILURE in 59m 48s

This is a legitimate tempest failure.
I need to check whether it's a known issue or update the OpenStack configuration.

check-rdo

check-rdo

check-rdo

check-rdo

authors: elfiesmelfie vyzigold


text:
Incorrect positioning of Minnesota Composite Image Service imagery

URL
https://www.openstreetmap.org/edit#map=21/44.9770183/-93.2263605
How to reproduce the issue?
Go to the above URL and toggle between "Minnesota Composite Image Service" and "Hennepin County Orthoimagery (2024)", see that "Minnesota Composite Image Service" appears offset by approximately a meter
Screenshot(s) or anything else?
Screenshots of the difference:

I reached out to the contact for the MCIS imagery dataset, who said "My first thought is, has the imagery been converted to the appropriate coordinate system? I believe OSM uses WGS84, and the imagery is in UTM NAD83 Zone 15". That appears to be the issue to me.
The file is too big to link directly to the line, but in data/imagery.json, there's the section with "id": "Minnesota-Composite-Image-Service", that is listed as "projection": "EPSG:3857". This seems incorrect, as it should be https://epsg.io/26915 instead of https://epsg.io/3857, from what I can tell.
Which deployed environments do you see the issue in?
Released version at openstreetmap.org/edit
What version numbers does this issue effect?
2.30.2
Which browsers are you seeing this problem on?
Firefox

Please check the "editor layer index" repo for the PR that added this imagery an reach out there or open an new issue there. iD does take the images from there.

@tordans This might be an issue with the import process for iD? Here's the relevant file from that repo:
https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/north-america/us/mn/MinnesotaCompositeImageService.geojson?short_path=bf2fb59#L807-L810
It lists both EPSG:3857 and EPSG:26915 as available projections, but the file in this repo only lists EPSG:3857. Is that an issue?

Opened a PR as possible quick solution.
Ref https://github.com/osmlab/editor-layer-index/pull/1031
@rbuffat Could you have a look at this, please? It seems this is another issue with generated projections, though maybe it was already fixed for future files.

https://github.com/osmlab/editor-layer-index/pull/2459

@knkski I am wondering why you think this is an projection issue? Comparing Bing vs. the other options, it looks to me that all the other options show the buildings in the same position but Bing is off. It is not uncommon that different image layers are off by a bit which is why you can adjust the image layer position to fit the commonly used mapping in that area.

The author seems to have been confused by OSM using EPSG:3857 instead of the more local NAD83. (not a preference of the editor itself), or it is a typo they mixed up the projections.
@tordans First layer shown on screenshots is Hennepin County, second is Minnesota Composite. Objects line up with both Bing and Hennepin but not with Minnesota Composite.

It lists both EPSG:3857 and EPSG:26915 as available projections, but the file in this repo only lists EPSG:3857. Is that an issue?

No, that's fine: as iD can only consume EPSG:3857 (and its aliases) or EPSG:4326 (#4858) sources, all other projections are not included in the bundled file for iD.

authors: danieldegroot2 knkski tordans tyrasd

repo: openstreetmap/iD

license: ISC


text:
Offer copying line segments in place

Here we see the user has roughly made a road next to a preexisting administrative boundary,

when in fact the road lies right on top of the administrative boundary.
If he could just copy a line segment in place the map would be much better.
Yes he can copy an entire district boundary, split and delete the "C" shaped majority of the "O" shaped boundary he doesn't need, then move it exactly back on top of where it was, but that is a lot of trouble.

I like this idea. Currently iD just ignores untagged vertices when copying, so this would be an additive feature.

(Another idea would be for the user to just add more tags to existing geometries: this line is both a road and a boundary.
But that is frowned upon, as changes to river flows do not usually affect boundary treaties based upon them. Hence the need for a way to easily duplicate lines (that may later change, and thus need to be two, not one.)

authors: jidanni quincylvania


text:
wrong QA warning "crossing ways" between a linear and an area-way on different levels

Hi,
please have a look at this footway: https://www.openstreetmap.org/way/589491916 in iD, its on level 0. It is claimed that it would cross with the pedestrian-multipolygon way https://www.openstreetmap.org/relation/3687928 , which is on level 1.
When there are two linear ways crossing on different levels, no warning is shown. But when a linear and an area-way are crossng on different levels, there is this warning which I think isn't necessary.
I know the footway in my example is indoor and might should be highway=corridor instead, but this has nothing to do with this, because is would have no effect, the same warning would appear.

+1
This seems a similar case:
https://www.openstreetmap.org/edit?way=839971909#map=19/47.56084/7.59054
Is it?

Yes, it is.

@Lukas458 Thanks for reporting. This was an issue with tags like level and layer getting ignored on all multipolygon crossings, such as highway areas and buildings.

authors: Lukas458 quincylvania sun-geo


text:
When adding a direction using the up/down arrow values go negative.

Had this a number of times being flagged on the issue report, which is dating from before the 5 degrees step change i.e. when direction incremented/decremented by 10 degrees. The simplest reproducible test is to enter direction=0, then using the down, the value goes -5. The OSMI issue report flags this as a suspect value. Going from 355 to 5 and back effectively turns 355 to -5 too.
O/T WishListed: Fantastic would be if 1) holding the up/down in/decrementing rolls on rather that clicking multiple times to get to a desired beam alignment. 2) Outstanding would be if one could grab the beam and drag it around.
thanks for reading.

Welcome, @sekerob. Is this causing problems for any actual data consumers? 355° and -5° are equivalent for the direction a stationary object is facing.

Outstanding would be if one could grab the beam and drag it around.

I'd consider this a separate issue…

Thanks for your comment and probably no, a data consumer will likely know that all numbers are an offset to 0, due north. Unfortunately hitting false-positive or ignore does not resolve... few weeks later the same issue pops up again. Anyway, thought if greater than 360, subtract 360 and if less than zero, add 360 would cure the issue. Hardly expect an editor doing a full circle twice.
cheers

authors: quincylvania sekerob


text:
Continuation of work from #3194

ui-2 branch is like #3194 but

things that are exported keep their names (except as noted below)
internal variables get new names where they conflice (fields -> fieldArr)
/ui/presets -> /ui/fields
some name changes in intro

I will be working on this.
cc @bhousel @tmcw

I just updated the PR, it is now runnable locally.
However for some very weird reason the spec/ui/preset tests are failing.
I loaded the browser and seems fine to me. ( I didnt do a comprehensive manual UI testing ).
cc: @bhousel @tmcw

authors: bhousel kepta


text:
fix(icon): Use communications tower icon for communications tower feature

As was pointed out in #6985, the icon for communications tower does not match.
This uses the icon maki-communications-tower for the Communication Tower feature.

Thanks for the PR, @hackily! So we try to have different icons for masts and towers since OSM makes a distinction between them. We're already using this icon for the communication mast presets so we'll have to find or draw something more tower-y. See https://wiki.openstreetmap.org/wiki/Tag:tower:type=communication

Sounds good @quincylvania - I was actually drawing a new one last night (I also don’t really like the maki one).. will ping you later today

authors: bhousel hackily quincylvania


text:
Add flashing_lights field

This PR adds a field for flashing_lights which will be used for Unmarked/Marked Crossing presets. The key flashing_lights currently has around 2.5K uses. I've added values listed on the wiki article (no, yes, button, always, sensor, and button;sensor). Crossings with flashing lights are pretty common in the US, here's an example from Alexandria, VA:

Good suggestion! I would only request one small change: given that the current usage is very small (less than 0.5% of crossings use the tag), I think it would be better to add this one as an optional field (moreFields). What do you think?

Yeah, this makes sense

repo: openstreetmap/id-tagging-schema


text:
OT Genetics portal sourced evidences: some studies are missing disease label

When @AsierGonzalez performed QC checks on the evidences for the 20.02 release it made clear ~4k Genetics portal sourced evidences are missing disease label. The initial investigation showed only a handful of studies are affected but needs to find out why this is happening.

Related to #860

A fix is going to be added to the evidence creator script that tests if the disease label is provided and skips rows where it is missing (while raising warnings), so these evidences won't reach the pipeline.

Bug found: when the evidences are generated there's no check to ensure the evidence has a disease label. This is going to be fixed and a warning is thrown for each such evidences so we'll see these rows in the log file.
Otherwise based on the input data this is expected: ~750 studies in the genetics portal study table has no disease associated with.

Fixes to filter out studies without disease id are merged: #42
Fix to prevent the generation of evidences without disease is merged: #39

repo: opentargets/platform


text:
Chore: FQNs should be constructed/deconstructed by the same utility function throughout the platform

Background
There is a need to look up attributes (namespaces, definitions, values) by FQNs, and therefore a need to build, store, and tear them down. https://github.com/opentdf/platform/issues/95 added the functionality to store FQNs in the database for lookup FQN -> Policy Attribute Objects, but there are needs in Access PDP, test functions, and the policy services to dynamically build FQNs going from Policy Attribute Objects -> FQNs. This should be common functionality
Acceptance Criteria

A shared suite of functions is built and consumed throughout to build and tear apart FQNs
Unit tests thoroughly cover them
Existing helper funcs and fmt.Sprintf calls are replaced by the shared functions
The policy GetAttributesByValueFQNs request (consumed by Auth service requests) successfully populates FQNs for all policy objects in response without doing joins with the FQNs table, deferring to composite keys and foreign keys to preserve relational integrity

Reopening with additional context that we should move validation like what was introduced here into a platform policy lib so that we can share it throughout the platform services and downstream PEPs.

repo: opentdf/platform


text:
Aggregate by quarter instead of by month

I forget if we can do this already, but if not we should when we know we don't have as much data in certain locations -- change the time aggregations to quarters or years, etc, or remove the timeline and just show all the data we know about.
If this is possible, then let's document it?

@dwins sent me this: https://www.postgresql.org/docs/9.6/static/functions-datetime.html#FUNCTIONS-DATETIME-TRUNC
which means we could change the default to quarters! something to look at as part of the #mozsprint

This can be accomplished by changing the UI display from months to quarters and setting the query string to bin by quarter.

@georgiamoon @meagdoh I'm putting some notes here on what I've been working on for this issue.

I'm working on this in a feature branch: https://github.com/critzo/piecewise/tree/quarters
A GCE VM is available to test deploy to here: https://104.197.237.109/

Georgia you should have ssh access to this VM now
Meag, if you send me your SSH public key, I'll add your access to it

Summary of Work:

Postgres supports quarter aggregation out of the box, so changing the dataURL is pretty easy.
Debugging and getting the JavaScript / JQuery to update the URL with appropriate start and end timestamps when the user clicks on the timeline element has been the main sticky bit.
Two things to-do:

Adjust the timeline/slider so it displays four quarters instead of 12 months

Month / Quarter labels are defined in the global config file
Slider instantiation is happening in piecewise_web/mlab.js

L168
L198

Adjust the functions that provide start/end when selecting a particular quarter

I started a function, getQuarter, to provide the start/end timestamps of a quarter, given a selected month, but it's not working.
I think that getQuarter needs to be called on the index page, so that when users click on a selected tick mark the quarter values are updated.

authors: critzo georgiamoon

repo: opentechinstitute/piecewise

license_source: bigquery


text:
Update OBS documentation and examples

Customer request: https://jira.tsi-dev.otc-service.com/browse/STO-18275
DETAILS FROM CS0509439:
Tenant-ID: OTC00000000001000******
Ihre Frage an uns: Hi, where can we find the latest documentation of the OTC Extensions for the OpenStack SDK, especially related to interacting with OBS? In the following versions, the OBS part is completely missing and the default OpenStack methods don't work. otcextensions 0.30.5.dev2 https://docs.otc.t-systems.com/python-otcextensions/index.html otcextensions 0.30.3.dev3 https://python-otcextensions.readthedocs.io/en/latest/index.html otcextensions 0.25.1.dev7 https://docs.otc-service.com/python-otcextensions/
REQUEST DESCRIPTION:
Tenant-ID: OTC00000000001000******
Ihre Frage an uns: Hi, where can we find the latest documentation of the OTC Extensions for the OpenStack SDK, especially related to interacting with OBS? In the following versions, the OBS part is completely missing and the default OpenStack methods don't work. otcextensions 0.30.5.dev2 https://docs.otc.t-systems.com/python-otcextensions/index.html otcextensions 0.30.3.dev3 https://python-otcextensions.readthedocs.io/en/latest/index.html otcextensions 0.25.1.dev7 https://docs.otc-service.com/python-otcextensions/

https://docs.otc.t-systems.com/python-otcextensions/sdk/proxies/obs.html

repo: opentelekomcloud/python-otcextensions


text:
add permission update argument

Add an argument to check for read/search/get permissions of a specified user/role on the newly created index and add permissions if necessary.

Not needed

repo: opentelekomcloud/sphinx-opensearch


text:
Use cmake in docs and fix Issue 100 - scan cmd

Removes Makefile references
Resolves: https://github.com/openthread/ot-docs/issues/100

Hi @jwhui - this could use a tech review too; not sure who to add...thanks!

repo: openthread/ot-docs


text:
🐛 [Bug]: 自定义物料，拖入编辑器后，无法选中

Environment
dev
Version
20
Version
latest
Link to minimal reproduction
// json
{   "name": {     "zh_CN": "iframe"   },   "component": "iframe",   "icon": "iframe",   "description": "iframe",   "docUrl": "",   "screenshot": "",   "tags": "",   "keywords": "",   "devMode": "proCode",   "npm": {},   "group": "component",   "category": "html",   "priority": 40,   "schema": {     "properties": [       {         "label": {           "zh_CN": "基础信息"         },         "description": {           "zh_CN": "基础信息"         },         "content": [           {             "property": "src",             "label": {               "text": {                 "zh_CN": "src"               }             },             "required": true,             "readOnly": false,             "disabled": false,             "cols": 12,             "widget": {               "component": "MetaInput",               "props": {}             },             "description": {               "zh_CN": ""             }           }         ]       }     ],     "events": {     }   },   "configure": {     "loop": true,     "condition": true,     "styles": true,     "isContainer": false,     "isModal": false,     "nestingRule": {       "childWhitelist": [],       "parentWhitelist": "",       "descendantBlacklist": "",       "ancestorWhitelist": ""     },     "isNullNode": false,     "isLayout": false,     "rootSelector": "",     "shortcuts": {       "properties": [         "text", "columns"       ]     },     "contextMenu": {       "actions": [         "create symbol"       ],       "disable": [         "copy",         "remove"       ]     }   },   "snippets": [     {       "name": {         "zh_CN": "iframe"       },       "icon": "input",       "screenshot": "",       "snippetName": "iframe",       "schema": {         "componentName": "iframe",         "props": {           "src": ""         }       }     }   ] }
// component
`

`
Step to reproduce
编写后，拖入编辑器，无法在编辑器选中
What is expected
No response
What is actually happening
No response
What is your project name
最新项目
Any additional comments (optional)
No response

#372

repo: opentiny/tiny-engine

license: MIT


text:
new Keycloak/keycloak Provider dose not work

Thank you for reporting an issue.
I made the upgrade from the old mrparkers/keycloak 4.4.0 to keycloak/keycloak 4.5.0
but i can not run the plan/apply
Based on this PR: https://github.com/opentofu/registry/pull/1356
Reproduce:

upgrade versions.tf:

terraform {
  required_providers {
    keycloak = {
      source = "keycloak/keycloak"
      version = "4.5.0"
    }
  }
}

run upgrade commands:

tofu state replace-provider mrparkers/keycloak keycloak/keycloak
# Successful

tofu init -upgrade
# Successful

tofu plan

Planning failed. OpenTofu encountered an error while generating this plan.

╷
│ Error: Missing required attribute
│
│   on provider["registry.opentofu.org/mrparkers/keycloak"] with no configuration line 1:
│   (source code not available)
│
│ The attribute "client_id" is required, but no definition was found.
╵
╷
│ Error: Missing required attribute
│
│   on provider["registry.opentofu.org/mrparkers/keycloak"] with no configuration line 1:
│   (source code not available)
│
│ The attribute "url" is required, but no definition was found.
╵

i have a file named: terraform.tf (same directory):
terraform {
  backend "s3" {
    ...
  }
}

provider "keycloak" {
  client_id     = var.terraform_client_id
  client_secret = var.terraform_client_secret
  url           = var.rhbk_base_url
}

OpenTofu Version
➜  tofu version
OpenTofu v1.8.7
on linux_amd64
+ provider registry.opentofu.org/hashicorp/external v2.3.4
+ provider registry.opentofu.org/hashicorp/null v3.2.3
+ provider registry.opentofu.org/hashicorp/time v0.12.1
+ provider registry.opentofu.org/keycloak/keycloak v4.5.0
+ provider registry.opentofu.org/mrparkers/keycloak v4.5.0

### OpenTofu Configuration Files

```hcl
# This file is maintained automatically by "tofu init".
# Manual edits may be lost in future updates.

provider "registry.opentofu.org/hashicorp/external" {
  version = "2.3.4"
  hashes = [
    "h1:saRbzhRhYh4urj+ARe8vIB0mlRspy6E/fPSyvwqjUW8=",
    "zh:0e5eb3513d6ad5cc3196799a6e413c6a9c0b642ba6d8f84fc11efa48f58358a4",
    "zh:1658beae42b4614d4009a3191710c86571ccf1dc526c4bac520a87ab701dd2e9",
    "zh:28d937c13e90c170fc1e4b726a9bcf113aade53b95b3eccd335cd9eaba8acff5",
    "zh:2ac19917bb83233f24391d4cbaf301bb6ec14013d3b7f93bdf64823280622daa",
    "zh:3263d1808fc5252d586a9aa98d89086c912f53e1a3dc43bc5306364b358f04fa",
    "zh:463469836637342495e22a936ef9ab3c8ab2fb47eb0fae09c346d63f3331af59",
    "zh:53398a27492cd11f61b2f24c2601c12f50c39da32b90fd25aed7011a1e25a225",
    "zh:5a44cfbcef52fd3c970144a69a934cab320bd3bb57939ae4682fc516783e2996",
    "zh:65edb579d9d0dac42e77728d81da6e85ea30d3fe8f2cb6e5db82602ee8afa17e",
    "zh:f2edd3027b7ae0d31a690fd5dcdcd22b467b4f1e045f84f2bc88289353ef9a5b",
  ]
}

provider "registry.opentofu.org/hashicorp/null" {
  version = "3.2.3"
  hashes = [
    "h1:LF8arSzHfhbyQSFtTMTYEqCM34klzrbAQBJMHYCs9d8=",
    "zh:1d57d25084effd3fdfd902eca00020b34b1fb020253b84d7dd471301606015ac",
    "zh:65b7f9799b88464d9c2ec529713b7f52ea744275b61a8dc86cdedab1b2dcb933",
    "zh:80d3e9c95b7b4ae7c54005cd127cae82e5c53d2b7023ef24c147337bac9dadd9",
    "zh:841b60c07683e4bf456799ccd718896fdafdcc2c49252ae09967f2e74d8c8a03",
    "zh:8fa1c592a9c78222e35713c6edb3f1f818a4c6f3524a30a209f0a7e919827b68",
    "zh:bb795cc1429e09466840c09d39a28edf1db5070b1ec76822fc1173906a264572",
    "zh:da1784818a89bea29dfe660632f0060a7a843e4e564d74435fbeca002b0f7d2a",
    "zh:f409bf21b1cdaa6dac47cd79806f3d93f67e9507fe4dbf33b0165335f53bc2e1",
    "zh:fbea7a1ff84b430ba9594698e93196d81d03e4036de3d1cafccb2a96d5b38581",
    "zh:fbf0c84663a7e85881388d7d71ac862184f05fbf2d17ecf76bc5d3d7503ea260",
  ]
}

provider "registry.opentofu.org/hashicorp/time" {
  version = "0.12.1"
  hashes = [
    "h1:PnOB6IAQJoYi/r3iUH7Hml2c2zFrIzHksQsrK3VPjSI=",
    "zh:50a9b67d5f5f42adbdb7712f67858aa64b5670070f6710751239b535fb48a4df",
    "zh:5a846fae035e363aed75b966d64a56f3489a38083e8407aaa656730437f53ed7",
    "zh:6767f1fc8a679b48eaa4cd114da0d8185fb3546375f3a0fb3728f10fa3dbc551",
    "zh:85d3da407c828bf057cbc0e86c75ef3d0f9f74a73c4ea1b4aef18e33f41092b1",
    "zh:9180721325139431112c638f5382a740ff219782f81d6346cdff5bccc418a43f",
    "zh:9ba9989f905a64db1409a9a57649549c89c7aedfb55ae399a7fa9411aafaadac",
    "zh:b3d9e7afb6a742e9be0541bc434b00d849fdfab0b4b859ceb0296c26c541af15",
    "zh:c87da712d718acd9dd03f544b020c320699cb29df197be4f74783e3c3d80fc17",
    "zh:cb1abe07638ef6d7b41d0e86dfb12d60a513aca3395a5da7191947f7459821dd",
    "zh:ecff2e823ef49eda03663fa8ee8bdc17d27cd419dbdacbf1719f38812dbf417e",
  ]
}

provider "registry.opentofu.org/keycloak/keycloak" {
  version     = "4.5.0"
  constraints = "4.5.0"
  hashes = [
    "h1:SaRSw74s//z4y2VybrIcx3GaIUQKcBcVGyYzhPVKq1g=",
    "zh:08c76d5000a2f8683577bf3fa5529584742e5f06bc06cf42ea8b05c94297cf7f",
    "zh:24ade48d62a67c65a64b425a23aa473eff0fdecae628a7272dbd027e7d1fb992",
    "zh:24c2c7d21f3e85256eed0f2601e9cbaf826867cf05c942f93d8c2a396cf3b1a3",
    "zh:2a4114f9f83f2c3286488773473bb67159dfd831b8b05076cfa5b54c84aa6111",
    "zh:3abbd8c4ec23b25a1083d4fee53f12c0b058906c87bb31d887d62dad354b3edf",
    "zh:5ed4fb36fb260b4af613e5e389710551cd6acec4b7b970de3dceb064d9e92036",
    "zh:718f6265f7cbefb72c65d32141c0e0816219b35dea3f978f2c9e441bc9f3b42b",
    "zh:72abedcdeccb82bfa5ea07fc54edd3d088fda9b3619d99f2dea81ba5b12a38e1",
    "zh:78c5a6cfc8789134f8f1c997bb8731395872ba0d4bc7f7df010e53ba52b92fe2",
    "zh:792206341f0ffcfad5b732fe938d93b911283088d7c2dc14be28ae8879fa9407",
    "zh:82ed201fe929d42b13725ae4e196b8842995a9ac261914b6721b2cf7c7c05a26",
    "zh:98ce3081a3a4998d793fd4ea01b386efa7076533aff0b055f93395955619ebfb",
    "zh:b91e4a911c30f0a5e929a34f9bbfc67cb8e5aa3b0a62633e4cfa44186ca10420",
    "zh:c39ac1504df522384186a446da485c906517c5f312ef4e321a6ad4c30b019e30",
    "zh:cbe2b76fc69f688500c0381160dbea6537add3d18cc7b622f81650a9c9af162d",
    "zh:e6b173a1e4ffa855d0a222c54e89efe0be648df3a29d39c66286132fa2e0a35e",
    "zh:eb7c90edaef4b97e86cb4b9ba8edfff49732f97eb60cf5acef4d790bed032bb3",
  ]
}

provider "registry.opentofu.org/mrparkers/keycloak" {
  version     = "4.5.0"
  constraints = ">= 4.4.0, < 5.0.0"
  hashes = [
    "h1:SaRSw74s//z4y2VybrIcx3GaIUQKcBcVGyYzhPVKq1g=",
    "zh:08c76d5000a2f8683577bf3fa5529584742e5f06bc06cf42ea8b05c94297cf7f",
    "zh:24ade48d62a67c65a64b425a23aa473eff0fdecae628a7272dbd027e7d1fb992",
    "zh:24c2c7d21f3e85256eed0f2601e9cbaf826867cf05c942f93d8c2a396cf3b1a3",
    "zh:2a4114f9f83f2c3286488773473bb67159dfd831b8b05076cfa5b54c84aa6111",
    "zh:3abbd8c4ec23b25a1083d4fee53f12c0b058906c87bb31d887d62dad354b3edf",
    "zh:5ed4fb36fb260b4af613e5e389710551cd6acec4b7b970de3dceb064d9e92036",
    "zh:718f6265f7cbefb72c65d32141c0e0816219b35dea3f978f2c9e441bc9f3b42b",
    "zh:72abedcdeccb82bfa5ea07fc54edd3d088fda9b3619d99f2dea81ba5b12a38e1",
    "zh:78c5a6cfc8789134f8f1c997bb8731395872ba0d4bc7f7df010e53ba52b92fe2",
    "zh:792206341f0ffcfad5b732fe938d93b911283088d7c2dc14be28ae8879fa9407",
    "zh:82ed201fe929d42b13725ae4e196b8842995a9ac261914b6721b2cf7c7c05a26",
    "zh:98ce3081a3a4998d793fd4ea01b386efa7076533aff0b055f93395955619ebfb",
    "zh:b91e4a911c30f0a5e929a34f9bbfc67cb8e5aa3b0a62633e4cfa44186ca10420",
    "zh:c39ac1504df522384186a446da485c906517c5f312ef4e321a6ad4c30b019e30",
    "zh:cbe2b76fc69f688500c0381160dbea6537add3d18cc7b622f81650a9c9af162d",
    "zh:e6b173a1e4ffa855d0a222c54e89efe0be648df3a29d39c66286132fa2e0a35e",
    "zh:eb7c90edaef4b97e86cb4b9ba8edfff49732f97eb60cf5acef4d790bed032bb3",
  ]
}

Hey @abstractionfactory okay i wil do that. i was not sure, if this is an issue comming from the REgestry or from tofu.
thanks for pointing this out.

repo: opentofu/registry


text:
@Traced annotation

I was wondering if it was ever discuss to have a @Traced method-level annotation?
It would allow to easily start/stop a span around a method (using AOP). We could even capture the args and return value at some point.
Something like this:
@Target({ ElementType.METHOD, ElementType.ANNOTATION_TYPE })
@Retention(RetentionPolicy.RUNTIME)
public @interface Traced {

    boolean withActiveSpanOnly() default true;

    String component() default "java-traced-annotation";

    String operationName() default "";

}

Apache SkyWalking offers this: https://github.com/apache/incubator-skywalking/blob/master/apm-application-toolkit/apm-toolkit-trace/src/main/java/org/apache/skywalking/apm/toolkit/trace/Trace.java
And it could be similar to the @Timed annotation from DropWizard http://metrics.dropwizard.io/3.1.0/apidocs/com/codahale/metrics/annotation/Timed.html

Microprofile has a similar annotation https://github.com/eclipse/microprofile-opentracing/blob/master/spec/src/main/asciidoc/microprofile-opentracing.asciidoc#321-the-traced-annotation
Sleuth has a similar annotations https://github.com/eclipse/microprofile-opentracing/blob/master/spec/src/main/asciidoc/microprofile-opentracing.asciidoc#321-the-traced-annotation and https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/annotation/SpanTag.java

I think this should be at the OT-Java level, as it could potentially be used by a lot of instrumentation libraries (CDI comes to mind as well).

@jpkrohling I agree it would be valuable to have the annotation directly inside the Java SDK.
I could send the PR today to start the discussion

replace component with tags
	Tag[] tags() default {};

public @interface Tag {

	String name();

	String value();

}

It's better tag value supports SPEL.

@ledor473 could you please describe use-cases when you are using this annotation?

Most of our use of the annotation is to easily create a span around a project-specific feature. The fact that it's an annotation makes it super easy to add valuable traces. You don't have to modify every function with a try-with-resources directly in the function.
Most of the usage are to highlight what is happening between the inbound call and the underlying database or the outgoing call.
Here's some examples:

To show which implementation of a datastore was picked for that trace
To differentiate between 2 different code path (feature flagged for example)
Create a span around a function that access to the filesystem

Hi,
I'm currently struggling with the same issue. Adding an @Traced annotation would be extremely helpful, because I don't want to keep writing the same try-with-resources, including the additional indentation. This allows me to keep focusing on business logic, instead of cross-cutting concerns.
Can anybody tell me if this is going to be implemented or not?

@nielsvn92 I can look into rebasing the code from https://github.com/opentracing-contrib/java-spring-cloud/pull/184 and re-submit it.

I'm looking for the same feature. It would be nice to not mess with business logic code.

I also looked for a similar feature. Why #184 has never been merged?

I'd be happy to re-submit if there's a desire to merge it. @pavolloffay let me know if you have some time to review and merge.

I am happy to review/merge if it's not controversial.

Any plans when this feature will be available in the release

Guys, do you need any help with the review or implementation to get this feature released?

@ledor473 sorry for the direct ping - great work on the PR. Is there anything in particular missing or blocking its merge?

@ledor473 sorry for the direct ping - great work on the PR. Is there anything in particular missing or blocking its merge?

@pavolloffay / @geoand / @jpkrohling would have to review, merge, and release it.
Sadly it feels like the project isn't very active because the issue was created almost 3 years ago and it caused us to created an internal fork

@pavolloffay / @geoand / @jpkrohling would have to review, merge, and release it.
Sadly it feels like the project isn't very active because the issue was created almost 3 years ago and it caused us to created an internal fork

Hey @ledor473.
We never got notified about your PR. I'll have a look

Hey @ledor473.
We never got notified about your PR. I'll have a look

authors: duclm2609 geoand jpkrohling ledor473 nielsvn92 orange-buffalo pavolloffay quaff rafabene ryanlewis sumantmunjalyahoo

repo: opentracing-contrib/java-spring-cloud


text:
Adopt FlaskScopeManager

These changes introduce an optional scope manager using Flask's stack, as originally proposed in  https://github.com/opentracing/opentracing-python/pull/105.
This is helpful for ensuring that the active span obtained anywhere in a view function's call chain is guaranteed to be associated with request as provided by werkzeug's context locals.

@carlosalberto

authors: analytically rmfitzpatrick

repo: opentracing-contrib/python-flask


text:
🛑 [CN] OpenUPM API /packages/recent is down

In 6d507e3, [CN] OpenUPM API /packages/recent (https://api.openupm.cn/packages/recent) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM API /packages/recent is back up in 070f7da after 7 minutes.

repo: openupm/upptime-openupmcn


text:
🛑 [CN] OpenUPM Website Docs is down

In dc1b5b9, [CN] OpenUPM Website Docs (https://openupm.cn/docs/) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website Docs is back up in f600fb2 after 8 minutes.


text:
🛑 [CN] OpenUPM Website is down

In bd07256, [CN] OpenUPM Website (https://openupm.cn) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Website is back up in d50892a after 8 minutes.


text:
🛑 [CN] OpenUPM Registry /package-name is down

In 6bc16f6, [CN] OpenUPM Registry /package-name (https://package.openupm.cn/com.littlebigfun.addressable-importer) was down:

HTTP code: 0
Response time: 0 ms

Resolved: [CN] OpenUPM Registry /package-name is back up in 2651b3b after 6 minutes.


text:
Inquiry on the use of EfficientAD

Thank you very much for sharing this great deep learning library for the anomaly detection.
I am trying to use EfficientAD with my original dataset, but I have some trouble to use it.
I thought EfficientAD is an unsupervised learning model and the input data of this model is normal images not abnormal images.
However, when I use my own dataset without writing abnormal_dir on the config.yaml, I received the following error.
    raise ConfigKeyError(f"Missing key {key!s}")
omegaconf.errors.ConfigAttributeError: Missing key abnormal_dir
    full_key: dataset.abnormal_dir
    object_type=dict

As for unsupervised learning models, I thought abnormal_dir which probably contain abnormal images is not necessary.
I would appreciate it if you could let me know on the followings.

Could you tell me if the input data of EfficientAD is just the normal images not abnormal images.

Since the default "task" in the config.yaml of EfficientAD is segmentation, is not the output of EfficientAD the anomaly score of each patch image?

Are mask images necessary as the input data for the segmentation task of EfficientAD?

Thank you.

Hi @Akihiko0123, glad that you like the library!
Can you share your config file or python code to run the model? Abnormal directory is used to run the validation and test to get performance metrics. They are not needed during training.

Hi @samet-akcay,
I appreciate you for your prompt reply!
I understand that Abnormal directory is used to run the validation and test to get performance metrics.
In that case, should I prepare many abnormal data for the validation and test ?
I thought the abnormal images are used only during inference phase to see the result.
My config file is as follows.
dataset:
  name: original
  format: folder
  path: ../test_codes_anogan/
  normal_dir: train_sample # name of the folder containing normal images.
  abnormal_dir: null # name of the folder containing abnormal images.
  normal_test_dir: null # name of the folder containing normal test images.
  task: segmentation
  mask: null
  extensions: null
  train_batch_size: 1
  eval_batch_size: 16
  num_workers: 8
  image_size: 256 # dimensions to which images are resized (mandatory)
  center_crop: null # dimensions to which images are center-cropped after resizing (optional)
  normalization: imagenet # data distribution to which the images will be normalized: [none, imagenet]
  transform_config:
    train: null
    eval: null
  test_split_mode: none # options: [from_dir, synthetic]
  test_split_ratio: 0.2 # fraction of train images held out testing (usage depends on test_split_mode)
  val_split_mode: same_as_test # options: [same_as_test, from_test, synthetic]
  val_split_ratio: 0.5 # fraction of train/test images held out for validation (usage depends on val_split_mode)

model:
  name: efficient_ad
  teacher_out_channels: 384
  model_size: small # options: [small, medium]
  lr: 0.0001
  weight_decay: 0.00001
  padding: false
  pad_maps: true # relevant for "padding: false", see EfficientAd in lightning_model.py
  normalization_method: min_max # options: [null, min_max, cdf] # min_max...最大1最小0に正規化

metrics:
  image:
    - F1Score
    - AUROC
  pixel:
    - F1Score
    - AUROC
  threshold:
    method: adaptive #options: [adaptive, manual]
    manual_image: null
    manual_pixel: null

visualization:
  show_images: False # show images on the screen
  save_images: True # save images to the file system
  log_images: False # log images to the available loggers (if any)
  image_save_path: null # path to which images will be saved
  mode: full # options: ["full", "simple"]

project:
  seed: 42
  path: ./results

logging:
  logger: [wandb] # options: [comet, tensorboard, wandb, csv] or combinations.
  log_graph: true # Logs the model graph to respective logger.

optimization:
  export_mode: null # options: torch, onnx, openvino
trainer:
  enable_checkpointing: true
  default_root_dir: null
  gradient_clip_val: 0
  gradient_clip_algorithm: norm
  num_nodes: 1
  devices: 1
  enable_progress_bar: true
  overfit_batches: 0.0
  track_grad_norm: -1
  check_val_every_n_epoch: 1
  fast_dev_run: false
  accumulate_grad_batches: 1
  max_epochs: 200
  min_epochs: null
  max_steps: 160000
  min_steps: null
  max_time: null
  limit_train_batches: 1.0
  limit_val_batches: 1.0
  limit_test_batches: 1.0
  limit_predict_batches: 1.0
  val_check_interval: 1.0
  log_every_n_steps: 50
  accelerator: auto # <"cpu", "gpu", "tpu", "ipu", "hpu", "auto">
  strategy: null
  sync_batchnorm: false
  precision: 32
  enable_model_summary: true
  num_sanity_val_steps: 0
  profiler: null
  benchmark: false
  deterministic: false
  reload_dataloaders_every_n_epochs: 0
  auto_lr_find: false
  replace_sampler_ddp: true
  detect_anomaly: false
  auto_scale_batch_size: false
  plugins: null
  move_metrics_to_cpu: false
  multiple_trainloader_mode: max_size_cycle

If there are items should be fixed, I would appreciate it if you could point them out.

Thanks. I see that you are setting the validation set in your config.
  test_split_mode: none # options: [from_dir, synthetic]
  test_split_ratio: 0.2 # fraction of train images held out testing (usage depends on test_split_mode)
  val_split_mode: same_as_test # options: [same_as_test, from_test, synthetic]
  val_split_ratio: 0.5 # fraction of train/test images held out for validation (usage depends on val_split_mode)

It is same_as_test. Despite test_split_mode being None, it probably fails, mainly due to validation split not being a None value
If you set val_split_mode to null, it should work. However, note that this will not run the adaptive thresholding and normalization properly. So you might need to find a manual threshold on your own.
Hope that helps.

repo: openvinotoolkit/anomalib


text:
CVAT doesn't export instance annotations in the correct format

Hi there. I'm a big fan of using the openvino model assisted annotation. So I need to train a MaskRCNN and convert it to openvino then upload the model to cvat (have done it for faster rcnn). But to train MaskRCNN you need a TFrecord file and for that you need the XMLS( in the correct format) with the bounding box coordinates of the polygons and also the PNG masks. When I dump annotations in the sementation mask format I don't get the XMLS. When I export in other format coco it has a json file which has the bbox co-ords but that is not what's needed.. We need an xml per image not one big Json file in the wrong format.
CVAT doesn't export the write annotation files needed to (convert to tfrecord) and train maskRCNN.
I'm Running CVAT in docker. Using a slightly older version - just before serverless functions were introduced.
Cheers,
Sam

Hi, have you tried exporting as PASCAL VOC?

Yes and since it’s polygon annotations, when I export as pascal VOC it Doesn’t output any annotations. Just empty folders

From: Maxim Zhiltsov notifications@github.com
Sent: Friday, September 25, 2020 11:51:01 PM
To: openvinotoolkit/cvat cvat@noreply.github.com
Cc: Sam Davidson sjd166@uclive.ac.nz; Author author@noreply.github.com
Subject: Re: [openvinotoolkit/cvat] CVAT doesn't export instance annotations in the correct format (#2223)
Hi, have you tried exporting as PASCAL VOC?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/openvinotoolkit/cvat/issues/2223#issuecomment-698885585, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK7R4HCOT7MUR6XQQQAIYYDSHR72LANCNFSM4RZMO7MQ.

Ok, makes sense. What about TFRecord format?

I dont think the TFRECORD export will work. I exported Bbox tfrecord once and they didn’t work. Even if it does.. I need to split it into train,Val, test which is impossible.

From: Maxim Zhiltsov notifications@github.com
Sent: Saturday, September 26, 2020 8:38:24 PM
To: openvinotoolkit/cvat cvat@noreply.github.com
Cc: Sam Davidson sjd166@uclive.ac.nz; Author author@noreply.github.com
Subject: Re: [openvinotoolkit/cvat] CVAT doesn't export instance annotations in the correct format (#2223)
Ok, makes sense. What about TFRecord format?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/openvinotoolkit/cvat/issues/2223#issuecomment-699460544, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK7R4HHH4NNAZIDBM6DVYH3SHWSABANCNFSM4RZMO7MQ.

@zhiltsov-max it turns out that exporting Polygon annotations as COCO and using create_coco_tf_record.py with the instances_default.json file, include_masks=True, from CVAT enables us to train a TF1OD mask RCNN (I believe).

authors: davodogster zhiltsov-max

repo: openvinotoolkit/cvat


text:
Possible memory leaks can lead to server crash on dataset export

My actions before raising this issue

[ ] Read/searched the docs
[ ] Searched past issues

Expected Behaviour

Current Behaviour

Test on a large video with chunks and cache enabled.

Run the code snippet with python manage.py shell
Hit ctrl+C at some point
check top output

There should not be any extra memory allocated, but after few runs over a video task with 3k frames I have 5-7 gb of allocated memory. Gc tells it knows nothing about these allocations.
import gc
import tracemalloc
tracemalloc.start(10)
try:
    from cvat.apps.engine.models import Task
    from cvat.apps.engine.frame_provider import FrameProvider
    fp = FrameProvider(Task.objects.get(pk=39).data) # a large video task

    while True:
        for i, f in enumerate(fp.get_frames(out_type=fp.Type.NUMPY_ARRAY)):
            pass

except:
    del fp
    del f
    snapshot = tracemalloc.take_snapshot()
    gc.collect()

Env:

Python 3.6.5
absl-py==0.8.1
alabaster==0.7.12
appdirs==1.4.4
asgiref==3.2.10
asn1crypto==0.24.0
astor==0.8.0
astroid==2.4.2
astunparse==1.6.3
atpublic==2.0
attrs==19.3.0
autopep8==1.5.3
av==8.0.2
Babel==2.8.0
bandit==1.6.2
bcrypt==3.1.7
cached-property==1.5.1
cachetools==4.0.0
certifi==2020.6.20
cffi==1.12.3
chardet==3.0.4
click==7.1.2
colorama==0.4.3
commonmark==0.9.1
configobj==5.0.6
coreapi==2.3.3
coreschema==0.0.4
coverage==5.2.1
coveralls==2.1.1
croniter==0.3.30
cryptography==2.7
cycler==0.10.0
dataclasses==0.7
-e git+https://github.com/openvinotoolkit/datumaro.git@3157e749f304635775f10a46b7b15ef09d7b4374#egg=datumaro
ddt==1.2.1
decorator==4.4.0
defusedxml==0.6.0
dictdiffer==0.8.1
diskcache==4.1.0
distro==1.5.0
dj-pagination==2.5.0
Django==3.1.1
django-allauth==0.42.0
django-appconf==1.0.4
django-auth-ldap==2.2.0
django-cacheops==5.0.1
django-compressor==2.4
django-cors-headers==3.5.0
django-extensions==3.0.6
django-filter==2.3.0
django-rest-auth==0.9.5
django-revproxy==0.10.0
django-rq==2.3.2
django-sendfile==0.3.11
django-silk==4.0.1
djangorestframework==3.11.1
docker==3.7.3
docker-compose==1.24.1
docker-pycreds==0.4.0
dockerpty==0.4.1
docopt==0.6.2
docutils==0.16
dpath==2.0.1
drf-yasg==1.17.1
dvc==1.7.2
EasyProcess==0.3
editdistance==0.5.3
entrypoint2==0.2.1
fakeredis==1.4.1
ffmpy==0.2.2
flatten-dict==0.3.0
flufl.lock==3.2
funcy==1.14
furl==2.1.0
future==0.18.2
gast==0.3.3
gitdb==4.0.5
gitdb2==3.0.2
GitPython==3.1.3
google-auth==1.11.0
google-auth-oauthlib==0.4.1
google-pasta==0.1.8
gprof2dot==2019.11.30
grandalf==0.6
grpcio==1.24.1
h5py==2.10.0
idna==2.7
imageio==2.6.1
imagesize==1.2.0
imgaug==0.4.0
importlib-metadata==1.7.0
inflection==0.3.1
isort==4.3.21
itypes==1.1.0
Jinja2==2.10.3
joblib==0.16.0
jsonpath-ng==1.5.2
jsonschema==2.6.0
Keras==2.4.2
Keras-Applications==1.0.8
Keras-Preprocessing==1.1.0
kiwisolver==1.1.0
lazy-object-proxy==1.5.1
lxml==4.4.1
Markdown==3.2.2
MarkupSafe==1.1.1
matplotlib==3.3.1
mccabe==0.6.1
mod-wsgi==4.7.1
nanotime==0.5.2
networkx==2.3
nibabel==3.1.1
nose==1.3.7
numpy==1.17.5
oauthlib==3.1.0
opencv-python==4.4.0.42
opencv-python-headless==4.2.0.34
opt-einsum==3.1.0
orderedmultidict==1.0.1
packaging==20.3
paramiko==2.6.0
pascal-voc-writer==0.1.4
pathlib2==2.3.5
pathspec==0.8.0
patool==1.12
pbr==5.4.5
pdf2image==1.14.0
Pillow==7.2.0
pipdeptree==0.13.2
piprot==0.9.11
ply==3.11
protobuf==3.10.0
psycopg2-binary==2.8.5
py-cpuinfo==4.0.0
pyasn1==0.4.7
pyasn1-modules==0.2.7
pycocotools==2.0.0
pycodestyle==2.6.0
pycparser==2.19
pydicom==2.0.0
pydot==1.4.1
Pygments==2.6.1
pygtrie==2.3.2
pyhash==0.9.3
pylint==2.6.0
pylint-django==2.3.0
pylint-plugin-utils==0.6
PyNaCl==1.3.0
pyparsing==2.4.2
pypi-kenlm==0.1.20190403
python-dateutil==2.8.0
python-ldap==3.3.1
python-logstash==0.4.6
python3-openid==3.1.0
pytz==2020.1
pyunpack==0.2.1
PyWavelets==1.0.3
PyYAML==5.3.1
rcssmin==1.0.6
redis==3.5.3
requests==2.24.0
requests-futures==1.0.0
requests-oauthlib==1.2.0
rich==6.2.0
rjsmin==1.1.0
rope==0.17.0
rq==1.5.1
rq-scheduler==0.10.0
rsa==4.0
rstcheck==3.3.1
ruamel.yaml==0.16.5
ruamel.yaml.clib==0.2.0
rules==2.2
scikit-image==0.15.0
scikit-learn==0.23.2
scipy==1.4.1
sentencepiece==0.1.91
Shapely==1.7.1
shortuuid==1.0.1
shtab==1.3.1
six==1.15.0
smmap==3.0.4
smmap2==2.0.5
snakeviz==2.1.0
snowballstemmer==2.0.0
sortedcontainers==2.1.0
Sphinx==3.2.1
sphinxcontrib-applehelp==1.0.2
sphinxcontrib-devhelp==1.0.2
sphinxcontrib-htmlhelp==1.0.3
sphinxcontrib-jsmath==1.0.1
sphinxcontrib-qthelp==1.0.3
sphinxcontrib-serializinghtml==1.1.4
sqlparse==0.3.1
stevedore==3.2.0
tabulate==0.8.7
tensorboard==2.2.2
tensorboard-plugin-wit==1.7.0
tensorboardX==1.8
tensorflow==2.2.0
tensorflow-estimator==2.2.0
termcolor==1.1.0
texttable==0.9.1
threadpoolctl==2.1.0
tokenizers==0.8.1
toml==0.10.1
torch==1.5.1
torchvision==0.6.1
tornado==6.0.3
tqdm==4.49.0
typed-ast==1.4.0
typing-extensions==3.7.4.3
uritemplate==3.0.0
urllib3==1.24.3
voluptuous==0.11.7
websocket-client==0.56.0
Werkzeug==1.0.1
wrapt==1.12.1
yamlloader==0.5.5
zc.lockfile==2.0
zipp==3.1.0

Your Environment

Git hash commit (git log -1): f2c84a2653fc601c90bcb84154f0fe7a6be937df
Operating System and version (e.g. Linux, Windows, MacOS): Ubuntu 18.04

Next steps
You may join our Gitter channel for community support.

@kirill-sizov , is it something similar to the issue which you are working on?

Fixed in #6501

authors: azhavoro nmanovic zhiltsov-max


text:
New lp tests

New LP tests
Fix outputs counting for amr_compute::MemoryManger in case of ArmNoOP on output
Fixed QuantizationInfo storing in ArmQuantize creation pass

@allnes Please have a look


text:
kubectl stops when restarting VM

Hi everyone,
I'm trying to use ovn-kubernetes via vagrant in ubuntu 18 and following this tutorial: https://github.com/openvswitch/ovn-kubernetes/blob/master/vagrant/README.md
Everything goes fine, from installation to pod creation but when I restart the VM and try to use kubectl I got: The connection to the server localhost:8080 was refused - did you specify the right host or port?
can anybody help me? after restarting the VM do I need to start some service?

@alissonpmedeiros
The vagrant is not designed to handle restarts. It is just for someone to get familiar with OVN installation procedure. It starts kubernetes daemons without the help of startup scripts. i.e., it does:
https://github.com/openvswitch/ovn-kubernetes/blob/master/vagrant/provisioning/setup-master.sh#L138
So after a restart, one will have to re-run those scripts.

Hi @shettyg , thanks for your help.
I realized that in master and minion I need to restart some services and I created a script to restart these services after restarting a VM.
The activation of the docker container (google container) must be done manually in the master, that is, through the container ID, which must be placed in the script. Additionally, the IPs on the master and the minion should be placed in the script as well. I hope you can help someone else.
initialize_master_services.sh
`#!/bin/bash
public ip from master node(k8s-master) defined in vm_config.conf.yml
MASTER1=10.10.0.11
PROTOCOL="ssl"
OVERLAY_IP=$MASTER1
echo "starting google containers..."
sudo docker container start 6f5334bce31f
sudo sh -c 'echo "PATH=$PATH:$HOME/k8s/server/kubernetes/server/bin" >> /etc/profile'
pushd k8s/server/kubernetes/server/bin
echo "Starting kube-apiserver ..."
nohup sudo ./kube-apiserver --service-cluster-ip-range=172.16.1.0/24
--address=0.0.0.0
--etcd-servers=http://127.0.0.1:4001
--advertise-address=$MASTER1
--v=2 2>&1 0<&- &>/dev/null &
Wait till kube-apiserver starts up
while true; do
./kubectl get nodes
if [ $? -eq 0 ]; then
break
fi
echo "waiting for kube-apiserver to start...."
sleep 1
done
echo "Starting kube-controller-manager ..."
nohup sudo ./kube-controller-manager --master=127.0.0.1:8080 --v=2 2>&1 0<&- &>/dev/null &
echo "Starting kube-scheduler ..."
nohup sudo ./kube-scheduler --master=127.0.0.1:8080 --v=2 2>&1 0<&- &>/dev/null &
popd
cat << KUBECONFIG >> ~/kubeconfig.yaml
apiVersion: v1
clusters:

cluster:
server: http://localhost:8080
name: default-cluster
cluster:
server: http://localhost:8080
name: local-server
cluster:
server: http://localhost:8080
name: ubuntu
contexts:
context:
cluster: ubuntu
user: ubuntu
name: ubuntu
current-context: ubuntu
kind: Config
preferences: {}
users:
name: ubuntu
user:
password: p1NVMZqhOOOqkWQq
username: admin
KUBECONFIG

pushd k8s/server/kubernetes/server/bin
nohup sudo ./kubelet --kubeconfig $HOME/kubeconfig.yaml
--v=2 --address=0.0.0.0
--fail-swap-on=false
--runtime-cgroups=/systemd/system.slice
--kubelet-cgroups=/systemd/system.slice
--enable-server=true --network-plugin=cni
--cni-conf-dir=/etc/cni/net.d
--cni-bin-dir="/opt/cni/bin/" >/tmp/kubelet.log 2>&1 0<&- &
popd
if [ $PROTOCOL = "ssl" ]; then
SSL_ARGS="-nb-server-privkey /etc/openvswitch/ovnnb-privkey.pem
-nb-server-cert /etc/openvswitch/ovnnb-cert.pem
-nb-server-cacert /vagrant/pki/switchca/cacert.pem
-sb-server-privkey /etc/openvswitch/ovnsb-privkey.pem
-sb-server-cert /etc/openvswitch/ovnsb-cert.pem
-sb-server-cacert /vagrant/pki/switchca/cacert.pem
-nb-client-privkey /etc/openvswitch/ovncontroller-privkey.pem
-nb-client-cert /etc/openvswitch/ovncontroller-cert.pem
-nb-client-cacert /etc/openvswitch/ovnnb-ca.cert
-sb-client-privkey /etc/openvswitch/ovncontroller-privkey.pem
-sb-client-cert /etc/openvswitch/ovncontroller-cert.pem
-sb-client-cacert /etc/openvswitch/ovnsb-ca.cert"
fi
ovn_nb="$PROTOCOL://$OVERLAY_IP:6641"
ovn_sb="$PROTOCOL://$OVERLAY_IP:6642"
nohup sudo ovnkube -k8s-kubeconfig $HOME/kubeconfig.yaml -net-controller -loglevel=4
-k8s-apiserver="http://$OVERLAY_IP:8080"
-logfile="/var/log/openvswitch/ovnkube.log"
-init-master="k8smaster" -cluster-subnet="192.168.0.0/16"
-init-node="k8smaster"
-service-cluster-ip-range=172.16.1.0/24
-nodeport
-k8s-token="test"
-nb-address="$ovn_nb"
-sb-address="$ovn_sb"
-init-gateways -gateway-localnet
${SSL_ARGS} 2>&1 &>/dev/null &
echo "END SCRIPT!"`
initialize_node_services.sh
`#!/bin/bash
PROTOCOL="ssl"
MASTER1=10.10.0.12
GW_IP=10.10.0.1
Install certificates
pushd /etc/openvswitch
sudo ovs-pki req ovncontroller
sudo ovs-pki -b -d /vagrant/pki sign ovncontroller switch
popd
Start k8s daemons
pushd k8s/server/kubernetes/server/bin
echo "Starting kubelet ..."
nohup sudo ./kubelet --kubeconfig $HOME/kubeconfig.yaml
--v=2 --address=0.0.0.0
--fail-swap-on=false
--runtime-cgroups=/systemd/system.slice
--kubelet-cgroups=/systemd/system.slice
--enable-server=true --network-plugin=cni
--cni-conf-dir=/etc/cni/net.d
--cni-bin-dir="/opt/cni/bin/" >/tmp/kubelet.log 2>&1 0<&- &
popd
Initialize the minion and gateway.
if [ $PROTOCOL = "ssl" ]; then
SSL_ARGS="-nb-client-privkey /etc/openvswitch/ovncontroller-privkey.pem
-nb-client-cert /etc/openvswitch/ovncontroller-cert.pem
-nb-client-cacert /etc/openvswitch/ovnnb-ca.cert
-sb-client-privkey /etc/openvswitch/ovncontroller-privkey.pem
-sb-client-cert /etc/openvswitch/ovncontroller-cert.pem
-sb-client-cacert /etc/openvswitch/ovnsb-ca.cert"
fi
ovn_nb="$PROTOCOL://$MASTER1:6641"
ovn_sb="$PROTOCOL://$MASTER1:6642"
nohup sudo ovnkube -k8s-kubeconfig $HOME/kubeconfig.yaml -loglevel=4
-logfile="/var/log/openvswitch/ovnkube.log"
-k8s-apiserver="http://:8080$MASTER1"
-init-node="$MINION_NAME"
-nodeport
-nb-address="$ovn_nb"
-sb-address="$ovn_sb"
${SSL_ARGS}
-k8s-token="test"
-init-gateways -gateway-interface=enp0s8 -gateway-nexthop="$GW_IP"
-service-cluster-ip-range=172.16.1.0/24
-cluster-subnet="192.168.0.0/16" 2>&1 &>/dev/null &
sleep 10
echo "END SCRIPT"`

I think we can close this issue, since the problem was solved and the scripts to restart the services in master and minion are available.

authors: alissonpmedeiros shettyg

repo: openvswitch/ovn-kubernetes


text:
fix: add custom notifications dependency

Summary of Changes
This PR #1211  moved custom notifications from default config to be DI injected but it missed adding the dependency in the app so the sample app crashes on start for missing dependency

[x] All commits contain a DCO Signed-off-by line (we use the DCO GitHub app to enforce this);
[x] Updated LICENSE-3RD-PARTY.md for any added dependencies or vendored components;
[x] Updated documentation as needed for changed code and new or modified features;
[x] Added sufficient tests so that overall code coverage is not reduced.

If you have any questions to any of the points above, just submit and ask! This checklist is here to help you, not to deter you from contributing!
Pro Tip 🤓

Read our contribution guide at least once; it will save you a few review cycles!
Your PR will likely not be reviewed until all the above boxes are checked and all automated tests have passed.

PR template adapted from the Python attrs project.

@wadeking98 I see you solved this bug in the PR #1224. Please confirm to close this PR

Confirmed, this has been fixed, thanks for your work though

repo: openwallet-foundation/bifold-wallet


text:
Requesting Dipika for Daniel

Requesting Dipika Bhattacharya for Mozilla with the departure of Daniel Beck

What about moving Daniel to members emeriti?

Any which way works for me :) Just waiting on @ddbeck

repo: openwebdocs/project


text:
IPv6?

Hi i try to add rules for zerotier, extract ip from "host root.zerotier.com"
        # ZeroTier
        - "iptables -A INPUT -i zt+ -j ACCEPT"
        - "iptables -A OUTPUT -o zt+ -j ACCEPT"
        - "iptables -A OUTPUT -m owner --uid-owner 998 -j ACCEPT"
        - "iptables -A OUTPUT -p udp -d  104.194.8.134 -j ACCEPT"
        - "iptables -A OUTPUT -p udp -d  103.195.103.66 -j ACCEPT"
        - "iptables -A OUTPUT -p udp -d  50.7.252.138 -j ACCEPT"
        - "iptables -A OUTPUT -p udp -d  84.17.53.155 -j ACCEPT"
        - "iptables -A OUTPUT -p udp -d  107.170.197.14 -j ACCEPT"
        - "ip6tables -A OUTPUT -p udp -d  2605:9880:200:1200:30:571:e34:51 -j ACCEPT"
        - "ip6tables -A OUTPUT -p udp -d  2605:9880:400:c3:254:f2bc:a1f7:19 -j ACCEPT"
        - "ip6tables -A OUTPUT -p udp -d  2001:49f0:d0db:2::2 -j ACCEPT"
        - "ip6tables -A OUTPUT -p udp -d  2604:a880:1:20::200:e001 -j ACCEPT"
        - "ip6tables -A OUTPUT -p udp -d  2a02:6ea0:d405::9993 -j ACCEPT"

The role create ruoles for IPv4 bat no for IPv6

Hi @mikysal78, I think that for making ipv6 work we have to make some changes, we use iptables-save, which stores rules two different files for ipv4 and ipv6, but we have focused on ipv4 only in this role.


text:
Use probe-rs instead of cargo embed

I've taken a shot at removing cargo embed and using probe-rs instead. #298
It's working using cargo run --target="thumbv7em-none-eabihf"
Additionally, I've switched to using defmt in place of cortex_m_semihosting::hprintln. If this change is undesirable, please let me know and I can revert it.
However, I encountered an issue: I couldn't get the tests to work with QEMU, as my computer gets stuck on every test. I tried running older commits, but nothing seems to work. Does cargo run with the default target work for you?
I'm marking this as a draft so we can resolve the QEMU issue before merging.
Thanks!

Thanks for this PR!
Replacing hprintln with defmt is a good thing IMO.
Do we still need (defmt-)rtt when we have defmt?
As for the QEMU issue, I will test it tomorrow morning (although run-example-on-qemu passed on CI, so I think it will be fine).

FYI, will test tomorrow instead since I cannot compile the psa backend in my M1 machine.

If replacing hprintln with defmt is fine, I will update this PR from draft to ready for review!

Do we still need defmt-rtt when we have defmt?

Yes, without defmt-rtt I was getting a bunch of linking issues like:
rust-lld: error: undefined symbol: _defmt_acquire
rust-lld: error: undefined symbol: _defmt_release
rust-lld: error: undefined symbol: _defmt_write

I found a issue that the solution was to keep the use defmt_rtt as _; to add a global logger
Let me know how the QEMU test goes!

I tried here, and I it indeeds gets stuck at
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.83s
     Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel /home/gfedrech/Developer/inria/dev/lakers-FORK/target/thumbv7m-none-eabi/debug/lakers-no_std`
Timer with period zero, disabling

On the other hand, the version on main prints:
$ cargo run  --no-default-features --features="crypto-psa" --release
    Finished `release` profile [optimized] target(s) in 4.36s
     Running `qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel /home/gfedrech/Developer/inria/dev/lakers-FORK/target/thumbv7m-none-eabi/release/lakers-no_std`
Timer with period zero, disabling
Hello, lakers!
Test test_new_initiator passed.
Test test_p256_keys passed.
Test test_prepare_message_1 passed.
Test test_handshake passed.
All tests passed.

(although I just realised that the QEMU version doesn't work without the --release flag, even on main).

Have you tried using defmt-semihosting as mentioned here? It seems it should be used for testing with QEMU.

@geonnave Thanks for the defmt-semihosting suggestion. I tried it out, but it appears that in addition to adding defmt-semihosting, I need to integrate a printer, a decoder, and a parser to properly process and display the data from QEMU.
This is how I understood they do in their example. Without this printer/decoder/parser combo, the log output appears as gibberish.
Because of this, I reverted to using use cortex_m_semihosting::hprintln as info; for the QEMU case and updated the README to reflect these changes.
Let me know if you need any further adjustments!

Thanks, left an editorial comment. Can you also please update the relevant section in the main README?
Feel free to add me as collaborator in your fork, this way I can also push some changes when needed (like updating the README).

I also just noticed, could you rebase and use the scope: description pattern in the commit messages? Just to keep the same pattern as the rest of the commits. (basically just add the example:  prefix to all commits)

I also just noticed, could you rebase and use the scope: description pattern in the commit messages? Just to keep the same pattern as the rest of the commits. (basically just add the example:  prefix to all commits)

Sorry about that! I didn't knew you guys were using conventional commit messages. I've rebased the branch and updated the commit messages. Thanks for the heads up!

authors: WilliamTakeshi geonnave

repo: openwsn-berkeley/lakers


text:
RISC-V: Value mismatch error after LLVM-integration

The failure is here: https://github.com/openxla/iree/actions/runs/4471762535/jobs/7859606789?pr=12653#step:8:449
The test will be disabled to make the integration continue.

The failure is on a dynamic matmul:
func.func @matmul_DYNxDYNxi8_times_DYNxDYNxi8_into_DYNxDYNxi32(%lhs: tensor<?x?xi8>, %rhs: tensor<?x?xi8>, %acc: tensor<?x?xi32>) -> tensor<?x?xi32> {
  %result = linalg.matmul ins(%lhs, %rhs: tensor<?x?xi8>, tensor<?x?xi8>) outs(%acc: tensor<?x?xi32>) -> tensor<?x?xi32>
  return %result: tensor<?x?xi32>
}

The MLIR is identical in both the healthy and the buggy version. We generate a single vector.outerproduct that should lead to something like:
    vle8.v	v10, (s2)
    vsext.vf2	v11, v10
    vwmacc.vx	v8, a5, v11

Full MLIR log:
Healthy: https://gist.github.com/dcaballe/2be71dab9abb787fef717eef005f9d98
Buggy: https://gist.github.com/dcaballe/ad71026c44f3cb43a041dac71d491c75
I haven't had a change to look at the LLVM-IR level but I do see significant differences at assembly level. It looks like the healthy version has some kind of multi-versioning that the buggy version doesn't have...
Healthy: https://gist.github.com/dcaballe/360f7f1b8a147b1f8a78f9203c01d7e0
Buggy: https://gist.github.com/dcaballe/07b45a198c345fa39bfe150a830dac23

I haven't had a chance to look at the LLVM IR yet. @MaheshRavishankar was also looking into it. Do you have any update, Mahesh?

I haven't had a chance to look at the LLVM IR yet. @MaheshRavishankar was also looking into it. Do you have any update, Mahesh?

No update yet, sorry doing other things, and havent been able to prioritize this.

I don't know if its relevant, but we did just find a bug in
commit a9d9616c0de3f07654ee139bead48b8d78f44e1f
Author: Luke Lau <luke@igalia.com>
Date:   Mon Mar 13 11:12:12 2023

    [RISCV][NFC] Share interleave mask checking logic

So it wasn't NFC.
Patch to fix is here https://reviews.llvm.org/D147268

Thanks, Craig! Testing here: https://github.com/openxla/iree/pull/12868

The fix seems to be related as the impacted test output changes with it and it seems to be closer to the reference but not yet correct: https://github.com/openxla/iree/actions/runs/4578527416/jobs/8085365775?pr=12868. I tried to revert the buggy commit but there seems to be a few dependencies on it already.

Correction, this fix doesn't seem to be related to the issue here. I was looking at a different benchmark failure that was also included as part of this issue. Looking into the failure more in detail now...

@dcaballe Any update on this one?

I'm my TODO list... I just need to get to it.

authors: MaheshRavishankar allieculp dcaballe okkwon topperc

repo: openxla/iree


text:
Enable transfer_write flattening for LLVMCPU

On the example of #12294, we want to flatten the transfer_write of vector<8x1xi32>:
vector.transfer_write %8, %subview_3[%c0, %c0, %c0, %c0] {in_bounds = [true, true]} : vector<8x1xi32>, memref<1x1x8x1xi32, strided<[2073600, 1920, 1, 1], offset: ?>>

into transfer_write of vector<8xi32>:
%collapse_shape = memref.collapse_shape %subview_3 [[0], [1], [2, 3]] : memref<1x1x8x1xi32, strided<[2073600, 1920, 1, 1], offset: ?>> into memref<1x1x8xi32, strided<[2073600, 1920, 1], offset: ?>>
%9 = vector.shape_cast %8 : vector<8x1xi32> to vector<8xi32>
%subview_4 = memref.subview %collapse_shape[0, 0, 0] [1, 1, 8] [1, 1, 1] : memref<1x1x8xi32, strided<[2073600, 1920, 1], offset: ?>> to memref<8xi32, affine_map<(d0)[s0] -> (d0 + s0)>>
vector.transfer_write %9, %subview_4[%c0] {in_bounds = [true]} : vector<8xi32>, memref<8xi32, affine_map<(d0)[s0] -> (d0 + s0)>>

It will allow LLVMCPUVectorLowering to create a single contiguous 8xi32 store instead of multiple 1xi32 stores. The later one results in worse performance.
This transform can be done by FlattenContiguousRowMajorTransferWritePattern in OptimizeVectorTransferPass. But it currently only works on memref not tensor, so we need to run the pass again after the bufferization.
IMO it makes sense to run OptimizeVectorTransferPass after the bufferization since the optimizations like FlattenContiguousRowMajorTransferWritePattern need to check contiguous memory accesses. But some canonicalizations in OptimizeVectorTransferPass also help eliminate transfer_read/write to avoid stack allocation during the bufferization. So the simple fix is to run the pass before and after the bufferization. LMKWYT

Looks like there is a dispatch size regression on RISC-V. I'll check if it impacts the performance.

Nice improvement!

Looks like there is a dispatch size regression on RISC-V. I'll check if it impacts the performance.

It would be good to understand why the size goes up. It should be the other way around unless we are missing a corner case...

There is a 20% regression on PersonDetect on RISC-V. I'm still finding the root cause.

You can also avoid the flattening for Riscv, and tag this issue on it

Are shuffle ops from transpose-like ops? They are vector<256xi32> types. I have a WIP PR that can lowers 16x16 vector into a sequence of shuffle ops, which has less length of shuffle vector but more shuffle ops. @dcaballe , will that help?

Are shuffle ops from transpose-like ops? They are vector<256xi32> types. I have a WIP PR that can lowers 16x16 vector into a sequence of shuffle ops, which has less length of shuffle vector but more shuffle ops. @dcaballe , will that help?

Those shuffles come from vector.shape_cast:
    %subview_2 = memref.subview %subview_1[0, 0, 0, 0] [1, 1, 8, 32] [1, 1, 1, 1] : memref<1x1x8x32xi32, strided<[18432, 768, 32, 1], offset: ?>> to memref<8x32xi32, affine_map<(d0, d1)[s0] -> (d0 * 32 + d1 + s0)>>
    %collapse_shape = memref.collapse_shape %subview_2 [[0, 1]] : memref<8x32xi32, affine_map<(d0, d1)[s0] -> (d0 * 32 + d1 + s0)>> into memref<256xi32, strided<[1], offset: ?>>
    %8 = vector.shape_cast %7 : vector<8x32xi32> to vector<256xi32>
    vector.transfer_write %8, %collapse_shape[%c0] {in_bounds = [true]} : vector<256xi32>, memref<256xi32, strided<[1], offset: ?>>

which is lowered into many vector.insert_strided_slice:
    %subview_4 = memref.subview %subview_3[0, 0, 0, 0] [1, 1, 8, 32] [1, 1, 1, 1] : memref<1x1x8x32xi32, strided<[18432, 768, 32, 1], offset: ?>> to memref<8x32xi32, affine_map<(d0, d1)[s0] -> (d0 * 32 + d1 + s0)>>
    %collapse_shape = memref.collapse_shape %subview_4 [[0, 1]] : memref<8x32xi32, affine_map<(d0, d1)[s0] -> (d0 * 32 + d1 + s0)>> into memref<256xi32, strided<[1], offset: ?>>
    %7 = vector.extract %6[0, 0] : vector<1x8x32xi32>
    %8 = vector.insert_strided_slice %7, %cst_0 {offsets = [0], strides = [1]} : vector<32xi32> into vector<256xi32>
    %9 = vector.extract %6[0, 1] : vector<1x8x32xi32>
    %10 = vector.insert_strided_slice %9, %8 {offsets = [32], strides = [1]} : vector<32xi32> into vector<256xi32>
    %11 = vector.extract %6[0, 2] : vector<1x8x32xi32>
    %12 = vector.insert_strided_slice %11, %10 {offsets = [64], strides = [1]} : vector<32xi32> into vector<256xi32>
    %13 = vector.extract %6[0, 3] : vector<1x8x32xi32>
    %14 = vector.insert_strided_slice %13, %12 {offsets = [96], strides = [1]} : vector<32xi32> into vector<256xi32>
    %15 = vector.extract %6[0, 4] : vector<1x8x32xi32>
    %16 = vector.insert_strided_slice %15, %14 {offsets = [128], strides = [1]} : vector<32xi32> into vector<256xi32>
    %17 = vector.extract %6[0, 5] : vector<1x8x32xi32>
    %18 = vector.insert_strided_slice %17, %16 {offsets = [160], strides = [1]} : vector<32xi32> into vector<256xi32>
    %19 = vector.extract %6[0, 6] : vector<1x8x32xi32>
    %20 = vector.insert_strided_slice %19, %18 {offsets = [192], strides = [1]} : vector<32xi32> into vector<256xi32>
    %21 = vector.extract %6[0, 7] : vector<1x8x32xi32>
    %22 = vector.insert_strided_slice %21, %20 {offsets = [224], strides = [1]} : vector<32xi32> into vector<256xi32>
    vector.store %22, %collapse_shape[%c0] : memref<256xi32, strided<[1], offset: ?>>, vector<256xi32>

Ouch... This is a big chunk of technical debt that is interfering with multiple scenarios right now: one is this, the other one is the transpose lowering that Hanhan is working on. Unfortunately, there isn't a single root cause. This is what I have identified so far:

OptimizeVectorTransferPass is doing far too many things at once, including removing leading and trailing unit dims but also collapsing non-unit dimensions. Generating a single vector<256xi32> would use 16 vector registers in AVX512 per operation. That doesn't make sense for CPUs (it probably does for GPUs, which is what pass was implemented for). I've been doing some experiments with this. We can try moving the trailing unit dims patterns out of the flatten flag and see what happens. We shouldn't be collapsing the dimensions for CPUs, at least at the same time as removing the unit dimensions.
In this sense, I have some changes to remove unit dims in more cases here.
vector.shape_cast is lowered to a scalar copy is some cases, which is very inefficient. We should try to use vector.broadcast/extract/insert when possible for all the vector lowering patterns.
We should lower the lowering of vector.shape_cast to the very end of the pipeline, as it's sometimes optimized away if we don't lower it too early. Trying to do so here (https://github.com/dcaballe/iree/commit/40819666de12e753d421b81e64875c8799ad81a8).

@pzread, do you think you could give it a try at only removing the unit dims without collapsing the dimensions to see what happens?

Ouch... This is a big chunk of technical debt that is interfering with multiple scenarios right now: one is this, the other one is the transpose lowering that Hanhan is working on. Unfortunately, there isn't a single root cause. This is what I have identified so far:

OptimizeVectorTransferPass is doing far too many things at once, including removing leading and trailing unit dims but also collapsing non-unit dimensions. Generating a single vector<256xi32> would use 16 vector registers in AVX512 per operation. That doesn't make sense for CPUs (it probably does for GPUs, which is what pass was implemented for). I've been doing some experiments with this. We can try moving the trailing unit dims patterns out of the flatten flag and see what happens. We shouldn't be collapsing the dimensions for CPUs, at least at the same time as removing the unit dimensions.
In this sense, I have some changes to remove unit dims in more cases here.
vector.shape_cast is lowered to a scalar copy is some cases, which is very inefficient. We should try to use vector.broadcast/extract/insert when possible for all the vector lowering patterns.
We should lower the lowering of vector.shape_cast to the very end of the pipeline, as it's sometimes optimized away if we don't lower it too early. Trying to do so here (dcaballe@4081966).

@pzread, do you think you could give it a try at only removing the unit dims without collapsing the dimensions to see what happens?

Only dropping the unit dims with https://github.com/iree-org/iree-llvm-fork/commit/1302177ae913600a3a1fbc2f70fcf219cc431523 works! We retain the improvement and no regressions now.
Are you planning to upstream the LLVM changes? I can wait for it or I can help upstream the code.

Awesome! Yes, I'm working on a few of these small patches today. I'll keep you posted. Thanks a lot for looking into this. At least now we have a better understanding of what is going on here.

@dcaballe Would you mind reviewing this again? SPIR-V has an issue (#14191) with vector.shape_cast generated in this optimization so right now I add an option to disable it there

Fix #12294

authors: MaheshRavishankar dcaballe hanhanW pzread


text:
[NFC] Move LLVMCPULowerToUKernels pass to Common/CPU

This removes the dep between Codegen/LLVMCPU and Codegen/VMVX. The next step to untangle LLVMCPU and VMVX better is having VMVX SelectLoweringStrategy. We will be able to remove LLVMCPU dep from compiler/Dialect/VMVX/Transforms/.
It also moves getCastOpOfElementWiseCast to be a static method in CPULowerToUKernels.cpp.

cc @Max191 @bjacob who might touch these files recently.
@pzread FYI


text:
Removing complex type support from various comparison ops

Request description
From https://github.com/openxla/stablehlo/pull/187#discussion_r979437990, we were having parity with Jax on the support for complex type for Min/Max Ops. As HLO does not support those types, Jax lowers them to first MHLO, by rewriting a set of lexicographic comparisons, and then the MHLO  gets converted trivially to HLO.
With this ticket, we decide to keep the type support of StableHLO min/max same as that of HLO. Jax can do similar lowering, as mentioned before, to use StableHLO directly.

Involves:

Updating the spec.
Adding verification checks to avoid complex types.
Fixing the complex type support in the interpreter.

Should we also remove support for complex tensors from ClampOp and SignOp (see linked PRs with discussions above)?

Deprioritizing this issue to focus on completing the StableHLO spec by the end of the year. Planning to pick it up again in early 2023.

Re: SignOp, we have decided to keep complex support there: https://github.com/openxla/stablehlo/pull/494#discussion_r1028678291.

Related issue: https://github.com/openxla/stablehlo/issues/997

repo: openxla/stablehlo


text:
bugfix: reject delete pod request by yurthub when cloud-edge network disconnected

What type of PR is this?

Uncomment only one  /kind <> line, hit enter to put that in a new line, and remove leading whitespace from that line:
/kind bug
/kind documentation
/kind enhancement
/kind good-first-issue
/kind feature
/kind question
/kind design
/sig ai
/sig iot
/sig network
/sig storage
/sig storage

/kind bug
What this PR does / why we need it:
when user deletes pod gracefully from cloud,  kubelet need to remove pod from etcd forcefully after cleaning up pods info(like pod volume, network, containers etc.) on edge node. so yurthub need to forward delete pod request carefully as following:

If cloud-edge network disconnected, yurthub should reject delete pod request, so kubelet can retry to delete pod in next interval
when cloud-edge network recovered,  delete pod request will be forwarded to kube-apiserver by yurthub.

so yurthub will return status code=403 for delete request when cloud-edge network disconnected.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:

Does this PR introduce a user-facing change?

other Note

/assign @Fei-Guo

/assign @zyjhtangtang

/lgtm

authors: rambohe-ch zyjhtangtang

repo: openyurtio/openyurt


text:
Support for aggregate and join operation in KafkaStreamsTracing

I would like to trace aggregate and join operations in the KStream DSL more explicitely but can not manage to wrap them into a transformer.
It would be great to have support for these operations similar to the existing map, etc.
Is that feasible at all? If so, I would be happy to contribute if someone could point me towards a potential solution.

@boxsterman thanks for the interest in contributing!
It might be a bit more challenging than simple transformers, but at the end joiners are materialized as processors, and we could be able to replicate and wrap joining functionality, similar to map operation.
org.apache.kafka.streams.kstream.internals.KStreamKTableJoinProcessor could be a good place to get started.
If you are up to experimenting with this, I'd be happy to help.

@jeqo I've already started digging into that direction and will definitely give it a try.

hi guys, is there any progress with this issue? I would like to trace logs from org.apache.kafka.streams.kstream.ValueJoiner when joining so this would be very helpfull :)

@matus753 want to give a PR a try? It has been over a year so I don't think anyone is working on it.

The challenge here is how to propagate tracing context information in KStream joins and aggregates. These operations are backed by a state store and this state store does store the message, but does not store any metadata (e.g. custom message headers) associated with it. That’s why the tracing context is lost if a state store is involved.
I’ve looked into this and it would require a change to the KStream client lib in order to include the metadata into the stored message. I’ve some ideas on how this could be done, but didn’t manage the time to kick off an official KIP.
Unfortunately this issue significantly limits the whole Kamon Kafka Stream instrumentation since almost all of the streams in my world do use joins and aggregates.
If some one is interested in picking this up, I would be more than happy to share my experiences and of course also help implementing it.

On 14 Oct 2020, at 12:56, Adrian Cole notifications@github.com wrote:
@matus753 https://github.com/matus753 want to give a PR a try? It has been over a year so I don't think anyone is working on it.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/openzipkin/brave/issues/889#issuecomment-708326333, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABS2GL4BI2ZSPILTVYYG6VDSKV7U7ANCNFSM4HDAJOOA.

@boxsterman so you mean it is currently like old kafka where some people used enveloping etc. I wonder if any phases can be known to execute in the same JVM? If so, we aren't limited to what's persisted to disk... Is it possible for you to raise an example project (maybe using zipkin's docker image for kafka) showing this problem? I think that could help all get on the same page even someone who might eventually need to KIP it

Adrian makes a good point. I'd also like to validate this limitation with an existing example. Joins (at least stream-table) actually propagate headers, here is a small example: https://github.com/jeqo/tracing-kafka-apps. Feel free to extend it to show case your issues.
@boxsterman probably you've already saw it, but there is an open issue related to this: https://issues.apache.org/jira/browse/KAFKA-7718
I also created https://cwiki.apache.org/confluence/display/KAFKA/KIP-634%3A+Complementary+support+for+headers+in+Kafka+Streams+DSL, that is still on early discussion. I plan to work on it this quarter.
Would love to get your feedback there.

authors: adriancole boxsterman jeqo matus753

repo: openzipkin/brave


text:
Adjust NPM wrapper script now that NPM is installed nested within node

Fixes https://github.com/openzipkin/zipkin/issues/1957

thanks much @ryanrupp!

authors: adriancole ryanrupp

repo: openzipkin/zipkin