Wrong statement regarding VMware vCenter statistics level?

On this web page it states

VMware vCenter statistics level settings can be 1 or higher level

whereas in the output file CapacityPlanner.log, i get the following error message:

vCenter statistics level is 1. It needs to be at least 2 for the tool to work.

Seems then that the info on the page is wrong, no?

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

ID: aa9a9a9e-e47f-2c35-752e-4d026f0fca93
Version Independent ID: c23d2cb9-c2d0-505c-5a58-53074fcd373b
Content: Azure Site Recovery Deployment Planner for VMware disaster recovery - Azure Site Recovery
Content Source: articles/site-recovery/site-recovery-deployment-planner.md
Service: site-recovery
GitHub Login: @Sharmistha-Rai
Microsoft Alias: sharrai

@baardhermansen Thanks for your comment! We will review and provide an update as appropriate.

@baardhermansen We are collecting the below metrics of VM disks.
"virtualDisk.read.average", "virtualDisk.write.average", "virtualDisk.numberReadAveraged.average", "virtualDisk.numberWriteAveraged.average"
As per the VMware docs mentioned below vCenter statistics level 1 also should work.
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.monitoring.doc/GUID-25800DE4-68E5-41CC-82D9-8811E27924BC.html
This is generic error we are throwing when statistics collection failed. The issue you reported may need investigation all the logs generated. Therefore, a support request needs to filed for deeper investigation.
FYI: Please note that this channel (the Azure Docs repository) is only for driving improvements related to the Azure documentation. It would be great if you can share the documentation link you are referring, so that we can assist you accordingly.

Hi @SadiqhAhmed-MSFT
You asked me for the documentation link, not entirely sure i understand; I opened this issue on the page in question, as can be seen under Document details - Content in the issue above.
After i adjusted the statistics level to 2, Your tool started to run without further issues.
Hence this issue regarding possible error in the documentation.

@baardhermansen I got your point. However, per content owner the doc doesn't any update. What you observed may need investigation by the technical support team.


Use rootfs file-system other than EXT4?

Hi everyone,
Is it possible to have a rootfs whose file-system is other than EXT4 file-system? For instance, let's say BTRFS?

Hi there!
I'm afraid BTRFS is not supported. Mariner is mostly focused around EXT (and FAT for /boot/efi).
You can play around with a few other formatting options in the ISO installer when you select manual formatting but they are closer to an experimental feature at the moment.

Knowing close ties between CBL-Mariner and WSL2, can an experimental rootfs filesystem for WSL2 other than EXT4 be achieved? Thanks!

Now that XFS as rootfs is possible, I think this question can be revisited. Thanks!

We do have EXT4 and XFS.
https://github.com/microsoft/CBL-Mariner/blob/2.0/toolkit/docs/formats/imageconfig.md

https://github.com/microsoft/CBL-Mariner/issues/4131#issuecomment-1845883616

#eric-desrochers, why not BTRFS, though? It's markedly superior.

Thanks for the response @eric-desrochers Nonetheless, I'd appreciate if this issue could be left open! IMHO, in future this would be crucial for WSL2/CBL-Mariner.


Adding override method to allow control over OnlyAllowMembersViewMemb…

…ership

Thanks Lane, I'll have a look at this one.

Hi Lane,
I manually processed this PR as I could not take over your code since you changed the method signature which will result in breaking folks who where using that method. I added an additional optional parameter to the method signature which defaults to false.

I left the original method signature in place and just called the override with the new param set to false. But your approach works, too. Tomato, Tomato. Thanks Bert!


aws

i am creating aws accout but i am not go through ec2 machine,by clicking ec2 the page displays like  below.i am go through below 3 steps,but unable to get ec2

contact support and explain same thing to them, they will guide you. mostly they may ask you for id proof

Is it over 24 hours since you registered? If yes, then click on Contact Support button and try to raise a ticket.

=>Some times "credit card" verification might be failed.
=> check your mail which was given to that account.
=>Or else try to create new account with new mobile number &  new mail id.

@ramakrishna228    Dont create any new account . please check the your payment method , if it success , wait for activation mail, it may take time to get activation mail. If it is activated then wait for 24 hours to access services.
If payment  gets failed , remove that card & add new card . AWS accept VISA and Master cards only.

Please raise support ticket on AWS @ https://aws.amazon.com/contact-us/


Cryptic error when running Kani on a file without a harness

I tried this code:

// no_harness.rs
pub fn my_api() {
    todo!()
}

using the following command line invocation:
kani no_harness.rs

