Should utf8EncodedLen be a global variable?

In my generated js, I see the following function and variable,
let utf8EncodedLen = 0;
function utf8Encode(s, realloc, memory) {
  if (typeof s !== 'string') throw new TypeError('expected a string');
  if (s.length === 0) {
    utf8EncodedLen = 0;
    return 1;
  }
  let allocLen = 0;
  let ptr = 0;
  let writtenTotal = 0;
  while (s.length > 0) {
    ptr = realloc(ptr, allocLen, 1, allocLen + s.length);
    allocLen += s.length;
    const { read, written } = utf8Encoder.encodeInto(
    s,
    new Uint8Array(memory.buffer, ptr + writtenTotal, allocLen - writtenTotal),
    );
    writtenTotal += written;
    s = s.slice(read);
  }
  if (allocLen > writtenTotal)
  ptr = realloc(ptr, allocLen, 1, writtenTotal);
  utf8EncodedLen = writtenTotal;
  return ptr;
}

used as follows
 const ptr1 = utf8Encode(v0_0, realloc1, memory0);
    const len1 = utf8EncodedLen;
    const ptr2 = utf8Encode(v0_1, realloc1, memory0);
    const len2 = utf8EncodedLen;
    const {logRoot: v3_0, logLength: v3_1, mapRoot: v3_2 } = arg1;
    const ptr4 = utf8Encode(v3_0, realloc1, memory0);
    const len4 = utf8EncodedLen;
    const ptr5 = utf8Encode(v3_2, realloc1, memory0);
    const len5 = utf8EncodedLen;
    exports1['protocol#prove-inclusion'](ptr1, len1, ptr2, len2, ptr4, len4, toUint32(v3_1), ptr5, len5);

When using this in practice all length vars match the length of the most recently encoded string, I believe because utf8EncodedLen is a global var.
I believe the issue would be alleviated if utf8Encode were to return an object with a pointer and a length field, and the global variable were eliminated, though perhaps I'm missing something that makes the global variable make more sense?  Happy to try and open a PR if others think this would be a good change.

fwiw by changing my bindings to use this
function myEncode(s, realloc, memory) {
  let encodedLen
  if (typeof s !== 'string') throw new TypeError('expected a string');
  if (s.length === 0) {
    encodedLen = 0;
    return 1;
  }
  let allocLen = 0;
  let ptr = 0;
  let writtenTotal = 0;
  while (s.length > 0) {
    ptr = realloc(ptr, allocLen, 1, allocLen + s.length);
    allocLen += s.length;
    const { read, written } = utf8Encoder.encodeInto(
    s,
    new Uint8Array(memory.buffer, ptr + writtenTotal, allocLen - writtenTotal),
    );
    writtenTotal += written;
    s = s.slice(read);
  }
  if (allocLen > writtenTotal)
  ptr = realloc(ptr, allocLen, 1, writtenTotal);
  encodedLen = writtenTotal;
  return {ptr, encodedLen};
}

instead of utf8Encode and replacing the above usage with
const var1 = myEncode(v0_0, realloc1, memory0);
const var2 = myEncode(v0_1, realloc1, memory0);
const {logRoot: v3_0, logLength: v3_1, mapRoot: v3_2 } = arg1;
const var4 = myEncode(v3_0, realloc1, memory0);
const var5 = myEncode(v3_2, realloc1, memory0);
exports1['protocol#prove-inclusion'](var1.ptr, var1.encodedLen, var2.ptr, var2.encodedLen, var4.ptr, var4.encodedLen, toUint32(v3_1), var5.ptr, var5.encodedLen);

I was able to resolve my bugs

It looks like what you say is true and the global value is used to return part of the result, but I'm not clear what part of that is the "bug". Is there some sort of reentrancy, concurrency, parallelism type issue you hit with this approach or is it more that you would prefer it to return an object?

Ah sorry I guess I was a little unclear on that.  As things are, the lengths of the different variables are incorrect when I pass them to my guest code.  The bytes are written to memory properly, but the first value will contain bytes from the second variable in my case, due to having a length associated with the most recent value of utf8EncodedLength, rather than the value from from when utf8Encode was originally called.  I'd guess that one could also produce cases where the length is too short, and guest input variables end up missing bytes of data in their value, even though the bytes were written to memory properly.

Is this mismatch between values in utf8EncodedLength when utf8Encode was initially called vs. when the value is needed something that happens in generated code or in your calling code? If it's in your calling code, then I would expect you can store the values as an object together yourself without needing a jco change and if it's in generator code then we should probably fix that code.

It's in the generated code.  Actually, in the current code I'm working with, the exposed guest function takes three args, the first of which is a struct with two string fields, the issue is happening in the fields.  The first field is getting the first handful of characters from the second field appended to the end, because the generated code communicates the wrong length of the first field from what I can tell.  So it's happening even though a single object argument containing two strings is passed to it, from what I can tell.

@macovedj can you share a simple example of the case here? Sounds like a bug we need to fix to me.

I'll try and generate some logs that show the appended bytes

Having a little bit of trouble logging the actual bytes this time around, but you can see that the lengths being passed are both `71`, where I'm logging the lengths that are actually fed to the guest bindings in my rust code,  However the strings have different lengths on the host side, and I believe 71 is the length of the final string that gets encoded that is passed from host to guest.

Managed to log the bytes... and what the strings look like on the host.  You can see that the first bytes of the second string are appended to the end of the first string on the guest side, because the guest thinks the first string is longer than it should be

@macovedj it's hard to speculate without having a full end to end example here, because there could be a number of reasons for this.
If you'd like to add some logging, I'd suggest adding console.log(utf8EncodedLen) at each point at which an assignment occurs, and comparing that to your own implementation. I'd be very surprised if you truly are seeing different numbers. Execution in JavaScript is very much deterministic (thankfully, the language isn't that bad :P), so that the utf8EncodedLen global variable should always take the correct value when used immediately after the last call. And because numbers are assigned by copy in JavaScript, the len1 and len2 values should be copies of the length at that point in time in the execution.
So there must be some other factor going on here (or a browser bug..!). Which environment are you testing on? Again if you can share a direct replicable example I can run I can happily investigate further. If I clone the repo, how would I set up the web server to get the bad output?

Another thing to check - in your build process output, are you running the script as a global somehow so that window.utf8EncodedLen is a number?

So you should be able to just clone this repo, then do npm i followed by npm run preview, and click the update button in order to reproduce.  There's some caching of some web/service worker stuff going on, so I'd maybe use an incognito window.  The protocol folder in components contains the jco generated javascript.  If you want to dig into the wasm, you can rebuild the wasm component by running cargo component build in the protocol-wasm folder in  this branch of this repo.  Traveling to Europe from Texas for CNCF today, but I intend to spend some time thinking about this some more coming up.

So you should be able to just clone this repo, then do npm i followed by npm run preview, and click the update button in order to reproduce. There's some caching of some web/service worker stuff going on, so I'd maybe use an incognito window. The protocol folder in components contains the jco generated javascript. If you want to dig into the wasm, you can rebuild the wasm component by running cargo component build in the protocol-wasm folder in this branch of this repo. Traveling to Europe from Texas for CNCF today, but I intend to spend some time thinking about this some more soon.

Actually, you'll also need to run the warg server, which you can do by running the setup-server.sh script in the registry repo, and then use the cli to publish a package.  I'll try and move that logic into one repo, to make it easier to reproduce when I can.

@macovedj thanks, I took a look and here's the generated code for that same section you mentioned before:
D || re();
        const {a: r, b: l} = e
          , o = h(r, E, i)
          , s = h(l, E, i);
        A["foo#hello-world"](o, p, s, p)

In the above, h is the utf8Encode function and p is the global utf8EncodedLen value.
As you can see, the JS optimization code as replaced the intermediate len1 and len2 with a direct inlining at the function call location.
This is therefore a bug with the quik optimizer in that it is assuming that the assignment can be inlined when it cannot due to it being a multi-assigned variable.
We could potentially alter our output - but the quik optimizer will have other bugs from this optimization issue, so it's probably worth reporting there. Let me know if I can help with creating that issue at all, and feel free to copy me in.

@guybedford Ah wow thanks for looking into it.  Makes sense.  Will try and put some thought into an issue soon, and keep you in the loop.

I wonder if we could wrap utf8EncodedLen with a function that returns the global so that optimizers treat it more opaquely as a function which might have side causes and side effects.

This issue has now been resolved in the Quik optimizer. This isn't a normal JS build bug by any means - most JS build tools would support this fine. So I'm confident we can mark this as resolved for the next Quik release and that will be the end of it.


When there are no pull requests, display a message

Otherwise, there is no menu and the user doesn't know what to do.

This now displays a message and prompts the user to enter a closed or merged pull request number.


Use tracing instead of println everywhere

I'll probably throw together a PR for this this weekend.

Good point, I've been meaning to switch to proper logging. That would be great, thank you. 👍


annotations / tolerations / nodeSelector support in helm charts

For easier integration into differing environments, it'd be great if these parts of the pod template spec for individual deployments were customisable!
It's possible to work around this with anything that can patch post-helm-rendered yamls, like:

kustomize
kustomize as used by helmfile's strategicMergePatches key
kustomize as used by helm 3's new post-renderer support

@SohumB Thanks for reporting this.
Makes perfect sense, we'll add it shortly


Issues met when training DAGAN for new dataset

