Vendor nspektr. Utilize it in Distribution._install_dependencies.

Summary of changes
In https://github.com/python/importlib_metadata/issues/368, I was exploring ways to make entry point dependency resolution available outside of Setuptools. In doing so, I explored creating the nspektr project. In creating that project and writing its tests, I discovered a flaw in how EntryPoint.extras resolved (https://github.com/python/importlib_metadata/issues/369), a flaw that affects Setuptools installation logic.
While the flaw is fixed in a late release of importlib_metadata, there are likely older versions of importlib_metadata as well as older versions of importlib.metadata without the fix (at the time of this writing, the bug still exists in all Python versions). I've used nspektr to provide a workaround for the flaw (https://github.com/jaraco/nspektr/commit/7245f0716bfca38dcf2c59cbdb5196422556c4f7).
This PR replaces the inline logic in Setuptools with the more thoroughly tested logic of nspektr, adopting the workaround for the broken extras handling and simplifying Setuptools own logic.
Pull Request Checklist

[x] Changes have tests
[x] News fragment added in changelog.d/.
(See documentation for details)

I am a little worried about yet another vendored dependency, this time even a project without a meaningful readme.

I respect that. I can give the project a readme.
Ultimately, I'd like to move all vendored dependencies to regular dependencies, though I'm not sure that's possible any time soon.

Sure, moving all vendored dependencies out is a meaningful goal. But it used to be just a handful, now we have plenty. Let's not kee adding new ones before we move all vendored dependencies to regular dependencies?

Let's not keep adding new ones before we move all vendored dependencies to regular dependencies?

I'd originally set out to add this functionality to importlib.metadata, but couldn't do that because importlib.metadata can't depend on packaging. Similarly, I couldn't add it to packaging because it can't depend on importlib.metadata. So another package was necessary if the functionality was going to have use outside of setuptools (which I'd intended for it to do since I discourage use of setuptools except as a backend). Furthermore, I was in no rush to replace the behavior as found in Setuptools with the behavior in nspektr until the creation of nspektr and its tests revealed a flaw in Setuptools' own implementation.
Then I was left with the choice to either copy the fix into setuptools and maintain two copies of the same functionality or vendor the package and rely on the same copy. I've got far too little time to be able to afford maintaining multiple forks of the same thing, so vendoring it was. I really feel like I have little choice.
I don't think it's been said, though, what's the harm in having an additional package vendored?

Let's not keep adding new ones before we move all vendored dependencies to regular dependencies?

Hi @hroncok , I think I can appreciate the concerns here, however there are some extra dependencies planned to be vendored in the near future to support features like pyproject.toml metadata (e.g. tomli). These have been proposed a few months ago. I hope that is OK.

Well, I am no authority here. I've made my point, but I am not willing to die on this hill :)

Miro, sorry if I've upset you. I had hoped that Setuptools could add dependencies as needed without adding complications. It seems from your sentiment that adding dependencies creates concerns for you. In #2825, I laid out the reasons why Setuptools wishes not to vendor dependencies, but none of my reasons seem particularly pertinent to a user or downstream packager. I would genuinely like to hear you articulate what motivated you to express your opinion, as that could influence how we think about new dependencies going forward.

Nah, I'm not upset. Just a bit confused about what setuptools is turning into.
With more vendored dependencies, setuptools grows bigger and bigger every release. We had a regression test asserting the wheel is no bigger than 600 KiB and we had to recently relax that requirement. The overall license of this package gets more complicated. There are more LICENSE files that we probably should ship with the package. The overall license of Python gets more complex, as it includes setuptools wheel...
(Most of this has already happened prior to this PR, e.g. this one particular dependency does not increase the size much or does not add yet another different license, but I speak generally about new vendored deps.)
It seems to me like this project has found itself smashed between 2 different forces. On one hand, it is the default legacy way how to build packages when you install them with pip or with python setup.py ... invocation. On other hand, it shall be a modern PEP 517 backend with dependencies, toml support and whatnot. Maybe it shouldn't be both?


Support port expander interrupts

I also wanted to add a PortDriverInterruptChange trait that would allow the user to wait on one or multiple pins changing state.
My approach:
#[derive(Debug, Clone, Copy, PartialEq, Eq)]
pub enum InterruptChangeError<EI, EP> {
    I2cError(EI),
    PinError(EP),
}

pub trait PortDriverInterruptChange: PortDriver {
    /// Wait until at least one pin in `mask` switches
    /// to the state indicated by the corresponding bit in `target_state`.
    ///
    /// If a pin already has the target state, it will not trigger an interrupt,
    /// unless it first switches to the opposite state.
    ///
    /// Returns the bits that switched to the state indicated in `target_state`
    ///
    /// Arguments:
    /// * `int_pin` - The mcu pin to wait for an interrupt by the port expander
    /// * `mask` - The port expander pins to wait for a level change on
    /// * `target_state` - For each port expander pin, the state to wait for.
    /// A 1 in the mask indicates a high level, a 0 indicates a low level.
    async fn wait_for_change_to<P>(
        &mut self,
        int_pin: P,
        mask: u32,
        target_state: u32,
    ) -> Result<u32, InterruptChangeError<Self::Error, P::Error>>
    where
        P: embedded_hal_async::digital::Wait;
}

(API is based on what the PI4IOE5V6408 offers. We could add other traits for edge detection later)
My idea was to make this accessible via:

A wait_for_change_to method for each pin
A wait_change_multiple method (similar to read_multiple)

Problem: We can not keep the driver locked, while awaiting an async function.
This would require an extension of the shared-bus crate to either allow passing an async closure to the lock method, or have a lock method that returns a guard.
Before I do this, I wanted to ask you, if I'm on the right track here, or whether you have a different solution in mind regarding interrupts.
Originally posted by @t-moe in https://github.com/Rahix/port-expander/issues/17#issuecomment-1910346921

Hi @t-moe,
I also thought about how to support pin change interrupts in port-expander.  The situation is a bit tricky.  We want to be able to reliably find out which event triggered the interrupt.  But this isn't straight forward: Some port expanders expose a register that you can read once to get the interrupt state of all pins.  After reading the register, this state is cleared again.  So if we were to have per-pin methods, they would possibly erase events from other pins by accessing this flag register.
So an API for pin change interrupts always needs to query all pins of the expander at once.  Or possibly mirror the flags locally such that we can track what pins fetched their flag already.  But this quickly runs the risk of desynchronizing between the real flag and the locally cached one.
Not really sure what kind of solution works best here...

Beyond these specifics, I would not design the API using a async wait_ function but rather leave the "wait for interrupt" part to the user.  They can wait on their interrupt line in whatever way they like and then just call some port-expander APIs to fetch the interrupt information from the chip.  Keeping the waiting part outside makes things more flexible and doesn't lock the user into using embedded-hal-async.

Hi @Rahix,
Thanks for your response and input regarding good API design.
Currently I mainly need the "wait for pin changed" interrupt, on all pins of the PI4OE5V6408 at once. But someone else might have a different requirement.
Which methods should I add to port_expander::dev::pi4ioe5v6408::Driver ?
listen_for_change(&mut self, mask: u8) -> Result<(),E> and  get_interrupt_status(&mut self) -> Result<u8,E>  to facilitate my specific usecase
or
(unsafe ?) fn write_reg(&mut self, reg: Regs, val: u8) -> Result<(),E>  (or update_reg) and  fn read_reg(&mut self, reg: Regs) -> Result<u8,E>  to allow more flexible customization?

I think it's easier to talk about code so I created #28 as an idea.  Please take a look and let me know your thoughts.
The idea is that you get a port_expander::fetch_pin_change() function to fetch the change-state of a number of pins.  This function will always reset the change state of all pins on the expander afterwards.
Similarly, a port_expander::fetch_interrupt_state() function can be used to fetch the pin-states that caused the interrupt.  Similarly, it also resets the interrupt info for all pins on the expander.
What I'm unsure about is whether this is really a usable API for downstream applications.  I very much dislike the fact that interrupt status needs to be queried in a central place with this API.  You can't really handle the indivudual pins in isolation with this interface...

Alright, because it's so much fun, here is a second alternative in #29.  This one is better at decoupling the individual pins.  The downside is that an explicit fetch_all_interrupt_state() is needed somewhere and missing that will lead to never receiving any interrupts (and no warning => hard to debug).

I really depends a bit on the usecase.
In my case, I use the port-expander to wake the chip from deepsleep. Upon power-up I decode the interrupt status in a central place and map it to an enum WakeupSource. So #28 would work fine for me.
Additionally:

#28 is missing pin.listen() and I can not configure the interrupt mask.
Having to manually call pin.fetch_all_interrupt_state() in #29 is really a bit unfortunate...

What if we combine #28 + #29 and offer both APIs to the user ?
port_expander::fetch_pin_change(pins) and pin.query_pin_change()
We could use the same traits under the hood.
The user can either call port_expander::fetch_pin_change(pins)  which is straight-forward.
Or if he needs per-pin calls, he can call pin.fetch_all_interrupt_state() followed by pin.query_pin_change()


add snapshot

Please add the theme in the file source/_data/themes.yml.

@NoahDragon
edit it in my local repo

Great. Merged.

Name of snapshot image and name of theme must be equal ?

Yes


fix chips z-index on portriat mode

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 99.612%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
12441

Relevant Lines:
12443

💛  - Coveralls


Do not store socket_addr and slave_id in Client

