feat: support message key as a column in avro_upsert

Signed-off-by: tabVersion<EMAIL_ADDRESS>hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Checklist For Contributors

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
[ ] All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

[ ] I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

[ ] My PR DOES NOT contain user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

Maybe we should check the hard-coded key_field field is not in the value schema?

feature has been done in #9926


Make resuming previous evaluations more explicit

I'm not resuming previous evaluations for now. I will later add a feature to do this explicitly with a --continue flag or so.

Done


[Settings GUI] String array: No indication that item is not allowed

#77427
"type": "array",
"items": {
	"type": "string",
	"enum": [
		"error",
		"warning",
		"info",
		"hint"
	]
},

settings.json:

settings GUI:

This functionality is not provided yet. We don't have much validation in settings editor.


Fix typos in quickstart-sample.md

Thank you for contributing to Microsoft Fabric documentation
Fill out these items before submitting your pull request:
If you are working internally at Microsoft:
Provide a link to an Azure DevOps Boards work item that tracks this feature/update.

Who is your primary Skilling team contact? @mention them individually tag them and let them review the PR before signing off.

For internal Microsoft contributors, check off these quality control items as you go

[x] 1. Check the Acrolinx report: Make sure your Acrolinx Total score is above 80 minimum (higher is better) and with no spelling issues. Acrolinx ensures we are providing consistent terminology and using an appropriate voice and tone, and helps with localization.

[x] 2. Successful build with no warnings or suggestions: Review the build status to make sure all files are green (Succeeded).

[x] 3. Preview the pages:: Click each Preview URL link to view the rendered HTML pages on the review.learn.microsoft.com site to check the formatting and alignment of the page. Scan the page for overall formatting, and look at the parts you edited in detail.

[ ] 4. Check the Table of Contents: If you are adding a new markdown file, make sure it is linked from the table of contents.

[ ] 5. #sign-off to request PR review and merge: Once the pull request is finalized and ready to be merged, indicate so by typing #sign-off in a new comment in the Pull Request. If you need to cancel that sign-off, type #hold-off instead. Signing off means the document can be published at any time. Note, this is a formatting and standards review, not a technical review.

Merge and publish

After you #sign-off, there is a separate PR Review team that will review the PR and describe any necessary feedback before merging.
The review team will use the comments section in the PR to provide feedback if changes are needed. Address any blocking issues and sign off again to request another review.
Once all feedback is resolved, you can #sign-off again. The PR Review team reviews and merges the pull request into the specified branch (usually the main branch or a release- branch).
From the main branch, the change is merged into the live branch several times a day to publish it to the public learn.microsoft.com site.

#sign-off

@mberdugo, can you please review this change? Thanks!

@mberdugo I'm no longer working on this project, for comment and review please contact @KesemSharabi.
Thanks!

Hal

@mberdugo - verified. Please sign off.

#sign-off

#sign-off


Dependencies update + API cleanups

Signed-off-by: Jérôme Benoit<EMAIL_ADDRESS>
PR Checklist

[x] Please add a description of your changes.
[ ] We need your changes to come with unit tests in order to keep this project in quality and easy to maintain.
[ ] If your changes contain any new feature please be sure to document it.
[ ] Please add a link to the open issue or task that this pull request will resolve.
[ ] Add a note to the changelog to indicate the change.

Does this PR introduce a breaking change?

[x] Yes
[ ] No

If yes please indicate it and migration info into the CHANGELOG.md file.

@pioardi needs to approve this, due to the changes to emitted output from build

looks good for me guys

@pioardi needs to approve this, due to the changes to emitted output from build

Rollup in the middle will still make the bundle output compatible with cjs.


JavaScript test runners skip resolution validations

From function getParserTestRunner(extractor, parser) in runner-datetime.js
...
if (actual.value && expected.Value) {
	// timex
	t.is(actual.value.timex, expected.Value.Timex, 'Result.Value.Timex');

	// resolutions
	var actualValue = {
		timex: actual.value.timex,
		futureResolution: actual.value.futureResolution,
		pastResolution: actual.value.pastResolution,
	}

	t.deepEqual(actualValue.futureResolution, expected.Value.FutureResolution);
	t.deepEqual(actualValue.pastResolution, expected.Value.PastResolution);
}
...

If the tested parser does not resolve the correct values for a test case and actual.value is null, then the other assertions are not executed, causing a false positive.
The same behavior is presented in getMergedParserTestRunner and getModelTestRunner
The correct behavior would be that those tests failed because actual.value is different from expected.Value

There is another issue in Merged Parse test.
The test is checking TypeName property https://github.com/Microsoft/Recognizers-Text/blob/06abe6ad30f29bee5f28119d370da6e73150c2d8/JavaScript/test/runner-datetime.js#L101 when the correct name is type.
https://github.com/Microsoft/Recognizers-Text/blob/06abe6ad30f29bee5f28119d370da6e73150c2d8/JavaScript/packages/recognizers-date-time/src/dateTime/baseMerged.ts#L342
It is a false positive since the property TypeName is undefined for both objects.

Fixed with:

Fix Number-with-Unit tests assertions #628
[JS] Fix datetime asserts #646

The same issue was fixed in Python with the following PR:

Fix number with unit test assertions #629
Fix datetime asserts #643


Missing build library: babel-runtime

When building from source, babel-runtime is not specified in package.json.  After adding this package I was able to build.

Resolved in 1.1.0


Sonoma 14.0 RC breaks Hidden Bar? No | in menu bar

Describe the bug
The < icon displays in menu bar, but the | does not.
There is space to the left of my left-most menu bar item, so the | isn't hidden, just isn't there.
Moving around the < icon changes nothing.
Steps to reproduce
Install hidden bar
Expected behaviour
Add both icons to menu bar < and |
Screenshots
If applicable, add screenshots to help explain your problem.
Environment
Installed the App Store version into  Sonoma 14.0 (released candidate 2023-09-22).

Is your monitor notched? Because notched display won't show excessive icons once the top-right corner is filled up.
If problem persists, uninstall the AppStore version (v1.8) and install the home-brew one (v1.9). If still nothing helps, try my forked version (need build from source).

Is your monitor notched? Because notched display won't show excessive icons once the top-right corner is filled up.

Yes, my monitor is notched (MacBook Pro 2021)

If problem persists, uninstall the AppStore version (v1.8) and install the home-brew one (v1.9). If still nothing helps, try my forked version (need build from source).

I tried the home-brew version, it also didn't work.
Where is the forked version?

Is your monitor notched? Because notched display won't show excessive icons once the top-right corner is filled up.

Yes, my monitor is notched (MacBook Pro 2021)

The separator bar might be obstructed by the notch. Apple limits the amount of icons that can be displayed in a notched screen at the same time.

Where is the forked version?

Here (You need to build from source). But it might not help if you really exceeded the icon amount limit.

I'm on Sonoma GA now and can confirm that the | was hidden from the notch. After closing some of the apps, I got the | back and could start moving apps into the hidden tray

Can confirm, Sonoma 14.0 breaks the hiddenbar. Closing apps in the bar doesn't help. < doesn't work anymore.

I'm on Sonoma 14.2.1 (MacBook Pro) and can't see the vertical bar, but hiding the icons works. It looks like the vertical bar is just invisible but takes up some space in the Menu Bar. I can even move the (invisible) vertical bar and it influences the selection of hidden icons.

See the screenshot: left of the arrow icon is a small "unused" space, that is the vertical bar.

Yep, it's broken, but I actually prefer it like that lmao

Alright, I might have found the fix, just right click where the button should be...

I am on notched Sonoma 14.0 and using the brew version. The vertical bar does show up after right clicking on the arrow, and the app works just fine.

Sonoma 14.2.1 (23C71) and using Hidden Bar 1.9 on Brew, and ⌘+Click of the ">" icon has no effect; the "|" section icon does not appear.

Sonoma 14.2.1 (23C71) (14-Inch 2021 MBP) and using Hidden Bar 1.9 on Brew, and ⌘+Click of the ">" icon has no effect; the "|" section icon does not appear, nor any unused space/hidden icon.
Additionally, I cannot even bring up the settings to the foreground vs the App store version.
Edit: #225 (comment) is a workaround (and this is possibly a duplicate issue). Changing the display to a higher resolution from 1512x982 (default) to 1800x1125, for example, shows the "|" icon and other apps which were hidden behind it previously and not expanding when I clicked the ">" icon.

Try right-clicking the ">" icon.


structs with VariableLengthInlineArray and SizeOf(0)

C structures with a flexible array member at the end (array of [0] elements) get translated to a VariableLengthInLineArray. As an example, I take USB_DESCRIPTOR_REQUEST, which in C is:
typedef struct _USB_DESCRIPTOR_REQUEST {
    ULONG ConnectionIndex;
    struct {
        UCHAR bmRequest;
        UCHAR bRequest;
        USHORT wValue;
        USHORT wIndex;
        USHORT wLength;
    } SetupPacket;
    UCHAR Data[0];
} USB_DESCRIPTOR_REQUEST, *PUSB_DESCRIPTOR_REQUEST;

I know about the discussion that in C# (using CsWin32) the VariableLengthInLineArray always has 1 member (as if UCHAR Data[1] instead of UCHAR Data[0]), and therefore the sizeof(C# struct) does not match the sizeof(C struct). And that's OK, since we now have a convenience member function SizeOf for such structures that takes a count parameter for the real number of elements in the array.
However, the function is defined as:
/// Computes the amount of memory that must be allocated to store this struct, including the specified number of elements in the variable length inline array at the end.
internal static unsafe int SizeOf(int count)
{
	int v = sizeof(USB_DESCRIPTOR_REQUEST);
	if (count > 1)
		v +=checked((count - 1) * sizeof(byte));
		else
			if (count < 0)
				throw new ArgumentOutOfRangeException();
	return v;
}

