NullPointerException when invoking with keyboard shortcut

Attempted to assign Gitflow: Feature Start to Ctrl+s, Ctrl+f as well as switching to Cmd+F12, (thinking perhaps it was the secondary keystroke portion that was causing an issue), but will get a NullPointerException when pressing the key combination. Using Gitflow: Feature Start through clicking the UI elements works as expected.
StackTrace
java.lang.NullPointerException
	at gitflow.GitflowConfigUtil.getFeaturePrefix(GitflowConfigUtil.java:58)
	at gitflow.actions.GitflowAction.setup(GitflowAction.java:56)
	at gitflow.actions.GitflowAction.actionPerformed(GitflowAction.java:48)
	at gitflow.actions.StartFeatureAction.actionPerformed(StartFeatureAction.java:29)
	at com.intellij.openapi.actionSystem.ex.ActionUtil$1.run(ActionUtil.java:215)
	at com.intellij.openapi.actionSystem.ex.ActionUtil.performActionDumbAware(ActionUtil.java:232)
	at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher$1.performAction(IdeKeyEventDispatcher.java:570)
	at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.a(IdeKeyEventDispatcher.java:619)
	at com.intellij.openapi.application.TransactionGuardImpl.performUserActivity(TransactionGuardImpl.java:193)
	at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.processAction(IdeKeyEventDispatcher.java:618)
	at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.b(IdeKeyEventDispatcher.java:477)
	at com.intellij.openapi.keymap.impl.IdeKeyEventDispatcher.dispatchKeyEvent(IdeKeyEventDispatcher.java:211)
	at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:633)
	at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:365)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)

happens the same when pressing alt+shift+n and selecting a task

Thanks for the reports!

I got this error in PyCharm after I switched the Project Interpreter to a virtualenv.
Now I just get a Error: Not a gitflow-enabled repo yet. Please init git flow and Error: Please have a look at the Version Control console for more details.
When I run git flow init in the terminal I get:
C:\Program Files\Git\usr\bin\git-flow: line 47: uname: command not found
C:\Program Files\Git\usr\bin\git-flow: line 76: sed: command not found
C:\Program Files\Git\usr\bin\git-flow: line 76: dirname: command not found
C:\Program Files\Git\usr\bin\git-flow: line 115: /gitflow-shFlags: No such file or directory
Hope this is helpful!

@DavidHulsmanNL If command line git-flow doesn't work then you have an issue with git flow itself - perhaps try to resolve it there?
gitflow4idea is just a front for that command line tool...
also - this is a separate issues than the OP's one with keyboard shortcuts. In the future, for new issues - please open a separate thread

@OpherV I will, thanks! (for the git flow link itself and posting a separate issue in the future :) )


MLP design in MaskEstimator

Thanks for your great work.
In the BS-RoFormer paper, the authors mention:

Each MLP layer consists of a RMS Norm layer, a fully connected layer followed by a Tanh activation, and a fully connected layer followed by a gated linear unit (GLU) layer[29].

However, your MaskEstimator implementation is somewhat different from the paper description.
Here's my implementation (I also checked the number of parameters):
class TanH(Module):
    def __init__(self, dim_in, dim_out):
        super().__init__()
        self.proj = nn.Linear(dim_in, dim_out)

    def forward(self, x):
        x = self.proj(x)
        return x.tanh()
class GLU(Module):
    def __init__(self, dim_in, dim_out):
        super().__init__()
        self.proj = nn.Linear(dim_in, dim_out * 2)

    def forward(self, x):
        x, gate = self.proj(x).chunk(2, dim=-1)
        return x * gate.sigmoid()
class MaskEstimator(Module):
    @beartype
    def __init__(
            self,
            dim,
            dim_inputs: Tuple[int, ...],
            mlp_expansion_factor = 4,
    ):
        super().__init__()
        self.dim_inputs = dim_inputs
        self.to_freqs = ModuleList([])

        for dim_in in dim_inputs:
            net = []
            net.append(TanH(dim, dim * ff_mult))
            net.append(GLU(dim * ff_mult, dim_in))
            self.to_freqs.append(nn.Sequential(*net))

    def forward(self, x):
        x = x.unbind(dim=-2)

        outs = []

        for band_features, to_freq in zip(x, self.to_freqs):
            freq_out = to_freq(band_features)
            outs.append(freq_out)

        return torch.cat(outs, dim=-1)

@YoungloLee hey Younglo
yes i think you are right
want to check 0.2.6 see if it aligns better? also, do you know if the tanh output aligns with the reals, and the glu output aligns with the imaginary? i don't have enough domain expertise to know why one mlp output is bounded between -1 and 1 while the other is not

According to the paper, tanh activation output is directly fed into the next fully connected layer with glu activation (e.g., MLP: Sequential(RMSNorm, Linear, tanh, Linear, GLU)).
I'm not certain, but it doesn't seem to be related to the real and imaginary components.. It just appears to be the authors' preference for an activation function

@lucidrains
According to the paper, tanh activation output is directly fed into the next fully connected layer with glu activation:
MLP: Sequential(RMSNorm, Linear, tanh, Linear, GLU))
I'm not certain, but those two don't seem to be related to the real and imaginary components. It just appears to be the authors' preference for an activation function

@YoungloLee ahh i totally misunderstood, thank you! i'm used to seeing swish for activation functions
ok, 0.2.8 should be accurate to the paper then!

Looks pretty well now and the parameters getting really close to the original paper but I think the RMS Norm they mentioned is still missing

@Psarpei it is taken care of at the end of the attention layers https://github.com/lucidrains/BS-RoFormer/blob/main/bs_roformer/bs_roformer.py#L302

it is standard to do a final normalization at the end of pre-normalized transformer

Aaaaah I see thanks :)


hasNewParent(true) which drastically improves performance.  Definitely needs review! :)

Minor change to node.ts so that we update the cache always in hasNewParent(true). I tried using updateCache and pass it on through to hasNewParent(updateCache) but this did not work. hence TRUE. Doubled scene rendering performance for us with this change.
The problem is that if (update) fails with the undefined behaviour, which basically means the topmost parent never gets to set  if (this._cache.parent === this.parent).  this means in computeWorldMatrix will always fail the sync test because of this topmost node.  Graphs I show for existing system basically shows nesting call as only 1 level ever, which is obviously wrong :) the working version shows a deeply nested recursion (something that needs addressing too, I would like to talk about, do you use slack? as this now takes a large chunk of processing time)
note: I grep'd all files and did not see anything calling this but the isSynchronized function. Hence felt save for now to just set the parameter to true.
so graphs,  these speak volumes.  I sample over 10 seconds.  They are named hasNewParent() or hasNewParent(true).  They are either frame time snapshot or a 10 second topdown tree view with isSynchronized() unwound so we can see recursive code nest cost (which can be fixed)
its hard to argue with same data and view setup but quite literally twice as fast.  I also have content lists of objects that were not getting parented out even though we had frozen matrices on a lot of content colliders and some other elements.  This pruned that list from 1416 items down to less than 200 for the animated tree/dancer/bear.   In this view it prunes it down to basically nothing.  So huge cost in computeWorldMatrix and therefore evaluateActiveMeshes drastically reduces but a large increase isSynchronized().
btw in these samples I deliberately chose best time from old system against worst time in new version.  I've sub 30ms for this view in the new and 120ms + for the old.  which technically I could claim 4 increase but lets keep it at the best old case and worst new case.. seems then we get no surprises :)
I've tested on validation tests seemed good, playground physics always ran 60 as well as instances. Took a lot of logging and stacktraces to figure this buggar out so hope this is a good fix! :)

I get this texture cache fail without these changes, although I should have checked pull history and seen previous errors . hopefully this will role through once those are fixed.

Well this is excellent finding!! I will merge it to give you credits but I will simply remove the parameter
For the discussion about nesting, we can just do it using a new github issue :)


API Basic Setup

Connecting API functions to a Flask API
Functions are now callable after running flask run  in the terminal.
http://<IP_ADDRESS>:5000/azur can then be called in e.g. Postman.
Example Body:
{
    "method": "hare",
    "votes": {
        "SPD": 1000000,
        "CDU": 300000,
        "GRÜNE": 100000,
        "LINKE": 50000
    },
    "num_of_seats":25
}

Decision to use POST instead of GET is questionable here?

num_of_seats zu num_seats umbenennen?


cleanup: introduce populateVolOptions(), to fill rbdVol from stage req

At present the nodeStageVolume() handle many logic of filling rbdvol
struct based on the request received and this method is complex to
follow. with this patch, filling or populating volOptions has been
segregrated and handled hence make the stage functions' job easy.
Signed-off-by: Humble Chirammal<EMAIL_ADDRESS>

/retest ci/centos/mini-e2e/k8s-1.21

@nixpanic comments are addressed. PTAL. Thanks !

/retest ci/centos/upgrade-tests-cephfs

internal/rbd/nodeserver.go

@madhu-1 done.. thanks.

@Mergifyio rebase

@nixpanic  all the comment are addressed, ptal

/retest ci/centos/mini-e2e-helm/k8s-1.20


Clarification "skip" warning

Hi! Thank you for the beautiful program :)
I have a question: I generally use this command to download music playlist from youtube

youtube-dl --extract-audio --audio-format best --embed-thumbnail --prefer-ffmpeg --no-check-certificate https://www.youtube.com/playlist?list=XXXXX

On each download I read this:

[youtube] Post-process file EXAMPLE.m4a exists, skipping

I'd like to know if the skipping action is normal and why it happens. Is there any way to "correct" this? The only way to hide it is to use -q but then I'd not see all the other information which I find useful.
Thank you again!

It's normal, YouTube already provides an audio file so that's what it downloads. It doesn't need to do anything else. If you want the audio in other format you can use --audio-format mp3or similar.
Don't use --no-check-certificate, it turns off certificate verification, so someone could manipulate the content you receive.

Perfect! Thank you very much jaimeMF!


[Bug]: The name validation logic is incorrect

ODC version
ODC 4.3.0
OB version
No related
What happened?
When editing a project, only the description information is modified, not the name. The message "The project named qym already exists. Please modify it and try again" is displayed.

What did you expect to happen?
Only modify the description information, not the project name. Do not check if the project name already exists.
How can we reproduce it (as minimally and precisely as possible)?
Select a project, click Set, do not change the name, change the description, and click Save
Anything else we need to know?
No response

pass


variant_utils: Add helpers for strv/as

We use this type extensively, so let's add some convenience API.
This should go away with glib 0.14, but that's a nontrivial port.

Let's do https://github.com/ostreedev/ostree-rs-ext/pull/53 instead


update_one with $pull