Only connect_tcp uses these variables. After connecting all that's needed for communication with the inverter is the Context.
By not storing the socket_addr and slave_id, the Client struct is also usable for Modbus-RTU connections (even though there is no helper to set up the context -- the caller can do this on their own).

I'm writing a Rust version of my "sunspec to MQTT" tool (https://github.com/MartijnVdS/pv2mqtt), and while trying to use this library, found that the Client struct has some parts that don't really belong in it.
Because I'd like to keep support for RTU, I decided to make the code more "connection independent", by requiring only the Context.
I've run the tests on my own inverter (Mn = "APSystems"), and the models it provides are detected correctly.

Hi, thx for your contribution, but there is already a branch which adds RTU support. This will also remove the socket_addr from the client struct.  I will finish this one at the end of the day.

I did not see that :) I'll close this merge request then.


create rule only for the api

Hey
I just installed the chart on my ocp cluster, and I want only to monitor the crt of the api.
Could someone help me achieve my goal?
Until now I set prometeusrule.create = false in order to create my own prometeusrules.
and I created with this configuration:
- alert: certificate
   rules:
   - alert: certificate-expired
      annotations:
        description: Certificate of "{{ $labels.subject_CN }}" is about to end in {{ $value }} days
                {{if $labels.secret_name }}in Kubernetes secret "{{ $labels.secret_namespace
                }}/{{ $labels.secret_name }}"{{else}}
        summary: Certificate is about to expire
      expr: ((x509_cert_not_after - time()) / 86400) < 30
      for: 1h
      labels:
          severity: critical

Hi,
I understand what you have done and your goal using this custom PrometheusRule. However you didn't describe what problem you encounter. I guess the alert is not working while you have certificates currently under the expiration threshold.
Before working on that it is necessary to confirm the exporter is deployed in an appropriate way for your k8s distribution and monitoring stack. OpenShift sometimes require more care and understanding as the default configuration is more elaborate in some ways than other typical distributions.
I don't think any developer on this project is also an OCP user so we're unlikely to guess what the issue may be right away. So let's go through the typical troubleshooting steps.
Could you please clarify if it is confirmed the exporter is being scrapped, and certificate metrics have appeared in Prometheus?
Going to the Prometheus web UI will help:

In the Status / Targets page there should entries named x509, that have been populated by prometheus-operator thanks to the ServiceMonitor or any other discovery method you may have enabled instead in chart values. Are they showing up green and UP?
Sending an expression such as x509_cert_not_after in the Graph form should list at least a few certificates.

If you cannot find x509 at all in the Targets list, then the issue has to do with how prometheus-operator is configured in the Prometheus object.
If the target was there but showing as DOWN, communication may be blocked by a NetworkPolicy which would not suprise me on OCP.
Please provide more information based on these points and questions, and what you did check already.

Sorry you are right, My problem is when I created this prometeusrules, it creates around 300 alerts, and all I want is just ine alert on the api.
I can show the mertics you have write.
Thank you very much about your response.

Ok I get it now, you are looking for a set of labels to apply as a filter on the x509_cert_not_after metric. For your alert expression to only target specific certificates.
What is this "api" you are mentioning? Is it the Kubernetes api-server for the cluster?
Usually you would not find control-plane certificates stored in Secrets. Did you also enable the hostpathExporters?

So sorry about the delay, I was out of office.
Yes, I meant to the Kubernetes api-server, In OpenShift we assimilating the api certificate in a secret.
Do you know any option to filter the  x509_cert_not_after metric, in order to create specific alert?
Thank you very much!


Creation of k8s master and worker images

we need publically available ciao k8s master and worker images, the same way we have cnci images available.

each image should contain a script to parse json config for k8s from cloud init

This work item is to define the content of each image

we changed our k8s strategy, so this is no longer relevant.


How to run the front-end?

I can't figure out how to run the front-end. Everything else appears to be running though. I get a missing script: start when I try npm start.
Help?

i am also facing same issue.


Fix reference to range(of:) in the contains doc

Shepherd #20860

@swift-ci please smoke test and merge


Import all of the UK

By early November, it would be "really nice" if the LTN tool could be run easily anywhere in the UK. The import process today is not that bad on native, but it could be smoother. It doesn't work on web, and that's more the blocker -- I want to tell someone to open their browser, click a URL, and have something working in... under 30 seconds ideally?
Related to #326.
Idea 1: make the Overpass import work on web
aka, continue #523
Today on native, we ask people to draw a boundary with geojson.io, then run cli one-step-import, which pulls from Overpass and does everything. In principle, this could all work on web too. The biggest friction is bringing in more dependencies (convert_osm, import_streets, importer, etc) into the main binary, after a previous effort to tease them out.
We could maybe do something funny, like open a new browser tab pointed at a new page, load a different WASM binary, do the import, and stash the resulting serialized map in local storage or something. Except we've already been hitting size limits with that -- 5MB or so? That definitely won't work.
Idea 2: flatgeobuffer
I could import all of the UK (from one giant .pbf) and turn it into one massive RawMap. Then we could convert it to a flatgeobuffer (fgb) file, stick that in S3. At runtime, someone requests a bbox of the area they want, and we efficiently read a minimal part of the fgb file, convert it back to RawMap, then finish the conversion into Map.
I had a quick look through RawMap and StreetNetwork. All of the important stuff is indexable in a FGB -- roads, intersections, areas, buildings.
Open questions:

How horrifically slow would it be for me to import the entire UK on my own machine? The process is parallelized on totally different inputs right now, so processing one big file is probably a scary idea. (Also, we only read osm.xml today -- for perf, we almost definitely would want to switch to osm.pbf)
How fast would the dynamic import process be for someone in a web browser? Could maybe try to estimate this by trying out the US census population reader in practice today, and adding up time to do the second half of map conversions.
How would the coordinate projection work? Right now, every map turns into Mercator (?) using the boundary. We natively store everything as distances in meters from a reference point. It works fine for city-sized areas, but for all of the UK, the distortion is probably crazy. And it would be an absolutely massive and complex change to change all of the code everywhere to work off of LonLat and do different math.

CC @BudgieInWA for thoughts about osm2streets and @michaelkirk for prior experience with the US census fgb.
Idea 3: Tiling
Chop up the UK into fixed square tiles of some size, and just import all of them as regular maps. If someone gets lucky and the area they care about is firmly within a tile, then they're all set. We could also consider gluing together adjacent tiles... maybe that would mean storing just as RawMaps (which're smaller and simpler -- no pathfinding, sequential IDs, or size-heavy lanes or turns) and then having a way to merge two adjacent ones together. Aside from the roads/buildings/areas crossing the boundary, this seems logically straightforward. As long as the total area isn't too big, the two Mercator projections glued together should be OK.
Common problems
All of these implementations share some issues.
To start with, how do users pick the area they want? We could continue to ask people to draw the area they want with geojson.io, and maybe even just limit to rectangles (or transform their polygon into a bbox). It'd be kind of neat to have something else built-in, but very high effort to read and display existing vector/raster tiles.
Today, lots of code, UIs, and save files assume a map name -- country, city, specific map name. For these custom areas or tiles, maybe we just have to use the coordinates of the 4 corners and update all the code to understand this special case. Over time, save files need to be stored and indexed differently to possibly apply to many different people's drawn boundaries. (This kind of works today within a country+city.)
How would switching apps work? Natively, we could cache the imported area (as we do now in zz/oneshot) and just open it again. On the web, I guess we hit the local storage problem -- we'd need a way to pass 50-100MB files around locally. Or just pay the cost and import again.

How would the coordinate projection work?

@bdon pointed me towards UTM or looking into coordinate systems designed for the UK. Maybe we could convert everything into those coordinates and continue treating everything as Cartesian

@Robinlovelace pointed me to https://epsg.io/27700 for the UK. OK, so the coordinate problem in idea 2 is solvable! Maybe the next test needs to be how quick it is to read thousands of features from FGB, or if any kind of batching is needed

Using FGB sounds interesting for sure, but I couldn't confidently say it'd work out, because I don't think they've had a ton of use - especially the rust and typescript drivers.
We're using an FGB to serve census polygons for abstreet, but I've never personally used it for mixed geometry collections — e.g. a bunch of road line strings and a bunch of polygons living in the same collection. Allegedly it works, but I can't vouch for it.
Another thing to consider are data access patterns. With FGB you currently only have a seek-forward stream, so you couldn't revisit past entities without buffering them into memory or streaming through the entire thing again.  Would that work for your use case?
I think the cost of traversing the index to get your bbox would likely be acceptable because, realistically, the processing to transform the map data into whatever you need for the LTN app will likely take a while.
Which brings me to revisit your option 4 (something server side). I'm not really sure what happens between "get the map data" and "use the app", is there substantial server side processing that you could do that would make the time-to-start-using-the-app happen faster for users, or is this really only about getting the client the right slice of the data?

With FGB you currently only have a seek-forward stream, so you couldn't revisit past entities without buffering them into memory or streaming through the entire thing again

That should be fine... the features will be fed into the FGB writer in an arbitrary order, but I'm assuming part of the writing + index creation arranges things somehow. So that when we do select_bbox and then iterate through the results, we only ever seek through once. We might get features in some arbitrary order (like road line-strings and building polygons interspersed even), but that doesn't matter.

is there substantial server side processing that you could do that would make the time-to-start-using-the-app happen faster for users

