Dockerfile: Update ruby to 2.6

Ruby 2.4 is already EOL, and 2.5 will be EOL at 2021-03-31.
Previously plugin issue #376 was blockage of updating to 2.5.
Does this still exist?
Even if so, I think updating to 2.6 is better.

Thanks Dalance,  Did you test with any plugins, could help for the future if we had a list of plugins that were used in the test.

Thanks Dalance,  Did you test with any plugins, could help for the future if we had a list of plugins that were used in the test.

I tested the following plugins.
They work fine.
https://github.com/happy-se-life/kanban
https://github.com/suer/redmine_absolute_dates
https://github.com/suer/redmine_enter_cancel
https://github.com/onozaty/redmine-view-customize

I tested the following plugins.
They work fine.
https://github.com/happy-se-life/kanban
https://github.com/suer/redmine_absolute_dates
https://github.com/suer/redmine_enter_cancel
https://github.com/onozaty/redmine-view-customize


完成 Authentication API 的設計

在這個 PR 中，我們完成了有關 Authentication 的設計與開發，目前整理出的 Route 如下：
GET /login

Return the login page.

Require: [none]
Data Parameter: [none]
Success Response: 200
Error Response:
	- code: 500
		- issue: Service temporarily unavailable due program has error.

GET /register

Return the register page.

Require: [none]
Data Parameter: [none]
Success Response: 200
Error Response:
	- code: 500
		- issue: Service temporarily unavailable due program has error.

POST /login

Required: [none]
Data Parameter:
	- [require] e-mail: The email of account. [str]
	- [require] password: The password of account. [str]
Success Response:
	- code: 200
		- content: [none]
Error Response:
	- code: 400
		- content:
			- message: The data has the wrong format and the server can't understand it.
	- code: 401
		- content:
			- message: The email or password that the user posted does not match any account.
	- code: 422
		- content:
			- message: The posted data has the correct format, but the data is invalid.

POST /register

Required: [none]
Data Parameter:
	- [require] e-mail: The email of account. [str]
	- [require] password: The password of account. [str]
	- [require] firstname: The firstname of account. [str]
	- [require] lastname: The lastname of account. [str]
	- [require] gender: the gender of account. [0-1]
	- [require] birthday: the birthday of account [yyyy-mm-dd]
Success Response:
	- code: 200
		- content: [none]
Error Response:
	- code: 400
		- content:
			- message: The data has the wrong format and the server can't understand it.
	- code: 401
		- content:
			- message: The posted email already exist.
	- code: 422
		- content:
			- message: The posted data has the correct format, but the data is invalid.

目前 API 的 message 均為 Failed，待修正。
目前已經完成階段性任務，故可以將 backend 合併至 develope 分支上。

GET 的應該也要標一下，然後

緊急兼容的部分要先併入 backend 嗎？
我們 error response 的 content 目前都還只是 Failed，可以發個 PR 調整

@Lai-YT 我將 API 的部分更新了，若沒有其他問題，請幫我 merge 這個 PR，感謝！


upgrade libhkl

The libhkl version available on conda forge is now old (<IP_ADDRESS>3).  It needs an update (<IP_ADDRESS>61 as of posted documentation today, <IP_ADDRESS>01 is the latest tag today).

Update the conda-forge feedstock.  The feedstock recipe pulls its version from https://github.com/picca/hkl but the latest version there is the same 2173.  Revise the feedstock to pull from the contemporary repo: https://repo.or.cz/hkl.git

pattern:
name: hkl
version: <IP_ADDRESS>01
sha256: 0be5985a8aa893ab9aaffbfb8dc08fce0e4a2d79

---: https://github.com/picca/{{ name }}/archive/v{{ version }}.tar.gz
+++: https://repo.or.cz/{{ name }}.git/snapshot/{{ sha256 }}.tar.gz

Might be simple (simpler than imagined) to update the conda-forge recipe but I should test things first locally with the new version before updating the feedstock.

RUN tar xzf hkl-<IP_ADDRESS>01.tar.gz
WORKDIR hkl-0be5985/
RUN uname -a
RUN ls -lAFgh .

Next step is to build a configure file and that's when the trouble starts:
docker build -t hkl_image .
# ....
docker run --rm -it hkl_image
root@59d2dfea95aa:~/hkl-0be5985# ./autogen.sh
autoreconf: export WARNINGS=
autoreconf: Entering directory '.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal --force -I m4
configure.ac:214: error: AM_COND_IF: no such condition "HAVE_INTROSPECTION"
/usr/share/aclocal-1.16/cond-if.m4:23: AM_COND_IF is expanded from...
configure.ac:214: the top level
autom4te: error: /usr/bin/m4 failed with exit status: 1
aclocal: error: /usr/bin/autom4te failed with exit status: 1
autoreconf: error: aclocal failed with exit status: 1
root@59d2dfea95aa:~/hkl-0be5985#

Not sure how to resolve this error and move forward:
configure.ac:214: error: AM_COND_IF: no such condition "HAVE_INTROSPECTION"

@picca, @mrakitin, @klauer : Any hints?