Hi, I am trying to train the DAGAN for a new dataset, which has been transformed into the standard numpy format [10, 28, 64, 64, 3] (10 people and 28 pictures for each)
I think this dataset is small enough. However, after I trained the model for over 200 epochs the loss of generator never converge. And images generated are not as expected. In the generated 16 by 16 images result, except for original images on the left top, all other images are the same, as shown below. I think the network didn't converge.

And this is the loss I got.

Could you please give me some suggestion/tricks on training the model? I will really appreciate!

Well, faces are very hard to model. Your main issue here is the fact that
you are using too small a dataset I think. Try increasing the number of
samples or give me some time to look into it. Furthermore, perhaps try
using a smaller discriminator and generator.
On Thu, 12 Apr 2018, 08:24 SUYENus<EMAIL_ADDRESS>wrote:

Hi, I am trying to train the DAGAN for a new dataset, which has been
transformed into the standard numpy format [10, 28, 64, 64, 3] (10 people
and 28 pictures for each)
I think this dataset is small enough. However, after I trained the model
for over 200 epochs the loss of generator never converge. And images
generated are not as expected. In the generated 16 by 16 images result,
except for original images on the left top, all other images are the same,
as shown below. I think the network didn't converge.
[image: image]
https://user-images.githubusercontent.com/35247113/38659647-fc2b9e1e-3e5c-11e8-96ae-68bbd235cb58.png
And this is the loss I got.
[image: image]
https://user-images.githubusercontent.com/35247113/38659687-19b5d9fe-3e5d-11e8-8fde-3da92f5125a6.png
Could you please give me some suggestion/tricks on training the model? I
will really appreciate!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/AntreasAntoniou/DAGAN/issues/2, or mute the thread
https://github.com/notifications/unsubscribe-auth/AKSuNtABjYqs_51jtGSs8i8qDWCb_61Nks5tnvMTgaJpZM4TRNKP
.

Hi Antreas Antonious, thanks a lot for your quick reply. Since I don't have much GPU and I thought it would easier to train on small datasets. I will try increasing samples and see if it would work better. Could you please give me a basic sense of how long does it need to train the model?(with the information of samples size and GPU number you have used) I have looked in to your paper but it seems that you didn't mention that.

Could any please help me? Still struggling with the issue of generating only one type of face.

When I trained the network I did about 50*4000 iters before the faces
converged. How many epochs and iters per epoch are you doing?
On Sat, 14 Apr 2018, 02:45 SUYENus<EMAIL_ADDRESS>wrote:

Could any please help me? Still struggling with the issue of generating
only one type of face.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AntreasAntoniou/DAGAN/issues/2#issuecomment-381295201,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKSuNjvMfab4VO0KZuQSGeYisvKfl8fOks5toVTVgaJpZM4TRNKP
.

Hi Antreas Antonious, thanks a lot for your reply.
Since my dataset is small, I have been training with 200 epochs * 9 iterations. (each iteration means 5 iterations for discriminator and 1 for generator.) It's indeed small amount of training. But what's really confusing me is the trend that all pictures generated are all the same face. Could you help me with it? Is it due to a small dataset? Should I use other z-dimension?

Your results look like how the DAGAN generated things after 14000 iters in
my eyes, experiments. It begins varying the faces after 54000 iters and
produces photorealistic results after 30*4000. I think your problem is both
the small amount of data and iters. However with enough iters even a small
amount of data should produce some low quality results of varying faces but
with poor generalization performance on unseen faces.
On Sat, 14 Apr 2018, 15:59 SUYENus<EMAIL_ADDRESS>wrote:

Hi Antreas Antonious, thanks a lot for your reply.
Since my dataset is small, I have been training with 200 epochs * 9
iterations. (each iteration means 5 iterations for discriminator and 1 for
generator.) It's indeed small amount of training. But what's really
confusing me is the trend that all pictures generated are all the same
face. Could you help me with it? Is it due to a small dataset? Should I use
other z-dimension?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AntreasAntoniou/DAGAN/issues/2#issuecomment-381334937,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKSuNoDQJEO9gE4vPAsfEcJzsfpx2-Rlks5tog7QgaJpZM4TRNKP
.

Thanks a lot Antreas!  I have increased the iterations to 200 per epoch and it finally starts to generate some variations. I hope it will work finally. I really appreciate your help.