I just did a few quick tests in release mode on native. nl/groningen/huge takes 31s to go from RawMap to Map (which is the step that would happen after reading everything from the FGB). Of that, matching buildings to the nearest road is the slowest step, at 18s -- and that's with full parallelization, which will be unavailable on web until we figure out web workers. Preparing the pathfinding CHs is the next slow bit at about 3s, and we could actually skip that for importing to the LTN tool, because it doesn't use the CHs anyway. Another smaller area is gb/leeds/north -- 15s for RawMap to Map, again with building matching at 8s being the bottleneck.
So you raise a great point -- as it works now, shoving the RawMap into a FGB and making the client do the final conversion would still be expensive. Matching buildings to the nearest road is only needed for one mode in the LTN tool (planning a route), and that UI is a little awkward right now anyway -- you have to click a building as a trip endpoint, which isn't intuitive or easy at low zooms. We could instead just snap a waypoint to the nearest position on each side of a road and get basically the same effect (or even better UX), much more cheaply. I'd have to think through how to structure this "hack" -- we'd basically be making a building's sidewalk_pos and driveway_geom optional and dealing with that consequence everywhere else in the codebase.
To note, I don't want to try to put the final Map file into an FGB:

the file size would be much greater -- we balloon roads into individual lanes, each with their own geometry
Map uses sequential IDs for everything, so we can't just clip an area and punch holes in the ID space
the pathfinding contraction hierarchy can't be subsetted, we'd have to just rebuild

So I think RawMap as an FGB is still a viable option, but it would take some work, and the performance for clients is still a bit unknown -- but seeing the FGB reading part should be not too hard of a test to try out. The bigger issue is still how to make one gigantic RawMap on my laptop (or a big VM somewhere, but that would make my development workflow a headache). Maybe all the internal importing steps can be parallelized enough and the initial OSM extraction fits in memory. But if not, idea 2 kind of breaks down anyway. Maybe I'll just give that a shot first then and see.

Haha, importing a 21GB uncompressed england-latest.osm.xml fails outright because an earlier refactor to be web-friendly reads the entire file into memory first, so memory allocation of<PHONE_NUMBER>1 bytes failed. Would also need to first fix that!

Sounds like a mega import!

We could maybe do something funny ... load a different WASM binary, do the import ...

We would want to load the JS/WASM dependency in the window and call it directly. Append a script tag to the dom or use dynamic import or something.
This is a lucrative goal, because this is the common JS usecase for osm2streets I think.
<script ... src="unpkg.com/osm2streets"></script>
<script ...>
const streets = await window.osm2streets.fetchArea("Fremantle");
...
</script>

Tiling

Chop up the UK into fixed square tiles of some size, and just import all of them as regular maps. We could also consider gluing together adjacent tiles...

This is a very lucrative goal I think, because once the tiling is incorporated, you can work at whatever scale you need to, if you spend the time computing tiles.

When a single short way is modified in JOSM one or two smallish tiles could be recalculated most of the time.
We can hook up raster/vector tiles for backward compat integration into slippy maps everywhere!

Calculate tiles with enough buffer around the edges that the influence of relevant osm geometry is considered.

We would want to load the JS/WASM dependency in the window and call it directly. Append a script tag to the dom or use dynamic import or something.

:O I didn't realize browsers could do that, but it makes perfect sense! Then there's no hassle to "pass back" the data from this computation.
OK all of the ideas are promising. In the very short term, I might go for the 1st, since it has the easiest implementation and would be more widely useful. Then I might try a bit of each of the other ideas and flesh out more tradeoffs

Haha, importing a 21GB uncompressed england-latest.osm.xml fails outright because an earlier refactor to be web-friendly reads the entire file into memory first, so memory allocation of<PHONE_NUMBER>1 bytes failed. Would also need to first fix that!

When I import montlake.bin with cargo run --bin game --release, I also encountered memory allocation of<PHONE_NUMBER>103129189 bytes failed (6EB...)

When I import montlake.bin with cargo run --bin game --release, I also encountered memory allocation of<PHONE_NUMBER>103129189 bytes failed