So, I'm migrating from comtihon/mongodb-erlang to this driver, as the former doesn't support proper aggregate batching.  However, while the transfer is mostly seemless, I have found an issue.
Given the following:
    update_statement = %{"$pull" => %{"address_book" => %{"id" => address_id}}}
    result = Utils.Mongo.update_one(MongoPool, @collection, filter, update_statement)

    case result do
      {:ok, %Mongo.UpdateResult{matched_count: 0}} ->
        {:error, %{reason: "Not Found"}}

      {:ok, %Mongo.UpdateResult{matched_count: 1, modified_count: 0}} ->
        {:error, %{reason: "Address not found"}}

      {:ok, %Mongo.UpdateResult{matched_count: 1, modified_count: 1} = result} ->
        :ok

If I pass an address id that doesn't exist, I would expect it to return {:error, "Address not found"} and for the address_book array to remain unchanged.  This is how it works in mongodb-erlang. However, with this library, while the address_book is indeed unchanged, I'm receiving the :ok as the UpdateResult object has modified_count set to 1.

I am not seeing the same behaviour.
I have the following information in my collection
Mongo.find(pid, "bar", %{}) |> Enum.to_list
[%{"_id" => #BSON.ObjectId<5b465928b3acd90167bb1027>,
   "list" => [%{"a" => 1}, %{"a" => 1}, %{"a" => 2}, %{"a" => 3}]}]

I then use the following
update_statement = %{"$pull" => %{list: %{a: 4}}}
Mongo.update_one(pid, "bar", %{"_id" => 12}, update_statement)
%Mongo.UpdateResult{matched_count: 0, modified_count: 0, upserted_id: nil}}

When I instead pass an empty filter to the update, which will match everything, I am getting the matched and modified counts
Mongo.update_one(pid, "bar", %{}, update_statement)
{:ok,
 %Mongo.UpdateResult{matched_count: 1, modified_count: 1, upserted_id: nil}}

Oh, no, you missed the issue.  Perform the same with a valid match in the document but no match in the $pull.  So:
Mongo.find(pid, "bar", %{}) |> Enum.to_list
[%{"_id" => #BSON.ObjectId<5b465928b3acd90167bb1027>,
   "list" => [%{"a" => 1}, %{"a" => 1}, %{"a" => 2}, %{"a" => 3}]}]
update_statement = %{"$pull" => %{list: %{a: 4}}}
Mongo.update_one(pid, "bar", %{"_id" => #BSON.ObjectId<5b465928b3acd90167bb1027>}, update_statement)
%Mongo.UpdateResult{matched_count: 1, modified_count: 1}}

It should be
%Mongo.UpdateResult{matched_count: 1, modified_count: 0}}

The point is that the document is found (matched_count: 1), but no data was updated (modified_count: 0)

Oh okay. I see the issue now. It appears that we are still using the opcodes for unawknowledged writes. We should be using commands for awknowledged writes. A little more information can be found here.

I am actually going to close this ticket because the current functionality does technically follow the spec. But I will make another in order to update to the newer commands.


Enhancement: Additional graph of (No. of infections) / (No. of tests) for each day

Need of this enhancement:
I have observe that no. of tests done vary a lot (like there is drop in testing for every 7th day) which actually distorts the way we interpret no. of infected cases .
For Ex: day1: 5 infected case when 10 tests were done, day2: 5 infected case when 5 tests were done.
There should be a graph that do not shadows the info that infection is increasing.
Solution:
Additional graph where we plot (No. of infections/ No. of tests * 100) vs time.

hi

Hey...
Any issues in understanding the requirement?
Regards,
Anshuman
On Sun, Sep 13, 2020, 10:10 PM Ayush Srivastav<EMAIL_ADDRESS>wrote:

hi
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/covid19india/covid19india-react/issues/2338#issuecomment-691694581,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFZGRAXAGG6TCHPG3G7VAZLSFTYYZANCNFSM4REIM47Q
.

I suggest this be done in the stats section over a 7 day period since number of tests are not updated regularly and are correct over larger periods of time (atleast for Mumbai)

Duplicates #2199


USHIFT-4744: Remove limits from servicemesh operator deployment

Which issue(s) this PR addresses:

Closes #

/retest

/lgtm


Particle Boron - Add a sample that uses the builtin LTE modem

Is your enhancement proposal related to a problem? Please describe.
I'm trying to use the LTE modem on the Particle Boron. The Boron seems to be pretty well supported board for quite sometime and was wondering if someone can share an example to get things off the ground for anyone new to using the LTE modem.
Describe the solution you'd like
I'd like to see a modem sample added for Particle Boron board.
Describe alternatives you've considered
I've been using the Particle DeviceOS that fully supports the Boron LTE modem and connects to their cloud. However, I'd like to run Zephyr on the Boron board and use it to access other cloud services.
Additional context

The modem on the Boron is a UBlox Sara (U2, R4 & R5) modem, have a look at the driver for supporting protocols.
Billy..

@WilliamGFish Thanks. Will do.
I have a mixture of the two Sara modem versions.
Will I be able to connect to the Particle cloud once I put Zephyr on the Boron and still use their free tier for LTE access?

@WilliamGFish Thanks. Will do.
I have a mixture of the two Sara modem versions.
Will I be able to connect to the Particle cloud once I put Zephyr on the Boron and still use their free tier for LTE access?

Two different questions:

Can zephyr connect and control the Sara modems? Absolutely.
Can you connect to the particle platform using zephyr? Now that's a question for particle.
Billy..

Are you using the Boron modem? If so, Are you connecting to a cloud service like Golioth, AWS, Nordic or other?
I’ll check with Particle but doubt very much they’ll support a Boron running Zephyr connecting to their cloud.


Model intra-frame events as deltas from frame start time

For VFX and OSVP realtime use, we would like to know intra-frame timing of the sensor exposure.
In VFX I believe this is helpful to characterize horizontal motion skew caused by rolling shutter delays.
In OSVP this helps to ensure that the (LED) display system is active while the shutter is open/active to reduce banding artifacts.
Per Tucker's comments, it does seem helpful to use the 'metadata' terminology for static data, and 'data' for dynamic fields that are expected to meaningfully change over time.
Dynamic data

Frame start time (PTP timestamp or more likely genlock sync, dynamic)

Static metadata

Offset to first line exposure start (static, float, μs)
Line exposure duration [exposure period] (static, float, μs)
Shutter skew [offset from start of first line exposure to start of last line exposure] (static, float, μs)
Number of lines (static, integer, count)
Line exposure direction (static, enum, 'bottom-to-top', 'top-to-bottom', 'left-to-right', 'right-to-left') (Note that we probably want to confirm if this is relative to the sensor, relative to the world, or other. Also need to confirm with the sensor vendors if this is a complete list, or if there is some other rolling shutter exposure scheme out there).

Note that this does not model multi-exposure "HDR" modes.
Example
2160p23.98 180° rolling shutter example (made up numbers):
41700μs total frame period =

0μs offset to exposure start
20850μs line read
4320μs shutter skew
2160 lines
top-to-bottom

=> total integration time of 20850μs + 4320μs => 25170μs
=> start delay between lines 4320μs / 2160 lines => 2μs
=> shutter closed time 41700μs - 25170μs => 16530μs

Note that I totally made up the example numbers, and general concept of what's going on here from an LED perspective. If you have sensor expertise please recommend corrections.

We should agree on what "frame start time" means, or decide that each manufacturer can define their own as long as its used consistently
If we want to be uniform, I suggest start of frame readout, rather than start of exposure, to be the frame start time.

I am trying to capture that from an IC-VFX perspective we want sensor exposures and LED display 'lit' time to line up relative to system/house sync.
You're right we likely need more definition there: what does the camera and display do relative to an incoming sync signal vs. what data/metadata is being generated in response.

To confirm, the only important information is the offset from frame start, right?
If so, why is absolute time important?

Just trying to incorporate the discussion from today re: PTP time in this data. From my perspective (ICVFX) we should likely only need to know offsets relative to a sync pulse.

Is the absolute time important for PTP to replace timecode , or are there other techniques for that?

There are definitely several approaches to this I think. If you know all the sensor parameters, and you know the exposure offset from a sync pulse (both as Ritchie said) than you can model the current status of the scan locally, even in an online context. The toolkit might have a static function that takes a struct of these values, and returns the current line being scanned and how long it's been scanning for.
Alternatively, the camera could perhaps send an 1D array of 0.0-1.0 float values that is the size of the vertical resolution, representing the exposure time of each line. This isn't far off from how some camera APIs send histograms in realtime.

@MadlyFX Any example data available?


v0.7.7

@yaichenbaum File interaction.cs was changed again by your merge and your change 9d5a59357c73100e29e94e85bbad4227ab8cc3f8 do not apply now.


Fix typos in README & comments

This is a redo of #8 which was rejected because of an issue with the CLA. I believe this should not be an issue anymore: when I visit https://cla.developers.google.com/clas it shows that I am covered under "Google Corporate CLA" agreement under name "Aril Computer Corp" signed Feb 26.

Hi Scott, thanks for fixing it, can you solve the conflict?

Rebased


vtile.toJSON viable for equality testing across operating systems

Up until v3.3.0 it was possible to do vtile2.toJSON() == vtile2.toJSON() to test the equality of vector tiles. As one example tilelive-bridge has been doing this and it has worked well to compare results to fixtures.
However starting at v3.3.0 I'm seeing that fixtures created on OS X no longer work on Linux. While the vector tiles are visually the same but the equality tests fail because the geometries are not the same. My hunch is that the simplification improvements in mapnik-vt have brought in minor changes to floating point rounding that manifest with different c++ libraries on OS X vs Linux.
The solution may be as simple as using static_cast<int>(std::floor(val + .5)) instead of just static_cast<int>(val), or it may be more involved.

I noticed this with @yhahn earlier in the process, the issue comes from the use of boost numerical_cast more then likely here:
https://github.com/mapnik/mapnik/blob/master/include/mapnik/geometry_strategy.hpp#L157-L178
I am not sure how to resolve it, as we shouldn't always floor. We could add another strategy to add floor however.

Created a branch of tl-bridge that uses 3.3.1-alpha, updated fixtures from OS X, and still failing on linux: https://travis-ci.org/mapbox/tilelive-bridge/builds/63426191.

OH GOD, so much research here:
So... our little rounding is done currently by the rounding_cast that I implemented here.
The basis of this is that it does basically the same as a numeric_cast however, provides the ability to round as well. The type of rounding is done by Float2IntRounding Policy at the end you might note:
The rounder policies supplied by this header use math functions floor() and ceil(). The standard versions of these functions are introduced in context by a using directive, so in normal conditions, the standard functions will be used.