Don't you need everything from hkl as well? https://github.com/conda-forge/hkl-feedstock/blob/main/recipe/meta.yaml#L31
(Isn't that message related to gobject-introspection?)

Got confused about some of those packages (glib was not found).  This solved the one problem and I'll keep trying the other packages to get a build going.  Thanks!

Getting further, now:
./configure: line 19635: syntax error near unexpected token `-fanalyzer,'
./configure: line 19635: `  AX_CHECK_COMPILE_FLAG(-fanalyzer, CFLAGS="$CFLAGS -fanalyzer", , )'

ligbtk-3-dev

Static analyzer: https://gcc.gnu.org/onlinedocs/gcc/Static-Analyzer-Options.html

Perhaps related: https://stackoverflow.com/questions/30412576/autotools-syntax-error-with-ax-check-compile-flag

I'll try that, thanks
On Thu, Mar 16, 2023, 11:05 AM Ken Lauer @.***> wrote:

Perhaps related:
https://stackoverflow.com/questions/30412576/autotools-syntax-error-with-ax-check-compile-flag
—
Reply to this email directly, view it on GitHub
https://github.com/bluesky/hklpy/issues/250#issuecomment-1472263359, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AARMUMAOS57CYHPTAQQP6L3W4M26FANCNFSM6AAAAAAV4M4PAU
.

RUN tar xzf "${TARBALL}"
RUN /bin/rm "${TARBALL}"
WORKDIR "${TARNAME}/"
RUN uname -a
RUN ls -lAFgh .

RUN ./autogen.sh
RUN ./configure --disable-hkl-doc --disable-gtk-doc
RUN make

Next, setup a conda environment with hklpy (in the image) and use the new material (library and header files).

So far, so good (unmodified libraries):
Step 26/26 : RUN source /root/miniconda/bin/activate hklpy && python /root/hklpy_check.py
 ---> Running in 88a2d8d94b14
===================== ========= =========
term                  value     axis_type
===================== ========= =========
diffractometer        fourc
sample name           main
energy (keV)          8.05092
wavelength (angstrom) 1.54000
calc engine           hkl
mode                  bissector
h                     0.0       pseudo
k                     0.0       pseudo
l                     0.0       pseudo
omega                 0         real
chi                   0         real
phi                   0         real
tth                   0         real
===================== ========= =========

@klauer Do you have suggestions how to replace the libhkl library and other necessary files?  Update with these files, then retest?
root@12262cf8a801:~/hkl-0be5985# ll ./hkl/.libs/libhkl.so*
lrwxrwxrwx 1 root root      15 Mar 16 22:04 ./hkl/.libs/libhkl.so -> libhkl.so.5.0.0*
lrwxrwxrwx 1 root root      15 Mar 16 22:04 ./hkl/.libs/libhkl.so.5 -> libhkl.so.5.0.0*
-rwxr-xr-x 1 root root 1440256 Mar 16 22:04 ./hkl/.libs/libhkl.so.5.0.0*
root@12262cf8a801:~/hkl-0be5985# ll hkl.h
-rw-rw-r-- 1 root root 23995 May 23  2022 hkl.h
root@12262cf8a801:~/hkl-0be5985# ll hkl/ccan/*.h
-rw-r--r-- 1 root root 2433 Mar 16 22:04 hkl/ccan/ccan_config.h
root@12262cf8a801:~/hkl-0be5985# ll hkl/ccan/darray/*.h
-rw-rw-r-- 1 root root 12531 May 23  2022 hkl/ccan/darray/darray.h

Will build conda package (per the recipe in meta.yaml) with new library, et al. and install with conda, all in the Dockerfile.

That seems a reasonable approach, @prjemian

https://github.com/conda-forge/hkl-feedstock/pull/13

Working on a solution now.  Build the libhkl.tar.gz library without conda.  Then, untar this file into $CONDA_PREFIX and build the conda recipe.  Choose matching versions of gobject-introspection and gsl for both the build of libhkl and the build of the conda-forge recipe.

Also, found a way to get the libhkl version string into the libhkl.tar.gz, by modifying the hkl.h file with the version tag:
# add version info
sed -i '/^.*tau = 2pi.*/i #define HKL_VERSION "'"${HKL_TAG}"'"' hkl.h

This makes it all the way into hklpy: hkl.util.libhkl.VERSION='v<IP_ADDRESS>01'

Apparently, the HKL_VERSION definitions in hkl.h is accessed by the gobject-introspection package, which strips off the HKL_ part before delivering that through the Python API.

This procedure was revealed by examining dir(hkl.util.libhkl) in the Python code.  The HKL_TAUdefinition appears in Python ashkl.util.libhkl.TAU.  Nice to see that HKL_VERSIONappears in Python similarly, ashkl.util.libhkl.VERSION`

Nice progress, @prjemian!

Done.:
(hklpy) prjemian@arf:~/.../Bluesky/hklpy$ conda search hkl | grep 3001
hkl                       <IP_ADDRESS>01 py310hff52083_0  conda-forge
hkl                       <IP_ADDRESS>01 py311h38be061_0  conda-forge
hkl                       <IP_ADDRESS>01  py38h578d9bd_0  conda-forge
hkl                       <IP_ADDRESS>01  py39hf3d152e_0  conda-forge


Hotfix/issue#96 - Displaying external subscription price models for suppliers should available by default

This change is

Reviewed 4 of 4 files at r1.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable


WIP: Web socket

Posting this here to get feedback. Is this the type of structure you'd like? I think implementing CosmosClient directly on the native WebSocketClient type from tendermint_rpc is the best way to go (although that seems to contrast with your other implementations). I'm curious why you've chosen to wrap all of the tendermint and cosmrs types within cosm-tome types, it seems to create a lot of boiler plate. It seems to me that reexporting them would be more convenient for most users.

Hey! Apologies on the delay.

I think implementing CosmosClient directly on the native WebSocketClient type from tendermint_rpc is the best way to go

I like this approach. We can easily switch the TendermintRPC client over to this approach as well, but the CosmosGRPC wont be as easy.

I'm curious why you've chosen to wrap all of the tendermint and cosmrs types within cosm-tome types, it seems to create a lot of boiler plate.

Great point. I wanted to wrap the cosmrs types because some things are different, and I wanted to future proof in the ability for us to diverge. But I agree, it does add boiler plate, especially when adding new modules. Happy to explore just reexporting all wrapper types in another PR.

But yeah, this all looks great to me.
Want to wrap this up and add  a impl CosmTome<WebsocketClient>in client.rs for ease of use?


smem still needed?

As per a quick discussion with @jrafanie, opening an issue to investigate if smem is sill needed on appliances.
smem was originally added in https://github.com/ManageIQ/manageiq-appliance-build/pull/84 for forked process, but the original reason no longer applies.
Came across this working on CentOS 8 based appliance, as the package doesn't exist (not even EPEL).

This was added for diagnostic purposes, to better be able to determine process memory on a running appliance, so it can probably be removed if it's not available.

Selfishly, I prefer the way smem presents PSS, USS, RSS vs. top only showing RSS but that's just me, I don't think it's required or documented.

I have no problem building the RPM if it's useful.  If we're keeping it, we should probably document though 😄


Fixed federator error on creating of a new transaction

I removed all my previously changes in the PR, and added a validation to process the transaction vote and so on only if the transaction it's for that federator side chain.


refresh cassandra node ips on connection failure/retry

Hi,
we are still using this version in production and since we are now using docker swarm we are facing issues when cassandra nodes in the swarm cluster are getting rescheduled because they are getting a new ip address. that alone is not a problem but we are using dns names and the plugin here does not refresh the ip addresses that have been resolved at the start of the app.
this pr should fix that.
greets

LGTM. Glad to hear that this plugin version is still doing its job in production 😃

Artifacts are now in the snapshot repository.

Cool! Thanks Martin!

That looks good so far. Are you gonna make a release?

Just released version 0.7 for Scala 2.11 https://dl.bintray.com/krasserm/maven/com/github/krasserm/akka-persistence-cassandra_2.11/0.7/ ... and sorry for the late reply.

Thanks! And no worries :)


[LUM-745] - Fix draw prizes fees implementation

Description:
The Draw fees implementation was faulty (use of struct instead of pointers) which prevented the collected fees to be sent to their recipient.
Fees were collected from Prizes at Draw time but the collector never actually sent them anywhere.
They remain therefore in the local balance of the Pool but are not actually usable by the Pool since it is not "aware" of their existence (they are considered sent to their recipient).
Solution:

NewFeeCollector now returns a pointer to prevent any faulty implementation
Unittests now test the fee collection at Draw time (in addition to testing it standalone)

Recommendation:
The next upgrade including this fix should include a Pool migration to Add the collected but not sent fees to the next PrizePool in order to do something with it and not let them sit in the Pool balance forever.
I'd not recommend to send it to stakers as the complexity of this operation is not worth the amount of collected fees.

Implementation looks fine. Shouldn't this PR also cover the migration fix?


TR DemoApp set NumberOfResults=0 for Monomodal Car

Please change the parameters in the OJP Demo App for OJP2.0 for a monomodal CAR TripRequest.
Reason: if we try to make a monomodal car route, where no PT exists, we will always get an error. And if a user explicit choose "monomdol car", I gues he wants to see only the IV route and not PT route as well.

Currently, in the Request are the following parameters:
           <NumberOfResultsAfter>5</NumberOfResultsAfter>           <NumberOfResultsBefore>0</NumberOfResultsBefore>
For testing carFerry and TunnelTransport as well, the Parameters should better be:
                    <NumberOfResults>0</NumberOfResults>

At the moment the GUI is sending always <NumberOfResults>5</NumberOfResults> and the monomodal car trip is taken and promoted on top of the other results.
https://tools.odpch.ch/ojp-demo-v2/search?from=8503104&to=8503672&mode_types=monomodal&transport_modes=self-drive-car&stage=v2-test&do_search=yes
@u233336 @TO-mdv - I can implement as required but that means we'll not see the rest of the alternative trips. Do we want this?

Sounds correct to me, for a monomodal CAR trip I don't need to see the PT trips


Make the OG weeks Hideable

What feature do you want to get added on the base engine?
what if you made a mod in the mods folder, and went into pack.json or something else and set ShowOGWeeks or something to false? that would be awesome! then I wouldn't have to see the og weeks in story mode and freeplay and only have my mod.
To test your sight, and reliability, please select the option of what should NOT be requested.
Stage Editor, 6K+ support, and winning icons.

Just edit the json week files on assets, bruh.

this is already possible and has been answered, delete their .json from assets/weeks

Just edit the json week files on assets, bruh.

this is already possible and has been answered, delete their .json from assets/weeks

HE SAID IN MODS FOLDER

they just want to have their mod, which you can already do

why

this is already possible and has been answered, delete their .json from assets/weeks

You can? nice. Thanks for the tip

now close this


[ABI] Eliminate the now-unused protocol requirement array.

This is a holdover from the old protocol descriptor layout, which is no
longer useful.

@swift-ci please smoke test and merge


Allow for updating of Jira ticket status as incident changes status

It would be nice if we could map incident statuses to Jira status optionally, if a ticket exists. Something like the example below. If a status_mapping doesn't exist for an incident status, then the Jira ticket wouldn't get an update during that time.
jira:
  update_status: True
  status_mapping:
    - incident_status: Investigating
      jira_status: Open
    - incident_status: Identified
      jira_status: In Progress
    - incident_status: Monitoring
      jira_status: In Review
    - incident_status: Resolved
      jira_status: Done
  project: INCMGMT
  issue_types: ['Task', 'Epic', 'Story']
  priorities: ['High', 'Medium', 'Low']
  labels:
    - incident-management
    - etc

@echoboomer if you're ok with this, I can take a crack at this over the holiday


Users can search for a job

Can we create another model, when someone apply to job for getting record of the applied time

the owner the job advert, can see the applicants and their past about working or stuff, the owner can decline, in progress or can accept.


Improve responsiveness

Couple of issues raised about the responsiveness of the app, needs to be improved.

This is much improved now, with added support for

iPhone 5 and iPhone 5s
iPhone 6+
Nexus 4, 5, 7

Ugh. Nexus fixes broke some iPhone layout. Reverting, will add back later


Make SwiftUI Label extension public

Fixes a mistake in the SwiftUI Label extension I previously contributed – it wasn't public 🤦♂

Thanks @sebj!


same client config different registry(same verdaccio) will cache the first config and cannot cleanup

Your Environment

verdaccio version: v5.1.2
node version [12.x.x, 14.x.x]: v14.17.3
package manager: [npm@7, pnpm@6, yarn@2] 6.14.13
os: [mac, windows@10, linux] linux
platform: [npm, docker, helm, other] npm

Describe the bug

i've deploy a registry on an intranet linux server (ip: 192.168.**.),and the server can access by a domain name (http://npm..*)
then i start the verdaccio.
when i config the registry to  http://npm.*.* in .npmrc, then execute yarn, it will work, and in yarn.lock, it shows like this.
<EMAIL_ADDRESS>  version "1.0.6"
  resolved "http://npm.*.*/name-1.0.6.tgz#eeca39f0a76edb54fa44c25326acb9b095c9c7b6"

but if i config the registry to http://192.168.**.*, in yarn.lock,it shows the same.
this will cause a problem. if i start the verdaccio,and on mac ,i config a intranet registry,
the verdaccio server will memomize my mac.and if i leave the intranet environment and config registry to domain name. i execute yarn will get errors at end.
error message like this: you can not access to http://192.168.**.*....tgz.
To Reproduce

start a verdaccio, and config to map to internet(or another intranet ip).
config the registry to verdaccio's intranet ip. and execute yarn
on same client,  execute yarn cache clean -f, remove  node_modules. rename yarn.lock to yarn1.lock
on same client,  config registry to verdaccio's another ip (intranet or internet), then executeyarn
compare yarn.lock and yarn1.lock, you will see ,they are equal.

Expected behavior

the lock file shows the tgz download url will equal to config registry.
Screenshots, server logs, package manager log

Configuration File (cat ~/.config/verdaccio/config.yaml)

Environment information

Debugging output

$ NODE_DEBUG=request verdaccio display request calls (verdaccio <--> uplinks)
$ DEBUG=verdaccio* verdaccio enable extreme verdaccio debug mode (verdaccio api)
$ npm -ddd prints:
$ npm config get registry prints:

Contribute to Verdaccio

[ ] I'm willing to fix this bug 🥇

when first get package with intranet.

then use domain. it show the same intranet dist url.

expected behavior:

hi @WindsonFF I understand your confusion, but that's not verdaccio issue. You might want to read
https://medium.com/verdaccio/verdaccio-and-deterministic-lock-files-5339d82d611e
and in other words, if you don't want to deal with this issue use other package manager different than npm, for instance

pnpm https://pnpm.io/
yarn v2 or higher: https://yarnpkg.com/getting-started/install

when first get package with intranet.

then use domain. it show the same intranet dist url.

expected behavior:

To force different domain you can use env variables, check this out
https://verdaccio.org/blog/2021/04/14/verdaccio-5-migration-guide#a-new-public-url-environment-variable

@juanpicado thks.
i've seen the code https://github.com/verdaccio/verdaccio/blob/2e995f5981c1a5eca6f43b14e52f06564acf6d8e/src/lib/utils.ts#L165
looks like this is cached.
and when i change registry in client, is the req.host changed? and if it changed, then the memoizedgetPublicUrl maybe should not cache ?


Mouse free operation

I find myself using your wonderful plugin more and more.
One form of friction is the need to always use the mouse to accept input. It would be ideal if this could be done with a return key, as with Quick Add.
Thanks again.

Hi,
This shouldn't be too difficult. Can you list the places where you'd need a key action instead of mouse click?

Great. With the command, Open this Note Field's Nodal, after entering new input into a field, it would be good to complete this using Enter on the keyboard.
Same with Manage Field at Cursor.


service and list status check for a MR

#1261

list status checks for a MR
list external status checks for a project

@svanharmelen can you take a look at your convenience?
For now, I'm adding list APIs as I don't have time to implement update/delete. they are coming in subsequent MR(s).
I'm not huge fun of StatusCheckProtectedBranch struct.

I initially have it as unnamed struct and embed it in ProjectStatusCheck but problem while testing that I need to re-write the same struct
there is no other (protected) branch struct that has the same attributes defined for external status check. I would've just reused if there were any.


duct.mdl is not attached

Description
Prop duct.mdl is flying in the air, fasteners are not attached to the wall and is positioned a little higher than it needs to be.

Solution
Move the model inside the building and lower a few units.

Change pic please

Change pic please

Ok bro

FINALLY
NEW PIC


Fix: changing the page back and forth could led to have no special price

Related issues

closes #
Short description and why it's useful

This problem was caused by multiple problems:

special_price and price could be the same
special_price was compared with price and not original_price
special_price from and to data where set to null (This could be
a problem here I am not 100% sure but in other cases like telling the
customer when the sales end would be broken with that.)

This is most likely on a client side only bug. So when you client side
tax calculation enabled.
Screenshots of visual changes before/after (if there are any)

Which environment this relates to
Check your case. In case of any doubts please read about Release Cycle

[x] Test version (https://test.storefrontcloud.io) - this is a new feature or improvement for Vue Storefront. I've created branch from develop branch and want to merge it back to develop
[] RC version (https://next.storefrontcloud.io) - this is a stabilisation fix for Release Candidate of Vue Storefront. I've created branch from release branch and want to merge it back to release
[] Stable version (https://demo.storefrontcloud.io) - this is an important fix for current stable version. I've created branch from hotfix or master branch and want to merge it back to hotfix

Upgrade Notes and Changelog

[x] No upgrade steps required (100% backward compatibility and no breaking changes)
[ ] I've updated the Upgrade notes and Changelog on how to port existing VS sites with this new feature

IMPORTANT NOTICE - Remember to update CHANGELOG.md with description of your change
Contribution and currently important rules acceptance

[x] I read and followed contribution rules

One thing I would guess is that we need to backport this some versions back.

Thanks!
Can you please apply this change to https://github.com/DivanteLtd/vue-storefront-api/blob/master/src/lib/taxcalc.js?

@ResuBaka yeah we need to port it to 1.10.4 please @patzick will release 1.10.4 at the same time we release 1.11rc1 - somewhere next week


Feature/model python

This branch adds Model class in Python with changes as follows:

get_parameter() and get_submodel() are replaced with params and submodels dict like properties.
auto_add_attributes() function is added. This is a shortcut of add_parameter() and add_submodel(). (see: #65)

auto_add_attributes is not acceptable because the name leads misunderstanding of the behavior. It needs more discusdion at #65.

Okay. I removed auto_add_attributes() function.
We have to take much time to discuss about this feature.


operator gitlab-operator-kubernetes (0.20.0)

Thanks submitting your Operator. Please check below list before you create your Pull Request.
New Submissions

[ ] Are you familiar with our contribution guidelines?
[ ] Have you packaged and deployed your Operator for Operator Framework?

[ ] Have you tested your Operator in all supported installation modes?
[ ] Have you considered whether you want use semantic versioning order?
[ ] Is your submission signed?
[ ] Is operator icon set?

Updates to existing Operators

[ ] Did you create a ci.yaml file according to the update instructions?
[ ] Is your new CSV pointing to the previous version with the replaces property if you chose replaces-mode via the updateGraph property in ci.yaml?
[ ] Is your new CSV referenced in the appropriate channel defined in the package.yaml or annotations.yaml ?
[ ] Have you tested an update to your Operator when deployed via OLM?
[ ] Is your submission signed?

Your submission should not

[ ] Modify more than one operator
[ ] Modify an Operator you don't own
[ ] Rename an operator - please remove and add with a different name instead
[ ] Modify any files outside the above mentioned folders
[ ] Contain more than one commit. Please squash your commits.

Operator Description must contain (in order)

[ ] Description about the managed Application and where to find more information
[ ] Features and capabilities of your Operator and how to use it
[ ] Any manual steps about potential pre-requisites for using your Operator

Operator Metadata should contain

[ ] Human readable name and 1-liner description about your Operator
[ ] Valid category name1
[ ] One of the pre-defined capability levels2
[ ] Links to the maintainer, source code and documentation
[ ] Example templates for all Custom Resource Definitions intended to be used
[ ] A quadratic logo

Remember that you can preview your CSV here.
--
1 If you feel your Operator does not fit any of the pre-defined categories, file an issue against this repo and explain your need
2 For more information see here

/merge possible

/merge possible

something is broken here - @pursultani and I are both listed as reviewers as per referenced https://k8s-operatorhub.github.io/community-operators/operator-ci-yaml/#reviewers (BTW, link is broken in GH Action comment) yet PR is not moving forward.

@droopy4096 a PR must be submitted by one of the reviewers in order to be automatically merged. gl-distribution-oc is not listed as a reviewer in your ci.yaml.

/merge possible

https://github.com/k8s-operatorhub/community-operators/pull/2862 is submitted and add gl-distribution-oc to ci.yaml.

https://github.com/k8s-operatorhub/community-operators/pull/2852 is submitted. It adds gl-distribution-oc to ci.yaml.


Allowing skipping HTTP01 and DNS01 self-check on a per-solver basis

Is your feature request related to a problem? Please describe.
Kinda intercects with #863, in nat nets cant successfully self validate acme rules, because of local k8s providers, which  refuses to create hairpin nat
Describe the solution you'd like
Nice env variable or cmd-flag for skip local self check and leave it up to the user
Describe alternatives you've considered
Nothing
Environment details (if applicable):

Kubernetes version (Any):
Cloud-provider/provisioner (Cheap local providers):
Install method (Helm):

/kind feature

This has been discussed before and we've avoided allowing it as we need some way to ensure that the challenge has propagated.
For DNS01, options like --dns01-recursive-nameservers and --dns01-recursive-nameservers-only help users that have DNS restricted environments that use DNS01.
I wonder if we can provide some other means to allow you to complete the self check without disabling it altogether? i.e. by overriding the server that we query for challenges?
/priority awaiting-more-evidence
/help

Yeah, custom server for queries definitely make sense, in dns01 flags you did perfect job, but, i think this can be more confusing in http01. For me, its ok to create flag looks like --http01-external-address=<IP_ADDRESS>:80 or something like that for sure.
But in that scenario user can use some kind of local created service with configured endpoints to the challenges, which de-facto like disabling at all.

I'd would like to disable the self-check, too: we have a k8s cluster with different inbound gateways and NAT and we can't hairpin the external DNS name to the correct internal IP in every scenario for every domain name, so internal checks against the external IP will timeout while requests from certbot's servers can read the challenge without problem.

We are also having this issue, while the http01 self check could be bypassed with hairpin nat, or an external split horizon DNS. in some cases this can be a real pain (Such as bootstrapping a system, see Rancher 2.0 HA install where you need an external LB)

I have the same issue : I cannot use cert-manager because of self-check tests. My router does not support hairpinning

this would be a great feature. we are experiencing self check failures due to our DNS policy of only allowing internal DNS servers for internal lookups. the self check is the only thing preventing the challenge from completing.

/remove-lifecycle rotten

+1

1

+1

Given we now better handle backing off when an Order fails, I think we could consider adding this as an option on the ACME solver.
Logically, it seems it'd make sense to make this an option that applies to both DNS01 and HTTP01 solvers.
If someone wants to give implementing this a go, please drop a comment here first so we can firm up the design details 😄
/cc @JoshVanL

/area acme
/area api

In our case, the node running Nginx Ingress controller somehow is able to visit the HTTP01 endpoint.
So we used podAffinity to schedule cert-manager on the same node and it solves the issue.

Any progress on this? We are running kubernetes in a cloud provider that does not support hairpinning. Without this feature we couldn't deploy cert-manager successfully.

The root problem is in Kubernetes networking if you use LoadBalancer that is provided by the hosting. I use DigitalOcean. Kubernetes is not routing network through LB public interface so there is no adding PROXY protocol header or SSL if you are setting it outside Kubernetes. I use PROXY protocol and the moment when I enable it and update Nginx to handle it everything works but cert-manager fails as it is trying to connect to public domain name and that fails. It works from my computer as I am outside and LB is adding needed headers, but not from within the cluster.
Cert-manager is not guilty for this, but if we can add some switches where we can instruct validator to add PROXY protocol instead to disable validation for that domain it would help some of us a lot.
For curl if I do (from inside the cluster):
curl -I https://myhost.domain.com

it fails.
If I do (from inside the cluster):
curl -I https://myhost.domain.com --haproxy-protocol

it works.
Check this: https://github.com/jetstack/cert-manager/issues/863

The root problem is in Kubernetes networking if you use LoadBalancer that is provided by the hosting. I use DigitalOcean. Kubernetes is not routing network through LB public interface so there is no adding PROXY protocol header or SSL if you are setting it outside Kubernetes. I use PROXY protocol and the moment when I enable it and update Nginx to handle it everything works but cert-manager fails as it is trying to connect to public domain name and that fails. It works from my computer as I am outside and LB is adding needed headers, but not from within the cluster.
Cert-manager is not guilty for this, but if we can add some switches where we can instruct validator to add PROXY protocol instead to disable validation for that domain it would help some of us a lot.
For curl if I do (from inside the cluster):
curl -I https://myhost.domain.com

it fails.
If I do (from inside the cluster):
curl -I https://myhost.domain.com --haproxy-protocol

it works.
Check this: #863

I was informed by DigitalOcean team that there is a fix for this behavior. They added an additional annotation to nxinx-ingress controller service that forces Kubernetes to use domain name of public IP instead of IP and that tricks Kubernetes to think that it is not "ours" and routes network around through LB.
https://github.com/digitalocean/digitalocean-cloud-controller-manager/blob/master/docs/controllers/services/examples/README.md#accessing-pods-over-a-managed-load-balancer-from-inside-the-cluster
This is it: (I just added this one)
kind: Service
apiVersion: v1
metadata:
  name: nginx-ingress-controller
  annotations:
    service.beta.kubernetes.io/do-loadbalancer-hostname: "hello.example.com"

It would also be nice if that could be disabled by on-certificate(request) base.
I have an issue with MetalLB + externalTrafficPolicy: Local where the cert-manager validator cannot access the solver since it's running on a different node than the "proxy" forwarding the requests to the solver.
Any thoughts on this?

I have the same issue as @MatthiasLohr. I recently introduced MetalLB to our cluster and I wasn't expecting certificate requests to stop working.
Does anyone know any workarounds for this?

Anton has volunteered to put a design document together for this feature! A big thank you - it'll be great to get input on this document once it's ready from those that require this feature! 😄
/assign @anton-johansson

What does that mean? Any ETA, when this feature will be available?

@MatthiasLohr I'm currently working on a design document where we can decide the best solution. It'll be up shortly.

Thank you! Would be really nice to have this feature as soon as possible, currently the last thing required for a production setup... Trying a lot of workarounds but nothing is really reliable.

I'll do my best to get this included in the v0.15.0 release.

Awesome, thanks! If I can help somehow, please let me know.

@MatthiasLohr @WhitePhoera I am in your exact same situation.
In my case, to workaround this, I created an internal DNS Zone with an entry matching the cert and pointed it to the IP address managed by MetalLB.
It's by no mean a long term solution but at least the certificate validated.

I cannot find this feature in the helm chart options of v0.15.0?  @anton-johansson did you implement the feature with the latest release?

Unfortunately, no, @Knowledge91. We decided to tackle the issue in another angle, and after that I've had my hands full with work.

Ok. Thanks for the update! Keep up the good work :)
P.S. I solved my problem by using my consumer router in bridge mode and installing OpenWrt on a Raspberry Pi, which has Nat Loopback build in.

Hey folks, any progress on that / solutions in sight?

also interested due to network design

+1 for me

Hey peeps! I apologize for this not being worked on. While doing some tests, it was clear that the solution wasn't going to work as expected. We discussed another solution, but that would require some rework and the time it would take - in combination with a lot of office hours - I just did not have time for it.
If anyone wants to resume the work, I'd be very happy!
PS: The reason that the solution isn't working as expected is that without performing this self-check (or ignoring its result), the challenge will be sent to Lets Encrypt before the cluster has had time to create the challenge Pod and set up the Ingress route.

If this can help anybody, what i have done is created IPTable Entries as follows, then I am OK to create the certificates as needed.
iptables -t nat -A PREROUTING -d <IP_ADDRESS> -p tcp --dport 80 -j DNAT --to <IP_ADDRESS>:80
iptables -t nat -A PREROUTING -d <IP_ADDRESS> -p tcp --dport 443 -j DNAT --to <IP_ADDRESS>:443
iptables -t nat -A POSTROUTING -s <IP_ADDRESS>/24 -d <IP_ADDRESS> -p tcp --dport 80 -j MASQUERADE
iptables -t nat -A POSTROUTING -s <IP_ADDRESS>/24 -d <IP_ADDRESS> -p tcp --dport 443 -j MASQUERADE
<IP_ADDRESS>  is the Public IP Address which my domain name points to
<IP_ADDRESS> is the Internal (private) ip address of my server
<IP_ADDRESS>/24 is the ip address range of any server on my network in CIDR format
In Addition, I also edited my /etc/hosts file and added
<IP_ADDRESS>            mydomain.com
After this, i was able to generate the certificates as was needed

I'm sorry but maybe we're overthinking/overengineering this... In some cases (NAT!), it is simply needed to skip the self-check. We could jump through hoops and come up with all kinds of convoluted solutions, or we could just give some control to the user of the software and add a flag that allows the self-check to be skipped.
In this case cert-manager is actively working against the user by enforcing checks that are already done by the ACME provider anyway. I don't see the harm in allowing these checks to be bypassed on a per-solver basis. Having the self-checks is a good, sane default, but forcing them makes for a bad user experience.

I completely agree!
I can see the point for "we don't know when we are up and ready for having LE checking us" - ok, then provide a second annotation for "wait x seconds until doing the LE request". And, even if we run into LE limits - that our problem, right?

The problem here is not rate limits it is that if a challenge fails too often it gets marked as invalid and a new one has to be requested thus cert-manager has to request a new token, set up the DNS/Ingress again and end up in a weird race condition. Which is what @anton-johansson hit against. Adding a time wait in seconds is a hack but it feels a bit sensitive to get in trouble with.
Just thinking out loud here:

what if we could query the internal ingress IP for HTTP01?
what if we checked the status fields on pod and ingress field as self-check for HTTP01?
I said HTTP01 a lot what about DNS01?
Why not both and add degrees of self-checks? Full, Local, Kubernetes Statuses...

Any suggestions?

I think DNS is a different problem. If you have to use HTTP01 and the special setting mentioned above, the self check give a false negative feedback.
Btw: Why does cert-manager check for external access at all? Why not just rely on the Pod readiness state (which has to be correctly implemented then, of course). If the Pod is ready (kubernetes readiness check returns success), any reason why the Pod is maybe still not accessible from outside (e.g. ingress controller screwed up), it outside of the responsibility of cert-manager. Therefore, it should be also outside of the responsibility checking for that.
Do I miss something or would it be enough just to change the general behavior to monitor readinessState? IMHO, that would be a more clean solution anyways, regardless of the problem. That's what readinessChecks are made for.

Why does cert-manager check for external access at all?

It's in the RFC: Clients SHOULD NOT respond to challenges until they believe that the    server's queries will succeed.
https://tools.ietf.org/html/rfc8555#section-8.2
Some ingresses take a while to route the routes to the solver pod, we have seen this happening causing issues. The solver pod in 99% of the cases starts way faster than the ingress is being ready. cert-manager should have the responsibility to follow the spec and check if everything is working before replying to the ACME server. Been talking to some co-workers and we have apparently seen that checking the pod probes still causes a race condition with the ingress (see the GCE one as a good example, it takes several minutes to propagate a route).

Personally I think cert-manager should obviously stick to the RFC by default, but is allowing an option to be added (on a per-solver basis) to bypass a self-check that simply doesn't work in some cases (again, NAT) really that bad? If I install Certbot on a server and run it, but my DNS is misconfigured, it will still perform the ACME request as all it sees is that the required vHost files are present on the server. It, too, will cause a user's rate limit to be exceeded if attempted too often. Is that such a problem, though? A user explicitly chose to disable a check because the aforementioned check cannot work on their infrastructure. I know in practice this obviously won't always be the case, but we should be able to trust that someone who uses an option like that has made sure everything else is in order, and even if they haven't or they have missed something, will realise that it is their own fault that they exceeded the rate limit because of this.
If I click Get Started on the Let's Encrypt website's home page, the first thing I see is Certbot. Certbot doesn't check for DNS propagation. It only checks the web server configuration. And even that is only by default, and can be cirumvented, because while sane, newbie-friendly defaults are good, there is no one-size-fits-all for everyone's workflow or setup.
If we really do insist to keep the self-check mandatory (which I personally don't think is the right solution here), a relatively simple fix could be to add an annotation that allows the IP address to be overridden. This would mean;

By default, the existing behaviour remains. A self-check is performed before an ACME request is sent.
Behind NAT, the internal IP address of the load balancer can be specified by the user (basically overriding DNS resolution). This way we still ensure that services are available and ingress routes have propagated. If a request succeeds via a load balancer on its internal IP, it should succeed on its external IP too (in most cases). If DNS is misconfigured, this is still the user's own responsibility, just like it is with Certbot.

Any thoughts on this?

I am not insisting on keeping a mandatory self-check, but we should take in account what @anton-johansson discovered while implementing this. But we should disencourage it being used. It would be good to built upon https://github.com/jetstack/cert-manager/pull/2783 to have a well tested solution that gives an answer to being able to know when we're ready to serve without a self-check.

It's in the RFC: Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed.
https://tools.ietf.org/html/rfc8555#section-8.2
In my view, I read this and understand that this above paragraph reads that the client should implement sanity check, and not necessarily endpoint validations.
ie:. The pods readiness state should be enough to meet this RFC requirement.  If it doesn't succeed, then there is another bug that needs to be fixed.  If it's the ingress that is the issue, then it should be handled outside of cert manager.
Just my view.

Basically my words, I agree!

I also stuck with this issue when setting up egress with Firewall for AKS. Hope the solution will be out soon.

I'm also in this situation, where my k8s cluster is behind a NAT gateway. I only chased this issue for about 8 hours before I understood what was going on - mostly due to my service's application, my ingress, and my router all running Nginx with the default 404 page.
As I see it, there are currently four options to make cert-manager work, although adding a fifth option of a switch to disable self-check in cert-manager would be really appreciated.
In order of hard to easy, which is also best fix to worst fix ;-)

implement hair-pin routing in the NAT gateway

pro: the correct fix for everything
con: impossible to implement on most consumer equipment

implement split DNS between the external Internet and the internal LAN

pro: apparent fix for everything
con: will mask misconfiguration on NAT gateway
con: complex for many people to implement

implement split DNS internally within k8s by adding a zone into core-dns

pro: fix for k8s
pro: discreet fix – does not effect surrounding LAN
con: user has to maintain a DNS zone

add hostAlias to cert-manager

pro: apparent fix for cert-manager
pro: discreet fix – does not effect surrounding k8s or LAN
pro: simple configuration format
con: will be removed when cert-manager is updated

I started by implementing (4) because it was the simplest.
I know the IP address on my LAN where my ingress-controller service is, since it's given a loadBalancerIP from a MetalLB pool. In my NAT gateway I DNAT ports 80 and 443 from the Internet IP address for my site to this LAN address. So I just use that IP address in a hostAliases node in the cert-manager's deployment.
I added a section similar to this to the cert-manager deployment, and restarted the deployment.
      hostAliases:
        - ip: <IP_ADDRESS>
          hostnames:
            - example.org
            - www.example.org

Hopefully this will be useful for future solution searchers.

I'm also in this situation, where my k8s cluster is behind a NAT gateway. I only chased this issue for about 8 hours before I understood what was going on - mostly due to my service's application, my ingress, and my router all running Nginx with the default 404 page.
As I see it, there are currently four options to make cert-manager work, although adding a fifth option of a switch to disable self-check in cert-manager would be really appreciated.
In order of hard to easy, which is also best fix to worst fix ;-)

implement hair-pin routing in the NAT gateway

pro: the correct fix for everything
con: impossible to implement on most consumer equipment

implement split DNS between the external Internet and the internal LAN

pro: apparent fix for everything
con: will mask misconfiguration on NAT gateway
con: complex for many people to implement

implement split DNS internally within k8s by adding a zone into core-dns

pro: fix for k8s
pro: discreet fix – does not effect surrounding LAN
con: user has to maintain a DNS zone

add hostAlias to cert-manager

pro: apparent fix for cert-manager
pro: discreet fix – does not effect surrounding k8s or LAN
pro: simple configuration format
con: will be removed when cert-manager is updated

I started by implementing (4) because it was the simplest.
I know the IP address on my LAN where my ingress-controller service is, since it's given a loadBalancerIP from a MetalLB pool. In my NAT gateway I DNAT ports 80 and 443 from the Internet IP address for my site to this LAN address. So I just use that IP address in a hostAliases node in the cert-manager's deployment.
I added a section similar to this to the cert-manager deployment, and restarted the deployment.
      hostAliases:
        - ip: <IP_ADDRESS>
          hostnames:
            - example.org
            - www.example.org

Hopefully this will be useful for future solution searchers.

In our case, the node running Nginx Ingress controller somehow is able to visit the HTTP01 endpoint.
So we used podAffinity to schedule cert-manager on the same node and it solves the issue.

Although this is a dirty/temporary solution, But worked for me.
Hairpinning is not a best solution at all.

In our case, the node running Nginx Ingress controller somehow is able to visit the HTTP01 endpoint.
So we used podAffinity to schedule cert-manager on the same node and it solves the issue.

Although this is a dirty/temporary solution, But worked for me.
Hairpinning is not a best solution at all.

In addition to the problem with NAT, I'm not sure assuming that a pod can call back into the cluster using an externally-resolved domain name is a good idea. There could be other reasons why a cluster admin wouldn't want to allow that (e.g. security or just enforcing that pods shouldn't talk to pods they don't need to talk to). To me it seems best to just wait for the components that need to be up to reply to the challenge to be up before initiating the real check (e.g. with Let's Encrypt) and skip the self-check altogether.

In addition to the problem with NAT, I'm not sure assuming that a pod can call back into the cluster using an externally-resolved domain name is a good idea. There could be other reasons why a cluster admin wouldn't want to allow that (e.g. security or just enforcing that pods shouldn't talk to pods they don't need to talk to). To me it seems best to just wait for the components that need to be up to reply to the challenge to be up before initiating the real check (e.g. with Let's Encrypt) and skip the self-check altogether.

In our case, the node running Nginx Ingress controller somehow is able to visit the HTTP01 endpoint.
So we used podAffinity to schedule cert-manager on the same node and it solves the issue.

This didn't work for me in the sense it doesn't work on a single node cluster (where everything has affinity :)).

In our case, the node running Nginx Ingress controller somehow is able to visit the HTTP01 endpoint.
So we used podAffinity to schedule cert-manager on the same node and it solves the issue.

This didn't work for me in the sense it doesn't work on a single node cluster (where everything has affinity :)).

Further example of when skipping self-check is needed is when split-DNS exists.
Imagine

a public facing zone with very few basic records
a private zone, possibly with sub-domains

The dns01 with rfc2136 solver in an Ingress will cause, via the configuration in an Issuer, to update the public zone, using the IP address and tsig credentials in the Issuer.
The private zone will not be updated. The self-check will be using internal DNS servers and will access the private zone. The self-check will always fail.
The certbot/dns-rfc2136 docker image does not require this self imposed self-check. It works in this split-DNS environment.

Further example of when skipping self-check is needed is when split-DNS exists.
Imagine

a public facing zone with very few basic records
a private zone, possibly with sub-domains

The dns01 with rfc2136 solver in an Ingress will cause, via the configuration in an Issuer, to update the public zone, using the IP address and tsig credentials in the Issuer.
The private zone will not be updated. The self-check will be using internal DNS servers and will access the private zone. The self-check will always fail.
The certbot/dns-rfc2136 docker image does not require this self imposed self-check. It works in this split-DNS environment.

If we were to get rid of the self-check in favor of a check for the right component to just be up, what are the things that need to be checked? I guess the pod, service, and ingress?

If we were to get rid of the self-check in favor of a check for the right component to just be up, what are the things that need to be checked? I guess the pod, service, and ingress?

If we were to get rid of the self-check in favor of a check for the right component to just be up, what are the things that need to be checked? I guess the pod, service, and ingress?

I think the more problematic part is to verify that the Ingress controller has actually picked up the Ingress and reloaded its configuration (?).

If we were to get rid of the self-check in favor of a check for the right component to just be up, what are the things that need to be checked? I guess the pod, service, and ingress?

I think the more problematic part is to verify that the Ingress controller has actually picked up the Ingress and reloaded its configuration (?).

My setup is bare-metal which sits behind my pfsense firewall. I also encounter the error: http://domain/.well-known/acme-challenge/ACME
For some reason, pfsense has been blocking internal IP to access my domain which is resolved to my WAN IP.
The way I do it is to allow NAT Reflection.
If you have SSL problem, just disable ssl-redirect by adding this under the annotations section.
nginx.ingress.kubernetes.io/ssl-redirect: "false"

I'm using the hostAliases approach and works perfectly.
It would be great that we can configure hostAlises entries using values in helm chart.

Is there any roadmap to allow us to permanently disable the self check?

Yeah I'm pretty stuck on this at the moment. I'm running a server at home and use dyndns to point to my own ip address. The challange is totally ready but cert-manager keeps getting 404 because it uses the same hostname and that hostname won't work when you're inside the network. I'm giving up on this altogether and going to use http for now but I'm sad about it.

Yeah I'm pretty stuck on this at the moment. I'm running a server at home and use dyndns to point to my own ip address. The challange is totally ready but cert-manager keeps getting 404 because it uses the same hostname and that hostname won't work when you're inside the network. I'm giving up on this altogether and going to use http for now but I'm sad about it.

Try this: https://github.com/jetstack/cert-manager/issues/1292#issuecomment-672042901

This has been discussed before and we've avoided allowing it as we need some way to ensure that the challenge has propagated.
For DNS01, options like --dns01-recursive-nameservers and --dns01-recursive-nameservers-only help users that have DNS restricted environments that use DNS01.
I wonder if we can provide some other means to allow you to complete the self check without disabling it altogether? i.e. by overriding the server that we query for challenges?
/priority awaiting-more-evidence
/help

@munnerz , I guess it's possible. I've another environment with docker and I'm using traefik to handle the certificates. I didn't face this error with traefik only with cert manager. Both are behind NAT. We're using HTTP01 for both as well.

Search engine sent me here trying to tackle cert-manager's interaction with split DNS, as some other users in this thread. I've seen the hostAliases workaround suggested here, but that wouldn't fit my use case since I'd like to have a lot of domains, and some of them point to dynamic IP addresses. It also implies duplicating quite a lot of things.
I've temporarily solved this with a different (but IMO slightly better) workaround involving dnsConfig, which allows to set a custom nameserver for the cert-manager pod. Pointing this to a nameserver that does not return the local addresses (e.g. <IP_ADDRESS>) fixes the issue for me, since the external one is returned.
This is already exposed in cert-manager's Helm chart, so adding the following to the values file works like a charm:
# Tell cert-manager to not use local DNS, since that would return local IPs and break preflight checks
podDnsPolicy: None
podDnsConfig:
  nameservers:
    - <IP_ADDRESS>

This has some side effects, like the cert-manager pod not being able to resolve cluster-local names, but so far this has not caused issues to me.

+1 from my side for implementing a possibility to disable the self checks. In my case, I am mostly interested in this for DNS-01 challenges.
Reason is, as many before me stated, split DNS in combination with network policy only allowing me to query internal DNS servers.
Internal DNS servers will host entries pointing to internal ip addresses for the zone that is being used internally only. The external DNS servers contain nothing else than the TXT records needed for ACME to issue certificates, which will then again be used internally only.
In Traefik, I have realized this setup easily with the disablePropagationCheck: true setting in the dnsChallenge part of acme configuration, and it works perfectly.
Sad to see that I cannot migrate to cert-manager in combination with ingress-nginx to achieve the same, without forking and coding myself.
Christian

Increadible. Almost 3 years old now...

This is already exposed in cert-manager's Helm chart, so adding the following to the values file works like a charm:
# Tell cert-manager to not use local DNS, since that would return local IPs and break preflight checks
podDnsPolicy: None
podDnsConfig:
  nameservers:
    - <IP_ADDRESS>

This has some side effects, like the cert-manager pod not being able to resolve cluster-local names, but so far this has not caused issues to me.

Works for me! :+1:
When you're using restrictive NetworkPolicies you also need allow outbound DNS queries (UPD, Port 53) from cert-manager! :zap:

This is already exposed in cert-manager's Helm chart, so adding the following to the values file works like a charm:
# Tell cert-manager to not use local DNS, since that would return local IPs and break preflight checks
podDnsPolicy: None
podDnsConfig:
  nameservers:
    - <IP_ADDRESS>

This has some side effects, like the cert-manager pod not being able to resolve cluster-local names, but so far this has not caused issues to me.

Works for me! +1
When you're using restrictive NetworkPolicies you also have to allow outbound DNS queries (UPD, Port 53) from cert-manager to the DNS servers of your choosing! zap facepalm

That may fix the DNS check problem but not necessarily the HTTP check, at least not for us
Our firewall doesn't allow traffic coming from an IP, looping through the firewall, and then going back to the same IP. According to our IT guys, this is not configurable.
When trying to check the HTTP challenge our firewall blocks this. The only solution I can see would be to skip the HTTP challenge and maybe only wait for the pod to become ready

As said in my comment, https://github.com/jetstack/cert-manager/issues/1292#issuecomment-1001494463, changing the DNS won't necessarily fix this
Please reopen this issue, as this still won't work for us

/reopen

I understand this issue is very old, and how frustrating it is to see it unfixed. Hopefully the just merged feature for overriding the DNS server will help some people for the DNS-01 challenge without having to inject specific hosts into the cert-manager controller pod.
Perhaps the solver blocks on issuers could have a "weak" check flag, which when enabled will rather than performing the same checks as an ACME server, would try a best effort internal only check. For example for HTTP-01 it could call the service IP rather than the resolving the full challenge through ingress, and for DNS-01 it could use the DNS provider's API to check if the record exists rather than resolving it through a recursive resolver. Would this be good enough?
I'll bring this issue up in our public issue meeting. These are open to anyone to join if you feel strongly about it!

@jakexks That sounds like a great Idea! 👍
That's actually my current workaround, setting the various hostAliases to the internal ingress service IP in the cert-manager deployment. But of course the service IP of the challenge pod would work as well 👍

Following up on this issue after we discussed it in our issue meeting.
Historically cert-manager has been very conservative about the amount of times we hit the ACME endpoints, as an old version was very unkind and effectively DDoSed let's encrypt.
We think the path forward is to make sure we have exponential backoff for issuance failures rather than the rather naive retry behaviour we currently have, so this will be worked on as soon as possible (Issue: https://github.com/jetstack/cert-manager/issues/4727).
Following that we would be happy to add a feature to skip the self check. We were slightly worried that a tutorial would surface on a popular blog with the skip feature enabled, which people would just copy and paste without thinking, so we would call the flag or YAML key something that makes it obvious we don't intend it to be used by default.

/remove-lifecycle rotten

/remove-lifecycle stale

I hit this issue. Again. Third time, I suppose. And now I don't even know how to work-around. Please, implement it!

Whilst this is an annoying, long-standing issue, there are solutions you can deploy straight out of the box to sidestep the problem entirely.
https://github.com/compumike/hairpin-proxy
Apply one YAML and be on your way. What would be really nice is if this method was the fallback solution on the first failure of the self-checks.

It would be great if this feature is implemented. We use Infoblox for internal DNS and Cloudflare for public DNS. Our security team somehow decided to only allow internal DNS queries, so we can't use --dns01-recursive-nameservers and --dns01-recursive-nameservers-only options.

The same issue. We cannot use --dns01-recursive-nameservers and --dns01-recursive-nameservers-only because of internal network policies - we don't have an access to external DNS servers.

This is still very relevant. The option to disable self-check dns01 solver would be great. Even better if it's directly in the Issuer/ClusterIssuer declaration.

Don't get stale, please. Get fixed!

/remove-lifecycle stale

I also really miss this feature. We're running our infra behind 1:1 NAT and I'm not able to connect public IP from the cluster. This would help me a lot.

This PR I've created here https://github.com/cert-manager/cert-manager/pull/5701 has unblocked me from the NAT hairpinning in my cluster with HTTP01 validation without the need for anything external or any other configuration with DNS.
The code works by allowing the user to set a flag --acme-http01-solver-host-endpoint to the internal DNS name of your ingress (such as traefik.traefik.svc.cluster.local) by keeping the Host header as the original domain being validated so that ingress routing is not affected.
This approach was discussed above and I'm not sure if this eventuated into code or was trialed, but this solution has worked for me the most cleanly. Please feel free to let me know about any oversights or anything I have missed with this approach.

This PR I've created here https://github.com/cert-manager/cert-manager/pull/5701 has unblocked me from the NAT hairpinning in my cluster with HTTP01 validation without the need for anything external or any other configuration with DNS.
The code works by allowing the user to set a flag --acme-http01-solver-host-endpoint to the internal DNS name of your ingress (such as traefik.traefik.svc.cluster.local) by keeping the Host header as the original domain being validated so that ingress routing is not affected.
This approach was discussed above and I'm not sure if this eventuated into code or was trialed, but this solution has worked for me the most cleanly. Please feel free to let me know about any oversights or anything I have missed with this approach.

I don't think this works if you have multiple ingress controllers in the cluster any recommendations for that use case?

@HoogWater Exactly the problem that I'm having. Worked around with hostAliases:
https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/

How about the Helm chart? I don't see anything related to spec.hostAliases in the template.

I'd just like to say that I managed to fix the self-check by setting hostAliases in the CM deployment. Even though it was frustrating, I still think that's a better way than bypassing the self-check entirely. If this was properly documented (this, or hairpin-proxy, or whatever) I'm pretty sure at least users behind NAT would manage to get the check to run.

I'm also struggling with the issue. I hoped that If I add two nameservers in the http01-solver-nameservers flag, one with internal resolution and one with public, it will checked both for self healthcheck. Although it is not working like that.
So if we are not allowed to skip self check, maybe it will be just possible to update selfcheck to check all nameservers or add an additional flag like: --selfcheck-nameservers ?

@bananu7 @FerronN I'm trying this currently and I'm not getting anywhere do you mind if you possibly share your yaml for the hostAliases? I'm putting this in the container deployment with "<IP_ADDRESS>  test.example.com" and while thats working it still can't seem to issue its cert.

@unixbird what are you using to deploy? I use kustomize. This is my kustomize file:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  template:
    spec:
      containers:
        - name: cert-manager-controller
      hostAliases:
      - ip: 192.168.x.x
        hostnames:
        - hostname.com

@unixbird what are you using to deploy? I use kustomize. This is my patch file:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: cert-manager
  namespace: cert-manager
spec:
  template:
    spec:
      containers:
        - name: cert-manager-controller
      hostAliases:
      - ip: 192.168.x.x
        hostnames:
        - hostname.com

kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml

patchesStrategicMerge:
- edit.yaml

ahhh you're doing it to cert-manager itself. I was trying to do this with a different deployment altogether. I'm not sure if this method would work for me as I use a ton of different subdomains (or I guess I could insert them as hosts everytime I need them).

/remove-lifecycle rotten

We were also using hostAliases for the cert-manager Deployment with HTTP-01 challenges, but as we ended up with list of 116 items (and still growing), I finally decided to automate handling of this and to get rid of hostAliases for good.
In our case, we have more ingress controllers and one of them is external (ingressClassName: nginx-external) which listens on an external IP (not reachable by cert-manager) and another one is internal (ingressClassName: nginx) which is accessible by cert-manager.
Metacontroller project seemed to me as the best fit for this, as we are already using it for other stuff.
Basically what we needed to do is whenever there is Ingress created for the acme.cert-manager.io/http01-solver (it is using ingressClassName: nginx-external), we need to duplicate it (adding "-internal" to it's name) but using internal ingress controller ingressClassName: nginx, so cert-manager can reach it during pre-check.
Install metacontroller: kubectl apply -k https://github.com/metacontroller/metacontroller/manifests/production
Create DecoratorController:
apiVersion: v1
kind: ConfigMap
metadata:
  name: acme-http01-solver-hooks
  namespace: metacontroller
  labels:
    app: acme-http01-solver
data:
  finalize-acme-http01-solver.jsonnet: |
    function(request) {
      attachments: [],
      finalized: std.length(request.attachments["Ingress.networking.k8s.io/v1"]) == 0
    }
  sync-acme-http01-solver.jsonnet: |
    function(request) {
      attachments: [
        {
          apiVersion: "networking.k8s.io/v1",
          kind: "Ingress",
          metadata: {
            name: request.object.metadata.name + "-internal"
          },
          spec: {
            ingressClassName: "nginx",
            rules: request.object.spec.rules
          }
        }
      ]
    }
---
apiVersion: metacontroller.k8s.io/v1alpha1
kind: DecoratorController
metadata:
  name: acme-http01-solver
spec:
  resources:
  - apiVersion: networking.k8s.io/v1
    resource: ingresses
    labelSelector:
      matchExpressions:
        - key: acme.cert-manager.io/http01-solver
          operator: In
          values: ['true']
  attachments:
  - apiVersion: networking.k8s.io/v1
    resource: ingresses
  hooks:
    sync:
      webhook:
        url: http://acme-http01-solver.metacontroller/sync-acme-http01-solver
    finalize:
      webhook:
        url: http://acme-http01-solver.metacontroller/finalize-acme-http01-solver
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: acme-http01-solver
  namespace: metacontroller
spec:
  replicas: 1
  selector:
    matchLabels:
      app: acme-http01-solver
  template:
    metadata:
      labels:
        app: acme-http01-solver
    spec:
      containers:
      - name: hooks
        image: metacontroller/jsonnetd:0.1
        imagePullPolicy: Always
        workingDir: /hooks
        volumeMounts:
        - name: hooks
          mountPath: /hooks
      volumes:
      - name: hooks
        configMap:
          name: acme-http01-solver-hooks
---
apiVersion: v1
kind: Service
metadata:
  name: acme-http01-solver
  namespace: metacontroller
spec:
  selector:
    app: acme-http01-solver
  ports:
  - port: 80
    targetPort: 8080

Once it is set up, second Ingress will be automatically created and also deleted after deletion of it's "parent" Ingress: https://metacontroller.github.io/metacontroller/api/decoratorcontroller.html#attachments

/remove-lifecycle stale

/remove-lifecycle rotten

/remove-lifecycle stale

cert-manager Helm chart supports hostsAliases now
# Optional hostAliases for cert-manager-controller pods. May be useful when performing ACME DNS-01 self checks.
hostAliases: []
# - ip: <IP_ADDRESS>
#   hostnames:
#   - foo.local
#   - bar.local

/remove-lifecycle stale

The only real fix to this is to just allow bypassing the self-check. We are provisioning LE certs for a lot of domains dynamically and cannot be redeploying cert-manager every time we add a new domain.


[2020-01-27] Deployment

NuGetGallery

[x] Merge dev to master https://github.com/NuGet/NuGetGallery/pull/7818
[ ] Deploy Release#56193

[ ] DEV
[X] INT
[x] PROD

Changes:

@loic-sharma Make deprecation reasons have consistent punctuation (#7812)
@loic-sharma Improve the display package page's performance (#7795)
@skofman1 Reject packages with duplicate dependency groups (#7814)

This is deployed but https://github.com/NuGet/NuGetGallery/issues/7714 needs verification


Need to sort out what happens with TCP if the upper layers decide to reuse the buffer they receive to do a send

Problem
The way our TCP implementation works is that it has a packet buffer chain, compacts things into the first buffer in the chain (sometimes), and then passes that first buffer in the chain to upper layers, after retaining it.
When upper layers return, it then updates the state of that buffer to indicate that some data got read from it.
This can fail if upper layers decide to reuse the packet buffer they received to send something.  If they do that, they might stomp on state that is not theirs (the bytes in the buffer which are part of the next message) and then TCP will also stomp on state that is not its (the DataLength() of the buffer after unwinding).
Proposed Solution
It seems like we have a few options:

Forbid upper layers from modifying the bytes of the packetbuffer.  This prevents in-place decryption and such.  Note that if there are other things upper layers want to do that are not same-size (like in-place decryption is), that could be a problem even if they are not reusing the buffer for sending.
Change TCP to ensure that it never has bytes from more than one message in a given packetbuffer in its queue.  That means not using CompactHead, but that might not be enough if a packet can come off the wire with pieces of multiple messages in it...
Check whether there is anything else in our buffer when pulling things out of the TCP queue, and actually copy, not just retain, as needed.  This might be done in tandem with some attempt to do item 2, so we'll mostly avoid having multiple messages in a buffer and copy when we can't avoid it.
Do nothing, document the heck out of what consumers are allowed to do with the incoming message buffer.  This is my least-favorite option, because it's too easy to screw this up as a consumer.

Other ideas?
@andy31415 @pan-apple @kpschoedel

Fixed by #5265 (commit 4eb50c2b) — upper layers get sole ownership.


Fixed broken ntttcp test

[Fix] Two support files for NTTTCP tests were not being uploaded. Added them to XML definition.
[Refactoring] Moved hardcoded linux script names from Powershell to XML definition.

Execution is verified
08/06/2018 11:57:58 : [INFO ] ~~~~~~~~~~~~~~~TEST END : PERF-NETWORK-TCP-THROUGHPUT-MULTICONNECTION-Synthetic~~~~~~~~~~
08/06/2018 11:57:58 : [INFO ] CURRENT - PASS    - 1
08/06/2018 11:57:58 : [INFO ] CURRENT - FAIL    - 0
08/06/2018 11:57:58 : [INFO ] CURRENT - ABORTED - 0
08/06/2018 11:57:58 : [INFO ] Checking background cleanup jobs..
08/06/2018 11:57:58 : [INFO ] Removed 8 context files.
08/06/2018 11:57:58 : [INFO ] Cycle Finished.. TC-83385
08/06/2018 11:57:58 : [INFO ]
Test Results Summary
ICA test run on 08/06/2018 10:24:55
ARM Image under test RedHat : RHEL : 7.4 : latest
Total Executed TestCases        1 (       1 Pass,        0 Fail,        0 Abort)
Total Execution Time(dd:hh:mm) 0:1:33
XML file: TestConfiguration
PERF-NETWORK-TCP-THROUGHPUT-MULTICONNECTION-Synthetic Execution Time: 93 minutes
	PERF-NETWORK-TCP-THROUGHPUT-MULTICONNECTION-Synthetic : PASS
Logs can be found at .\TestResults\2018-06-08-10-24-48-7371


Used anugular2 forms for quick add work item

Fixes for #139

Can one of the admins verify this patch?

Reviewed the PR and LGTM.

[test]

@nimishamukherjee Why did you want the quick add to be a form? It does not appear to add anything to it by making it a form.

@joshuawilson primarily for consistency. We can drop this if needed

These changes break the UI and adding Forms to this component does not provide value. Therefore, I'm closing it.


layoutSubviews crashes on scroll

cant really tell why this is happening but when i scroll up by tapping on the status bar i get this crash (as in the picture) anyone know's how to deal with this?
New issue checklist

[*] I have reviewed the README and documentation
[ *] I have searched existing issues and this is not a duplicate

General information

IGListKit version:
iOS version(s): 10.1
CocoaPods/Carthage version: 1.1.1
Xcode version: 8.2
Devices/Simulators affected: Device
Reproducible in the demo project? (Yes/No): Not sure
Related issues:

At minimum I think anyone would need a stacktrace or (much better) an example project to understand what is going on. A crash happens because something critically wrong so my best guess is that you have configured something out of the ordinary that IGListKit does not support or you got confused about how to do XYZ correct :)

i have the same issue, but i don´t know if are in the same cases that @rotemdoron, but i have an stack trace, and is relationated to another isses
Stack trace crash layoutsubview

I replied in your issue @kleiberjp :) Thanks for the stacktrace and the example project! Those help a a lot

hi @heumn  thanks for replying, the only stack trace i get is this :
libc++abi.dylib: terminating with uncaught exception of type NSException (lldb)

it happens always when i scroll up by clicking on the status bar

Thanks for the screenshot :) This is only "half" of the crash information. You are not printing / showing the exception thrown when it crashes
Would it be possible with an example project?

ok so this is the exception im getting :
negative sizes are not supported in the flow layout
but there is no place in the sizeForItem that i give a negative size

@rotemdoron can you post some of the code for your section controllers? Are you doing any form of subtraction in there? Also you're using UICollectionViewFlowLayout right?

yeap my collectionview is in storyboard together with the flowlayout, not using the flow layout in code though.
code example :
` func cellWidth() -> CGFloat {
return collectionContext!.containerSize.width - inset.left - inset.right
}
func sizeForItem(at index: Int) -> CGSize {

    let cellType = self.object?.articleSectionList[index]
    var size : CGSize = CGSize(width: cellWidth(), height: 0)

    switch cellType! {
    case .stamp:
        size.height = WHStampLabelCollectionCell.getCellHeight()
        break
    case .writer:
        let height = WHWriterCollectionViewCell.textHeight((object?.writer?.fullNameAndCredit)!, width: cellWidth())
        size.height = height
        break
    case .date:
        size.height = WHDateCollectionViewCell.getDateCellHeight()
        break

    case .content:
        let height = WHContentLabelCollectionCell.textHeight((object?.content)!, width: cellWidth())
        size.height = height
        break
    case .media:
        size.height = (object?.mediaSize.value)!
        break
    case .hashTag:
        size.height = calculateHashTagsHeight()
        break
    case .embed:
        size.height = (object?.embededSize.value)!
        break
    }

    print("size -- \(size) and Type -- \(cellType!)")
        return size
}

func cellForItem(at index: Int) -> UICollectionViewCell {

    let cellType = self.object?.articleSectionList[index]

    switch cellType!
    {
    case .stamp:
        let cell = self.collectionContext!.dequeueReusableCell(withNibName: WHStampLabelCollectionCell.nibName, bundle: nil, for: self, at: index) as! WHStampLabelCollectionCell
        cell.configureCellWith(article: object!)
        return cell

    case .writer:
        let cell = self.collectionContext!.dequeueReusableCell(withNibName: WHWriterCollectionViewCell.nibName, bundle: nil, for: self, at: index) as! WHWriterCollectionViewCell
        cell.configureCellWith(article: object!)
        cell.delegate = self

        return cell

    case .date:
        let cell = self.collectionContext!.dequeueReusableCell(withNibName: WHDateCollectionViewCell.nibName, bundle: nil, for: self, at: index) as! WHDateCollectionViewCell
        cell.configureCellWith(article: object!)
        return cell

    case .content:
        let cell = self.collectionContext!.dequeueReusableCell(withNibName: WHContentLabelCollectionCell.nibName, bundle: nil, for: self, at: index) as! WHContentLabelCollectionCell
        cell.textLabel.text = object?.content

        return cell

    case .media:
        let cell = collectionContext!.dequeueReusableCell(withNibName: MediaTypesCollectionCell.nibName, bundle: nil, for: self, at: index) as! MediaTypesCollectionCell
        adapter.collectionView = cell.collectionView

        return cell

    case .embed:
        let cell = configureEmbedCell(index: index)
        return cell

    case .hashTag:
        let cell = collectionContext!.dequeueReusableCell(withNibName: WHHashtagsCollectionCell.className, bundle: nil, for: self, at: index) as! WHHashtagsCollectionCell
        cell.configureCell(hashtags: object?.hashtag, cellTappedBlock: {(hashTag) in
            _ = self.viewController?.navigationController?.wh_PushViewController(type: .hashTags, presentType: .push , animated: true, userInfo: hashTag)
            AnalyticsManager.instance.trackAction(event: .hashtag, info: nil)
        })

        return cell
    }
}

`
you can see im printing the sizes, none of them is negative size or zero.

@rotemdoron Hmm the return collectionContext!.containerSize.width - inset.left - inset.right looks suspect.  Could you add an assert that checks if the container width is 0? I'm going to open another issue to track possibly fixing making this mistake.

@rnystrom thanks for the feedback, i tried assert seems the container size is correct im also printing it and the size is right even right before the crash.


[SPARK-25737][CORE] Remove JavaSparkContextVarargsWorkaround

What changes were proposed in this pull request?
Remove JavaSparkContextVarargsWorkaround
How was this patch tested?
Existing tests.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3994/
Test PASSed.

Test build #97402 has started for PR 22729 at commit 4a31de3.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97402/
Test FAILed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/3996/
Test PASSed.

Test build #97404 has started for PR 22729 at commit 29edd40.

Test build #97404 has finished for PR 22729 at commit 29edd40.

This patch fails PySpark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97404/
Test FAILed.

Test build #97417 has started for PR 22729 at commit c4e6dee.

Test build #97417 has finished for PR 22729 at commit c4e6dee.

This patch fails to build.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97417/
Test FAILed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/4007/
Test PASSed.

Merged build finished. Test PASSed.

Test build #97422 has started for PR 22729 at commit 819b8a3.

Test build #97422 has finished for PR 22729 at commit 819b8a3.

This patch fails MiMa tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97422/
Test FAILed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/4018/
Test PASSed.

Merged build finished. Test PASSed.

Test build #97428 has started for PR 22729 at commit 0860d27.

Test build #97428 has finished for PR 22729 at commit 0860d27.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97428/
Test FAILed.

Test build #4380 has started for PR 22729 at commit 0860d27.

Test build #4380 has finished for PR 22729 at commit 0860d27.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

retest this please

Test build #97487 has started for PR 22729 at commit 0860d27.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/4060/
Test PASSed.

Test build #97487 has finished for PR 22729 at commit 0860d27.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97487/
Test FAILed.

I think it's a legit failure. It touches a Kinesis test, and that has triggered what I assume is an existing problem in the Kinesis integration. It looks like it didn't like the fact that we updated jackson in master, but that change hadn't triggered this test. I'll follow up and see about harmonizing or fixing it first.

Jenkins, retest this please.

Test build #97616 has started for PR 22729 at commit 0860d27.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/4130/
Test PASSed.

Test build #97616 has finished for PR 22729 at commit 0860d27.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97616/
Test FAILed.

Test build #4383 has finished for PR 22729 at commit 0860d27.

This patch fails Spark unit tests.
This patch does not merge cleanly.
This patch adds no public classes.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/4306/
Test PASSed.

Merged build finished. Test PASSed.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/4337/
Test PASSed.

Test build #4385 has started for PR 22729 at commit 0860d27.

Test build #4385 has finished for PR 22729 at commit 0860d27.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #4387 has started for PR 22729 at commit 0860d27.

Test build #4387 has finished for PR 22729 at commit 0860d27.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #4390 has started for PR 22729 at commit 0860d27.

Test build #4390 has finished for PR 22729 at commit 0860d27.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Test build #4391 has started for PR 22729 at commit 0860d27.

Test build #4391 has finished for PR 22729 at commit 0860d27.

This patch fails due to an unknown error code, -9.
This patch merges cleanly.
This patch adds no public classes.

Test build #97979 has started for PR 22729 at commit 367f3e9.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/4443/
Test PASSed.

Test build #97979 has finished for PR 22729 at commit 367f3e9.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/97979/
Test PASSed.

Merged to master


Updates Python test expansion service to use Cloud Pickle

Blocked by https://github.com/apache/beam/pull/23739.

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

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

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

See CI.md for more information about GitHub Actions CI.

R: @robertwb

Run XVR_JavaUsingPython_Dataflow PostCommit

Run XVR_JavaUsingPython_Dataflow PostCommit

Run XVR_JavaUsingPython_Dataflow PostCommit

Run XVR_JavaUsingPython_Dataflow PostCommit

Run Python PreCommit


WIP: Fix bug #22 no paginator on opti build

Fix #22

Need to simplify code when detecting library type

Still waiting for review

IKR


Replace Promised axiom for a Blocking axiom

The issue with the previous approach is that you can't override methods for java in a class extending a Promised class because the methods get flagged for js/swift. Removing that flagging breaks more things because java wants to generate all the axioms that Promised axiom installs. This feels like the simplest approach.

What I don't like about this is that even after the waiting is done, you still call maybeWAitFor which is synchronized, this may hurt performance in highly concurrent situations.  Would be better if after this was started we changed state to one without the check, ideally then the JIT would eventually inline this decorator entirely if its in a hot spot.

Oh good point. I'll take a stab at that and let you know when it's updated.

Ok I updated this to be more like swift's implementation of the blocking axiom which didn't use synchronized and used a semaphore instead. I'm not sure if a semaphore is the right tool for the job here though. I release all waiting threads via:
semaphore.release(semaphore.getQueueLength());

but my understanding is that getQueueLength is just an estimate because that length could change from another thread so that might not flush all threads if something makes it into the condition to wait, but gets pre-empted before it starts waiting and during that time the property gets set and all waiters get flushed. Is that a possibility? My concurrency game isn't great so any thoughts/suggestions are greatly appreciated. Is there a concurrency tool other than a semaphore I'm missing?


Caffe-cpu in trainning and create lmdb

Hi Rich Zhang! I am trying to train colorization with caffe-cpu on ubuntu 18.04. After I run ./train/fetch_caffe.sh the ./caffe-colorization does not exist, instead ./caffe_private_pascal appear and how to import image by mysefl not use image from imagenet.org.
Can you support me? I am a newbie

I think ./caffe-colorization and ./caffe_private_pascal do the same thing in fact,both of them are used for the installation of Caffe.
You can download your own images and save them on your disk,prepare your data and txt file,open caffe/example/imagenet/create_imagenet.h,modify the first five variable with your own path,run the create_imagenet.h and it will produce lmdb files.

about lmdb file,i found some unknown mistakes in my answer,you can refer to
https://stackoverflow.com/questions/31427094/a-guide-to-convert-imageset-cpp#


Number of points should be capped at line length

At first I didn't 'get' what number of points did. But now I see it, it's the plotting points.
However, if the line length is less than the number of points, default 100, then artifacts are produced:

y-values are just duplicated to 'fill' the empty points, so those flat sections aren't real.
Here's the actual data with Num points = to actual number of pixels measured.

Careful inspection of the image layer confirms that this is the correct plot, not the one above for 100 points.
Number of points should thus cap at the number of pixels of the line, the number of actual data points.
I can understand downsampling the plot in the case of long lines and many points, such that less points are plotted than measured, but the other direction is definitely not correct.
BTW Perhaps downsampling is a better way of conveying what 'Number of points' is supposed to do?

Sure @psobolewskiPhD, like mentioned above, this project is open for contributions. Just file a pull-request with a user interface with more options. I don't insist in the current way of plotting as default, but I like the functionality :-)


FastCell with ObservableCollection and .Insert(0, item) is buggy

I have a ListView which is bound to an ObservableCollection. Changing the ObservableCollection works great and the ListView using FastCell updates the items correctly.
But when I'm going to add an item on the top of the ObservableCollection with:
MyObservableCollection.Insert(0, myNewItem);
the elements in the List sometimes get the same BindingContext assigned, so I have duplicates in my ListView despite having them in my ObservableCollection.
This is noticeable if you have a small List with 3-10 items in it. In bigger lists it seems to work fine.
This also happens when moving items (sorting) in the collection.
Any idea on this?

I'll look into it
Sent from my iPhone

On 26 Jun 2015, at 06:53, coonmoo<EMAIL_ADDRESS>wrote:
I have a ListView which is bound to an ObservableCollection. Changing the ObservableCollection works great and the ListView using FastCell updates the items correctly.
But when I'm going to add an item on the top of the ObservableCollection with:
MyObservableCollection.Insert(0, myNewItem);
the elements in the List sometimes get the same BindingContext assigned, so I have duplicates in my ListView despite having them in my ObservableCollection.
This is noticeable if you have a small List with 3-10 items in it. In bigger lists it seems to work fine.
Any idea on this?
—
Reply to this email directly or view it on GitHub.


Support suggestions in widget tree rather than an Overlay

Is your feature request related to a problem? Please describe.
suggestions as an overlay above the widgets by default and no option to show it in the widget tree please add any property to show it within the widget not over the widget
Describe the solution you'd like
There should be any property to toggle this .

Hey @WaseemAbbasi22, Thanks for filing the issue. This was intentionally removed considering it abruptly shows the UI in the widget tree. May I know what your use case is?

Closing due to lack of activity.


Typo in instructions for Path

The instructions indicate that when you put the contents of the zip folder into C:\bin\phantomjs that you should then add C:\bin\phantomjs to the environment variables. However, the newest version (2.0.0) has "phantomjs.exe" inside of "bin" which means the PATH needs to also be changed to be "C:\bin\phantomjs\bin".

Please be specific: which instructions? This one seems to be correct: http://phantomjs.org/download.html.

Due to the lack of a concrete follow-up possibility, this issue will be closed.


How to combine scores of stage1 and stage2

What if their prediction class is different? Like stage1 predict the box as cat, while stage2 predict the box as dog.
Thank you

We multiply the softmax score elementwise, which is a 21-D vector for pascal voc and 81-D vector for coco. For example, stage 1 predict [0.9, 0.1] and stage 2 predict [0.2, 0.8], the final score is [0.18, 0.08].


Fix broken build

An old version of xo had a bug which caused the build to fail on Windows. See https://travis-ci.org/github/sindresorhus/clipboardy/jobs/649355100#L83-L96
cc @sindresorhus

@sindresorhus We may or may not have found another xo bug: https://travis-ci.org/github/sindresorhus/clipboardy/jobs/664474048#L233

@sindresorhus xo found a problem with the requested Node engine not being compatible with the spread syntax. Therefore, the minimum node version change should still be a minor patch since versions prior to 8.3 were never working but not caught.

master is passing now, so I'm gonna close this. We can upgrade XO when we target Node.js 10 at some point. I don't want to do that and a major release unless we have to though.


Adds a script for removing unused diagnostics

This adds a script which only runs on linux boxes, that searches the codebase for every diagnostic and lets you know if nothing is found.
TODO: Add to CI.

I can use findstr to check

Yeah, lets do it


Update README.md

Update documentation URL

Closing this pull request as the link has been updated here: https://github.com/blackducksoftware/detect-ado/pull/72#discussion_r1830006786


Some purely style changes

R: @beaufortfrancois
I doubled the size of sliders in Chrome/webkit[1] because the default size is too small on mobile.
I changed my toolbar class to be a flex row.
I also changed the image preview on the capture page so that it showed the whole image, rather than expanding the image to fully cover the screen. It was surprising to people to find that the photo was cropped a lot less than the preview.
[1] I haven't been through the process of styling sliders for FF and Edge yet because I wanted to lock down the style once rather than have to make every change 3 times while I iterated on it.

LGTM


Alternative for sys.dm_db_index_usage_stats in Babelfish

Hi @staticlibs ,
The table sys.dm_db_index_usage_stats are used in our application in one of the scenario to get the last updated date of the particular table. But In postgresql, during the call for the specific procedure, we are getting error like the relation is not exist.
Sql-

Error -
Used Query-SELECT MAX(Last_User_Update) AS Last_User_Update FROM sys.dm_db_index_usage_stats WHERE Object_Id = object_id({0})
Question: In Postgresql/Babelfish, we are having any tables/procedure/functions to get these details.

@Aravind2601
The only reliable way to do this in Postgres is to create triggers for every table and record the fact of the table update manually. This is not as laborious as it sounds, as such triggers can be generated in T-SQL for all tables from system catalog. Still this is a manual and major effort.
There are a number of ways to get an "approximate" date of the last update (with false positives or false negatives depending on a method) - I can elaborate on them if your business requirement does not mandate these update dates to be precise.

@staticlibs sent Alex. Please check and let me know.

@Aravind2601
If you need the last update timestamp for a particular table, you can enable track_commit_timestamp option:

And then use the following query:
select max(pg_xact_commit_timestamp(xmin)) from tab1

The problem with this approach is that it stores timestamp information only for existing rows. So if the row is deleted - this information is lost. If it is necessary to track the deletion of rows, then the trigger approach from this comment can be used.