This does not return the correct size for 0; SizeOf(0) is still off by 1 array element. In fact SizeOf(0) == SizeOf(1) in the current implementation. Note that for the example USB_DESCRIPTOR_REQUEST, 0 is actually a valid size for the array (as in: the data is optional).
I don't know if this is deliberate, or actually a bug.
Could SizeOf(0) be changed so it returns sizeof(C# struct) - sizeof(the 1 element in VariableLengthInLineArray) == sizeof(C struct)? Something like:
/// Computes the amount of memory that must be allocated to store this struct, including the specified number of elements in the variable length inline array at the end.
internal static unsafe int SizeOf(int count)
{
	int v = sizeof(USB_DESCRIPTOR_REQUEST);
	if (count >= 0)
		// NOTE: the -1 for count == 0 is intentional, to compensate for the omnipresent 1 element in VariableLengthInLineArray
		v +=checked((count - 1) * sizeof(byte));
	else
		throw new ArgumentOutOfRangeException();
	return v;
}

That's an interesting problem. Am I correct in supposing it's important for you to get the size of the struct that reflects a 0 length trailing buffer specifically, such that passing a size that implies a length of 1 causes a malfunction? Or is this just to 'feel good' about the size matching what C would say?
It's potentially problematic to change the behavior to match what you say, because to C#, the VariableLengthInlineArray struct is one element in length. Suppose then that you use SizeOf(0) to determine the size of a buffer you needed to allocate, and then you copied a USB_DESCRIPTOR_REQUEST into it from C#. That would be a buffer overrun because the runtime would copy USB_DESCRIPTOR_REQUEST plus one element, since that's how the type is defined in C#. The SizeOf method was written to reflect the size of the memory that must be allocated from C#. It wasn't meant for initializing a field on the native struct that would represent the whole size of the struct plus buffer (given a 0 length buffer, anyway).
If this really is important, we may need to introduce another function alongside SizeOf with a very clear name and xml docs so folks know which one to call when.

My use case could definitely be rewritten to use the current way CsWin32 generates the struct. But before CsWin32 supported the USB structures I already had my own definition as here:
https://github.com/dorssel/usbipd-win/blob/d064ea10aa3a17acfe83537e98b078214f05e75a/Usbipd/Interop/WinSDK.cs#L18-L33
I use it "C-style" to custom marshal the data that comes after it, which is not really byte data, but instead another structure. And with "C-style" I mean: use offset into the byte representation to get to the start of that following data struct. And that offset in C is just sizeof(USB_DESCRIPTOR_REQUEST). But not in C#, where there currently is no way to get the that original size (except subtracting the 1 byte manually). Here is how I use it (note: this code predates the CsWin32 support for these structures.
https://github.com/dorssel/usbipd-win/blob/d064ea10aa3a17acfe83537e98b078214f05e75a/Usbipd/ExportedDevice.cs#L79-L122
I am slowly trying to get rid of all my manual WinSDK "defines" and move to CsWin32 for everything. This thing just struck me. And like I said, I can easily rewrite it to work with CsWin32. I was just wondering why it is not possible to get the original C size for "sizeof(USB_DESCRIPTOR_REQUEST)".
On a side note: what if, instead of adding the empty struct with [] operator (which VariableLengthInlineArray really is) you would implement the 0-size array last element as member function. Then you could do something like:
[MethodImpl(MethodImplOptions.AggressiveInlining)]
internal ref TData FlexibleArrayMember(int index)
{
    if (index < 0) {
        throw new ArgumentOutOfRangeException(nameof(index));
    }
    unsafe
    {
        fixed (STRUCT_TYPE* ptr = &this)
        {
            return ref *(((TData *)(ptr + 1)) + index);
        }
    }
}

Instead of addressing the flexible array like Data[index] it would be Data(index), but at no cost of the one extra byte for the empty struct. And such a member function should probably be marked as unsafe (even though its prototype itself does not require that).
And on that last note: why is the SizeOf() helper marked as unsafe. I think it shouldn't be...

I think you have some good ideas here. I haven't the time this week probably, but I'll review more closely and see what we can adopt.

Thanks. But that's what they realy are ... ideas ... not proposals. Like I said, I could use the generated types as they are by just rewriting a little bit of code. But if you are interested in the "flexible array without a 1-byte empty struct" idea. There are some corner cases to consider. Such as alignment, for example a C struct:
UCHAR a;
UCHAR b;
UCHAR c;
DWORD array[0];

In C this will have alignment 4, size 4, and a byte of padding between c and array. But if you simply make a C# struct with the first 3 members and a kludge method like I suggested, then of course you need something like pack(4). In that case a simple dummy padding member is not enough, as that would make the size 4, but still have alignment 1.


npm install not working

"npm install" command of the installation fails with a "Arguments to path.join must be strings" error.

Made a PR for fixin this.


[FLINK-1543] Adds better exception handling in actors

Adds try and catch blocks around exception throwing methods in the JobManager and TaskManager. This PR is based on #384.

+1 Nice work and a critical fix. Prevents the root actors from failing on user code problems.

@tillrohrmann I had concern about style and question about value about parameter passed.
Would be nice to address those before committing.

@hsaputra, sorry I did not see your comments before I committed the PR. I started merging it yesterday but it always failed because of some minor issues on Travis. Therefore, I only looked at the Travis results. Won't happen again.
You're right that the extra spaces are missing. Good catch. I'll add them with my next commit.

No worries, thanks for replying to my concern =)


bump pxt common packages to 9.2.7

Bump to pick up new pxt ref in pxt-common-packages to update the transitive dependencies

err hold off as we'll need to bump the refs again for skillmap bumps looks like


crawl only shared_data

Well, more like an suggestion, than a "bug" report.
I think you shouldn't load the full instagram page.
First, the element classes (inside elements.json), change with some frequency (have no ideia wich frequency is that).
So, my sugestion it 's just load _sharedData inside the profile.
Don't load javascripts, images, styles.. It's way faster.
Something like this:
        this.page = await this.browser.newPage();
        await this.page.setRequestInterception(true);
        this.page.on('request', (request) => {
            if (['image', 'stylesheet', 'font', 'script'].indexOf(request.resourceType()) !== -1) {
                request.abort();
            } else {
                request.continue();
            }
        });
        await this.page.setExtraHTTPHeaders({
            'Accept-Language': 'pt-BR'
        });
        await this.page.goto('https://instagram.com/' + username, {
            waitUntil: 'networkidle0'
        });
        const sharedData = document.querySelector('script').innerText;
        const html = /window._sharedData = (.*);/.exec(sharedData)[1];
        const profileData = JSON.parse(html);

/* Maybe here you could use your version 1.0 "parseData" function from here ? */

I ended up doing this to my project here, based on what you wrote.
If you want I can fork and send a PR. Just let me know.
https://gist.githubusercontent.com/Stiveknx/86342c6588371010a30d8239e07df0ad/raw/a11780c36f28b51958501e11285f05bb2ed1b2e0/profilecrawl.ts

thanks for your comment, it's interesting and I hadn't thought about it. Do a PR and then I'll watch.


Step 4 = incorrect for Office 2013

The Custom add-ins section at the bottom of the dialog and "Add a custom add-in" option does not appear in Outlook 2013 when hitting the Store button then "My add-ins"  as mentioned on this page for step 4.
Locate the Custom add-ins section at the bottom of the dialog. Select the Add a custom add-in link, and then select Add from file.

[Enter feedback here]

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

ID: 3f364ae0-b7dd-edb3-b51b-8f6d0d99afbe
Version Independent ID: 7dd1ce8f-16e7-88f8-f291-4afbe76baba7
Content: Sideload Outlook add-ins for testing - Office Add-ins
Content Source: docs/outlook/sideload-outlook-add-ins-for-testing.md
Product: outlook
Technology: add-ins
GitHub Login: @o365devx
Microsoft Alias: o365devx

Hi @jpro71 , this seems to be an error in our documentation. Outlook 2013 does not support custom add-ins. Thanks for bringing this to our attention, we will go ahead and fix it.

@jpro71 We're updating the instructions Outlook 2013 (see linked PR #1989). Can you give them a try and let us know if they helped? Thanks.

@jpro71 We've added sideload instructions for Outlook 2013. Those changes should be published soon. Thanks.

Excellent looking forward to it.
On Mon, Jun 29, 2020 at 2:34 PM Elizabeth Samuel<EMAIL_ADDRESS>wrote:

@jpro71 https://github.com/jpro71 We've added sideload instructions for
Outlook 2013. Those changes should be published soon. Thanks.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/OfficeDev/office-js-docs-pr/issues/1974#issuecomment-651289345,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AQBISS6VUD5D5PGNZGVN2Q3RZDNFHANCNFSM4OETCSKQ
.


request: No nodejs imports rule

To the point, I'm trying to create a structure for my projects centered around a single file that holds a list of all the dependencies. In deno, it seems to be a common practice to have a deps.js (or deps.ts) file that lists all the external dependencies in a project:
For example<EMAIL_ADDRESS>I would want to replicate this with NodeJS for the purpose of bundling just that one file. I'm not finding anything that allows me to set a rule of no external imports at all. I would want to set that as default for all files (in .eslintrc.json) but disable it for the deps.js. The import/no-nodejs-modules rule is close to what I want but that only works for NodeJS builtins, not for external modules.  import/no-extraneous-dependencies is similar, but basically, I don't want it to check package.json.
If there was a way to regex the module names, I believe I can enforce something that requires a path-like system (eg: './b.js'). I just want to avoid something like import _ from 'lodash' from most files.

This package, and eslint itself, are node modules - I'm having trouble understanding the use case of running node-based tools on non-node platforms. eslint may support deno, but most eslint plugins don't (including this one).
All that said, I think you can use a custom resolver here, which could tell this plugin how to resolve everything including core modules, and no-unresolved would error out on anything you didn't want included. Would that do what you need?