Even rounding is a little odd perhaps, and perhaps we should switch to a truncating policy instead. If you look at the code for the Round Policy you see:
typedef mpl::integral_c<std::float_round_style,std::round_to_nearest> round_style ;
This comes from the standard library on how to round based on different types, but it gets more complex then that... So lets continue down this rabbit hole.
For double types compilers are supposed to follow IEEE 754. The wonderful part is that they don't (exactly), and GCC and Clang are allowed to do it differently especially when it comes to arithmetic. Here is a huge explanation of this on stack overflow about numeric casting and percision arithmetic. but what you want to quickly take note is the following:

There might have been a loss in precision in the doubles PRIOR to being rounded which might be the issue with arithmetic and compiler options
There might have been a loss of precision due to casting the value to and from a float at some point such that precision isn't properly carried and different casting rules apply different per compiler.
Casting to an int MIGHT have different precision rules between different compilers.

I think some of this might be a difference in -O2 and -O3 for how math is done, but not certain will have to review those flags.
In short, it might have been just luck that it turned out the same before.

currently thinking here is that we'll punt on this by checking in platform specific fixtures for tl-bridge. This will dodge the need to fully fix this now, while ensuring that any changes in fixtures are still captured (which is key).

confirmed this is fixed by:

using tl-bridge branch with new fixtures created on OS X
built node-mapnik from source on ubuntu precise 64 bit at https://github.com/mapnik/node-mapnik/commit/813bf078b44197a4bedb9d273881ca5428e18d31
ensured all tests pass on ubuntu and osx

Fixing commit was by @flippmoke but code now in use moved so the final fixing commit was https://github.com/mapnik/clipper/commit/11859d514ab72270e45937e62f411523273ed958


fix(conn): change the read err log from info to debug

Issues associated with this PR
KeepAlive connections without data transfer will frequently print timeout logs and eventually fill the disk， like:

so, need change the read err log from info to debug.
Solutions
You should show your solutions about the issues in your PR, including the overall solutions, details and the changes. At this time, Chinese is allowed to describe these.
UT result
Unit Test is needed if the code is changed, your unit test should cover boundary cases, corner cases, and some exceptional cases. And you need to show the UT result.
Benchmark
If your code involves the processing of every request, you should give the Benchmark Result.
Code Style

Make sure Goimports has run
Show Golint result

use #1513 instead. the branch develop planned to be merged into master this week

this log is delete by #1513,
and merged into master by #1527
close this pr.
thanks


[BUG] Send operation timed out when producing events to Azure eventhubs

Describe the bug
I have a long-running application that uses azure eventhub SDK (5.1.0), continually publishing data to Azure event hub. The service threw the below exception after few days. What could be the cause of this and how we can overcome this?
StackOverflow post: https://stackoverflow.com/questions/63632202/send-operation-timed-out-when-producing-events-to-azure-eventhubs
Exception or Stack Trace
Exception in thread "SendTimeout-timer" reactor.core.Exceptions$BubblingException: com.azure.core.amqp.exception.AmqpException: Entity(abc): Send operation timed out, errorContext[NAMESPACE: abc-eventhub.servicebus.windows.net, PATH: abc-metrics, REFERENCE_ID: 70288acf171a4614ab6dcfe2884ee9ec_G2S2, LINK_CREDIT: 210]
	at reactor.core.Exceptions.bubble(Exceptions.java:173)
	at reactor.core.publisher.Operators.onErrorDropped(Operators.java:612)
	at reactor.core.publisher.FluxTimeout$TimeoutMainSubscriber.onError(FluxTimeout.java:203)
	at reactor.core.publisher.MonoFlatMap$FlatMapMain.secondError(MonoFlatMap.java:185)
	at reactor.core.publisher.MonoFlatMap$FlatMapInner.onError(MonoFlatMap.java:251)
	at reactor.core.publisher.FluxHide$SuppressFuseableSubscriber.onError(FluxHide.java:132)
	at reactor.core.publisher.MonoCreate$DefaultMonoSink.error(MonoCreate.java:185)
	at com.azure.core.amqp.implementation.ReactorSender$SendTimeout.run(ReactorSender.java:565)
	at java.util.TimerThread.mainLoop(Timer.java:555)
	at java.util.TimerThread.run(Timer.java:505)
Caused by: com.azure.core.amqp.exception.AmqpException: Entity(abc-metrics): Send operation timed out, errorContext[NAMESPACE: abc-eventhub.servicebus.windows.net, PATH: abc-metrics, REFERENCE_ID: 70288acf171a4614ab6dcfe2884ee9ec_G2S2, LINK_CREDIT: 210]
	at com.azure.core.amqp.implementation.ReactorSender$SendTimeout.run(ReactorSender.java:562)
	... 2 more

Setup (please complete the following information):

Version of the Library used is 5.1.0 (Azure eventhub java SDK)

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

Thanks for filing this github issue, @madushajg.  Someone from the Event Hubs team will follow up with you shortly on this reliability issue.
/cc @conniey @srnagar @YijunXieMS

@madushajg Hey! Thanks for reporting this bug. I have a few questions:

What happens when you encounter this error?

Does the application stop working after the exception occurs?

Do you have a small snippet for how you are sending events?

If it is that single operation, you can try to resend the event. The "SendTimeout-Timer" is a timer that waits for an ACK from the Event Hubs service saying that the message was successfully received. There are times where a TimeoutException can occur, in those cases, you should try to resend the message.
Here is some documentation on possible Event Hubs exceptions.

Hi @conniey, please find my answers.

What happens when you encounter this error?

Does the application stop working after the exception occurs?

My application stopped working after the exception

Do you have a small snippet for how you are sending events?

something similar to the following
        EventHubProducerClient producer = new EventHubClientBuilder().connectionString(
                "connection_string",
                "eventhub_name"
        ).buildProducerClient();

        EventDataBatch batch = producer.createBatch();
        EventData sendEvent;
        do {
            final byte[] payloadBytes = gson.toJson("sample_data").getBytes(UTF_8);
            sendEvent = new EventData(payloadBytes);
        } while (batch.tryAdd(sendEvent));
        producer.send(batch);
        }

Here is some documentation on possible Event Hubs exceptions.

I've gone through this. But seems this does not contain any clue :/

Hey,

The send timeout is a transient error. Does it work when you attempt to send the data again?
Can you enable logs when it fails? I'm curious to understand what happens to the AMQP connection.. if it closes or if it tries to reestablish itself.

https://github.com/Azure/azure-sdk-for-java/wiki/Logging-with-Azure-SDK

For example:
EventHubProducerClient producer = new EventHubClientBuilder()
    .connectionString("connection_string","eventhub_name")
    .buildProducerClient();

EventDataBatch batch = producer.createBatch();
EventData sendEvent;

do {
    final byte[] payloadBytes = gson.toJson("sample_data").getBytes(UTF_8);
    sendEvent = new EventData(payloadBytes);
} while (batch.tryAdd(sendEvent));

boolean isSent = false;
while (!isSent) {
    try {
        producer.send(batch);
        isSent = true;
    } catch (Exception e) {
        System.out.printf("Unable to send batch: %s%n.", e);
    }
}

Thanks!

Feel free to open this issue if my sample doesn't work for you or open a new issue if something else pops up. :)


Don't Merge! PR real time test for target branch full build

Docs Build status updates of commit 8f5c988:
:clock10: Pending: waiting for processors (10 builds ahead of you)
:warning: Docs Build is busy, currently there are 10 builds ahead of this one, for more information you can view the Build queue graph on the Docs Portal.

Docs Build status updates of commit 8f5c988:
:clock10: Full build: the average full build time is 7 min(s) 45 sec(s), this is based on the last 30 build(s) for this repository.

Docs Build status updates of commit 8f5c988:
:warning: Validation status: warnings

File
Status
Preview URL
Details

docs-ref-conceptual/testing.md
:warning:Warning
View (azure-cli-latest) View (azure-cli-2017-03-09-profile) View (azure-cli-2018-03-01-hybrid)
Details

docs-ref-conceptual/testing.md

[Warning] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Warning] Missing attribute: title.
[Warning] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Warning] Missing attribute: title.
[Warning] Missing attribute: either ms.prod or ms.service is required. Use ms.prod for on-premise products, or ms.service for cloud services.
[Warning] Missing attribute: title.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Spi::enable takes Rcc as a parameter making it impossible to enable SPI after the clocks were frozen.

I think there are 2 ways to solve this

Remove the Rcc argument and access the register internally using unsafe. Serial::new does this.
Split the Rcc struct, one part which configures the clock and another part which can turn on/off the peripherals.

this one is resolved i guess, may be its ok to close


Color of Selected Search Text Same as BG in Quick Open

Expected Behavior
When I search for a file using Quick Open (CMD-P) I should be able to easily read the selected item.
Actual Behavior
The search term in the selected item is the same color as the background of the selected item so you can't easily read it.

Version: 1.57.0-insider
Commit: 541a5d4fa70ab3095f23b28b88914e1f6a8f65c4
Date: 2021-05-28T10:00:38.762Z
Electron: 12.0.9
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Darwin x64 20.4.0

same with:
Version: 1.57.0 (user setup)
Commit: b4c1bd0a9b03c749ea011b06c6d2676c8091a70c
Date: 2021-06-09T17:18:42.354Z (1 day ago)
Electron: 12.0.9
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19043

I guess its caused by Updated Quick Pick & suggest widget colors
overwriting the new values in settings.json workarounds the issue for me:

        "workbench.colorCustomizations": {
            "list.focusHighlightForeground": "#fff",
            "quickInputList.focusForeground": "#fff",
            "editorSuggestWidget.selectedForeground":"#fff",
        },

same with:
Version: 1.57.0 (user setup)
Commit: b4c1bd0a9b03c749ea011b06c6d2676c8091a70c
Date: 2021-06-09T17:18:42.354Z (1 day ago)
Electron: 12.0.9
Chrome: 89.0.4389.128
Node.js: 14.16.0
V8: <IP_ADDRESS>-electron.0
OS: Windows_NT x64 10.0.19043

I guess its caused by Updated Quick Pick & suggest widget colors
overwriting the new values in settings.json workarounds the issue for me:
        "workbench.colorCustomizations": {
            "list.focusHighlightForeground": "#fff",
            "quickInputList.focusForeground": "#fff",
            "editorSuggestWidget.selectedForeground":"#fff",
        },

I prefer "#000" since it's less strian on the eyes.

I found these to work quite well depending on your taste...
Light:
"workbench.colorCustomizations": {
    "list.focusHighlightForeground": "#f1f9fa",
    "quickInputList.focusForeground": "#f1f9fa",
    "editorSuggestWidget.selectedForeground":"#f1f9fa",
},

Dark:
"workbench.colorCustomizations": {
    "list.focusHighlightForeground": "#3c6169",
    "quickInputList.focusForeground": "#3c6169",
    "editorSuggestWidget.selectedForeground":"#3c6169",
},

That looks great! Is it possible to make that the official solution? Right now the contrast is making the theme hard to use.