(That's unrelated to this issue.) 62d289b0a92146e6fb50840843ac3db5c46bd943 last night changed the binary format, so if you did git pull, you also need to do cargo run --release --bin updater -- download. See https://a-b-street.github.io/docs//tech/dev/index.html#downloading-more-cities. I'm guessing the raw_map file became out of date

https://github.com/a-b-street/abstreet/tree/wasm_importer is in progress for "Idea 1: make the Overpass import work on web". There are some weird JS tricks in here (like we can't dynamically import from wasm-bindgen, and we can't even use inline_js as a workaround), but so far, no blockers. We can just define a new JS function that does the dynamic import, and later call it. Lots of refactoring needed to make convert_osm work without a filesystem, though

Reviving this for AI:UK -- I need to be able to spin up the LTN tool anywhere in the UK relatively quickly for live demo purposes.
I've been trying imports of massive transport authority regions as one experiment. Importing huge areas itself is slow for some reasons I'm working on, but could be done beforehand. Problem is, loading them, rendering road labels, everything in the LTN app also gets slower. So... not looking like a good option.
To avoid hitting the network, we could use an england-wide cached pbf and (now) use osmium to clip. I could pre-download all geofabrik slices in UK to speed things up. But TODO, also try running a local Overpass server with just the UK as input.
Another approach I'm considering is to import a bunch of smaller places. I've tried this before as tiles, but the resulting boundaries are too arbitrarily weird. Maybe all of the smaller boundaries from ATIP would be a good candidate.

Maybe all of the smaller boundaries from ATIP would be a good candidate.

I think local authority district boundaries, which include boroughs of London, would be good for this. Good luck with this mission!

pueue parallel 1 first, or something low, due to osmium.
for x in ../abstreet-to-atip/aiuk_boundaries/*; do NAME=basename -s .geojson $x; pueue add --escape ./target/release/cli one-step-import --geojson-path "$x" --map-name "$NAME" --use-geofabrik --use-osmium --skip-ch; done

(There are somehow newlines in the filenames; I think basename is weird)

About 380 files, 12GB output, each map loads fast enough. This'll work fine for AIUK. I'll also prepare a clickable geojson map to avoid asking people if they know the LAD of their area!

Let me know if you need more compute power at some point!


WIP compute job history

Fixes #338  .
Changes proposed in this PR:

fetching  compute job history from the Subgraph

think some architectural change is required so we can ditch the fetch-each-asset-individually completely:

for all the DIDs we get from The Graph query, do a queryMetadata(), where the query includes a list of those DIDs, and with highest page count possible (so we do not have to deal with pagination)
it will return a QueryResult and result.results will have array of DDOs. Put that into a new component state.
in getAssetDetails() then iterate through that state, instead of querying Aquarius for each asset

Then it should load way faster.

I think we are stuck and the intended outcome of getting compute history from The Graph can only work out if we actually have the jobs in our subgraph. Because token orders !== compute jobs. Because a job can be started without a token order when a job on a dataset has been started before.
So correlating token orders with actual started jobs where we still have to fetch the jobs through ocean.js is defeating the purpose of this issue. The problem visualized:
My compute jobs through ocean.compute.status:

And then with this PR where we get all the token orders, make a list of DIDs out of it, then query Aquarius for it only including compute datasets:

So then ocean.compute.status would give us a completely different list.

I'll take a look. At first sight the logic is wrong here but need to debug a bit to be sure.

Currently blocked by https://github.com/oceanprotocol/ocean.js/pull/717
We are going to fetch all the jobs for the user from each provider. It's the least amount of calls and the fastest.
~1.5 seconds for me with 30+ jobs.

I get multiple signature request for all jobs right away, even before list loads:

We should try to limit that signature to retrieving the detail logs, as we do right now on live.
As a comparison, it looks like we might show jobs multiple times:
Live:

This branch:

Also seem to be getting different timestamps on reload, and they do not make sense for Berlin Fish Fauna (2013) cause it didn't exist 6 months ago:

Yes, because your testing doesn't make sense. My push is tested using a local version of ocean.js and not finished because i need the update in the provider so i didn't bother to wrap things up until i have that update.

First quick test, might have started a bunch of jobs but not sure that many. And the CREATED & FINISHED times seem weird:

And not sure if we want to look at that in this PR, but none of the listed jobs have any logs for me

is this on main or rinkeby?

fixed, it was a bug related to network switching


Some light editing to the documentation

Some light editing, in the first 400 lines so far. Mainly spelling and grammar

Thank you very much! \o/


itertool.map has no length

Line 33 "N_used = len(true_hmm.used_states)". "true_hmm.used_states" is itermap.tool type and has no length....
I am not sure if this is because Python version. I'm using Python 2.7.6. What version are you using?

Thanks.  This was a regression in pyhsmm.  I've fixed it in https://github.com/mattjj/pyhsmm/commit/83f0bf1e3798c3625b7fee2d25b4b8a52f0a99e7.  Please pull the latest pyhsmm from master and then try running the pyhsmm_spiketrains demo.  It is working for me with python 2.7.13.


Release/1.5

Can one of the admins verify this patch?

add to whitelist

ok to test

test this please


.Net: Fix #6030

Motivation and Context

#6030
Description
In this implementation, the Ġ will be reserved in liquid template which is used to replace : in all input variables when unsafe content is not allowed.
The encoding process for input variables when unsafe content is not allowed is

replace all : to Ġ // this is the extra step comparing with HandlerBar Template
Encode xml using HttpUtility.HtmlEncode

The decoding process is

replace all Ġ to :

Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

In this implementation, the Ġ will be reserved in liquid template which is used to replace : in all input variables when unsafe content is not allowed.

Why is that necessary? And why is that ok? Why are we in a position to effectively ban "Ġ"?


Move to Eclipse?

Is this repository going to stay under the JNOSQL organization or will it move to the Eclipse one?

We'll stay here.

@keilw  please send an email to each issue. There is a good point to start the discussion

This was about the GitHub organization, but if there's a committers mailing list, we can ask the question there (where Mentors like Wayne should also be CC)


test(coverage): refactor testing structure

Description

Refactors coverage tests similarly as done for others in https://github.com/vitest-dev/vitest/pull/5600. The current coverage tests are a bit of mess.
Most coverage tests will need a way to change coverage options and verify the output. For this we'll need to use Vitest Node APIs. Vitest Workspaces is used to change coverage providers and browser mode. Tests themselves configure different coverage options that are being tested.
Includes fix from https://github.com/vitest-dev/vitest/pull/5954 so let's merge that one first.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
[x] Ideally, include a test that fails without this PR but passes with it.
[x] Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

[x] Run the tests with pnpm test:ci.

Documentation

[ ] If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

[x] Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

Let's first merge https://github.com/vitest-dev/vitest/pull/5954


Operator client - getsubscriptionusage

Currently all the subscriptions are taken into consideration during the report. It needs to be narrowed down to as low set as possible before writing csv file.

Fixed in scope of #712

Checked on Windows Server 2016, jdk1.8u121, build BES_MASTER_UNIT-1769 2017/06/02 in SAML mode.
Command getsubscriptionusage works as expected.

Retested on Windows Server 2016, jdk1.8u121, build BES_MASTER_UNIT-1778 2017/06/29 (Official 17.2.0) in Saml mode. Command getsubscriptionusage works as expected.


Re-run versioneer install to fix version number (tag_prefix)

The tag_prefix as specified in pyproject.toml ('v', which is also what is being used in practice) didn't match what's in the generated/committed _version.y file. so re-running versioneer install --no-vendor to fix this.
I used the latest version 0.29, which also seems to include some other formatting changes
Probably this is only needed for editable dev installs

Could you exclude it from precomit or run pre-commit over it?

which also seems to include some other formatting changes

ah, that's probably for running black afterwards. will do that here as well

thx!


Support ODCS as a data source

Support ODCS (Open Data Contract Standard) as a data source for data generation and validation.

Added in as part of release 0.10.10.


Default SetOptions should be OVERWRITE

When setting a POJO the default SetOptions should be OVERWRITE so that Firestore conventions are followed

There seems to be no way of creating a SetOptions with merge = false? So this library would need to call another overload instead of passing SetOptions.merge()?
But this library is dead, right?


Quick start guide failed to parse objdump output

When going through the quickstart guide, I run the following commands:
python3.9 -m pip install virtualenv
python3.9 -m virtualenv ~/venv-revizor
source ~/venv-revizor/bin/activate
pip install revizor-fuzzer

git clone https://github.com/microsoft/sca-fuzzer.git

cd sca-fuzzer/src/x86/executor
make uninstall
make clean
make
make install

cd ../../../
rvzr download_spec -a x86-64 --extensions ALL_SUPPORTED --outfile base.json

./tests/quick-test.sh

And the quick test fails with the following error:
Traceback (most recent call last):
  File "/home/username/venv-revizor/bin/rvzr", line 8, in <module>
    sys.exit(main())
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/cli.py", line 393, in main
    exit_code = fuzzer.start_from_asm(args.num_test_cases, args.num_inputs, args.timeout,
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/fuzzer.py", line 119, in start_from_asm
    return self._start(num_test_cases, num_inputs, timeout, nonstop, save_violations)
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/x86/x86_fuzzer.py", line 117, in _start
    return super()._start(num_test_cases, num_inputs, timeout, nonstop, save_violations)
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/fuzzer.py", line 137, in _start
    test_case: TestCase = self.generation_function(self.existing_test_case)
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/asm_parser.py", line 166, in parse_file
    self.generator.get_elf_data(test_case, obj_file)
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/x86/x86_generator.py", line 64, in get_elf_data
    self.elf_parser.parse(test_case, obj_file)
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/x86/x86_elf_parser.py", line 69, in parse
    instruction_addresses = self._parse_objdump_output(obj_file)
  File "/home/username/venv-revizor/lib/python3.9/site-packages/revizor/x86/x86_elf_parser.py", line 225, in _parse_objdump_output
    assert section_name != "", "Failed to parse objdump output (section_name)"
AssertionError: Failed to parse objdump output (section_name)
Detection: FAIL
Command: rvzr  fuzz -s /home/username/Desktop/sca-fuzzer/tests/../base.json --save-violations f -I /home/username/Desktop/sca-fuzzer/tests/x86_tests/configs -t /home/username/Desktop/sca-fuzzer/tests/x86_tests/asm/spectre_v1.asm -c /home/username/Desktop/sca-fuzzer/tests/x86_tests/configs/ct-seq.yaml -i 20
Exit code: 1
Output: '
WARNING: [executor] SMT is on! You may experience false positives.'

Rather than giving the expected result
Detection: OK
Filtering: OK

My machine is an Intel i7-8565U running EndeavourOS Linux x86_64 with Linux kernel version 6.6.40-1-lts, and my python version is 3.9.19
Any insights on how to resolve this?

Thanks for submitting a bug report!
What is the version of the assembler on your system? (as --version)

Thanks for the quick response!
My assembler version is:
$ as --version
GNU assembler (GNU Binutils) 2.42.0
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-pc-linux-gnu'.

And my objdump version is:
GNU objdump (GNU Binutils) 2.42.0
Copyright (C) 2024 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.

The most recent commit to main should fix the issue. Could you, please, verify that the fix works on your system?

Assuming that the issue is resolved. @EdmundGoodman please, let me know if it isn't.


MM-T459 E2E Test for Group Messaging: Add first user

Summary
In the dialog to create a new direct message (or group message), ensure that the user list is always sorted alphabetically, even after selecting a first user.

Added e2e test with cypress
Updated util function to render username span with unique html ID, this helps with a more precise selection of the user's display name + display username in the direct message dialog
Updated snapshot for unit test that depends on the modification of the previous step

Related test case: MM-T459
Related ticket: MM-1816

Thanks for the feedback @saturninoabril I appreciate your advice ! :)
I think I'm good for a second pass.
Cheers !

@saturninoabril I'm afraid I do not see any additionnal comment :/


Updated 'known good' versions of software

These versions definitely build a MIPS cross compiler on amd64 under Linux.

Closing as no response received.


Won't allow me to change values with ScriptHandler::buildParameters

Hi there,
I installed this plugin for my Symfony2 project. When the composer install task runs, it doesn't ask me to provide parameters like it does if I run composer install manually. I have this in my composer.json file:
"scripts": {
     "post-install-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
        ],
        "post-update-cmd": [
            "Incenteev\\ParameterHandler\\ScriptHandler::buildParameters",
            "Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::clearCache",
        ]
    },
    "extra": {
        "incenteev-parameters": {
            "file": "app/config/parameters.yml"
        },
    },

If it doesn't generate correct parameter file, the next hook clearCache won't work properly because of the wrong database connection. Is there anything I can do to get buildParameters working during a deployment?
I do not have --no-interaction argument in the composer install command.

Same issue.

When I deploy my own Symfony projects with Capistrano, I have already put a complete parameters.yml.dist in place (in a shared folder), and then symlinked it, into the app/config/ directory with the  :linked_files. That is used as the source to generate the parameters.yml file for use with the Composer scripts.  Any variables that I choose to leave as '~' in the .yml.dist file shows up in the .yml file as 'null'.

@sudosu Thanks for bringing this back to my attention. Have you tried set :composer_install_flags, '--no-dev --quiet --optimize-autoloader' without the --no-interaction flag? Because I need to run Capistrano inside CI so interactive shell is not an option for me.
@alister True. But normally one shouldn't put the real credentials like database password in the dist file in git. These sensitive parameters should only be set upon deployment. The values you defined in the dist file will be served as the default values.

@yellowmamba Yes, I tried it with --no-interaction and nothing changes.


Upgrade React-native package

We need to upgrade react-native package to 0.69

There is an incompatibility between react-native-reanimated 2.8.0 and react-native 0.69.0 till now.

There is another incompatibility between Expo 45.0.0 and react-native 0.69.0,
The Expo team is working to support RN 0.69.0 based on this PR.
So we need to wait till the expo update.
@keithluchtel Regarding monorepo approach can we downgrade the box app to RN 0.68.2 or do you prefer we wait until the expo update to merge the apps in a monorepo?

@ghorbani-m we can look at downgrading the other apps. I'd suggest getting fotos to at least 68.2 and doing that upgrade first. If Expo isn't ready by then, I'll handle downgrading the monorepo.

@keithluchtel I agree, will upgrade Fotos to 0.68.2


Add quicklogic-vtr and quicklogic-vtr-gui recipes for Linux

These are exactly the same as in the current master of https://github.com/QuickLogic-Corp/ql_conda_eda
Difference with SymbiFlow versions of vtr lies mostly in using master instead of master+wip branch of the source repository.

It turned out QuickLogic's vtr is compatible with the mainline vtr repository. Adding these packages while there is a vtr package built based on mainline repository seems pointless.

@ajelinski -- Can we create a "dummy" package which just installs the upstream vtr?

Sure, it seems possible. I will work on that.


Update S2 library within pydeck

Background

Change List

Update S2 library to correspond with core deck.gl's S2 library

Coverage remained the same at 82.986% when pulling 8f114ed5d06956d1306166fdde98cf6ca0268fa0 on ajd/pydeck-update-s2-lib into ed58a63728b3fea6f00c1f418cc6cea6e40a25cd on master.


items_count_limit does not work

Brief bug description
I am attempting to modify an existing content type and add a linked items with a items_count_limit restriction but it does not work.
Repro steps

Make sure you have a content type you want to create a migration to add a new linked items item.
For the value of the modification, add items_count_limit. Specify the condition and value.
Compile the TypeScript migration into JavaScript.
Run the migration with kontent migration run -n test -e DEV.
Check your Kentico project to see the results.
Notice the items_count_limit had no effect.

Expected behavior
I expect the items_count_limit restriction to apply.
Additional context
Below is my migration code.
const migration: MigrationModule = {
  order: 1,
  run: async apiClient => {
    await apiClient
      .addContentType()
      .withData(BuildChecklistItemType)
      .toPromise()

    await apiClient
      .modifyContentType()
      .byTypeCodename('checklist')
      .withData(ChecklistModification)
      .toPromise()
  },
}

const BuildChecklistItemType = (
  builder: ContentTypeElementsBuilder,
): ContentTypeModels.IAddContentTypeData => ({
  codename: 'checklist_item_1',
  elements: [
    builder.textElement({
      codename: 'text',
      is_required: true,
      name: 'Text',
      type: 'text',
    }),
  ],
  name: 'Checklist Item 1',
})

const ChecklistModification: ContentTypeModels.IModifyContentTypeData[] = [
  {
    op: 'addInto',
    path: '/elements',
    value: {
      allowed_content_types: [
        {
          codename: 'checklist_item_1',
        },
      ],
      codename: 'items_1',
      is_required: true,
      items_count_limit: { // LOOK HERE
        condition: 'exactly',
        value: 4,
      },
      name: 'Items 1',
      type: ElementModels.ElementType.modularContent,
    },
  },
]

Here is the result in Kentico:

Everything worked as expected except the items_count_limit.
Please let me know if I can provide any additional information. Thank you! :)

Hi,
accoring to documentation you are using incorrect name of property items_count_limit
Try to set item_count_limit instead of items_count_limit

@michalpaukert Goodness, I totally missed this! Thanks for clearing that up. I got confused because this is what the linked items interface looks like from kontent-management:
interface ILinkedItemsInType extends IElementInContentType {
    items_count_limit: {
        value: number;
        condition: 'at_most' | 'exactly' | 'at_least';
    };
    allowed_content_types?: SharedContracts.IReferenceObjectContract[];
    name: string;
    guidelines?: string;
    type: 'modular_content';
    codename?: string;
    external_id?: string;
    content_group?: SharedContracts.IReferenceObjectContract;
}

Thanks again for clearing that up though! :)


Roll Flutter from 47b5ed3948e8 to 8fe895dc95f9 (41 revisions)

Roll Flutter from 47b5ed3948e8 to 8fe895dc95f9 (41 revisions)
https://github.com/flutter/flutter/compare/47b5ed3948e8...8fe895dc95f9
2022-02-28<EMAIL_ADDRESS>Roll Plugins from 351415caa735 to f96d633e7a54 (3 revisions) (flutter/flutter#99275)
2022-02-28<EMAIL_ADDRESS>Roll Engine from 4c00976e8602 to efd538065a78 (1 revision) (flutter/flutter#99267)
2022-02-28<EMAIL_ADDRESS>Roll Engine from 05d1b5a66b8a to 4c00976e8602 (1 revision) (flutter/flutter#99262)
2022-02-28<EMAIL_ADDRESS>Roll Engine from 97e2689b7b1d to 05d1b5a66b8a (2 revisions) (flutter/flutter#99258)
2022-02-28<EMAIL_ADDRESS>Roll Engine from f93dc3d7860f to 97e2689b7b1d (7 revisions) (flutter/flutter#99251)
2022-02-27<EMAIL_ADDRESS>Roll Engine from 0726fdc4db38 to f93dc3d7860f (1 revision) (flutter/flutter#99216)
2022-02-26<EMAIL_ADDRESS>Roll Engine from 5d190bb7f598 to 0726fdc4db38 (6 revisions) (flutter/flutter#99213)
2022-02-26<EMAIL_ADDRESS>Roll Engine from 729f5b2ac016 to 5d190bb7f598 (1 revision) (flutter/flutter#99193)
2022-02-26<EMAIL_ADDRESS>Work around VS CMake generation bug (flutter/flutter#98945)
2022-02-26<EMAIL_ADDRESS>Roll Engine from 1012ac4b5af7 to 729f5b2ac016 (42 revisions) (flutter/flutter#99190)
2022-02-25<EMAIL_ADDRESS>[flutter_conductor] log to stderr but do not crash conductor if branch name validation fails (flutter/flutter#99181)
2022-02-25<EMAIL_ADDRESS>added wotw links for Baseline and GestureDetector (flutter/flutter#99178)
2022-02-25<EMAIL_ADDRESS>Run update-packages (flutter/flutter#99038)
2022-02-25<EMAIL_ADDRESS>Use flutter pub instead of dart pub (flutter/flutter#99159)
2022-02-25<EMAIL_ADDRESS>Deflake Mac module_test_ios (flutter/flutter#99009)
2022-02-25<EMAIL_ADDRESS>Add clipBehavior to Snackbar (flutter/flutter#98252)
2022-02-25<EMAIL_ADDRESS>Roll Plugins from 6d88e3a2a184 to 351415caa735 (8 revisions) (flutter/flutter#99156)
2022-02-25<EMAIL_ADDRESS>[ReorderableListView] Add footer (flutter/flutter#92086)
2022-02-25<EMAIL_ADDRESS>Do not crash if dispatch the mouse events before the tooltip overlay detached (flutter/flutter#97268)
2022-02-25<EMAIL_ADDRESS>Re-land Assert golden files use the right extension (flutter/flutter#99082)
2022-02-25<EMAIL_ADDRESS>[framework] Provide gesture settings to regular gesture detectors (flutter/flutter#99081)
2022-02-25<EMAIL_ADDRESS>Marks Linux_android android_picture_cache_complexity_scoring_perf__timeline_summary to be unflaky (flutter/flutter#98989)
2022-02-25<EMAIL_ADDRESS>Fix a Tabs crash when change the TabControllers (flutter/flutter#98242)
2022-02-25<EMAIL_ADDRESS>use dart pub deps to analyze consumer dependencies (flutter/flutter#99079)
2022-02-25<EMAIL_ADDRESS>adds trackRadius to ScrollbarPainter and RawScrollbar (flutter/flutter#98018)
2022-02-25<EMAIL_ADDRESS>Wait for ios-deploy stdout before closing logLine stream (flutter/flutter#99041)
2022-02-25<EMAIL_ADDRESS>Correct font weight for Cupertino tab label (flutter/flutter#90109)
2022-02-25<EMAIL_ADDRESS>Fix samples so that they present properly in the docs (flutter/flutter#97224)
2022-02-25<EMAIL_ADDRESS>[dap] Don't use --start-paused when running in Profile/Release mode (flutter/flutter#98926)
2022-02-24<EMAIL_ADDRESS>reads min/target sdk versions from localproperties (flutter/flutter#98450)
2022-02-24<EMAIL_ADDRESS>Increase recommended CocoaPods version to 1.11 (flutter/flutter#98621)
2022-02-24<EMAIL_ADDRESS>Pasting collapses the selection and puts it after the pasted content (flutter/flutter#98679)
2022-02-24<EMAIL_ADDRESS>Revert "Assert golden files use the right extension (#99016)" (flutter/flutter#99075)
2022-02-24<EMAIL_ADDRESS>Assert golden files use the right extension (flutter/flutter#99016)
2022-02-24<EMAIL_ADDRESS>Remove cli_utils from allow-list (flutter/flutter#99037)
2022-02-24<EMAIL_ADDRESS>Call bringIntoView after RenderEditable updates on paste (flutter/flutter#98604)
2022-02-24<EMAIL_ADDRESS>Update Xcode version to 13a233 (flutter/flutter#98297)
2022-02-23<EMAIL_ADDRESS>Bump github/codeql-action from 1.1.2 to 1.1.3 (flutter/flutter#99026)
2022-02-23<EMAIL_ADDRESS>Draggable can be accepted when the data is null (flutter/flutter#97355)
2022-02-23<EMAIL_ADDRESS>Use int for PlaceholderSpan.placeholderCodeUnit (flutter/flutter#98971)
2022-02-23<EMAIL_ADDRESS>Skip can validate flutter version in parallel test in Linux web_tool_tests (flutter/flutter#99017)
If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-plugins
Please CC<EMAIL_ADDRESS>on the revert to ensure that a human
...

Commit queue failed; closing this roll.


Avoid WithConn when possible with Redis Cluster

Calling Do on a *Cluster currently always wraps the Action with WithConn.
https://github.com/mediocregopher/radix.v3/blob/6501e39a206c4e65228f6a05aac97d1fdd66d1ef/cluster.go#L332-L345
From my understanding of the code and the Redis Cluster protocol, the WithConn is only necessary when also sending the ASKING command. That means for most calls the WithConn does basically nothing and can be skipped unless ask == true.
Although calling WithConn does not hurt correctness, it still hurts allocations quite a bit, which can be seen when changing doInner to only call WithConn when ask == true.
Since I'm not that familiar with the Redis Cluster protocol / logic I wanted to double check that my understanding here is correct, before making a change.
Here's a diff that makes the WithConn call optional and adds a benchmark for the Cluster.Do implementation.
diff --git a/cluster.go b/cluster.go
index 4fb8c08..1a93f8e 100644
--- a/cluster.go
+++ b/cluster.go
@@ -323,14 +323,17 @@ func (c *Cluster) doInner(a Action, addr, key string, ask bool, attempts int) er
                return err
        }

-       err = p.Do(WithConn(key, func(conn Conn) error {
-               if ask {
+       if ask {
+               err = p.Do(WithConn(key, func(conn Conn) error {
                        if err := conn.Do(Cmd(nil, "ASKING")); err != nil {
                                return err
                        }
-               }
-               return conn.Do(a)
-       }))
+
+                       return conn.Do(a)
+               }))
+       } else {
+               err = p.Do(a)
+       }

        if err == nil {
                return nil
diff --git a/cluster_test.go b/cluster_test.go
index 6c84ffe..94365c5 100644
--- a/cluster_test.go
+++ b/cluster_test.go
@@ -136,6 +136,19 @@ func TestClusterDo(t *T) {
        }
 }

+func BenchmarkClusterDo(b *B) {
+       c, _ := newTestCluster()
+
+       k, v := clusterSlotKeys[0], randStr()
+       require.Nil(b, c.Do(Cmd(nil, "SET", k, v)))
+
+       b.ResetTimer()
+
+       for i := 0; i < b.N; i++ {
+               require.Nil(b, c.Do(Cmd(nil, "GET", k)))
+       }
+}
+
 func TestClusterWithPrimaries(t *T) {
        c, _ := newTestCluster()
        var topo ClusterTopo

Benchmark results with (benchstat):
name         old time/op    new time/op    delta
ClusterDo-8    5.59µs ± 1%    5.60µs ± 3%     ~     (p=0.434 n=9+10)

name         old alloc/op   new alloc/op   delta
ClusterDo-8    4.85kB ± 0%    4.78kB ± 0%   -1.37%  (p=0.000 n=9+9)

name         old allocs/op  new allocs/op  delta
ClusterDo-8      20.0 ± 0%      17.0 ± 0%  -15.00%  (p=0.000 n=10+10)

Using a real Redis Cluster the allocation difference is the same (the total number of allocations is much lower in both cases, but there are still 3 allocations saved).

Yup, that seems right to me. If you wanna submit a PR for it that'd be awesome, only thing I'd ask is to add a comment at the new if statement explaining that it's differentiated for performance reasons.


Reconcile seeds.rb with recent schema changes.

oss_license_* -> floss_license_*
repo_url_status -> repo_public_status
oss* -> floss*

I tested that my modified install-badge-dev-env (separate PR pending) successfully completes and allows me to launch a local test server.

I hope this kind of mistake won't happen again in the future, since I've now modified the documentation to make it clear that changing schemas should include examining seed.db.


Configurations were removed when NPM was updated by Watchtower!

Hi there,
I love NPM. It helps me to avoid lots of headaches when configuring proxies for different domains.
FYI, I use Portainer to deploy NPM. Everything is perfect. Yet, when Watchtower silently updated NPM, all of my data/configurations were gone. There must be something wrong with my way of using NPM or Watchtower.
I would love to hear from you.
Cheer.

Persistent data should be saved on the host, not inside the container.  So I don't think Watchtower removed the data from the host.
Did you have a volume mapping configured for the /config folder ?

Thanks for your comment @jlesage
The persistent data should be kept on the host, I know that. So there could be something wrong with the way I run NPM. I often use Portainer to manage docker. I think I have already configured it correctly as in the image attached:

Which Docker image are you using?

I am using this one https://hub.docker.com/r/jc21/nginx-proxy-manager

Ok, for this image, you should report the issue at https://github.com/jc21/nginx-proxy-manager/issues instead.

thanks @jlesage .


Fix convince browsers to download files rather than rendering inline

When in /DebugConsole, convince browsers to download files rather than rendering inline.
See issue https://github.com/projectkudu/kudu/issues/1634
Content-Disposition: attachment is now present in response from /api/vfs:
(i.e. https://sitename.scm.azurewebsites.net/api/vfs/LogFiles/log.xml)
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 851
Content-Type: application/xml
[...]
Content-Disposition: attachment
[...]

A bit offtopic, i renamed VerifyDeployment() to VerifyDeploymentAsync().

Appending "Async" is not required but is the convention when writing asynchronous methods. (http://www.asp.net/mvc/overview/performance/using-asynchronous-methods-in-aspnet-mvc-4)

Hi @snobu, I'm your friendly neighborhood .NET Foundation Pull Request Bot (You can call me DNFBOT). Thanks for your contribution!
You've already signed the contribution license agreement. Thanks!
The agreement was validated by .NET Foundation and real humans are currently evaluating your PR.
TTYL, DNFBOT;


[QUERY] EnableAmqpLinkRedirect not supported in connection string?

I'm using a Connection string to connect with the Azure Event Hub.
In order to avoid the usage of TCP ports 104XX Microsoft has documented to turn the EnableAmqpLinkRedirect property to false. The default is True
The EventHubsConnectionStringBuilder does not have this property at all. And the ServiceBusConnectionStringBuilder creates a connection string that the EventHubClient does not accept.
So... how do I then disable this flag in order to avoid the usage of port 104xx ?
The following sample code has both connection string builders
// var s =  new Microsoft.ServiceBus.ServiceBusConnectionStringBuilder(azureEventHubOption.EventHubConnectionString)
            var s = new EventHubsConnectionStringBuilder(azureEventHubOption.EventHubConnectionString)
            {
                EntityPath = azureEventHubOption.EventHubName,
                /* EnableAmqpLinkRedirect is not accepted as a valid connection string
                 Maybe future versions will allow this

                EnableAmqpLinkRedirect = azureEventHubOption.EnableAmqpLinkRedirect
                */
            };

            var eventHubClient = EventHubClient.CreateFromConnectionString(s.ToString());