Sorry if I wasn't clear. I'm not using deno. I'm using node. But the paradigm of putting all your dependencies in one file is common seen in deno (it's an example).
The use case is all application code (let's say in /src/*) is environment agnostic. They would be pure ES modules that don't use node based resolution. Instead of
src/index.js
import '_' from 'lodash';
import `readFile` from 'fs/promises';

/** CODE **/

It would be:
deps.js
export { default as _ } from 'lodash';
export { readFile } from 'fs/promises';

src/index.js
import { _, readFile } from '../deps.js'

So, the application code has no idea (or care) how the external dependencies are resolved, or what the true source of the import is.

Another example is the ability to ship two different deps.js files based on the environment. For example,
deps.js (nodeJS)
import { JSDOM } from 'jsdom';
export const EventTarget = new JSDOM().window.EventTarget;

deps.js (browser)
export const EventTarget = window.EventTarget;

I can also swap out imported modules that may be referenced by multiple files. So if I choose to change a dependency from, (eg: colors to bevry/ansi), I don't have to change every file that uses that import, but instead just deps.js

The last example is my current predicament of bundling just deps.js for backend deployment. I would want to bundle deps.js, but not anything in /src/*.

While writing this out, I think I got it working with:
{
  "settings": {
    "import/resolver": {
      "node": {
        "moduleDirectory": []
      }
    }
  }
}

So I'm going to go ahead and close it. Thanks! import/resolver was the trick.

Please change the title of this closed issue as it comes up in searches where it shouldn't.


Unexpected ports allowed with egress rules using ipBlock and except

What happened:
I have network policy with three egress rules.  The Kubernetes ServiceCIDR is <IP_ADDRESS>/16.

It allows access to CoreDNS.
It allows access to port 8080 with a destination of <IP_ADDRESS>/16.
It allows access to the any address (<IP_ADDRESS>/0), except <IP_ADDRESS>/16.

When I apply the below network policy.  I am able to access to any port with destination of <IP_ADDRESS>/16, when it should only be 8080.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-internet-and-svc-8080
spec:
  egress:
  - ports:
    - port: 53
      protocol: UDP
    to:
    - namespaceSelector:
        matchLabels:
          kubernetes.io/metadata.name: kube-system
      podSelector:
        matchLabels:
          k8s-app: kube-dns

  - ports:
    - port: 8080
      protocol: TCP
    to:
    - ipBlock:
        cidr: <IP_ADDRESS>/16

  - to:
    - ipBlock:
        cidr: <IP_ADDRESS>/0
        except:
        - <IP_ADDRESS>/16

  podSelector:
    matchLabels:
      app: client-one
  policyTypes:
  - Egress

Attach logs

evel":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"Total L4 entry count for catch all entry: ","count: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":0,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:673","msg":"Updating Map with ","IP Key:":"<IP_ADDRESS>/32"}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":0,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":53,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:673","msg":"Updating Map with ","IP Key:":"<IP_ADDRESS>/32"}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":0,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":53,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:673","msg":"Updating Map with ","IP Key:":"<IP_ADDRESS>/32"}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":0,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":53,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:673","msg":"Parsed Except CIDR","IP Key: ":"<IP_ADDRESS>/16"}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":255,"startPort: ":0,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:673","msg":"Updating Map with ","IP Key:":"<IP_ADDRESS>/16"}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":0,"endPort: ":0}
{"level":"info","ts":"2024-01-05T15:29:18.011Z","logger":"ebpf-client","caller":"ebpf/bpf_client.go:701","msg":"L4 values: ","protocol: ":254,"startPort: ":8080,"endPort: ":0}

From the logs see the relevant snippet below, I believe the policy agent is doing some port merge and doesn't take into account that the IP block from earlier was from an except clause.
"msg":"Parsed Except CIDR","IP Key: ":"<IP_ADDRESS>/16"}
"msg":"L4 values: ","protocol: ":255,"startPort: ":0,"endPort: ":0}

"msg":"Updating Map with ","IP Key:":"<IP_ADDRESS>/16"}
"msg":"L4 values: ","protocol: ":254,"startPort: ":0,"endPort: ":0} <== NOT EXPECTED, all ports??
"msg":"L4 values: ","protocol: ":254,"startPort: ":8080,"endPort: ":0}

What you expected to happen:
I expect the client-one pods to access port 8080 with destination IP of <IP_ADDRESS>/16, but not to any other ports like 9090 or others.
How to reproduce it (as minimally and precisely as possible):
Here is a demo-app service/deployment used to reproduce the issue.
---
apiVersion: v1
kind: Service
metadata:
  name: demo-app
spec:
  type: ClusterIP
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  selector:
    app: demo-app
...
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo-app-index
data:
  index.html: |
    <!DOCTYPE html>

        <title>Welcome to Amazon EKS!</title>

Welcome to Amazon EKS!

If you see this page, you are able successfully access the web application as the network policy allows.

For online documentation and installation instructions please refer to
          Amazon EKS Networking.

          The migration guides are available at
          Amazon EKS Network Policy Migration.

Thank you for using Amazon EKS.

...
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-app
spec:
  selector:
    matchLabels:
      app: demo-app
  replicas: 1
  template:
    metadata:
      labels:
        app: demo-app
    spec:
      containers:
      - name: demo
        image: public.ecr.aws/docker/library/nginx:stable
        imagePullPolicy: IfNotPresent
        command: ["/bin/sh", "-c"]
        args: ["sed -i 's/listen[[:space:]]*80;/listen 8080;/g' /etc/nginx/conf.d/default.conf && nginx -g 'daemon off;'"]
        volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nginx-index-volume

      volumes:
      - name: nginx-index-volume
        configMap:
          name: demo-app-index
...

Here is the client-one deployment used to test the network policy.  Please note, the memory resource request and adjust as needed.  I bumped this up so that the clients are spread across more nodes and I'm not doing a "single" node testing, which might not be representative of node-node networking nuances.
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: client-one
  labels:
    app: client-one
spec:
  replicas: 10
  selector:
    matchLabels:
      app: client-one
  template:
    metadata:
      labels:
        app: client-one
    spec:
      terminationGracePeriodSeconds: 2
      containers:
      - name: client-one
        image: curlimages/curl:latest
        command: ["/bin/sh", "-c"]
        args:
          - |
            sleep infinity
        resources:
          requests:
            memory: "1200Mi"
...

Here is my initial state, I've deployed the clients, the demo-app and my network policy.  I list my in-cluster services, demo-app running in default namespace and prometheus running in the monitoring namespace.
# k get pods
NAME                          READY   STATUS    RESTARTS   AGE
client-one-655ffdf468-57ncr   1/1     Running   0          41m
client-one-655ffdf468-5x6df   1/1     Running   0          41m
client-one-655ffdf468-7tv2j   1/1     Running   0          41m
client-one-655ffdf468-8cf65   1/1     Running   0          41m
client-one-655ffdf468-9ckx4   1/1     Running   0          41m
client-one-655ffdf468-cz8rw   1/1     Running   0          41m
client-one-655ffdf468-fq9rx   1/1     Running   0          41m
client-one-655ffdf468-gzt9t   1/1     Running   0          41m
client-one-655ffdf468-jtpt7   1/1     Running   0          41m
client-one-655ffdf468-n24mq   1/1     Running   0          41m
demo-app-649c8db494-zrpp5     1/1     Running   0          42m

# k get netpol
NAME                          POD-SELECTOR     AGE
allow-internet-and-svc-8080   app=client-one   15m

# k get svc
NAME         TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
demo-app     ClusterIP   <IP_ADDRESS>   <none>        8080/TCP   43m
kubernetes   ClusterIP   <IP_ADDRESS>      <none>        443/TCP    18h

# k get svc -n monitoring prometheus-kube-prometheus-prometheus
NAME                                    TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
prometheus-kube-prometheus-prometheus   ClusterIP   <IP_ADDRESS>   <none>        9090/TCP   18h

Here is my result of the network policy testing.  I get all the client-one pods and then exec into it and run a simple curl command to query its UI and print its status code.

Is the network policy even working?  Yes, it is.  I can show the before and after addition to the current network policy.  I will add <IP_ADDRESS>/16 to the except list, so that the pod won't be able to access the EC2 metadata endpoint.

Environment:

Kubernetes version (use kubectl version):
Client Version: v1.25.15-eks-e71965b
Kustomize Version: v4.5.7
Server Version: v1.25.16-eks-8cb36c9

CNI Version: amazon-k8s-cni:v1.15.3-eksbuild.1

Network Policy Agent Version: aws-network-policy-agent:v1.0.5-eksbuild.1

OS (e.g: cat /etc/os-release): Ubuntu 20.04.6 LTS

Kernel (e.g. uname -a): 5.15.0-1051-aws

@mw-tlhakhan I have not gotten a chance to dig deeper, but since you can reproduce this, have you tried using Network Policy agent image v1.0.7? I am wondering if this was fixed in the recent batch of bug fixes.

@mw-tlhakhan - Thanks for the detailed explanation. There is no change in this part of the code in 1.0.7 or main so it is expected. I will look into this and get back.

I did repro it -
{"msg":"Parsed Except CIDR","IP Key: ":"<IP_ADDRESS>/16"}
{"msg":"L4 values: ","protocol: ":255,"startPort: ":0,"endPort: ":0} -> reserved value (255) was derived correctly

{"msg":"Updating Map with ","IP Key:":"<IP_ADDRESS>/16"}
{"msg":"L4 values: ","protocol: ":254,"startPort: ":0,"endPort: ":0} -> this should have been 255

{"msg":"L4 values: ","protocol: ":254,"startPort: ":8080,"endPort: ":0}

We are evaluating to see if this is a bug. There are conflicting rules for the same CIDR. One rule is blocking -
- to:
    - ipBlock:
        cidr: <IP_ADDRESS>/0
        except:
        - <IP_ADDRESS>/16

While another rule is allowing for a particular port -
- ports:
    - port: 8080
      protocol: TCP
    to:
    - ipBlock:
        cidr: <IP_ADDRESS>/16

But since there is an allow all with /m for all port and protocol we go ahead and inherit and in this case from <IP_ADDRESS>/0..except is meant to selectively block certain cidrs while allowing the rest.

Hi @jayanthvn! I see a similar issue in my EKS environment:
> k describe po -n kube-system -l app.kubernetes.io/instance=aws-vpc-cni | grep -A10 'aws-eks-nodeagent:' |grep -e aws-eks-nodeagent -e "Image:" -e enable-network-policy -e Args
  aws-eks-nodeagent:
    Image:<PHONE_NUMBER>52.dkr.ecr.eu-west-1.amazonaws.com/amazon/aws-network-policy-agent:v1.0.7-eksbuild.1
    Args:
      --enable-network-policy=true

I have two egress rules added for <IP_ADDRESS>/0 in the network policy object:
    - ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
      to:
        - ipBlock:
            cidr: <IP_ADDRESS>/0
    - to:
        - ipBlock:
            cidr: <IP_ADDRESS>/0
            except:
            - <IP_ADDRESS>/8
            - <IP_ADDRESS>/16
            - <IP_ADDRESS>/12
            - <IP_ADDRESS>/16

Applying this configuration results in the rule that only allows 53 port traffic, while I would expect that all ports are allowed as both rules should be merged:
Key : IP/Prefixlen - <IP_ADDRESS>/0
-------------------
Value Entry :  0
Protocol -  UDP
StartPort -  53
Endport -  0
-------------------
-------------------
Value Entry :  1
Protocol -  TCP
StartPort -  53
Endport -  0

As a workaround, I can add port and endPort parameters for all ports to the network policy which will result in the following rule:
# network policy object
    - ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
      to:
        - ipBlock:
            cidr: <IP_ADDRESS>/0
    - ports:
        - protocol: UDP
          port: 1
          endPort: 65535
        - protocol: TCP
          port: 1
          endPort: 65535
      to:
        - ipBlock:
            cidr: <IP_ADDRESS>/0
            except:
            - <IP_ADDRESS>/8
            - <IP_ADDRESS>/16
            - <IP_ADDRESS>/12
            - <IP_ADDRESS>/16
# ebpf map content
Key : IP/Prefixlen - <IP_ADDRESS>/0
-------------------
Value Entry :  0
Protocol -  UDP
StartPort -  53
Endport -  0
-------------------
-------------------
Value Entry :  1
Protocol -  TCP
StartPort -  53
Endport -  0
-------------------
-------------------
Value Entry :  2
Protocol -  UDP
StartPort -  1
Endport -  65535
-------------------
-------------------
Value Entry :  3
Protocol -  TCP
StartPort -  1
Endport -  65535

Do you have any pointers on what could be the root cause? Can we consider this a bug in the network-policy-agent? It seems that something is going wrong when merging two rules and one of the rules doesn't contain any ports configuration.

@Infra-Red We will need to check it out but I don't see the need for splitting the policy in to two rules (i.e.,) why can't it be a single entry as you want to allow port 53 for all IPs.
        - ipBlock:
            cidr: <IP_ADDRESS>/0
            except:
            - <IP_ADDRESS>/8
            - <IP_ADDRESS>/16
            - <IP_ADDRESS>/12
            - <IP_ADDRESS>/16

If the intention was to allow port 53 access for all IPs but to exclude CIDRs under except for all the other port and protocol combinations, then the above policy doesn't look right. One entry says to exclude the CIDRs (under except) for all ports and protocols and the other says to allow port 53 for these same set of CIDRs. Ideally you should instead specify the policy similar to the policy in the prior comments.

@pgier and @Infra-Red did you end up using Calico as the network policy engine in the end to work around this limitation? I second that something is really odd when you try to use the except block on IPv4 and IPv6  if you're using an IPv6 EKS cluster.

Facing same issue while trying to add blanket block rule and then allowing traffic for certain ports. But nodeagent endsup allowing all ports for the CIDR range.
Policy file:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-egress-block
spec:
  podSelector:
    matchLabels:
      app: pod1
  policyTypes:
  - Egress
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-all-except-dev-cidr-block
spec:
  podSelector:
    matchLabels:
      app: pod1
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: <IP_ADDRESS>/0
        except:
        - <IP_ADDRESS>/16
        - <IP_ADDRESS>/16
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-ports
spec:
  podSelector:
    matchLabels:
      app: pod1
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: <IP_ADDRESS>/16
    ports:
    - protocol: TCP
      port: 15432
      endPort: 15432

@mw-tlhakhan This open PR https://github.com/aws/aws-network-policy-agent/pull/344 will fix this issue. PR handles overlaps in allow and except blocks. I will update here once we have this changes released


protoreflect.Value.Interface() returns incorrect interface{} type for oneof field values that are messages

What version of protobuf and what language are you using?
Version: 1.4.3, go version go1.15.7 windows/amd64
What did you do?
protoreflect.Value does not seem to provide the correct type attached to the interface{} for message oneof fields. For example, given the following protobuf:
syntax = "proto3";

message Image {
    string mime_type = 1;
    bytes data = 2;
}

message Person {

    string name = 1;

    oneof avatar {
        string url = 2;
        Image image = 3;
    }
}

And the following program:
func main() {

	a := &person.Person{
		Name: "A",
		Avatar: &person.Person_Url{
			Url: "https://...",
		},
	}

	b := &person.Person{
		Name: "B",
		Avatar: &person.Person_Image{
			Image: &person.Image{
				MimeType: "image/png",
				Data:     []byte{ /*...*/ },
			},
		},
	}

	fmt.Printf("A:\n")
	a.ProtoReflect().Range(func(fd pref.FieldDescriptor, val pref.Value) bool {
		fmt.Printf("  %s = %T\n", fd.Name(), val.Interface())
		return true
	})

	fmt.Printf("B:\n")
	b.ProtoReflect().Range(func(fd pref.FieldDescriptor, val pref.Value) bool {
		fmt.Printf("  %s = %T\n", fd.Name(), val.Interface())
		return true
	})

	msg := b.ProtoReflect()
	imageFd := msg.Descriptor().Fields().ByName("image")
	fmt.Printf("has image = %v\n", msg.Has(imageFd))
	ival := msg.Get(imageFd).Interface() // incorrectly has type *impl.messageState
	fmt.Printf("type = %T\n", ival)

	// pointer address seems correct, however
	im := (*person.Image)(unsafe.Pointer(reflect.ValueOf(ival).Pointer()))
	fmt.Printf("mime type = %s\n", im.MimeType)
}