Hi @jacobgraf, @RYDB3RG, @ad-on-is and @pspeter3 :wave:, thanks for your contributions :+1:
The latest VS Code version 1.57.0 “broke“ the styles through the introduction of more fine grained theme keys. I've pulled some app updates today and was also facing the problem, but like always the OSS community has been quicker 😉
I've been going through the release notes of VS Code version 1.45.0 up to 1.57.0 to get up-to-date with theme/style specific changes. I hope I can adapt these and ship a new release version as soon as possible.
@jacobgraf The suggestion looks nice, I've also played around with the new keys and using nord4 to nord6 for the “lazy match“ tokens should work best, but I'm not sure about the background accent color yet.

To get this inconsistency fixed as soon as possible and make the theme better usable again I've changed the plan for the next version 0.16.0 and submitted #199. Using nord6 as highlight color for the quick picker should work fine with the nord8 background, also mainly because the color for non-focused entries still uses nord8.
Let me know what you think about it, I'm happy for every feedback.


Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: net/http: TLS handshake timeout

Bugs should be filed for issues encountered whilst operating cert-manager.
You should first attempt to resolve your issues through the community support
channels, e.g. Slack, in order to rule out individual configuration errors.
Please provide as much detail as possible.

Describe the bug:
Cluster Issuer installation fails with TLS handshake timeout
kubectl apply -f cert-issuer-letsencrypt-prd.yml -n cert-manager
Error from server (InternalError): error when creating "cert-issuer-letsencrypt-prd.yml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: net/http: TLS handshake timeout

Expected behaviour:
kubectl apply -f cert-issuer-letsencrypt-prd.yml -n cert-manager

works successfully and does not generate an error
Steps to reproduce the bug:

Create cert-manager ns
kubectl create ns cert-manager

Install cert-manager using helm 3
helm install cert-manager jetstack/cert-manager --namespace cert-manager
NAME: cert-manager
LAST DEPLOYED: Sat Feb 15 11:40:28 2020
NAMESPACE: cert-manager
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
cert-manager has been deployed successfully!

Add secret letsencrypt-prd
kubectl -n cert-manager apply -f cert-cloudflare-api-key-secret.yml

Create cluster-issuer
kubectl apply -f cert-issuer-letsencrypt-prd.yml -n cert-manager

cert-issuer-letsencrypt-prd.yml
apiVersion: cert-manager.io/v1alpha2
kind: ClusterIssuer
metadata:
  name: letsencrypt-prd
  namespace: cert-manager
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: xxxx
    privateKeySecretRef:
      name: letsencrypt-prd
    solvers:
    - dns01:
        cloudflare:
          email: xxxx
          apiKeySecretRef:
            name: cloudflare-api-key-secret
            key: api-key

Anything else we need to know?:
Environment details::

Kubernetes version (e.g. v1.10.2): v.1.17.2
Cloud-provider/provisioner (e.g. GKE, kops AWS, etc): bare-metal
cert-manager version (e.g. v0.4.0): 0.13.0
Install method (e.g. helm or static manifests): helm 3

/kind bug
Pods are running fine, no restarts
kubectl -n cert-manager get pods
NAME                                      READY   STATUS    RESTARTS   AGE
cert-manager-c6cb4cbdf-djqt4              1/1     Running   0          37m
cert-manager-cainjector-76f7596c4-wsb4z   1/1     Running   0          37m
cert-manager-webhook-8575f88c85-xf7w2     1/1     Running   0          31m

crd are there
kubectl get crd | grep cert-manager
certificaterequests.cert-manager.io                     2020-02-15T10:39:37Z
certificates.cert-manager.io                            2020-02-15T10:39:38Z
challenges.acme.cert-manager.io                         2020-02-15T10:39:38Z
clusterissuers.cert-manager.io                          2020-02-15T10:39:39Z
issuers.cert-manager.io                                 2020-02-15T10:39:40Z
orders.acme.cert-manager.io                             2020-02-15T10:39:40Z

logs of cert-manager-webhook pod repreatetly show http: TLS handshake error from <IP_ADDRESS>:5067: EOF
kubectl -n cert-manager logs cert-manager-webhook-8575f88c85-xf7w2
I0215 10:47:05.409158       1 main.go:64]  "msg"="enabling TLS as certificate file flags specified"
I0215 10:47:05.409423       1 server.go:126]  "msg"="listening for insecure healthz connections"  "address"=":6080"
I0215 10:47:05.409471       1 server.go:138]  "msg"="listening for secure connections"  "address"=":10250"
I0215 10:47:05.409495       1 server.go:155]  "msg"="registered pprof handlers"
I0215 10:47:05.409672       1 tls_file_source.go:144]  "msg"="detected private key or certificate data on disk has changed. reloading certificate"
2020/02/15 10:48:46 http: TLS handshake error from <IP_ADDRESS>:25427: EOF
2020/02/15 10:53:56 http: TLS handshake error from <IP_ADDRESS>:48126: EOF
2020/02/15 10:59:06 http: TLS handshake error from <IP_ADDRESS>:21683: EOF
2020/02/15 11:04:16 http: TLS handshake error from <IP_ADDRESS>:9457: EOF
2020/02/15 11:09:26 http: TLS handshake error from <IP_ADDRESS>:41640: EOF
2020/02/15 11:14:36 http: TLS handshake error from <IP_ADDRESS>:56638: EOF

here the logs from cert-manager-pod
kubectl -n cert-manager logs cert-manager-c6cb4cbdf-fzdmj
I0215 12:23:31.410690       1 start.go:76] cert-manager "msg"="starting controller"  "git-commit"="6d9200f9d" "version"="v0.13.0"
W0215 12:23:31.410750       1 client_config.go:543] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0215 12:23:31.411825       1 controller.go:167] cert-manager/controller/build-context "msg"="configured acme dns01 nameservers" "nameservers"=["<IP_ADDRESS>:53"]
I0215 12:23:31.412082       1 controller.go:130] cert-manager/controller "msg"="starting leader election"
I0215 12:23:31.412188       1 metrics.go:202] cert-manager/metrics "msg"="listening for connections on" "address"="<IP_ADDRESS>:9402"
I0215 12:23:31.412836       1 leaderelection.go:242] attempting to acquire leader lease  kube-system/cert-manager-controller...
I0215 12:24:50.921660       1 leaderelection.go:252] successfully acquired lease kube-system/cert-manager-controller
I0215 12:24:50.922007       1 controller.go:172] cert-manager/controller/certificaterequests "msg"="new certificate request controller registered"  "type"="selfsigned"
I0215 12:24:50.922139       1 controller.go:172] cert-manager/controller/certificaterequests "msg"="new certificate request controller registered"  "type"="venafi"
I0215 12:24:50.922149       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="certificaterequests-issuer-selfsigned"
I0215 12:24:50.922214       1 controller.go:74] cert-manager/controller/certificaterequests-issuer-selfsigned "msg"="starting control loop"
I0215 12:24:50.922245       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="certificaterequests-issuer-venafi"
I0215 12:24:50.922291       1 controller.go:74] cert-manager/controller/certificaterequests-issuer-venafi "msg"="starting control loop"
I0215 12:24:50.922307       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="clusterissuers"
I0215 12:24:50.922338       1 controller.go:74] cert-manager/controller/clusterissuers "msg"="starting control loop"
I0215 12:24:50.922376       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="webhook-bootstrap"
I0215 12:24:50.922407       1 controller.go:74] cert-manager/controller/webhook-bootstrap "msg"="starting control loop"
I0215 12:24:50.922412       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="issuers"
I0215 12:24:50.922474       1 controller.go:74] cert-manager/controller/issuers "msg"="starting control loop"
I0215 12:24:50.922537       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="orders"
I0215 12:24:50.922578       1 controller.go:74] cert-manager/controller/orders "msg"="starting control loop"
I0215 12:24:50.922602       1 controller.go:172] cert-manager/controller/certificaterequests "msg"="new certificate request controller registered"  "type"="acme"
I0215 12:24:50.922711       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="certificaterequests-issuer-acme"
I0215 12:24:50.922736       1 controller.go:172] cert-manager/controller/certificaterequests "msg"="new certificate request controller registered"  "type"="vault"
I0215 12:24:50.922740       1 controller.go:74] cert-manager/controller/certificaterequests-issuer-acme "msg"="starting control loop"
I0215 12:24:50.922855       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="certificaterequests-issuer-vault"
I0215 12:24:50.922904       1 controller.go:74] cert-manager/controller/certificaterequests-issuer-vault "msg"="starting control loop"
I0215 12:24:50.922982       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="certificates"
I0215 12:24:50.923031       1 controller.go:74] cert-manager/controller/certificates "msg"="starting control loop"
I0215 12:24:50.923042       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="ingress-shim"
I0215 12:24:50.923073       1 controller.go:74] cert-manager/controller/ingress-shim "msg"="starting control loop"
I0215 12:24:51.025320       1 controller.go:172] cert-manager/controller/certificaterequests "msg"="new certificate request controller registered"  "type"="ca"
I0215 12:24:51.025331       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="challenges"
I0215 12:24:51.025385       1 controller.go:74] cert-manager/controller/challenges "msg"="starting control loop"
I0215 12:24:51.025430       1 controller.go:101] cert-manager/controller "msg"="starting controller" "controller"="certificaterequests-issuer-ca"
I0215 12:24:51.025473       1 controller.go:74] cert-manager/controller/certificaterequests-issuer-ca "msg"="starting control loop"
I0215 12:24:51.122618       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/cert-manager-webhook-ca"
I0215 12:24:51.122638       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/cloudflare-api-key-secret"
I0215 12:24:51.122650       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/cert-manager-webhook-tls"
I0215 12:24:51.122669       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/sh.helm.release.v1.cert-manager.v1"
I0215 12:24:51.122674       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/cloudflare-api-key-secret"
I0215 12:24:51.122705       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/cert-manager-token-5tdm7"
I0215 12:24:51.122729       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/cert-manager-token-5tdm7"
I0215 12:24:51.122780       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/cert-manager-webhook-token-6hpwz"
I0215 12:24:51.122729       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/sh.helm.release.v1.cert-manager.v1"
I0215 12:24:51.122805       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/cert-manager-webhook-token-6hpwz"
I0215 12:24:51.122840       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/default-token-vlftn"
I0215 12:24:51.122867       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/default-token-vlftn"
I0215 12:24:51.122618       1 controller.go:129] cert-manager/controller/webhook-bootstrap "msg"="syncing item" "key"="cert-manager/cert-manager-cainjector-token-lzwbt"
I0215 12:24:51.122903       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/cert-manager-cainjector-token-lzwbt"
I0215 12:24:51.123241       1 controller.go:129] cert-manager/controller/ingress-shim "msg"="syncing item" "key"="kube-system/dashboard-kubernetes-dashboard"
I0215 12:24:51.123256       1 controller.go:197] cert-manager/controller/webhook-bootstrap/webhook-bootstrap/ca-secret "msg"="ca certificate already up to date" "resource_kind"="Secret" "resource_name"="cert-manager-webhook-ca" "resource_namespace"="cert-manager"
I0215 12:24:51.123281       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/cert-manager-webhook-ca"
I0215 12:24:51.123420       1 controller.go:255] cert-manager/controller/webhook-bootstrap/webhook-bootstrap/ca-secret "msg"="serving certificate already up to date" "resource_kind"="Secret" "resource_name"="cert-manager-webhook-tls" "resource_namespace"="cert-manager"
I0215 12:24:51.123450       1 controller.go:135] cert-manager/controller/webhook-bootstrap "msg"="finished processing work item" "key"="cert-manager/cert-manager-webhook-tls"