System.ArgumentException
  HResult=0x80070057
  Message=Illegal connection string parameter name 'EnableAmqpLinkRedirect'
Parameter name: connectionString
  Source=Microsoft.Azure.EventHubs
  StackTrace:
   at Microsoft.Azure.EventHubs.EventHubsConnectionStringBuilder.ParseConnectionString(String connectionString)
   at Microsoft.Azure.EventHubs.EventHubsConnectionStringBuilder..ctor(String connectionString)
   at Microsoft.Azure.EventHubs.EventHubClient.CreateFromConnectionString(String connectionString)
   at Nodinite.LogAgent.PickupService.Helpers.AzureEventHubHelper.GetEventHubClient() in C:\Projects\Nodinite\LogAgent.PickupService\Nodinite.LogAgent.PickupService\Helpers\EventHubHelper.cs:line 59

Hi @zodapoplinsky.  We're sorry that you're experiencing difficulties and appreciate you reaching out to let us know.
If I understand the context of your question, it looks as if you're using the Microsoft.Azure.EventHubs library, and are looking to disable the EnableAmqpLinkRedirect feature that the  Microsoft.ServiceBus.Messaging provided.  My understanding is that feature was not included in Microsoft.Azure.EventHubs and, thus, there is no need to disable it.   I'll defer to @serkantkaraca and @JamesBirdsall as the authoritative voices, should they have additional thoughts to offer or my understanding is not correct.
May I ask if this is something that you were looking to do preemptively or if you're looking to make this adjustment in response to a problem that you're running into?

