Elem none

Add an element none.
This can be used for sending arguments to functions.
Maybe more later, but I thought it was a cool idea for now.
Also lets you specify information without having to have it get packed. Probably will find some bugs when we unpack or have some weird situations like that.

Aaron, I'll ping you when this seems ready.
I've found a few other things I want to fix along the way. Feel free to let me know if you don't like the idea though.

I wasn't sure at first, but after looking at the test I think I like the idea.  Having a structured way to provide values that are used to construct the message like the md5 salt example seems like a potentially useful thing.

@sprout42 I added the ability to specify information about when to run certain functions in the callable. I'm thinking some of the structure might change, but the idea is mostly there.
You can now do something like:
        def pseudo_salted_md5(salt, original):
            temp_md5 = md5(original)

            if salt is None:
                salt = b''

            return md5(salt + temp_md5.digest()).digest()

        def pack_salt(data):
            return b''.join(item.to_bytes(1, 'little') for item in data)

        TestStruct = Message('TestStruct', [
            ('length_in_objects', 'H', 'vardata'),
            ('vardata', self.VarTest, 'length_in_objects'),
        ])

        CRCedMessage = Message('CRCedMessage', [
            ('data', TestStruct),
            ('salted', None),
            ('function_data', '16B', {
                'make': (pseudo_salted_md5, 'salted', b'data'),
                'pack': (pseudo_salted_md5, 'salted', b'data'),
                'unpack': (pack_salt, 'function_data'),
            }, False),
        ])

The main reason I added this was because you'll probably want to run different functions to unpack rather than pack something. When you pack it, you want your function to go from items -> bytes, and when unpack you want to go from bytes -> objects. But sometimes because of how the struct works, you'll get weird things.
When you unpack the MD5 thing, because of the 16I for the struct packing, you'd get a list of 16 ints, which isn't that helpful when you want it to stay bytes.
Anyway, let me know what you think about this.

I remember thinking that it'd be nice to have a raw bytes element (I just looked, apparently it's issue #5).  I did think that the numeric element should take the list of 16 Ints and smash them into one gigantic number... although I'm not sure that's super useful in this case (it's more useful when taking a field that is 3B and making a sensible number out of it).
It is true that you'd need different functions for pack/unpack, especially with this type of data.  most likely you'll encode using one value and decode using another.
If we had a raw bytes element then that would make sense for this because the pack function could run based on some object-only None data value(s) then the output of that function would be bytes that are inserted into the message.  So perhaps we should figure out how to solve issue #5 before you (we?) finish this PR.

So... I can't remember why I wanted to hold off on this yet, I'm merging it.


libvirt_domain still created on error

System Information
Linux distribution
Archlinux
Terraform version
$ terraform -v
Terraform v1.3.9
on linux_amd64
+ provider registry.terraform.io/dmacvicar/libvirt v0.7.1
+ provider registry.terraform.io/hashicorp/template v2.2.0

Provider and libvirt versions
.terraform/providers/registry.terraform.io/dmacvicar/libvirt/0.7.1/linux_amd64/terraform-provider-libvirt_v0.7.1 -version
.terraform/providers/registry.terraform.io/dmacvicar/libvirt/0.7.1/linux_amd64/terraform-provider-libvirt_v0.7.1 0.7.1

Checklist

[x] Is it a bug or something that does not work as expected? Please make sure you fill the version information below:

Description of Issue/Question
Setup
(Please provide the full main.tf file for reproducing the issue (Be sure to remove sensitive information)
The file in nvram must be missing to reproduce:
terraform {
  required_providers {
    libvirt = {
      source = "dmacvicar/libvirt"
    }
  }

  required_version = ">= 0.13"
}

provider "libvirt" {
  uri = "qemu:///system"
}

resource "libvirt_volume" "packer_win10_22H2" {
  name = "packer_win11_22H2"
  pool = "default"
  source = "qemu-drives/packer-win10_22H2"
  format = "qcow2"
}

resource "libvirt_network" "some_network" {
  name = "some_network"
  mode = "nat"
  domain = "kvm"
  dns {
    enabled = true
    local_only = false
  }
}

resource "libvirt_volume" "win10_terraform_01" {
  provider = libvirt.rtiiix
  name = "win10_terraform_01_storage"
  pool = "default"
  base_volume_id = libvirt_volume.packer_win10_22H2.id
  size = "30000000000"
}

resource "libvirt_domain" "win10_terraform_01" {
  provider = libvirt.rtiiix
  # domain name in libvirt, not hostname
  name = "win10_terraform_01"
  memory = "2048"
  vcpu = 2
  firmware = "/usr/share/OVMF/x64/OVMF_CODE.fd"
  nvram {
    file = "win10_terraform_01.fd"
    template = "/usr/share/ovmf/x64/OVMF_VARS.fd"
  }

  autostart = true

  network_interface {
    network_id     = libvirt_network.shady_network.id
    mac            = "52:54:00:6C:3C:02"
    addresses      = ["<IP_ADDRESS>"]
    hostname       = "win10_terraform_01"
    wait_for_lease = true
  }

  disk {
    volume_id = libvirt_volume.win10_terraform_01.id
  }

  console {
    type        = "pty"
    target_port = "0"
    target_type = "serial"
  }
}

Steps to Reproduce Issue
(Include debug logs if possible and relevant).
Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

libvirt_domain.win10_terraform_01: Creating...
╷
│ Error: error creating libvirt domain: Failed to open file '/usr/share/ovmf/x64/OVMF_VARS.fd': No such file or directory
│
│   with libvirt_domain.win10_terraform_01,
│   on main.tf line 90, in resource "libvirt_domain" "win10_terraform_01":
│   90: resource "libvirt_domain" "win10_terraform_01" {
│
╵

The second time you apply, it will result in
o you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

libvirt_domain.win10_terraform_01: Creating...
╷
│ Error: error defining libvirt domain: operation failed: domain 'win10_terraform_01' already exists with uuid 3142bd26-c41f-40b1-9959-b38ecfd406dd
│
│   with libvirt_domain.win10_terraform_01,
│   on main.tf line 90, in resource "libvirt_domain" "win10_terraform_01":
│   90: resource "libvirt_domain" "win10_terraform_01" {
│
╵

Because the domain would have been created despite the error in the previous case.
Note: line are not matching because I removed what was not necessary after, sorry for that. Since the line is quoted, it's easy to fetch the correct location.
Expected result
The domain should not have been created in the first step, or be destroyed before terraform exits.

I have been hitting this issue as well.


Investigate Dalvik compatibility

This library currently does not work on Dalvik, due to the VM's poor support for XML schemas.
Here's a stack trace I get on instantiating a Srx2SaxParser:
Caused by: java.lang.IllegalArgumentException: http://www.w3.org/2001/XMLSchema
     at javax.xml.validation.SchemaFactory.newInstance(SchemaFactory.java:192)
     at net.sourceforge.segment.util.Util.getSchema(Util.java:265)
     at net.sourceforge.segment.util.Util.getSchema(Util.java:247)
     at net.sourceforge.segment.srx.io.Srx2SaxParser.<init>(Srx2SaxParser.java:181)

Let me know if you need any more information.

Thank you for bug report. I currently don't develop on Android / Dalvik, so I wasn't aware of the issue.
Can I suggest to try the following:

Disable the validation on Dalvik (or always). To do this create Srx2SaxParser as follows:
 Map<String, Object> parameters = new HashMap<String, Object>();
 parameters.put(Srx2SaxParser.VALIDATE_PARAMETER, false);
 SrxParser parser = new Srx2SaxParser(parameters);

Try other parsers - Srx2Parser (which uses JAXB, always validating) or Srx2StaxParser (which uses STAX, no validation).

Since Dalvik's libraries do not support schema validation, there's probably not much I can do except using custom library to do it. Do you think it would be worth it?

It's all looking promising, thanks. I successfully followed your first suggestion. All the extra changes I've had to make are in https://github.com/languagetool-org/languagetool, so I'm gonna go ahead and close this issue.
Resolution – Segment works on Android.

Cool, I am glad I could help.

Actually, should we consider improving the scenario of using the library on Android with validation enabled such that it raises a more comprehensible exception?

Well, I think it's Adnroid / Dalvik developers job to make the error more clear. It's quite weird that they don't support XMLSchema.
Nevertheless, feel free to send me a pull request - I don't currently develop on Android so I won't do it. Let me know whether you are interested in contributing, I will close the ticket otherwise.


How to read Shell Curl output into a variable

Question Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Question Description

In one of my lanes, I am trying to call a shell curl command to do something. The response of that curl is: {"app_url":"bs://05ab244fa8558ac74c12c435594c"}. Here is the command inside my lane:
#1
app_upload_response = sh("curl -u #{browserstackKey} -X POST 'https://api-cloud.browserstack.com/app-automate/upload' -F<EMAIL_ADDRESS>#2
app_url = app_upload_response[:app_url]
The lane fails on #2, saying: "no implicit conversion of Symbol into Integer". I don't see where I am trying to convert a symbol to an integer? Please help.

What does app_upload_response look like after 1)?

I was able to solve it via JSON. I was expecting the returned data from the CURL would be a hashmap but it was a plain json acceptable string ({"app_url":"bs://05ab244fa855812c435594c"})
After using JSON.parse(), I was able to convert it into a hash and then got the value of app_url key.
app_upload_response = `curl -u #{browserstackKey} -X POST 'https://api-cloud.browserstack.com/app-automate/xcuitest/test-suite' -F<EMAIL_ADDRESS>
jsonResponse = JSON.parse(app_upload_response)

browserstackTestURL = jsonResponse["test_url"]


Install Guide is broken[BUG]

Any attempts to goto the website hosted at https://wiki.cajun.pro/books/varken/ results in the following response:
Wrong request URL. Error pages are available at the following URLs: /{code}.html

Wayback machine does have some pages archived, but it is not a full archive.

Looks like the wiki is back up and running, I am able to access everything at this time.
Thank you!!!


[stable/prometheus-operator] fix cpu usage

What this PR does / why we need it:
CPU display is broken in current release. The selector in prometheus must have changed. Removing node_ fixes the issue for us on the default dashboards
Checklist
[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

[x] DCO signed
[x] Chart Version bumped
[x] Variables are documented in the README.md
[x] Title of the PR starts with chart name (e.g. [stable/mychartname])

/ok-to-test

/hold

@vsliouniaev ah didn't see that. Will look into doing that then. Thx for the pointer

OK the complexity of this is going outside of scope so I'll just lurk again and wait for #18375 to merge and see from there


Netty sun.nio.ch.EPollArrayWrapper.epollWait High CPU usage profiler problem

Some guys here (including me) reported that their Netty application has a very high CPU usage. This article helped me a lot:
http://www.brendangregg.com/blog/2014-06-09/java-cpu-sampling-using-hprof.html
To sum it up in a few sentences: When you profile your Netty application with the Java parameter '-agentlib:hprof=cpu=samples' it might show a very high CPU usage for this method: sun.nio.ch.EPollArrayWrapper.epollWait. This should be a wrong result in most of the cases.
It seems in my case it was the Java based SSLHandler which consumed a lot of CPU.
So my little Netty world is alright now :)

Interesting. I just stumbled upon this issue doing some profiling for Vert.x 3 - looks like the exact same issue is present in VisualVM in JDK 8 :(


Add PR template

Adding an initial PR template (mostly because I'd like to get notified when PR's are open). We can adjust these as necessary, I just stole what we use for the CoP.

Gonna go ahead and merge this so we have the notifications on each PR. If we want to add more to the guidelines feel free to open a PR.


Remove CAS container

This PR will remove the CAS server from the development environment.

I built and ran this in my local environment successfully


Release Google.Cloud.Trace.V2 version 3.2.0

Changes in this release:
New features

Enable REST transport in C# (commit f6a1c3e)

Created release for Google.Cloud.Trace.V2-3.2.0


Create custom components in MJML

First of all, let me say I love MJML.
I'm currently setting up some templates though and am finding that creating components is a bit cumbersome.
My project is setup with:

components written in JS
includes written in MJML
templates written in MJML

I'm using the VS Code extension for MJML, so when editing an include or template I get feedback in the editor.
I'm finding that the components are the one place where I am kind of coding in the dark though (markup is inside a template literal).
I know I can run a build and it will tell me what is wrong, but that loop is really slow, even with a watch task.
I'd love to be able to create a component in MJML.
If you've used Svelte, you know where I'm going with this...
Creating a component could be this easy:
MyComponent.mjml
<script>
  export const tag = "my-component";
  export const allowedAttributes = { align: "enum(left,center,right)", href: "string" };
  export const defaultAttributes = { align: "left", href: "" };
</script>

<mj-section>
  <mj-column>
    <mj-button {align} {href}>
      <slot />
    </mj-button>
  </mj-column>
</mj-section>

Usage:
<mjml>
  <mj-body>
    <my-component align="center" href="/">Click me</my-component>
  </mj-body>
</mjml>

Actually, even simpler:
<script>
  export const tag = "my-component";

  /** @type {"left" | "center" | "right"} */
  export let align = "left";

  /** @type {string} */
  export let href: string = "";
</script>

<mj-section>
  <mj-column>
    <mj-button {align} {href}>
      <slot />
    </mj-button>
  </mj-column>
</mj-section>

Agreed - creating custom components is very cumbersome, to the point where I've decided it's not even worth it. So much overhead is needed to create a new component - this is an area that could definitely use some overhaul.


Unable to swap Fan icon

Hi all,
I think I found a bug.
I've got a Tuya ceiling fan installed and working, however the icon on homekit is of a table top fan.
When I go to the device settings and try to tap on the fan icon to swap it, nothing happens.

This plugin is incredibly better than the official one.
Excellent work guys !

Hi @ricardotpo,
Icon customize feature is provided by homekit app, most accessories don't support icon changing, only few supported (Switch, Light).
See #93 .

there is a fan device/accessory type that allows switching icons, as shown in attached

there is a fan device/accessory type that allows switching icons, as shown in attached
i came across this in the homebridge-irobot plugin, which uses a type of fan accessory to surface the vacuum

Thanks for the information, I will review it's code to see how it do.

@0x5e Thank you !
I was not expecting such a fast response !

@ricardotpo @r2shyyou There's two services: Fan and Fanv2, I'm using Fanv2 and homebridge-irobot is using Fan.
Fan has more customizable icons, while Fanv2 has more characteristics (mode: auto/manual, child lock, swing).
Seems the custom icon requirements is strong, before mode/child lock/swing implemented, I will use Fan instead.

So for the fs and fskg category, I need to check their schema and if one of the mode, lock, swing exists, I will treate it as Fanv2, else Fan. I think that's a final solution. Besides there's some cache cleanning work to be done.

Please try 1.7.0-beta.1, should work now :)


Chinese nickname length support

const nickname = 'test'
nickname.length === 4  // is fine

but Chinese is wider, i hope this below:
const ChineseNickname = '测'
ChineseNickname.length = ChineseNickname.replace(/([\u4e00-\u9fa5])/g,'aa').trim().length;
// this length === 2

then:
const mixinNickname = '测test'
mixinNickname.length === 3 // this is i need

it can be a feature?

Well this can be solved by a custom rule for now, can't say if it would be implemented soon or not.

thank you, i will try

You can do this:
import { Validator }, VeeValidate from 'vee-validate';

Validator.extend('cNickname', (value, [length]) => {
  return value.replace(/([\u4e00-\u9fa5])/g,'aa').trim().length <= length;
});

and you can use this rule in your templates like the included ones.


fix: close AI window on navigating between SQL queries

Description
When a user navigates between SQL queries the AI window persists causing Accept/Reject to overwrite code in intended places. This PR fixes it by force closing AI window, when dataTreePath passed to code editor changes
Type of change

Bug fix (non-breaking change which fixes an issue)

Testing

How Has This Been Tested?

[x] Manual
[ ] Jest
[ ] Cypress

Test Plan

Add Testsmith test cases links that relate to this PR

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[ ] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[ ] Test plan covers all impacted features and areas of interest
[ ] Test plan has been peer reviewed by project stakeholders and other QA members
[ ] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test sha=a4439fb


Delete old photo after uploading new ones

It appears to me (I haven't digged to backend source) that the backend doesn't update old photos in the storage with new photos as new ones are updated.

It can change profile picture from the default picture (from GitHub or Google) to the uploaded picture (Firebase Storage), however it apparently can't change from one uploaded picture to another uploaded picture.
Please have a look. I say apparently because it may be a frontend bug (which I think is unlikely). For now I will add the [bug] label.

Steps to reproduce:

Go to https://test.joulev.dev, log in there
If your photoURL is the default photo from GitHub or Google, upload a new one
Upload another profile photo

It now appears that the photos are indeed updated but for some reasons, the public URL doesn't point to the new photo immediately. In fact, it takes quite long, and it isn't due to caching either (I opened the link in a new browser and it still shows the old photo).

I used { metadate: { firebaseStorageDownloadTokens: <token> } } to manually set the token and recreate the download URL.
This is not a documented feature 😰 But it was the best solution available.


update docs to remove confusing inconsistency regarding whether or not patrol_cli is mandatory

Use case
The pub.dev docs for patrol include the line:

It can be used on its own or with patrol_cli.

This line is from here:
https://github.com/leancodepl/patrol/blob/c08337011c4ba02d75173cf400aa31c8ba3ddc5b/packages/patrol/README.md#L12
Those docs go on to include example integration test code which includes widget tests.
The above conflicts with the Getting Started section of the docs, which says:

Patrol CLI (command-line interface) is a small program that enables running Patrol UI tests. It is necessary to run UI tests (flutter test won't work! Here's why).

Proposal
Remove the misleading line:

It can be used on its own or with patrol_cli.

... and replace with something to the effect of patrol_cli is required to run widget tests.

That's right - we forgot to update the docs. Thanks & sorry.


A cookie associated with a cross-site resource at https://m.stripe.com/ was set without the SameSite attribute.

Just started noticing some new warnings in Chrome regarding the cookies that Stripe loads into Session Storage. Here is the full warning:
A cookie associated with a cross-site resource at https://m.stripe.com/ was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

Not sure if anything needs to be done with this package, or if Stripe just needs to update their cookie attributes and we'll be all set.

Yeah, Stripe's library does all the heavy lifting, this package just wraps calls to it in a way that's friendly to Angular.js apps.
I'll keep this open for now, in case someone else has interrogations about this. Feel free to add more information when you find out what this is about!


worthless answers

it keeps repeating the same failed solution even if i show that i already implemented it. this is worthless and it seems especially bad compared to regular chatgpt. like it has an ego and an inability to acknowledge its own failures. please drop the ego. (screenshot is of a bonus: reporting this issue was too much data for github apparently? weird)

Ditto. The endless going circles with it insisting on repeating the same mistakes I've already told it to stop doing is a tremendous waste of time. It cycles between three or four wrong answers, always forgetting by the third question following what I've already told it repeatedly is wrong and not to do.
This is far beyong this just having some rough edges that need sanding off. This going in endless circles is a 100% waste of user time, absolutely and totally nonconstructive.
And I can't even get it to submit the chat that I wanted to submit feedback about at all. It just opens this issues section in my browser. There's no way for me to export, save, copy, or otherwise indicate the chat that the problm is with.

+1 happens to me sometimes

Sorry for the bad experience but something more concrete would help me improve those scenarios. Please share the specific prompts or just share the whole conversation (right click > copy all). You can also email it to me if you prefere.


⚠ Bofrost.be has degraded performance

In 3fcfa04, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 920 ms

Resolved: Bofrost.be performance has improved in 3be6bc6 after 6 minutes.


UI5 Table, too much data send on selection to server

all dimensions with all members are sent to the server, then the connection breaks.

corrected with installer from yesterday. now, not all data are passed back, only those which are requried.


Set up and integrate Open Meteo API (Weather)

[ ] Make call to to API with required user information (location in proper format for API)
[ ] Return information in console.log
[ ] Parse said information in console.log
[ ] Return necessary cloud cover information to user

We have switched from Open Meteo to Weather API for the time being.  So far, I'm able to get the information to be printed to the console log.


When will the source code be published

Really appreciate your impressive work! When will the source code be published? Can't wait to have a try on your model.

We are preparing the code for publication at the moment. We intend to finish it before september.

@klingner congratulations on the great work and acceptance to ECCV 2020.
Looking forward to the code!


Refining the diagnostic output system

The current ConfigOutput system works fine, but we will soon be adding XIOS. This will allow more complex specification of diagnostic outputs. This issue is the place to discuss what the future output system of nextSIM-DG will look like.

My current thoughts on where development should go:

The set of diagnostic outputs should be able to be specified at runtime, preferably by only changing the configuration options in the config file or on the command line. This is currently how ConfigOutput works, but I would like to maintain that functionality when XIOS and its XML files are added. This might involve a wrapper script around the nextsim executable to create the XIOS files. Such a script might be needed anyway to launch the XIOS server &c.
Some way to specify how much output is passed to ConfigOutput/XIOS. My understanding is that XIOS expects all of the fields to be passed to it, and filtering is done internally. Considering that we might want to provide a large number of debug outputs, some way of setting this might be useful.
But a user is unlikely to want to choose regular/debug levels of output globally, but rather on a per component basis. This would imply a few things:

Configuration options for anything that has a variable level of input.
More parts of the model become configurable, increasing class complexity. But this would have to increase in any case to allow selectable levels of output.
The available fields are now visible in the config help system, so an additional help system laying out the available fields is not necessary.
Common code for the detail switching can be placed in a base class, something like ConfiguredOutputComponent, inheriting from both ModelComponent and Configured.

The workflow might then be:

The user consults the documentation or the config help system to determine which output fields they require. This information includes the field name used by ConfigOutput and XIOS.
The user adds this information to the config file or the nextsim command line.
For XIOS, this information is processed by a script to generate the necessary XML files.
The classes supporting output are configured to generate the requested output.
During runtime, all configured fields are forwarded to ConfigOutput/XIOS every TS, where the necessary output processing occurs.


Updating some previews which moved to GA's

Approx Percentile, SQL Projects

@MashaMSFT
Can you review the proposed changes?
When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team


ProfileMobileTabs

Addto shared-components new component ProfileMobileTabs from https://github.com/adamryvola/school-picker/tree/master/app/components/ProfileMobileTabs

Sorry i forgot add a keys

      items.map((item, index) =>
        <button
          ...
          key={index}
        >
         ...
        </button>
      )

DONE
https://adamryvola.github.io/shared-components/#ProfileMobileTabs
TODO: integrate into school-picker and others

Added into school-picker
Add new propery: handler
DONE


Support CRUD + Charge for tokenised credit cards

Basic quick + dirty support for creating, reading, updating, deleting and charging tokenised credit cards
Tests included + updated.
Note: I had to break your API for bill_to slightly to add extra fields because you didn't include postcode or state which are required here.

@speeddragon should we take a look into this or do you prefer to handle it?

This PR needs a refactor since the Client module is getting huge, as mentioned in my last comment.

@Zensavona can you evaluate the refactor suggestion made by @speeddragon and implement it?

@rageofflames / @speeddragon since the Client module is getting huge, is it a problem from your guys' perspective to break the existing API and split it up? That's the reason I left it this way.
Just let me know about that and I'll get to it when I have a spare couple hours.

We definitely should break it. If I have some time I will try to improve it also.


removed the utilities submodule

added the get_filename function to a new app called core

Also, ordered the imports in modified files to be in alphabetical order.


Show sponsored transactions in sponsor address history

Currently, when a wallet sponsors a transaction, it does not show up in the history of the address.
For example, the address below has sponsored several transactions:
https://explorer.stacks.co/address/SP3NMS4ZSNFW1YM4HYF4WJKKVSXN7DR1FZG6P2HHG?chain=mainnet
The nonce of the address has increased, but there are no corresponding transactions in the history.

Thanks Ken. This issue is duplicated, I'll close it in favor of https://github.com/hirosystems/explorer/issues/576


broken reverse stager

PS >dir
error: uncaptured python exception, closing channel <lib.listener.Handler connected ...:*** at 0x7f1d19f1a4b0> (<class 'ssl.SSLWantReadError'>:The operation did not complete (read) (_ssl.c:1946) [/usr/lib/python2.7/asyncore.py|read|83] [/usr/lib/python2.7/asyncore.py|handle_read_event|449] [/root/wpl/Winpayloads/lib/listener.py|handle_read|42] [/usr/lib/python2.7/asyncore.py|recv|387] [/usr/lib/python2.7/ssl.py|recv|754] [/usr/lib/python2.7/ssl.py|read|641])
Client 1 Connection Killed

I have used installation from source...


Project maintainer privileges

@paulgodfrey @VijayM Not sure if it's unconventional at Zendesk, but could I be restored as a maintainer for the repo? Would still like to help out and maintain this project after having left the team :)

@zenrfung @haabaato help :) Could one of you ping ops?


Fix exception in website-relations-joined

If the website relation is joined when there are no docker-registry
relations then the hook panics trying to update the clients. This change
checks the clients exist before attempting to update them.

Thanks! This is currently in the beta channel, available in rev 15 and higher:
https://jujucharms.com/u/containers/docker-registry/15


Removed Extra Slide

Problem
There was an extra slide!
Solution
It was pointless and I deleted it.
Things to check

[x]  The slide is removed
[ ]  The other slides are intact

Yeah this slide was important just needs to be realized.


⚠ Bofrost.nl has degraded performance

In eb0306b, Bofrost.nl (https://www.bofrost.nl) experienced degraded performance:

HTTP code: 200
Response time: 1475 ms

Resolved: Bofrost.nl performance has improved in fb8d9f3 after 6 minutes.


error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge

istio-egressgateway-547789479-tt8hd        1/1       Running     12         9h
istio-ingress-5b8b8669b5-hjqrd             1/1       Running     12         9h
istio-ingressgateway-5bf975f6d9-7thwm      1/1       Running     12         9h

these three pods keep restarting.

2018-05-03T07:29:49.935580Z     info    Epoch 0 starting
2018-05-03T07:29:49.936317Z     info    Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster istio-ingress --service-node ingress~<IP_ADDRESS>~istio-ingress-5b8b8669b5-hjqrd.istio-system~istio-system.svc.cluster.local --max-obj-name-len 189 -l info --v2-config-only]
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:188] initializing epoch 0 (hot restart version=9.200.16384.256.options=capacity=16384, num_slots=8209 hash=228984379728933363)
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:190] statically linked extensions:
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:192]   access_loggers: envoy.file_access_log,envoy.http_grpc_access_log
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:195]   filters.http: envoy.buffer,envoy.cors,envoy.ext_authz,envoy.fault,envoy.grpc_http1_bridge,envoy.grpc_json_transcoder,envoy.grpc_web,envoy.gzip,envoy.health_check,envoy.http_dynamo_filter,envoy.ip_tagging,envoy.lua,envoy.rate_limit,envoy.router,envoy.squash,istio_authn,jwt-auth,mixer
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:198]   filters.listener: envoy.listener.original_dst,envoy.listener.proxy_protocol
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:201]   filters.network: envoy.client_ssl_auth,envoy.echo,envoy.ext_authz,envoy.http_connection_manager,envoy.mongo_proxy,envoy.ratelimit,envoy.redis_proxy,envoy.tcp_proxy,mixer
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:203]   stat_sinks: envoy.dog_statsd,envoy.metrics_service,envoy.statsd
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:205]   tracers: envoy.dynamic.ot,envoy.lightstep,envoy.zipkin
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:208]   transport_sockets.downstream: alts,raw_buffer,ssl
[2018-05-03 07:29:49.973][55][info][main] external/envoy/source/server/server.cc:211]   transport_sockets.upstream: alts,raw_buffer,ssl
[2018-05-03 07:29:49.980][55][warning][upstream] external/envoy/source/common/config/grpc_mux_impl.cc:217] gRPC config stream closed: 1,
[2018-05-03 07:29:49.980][55][warning][upstream] external/envoy/source/common/config/grpc_mux_impl.cc:39] Unable to establish new stream
[2018-05-03 07:29:49.980][55][info][config] external/envoy/source/server/configuration_impl.cc:52] loading 0 listener(s)
[2018-05-03 07:29:49.980][55][info][config] external/envoy/source/server/configuration_impl.cc:92] loading tracing configuration
[2018-05-03 07:29:49.980][55][info][config] external/envoy/source/server/configuration_impl.cc:101]   loading tracing driver: envoy.zipkin
[2018-05-03 07:29:49.980][55][info][config] external/envoy/source/server/configuration_impl.cc:114] loading stats sink configuration
[2018-05-03 07:29:49.980][55][critical][main] external/envoy/source/server/server.cc:72] error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge
[2018-05-03 07:29:49.981][55][info][main] external/envoy/source/server/server.cc:426] exiting
2018-05-03T07:29:49.983382Z     warn    Epoch 0 terminated with an error: exit status 1
2018-05-03T07:29:49.983414Z     warn    Aborted all epochs
2018-05-03T07:29:49.983463Z     info    Epoch 0: set retry delay to 1m42.4s, budget to 0

Name:           istio-ingress-5b8b8669b5-hjqrd
Namespace:      istio-system
Node:           kube-6.sbezverk.cisco.com/<IP_ADDRESS>
Start Time:     Wed, 02 May 2018 17:46:08 -0400
Labels:         istio=ingress
                pod-template-hash=1646422561
Annotations:    sidecar.istio.io/inject=false
Status:         Running
IP:             <IP_ADDRESS>
Controlled By:  ReplicaSet/istio-ingress-5b8b8669b5
Containers:
  ingress:
    Container ID:  docker://7c8a3af4db790342f13c290f029d991468430a8571a5d02847f759a6f09a3e4f
    Image:         <IP_ADDRESS>:4000/istio/proxyv2:0.8.0
    Image ID:      docker-pullable://<IP_ADDRESS>:4000/istio/proxyv2@sha256:cb5885e5084b861f56b128993cc5b2d775468fe503758631e2fd421a4a8660d3
    Port:          443/TCP
    Host Port:     0/TCP
    Args:
      proxy
      ingress
      -v
      2
      --discoveryRefreshDelay
      1s
      --drainDuration
      45s
      --parentShutdownDuration
      1m0s
      --connectTimeout
      10s
      --serviceCluster
      istio-ingress
      --zipkinAddress
      zipkin:9411
      --statsdUdpAddress
      istio-statsd-prom-bridge:9125
      --proxyAdminPort
      15000
      --controlPlaneAuthPolicy
      NONE
      --discoveryAddress
      istio-pilot:8080
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    255

@kyessenov It looks like your change #4721 introduced opts map to pass some variables into the envoy template.  But in the template, the expected location of variables are in  struct config.
https://github.com/istio/istio/blob/master/tools/deb/envoy_bootstrap_v2.json#L55
Could you comment if it is expected or it was just missed?

@sbezverk hit the same issue, what's the resolution to this?

@rootfs I think my issue at the  time was wrong version of proxy, after rebuilding everything it started working. Also I run test last Friday on the master and it worked as well.

this is a problem with the envoy.json file we load envoy with when it starts
  "stats_sinks": [
    {
      "name": "envoy.statsd",
      "config": {
        "address": {
          "socket_address": {"address": "istio-statsd-prom-bridge", "port_value": 9125}
        }
      }
    }
  ]

We are assigning a DNS name to a socket address
related Envoy docs:
https://www.envoyproxy.io/docs/envoy/latest/api-v2/config/metrics/v2/stats.proto#envoy-api-msg-config-metrics-v2-statsdsink

Ran into the same issue:
[2018-07-04 19:12:15.502][44][critical][main] external/envoy/source/server/server.cc:77] error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge

It seems like that error causes the ingressgateway and egressgateway to stop. Does anyone know what exactly the problem might be?

Ive come across the same issue as @venilnoronha.

After recreating the Calico CNI everything started resolving. I have a suspicion it was mainly due to missing rbac configuration.

@nixgadget thanks for the information.
Regarding the missing RBAC configuration, is it the istio RBAC that's misconfigured, or something else?

For me i think it was the missing RBAC in Calico CNI.

@nixgadget I see. For me, it's the same with flannel & weave net.

I got the same problem with weave.

nslookup fails to resolve istio-statsd-prom-bridge on that cluster:
root@master-0-ubuntu1604:~/istio-demo# kubectl -n istio-system exec -ti prometheus-9c994b8db-7nmjp -- nslookup istio-statsd-prom-bridge
Server:    <IP_ADDRESS>
Address 1: <IP_ADDRESS>

nslookup: can't resolve 'istio-statsd-prom-bridge'
command terminated with exit code 1

However, on a healthy deployment it appears like so:
root@master-0-ubuntu1604:~# kubectl -n istio-system exec -ti prometheus-9c994b8db-zrdjc -- nslookup istio-statsd-prom-bridge
Server:    <IP_ADDRESS>
Address 1: <IP_ADDRESS> kube-dns.kube-system.svc.cluster.local

Name:      istio-statsd-prom-bridge
Address 1: <IP_ADDRESS> istio-statsd-prom-bridge.istio-system.svc.cluster.local

Same issue.

k8s v1.11.0
istio 0.8.0
flannel v0.9.1 via https://raw.githubusercontent.com/coreos/flannel/v0.9.1/Documentation/kube-flannel.yml

I deployed using the template generated by helm as follows:
helm template install/kubernetes/helm/istio --name istio \
    --namespace istio-system \
    --set sidecarInjectorWebhook.enabled=false \
    --set tracing.enabled=true \
    --set grafana.enabled=true \
    --set servicegraph.enabled=true > istio.yaml

It sounds like the cause of this is outlined in comment https://github.com/istio/istio/issues/5379#issuecomment-399489304 right?
In  pilot/cmd/pilot-agent/main.go it looks like there's some dns-resolution that is attempted (but not sure if this code is even related).
 // resolve statsd address
 if proxyConfig.StatsdUdpAddress != "" {
     addr, err: = proxy.ResolveAddr(proxyConfig.StatsdUdpAddress)
     if err == nil {
             proxyConfig.StatsdUdpAddress = addr
         }
         // If istio-mixer.istio-system can't be resolved, skip generating the statsd config.
         // (instead of crashing). Mixer is optional.
 }

@nabadger that's correct, the cause is the failure in DNS resolution. I found that when using flannel, kube-dns/coredns fail to resolve addresses like kubernetes.default, istio-statsd-prom-bridge, etc. However, on a clean deployment with the weave net plugin (instead of flannel), they resolve correctly. It'd be great if you could verify that on your end too.

@venilnoronha It looks like it's stable with weave 👍

@nabadger thanks for trying it out.
Interestingly, the exact opposite thing happened when I tried reverting flannel and replaced it with weave net.

I have the same issue on istio-1.0.0 on a Azure AKS v1.10.3.
istio-ingressgateway-fc648887c-sddmd        0/1       CrashLoopBackOff
kubectl logs istio-ingressgateway-fc648887c-sddmd -n istio-system :
[2018-08-02 07:56:29.122][69][critical][main] external/envoy/source/server/server.cc:78] error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge
[2018-08-02 07:56:29.122][69][info][main] external/envoy/source/server/server.cc:449] exiting
2018-08-02T07:56:29.124560Z     warn    Epoch 0 terminated with an error: exit status 1
2018-08-02T07:56:29.124579Z     warn    Aborted all epochs
2018-08-02T07:56:29.124606Z     error   Permanent error: budget exhausted trying to fulfill the desired configuration
2018-08-02T07:56:29.124610Z     error   cannot start the proxy with the desired configuration

I also checked the pilot connectivity (https://istio.io/help/ops/misc/#verifying-connectivity-to-istio-pilot) and I got the error : Could not resolve host: istio-pilot
I installed with helm template :
helm template install/kubernetes/helm/istio --name istio --namespace istio-system > $HOME/istio.yaml
kubectl create namespace istio-system
kubectl create -f $HOME/istio.yaml

Any help or lead would be appreciated. Kube-dns works fine, our pods can communicate with each other before the installation of istio.

For comparison, following is the proxy log from the app pod that starts successfully:
2018-08-17T03:23:07.074135Z	info	Version<EMAIL_ADDRESS>2018-08-17T03:23:07.074174Z	info	Proxy role: model.Proxy{ClusterID:"", Type:"sidecar", IPAddress:"<IP_ADDRESS>", ID:"sleep-647cf6648c-bl282.default", Domain:"default.svc.cluster.local", Metadata:map[string]string(nil)}
2018-08-17T03:23:07.074181Z	info	Attempting to lookup address: istio-statsd-prom-bridge.istio-system
2018-08-17T03:23:07.075534Z	info	Addr resolved to: <IP_ADDRESS>:9125
2018-08-17T03:23:07.075548Z	info	Finished lookup of address: istio-statsd-prom-bridge.istio-system
2018-08-17T03:23:07.075885Z	info	Effective config: binaryPath: /usr/local/bin/envoy
configPath: /etc/istio/proxy
connectTimeout: 10s
discoveryAddress: istio-pilot.istio-system:15007
discoveryRefreshDelay: 1s
drainDuration: 45s
parentShutdownDuration: 60s
proxyAdminPort: 15000
serviceCluster: sleep
statsdUdpAddress: <IP_ADDRESS>:9125
zipkinAddress: zipkin.istio-system:9411

2018-08-17T03:23:07.075911Z	info	Monitored certs: []envoy.CertSource{envoy.CertSource{Directory:"/etc/certs/", Files:[]string{"cert-chain.pem", "key.pem", "root-cert.pem"}}}
2018-08-17T03:23:07.076087Z	info	Starting proxy agent
2018-08-17T03:23:07.076160Z	info	Received new config, resetting budget
2018-08-17T03:23:07.076169Z	info	Reconciling configuration (budget 10)
2018-08-17T03:23:07.076179Z	info	Epoch 0 starting
2018-08-17T03:23:07.076726Z	info	Envoy command: [-c /etc/istio/proxy/envoy-rev0.json --restart-epoch 0 --drain-time-s 45 --parent-shutdown-time-s 60 --service-cluster sleep --service-node sidecar~<IP_ADDRESS>~sleep-647cf6648c-bl282.default~default.svc.cluster.local --max-obj-name-len 189 -l debug --v2-config-only]
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:183] initializing epoch 0 (hot restart version=10.200.16384.256.options=capacity=16384, num_slots=8209 hash=228984379728933363 size=4882536)
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:185] statically linked extensions:
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:187]   access_loggers: envoy.file_access_log,envoy.http_grpc_access_log
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:190]   filters.http: envoy.buffer,envoy.cors,envoy.ext_authz,envoy.fault,envoy.filters.http.header_to_metadata,envoy.filters.http.jwt_authn,envoy.filters.http.rbac,envoy.grpc_http1_bridge,envoy.grpc_json_transcoder,envoy.grpc_web,envoy.gzip,envoy.health_check,envoy.http_dynamo_filter,envoy.ip_tagging,envoy.lua,envoy.rate_limit,envoy.router,envoy.squash,istio_authn,jwt-auth,mixer
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:193]   filters.listener: envoy.listener.original_dst,envoy.listener.proxy_protocol,envoy.listener.tls_inspector
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:196]   filters.network: envoy.client_ssl_auth,envoy.echo,envoy.ext_authz,envoy.filters.network.thrift_proxy,envoy.http_connection_manager,envoy.mongo_proxy,envoy.ratelimit,envoy.redis_proxy,envoy.tcp_proxy,mixer
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:198]   stat_sinks: envoy.dog_statsd,envoy.metrics_service,envoy.stat_sinks.hystrix,envoy.statsd
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:200]   tracers: envoy.dynamic.ot,envoy.lightstep,envoy.zipkin
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:203]   transport_sockets.downstream: alts,envoy.transport_sockets.capture,raw_buffer,tls
[2018-08-17 03:23:07.092][16][info][main] external/envoy/source/server/server.cc:206]   transport_sockets.upstream: alts,envoy.transport_sockets.capture,raw_buffer,tls
[2018-08-17 03:23:07.094][16][debug][main] external/envoy/source/server/server.cc:234] admin address: <IP_ADDRESS>:15000
[2018-08-17 03:23:07.094][16][info][config] external/envoy/source/server/configuration_impl.cc:50] loading 0 static secret(s)
[2018-08-17 03:23:07.095][21][debug][grpc] external/envoy/source/common/grpc/google_async_client_impl.cc:39] completionThread running
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/upstream/cluster_manager_impl.cc:707] adding TLS initial cluster xds-grpc
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/upstream/cluster_manager_impl.cc:707] adding TLS initial cluster zipkin
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/upstream/upstream_impl.cc:1039] starting async DNS resolution for istio-pilot.istio-system
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/network/dns_impl.cc:147] Setting DNS resolution timer for 3436 milliseconds
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/upstream/cluster_manager_impl.cc:61] cm init: adding: cluster=xds-grpc primary=1 secondary=0
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/upstream/upstream_impl.cc:1039] starting async DNS resolution for zipkin.istio-system
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/network/dns_impl.cc:147] Setting DNS resolution timer for 3436 milliseconds
[2018-08-17 03:23:07.095][16][debug][upstream] external/envoy/source/common/upstream/cluster_manager_impl.cc:61] cm init: adding: cluster=zipkin primary=2 secondary=0
[2018-08-17 03:23:07.096][16][debug][upstream] external/envoy/source/common/config/grpc_mux_impl.cc:38] Establishing new gRPC bidi stream for rpc StreamAggregatedResources(stream .envoy.api.v2.DiscoveryRequest) returns (stream .envoy.api.v2.DiscoveryResponse);

[2018-08-17 03:23:07.096][16][debug][router] external/envoy/source/common/router/router.cc:253] [C0][S14394058067812381939] cluster 'xds-grpc' match for URL '/envoy.service.discovery.v2.AggregatedDiscoveryService/StreamAggregatedResources'
[2018-08-17 03:23:07.096][16][debug][upstream] external/envoy/source/common/upstream/cluster_manager_impl.cc:989] no healthy host for HTTP connection pool
[2018-08-17 03:23:07.097][16][debug][http] external/envoy/source/common/http/async_client_impl.cc:93] async http request response headers (end_stream=true):
':status', '200'
'content-type', 'application/grpc'
'grpc-status', '14'
'grpc-message', 'no healthy upstream'

[2018-08-17 03:23:07.097][16][warning][upstream] external/envoy/source/common/config/grpc_mux_impl.cc:240] gRPC config stream closed: 14, no healthy upstream
[2018-08-17 03:23:07.097][16][warning][upstream] external/envoy/source/common/config/grpc_mux_impl.cc:41] Unable to establish new stream
[2018-08-17 03:23:07.097][16][info][config] external/envoy/source/server/configuration_impl.cc:60] loading 0 listener(s)
[2018-08-17 03:23:07.097][16][info][config] external/envoy/source/server/configuration_impl.cc:94] loading tracing configuration
[2018-08-17 03:23:07.097][16][info][config] external/envoy/source/server/configuration_impl.cc:103]   loading tracing driver: envoy.zipkin
[2018-08-17 03:23:07.097][16][info][config] external/envoy/source/server/configuration_impl.cc:116] loading stats sink configuration
[2018-08-17 03:23:07.097][16][debug][config] external/envoy/source/extensions/stat_sinks/statsd/config.cc:26] statsd UDP ip address: <IP_ADDRESS>:9125
[2018-08-17 03:23:07.097][16][info][main] external/envoy/source/server/server.cc:410] starting main dispatch loop
...

The successful DNS lookup happens at startup:
2018-08-17T03:23:07.074181Z	info	Attempting to lookup address: istio-statsd-prom-bridge.istio-system
2018-08-17T03:23:07.075534Z	info	Addr resolved to: <IP_ADDRESS>:9125
2018-08-17T03:23:07.075548Z	info	Finished lookup of address: istio-statsd-prom-bridge.istio-system

And this is used when "loading stats sink configuration":
[2018-08-17 03:23:07.097][16][info][config] external/envoy/source/server/configuration_impl.cc:116] loading stats sink configuration
[2018-08-17 03:23:07.097][16][debug][config] external/envoy/source/extensions/stat_sinks/statsd/config.cc:26] statsd UDP ip address: <IP_ADDRESS>:9125

This is most likely a failed DNS resolve issue.
Please run dig or nslookup to query the istio-statsd-prom-bridge.istio-system inside ingress pod if possible(or from a pod running on the same node), and paste output here.
In my case, I got something looked like this:
root@nginx1-rt8w7:/# nslookup istio-statsd-prom-bridge.istio-system
;; reply from unexpected source: <IP_ADDRESS>#53, expected <IP_ADDRESS>#53
;; reply from unexpected source: <IP_ADDRESS>#53, expected <IP_ADDRESS>#53
;; reply from unexpected source: <IP_ADDRESS>#53, expected <IP_ADDRESS>#53
;; reply from unexpected source: <IP_ADDRESS>#53, expected <IP_ADDRESS>#53

This error happens due to incorrect iptables masqurade, after running the following command(from this issue https://github.com/kubernetes/kubernetes/issues/21613#issuecomment-343190401), the problem disappeared:
modprobe br_netfilter

Hope it helps.

I'm hitting this same issue with Kubernetes 1.11.2, CoreDNS 1.2.0, and Istio 1.0.2. I believe it will be fixed in the next release by https://github.com/istio/istio/pull/8256.
It looks like before this change the proxy agent that wraps Envoy attempts to resolve the provided statsd address once at startup. If that one shot resolution failed Envoy would be configured with the hostname rather than an IP, causing it to fail to start due to its invalid configuration. The above PR effectively disables statsd metrics if the oneshot resolution fails.

I got the same problem at istio 1.0.2, and fix it now.  I just forgot to set kubelet parameter "--cluster_dns=<IP_ADDRESS> --cluster-domain=cluster.local".

#8256 removes the need for restarting, but it doesn't resolve why DNS cannot be resolved. Is there an issue with how DNS is resolved within the container?

@ianvernon I've had DNS resolution issues when using the CoreOS Flannel plugin. See coreos/flannel#1017 for more info.

@venilnoronha what's interesting is that this is happening across multiple CNI plugins - indicating that something else is afoot other than CNI. DNS is always fun :)

@ianvernon :D for me it started working once I switched over to Weave.

I have similar issue on RKE baremetal cluster with calico and istio 1.0.2. Gateway running on hostPort. Testing resilience i restarted gateway's host machine, and after it has been brought up, gateway has't booted up with this error.

@miv i am doing the same running IngressGateway as a daemonset with hostPort.
However, I am running Kubernetes 1.12.1 but Istio 1.0.1 maybe I need to upgrade?

I'm having the same exact issue with my statsd configuration:
error initializing configuration '/etc/envoy/envoy.json': malformed IP address: newrelic-statsd.newrelic-infra.svc.cluster.local
I exec'ed into the Envoy container and verified nslookup newrelic-statsd.newrelic-infra.svc.cluster.local resolved to an IP address. This is running on AWS EKS (with CNI). All other clusters in the same config also use kube-dns names, and Envoy can successfully resolve those; so far it seems to be specific to stats_sinks address(es). Any suggestions?

I am running into the same issue
[2019-03-13 14:02:24.334][48][critical][main] external/envoy/source/server/server.cc:78] error initializing configuration '/etc/istio/proxy/envoy-rev0.json': malformed IP address: istio-statsd-prom-bridge
Kubernetes version 1.12.5, istio 1.0.2


Add support for resolving metaclasses

Summary
I mirrored some of the idioms that @AlexWaygood used in the MRO work.
Closes https://github.com/astral-sh/ruff/issues/14096.

(Oops, it looks like I did this prior to pulling and need to resolve some conflicts.)

Looks like there are test failures here, and the error output assertions in the benchmark need to be updated. (I haven't looked closely at the discrepancy; it may just be that we need to update the assertion, or it may highlight an issue with the PR that should be fixed.)

Somewhat confused by the test failures but looking into them. (None of them are in the metaclass tests.)

class NotSubscriptable: ...

a = NotSubscriptable[0]  # error: "Cannot subscript object of type `Literal[NotSubscriptable]` with no `__class_getitem__` method"

We no longer throw this error -- I think because we resolve the metaclass to type, which allows subscripting. That seems wrong to me but I must be misunderstanding something about the semantics.

I think the remaining failures represent a misunderstanding or lack of nuance in how we handle metaclass lookups / __class_getitem__ so would appreciate reviews on that component.

Gonna do a bit more research into how subscripts interact with this.

Okay, the subscript failures were all related to a misunderstanding of literal vs. instance for class types. Fixed.

But I still have one failure in the MRO tests due to a cycle somewhere.

Ok I'm not handling cycles in metaclasses. Will debug.

Ok I'm not handling cycles in metaclasses. Will debug.

You'll probably have to use something like the is_class_cyclically_defined function we currently have in mro.rs. Feel free to move it to another file if you need to!


Shortcut property is not copied by report.Report.Copy method

Shortcut property is not copied by report.Report.Copy method
Method Copy ignores Shortcut property: https://github.com/weaveworks/scope/blob/3de06b5a0963549308bd28a296063ec5c5e963d7/report/report.go#L258
As a result, report is published with Shortcut property always set to false for docker.reporter
It happens because probe.drainAndPublish function makes report copy calling rpt.BackwardCompatible()
https://github.com/weaveworks/scope/blob/7b0f0cb158d3f8e468913ee5658ddbfae933b8b7/probe/probe.go#L203

This does look like a bug indeed. Could you submit a PR with a fix?


replace normalizeCounts by normalizeCounts.internal in celda_C: EM

normalizeCounts.internal  is a wrapper function of "_mvMult" to normalize counts matrix, for internal usage only, as unable to keep the column/row names

Decided to write these functions in Rcpp instead of C to handle colSums at the lower level.


Port deflate_quick to ARM

In #199 @Dead2 wrote:

If only we could port deflate_quick to ARM too.

ARM doesn't have anything similar to the pcmpestri SSE4.2 instruction used by the compare258 function of deflate_quick.  This instruction is a huge part of the performance: it's used to do a miniature strstr-like operation to find matching patterns in the dictionary.

It seems like we could replace compare258 with match_len = longest_match(s, hash_head) if SSE4.2 not supported. If that is the case, perhaps we could extend compare258 to deflate_slow, deflate_medium, etc if SSE4.2 is supposed. What do you think?

compare258 is essentially compare of 256 bytes followed by compare of trailing 2 bytes... Only difference is that for all iterations of the loop, it needs to find the first non-matching index in the vector and calculate length from it... If we assume that it is likely that all lanes are equal most of the time, it should not have performance penalty when the trailing bytes are not equal. Trailing bytes can be handled using uint8_t, uint16_t, uint32_t and uint64_t.

This is now complete.


Make Lua API documentation public

Details
The API documentation should be hosted somewhere so people can play around with it. Preferably we could use elonafoobar.github.io. The documentation can be generated to bin/doc by installing luarocks and ldoc, then running make ldoc.

It seems like the automatic pages creation is limited by three factors. Two of them apply to this repo. (no docs/ in master branch, org name matches repo name)
To publish your site's source files from a /docs folder on your master branch, you must have a master branch and your repository must:

- have a /docs folder in the root of the repository
- not follow the repository naming scheme <username>.github.io or <orgname>.github.io


priority of building

I've noticed that the build system build commits in the order that they were pushed to the pull requests.  It also seems that all commits in a pull request are rebuilt, even if only a new commit is pushed at the end.
If possible, it would be nice to:

First build all 'final' commits, i.e. the ones where currently the TEST builds are performed.
Then single-commit pull requests are not so easily stalled by multi-commit requests.
Prefer to build commits that have most other successfully built commits.
Then code that fails style check and later fast builds will not hold the slower builders.

@inkdot7 Thank you for opening this issue. These are all valid points. Below are my thoughts on each.

Building all the 'final' commits may be doable. When creating a buildbot builder, it is possible to specify a function to choose the next build. Perhaps, that may be worth looking into?
For optimizing which commits get built, we could do require that commits pass the STYLE builder before triggering other. We could create a "fast TEST" builder which can run a subset of the test suite and once that passes, we can then trigger the TEST builders.
For the only building new commits, this is tracked by commit hash if I am not mistaken. I believe github issues a synchronize event via it's webhook. I believe it contains only the commit hashes that changed, but I could be wrong about that.

Would you be interested in attempting to tackle the above?

@dinatale2 Thanks for the quick response.  I looked around in the code a bit:

In class CustomGitHubEventHandler of master/master.cfg, there is commits_cur which gives the part number of a commit.  If adding this to the change dictionary makes it visible(?) to a nextBuild method of class ZFSBuilderConfig in master/buildslaves.py then reordering builds would be easy.  If the value is also set to 0 for commits_cur == commits_num, then it would be straight-forward for nextBuild: choose the first request with the lowest number: final commits gets built before others, and others are built such that the ends of long commit chains have to wait for shorter chains.
I could try to make a patch/pull request.  But it would be untested, as I've no experience setting up a buildbot system.  Useful?

Introducing a fast TEST would make the test builds finish later, which is not so nice.  As those have many builders, I've not felt any problems there.  Also, as the tests sometimes give spurious failures, it would not be nice if that prevents the other tests from running.

  It looks like extra rebuilds of unchanged commits when just one new is added is due to class CustomGitHubEventHandler, which adds all commits as changes when it gets told about a new update.
I do not know if the buildbot system tries to remove duplicate changes, but that may be thwarted by the fact that part %d/%d is added to each change comment, and thus change when more commits are added to a chain.
Otherwise, a global dictionary of commits that have been added as changes would be needed to avoid these rebuilds.  But the re-prioritisation above is probably enough.

There is also some mergeRequests or collapseRequests buildbot functionality.  Perhaps this can be used to remove duplicate builds of the same commit.

I don't think mergeRequests or collapseRequests are what you want. I think you had the right idea with nextBuild. Go ahead and make a pull request for a nextBuild function to do the re-prioritisation as you described. I have a small development environment setup to test proposed changes and can let you know if your proposed change will work or not.
I don't think the global dictionary of commits is a bad idea. I want to determine what information comes from a github synchronization event before we make that change though.

Ok, I think I was probably wrong on the pull request event synchronize action. I think the commit url will always provide the complete list of commits. I'm not opposed to introducing the dictionary to keep track of the hashes. I highly recommend you look into how to limit the amount of memory that dictionary may take up though since the build master is a long living instance.

Pull request is there, but with it written semi-blind, expect the worst...
Regarding duplicates: https://developer.github.com/v3/activity/events/types/#pushevent makes me suspect that there could be an distinct member of each commit, that may be of use.
Otherwise, a dictionary might be more clear in what it does.  One could keep a list of e.g. the 100 last unique commit sha that have been propagated through CustomGitHubEventHandler.  Then it will not grow too large.  With the current turn-around in the buildbots, that should be plenty.  The main purpose is to prevent back-to-back rebuilds when additional fix-up commits are pushed. Each time handle_pull_request is invoked, a local dictionary for quick lookup could be made from the list.


Always wait for the host-only adapter to appear

Sometimes it takes times for a host-only adapter to appear after it's created.
This is specially true the first time such an adapter is created.
Signed-off-by: David Gageot<EMAIL_ADDRESS>

LGTM

LGTM


Do not check ResultSetIndex when ResuilSet is nil.

Pull request type

Please check the type of change your PR introduces:

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, renaming)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] Documentation content changes
[ ] Other (please describe):

What is the current behavior?
query: non-retryable error occurred on attempt No.1 (idempotent=true): set 1: get next row: received part with result set index = 1, current result set index = 0: critical violation of the logic - wrong result set index at `github.com/ydb-platform/ydb-go-sdk/v3/internal/query.(*resultSet).nextRow(result_set.go:149)` at `github.com/ydb-platform/ydb-go-sdk/v3/internal/query.do.func1(client.go:126)` at `github.com/ydb-platform/ydb-go-sdk/v3/internal/query.(*poolStub).With.func2(client.go:83)` at `github.com/ydb-platform/ydb-go-sdk/v3/retry.Retry.func1(retry.go:264)` at `github.com/ydb-platform/ydb-go-sdk/v3/retry.opWithRecover(retry.go:411)` at `github.com/ydb-platform/ydb-go-sdk/v3/retry.RetryWithResult(retry.go:356)` at `github.com/ydb-platform/ydb-go-sdk/v3/retry.Retry(retry.go:270)` at `github.com/ydb-platform/ydb-go-sdk/v3/internal/query.(*poolStub).With(client.go:89)` at `github.com/ydb-platform/ydb-go-sdk/v3/internal/query.do(client.go:134)`

Issue Number: #1310
What is the new behavior?
EOF returned when next part is empty

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 42.92%. Comparing base (42ca696) to head (c811a3e).

Additional details and impacted files
@@            Coverage Diff             @@
##           master    #1312      +/-   ##
==========================================
+ Coverage   41.28%   42.92%   +1.63%
==========================================
  Files         321      258      -63
  Lines       33782    24359    -9423
==========================================
- Hits        13948    10456    -3492
+ Misses      19363    13461    -5902
+ Partials      471      442      -29

Flag
Coverage Δ

go-1.20.x
42.92% <100.00%> (-0.59%)
:arrow_down:

go-1.21.x
?

go-1.22.x
?

macOS
42.92% <100.00%> (+2.10%)
:arrow_up:

ubuntu
?

unit
42.92% <100.00%> (+1.63%)
:arrow_up:

windows
?

Flags with carried forward coverage won't be shown. Click here to find out more.

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


"Failed to get the number of CUDA devices: CUDA driver version is insufficient for CUDA runtime version" on Windows 10

Tensorflow was working on my new Windows 10 for about 24 hours then broke.
Running a Keras lstm_text-generator with a small test txt file, all was well.
After running the same script with a larger 8mb txt file as input data, python encountered an error, system froze, rebooted.
Environment info
Windows 10
Tensorflow 0.12.1
Python 3.5.2
Path includes both:
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\bin
C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\extras\CUPTI\libx64
(as recommended here: https://github.com/tensorflow/tensorflow/issues/6235 and https://github.com/tensorflow/tensorflow/issues/5968 )
cmd
testing>python saveModel_best_only-pima.py Using TensorFlow backend. I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\stream_executor\dso_loader.cc:128] successfully opened CUDA library cublas64_80.dll locally I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\stream_executor\dso_loader.cc:128] successfully opened CUDA library cudnn64_5.dll locally I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\stream_executor\dso_loader.cc:128] successfully opened CUDA library cufft64_80.dll locally I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\stream_executor\dso_loader.cc:128] successfully opened CUDA library nvcuda.dll locally I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\stream_executor\dso_loader.cc:128] successfully opened CUDA library curand64_80.dll locally I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\core\common_runtime\gpu\gpu_device.cc:885] Found device 0 with properties: name: GeForce GTX TITAN X major: 5 minor: 2 memoryClockRate (GHz) 1.076 pciBusID 0000:01:00.0 Total memory: 12.00GiB Free memory: 10.00GiB I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\core\common_runtime\gpu\gpu_device.cc:906] DMA: 0 I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\core\common_runtime\gpu\gpu_device.cc:916] 0:   Y I c:\tf_jenkins\home\workspace\release-win\device\gpu\os\windows\tensorflow\core\common_runtime\gpu\gpu_device.cc:975] Creating TensorFlow device (/gpu:0) -> (device: 0, name: GeForce GTX TITAN X, pci bus id: 0000:01:00.0) Failed to get the number of CUDA devices: CUDA driver version is insufficient for CUDA runtime version Failed to initialize CUDA device #0: CUDA driver version is insufficient for CUDA runtime version Failed to initialize CUDA device #1: CUDA driver version is insufficient for CUDA runtime version ...
"
Directory of C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v8.0\lib
2017-01-31  03:37 PM              .
2017-01-31  03:37 PM              ..
2017-01-31  03:37 PM              Win32
2017-01-31  05:15 PM              x64
What related GitHub issues or StackOverflow threads have you found by searching the web for your problem?
http://stackoverflow.com/questions/3253257/cuda-driver-version-is-insufficient-for-cuda-runtime-version

Issue resolved.
Reinstalled all CUDA CUDNN drivers.


New System Tests

Tasks:

[x] This PR adds the new system tests
[x]  Whenever a PR is updated it runs the system tests
[x]  It builds the go-spacemesh and system tests docker images and pushes to dockerhub
[x]  It runs the tests in a k8s cluster hosted on GCP
[x]  After running the tests it prints the tests results and cleans all pods
[x]  Create separate repo for cluster setup artifacts
[ ]  Create terraform playbook for automation of cluster setup
[x]  Run system tests only when bors try or bors merge is invoked
[ ]  Fail the CI when tests fail (read logs to check if it passed or failed)

@narayanprusty i merged pull request with tests. note that the module is systest (without s on the end).

@dshulyak I have removed artefacts from this repo. I have created a separate repo and added the artifacts there. I will create a terraform playbook which uses grafana/loki-stack in that repo.

@narayanprusty i realized that we should run new ci job only on bors try and bors merge. otherwise, it should be skipped as the rest of the long-running jobs.

bors try

bors try

bors try

bors try

bors try

bors try

bors try

bors try

bors try

bors try

bors try

bors merge

bors merge

bors try


[Proposal]: add a secret to store the builder ssh keys

Right now deis/builder stores/uses the keys in etcd. After #148 there's no place to store the keys.

@aledbf after #148, wouldn't the keys be stored only inside the controller, and accessed via the controller hooks API?

@arschles I mean the ssh keys located in /etc/ssh used in the builder in the ssh session. If we don't add this feature every time the builder is started it will use a different key

Ah, you're talking about host keys here. Missed that, thanks.

I agree. Without this, it'll get really annoying to users when a pod gets restarted.

We'd have to have Helm generate the host keys on the fly, btw, otherwise we'd have a security issue. (Or we could figure out another way to dynamically generate them.)

I think this is ok as long as we continue to run builder with replicas: 1, which IIRC is our working assumption at least for beta.

Also, +1 on using helm generate to generate host keys on the fly. We can also fail to launch builder if keys aren't present in the secret. I think (although I haven't done an audit) that doing so will remove builder's dependency on ssh-keygen, as it currently attempts to generate new keys if none are found in etcd (which they won't ever be after #148)

@arschles @aledbf I think we are calling controller for ssh key validation which are stored in database.
I think we should close this issue

Other option is instead of doing the HTTP ping is to look for the keys in a predefined secret(s) (or discoverable one) that controller writes to

If you git push to the builder, delete the pod, let it restart, and then try the git push again, the push will fail with a host validation error. @helgi are you suggesting that when the builder comes up we populate the host key from a value gotten from the controller? If so, what benefit does that give over a helm generated key?

You are talking about the builder to API auth token, I was referring to the ssh keys. Probably an overkill anyway for now

@helgi nope, talking about the SSH host keys, and suggesting that we store them in the same manner that we store the builder -> API auth token. See discussion above

To be completely clear:

@helgi @smothiki you are talking about deis keys, which is the user's SSH public keys
@arschles and @aledbf are talking about the builder's SSH private keys

The latter is what we need to write out to a secret. I'll tackle this.

@technosophos how does introducing new template functions to helm for generating said private keys sound to you, or does that sound a little extravagant for helm?

I just booted up a builder and copied the base64 encoded SSH keys into the secret hoping we could use that, but it looks like we can't base64 encode the host keys into a secret because the maximum length allowed is 253 characters for a secret, so the idea of introducing a function is shot out of the pond.
Logs from helm install:
The Secret "builder-ssh-private-keys" is invalid.

* data[ssh_host_ecdsa_key]: Invalid value: "ssh_host_ecdsa_key": must have at most 253 characters and match regex \.?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*
* data[ssh_host_ed25519_key]: Invalid value: "ssh_host_ed25519_key": must have at most 253 characters and match regex \.?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*
* data[ssh_host_rsa_key]: Invalid value: "ssh_host_rsa_key": must have at most 253 characters and match regex \.?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*
* data[ssh_host_dsa_key]: Invalid value: "ssh_host_dsa_key": must have at most 253 characters and match regex \.?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*

@bacongobbler the issue is with the key ssh_host_rsa_key should be ssh-host-rsa-key

Dealt with the same thing in https://github.com/deis/controller/blob/master/rootfs/scheduler/init.py#L593

oops, my mistake. Good catch. The error seemed to allude to the value being the issue rather than the key itself. I should've caught that.

https://github.com/deis/builder/blob/master/pkg/sshd/sshd.go#L31 here we are adding three keys ecdsa , rsa, dsa . So if we can generate them as secrets problem solved. Also do we need 3 types of auth keys ?

@smothiki the more the better, so yes. Some users have ecdsa public keys, so we need an ecdsa private key to match for signing.

Easy solution would be asking users to generate what type of key they want ? or default generates all three types of keys

the builder generated all three types of keys. I'm currently just hardcoding a base64-encoded rsa, dsa and ecdsa private key into a secret with the intent to write template functions for helm to generate these keys for us in the future.

That would mean that its the same key for every builder install which arises security issues.
Just by knowing a router IP anyone can access builder. rather generate a secret randomly is the best option

Yes, I'm aware of the issue that it's a security issue. This is just the initial PR, and I am currently working on the templating on helm's end separately. Just splitting them out into different units of work so it's easier to review.

better implement everything at once rather than hardcoding keys. I'm okay if you think the helm generate stuff lands in beta3 which replaces the hardcoded values


Bird2 result not displaying correctly

Deployment Type
Manual
Version
v2.0.4
Steps to Reproduce
Hi,
I'm using Bird 2 with Pathvector,
The UI doesn't display correctly and just shows text, Is this normal?
I was expecting a similar result as the demo which also has an AS-PATH map.
Additionally, Incorrect Inputs just return BIRD 2.0.12 ready. which I think is related to Issue https://github.com/thatmattlove/hyperglass/issues/166
Expected Behavior
BGP Route to <IP_ADDRESS> but returns formated UI and AS-PATH Map.

Observed Behavior
BGP Route to <IP_ADDRESS> but returns text.

Other Errors:

Configuration
No response
Devices
devices:
  - name: London-01
    address: ########
    credential:
      username: ########
      key: ########
    platform: bird
    attrs:
      source4: ########
      source6: ########

Logs
2024-09-17 16:02:28.189 | DEBUG    | hyperglass.models.directive:membership:111 - Checking target membership
2024-09-17 16:02:28.189 | DEBUG    | hyperglass.models.directive:membership:116 - Target membership verified
2024-09-17 16:02:28.190 | DEBUG    | hyperglass.models.directive:in_range:123 - Target is in range
2024-09-17 16:02:28.190 | DEBUG    | hyperglass.models.api.query:validate_query_target:107 - Validation passed
2024-09-17 16:02:28.190 | INFO     | hyperglass.api.routes:query:79 - Starting query execution
2024-09-17 16:02:28.190 | DEBUG    | hyperglass.api.routes:query:87 - Cache hit
2024-09-17 16:02:28.192 | INFO     | hyperglass.api.routes:query:146 - Execution completed
2024-09-17 16:02:28.193 | INFO     | logging:callHandlers:1706 - ######## - "POST /api/query HTTP/1.1" 201

It seems like this feature currently is only for Arista and Juniper : (


Incorrect .return() result on generator with yield* to another generator with try/finally

function i(o) { print(JSON.stringify(o)) }
function* test() {
  try {
    yield 1;
  } finally {
    yield 2;
  }
  yield 3;
}

function* wrap() {
  yield* test();
  yield 4;
}

iter = wrap();
i(iter.next()); // { value: 1, done: false }
i(iter.return(42)); // { value: 2, done: false }
i(iter.next()); // { value: 4, done: false }
i(iter.next()); // { value: undefined, done: true }

Expected is above. However in our implementation we give { value: 2, done: true} for the 2nd result. I believe spec says .return(42) should invoke .return(42) on the inner generator, whose signal is handled by try/finally and yields { done: false, value: 2 }, which is then yielded as-is in step 5.c.viii of yield *.

Reviewing EmitYieldStar I see that we simply do not look for nor call return on the iterator operand.  We call next always, regardless of the way the generator was called into.  So same problem for throw.
This is related to #137 and #510

I fixed this issue while fixing #137 (pr: #597)

Fixed by #665


DOC: Change the Insight Journal handle links to insight-journal links

DOC: Change the Insight Journal handle links to insight-journal links
DOC: Make insight-journal links consistent: add www to URL

PR Checklist

[X] No API changes were made (or the changes have been approved)
[X] No major design changes were made (or the changes have been approved)

The cross-references should probably be changed to the corresponding DOIs, but that it left as future work: with some work, a script that reads the insight-journal occurrences, retrieves the DOIs from the corresponding JSON metadata files in the IJ repository/website would probably make the trick automatically.

/azp run ITK.Linux