text:
L1VH CNI Code changes

Reason for Change:

This implementation is to support swiftv2 L1VH CNI feature:
CNI receives goal state from CNS and create linux/windows pod on Windows VM/Node in swiftv2 L1VH path;
The container pod is using secondary interface with its mac address and NIC type(Delegated NIC or Accelnet) to be created;
We support up to 8 pods to be created by using different interfaces along with different hnsNetwork; CNI supports hnsNetwork creation(when pod is added to the VM) and deletion(when pod is removed from VM) to prevent leakage;
Issue Fixed:

Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] relevant PR labels added

Notes:

/azp run Azure Container Networking PR

/azp run Azure Container Networking PR

we don't use integration branches, why is this not targeting master?

We can not merge this code to master until github.com/Microsoft/hcsshim v0.12.0-rc.2 is out of release candidate status. We want to be able to still work, test, and retain code reviews for this work.


text:
ALTER DB needs to be run on master

Clarifying that ALTER DATABASE command needs to be run on master database.

Hi @sahaj08, I'm your friendly neighborhood Azure Pull Request Bot (You can call me AZPRBOT). Thanks for your contribution!

It looks like you're working at Microsoft (sahajs). If you're full-time, we DON'T require a contribution license agreement.

If you are a vendor, or work for Microsoft Open Technologies, DO please sign the electronic contribution license agreement. It will take 2 minutes and there's no faxing! https://cla.azure.com.

TTYL, AZPRBOT;

@barbkess

source: gharchive/pull-request

repo: Azure/azure-content

license_type: permissive

license_source: github-api


text:
Updating freshness

Updating freshness

@mimig1

Please address/resolve verbatim bug 5604335.The new feedback (from 9/8) is: "not enough details provided", but I need to track that you've seen it and it's up to you to decide what to do with it. http://sqlbuvsts01:8080/Main/DocumentDB/_workitems#_a=edit&id=5604335&triage=true

Resolved. Not enough details provided to action anything.

#sign-off

@rmca14


text:
Azure CosmosDB Unexpected Pagination Behaviour

We are using CosmosDb C# SDK
We tried both: "Microsoft.Azure.Cosmos 3.4.1", "Microsoft.Azure.DocumentDB.Core 2.9.1 and 2.4.2"
We are getting invalid results and the main problems is the ResponseContinuation

[{"token":null,"range":{"min":"05C1DFFFFFFFFC","max":"FF"}}]

This started showing in one of our smaller service with only 14 documents.
In all queryes we use the folowing headers:

"x-ms-documentdb-query-enablecrosspartition" = true
"x-ms-max-item-count" = 100

Query 1:
The query is the folowing SELECT * FROM c.
We get the folowing response:

7 items
ResponseContinuation [{"token":null,"range":{"min":"05C1DFFFFFFFFC","max":"FF"}}]

Then we use the continuation token to get the other 7 items.
Query 2:
If we modify the query to SELECT * FROM c ORDER BY c.property ASC, the order gets messed up! (responses are simplified)

we get the folowing result ["A", "B", "C", "D", "F"]
and the second query ["C", "D", "G"]

Query 3:
if we want to find only one item SELECT TOP 1 * FROM c WHERE c.name = @name, and the item is in the "second query result"

nothing and RequestContionuation {"top":1,"sourceToken":"[{\"token\":null,\"range\":{\"min\":\"05C1DFFFFFFFFC\",\"max\":\"FF\"}}]"}

This is all a really unexpected behaviour.
Why does ORDER BY, TOP even exist if we can't even use it properly..
We can't afford to list all data from cosmos to our server and then do ordering, expecialy on bigger containers.
Stackoverflow link: https://stackoverflow.com/questions/58876612/azure-cosmosdb-unexpected-pagination-behaviour

Any progress on this?

@bchong95 can you take a look at query 2 and 3?
For Query 1 it looks like you hit a common issue which is people misunderstand the max item count. The max item count is a maximum. There is no minimum. Empty pages are possible. For your scenario it looks like you have at least 2 partitions in Cosmos DB. The SDK went to the first partition and got 7 results and the other 7 results are on the second partition.

Any progress on this?

You are not allowed to mix and match continuation tokens with different queries. Please provide a console application code that reproduces the issue if there is no query or continuation token modification across continuations.

@Jubast you probably figured it out by now, but commenting in case someone else comes across this issue. Regarding query 3.
We have solved this by checking  documentQuery.HasMoreResults
If there are more results, we use the continuation token, although doesn't seem to hold any value, and we send the request again. It will then retrieve the matches from the second partition.

source: gharchive/issue

license: MIT