Hi Antreas Antoniou,  I have been training the model and results are getting better and better. However, the loss curves are a bit confusing to me. (shown as following) I cannot understand why both the loss of discriminator and generator are diverging but results are getting better. Could you please help me to understand the loss curve, or tell me the loss function you have used for discriminator and generator? It could save a lot of time rather than fully digging into your codes... THANK YOU.  (the order of loss curves from top to bottom are d_loss_fake, d_loss_real, d_losses, g_losses

I am using Wasserstein loss with Gradient Penalty. The important loss that
correlates with sample quality is d_loss. The smaller it gets the better
the sample quality becomes, approximately. The g_loss getting bigger is
also explained in the Wasserstein with GP paper. It basically means that it
becoming harder and harder to fool the discriminator.
On Tue, 17 Apr 2018, 06:52 Su Ye<EMAIL_ADDRESS>wrote:

Hi Antreas Antoniou, I have been training the model and results are
getting better and better. However, the loss curves are a bit confusing to
me. (shown as following) I cannot understand why both the loss of
discriminator and generator are diverging but results are getting better.
Could you please help me to understand the loss curve, or tell me the loss
function you have used for discriminator and generator? It could save a lot
of time rather than fully digging into your codes... THANK YOU. (the order
of loss curves from top to bottom are d_loss_fake, d_loss_real, d_losses,
g_losses
[image: image]
https://user-images.githubusercontent.com/35247113/38850886-f71d3986-4245-11e8-870a-cb4930e1c8fc.png
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AntreasAntoniou/DAGAN/issues/2#issuecomment-381853544,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKSuNjfQuSd-RAjjWXFh8wUWxksTwT1Zks5tpYMwgaJpZM4TRNKP
.

Antreas thanks a lot for your explanation! Do you know what't happening when there is a steep change (the peak) in the middle of loss curve? It looks like suddenly the discriminator found out a way to discriminate fake images... It's quite interesting.

If you have more data just like in my experiments what you will observe is:
D loss starts positive goes negative and keeps becoming more and more
negative. At some point it stops and then begins moving back towards 0.
That's when the model converges. Initially it is still learning thus with
every step becoming stronger and thus predicting a larger magnitude
distance between real and fake.
On Tue, 17 Apr 2018, 15:23 Su Ye<EMAIL_ADDRESS>wrote:

Besides, regarding your saying
"The important loss that correlates with sample quality is d_loss. The
smaller it gets the better the sample quality becomes, approximately. "
In the loss curve that I have showed you, the d_loss is negative value and
going more negative. What do you mean by d_loss getting smaller? Getting
close to zero or getting close to negative infinity?
I have just looked though their paper and I saw the tiny experiments they
took on LSUN, the d_loss of which is positive value. However, the d_loss I
got is negative. Do you know why this happen? Is it because of you change
the setting during implementation or there is sth wrong in my training?
Could I conclude that this loss diverges because of limited data just as
said in their paper?
I really appreciate your help.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AntreasAntoniou/DAGAN/issues/2#issuecomment-382010934,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKSuNux7EnWUDDMhiko7XS7h9LZjKdQsks5tpfrTgaJpZM4TRNKP
.

Oh maybe I should increase the size of discriminator? It seems that in my training the discriminator totally lose the game.

Just pass arguments - - gen 2 and - - disc 5 to replicate my setup
On Tue, 17 Apr 2018, 16:16 Su Ye<EMAIL_ADDRESS>wrote:

Oh maybe I should increase the size of discriminator? It seems that in my
training the discriminator totally lose the game.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/AntreasAntoniou/DAGAN/issues/2#issuecomment-382030658,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKSuNmADz1vOxohu_DCAssnQtoqAISCoks5tpgc-gaJpZM4TRNKP
.

Great! Thanks a lot.

Hi，May I ask how you make your own npy data set?


Render DV regression reports from Markdown to HTML inline in hardware block docs

As title, probably need to use a JS markdown renderer.
@sriyerg @weicaiyang

This seems to be implemented now, so I am closing this issue.
Please reopen if this is not the case.

I think this refers to adding a shortcode in the docs.opentitan.org area itself such that all regression results are directly expanded in there, rather than a separate reports.opentitan.org area.

Apologies if I closed this prematurely - I understood that the mechanism for rendering inline snippets has been implemented, but we're not using it currently since we have settled on a different solution (publishing directly to reports.opentitan.org).
Do we still have plans to move the regression results into the docs? If so, let's reopen this issue.


Support Windows line endings in the bag verifier

For https://github.com/wellcomecollection/storage-service/issues/894
Previously we had an overly strict regex for matching the Bag Declaration (bagit.txt):
private val declaration = new Regex(
  "BagIt-Version: \\d\\.\\d+\nTag-File-Character-Encoding: UTF-8\n?"
)

Now we defer to Scala to split lines in bagit.txt for us (String.lines), so we don't have to worry about supporting different line endings.  This means we get support for Windows line endings for "free".
This approach also means we can provide slightly better error messages when we don't accept the Bag Declaration as supplied, e.g. "encoding must be UTF-8" or "not correctly formatted".
Once this patch is merged, I'll try a Windows bag in the staging environment and see if anything else breaks; if not, I'll close the ticket.

Quick guide to the files in this PR for anybody who's not worked on the storage service before:

BagBuilder creates example bags that we can use for testing.

Each of the classes in bag_verifier/verify/steps checks a particular part of the bag, and we have detailed tests for that particular check

The BagVerifier is a trait that comes in multiple implementations (a standalone bag in S3, a replicated bag in S3, a replicated bag in Azure), and BagVerifierTestCases contains a set of generic test cases that should apply to every implementation. We then have one implementation of the TestCases for each implementation of the core trait, so every test case is run against every implementation.
This is a pretty common pattern in our codebase: a base trait, a TestCases trait, and one test implementation for every implementation of the trait.


Tempfix for injection issue on canary

Thanks to a tempfix I found from Zerebos

Applied the changes to the beta branch from #101 via fd82c1a.


redeploy kubernetes engine

redeploy kubernetes engine

Ran Plan for 2 projects:

dir: infrastructure/gcp/cloud-deployment/gcompute-engine-bastion workspace: default
dir: infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols workspace: default

1. dir: infrastructure/gcp/cloud-deployment/gcompute-engine-bastion workspace: default
Plan Error
Show Output
running "/usr/bin/terraform plan -input=false -refresh -out \"/home/atlantis/.atlantis/repos/greyhats13/ol_shop/12/default/infrastructure/gcp/cloud-deployment/gcompute-engine-bastion/default.tfplan\"" in "/home/atlantis/.atlantis/repos/greyhats13/ol_shop/12/default/infrastructure/gcp/cloud-deployment/gcompute-engine-bastion": exit status 1
data.terraform_remote_state.vpc_ols_network: Reading...
data.terraform_remote_state.gcloud_dns_ols: Reading...
data.terraform_remote_state.gkubernetes_engine_ols: Reading...
data.terraform_remote_state.vpc_ols_network: Read complete after 0s
data.terraform_remote_state.gkubernetes_engine_ols: Read complete after 0s
data.google_project.current: Reading...
data.terraform_remote_state.gcloud_dns_ols: Read complete after 0s
data.google_project.current: Read complete after 2s [id=projects/onlineshop-378118]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create

Terraform planned the following actions, but then encountered a problem:

  # module.gcompute-engine.google_compute_firewall.firewall["ssh"] will be created
  + resource "google_compute_firewall" "firewall" {
      + creation_timestamp = (known after apply)
      + destination_ranges = (known after apply)
      + direction          = (known after apply)
      + enable_logging     = (known after apply)
      + id                 = (known after apply)
      + name               = "ols-dev-gce-bastion-allow-ssh"
      + network            = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/global/networks/ols-dev-vpc-network"
      + priority           = 1000
      + project            = (known after apply)
      + self_link          = (known after apply)
      + source_ranges      = [
          + "<IP_ADDRESS>/0",
        ]
      + target_tags        = [
          + "bastion",
        ]

      + allow {
          + ports    = [
              + "22",
            ]
          + protocol = "tcp"
        }
    }

  # module.gcompute-engine.google_compute_instance.instance will be created
  + resource "google_compute_instance" "instance" {
      + can_ip_forward       = false
      + cpu_platform         = (known after apply)
      + current_status       = (known after apply)
      + deletion_protection  = false
      + guest_accelerator    = (known after apply)
      + id                   = (known after apply)
      + instance_id          = (known after apply)
      + label_fingerprint    = (known after apply)
      + machine_type         = "e2-medium"
      + metadata             = (known after apply)
      + metadata_fingerprint = (known after apply)
      + min_cpu_platform     = (known after apply)
      + name                 = "ols-dev-gce-bastion"
      + project              = (known after apply)
      + self_link            = (known after apply)
      + tags                 = [
          + "bastion",
        ]
      + tags_fingerprint     = (known after apply)
      + zone                 = "asia-southeast2-a"

      + boot_disk {
          + auto_delete                = true
          + device_name                = (known after apply)
          + disk_encryption_key_sha256 = (known after apply)
          + kms_key_self_link          = (known after apply)
          + mode                       = "READ_WRITE"
          + source                     = (known after apply)

          + initialize_params {
              + image  = "debian-cloud/debian-11"
              + labels = (known after apply)
              + size   = 20
              + type   = "pd-standard"
            }
        }

      + network_interface {
          + ipv6_access_type   = (known after apply)
          + name               = (known after apply)
          + network            = (known after apply)
          + network_ip         = (known after apply)
          + stack_type         = (known after apply)
          + subnetwork         = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/regions/asia-southeast2/subnetworks/ols-dev-vpc-subnet-asia-southeast2"
          + subnetwork_project = (known after apply)

          + access_config {
              + nat_ip       = (known after apply)
              + network_tier = "STANDARD"
            }
        }

      + service_account {
          + email  = (known after apply)
          + scopes = [
              + "https://www.googleapis.com/auth/cloud-platform",
            ]
        }
    }

  # module.gcompute-engine.google_dns_record_set.record[0] will be created
  + resource "google_dns_record_set" "record" {
      + id           = (known after apply)
      + managed_zone = "ols-dev-gcloud-dns-blast-ols-blast"
      + name         = "bastion.ols.blast.co.id."
      + project      = (known after apply)
      + rrdatas      = (known after apply)
      + ttl          = 300
      + type         = "A"
    }

  # module.gcompute-engine.google_project_iam_member.sa_iam will be created
  + resource "google_project_iam_member" "sa_iam" {
      + etag    = (known after apply)
      + id      = (known after apply)
      + member  = (known after apply)
      + project = "onlineshop-378118"
      + role    = "roles/viewer"
    }

  # module.gcompute-engine.google_service_account.sa will be created
  + resource "google_service_account" "sa" {
      + account_id   = "ols-dev-gce-bastion"
      + disabled     = false
      + display_name = "Service Account for ols-dev-gce-bastion instance"
      + email        = (known after apply)
      + id           = (known after apply)
      + member       = (known after apply)
      + name         = (known after apply)
      + project      = (known after apply)
      + unique_id    = (known after apply)
    }

  # module.gcompute-engine.local_file.private_key will be created
  + resource "local_file" "private_key" {
      + content              = (sensitive value)
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0700"
      + file_permission      = "0400"
      + filename             = "id_rsa.pem"
      + id                   = (known after apply)
    }

  # module.gcompute-engine.tls_private_key.tls will be created
  + resource "tls_private_key" "tls" {
      + algorithm                     = "RSA"
      + ecdsa_curve                   = "P224"
      + id                            = (known after apply)
      + private_key_openssh           = (sensitive value)
      + private_key_pem               = (sensitive value)
      + private_key_pem_pkcs8         = (sensitive value)
      + public_key_fingerprint_md5    = (known after apply)
      + public_key_fingerprint_sha256 = (known after apply)
      + public_key_openssh            = (known after apply)
      + public_key_pem                = (known after apply)
      + rsa_bits                      = 2048
    }

Plan: 7 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + private_ip = (known after apply)
  + public_ip  = (known after apply)
╷
│ Error: Unsupported attribute
│
│   on main.tf line 91, in module "gcompute-engine":
│   91:     cluster_name          = data.terraform_remote_state.gkubernetes_engine_ols.outputs.cluster_name
│     ├────────────────
│     │ data.terraform_remote_state.gkubernetes_engine_ols.outputs is object with no attributes
│
│ This object does not have an attribute named "cluster_name".
╵

2. dir: infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols workspace: default
Show Output
data.terraform_remote_state.vpc_ols_network: Reading...
data.terraform_remote_state.vpc_ols_network: Read complete after 0s
data.google_service_account.gcompute_engine_default_service_account: Reading...
data.google_service_account.gcompute_engine_default_service_account: Read complete after 2s

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

  # module.gkubernetes_engine.google_container_cluster.cluster will be created
+ resource "google_container_cluster" "cluster" {
      + cluster_ipv4_cidr           = (known after apply)
      + datapath_provider           = (known after apply)
      + default_max_pods_per_node   = (known after apply)
      + enable_binary_authorization = false
      + enable_intranode_visibility = (known after apply)
      + enable_kubernetes_alpha     = false
      + enable_l4_ilb_subsetting    = false
      + enable_legacy_abac          = false
      + enable_shielded_nodes       = true
      + endpoint                    = (known after apply)
      + id                          = (known after apply)
      + initial_node_count          = 1
      + label_fingerprint           = (known after apply)
      + location                    = "asia-southeast2-a"
      + logging_service             = (known after apply)
      + master_version              = (known after apply)
      + monitoring_service          = (known after apply)
      + name                        = "ols-dev-gkubernetes-engine-cluster"
      + network                     = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/global/networks/ols-dev-vpc-network"
      + networking_mode             = (known after apply)
      + node_locations              = (known after apply)
      + node_version                = (known after apply)
      + operation                   = (known after apply)
      + private_ipv6_google_access  = (known after apply)
      + project                     = (known after apply)
      + remove_default_node_pool    = true
      + resource_labels             = {
          + "business_unit" = "ols"
          + "code"          = "gkubernetes-engine"
          + "environment"   = "dev"
          + "feature"       = "cluster"
        }
      + self_link                   = (known after apply)
      + services_ipv4_cidr          = (known after apply)
      + subnetwork                  = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/regions/asia-southeast2/subnetworks/ols-dev-vpc-subnet-asia-southeast2"
      + tpu_ipv4_cidr_block         = (known after apply)

      + binary_authorization {
          + evaluation_mode = "PROJECT_SINGLETON_POLICY_ENFORCE"
        }

      + cluster_autoscaling {
          + enabled = false

          + resource_limits {
              + maximum       = 8
              + minimum       = 2
              + resource_type = "cpu"
            }
          + resource_limits {
              + maximum       = 32
              + minimum       = 4
              + resource_type = "memory"
            }
        }

      + dns_config {
          + cluster_dns        = "CLOUD_DNS"
          + cluster_dns_domain = "blast.local"
          + cluster_dns_scope  = "VPC_SCOPE"
        }

      + ip_allocation_policy {
          + cluster_ipv4_cidr_block       = (known after apply)
          + cluster_secondary_range_name  = "pods-range"
          + services_ipv4_cidr_block      = (known after apply)
          + services_secondary_range_name = "services-range"
          + stack_type                    = "IPV4"
        }

      + master_auth {
          + client_certificate     = (known after apply)
          + client_key             = (sensitive value)
          + cluster_ca_certificate = (known after apply)

          + client_certificate_config {
              + issue_client_certificate = true
            }
        }

      + master_authorized_networks_config {
          + gcp_public_cidrs_access_enabled = false

          + cidr_blocks {
              + cidr_block   = "<IP_ADDRESS>/28"
              + display_name = "my-home-public-ip"
            }
        }

      + network_policy {
          + enabled  = true
          + provider = "CALICO"
        }

      + private_cluster_config {
          + enable_private_nodes   = true
          + master_ipv4_cidr_block = "<IP_ADDRESS>/28"
          + peering_name           = (known after apply)
          + private_endpoint       = (known after apply)
          + public_endpoint        = (known after apply)
        }
    }

  # module.gkubernetes_engine.google_container_node_pool.nodepool["spot"] will be created
+ resource "google_container_node_pool" "nodepool" {
      + cluster                     = "ols-dev-gkubernetes-engine-cluster"
      + id                          = (known after apply)
      + initial_node_count          = (known after apply)
      + instance_group_urls         = (known after apply)
      + location                    = "asia-southeast2-a"
      + managed_instance_group_urls = (known after apply)
      + max_pods_per_node           = (known after apply)
      + name                        = "spot"
      + name_prefix                 = (known after apply)
      + node_count                  = 2
      + node_locations              = (known after apply)
      + operation                   = (known after apply)
      + project                     = (known after apply)
      + version                     = (known after apply)

      + autoscaling {
          + location_policy = "BALANCED"
          + max_node_count  = 20
          + min_node_count  = 2
        }

      + node_config {
          + disk_size_gb      = 20
          + disk_type         = "pd-standard"
          + guest_accelerator = (known after apply)
          + image_type        = (known after apply)
          + labels            = {
              + "business_unit" = "ols"
              + "code"          = "gkubernetes-engine"
              + "environment"   = "dev"
              + "feature"       = "cluster"
              + "name"          = "ols-dev-gkubernetes-engine-cluster-nodepool-spot"
              + "type"          = "spot"
            }
          + local_ssd_count   = (known after apply)
          + logging_variant   = "DEFAULT"
          + machine_type      = "e2-medium"
          + metadata          = (known after apply)
          + min_cpu_platform  = (known after apply)
          + oauth_scopes      = [
              + "https://www.googleapis.com/auth/cloud-platform",
            ]
          + preemptible       = false
          + service_account   = (known after apply)
          + spot              = false
          + tags              = [
              + "spot",
            ]
          + taint             = (known after apply)

          + shielded_instance_config {
              + enable_integrity_monitoring = false
              + enable_secure_boot          = true
            }
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:
+ cluster_ca_certificate     = (known after apply)
+ cluster_client_certificate = (known after apply)
+ cluster_client_key         = (sensitive value)
+ cluster_endpoint           = (known after apply)
+ cluster_id                 = (known after apply)
+ cluster_location           = "asia-southeast2-a"
+ cluster_master_version     = (known after apply)
+ cluster_name               = "ols-dev-gkubernetes-engine-cluster"
+ cluster_self_link          = (known after apply)

:arrow_forward: To apply this plan, comment:

atlantis apply -d infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols

Plan: 2 to add, 0 to change, 0 to destroy.

:fast_forward: To apply all unapplied plans from this pull request, comment:

atlantis apply

:put_litter_in_its_place: To delete all plans and locks for the PR, comment:

atlantis unlock

atlantis apply

Ran Apply for 2 projects:

dir: infrastructure/gcp/cloud-deployment/gcompute-engine-bastion workspace: default
dir: infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols workspace: default

1. dir: infrastructure/gcp/cloud-deployment/gcompute-engine-bastion workspace: default
Apply Error
running "/usr/bin/terraform apply -input=false \"/home/atlantis/.atlantis/repos/greyhats13/ol_shop/12/default/infrastructure/gcp/cloud-deployment/gcompute-engine-bastion/default.tfplan\"" in "/home/atlantis/.atlantis/repos/greyhats13/ol_shop/12/default/infrastructure/gcp/cloud-deployment/gcompute-engine-bastion": exit status 1
╷
│ Error: Cannot apply incomplete plan
│
│ Terraform encountered an error when generating this plan, so it cannot be
│ applied.
╵

2. dir: infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols workspace: default
Apply Error
Show Output
running "/usr/bin/terraform apply -input=false \"/home/atlantis/.atlantis/repos/greyhats13/ol_shop/12/default/infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols/default.tfplan\"" in "/home/atlantis/.atlantis/repos/greyhats13/ol_shop/12/default/infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols": exit status 1
module.gkubernetes_engine.google_container_cluster.cluster: Creating...
╷
│ Error: googleapi: Error 400: Resource limits are supported only with node autoprovisioning.
│ Details:
│ [
│   {
│     "@type": "type.googleapis.com/google.rpc.RequestInfo",
│     "requestId": "0x7f205a7ad412501"
│   }
│ ]
│ , badRequest
│
│   with module.gkubernetes_engine.google_container_cluster.cluster,
│   on ../../modules/compute/gkubernetes-engine/gkubernetes-engine.tf line 2, in resource "google_container_cluster" "cluster":
│    2: resource "google_container_cluster" "cluster" {
│
╵

Ran Plan for 2 projects:

dir: infrastructure/gcp/cloud-deployment/gcompute-engine-bastion workspace: default
dir: infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols workspace: default

1. dir: infrastructure/gcp/cloud-deployment/gcompute-engine-bastion workspace: default
Show Output
data.terraform_remote_state.gcloud_dns_ols: Reading...
data.terraform_remote_state.vpc_ols_network: Reading...
data.terraform_remote_state.gkubernetes_engine_ols: Reading...
data.terraform_remote_state.vpc_ols_network: Read complete after 0s
data.terraform_remote_state.gkubernetes_engine_ols: Read complete after 0s
data.terraform_remote_state.gcloud_dns_ols: Read complete after 0s
data.google_project.current: Reading...
data.google_project.current: Read complete after 0s [id=projects/onlineshop-378118]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

  # module.gcompute-engine.google_compute_firewall.firewall["ssh"] will be created
+ resource "google_compute_firewall" "firewall" {
      + creation_timestamp = (known after apply)
      + destination_ranges = (known after apply)
      + direction          = (known after apply)
      + enable_logging     = (known after apply)
      + id                 = (known after apply)
      + name               = "ols-dev-gce-bastion-allow-ssh"
      + network            = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/global/networks/ols-dev-vpc-network"
      + priority           = 1000
      + project            = (known after apply)
      + self_link          = (known after apply)
      + source_ranges      = [
          + "<IP_ADDRESS>/0",
        ]
      + target_tags        = [
          + "bastion",
        ]

      + allow {
          + ports    = [
              + "22",
            ]
          + protocol = "tcp"
        }
    }

  # module.gcompute-engine.google_compute_instance.instance will be created
+ resource "google_compute_instance" "instance" {
      + can_ip_forward       = false
      + cpu_platform         = (known after apply)
      + current_status       = (known after apply)
      + deletion_protection  = false
      + guest_accelerator    = (known after apply)
      + id                   = (known after apply)
      + instance_id          = (known after apply)
      + label_fingerprint    = (known after apply)
      + machine_type         = "e2-medium"
      + metadata             = (known after apply)
      + metadata_fingerprint = (known after apply)
      + min_cpu_platform     = (known after apply)
      + name                 = "ols-dev-gce-bastion"
      + project              = (known after apply)
      + self_link            = (known after apply)
      + tags                 = [
          + "bastion",
        ]
      + tags_fingerprint     = (known after apply)
      + zone                 = "asia-southeast2-a"

      + boot_disk {
          + auto_delete                = true
          + device_name                = (known after apply)
          + disk_encryption_key_sha256 = (known after apply)
          + kms_key_self_link          = (known after apply)
          + mode                       = "READ_WRITE"
          + source                     = (known after apply)

          + initialize_params {
              + image  = "debian-cloud/debian-11"
              + labels = (known after apply)
              + size   = 20
              + type   = "pd-standard"
            }
        }

      + network_interface {
          + ipv6_access_type   = (known after apply)
          + name               = (known after apply)
          + network            = (known after apply)
          + network_ip         = (known after apply)
          + stack_type         = (known after apply)
          + subnetwork         = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/regions/asia-southeast2/subnetworks/ols-dev-vpc-subnet-asia-southeast2"
          + subnetwork_project = (known after apply)

          + access_config {
              + nat_ip       = (known after apply)
              + network_tier = "STANDARD"
            }
        }

      + service_account {
          + email  = (known after apply)
          + scopes = [
              + "https://www.googleapis.com/auth/cloud-platform",
            ]
        }
    }

  # module.gcompute-engine.google_dns_record_set.record[0] will be created
+ resource "google_dns_record_set" "record" {
      + id           = (known after apply)
      + managed_zone = "ols-dev-gcloud-dns-blast-ols-blast"
      + name         = "bastion.ols.blast.co.id."
      + project      = (known after apply)
      + rrdatas      = (known after apply)
      + ttl          = 300
      + type         = "A"
    }

  # module.gcompute-engine.google_project_iam_member.sa_iam will be created
+ resource "google_project_iam_member" "sa_iam" {
      + etag    = (known after apply)
      + id      = (known after apply)
      + member  = (known after apply)
      + project = "onlineshop-378118"
      + role    = "roles/viewer"
    }

  # module.gcompute-engine.google_service_account.sa will be created
+ resource "google_service_account" "sa" {
      + account_id   = "ols-dev-gce-bastion"
      + disabled     = false
      + display_name = "Service Account for ols-dev-gce-bastion instance"
      + email        = (known after apply)
      + id           = (known after apply)
      + member       = (known after apply)
      + name         = (known after apply)
      + project      = (known after apply)
      + unique_id    = (known after apply)
    }

  # module.gcompute-engine.local_file.ansible_vars[0] will be created
+ resource "local_file" "ansible_vars" {
      + content              = jsonencode(
            {
              + cluster_name = "ols-dev-gkubernetes-engine-cluster"
              + project_id   = "onlineshop-378118"
              + region       = "asia-southeast2-a"
            }
        )
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0777"
      + file_permission      = "0777"
      + filename             = "ansible_vars.json"
      + id                   = (known after apply)
    }

  # module.gcompute-engine.local_file.private_key will be created
+ resource "local_file" "private_key" {
      + content              = (sensitive value)
      + content_base64sha256 = (known after apply)
      + content_base64sha512 = (known after apply)
      + content_md5          = (known after apply)
      + content_sha1         = (known after apply)
      + content_sha256       = (known after apply)
      + content_sha512       = (known after apply)
      + directory_permission = "0700"
      + file_permission      = "0400"
      + filename             = "id_rsa.pem"
      + id                   = (known after apply)
    }

  # module.gcompute-engine.null_resource.ansible_playbook[0] will be created
+ resource "null_resource" "ansible_playbook" {
      + id       = (known after apply)
      + triggers = {
          + "playbook_checksum" = "60a355ce39c9a4274be3fc4c0373ac6e0a0f04a7e13f8ec551a970d66c285e0d"
        }
    }

  # module.gcompute-engine.tls_private_key.tls will be created
+ resource "tls_private_key" "tls" {
      + algorithm                     = "RSA"
      + ecdsa_curve                   = "P224"
      + id                            = (known after apply)
      + private_key_openssh           = (sensitive value)
      + private_key_pem               = (sensitive value)
      + private_key_pem_pkcs8         = (sensitive value)
      + public_key_fingerprint_md5    = (known after apply)
      + public_key_fingerprint_sha256 = (known after apply)
      + public_key_openssh            = (known after apply)
      + public_key_pem                = (known after apply)
      + rsa_bits                      = 2048
    }

Plan: 9 to add, 0 to change, 0 to destroy.

Changes to Outputs:
+ private_ip = (known after apply)
+ public_ip  = (known after apply)

:arrow_forward: To apply this plan, comment:

atlantis apply -d infrastructure/gcp/cloud-deployment/gcompute-engine-bastion

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d infrastructure/gcp/cloud-deployment/gcompute-engine-bastion

Plan: 9 to add, 0 to change, 0 to destroy.

2. dir: infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols workspace: default
Show Output
data.terraform_remote_state.vpc_ols_network: Reading...
data.terraform_remote_state.vpc_ols_network: Read complete after 1s
data.google_service_account.gcompute_engine_default_service_account: Reading...
data.google_service_account.gcompute_engine_default_service_account: Read complete after 0s

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
+ create

Terraform will perform the following actions:

  # module.gkubernetes_engine.google_container_cluster.cluster will be created
+ resource "google_container_cluster" "cluster" {
      + cluster_ipv4_cidr           = (known after apply)
      + datapath_provider           = (known after apply)
      + default_max_pods_per_node   = (known after apply)
      + enable_binary_authorization = false
      + enable_intranode_visibility = (known after apply)
      + enable_kubernetes_alpha     = false
      + enable_l4_ilb_subsetting    = false
      + enable_legacy_abac          = false
      + enable_shielded_nodes       = true
      + endpoint                    = (known after apply)
      + id                          = (known after apply)
      + initial_node_count          = 1
      + label_fingerprint           = (known after apply)
      + location                    = "asia-southeast2-a"
      + logging_service             = (known after apply)
      + master_version              = (known after apply)
      + monitoring_service          = (known after apply)
      + name                        = "ols-dev-gkubernetes-engine-cluster"
      + network                     = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/global/networks/ols-dev-vpc-network"
      + networking_mode             = (known after apply)
      + node_locations              = (known after apply)
      + node_version                = (known after apply)
      + operation                   = (known after apply)
      + private_ipv6_google_access  = (known after apply)
      + project                     = (known after apply)
      + remove_default_node_pool    = true
      + resource_labels             = {
          + "business_unit" = "ols"
          + "code"          = "gkubernetes-engine"
          + "environment"   = "dev"
          + "feature"       = "cluster"
        }
      + self_link                   = (known after apply)
      + services_ipv4_cidr          = (known after apply)
      + subnetwork                  = "https://www.googleapis.com/compute/v1/projects/onlineshop-378118/regions/asia-southeast2/subnetworks/ols-dev-vpc-subnet-asia-southeast2"
      + tpu_ipv4_cidr_block         = (known after apply)

      + binary_authorization {
          + evaluation_mode = "PROJECT_SINGLETON_POLICY_ENFORCE"
        }

      + cluster_autoscaling {
          + enabled = false
        }

      + dns_config {
          + cluster_dns        = "CLOUD_DNS"
          + cluster_dns_domain = "blast.local"
          + cluster_dns_scope  = "VPC_SCOPE"
        }

      + ip_allocation_policy {
          + cluster_ipv4_cidr_block       = (known after apply)
          + cluster_secondary_range_name  = "pods-range"
          + services_ipv4_cidr_block      = (known after apply)
          + services_secondary_range_name = "services-range"
          + stack_type                    = "IPV4"
        }

      + master_auth {
          + client_certificate     = (known after apply)
          + client_key             = (sensitive value)
          + cluster_ca_certificate = (known after apply)

          + client_certificate_config {
              + issue_client_certificate = true
            }
        }

      + master_authorized_networks_config {
          + gcp_public_cidrs_access_enabled = false

          + cidr_blocks {
              + cidr_block   = "<IP_ADDRESS>/28"
              + display_name = "my-home-public-ip"
            }
        }

      + network_policy {
          + enabled  = true
          + provider = "CALICO"
        }

      + private_cluster_config {
          + enable_private_nodes   = true
          + master_ipv4_cidr_block = "<IP_ADDRESS>/28"
          + peering_name           = (known after apply)
          + private_endpoint       = (known after apply)
          + public_endpoint        = (known after apply)
        }
    }

  # module.gkubernetes_engine.google_container_node_pool.nodepool["spot"] will be created
+ resource "google_container_node_pool" "nodepool" {
      + cluster                     = "ols-dev-gkubernetes-engine-cluster"
      + id                          = (known after apply)
      + initial_node_count          = (known after apply)
      + instance_group_urls         = (known after apply)
      + location                    = "asia-southeast2-a"
      + managed_instance_group_urls = (known after apply)
      + max_pods_per_node           = (known after apply)
      + name                        = "spot"
      + name_prefix                 = (known after apply)
      + node_count                  = 2
      + node_locations              = (known after apply)
      + operation                   = (known after apply)
      + project                     = (known after apply)
      + version                     = (known after apply)

      + autoscaling {
          + location_policy = "BALANCED"
          + max_node_count  = 20
          + min_node_count  = 2
        }

      + node_config {
          + disk_size_gb      = 20
          + disk_type         = "pd-standard"
          + guest_accelerator = (known after apply)
          + image_type        = (known after apply)
          + labels            = {
              + "business_unit" = "ols"
              + "code"          = "gkubernetes-engine"
              + "environment"   = "dev"
              + "feature"       = "cluster"
              + "name"          = "ols-dev-gkubernetes-engine-cluster-nodepool-spot"
              + "type"          = "spot"
            }
          + local_ssd_count   = (known after apply)
          + logging_variant   = "DEFAULT"
          + machine_type      = "e2-medium"
          + metadata          = (known after apply)
          + min_cpu_platform  = (known after apply)
          + oauth_scopes      = [
              + "https://www.googleapis.com/auth/cloud-platform",
            ]
          + preemptible       = false
          + service_account   = (known after apply)
          + spot              = false
          + tags              = [
              + "spot",
            ]
          + taint             = (known after apply)

          + shielded_instance_config {
              + enable_integrity_monitoring = false
              + enable_secure_boot          = true
            }
        }
    }

Plan: 2 to add, 0 to change, 0 to destroy.

Changes to Outputs:
+ cluster_ca_certificate     = (known after apply)
+ cluster_client_certificate = (known after apply)
+ cluster_client_key         = (sensitive value)
+ cluster_endpoint           = (known after apply)
+ cluster_id                 = (known after apply)
+ cluster_master_version     = (known after apply)
+ cluster_self_link          = (known after apply)

:arrow_forward: To apply this plan, comment:

atlantis apply -d infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols

:put_litter_in_its_place: To delete this plan click here
:repeat: To plan this project again, comment:

atlantis plan -d infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols

Plan: 2 to add, 0 to change, 0 to destroy.

:fast_forward: To apply all unapplied plans from this pull request, comment:

atlantis apply

:put_litter_in_its_place: To delete all plans and locks for the PR, comment:

atlantis unlock

Locks and plans deleted for the projects and workspaces modified in this pull request:

dir: infrastructure/gcp/cloud-deployment/gcompute-engine-bastion workspace: default
dir: infrastructure/gcp/cloud-deployment/gkubernetes-engine-ols workspace: default


Move hand written istioctl docs into auto-generated command docs

Now that istioctl reference docs are auto-generated move all of the previously written documentation under istio.io/docs/reference/istioctl.md into cmd/istioctl/*.go. Also update the mixer command documentation.
Fixes https://github.com/istio/istio.github.io/issues/70

Jenkins job manager/presubmit passed

I replaced the text on mixer scope/subject/rule with a link to the existing documentation here.

Jenkins job manager/presubmit passed

Jenkins job manager/e2e-smoketest passed

It might be worthwhile to add Hidden: true, to mixerCmd and mixerRuleCmd in cmd/istioctl/mixer.go.  Those commands are only subcommands for the real "istioctl mixer rule create" and "istioctl mixer rule get" and having them in the Documentation as commands feels awkward.

Jenkins job manager/presubmit passed

Jenkins job manager/e2e-smoketest passed


Reading in RooFit objects

I'm not sure if uproot is designed to be able to read in RooFit objects yet, so first of all should this be possible in the latest version of uproot?
I gave it a go regardless: I tried reading in a RooWorkspace and got the following error:
>>> import uproot
>>> ws = uproot.open("datacard.root")["w"] # read in RooWorkspace object
...
  File "<generated from TStreamerInfo 'RooWorkspace' at 0x7fa2f8832550>", line 37, in _readinto
NameError: global name 'RooWorkspace_3a3a_CodeRepo' is not defined

It seems to recognise that it's a RooWorkspace but fails somewhere after that.

I don't actually know a lot about RooFit. In principle, uproot should be able to read them, and working through the process of making that happen would shake out some bugs in the corners of that code. The NameError above is probably a case of me looking for the C++ name (RooWorkspace::CodeRepo) instead of its Python translation (RooWorkspace_3a3a_CodeRepo). Those sorts of things are easy to fix with an example but hard to catch by eye.
Do you have an example? I'm rushing to meet a deadline today, but I won't be able to go anywhere with this until I have a sample. (I suppose I could look up a "first steps in RooFit" example, but it would be nice to solve your particular problem.)

Let me know if you really need this capability and are willing to iterate on eliminating the bugs for your use-case. They may be trivial (the first one looks trivial) but that's not guaranteed. I'd also need to know which classes you'll be needing to direct our search for bugs.
Keep in mind that we won't be writing RooWorkspaces anytime soon— your use-case would have to have something to gain from reading RooWorkspaces in Python that were created (fitted) in ROOT. I can't think of anything right now...
(Oh, and I would of course want to eliminate all deserialization bugs, but they can only be discovered by example and the space is hard to cover. Therefore, I'm doing it in response to use-cases.)


Adding office hours and meeting recordings link to community page

Also changed the Zoom link on the office hours invite to match https://github.com/kubernetes/community/pull/4608.
/assign @bowei

/lgtm

/lgtm
/approve


Ensure comparison view picks up request/instance-specific EditHandler customisations

Some edit handlers, such as the 'unofficial' PerUserContentPanels recipe from #4749, vary their field list according to the current request/instance by hooking into bind_to. This was not being called on the comparison view, meaning that when these edit handlers are in use, the field list was never getting populated and so the view was wrongly reporting no changes.
Note that the bind_to method also allows binding a form, which we do still skip (since the comparison view doesn't construct one).

Merged in ac00945d3bebae836c01f99ce51b5d41172a81e0


Fix regex in font-size filtering example in README.md

Remove stray $ from the example filter for font-size.  Use grouping rather than charset for alternatives.
Note might opt to use capture rather than non-capture grouping to make consistent with other examples.

Thanks.


Fix regex in Kotlin MinimalWordCount example.

MinimalWordCount example in Kotlin was broken, as the regex was treated as a plain string instead of a regex.
Added toRegex (see https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.text/to-regex.html) to fix.
No JIRA issue for this, sorry.
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[x] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

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

R: @harshithdwivedi could you please have a look (I hope I am addressing the right person)

LGTM!

fyi, I can't merge this myself, don't have write access to the repo. So waiting for somebody to merge
cc @harshithdwivedi

@pabloem @alexvanboxel can either of you look into this? Thanks :)


[QUESTION]

Hi! I am using Producer SDK (version 2.0.2) in the application, that takes frames from a simple UDP-based internal protocol to a KVS Stream.
Sometimes I'm facing a packet loss in the UDP. In this case I can't provide the SDK with an ongoing frame in time. And it happened that if there is high amount of lost frames, the SDK fails to keep up with the connection and some issues occur that lead to a necessity to restart the streaming.
I wonder if there is a problem with my stream configuration:
	config.m_streamRetention = hours(2);
	config.m_streamMaxLatency = seconds(15);
	config.m_fps = 30;
	config.m_bitrate = 120000000;

	auto stream_definition = make_unique<StreamDefinition>(config.m_streamName.c_str(),
		config.m_streamRetention,
		nullptr,//&tags,
		"",
		STREAMING_TYPE_REALTIME,
		"video/h264",
		config.m_streamMaxLatency,
		seconds(1), // fragment duration
		milliseconds(1),
		true, // key frame fragmentation
		true, // frame_timecodes
		true, // absolute timecodes
		true, // application fragment acks required
		true, // recover after an error
		true, // recalculate metrics at runtime
		NAL_ADAPTATION_FLAG_NONE,
		config.m_fps,
		config.m_bitrate);

If there is a way to improve this config?

@imizus the older version of the SDK does not automatically support the "intermittent" producer case.
Please upgrade to the latest commits. In this case, it will support automatic intermittent producer scenario. When the application stops producing frames into the stream object, the connection will timeout (from the backend) and will notify the underlying stream object. If the buffer is empty, the SDK will not re-try to create a new session. As soon as a new frame comes in, it will automatically issue PutMedia call.
The only thing to note here is that as in your case with the persistence, due to the fact that we won't be getting the last fragment persisted ACK, we will re-send the last fragment first to get the ACK. In order to handle this, the application will have to explicitly specify EoFR frame at the end of the session so the backend will know the fragment is "closed". Most use cases this won't matter at all.

BTW, the config looks good.

Thank you for the rapid answer.
I have updated to SDK 3.0.0 and now it seems to work much better, but another new issue occured.
During the data uploading a single message pops out hundreds times:
07:13:18.450 ERROR getKinesisVideoStreamData(): operation returned status code: 0x5200002f

In the doc it's written that this code means STATUS_NO_MORE_DATA_AVAILABLE, but the incoming and outgoing FPS are measured, both equal to 30.
Why is it happening? Is there any impact of this on the working of the app and how to take rid of it?

@imizus this is a known issue that was fixed later in PIC. This is not an error but a status code indicating the buffer is empty (good) but it gets misinterpreted as a warning.
Generally, the networking thread pulls the bits from the lower-layer buffer. The buffer can return the bits, no more data, eos status codes to signal certain things to the network layer (C Producer layer) and these are not errors.
The streaming shouldn't be affected by this erroneous printout

Thank you again!
And another question.
On the side of consumer we have a Java application that downloads the stream and decodes it. And sometimes we see 2 errors (on different consumer instances):

java.lang.RuntimeException: Add new ParserException type
java.lang.IllegalArgumentException: Trying to decode an EBML ID and it wants 4 more bytes, but IDs max out at 4 bytes

What do they mean?

It’s hard to tell without more details. However, I am guessing that this is likely caused by the producer side dropping a partial frame perhaps. The real-time path will evaluate to but in and bit out to minimize the latency so by the time the backend detects a broken fragment the bits have been already sent down to the consumer

Resolving due to staleness


ttt: simple test with CI+Konnect

Codecov Report
Patch and project coverage have no change.

Comparison is base (bb3ef61) 35.57% compared to head (960dbd3) 35.57%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #921   +/-   ##
=======================================
  Coverage   35.57%   35.57%
=======================================
  Files          92       92
  Lines       11279    11279
=======================================
  Hits         4013     4013
  Misses       6873     6873
  Partials      393      393

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Bootstrap Data Migration Error

Environmental Info:
K3s Version:

k3s version v1.22.2+k3s-6b4d75d2 (6b4d75d2)
go version go1.16.8
Node(s) CPU architecture, OS, and Version:

Linux opni-single-node-hpc 5.4.0-1047-kvm #49-Ubuntu SMP Mon Sep 20 21:27:33 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Cluster Configuration:

Single node, default storage configuration
Describe the bug:

After upgrading k3s from commit 12e675e2cc3431d25630f63535f66ad4bb22ae85 to 6b4d75d2451ef26e1061e81f186f25f26b5a7e94, startup failed with the following error messages:
Oct 14 17:44:31 opni-single-node-hpc systemd[1]: Starting Lightweight Kubernetes...
Oct 14 17:44:31 opni-single-node-hpc sh[64905]: + /usr/bin/systemctl is-enabled --quiet nm-cloud-setup.service
Oct 14 17:44:31 opni-single-node-hpc sh[64906]: Failed to get unit file state for nm-cloud-setup.service: No such file or directory
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=debug msg="Asset dir /var/lib/rancher/k3s/data/157e7133c019a632df3b8ec2becdfe8c22ce2a3ca3d89ba9de425b84c5914d8d"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=debug msg="Running /var/lib/rancher/k3s/data/157e7133c019a632df3b8ec2becdfe8c22ce2a3ca3d89ba9de425b84c5914d8d/bin/k3s-server [/usr/local/bin/k3s server --debug]"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=info msg="Starting k3s v1.22.2+k3s-6b4d75d2 (6b4d75d2)"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=info msg="Configuring sqlite3 database connection pooling: maxIdleConns=2, maxOpenConns=0, connMaxLifetime=0s"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=info msg="Configuring database table schema and indexes, this may take a moment..."
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=info msg="Database tables and indexes are up to date"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=info msg="Kine available at unix://kine.sock"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=info msg="Reconciling bootstrap data between datastore and disk"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=info msg="Migrating bootstrap data to new format"
Oct 14 17:44:31 opni-single-node-hpc k3s[64909]: time="2021-10-14T17:44:31Z" level=fatal msg="starting kubernetes: preparing server: EOF"
Oct 14 17:44:31 opni-single-node-hpc systemd[1]: k3s.service: Main process exited, code=exited, status=1/FAILURE
Oct 14 17:44:31 opni-single-node-hpc systemd[1]: k3s.service: Failed with result 'exit-code'.
Oct 14 17:44:31 opni-single-node-hpc systemd[1]: Failed to start Lightweight Kubernetes.

Steps To Reproduce:

Installed K3s:
$ curl -sfL https://get.k3s.io | INSTALL_K3S_COMMIT=12e675e2cc3431d25630f63535f66ad4bb22ae85 sh -
Upgraded K3s:
$ curl -sfL https://get.k3s.io | INSTALL_K3S_COMMIT=6b4d75d2451ef26e1061e81f186f25f26b5a7e94 sh -

Expected behavior:

K3s upgrades to the new version successfully
Actual behavior:

K3s fails to start with error messages.
Additional context / logs:

Server args used: '--write-kubeconfig-mode=644' '--tls-san=<server's public ip>' '--kube-scheduler-arg=v=2' '--log=/var/log/k3s.log' '--alsologtostderr'
Reverting to the previous version allows k3s to start normally again.
Starting with --debug does not yield any additional information

Backporting

[ ] Needs backporting to older releases

I have validated bootstrap functionality works on master-branch using commitid 8271d98a766b060463bc73ef66c5085b5797b4cc, however I believe this issue may be more related to the log file argument. We have other issues to resolve that, so I am going to close this one out.


[6.3.x] Fix few intermittently failing tests

KieModuleRepoTest was influencing other tests,
executed after

specified runOrder for surefire. Hourly means
that surefire will execute the tests
in alphabetical order on even hours and in
reverse alphabetical order on odd hours. This
brings certain level of predictability as to
in which order the tests are executed, but at the same
time allows to detect at least some issues related
to order of exeuction of the tests (which is
bad as unit tests should not be dependent on
each other). see http://maven.apache.org/surefire/maven-surefire-plugin/test-mojo.html#runOrder for more info

increase test timeouts to accomodate slower machines

Same changes already applied to master. @etirelli since these are only test fixes, I believe it is save to apply them to 6.3.x as well.

+1 merged


Cherry-pick PR #354, #355, #360, and #398 to release-v1.2

Cherry-Pick Details

Original PR Titles:

fix: improve error handling for Prism Client
refactor: task status file
refactor: client.go file helper methods
Switch Nutanix Client to use Session Auth instead of Basic Auth

Original PR URLs:

https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/pull/354
https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/pull/355
https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/pull/360
https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/pull/398

Original Commit SHAs:

1f8716d88ee3ef965599254144cd2ce2a4c5e37c
5fd7ada9b99ab7f3b2b48dd15ae186c017296c4b
3fa9d45b680065e2471e22854189e1ff1d6b2eb0
03c61d34afe159fe91940724e44f821dfeed1d1c

Cherry-Pick Reason: Cherry-picking changes that allow us to cleanly cherry-pick new patches related to session auth

@thunderboltsid: The following tests failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:
Test name	Commit	Details	Required	Rerun command
ci/prow/e2e-capx-controller-upgrade	9c7ba34 link	false	/test e2e-capx-controller-upgrade
ci/prow/e2e-k8s-upgrade	9c7ba34 link	false	/test e2e-k8s-upgrade
ci/prow/e2e-nutanix-features	786115e link	false	/test e2e-nutanix-features
Full PR test history. Your PR dashboard.

e2e-nutanix-features test suite actually passed but it seems the !cluster-upgrade-conformance && !conformance did not get passed to the the test command. As a result, it took longer for the test to run and it only skipped cluster-upgrade-conformance.

Ginkgo ran 1 suite in 1h19m1.425626558s
Test Suite Passed
make[1]: Leaving directory '/home/prow/go/src/github.com/nutanix-cloud-native/cluster-api-provider-nutanix'
make: *** No rule to make target '&&'.  Stop.

Testing out a potential fix with with https://github.com/nutanix-cloud-native/cluster-api-provider-nutanix/pull/423/commits/79c6cd1ffb7bd595fa21d67403874ea513859124


Add [Paribu a.ş] #personal GBZLHG…2ZQKVA

Address: GBZLHGDYMSVF4X6DYAGKLIQX3F64W3MXNDVGHKQPR226TCJ5QJ2ZQKVA
Tags: personal
Title: Paribu a.ş
Requested by @polat06

302766 Memo

@polat06 this issue is being combined with your other same issue posted. https://github.com/stellar-expert/public-directory/issues/502


using board_url with vetiver

The hope is to use pins.board_url for model cards, but it is currently not since vetiver requires a version.
Pins will be adding this capability! Tracking in
https://github.com/rstudio/pins-python/pull/147

Pins PR is merged, and this does indeed "just work" now!


data: SafeerAlEhsan

Fixes Issue

Changes proposed

Check List (Check all the applicable boxes)

[x] My code follows the code style of this project.
[ ] My change requires changes to the documentation.
[ ] I have updated the documentation accordingly.
[ ] All new and existing tests passed.
[ ] This PR does not contain plagiarized content.
[x] The title of my pull request is a short description of the requested changes.

Screenshots

Note to reviewers

Hey Pradumna. Small question. Do I update my local branch and then create another PR or is there a way to update the branch here?

I made another PR ( #3592 ) since git tracking does not seem to pick up case sensitive file name changes.


Update money page

We now have 10 guilds, and 1000 gold has been issued in total.
We now have 12 guilds, and 1200 gold has been issued in total.
Could you update this, @kirstyrose?
Thanks!

Done.


Re-installing profiles

I'm trying to build a package to do the following, all in one shot, I don't know if this tool can do it however. Everything else I've tried has been a complete failure.
I need to:

remove existing profiles if they exist.
install the trust profile.
install the enrollment profile.

I want a single pkg that our tier 1 techs can just double-click and be done with.
Thoughts anyone?

This tool has some of the bits you need, but you'll need to do some work to build a single pkg that meet your needs.
make-profile-pkg builds a single pkg for a single profile, so you could potentially use it to build your two packages, and then use productbuild to put them together into a single distribution pkg.
For removing existing profiles, you could add a preinstall script to one of the packages or add a third package that handles the removal using a preinstall script. If you build a pkg using pkgbuild and use the --nopayload option, it won't leave behind a receipt, and so can instead be used as a vehicle for running scripts.
Note that if your new profile has the same identifier as the old versions, those will be "updated" so you don't necessarily need to remove old ones first. But, only if the identifiers are the same.


React-native implementation.

Hi,
I'm new to aws iot core so if i have missed something please advice me.
I'm working on a iot project where i have to control the on board led of esp32 through react-native app.
The flow goes as App <--> aws-iot-core <--> esp32.
Upon searching i came here and saw this example in react,
So my question is will this work in react-native and in my case?
What I've tried till now is controlling led by checking receiving message from aws iot core test.
So my other question is how should i achieve that through app or where should i look into?
OS - Win10
Iot model - ESP32
App - React-Native ( Android only )

Hi Sidd,
I'm not super familiar with React-Native but this implementation relies on the Amplify PubSub library so as long as you are able to use that library, it should work the same way!


Provide link for specific video

ex)
https://youtu.be/f5ShDNOqq1E
->
https://youtube-lite.js.org/video/f5ShDNOqq1E
And I guess custom 'copy link' button would be needed.
This link also can be very powerful advertisement!

As of PR #36, You can now use:
https://youtube-lite.js.org/video/f5ShDNOqq1E

Now we have to add a 'share' button.

Nice work!
How about shorten paths so that your code become the next line?
<Redirect from="/v/:id" to="/video/Default/:id" />

yeah. we can have both v and video like you said.

closed as of #42. For 'copy link' or share button, refer to #41.


Ionic time out error

Hi - I'm new to ionic . I get this error on start blank app
✔ Creating directory C:\projects\noteit - done!
Fetching app base (https://github.com/driftyco/ionic2-app-base/archive/master.tar.gz)
✖ Downloading - failed!
Error: Timeout of 25000ms reached for https://github.com/driftyco/ionic2-app-base/archive/master.tar.gz
can anyone help ?

@1374hamed This will be solved in the next version. See https://github.com/driftyco/ionic-cli/issues/2256
Thanks.


fix: update field validation style

Add validation icons to help text:

Make focus styles of validated inputs the same as normal ones.
Focus state before:

Focus state after:

Coverage remained the same at 87.954% when pulling f0d7719e7c4a72ec0d25af98e6d3cf173de08d1e on abutterworth/field-validation-style into 01d4dd33f6fa5f50506459610826efdc5c47fc91 on master.

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

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Bump bytes crate to 0.6

bytes is not a public dependency of http now, so the minor version bump is not necessary (see #369).

A MINOR version bump (0.3.0) may not be necessary as you say, but is it really desirable to introduce bytes 0.6 in a patch release of http?   As it will end up being a duplicate with other crates remaining dependent on bytes 0.5 for quite some time, I don't think its desirable to introduce it that way.    It might be better to release the change in http 0.3.0 (as in da252dd) so that h2, hyper, and related crates can update to it in their own MINOR releases.
If there is some motivation for releasing it as a patch, then consider broadening the dependency instead, e.g. bytes = ">= 0.5, < 0.7" .    Yes, by default the same duplication will occur, but at least consumers have the option of using Cargo.lock to use bytes 0.5.6 and avoid the duplicate.

Some users of http as a public dependency, like attohttpc and http-types (via hyperium_http feature), do not depend on bytes, so I think a minor version bump is undesirable for them.

See also hyperium/http-body#29.  That bytes dependency is public.  If this PR (82418a8) was released as is, current hyper (which depends on both http and http-body, as well as bytes directly) users would end up with duplicate bytes crates, without necessarily having any bytes dependency themselves.

@dekellum I'm quite sure a new hyper will not be released until http-body also depends on bytes 0.6.

Sure, but new hyper will be 0.14 (a MINOR bump) for new tokio, etc., right?
My more limited point is just that if this PR was released as is,  cargo update on an existing hyper 0.13 application will result in duplicate of bytes crate. If on the other hand, you release the bytes upgrade as http 0.3.0, then no duplicate now, and no duplicates with mass upgrade to hyper 0.14 with its tokio, http, http-body, bytes deps.

I've forgotten the exact details cargo will do if we use a version range... If other crates in the dependency graph want 0.5.x, will it just keep it to 1 copy? If so, I find that preferable.

Sadly, no.  Cargo will go for maximum versions, not to minimize duplicates.  Thus I'd prefer this in http 0.3.0, but if it must be done as a patch release then at least with the range, you can avoid the duplicate by something like cargo update -p bytes:0.6.0 --precise 0.5.6 and keeping your lock file.


Any plan for upgrading to latest build_runner

Is there a roadmap to upgrade compatibility according to the build_runner build_runner: ^1.3.0
and  build_web_compilers: ^2.0.0 ?

The use of build_runner ^1.3.0 implies build_runner_core ^3.0.0, and build_runner_core >=2.0.2 implies analyzer >=0.35.0 <0.37.0.
That version of the analyzer eliminates a number of features that reflectable is using, so there's some repair work to be done before reflectable can be used with analyzer version 0.35.0 and up. This is being handled in #173, so I'll close this issue as a duplicate thereof.
PS: #173 has 'Flutter' in the title, but it is concerned with porting reflectable to analyzer 0.35, that requirement just came up in connection with Flutter first.

Thank you for answering, I'll wait for any update about #173 issue.


feature: Add guess type check during Get if no element found by key

Add check for new subtypes:
type Element uint8
Register[uint8]()
Get[Element]()


RNS Shell Implementation

Implemented RNS Shell for replacing sk_app which was used from Skia for POC purpose.
Supports Only Linux Platform now.
Has Boot strap code for application.
Has platform Task runner implementation.
Has Layer management and Render Tree management.
Has Platform Graphics support with OpenGL backend with X11 & LibWPE client backend. Supports GLX and EGL interface.
Has compositor framework for rendering Render Layer tree.
Added RNS logging and Utility Helper Macros.

if sk_app is not used, please try to remove sk_app, so that git may able to know the file renaming. otherwise, it's hard to review the difference between sk_app and rns_shell.

Done, But I noticed that git didn't detect all the files as renamed, some of file still shown as new files. But it is better than before.


Avro

Wondering if the Explorer will support avro serialized messages soon?

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

ID: 4473571e-db99-fd3c-5861-1ba66e3a6890
Version Independent ID: a2ebb61f-e901-a778-cca0-503fb10ae42b
Content: Use Azure Service Bus Explorer to perform data operations on Service Bus (Preview) - Azure Service Bus
Content Source: articles/service-bus-messaging/explorer.md
Service: service-bus-messaging
GitHub Login: @axisc
Microsoft Alias: aschhab

Hello @KKanekoa,
Thank you for your feedback! We will review and update as appropriate.

@KKanekoa The explorer peeks into the Queue/Subscription to see what's in. The message payloads are always serialized to binary. You can plug in the avro format file and it will be visible in your application - senders and receivers - but won't be displayed appropriately on the Explorer on the portal.
We will add it to the backlog, but don't have an ETA for it now.


LICENSE: add title

The title is not legally mandated, but it's convenient for human consumption, and provides additional metadata; for that reason, it is typically included in the template text of this license, as recommended by OSI, SPDX, choosealicense.com, and others.
Note: This PR is part of my personal project to improve the consistency and visibility of the ISC license in open source projects. See https://github.com/github/choosealicense.com/issues/377 for more details.

Pinging @emilbayes and @mafintosh — this is a one-line change, so it should be an easy decision one way or the other :)


Unable to integrate jqf into gradle project

I'm working on a big proprietary project managed by Gradle and I'm struggling with JQF integration.
I've tried to rewrite the JQF maven plugin to Gradle plugin+task, but I'm too novice in Gradle to be able to dynamically retract valid class object for GuidedFuzzing. The object I'm getting contain proxy of the @RunWith annotation, but the library expects actual annotation class.
I've tried to create simple main class as part of the project where I mimic the implementation of the FuzzGoal, using exact same code but having the java runtime classloader instead of InstrumentingClassLoader. 2 seconds after start of the program I get the message saying
Too many trials without coverage; likely all assumption violations
which means that no coverage was retrieved from the runs.
Any ideas on how to make JQF work with gradle project?

Hello. I am not personally familiar with Gradle so I cannot give you any Gradle-specific advice.
However, I can confirm that if you replace the InstrumentingClassLoader with the Java system classloader, then the loaded classes will not get instrumented. That is likely why you are seeing a warning regarding lack of coverage information.
In order to get coverage info, the bytecode of the application classes must be instrumented as they are loaded. This can be done in one of two ways: (1) Using the InstrumentingClassLoader, as done in the Maven plugin, or (2) starting the JVM with a -javaagent, as done by the command-line launch scripts.
For Gradle projects, I would recommend the former. The only downside to this is that you cannot instrument classes that have already been loaded before the classloader kicks in, such as Gradle itself and anything that Gradle depends on.


Fix 500 errors when resetting password

https://github.com/DefectDojo/django-DefectDojo/pull/8081 introduced a 500 error when attempting to reset password from email link, as the settings object was not accessible within each validator.

Hi @blakeaowens, can you please provide logs from the request which raise HTTP-500?
#8081 had some reason (accept changes from System_settings with a necessary restart of the application). I would like to know, how/why validators are failing right now.

Btw, it might be a good idea to write some unit/integration test on it.

@kiblik
  File "/app/dojo/user/validators.py", line 21, in get_help_text     minimum_length=self.settings.minimum_password_length))                    ^^^^^^^^^^^^^ AttributeError: 'MinLengthValidator' object has no attribute 'settings'

@kiblik
File "/app/dojo/user/validators.py", line 21, in get_help_text
    minimum_length=self.settings.minimum_password_length))
                   ^^^^^^^^^^^^^
AttributeError: 'MinLengthValidator' object has no attribute 'settings'

Thank you. Do you mind if I will introduce an approach to fixing mentioned issue, keeping the ability to accept changing of settings without necessary restart and maybe test validators to avoid these issues in the future?

@kiblik I decided to do some further testing with the changes made in this PR, and I did not see any need to restart for system settings changes to take place within the validators. I have attached a video that shows me changing the password requirements, and seeing those changes immediately reflected in the change password form without any problems.
Please let me know if I am misunderstanding your concern/initial reason for making the changes you did. Thanks!
https://github.com/DefectDojo/django-DefectDojo/assets/76979297/e6e30e1d-3f07-4f9a-835f-a8c115047e49

Hmmm... interesting. You understood me absolutely correctly. But I had totally opposite outcome. It is magical for me.
Btw, I was just going to write you that I prepared the implementation which I proposed (including tests): #8314