Hi, please review the following documentation
I would like to limit the number of ports used for the EventHub and from what I can read, this feature should exists for the eventhub.
In my code example I'm testing both the  ServiceBusConnectionStringBuilder and the EventHubsConnectionStringBuilder
None of the provides a connection string that the EventHubClient class accepts

Thank you for the additional context.
To clarify, the feature exists within the Event Hubs service, but a client must opt-in.  It works by establishing a connection to the Event Hubs gateway using the standard AMQP ports (5671, 5672) and requesting that the service provide discovery for partition nodes to directly connect, which is where the 104xx port range would be used.
The client must take action should the service provide that information, it isn't something that the service can perform directly.   While this was behavior that the Microsoft.ServiceBus.Messaging client contained, this functionality does not exist in the Microsoft.Azure.EventHubs client for .NET.
As a result, there is nothing to disable within the Microsoft.Azure.EventHubs client, and you should only be seeing Event Hubs traffic over the standard AMQP ports.

According to this part of the documentation. The Client can control this behaviour by the usage of the EnableAmqpLinkRedirect property.
If this is not a bug, then at least it's a feature request to get the same functionality for the client in the Microsoft.Azure.EventHubs  as for Microsoft.ServiceBus.Messaging

Forgive me, but I'm a bit confused as to your request.  As I understand it, you were asking to opt-out of the redirect behavior and ensure that traffic uses only the standard AMQP ports.   As mentioned, that is the behavior for the Microsoft.Azure.EventHubs library.   To be clear: Microsoft.Azure.EventHubs will NOT make use of the 104XX port range.
I'm not sure if I misunderstood your intent, you are now expressing a different ask, or you believe that there is an issue with the library that you're observing.  Would you please be so kind as to help me understand?
For wider context, the Microsoft.Azure.EventHubs library has been superseded by the Azure.Messaging.EventHubs library and is currently in maintenance mode.  The Microsoft.Azure.EventHubs will continue to be supported for the foreseeable future, but is no longer delivering new features.  The Azure.Messaging.EventHubs library is under active development and does not yet offer direct connections to partition nodes (aka AmqpLinkRedirect).   This is a feature that we are planning on and intend to add in the near term.   The design and details for support can be found [here], and the work can be tracked [here].

