Implement capability contracts for components

Description of the problem
The biggest friction we have at the moment with halkyon is that we still have to figure out the wiring manually.
i.e. if a client service needs a backend endpoint, you need to know that the client expects to be injected an endpoint URL in an env variable and know the env name. you will also need to know the URL of the backend service to be able to inject it in the client service as an env link type
The issues I see with this are multiple:

we offer 2 types of links, why should one select one over the other? how do you make that choice? Unclear
you need to know what the client app is requiring and in what form (e.g. environment variable named FOO) but you don't currently have access to that information at the halkyon level
you need to know the url of the backend service even though that's highly dependent on how that service is deployed and then enter it manually

Proposition
Based on that, I started thinking that components should have contracts
this would also tie up with the capability concept in a more natural way
a component could define a set of required capabilities and a set of provided capabilities:

required capabilities would indicate the type of capability and how the component expect them
provided capabilities would indicate the kind of services the component is capable of providing
a component couldn't move to the running state without all its required capabilities being satisfied
we could also have optional capabilities but let's not worry about that now

So the client-server interaction would be solved the following way
client specifies: requires a REST capability (i.e. I need an endpoint to connect to) and expect the URL to be provided as ENDPOINT variable
this would be part of the component definition (syntax/semantics TBD)
this could maybe be helped with by dekorate (not sure yet)
this way, the designer of the component / app, lets the rest of the world know what the component needs to be running
On the other side, we have the backend component
there, dekorate can help quite a bit
Based on the analysis we already do on the app, we know that the app exposes endpoints, we could know on what URLs (relative to the app's context) and on what port
So we could automatically generate provided capabilities for the backend component
Now, how do things tie together?
well, when you create your app, you will want to link the client with the backend
so hal could look at provided capabilities that match the from component required capabilities and offer to create a "connection" between them
the link could then be automatically created without the user having to know about which env variable to use or how the backend URL is composed
the only thing the user will need to decide is which of the exposed URLs to use
but the rest could (and should) be quite transparent
So is this just some crazy, sleep deprived idea or could this actually make sense?
Example: for the database use case, we could generate a datasource based on the provided contract of the target capability that would be a little more complex to handle
but I could see it working though it might require smarter runtime images (i.e. we might need to be able to run code on the runtime images to do the datasource creation manipulation in a runtime-agnostic way from halkyon)
So a client component could look like:
spec:
    deploymentMode: "dev"
    runtime: "spring-boot"
    version: "2.1.6.RELEASE"
    capabilities:
      required:
        - type: "rest"
          parameters:
            - name: "expectedVar"
              value: "ENDPOINT"
      provided:
        - type: "url"
          parameters:
            - name: "context"
              value: "/foo"
            - name: "port"
              value: 8080

and the backend component:
spec:
    deploymentMode: "dev"
    runtime: "spring-boot"
    version: "2.1.6.RELEASE"
    capabilities:
      required:
        - type: "database"
          parameters:
            - name: "datasourceName"
              value: "myDB"
      provided:
        - type: "rest"
          parameters:
            - name: "context"
              value: "/api"
            - name: "port"
              value: 8080
            - name: "endpoints"
              value:
                - "/foo"
                - "/bar"

Moved the issue to the operator project instead…

I will review the ticket completely but If I follow the idea correctly, then the idea is to let a component to express if it needs something =required or if it will propose something =provided - correct ?

Yes.

How then the link will be able to work using such .spec.capabilities field ? Example ? @metacosm

To create a link, a client will need to look for capabilities providing what the client component requires. Using hal as an example, hal link would first ask you to select the component requiring a capability. It would then list all non-satisfied required capabilities (and probably also the possibility at some point to change already satisfied ones). Once selected, hal would use the required capability metadata to find matches among already known capabilities (i.e. anything with a provided field that matches what the component required looks for) and, probably in a second stage, offer the possibility to create a new matching capability, think provisioning a DB from the asking component. The user would then inspect / select among all the matches which one to link to. hal would then create a link between both component / capability using the client component's required metadata to inject the matching information in the component's deployment resource. I suspect that all of this could be done using only secrets as opposed to specifying env variables directly, i.e. a providing component would generate a capability with a secret containing all the metadata needed to consume the capability, adapted to the required metadata of the consuming component… 😅

I have 2 questions:
1. How would the endpoints provided by a component be generated? Would all the endpoints be listed and if not how would one control which ones are included?

Though we could probably list all endpoints using dekorate processing, it probably makes sense to generate only the entry point to the api e.g. context relative to app and port…

2. What happens if two different components expose the same endpoint? How would it be decided which link would be followed?

Provided capabilities are component-scoped so no risk of confusion. Also, there is no automatic linking going on, only exposed metadata. It's up to the user to select which endpoint they want to use in their app. We only provide (some) formalization on top of (right now informal) component requirements to help tools discover and help user make their choice.

I started playing with the hal and halkyon today and although I find the concept of the Link between a Component and Capability awesome, I fail to see the reasoning for a developer would use it between Component.
When I want component A to be able to "talk" to Component B, I would typically only need a URL and to keep things configurable I would typically just use an env var to set it.
In some scenaria, I might not even need to do that (see Spring profiles for example where a kubernetes profile could contain configuration that just points to the DNS of the "downstream" component).
In its current incarnation, the Link between Components is just overhead - since it doesn't provide anything additional to an env var while introducing another layer of abstraction.

IIUC, the linking part helps an architect have an overall view of the system and that is why we want it?
I am asking because from a typical developer perspective I can't really see what benefit it brings to the table.

When I want component A to be able to "talk" to Component B, I would typically only need a URL and to keep things configurable I would typically just use an env var to set it.

And how would you do that if you don't know what a component is build from, i.e. if you only know about the component, link and capability abstractions? Even if you know about the underlying resources, how would you add the env variable? It certainly is feasible but is creating a link really that far fetched (as opposed to the alternative(s))?

IIUC, the linking part helps an architect have an overall view of the system and that is why we want it?
I am asking because from a typical developer perspective I can't really see what benefit it brings to the table.

As a developer don't you want to be able to see the dependencies between your services in a more explicit way? As a developer I find it useful to know that my component depends on another one, a relation that the link makes explicit, instead of having to remember that the dependency is hidden in an environment variable with a magic URL in it.
However, I do agree that the current link implementation is sub-par in that regard. :)

It's not far fetched, it's just that it doesn't add any value.
Even if I create a link, I still have to point it to the appropriate coordinates.
For me, just having the ability to add arbitrary env vars without having to think of an extra abstraction layer would be ideal

Of course I would LOVE to be able to see the dependencies of my component.
But I don't want to have to add another abstraction layer which feels unnatural in order to do that.
If there some magical way where I could just say link component A to B without me having to do anything (in the standard case, but allow me to override if needed), then that is something I could get behind.

For me, just having the ability to add arbitrary env vars without having to think of an extra abstraction layer would be ideal

Again, how do you add env vars if the only abstractions you know are components, links or capabilities? If you know enough about k8s to be able to add env vars directly to your deployment yourself, would you care about halkyon to start with?

For me, just having the ability to add arbitrary env vars without having to think of an extra abstraction layer would be ideal

Again, how do you add env vars if the only abstractions you know are components, links or capabilities? If you know enough about k8s to be able to add env vars directly to your deployment yourself, would you care about halkyon to start with?

Of course I would since it provides a ton of more things.
Having to set an env var to change my configuration is something most devs are familiar with regardless of environment.
I don't see why deploying in Kubernetes makes a difference. If anything having the ability in hal to set my environment variable frees me from having to figure out where in massive Kubernetes Deployment YAML file I need to add it for it to actually work :)

If anything having the ability in hal to set my environment variable frees me from having to figure out where in massive Kubernetes Deployment YAML file I need to add it for it to actually work :)

And that's exactly what hal link create does, so I'm not sure what is the issue with link to add an env var?
Then again, the point of this discussion is to make links more useful so if you think something doesn't feel right, we need to improve things;

I understand that to you hal link between components seems obvious.
What I am saying is that using it instead of the well known and universaly understood concept of the env var without any additional benefit, is just creating confusion in my mind.
How am I supposed to know that when I want to simply set an env var (for pointing a configuration property - a URL in most cases to some other component) I need to use hal link?

Because the env var is simply an implementation detail of a relation / link between your component and something else? And because what you really want to do is create a link between your component and something else and NOT just create an env var? To me, the link abstraction feels appropriate in that context because I couldn't care less how the dependency is expressed as long as one, it's explicit and two, it's easy to create it (which is the point I want to improve, i.e. a user shouldn't have to even know about env var or secret).
Why would it be any different to link to capabilities? Why do you think it's more obvious to create a link to a capability? Not trying to argue, just trying to understand…