It prints out the following:
> go run main.go
A:
  name = string
  url = string
B:
  name = string
  image = *impl.messageState
has image = true
type = *impl.messageState
mime type = image/png

What did you expect to see?
The value obtained from the message's image field should have a type of *person.Image.
What did you see instead?
The interface is of type *impl.messageState which prevents expected normal interface coercion to the proper type. i.e. val.Interface().(*person.Image)

I don't think this has anything to do with oneofs.
The issue that protoreflect.Value operates on a protoreflect.Message types for a message, and not a proto.Message.
To obtain on a proto.Message, you'll need to additionally call the protoreflect.Message.Interface method.
This should do what you want:
b.ProtoReflect().Range(func(fd pref.FieldDescriptor, val pref.Value) bool {
	v := val.Interface()
	if m, ok := v.(pref.Message); ok {
		v = m.Interface()
	}
	fmt.Printf("  %s = %T\n", fd.Name(), v)
	return true
})

Ah, indeed, you are correct!


fix: locks on singleton and client state to ensure thread safety

This PR

locks on singleton and client state to ensure thread safety

Related Issues

Fixes https://github.com/open-feature/go-sdk/issues/90
Notes

Follow-up Tasks

How to test

Codecov Report

Merging #93 (efd2342) into main (9fbed88) will increase coverage by 2.02%.
The diff coverage is 95.34%.

@@            Coverage Diff             @@
##             main      #93      +/-   ##
==========================================
+ Coverage   69.24%   71.26%   +2.02%
==========================================
  Files           7        7
  Lines         569      623      +54
==========================================
+ Hits          394      444      +50
- Misses        158      162       +4
  Partials       17       17

Impacted Files
Coverage Δ

pkg/openfeature/client.go
71.23% <93.75%> (+1.85%)
:arrow_up:

pkg/openfeature/openfeature.go
92.98% <100.00%> (+2.28%)
:arrow_up:

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more


Makefile: use the most updated tag as default

When a user is running make deploy without specifiying any specific option we should deploy the controller with the most updated version.
The most updated version that is getting build (automatically by the CI) is with the 4.10-snapshot tag, hence that should be the default.
Not running with the most updated version out of the box, might lead to gaps between what specified in the manifests (flags, args, etc.) and what the binary in the image actually contains
Signed-off-by: Talor Itzhak<EMAIL_ADDRESS>