Ok, thanks for the clarifications


Srikanth9793

The Readme file is currently lengthy and complex, making it challenging for newcomers to comprehend how to contribute effectively to the project.
To enhance accessibility and clarity, I propose relocating the Contributing section to the beginning of the Readme file and streamlining its content where feasible.
I kindly request assistance from anyone willing to dedicate time to address this issue and improve the project's accessibility for all contributors. Thank you!

I have done changes as per the above request

README.md

Hi All,
I'm Srikanth Pynaboina, and I'm excited to join the JabRef community! I have a strong interest in open source software and also make the software accessible for every one. The main thing that attracts me in this project was its robust functionality.
I am interested to contribute to this particular issue is to enhance the readability and accessibility of our README file. I propose the updating the Contributing section of the README file which helps the new commers to easily understand how to get involved.
I am looking forward for collaborating with all of you. If anyone has any more ideas on this proposal, please feel free to share!
Best Regards,
Srikanth Pynaboina

Hi @caiton1
I'm Srikanth Pynaboina, I am interested in this particular issue in the JabRef project. I have gone through all of your contributions for this project. You have contributed the most in this project. I would greatly appreciate your insights or advice on my above proposal. Your insights and advice will help me to make the README more readable and accessible for everyone.
Thank you in advance for all your insights and advices I am looking forward to collaborating with you and rest of the community for this improvement.
Best regards,
Srikanth Pynaboina


Cutting the power cable of an airlock in a blackout event restores power to the door

Description
Ditto
Reproduction
Start the event where power goes off, wait for it to affect an airlock, cut one power wire and then power comes back and the door is useable again
Additional context
I don't know if this is intentional or not

I believe airlocks have two power wires, and both need to be cut to disable the door.


Icons (Models, Validator, Properties) do not appear on the sidebar.

Version of Archi, Operating System
Archi 4.2, Win7
Expected Behaviour
Icons (Models, Validator, Properties) appear on the sidebar.
Actual Behaviour
Icons (Models, Validator, Properties) replaced with red square on it's sidebar. Just hide/show by Alt+1, Alt+2, Alt+8 can reload correct image.
Steps to Reproduce the Behaviour

Just start Archi 4.2

No idea why this is happening. Try "Window -> Reset Window Layout", if that doesn't work try "Help -> Reset to Defaults" and restart.

Can't be bothered to reply? Closed.

Oh, @Phillipus, I'm so sorry! I did not think you were expecting my answer...
After the complaint Archi began to work without problems, and I could not apply your advice.

@mdvadim No problem. (My last message didn't sound right so I deleted it ;-))


No improved performance for inserting into Reverb via multithreading

Hi, This is a follow-up from #72
I have done some profiling using the suggested solution from #72, however, I found that there is no speed-up using the suggested solution.
Here is complete repro script, I have modified a few things from the answer in #72 (including some fixes to the solution as well as making the script self-contained)
from concurrent import futures
import operator
import time

from absl import app
from absl import flags
from absl import logging
from acme import specs
from acme import types
from acme.adders import reverb as adders_reverb
from acme.testing import fakes
import numpy as np
import reverb
from reverb import rate_limiters
import tensorflow as tf
import tree

FLAGS = flags.FLAGS

def load_dataset_into_reverb(
    replay_client: reverb.Client,
    dataset: types.Transition,
    table_name: str,
    num_keep_alive_refs: int = 1,
    num_workers: int = 10,
):
    """Load offline dataset into reverb"""
    logging.info("Populating reverb with offline data")

    table_size = replay_client.server_info()[table_name].max_size
    dataset_size = tree.flatten(dataset)[0].shape[0]
    if table_size < dataset_size:
        raise ValueError(
            f"Unable to insert dataset of size {dataset_size} into table with "
            f"size {table_size}"
        )

    num_items_per_worker = dataset_size // num_workers

    def _run_worker(offset: int):
        with replay_client.trajectory_writer(num_keep_alive_refs) as writer:
            start_idx = offset * num_items_per_worker
            end_idx = min(dataset_size, (offset + 1) * num_items_per_worker)
            for i in range(start_idx, end_idx):
                blob = tree.map_structure(operator.itemgetter(i), dataset)
                writer.append(blob)
                item = tree.map_structure(operator.itemgetter(-1), writer.history)
                writer.create_item(
                    table=table_name,
                    priority=1.0,
                    trajectory=item,
                )

    start_time = time.time()
    with futures.ThreadPoolExecutor(num_workers) as executor:
        # Converting this to a list forces the futures to be resolved which
        # mean that any error raised by the workers is propagated here.
        list(executor.map(_run_worker, range(num_workers)))
    logging.info(
        "Populated reverb with offline data, time elapsed %.2f seconds",
        time.time() - start_time,
    )

def main(_):
    # Disable TF GPU
    tf.config.set_visible_devices([], "GPU")

    # environment = utils.make_environment("hopper-medium-v0", seed=0)
    environment = fakes.ContinuousEnvironment(action_dim=3, observation_dim=11)
    spec = specs.make_environment_spec(environment)

    dataset_size = int(1e5)
    dataset = types.Transition(
        observation=np.zeros(
            (dataset_size,) + spec.observations.shape, spec.observations.dtype
        ),
        next_observation=np.zeros(
            (dataset_size,) + spec.observations.shape, spec.observations.dtype
        ),
        reward=np.zeros((dataset_size,) + spec.rewards.shape, spec.rewards.dtype),
        action=np.zeros((dataset_size,) + spec.actions.shape, spec.actions.dtype),
        discount=np.zeros((dataset_size,) + spec.discounts.shape, spec.discounts.dtype),
    )
    replay_table = reverb.Table(
        name=adders_reverb.DEFAULT_PRIORITY_TABLE,
        sampler=reverb.selectors.Uniform(),
        remover=reverb.selectors.Fifo(),
        max_size=int(1e6),
        rate_limiter=rate_limiters.MinSize(1),
        signature=adders_reverb.NStepTransitionAdder.signature(environment_spec=spec),
    )
    replay_server = reverb.Server([replay_table], port=None)
    replay_client = reverb.Client(f"localhost:{replay_server.port}")
    # Load offline dataset into Reverb

    load_dataset_into_reverb(replay_client, dataset, replay_table.name, num_workers=10)

if __name__ == "__main__":
    FLAGS.logtostderr = True
    app.run(main)

It seems that the total time it takes for the loading to finish is the same whether I am using 10 workers or 1 worker. I am not sure what's happening, could this be an issue with Python's GIL?

The main source of slowness is the map between append and create_item:
tree.map_structure(operator.itemgetter(-1), writer.history)
Adding more threads doesn't help as computations run sequentially due to GIL. Actually - more threads make it run slower due to context switches.
cProfile you provided shows the main thread waiting on the workers to complete, so it doesn't tell much.

You are probably right. I will go with that then. Thanks!


chore: upgrade metal-go to 0.22.2 and fix enum type errors

The latest release of metal-go introduced true enum fields.  Previously, metal-go generated enum fields as plain strings due to a bug in openapi-generator.  Now that enum fields are generated as Go enums, we need to convert user-provided string values for those fields to the correct enum type for input and we need to convert the enum values to plain strings for output.
This updates metal-go to the latest release and addresses type errors for metal-go client code as it exists in the main branch; PRs that introduce metal-go elsewhere in the CLI may need to be updated as well before they can be merged.

The API spec for the plan type enum has NVME, but the API response has NVMe, so the plan subcommand is broken by the introduction of true enums: https://github.com/equinix/metal-cli/actions/runs/6252218404/job/16974991464#step:5:116

There were other data validation issues that I missed somehow when running these tests locally; another metal-go PR is up to remove a couple inaccurate enums from the plan spec: https://github.com/equinix-labs/metal-go/pull/156

Updated to run with<EMAIL_ADDRESS>and the end-to-end tests are passing again


Initial FPTI Networking Capability

Reason for changes

See summary of https://github.com/paypal/iOS-SDK/pull/91

Summary of changes

Add analytics specific method on HttpRequestFactory to construct HttpRequest
Add AnalyticsEventData data class to model JSON post structure
Add DeviceInspector class to perform all  app Context and build specific information extraction

Checklist

~Added a changelog entry~ Will update CHANGELOG once events are sent.

Authors
@sshropshire @scannillo @kgangineni

Also why are not the PR checks being run? maybe the PR needs to be assinged for it to work?

Also why are not the PR checks being run? maybe the PR needs to be assinged for it to work?

I'm not sure about this actually. They aren't active on this branch for some reason.


Timestamps first argument is not working in migrations

Type
Bug
Description
I'm using postgres database and the following migration produces wrong result:
knex.schema.createTable('permissions', (table) => {
  table.increments('id')
  table.string('title', 40).notNullable().unique()
  table.timestamps(true)
  table.timestamp('created_at_ts', true)
})

Expected
table.timestamps(true) should generate timestamp without time zone columns.
Current
table.timestamps(true) generates timestamp with time zone columns, no matter if true is used as the first argument.
To compare, table.timestamp('created_at_ts', true) creates correct column.

Package versions

knex 0.13.0
pg 7.1.0
node 8.1.2
postgres 9.6.3
mac os 10.12.5

Looking at the source code, it seems like this argument is used to choose between timestamp or datetime method, not the timestamp/timestamptz column type.


OpenShift 4.8.x - Prometheus cert-utils metrics down

Hi -
We are on OpenShift 4.8.35 and updated our cert-utils to 1.3.10 in all our environments.
But we are getting an alert message that the cert-utils metrics is down.
cert-utils is installed in namespace openshift-operators and not cert-utils-operator.
The endpoint is the IP and I can get those metrics per the commands you specify in the wiki, even using the service name.
But I'm getting this error:
Get "https://x.x.x.x:8443/metrics": x509: certificate is valid for cert-utils-operator-controller-manager-metrics-service.openshift-operators.svc, cert-utils-operator-controller-manager-metrics-service.openshift-operators.svc.cluster.local, not cert-utils-operator-controller-manager-metrics-service.cert-utils-operator.svc
so, i'm wondering if the problem is in the prometheus config for server_name.
  tls_config:     ca_file: /etc/prometheus/certs/secret_openshift-operators_cert-utils-operator-certs_tls.crt     server_name: cert-utils-operator-controller-manager-metrics-service.cert-utils-operator.svc     insecure_skip_verify: false
the server_name in the Prometheus config is not valid per the error message.
Can this be the problem when trying to pull metrics?

Only 12 issues listed and yet no updates?
Can someone please assist

It seems like the certificate being issued looks properly configured if the operator was installed to the openshift-operators namespace. But given that the service monitor seems to target a service in a namespace called cert-utils-operator, the DNS is not matching.
This shouldn't happen, because the template for the certificate resources takes into account the target namespace:
https://github.com/redhat-cop/cert-utils-operator/blob/v1.3.10/config/helmchart/templates/certificate.yaml
In this case, it seems that the {{ Release.Namespace }} did indeed get populated, but with the wrong namespace, which makes me think somehow Helm determined the wrong value, and I'm not exactly sure how that happened.
A few assumptions to validate:

I assume Helm is being used to provision the operator
I assume enableCertManager=true and as a result cert-manager is providing the certificate
I assume the Certificate custom resource contains dnsNames that include .openshift-operators.svc
If any of those assumptions are incorrect, please let me know. That will change my point of view.

And one (speculative) thing to try:
Assuming that Helm is confused about the target namespace, I'm curious what would happen if we were more explicit and used the --namespace flag when deploying. Perhaps that will result in the correct value substitution  for {{ Release.Namespace }}.
Thanks for your patience.

Hi @davgordo -
I did not install the cert-utils operator through Helm. I actually installed it through OperatorHub UI via the OpenShift Console.
Can I provide you with any additional information?

@davgordo -
We do have cert-manager installed and I just checked, there is no certificate for cert-utils like the one provided in https://github.com/redhat-cop/cert-utils-operator/blob/v1.3.10/config/helmchart/templates/certificate.yaml
Let me get the data your requested

Yes, so for context. When installing via Helm, we provide cert-manager support because we're making an assumption (sometimes it's a bad assumption) that users using Helm are probably targeting plain k8s.
When the target platform is OpenShift, on the other hand, there are some built-in certificate capabilities that we can leverage instead. Specifically you'll see this config in the annotations of the cert-utils-operator-controller-manager-metrics-service. Those annotation will essentially ask the platform to provide a certificate secret that matches up with the Service definition.
So with that background, I just used OLM to deploy this operator, and the result looked okay to me so far. If I decode the certificate, I see the following SANS:

