text:
🛑 wvtaxsales is down

In 37167ba, wvtaxsales (wvtaxsales.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: wvtaxsales is back up in e49fa83.


text:
🛑 ojolink is down

In 6e82e80, ojolink (ojolink.net) was down:

HTTP code: 403
Response time: 475 ms

Resolved: Ojolink is back up in 2954599.

source: gharchive/issue

license: MIT

license_type: permissive

license_source: github-api


text:
🛑 ojolink is down

In c219d9e, ojolink (ojolink.net) was down:

HTTP code: 403
Response time: 444 ms

Resolved: Ojolink is back up in 83a9738.


text:
🛑 orkut is down

In 959ef13, orkut (orkut.com.br) was down:

HTTP code: 429
Response time: 639 ms

Resolved: orkut is back up in 30ae80d.


text:
🛑 orkut is down

In d5a7fce, orkut (orkut.com.br) was down:

HTTP code: 429
Response time: 784 ms

Resolved: orkut is back up in 1b19cb3.


text:
🛑 inkcityusa is down

In 58ff054, inkcityusa (inkcityusa.com) was down:

HTTP code: 502
Response time: 548 ms

Resolved: inkcityusa is back up in 8b923d1.


text:
🛑 orkut is down

In 4c33aaf, orkut (orkut.com.br) was down:

HTTP code: 0
Response time: 0 ms

Resolved: orkut is back up in ae97d29.


text:
🛑 ojolink is down

In 688f1df, ojolink (ojolink.net) was down:

HTTP code: 403
Response time: 386 ms

Resolved: Ojolink is back up in 633840d.


text:
🛑 ojolink is down

In 9646af1, ojolink (ojolink.net) was down:

HTTP code: 403
Response time: 390 ms

Resolved: Ojolink is back up in 3e8ecc3.


text:
🛑 ojolink is down

In 712acf7, ojolink (ojolink.net) was down:

HTTP code: 403
Response time: 512 ms

Resolved: Ojolink is back up in 819f2df.


text:
🛑 orkut is down

In 9b21f9e, orkut (orkut.com.br) was down:

HTTP code: 429
Response time: 687 ms

Resolved: orkut is back up in 23c9b5d.


text:
🛑 ojolink is down

In 9e8282c, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 249a13e.


text:
🛑 ojolink is down

In 613761d, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 0b7fbe5.


text:
🛑 ojolink is down

In 872f760, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 12adf13.


text:
🛑 ojolink is down

In 2ca0c85, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in a3032b4.


text:
🛑 carlinha is down

In 48bb43a, carlinha (carlinha.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: carlinha is back up in c67a207.


text:
🛑 ojolink is down

In 7457d41, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 1d34522.


text:
🛑 ojolink is down

In 78fc091, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 885caa3.


text:
🛑 ojolink is down

In a8c1fee, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 6f9e756 after 828 days, 5 hours, 8 minutes.


text:
🛑 ojolink is down

In 6d9bf6e, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in d5b17e7 after 832 days, 10 hours, 10 minutes.


text:
🛑 feest-start is down

In 5bc34f2, feest-start (feest-start.nl) was down:

HTTP code: 0
Response time: 0 ms

Resolved: feest-start is back up in f1d763c after 28 minutes.


text:
🛑 ojolink is down

In 5533db2, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in d3b0ad3 after 20 minutes.


text:
🛑 carlinha is down

In a5b8fbe, carlinha (carlinha.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: carlinha is back up in 42f6da3 after 18 minutes.


text:
🛑 carlinha is down

In 48a642e, carlinha (carlinha.org) was down:

HTTP code: 0
Response time: 0 ms

Resolved: carlinha is back up in e8274f0 after 12 hours, 37 minutes.


text:
🛑 hcr is down

In 9158254, hcr (hcr.co.uk) was down:

HTTP code: 0
Response time: 0 ms

Resolved: hcr is back up in 42e5283 after .


text:
🛑 asgreenas is down

In a422fad, asgreenas (asgreenas.com) was down:

HTTP code: 403
Response time: 690 ms

Resolved: asgreenas is back up in 6b49d1a after 32 minutes.


text:
🛑 youjizz is down

In fc73873, youjizz (youjizz.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: youjizz is back up in ed9952a after 1 hour, 58 minutes.


text:
🛑 simerini is down

In e6956d4, simerini (simerini.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: simerini is back up in 9e7b687 after 2 days, 20 hours, 31 minutes.


text:
🛑 torrentzap is down

In 353ca72, torrentzap (torrentzap.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: torrentzap is back up in 223a9c0 after 52 minutes.


text:
🛑 ojolink is down

In 1488aa6, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 9b63965 after 13 minutes.


text:
🛑 ojolink is down

In fe8d217, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 3d5bfc6 after 36 minutes.


text:
🛑 orkut is down

In cdce6a9, orkut (orkut.com.br) was down:

HTTP code: 0
Response time: 0 ms

Resolved: orkut is back up in 22cc3c8.


text:
🛑 ojolink is down

In f371f58, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 7fae98b after 17 minutes.


text:
🛑 ojolink is down

In 2623056, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 31ec004 after 19 minutes.


text:
🛑 uzboys is down

In 489a339, uzboys (uzboys.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: uzboys is back up in 0c30068 after 1 hour, 16 minutes.


text:
🛑 adobe is down

In b730fdc, adobe (adobe.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: adobe is back up in 964f0bd after 77 days, 7 hours, 19 minutes.


text:
🛑 ojolink is down

In c8a2a42, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in 8be28eb after 9 minutes.


text:
🛑 orkut is down

In 4957d41, orkut (orkut.co.in) was down:

HTTP code: 0
Response time: 0 ms

Resolved: orkut is back up in b9fd5b6 after 45 minutes.


text:
🛑 ojolink is down

In 0d718af, ojolink (ojolink.fr) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Ojolink is back up in e14f9e9 after 8 minutes.


text:
🛑 uzboys is down

In 90fbb71, uzboys (uzboys.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: uzboys is back up in 06ac129 after 3 hours, 15 minutes.


text:
🛑 uzboys is down

In 9a1150d, uzboys (uzboys.com) was down:

HTTP code: 0
Response time: 0 ms

Resolved: uzboys is back up in f282744 after 2 hours, 27 minutes.


text:
Improve tests for Coreg, in particular with NaNs

As mentioned in #135, many issues arose when using DEMs with NaNs. Current tests do not include nans, so it should be improved.
The lower level function such as get_horizontal_shift or calculate_slope_aspect should also be tested, to more easily identify the source of the issue.

And also for all Coreg subclasses, see #202

authors: adehecq rhugonnet

repo: GlacioHack/xdem


text:
Update scalajs-dom to 2.7.0

About this PR
📦 Updates org.scala-js:scalajs-dom from 0.9.8 to 2.7.0 ⚠
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (0.9.8).
You might want to review and update them manually.
html/src/main/scala/org/lrng/binding/AttributeFactories.scala

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-js", artifactId = "scalajs-dom" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "org.scala-js", artifactId = "scalajs-dom" }
}]

labels: library-update, early-semver-major, semver-spec-major, version-scheme:early-semver, old-version-remains, commit-count:1

Superseded by #250.

source: gharchive/pull-request


text:
Update sbt to 1.7.2

Updates org.scala-sbt:sbt from 1.3.13 to 1.7.2.
GitHub Release Notes - Version Diff
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

Applied Scalafix Migrations

org.scala-sbt:sbt:1.5.0

https://gist.githubusercontent.com/eed3si9n/57e83f5330592d968ce49f0d5030d4d5/raw/7f576f16a90e432baa49911c9a66204c354947bb/Sbt0_13BuildSyntax.scala
Documentation: https://eed3si9n.com/syntactic-scalafix-rule-for-unified-slash-syntax

Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.scala-sbt", artifactId = "sbt" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "@monthly" },
  dependency = { groupId = "org.scala-sbt", artifactId = "sbt" }
}]

labels: library-update, early-semver-minor, semver-spec-minor, scalafix-migrations, commit-count:n:2

Superseded by #85.


text:
Apple .plist support

Description
I would like to see support for Apple .plist xml files.
If I beautify a plist file I get an error:

Atom Beautify could not determine a supported beautifier to handle this file with grammar "Property List (XML)" and extension "plist". If you would like to request support for this file and its language, please create an issue for Atom Beautify at https://github.com/Glavin001/atom-beautify/issues

I would like to up vote this!

Just submit a pull request to extend XML beautification to support the .plist file extension:
https://github.com/Glavin001/atom-beautify/blob/master/src/languages/xml.coffee

Closed by https://github.com/Glavin001/atom-beautify/pull/1335

Published to v0.29.15

authors: Glavin001 bochoven pnerum prettydiff

license: mit

license_source: bigquery


text:
Rename maxnumemailaccount

The service limit maxnumemailaccount in account/info should probably be renamed maxnumemailaccounts

Thanks for reporting! Sorry it took so long for us to respond :cry:
We've added maxnumemailaccounts in addition to maxnumemailaccount (now deprecated) and will remove maxnumemailaccount at a later date.

authors: peterhellberg wecc

repo: GleSYS/API


text:
making final changes for mvp frappe

Please provide enough information so that others can review your pull request:

Explain the details for making this change. What existing problem does the pull request solve?

Screenshots/GIFs

making final changes for mvp frappe

repo: GlobeDock/frappe


text:
Feature/java 2 objc

@rasekhg @adamhillglympse @corvino @Invader-Zim PTAL
Java -> ObjectiveC panel was added.

LGTM

authors: egorpushkin rasekhg

repo: Glympse/CrossCompilingConsole


text:
ModManifest Validation - Make sure error messages include a reference to the mod that cause the validation error

As @ithinkandicode mentioned on Discord, the deprecation warning of compatible_mod_loader_version doesn't include the mod id, it is caused by. This requires the user to follow the stack trace and check the data himself. We can make that process easier by adding the mod id to the error message.

From a quick first look this functions need this treatment:

[x] _handle_compatible_mod_loader_version()
[x] is_semver_valid()

closed by https://github.com/GodotModding/godot-mod-loader/pull/197

repo: GodotModding/godot-mod-loader


text:
Can't build C++ bindings for Godot 3.1

Hi. I was trying to add C++ support to my project in according with this tutorial, but building process was failed:
$ git clone --recursive -b 3.1 https://github.com/GodotNativeTools/godot-cpp
$ cd godot-cpp
godot-cpp $ scons platform=linux generate_bindings=yes use_custom_api_file=yes custom_api_file=../api.json
scons: Reading SConscript files ...
...
...
g++ -o src/gen/AudioEffectSpectrumAnalyzer.o -c -fPIC -g -std=c++14 -Wwrite-strings -Og -m32 -I. -Igodot_headers -Iinclude -Iinclude/gen -Iinclude/core src/gen/AudioEffectSpectrumAnalyzer.cpp
In file included from src/gen/AudioEffectSpectrumAnalyzer.cpp:1:0:
include/gen/AudioEffectSpectrumAnalyzer.hpp:35:31: error: invalid use of incomplete type 'class godot::AudioEffectSpectrumAnalyzer'
  AudioEffectSpectrumAnalyzer::FFT_Size get_fft_size() const;
                               ^~~~~~~~
In file included from src/gen/AudioEffectSpectrumAnalyzer.cpp:1:0:
include/gen/AudioEffectSpectrumAnalyzer.hpp:16:7: note: definition of 'class godot::AudioEffectSpectrumAnalyzer' is not complete until the closing brace
 class AudioEffectSpectrumAnalyzer : public AudioEffect {
       ^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/gen/AudioEffectSpectrumAnalyzer.cpp:61:30: error: 'FFT_Size' in 'class godot::AudioEffectSpectrumAnalyzer' does not name a type
 AudioEffectSpectrumAnalyzer::FFT_Size AudioEffectSpectrumAnalyzer::get_fft_size() const {
                              ^~~~~~~~
scons: *** [src/gen/AudioEffectSpectrumAnalyzer.o] Error 1
scons: building terminated because of errors.

Compiler:
$ g++ --version
g++ (Ubuntu 7.4.0-1ubuntu1~16.04~ppa1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

What I'm doing wrong?
Thanks!

Hi, do not specify the api.json, it should be one present in headers submodule. Specify godotbinpath argument with path to your Godot executable. If tout prefer to use clang instead of gcc add use_llvm=yes

@piiertho thank you, it works!

repo: GodotNativeTools/godot-cpp


text:
Environment Cementery (stone wall) - Stone_wall 3D Model

[x] 3D Model
[x] UVS
[x] Texture

EXPECTED RESULT:
Finished a estructure of cementery with the textures to be able to export unity.

Model textured & ready to be implemented in the project's next version.

authors: CamachiN Quooler

repo: GoldenArmor/HostileKingdom


text:
[BUG/Improvements] Pool Transactions not displaying

No Transactions displayed

“Show More” appears when there are no transactions (should only appear after 25 transactions and the page truncates)

I fixed the UI for recent transactions. Changes are in an open PR.

@sirpy @decentralauren @L03TJ3 One thing that is not clear to me: How do I get the data for the recent transactions?
I could filter events in the smart contract, but that won't provide all of the necessary data. The amount donated in a transaction is not available on-chain. The smart contract instead knows about flow rates and the total amount a supporter has contributed.

@krisbitney i'm not sure what you mean. all data should be from the subgraph.
If you mean right after user has performed an action and you want to display it for him then we need to either add some refresh for subgraph after user actions or add the action itself manually to the apollo cache

@krisbitney i'm not sure what you mean. all data should be from the subgraph. If you mean right after user has performed an action and you want to display it for him then we need to either add some refresh for subgraph after user actions or add the action itself manually to the apollo cache

No, that is not what I mean. The subgraph is itself limited to on-chain data, so modifying the subgraph won't help.
According to the figma, the transaction items in the "recent transactions" list should have G$ amounts. How do I get those amounts?

ok I see.
@decentralauren @patpedrosa What type of transactions is "recent transactions" supposed to show? donations? rewards distributions? probably the name should be changed to "recent X".
@krisbitney we'll need to update the subgraph. if it is donations we can add a DonationEvent record (create it in handleSupport) for rewards distribution txs we already have the EventData records

ok I see. @decentralauren @patpedrosa What type of transactions is "recent transactions" supposed to show? donations? rewards distributions? probably the name should be changed to "recent X".
@krisbitney we'll need to update the subgraph. if it is donations we can add a DonationEvent record (create it in handleSupport) for rewards distribution txs we already have the EventData records

Yes, for sure. I can add events for donations. Still, the donation events won't have the amount donated because the contract knows only about flow rates. The amount the user donated is a function of flowRate and the duration of the flow.

I can have the amount in the donations be flowing rates, so they will show how much the user donated so far but not the total amount the user will donate through the transaction. What do you think?

Well donations are either single or a flow rate.
both the donation amount and flow rate are known from the event.
if it is a flow rate then we can show next to the TX - 50G$/month
if it is a single donation then just show the amount - 50G$

@decentralauren @patpedrosa Transaction pool is showing. What do we need to do with the "Show more" button?

@L03TJ3 make action item for loading of transaction list

@L03TJ3 make action item for loading of transaction list.

[ ]  - should show payouts / donated amounts

The transactions list already displays in the ViewCollective component, with payouts and donated amounts

Unable to verify on UI but in code it shows it should show both donation + stewards payment so closing.
Show more button is defined here: https://github.com/GoodDollar/GoodCollective/issues/124
What has not been added was if it is a flow rate then we can show next to the TX - 50G$/month
not sure what to do with that
@patpedrosa @decentralauren

Unable to verify on UI but in code it shows it should show both donation + stewards payment so closing.
Show more button is defined here: #124
What has not been added was if it is a flow rate then we can show next to the TX - 50G$/month not sure what to do with that @patpedrosa @decentralauren

It looks like I misread that and made the donation amount a flowing rate. We can show all of the donation amounts in transactions in terms of a single unit (e.g. per month), but we cannot know whether the supporter intended to donate per day, per week, per month, etc.

Closing this ticket as the open item is in #167

authors: L03TJ3 decentralauren krisbitney sirpy vldkhh

repo: GoodDollar/GoodCollective


text:
[Bug] Canceling the stream takes user to an empty profile page

Canceling a stream does not mean that the donations made so far were withdrawed, so the profile should now show empty.

The donations aren't being removed. I think the wallet is empty due to this error that is preventing subgraph queries:

@sirpy @L03TJ3 I don't have access to the subgraph infra. Would you be able to take a look and see what's going on?

@krisbitney thegraph is a free service, we dont have any special access. Does this still happen?

@krisbitney thegraph is a free service, we dont have any special access. Does this still happen?

I'm no longer getting this error. Maybe it happened because I had recently redeployed the subgraph multiple times and we were rate limited, or maybe The Graph was having some issues on their end. I don't know.
@patpedrosa Could you please try again? I just tested it and my donation still showed.
I actually had the opposite problem: it took a few minutes before my profile reflected that the donation had stopped, so it looked like the donation kept flowing. My total donated amount went up to $GD 134, then reverted back to 132. The donation fetching is polled with an interval of 1 second (i.e. it checks for new data every 1 second), but it takes a short time for the transaction to finalize and the subgraph to update.

I've retested it, it's showing correctly. Thank you.

Thank you for taking another look. I appreciate it!

authors: krisbitney patpedrosa sirpy


text:
User should capture good quality facial picture

Based on kairo id-wallet
Build a component that analyzes video stream of user
User should see an oval in top of screen where he should place his head
When the following conditions apply oval turns to green and we take screenshot

[x] distance between eyes passes minimum (see kairos existing test)

[ ] need to check screen distance vs captured image distance
[ ] adapt to kairos best practices

[x] head roll + yaw - ie straight face
[x] head fits in oval/big enough ie takes > X% of oval width and %Y of height

[ ] adapt to kairos best practices

[ ] image resolution should match kairos best practices
[x] natural expression

best practices in new issue

repo: GoodDollar/GoodDAPP


text:
response.remoteAddress() when use proxy

Puppeteer version: 1.12.2
Platform / OS version: Debian 9.6 stretch
Node.js version: 10.14.0

The code below uses to get all IP of servers requested when the webpage loading
const puppeteer	  = require('puppeteer');

(async () => {

const browser = await puppeteer.launch({
    args: ['--proxy-server=XXX.YYY.X.ZZ:5002']
   });

const page = await browser.newPage();

page.on('response', async(response) => {
    console.log(response.remoteAddress().ip);
   });

await page.goto('https://github.com/');

await browser.close();

})();

Instead of servers IP list, there just proxy IP shown in all requests.
When proxy not used, everything is ok. But what should to do, if proxy needed?
Please, help

@dolima I don't think there's much we can do regarding this; it's up to a proxy to provide you with a real IP address you're contacting.

authors: aslushnikov dolima

repo: GoogleChrome/puppeteer


text:
skipWaiting() fails to activate waiting service worker

Library Affected:
workbox-core v4.3.1
Browser & Platform:
Windows: Google Chrome 78.0.3904.108, Firefox 71.0
Issue Description:
I've tried to follow the instructions at the docs to show a prompt, when an update is available.
After clicking the button that triggers wb.messageSW({type: 'SKIP_WAITING'});, the message is processed in the service worker, and skipWaiting() is called. Then, a warning is logged to console in chrome:
Event handler of 'install' event must be added on the initial evaluation of worker script.. The service worker
I've also tried to do a minimal reproduction of the bug, but there, it works as intended.
Any idea whats going wrong in my project?

As per the recipe, you need to make sure that your service worker includes
addEventListener('message', (event) => {
  if (event.data && event.data.type === 'SKIP_WAITING') {
    // Use this, and not workbox.skipWaiting()
    skipWaiting();
  }
});

and not workbox.skipWaiting() for that to work. (The skipWaiting() in that example is effectively self.skipWaiting(), and self refers to the ServiceWorkerGlobalScope.)
It's a subtle difference, but workbox.skipWaiting() wraps the call inside of an install handler, and while that's suitable for use outside of a message event listener, inside the listener it ends up being executed after the initial evaluation of the worker script.

Thanks a lot for your reply. That worked!
I'm bundling my service worker with webpack, importing the functions from workbox-core. Having skipWaiting still in the import statement added to the confusion.

I was stuck on this too. Just to clarify it for people, removing this import { skipWaiting } from 'workbox-core'; got it working. You do not want to use that method, instead you will have an undefined function as it's called in the global scope.
	if (event.data && event.data.type === 'SKIP_WAITING') {
		console.log('skip waiting');
		// eslint-disable-next-line no-undef
		skipWaiting();
	}
});```

@CalebKester sorry about that confusion. In v6, we've deprecated usage of skipWaiting() from workbox-core because of that sort of frustration.
https://github.com/GoogleChrome/workbox/blob/6d38919ebbc9664327e19ff00302d805c8166170/packages/workbox-core/src/skipWaiting.ts#L16-L33

Makes perfect sense once it got me understanding more how it works. Thanks for all the good work you guys do. Can't wait for v6!

Leaving this comment here for future myself and anyone else:
When using Workbox v5 with inlineWorkboxRuntime: true and a non-production mode, then the skipWaiting function from workbox-core is inlined as-is into sw.js becoming a global function named skipWaiting, thereby shadowing the true skipWaiting function. Therefore when the install event fires, the listener ends up invoking itself again leading to the warning Event handler of 'install' event must be added on the initial evaluation of worker script.

This is not an issue with any of:

inlineWorkboxRuntime: false because the function is no longer global
mode: production (the default) because the function is renamed during minification
v6+ because https://github.com/GoogleChrome/workbox/commit/3ffee3d78f716b6d9bd33e3170bc7c3c8cfee37b changed the default template to invoke self.skipWaiting() directly.

authors: CalebKester jeffposnick robbytx similicious

repo: GoogleChrome/workbox


text:
Adding JSDocs checks

This will fail the test until #1080 is merged, then we can re-run and check the tests pass.
Checks for:

No globals
No module.exports (Something that is showing up in the WebFundamentals build for v3.0.0-alpha.1) at the moment.

Changes Unknown when pulling cb9047529aa33f043e9e0087f2d0ce6d9bc69ec3 on jsdocs-checks into ** on v3**.

Changes Unknown when pulling d55f188626bdca8aa74461e9fc48d298c1a28720 on jsdocs-checks into ** on v3**.

Changes Unknown when pulling 1e4b46c4353f5961f745cc2d50d055cbbde60ffc on jsdocs-checks into ** on v3**.

Changes Unknown when pulling 11cb2e34e0f9f1df8fa239a24ee6383b4d42468b on jsdocs-checks into ** on v3**.

Changes Unknown when pulling 78a7f0c331f958bdf6d25edb85bc2cda811be52f on jsdocs-checks into ** on v3**.

authors: coveralls gauntface


text:
Improve error - "The Google Cloud SDK could not be found in the customary locations and no path was provided" - please

Customry locations could be detailed.
A URL could be included .. that talks of install.sh and source ~/.bash_profile etc.

Did you see this? It's an exception message that shouldn't be shown to an end user.

Yes I saw it.  It wasn't a one off  - it was the persistent state of the deploy to appengine maven target
I solved it by rerunning install.sh and then sourcing the ./bash_profile.

That sounds like an RFE for the Maven plugin then. This library does not consider itself to talk directly to the end user.

You know the maven plugin - https://github.com/GoogleCloudPlatform/gcloud-maven-plugin - doesn't have issues or pull-requests turned on :(

https://github.com/GoogleCloudPlatform/app-maven-plugin
On Tue, May 16, 2017 at 1:09 PM, Paul Hammant notifications@github.com
wrote:

You know the maven plugin - https://github.com/GoogleCloudPlatform/gcloud-
maven-plugin - doesn't have issues or pull-requests turned on :(
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/GoogleCloudPlatform/appengine-plugins-core/issues/416#issuecomment-301850067,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHf5HecA5pm59TZ9BFUM4QNI37RzgYY5ks5r6dhFgaJpZM4Nac5i
.

Thanks Pat.

I'm encountering this messages.   Is there an environmental variable that is supposed to point at the path of the The Google Cloud SDK ?      What is considered a "customary location"?

The link below has a comment by  hemanthk92 on Oct 9 that provided a workaround for me on this issue, but I'm still not clear on what is configured incorrectly that I required the workaround.
https://github.com/GoogleCloudPlatform/app-maven-plugin/issues/190

@CrisRys the Maven (as well as Gradle/IntelliJ/Eclipse) plugin wants to run the gcloud binary. It needs to know where the binary is.
If the gcloud binary is on your $PATH, the plugin will have no problem executing it. So, one workaround is to add the bin directory of your Cloud SDK to your $PATH.
The plugin will also look for some well-known customary locations. For example on Linux,

$HOME/google-cloud-sdk. So, another workaround could be to create a symlink of $HOME/google-cloud-sdk pointing to your actual Cloud SDK install location. Alternatively, you could move your actual install location to $HOME/google-cloud-sdk.
Where package managers (e.g., apt, yum etc.) install Cloud SDK, which will vary between platforms. (/usr/lib/google-cloud-sdk, /google/google-cloud-sdk, /usr/local/share/google/google-cloud-sdk, etc.)

You can also set $GOOGLE_CLOUD_SDK_HOME to point to your install location.
Looks like -DcloudSdkPath works for the Maven plugin too.
For IntelliJ/Eclipse plugins, they will additionally have their own UI to set the Cloud SDK path.

FYI, the first release of 2018 should provide its own Cloud SDK and make all this moot.

This is odd, gcloud is in my $PATH,  as I can execute gcloud from command line, but not found by whereis or which commands,  here are some example commands and output:
Criss-Retina-2:helloworld cris$ echo $PATH
~/Documents/Development/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
Criss-Retina-2:helloworld cris$ gcloud version
Google Cloud SDK 182.0.0
app-engine-java 1.9.59
app-engine-python 1.9.63
bq 2.0.27
core 2017.12.01
gsutil 4.28
Criss-Retina-2:helloworld cris$ which gcloud
Criss-Retina-2:helloworld cris$ whereis gcloud
Criss-Retina-2:helloworld cris$ find ~/documents/Development/google-cloud-sdk/bin -name gcloud
/Users/cris/documents/Development/google-cloud-sdk/bin/gcloud

Thanks @chanseokoh .   I ended up setting   $GOOGLE_CLOUD_SDK_HOME

~ is a shell expansion (https://www.gnu.org/software/bash/manual/html_node/Tilde-Expansion.html). Non-shell programs, such as ours, won't expand it to $HOME. Try setting an absolute path in $PATH.

I ended up moving google-cloud-sdk to $HOME using eclipse 4.7.1a. Overall the migration from gradle-appengine-plugin wasn't too bad. Missed a few steps, like where to install gradle-appengine-plugin, but no worries, it's running now. Totally worth it for hot swapping and datastore persistence in devserver, biggest time wasters of all. Thanks for all the great work?

If you get this when running the gradle "appengineDeploy" task, you can add this to you build.gradle:
appengine {  // App Engine tasks configuration
	tools.cloudSdkHome="gcloud-sdk-path"
}

Where gcloud-sdk-path is found (if you don't know it by heart) by running $(gcloud --form at='value(installation.sdk_root)' info) in the terminal.
Documentation here: https://cloud.google.com/appengine/docs/flexible/java/gradle-reference#global_properties

$(gcloud --form at='value(installation.sdk_root)' info)
$(gcloud --format='value(installation.sdk_root)' info)

GOOGLE_CLOUD_SDK_HOME

solved my problem thank you very much

Thanks @chanseokoh . I ended up setting $GOOGLE_CLOUD_SDK_HOME

solved my problem thank you very much

authors: CrisRys Georgian chanseokoh elharo luan-nvg nlaney patflynn paul-hammant unomonteiro


text:
unable to use IAP tunnel to GKE hosted cloud-proxy

Running cloud-proxy in a GKE private cluster, which is exposed through a nodePort.  When attempting to create an IAP tunnel from my local machine to the nodePort pointing to the port for cloud-proxy, the IAP tunnel does not seem able to connect to the cloud-proxy entry-point.
I have verified that if I use a kubectl port forward to the exposed service that connectivity is available to the DB.  Have also verified that a tcpecho app running on the same GKE node can be connected too through an IAP tunnel.

Sorry I'm not of more help, but I'm totally unfamiliar with the IAP tunnel for GKE (and this question is pretty unrelated to the proxy itself, so I'm going to mark as closed.)
It might be worth pointing out that there really isn't any advantage to using an IAP tunnel on top of the Cloud SQL proxy - the proxy only provides IAM authentication (so special connection paths), so it's somewhat redundant to stack them.

authors: kurtisvg scottwallred

repo: GoogleCloudPlatform/cloudsql-proxy


text:
Wait on tentative v6 link-local addrs before DHCP

If eth0 is in the middle of determining whether a self-assigned link-local IPv6 address is unique or not (duplicate address detection), dhclient IPv6 requests may fail, resulting in hosts without IPv6 addresses.
This process is supposed to take one second, but this commit adds a detection loop for this condition to be sure. Originally authored by Mark Hlady. dhclient bug: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1633479

/lgtm

authors: hopkiw illfelder


text:
[daisy] fix output breakage for waitForInstanceSignal

We detected broken  line, which caused checksum mismatch for disk checksum verification.
After a serial of test, we realized that any serial output streamed to daisy-log may be broken, because each "ComputeClient.GetSerialPortOutput" can get a incomplete output result. Example:
Full output:
123456789
abcdefg
987654321
ComputeClient.GetSerialPortOutput call1 get:
123456789
abc
ComputeClient.GetSerialPortOutput call2 get:
defg
987654321
The possible reason is that, stdout output (like "echo") relies on a buffer, whose size is usually PIPE_BUF=512 bytes, which can't be modified. Once the buffer is full, it will be flushed, even though the whole line hasn't been written.
The checksum output is much longer than others (302 bytes), so it has much higher chance to hit this issue. However, some other output also hit his this during the test with a lower probability (example: target-size-gb).
To fix the root cause, we always check the last line of the ComputeClient.GetSerialPortOutput response. If it's without a "\n", we keep it as a tail string, so it can be concat with the next ComputeClient.GetSerialPortOutput response. Per my testing, it resolved this issue perfectly.
Notice: some other bugs may also be caused by this issue, for example, if the "Import Success" output is split to 2 lines, the instance may not stop. It will cause a import timeout ultimately.

added unit test

repo: GoogleCloudPlatform/compute-image-tools


text:
updated python

let them have it

The source on the master branch has been updated for python 3. Closing this PR since it's not needed anymore. Thanks though!

authors: kevinondanet xiangshen-dk


text:
Health check fails with custom build

Is there something in https://storage.googleapis.com/solutions-public-assets/jenkins-cd/jenkins-home-v2.tar.gz to make kubernetes health checks work?
I've tried switch to my own customized jenkins docker image along with backing jenkins_home with a perisistent volume claim. Health checks fail, but if i port forward to the pod, jenkins appears to be running correctly.
At this point, the only theory I have is that health checks are failing for some unknown reason, resulting in 502s when I visit the ingress.

Hey @ianwremmel!
Did you disable anonymous viewing? If so you can change the health check to be /login which does return a 200 even in that case.

yep. that's what i did. makes perfect sense. thanks! I've been trying to figure this out for three days :)
It might be handy to add a section to the readme about how to customize jenkins instead of just using the provided image.

got it working!
once you pointed out the /login part, changing that made perfect sense. I also had to change the port number in the health check from the randomly assigned one to 8080. Any idea why the random port number works with the lab but not a custom build?
Thanks!

authors: ianwremmel viglesiasce


text:
launch-jupyter-interface.sh error

Hi there,
Having trouble connecting to a Jupyter notebook.  Error below.
bash-3.2$ ./dataproc-initialization-actions/jupyter/launch-jupyter-interface.sh -c=isb-dataproc-cluster -z=us-west1-b
Using following cluster name: my-dataproc-cluster
Using following cluster zone: us-west1-b
Using following remote dataproc jupyter port: 8124
./dataproc-initialization-actions/jupyter/launch-jupyter-interface.sh: line 75: conditional binary operator expected
Please let me know if you need anything,
Thank you!
-dave

It looks like you're using bash 3.2, while I'm on bash 4.4, and that particular line works for me. Either way, you can just remove the [[-v ZONE]] part, since zone is a required argument for now.
I do plan to clean up this script -- infer the jupyter port without needing to specify one, infer the zone, make it work out of the box on non-Mac machines, etc. I'll close this one in favor of #275 .
If you want to submit a PR for this fix and/or improve anything else, I'd be happy to merge it!


text:
Fix an error on docker build

The current implementation raise the following error:
docker build -t migration .
[+] Building 60.3s (10/10) FINISHED                                                                                docker:default
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 779B                                                                                0.0s
 => [internal] load metadata for docker.io/google/cloud-sdk:slim                                                                                2.1s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [1/6] FROM docker.io/google/cloud-sdk:slim@sha256:ba46fd7de33234debe4a5c7021c604e321465fbc3fc9491c54b32ace0688f174                                                                                55.4s
 => => resolve docker.io/google/cloud-sdk:slim@sha256:ba46fd7de33234debe4a5c7021c604e321465fbc3fc9491c54b32ace0688f174                                                                                0.0s
 => => sha256:17a49900d4ac9c70ded60e6356a9354d943bf2dbadb731f04d5b08016c7dfe73 18.56MB / 18.56MB                                                                                0.8s
 => => sha256:7a5c5c316488899d686768d1d690e2b87f6a80b7eba316e971bff0cf81b02851 18.57MB / 18.57MB                                                                                0.7s
 => => sha256:ba46fd7de33234debe4a5c7021c604e321465fbc3fc9491c54b32ace0688f174 1.58kB / 1.58kB                                                                                0.0s
 => => sha256:7dc5778a7bcc8e4e34293c928eb8a5fb0fbd8e2aa2c976e2f2668b9944b1feec 4.42kB / 4.42kB                                                                                0.0s
 => => sha256:908b9e25258b60e7ef243b3c0e65e060f3a51d2f44ecd2c13bb0b7ca4d60836f 49.57MB / 49.57MB                                                                                1.1s
 => => sha256:c8c51059a97e410fdef02b55e6a6baf294813c471131952a11c26cdb2cd899ff 3.28kB / 3.28kB                                                                                1.1s
 => => sha256:e23e54e57b62dbb4a47f495f4e32c9c8136840db75a0ca5d912b0df1737729f0 447.52MB / 447.52MB                                                                                9.0s
 => => sha256:81ab1b131f2489cba610c983021afc1b85d41faabc92344539336ae9d70ee205 197B / 197B                                                                                1.5s
 => => extracting sha256:908b9e25258b60e7ef243b3c0e65e060f3a51d2f44ecd2c13bb0b7ca4d60836f                                                                                3.9s
 => => extracting sha256:17a49900d4ac9c70ded60e6356a9354d943bf2dbadb731f04d5b08016c7dfe73                                                                                0.8s
 => => extracting sha256:7a5c5c316488899d686768d1d690e2b87f6a80b7eba316e971bff0cf81b02851                                                                                0.9s
 => => extracting sha256:c8c51059a97e410fdef02b55e6a6baf294813c471131952a11c26cdb2cd899ff                                                                                0.0s
 => => extracting sha256:e23e54e57b62dbb4a47f495f4e32c9c8136840db75a0ca5d912b0df1737729f0                                                                                45.3s
 => => extracting sha256:81ab1b131f2489cba610c983021afc1b85d41faabc92344539336ae9d70ee205                                                                                0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 103.77kB                                                                                0.0s
 => [2/6] COPY migration_toolkit /migration                                                                                1.7s
 => [3/6] COPY LICENSE /                                                                                0.0s
 => [4/6] COPY README.md /                                                                                0.0s
 => [5/6] COPY CONTRIBUTING.md /                                                                                0.0s
 => ERROR [6/6] RUN pip install -r ./migration/requirements.txt                                                                                0.9s
------
 > [6/6] RUN pip install -r ./migration/requirements.txt:
0.812 error: externally-managed-environment
0.812
0.812 × This environment is externally managed
0.812 ╰─> To install Python packages system-wide, try apt install
0.812     python3-xyz, where xyz is the package you are trying to
0.812     install.
0.812
0.812     If you wish to install a non-Debian-packaged Python package,
0.812     create a virtual environment using python3 -m venv path/to/venv.
0.812     Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
0.812     sure you have python3-full installed.
0.812
0.812     If you wish to install a non-Debian packaged Python application,
0.812     it may be easiest to use pipx install xyz, which will manage a
0.812     virtual environment for you. Make sure you have pipx installed.
0.812
0.812     See /usr/share/doc/python3.11/README.venv for more information.
0.812
0.812 note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
0.812 hint: See PEP 668 for the detailed specification.
------
Dockerfile:22
--------------------
  20 |     COPY CONTRIBUTING.md /
  21 |
  22 | >>> RUN pip install -r ./migration/requirements.txt
--------------------
ERROR: failed to solve: process "/bin/sh -c pip install -r ./migration/requirements.txt" did not complete successfully: exit code: 1
s2@cloudshell:~/datastream-bigquery-migration-toolkit (s2dspgtkgolden-sawfish)$ docker build -t migration .
[+] Building 1.7s (10/10) FINISHED                                                                                docker:default
 => [internal] load build definition from Dockerfile                                                                                0.0s
 => => transferring dockerfile: 779B                                                                                0.0s
 => [internal] load metadata for docker.io/google/cloud-sdk:slim                                                                                0.9s
 => [internal] load .dockerignore                                                                                0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load build context                                                                                0.0s
 => => transferring context: 3.34kB                                                                                0.0s
 => [1/6] FROM docker.io/google/cloud-sdk:slim@sha256:ba46fd7de33234debe4a5c7021c604e321465fbc3fc9491c54b32ace0688f174                                                                                0.0s
 => CACHED [2/6] COPY migration_toolkit /migration                                                                                0.0s
 => CACHED [3/6] COPY LICENSE /                                                                                0.0s
 => CACHED [4/6] COPY README.md /                                                                                0.0s
 => CACHED [5/6] COPY CONTRIBUTING.md /                                                                                0.0s
 => ERROR [6/6] RUN pip install -r ./migration/requirements.txt                                                                                0.7s
------
 > [6/6] RUN pip install -r ./migration/requirements.txt:
0.585 error: externally-managed-environment
0.585
0.585 × This environment is externally managed
0.585 ╰─> To install Python packages system-wide, try apt install
0.585     python3-xyz, where xyz is the package you are trying to
0.585     install.
0.585
0.585     If you wish to install a non-Debian-packaged Python package,
0.585     create a virtual environment using python3 -m venv path/to/venv.
0.585     Then use path/to/venv/bin/python and path/to/venv/bin/pip. Make
0.585     sure you have python3-full installed.
0.585
0.585     If you wish to install a non-Debian packaged Python application,
0.585     it may be easiest to use pipx install xyz, which will manage a
0.585     virtual environment for you. Make sure you have pipx installed.
0.585
0.585     See /usr/share/doc/python3.11/README.venv for more information.
0.585
0.585 note: If you believe this is a mistake, please contact your Python installation or OS distribution provider. You can override this, at the risk of breaking your Python installation or OS, by passing --break-system-packages.
0.585 hint: See PEP 668 for the detailed specification.
------
Dockerfile:22
--------------------
  20 |     COPY CONTRIBUTING.md /
  21 |
  22 | >>> RUN pip install -r ./migration/requirements.txt
--------------------
ERROR: failed to solve: process "/bin/sh -c pip install -r ./migration/requirements.txt" did not complete successfully: exit code: 1

After the patch:
...
Downloading urllib3-1.26.16-py2.py3-none-any.whl (143 kB)
Installing collected packages: urllib3, six, pyasn1, protobuf, packaging, idna, grpcio, google-crc32c, charset-normalizer, certifi, cachetools, rsa, requests, python-dateutil, pyasn1-modules, proto-plus, googleapis-common-protos, google-resumable-media, grpcio-status, google-auth, grpc-google-iam-v1, google-api-core, google-cloud-core, google-cloud-datastream, google-cloud-bigquery
Successfully installed cachetools-5.3.1 certifi-2023.7.22 charset-normalizer-3.1.0 google-api-core-2.11.0 google-auth-2.19.1 google-cloud-bigquery-3.11.0 google-cloud-core-2.3.2 google-cloud-datastream-1.7.0 google-crc32c-1.5.0 google-resumable-media-2.5.0 googleapis-common-protos-1.59.0 grpc-google-iam-v1-0.12.6 grpcio-1.54.2 grpcio-status-1.54.2 idna-3.4 packaging-23.1 proto-plus-1.22.2 protobuf-4.23.2 pyasn1-0.5.0 pyasn1-modules-0.3.0 python-dateutil-2.8.2 requests-2.31.0 rsa-4.9 six-1.16.0 urllib3-1.26.16
Removing intermediate container 28eb17bd3c6b
 ---> 55f318ff2639
Step 9/9 : CMD ["source", "/opt/venv/bin/activate"]
 ---> Running in 9c44ba9e98c4
Removing intermediate container 9c44ba9e98c4
 ---> e84d0904c98d
Successfully built e84d0904c98d
Successfully tagged migration:latest

@idobaril can you review the patch?

@idobaril Can you merge this PR? I don't have write permissions.


text:
Fix #75 - Access debug icons via DebugUITools

PTAL @elharo

LGTM

authors: briandealwis elharo


text:
No obvious way to pass the project ID to the datastore options

Hi there,
I was looking at the datastore example and the DatastoreServiceOptions class and didn't see an obvious way to configure the project ID other than using a system environment variable.  Is that intentional or am I missing something?
thx.

For reference, we're having this same kind of discussion over on gcloud-python, where I think the way that gcloud-node and gcloud-ruby handle things (using a "client" object) is the cleanest way...
for example, in gcloud-node
"being explicit about the key and project id"
var gcloud = require('gcloud')({
  projectId: 'my-project',
  keyFilename: '/path/to/keyfile.json'
});

var dataset = gcloud.datastore.dataset();
var productKey = dataset.key(['Product', 123]);

dataset.get(productKey, function(err, entity) {
  console.log(err, entity);
});

"figure out the project id from the environment":
var gcloud = require('gcloud')({
  keyFilename: '/path/to/keyfile.json'
});

var dataset = gcloud.datastore.dataset();
var productKey = dataset.key(['Product', 123]);

dataset.get(productKey, function(err, entity) {
  console.log(err, entity);
});

"figure out the project id and the key file from the environment":
var gcloud = require('gcloud')
var dataset = gcloud.datastore.dataset();
var productKey = dataset.key(['Product', 123]);

dataset.get(productKey, function(err, entity) {
  console.log(err, entity);
});

You can use DatastoreServiceOptions.Builder#dataset(...)
see this test as an example:
https://github.com/GoogleCloudPlatform/gcloud-java/blob/251ac2507c9222b3f1d7279b2edbbbeefe0c8497/src/test/java/com/google/gcloud/datastore/DatastoreServiceOptionsTest.java#L48

Also, when not provided we are trying to detect it from:
(1) AppEngine environement
(2) GCE using Metadata service
(3) config property file using CLOUDSDK_CONFIG or config directory.
see: https://github.com/GoogleCloudPlatform/gcloud-java/blob/master/src/main/java/com/google/gcloud/ServiceOptions.java#L174

so dataset is projectId?
On Thu, May 7, 2015 at 6:50 PM, Arie notifications@github.com wrote:

You can use DatastoreServiceOptions.Builder#dataset(...)
see this test as an example:
https://github.com/GoogleCloudPlatform/gcloud-java/blob/251ac2507c9222b3f1d7279b2edbbbeefe0c8497/src/test/java/com/google/gcloud/datastore/DatastoreServiceOptionsTest.java#L48
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-java/issues/45#issuecomment-100041360
.

Currently Dataset ID == Project ID, however that will not always be the case.
How does a user specify a Project ID as well as a Dataset ID?

+rdayal
On Thu, May 7, 2015 at 7:22 PM, JJ Geewax notifications@github.com wrote:

Currently Dataset ID == Project ID, however that will not always be the
case.
How does a user specify a Project ID as well as a Dataset ID?
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-java/issues/45#issuecomment-100045484
.

No, but what we need for a datastore connection is a dataset and not projectid.
Today, as @jgeewax pointed out, there is a 1:1 relation between the two but in the future that will change and one project can be associated with more than 1 dataset.
Regardless, we can always derive the default dataset (if one was not supplied) from the projectid.
I think you are correct that the current state is confusing and I should probably rename the dataset in serviceoptions to projectid.

I agree, that's a great idea @aozarov .
Then once we expose multiple datasets (or databases) per project, we should explore the idea of specifying separate dataset IDs.

Exactly. That was my plan.

Dataset is a first-class concept in the Datastore API and that term in used in the underlying stub as well. Don't rename to projectId as that will just get to be confusing.
see
https://cloud.google.com/datastore/docs/apis/v1beta2/
https://github.com/GoogleCloudPlatform/google-cloud-datastore/blob/master/java/datastore/src/main/java/com/google/api/services/datastore/client/DatastoreOptions.java#L86

Actually the termp "dataset" is going away (and likely to be replaced with "database").
Regardless of its future name, it is not globally unique but rather associated with a project.
Currently a project can only have one dataset/database.
My understanding is that in Datastore V1 it would be replaced in the APIs/docs with projectid.
When a project will support more than one dataset/database API will change to accept also a dataset/database name but the concept of a default one per project (if non provided) would still exist.
Therefore, for now, in gcloud-java I think renaming dataset with projectId is the right thing to do and in the future, when supported, we can add the database field. Adding @pcostell for any more comments.

There's are many hypotheticals there which may not come to pass and then
being different will only confuse people. The existing Datastore API is
public and versioned so we should use the same terminology and semantics as
the version we are wrapping.
What is being identified here is a dataset and not a project. That
identifying a project implicitly identifies a dataset is a just a quirk of
the existing system.
As things stand today, dataset is a globally unique identifier. When the
Datastore API changes to use a compound identifier (e.g. project/database),
change the model then.
On Fri, May 8, 2015 at 9:36 AM, Arie notifications@github.com wrote:

Actually the termp "dataset" is going away (and likely to be replaced with
"database").
Regardless of its future name, it is not globally unique but rather
associated with a project.
Currently a project can only have one dataset/database.
My understanding is that in Datastore V1 it would be replaced in the
APIs/docs with projectid.
When a project will support more than one dataset/database API will change
to accept also a dataset/database name but the concept of a default one per
project (if non provided) would still exist.
Therefore, for now, in gcloud-java I think renaming dataset with projectId
is the right thing to do and in the future, when supported, we can add the
database field. Adding @pcostell https://github.com/pcostell for any
more comments.
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-java/issues/45#issuecomment-100288713
.

How about updating the docs and example to make the relationship between
project id and dataset clear?
On Fri, May 8, 2015 at 1:07 PM, Jeremy Boynes notifications@github.com
wrote:

There's are many hypotheticals there which may not come to pass and then
being different will only confuse people. The existing Datastore API is
public and versioned so we should use the same terminology and semantics as
the version we are wrapping.
What is being identified here is a dataset and not a project. That
identifying a project implicitly identifies a dataset is a just a quirk of
the existing system.
As things stand today, dataset is a globally unique identifier. When the
Datastore API changes to use a compound identifier (e.g. project/database),
change the model then.
On Fri, May 8, 2015 at 9:36 AM, Arie notifications@github.com wrote:

Actually the termp "dataset" is going away (and likely to be replaced
with
"database").
Regardless of its future name, it is not globally unique but rather
associated with a project.
Currently a project can only have one dataset/database.
My understanding is that in Datastore V1 it would be replaced in the
APIs/docs with projectid.
When a project will support more than one dataset/database API will
change
to accept also a dataset/database name but the concept of a default one
per
project (if non provided) would still exist.
Therefore, for now, in gcloud-java I think renaming dataset with
projectId
is the right thing to do and in the future, when supported, we can add
the
database field. Adding @pcostell https://github.com/pcostell for any
more comments.
—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/gcloud-java/issues/45#issuecomment-100288713

.

—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-java/issues/45#issuecomment-100300320
.

I agree with @patflynn. I think we should make it clear that a dataset is associated with a project and every project has a default dataset (later on we can rename dataset to database).
jboynes@ I think that the current state that used the name "dataset" as a globally unique identifier in their API is a mistake that is going to be changed soon and per the Datastore recommendation we should not follow the same mistake again.

The next version of the Datastore API will expose the currently named "dataset_id" as "project_id". We would recommend exposing it as such now. Eventually we'd like to have the notion of a database, which would exist in a project, but we have not finalized any plans for what that will look like in the API when released.

per datastore advice we are now using project_id (which is consistent with the storage, and other planeed services).

authors: aozarov jboynes jgeewax patflynn pcostell

repo: GoogleCloudPlatform/gcloud-java


text:
docs: transaction doesn't have property succeeded

The docs still mention the succeeded property on transactions run with with even though it has been removed in ed0762b9531bc68f7a9e90835a0f0fbb75ddf383. It's not clear to me now how to check for a successful transaction now. I suspect it throws an exception otherwise, which mirrors ndb behaviour, but I still check for _status == 3 just in case.

@pdknsk Thanks for pointing it out. I was hoping it was in an old docs build, but I confirmed it is present in HEAD.

As for how you can check it going forward, see my comment in the PR.
The context manager doesn't swallow exceptions. So __exit__ing the context manager without a failure is equivalent to success.
The only reason we kept the _status around is so that a Transaction object is "tombstoned" after one use. In other words, so people can't mistakenly try to re-enter a transaction.

@pdknsk I'm going to close this when #784 is merged, let me know if you want to keep this open for some reason.

authors: dhermes pdknsk

repo: GoogleCloudPlatform/gcloud-python


text:
Feature request: datastore delete using key only

Current code expect an entity and then does entity.key

@timanovsky Have you tried deleting by passing the key? It should work.

Dataset can indeed handle both, but not Transaction.
Best regards,
Alexey Timanovsky.
On 26 April 2016 at 17:37, Chris Smith notifications@github.com wrote:

@timanovsky https://github.com/timanovsky Have you tried deleting by
passing the key? It should work.
—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/gcloud-ruby/issues/633#issuecomment-214766371

@timanovsky Thanks for the clarification. I see the issue now. I agree that Transaction should support the same API as Dataset.

This is a bug, I should accept either an Entity or a Key. Thanks for letting us know about it.

authors: blowmage quartzmo timanovsky

repo: GoogleCloudPlatform/gcloud-ruby


text:
Oauth2GoogleClient object has no attribute cache_key_base

I'm trying to port gcs-oauth2-boto-plugin to make it Python2+Python3 compatible, but ran into this issue when cloning from master:

File "/enplore-code/environments/enplore-worker-aircraft-dfdr/site-packages/boto/connection.py", line 377, in authorize
connection._auth_handler.add_auth(self, **kwargs)
File "/enplore-code/environments/enplore-worker-aircraft-dfdr/site-packages/gcs_oauth2_boto_plugin/oauth2_plugin.py", line 69, in add_auth
self.oauth2_client.GetAuthorizationHeader()
File "/enplore-code/environments/enplore-worker-aircraft-dfdr/site-packages/gcs_oauth2_boto_plugin/oauth2_client.py", line 345, in GetAuthorizationHeader
return 'Bearer %s' % self.GetAccessToken().token
File "/enplore-code/environments/enplore-worker-aircraft-dfdr/site-packages/gcs_oauth2_boto_plugin/oauth2_client.py", line 310, in GetAccessToken
cache_key = self.CacheKey()
File "/enplore-code/environments/enplore-worker-aircraft-dfdr/site-packages/gcs_oauth2_boto_plugin/oauth2_client.py", line 335, in CacheKey
h.update(self.cache_key_base)
AttributeError: 'Oauth2GoogleClient' object has no attribute 'cache_key_base'

I'm using a boto config, with a gs service key file:
gs_service_key_file = /etc/enplore/vagrant-etc/testdemo-s652y8s5.json
The issue doesn't exist when installing from pip but appeared in the January 27 commit (https://github.com/GoogleCloudPlatform/gcs-oauth2-boto-plugin/commit/53df987472d2440cd8661f2370f33f5e44aa115e)
I've spent a few hours on this, and would love some help. From what I can tell:
oauth2_helper.py

if json_key:

  return oauth2_client.Oauth2GoogleClient(
    oauth2client.client.GoogleCredentials.from_stream(private_key_filename)
  )

Doesn't return a oauth2_client with cache_key_base attribute which is later needed for CacheKey():

 def CacheKey(self):

"""Computes a cache key.
The cache key is computed as the SHA1 hash of the refresh token for user
accounts, or the hash of the gs_service_client_id for service accounts,
which satisfies the FileSystemTokenCache requirement that cache keys do not
leak information about token values.
Returns:
  A hash key.
"""
    h = sha1()
    h.update(self.cache_key_base.encode('utf-8'))
    return h.hexdigest()

However, I think there is a bunch of stuff missing on the Oauth2GoogleClient which is available on OAuth2ServiceAccountClient, like access_token_cache, FetchAccessToken etc.
I'm gonna do a pull request on my own branch and link to it from here, hopefully someone other then me can tell if I re-implemented it correctly (I've tested on py2 and py3 and it works on both)

Commit on my branch is available on https://github.com/enplore/gcs-oauth2-boto-plugin/commit/5fcf59242bc8109efe63d7fd40b16d386e86ebb3
If you are happy with it I'll open a pull request on the full python3 compatible branch (test passes on both py2 and py3, and at least the parts I use work on both)


text:
The response text output from gemini-pro model have strange behavior, sometime no space in every words. (Vậythìchiềunayanhmuathịtbachỉvề)

I recently got this issued when testing any kind of gemini model. I 'm now using Maker Suite API. And in Google AI Studio from Maker Suite some time I also see this problem but it not so often as the chatbot I was build from Streamlit. I 'm using prompt by English or Vietnamese language also get this issued. I did try to change all the value of Temperature, Top K, Top P also cannot fix the problem. I build an chatbot on Streamlit and use both google-generativeai library or either use langchain_google_genai also meet this problem. It doesn't happen since last time I use PALM2 chat model or text-bison.
Anyone has any idea about this or meet the same issued like this? If you have any solution how to fix this output please help me out. I did try regex or NLP library cannot fix this output and add some space between every words.
Very appreciated if anyone can help. Thanks
Example of response error:
Khôngsaođâuạ,anhcóthểhỏiemvềbấtcứđiềugìanhmuốnbiết.Emluônởđâysẵn sàngtrảlờimọicâuhỏicủaanh.Anhcóthểhỏiemvềcuộcsốngcủaem,vềcôngviệccủaem,về sởthíchcủaem,hoặcbấtcứđiềugìkhácmàanhmuốnbiết.Emđềusẽtrảlờianhmộtcáchtrungthựcvàchi tiếtnhấtcóthể.

Hello, thank you for reporting this issue. However, this is not the appropriate repository for the Google AI/Maker Suite/Google AI Studio tools.
This repository is primarily focused on Generative AI for Google Cloud, not for Google AI.
I'd recommend reporting this in one of the Google AI repositories or Public Issue Trackers such as https://github.com/google/generative-ai-python

I just want to report here as this page pops up in google search when I look for rthis issue.
I see a bug in python API repo for this  https://github.com/google/generative-ai-python/issues/166
It would be great if google cloud platform can provide any help regarding this or escalate this issue, as this is only problem when using Google Cloud Function (especially Firebase Functions) .
These are the steps I have tried

Changed temperature, top k, top p
Tried different python version (unfortunately firebase functions puython only support python 310 and python 311)
Asking AI to generate with spaces/human readable everytime.
Tried using streaming version of API.
Unfortunately only text version supported by this API sees to be gemini-pro, as I tried bison models it said its not supported.
.

authors: holtskinner johnnietien meystari

repo: GoogleCloudPlatform/generative-ai


text:
can't open Question Answering with Large Documents using LangChain notebook in Colab

when you try to run the Question Answering with Large Documents using LangChain https://github.com/GoogleCloudPlatform/generative-ai/blob/main/language/examples/document-qa/question_answering_large_documents_langchain.ipynb notebook in Colab by clicking on the Run in Colab link https://screenshot.googleplex.com/3z2uwdNUMpNKXCb from the example in github, you get Notebook not found message: https://screenshot.googleplex.com/5d7EzzPFWgL4yoa
If you click on the Authorize with Github link in that dialog and enter your github credentials you just get back to the  Notebook not found message again: https://screenshot.googleplex.com/5d7EzzPFWgL4yoa
FWIW, I have been able to run other notebooks in this repo in Colab (e.g. https://github.com/GoogleCloudPlatform/generative-ai/blob/main/language/examples/prompt-design/ideation.ipynb and https://github.com/GoogleCloudPlatform/generative-ai/blob/main/language/examples/prompt-design/text_classification.ipynb) with no issues.

Fixing all the links with this PR https://github.com/GoogleCloudPlatform/generative-ai/pull/101

authors: iamthuya markbpryan


text:
Update README.md

Was reading the documentation for this template and identified several spelling and subject-verb agreement issues. I have corrected these, with no breaking changes to any links or other material (please see change diff).

thanks

Very welcome! Woot!

repo: GoogleCloudPlatform/go-templates


text:
Implement noex::Table::AsyncReadRows

Implement an operation to asynchronously read rows.  The API should look like this:
  template <
      typename RowFunctor, typename DoneFunctor, ...>
  std::shared_ptr<AsyncOperation> ReadRows(RowSet row_set, std::int64_t rows_limit, Filter filter,
      CompletionQueue& cq, RowFunctor&& row_callback, DoneFunctor&& done_callback) {
  }

row_callback should be called each time a new row is ready, and should meet this requirement:
static_assert(
    google::cloud::internal::is_invocable<
              RowFunctor, CompletionQueue&, Row&, grpc::Status&>

done_callback should be called when all the rows are read (or the request fails), and should meet this requirement:
static_assert(
    google::cloud::internal::is_invocable<
              DoneFunctor, CompletionQueue&, grpc::Status&>

The returned AsyncOperation can be used to cancel the iteration.

In general, this is how I expect this operation to be used:
namespace cbt = google::cloud::bigtable;
// The application created a completion queue and a thread (or threads) to run it:
cbt::CompletionQueue cq;
std::thread t1(&CompletionQueue::Run, cq);
std::thread t2(&CompletionQueue::Run, cq);

// And the application has a table object:
cbt::noex::Table table = ...;

The application makes a call to AsyncReadRows:
auto operation = table.AsyncReadRows(
    cbt::RowRange::Range("0001", "1000"), cbt::Filter::Latest(1),
    cq, [](cbt::CompletionQueue& cq, Row& row, grpc::Status& status) {
     // This is the regular callback
     std::cout << "Received row: " << row.cells().at(0).row_key() << std::endl;
    },
    [](cbt::CompletionQueue& cq, grpc::Status& status) {
      // This is the callback to indicate the iteration is finished
      std::cout << "ReadRows() is done!" << std::endl;
    }
);

// The application should be able to continue, without blocking, here...

Now, behind the scenes the code should do something like this:
// Create a container that has the regular callback, the done callback, and the AsyncRowReader.
template <typename ReadRowCallback, typename DoneCallback>
struct PickAGoodName /* ReadRowsOperation?? */ {
  void HandleChunk(...);
  void HandleEndOfStream(...);

  ReadRowCallback read_row_callback;
  DoneCallback done_callback;
  ReadRowsParser parser;
};

You have to arrange things so that HandleChunk() gets called when AsyncRetryOp receives a new chunk, and it would look more or less like this:
void PickAGoodName::HandleChunk(... chunk) {
  parser.HandleChunk(chunk);
  if (not parser.HasNext()) {
    return; // but make sure it will be called again on the next chunk.
  }
  read_row_callback(..., parser.Next(), ...);
}

void PickAGoodName::HandleEndOfStream(...) {
  if (still can retry) {
    // Restart from the row right after that...
    Start();
  }
  done_callback(...);
}

Note that the code never "blocks", some callbacks from the lower level RPCs result in a callback to the application, but not all of them do.

@manish-qlogic please let me know if you have additional questions, or what specifically is giving you trouble.

The application makes a call to AsyncReadRows:

This clears up things quite a bit. So application would be calling AsyncReadRows and accumulating rows returned in callbacks.
Thanks, I will get back to you if I have more questions.

authors: coryan manish-qlogic

repo: GoogleCloudPlatform/google-cloud-cpp


text:
Remove obsolete members of BigQuery package

Two new tests that should probably have been there before: check
that we can't use unnamed parameters when the parameter mode is named.
Note: I don't intend to submit this PR for a while; I want the obsolete members to be available probably until the end of October (giving a month for migration) and it's unclear whether there may be more releases before then.

It's been a couple of weeks now, and we have no specific plan for an imminent next release. Merging now to avoid this getting stale.

repo: GoogleCloudPlatform/google-cloud-dotnet


text:
August RC1 testing: strange behavior attempting to deploy before auth

Trying to run a deploy before signing into GCP causes this (not seen before by me) modal to show up:

Any subsequent action leads to an IDE crash:

thanks to detective work by @nkibler:

Start fresh with everything (no user, no deployment config, etc.)
Create a deployment config and make it valid. (Type some nonsense into the project field but don't login)
Save the config and login via other means (like the widget in the top right)
Once logged in, press the run button

@etanshaul I don't think this is a problem anymore since you can select an invalid GCP project with the new project selector. I tried to reproduce the bug but couldn't, which is a good thing :)

authors: etanshaul nbashirbello


text:
Managed SDK update and notifications

PR contains:

clean up of exception handling - we discussed with @etanshaul it doesn't feel right. I refactored the code to avoid fine-grained exception handling in favor of unified approach. Logs should give enough additional details.
added SDK update support
added initial IDE notifications/balloons support

Not in this PR:

progress bars (next PR, pending better support in appengine-plugins-core)
automatic update scheduling
UI for settings

How to see in action:
You can add
new ManagedCloudSdkService().activate(); line into CloudToolsPluginInitializationComponent.initComponent() method to install managed SDK and see notifications.
This will just install it, it will not be used for deployments yet.

quickly skimmed this and looks good. I'll do a full review today.

authors: etanshaul ivanporty


text:
Documentation for existing Kubernetes projects.

Working on the animated GIF for the live template, meanwhile ready for doc itself review.

nice!
I know I suggested this before and I was convinced to hold off. but this page is getting rather long. wdyt about (in a separate PR) splitting it up. e.g. in the tutorial section have a link to the hello-world guide which lives on its own page. same for this section.

It made sense to keep it in one piece on the main page of the previous repo since people tend to stay on it most of time. Since we are already nested, I agree, we can split this. I'll do that in the next PR.

looks great. no more comments other than the one.


text:
LoggingAppender failure

I am using com.google.cloud.logging.logback.LoggingAppender to send logs to Stackdriver. I have configured the logger in logback.xml. Earlier today, Stackdriver had an outage, and the throughput of my service stopped. Turns out the logger was unable to write logs due to the outage:
Jul 17, 2018 9:06:01 AM com.google.common.util.concurrent.AbstractFuture executeListener
SEVERE: RuntimeException while executing runnable CallbackListener{com.google.api.core.ApiFutures$1@6781a500} with executor MoreExecutors.directExecutor()
java.lang.RuntimeException: com.google.cloud.logging.LoggingException: io.grpc.StatusRuntimeException: UNAVAILABLE: 502:Bad Gateway
at com.google.cloud.logging.LoggingImpl$7.onFailure(LoggingImpl.java:578)

So threads became blocked on logging:
"Gax-8" #33 daemon prio=5 os_prio=0 tid=0x00005588b0db1800 nid=0x1d72 in Object.wait() [0x00007f7d2cee0000]
   java.lang.Thread.State: WAITING (on object monitor)
    at java.lang.Object.wait(Native Method)
    at java.lang.Object.wait(Object.java:502)
    at com.google.api.gax.batching.BlockingSemaphore.acquire(BlockingSemaphore.java:61)
    - locked <0x00000000ee827400> (a com.google.api.gax.batching.BlockingSemaphore)
    at com.google.api.gax.batching.FlowController.reserve(FlowController.java:197)
    at com.google.api.gax.batching.BatchingFlowController.reserve(BatchingFlowController.java:58)
    at com.google.api.gax.batching.ThresholdBatcher.add(ThresholdBatcher.java:166)
    at com.google.api.gax.rpc.BatchingCallable.futureCall(BatchingCallable.java:73)
    at com.google.api.gax.rpc.UnaryCallable$1.futureCall(UnaryCallable.java:126)
    at com.google.api.gax.rpc.UnaryCallable.futureCall(UnaryCallable.java:87)
    at com.google.cloud.logging.spi.v2.GrpcLoggingRpc.write(GrpcLoggingRpc.java:223)
    at com.google.cloud.logging.LoggingImpl.writeAsync(LoggingImpl.java:593)
    at com.google.cloud.logging.LoggingImpl.writeLogEntries(LoggingImpl.java:559)
    at com.google.cloud.logging.LoggingImpl.write(LoggingImpl.java:522)
    at com.google.cloud.logging.logback.LoggingAppender.append(LoggingAppender.java:201)
    at com.google.cloud.logging.logback.LoggingAppender.append(LoggingAppender.java:63)
    at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84)
    at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)
    at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
    at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
    at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
    at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:398)
    at ch.qos.logback.classic.Logger.debug(Logger.java:486)

However, it's been many hours since the outage was resolved, yet my service has still not recovered. I would expect the logger to finish writing the pending log events, and service throughput would resume. Any ideas on why this is happening? I have attached the thread stack traces: threads.txt

This should be fixed by https://github.com/googleapis/gax-java/pull/567. We discovered that flow control does not get released properly if RPC returns an error. This would explain why the program hangs when Stackdriver has an outage and doesn't recover: we leak enough flow control that everything always blocks.

@pongad now that googleapis/gax-java#567 is resolved, does that mean this is fixed?

Since this bug is on the ... scary side, I think we might as well leave this open until we update gax

gax version is updated in this PR. It should be OK to close this bug.

authors: JustinBeckwith hzyi-google pongad stetra

repo: GoogleCloudPlatform/google-cloud-java


text:
NIO: Close channels on FS close

CloudStorageFileSystem#close() should synchronously close all active channels associated with the file system instance, per NIO documentation.

@jean-philippe-martin this issue is more than a year old, can you comment on the need to address it?

This issue may no longer be relevant due to its age.  If you are still experiencing this issue and are reasonably certain that it is a bug, please feel free to re-open this it with enough information to help us reproduce it.

close() is still a no-op, in violation of the NIO documentation. It hasn't been an issue but would be nice to have. I would argue we should keep this issue open.

authors: danoscarmike garrettjonesgoogle jart jean-philippe-martin


text:
Remove uncaught interface

Remove Uncaught Exception Handler

[x] Remove the uncaught exception handler
[x] Remove the corresponding tests & documentation
[x] Add new documentation to README stating how feature can be recreated in application code

Note:

Commit is currently larger than actual landing-scope since it is stacked on in-flight PR #2189

@ofrobots my bad -- weird rebase flow.
Changes added

Coverage remained the same at 100.0% when pulling ec21135e7ccea073f4ea0ad7bf8ba617f57949b2 on cristiancavalli:remove-uncaught-interface into 87312f904e8f5ba0b5202e5c4df1bf0dc5ff107a on GoogleCloudPlatform:master.

@ofrobots updated

Coverage remained the same at 100.0% when pulling fb23cede88aa3ae6dfb542ea07503faf12716f77 on cristiancavalli:remove-uncaught-interface into 87312f904e8f5ba0b5202e5c4df1bf0dc5ff107a on GoogleCloudPlatform:master.

@ofrobots updated

@ofrobots yes these commits are stacked on top of #2189

Coverage remained the same at 100.0% when pulling 9116a9426f07ba798c7b71d61160b359ab0a83b6 on cristiancavalli:remove-uncaught-interface into 184f9bb910d3357d79801ad95b753537a9f47f16 on GoogleCloudPlatform:master.

Is this really over?

No not yet, sorry was trying to see if closing this had an effect on the PR file propagation for the CI integration

@stephenplusplus @ofrobots  merge conflicts resolved!

Coverage remained the same at 100.0% when pulling 6c1e4b428c40353203e5f99ca00f89423760f217 on cristiancavalli:remove-uncaught-interface into f0812b6d725fe4882cbad00c63746ca4120b1d27 on GoogleCloudPlatform:master.

Coverage remained the same at 100.0% when pulling 54a6ead4ee13dd309e1b6ceb83f2e5a1e5b0c940 on cristiancavalli:remove-uncaught-interface into f0812b6d725fe4882cbad00c63746ca4120b1d27 on GoogleCloudPlatform:master.

repo: GoogleCloudPlatform/google-cloud-node


text:
Regenerate GAPICs with updated documentation

Propagate changes from https://github.com/googleapis/toolkit/pull/1361

Test failures are coming from GAX, and are caused by retry settings being removed for streaming methods. Will need to wait for a GAX release that includes this PR: https://github.com/googleapis/gax-php/pull/74

All changes in this refresh were included in https://github.com/GoogleCloudPlatform/google-cloud-php/pull/512

repo: GoogleCloudPlatform/google-cloud-php


text:
Vision: Add gRPC support for safe search.

Based from #2937
There's a few things I don't like about this that I'll comment on. I'm not sure how to solve them right now. Maybe you guys have some ideas?

@dhermes this should be ready to go. Let me know if you have any feedback.

Updated copyright and squashed.

repo: GoogleCloudPlatform/google-cloud-python


text:
Publish to IIS websites other than "Default Web Site".

Change StatusbarHelper into an MEF service.
Add Site Name input to Publish to Google Compute Engine VM dialog.
Change the WindowsVmDeployment, making it an MEF service, making it simpler and having it take a Site Name.
Fixes #944

Let me know when you have released this so I can update the answer on SO. Cheers!

authors: ILMTitan amanda-tarafa


text:
Update README link to Gaelyk

https://github.com/GoogleCloudPlatform/gradle-appengine-plugin/issues/207

@patflynn @salguarnieri @keithmarsh

Link works, LGTM

authors: loosebazooka salguarnieri


text:
kubectl: Add proxy --unix-socket=/file/path option

Proxies on a TCP port are accessible outside the current security
context (eg: uid). Add support for having the proxy listen on a
unix socket, which has permissions applied to it.
We make sure the socket starts its life only accessible by the
current user using Umask.
This is useful for applications like Cockpit and other tools which
want the help of kubectl to handle authentication, configuration and
transport security, but also want to not make that accessible to
all users on a multi-user system.

@eparis When you have time, is this something you'd be interested in reviewing?

This looks like something we could wait until after 1.0 to take, but punting over to @jlowdermilk.

It LGTM and we would certainly like to see it in 1.0. Although would understand a rejection. It's obviously safe from a 'breaks other stuff' PoV

Small nit otherwise lgtm. Agree that it's a low risk feature. Deferring to @bgrant0607 to make the call whether it's v1.0 or post.

I'm fine with this particular change, but I need to stop even looking at PRs containing anything other than critical bug fixes very, very soon.
Install pre-submit hooks.
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/devel/development.md#hooks
./hack/verify-gofmt.sh
!!! 'gofmt -s' needs to be run on the following files:
./pkg/kubectl/proxy_server.go

Updated.

Changed to --unix-socket
Check for both --unix-socket and --port
Updated docs
Fixed gofmt
Moved print statements.

Fixed issue with warning about filter for unix sockets.

LGTM

Rebased commit from #10680 onto this branch, as suggested by @bgrant0607

Code LGTM, but I think this deserves some sort of e2e test.

@eparis Where would I put an e2e test? And how can I run these tests. They fall over when I try to poke them in an ignorant manner:
$ sudo ./_output/local/bin/linux/amd64/e2e --provider=local
...
FAIL! -- 1 Passed | 43 Failed | 1 Pending | 5 Skipped F0702 22:21:10.758207   25200 driver.go:94] At least one test failed

development.md
https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/devel/development.md#end-to-end-tests
On Thu, Jul 2, 2015 at 4:21 PM, Stef Walter notifications@github.com
wrote:

@eparis https://github.com/eparis Where would I put an e2e test? And
how can I run these tests. They fall over when I try to poke them in an
ignorant manner:
$ sudo ./_output/local/bin/linux/amd64/e2e --provider=local
...
FAIL! -- 1 Passed | 43 Failed | 1 Pending | 5 Skipped F0702 22:21:10.758207   25200 driver.go:94] At least one test failed
—
Reply to this email directly or view it on GitHub
https://github.com/GoogleCloudPlatform/kubernetes/pull/10608#issuecomment-118154883
.

--
Clayton Coleman | Lead Engineer, OpenShift

@stefwalter are we blocking this on an e2e?

Re. e2e, see also #10764.
This needs to wait until after 1.0.

@stefwalter needs rebase.

@stefwalter Thanks for the PR -- can you please rebase, and I'll try to merge quickly after that?

@alex-mohr Thanks, rebased.

needs a gofmt as well.

needs a gofmt as well.

Done and generated docs.

Tests are also not compiling.
make test
...
# github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl
_output/local/go/src/github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl/proxy_server_test.go:290: too many arguments in call to NewProxyServer
FAIL	github.com/GoogleCloudPlatform/kubernetes/pkg/kubectl [build failed]

Fixed make test

@stefwalter, what happened to the e2e test that was included with this change? Should be pretty easy to add a test for --unix-socket under Describe("Proxy server", ...

what happened to the e2e test that was included with this change? Should be pretty easy to add a test for --unix-socket under Describe("Proxy server", ...

Seems more complicated due to the use of a Unix socket with net.http ... but I can give it a shot.

Ok, I think this is ready.

Minor nit, LGTM. Thanks for adding the e2e test.

authors: alex-mohr bgrant0607 bprashanth eparis jlowdermilk mikedanese smarterclayton stefwalter zmerlynn

repo: GoogleCloudPlatform/kubernetes


text:
Refactored persistent volume controllers to new packaging structure

@gmarek this repackaging matches what you did in #12078.

@mikedanese

Thanks!

authors: gmarek markturansky


text:
add flag to manage $KUBCONFIG files

This adds a flag to kubectl config * commands to directly view and modify the .kubeconfig file referenced by $KUBECONFIG.

+1, I've been wanting this change. I actually think it should be default behavior; the envvar flag is unnecessary. If I set $KUBECONFIG, I expect kubectl to use it for both read and write.

If I set $KUBECONFIG, I expect kubectl to use it for both read and write.

git config operates against local config by default.  Admittedly, there isn't a environment variable file for git, but I think people might expect congruence.  It's a very easy change, but I do want to make sure it's an explicit one.
@smarterclayton Any thoughts?

I think write priority should match load order. The loading rules will prioritize a kubeconfig file from envvar over the local one. This means that with current behavior, if I set $KUBECONFIG, then run kubectl set-context foo, that context is potentially ignored by subsequent calls because I set it in a local .kubeconfig, but I'm reading from the envvar .kubeconfig first.

I'm convinced.  --local is now false by default.  --envvar still exists as an explicit option to clearly specify intent.  Default behavior is

$KUBECONFIG if it is set
./.kubeconfig if it is not.

I'm fine with keeping --envvar as an explicit option, as long as we fail a command if --envvar was specified, but the variable is unset.
Also, this is a bit tangent, but it doesn't look like we prevent the user from specifying multiple flags for kubeconfig source. i.e. we should error out on a command like
kubectl config set-context foo --global --local

Am I just missing that error code?

I'm fine with keeping --envvar as an explicit option, as long as we fail a command if --envvar was specified, but the variable is unset.

Done.

it doesn't look like we prevent the user from specifying multiple flags for kubeconfig source

Nope, looks like an oversight.  I added it.

lgtm.


text:
Make client service requests use the default timeout now that external load balancers are created asynchronously

Effectively reverts #5858. Load balancers are created asynchronously as of #6271.

ping

Apologies for the delay Alex.
Have you run the Services e2e tests against this?

Yes, I ran the change through them 10 times and they all came up green.

LGTM

authors: a-robinson quinton-hoole


text:
Revert "Revert "Revert "Kubelet: Add rkt as a runtime option"""

Comically re-revert #7743
Because @zmerlynn is an idiot and can't read his own build results.
Reverts GoogleCloudPlatform/kubernetes#7811

If you want to see what success is, run
make release
$ ldd -v _output/release-stage/server/linux-amd64/kubernetes/server/bin/kubelet | grep GLIBC_2.14
                libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6
                libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6

If you see those GLIBC_2.14 tags, that's bad. :)

LGTM

Ah yes, we do have that issue...

Yes, I totally ran into this issue when I hacked the demo for rkt and k8s. The way for me to fix the issue is I linked kubelet statically. Our debian image has old libc, but rkt requires a newer version.

Of course we fix is just a workaround.

I left the issue open as #7803.

The title of this reads like http://en.wikipedia.org/wiki/Buffalo_buffalo_Buffalo_buffalo_buffalo_buffalo_Buffalo_buffalo

I felt a little comical here. Apologies for the in and out. :)

authors: dchen1107 liggitt vmarmol zmerlynn


text:
update setuptools version

Description
Fix nightly test issue with setuptools version.
This is the issue that setuptools version >= 71.X doesn't work: https://github.com/pypa/setuptools/issues/4483
Tests
https://60bb71acc6784780b3bbdbae4ffa636f-dot-us-central1.composer.googleusercontent.com/dags/pytorchxla-torchbench-release/grid?dag_run_id=manual__2024-07-23T17%3A01%3A51.682195%2B00%3A00&task_id=torchbench_all-v4-8.provision.setup&tab=logs
Checklist
Before submitting this PR, please make sure (put X in square brackets):

[x] I have performed a self-review of my code.
[x] I have necessary comments in my code, particularly in hard-to-understand areas.
[x] I have run one-shot tests and provided workload links above if applicable.
[x] I have made or will make corresponding changes to the doc if needed.

Could you summarize the reason why we need to select the setuptools version ">=70.0.0,<71.0.0" in the PR description?
Also, do you need to add a TODO to remove the version constraint later?

Could you summarize the reason why we need to select the setuptools version ">=70.0.0,<71.0.0" in the PR description?
Also, do you need to add a TODO to remove the version constraint later?

Added in the description. Personally I have no plan to remove the version constraint in the near term. This requires other packages to update their setup.py accordingly, which may take time.

repo: GoogleCloudPlatform/ml-auto-solutions


text:
Upgrade pax stable python version

Description
The pax stable tests include optax as a dependency, which on 1/15 released a new stable version dependent on a newer python version. As a result, this PR updates the python version for the pax stable tests.
Tests
Will include link once the tests are done
Checklist
Before submitting this PR, please make sure (put X in square brackets):

[X] I have performed a self-review of my code.
[X] I have necessary comments in my code, particularly in hard-to-understand areas.
[X] I have run one-shot tests and provided workload links above if applicable.
[X] I have made or will make corresponding changes to the doc if needed.

The fix to the stable tests might require a new pax version, in which case I will hold this PR off for the time being.

The fix to the stable tests might require a new pax version, in which case I will hold this PR off for the time being.

new pax/praxis 1.3.1 is released, will open this PR, ready for review/merge


text:
Document Cloud Build worker pool quota increase required for the 1 private pool per region - will hit on 2nd dev LZ

I currently have a limit of 1 private cb pool per region

module.tf_private_pool.google_service_networking_connection.worker_pool_conn[0]: Creation complete after 2m13s [id=projects%2Fprj-b-cicd-fgbs%2Fglobal%2Fnetworks%2Fvpc-b-cbpools:servicenetworking.googleapis.com]
module.tf_private_pool.google_compute_network_peering_routes_config.peering_routes[0]: Creating...
module.tf_private_pool.google_cloudbuild_worker_pool.private_pool: Creating...

module.tf_private_pool.google_compute_network_peering_routes_config.peering_routes[0]: Still creating... [10s elapsed]
module.tf_private_pool.google_compute_network_peering_routes_config.peering_routes[0]: Creation complete after 12s [id=projects/prj-b-cicd-fgbs/global/networks/vpc-b-cbpools/networkPeerings/servicenetworking-googleapis-com]
╷
│ Error: Error creating WorkerPool: operation received error: error code "8", message: generic::resource_exhausted: project 991985440030 has insufficient quota to create a new worker pool; see https://cloud.google.com/build/quotas, details: []
│  details: map[]
│
│   with module.tf_private_pool.google_cloudbuild_worker_pool.private_pool,
│   on modules/cb-private-pool/main.tf line 30, in resource "google_cloudbuild_worker_pool" "private_pool":
│   30: resource "google_cloudbuild_worker_pool" "private_pool" {
│
╵
michael@cloudshell:~/tef-oldev3/pbmm-on-gcp-onboarding/0-bootstrap (tef-oldev3)

3 min later - quota approved
our Case #51131277 for Google Cloud Platform has been updated.

Case Subject: Cloud Build API Quota Increase Request For Project prj-b-cicd-fgbs

Case Comment :
Hello, Your quota request for project '991985440030' has been approved and your quota has been adjusted accordingly. The following quotas were increased: +-----------------------+--------------------------------+-------------------------+-----------------+ | Name | Dimensions | Location | Requested Limit | +-----------------------+--------------------------------+-------------------------+-----------------+ | PrivatePoolsPerRegion | region=northamerica-northeast1 | northamerica-northeast1 | 5 | +-----------------------+--------------------------------+-------------------------+-------------


text:
fix: Teradata SSLMODE issue fix

Solves Teradata SSLMODE support - connection timeout issue (#1011) and adds support for additional teradatasql connection options as a JSON string.
Example of usage:
data-validation connections add -c my_td Teradata --json-params "{'sslmode': 'disable', 'encryptdata': 'true'}"

PR closed/replaced due to issues with email associated with commit.


text:
Pull from main into oci-branch

Keeping up to date with main branch
Also fixes an argument order bug in kpt pkg push

@phanimarupaka can you pl. take a final look and get it merged in the branch.

Checking why the live tests are failing.

I noticed in the pull from main it started back in November. There could have been something not quite right in the earlier rebase - I can take a look at that first, wouldn't want you to spend time troubleshooting a broken PR.

authors: droot loudej phanimarupaka

repo: GoogleContainerTools/kpt


text:
Prep for merge

Preparing for merging the feature-rollouts branch into the main branch.
Note: DO NOT MERGE THIS YET.

@natasha41575 so I created another PR https://github.com/GoogleContainerTools/kpt/pull/3805 that should facilitate clean merge. I had to remove two commits. One of them will be redundant post merge and second-one, I plan to re-add after the merge as a separate PR.


text:
Image dragging causing 'malformed-mjml' error

When image from file editor is dragged onto canvas at top or bottom, it shows outside the MJML tags and causes a 'malformed-MJML' error to appear in the console.
It seems like it is being dragged between the wrapper and the MJML.
Is there a way to change the wrapper from an html body tag so this issue doesn't occur?

Hi @katefurtney what do you mean by "file editor"?

authors: artf katefurtney

repo: GrapesJS/mjml


text:
Add statistics tracking

[ ] Total info hashes (total torrent count)
[ ] Total peer hits

[ ] Unique peer hits

[ ] Total bytes transferred
[x] Peers reaped

I'm going to hold off on unique peer hits for Notorious. I don't want to track user's IPs or any other meaningful data, but I don't mind incrementing a column in a DB. Regardless of the nature of what I'm hosting (FOSS software) I don't want to store information about people testing my software. Would make me some sorta rood dood.

repo: GrappigPanda/notorious


text:
🛑 Server Gaming is down

In 9da1232, Server Gaming (https://game.greathost.ro) was down:

HTTP code: 403
Response time: 1104 ms

Resolved: Server Gaming is back up in d5f4c0f after 23 minutes.

repo: GreathostRo/upptime


text:
🛑 Server Ultra is down

In eb4dded, Server Ultra (https://ultra.greathost.ro) was down:

HTTP code: 403
Response time: 1767 ms

Resolved: Server Ultra is back up in 1e5cc73 after 2 minutes.


text:
🛑 Server Gaming is down

In ee8a563, Server Gaming (https://game.greathost.ro) was down:

HTTP code: 403
Response time: 929 ms

Resolved: Server Gaming is back up in efae5c0 after 11 minutes.