It maybe just be that the current implementation is confusing me - I can't really know for sure however.
In the case of the capability you know exactly what you need to "link" to and fully expect you would need to set multiple properties to get setup. Also, the property names for these capabilites can be somewhat standardised (or clearly documented) so the tool can provide meaningful help.
In the case of linking one component to another, I would typically only provide a URL of downstream components. Often enough, I wouldn't even have to do that since in k8s I can just use the DNS name of the service.
For the tool to provide meaningful help in this case I assume you would need to know the name of the downstream component you are linking to. But if that is the case, then as I said the user can just use the DNS name of the service.
It's possible that this concept is great and I just can't it get it through my thick skull. FWIW, I never really liked or understood the meaning of the similar concept in odo either.

Hi @arthurdm, I will look at your design proposal since there might be parallels indeed.

we're trying to solve a very similar problem.

That should be great to work together around this problematic. BTW, another puzzle piece that we should also have a look to simplify the binding is perhaps part of this project - https://github.com/redhat-developer/service-binding-operator

I am interested in your thoughts, and if this approach is something that we could have in common.

I definitively agree to have something in common

You can see examples of contracts at: https://github.com/halkyonio/operator/blob/capabilities-ng/demo/fruit-backend-sb/halkyon.yml#L34-L51 where the backend component both defines it requires a PostgreSQL DB and provides a REST endpoint which the client component consumes: https://github.com/halkyonio/operator/blob/capabilities-ng/demo/fruit-client-sb/halkyon.yml#L23-L32.
You'll notice that the client component specifies a "weird" looking env variable: https://github.com/halkyonio/operator/blob/capabilities-ng/demo/fruit-client-sb/halkyon.yml#L31-L32, this is used for the target capability to override the default name of the env var under which the backend REST endpoint URL is published. This allows the application underlying the component to avoid having to adapt to the Halkyon capability mechanism (in essense, that env variable says: "publish your endpoint url into an env var named as I'm telling you, in this case KUBERNETES_ENDPOINT_FRUIT").
Though this is not shown in the examples above, where explicit bindings are done using boundTo attributes (https://github.com/halkyonio/operator/blob/capabilities-ng/demo/fruit-client-sb/halkyon.yml#L26 and https://github.com/halkyonio/operator/blob/capabilities-ng/demo/fruit-backend-sb/halkyon.yml#L37), we also support auto-binding to a capability if only one capability matching the component's requirement exists on the cluster. While we haven't implemented it yet (and might not do so), it's also conceivable to add an auto-provision attribute for these capabilities that might support it (e.g. databases) where the target capability could be created on demand (e.g. a database would be provisioned) based on the component's requirements if no such capability already exists on the cluster.

You can see examples of contracts at: https://github.com/halkyonio/operator/blob/capabilities-ng/demo/fruit-backend-sb/halkyon.yml#L34-L51 where the backend component both defines it requires a PostgreSQL DB and provides a REST endpoint which the client component consumes: https://github.com/halkyonio/operator/blob/capabilities-ng/demo/fruit-client-sb/halkyon.yml#L23-L32.

Excellent !!

we also support auto-binding to a capability if only one capability matching the component's requirement exists on the cluster.

This mechanism should be documented/described as it represents a great feature such as Spring cloud offers too with their cf tool

to add an auto-provision attribute for these capabilities

concerning this point, I think that we should create a separate ticket explaining the strategy that we could support without too much effort
Example: If OLM is deployed and If the capability matches an existing operator (= that we could resolve using CSV labels, annotations), then we could issue a subscription.

to add an auto-provision attribute for these capabilities

concerning this point, I think that we should create a separate ticket explaining the strategy that we could support without too much effort
Example: If OLM is deployed and If the capability matches an existing operator (= that we could resolve using CSV labels, annotations), then we could issue a subscription.

That's a slightly different idea, actually. What I meant is the following use case: one component needs a DB but no capability exists for a DB. However, the kubedb capability is available (though no DB has actually been created) and so we could have halkyon create a DB instance based on the component's requirement automatically. This would go one step further above auto-linking: if no DB exists and a capability is installed that can provision instances, then create one. With the current implementation, it wouldn't require much more than an autoCreate: true field in the component's associated required capability (and some code at the operator level, of course) to get this working…

That's a slightly different idea, actually. What I meant is the following use case: one component needs a DB but no capability exists for a DB. However, the kubedb capability is available (though no DB has actually been created) and so we could have halkyon create a DB instance based on the component's requirement automatically.

I dont see why what you describe here is different from the OLM/subscription proposition described at #220 as by example a missing prometheus capability could also result into the creation of a subscription CR to tell to OLM to install it and next we could base on default parameters create the ServiceMonitor CRD needed to configure prometheus

That's a slightly different idea, actually. What I meant is the following use case: one component needs a DB but no capability exists for a DB. However, the kubedb capability is available (though no DB has actually been created) and so we could have halkyon create a DB instance based on the component's requirement automatically.

I dont see why what you describe here is different from the OLM/subscription proposition described at #220 as by example a missing prometheus capability could also result into the creation of a subscription CR to tell to OLM to install it and next we could base on default parameters create the ServiceMonitor CRD needed to configure prometheus

That's completely different :)
In the use case I describe, kubedb is already installed and working, it's just that there is no database instance. There is no need to install any operator, just create a DB instance without the user having the create a capability instance manually.
What you describe is a completely different use case where you need to install an operator.

just create a DB instance without the user having the create a capability instance manually.

So, what you describe here corresponds also to create a CR for a particular Operator in order to install the service/capability needed.

Capability
System processing it
CR created
System Operating it

Database/PostgreSQL
Plugin KubeDB
PostgreSQL CR
Kube Controller

Metrics/Prometheus
PluginPrometheus
ServiceMonitor
Prometheus Operator


FrameBuffer::new should not take a &str argument

Instead should take AsRef<Path>.
This should be a backwards compatible change.
Without this, I have to convert my path to a &str before giving it to the function.
Same concept is implemented in std::fs::File::open.

Thank you :+1:


Dev - Missing LHN

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Login the app, LHN is not observed

Expected Result:
LHN is display
Actual Result:
LHN is not display
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number:
Reproducible in staging?: Dev
Reproducible in production?: dev
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation

Expensify/Expensify Issue URL:
Issue reported by: @namhihi237
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1693415219465709
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

I cannot reproduce this issue.

Closing.


Material Long Press Text Handle Flash

The text selection handles in Material flash like crazy during a long press.  This is because the user's finger is moving ever so slightly, causing the selection to be reset even though the actual text selection hasn't changed.

Strange golden failure. It seems like the cursor is now shorter? I can't reproduce it on a device though.

TODO: Bump the versions of the 2 failing golden images once https://github.com/flutter/goldens/pull/33 is merged.  That plus the fix in the commits above should fix the failing golden tests.


Sort is disabled when serverSide is set to true

I have noticed setting serverSide: true in the options parameter will disable any sorting functionality, despite sort being set to true for all columns.
Expected Behavior
Clicking on a column should sort the table's data
Current Behavior
Right now the sort icon appears on the column headers, but it doesn't actually do anything.
I have found the exact line this issue originates from on line 927 in src/MUIDataTable.js:
if (this.options.serverSide) {
          newState = {
            ...newState,
            data: prevState.data,
            displayData: prevState.displayData,
            selectedRows: prevState.selectedRows,
          };
        } else {
          const sortedData = this.sortTable(data, index, newOrder);
          newState = {
            ...newState,
            data: sortedData.data,
            displayData: this.getDisplayData(columns, sortedData.data, prevState.filterList, prevState.searchText),
            selectedRows: sortedData.selectedRows,
            previousSelectedRow: null,
          };
        }
        return newState;

sortedData should be added to the if condition as well.

I think that's right.
ref : https://github.com/gregnb/mui-datatables/blob/master/examples/serverside-sorting/index.js

When serverSide=true, the table assumes sorting is handled on the server (ex: a table with 10k rows only displaying 10 at a time - the server would need to be involved to correctly sort). The example @wdh2100 shows how the handle this situation.


Blacksmith Cost

Since I was picking up on playing SHC I just noticed again, that the Blacksmith is the only weapon/armor crafter that costs 200g instead of 100g to build. I can't think of any reason for that as they are not even that efficient in producing gold for selling weapons (Wood is better for pure Gold gain and Armorer is faster than Blacksmith for the same gold value for swords/maces/armors.
Could it be possible to have an option in the patch that reduces the gold cost for the Blacksmith to 100g?

Or alternatively make the weapons they produce a little more expensive (especially swords)?

One thing to add: AI that have a high weapon production including Blacksmiths can run into the problem of delaying their Blacksmith until the end due to the higher gold costs, meaning everytime they have 100 gold they could build a different building than the Blacksmith.

only reason I could see for the extra cost is that the developers wanted to discourage players going straight to the top melee units (macemen for speed, swordsmen for strength) too early in the match. their plan was likely to encourage players to start with spears (100 gold for a poleturner), then move into pikes (another 100 gold for armourer), then into swords if the game goes long enough to be worth it, and finally into knights. Each level of unit is a slightly bigger step up in investment than the level before.
This progression style does work for ranged units - start with bows, then move to crossbows. I suppose you could move from there into bows+maces, then into xbows+maces if you want to extend that path a little.
If this was their plan, I like the idea, however it didnt exactly work, but maybe byburton's idea of making swords more expensive would make a progression approach a bit more practical, though i think the cost of most weapons would need to go up, or at least the buy/sell prices be more different. Right now, you just buy the weapons you need untill you have the units to secure you while you build up eco to get the weapons production up, (often selling the weapons from the earlier weapons buildings like armourers and fletchers to pay for it)

Bro... It's because he can produce two different weapons both of which resources needed are iron, unlike for other workshops. It's not like the armourer who is limited only to metal armours.

yes, but he cant do both at the same time, so that is not a valuable feature to building him.
The fact that both need iron i dont see as relevant, because iron is also more expensive, the extra cost to make iron weapons is introduced in the price of iron (iron is slower to produce than wood as well, and theres the "Opportunity Cost" of not selling it as well).
The only benefit within SHC for a blacksmith over a poleturner, is that the units that can be made with it are stronger or faster, depending which unit you are making, the downside being that its more expensive to keep running. The question is is that enough to justify doubling the cost of a blacksmith or not.

He can do both if you keep switching him. You pay extra gold for being capable of making both the weapons at will, instead of building 3 different iron-based workshops for each of the gear, but two. It's more expensive because it's iron, not wood, deal with it. Going by your logic an armourer should cost 10 wood 50 gold?
Maces are the fastest to make, swords second and metal armours are the slowest from the ironworks.
Using armourers you need like 4-5 of them for 2 iron mines. 3 mace-smiths would he enough on that situation, you pay 100-200 gold more, but 20-40 wood less.

The armourer is more expensive than the tanner.

Also bows vs xbows - bows are cheaper, same with spears vs pikes. Smith crafts cost the same.
Concluding: you can produce two weapons but they are no equal to eachother, meanwhile maces and sword pretty much are with only very little difference in terms of production speed.

Sorry, my edit obviously came in after you started responding.
Im not sure which logic of my says the armourer should drop in cost, in fact, im not arguing any logic. I
In my Edit above i pointed out that the internal logic of weapons production is inconsistent, so theres no point in justfying the cost of blacksmiths by comparing them to the other buildings.
By the two trains of thought you have produced (iron being the basis of the weapons, and the fact that he makes two weapons), the tanner would need to be decreased in cost (cows vs armorer's iron, 1 armour vs poleturner and fletchers 2 weapons). - 10wood is not close to relative to the 100gold difference for blacksmith.
By your latest edit of iron craftables being produced faster. I dont see that as relevant, it is the value of the result compared to the cost that is relevant. Are swords and maces enough more profitable than crossbows to justify doubling the startup costs - i actually dont know, but I suspect that even with the slower production time, crossbows make you more gold than swords or maces. If that is correct then the value of a blacksmith should be about the same as a fletcher in my opinion. Even if not, you are limited to how many you can build by the number of iron you have close by, whereas crossbows you can buy more wood, or, on most maps, just build more woodcutters, so due to the relative benefits, blacksmiths are only worthwhile to a certain extent, and i see that as enough of a limitation to justify an equal cost.
And the latest message, relative prices of the weapons is also not relevant. If you are looking for sale value, you set it to the more profitable weapon. You aren't going to keep going into a building and changing the weapon every 30 seconds, you are just going to set it to your needs, and leave it until your needs change

Pointless to continue on discussing. All you see is "Irrelevant", or has "no point". So yeah, no point in continuing the discussion within your world where all what makes you happy is 2+2=4 without any depth within.

lol, I do believe i was the one arguing against the 2+2=4 approach. But all good, this was a discussion on opinion anyways, You dont have to agree with me, i like to hear your views, but that doesnt mean i have to agree that your points are important to the discussion at hand.

Whatever. I just gave in points why they might cost 200 gold. Maybe it feels better on SH1 HD. You need 2 wood for a bow, and 4 wood for a crossbow there, which makes smiths 200 gold more senseworthy noticeable there, than on Crusader, I think the devs simply didn't change them, because they felt good with them as they are. Tho the wood ones seem needed to be produced faster than were on the previous game in order to match the european troops with the mercenary units gold-only cost I believe.

@Rakso69

Maces are the fastest to make, swords second and metal armours are the slowest from the ironworks.

Just to clear out some missinformation: metal armours are actually the fastest from the iron workers
Speed of the weapon production is as follows:
Iron armour : Maces : Swords
94 : 79 : 74
Video proof:
https://www.youtube.com/watch?v=LbFN8VHx-iQ&t=604s&app=desktop
Thanks for the discussion.
I for my part would say, all the weapon production buildings are good as they are besides the fletcher and the iron armourer, which should cost as much as a apothecary in my opinion, so 150 gold + 20 wood
Giving swords a different iron ratio might also be a good option: just let them be out of 2 Iron and double buy and sell price.
Honestly, i wouldnt bother with these, the main argument was already made @Truetobi91, giving the AI faster buildup for blacksmiths by lowering cost to 100 gold. I dont think thats necessarily a good thing. There is no situation the AI should rush sword/mace production anyways, so keeping it more expensive encourages the AI to play more reasonable and safe.
Peace :dancer:


[BUG] clipping creates incorrectly filled polygon geometry

Discovered a variant of #496 while investigating why a Dutch island was mysteriously disappearing at z6, but rendered fine on other levels.
https://user-images.githubusercontent.com/188935/229980662-5956801a-a83c-42d9-a743-24365ec86fc6.mov
The video is of @wipfli's map (it was the first public Planetiler source I could think of 😄), but the profile uses the same OSM water polygon source as my own, and exhibits exactly the same issue. public map link
The relevant portion of my profile is simple. There's no polygon merging or any other post processing:
    features.polygon("ocean")
      .setBufferPixels(4.0)
      .setMinZoom(6)

swiss-map's implementation is similarly simple.
I haven't dug into what exactly is happening, but looking at a tile inspector view, we can see the island is filled in (twice apparently, given the shading)

Some quick changes I tried:

Set bufferPixels to 0: no effect
Set bufferPixels to 100: no effect
Set minPixelSize to 0: no effect
Set pixelTolerance to 0.5: fixed

Here's the relevant WKT geometry.

Can you try making a minimum possible reproduction using an extract from https://app.protomaps.com/downloads/osm and share the OSM PBF + script to generate it here?
Feels like this might be a cause where buffer(0) isn't robust enough.

Did some more experimentation and was able to shrink it down to a couple test cases here https://github.com/erik/planetiler/commit/249f9b8d672b07d8b4285985b53c83a8b8df084f
The piers were a red herring. I think the problem is from this south-western part of the polygon
Current understanding for z6, inside FeatureRenderer:

GeometryCoordinateSequences.reassemblePolygons(terschelling) returns a geometry with a self-intersection in the inner ring.
GeoUtils.snapAndFixPolygon() fixes this self-intersection, but does so by filling the inner ring and returning a geometry that is not topologically valid (multipolygon with nested rings)

Thanks for digging into this @erik - I'm seeing the same thing.  The foolproof solution here would be to fix the polygon before calling snapAndFix (so I guess it would become fixAndSnap) - but in general the approach in planetiler has been to optimistically try working with the geometry first, detect if an invalid polygon causes an issue, then fail and fix it if so.  JTS precision reducer already detects and fails on most of the failure cases - Do you think there's an easy way to detect if this case has occurred? Either in planetiler, or we could make a change deeper within JTS as well.

Here's an even more minimal test case:
POLYGON(
  (
    0 0,
    2 0,
    2 1,
    0 1,
    0 0
  ),
  (
    1.19053596444428 0.9029693332377,
    1.06439281777784 0.92184484124482,
    1.42787640888855 0.8257737683016,
    0.94579086222257 0.5617504680322,
    1.19053596444428 0.9029693332377
  )
)

Before:

After:

Funny thing is if you do a pointwise precision reduction the output ends up valid

Looks like an issue might be that Orientation.isCCW returns true for that inner ring (before snapping) so JTS OverlayNG inverts it.  If JTS used Orientation.isCCWArea then the output would be what we expect.  The call chain is:
	  at org.locationtech.jts.operation.overlayng.EdgeNodingBuilder.computeDepthDelta(EdgeNodingBuilder.java:364)
	  at org.locationtech.jts.operation.overlayng.EdgeNodingBuilder.addPolygonRing(EdgeNodingBuilder.java:291)
	  at org.locationtech.jts.operation.overlayng.EdgeNodingBuilder.addPolygon(EdgeNodingBuilder.java:256)
	  at org.locationtech.jts.operation.overlayng.EdgeNodingBuilder.add(EdgeNodingBuilder.java:224)
	  at org.locationtech.jts.operation.overlayng.EdgeNodingBuilder.build(EdgeNodingBuilder.java:163)
	  at org.locationtech.jts.operation.overlayng.OverlayNG.nodeEdges(OverlayNG.java:541)
	  at org.locationtech.jts.operation.overlayng.OverlayNG.computeEdgeOverlay(OverlayNG.java:495)
	  at org.locationtech.jts.operation.overlayng.OverlayNG.getResult(OverlayNG.java:483)
	  at org.locationtech.jts.operation.overlayng.PrecisionReducer.reducePrecision(PrecisionReducer.java:62)
	  at org.locationtech.jts.precision.PrecisionReducerTransformer.reduceArea(PrecisionReducerTransformer.java:120)
	  at org.locationtech.jts.precision.PrecisionReducerTransformer.transformPolygon(PrecisionReducerTransformer.java:112)
	  at org.locationtech.jts.geom.util.GeometryTransformer.transform(GeometryTransformer.java:129)
	  at org.locationtech.jts.precision.PrecisionReducerTransformer.reduce(PrecisionReducerTransformer.java:41)
	  at org.locationtech.jts.precision.GeometryPrecisionReducer.reduce(GeometryPrecisionReducer.java:195)
	  at org.locationtech.jts.precision.GeometryPrecisionReducer.reduce(GeometryPrecisionReducer.java:83)
	  at com.onthegomap.planetiler.geo.GeoUtils.snapAndFixPolygon(GeoUtils.java:310)

Opened up an issue against JTS: https://github.com/locationtech/jts/issues/974

OK so it looks like this won't make it into JTS - our options are from fastest but least safe to slowest but most safe:

Override EdgeNodingBuilder in planetiler and change that one line to use isCCWArea
Change snapAndFixPolygon  to do an isValid check then fix if not before calling GeometryPrecisionReducer
Change  FeatureRenderer to do that same check immediately after simplifying geometries

I should run a quick check on the planet, but here are some stats testing on an r7g.metal instance on the planet:

option
ocean time
osm pass2 time
fixes this issue
prevents future GeometryPrecisionReducer issues
might prevent future SlicedGeometry issues

baseline
32s
12m29s
⛔
?
?

1
31s
11m51s
✅
?
?

2
34s
13m58s
✅
✅
?

3
2m24s
17m53s
✅
✅
✅

It looks like isCCWArea is a little faster (and more appropriate for snapping to a grid IMO).  Verifying if a polygon is valid and fixing it can get expensive for individual very complex polygons which is why doing it in snapAndFix is faster - since the size and complexity of the polygon is limited since it's already clipped to a tile boundary.
WDYT?

Since the issue seems really uncommon, I'd lean toward using one of the faster, less comprehensive fixes if possible.
Would it be feasible to collect some numbers on how many times each option catches a polygon that would be broken today? It's possible that there are more existing cases we don't know about because they're not as obvious as Terschelling.

One interesting observation on #566 is that if I run over massachusetts the old logic fixed geometries after snapAndFix failed 2,629 times, but the new logic fixes geometries after isValid fails 20,945 times - so GeometryPrecisionReducer was doing quite a bit of fixing on its own.  I'm kind of surprised that we even need to fix the geometry separately because under the covers GeometryPrecisionReducer and geometry fixer are both just calling overlayng.

@msbarry no - I don't use clipper2 at all, I use clipper 1 but 100% of polygons go through another step with wagyu ; wagyu guarantees simple and valid output with 0 exceptions I've encountered.


IntelliSense is not working

IntelliSense doesn't work. Doesn't show what's in the component, nor does it suggest component names in autocomplete (Nuxt UI installed)

What I've already tried (Did not help):

Change extension version (tried all versions)
Reinstall the extension
Install a different version of VSCode (1.88)
Reinstall VSCode
Disable all extensions and enable only vue - official

Possibly related things:
By TypeScript

By Vue Language Server

Extension: v2.0.16
VSCode: v1.89.0
OS: Windows 11
Framework: Nuxt 3

Same here after the extension update I'm getting no linting at all, no suggestions/ IntelliSense.

Extension: v2.0.16
VSCode: v1.89.0
OS: Windows 11
Framework: Quasar

I have the same problem, just going back to version 2.0.14 solves it, version 2.0.15 is also compromised

I tried all the versions that are available on the marketplace. Did not help.

Yo This is so weird I want to say something but first, did you try using any VPN or proxy to another network?
Like I mean to fix it. try and tell me.

This sounds very strange. How changing the network helps the extension, which in theory works offline.
Actually, as expected, VPN didn’t help at all.

Yeah you are right, I know this is nonsense, but for me choosing insider versions also wont work without changing my ip addr.

Are you talking about the insider version of the extension or VSCode?
I'm just not really sure what the problem is in the editor or in the extension

Can you clone https://github.com/johnsoncodehk/volar-starter and reproduce the problem locally?
If yes, can you reproduce this problem for https://github.com/johnsoncodehk/volar-starter in GitHub Codespaces?
If no, can you reproduce this problem for you project in GitHub Codespaces?

@DenisOstr the insider version of this vue extension!

Can you clone https://github.com/johnsoncodehk/volar-starter and reproduce the problem locally?
If yes, can you reproduce this problem for https://github.com/johnsoncodehk/volar-starter in GitHub Codespaces? If no, can you reproduce this problem for you project in GitHub Codespaces?

I'll try this

Can you clone https://github.com/johnsoncodehk/volar-starter and reproduce the problem locally?
If yes, can you reproduce this problem for https://github.com/johnsoncodehk/volar-starter in GitHub Codespaces? If no, can you reproduce this problem for you project in GitHub Codespaces?

Sure, can't right now but I'll also try later

Same issue here. Seems related to vscode april's update (v1.89.0). Downgrading vscode worked for me.

I tried and got the following result:

Locally, it doesn't work either.
I can’t check it in codespaces, but I tried it in VSCode Web (with only two extensions (Vue - Official and TypeScript IntelliSense for Web)), and it doesn’t work there either

Same issue here. Seems related to vscode april's update (v1.89.0). Downgrading vscode worked for me.

I tried, but I'll try again

@arielkern Which version did you install? I tried 1.88.1 but that didn't work either

I tried VSCode version 1.88.1, it didn't work.
I tried VSCode version 1.87.2, it didn't work.
I uninstalled VSCode and everything related with it, installed both versions, it didn’t work

Update VSCode version 1.89.1, it didn't work.
Vue - Official version: v2.0.16
But, VSCode version 1.89.1 and Vue - Official version: v2.0.14 work

What exactly works and how?
For me, with versions 1.87.2 and 1.8.27 (VSCode and Vue - Official), only autocomplete worked, and sometimes it doesn’t find certain things. Intellisense also doesn't work for me (when I'm just trying to call something without starting to type. Press CTRL + Space)
On version 1.89.1 I tried all versions of Vue - Official, none worked

I've checked it now. It seems like autocomplete works on versions 1.89.1 and 2.0.16, but Intellisense doesn’t show me anything

I can exactly use autocomplete and so on, without any other changes, but I use Archlinux, I don't know if this could influence

Hello, a few minutes ago I updated to the latest version of Vue Official v2.0.17 with VS Code 1.89.1 and everything is fine.

Update to the latest version and set the tsconfig.json file to the following format
{
"CompilerOptions":{
"BaseUrl": "./",
"AllowJs": true,
"ResolveJsonModule": true,
//"Target": "ES2022",
"IsolatedModules": true,
"Strict": true,
"Paths":{
"~/*": [./*]
},
"OutDir": "./dist"
}
}

It seems that the target will cause an exception to occur

delete Vscode plugin "vetur"
use "Vue - official"

Hello everybody. I was having the same issue and none of the versions worked for me, not even downgrading the extension to 1.8.27
I found that there's a new feature in version 2 called Hybrid mode. I found this issue and it's kind of similar (I might be wrong). So, what I did was setting this new setting to typeScriptPluginOnly. Probably this is not best fix but at least, it helped me to enable IntelliSense again. So, I hope it can help you guys while this is properly fixed

I am on VSCode version v1.89.1 and Volar version v2.0.19
It doesn't seem to be able to autocomplete even basic things like auto importing ref and other components.
I don't know how I can help beyond saying what's happening to me, is there a way to get a debug log and send it here or something that will help the developers find the source of the issue?

I'm experiencing something related to this, and I would like to provide some findings in hope that makes sense to  maintainers.
I'm using Vue.JS + TypeScript, with default configs (no change regarding Vue/Volar). I'm also using Codespaces for development, so that's why I get this behavior pretty often.
Upon creation of a new Codespaces machine, after everything is installed, if I try to open a Vue file it seems everything is working, hover/IntelliSense on HTML is working fine, but once I try hover on a TypeScript variable I get nothing, and of course, not completions, etc.
Please take noticed on this VSCode status:

I've enabled language server tracing, and once I hover a simple const I get this:
[Trace - 1:30:44 PM] Received response 'textDocument/hover - (22)' in 3ms.
No result returned.

I've noticed that restarting language server, or event just closing and reopening Codespaces didn't work either.
But what I found is that, once I restarted VSCode itself (quit and reopen the application), and load the same Codespaces, and open the same file, everything seems to magically works.
One thing I've noticed is that now I'm getting a new row with TS version on VSCode status:

I hope someone can reproduce this even on local codebases, and we get to the bottom of what's going on. Maybe something related to Hybrid Mode?

When will it be, this problem will resolved?
This have always helped me, but as far as complementary functions are concerned, really, really, useless.
ref,reactive,computed... various functions exist, but ,I haven't seen any of these codes auto import in the last two years.
Until a few years ago, I was open to using the vetur extension as a transition period, but I think that time has passed.
When will this extension work properly?

Hello everybody. I was having the same issue and none of the versions worked for me, not even downgrading the extension to 1.8.27
I found that there's a new feature in version 2 called Hybrid mode. I found this issue and it's kind of similar (I might be wrong). So, what I did was setting this new setting to typeScriptPluginOnly. Probably this is not best fix but at least, it helped me to enable IntelliSense again. So, I hope it can help you guys while this is properly fixed

This also allowed me to get suggestions functioning again, unsure of what else it could have broken. It's worth noting that I received a type error when setting this value away from auto, so I've set it to false in my settings.json
  "vue.server.hybridMode": false

Hello everybody. I was having the same issue and none of the versions worked for me, not even downgrading the extension to 1.8.27
I found that there's a new feature in version 2 called Hybrid mode. I found this issue and it's kind of similar (I might be wrong). So, what I did was setting this new setting to typeScriptPluginOnly. Probably this is not best fix but at least, it helped me to enable IntelliSense again. So, I hope it can help you guys while this is properly fixed

This also allowed me to get suggestions functioning again, unsure of what else it could have broken. It's worth noting that I received a type error when setting this value away from auto, so I've set it to false in my settings.json
 "vue.server.hybridMode": false

Setting hybrid mode to false worked for me, but autocomplete for method names (vue 2 options api) doesn't seem to be working.

Closing this issue because there seem to be multiple different problems that have similar behavior. Some of them were months ago and may no longer be applicable.
Possible fixes gathered from comments:

Upgrade to the latest version
Check VPN
Check compilerOptions.target field in tsconfig.json
Set hybrid mode to "typeScriptPluginOnly" or false in extension settings - However, this is only a temporary workaround. You may still need to open a new issue with the problem you're facing.

@dalpii Thank you for providing this valuable information. I am not sure if this still happens in the latest version. If it still happens, please open a new issue. Thanks!

I'm still having issues even after checking the possible fixes listed by @KermanX.
But I took some hours today to try to anything else. Although it was hard to replicate with a sample repository, I did these tests on a project we're working on, so quite few files.
My findings are somewhat strange, and I don't even know how to create a bug for this @KermanX, or even if it's a bug here, Codespaces, or something else. So as background, we use Codespaces here with default Microsoft images and configure to install some extensions, including this one.
So, if I create a new Codespace from scratch, wait for it to finish and load things, and try to open a .vue file, I get NO IntelliSense, no matter what I do (restart Vue server command from VSCode, etc.):
https://github.com/user-attachments/assets/a5251b9f-a8a4-43c4-8c1a-12621fadfac4
But again, if I create a new Codespace from scratch, but this time keep the "Extensions" tab open on VS Code, wait for all installation to finish, making sure to see the "time to load" appear on Vue extension, and then open the same .vue file, we can see that now it's showing on status bar that is "initializing JS/TS stuff" and IntelliSense works right away:
Sorry, this video is little bit longer:
https://drive.google.com/file/d/1o5fKgwcxu46dbK32Ei7ZhrHhVXurJB8w/view?usp=share_link
I'm really not sure what's going on, but maybe something related to extension initialization?!
I hope these findings help someone with more knowledge on how VS Code extension works.


Set Filename in Configuration

I'd love to see the option to change the filenames for the monitor and workspaces file. This would help, if someone (as me) has a different "monitors.conf" file where other things for the monitor are configured.
I think adding the option to the configuration-file in .conf/nwg.displays/conf would not be that hard, and if you would like, I can take a look at it myself and open a pull-request after.  Of course, leaving the current filenames as standard so it is backwards compatible and only relevant for those how like to change the names.
Optional
another, further, idea in this direction would be to support the option to put the monitors.conf file inside a subfolder of hpyr/sway for those you like to structure their config a bit more

There exist 4 output files: ~/.config/sway/outputs, ~/.config/sway/workspaces, ~/.config/hypr/monitors.conf and ~/.config/hypr/workspaces.conf. Adding a possibility to configure a name of just one of them would be odd. As from my point of view nwg-displays is just a small part of the nwg-shell project, and work well as is, I feel no need to complicate the code for no reason. If you want to deal with it, you need to remember about all files.

I need this feature too. All hypr utilities use the same ~/.config/hypr directory and it gets messy when they are not split to sub-directories. So I put all my hyprland configs to ~/.config/hypr/hyprland directory just to make it a little bit more organized. And I would really like monitors.conf to be inside my hyprland sub-directory too.
Any chance you might reconsider adding this feature?


MINOR: remove org.apache.kafka.streams.errors.BrokerNotFoundException

BrokerNotFoundException is useless after 234ec8a8af76bfb7874dd99714a65089d6048953 was merged.
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Even if we don't throw this exception any longer, it seems to be a public API change, and thus we should rather do a KIP an first deprecate the class to remove it only later in a major release?
\cc @bbejeck WDYT?

Yeah, we should not remove public classes without a deprecation cycle.

@mjsax @ijuma Thanks for your response. I will file a KIP to deprecate it.

superseded by https://issues.apache.org/jira/browse/KAFKA-12281


Super Scaffold and test an incoming webhook

Solves the remaining problem in #453.
Joint PR

https://github.com/bullet-train-co/bullet_train-core/pull/543

We aren't running a system test, but by Super Scaffolding an incoming webhook and testing it this way, we can ensure that the scaffolder itself works.

The release test is failing as expected, but the core Super Scaffolding test is passing so we should be good to go.


issue #684 : More reliably clean up for InterruptedException in BackgroundTupleResult

This PR addresses GitHub issue: #684 .
Briefly describe the changes proposed in this PR:

Cleans up more reliably in BackgroundTupleResult when InterruptedException occurs
Removes internal synchronisation in QueueCursor for exceptions so it now uses ConcurrentLinkedQueue instead of LinkedList.

All tests pass for me after the changes.
Signed-off-by: Peter Ansell<EMAIL_ADDRESS>

The only tools I used were the Eclipse Call Hierarchy, and the Eclipse "find implementations of this method" functionality.

I will look over it again today and check, haven't been back to it in a while so will likely see something.

I also simplified the awaitTermination logic in a commit after you approved the changes (removing it and its variables entirely) by calling shutdown while we have the lock to prevent future threads which were waiting on the lock from being able to successfully submit new tasks. This was implemented by adding a new helper method, submitAndShutdown.

LGTM.

Travis passed: https://travis-ci.org/eclipse/rdf4j/builds/185652830
This patch doesn't have the elastic search test fixes so it may not pass on Hudson.


Update IAM service definitions

This is an auto-generated PR with IAM service updates.

:tada: This PR is included in version 1.1.24 :tada:
The release is available on:

Visual Studio Marketplace
GitHub release

Your semantic-release bot :package::rocket:


Link to Azure Active Directory Module goes to MS connect which has retired

It appears Azure Active Directory Module in MS connect is retired.  Should the modules from MSOnline and MSOnlineExtended be updated as well?

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

ID: d499cfa0-9a8e-37c8-4607-874d3d72ed69
Version Independent ID: 267ded1d-8e8d-3d11-44b4-3e83c70d40c8
Content: Configure server-to-server authentication from SharePoint Server to SharePoint Online
Content Source: SharePoint/SharePointServer/hybrid/configure-server-to-server-authentication.md
Service: unspecified
GitHub Login: @MikePlumleyMSFT
Microsoft Alias: mikeplum

Link fixed. Thanks for spotting that.


Invalid URL host RFC4007 (IPV6)

android 7.1
code 1:
val okclient = OkHttpClient()
 var ENDPOINT="http://[fe80::21fe:aaaa:4ffb:4ef7%wlan0]:3000/"
val request = Request.Builder()
                       .url(ENDPOINT)
                       .build();
 val response = okclient.newCall(request).execute()

error:
java.lang.IllegalArgumentException: Invalid URL host: "[fe80::21fe:aaaa:4ffb:4ef7%wlan0]"
 at okhttp3.HttpUrl$Builder.parse$lib(HttpUrl.kt:1338)

code 2:
 var ENDPOINT="http://[fe80::21fe:aaaa:4ffb:4ef7]:3000/"

error:
java.net.ConnectException: Failed to connect to /fe80::21fe:aaaa:4ffb:4ef7:3000

Previous discussion https://github.com/square/okhttp/issues/1706

The issue was security related https://github.com/square/okhttp/pull/4865
So likely we won't accept this.
There is a manual workaround using your own custom socket factory, so you aren't blocked.

What would help in general is more context on the use case, why it's required. And if other browsers and user agents support this also. Firefox, chrome, curl, python requests etc.

thanks


tikz.sty not found

Hi, I'm not that familiar with Tex or the packages so I'm having some trouble understanding what I'm supposed to do here.
I used to use moderncv and don't remember any issues like this but haven't updated in a long time.
Can anyone help explain how to fix this?
Cheers
Class moderncv Warning: "academicons requires xetex/luatex to work. Using alternatives.".

(/usr/local/texlive/2021/texmf-dist/tex/latex/moderncv/moderncviconsawesome.sty (/usr/local/texlive/2021/texmf-dist/tex/latex/fontawesome5/fontawesome5.sty (/usr/local/texlive/2021/texmf-dist/tex/latex/l3packages/l3keys2e/l3keys2e.sty) (/usr/local/texlive/2021/texmf-dist/tex/latex/fontawesome5/fontawesome5-generic-helper.sty (/usr/local/texlive/2021/texmf-dist/tex/latex/fontawesome5/fontawesome5-mapping.def)))) (/usr/local/texlive/2021/texmf-dist/tex/latex/moderncv/moderncviconstikz.sty

! LaTeX Error: File `tikz.sty' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: sty)

Enter file name:
/usr/local/texlive/2021/texmf-dist/tex/latex/moderncv/moderncviconstikz.sty:20: Emergency stop.
<read *>

l.20 \RequirePackage
                    {etoolbox}^^M
/usr/local/texlive/2021/texmf-dist/tex/latex/moderncv/moderncviconstikz.sty:20:  ==> Fatal error occurred, no output PDF file produced!
Transcript written on out/document.log.
Latexmk: Missing input file 'tikz.sty' (or dependence on it) from following:
  '! LaTeX Error: File `tikz.sty' not found.'
Collected error summary (may duplicate other messages):
  pdflatex: Command for 'pdflatex' gave return code 1
      Refer to 'out/document.log' for details
Latexmk: Use the -f option to force complete processing,
 unless error was exceeding maximum runs, or warnings treated as errors.
Latexmk: Examining 'out/document.log'
=== TeX engine is 'pdfTeX'
Latexmk: Errors, so I did not complete making targets

Can you explain how you installed moderncv? It looks like you are missing packages.
Btw, you use pdftex, consider using luatex or xetex.

I installed it using a docker image with VSCode. I think I might have figured out my problem though... I was searching for a package called Tikz but I think it was called pgf and I was looking for the wrong thing. Going to https://www.ctan.org/ and just searching for the missing thing seems to be the way to go because then it shows you the actual package name.


workload_volume object exceeds the data capacity of the performance subsystem

Describe the bug
Harvest 1.6 (via Nabox) failing to update volume data, getting the following message:
[2021-07-08 19:30:18] [WARNING] [workload_volume] update of data cache failed with reason: Aggregated instances requested for the workload_volume object exceeds the data capacity of the performance subsystem, because it includes 59680 constituent instances. With the current counter set, use the -node, -vserver, or -filter flags to include at most 39960 constituent instances in order to stay within the data capacity. Alternatively, requesting fewer counters will also reduce the required data and may allow more instances to be requested.
Environment
8 x FAS9000 with nearly 8k volumes.  Harvest 1.6 via Nabox 2.6.4

Harvest version: 1.6
Command line arguments used: not sure, however Nabox is invoking it
OS: Nabox 2.6.4 (Debian 8)
Install method: deploy OVA in ESXi 6.7
ONTAP Version: 9.5p4
Other: Nabox using NetApp SDK v9.5

To Reproduce
Install Nabox, install Harvest, install NetAPP SDK, aim at cluster, fire
Expected behavior
Hoping to not get this error, and therefore have all volume stats populated
Actual behavior
repeatedly get this error:
21-07-08 19:27:05] [NORMAL ] [main] Startup complete.  Polling for new data every [300] seconds.
[2021-07-08 19:30:18] [WARNING] [workload_volume] update of data cache failed with reason: Aggregated instances requested for the workload_volume object exceeds the data capacity of the performance subsystem, because it includes 59680 constituent instances. With the current counter set, use the -node, -vserver, or -filter flags to include at most 39960 constituent instances in order to stay within the data capacity. Alternatively, requesting fewer counters will also reduce the required data and may allow more instances to be requested.
[2021-07-08 19:30:18] [WARNING] [workload_volume] data-list update failed.
[2021-07-08 19:35:39] [WARNING] [workload_volume] update of data cache failed with reason: Aggregated instances requested for the workload_volume object exceeds the data capacity of the performance subsystem, because it includes 59680 constituent instances. With the current counter set, use the -node, -vserver, or -filter flags to include at most 39960 constituent instances in order to stay within the data capacity. Alternatively, requesting fewer counters will also reduce the required data and may allow more instances to be requested.
[2021-07-08 19:35:39] [WARNING] [workload_volume] data-list update failed.
Possible solution, workaround, fix
Tell us if there is a workaround or fix
Additional context
I'm guessing this has to do with the size of our cluster.  Probably ONTAP not provisioning the appropriate amount of 'data capacity in the performance subsystem' for a cluster with a very large number of volumes.    Assuming so, wondering if there is a way to tell Harvest to only pull 'basic' stats for volumes?   We are just interested in core things like reads/writes/etc.

hi @altmiket there have been a lot of changes in Harvest recently with the move from 1.6 to open-source. Can you try to recreate wit the latest version of Harvest 2.0 open-source?

will do - thanks!

Sorry I have moved on from that particular job and no longer have access to
the cluster.
On Wed, Aug 10, 2022 at 6:29 AM Rahul @.***> wrote:

@altmiket https://github.com/altmiket Do you see this issue in Harvest
2.0?
—
Reply to this email directly, view it on GitHub
https://github.com/NetApp/harvest/issues/294#issuecomment-1210675990,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACBKBVJ6BXCSQP2GP4DASQTVYOVD7ANCNFSM5AHIVRJQ
.
You are receiving this because you were mentioned.Message ID:
@.***>


Add binary txt option.

@kkushimoto Thanks for PR :smiley:
Just a quick question: I'm really curious of your use case with binary TXT records. Do you mind sharing it?

Thank you for reviewing my PR.

I'm really curious of your use case with binary TXT records.

I want to find a service that publish binary value txt.
I'm not good at English :sweat:

@kkushimoto Ups, didn't see your response before now. I've merged your pull request and it's now published as v3.4.0 on npm

Thank you so much!


Panic when an unexpected message is received

I noticed an issue and I can't explain why. My application was using this crate but I encountered a panic last night, inspecting the code I noticed this line: https://github.com/benashford/redis-async-rs/blob/a369e5b2fbe5f48c46c64065b89a56bcfc62eb8b/src/client/paired.rs#L134
Why there is a panic! here and not an error!? In the doc I can't see anything that says that the crate can panic in some circumstances.
Is this an expected behaviour? Can this be fixed?

This issue can only happen if, for some reason, Redis sends back more items of data than the client requests.
This can happen if certain commands, like MONITOR or SUBSCRIBE commands, are used with a PairedConnection (which is why there's a separate PubSubConnection) because those commands return unlimited amounts of data; and when this happens the connection cannot be used for general purposes, hence the need to flag the error.
I'm willing to change this, but I'm keen to avoid any hidden failures.  Ideally the consumers will be informed, but this precise error only happens at the instant where nothings listening.
Potential solutions:

Inform any later calls that the connection has errored and a new one will be required.  Downside: forces the caller to do a lot of work.

Drop and reconnect the connection automatically.  (Which is what will happen with #28)  Downside: runs the risk of the calling application never knowing that something went wrong in the first place, and therefore have a recurring difficult-to-understand bug.

Have a list of banned commands, attempting to use them in PairedConnection will pre-emptively return an error, rather than waiting for the connection to become poisoned.  Downside: will need to be continually updated with newer versions of Redis.

@benashford The version of Redis that I'm using server-side is the 3.0 and I'm only using the expected right commands for the PairedConnection and not any other command that can run in multiple data, that's the weird thing here, maybe it's a bug.
What we can do as the best solution then? A part informing the caller that an unrecoverable error has occurred? We can't panic here without reporting it in the doc so, after a filter, we have to manage the case that the client receives an unexpected message anyway without panicking.
What do you think?

Yes, that does sound like it could be a bug.  Has it only happened the once, or is it repeatable?  And if it's repeatable is it possible to extract a test case?

Unfortunately I can't try to reproduce it again because I'm running an important Telegram bot with an intensive use of SET command, running 24h a day...
I'm just using the SET command and anything else, I think that is a bug of the Redis version but this can't run in a panic client-side.
In my fork it's currently running but I'm not monitoring the error, I can do it in the next release if this can help.

@benashford I think that a panic! should be at least mentioned on the method doc but anyway, I think is not a correct behavior to panic the entire application in a library, an error is much better and let the implementer be able to handle it.


Configuration for rule "no-labels" is invalid

eslint version: 1.10.3
eslint-config-standard version: 5.0.0
eslint-plugin-promise version: 1.0.8
eslint-plugin-standard version: 1.3.1
Full error:
Error: standard:
	Configuration for rule "no-labels" is invalid:
	Value "2,[object Object]" has more items than allowed.

Referenced from: /private/tmp/immutable-redux/.eslintrc
    at validateRuleOptions (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-validator.js:102:15)
    at /private/tmp/immutable-redux/node_modules/eslint/lib/config/config-validator.js:148:13
    at Array.forEach (native)
    at Object.validate (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-validator.js:147:35)
    at load (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:390:19)
    at /private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:326:36
    at Array.reduceRight (native)
    at applyExtends (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:309:28)
    at Object.load (/private/tmp/immutable-redux/node_modules/eslint/lib/config/config-file.js:395:22)
    at loadConfig (/private/tmp/immutable-redux/node_modules/eslint/lib/config.js:74:33)

Wasn't seeing this issue with eslint-config-standard 4.x.x...

PR submitted

+1 (sorry that Github does not have a simple +1 button)

eslint-config-standard v5.0.0 is designed for use with eslint v2.0.0, which is due to be released soon.
Try updating eslint: npm install<EMAIL_ADDRESS>The release candidate (RC) version of eslint v2.0.0 is quite stable and already ready for use, IMO. But if you're conservative, I'd wait until the stable v2.0.0 release before upgrading to eslint-config-standard v5.0.0.

I use eslint 2.0.0 and islint-config-standard 5.1.0. I still get:
Error: standard:
Configuration for rule "no-labels" is invalid:
Value "2,[object Object]" has more items than allowed.
error is thrown at line 332 of eslint/lib/config/config/config-file.js

Same here, with node 5.6 but not with 4.2
https://travis-ci.org/Strider-CD/core/jobs/109235175

Please re-open this issue.

@knownasilya It looks like your issue is caused by using an old version of snazzy. You're using 2.x instead of 3.0.0.
@zmarty Not re-opening. This configuration works fine with 2.0.0. Your issue is due to eslint 1.x getting used somehow. Try updating snazzy if you use htat.

@feross yes, thanks I saw your comment in the other repo and that solved my issue. Although still having that issue with Node 5.6 and the react error with snazzy.

@knownasilya this issue? https://github.com/feross/snazzy/issues/8 let's discuss over there.

Like I said, I have the issue with 2.0.0. And 5.10. Any ideas on that?
Op 18 feb. 2016 22:37 schreef "Feross Aboukhadijeh" <
<EMAIL_ADDRESS>
@knownasilya https://github.com/knownasilya this issue? feross/snazzy#8
https://github.com/feross/snazzy/issues/8 let's discuss over there.
—
Reply to this email directly or view it on GitHub
https://github.com/feross/eslint-config-standard/issues/23#issuecomment-185933336
.

@im-martijn Can you run npm ls --depth=50 and paste what you get here?
I bet you'll find eslint 1.x somewhere in the tree.

Yes. I have<EMAIL_ADDRESS>in my package.json, but also<EMAIL_ADDRESS>and<EMAIL_ADDRESS>These both use<EMAIL_ADDRESS>Is there something I
can do about this? Must I wait until these packages start supporting eslint@
^2.0.0?
Op 18 feb. 2016 22:43 schreef "Feross Aboukhadijeh" <
<EMAIL_ADDRESS>
@im-martijn https://github.com/im-martijn Can you run npm ls --depth=50
and paste what you get here?
I bet you'll find eslint 1.x somewhere in the tree.
—
Reply to this email directly or view it on GitHub
https://github.com/feross/eslint-config-standard/issues/23#issuecomment-185935014
.

@im-martijn Yeah, gulp-eslint and mocha-eslint are using eslint 1.x to read the config file which is meant for eslint 2.x.
Why don't you just depend on the older version of eslint-config-standard? Putting in ^4.0.0` would work.

@im-martijn See https://github.com/feross/snazzy/issues/8#issuecomment-185957231. That might also be the cause of your issue, if you're using snazzy.

I had the exact same issue with Atom editor:

Turns out that the issue was that I was using global eslint installation, which was on 1.x. I fixed it by going to linter-eslint's setting and set it to use local eslint installation:

@chibicode Thanks for sharing that info. Should help future folks coming in from Google :)


Add support for ELB listener modifications

Without this change, the listeners on elb_loadbalancer resources are
marked as read-only in the type and are thus not modifiable.  This work
adds support for modifying listeners and setting the 'policy' for HTTPS
listeners to control which cipher suites are available.

Due to the change in behavior, this warrants an appropriate version bump, as some users may be relying on the notion that puppet will not modify the listeners on their ELBs.  A surprise change here may cause site outages for users that are not prepared for this change.

As listeners is "read_only" (write-once at creation, technically) I don't think there would be any existing manifests or workflows that would have different outcomes after this merged, and it would only expand the API of the module, so this should be a feature not a breaking change. Yeah @zleswomp ?

@hunner Thats right.  If manifests that are deployed with incorrect listeners, puppet is unable to change them today.  This code would allow those manifests to proceed, potentially causing a problem.  Just something for release notes.


Fix preopening dirs on Windows

As it turns out, in order to get a dir handle on Windows in Rust, you need to 1) use std::os::windows::fs::OpenOptionsExt, and 2) apply FILE_FLAG_BACKUP_SEMANTICS as one of the extended attributes. This, according to the docs, will create a handle to an existing dir, while any attempt at trying to create a dir this way will result in failure, which is what we are after AFAICT.

Can you use the resulting directory handles be used to do the equivalent of openat? From some brief perusing of the documentation, it wasn't clear whether that's supported.

Excellent question. From what I can tell, it's not directly supported using the mid-level winapi. It is however possible using the low-level Windows internal lib (winternl.h), but it's clearly stated in the docs that the lib is subject to change from a service pack to service pack (ouch!).
So, we have two options:

link and use the Windows' internal lib, and use

__kernel_entry NTSTATUS NtCreateFile(
  OUT PHANDLE           FileHandle,
  IN ACCESS_MASK        DesiredAccess,
  IN POBJECT_ATTRIBUTES ObjectAttributes,
  OUT PIO_STATUS_BLOCK  IoStatusBlock,
  IN PLARGE_INTEGER     AllocationSize,
  IN ULONG              FileAttributes,
  IN ULONG              ShareAccess,
  IN ULONG              CreateDisposition,
  IN ULONG              CreateOptions,
  IN PVOID              EaBuffer,
  IN ULONG              EaLength
);

the "root" directory can then be specified in ObjectAttributes.RootDirectory.

write our own version of openat for Windows in which we use the preopened directory handle to extract the path (GetFinalPathNameByHandleA), and manually concatenate and canonicalise desired paths onto it.

The choices don't seem too great, but the second option seems "safest" from the portability point of view, plus the API calls required to make it work are provided by winapi-rs. The first option however is appealing since we wouldn't have to deal with path calculations, but as a big drawback, we'd need to figure out how to access the Windows internal lib from Rust plus there is a high chance its behaviour would change in the next service pack release of Windows, so we'd need to keep a close eye on the releases to guarantee compatibility.
Let me know your thoughts! Later on today I think I might have a stub at 1. and see where we get with it. Having that implemented, I guess we'd almost be able to get the WASI tutorial working. :-)

Confirmed in CraneStation/wasi-common#22 that option 2. is definitely viable and seems the way to go. So, to sum up, in CraneStation/wasi-common#22, I’ve implemented the basics for a Windows equivalent of openat (see winx::file::openat) which is then used to successfully implement path_open syscall on Windows.
Given all of the above, I think we could merge this PR as is :-)

The docs for FILE_FLAG_BACKUP_SEMANTICS here say:

The file is being opened or created for a backup or restore operation. The system ensures that the calling process overrides file security checks when the process has SE_BACKUP_NAME and SE_RESTORE_NAME privileges.

Does this imply that wasi-common has to run with SE_BACKUP_NAME and/or SE_RESTORE_NAME privileges?

The docs for FILE_FLAG_BACKUP_SEMANTICS here say:

The file is being opened or created for a backup or restore operation. The system ensures that the calling process overrides file security checks when the process has SE_BACKUP_NAME and SE_RESTORE_NAME privileges.

Does this imply that wasi-common has to run with SE_BACKUP_NAME and/or SE_RESTORE_NAME privileges?

As far as I know, no. It’s an unfortunate name for a flag which historically was used only in backup situations (it seems that on Win only backup software was only ever opening handles to directories...).
Rust’s libstd also relies on this flag in order to being able to open dirs: see here.

Also, taken from the link you’ve pasted in:

To open a directory using CreateFile, specify the FILE_FLAG_BACKUP_SEMANTICS flag as part of dwFlagsAndAttributes. Appropriate security checks still apply when this flag is used without SE_BACKUP_NAME and SE_RESTORE_NAME privileges.

So, as far as I understand, the SE_BACKUP_NAME and SE_RESTORE_NAME are optional.

Ok!


HDFS-16602. Use "defined" directive along with #if

Description of PR
The #if preprocessor directive expects a boolean expression. Thus, we need to use the defined directive as well to check if the macro has been defined.
How was this patch tested?
In progress.
For code changes:

[x] Does the title or this PR starts with the corresponding JIRA issue id (e.g. 'HADOOP-17799. Your PR title ...')?
[ ] Object storage: have the integration tests been executed and the endpoint declared according to the connector-specific documentation?
[ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
[ ] If applicable, have you updated the LICENSE, LICENSE-binary, NOTICE-binary files?

:broken_heart: -1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
41m 29s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
37m 51s

trunk passed

-1 :x:
compile
0m 46s
/branch-compile-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in trunk failed.

+1 :green_heart:
mvnsite
0m 46s

trunk passed

+1 :green_heart:
shadedclient
58m 24s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 24s

the patch passed

-1 :x:
compile
0m 27s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
cc
0m 27s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
golang
0m 27s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

-1 :x:
javac
0m 27s
/patch-compile-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m 25s

the patch passed

+1 :green_heart:
shadedclient
18m 48s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

-1 :x:
unit
0m 38s
/patch-unit-hadoop-hdfs-project_hadoop-hdfs-native-client.txt
hadoop-hdfs-native-client in the patch failed.

+1 :green_heart:
asflicense
0m 52s

The patch does not generate ASF License warnings.

124m  4s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/1/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4371

Optional Tests
dupname asflicense compile cc mvnsite javac unit codespell detsecrets golang

uname
Linux 9577bc635904 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / ac6811fcd0704464c90361c78f46e7bc4617bddc

Default Java
Red Hat, Inc.-1.8.0_332-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/1/testReport/

Max. process+thread count
545 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/1/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
0m 39s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
37m 42s

trunk passed

+1 :green_heart:
compile
4m  0s

trunk passed

+1 :green_heart:
mvnsite
0m 49s

trunk passed

+1 :green_heart:
shadedclient
61m 35s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 24s

the patch passed

+1 :green_heart:
compile
3m 43s

the patch passed

+1 :green_heart:
cc
3m 43s

the patch passed

+1 :green_heart:
golang
3m 43s

the patch passed

+1 :green_heart:
javac
3m 43s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m 27s

the patch passed

+1 :green_heart:
shadedclient
19m  1s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
32m 47s

hadoop-hdfs-native-client in the patch passed.

+1 :green_heart:
asflicense
0m 49s

The patch does not generate ASF License warnings.

122m  3s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4371

Optional Tests
dupname asflicense compile cc mvnsite javac unit codespell detsecrets golang

uname
Linux 8f37b16f5a4a 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / b472514254aeaae500853979626918c80c8387b4

Default Java
Red Hat, Inc.-1.8.0_332-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/2/testReport/

Max. process+thread count
666 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/2/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
22m 58s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
23m 14s

trunk passed

+1 :green_heart:
compile
4m 12s

trunk passed

+1 :green_heart:
mvnsite
1m  4s

trunk passed

+1 :green_heart:
shadedclient
47m 55s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 32s

the patch passed

+1 :green_heart:
compile
3m 46s

the patch passed

+1 :green_heart:
cc
3m 46s

the patch passed

+1 :green_heart:
golang
3m 46s

the patch passed

+1 :green_heart:
javac
3m 46s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m 35s

the patch passed

+1 :green_heart:
shadedclient
19m 18s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
33m 12s

hadoop-hdfs-native-client in the patch passed.

+1 :green_heart:
asflicense
1m  2s

The patch does not generate ASF License warnings.

131m 46s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/2/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4371

Optional Tests
dupname asflicense compile cc mvnsite javac unit codespell detsecrets golang

uname
Linux 0700fbc3045c 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / b472514254aeaae500853979626918c80c8387b4

Default Java
Red Hat, Inc.-1.8.0_312-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/2/testReport/

Max. process+thread count
698 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/2/console

versions
git=2.27.0 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
37m 35s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
39m  1s

trunk passed

+1 :green_heart:
compile
3m 52s

trunk passed

+1 :green_heart:
mvnsite
0m 49s

trunk passed

+1 :green_heart:
shadedclient
62m 35s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 25s

the patch passed

+1 :green_heart:
compile
3m 37s

the patch passed

+1 :green_heart:
cc
3m 37s

the patch passed

+1 :green_heart:
golang
3m 37s

the patch passed

+1 :green_heart:
javac
3m 37s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m 27s

the patch passed

+1 :green_heart:
shadedclient
18m 54s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
32m 42s

hadoop-hdfs-native-client in the patch passed.

+1 :green_heart:
asflicense
0m 53s

The patch does not generate ASF License warnings.

159m 25s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4371

Optional Tests
dupname asflicense compile cc mvnsite javac unit codespell detsecrets golang

uname
Linux 5c95ffd2fd24 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2c790d4f5b7c9ae5262b62197a76b2f48f5c525b

Default Java
Red Hat, Inc.-1.8.0_332-b09

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/testReport/

Max. process+thread count
572 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/console

versions
git=2.9.5 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
21m 50s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
22m 44s

trunk passed

+1 :green_heart:
compile
4m  8s

trunk passed

+1 :green_heart:
mvnsite
1m  3s

trunk passed

+1 :green_heart:
shadedclient
47m 31s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 32s

the patch passed

+1 :green_heart:
compile
3m 40s

the patch passed

+1 :green_heart:
cc
3m 40s

the patch passed

+1 :green_heart:
golang
3m 40s

the patch passed

+1 :green_heart:
javac
3m 40s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m 36s

the patch passed

+1 :green_heart:
shadedclient
19m 11s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
33m  3s

hadoop-hdfs-native-client in the patch passed.

+1 :green_heart:
asflicense
1m  0s

The patch does not generate ASF License warnings.

129m 52s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4371

Optional Tests
dupname asflicense compile cc mvnsite javac unit codespell detsecrets golang

uname
Linux 9136a8e62055 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2c790d4f5b7c9ae5262b62197a76b2f48f5c525b

Default Java
Red Hat, Inc.-1.8.0_312-b07

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/testReport/

Max. process+thread count
549 (vs. ulimit of 5500)

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/console

versions
git=2.27.0 maven=3.6.3

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.

:confetti_ball: +1 overall

Vote
Subsystem
Runtime
Logfile
Comment

+0 :ok:
reexec
20m 45s

Docker mode activated.

_ Prechecks _

+1 :green_heart:
dupname
0m  0s

No case conflicting files found.

+0 :ok:
codespell
0m  0s

codespell was not available.

+0 :ok:
detsecrets
0m  0s

detect-secrets was not available.

+1 :green_heart:
@author
0m  0s

The patch does not contain any @author tags.

+1 :green_heart:
test4tests
0m  0s

The patch appears to include 1 new or modified test files.

_ trunk Compile Tests _

+1 :green_heart:
mvninstall
24m 22s

trunk passed

+1 :green_heart:
compile
3m 33s

trunk passed

+1 :green_heart:
mvnsite
0m 44s

trunk passed

+1 :green_heart:
shadedclient
54m 27s

branch has no errors when building and testing our client artifacts.

_ Patch Compile Tests _

+1 :green_heart:
mvninstall
0m 24s

the patch passed

+1 :green_heart:
compile
3m 13s

the patch passed

+1 :green_heart:
cc
3m 13s

the patch passed

+1 :green_heart:
golang
3m 13s

the patch passed

+1 :green_heart:
javac
3m 13s

the patch passed

+1 :green_heart:
blanks
0m  0s

The patch has no blanks issues.

+1 :green_heart:
mvnsite
0m 26s

the patch passed

+1 :green_heart:
shadedclient
26m  9s

patch has no errors when building and testing our client artifacts.

_ Other Tests _

+1 :green_heart:
unit
32m 10s

hadoop-hdfs-native-client in the patch passed.

+1 :green_heart:
asflicense
0m 47s

The patch does not generate ASF License warnings.

140m 50s

Subsystem
Report/Notes

Docker
ClientAPI=1.41 ServerAPI=1.41 base: https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/artifact/out/Dockerfile

GITHUB PR
https://github.com/apache/hadoop/pull/4371

Optional Tests
dupname asflicense compile cc mvnsite javac unit codespell detsecrets golang

uname
Linux 090bce813b0b 4.15.0-58-generic #64-Ubuntu SMP Tue Aug 6 11:12:41 UTC 2019 x86_64 GNU/Linux

Build tool
maven

Personality
dev-support/bin/hadoop.sh

git revision
trunk / 2c790d4f5b7c9ae5262b62197a76b2f48f5c525b

Default Java
Debian-11.0.15+10-post-Debian-1deb10u1

Test Results
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/testReport/

modules
C: hadoop-hdfs-project/hadoop-hdfs-native-client U: hadoop-hdfs-project/hadoop-hdfs-native-client

Console output
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4371/3/console

versions
git=2.20.1 maven=3.6.0

Powered by
Apache Yetus 0.14.0 https://yetus.apache.org

This message was automatically generated.


⚠ BroadcasTheNet has degraded performance

In f572169, BroadcasTheNet ($BTN) experienced degraded performance:

HTTP code: 200
Response time: 7993 ms

Resolved: BroadcasTheNet performance has improved in 6aae67f after 5 minutes.