cert-utils-operator-controller-manager-metrics-service.cert-utils-operator.svc
cert-utils-operator-controller-manager-metrics-service.cert-utils-operator.svc.cluster.local

Those look good because they reflect the cert-utils-operator namespace. So now I'm more curious about what the certificate data and the service annotations you are seeing in your environment.

Here is the service yaml, for DNS, how do I pull that information? I can't provide the secret since it contains certificates.
I did remove the UID and IP's below.

kind: Service
apiVersion: v1
metadata:
annotations:
service.alpha.openshift.io/serving-cert-secret-name: cert-utils-operator-certs
resourceVersion: '974328279'
name: cert-utils-operator-controller-manager-metrics-service
managedFields:
- manager: catalog
operation: Update
apiVersion: v1
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:annotations':
.: {}
'f:service.alpha.openshift.io/serving-cert-secret-name': {}
'f:labels':
.: {}
'f:control-plane': {}
'f:ownerReferences':
.: {}
.: {}
'f:apiVersion': {}
'f:blockOwnerDeletion': {}
'f:controller': {}
'f:kind': {}
'f:name': {}
'f:uid': {}
'f:spec':
'f:ports':
.: {}
'k:{"port":8443,"protocol":"TCP"}':
.: {}
'f:name': {}
'f:port': {}
'f:protocol': {}
'f:targetPort': {}
'f:selector':
.: {}
'f:control-plane': {}
'f:sessionAffinity': {}
'f:type': {}
- manager: olm
operation: Update
apiVersion: v1
time: '2022-05-11T16:59:42Z'
fieldsType: FieldsV1
fieldsV1:
'f:metadata':
'f:labels':
'f:operators.coreos.com/cert-utils-operator.openshift-operators': {}
namespace: openshift-operators
ownerReferences:
- apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
name: cert-utils-operator.v1.3.10
controller: false
blockOwnerDeletion: false
labels:
control-plane: cert-utils-operator
operators.coreos.com/cert-utils-operator.openshift-operators: ''
spec:
ports:
- name: https
protocol: TCP
port: 8443
targetPort: https
selector:
control-plane: cert-utils-operator
clusterIP: x.x.x.x
clusterIPs:
- x.x.x.x
type: ClusterIP
sessionAffinity: None
ipFamilies:
- IPv4
ipFamilyPolicy: SingleStack
status:
loadBalancer: {}

Here is the DNS output.
Downloads % openssl x509 -in cert.crt -text -noout |grep DNS
DNS:cert-utils-operator-controller-manager-metrics-service.openshift-operators.svc, DNS:cert-utils-operator-controller-manager-metrics-service.openshift-operators.svc.cluster.local
Downloads %

@davgordo  - I provided the information above. All seems right so why did Prometheus use the wrong server_name?

So I think it doesn't look right to me, because I thought this operator is installed in the cert-utils-operator namespace, and the DNS on the cert would lead me to believe that it is installed in the openshift-operators namespace.
The operator is deployed to the cert-utils-operator namespace, right? Or did I misunderstand?

@davgordo  - cert-utils is installed under openshift-operators  not cert-utils-operator - that is why i think we are running into this issue.

@davgordo - cert-utils is installed under openshift-operators  not cert-utils-operator - that is why i think we are running into this issue.

Ah hah! My apologies for misunderstanding. So Prometheus is going to search for services usually by label. We can tell it what labels to search for with ServiceMonitor configuration. I would like to see that ServiceMonitor yaml if you can provide it.
My cluster spun down, but as soon as I spin back up, I will try to specify the openshift-operators namespace when I install with OLM and try again to recreate.
Wild guess but, you don't happen to have a namespace called cert-utils-operator on the same cluster, do you? Just eliminating some variables. I'm thinking a left-over Service that wasn't cleaned up from a previous installation could cause problems.

@davgordo  No, we don't have a namespace called cert-utils-operator -- Let me check where I can pull the ServiceMonitor

@davgordo  Found it and I think this might be the problem? I bolded it below.
 Server name is wrong there. Thanks for all your help with the extra info. The problem is clear now. We'll have to do some brainstorming for a fix.

@davgordo  - Yeah! Please do keep me informed. I have many clusters with this issue that i definitely want to fix.

@cigna-asoria actually, I don't know for sure whether OLM creates that service monitor automatically... Did you all configure that, or was that provided by the operator provisioning?

@davgordo  -  No, we did not configure that. We only upgraded/installed cert-utils instances through OperatorHub UI via the OpenShift Console. My take is that OpenShift deployed it.

@cigna-asoria FYI, I know it's not an ideal fix, but I am able to modify the serverName manually and this change does not get overwritten by the operator. This might help you temporarily until we make the next release.

This issue seems to persist as the fix linked above apparently hasn't been merged, could it be re-opened?


Add random suffix to IT resource IDs to avoid collision

There have been cases of name collisions on parallel tests, so adding random suffix to avoid collision.

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

R: @Abacn

thanks! once https://github.com/GoogleCloudPlatform/DataflowTemplates/pull/1498 get in sync it once and will merge it

@Abacn @Polber what are next steps here?

Sorry did not track the progress. @Polber Could you please rebase onto latest master and fix the PreCommit ?

@Polber I think we still need this, right?


Added test which fails with custom unpacker

There's some overlap here with #4.
Data type error message was addressed in 758d550de381fc76f20333fd5628758647d23744.
Single/double support was addressed in 7e5ebdbf86f79ddc9441169ef7243e0a5f904301.