with Kani version: 0.15.0
I expected to see this happen:  Kani should exit gracefully and print the same message it prints when using cargo kani
No proof harnesses (functions with #[kani::proof]) were found to verify.

Instead, this happened: Kani command failed with the following error:
Error: No such file or directory (os error 2)

This is a duplicate of https://github.com/model-checking/kani/issues/1910?

Yeah, I just noticed that now. I'll close this one.


Default to case insensitive usernames and emails in cognito?

Is your feature request related to a problem? Please describe.
Looks like cognito has a new property to make usernames and emails case insensitive. See https://aws.amazon.com/about-aws/whats-new/2020/02/amazon-cognito-user-pools-service-now-supports-case-insensitivity-for-user-aliases/ and https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-cognito-userpool-usernameconfiguration.html
Describe the solution you'd like
It seems like this should be default when amplify cli sets up auth. It looks like Cognito service will make this default eventually.

Definitely +1 from me, in fact I'd love if somebody could enlighten me as to a scenario where case sensitive usernames/emails are ever a good idea? Especially emails. Seems weird to me that it's even an option in Cognito.

@hisham @lukeramsden - agree. We will make this change. cc @asmajlovicmars

Fixed in: https://github.com/aws-amplify/amplify-cli/pull/6065

Fixed in: https://github.com/aws-amplify/amplify-cli/pull/6065

agh, missed this by a few weeks and there is no way to update existing pool :(


[feature] Ignore link if text relating to link is ignored

Version and OS
Linux/docker
Is your feature request related to a problem? Please describe.
My current use case is in monitoring when new items are listed on various selling sites. That said I am sure this is applicable elsewhere. When using the "Render anchor tag content" the "ignore text" filter becomes rather useless as all the rendered links are listed below the items title text.
Describe the solution you'd like
When any text relating to the links is ignored, the link should be ignored as well.
Describe the use-case and give concrete real-world examples
The following is eBay output. If I want to ignore the text "iphone 12" it will not prevent any future triggers with that text as the links of the new listings will not be ignored.

iphone 12 pro max 128gb unlocked

Apple iPhone 12 pro 64gb unlocked Grey

Hmm i'm not sure about this one, the 'ignore text' part is definitely applied to the output
the flow is something like

extract page
convert to text (with "Render anchor tag content" enabled)
apply ignores
decide what todo

Hmmm, got any more info? version? screenshots?


Code Inquiry: Gini Coefficient, Shannon-Wiener, Heatmap, and Model Testing

It's great that you shared your work. Can you tell me in which part of the code you calculated Gini coefficient and Shannon-Wiener, and where the heatmap was generated? I couldn't find its plot, and once the model is trained, how do you test it?

Thank you for your comment.
The current version of the repo only contains the code of main technical contribution of our work.
Regarding your comment:

Attention Evaluation: I utilized and modified this repo(https://github.com/luo3300612/Visualizer) for my attention visualization and evaluation (Gini and SW).

Model Evaluation: After finishing the training process, you will get the saved model in ./final_models folder. You can load and evaluate it in the same environment or new environment by employing different XXX.world in "catkin_ws/src/gtrl/launch/empty_world.launch" file.


Rereading a fasta takes too long

When BOLDigger is restarted it takes to long to re-read the fasta. I assume this happens somewhere in reading the hdf store and filtering for unique ids.

Fixed with 1.1.6


Changing markup breaks the displayed value

Hi there,
First of all, thanks for this project, it'll help me a lot (as soon as I resolve this issue ;)).
Here is the deal: whenever I set a custom markup, the displayed value in the mention switches from display to id.
Here is a simple snippet:
<MentionsInput
  className="TextArea"
  onChange={onChange}
  value={value}
  markup="@[__type__](__id__)"
  >
  <Mention
    trigger="#"
    className="Mention--cell"
    type="Cell"
    data={data.allCells && data.allCells.map((cell) => ({ id: cell.id, display: cell.name }) )}
  />
</MentionsInput>

In this example the mention will always display cell.id.
Even if I try to set a custom displayTransform  like displayTransform={ (id, display) => display }), it always ends up rendering ìd` instead!
If I remove my custom markup, everything is back to normal...
Thanks in advance for your help.

Ok, so I've just discovered that is renders correctly if you make sure you use __display__ in your markup.

The data provided for the <Mention /> are only used for rendering suggestions (and generating the markup when a mention is selected). The display value is derived only from the markup value. There is no lookup from the <Mention />'s data prop happening.

For anyone that has the same issue and really don't want to use __display__ in their raw text: Use the displayTransform function, and lookup the display by id manually.
I have no idea why this is not supported by default...

For anyone that has the same issue and really don't want to use __display__ in their raw text: Use the displayTransform function, and lookup the display by id manually.
I have no idea why this is not supported by default...

Can you please explain what you mean exactly? I think I have the exact same usecase


Suggestion to Remove "valid_gpt_models" from gpt_model.py

Thank you for your helpful library.
I am writing to suggest removing the valid_gpt_models list.
The model pointing provided by OpenAI can occasionally change, but the DeepEval code cannot always be updated simultaneously. For example, "gpt-4o" currently points to "gpt-4o-2024-05-13" (as of July 2024), but this can change at any time. This variability can lead to inconsistencies and confusion in the evaluation results, affecting the reliability and consistency of DeepEval's assessments.
Therefore, I suggest allowing the code to return errors if users input invalid model names, instead of relying on a static and incomplete valid_gpt_models list.
Thank you for considering this suggestion.
I hope this helps!

As feared, "gpt-4o" is scheduled to be updated to "gpt-4o-2024-08-06" soon. Changes in the evaluation model can create significant flaws in the reliability of the results. To ensure that users always have access to a consistent model, please consider removing the valid_gpt_models list or adding the pointed models (like "gpt-4o-xxxx-xx-xx") to the list.

suggestion to replace the code with
valid_gpt_models = [openai_model.id for openai_model in client.models.list().data]


RuntimeError: tensorflow/lite/kernels/conv.cc:316 input->dims->data[3] != filter->dims->data[3] (4 != 3)Node number 1 (CONV_2D) failed to prepare.

ubuntu18.04
tf-nightly-gpu : '2.4.0-dev20200811'
numpy  :  1.18.3
I follow the official website to convert the file (https://www.tensorflow.org/lite/performance/post_training_integer_quant)
The first step is to convert .h5 files to tflite files(success!!),but When performing integer quantization This error occurred：
[RuntimeError: tensorflow/lite/kernels/conv.cc:316 input->dims->data[3] != filter->dims->data[3] (4 != 3)Node number 1 (CONV_2D) failed to prepare.]
My model:
hdf5.zip
tflite.zip
One of my training materials:
train_img.zip

@LINYOUWEI0804
Request you to share colab link or stand alone code to reproduce the issue in our environment.It helps us in localizing the issue faster.Thanks!

My training program：
train.zip

@LINYOUWEI0804 Looks like there is a mismatch in the data shape. You can check model.summary that input_shape of image is (1, 224, 224, 3) whereas xtrain.shape in representative_data_gen is (1, 224, 224, 4).
Can you please update the shape of representative_data_gen and then convert the model. As error is clearly mentioning there is a mismatch in the shape, i think this will work for you. Thanks!
Please verify once and close the issue if this resolved the issue for you. Thanks!

I am totally new to this environment and faced the same problem
may I know if you could solve your problem?

tensorflow/lite/kernels/conv.cc:313 input->dims->size != 4 (3 != 4)Node number 1 (CONV_2D) failed to prepare.
the problem is that I dont have conv2D at all

@giahi Can you please create a new issue with a simple standalone code to reproduce the error? Thanks!

My problem is that 3 dimensions are created when building the model, like this
model = tf.keras.applications.MobileNetV2(include_top=False, weights='imagenet', input_shape=(224 ,224 ,3)), but The data set I provided during the integer quantification is in png format. The 4 dimensions are different from the 3 dimensions of the model.


Question

Hello,
First, I love your work with this plugin. Can I do sth. like /givemoney/80/? Or can I perform any command (like /eco set  80) with feedback?
~kial1

Not at the moment. I am currently working on integrating Vault support but at this moment it is not a feature in the master branch. I am hoping I can finish this feature by the end of this week but no promises.

Do you think of any command support?

I'm not entirely sure what you are asking but if I am correct you are asking about the ability to execute any command. While that is definitely a possibility for a feature it currently isn't and likely won't be as I feel like that is kinda out of the scope of the project, not to mention the security implications if any command can be executed from the endpoint it creates. Unless @phybros has a different vision. If you just need the ability to execute arbitrary commands and get the resulting feedback, you should look into using the built-in RCON protocol that is already installed in your server. Most languages have clients for interacting with the servers RCON.

Would be nice if you can finish the Vault support by the end of this week. Yeah executing commands is not really secure, you are right. Is there also a eta when there will be a auth support with a token or so?
~kial1

I am not the creator of the project and don't know a ton about javalin in general. So that would be a question for @phybros.

I think an endpoint that allows you to run arbitrary commands might be an OK feature, but I would want to force the server admin to whitelist all commands that are allowed. I'm going to close this ticket since it's been answered.


OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

[Enter feedback here]
When I attempt to start the http.server, I get the following error. I have tried running my terminal as admin.
OSError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

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

ID: 4f894a59-0503-d934-947b-723abc207186
Version Independent ID: aa79b6b4-65e6-c89d-4e2f-e5ec73089a95
Content: Use Python and TensorFlow for machine learning in Azure
Content Source: articles/azure-functions/functions-machine-learning-tensorflow.md
Service: azure-functions
GitHub Login: @anthonychu
Microsoft Alias: antchu

This might be a firewall issue. Are you able to run other web apps using Python (like a Flask app, for example)?

Hello @ntimmerman - Just following up here on the above. Let us know if you're still encountering this issue and need further assistance in troubleshooting.

@ntimmerman Since we haven't heard back, we will now proceed to close this thread for now. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.


MGDCTRS-2139 chore: hide pricing tier elements

This change temporarily hides the filter and pricing tier badge from the UI until it's needed.

@gashcrumb WDYT about adding an inline comment about the commented code block

@indraraj I think git blame kinda has that covered as that links to the change which links to the Jira.

...also I figure the next change in here will be to either restore this or remove it.


HIP 55:  Validator Challenges

Author(s): @Vagabond,
@andymck, @abhay
Start Date: 2022-02-03
Category: Technical
Original HIP PR: https://github.com/helium/HIP/pull/359
Tracking Issue: https://github.com/helium/HIP/issues/362 (this)
Status: In Discussion

Summary
This HIP proposes a change to how Proof-of-Coverage (PoC) Challenges are
generated and submitted to the Helium blockchain to allow for further network
scalability and to lower the hardware complexity/cost of Hotspots. Specifically,
it moves the responsibility of PoC Challenge creation to Validators and
consequently proposes moving the economic reward for creating Challenges to this
group as well.
Rendered view
https://github.com/helium/HIP/blob/main/0055-validator-challenges.md

I am very excited to see this draft HIP. Moving challenge creation to validators is a huge step forward today light hotspots.
A couple thoughts to consider with regard to the load on the CG and incentives:

A challenge is going to trigger a lot of requests to the Challenge Validator, which in most cases will be an active CG member. This could add excessive load to the validators in CG. For example, all hotspots in a targeted hex must send a request to the challenge validator to see if it is the challengee. That is an average of 30 and max of >2000 hotspots in a hex. At the current poc interval, there are ~30,000 PoCs per epoch or ~700 challenges per validator. Add in witness counts per Poc and there could easily be tens of thousands of additional requests being made to in CG validators. At the same time, the rest of the validators (98%) remains relatively idle.
In this model, non-CG validators are being tasked with additional work but no additional rewards. There will be little incentive for validators to support light hotspots. I understand that this proposal leaves open future mechanisms like slashing. However, in the interim, I fear we will see validators opting out of providing the gateway service while not in CG if there is not a reward to do so.

Perhaps there could be a way to have the CG generate the challenges but assign other validators not in the CG to perform the work of notifying the challengee, collecting the witnesses, and submitting the blockchain_txn_poc_receipts_v2 transaction to the CG. The rewards from the 0.9% pool should then be given to those validators to provide incentive for them to do so.

My thought on this @anthonyra would be similar to what the authors are already proposing - have the CG pick the hex/hotspot to be challenged, but then also pick an active, non-CG validator to handle the rest of the process of notifying the challengee, collecting receipts and witnesses, and submitting the poc txn to the blockchain - same as described in the HIP. And, reward the non-CG validator doing that work with the challenge creation rewards.
I think the added complexity is that block metadata would have to include not only the target hex, but also the details of the non-CG validator selected to do the rest of the challenge work. Also, there would need to be a mechanism for the CG member to share secret information with the selected non-CG validator including the specific hotspot in the hex and the onion key. This could potentially be encrypted with the non-CG validators public key and included in the block metadata or sent via a p2p connection directly to the non-CG validator.
The last piece of this is knowing whether the non-CG validators are active AND providing the necessary gRPC service to perform the challenge role. I propose adding an optional parameter to the heartbeat transaction that includes the gRPC listen address of the validator. If this is populated and the heartbeat meets the definition of live (i.e. withing 150 blocks of current), then the validator would be eligible to be selected to handle challenges.
CC: @abhay @Vagabond

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.

I think it would be possible for the validators to create challenge information and submit them to the group (vs the group generating them itself), then the challenging validator would remain the sole holder of any private information until the receipt was published. That challenge information could flow through the block metadata as proposed in the HIP but, as noted, would not be tied to a consensus group member under this alternative.
Doing that is now interesting because non-elected validators become invested in providing validation services to the light hotspots so they can maximize their chances of doing challenges. Because the actual challengees are unknown until the block is published, validators would be unwise to favor any specific light gateway connections because they don't know who they may need to communicate with in the future.
Then, as proposed above, the challenging validator would be in charge of constructing and reporting the receipt transaction.

I would also like to make the association of a validator and a light hotspot using that validator a trackable signal on-chain that could be used in election selection criteria down the road. This would help reward strong, reliable validators with good reputations and help align incentives between hotspots and validators if the hotspot owners are given agency over which validators their hotspots are using.

So are we voting on the HIP as written or as @Vagabond described, or just the concept of moving challenge creation (and therefore the need to sync and all the related problems) away from hotspots? I'm definitely in favor of that last thing.

Another important caveat I was thinking about has to do with us shifting these rewards to the CG.
As of right now there's no incentive to have long epochs. Instead they want to have the shortest possible and most elections. If CG members were rewarded for challenges would they split the pot that was collected over the course of an epoch?
If so, that would be ~0.34 HNT per validator per epoch ideally. However, it then incentives the CG to have long epochs because sure they won't be getting the 2HNT ish per election but they can't control that. But what they can control is the length by purposely sabotaging the election. This could be unstuck with a rescue block sure, but I don't think we should provide even the chance to incentivize long epochs.
One option is to only allow challenge creation during the first 30 blocks of an election but then hotspots would get the short end of stick on a purposefully long one or an "issue" that resulted in a long block.

Yes, that's another good point for shifting things to the validator pool rather than the consensus group.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

I would second third and fourth this sentiment. While this change will make for a more efficient network experience for consistency and the uptime of the hotspots, I absolutely do not believe that they should further allocate more share of the rewards to those who share an already disproportionately large portion of these rewards compared to the number of validators. The miners who make up the majority of this network should not have to pay the price for every change in this ecosystem. There really is no need to allocate an additional .9% to Validators in this network unless the message quite blatantly is suggesting that validators should not expect to do anything simply for the betterment of the network, while the regular miners should be expected to prop up the network of the pure goodness of our hearts and pay the price every time in terms of giving up our rewards. This was promoted as the people's network; this type of scenario feels all too similar to the world we already live in where the top 10-1% should benefit on top of their already lucrative advantages, while everyone else pays for them to be there.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works.
While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Hear hear! Very well said. It is extremely concerning.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Exactly this, Helium doesn't need to fall victim to same fault that US politicians do. An bird's eye rebalancing of the network's reward structure is definitely needed after so much development.

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Where do you get 17%?

I am not in favor of moving the Challenger rewards to the Validators. While individually small, it's just another piece of the pie being taken away from Hotspot owners - the very people you asked to grow the network - don't penalize us for it. Instead, reallocate these small rewards back to the reward pool for Beaconing and Witnessing.
Validators already have sufficient staking rewards.
Other than that, I think this will be a great improvement.

This is spot on. Rewards are in the toilet and the last thing we humble hotspot owners need is even more of the pie being taken away. Improve the network yes, but put the rewards back in the daily pool.

Which ever entity of the blockchain is tasked with creating challenges should be rewarded. I highly doubt you're willing to work for free so why should the entity picked to do challenge creations work for free?

This is roughly a 17% raise for Validators - who dominate the vote, based on the way HNT weighting works. While I support the technical aspects of this change, the large wallets typically held by Validators means they have the ability to vote themselves a raise, which calls into question whether they are voting for the change itself or the raise.

Where do you get 17%?

5.2% up to 6.1% - that is a 17% change.

Ahh okay, well the math does check out but I still think it's the better option. I'm a proponent for who ever is left in charge of this work should get rewarded. How that rewarding is done can be negotiated. But a simple 0.9% change makes the most sense to me.
The other option would be to split the 0.9% to all the hotspots and charge the hotspots per challenge created? It'd be better for the challenger though, because hotspots rewards would be affected by network size and halvenings. But the challengers would charge the same rate per challenge.

5.2% up to 6.1% - that is a 17% change.

This isn't right. Validators get 6% of network rewards. So 6% to 6.9% is 15%. The 5.1% is our APY (before costs).
Also, this doesn't mean an individual validator will earn 15% more. When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

When the validator hip was introduced, the goal was to get to at least 100 validators. There are now 3,426 validators. To me, the fact that there are 34x more validators than needed shows that validators already are over-incentivized. So let's not increase the incentive further. Even if 90% of existing validators would drop because of the new work, the network would still be stable.

with regard to the load on the CG and incentives:

The Helium development team has made lots and lots of performance improvements to the validator code. Discovery mode was taken away, so we even have feature loss to lower the load on the validators.
The network didn't take away rewards from validators when the load was lowered, nor when disco mode was removed. Why should the network give validators more rewards now?

When the validator hip was introduced, the goal was to get to at least 100 validators. There are now 3,426 validators. To me, the fact that there are 34x more validators than needed shows that validators already are over-incentivized.

Where did you get 100 validators from? In any case, network security in proof of stake networks is better measured by looking at the percentage of supply staked, which is currently 35%. This is how other proof of stake networks compare (data taken from StakingRewards):

Solana: 75%
Ethereum: 8%
Cardano: 69%
Avalanche: 60%
Terra: 40%
Polkadot: 53%
BNB Chain: 84%
Cosmos Hub: 64%

Helium's current 35% is considerably lower than any other network except Ethereum, which is an outlier because the migration to proof of stake has not actually happened yet. Helium has to pay for miners too, which is means our funding for validators is comparatively low, so I want to rebut the notion that validators are "over incentivised". It just clearly is not the case.
Frankly, I do not really care that much about taking 0.9% more of network rewards. As I have already said, those rewards will buy more validators, they won't improve the bottom line of individual validators. However, the PoC rewards are not some frivolous expenditure that will simply disappear into a black hole of growing validator count, but rather a critical component of the game theoretic assurances that a public blockchains needs to function. That is because the 0.9% will incentivise new behaviour whereby we spread work across non-CG validators. That has to be payed for, otherwise there is no assurance that validators will opt to provide the service.
Any public blockchain must properly leverage economic incentives to remain viable and robust long term. You cannot expect self-interested, pseudonymous strangers on the internet to perform work outside of their self interest. It just won't work. This goes for any actor in any crypto network, including both validators and miners on Helium.
So I get it, you're trying to take care of you income, and that is what I would expect you to do in this scenario. However, I have an eye to the future, and am not looking at this in terms of my income, which won't be much affected in the near term, but I am looking at it in terms of my capital investment. I need Helium to succeed, I need it to attract new miners and to expand the network to improve availability for ends users. To do that, we must make it as robust and scalable as possible, and this HIP is a major component of that effort.

To be clear: I own 0 mining hotspots and 0 validators. So your assumption that I am protecting my income is partly false. I do prefer to protect my investment in the very first OUI though, which is only valuable if the Helium network provides coverage.
Yes, we can push for the Helium Network to be like any other crypto currency. Or we can let the Helium Network do what the network was built for: provide utility in the real world by providing coverage. To provide coverage, we need hotspots. To me, the way to make Helium succeed is to expand the coverage (both in terms of new geographical areas and in terms of new connection types like 5G, wifi, etc). We don't need the validators eating an even bigger share of the value produced by Helium.
So it seems like we both want Helium to succeed. We just have very different ideas of what it takes to succeed.

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

Why? its not like the validators are just going to pack up, cash in their helium and leave. They already have a huge slice of the pie for less work than they did a year ago. Now they have to take on a bit more they should be rewarded? Did they lose some of that slice when they stopped supporting discovery mode? Their workload was reduced but their slice wasn't.

Seamna la fel de mult cu, oameni care ajung sus și muncesc din ce an ce mai puțin pe bani multi.

5.2% up to 6.1% - that is a 17% change.

This isn't right. Validators get 6% of network rewards. So 6% to 6.9% is 15%. The 5.1% is our APY (before costs).
Also, this doesn't mean an individual validator will earn 15% more. When you increase network rewards, more people are attracted to sign up. We'll end up back where we were with the APY, but there'll simply be more validators.

Thank you for refining my numbers. But the point behind that thread is lost when you look at only the numbers. Let me make it again.
I support this HIP on its technical merits and what it means for Hotspots and the network at large. But I detest the idea of HNT weighted voting when part of the discussion involves rewards moving across the boundary between Hotspots and Validators. Validators will always win that vote due to their large wallets.
This HIP is only an improvement for Hotspots (performance), while also taking something away. Validators only stand to gain - or at least suffer no losses. Therefore, Validators should not have a voice in this vote, due to the their influence on the outcome by HNT weighting. Instead, this vote should be Hotspot count weighted. Then if it passes, you'd know that the Hotspot owners (as a group) fully understood the trade and elected to give the 0.9% to the Validators. In its current form, it feels like Validators are taking it and there's nothing we can do about it. If the vote gets too close, a single Validator or a single HNT whale can tip the scale.
It would be interesting to see a histogram of the raw votes by HNT weight. How many raw votes have 100 HNT, 1000, 10000, 100000, etc.?
It would also be interesting to see a histogram of Hotspot count. How many raw votes have 1, 10, 25, 50, 100, 200, etc.?

To provide coverage, we need hotspots

I completely agree, which is why I support this HIP. It makes hotspots much, MUCH more efficient and cheaper to run, meaning that the network can fund more of them with less. Giving validators PoC rewards is a necessary component of that because we have to incentivise the correct behaviour to make it all work.

Why? its not like the validators are just going to pack up, cash in their helium and leave. They already have a huge slice of the pie for less work than they did a year ago. Now they have to take on a bit more they should be rewarded? Did they lose some of that slice when they stopped supporting discovery mode? Their workload was reduced but their slice wasn't.

The validators won't pack up, however there's nothing stopping an operator of a validator from not providing challenges. I know for a fact, if this work isn't rewarded that's exactly what's going to happen. And if there's no challenges being created there's no PoC.
It gets even worse when validators can "pick" the hotspots they serve. So I'd expect challenges won't go away completely they'll just be only created for those the validators want. The counter to this is just to provide the blanketed 0.9% of rewards like today that way they aren't incentivized to play favorites. They'll just create what's needed per block.
Because as it stands, validators would rather hotspots not bother them since their primary job becomes significantly easier. We want to prevent this motive

What prevents validators from playing favorites if they do get the 0.9%?
This is starting to look more and more like a hostage situation.

Based on this morning's numbers (8AM CST on 2/19), 37% of wallets are against this HIP, but due to HNT weighting this is less than 7% against.
Additionally, the displayed 93% approval likely makes those that are against this HIP, unlikely to pay the poll tax to vote, further skewing the results.
If HNT weighting was removed, 37% against is enough to block this HIP.
Because of the huge gap due to HNT weighting and polar opposite outcome, this vote should be cancelled and redesigned.

It's all about numbers, they can still play favorites. But the target hex is based on the block hash. They can't pick challengees. But if the only challengees are those specifically cherry picked by validators that's bad.
If anything your comment here suggests that the 0.9% might not be enough to prevent this "favoritism".

In the light of yesterdays AMA discussion I'm a bit confused regarding validators and the terminology used in the HIP55: In the basic a non-staked validator (ie just running the validator software) is also a validator. So my question is; do the validators that light-hotspots connect to need to be staked?
My proposal would be to figure out a architecture where validators that light-hotspots connect to don't need to be staked. Light-hotspot operators should be able to select trust-worthy light-hotspot-serving-validators.
Additionally I think that there should be some thought around the direct-connection of light-hotspots to consensus-group members for delivering reports. I think this is a sub-optimal architecture and a way should be found to exchange those messages via gossip, removing a direct-connection requirement to CG members. It would be very easy to connection-starve a CG-member.

Additionally I think that there should be some thought around the direct-connection of light-hotspots to consensus-group members for delivering reports. I think this is a sub-optimal architecture and a way should be found to exchange those messages via gossip, removing a direct-connection requirement to CG members. It would be very easy to connection-starve a CG-member.

Agreed. @Vagabond, @PaulVMo and @anthonyra outlined a way to offload work to non-CG members above. Scroll up a bit.

So my question is; do the validators that light-hotspots connect to need to be staked?

Yes, they need to be staked.

Yes, they need to be staked. The language could be improved a bit to make the distinction between a validator and a chain-follower clearer.

I understand that there's some trust placed in light-hotspot-connecting validators, but wouldn't it be better to have non-staked or less-staked light-hotspot-serving-validators? This would make it easier to scale out the light-hotspot-serving stack while not risking performing bad and getting penalties while in the CG because you still have to serve those light-hotspots.

I agree that does sound like a pretty good idea. The 0.9% could be used to incentivise a new, small class of PoC challengers with a low stake, say 100 HNT.

but wouldn't it be better to have non-staked or less-staked light-hotspot-serving-validators?
Agree with the less-staked part.

We have to be careful to not let the system be easily gamed.  Does that friction have to be 10,000 HNT? I don't think so, it's certainly easier to make the existing validators do this, but a new class of node with a small stake (or some other source of friction) seems like a good way to let more folks spin these up.

So what does this actually mean for people owning a miner? How much less will we get? Because I recently acquired a hotspot and my placing is good, still rewards are pretty disappointing. Now they are getting even lower? I'm starting to think I'm better off selling the thing for a profit now.
Also just checked the votes, 99.6% in favor of this? How?
Are the hotspot owners even voting?
BTW they charge HNT to vote? I barely have 2 HNT after a month of "mining" so yeah looking at these odds I rather keep it than vote for jack...

I continue to have a massive issue with the way these HIPs are developed amd then voted upon. Apart from yelling your thoughts into the forest on Github or Discord, not knowing if your ideas are even heard, the normal hotspot owner has no way of really influencing these HIPs. Then they suddenly go to take-it-or-leave-it votes with a few large wallets determining the outcome, despite many detail questions still being unanswered. This is a pseudo-democracy and a PERFECT setup for wallet-biased network development into the future.
On that note, why not allow hotspots to vote themselves into our out of the challenge creation process? Why render 500'000 mini-computers useless (plus the hundreds of thousands currently on order), especially with the current chip shortage? That's a massive waste.
If I have well-performing "heavy" hotspot with good backhaul bandwidth, I may not mind the workload and may want to share in the 0.9% HNT allocation. If I prefer to buy a cheaper hotspot or have issues with my cell backhaul data usage, I may forego that income and opt out.
Heavy hotspots that opt in should be equal to validators when it comes to challenge creation.
This gives hotspot owners a choice and helps to counteract all the centralization trends we've been seeing in the Helium network.

I continue to have a massive issue with the way these HIPs are developed amd then voted upon. Apart from yelling your thoughts into the forest on Github or Discord, not knowing if your ideas are even heard, the normal hotspot owner has no way of really influencing these HIPs. Then they suddenly go to take-it-or-leave-it votes with a few large wallets determining the outcome, despite many detail questions still being unanswered. This is a pseudo-democracy and a PERFECT setup for wallet-biased network development into the future.
On that note, why not allow hotspots to vote themselves into our out of the challenge creation process? Why render 500'000 mini-computers useless (plus the hundreds of thousands currently on order), especially with the current chip shortage? That's a massive waste.
If I have well-performing "heavy" hotspot with good backhaul bandwidth, I may not mind the workload and may want to share in the 0.9% HNT allocation. If I prefer to buy a cheaper hotspot or have issues with my cell backhaul data usage, I may forego that income and opt out.
Heavy hotspots that opt in should be equal to validators when it comes to challenge creation.
This gives hotspot owners a choice and helps to counteract all the centralization trends we've been seeing in the Helium network.

Quite a clever and fair suggestion to resolve/solve this whole .9% allocation dilemma. I can only hope that the ones responsible for this project are as reasonable when it comes re-envisioning the way we vote in this ecosystem, as well as exploring a new weighted system voting perhaps.
This idea certainly has true decentralized fairness in mind.

The HIP has been approved via heliumvote, with 96.3% voting For HIP 55.
On behalf of the DeWi, the HIP Editors, and the wider Helium community, I am marking this proposal as approved and recommending that the coredev team implement the necessary changes as soon as reasonably possible.

When will the HIP 54 and HIP 55 come in action and the hotspots will no longer be relayed @edakturk14 @hiptron

Hardware is currently active on Testnet.
For most up-to-date timelines on light hotspot rollout, please refer to https://docs.helium.com/mine-hnt/light-hotspots/#development-timelines


djdjz7.Cloudsnote version <IP_ADDRESS>

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?
[x] This PR only modifies one (1) manifest
[x] Have you validated your manifest locally with winget validate --manifest <path>?

[x] Does your manifest conform to the 1.4 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

@microsoft-github-policy-service agree [company="Kubix"]

@microsoft-github-policy-service agree

Automatic Validation ended with:

Installation failed with exit code -2146762487 2023-04-23 23:09:45.524 [CORE] Deployment operation #0: error 0x800B0109: The root certificate of the signature in the app package or bundle must be trusted.
2023-04-23 23:09:45.524 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(161)\WindowsPackageManager.dll!582213F2: (caller: 581B3932) Exception(1) tid(15d0) 800B0109 A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Hi @didjz7,
How was this package signed? For best results, packages should be digitally signed. If it's self-signed or with a certificate local to a domain, corporation, or other closed group, please consider using a local manifest (WinGet install --manifest C:\path\to\manifest\files) for local installations.

This package is self signed.
Is self signed packages not accepted in this repo?

This package is self signed. Is self signed packages not accepted in this repo?

Indirectly, unfortunately. It has some discussion.

Packages basically have to be available for anonymous users to download and install from almost any location.
Signing gives a "tamper proof seal" on the package, a way to verify that the bits committed by the developer are the same as received by the user, regardless of identity or location.

Well then, thanks anyway. I will close this PR.


NavigationView display bug when use a transparent color as pane color

Describe the bug
NavigationView displays another color on the left or right side of the pane when use a transparent color as pane color
Steps to reproduce the bug

Add a new NavigationView
Custom Pane Color in the App.Xaml like this:

<SolidColorBrush x:Key="NavigationViewDefaultPaneBackground" Color="#CF000000"/>
<SolidColorBrush x:Key="NavigationViewExpandedPaneBackground" Color="#CF000000"/>

Run the application

Expected behavior
NavigationView should dispaly the pane with a single color as we set.
Screenshots

Version Info
NuGet package version:
Microsoft.UI.Xaml 2.2.190917002

Windows 10 version
Saw the problem?

Insider Build (xxxxx)

May 2019 Update (18362)
Yes

October 2018 Update (17763)

April 2018 Update (17134)

Fall Creators Update (16299)

Creators Update (15063)

Device form factor
Saw the problem?

Desktop
Yes

Mobile

Xbox

Surface Hub

IoT

Additional context

@yanshouwang what you're seeing is actually expected behavior. Depending on NavigationView's mode (Minimal, Compact) the layers underneath the Pane vary. In Compact mode, the Content panel is pushed to the right because the Pane panel will always take up some amount of width, whether the Pane is open or closed. The same is not true in Minimal mode because, in that case, the closed Pane takes up no space. Because you've set the alpha of the Pane's background color to be transparent, some of this underlying structure becomes visible.
Can you tell me more about the scenario you're trying to accomplish? The widths in your screenshots are not what I expected to see - are you overwriting some of the control's properties?
By changing the value of NavigationViewExpandedPaneBackground you're removing the acrylic that draws by default. Is that intentional?

@YuliKl I only set "IsTitleBarAutoPaddingEnabled" and "IsBackButtonVisible" and override the Pane's background.
My scenrario is that actually I want to set the pane's background with an acrylic brush and set a transparent color as it's fallback color, so when the window is inactive, the pane will show the fallback color.
So if this is a expected behavior I think maybe the Docs should write something to clear that not to use a color with alpha as the arcylic brush when using it as NavView's PaneBackground :)

Thank you for the explanation. Agreed that we should make this information clear in our documentation, so reactivating this issue to track a doc update.


Flip the range for fade-out

Previously, fading in tiles went from 0.0 --> 1.0 and fading out tiles went from 1.0 --> 0.0. When these values are used to threshold a dither texture in a renderer, this small discrepancy might cause floating point disagreement between fading in tiles and fading out tiles. So instead, we now want fading in and fading out tiles to have the exact same dither threshold (fade percentage) and simply invert the resulting sample if it is fading out. Since the dither texture is sampled in screen-space, this allows the fading out tiles and fading in tiles to blend together perfectly without appearing transparent.
@kring came up with the idea and it works quite nicely!

@kring Thanks for spotting that, I just simplified the logic that keeps fading out tiles from being unloaded. Now it just checks if a tile is in the fading-out list (actually an unordered_set) before deciding to unload it. The logic seems cleaner, the memory leak is fixed, and the extra std::unordered_set::find call looks fast enough in the profiler. What do you think?

That sounds good to me, thanks @nithinp7!


Build status callback for mxbuild error output & refactor / add tests

@jtwaleson @djvdorp take a look when you have time :)

LGTM :+1: !


Add config reloading command

Fixes #44
New command: config
Prints the current configuration

New command: config reload

Reloads the .mementorc file, and reboots the server.
All options can be updated at runtime. Including the port and the cache directory!

Codecov Report

Merging #58 into master will decrease coverage by 5.12%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master      #58      +/-   ##
==========================================
- Coverage    99.1%   93.98%   -5.13%
==========================================
  Files          22       22
  Lines         449      449
  Branches       45       45
==========================================
- Hits          445      422      -23
- Misses          1       27      +26
+ Partials        3        0       -3

Impacted Files
Coverage Δ

src/infrastructure/service/index.ts
0% <0%> (-100%)
:arrow_down:

src/domain/usecase/index.ts
0% <0%> (-100%)
:arrow_down:

src/application/http/request/index.ts
0% <0%> (-100%)
:arrow_down:

src/application/http/request/handler.ts
0% <0%> (-82.36%)
:arrow_down:

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a7e2f19...6520602. Read the comment docs.


fix(TDI-44393) : fix tSnowflakeOutputBulk regression

What is the current behavior? (You can also link to an open issue here)
https://jira.talendforge.org/browse/TDI-44393
Fix after TUJ failing for https://jira.talendforge.org/browse/TDI-44393
What is the new behavior?
tSnowflakeOutputBulk & tSnowflakeBulkExec and tSnowflakeOutputBulkExec don't fail anymore.
'ue schema date pattern' has been hidden in tSnowflakeBulkExec.
Backport from maintenance/0.28 to master.
Please check if the PR fulfills these requirements

[x] The commit message follows Talend standard
[ ] Tests for the changes have been added (for bug fixes / features)
[ ] Docs have been added / updated (for bug fixes / features) ?
[ ] The code coverage on new code >75%
[ ] The new code does not introduce new technical issues (sonar / eslint)

What kind of change does this PR introduce?

[x] Bugfix
[ ] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build / CI related changes
[ ] Other... Please describe:

Does this PR introduce a breaking change?

[ ] Yes
[ ] No

If this PR contains a breaking change, please describe the impact and migration path for existing applications: ...
Other information:

Pull request test result: success :star:


Upgrade Truth 1.4.2 -> 1.4.3

This PR contains the following updates:

Package
Type
Update
Change

Truth
compile
patch
1.4.2 -> 1.4.3

Release Notes

google/truth (Truth)
v1.4.3: 1.4.3
Compare Source

Added more nullness information to our APIs (in the form of JSpecify annotations). This could lead to additional warnings (or even errors) for users of Kotlin and other nullness checkers. Please report any problems. (ee680cb)
Deprecated Subject.Factory methods for Java 8 types. We won't remove them, but you can simplify your code by migrating off them: Just replace assertAbout(foos()).that(foo) with assertThat(foo) (or about(foos()).that(foo) with that(foo)). (59e7a50)

[ ] If you want to rebase/retry this PR, check this box

Suggested commit message:
Upgrade Truth 1.4.2 -> 1.4.3

See:
- https://github.com/google/truth/releases/tag/v1.4.3
- https://github.com/google/truth/compare/v1.4.2...v1.4.3


Updating committer page on samza.apache.org

Giving more screen time for currently active Apache Samza committers (no JIRA)

@nickpan47 Can you please take a look?


Merge jerry_get_value_without_error and jerry_value_clear_error_flag

JerryScript-DCO-1.0-Signed-off-by: Istvan Miklos<EMAIL_ADDRESS>

Thank you for the reviews, I updated the PR with these changes.

Related issue #2213

I updated the PR. Thanks for the reviews.


ID should not be part of the WorkItem PUT/PATCH Payload model

When a Workitem is created it's given ID workitems/:id. To GET a WorkItem you invoke http GET on the id workitems/:id. When you want to update a WorkItem, you should talk to the Resource via the ID workitems/:id.
GET "/workitems" - collection
POST  "/workitems" - create a single workitem
GET "/workitems/id" - single workitem
PUT/PATCH "/workitem/id" - update the fields/content of a single workitem

Similar to #95 .

Instead of doing put api/workitem with payload { ID: 35, Name: "asdf", ...} you would use /api/workitem/35/ with payload { Name: "asdf", ...}


Make cookie policy link relative

Description

Change footer cookie policy link to be relative to domain.
Add integration test to prevent this being an issue in the future
Related Issue

Motivation and Context

Checklist

[ ] An ADR
[x] New and/or updated tests
[x] Changes log in CHANGELOG

Deployment has happened https://connecting-to-services-pr-611.nhswebsite-integration.nhs.uk/find-a-pharmacy/
Not sure why check is not being updated.


Ansible 2.9 bug with php-versions 'Define PHP variables' task

Issue Type

Bug Report / Support Request

Your Environment
N/A
Your OS

Any

Full console output
TASK [geerlingguy.php-versions : Define PHP variables.] ************************
934ok: [localhost] => (item={'value': u'__php_extension_conf_paths', 'key': u'php_extension_conf_paths'})
935ok: [localhost] => (item={'value': u'__php_fpm_daemon', 'key': u'php_fpm_daemon'})
936ok: [localhost] => (item={'value': u'__php_uploadprogress_module_path', 'key': u'php_uploadprogress_module_path'})
937ok: [localhost] => (item={'value': u'__php_xhprof_module_path', 'key': u'php_xhprof_module_path'})
938fatal: [localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'php_fpm_conf_path' is undefined\n\nThe error appears to be in '/var/www/drupalvm/provisioning/roles/geerlingguy.php-versions/tasks/main.yml': line 8, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Define PHP variables.\n  ^ here\n"}

Summary
On Debian/Ubuntu base boxes, the above error results after updating to the latest version of the geerlingguy.php-versions role, if you're running the latest stable version of Ansible (2.9.0).
This seems like it could be related to an upstream Ansible bug/issue, https://github.com/ansible/ansible/issues/64169
Basically, for some reason, the php_fpm_conf_path variable is undefined in the geerlingguy.php-versions role.

Just pushed a possible fix; needed to use the role-defined variable in the definition of the other role-defined variable. Although I'm a little worried that some variable scoping issues might crop up in Ansible 2.9.x :/

That bug is fixed, now hitting a Varnish role error with a missing filter in Ansible 2.9: https://github.com/geerlingguy/ansible-role-varnish/issues/90


🐛 Bug Report — Runtime APIs -- Fetch extremely slow and errors

Running the example fetch from docs errors and is extremely slow, both deployed and when run with wrangler and leaves errors in log.
async function getJson() {
  const url = "https://jsonplaceholder.typicode.com/todos/1";

  // gatherResponse returns both content-type & response body as a string
  async function gatherResponse(response: any) {
    const { headers } = response;
    const contentType = headers.get("content-type") || "";
    if (contentType.includes("application/json")) {
      return { contentType, result: JSON.stringify(await response.json()) };
    }
    return { contentType, result: response.text() };
  }

  const response = await fetch(url);
  const { contentType, result } = await gatherResponse(response);

  const options = { headers: { "content-type": contentType } };
  return new Response(result, options);
};

console.log("Get JSON");
const json = await getJson();
console.log("Got JSON");

Takes multiple seconds to return.
Get JSON
✘ [ERROR] Uncaught (async) Error: internal error

Got JSON

Tried various other URLs, and it's slow regardless of the endpoint. Why is fetch slow and returning errors?
My end goal is to just fetch something from r2, but it's so slow its unusable.

Here:
 return { contentType, result: response.text() };

You are missing an await, it should be:
return { contentType, result: await response.text() };

Additionally note that this line:
  return { contentType, result: JSON.stringify(await response.json()) };

seems to be needlessly parsing the JSON and re-serializing it, wasting time, although not much time if the JSON is short.

[ERROR] Uncaught (async) Error: internal error

I cannot reproduce any error. The code seems to function fine (except it returns the text [object Promise] in the non-JSON case).

Takes multiple seconds to return.

I cannot reproduce this, the code seems to be dominated by the time it takes to contact the origin server (which even then is well under 1s). Less than 1ms CPU time used. Perhaps there is something wrong with your internet connection?


Error: [Polly] [adapter:xhr] XHR global not found.

Description
I use TestCafe for the execution of my tests but i get the following error even if the XHR adapter is registered.
Should polly.js be compatible with TestCafe?
I have tried to find other users with similar error but no results.
Error: [Polly] [adapter:xhr] XHR global not found.
Error Message & Stack Trace
      Error: [Polly] [adapter:xhr] XHR global not found.
      Browser: HeadlessChrome 73.0.3683 / Windows 10.0.0

         1 |export default function(msg, condition) {
         2 |  if (!condition) {
       > 3 |    throw new Error(`[Polly] ${msg}`);
         4 |  }
         5 |}
         6 |

         at Object.assert (...\@pollyjs\utils\src\utils\assert.js:3:11)
         at XHRAdapter.assert (...\@pollyjs\adapter\src\index.js:207:5)
         at XHRAdapter.assert [as onConnect] (...\@pollyjs\adapter-xhr\src\index.js:16:10)
         at XHRAdapter.onConnect [as connect] (...\@pollyjs\adapter\src\index.js:44:12)
         at Polly.connect [as connectTo] (...\@pollyjs\core\src\polly.js:269:13)
         at connectTo (...\@pollyjs\core\src\polly.js:165:50)
         at Polly.forEach [as configure] (...\@pollyjs\core\src\polly.js:165:26)
         at new configure (...\@pollyjs\core\src\polly.js:49:10)

Config
Copy the config used to setup the Polly instance:
import { Polly } from '@pollyjs/core';

 const FetchAdapter = require('@pollyjs/adapter-fetch')
 const XHRAdapter   = require('@pollyjs/adapter-xhr')
 const FSPersister = require('@pollyjs/persister-fs')
.....

  const polly = new Polly('Hello Polly', {
    adapters: ['xhr'],
    persister: 'fs',
    logging: true
  });

    polly.configure({ recordIfMissing: true,
    persisterOptions: {
      fs: {
        recordingsDir: '__recordings__'
      }
    }
  });

});

Dependencies
Copy the @pollyjs dependencies from package.json:
{
    "@pollyjs/adapter-fetch": "^2.3.1",
    "@pollyjs/adapter-xhr": "^2.3.0",
    "@pollyjs/core": "^2.3.0",
    "@pollyjs/persister-fs": "^2.1.0",
    "@types/pollyjs__core": "^2.3.0"
}

Environment
Node.js v10.13.0
win32 10.0.17763
npm: 6.4.1
yarn: 1.13.0

Im not familiar with TestCafe but I'm assuming that the browser context is not within the same one as the one the polly instance is running on. The fetch adapter currently supports passing it a context:
new Polly('Recording Name', {
  adapters: ['fetch'],
  adapterOptions: {
    fetch: { context }
  }
});

Where the context is where polly should fine the necessary globals to override. Does TestCafe give you access to the running browser window?

Closing as the issue went stale.


Fix "better" event sorting

Using Consistently in the tests should prevent the issue from coming back.

Probably shouldn't just re-test this after I just remarked that we should all treat flakey tests with more care...
• [FAILED] [50.770 seconds]
Test status sync with multiple templates [AfterEach]
/home/runner/work/governance-policy-status-sync/governance-policy-status-sync/governance-policy-status-sync/test/e2e/case3_multiple_templates_test.go:62
  Should not set overall compliancy to compliant
  /home/runner/work/governance-policy-status-sync/governance-policy-status-sync/governance-policy-status-sync/test/e2e/case3_multiple_templates_test.go:85

  Begin Captured GinkgoWriter Output >>
    STEP: Creating a policy on hub cluster in ns:managed 10/05/22 17:22:22.077
    STEP: Creating a policy on managed cluster in ns:managed 10/05/22 17:22:22.51
    STEP: Generating an event doesn't belong to any template 10/05/22 17:22:22.689
    STEP: Checking if policy status consistently nil 10/05/22 17:22:22.703
    STEP: Deleting a policy on hub cluster in ns:managed 10/05/22 17:22:42.704
  << End Captured GinkgoWriter Output

  Timed out after 30.001s.
  Expected
      <*errors.errorString | 0xc0001c1a00>: {
          s: "list size doesn't match, expected 0 actual 1",
      }
  to be nil
  In [AfterEach] at: /home/runner/go/pkg/mod/open-cluster-management.io/governance-policy-propagator@v0.8.0/test/utils/utils.go:188


RunTimeError during analysis of hls .ts chunk

/mpeg2ts.rb:207:in `processAdaptationField': not supported adaptation field (RuntimeError)
from /mpeg2ts/mpeg2ts.rb:418:in `processMPEG2TSBlock'
from /mpeg2ts/mpeg2ts.rb:450:in `block in <main>'
from /mpeg2ts/mpeg2ts.rb:443:in `open'
from /mpeg2ts/mpeg2ts.rb:443:in `<main>'

I'm running on OSX 10.9.5 and trying to analyze a .ts file from an instance of wowza 4.1.x.
$ ruby -v
ruby 2.0.0p481 (2014-05-08 revision 45883) [universal.x86_64-darwin13]
The rest of the output looks sane as it seems to be describing the details of the PES and related fields successfully.

Hi,
Thanks for the feedback. So as I understand, it gives error but keeps working and actually performs the analysis, is that what you mean?
Thank you.

No, it appears to fail after it scrapes the initial container metadata.
$ ruby ~/mpeg2ts.rb media_w1762149747_140113.ts
"Elementary Stream Description {"
" PID=258"
" TYPE=21"
" TYPE_DESC=Metadata carried in PES packets"
" DESC=[38, 13, 255, 255, 73, 68, 51, 32, 255, 73, 68, 51, 32, 0, 15]"
"}"
"Elementary Stream Description {"
" PID=256"
" TYPE=27"
" TYPE_DESC=AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video"
"}"
"Elementary Stream Description {"
" PID=257"
" TYPE=15"
" TYPE_DESC=ISO/IEC 13818-7 Audio with ADTS transport syntax"
"}"
/mpeg2ts.rb:207:in processAdaptationField': not supported adaptation field (RuntimeError) 	from /mpeg2ts.rb:418:in processMPEG2TSBlock'
from /mpeg2ts.rb:450:in block in <main>' 	from /mpeg2ts.rb:443:in open'
from /mpeg2ts.rb:443:in `'

Got it. Can you also send media_w1762149747_140113.ts or similar file so we could reproduce the issue?

Sure.
On Oct 2, 2015 1:07 AM, "WMSPanel team"<EMAIL_ADDRESS>wrote:

Got it. Can you also send media_w1762149747_140113.ts or similar file so
we could reproduce the issue?
—
Reply to this email directly or view it on GitHub
https://github.com/WMSPanel/mpeg2ts/issues/2#issuecomment-144952829.

If you need the playlist as well, I can provide that. In the interim, here is the .ts chunk.
Michael
On Oct 2, 2015, at 1:07 AM, WMSPanel team<EMAIL_ADDRESS>wrote:

Got it. Can you also send media_w1762149747_140113.ts or similar file so we could reproduce the issue?
—
Reply to this email directly or view it on GitHub.

I'm sorry, I don't see chunks attached to this ticket.

My apologies... I guess the attachment didn't work last time. Since gh doesn't allow uploading zip files, I've dumped a set of chunks onto dropbox. The *_ao.m3u8 and related files are supposedly audio only. For this conversation, I wouldn't worry about those as I'm only trying to test the playlist.m3u8 at the moment.
https://www.dropbox.com/s/npepkg3cw07mqgp/feed01.zip?dl=0


Speaker Recognition API returns bad request with no further message

Hi
I am sending my wav file to api see below
RequestMessage	{Method: POST, RequestUri: 'https://westus.api.cognitive.microsoft.com/spid/v1.0/identificationProfiles/034f5efa-a536-4d9b-a90f-38686c8eb263/enroll?shortAudio=True', Version: 1.1, Content: System.Net.Http.MultipartFormDataContent, Headers:
{
Ocp-Apim-Subscription-Key: 72d89b96c4434b7ba8377b51aaaeb211
Content-Type: multipart/form-data; boundary="54a6b99e-b621-4c65-b445-08476656aec2"
Content-Length: 223
}}	System.Net.Http.HttpRequestMessage
I get the ff in return
clientResponse	{StatusCode: 400, ReasonPhrase: 'Bad Request', Version: 1.1, Content: System.Net.Http.StreamContent, Headers:
{
Pragma: no-cache
apim-request-id: e82122b7-4dc1-4a96-bd51-7be46dc05a7e
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff
Cache-Control: no-cache
Date: Tue, 18 Apr 2017 12:50:28 GMT
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Content-Length: 83
Content-Type: application/json; charset=utf-8
Expires: -1
}}	System.Net.Http.HttpResponseMessage
Kindly help

I am facing the same issue. Does anyone know the solution?


[Task]  Find a not yet tested class or list of function in an already tested class that is not yet tested in thenewboston-js project (bug bounty paid per issue reported)

Task
Contributors are able to complete this task and earn thenewboston coins.  Check out the labels to learn how much you can earn for contributing by completing this task.  Please make sure to be honest if you wish to contribute by saying you can't finish this and we can just un-assign you with no harm done!  There is no point in delaying tasks from being completed for miscommunication!

Overview
Some classes and methods in thenewboston-js library are missing tests (Unit tests). To earn TNBC, find a not tested class or list of function in an already tested class that is not yet tested in thenewboston-js repository and report an issue following the format here https://github.com/thenewboston-developers/Website/issues/1357
Once you create an issue that complies with information here and it is not duplicate, the bounty will be assigned (250 tnbc) for each task created
Link the task you created via commenting on this issue, the URL of the task
Note: Please try not to create duplicates
Behavior

Each issue should be specific to a class;
All untested methods in class to be listed in issue;
Find test samples from existing tests and include links to the sample file.

Please ask for this task to be assigned to you and earn and its sweet reward 😉
Remember to include your account number in your PR description for us to pay you 💰

I will work on this

@dras51 any updates about this?

#153


Full test Plan for UI Admin uer

Note: for User role test exclude after Account/User feature, for DomainAdmin role exclude after Infrastructure (except for Offerings)
Common

[X] Project selector
[X] Language selector
[X] Notifications / clear notifications
[X] Paginations
[X] Profile
[X] Help
[X] Logout
[X] Context-sensitive help

Dashboard

[X] Fetch latest (only on Admin dashboard)
[X] View hosts in alert state
[X] View alerts
[X] View events

Compute > Instances

[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Links
[X]    Filter by
[X]    Create new instance

Compute > Kubernetes
This requires configuring and setting up CKS: http://docs.cloudstack.apache.org/en/latest/plugins/cloudstack-kubernetes-service.html

[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Links
[X]    Filter by
[X]    Add Kubernetes cluster
[X]    Start/stop a Kubernetes cluster
[X]    Scale Kubernetes cluster
[X]    Upgrade Kubernetes cluster
[X]    Delete Kubernetes cluster

Compute > Instances > selected instance

[X]    View console
[X]    Reboot instance
[X]    Update instance
[X]    Start/Stop instance
[X]    Reinstall instance
[X]   Take snapshot
[X]    Assign VM to backup offering
[X]    Attach ISO
[X]    Scale VM
[X]    Migrate instance to another host
[X]    Change affinity
[X]    Change service offering
[X]    Reset Instance Password
[X]    Assign Instance to Another Account (VM must be stopped)
[X]    Network adapters
[X]    Add network to VM
[X]    Set default NIC
[X]    Add/delete secondary IP address
[X]    Delete VM network
[X]    Settings
[X]    Add setting
[X]    Update setting
[X]    Delete setting
[X]    Add / delete comment
[X]    Add / delete tags
[X]    Links

Compute > Instance groups

[X]    Search
[X]    Sort
[X]    Links
[X]    New instance group

Compute > Instance groups > selected instance group

[X]   Links
[X]   Update instance group
[X]   Delete instance group

Compute > SSH Key Pairs

[X]    Search
[X]    Sorting
[X]    Links
[X]    New SSH key pair

Compute > SSH Key Pairs > selected SSH key pair

[X]    Links
[X]    Delete SSH key pair

Compute > Affinity Groups

[X]    Search
[X]    Sort
[X]    Links
[X]    New affinity group

Compute > Affinity Groups > selected affinity group

[X]    Links
[X]    Delete affinity group

Storage > Volumes

[X]    Basic earch
[X]    Extended search
[X]    Sort
[X]    Links
[X]    Create volume
[X]    Upload local volume
[X]    Upload volume from URL

Storage > Volumes > selected volume

[X]    Detach volume
[X]    Take snapshot
[X]    Recurring snapshot
[X]    Resize volume
[X]    Migrate volume
[X]    Download volume
[X]    Delete volume
[X]    Links
[X]    Add/delete tags

Storage > Snapshots

[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Links

Storage > Snapshots > selected snapshot

[X]    Links
[X]    Add/delete tags
[X]    Create template
[X]    Create volume
[X]    Revert snapshot
[X]    Delete snapshot

Storage > VM Snapshots

[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Links

Storage > VM Snapshots > selected snapshot

[X]    Links
[X]    Add/delete tags
[X]    Revert VM snapshot
[X]    Delete VM snapshot

Network > Guest networks

[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Links
[X]    Add network

Network > Guest networks > selected network

[X]    Links
[X]    Add/delete tags
[X]    Update network
[X]    Restart network
[X]    Delete network
[X]    Acquire new IP (only for isolated networks)
[X]    Replace ACL list(only for VPC isolated networks)
[X]    Delete public IP address (only for isolated networks)
[X]    Add/delete egress rule (only for isolated networks)

**Network > VPC **

[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Links
[X]    Add VPC

Network > VPC > selected VPC

[X]    Links
[X]    Update VPC
[X]    Restart VPC
[X]    Delete VPC
[X]    Networks
[X]    - Links
[X]    - Paginations
[X]    - Add network
[X]    - Add internal LB
[X]    Public IP addresses
[X]   - Links
[X]    - Pagination
[X]    - Select tier
[X]    - Acquire new IP
[X]    - Delete IP address
[X]    Network ACL Lists
[X]    - Links
[X]    - Pagination
[X]    - Add network ACL list
[X]    Private Gateways
[X]    - Links
[X]    - Pagination
[X]    - Add private gateway
[X]    VPN Gateway
[X]   - Links
[X]    VPN Connections
[X]    - Links
[X]   - Pagination
[X]    - Create Site-to-site VPN connection
[X]    Virtual routers
[X]    - Links
[X]    Add/delete tags

Network > Security groups

[X]    Search
[X]    Sort
[X]    Links
[X]    Add security group

Network > Security groups > selected security group

[X]    Links
[X]    Add/delete tags
[X]    Add ingress rule by CIDR
[X]    Add ingress rule by Account
[X]    Ingress rule - add/delete tags
[X]    Ingress rule - delete
[X]    Add egress rule by CIDR
[X]    Add egress rule by Account
[X]    Egress rule - add/delete tags
[X]    Egress rule - delete
[X]    Ingress/egress rules pagination

Network > Public IP Addresses

[X]    Search
[X]    Sort
[X]    Links
[X]    Acquire new IP

Network > Public IP Addresses > selected IP address

[X]    Links
[X]    Add/delete tags
[X]    Enable/Disable static NAT
[X]    Release IP
[X]    Firewall - add rule
[X]    Firewall rule - add/delete tags
[X]    Firewall rule - delete
[X]    VPN - Enable/Disable VPN
[X]    VPN - Manage VPN Users

Network > VPN Users

[X]    Links
[X]    Search
[X]    Sort
[X]    Add VPN user

Network > VPN Users > selected VPN user

[X]    Links
[X]    Delete VPN User

Network > VPN Customer Gateway

[X]    Links
[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Add VPN Customer Gateway

Network > VPN Customer Gateway > selected gateway

[X]    Links
[X]    Edit VPN Customer Gateway
[X]    Delete VPN Customer Gateway
[X]    Add/delete tags - Xen do they support it ?

Images > Templates

[X]    Links
[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Change order (move to the top/bottom, move one row up/down)
[X]    Register template
[X]    Upload local template

Images > Templates > selected template

[X]    Links
[X]    Add/delete tags
[X]    Edit template
[X]    Copy template
[X]    Update template permissions
[X]    Delete template
[X]    Download template
[X]    Zones pagination
[X]    Settings - add/edit/remove setting

Images > ISOs

[X]    Links
[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Change order (move to the top/bottom, move one row up/down)
[X]    Register ISO
[X]    Upload local ISO

Images > ISOs > selected ISO

[X]    Links
[X]    Add/delete tags
[X]    Edit ISO
[X]    Download ISO
[X]    Update ISO permissions
[X]    Copy ISO
[X]    Delete ISO
[X]    Zones - pagination

Images > Kubernetes ISOs

[X]    Links
[X]    Basic search
[X]    Sort
[X]    Refresh
[X]    Pagination
[X]    Enable/Disable
[X]    Add Kubernetes Version

Projects

[X]    Links
[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Switch to project
[X]    New project

Projects > selected project

[X]    Links
[X]    Add/delete tags
[X]    Edit project
[X]   Suspend/Activate project
[X]    Add account to project
[X]    Accounts - Make account project owner
[X]    Accounts - Remove account from project
[X]    Delete project
[X]    Accounts - pagination
[X]    Resources - edit

Events

[X]    Links
[X]    Basic search
[X]    Extended search
[X]    Sort
[X]    Archive event
[X]    Delete event

Events > selected event

[X]    Links
[X]    Archive event
[X]    View event timeline
[X]    Delete event

Users

[X]    Links
[X]    Search
[X]    Sort
[X]    Add user

Accounts

[X]    Links
[X]    Search
[X]    Sort
[X]    Add account
[X]    Add LDAP account

Accounts > selected account

[X]    Links
[X]    Update account
[X]    Update resource count
[X]    Disable/enable account
[X]    Lock/unlock account
[X]    Add certificate
[X]    Delete account
[X]    Settings

Users > selected user

[X]    Links
[X]    Edit user
[X]    Change password
[X]    Generate keys
[X]    Disable/enable user
[X]    Delete user
[X]    Copy API Key
[X]    Copy Secret Key

Domains

[X]    Search
[X]    Expand/collapse
[X]    Add/delete note
[X]    Add domain
[X]    Edit domain
[X]    Delete domain
[X]    Update resource count
[X]    Link domain to LDAP Group/OU
[X]    Settings

Roles

[X]    Links
[X]    Search
[X]    Sort
[x]    Create role

Roles > selected role

[X]    Edit role
[X]    Delete role
[X]    Rules - add new rule
[X]    Rules - modify rule
[X]    Rules - delete rule
[X]    Rules - change rules order

Infrastructure > Summary

[X]    Links
[X]    Setup SSL certificate

Infrastructure > Zones

[X]    Links
[X]    Search
[X]    Sort
[X]    Pagination
[X]    Add zone

Infrastructure > Zones > selected zone

[X]    Links
[X]    Edit zone
[X]    Enable/disable zone
[X]    Enable/disable out-of-band management
[X]    Enable HA (disable?)
[X]    Add VMWare datacenter
[X]    Delete zone
[X]    Settings - edit

Infrastructure > Pods

[X]    Links
[X]    Search
[X]    Sort
[X]    Add Pod

Infrastructure > Pods > selected Pod

[X]    Links
[X]    Dedicate/Release Pod
[X]    Edit Pod
[X]    Disable/enable Pod
[X]    Delete Pod

Infrastructure > Clusters

[X]    Links
[X]    Search
[X]    Sort
[X]    Add Cluster

Infrastructure > Clusters > selected cluster

[X]    Links
[X]    Dedicate/Release cluster
[X]    Enable/disable cluster
[X]    Manage/unmanage cluster
[X]    Enable/disable out-of-band management
[X]    Enable/disable HA
[X]   Configure HA
[X]    Delete cluster
[X]    Settings - edit

Infrastructure > Hosts

[X]    Links
[X]    Search
[X]    Sort
[X]    Add host

Infrastructure > Hosts > selected host

[X]    Links
[X]    Add/delete notes
[x]    Dedicate/release host
[X]    Edit host
[X]    Force reconnect
[X]    Disable/enable host
[X]    Enable/cancel maintenance mode
[X]    Enable/disable out-of-band management
[X]    Enable/disale HA
[X]    Delete host (only if disabled)

Infrastructure > Primary Storage

[X]    Links
[X]    Search
[X]    Sort
[X]    Add Primary storage

Infrastructure > Primary Storage > selected primary storage

[X]    Links
[X]    Edit primary storage
[X]    Enable/cancel maintenance mode
[X]    Delete primary storage
[X]    Settings - edit

Infrastructure > Secondary Storage

[X]    Links
[X]    Search
[X]    Sort
[X]    Add Secondary storage

Infrastructure > Secondary Storage > selected secondary storage

[X]    Links
[X]    Delete secondary storage
[X]    Settings - edit

Infrastructure > System VMs

[X]    Links
[X]    Search
[X]    Sort

Infrastructure > System VMs > selected system VM

[X]    Links
[X]    View console
[X]   Start/Stop system VM
[X]    Reboot system VM
[X]    Change service offering
[X]    Migrate system VM
[X]    Run diagnostics
[X]    Get diagnostics data
[X]    Destroy system VM

Infrastructure > Virtual routers

[X]    Links
[X]    Search
[X]    Sort

Infrastructure > Virtual routers > selected virtual router

[X]    Links
[X]    View console (running)
[X]    Start/Stop router
[X]    Reboot router
[X]    Change service offering
[X]    Migrate router (running)
[X]    Run diagnostics (running)
[X]    Get diagnostics data
[X]    Destroy router

Infrastructure > Internal LB VMs

[X]    Links
[X]    Search
[X]    Sort

Infrastructure > Internal LB VMs > selected internal LB VM

[X]    Links
[X]    View console
[X]    Stop router
[X]    Migrate router

Infrastructure > CPU Sockets

[X]    Search Not supported or even needed
[X]    Sort

Infrastructure > Management servers

[X]    Links
[X]    Search Not supported via backend
[X]    Sort

Infrastructure > Management servers > selected management server
Infrastructure > Alerts

[X]    Links
[X]    Search
[X]    Sort

Infrastructure > Alerts > selected alert

[X]    Archive alert
[X]    Delete alert

Service Offerings > Compute offerings

[X]    Links
[X]    Search
[X]    Sort
[X]    Add offering

Service Offerings > Compute offerings > selected offering

[X]    Links
[X]    Edit offering
[X]    Update offering access
[X]    Delete offering

Service Offerings > System offerings

[X]    Links
[X]    Search
[X]    Sort
[X]    Change order (move to the top/bottom, move one row up/down)
[X]    Add offering

Service Offerings > System offerings > selected offering

[X]    Edit offering
[X]    Delete offering

Service Offerings > Disk offerings

[X]    Links
[X]    Search
[X]    Sort
[X]    Change order (move to the top/bottom, move one row up/down)
[X]    Add offering

Service Offerings > Disk offerings > selected offering

[X]    Links
[X]    Edit offering
[X]    Update offering access
[X]    Delete offering

Service Offerings > Network offerings

[X]   Links
[X]    Search
[X]    Sort
[X]    Change order (move to the top/bottom, move one row up/down)
[X]    Add offering

Service Offerings > Network offerings > selected offering

[X]    Edit offering
[X]    Enable/Disable offering
[X]    Update offering access
[X]    Delete offering

Service Offerings > VPC offerings

[X]    Links
[X]    Search
[X]    Sort
[X]    Change order
[X]    Add offering

Offerings > VPC offerings > selected offering

[X]    Links
[X]    Add / delete tags
[X]    Edit offering
[X]    Enable/Disable offering
[X]    Update offering access
[X]    Delete offering

Configuration > Global settings

[X]    Links
[X]    Search
[X]    Sort
[X]    Edit value

Configuration > LDAP Configuration

[X]    Links
[X]    Search
[X]    Sort Not supported via backend
[X]    Configure LDAP

Configuration > LDAP Configuration > selected LDAP configuration

[X]  remove LDAP

Configuration > Hypervisor capabilities

[X]    Data
[X]    Search
[X]    Sort

Tools

[X] Comments
[X] Import-Export instances

Environmnet: 4.17.2 and 4.18 nightly builds
Bugs found when testing the UI for the admin user

Date
Github Issue
Description
Status
Reporter
Assignees

10/2/2023
#7189
Context senstive help icon is not displayed for some tabs
In progress
kiranchavala

13//2/2023
#7202
host anti-affinity and host affinity is not working
In progress
kiranchavala

13//2/2023
#7204
Unable to select a default (host) option during the vm deployment
Closed fixed in #7256
kiranchavala

20/2/2023
#7266
Internal LB rules are not displayed
In progress
kiranchavala

Enhancement issues logged

Date
Github Issue
Description
Status
Reporter
Assignees

10/2/2023
#7189
List alerts page should have a filter drop down
In progress
kiranchavala

13//2/2023
#7216
Ability to select account and user in the drop down when adding to the project
In progress
kiranchavala

14//2/2023
#7204
Ability to view Archived events
In progress
kiranchavala

14//2/2023
#7218
Filter option is missing for the following tabs in the UI
In progress
kiranchavala

17/2/2023
#7246
Assign a static-nat label to the public-ip address
In progress
kiranchavala

17/2/2023
#7247
Assign a network name coloumn in the Guest Vlan page
In progress
kiranchavala

17/2/2023
#7248
Create a vpn users tab
In progress
kiranchavala

17/2/2023
#7249
Create a Site-to-site VPN Connections tab
In progress
kiranchavala

17/2/2023
#7250
Enabling site to site vpn connection before enabling VPN Gateway doesn't throw an error message
In progress
kiranchavala

17/2/2023
#7251
Events tab is missing for the following sections
In progress
kiranchavala

22/02/2023
#7278
Unable to order the ISO/templates in the UI
In progress
kiranchavala

Thanks @kiranchavala ! If you're done with the effort I think it's safe to close the issue.
great results btw!


Defer Treesitter setup to improve startup time of nvim {filename}

Wrapping the require('nvim-treesitter.configs').setup block in a vim.defer_fn(function()...end, 0) saves 185ms of startup time when loading a file with an expensive Treesitter parser such as: nvim test.cc.
Default init.lua:
302.407 000.007: --- NVIM STARTED ---
Adding vim.defer_fn around require('nvim-treesitter.configs').setup block:
115.798 000.005: --- NVIM STARTED ---
The 185ms startup delay does not occur when loading a simple .txt file or .lua file.
Changes visual experience:
Before: slower startup + treesitter colors available first frame
After: faster startup + treesitter colors come in after first frame

@AshrafMichail23 This PR is still marked as a WIP, are you still actually working on it?

@AshrafMichail23 This PR is still marked as a WIP, are you still actually working on it?

Marked as "ready for review".

OK I just tested this myself. I don't see any downsides here! Merging.
Folks please yell if this impacts you in any way, and @AshrafMichail23 thanks for your contribution!


[Feature][PagerDuty] Add data source dashboard for PagerDuty

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Use case
PagerDuty support is added in v0.17. We should add a data source dashboard for PagerDuty so users can browse PagerDuty data after collection. Since most PagerDuty data lives in issues table in the domain layer as of now, the dashboard can re-use panels from other data source dashboards in the issue management domain.
Description
No response
Related issues
No response
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

What additional metrics do they want other than those from other dashboards?


Rebalance class status progress message

The Rebalance class status message contains a string related to imputation instead:
No columns specified for imputation. These columns have been automatically identified:
[]
Running oversampling...

This is actually an expected behavior. What happening here is that some classes have a default pre-processing pipeline. For the Rebalance class, for example, when using SMOTE (which doesn't work with categorical variables or missing values), the transform_pipe parameter must contain an encoder and an imputer. Otherwise, a default BasicImputer and EncoderOHE objects are created and inserted in the transform_pipe internal variable. When calling the rebalance method, the BasicImputer and EncoderOHE will run before running SMOTE. This message is printed by the BasicImputer created. You can suppress this message by setting verbose = False when instantiating the Rebalance class


Control the click of the middle mouse button

Description of the new feature / enhancement
Having the option to control the click, today I use third-party software to make the middle button have the function of returning anywhere in Windows.
Scenario when this would be used?
Anywhere in Windows.
Supporting information
No response

/dup #1475


Admob Pro auto shoe doesnt work for interstitial ads

Hi,
i ve bulding an app by using vs7 cordova and i ve installed this plugin, it works well but for intersititial ads dont show auto. my codes are below;
    function reklamYukle() {
        var admobid = {};
        // TODO: replace the following ad units with your own
        if (/(android)/i.test(navigator.userAgent)) {
            admobid = { // for Android
                banner: 'ca-app-pub-5534669392136777/9811456161',
                interstitial: 'ca-app-pub-5534669392136777/5454702358',
            };
        } else if (/(ipod|iphone|ipad)/i.test(navigator.userAgent)) {
            admobid = { // for iOS
                banner: 'ca-app-pub-5534669392136777/7944497261',
                interstitial: 'ca-app-pub-5534669392136777/4856501200',
            };
        } else {
            admobid = { // for Windows Phone
                banner: 'ca-app-pub-6869992474017983/8878394753',
            };
        }

        AdMob.createBanner({
            adId: admobid.banner,
            position: AdMob.AD_POSITION.BOTTOM_CENTER,
            overlap: false,
            offsetTopBar: false,
            bgColor: 'black',
            autoshow: true
        });

        AdMob.prepareInterstitial({
            adId: admobid.interstitial,
            autoShow: true
        });
    }

    function onDeviceReady() {
        reklamYukle();
    }

    document.addEventListener("deviceready", onDeviceReady, false);

Actually it's not a good idea to auto show interstitial, as usually it will take a little time to load ad resource from server, and may display unexpected.
It's a better practice to prepareInterstitial() with autoShow:false, then showInterstitial() at a better timing, like at a game level over, or let the use decide to watch it.

I changed my code as u said. But i released that interstitial ads are not displayed twice. I just put click function for a button to checked it wheather its working or not when i click first time its working well, but on twice click its not working. What can be caused this ?

Before each call to showInterstitial(), you need call prepareInterstitial() to load ad resource from server,  and wait for 'onAdLoaded' event as notification of ad resource ready.