hi @papanito my configuration is the same, but Kubernetes version 1.16 and I tried to install cert-manager today using static file instead of helm.
I had exactly the same issue and solved it by following this page https://cert-manager.io/docs/installation/compatibility/ . Particularly, I have used cert-manager-no-webhook.yaml instead of cert-manager.yaml. You can consider if this option is suitable for you.
So now I finished my configuration and HTTPS works fine. Followed https://www.digitalocean.com/community/tutorials/how-to-set-up-an-nginx-ingress-with-cert-manager-on-digitalocean-kubernetes . A note that I'm using bare metal.

output of kubectl get secret -n cert-manager

kubectl get secret -n cert-manager
NAME                                  TYPE                                  DATA   AGE
cert-manager-cainjector-token-lzwbt   kubernetes.io/service-account-token   3      42h
cert-manager-token-5tdm7              kubernetes.io/service-account-token   3      42h
cert-manager-webhook-ca               kubernetes.io/tls                     3      42h
cert-manager-webhook-tls              kubernetes.io/tls                     3      42h
cert-manager-webhook-token-6hpwz      kubernetes.io/service-account-token   3      42h
cloudflare-api-key-secret             Opaque                                1      41h
default-token-vlftn                   kubernetes.io/service-account-token   3      42h
sh.helm.release.v1.cert-manager.v1    helm.sh/release.v1                    1      42h

@laimison yep that worked.

Still not sure why it does not work with the webhook. Also not sure whether I really sure if this is the best approach as

Doing this may expose your cluster to miss-configuration problems that in some cases could cause cert-manager to stop working altogether (i.e. if invalid types are set for fields on cert-manager resources).

Also interestingly, webhook was working on the initial setup of my cluster back in January. I did add an additional node and updated the underlying OS. Not sure yet why it stopped working...

I am having the same symptom. And I am sure it is something with my Weave CNI, because it worked with AWS VPC CNI.
I even tried tcpdump on cert-manager and cert-manager-webhook pods, surprisingly, there is no traffic on webhook port.

I just ran into this BKPR 1.4.0 on a new GKE cluster. I tried to recreating the node pool, but kept getting the same error during the BKPR install. I eventually I destroy my cluster, and built a new one.

I resolved the problem at https://github.com/jetstack/cert-manager/issues/2319#issuecomment-590210052

Guys I am seeing the same issue. The cluster is in Amazon via EKS service. K8s version 1.14.9
I am getting this error when it tries to generate a certificate via the already created let's encrypt clusterissuers.
I0325 14:56:10.310305       1 controller.go:129] cert-manager/controller/ingress-shim "msg"="syncing item" "key"="featureflags/ffs-api-feature-flags-service-api"
E0325 14:56:10.316197       1 controller.go:131] cert-manager/controller/ingress-shim "msg"="re-queuing item  due to error processing" "error"="Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.slr-system.svc:443/mutate?timeout=30s: x509: certificate is valid for cert-manager-webhook, cert-manager-webhook.cert-manager, cert-manager-webhook.cert-manager.svc, not cert-manager-webhook.slr-system.svc" "key"="featureflags/ffs-api-feature-flags-service-api"
These are the webhook logs:
I0325 08:40:45.540230       1 main.go:64]  "msg"="enabling TLS as certificate file flags specified"
I0325 08:40:45.540567       1 server.go:126]  "msg"="listening for insecure healthz connections"  "address"=":6080"
I0325 08:40:45.540612       1 server.go:138]  "msg"="listening for secure connections"  "address"=":10250"
I0325 08:40:45.540694       1 server.go:155]  "msg"="registered pprof handlers"
I0325 08:40:45.541014       1 tls_file_source.go:144]  "msg"="detected private key or certificate data on disk has changed. reloading certificate"
2020/03/25 14:50:55 http: TLS handshake error from <IP_ADDRESS>:39660: remote error: tls: bad certificate
2020/03/25 14:51:00 http: TLS handshake error from <IP_ADDRESS>:39750: remote error: tls: bad certificate
2020/03/25 14:51:10 http: TLS handshake error from <IP_ADDRESS>:39820: remote error: tls: bad certificate
2020/03/25 14:51:30 http: TLS handshake error from <IP_ADDRESS>:39974: remote error: tls: bad certificate
2020/03/25 14:52:10 http: TLS handshake error from <IP_ADDRESS>:40328: remote error: tls: bad certificate
2020/03/25 14:53:30 http: TLS handshake error from <IP_ADDRESS>:41022: remote error: tls: bad certificate
2020/03/25 14:56:10 http: TLS handshake error from <IP_ADDRESS>:42490: remote error: tls: bad certificate
2020/03/25 15:01:10 http: TLS handshake error from <IP_ADDRESS>:45270: remote error: tls: bad certificate
2020/03/25 15:06:10 http: TLS handshake error from <IP_ADDRESS>:47966: remote error: tls: bad certificate
I tried deleting the certificate and restarting the webhook pod but still getting these errors.. I have been installing cert-manager and it's components via manifests. The version is v0.13.1.
Do you have any ideas guys?

Switching it over to "cert-manager" works.. But why?

Same here https://github.com/jetstack/cert-manager/issues/2752

I am running into this issue as well using the recommended manifest installation:
kubectl apply \
  --validate=false \
  -f https://github.com/jetstack/cert-manager/releases/download/v0.14.0/cert-manager.yaml

Same here having upgraded from v0.11 to 0.14.1.  Mandatory webhook component seems to have borked.  Rolling back until all the open issues about this problem are closed.  May I suggest a patch to make it optional again in the meantime?

I have a similar issue with non-standard namespace (core-l7)
Error: UPGRADE FAILED: release core-l7 failed, and has been rolled back due to atomic being set: failed to create resource: conversion webhook for cert-manager.io/v1alpha3, Kind=ClusterIssuer failed: Post https://cert-manager-webhook.core-l7.svc:443/convert?timeout=30s: x509: certificate signed by unknown authority
helm.go:75: [debug] conversion webhook for cert-manager.io/v1alpha3, Kind=ClusterIssuer failed: Post https://cert-manager-webhook.core-l7.svc:443/convert?timeout=30s: x509: certificate signed by unknown authority

Here https://github.com/jetstack/cert-manager/issues/2752#issuecomment-605966908 you can find the answer of @munnerz that explains very well the issue, the reason behind and a possible workaround.

Thank you!

I'm still seeing the problem,
everything is installed into cert-manager namespace. First ierror on install
Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: x509: certificate signed by unknown authority

http: TLS handshake error from <IP_ADDRESS>:50016: remote error: tls: bad certificate

on fresh upgrade to 0.14.1
immediate creation of webhook gives
I0401 14:04:58.427632       1 main.go:79]  "msg"="enabling TLS as certificate file flags specified"
I0401 14:04:58.428254       1 server.go:131]  "msg"="listening for insecure healthz connections"  "address"=":6080"
I0401 14:04:58.428394       1 server.go:143]  "msg"="listening for secure connections"  "address"=":10250"
I0401 14:04:58.428518       1 server.go:165]  "msg"="registered pprof handlers"
I0401 14:04:58.428800       1 tls_file_source.go:144]  "msg"="detected private key or certificate data on disk has changed. reloading certificate"
2020/04/01 14:23:11 http: TLS handshake error from <IP_ADDRESS>:52582: remote error: tls: bad certificate
2020/04/01 14:26:12 http: TLS handshake error from <IP_ADDRESS>:53848: remote error: tls: bad certificate

and nothing works.
if I understand the workaround correctly (just deploy into the cert-manager namespace so that all the crds which have hardcoded namespaces and are not controlled by helm), then we've done than and I'm still seeing the error.
I don't actually understand the error. Which certificate is bad?

I've solved my problems with sed :))
namespace="not-cert-manager"
curl -s -L "https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager.crds.yaml" 2>&1 | sed -e "s/namespace: cert-manager/namespace: ${namespace}/" -e "s/cert-manager.io\/inject-ca-from-secret: cert-manager\/cert-manager-webhook-tls/cert-manager.io\/inject-ca-from-secret: ${namespace}\/${namespace}-cert-manager-webhook-tls/" |  kubectl apply --validate=false -f -

@Antiarchitect Only your solution worked for me!
Steps taken:
1) kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io cert-manager-webhook
2) kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io cert-manager-webhook
3) namespace="not-cert-manager"
4) curl -s -L "https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager.crds.yaml" 2>&1 | sed -e "s/namespace: cert-manager/namespace: ${namespace}/" -e "s/cert-manager.io/inject-ca-from-secret: cert-manager/cert-manager-webhook-tls/cert-manager.io/inject-ca-from-secret: ${namespace}/${namespace}-cert-manager-webhook-tls/" |  kubectl apply --validate=false -f -

@Antiarchitect Only your solution worked for me!
Steps taken:
kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io cert-manager-webhook
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io cert-manager-webhook
namespace="not-cert-manager"
curl -s -L "https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager.crds.yaml" 2>&1 | sed -e "s/namespace: cert-manager/namespace: ${namespace}/" -e "s/cert-manager.io\/inject-ca-from-secret: cert-manager\/cert-manager-webhook-tls/cert-manager.io\/inject-ca-from-secret: ${namespace}\/${namespace}-cert-manager-webhook-tls/" |  kubectl apply --validate=false -f -

Hi @TylerIlunga and @Antiarchitect,
I've the same issue, and with that fix I've already created an issuer. But when try describe created issuer, return that error:
conversion webhook for cert-manager.io/v1alpha2, Kind=Issuer failed: Post https://cert-manager-webhook.not-cert-manager.svc:443/convert?timeout=30s: service "cert-manager-webhook" not found.

Hi @jarpsimoes.  It is better to apply those sed filters on a clean setup. But the problem is cert-manager is a rather complicated piece of software that creates some global entities.