the idea is good, but it clashes with our (and OCP's?) tagging policy

the idea is good, but it clashes with our (and OCP's?) tagging policy

it seems so, but I don't understand why in the CI it's using the VERSION from the Makefile.
I thought we should inject and use the latest build from prow

Deprecated by https://github.com/openshift/release/pull/25141


Feat:CI and CD pipeline

Describe the feature
Continuous Integration (CI) and Continuous Deployment (CD) pipelines are essential practices in modern software development, offering numerous advantages that enhance the efficiency, reliability, and quality of software projects. Here are some key benefits:
Improved Code Quality.
Faster Delivery and Deployment,
Increased Collaboration and Transparency,
Enhanced Customer Satisfaction.
Implementing CI/CD pipelines brings a wide range of advantages, from improving code quality and speeding up delivery cycles to reducing risks and enhancing team collaboration. These benefits collectively contribute to the development of high-quality software, quicker time-to-market, and higher customer satisfaction, making CI/CD pipelines a cornerstone of modern software development practices
Add ScreenShots
NA
Record

[X] I agree to follow this project's Code of Conduct
[X] I'm a GSSOC'24 contributor
[X] I want to work on this issue

how do you implement this ? what's your thought process !!

First, I create a Dockerfile, then create two YAML files in the GitHub folder for the CI pipeline. I'll write some commands:
First, I write all the jobs that the CI has to follow.
Then, name the jobs.
Name the job machines.
Clone the repo on the machine.
Install dependencies.
Then, run lint checks to verify the flow.


Users can mint many nfts

In the mint function we accept a zk proof and verify it against the semaphore root. This allows a single user to make many proofs using the same identity.
I think we should limit the number of tokens that can be minted to 1 per semaphore identity. Since we're burning these semaphore identities after this event we could accept a simple proof of ownership for an identity commitment. Then we add the commitment to a list indicating it has claimed a token.

@vimwitch that mint function is only used to save 9-canvas pictures, the owner is the TAZ contract itself. Since the proof verification for each specific canvas happens off-chain, I think we can use that function without any on-chain proof verification.
I think it's also ok to show two different ways to verify proofs: off-chain and on-chain.


Load default parameter set first. Remove SAPIEN mention from notes.

New Pester test for module help. By default, tests help for latest version of PSScriptAnalyzer module.

This change is

Do not work on a plane with intermittent internet access. You're likely to upload wrong file. Sorry!


TenantCouldNotBeIdentifiedOnDomainException

Problem
This is for whoever is getting the TenantCouldNotBeIdentifiedOnDomainException for when a tenant does not exist
Solution
What i did is in the Providers/TenancyServiceProvider in the boot method i put this and it works like a charm.
InitializeTenancyByDomain::$onFail = function ($exception, $request, $next) {
            return redirect('http://my-domain.com'); //the domain you want redirected to, or you can also show a custom error page
};

Your setup

Laravel version: [e.g. 8.61.0]
stancl/tenancy version: [3.4]

If this does not work for someone - check if you are using universal routes. You have to deactivate universal routes to use this solution.


fix #10: add support for garrison and dalaran hearthstones

This isn't quite working. I'm occasionally getting this error:
Message: Interface/AddOns/HearthRoulette/Addon.lua:181: attempt to concatenate local 'toyName' (a nil value)
Time: Sat Nov 25 23:28:50 2023
Count: 1
Stack: Interface/AddOns/HearthRoulette/Addon.lua:181: attempt to concatenate local 'toyName' (a nil value)
[string "=[C]"]: ?
[string "@Interface/AddOns/HearthRoulette/Addon.lua"]:181: in function `_UpdateToys'
[string "@Interface/AddOns/HearthRoulette/Addon.lua"]:111: in function `UpdateAll'
[string "@Interface/AddOns/HearthRoulette/Events.lua"]:48: in function `?'
[string "@Interface/AddOns/HearthRoulette/Events.lua"]:8: in function <Interface/AddOns/HearthRoulette/Events.lua:6>

Locals: (*temporary) = <function> defined =[C]:-1

closing, merged to main


Merge pull request #1 from wu-sheng/master

update from base repository.

Coverage remained the same at 17.393% when pulling 532eab53c0956483081ab6c4efd9428a2256dd86 on trey03:master into 3f188b14548b8c3cbe49be7b75251471458c2e36 on wu-sheng:master.

Coverage remained the same at 17.393% when pulling 532eab53c0956483081ab6c4efd9428a2256dd86 on trey03:master into 3f188b14548b8c3cbe49be7b75251471458c2e36 on wu-sheng:master.

This is an invalid pr, closing it.


Gas-load charts do not load for the LESses I have tried

For instance: https://beta-moses.energytransitionmodel.com/testing_grounds/499/gas_load

The HTTP request times out because the LES takes too long to calculate. We'll need to switch this page to use a poller. I think this is related to #1017.

What's the status?

What's the status?

This will be picked up in the current sprint. I have increased its priority but it would still be useful to know if you need this at a certain time.

@JeroenvdLogt @ThomBuijs Do you need this for a certain time?

Preferably, I would like this as soon as possible, since I will work on a use case which will include electricity, gas, and heat. Heat will still be in beta, so I would like to focus on electricity and gas for the moment and continue with heat as soon as it will be available on the live server. What would you advice?

Preferably, I would like this as soon as possible

We expect to have this working (on BETA) today.
@antw is the gas-chart something that can be cherry-picked to LIVE easily so @ThomBuijs can work on electricity and gas in the LIVE server and heat networks can still be tested more on BETA?

The yearly gas flow chart fixes will be on beta momentarily. I'll see what I can do about getting it onto the live server...

I'll see what I can do about getting it onto the live server...

I don't think this is possible. There are too many changes to the inner-workings of the charts, and those changes are mixed into commits involving heat. It's all or nothing. 😞

I don't think this is possible. There are too many changes to the inner-workings of the charts, and those changes are mixed into commits involving heat. It's all or nothing. 😞

Thanks @antw for your assessment!

I was wondering what the status is of this issue. What does

grdw added a commit that referenced this issue a day ago

mean?

What does "grdw added a commit that referenced this issue a day ago" mean?

You can ignore that; it means some piece of code was changed, and that the change had something to do with this issue. In this case, the change was actually made ten days ago.
The issue has been fixed, and the changes are on the beta server already; it should now be possible to view the weekly gas load charts and annual gas flow charts for all LESes. It it not yet available on the live/production server since it depends on certain features which were added to accommodate the heat network.

The yearly gas flow doesn't seem to work anymore in my LES https://beta-moses.energytransitionmodel.com/testing_grounds/675/gas_load. I have seen it when you mentioned it was fixed, but right now it seems to stop working. My LES has only 10 households  so it is not that big.

The error you are receiving (which is a little vague) does not have to do with the original issue. The problem is in #1371 . Therefor I'm closing this issue and will copy your comment over to that issue to keep github issue a bit cleaner.


Mismatch in execution results between original and transpiled quantum circuits

Environment

Qiskit Terra version: 0.25.2
Python version: 3.10.9
Operating system: MacOS 13.5 Ventura

What is happening?
There is a significant difference in the execution probabilities between the origianl and transpiled versions of a quantum circuit.
How can we reproduce the issue?
To reproduce the issue, run the following Python code:
import qiskit
from qiskit import QuantumCircuit, transpile, Aer

bug_qasm = """OPENQASM 2.0;
include "qelib1.inc";
gate xx_minus_yy(param0,param1) q0,q1 { rz(-1.0*param1) q1; rz(-pi/2) q0; sx q0; rz(pi/2) q0; s q1; cx q0,q1; ry(param0/2) q0; ry(-0.5*param0) q1; cx q0,q1; sdg q1; rz(-pi/2) q0; sxdg q0; rz(pi/2) q0; rz(param1) q1; }
gate cz_o0 q0,q1 { x q0; cz q0,q1; x q0; }
gate cu_o0(param0,param1,param2,param3) q0,q1 { x q0; cu(5.357846225354717,2.6501721205180506,2.517537079356961,2.314755551822069) q0,q1; x q0; }
qreg q[5];
creg c[5];
xx_minus_yy(5.406019900390381,5.335758733864367) q[3],q[0];
xx_minus_yy(1.0133883523318572,4.84610607777235) q[2],q[1];
ch q[2],q[1];
cu_o0(5.357846225354717,2.6501721205180506,2.517537079356961,2.314755551822069) q[2],q[1];
x q[2];
crx(0.7209182093135525) q[3],q[2];
cz_o0 q[3],q[2];
crx(1.9847086501028472) q[3],q[2];
rx(4.073913392539286) q[2];
measure q[0] -> c[0];
measure q[1] -> c[1];
measure q[2] -> c[2];
measure q[3] -> c[3];
measure q[4] -> c[4];"""

simulator = Aer.get_backend("aer_simulator")
circ = QuantumCircuit.from_qasm_str(bug_qasm)
original = transpile(circ, backend=simulator, optimization_level=0)
transpiled = transpile(transpile(circ, optimization_level=3), backend=simulator, optimization_level=0)

orig_count = simulator.run(original, shots=100000).result().get_counts()
trans_count = simulator.run(transpiled, shots=100000).result().get_counts()

for k in sorted(orig_count.keys()):
    print(f"{k}: {orig_count.get(k, 0):>5} {trans_count.get(k, 0):>5}")

Upon execution, the result differ in the original and transpiled circuits, as shown below:
00000: 56379 27509  // different
00010:  3148 20967  // different
00100:  3441 32037  // different
00110: 19066  1510  // different
01001:  4600  4539
01011:   988   989
01101:  8530  8555
01111:  3848  3894

What should happen?
The probabilities for both the original and transpiled circuits should be consistent.
Any suggestions?
During the transpilation process, there is a NumPy warning related to matrix determinant calculations. This could potentially be the source of the issue:
.../python3.10/site-packages/numpy/linalg/linalg.py:2154: RuntimeWarning: divide by zero encountered in det
  r = _umath_linalg.det(a, signature=signature)
.../python3.10/site-packages/numpy/linalg/linalg.py:2154: RuntimeWarning: invalid value encountered in det
  r = _umath_linalg.det(a, signature=signature)

It's possible that an incorrect use of the NumPy library within Qiskit transpiler is causing the discrepancy.

Please check issue #3689 .

Hello, thank you for the comment.
Upon reviewing #3689, I noticed that while both issues are about the transpilation/optimization process, this issue is not a duplicate. Specifically, I applied the same testing procedure on my end and found no discrepancies or NumPy warnings in the example circuit from issue #3689.
Given these differences, could this be considered a new, unique transpiler bug? I'm interested in delving into this further and could allocate time for investigation (and bug fix, if possible) this winter.

I've tested the above circuit and it seems that with current main HEAD it works fine, and by bisecting I found that from this commit onward the divergent behavior disappeared.
@alexanderivrii would you kindly take a look if this is the case?

It seems this bug has been fixed in the latest version (released shortly after the issue was created). Closing the issue. Thanks to @doehyunbaek for pointing this out!


Fixed UI of values cards and team cards

Fixed Values UI Cards and team members UI. Added hover effect on the cards for better user experience.

@MonilMehta Add both before & after screenshot

Before

After

@MonilMehta Awesome contribution to Hacktoberfest'24! 🎉 Your work is super valuable. Keep up the great work!


0.28.1 - Unable to connect to RabbitMQ via SSL using EXTERNAL connection

We had sensu client 0.26.5-2 and we upgraded to 0.28.1-1 on RHEL 6.8 server and wihtout changing any details of rabbitmq or the cacerts adn we finally noticed that the 0.28.1-1 version of client is not ablet omake a sucessfull SSL connection using the auth mechanism ssl enabled in Rabbit and using the cacerts from teh previous versions of the sensu client. When we reverted back to sensu 0.26.5-2, again without any changes to config, we could see the sucessfull connection.
Expected Behavior

When upgrading sensu, we should have a flawless working connection after upgrade
Current Behavior

After upgrade unablet o make a SSL connection to rabbit MQ
Possible Solution

Dont Know
Steps to Reproduce (for bugs)

Install sensu 0.26.5-2 with rabbit MQ on SSL and client side having the auth mechanism set to EXTERNAL
Check the connectivity for 0.26.5-2
Upgrade thesensu to 0.28.1-1, watch the sensu logsand netstat to find the connections
4.The below logs will appear after upgrading to 0.28.1-1
{"timestamp":"2017-03-03T08:41:02.468064-0500","level":"warn","message":"loading config files from directory","directory":"/etc/sensu/conf.d"}
{"timestamp":"2017-03-03T08:41:02.468088-0500","level":"warn","message":"loading config file","file":"/etc/sensu/conf.d/client/rabbitmq.json"}
{"timestamp":"2017-03-03T08:41:02.468132-0500","level":"warn","message":"applied sensu client overrides","client":{"name":"sd-56ac-b426","address":"<IP_ADDRESS>","subscriptions":["client:sd-56ac-b426"]}}
{"timestamp":"2017-03-03T08:41:02.470819-0500","level":"warn","message":"loading extension files from directory","directory":"/etc/sensu/extensions"}
{"timestamp":"2017-03-03T08:41:02.470877-0500","level":"info","message":"configuring sensu spawn","settings":{"limit":12}}
{"timestamp":"2017-03-03T08:41:02.688061-0500","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":null}
{"timestamp":"2017-03-03T08:41:14.865141-0500","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":null}
{"timestamp":"2017-03-03T08:41:17.865932-0500","level":"warn","message":"transport connection error","reason":"tcp connection lost"}
{"timestamp":"2017-03-03T08:41:17.866082-0500","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":null}
{"timestamp":"2017-03-03T08:41:58.853068-0500","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":null}
{"timestamp":"2017-03-03T08:42:01.854129-0500","level":"warn","message":"transport connection error","reason":"tcp connection lost"}
{"timestamp":"2017-03-03T08:42:01.854285-0500","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":null}

Context

Its a dev machine and happy to provide what ever details needed, please be noted taht the same settings works fine for 0.26.5-2
Your Environment

Sensu version used: 0.28.1-1
Active Sensu extensions (e.g. WizardVan 0.1.0): Nothing
Operating System and version (e.g. Ubuntu 14.04): RHEL 6.8
Transport and runtime versions (e.g. RabbitMQ 3.6.2 on Erlang 18.2): RabbitMQ 3.6.5 Erlang/OTP 19.0

Hi @balajik1992, thanks for reporting this.

Install sensu 0.26.5-2 with rabbit MQ on SSL and client side having the auth mechanism set to EXTERNAL

I take it that your comments referencing configuration of authentication mechanisms is referring to the RabbitMQ broker? To my knowledge Sensu itself has no configuration for specifying RabbitMQ authentication mechanisms. Can you please share your Sensu client's RabbitMQ configuration?

Attaching the rabbitmq json file
{
"rabbitmq": [
{
"host": "hostname",
"port": 5671,
"vhost": "/sensu",
"heartbeat": 30,
"prefetch": 50,
"auth_mechanism": "EXTERNAL",
"ssl": {
"cert_chain_file": "/etc/sensu/ssl/cacerts.pem"
},
"verify_peer": false
}
]
}

@sureshsubramaniam
is there really an option to configure auth_mechanism in sensu config for rabbitmq?
We are using SSL as well...and all works fine.
I am missing private_key_file in tour config.
verify_peer is also not valid I would say...
This is what we have in rabbitmq config (for rabbitmq):
{ssl_options, [{cacertfile,           "/etc/rabbitmq/ssl/cacert.pem"},
{certfile,             "/etc/rabbitmq/ssl/cert.pem"},
{keyfile,              "/etc/rabbitmq/ssl/key.pem"},
{verify,               verify_peer},
{fail_if_no_peer_cert, true}]},
{auth_mechanisms, ['PLAIN', 'AMQPLAIN']}

@mcbsdEU
This is the sensu client side rabbitmq.json where you can define the rabbitmq config info and this has been working till 0.26.5-2 without issues. You can use external auth and use the certificate CN as the username

Ok, interesting...

It reduces the workload on populating the keys and security issues on sharing the private key to the clients

So you are using following option in rabbitmq config ?
{ssl_cert_login_from, common_name}

To my knowledge Sensu itself has no configuration for specifying RabbitMQ authentication mechanisms.

My understanding here is only half-right. Sensu itself doesn't do anything with rabbitmq attributes like auth_mechanism but they are passed along to the underlying amqp library.

@cwjohnston
yes i  also have the same understanding, but somehow with the same config the sensu client 0.26.5 and the prior versions are working as expected, but the versions above 0.26.5 is not working, i tried all the versions after 0.26.5, it has the same behavior, was there anything that was changed for transport after 0.26.5

BTW we are using our internal signed cert in the RabbitMQ config and the internal CA Chain

@sureshsubramaniam yes there have been changes to the transport, e.g. sensu-transport v6.0.0 to v7.0.2.
Are you seeing anything relevant to this connection failure in the RabbitMQ broker log?

not really, the rabbitmq log says as below for every connection attempt from the client. But if i connect a client v 0.26.5 from the same server that was running 0.28.1 it connects successfully, i can see the connect log in the rabbit and also the rabbitmqctl list_connections, using the same rabbitmq config on the client side
=ERROR REPORT==== 3-Mar-2017::12:25:35 ===
SSL: certify: ssl_connection.erl:456:Fatal error: handshake failure
=ERROR REPORT==== 3-Mar-2017::12:25:55 ===
SSL: certify: ssl_connection.erl:456:Fatal error: handshake failure
=ERROR REPORT==== 3-Mar-2017::12:26:15 ===
SSL: certify: ssl_connection.erl:456:Fatal error: handshake failure

I also see that 0.26.5 (our last release using sensu-build) ships with OpenSSL 1.0.1t, and releases built with sensu-omnibus since then are using OpenSSL 1.0.2j or newer.

@balajik1992 @sureshsubramaniam can you provide output of rabbitmqctl eval 'ssl:cipher_suites(openssl).' from your RabbitMQ broker?

@balajik1992 @sureshsubramaniam also your system's installed version of openssl may be relevant

Had the same issues after upgrading. OpenSSL is the cause and i needed to upgrade Erlang to 19 for it to work again. It seems as the newer OpenSSL contains and advertises some Ciphers which Erlang can't understand and therefore fails to ignore them.

@cwjohnston the openssl version used in the rabbitmq server runnignon RHEL 6.8 is OpenSSL 1.0.1e-fips 11 Feb 2013. The erlang OTP version is Erlang/OTP 19 [erts-8.0] [source] [64-bit] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]
The output of the list of ciphers being honored are as follows
["ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384",
"ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384",
"ECDH-ECDSA-AES256-GCM-SHA384","ECDH-RSA-AES256-GCM-SHA384",
"ECDH-ECDSA-AES256-SHA384","ECDH-RSA-AES256-SHA384",
"DHE-RSA-AES256-GCM-SHA384","DHE-DSS-AES256-GCM-SHA384",
"DHE-RSA-AES256-SHA256","DHE-DSS-AES256-SHA256","AES256-GCM-SHA384",
"AES256-SHA256","ECDHE-ECDSA-AES128-GCM-SHA256",
"ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES128-SHA256",
"ECDHE-RSA-AES128-SHA256","ECDH-ECDSA-AES128-GCM-SHA256",
"ECDH-RSA-AES128-GCM-SHA256","ECDH-ECDSA-AES128-SHA256",
"ECDH-RSA-AES128-SHA256","DHE-RSA-AES128-GCM-SHA256",
"DHE-DSS-AES128-GCM-SHA256","DHE-RSA-AES128-SHA256","DHE-DSS-AES128-SHA256",
"AES128-GCM-SHA256","AES128-SHA256","ECDHE-ECDSA-AES256-SHA",
"ECDHE-RSA-AES256-SHA","DHE-RSA-AES256-SHA","DHE-DSS-AES256-SHA",
"ECDH-ECDSA-AES256-SHA","ECDH-RSA-AES256-SHA","AES256-SHA",
"ECDHE-ECDSA-DES-CBC3-SHA","ECDHE-RSA-DES-CBC3-SHA","EDH-RSA-DES-CBC3-SHA",
"EDH-DSS-DES-CBC3-SHA","ECDH-ECDSA-DES-CBC3-SHA","ECDH-RSA-DES-CBC3-SHA",
"DES-CBC3-SHA","ECDHE-ECDSA-AES128-SHA","ECDHE-RSA-AES128-SHA",
"DHE-RSA-AES128-SHA","DHE-DSS-AES128-SHA","ECDH-ECDSA-AES128-SHA",
"ECDH-RSA-AES128-SHA","AES128-SHA"]

@lobeck is there a specific version under 19 of erlang that worked for you, as we are using the erlang 19.0 with the rabbitmq v3.6.5

@sureshsubramaniam no idea, i was using the (CentOS 7) system packages before. I then switched to the upstream packages, which required a switch of both Erlang and RabbitMQ. Didn't investigate much further at this point, just wanted it running again and the latest versions were good.

Hi @cwjohnston ,, Please look into the cipher...please let us know your suggestions

@sureshsubramaniam I suspect https://bugs.erlang.org/browse/ERL-203 is relevant here, reportedly fixed in Erlang 19.1.

@cwjohnston, we are also using 19.2.3 version (erlang) and sensu-0.28.1 , but not working

@balajik1992 what version of openssl is installed on your rabbitmq system?

@cwjohnston
OpenSSL 1.0.1e-fips 11 Feb 2013

@cwjohnston
with RHEL6 , we have tested with openssl-1.0.1e-48.el6_8.3.x86_64, with RHEL7, we tested with openssl-1.0.1e-51.el7_2.5.x86_64...Both are not accepting cacaerts.

Hi.
We have the same problem
{"timestamp":"2017-03-16T18:38:08.992213+0100","level":"warn","message":"transport connection error","reason":"tcp connection lost"}
{"timestamp":"2017-03-16T18:38:08.992306+0100","level":"warn","message":"transport connection error","reason":"possible authentication failure. wrong credentials?","user":"sensu"}
with a sensu-client 0.28.3-1.el7 installed on centos 7 and rabbitmq server 3.6.7 using SSL connection. Older clients (<= 0.27) in other servers work correctly.

I  tried upgrading the OpenSSL on raabitmq server and client server to 1.0.2j and saw the same issue. My suspect now on amqp client being used, @cwjohnston can shed some light if there is a change in the amqp client being used on newer Sensu clients.

@cwjohnston I also tried with openssl to 1.0.2k still the same issue for clients using only cacerts and making a external auth in rabbitmq

I have similar issue. Most recent sensu version that works for me is 0.24.1.

@balajik1992 which version of Erlang do you have installed?

@sureshsubramaniam are you able to upgrade to Erlang 19.1 (or later) and see if you are still experiencing this issue?

@b3niup There were no changes to OpenSSL or transport code between 0.24.1 and 0.25.0. Are you able to re-confirm that upgrading to 0.25.0-1 causes this issue for you?

My bad, I re-verified this and 0.25.0-1 seems to work fine. 0.26.0-1 too.
0.27.0-3 does not though.

As this seems to be a build related issue, I am going to remove this issue from the 0.29 milestone.

@portertech can you please provide some insights on the build issue related to this, so that we can Ensure to double check if this happens in future

As this seems to appear from versions above 0.26.5

@sureshsubramaniam this issue is still open. We determining what exactly causes the issue, seems that it's likely to do with the move to embedded openssl 1.0.2 in the Sensu 0.27 builds (not to do with the Sensu Core code). This Sensu Core GH issue has many contributors, which does cause some issues with the signal/noise ratio, but in the end usually helps debug it and find the cause.

@cwjohnston are we considering this for the package of 0.29 in the build package that is using a embedded openssl

I have just tested with 29.0-7, but the problem stays the same.

@sureshsubramaniam can you please run the following command and provide the output here:
rabbitmqctl status

Thank you.

@portertech Attaching the output from the rabbitmq status
sensu - 0.28.4
rabbitmq - 3.6.9
Seems to be an issue with the 0.29.0-7 aswell, with the multiple rabbitmq 3.6.5 - 3.6.9
rabbitmqctl status
Status of node 'rabbit@testhost' ...
[{pid,9935},
{running_applications,
[{rabbitmq_auth_mechanism_ssl,
"RabbitMQ SSL authentication (SASL EXTERNAL)","3.6.9"},
{rabbitmq_amqp1_0,"AMQP 1.0 support for RabbitMQ","3.6.9"},
{rabbit,"RabbitMQ","3.6.9"},
{os_mon,"CPO  CXC 138 46","2.4.2"},
{amqp_client,"RabbitMQ AMQP Client","3.6.9"},
{rabbit_common,
"Modules shared by rabbitmq-server and rabbitmq-erlang-client",
"3.6.9"},
{xmerl,"XML parser","1.3.13"},
{ranch,"Socket acceptor pool for TCP protocols.","1.3.0"},
{ssl,"Erlang/OTP SSL application","8.1.1"},
{public_key,"Public key infrastructure","1.4"},
{crypto,"CRYPTO","3.7.3"},
{asn1,"The Erlang ASN1 compiler version 4.0.4","4.0.4"},
{syntax_tools,"Syntax tools","2.1.1"},
{compiler,"ERTS  CXC 138 10","7.0.4"},
{mnesia,"MNESIA  CXC 138 12","4.14.3"},
{sasl,"SASL  CXC 138 11","3.0.3"},
{stdlib,"ERTS  CXC 138 10","3.3"},
{kernel,"ERTS  CXC 138 10","5.2"}]},
{os,{unix,linux}},
{erlang_version,
"Erlang/OTP 19 [erts-8.3] [source] [64-bit] [smp:4:4] [async-threads:64] [hipe] [kernel-poll:true]\n"},
{memory,
[{total,57892904},
{connection_readers,343144},
{connection_writers,19768},
{connection_channels,155944},
{connection_other,256272},
{queue_procs,423856},
{queue_slave_procs,0},
{plugins,2832},
{other_proc,19658624},
{mnesia,110824},
{metrics,198560},
{mgmt_db,0},
{msg_index,44440},
{other_ets,2290640},
{binary,2454064},
{code,21910738},
{atom,900041},
{other_system,9318885}]},
{alarms,[]},
{listeners,[{clustering,25672,"::"},{'amqp/ssl',5671,"<IP_ADDRESS>"}]},
{vm_memory_high_watermark,0.4},
{vm_memory_limit,6690381824},
{disk_free_limit,50000000},
{disk_free,93390635008},
{file_descriptors,
[{total_limit,10140},
{total_used,6},
{sockets_limit,9124},
{sockets_used,4}]},
{processes,[{limit,1048576},{used,209}]},
{run_queue,0},
{uptime,11465},
{kernel,{net_ticktime,60}}]

Erlang used is 19.3.0 (Zero dependency Erlang/OTP 19.3)

We've run into this issue as well.
Sensu: 0.29.0-7
rabbitmq: 3.6.9-1.el6
Erlang: 19.2
Reverting to Sensu 0.26.5-2 resolved the issue.

I suspect this issue may have something to do with the way in which the certificates in use are being generated. Is anyone experiencing this problem using certs generated by the Sensu SSL tool ?
@royalj @sureshsubramaniam @b3niup @Koen76 can you please use the following openssl command to determine the signature algorithm and public key algorithm for your certificates and report back?
openssl x509 -in cert.pem  -text -noout
The output should be similar to this, edited for brevity:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=SensuCA
        Validity
            Not Before: Apr 13 20:30:03 2017 GMT
            Not After : Apr 12 20:30:03 2022 GMT
        Subject: CN=sensu, O=server
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (2048 bit)
                Modulus (2048 bit):
                    <snip>
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
    Signature Algorithm: sha1WithRSAEncryption
       <snip>

@cwjohnston
We don't use the Sensu SSL Tool to generate certs
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            <snip>
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA
        Validity
            Not Before: Mar  9 00:00:00 2017 GMT
            Not After : May 27 12:00:00 2020 GMT
        Subject: C=US, ST=State, L=Locale, O=My Organization, OU=My OU, CN=*.domain.com
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                   <snip>
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                <snip>
            X509v3 Subject Key Identifier:
                <snip>
            X509v3 Subject Alternative Name:
                <snip>
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 CRL Distribution Points:
                Full Name:
                  URI:http://crl3.digicert.com/sha2-ha-server-g5.crl
                Full Name:
                  URI:http://crl4.digicert.com/sha2-ha-server-g5.crl
            X509v3 Certificate Policies:
                Policy: 2.16.840.1.114412.1.1
                  CPS: https://www.digicert.com/CPS
                Policy: <IP_ADDRESS>.2.2
            Authority Information Access:
                OCSP - URI:http://ocsp.digicert.com
                CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt
            X509v3 Basic Constraints: critical
                CA:FALSE
    Signature Algorithm: sha256WithRSAEncryption
         <snip>

@royalj thanks for the details. I have adjusted my local test to use SHA256 instead of SHA1 but I am still unable to reproduce this. Are you using "auth_mechanism": "EXTERNAL" in your Sensu configuration?

I am also curious if anyone experiencing this issue has tried explicitly setting versions and ciphers in rabbitmq.config ssl_options as described in the Sensu SSL reference documentation, e.g.:
[
  {rabbit, [
     {ssl_listeners, [5671]},
     {ssl_options, [{cacertfile,"/etc/rabbitmq/ssl/cacert.pem"},
                    {certfile,"/etc/rabbitmq/ssl/cert.pem"},
                    {keyfile,"/etc/rabbitmq/ssl/key.pem"},
                    {versions, ['tlsv1.2']},
                    {ciphers,  [{rsa,aes_256_cbc,sha256}]},
                    {verify,verify_peer},
                    {fail_if_no_peer_cert,true}]}
   ]}
].

My cert:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=SensuCA
        Validity
            Not Before: Feb 14 11:14:50 2015 GMT
            Not After : Feb 13 11:14:50 2020 GMT
        Subject: CN=sensu, O=client
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    -- cut --
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
    Signature Algorithm: sha1WithRSAEncryption
        -- cut --

I've tried mentioned ssl_options without any improvement.

After I updated my rabbitmq ssl options to include the cipher and version configs to match the Sensu SSL reference docs, upgraded to Sensu 0.29.0-7 and it is now working for me. We are not using the auth_mechanism option in our Sensu configuration.

@cwjohnston
The Cert details for your information
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
5d:b3:bf:93:00:00:00:00:3b:a9
Signature Algorithm: sha1WithRSAEncryption
Issuer: DC=INTERNAL, DC=INTERNAL, CN=INTERNAL
Validity
Not Before: Mar  2 09:21:58 xxxx GMT
Not After : Mar  2 09:21:58 xxxx GMT
Subject: C=INTERNAL, O=INTERNAL, OU=INTERNAL, CN=hostshortname
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Alternative Name:
DNS:FQDN of RABBITMQHOST, DNS:SHORTNAME OF RABBITMQ HOST
X509v3 Subject Key Identifier:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
X509v3 Authority Key Identifier:
keyid:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
        X509v3 CRL Distribution Points:

            Full Name:
              URI:http://internalURL
              URI:ldap:///internalURL

        Authority Information Access:
            CA Issuers - URI:http://internalURL
            CA Issuers - URI:ldap:///internalURL

        X509v3 Key Usage: critical
            Digital Signature, Key Encipherment
        <IP_ADDRESS>.4.1.xxx.xx.xxx:
            0+.#+.....7.....,.../.......N..B...E..F..d...
        X509v3 Extended Key Usage:
            TLS Web Server Authentication, TLS Web Client Authentication
        <IP_ADDRESS>.4.1.xxx.xxx.xxx:
            0.0

..+.......0
..+.......
S/MIME Capabilities:
......0...+....0050....H..
...H..
Signature Algorithm: sha1WithRSAEncryption
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:

we had been using the rabbitmq config as follows, which includes the versions
The below ciphers were working for us until the 26.5, will try with rsa,aes_256_cbc,sha256 and will keep posted
[
{ssl, [{versions, ['tlsv1.2', 'tlsv1.1']}]},
{rabbit, [
{cluster_partition_handling, pause_minority},
{ssl_listeners, [5671]},
{tcp_listeners, []},
{log_levels,[{connection, debug}]},
{ssl_allow_poodle_attack, false},
{ssl_apps,[asn1,crypto,public_key,ssl]},
{auth_mechanisms, [ 'EXTERNAL', 'PLAIN', 'AMQPLAIN' ]},
{ssl_cert_login_from, common_name},
{ssl_options, [{cacertfile,"/etc/sensu/ssl/cacerts.pem"},
{certfile,"/etc/sensu/ssl/hostcert.pem"},
{keyfile,"/etc/sensu/ssl/key.pem"},
{versions, ['tlsv1.2', 'tlsv1.1']},
{dhfile, "/etc/sensu/ssl/dh-params.pem"},
{ciphers, ["ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384",
"ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384", "ECDHE-ECDSA-DES-CBC3-SHA",
"ECDH-ECDSA-AES256-GCM-SHA384","ECDH-RSA-AES256-GCM-SHA384","ECDH-ECDSA-AES256-SHA384",
"ECDH-RSA-AES256-SHA384","DHE-DSS-AES256-GCM-SHA384","DHE-DSS-AES256-SHA256",
"AES256-GCM-SHA384","AES256-SHA256","ECDHE-ECDSA-AES128-GCM-SHA256",
"ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES128-SHA256","ECDHE-RSA-AES128-SHA256",
"ECDH-ECDSA-AES128-GCM-SHA256","ECDH-RSA-AES128-GCM-SHA256","ECDH-ECDSA-AES128-SHA256",
"ECDH-RSA-AES128-SHA256","DHE-DSS-AES128-GCM-SHA256","DHE-DSS-AES128-SHA256",
"AES128-GCM-SHA256","AES128-SHA256"]},
{depth, 2},
{verify,verify_peer},
{fail_if_no_peer_cert,true},
{secure_renegotiate, true},
{reuse_sessions, true},
{honor_cipher_order, true},
{max_connections, infinity}]}
]}
].

@portertech thanks for looking into this

Also seeing this on a CentOS environment with "vanilla" sensu 0.29 with key/cert/cacert out of the sensu ssl generation tool.

Seeing this on 0.29.0 release 11 rpm also

@portertech, @cwjohnston, @agoddard would love an update on this issue, pretty please.

Also seeing this issue on centos 7 with 0.29.0 works fine with out ssl.
using the sensu-ansible playbook that uses the ssl generation scripts
rabbit:
[
    {rabbit, [
        {ssl_listeners, [5671]},
    {ssl_options, [{cacertfile,"/etc/rabbitmq/ssl/cacert.pem"},
                   {certfile,"/etc/rabbitmq/ssl/cert.pem"},
                   {keyfile,"/etc/rabbitmq/ssl/key.pem"},
	            {versions, ['tlsv1.2']},
                    {ciphers,  [{rsa,aes_256_cbc,sha256}]},
                   {verify,verify_peer},
                   {fail_if_no_peer_cert,true}]}
      ]}
].

/etc/sensu/conf.d/rabbitmq
{
  "rabbitmq": {
        "ssl": {
      "cert_chain_file": "/etc/sensu/ssl/cert.pem",
      "private_key_file": "/etc/sensu/ssl/key.pem"
    },
        "host": "xx.utl.xx.lab.priv",
    "port": 5671,
    "vhost": "/sensu",
    "user": "sensu",
    "password": "sensu"
  }
}

cert
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: CN=SensuCA
        Validity
            Not Before: Jun 20 20:42:59 2017 GMT
            Not After : Jun 19 20:42:59 2022 GMT
        Subject: CN=sensu, O=client
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                <snip>
                           Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
    Signature Algorithm: sha1WithRSAEncryption

@cwjohnston @portertech @agoddard any luck on this issue. Your help is much appreciated on this

@sureshsubramaniam @dmsimard @b3niup @Koen76
Sorry to say but I am still not able to reproduce this issue. Unfortunately a number of folks have been commenting here without providing a complete set of details around their platform, openssl, erlang and rabbitmq versions.
As some have indicated that reconfiguring ciphers has solved the problem for them, I am increasingly certain this issue boils down to the intersection of openssl and erlang versions -- perhaps including the version of openssl that erlang packages are compiled against, not just those libraries present on the system.  As previously noted in this thread, Sensu 0.27 and later have an upgraded OpenSSL version. We have no plans to roll this back, as OpenSSL 1.0.1 is end-of-life and we do not have the resources to maintain backports for any subsequent fixes.
The following example environments works for me, both using shared password authentication and EXTERNAL auth mechanism with rabbitmq_auth_mechanism_ssl plugin. I've also successfully used certificate chains generated by both the sensu_ssl_tool CA and a Puppet Enterprise CA. In both environments I am using the erlang and rabbitmq-server packages published by the RabbitMQ maintainers.
CentOS 7.3 environment:
# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
# rpm -qa | grep -E 'sensu|rabbitmq|erlang|openssl'
sensu-0.29.0-11.el7.x86_64
openssl-libs-1.0.1e-60.el7_3.1.x86_64
openssl-1.0.1e-60.el7_3.1.x86_64
erlang-19.3.6-1.el7.centos.x86_64
rabbitmq-server-3.6.10-1.el7.noarch

# cat /etc/rabbitmq/rabbitmq.config
[
  {rabbit, [
    {ssl_listeners, [5671]},
    {ssl_options, [
       {cacertfile,"/etc/rabbitmq/ssl/cacert.pem"},
       {certfile,"/etc/rabbitmq/ssl/cert.pem"},
       {keyfile,"/etc/rabbitmq/ssl/key.pem"},
       {verify,verify_peer},
       {fail_if_no_peer_cert,true},
       {versions, ['tlsv1.2']},
       {ciphers,  [{rsa,aes_256_cbc,sha256}]}
    ]}
  ]}
].

# rabbitmqctl eval 'ssl:cipher_suites(openssl).'
["ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384",
 "ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384",
 "ECDH-ECDSA-AES256-GCM-SHA384","ECDH-RSA-AES256-GCM-SHA384",
 "ECDH-ECDSA-AES256-SHA384","ECDH-RSA-AES256-SHA384",
 "DHE-RSA-AES256-GCM-SHA384","DHE-DSS-AES256-GCM-SHA384",
 "DHE-RSA-AES256-SHA256","DHE-DSS-AES256-SHA256","AES256-GCM-SHA384",
 "AES256-SHA256","ECDHE-ECDSA-AES128-GCM-SHA256",
 "ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES128-SHA256",
 "ECDHE-RSA-AES128-SHA256","ECDH-ECDSA-AES128-GCM-SHA256",
 "ECDH-RSA-AES128-GCM-SHA256","ECDH-ECDSA-AES128-SHA256",
 "ECDH-RSA-AES128-SHA256","DHE-RSA-AES128-GCM-SHA256",
 "DHE-DSS-AES128-GCM-SHA256","DHE-RSA-AES128-SHA256","DHE-DSS-AES128-SHA256",
 "AES128-GCM-SHA256","AES128-SHA256","ECDHE-ECDSA-AES256-SHA",
 "ECDHE-RSA-AES256-SHA","DHE-RSA-AES256-SHA","DHE-DSS-AES256-SHA",
 "ECDH-ECDSA-AES256-SHA","ECDH-RSA-AES256-SHA","AES256-SHA",
 "ECDHE-ECDSA-AES128-SHA","ECDHE-RSA-AES128-SHA","DHE-RSA-AES128-SHA",
 "DHE-DSS-AES128-SHA","ECDH-ECDSA-AES128-SHA","ECDH-RSA-AES128-SHA",
 "AES128-SHA","ECDHE-ECDSA-DES-CBC3-SHA","ECDHE-RSA-DES-CBC3-SHA",
 "EDH-RSA-DES-CBC3-SHA","EDH-DSS-DES-CBC3-SHA","ECDH-ECDSA-DES-CBC3-SHA",
 "ECDH-RSA-DES-CBC3-SHA","DES-CBC3-SHA"]

Centos 6.9 Environment:
# cat /etc/redhat-release
CentOS release 6.9 (Final)
[root@ip-10-0-0-64 ~]# rpm -qa | grep -E 'sensu|rabbitmq|erlang|openssl'
erlang-19.3.6-1.el6.x86_64
sensu-0.29.0-11.el6.x86_64
openssl-1.0.1e-57.el6.x86_64
rabbitmq-server-3.6.10-1.el6.noarch

# cat /etc/rabbitmq/rabbitmq.config
[
  {rabbit, [
    {ssl_listeners, [5671]},
    {ssl_options, [
       {cacertfile,"/etc/rabbitmq/ssl/cacert.pem"},
       {certfile,"/etc/rabbitmq/ssl/cert.pem"},
       {keyfile,"/etc/rabbitmq/ssl/key.pem"},
       {verify,verify_peer},
       {fail_if_no_peer_cert,true},
       {versions, ['tlsv1.2']},
       {ciphers,  [{rsa,aes_256_cbc,sha256}]}
    ]}
  ]}
].

# rabbitmqctl eval 'ssl:cipher_suites(openssl).'
["ECDHE-ECDSA-AES256-GCM-SHA384","ECDHE-RSA-AES256-GCM-SHA384",
 "ECDHE-ECDSA-AES256-SHA384","ECDHE-RSA-AES256-SHA384",
 "ECDH-ECDSA-AES256-GCM-SHA384","ECDH-RSA-AES256-GCM-SHA384",
 "ECDH-ECDSA-AES256-SHA384","ECDH-RSA-AES256-SHA384",
 "DHE-RSA-AES256-GCM-SHA384","DHE-DSS-AES256-GCM-SHA384",
 "DHE-RSA-AES256-SHA256","DHE-DSS-AES256-SHA256","AES256-GCM-SHA384",
 "AES256-SHA256","ECDHE-ECDSA-AES128-GCM-SHA256",
 "ECDHE-RSA-AES128-GCM-SHA256","ECDHE-ECDSA-AES128-SHA256",
 "ECDHE-RSA-AES128-SHA256","ECDH-ECDSA-AES128-GCM-SHA256",
 "ECDH-RSA-AES128-GCM-SHA256","ECDH-ECDSA-AES128-SHA256",
 "ECDH-RSA-AES128-SHA256","DHE-RSA-AES128-GCM-SHA256",
 "DHE-DSS-AES128-GCM-SHA256","DHE-RSA-AES128-SHA256","DHE-DSS-AES128-SHA256",
 "AES128-GCM-SHA256","AES128-SHA256","ECDHE-ECDSA-AES256-SHA",
 "ECDHE-RSA-AES256-SHA","DHE-RSA-AES256-SHA","DHE-DSS-AES256-SHA",
 "ECDH-ECDSA-AES256-SHA","ECDH-RSA-AES256-SHA","AES256-SHA",
 "ECDHE-ECDSA-AES128-SHA","ECDHE-RSA-AES128-SHA","DHE-RSA-AES128-SHA",
 "DHE-DSS-AES128-SHA","ECDH-ECDSA-AES128-SHA","ECDH-RSA-AES128-SHA",
 "AES128-SHA","ECDHE-ECDSA-DES-CBC3-SHA","ECDHE-RSA-DES-CBC3-SHA",
 "EDH-RSA-DES-CBC3-SHA","EDH-DSS-DES-CBC3-SHA","ECDH-ECDSA-DES-CBC3-SHA",
 "ECDH-RSA-DES-CBC3-SHA","DES-CBC3-SHA"]

Note that both environments are reporting an identical set of cipher suites, and the cipher suites configuration reported by @sureshsubramaniam is a subset of those reported in the examples above.
I have also tried adding the following to rabbitmq ssl_options, and see no change:
{secure_renegotiate,true},
{reuse_sessions,true},
{honor_cipher_order,true}

In both environments I am using the erlang and rabbitmq-server packages published by the RabbitMQ maintainers. maybe that's the issue - I'm using CentOS 7.3 setup but I'm installing rabbitmq and erlang from epel repository (especially since RabbitMQ doesn't host own repo), hence my versions are:
# rpm -qa | grep -E 'sensu|rabbitmq|erlang|openssl' | sort
erlang-asn1-R16B-03.18.el7.x86_64
erlang-compiler-R16B-03.18.el7.x86_64
erlang-crypto-R16B-03.18.el7.x86_64
erlang-erts-R16B-03.18.el7.x86_64
erlang-hipe-R16B-03.18.el7.x86_64
erlang-inets-R16B-03.18.el7.x86_64
erlang-kernel-R16B-03.18.el7.x86_64
erlang-mnesia-R16B-03.18.el7.x86_64
erlang-os_mon-R16B-03.18.el7.x86_64
erlang-otp_mibs-R16B-03.18.el7.x86_64
erlang-public_key-R16B-03.18.el7.x86_64
erlang-runtime_tools-R16B-03.18.el7.x86_64
erlang-sasl-R16B-03.18.el7.x86_64
erlang-sd_notify-0.1-1.el7.x86_64
erlang-snmp-R16B-03.18.el7.x86_64
erlang-ssl-R16B-03.18.el7.x86_64
erlang-stdlib-R16B-03.18.el7.x86_64
erlang-syntax_tools-R16B-03.18.el7.x86_64
erlang-tools-R16B-03.18.el7.x86_64
erlang-xmerl-R16B-03.18.el7.x86_64
openssl-1.0.1e-60.el7_3.1.x86_64
openssl-libs-1.0.1e-60.el7_3.1.x86_64
rabbitmq-server-3.3.5-34.el7.noarch
sensu-0.29.0-11.el7.x86_64

# rabbitmqctl eval 'ssl:cipher_suites(openssl).'
["DHE-RSA-AES256-SHA256","DHE-DSS-AES256-SHA256","AES256-SHA256",
 "DHE-RSA-AES128-SHA256","DHE-DSS-AES128-SHA256","AES128-SHA256",
 "DHE-RSA-AES256-SHA","DHE-DSS-AES256-SHA","AES256-SHA",
 "EDH-RSA-DES-CBC3-SHA","EDH-DSS-DES-CBC3-SHA","DES-CBC3-SHA",
 "DHE-RSA-AES128-SHA","DHE-DSS-AES128-SHA","AES128-SHA","RC4-SHA","RC4-MD5",
 "EDH-RSA-DES-CBC-SHA","DES-CBC-SHA"]
...done.

@b3niup Agreed, the Erlang and RabbitMQ packages from EPEL are likely getting too old.
Per https://www.rabbitmq.com/which-erlang.html Erlang 17.0 is the minimum for reliable TLS and 19.2+ is recommended.
RabbitMQ maintainers provide their zero-dependency Erlang RPM via yum repo on PackageCloud e.g. https://packagecloud.io/rabbitmq/erlang/install

@cwjohnston yep, with packages from mentioned repository sensu 0.29 works fine.
# rpm -qa | grep -E 'sensu|rabbitmq|erlang|openssl' | sort
erlang-19.3.6-1.el7.centos.x86_64
openssl-1.0.1e-60.el7_3.1.x86_64
openssl-libs-1.0.1e-60.el7_3.1.x86_64
rabbitmq-server-3.6.10-1.el7.noarch
sensu-0.29.0-11.el7.x86_64```

Good days guys. I also have the same problem issued here. And for me recommendation from @cwjohnston was health. After setup from packagecloud my sensu is work fine with same keys as before upgrade. It seems security incompatibility issue in erlang.
I had issue on Centos 7.2.

We faced the same issue when upgrading from sensu 0.26 to sensu 1.0.0 on Ubuntu 14. After re-installing erlang to latest version (20) as suggested by @cwjohnston, sensu is able to authenticate with rabbitmq again. Before erlang version was 16x. We followed the instruction here for installing erlang thru distro package: https://www.erlang-solutions.com/resources/download.html
Shouldn't be too hard whether doing it manually or using some config management tools like Chef, Ansible...

Same issue here. Default CentOS 7 packages (Erlang 16x).
After upgrade to version 20 as instructed at https://www.erlang-solutions.com/resources/download.html everything works. Also get latest rabbitmq from https://www.rabbitmq.com/download.html

It seems there are valid steps to fix and move past this issue. This issue was overloaded with various SSL/TLS issues. I am going to close this issue. If the steps in the issue do not resolve your issues, please feel free to create a new issue for your unique TLS issue.


Spawn planets behavior

Spawn planets continuously as the player/camera move. Try not to spawn things directly on the line of the player when it's spawn-time. Don't spawn while ship is under the effect of a gravity well.

Ignored the "don't spawn while ship is under the effect of a gravity well" clause, as I deemed it unnecessary.


handle chunking

yt_xarray currently loads in data on a single yt grid. For uniform grids, it should be straightforward to chunk it as well as align the yt grids with any existing xarray chunks (e.g., when xarray is using a dask backend). Stretched grids however, might need some upstream changes in yt.

#30 addresses part of this: chunking for uniform grids. It works with dask arrays!
To close this issue for the v0.2.0 release, just need to add the option to auto-align the dask and yt chunks.
Future releases could add the functionality for stretched grids, but some work upstream in yt may be necessary for that.


pach sound different since update

Hello, thanks a lot for this module and for the graphic update
I've create a patch with version 1 and i 'm a bit lost since update, names have changed and my patch sound different.
can you help ?
here the patch
and happily, I've an other machine where i don't upgrade so here a screenshot of the original patch:

OK, let me have a look and I'll see what might be different
cheers,
john

Thanks !


Get rid of yield pattern in test fixtures

When I first saw this I thought it looked weird but not harmful.
But after understanding a bit more about the user deletion issue from https://github.com/ansible/django-ansible-base/pull/160, I now believe it is likely papering over a real issue with cascade deletions. Maybe it made the tests pass at some point, but it's possible it made a test pass that should have been failing.
Also, I need to write tests that do user.delete() and with the current fixtures that gives an error on teardown because the user is already deleted.

Thanks.


Unicode surrogate pairs corrupted by Clean during ingest (AIDH-1865)

During of control characters Clean.unicodeDefault, Unicode supplementary surrogate pairs become corrupted.
This is because the Java regex (?U)\\p{Print} is only Plane 0-aware. Therefore, supplementary surrogate pair sequences in higher planes are not supported. For example, 😀(U+1F600 / UTF-8 F09F 9880 / UTF-16 D83D DE00) is corrupted to ? (U+003F).

Corruption can be avoided by:

Removing higher-plane characters from the output.
Including higher-plane characters in the output.

Option 1 is the safest default (support Plane 0 only):

Supplementary high-plane support is problematic because many systems are not surrogate-aware.
Java does not define a safe printable set for supplementary surrogates.

Option 2 is an advanced option that needs careful E2E planning and handling.

See also https://github.com/CommBank/OmniaDesignForum/blob/289dc0331087ac7ee90f6957a0d2c6107c9106fe/features/string-features.md

v2.28.1 AIDH-1865 (#535) implements Option 1 as the default and Option 2 as an advanced capability.


Upgrade django

This PR is still WIP (eg failing tests - last commit). I am opening it so that the review can proceed in parallel. @johngian r? @glogiotatidis can you please have a look too if you have some free time?

This a list with things that we still need to do. Feel free to add items as you discover issues.
[ ] Update tests.
[ ] Update deployment script
[ ] Check mapbox maps.

You are removing happyforms but you are not changing the codebase to strip whitespace. That means that we are also going to accept as valid trailing whitespaces in form input fields.

Docker image build was failing. Here is a patch that fixes it:
https://github.com/johngian/remo/commit/42160418de6cbf7df57db19366b0849bcc1377c8

Please squash commits. There some interim commits that have non-used stuff (eg. whitenoise)
https://github.com/mozilla/remo/pull/1127/commits/a0c42b733967a62d7d2e34f5f21fcde7326efe7e#diff-d7967439d6e03110713bf2361eec67e4R64

It looks like there is no code related issue with mapbox. Unfortunately the example mapbox api key can not be used for dev purposes anymore. Tried with the one from prod and maps show up as expected.

Don't forget to remove vendor-* from the servers when you push this code.

I guess you mean to update this to pip8 but you already had the peep changes ready, so that's cool for now but keep in mind that peep is practically dead.

I am getting this warning when running runserver:
?: (1_8.W001) The standalone TEMPLATE_* settings were deprecated in Django 1.8 and the TEMPLATES dictionary takes precedence. You must put the values of the following settings into your default TEMPLATES dict: TEMPLATE_DEBUG.

This should be fixed in: local.py-docker-dist, localtravis.py

Please fix the celery configuration in local.py-docker-dist. You need to add this line in order celery to connect to the broker:
BROKER_URL = 'amqp://guest:guest@broker:5672//'

Thanks @glogiotatidis for the review. I am closing this in favor of #1129.


[api] rspec refactoring - spec/requests/api/vms_spec.rb

Added url helper methods for generating URL's
Added an api_basic_authorize helper method set both role and basic_authorize in one shot.
New helper method to fetch values dynamically from shared_examples.
Adding shared examples via spec/requests/shared_examples/api.rb
Converted spec/requests/api/vms_spec.rb to using shared examples

https://trello.com/c/p76x7lcu

using shared examples, examples are much easier to read, 1030 lines in vms_spec down to 800. going to let() methods shaved only a second or so run-time for that file down to 27.5 secs.

@Fryguy we're green, please review.

Found the following to be of relevance here: http://www.bignerdranch.com/blog/using-rspec-shared-contexts-ensure-api-consistency/
Going the route of including examples better long term for the API.

@abellotti ping me. are you all set?

yep, this PR is good to go.  I have many others coming that require this one as foundation.  Thanks.

future reference, the context should hold the "with ..." part and the it should hold the text before that.


DF-261:add django debug toolbar

Added django debug toolbar to display various debug information in debug mode

@TNA-Allan You should just need to rerun poetry update to take into account dependency changes from the other PR :)

Closing as when rebasing issues got in code not belonging to this branch.