@Antiarchitect Only your solution worked for me!
Steps taken:
kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io cert-manager-webhook
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io cert-manager-webhook
namespace="not-cert-manager"
curl -s -L "https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager.crds.yaml" 2>&1 | sed -e "s/namespace: cert-manager/namespace: ${namespace}/" -e "s/cert-manager.io\/inject-ca-from-secret: cert-manager\/cert-manager-webhook-tls/cert-manager.io\/inject-ca-from-secret: ${namespace}\/${namespace}-cert-manager-webhook-tls/" |  kubectl apply --validate=false -f -

I followed the same action plan and it is working.
but after that i cant describe or delete the issuer , it is giving me the following error:
conversion webhook for cert-manager.io/v1alpha2, Kind=Issuer failed: Post https://cert-manager-webhook.not-cert-manager.svc:443/convert?timeout=30s: service "cert-manager-webhook" not found.
Any Idea ?

I have been dealing with this issue for a couple days now. After the 0.15.0 alpha came out today I thought this issue would be resolved, but I continue to suffer the same issue.
Also I don't think @Antiarchitect 's solution is actually a real solution since it necessitates deletes the webhook configurations, effectively disabling the webhook. I think the issue is TLS connection establishment related, but I am not sure why none of the ciphers work.

Hi @zzaareer. Did you install the cert-manager into the not-cert-mananger namespace? If not, you have to adjust the variable namespace according to your namespace.

I'm not sure if this is helpful, but an FYI: attempting to apply this via kubectl -k (kustomize) failed, but kubectl -f succeeded.  I don't know how to research more.

I ended up finding another unique solution to this problem, and all of cert-manager is working at full capacity for me now. My setup was:
Kubernetes 1.18
Calico CNI
Bare Metal
Cert-Manager 0.14.1

To fix, for some reason I had to make an adjustment to the calico network IP pool configuration away from the default. I downloaded the calico setup YAML (https://docs.projectcalico.org/manifests/calico.yaml), and then I edited this snippet
- name: CALICO_IPV4POOL_IPIP
  value: "Always"

to
- name: CALICO_IPV4POOL_IPIP
  value: "Never"

After deleting the default created IP pool and restarting calico, I reinstalled cert-manager and it began working as intended.
I am not sure exactly why this change fixed all my problems.

I am also bit by this bad. :(

I am having the same issue but the workaround does not fix the problem on my cluster. If anyone can point me in the right direction, it would be appreciated, I am a bit lost here:
$ kubectl get CertificateRequest -o wide
NAME                                         READY   ISSUER                STATUS                                                                                AGE
www.mydomain.com-prod-tls-2148034915         False   letsencrypt-prod      Waiting on certificate issuance from order default/www.mydomain.com-prod-tls-2148034915-4293390561: "pending"         92m

$ kubectl describe challenges
Error from server: conversion webhook for acme.cert-manager.io/v1alpha3, Kind=ChallengeList failed: Post https://cert-manager-webhook.not-cert-manager.svc:443/convert?timeout=30s: service "cert-manager-webhook" not found
$ kubectl get certificate -o wide -A
NAMESPACE   NAME                              READY   SECRET                            ISSUER             STATUS                                                                                AGE
default     www.mydomain.com-prod-tls         False   www.mydomain.com-prod-tls         letsencrypt-prod   Waiting for CertificateRequest "www.mydomain.com-prod-tls-2148034915" to complete         92m30s

After applying the workaround from @Antiarchitect I got this new error:
$ kubectl describe challenges
Error from server: conversion webhook for acme.cert-manager.io/v1alpha3, Kind=ChallengeList failed: Post https://cert-manager-webhook.kube-system.svc:443/convert?timeout=30s: x509: certificate signed by unknown authority
Certificates generated, but they have "Invalid date" for beginning and expired. I see the tls.key, but ca.crt and tls.crt are empty:
apiVersion: v1
data:
ca.crt: ""
tls.crt: ""
tls.key: XXXXXXXXXXX=
kind: Secret
metadata:
annotations:
cert-manager.io/certificate-name: www.mydomain.com-prod-tls
cert-manager.io/issuer-kind: ClusterIssuer
cert-manager.io/issuer-name: letsencrypt-prod
creationTimestamp: "2020-04-22T01:59:21Z"
name: www.mydomain.com-prod-tls
namespace: default
resourceVersion: "166305"
selfLink: /api/v1/namespaces/default/secrets/www.mydomain.com-prod-tls
uid: 2a405cdc-4ef9-4215-bb2e-028b41d9e7db
type: kubernetes.io/tls

me too :(
I am having similar problem ... using v0.14.2 ...
i.e. deploying cert-manager in the "cert-manager" namespace,
Using airship armada to helm install which forces use of "--name xyz" to helm which changes service names to xyz-cert-manager-webhook,
Used 'Values.webhook.serviceName = xyz-cert-manager-webhook' to correct the dns names in certificate,
...
I can create issuer ... but on get, describe, etc. of issuer get the following error:
Error from server: conversion webhook for cert-manager.io/v1alpha2, Kind=Issuer failed: Post https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s: service "cert-manager-webhook" not found
Why is the wrong web hook dns name being used here ?
( the correct web hook dns name is used when the issuer is created )

me too :(
I am having similar problem ... using v0.14.2 ...
i.e. deploying cert-manager in the "cert-manager" namespace,
Using airship armada to helm install which forces use of "--name xyz" to helm which changes service names to xyz-cert-manager-webhook,
Used 'Values.webhook.serviceName = xyz-cert-manager-webhook' to correct the dns names in certificate,
...
I can create issuer ... but on get, describe, etc. of issuer get the following error:
Error from server: conversion webhook for cert-manager.io/v1alpha2, Kind=Issuer failed: Post https://cert-manager-webhook.cert-manager.svc:443/convert?timeout=30s: service "cert-manager-webhook" not found
Why is the wrong web hook dns name being used here ?
( the correct web hook dns name is used when the issuer is created )

FYI ... 0.15-alpha.0 fixed my problem

@pierluigilenoci thanks for the hint. The main difference for me it's I use the ns cert-manager

We've made significant improvements to the way TLS is managed in the upcoming v0.15 release, as well as adding an installCRDs option to the Helm chart which will handle correctly updating service names and conversion webhook configuration when deploying into namespaces other than cert-manager or using a Helm release name other than cert-manager.
I think this issue can now be closed after this, and if anyone is still running into issues I'd advise you to try the new v0.15.0-alpha.1 release and reporting back! (to be safe, it may be best to start 'fresh' in case you have a currently broken configuration!)

I just install the new version of cert-manager 0.15.0-alpha.1 and tried the test-resources to create the issuer and certificate but still getting the same issue:
kubectl apply -f test-resources.yaml
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: dial tcp <IP_ADDRESS>:443: i/o timeout
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: dial tcp <IP_ADDRESS>:443: i/o timeout

I don't think your issue here is the same as the original poster (which had a TLS handshake timeout) - in your case, it seems like there is some legitimate issue between your apiserver and pods running in your cluster. This is part of the Kubernetes conformance suite, so if that's the case, is something that needs to be fixed within your Kubernetes deployment.
Has your webhook pod started? & are endpoints being registered behind the Service resource okay? kubectl get pod,service,endpoints -n cert-manager should help work that out :). Otherwise I'd investigate how/where you've deployed Kubernetes.

@munnerz  Thank you for your help.
I deployed the cert manager using the kubectl command like below :
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.0-alpha.1/Cert-manager.yaml
every thing working fine as you can see:
kubectl get pod,service,endpoints -n cert-manager
NAME                                           READY   STATUS    RESTARTS   AGE
pod/cert-manager-5bb5b9dcf8-sb52s              1/1     Running   0          28m
pod/cert-manager-cainjector-869f7868b7-rrrw2   1/1     Running   0          28m
pod/cert-manager-webhook-79d78c45cd-7fxfs      1/1     Running   0          28m
NAME                           TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
service/cert-manager           ClusterIP   <IP_ADDRESS>           9402/TCP   28m
service/cert-manager-webhook   ClusterIP   <IP_ADDRESS>           443/TCP    28m
NAME                             ENDPOINTS           AGE
endpoints/cert-manager           <IP_ADDRESS>:9402    28m
endpoints/cert-manager-webhook   <IP_ADDRESS>:10250   28m
but when i try to create the issuer and certificate i got the timeout and  context deadline exceeded

Using cert manager v0.15.0 which is released yesterday. With installCRDs set true, I am still getting the same error as above:
failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: x509: certificate signed by unknown authority

Our scripts deploy another helm chart which contains cert manager resources just after cert manager helm release reports ready and helm fails with above error. However, if I try to create resources after some time, I don't get any errors. So, it looks like a timing issue but I was not getting it with v0.15.0-alpha.0.

@zzaareer is your api-server able to access to your nodes?
timeout and context deadline exceeded errors sounds very similar to issues with webhooks while using GKE private clusters:

https://www.revsys.com/tidbits/jetstackcert-manager-gke-private-clusters/
https://github.com/open-policy-agent/gatekeeper/blob/master/README.md#running-on-private-gke-cluster-nodes

I am getting the same errors.  Does port 443 need to be allowed through to the node hosting the webhook pod?  I am running a on-prem k8s cluster.

I have the same error here using v0.15.0

I am observing initial startup of cert-manager consistently fails with:
Failed to pull image "quay.io/jetstack/cert-manager-webhook:v0.15.0-alpha.0": rpc error: code = Unknown desc = failed to pull and unpack image "quay.io/jetstack/cert-manager-webhook:v0.15.0-alpha.0": failed to copy: httpReaderSeeker: failed open: failed to do request: Get https://quay.io/v2/jetstack/cert-manager-webhook/manifests/sha256:8596cc308466075565c54ec30fec2847bc357b741ddc70f0a8460d9e6e229edc: unexpected EOF

which increases startup time and this could be related to the root cause why we started to get this error.
Full events:
Events:
  Type     Reason     Age                  From                              Message
  ----     ------     ----                 ----                              -------
  Normal   Scheduled  2m21s                default-scheduler                 Successfully assigned cert-manager/cert-manager-webhook-67545d6b46-q4zdj to local-dev-control-plane
  Warning  Failed     34s                  kubelet, local-dev-control-plane  Failed to pull image "quay.io/jetstack/cert-manager-webhook:v0.15.0-alpha.0": rpc error: code = Unknown desc = failed to pull and unpack image "quay.io/jetstack/cert-manager-webhook:v0.15.0-alpha.0": failed to copy: httpReaderSeeker: failed open: failed to do request: Get https://quay.io/v2/jetstack/cert-manager-webhook/manifests/sha256:8596cc308466075565c54ec30fec2847bc357b741ddc70f0a8460d9e6e229edc: unexpected EOF
  Warning  Failed     34s                  kubelet, local-dev-control-plane  Error: ErrImagePull
  Normal   BackOff    33s                  kubelet, local-dev-control-plane  Back-off pulling image "quay.io/jetstack/cert-manager-webhook:v0.15.0-alpha.0"
  Warning  Failed     33s                  kubelet, local-dev-control-plane  Error: ImagePullBackOff
  Normal   Pulling    20s (x2 over 2m19s)  kubelet, local-dev-control-plane  Pulling image "quay.io/jetstack/cert-manager-webhook:v0.15.0-alpha.0"
  Normal   Pulled     16s                  kubelet, local-dev-control-plane  Successfully pulled image "quay.io/jetstack/cert-manager-webhook:v0.15.0-alpha.0"
  Normal   Created    16s                  kubelet, local-dev-control-plane  Created container cert-manager
  Normal   Started    15s                  kubelet, local-dev-control-plane  Started container cert-manager

My pods all come up fine without delay.  I have tried following the Helm release notes aswell as the kubectl method.  Same error consistently...

Switch my pod network from flannel to Calico resolved my issue to create an issuer.   I found some clues here: https://github.com/jetstack/cert-manager/issues/2811

Hi, I ran into the same issue like @zzaareer on a rancher kubernetes  cluster. I have successfully deployed cert-manager via helm v3:
helm install cert-manager jetstack/cert-manager --namespace cert-manager --version v0.15.0 --set installCRDs=true --description "install cert-manager"

but when I try to install the test resources, I get the following error:
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded (Client.Timeout exceeded while awaiting headers)
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: context deadline exceeded

I attached a sidecar to the cert-manager pod for debugging and it shows me that I can resolve cert-manager-webhook.cert-manager.svc, but the IP is not answering on a ping.

@shibumi check out the your CNI setup (flannel or calico).  I think there is a flag to pass flannel so that the host-gw is used.  I am no expert but changing from flannel to calico worked for me.

@Trenthani We are using calico only already.

@turkenh I am seeing the same issue but no errors in my events. I am following the same approach as you. i.e., deploy the cert-manager first and then the issuer with a separate helm chart. The interesting thing however, I do not see the error if I deploy my Issuer after a few seconds (~60). Back to back installations of cert-manager and the Issuer certainly throws the following error:
Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: x509: certificate signed by unknown authority
@munnerz , I am certainly seeing the same error as the original issue with v.015.0. Any thoughts on why I am seeing the error when I try to immediately deploy the Issuer after the cert-manager deployment and NOT when I deploy the Issuer after a bit of a wait?

fixed this problem on my hard upgrade from v0.10 to v0.15 by deleting "cert-manager-webhook-ca" cause it's not updated automatically if exists

@turkenh I am seeing the same issue but no errors in my events. I am following the same approach as you. i.e., deploy the cert-manager first and then the issuer with a separate helm chart. Just as you had observed, I do not see the error if I deploy my Issuer after a few seconds (~60). Back to back installations of cert-manager and the Issuer certainly throws the following error:
Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: x509: certificate signed by unknown authority
@munnerz , I am certainly seeing the same error as the original issue with v.015.0. Any thoughts on why I am seeing the error when I try to immediately deploy the Issuer after the cert-manager deployment and NOT when I deploy the Issuer after a bit of a wait? This still appears to be a bug. Do you want me to open another issue to track this?

I had similar issue and found out that my kube-controller-manager pod and kube-api-server had wrongly configured NO_PROXY not excluding .svc from proxy traffic. I had to change /etc/kubernetes/manifests/*.yaml on master node.

 I its immediately being recreated. Then, once it is back, I tried to install die ClusterIssuer again and no success:
Error from server (InternalError): Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=30s: x509: certificate signed by unknown authority

Not sure how the CA creation works, but something is off.

@munnerz, can you please consider re-opening this. Keeps happening in 0.15.2.

Waiting a while as mentioned earlier seems to do the trick, so there is probably a timing issue somewhere. Tested on 0.15.2.
The following works for me (you might wanna tinker with the timer):
kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.2/cert-manager.yaml
kubectl -n cert-manager rollout status deploy/cert-manager-webhook
sleep 20

Waiting a while as mentioned earlier seems to do the trick, so there is probably a timing issue somewhere. Tested on 0.15.2.
The following works for me (you might wanna tinker with the timer):

kubectl apply --validate=false -f https://github.com/jetstack/cert-manager/releases/download/v0.15.2/cert-manager.yaml

kubectl -n cert-manager rollout status deploy/cert-manager-webhook

sleep 20

I had a 60 second wait built in to my script and it still failed, came back 10 minutes later and tried this and it worked.

I had issue with deploy ClusterIssuer, error was:
Internal error occurred: failed calling webhook \"webhook.cert-manager.io\": Post https://cert-manager-webhook.cert-manager.svc:443/validate?timeout=30s: context deadline exceeded

Solved as:
$ helm install \
  cert-manager jetstack/cert-manager \
  --namespace cert-manager \
  --version v0.16.0 \
  --set installCRDs=true

$ kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io cert-manager-webhook
$ kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io cert-manager-webhook

Had the same error. My cause was, that I accidentally turned on the istio-injection in the cert-manager namespace...
After turning it off, everything was fine again.
May my clumsiness will help someone ;)

This happens when you put any annotations on the Issuer or ClusterIssuer resources. Causes it to fail the validating webhook.

This happens when you put any annotations on the Issuer or ClusterIssuer resources. Causes it to fail the validating webhook.

Can you file a seperate issue for that?

这个问题可能是cni导致的，我修改了calico的mtu后这个问题解决了(This problem may be caused by cni. After I modified the mtu of calico, the problem was solved.)
{
"name": "k8s-pod-network",
"cniVersion": "0.3.1",
"plugins": [
{
"type": "calico",
"log_level": "info",
"log_file_path": "/var/log/calico/cni/cni.log",
"datastore_type": "kubernetes",
"nodename": "k3s-operator-1",
"mtu": 1420,
"ipam": {
"type": "calico-ipam"
},
"policy": {
"type": "k8s"
},
"kubernetes": {
"kubeconfig": "/etc/cni/net.d/calico-kubeconfig"
}
},
{
"type": "portmap",
"snat": true,
"capabilities": {"portMappings": true}
},
{
"type": "bandwidth",
"capabilities": {"bandwidth": true}
}
]
}

"mtu": 1440-> "mtu": 1420,

Thanks for that. This fixed it for me on microk8s 1.19.

Using hetzner cloud servers here, and the problem was fixed indeed by changing MTU not cert-manager
Changing calico MTU from 1440 to 1400 or 1420 fixed the error running test-resource.yaml
Error from server (InternalError): error when creating "test-resources.yaml": Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post "https://cert-manager-webhook.cert-manager.svc:443/validate?timeout=10s": context deadline exceeded

MTU Change:
kubectl patch configmap/calico-config -n kube-system --type merge \
  -p '{"data":{"veth_mtu": "1400"}}'
kubectl rollout restart daemonset calico-node -n kube-system

Update from previous solution
Steps taken:
kubectl delete -f https://github.com/jetstack/cert-manager/releases/download/v1.0.3/cert-manager.yaml
kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io cert-manager-webhook
kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io cert-manager-webhook
namespace="not-cert-manager"
curl -s -L "https://github.com/jetstack/cert-manager/releases/download/v1.0.3/cert-manager.crds.yaml" 2>&1 | sed -e "s/namespace: cert-manager/namespace: ${namespace}/" -e "s/cert-manager.io\/inject-ca-from-secret: cert-manager\/cert-manager-webhook-tls/cert-manager.io\/inject-ca-from-secret: ${namespace}\/${namespace}-cert-manager-webhook-tls/" |  kubectl apply --validate=false -f -

Potential resolution:
In our case, our cert-manager-webhooks pod had been running for nearly a year. We suspect it was using some sort of out-of-date internal cluster cert. After deleting the webhook pod, the Deployment spun up a new one without the issue.

Here is the easiest solution to this quagmire. The problem stems from the webhook cert secret being outdated for the newer cert-manager. Easiest way to solve all this stuff is just scorch the earth. Helm uninstall or kubectl delete all cert-manager resources and CRDs.  Then make sure all secrets and all configmaps are clear in the cert-manager NS. Then you should be able to redeploy. Your existing certs live as secrets, so they will be unaffected and on next boot cert-manager will find them and add them to the internal queue.

I had similar problem.
My solution turned to be very complicated.

Delete everything related to cert-manager. CDRS. Secrets.
Download https://github.com/jetstack/cert-manager/releases/download/v1.1.0/cert-manager.crds.yaml
Replace all namespace cert-manager occurrences to be kube-system in cert-manager.crds.yaml
Apply cert-manager.crds.yaml
Apply helm chart 1.1.0 to namespace kube-system
Delete cert-manager-webhook-ca secret from kube-system namespace.
Check logs of webhook pod, it should be

I1207 14:51:21.279796       1 logs.go:58] http: TLS handshake error from <IP_ADDRESS>:54902: remote error: tls: bad certificate
I1207 14:51:21.280118       1 logs.go:58] http: TLS handshake error from <IP_ADDRESS>:54900: remote error: tls: bad certificate
I1207 14:52:41.385457       1 dynamic_source.go:135] cert-manager/webhook "msg"="Detected root CA rotation - regenerating serving certificates"
I1207 14:52:41.409557       1 dynamic_source.go:199] cert-manager/webhook "msg"="Updated serving TLS certificate"

Check log of cert-manager pod , should be ok

The cdrs includes with helm chart will not work. They miss some definitions.

@Antiarchitect
it worked for me

Had the same error. My cause was, that I accidentally turned on the istio-injection in the cert-manager namespace...
After turning it off, everything was fine again.
May my clumsiness will help someone ;)

It helped me, thanks a lot =)

Since I also had the error
Internal error occurred: failed calling webhook \"webhook.cert-manager.io\":
Post https://cert-manager-webhook.cert-manager.svc:443/validate?timeout=30s: context deadline exceeded

which bothered me for quite some time I want to share my story :wink: Maybe it helps someone. So to get this error away I also did
$ kubectl delete mutatingwebhookconfiguration.admissionregistration.k8s.io cert-manager-webhook
$ kubectl delete validatingwebhookconfigurations.admissionregistration.k8s.io cert-manager-webhook

as mentioned in https://github.com/jetstack/cert-manager/issues/2602#issuecomment-669091541 . I'm installing cert-manager via the official Helm chart. So while I tried to upgrade from cert-manager v1.4.x to v1.5.0 the startupapicheck failed which also tries to call the webhook and it also exited with context deadline exceeded. While you can disable this check I really wanted to find out what was the real cause.
So while chatting with a team mate about that issue he asked the right question: Are you aware that the K8s control plane tries to connect to that webhook? :wink: I have no idea why I ignored that fact for quite a while... In my case there was just no connection from the control plane to the "Pod network" and I actually never needed it. So the controller nodes tried to connect to https://cert-manager-webhook.cert-manager.svc:443/validate?timeout=30s: and they of course had no idea where to route that request because there was just no network route from the controller nodes network to the "Pod network" (the K8s Pod and Service IP range).
My solution for now actually looks like this:
helm install cert-manager jetstack/cert-manager
  --namespace cert-manager
  --version v1.5.3
  --set installCRDs=true
  --set global.leaderElection.namespace="cert-manager"
  --set webhook.securePort="30001"
  --set webhook.hostNetwork=true
  --set webhook.url.host="worker:30001"
  --set webhook.extraArgs="{--dynamic-serving-dns-names=worker:30001}"

This makes the webhook listening on port 30001 on the host network too. So now the controller nodes can communicate with the webhook via the host network. Of course worker needs to be replaced with a real hostname e.g. And to avoid a certificate error --dynamic-serving-dns-names is also needed. Here a list of valid DNS names can be included so that the webhook TLS certificate matches the hostname in the URL.

We ran into this, and the specific resource that was conflicting was the cert-manager-webhook-ca secret, which had been left over from a previous installation that was removed manually. When I looked at the details, that secret had been created 2 years previously to the new version of cert-manager being installed. I was able to simply run kubectl delete -f https://github.com/jetstack/cert-manager/releases/download/v[X.X]/cert-manager.yaml which removed everything in that namespace (including old stuff), and then re-ran kubectl apply .... After doing that, I confirmed that the secret was new, and everything started working. HTH

curl -s -L "https://github.com/jetstack/cert-manager/releases/download/v0.14.1/cert-manager.crds.yaml" 2>&1 | sed -e "s/namespace: cert-manager/namespace: ${namespace}/" -e "s/cert-manager.io/inject-ca-from-secret: cert-manager/cert-manager-webhook-tls/cert-manager.io/inject-ca-from-secret: ${namespace}/${namespace}-cert-manager-webhook-tls/" |  kubectl apply --validate=false -f -

After changing version to newer (v1.8.0 in curl) also helped for me! Thanks

in my case helped restarting calico-node pods


[WIP] buffer console messages until enabled.

Buffers the console messages until enable is called.

This should probably be moved to BaseAgent (Why isn't it just called Agent? :grin:) as most domains should work this way. Record what is happening but don't report it until the client requests it.

Closing this as #59 supersedes it


Enable timestamps to use alternative hours

Hey @autotelik. Thanks for the contribution! I had been thinking about a configuration object like this. I'm trying to avoid dependencies on rails for this gem and I see you reference ActiveSupport. Is there a way to avoid that?
The problem you're solving feels like clock-drift or time-zone.  I'd rather not have two properties for house and minutes.  I'd prefer to either have a clock-drift property which would be minutes or a timezone attribute that would compare based on timestamp.  All timestamps from the gem right now are UTC, which is lowest common denominator.
Can you explain your scenario more?

hi ... really, sorry, no idea how this ended up here .. this was supposed to just be a local fix in our fork

for info we had some funny issues on Ubuntu where CRM would reject messages due to timestamp issue but could not resolve via setting the various times in Linux.
There did not seem a way to trigger usage of your original methods like get_current_time_plus_hour  so was an attempt to create a configurable way to over ride the defaul timestamps

@autotelik I like the idea of making timing checks being expanded but these properties don't feel quite right.  I like the configuration object but we shouldn't need rails for it.


Wildcards in route names

Is there a notion of a "catch-all" or default route?
Or routes that match based on globs or regular expressions?

I don't see this in the documentation. Can anyone verify?

@srph I'm gonna necro to answer your question.
One way to match is to just not have a path prop
react-router docs says:

Any valid URL path that path-to-regexp understands.

If you look at the package.json of react-router on npm, you will see the dependency "path-to-regexp": "^1.7.0".
The most recent path-to-regxp broke compatibility with the older versions, so that's why react-router stays on "^1.7.0"

No wildcard asterisk () - use parameters instead ((.))


Snapshot (management) metrics

Hi there,
we were wondering whether it would make sense to extend the prometheus-exporter-plugin-for-opensearch in such a way that it exports additional metrics about which snapshots have been created, when the last snapshot has been created and so on. The main use-case would be to monitor whether backups are created in a regular fashion (using Snapshot Management), so that disruptions of the snapshot creation can be detected early on using alerts.
Do you think that would make a worthwhile addition to the plugin?
Thanks,
Thilo

Is this metric exposed by OpenSearch itself? If yes then that adding it to Prom. exporter would be an easy task. Or are there at least some relevant metrics already exposed by OpenSearch?

One could retrieve the registered repositories using a GetRepositoriesRequest and then obtain details about each snapshot using GetSnapshotsRequest. Exposing a time series per snapshot could be tricky (metrics inflation), so one could limit the number of observed snapshots to the n latest. If a snapshot has been created by a Snapshot Management Policy this is indicated using the sm_policy metadata attribute, which one could group the metrics by (to just expose the metrics of the last snapshot created by the policy).
In the REST API this maps to:
GET _snapshot

GET _snapshot/<repo_name>/_all

Agreed, would be nice to have :)

@lukas-vlcek I would like to take this up, we are implementing something similar in our forked repo, so we can contribute back the same. Please let me know if we still plan to add snapshot related metrics

@patelsmit32123 I would love to take a look at any PR :-)

@lukas-vlcek PTAL at #295, I have tested them on our staging env, seems to be working fine. I have not added any integration tests, i didn't understand the file naming pattern '30_10_*' and also if you can share some resources to better understand these kind of tests, thanks!!!


feat(tabs): apply ODS theme

ref: UK-100

Update style for ODS theme
Update stories for Storybook
Add subheading attribute
Add variant attribute
BREAKING CHANGE Remove checked attribute: It will not be used anymore.

Hello @AxelPeter,
Your pull request is now closed due to inactivity.
Feel free to re-open it if you have any update.
Anna Bot for OVH UX <3

Hello @AxelPeter,
Your pull request is now closed due to inactivity.
Feel free to re-open it if you have any update.
Anna Bot for OVH UX <3


Enable custom granularity inputs for filters

We are enabling support for custom granularity, which means
users will need to be able to reference them in where filters and
other contexts where their input representations of their manifest
elements will need to be parsed.
Historically, we have restricted time granularities to an enumerated
set of standard supported grains. With the addition of custom
granularities we must now admit the possibility of arbitrary string
names representing valid time granularities.
This change updates the interfaces for parsing time dimensions out
of filter expressions to allow for arbitrary string inputs representing
custom granularity names.
For various reasons - mainly having to do with the filter parser
not having access to the semantic manifest - we will NOT be able
to support custom granularity references via dundered string names. So
something like metric_time__martian_year will not work, but
the explicit syntax of Dimension('metric_time').grain('martian_year')
will be accepted and processed.
Resolves #345

I might not have been clear about this in discussion, but I think it would be a much better user experience if we actually could pass the granularity name via dundered syntax. We would need to pass the manifest lookup around, which is annoying. But it should be possible since we're enforcing name uniqueness, right?

@tlento - reraising my comment here. I would like for us to be able to pass custom grains via dundered syntax, but is that limited by the same issues raised in the other thread on this PR?
Not blocking for merging this. I can include this note in the investigation task I'm putting up for myself.

I would like for us to be able to pass custom grains via dundered syntax, but is that limited by the same issues raised in the other thread on this PR?

It's the same set of issues, and I think "limited" is the correct term - it's not impossible in all cases, but it's very difficult to do in a reasonable way from within this component inside DSI.
We can support the dundered syntax for query parameters today - even where filters - we'd just need to make sure whatever parses them does a conversion from dundered input to what the DSI parser supports.
The hard part is the manifest - filter parameters stored in the YAML can show up in any metric, and that means we'd need to have the list of custom grains before we try to do any parsing.

I think it would be a much better user experience if we actually could pass the granularity name via dundered syntax. We would need to pass the manifest lookup around, which is annoying. But it should be possible since we're enforcing name uniqueness, right?

I'd avoid the manifest lookup. All we need is the set of custom granularity names.
I suggest pushing a breaking change to this API and changing call_parameter_sets from a property to a function and passing the set of custom granularity constructs in at that point. This only works if none of our YAML parsers use call_parameter_sets in its property format, which I suspect is the case but I'm not 100% sure. I'd use the equivalent of the "ExpandedTimeGranularity" struct instead of string names, because adding that is potentially useful to us in other ways.
One issue with the breaking change - dbt-core 1.9.x is going to roll to beta soon. I'm not sure if it's worth the risk to try to jam this in right before those cutoffs. Worst case we can do a 2-stage shift, where we keep the property but have it only work for standard grains, add a new function to the protocol, cut everything calling it over to the function, and then remove the property. That defers the "breaking change" and allows us to add the new functionality in cloud even if we miss the core 1.9 cut. Source available users of MetricFlow won't be able to use custom calendar with the dunder syntax until 1.10, but they'll still be able to use the feature as long as they always specify the grain explicitly instead of relying on dunder magic.


Mayachain - ledger support

Apparently using the thorchain app support for mayachain on ledger is available.
ClientLedger for Maya would be awesome

let me know if you want access here
https://github.com/xchainjs/ledger-thorchain
also would it be worth forking this and making it xchainjs/ledger-mayachain. and then publishing the package


Incorrect samples for Viva Learning Learning Content Sample API (Patch Learning Content)

Hi,
Following the documentation (see below), here are my feedbacks :

"contributor": "Scott Simpson", : should be "contributorS": ["Scott Simpson"] as it's a string collection
"createdDateTime": "2018-01-01T00:00:00" : missing a Z at the end (should be "2018-01-01T00:00:00Z")
in attributes list, it could be useful to precise that the duration should be in ISO 8601 format (I missed it, trying to push values in standard seconds).
I think that the step to create a new learning content item is not clear enough. May worth to mention that the first query should be PATCH /employeeExperience/learningProviders/{learningProviderId}/learningContents(externalId='{externalId}') , then that it can be patched / updated using the generated system ID.

Kind regards !
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 54cab990-a67c-cdd3-38b0-7b58c7e7f9bc
Version Independent ID: 5ce0d8d7-6e12-0b19-b941-dab7175f1768
Content: Update learningContent - Microsoft Graph beta
Content Source: api-reference/beta/api/learningcontent-update.md
Product: employee-learning
Technology: microsoft-graph
GitHub Login: @malabikaroy
Microsoft Alias: MSGraphDocsVteam

Closing as this has been fixed already. Thanks.


Webapp:az webapp does not support installing extensions

Expected
On the azure portal new extensions can be installed as shown below. It is expected that the same action can be taken via the "az webapp" command.

Actual
The az webapp command does not support installing extensions such as Pythong 2.7.

route to appropriate team

Thanks for reporting we will add support to this in upcoming milestones.

Considering this for feature request.
FYI @panchagnula

Thank you for the feedback but we will not be doing this at this time.