META: API Discussion

We're going to be using Popper.js for our app, but since we're on a legacy version of Ember at the moment we can't use this addon (and probably won't be able to use it until that Glimmer render-in-place helper arrives). However, we would like to match the external API of this component with our internal implementation so that when that time comes, we can swap it out and start contributing back.
The current API is pretty simple and not really easy to use with pre-Ember 2.4(?) apps - basically any without the hash helper, because options is difficult to specify declaratively otherwise. We can't even really polyfill the hash helper because in 1.8/1.11, single word helpers are a bit of a pain 😕
I don't think it would be too unreasonable to follow ember-tethers pattern of adding the top level options as properties of the component, but requiring them to be passed in as objects below that. So a configuration currently like so:
{{#ember-popper options=(hash placement="top" modifiers=(hash offset=(hash offset="10px")))}}

Would become:
{{#ember-popper placement="top" modifiers=(hash offset=(hash offset="10px"))}}

There are only 3 top level options for Popper, so this would be a pretty minimal API to maintain. If Popper decides to change its public API dramatically, we could follow suite with a major/minor version bump. I also think this would be a lot better for developer ergonomics - the bottom example is much easier to read and understand.

I also think we should try to preserve class instead of popperClass as an external API, can do some work to make that happen cleanly

Re flattening: I'm totally on board with this. Will happily accept PRs, or get around to it myself eventually.
Re preserving class: I'd love that. Went asking about this in #ember-cli and was recommended against it without employing a lot of trickery, but if you know a way to do it cleanly, that would be awesome.

Resolved in #11. Will make a separate issue for using class over popperClass.


Broken API versioning wiki link in design guidelines

Problem description
In chapter5 of design guidelines, there is a reference to API versioning wiki link. This link is broken.
Expected behavior
Fix broken link.
Alternative solution
Do we want to refer to a document in release management repo or should we keep referring to the wiki?
Additional context

In my view +1 to keep referring to the wiki (I guess this has been a consequence of wiki migration) and i think wiki audience is higher

@wrathwolf
Is it possible to configure (temporary) redirection from specific URL:
https://wiki.camaraproject.org/x/a4BaAQ
to:
https://lf-camaraproject.atlassian.net/wiki/x/3yLe


Use Azure.Test.HttpRecorder to record and mock LUIS service responses

We found the Azure.Test.HttpRecorder used in the LUIS Runtime.Tests to conditionally hit the external service and store the response in file system and then use this responses to mock the service for unit tests.
Currently, this NuGet is incompatible with NETCOREAPP2.0 but they seem to be working on getting a new version with compatibility.
The purpose of this issue is to check for the compatibility status with NETCOREAPP2.0 and update those unit tests accessing external services to use the HttpRecorder component.

We can run tests on .NET 4.61, which should be enough for GA. Keep track of this items and pull in the updates as soon as they are ready.

On hold along with #1338 waiting for dependencies to be updated.

This remains blocked, as the underlying dependencies are not yet .Net Core. The MockLuisRecognizer as defined by Gabo as part of the testing infrastructure would also address this.
Punting to 4.5.

The latest version supports both:

.NETCoreApp 2.0
Newtonsoft.Json (>= 10.0.3)

I believe we should be able to take this update in the 4.6 cycle.

Closing.


Untag manifests for DELETE API calls by tag

This is a proposed implementation for #1954 that would help close #1811  #1859
Documentation will have to be updated as well if this is an accepted API change.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "untag" git@github.com:sergeyfd/distribution.git somewhere
$ cd somewhere
$ git rebase -i HEAD~2
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Ammending updates the existing PR. You DO NOT need to open a new one.

So does this approach make sense? In my opinion an ability to delete tags would be a good improvement for the current API.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "untag" git@github.com:sergeyfd/distribution.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354171120
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "untag" git@github.com:sergeyfd/distribution.git somewhere
$ cd somewhere
$ git rebase -i HEAD~842354592672
editor opens
change each 'pick' to 'edit'
save the file and quit
$ git commit --amend -s --no-edit
$ git rebase --continue # and repeat the amend for each commit
$ git push -f

Amending updates the existing PR. You DO NOT need to open a new one.

Added tests and a proper (?) support for proxy mode.

@dmcgowan Could you take a look?

@sergeyfd sorry I have no responded. I have the same feeling that I have expressed before, without the ability to lock this operation could be racy. Your deletion logic is correct though. As for the race, there are 3 approaches we could take....

Don't worry about it, it is very unlikely a specific manifest digest is tagged within that deletion windows.
Allow deletion calls to occur while the registry is in read only mode. This deletion will not have a negative on any running garbage collection.
Wait until we have transactional metadata, still no timeframe on getting this merged in though.

I think option 2 is interesting but don't think that is a simple change and may be a breach of contract. Users are already doing option 1 so merging this would probably just make that approach official.
Ping @stevvooe @aaronlehmann do we want this feature now or should we stick with our current solutions and wait until option 3 to merge something in.

Oh, how we soon forget.
The reason we don't do this is documented in the API docs and the github issues that originally added deletion support. Not only is this operation racy, but it is destructive.
The effect can be accomplished by calling HEAD on the tag and then using that digest to delete the manifest.
If someone wants to carry the idea of the first-class tags and actually fix this, I would be in support of that. Also, if someone wants to actually address the issues that I've identified with deleting tags, rather than just assuming we just didn't implement it because we are lazy, that would also be great.

https://github.com/docker/distribution/issues/1566#issuecomment-205484205 sums up the problem and work around in the best manner possible.

First-class tags: https://github.com/docker/distribution/pull/173
Similar PR: https://github.com/docker/distribution/pull/933
Another attempt: https://github.com/docker/distribution/pull/1137

For this to go in, you really need to solve the technical issues. The problems with many solutions is they don't account for the schema1 case, which includes the tag in the manifest. The other problem with existing solutions is that it doesn't account for the race conditions.
However, I would ask that folks stop assuming this is some sort of glaring oversight. This is an unfortunate side-effect of the data model. There are ways to address it, but it takes some consideration to address appropriately.

@stevvooe Unfortunately doing HEAD and then deleting by digest doesn't provide same functionality and can be really dangerous in it turn, see here: #1811 Inability to get rid of a tag is really annoying.

@dmcgowan You have to educate me here. Why deleting by digest with deleting all accompanying tags is safe and re-using the same code for deleting manifest after making sure that it has only one tag pointing to it isn't. Why same race conditions do not apply to the delete by digest? However @stevvooe is right that this approach doesn't support schema 1 manifests.
I wouldn't pursue option 2. The need to put a registry into R/O mode to run GC is already bad enough and adding more features depending on that would make it even worse.
Thanks for the looking into this PR anyway. And please don't think that your users do not appreciate the work you guys do.

@sergeyfd Ok, so that sounds like a bug. If a tag file references a manifest that has been deleted, the API should return 404. Is it not doing that?
The main reason why digests are considered safe and tags are not is simply uniqueness. When one deletes by digest, there is some guarantee that digest only has a single target. With a tag, it could have been updated in a concurrent request and the deletion would be invalid or random depending on the backend.
Some of the underlying concepts are described in https://github.com/docker/docker.github.io/blob/master/registry/architecture.md#eventual-consistency.

@stevvooe Sorry but you are not following. The problem with doing HEAD and then deleting by acquired digest is that it deletes manifest and all other tags that might exists in the registry and point to the same digest. This is definitely unexpected, and not well documented, side effect of deletion by digest.
BTW, the proposed PR deletes manifest only if it's the only existing tag for that manifest, otherwise it deletes only a tagging link by calling Untag()
Thanks for that link, I'll ready through that document.

The problem with doing HEAD and then deleting by acquired digest is that it deletes manifest and all other tags that might exists in the registry and point to the same digest.

How is this unexpected? What should the tag point to after its target has been deleted?

@stevvooe, In schema1 retrieving a digest by tag and using that digest in Delete operation would lead to deletion of just that tag. In schema 2 this same operation leads into deletion of a manifest and ALL tags pointing to that manifest. So if we tag same image as /repo/cool_image:sergeyfd and /repo/cool_image:stevvoe deleting the first one by me would delete the second one as well. This could be unexpected to you. So the problem that I am trying to state is that in schema 2 there's no easy way to get rid of a tag. One has to upload a dummy image, point a tag that needs to be deleted to that dummy image, and then delete that image. Quite cumbersome logic for something that looks simple.
Unfortunately you are right. Since digests are basically immutable and tags aren't implementing support fort Untag API call in a way that I proposed does create race conditions when tag can be switched to some other image while Delete operation is in action. And I do not know how to go around this.

So if we tag same image as /repo/cool_image:sergeyfd and /repo/cool_image:stevvoe deleting the first one by me would delete the second one as well. This could be unexpected to you.

I don't find this unexpected. That is why I am confused. Let's say we each create a soft link to a common file on a filesystem. If that file gets deleted, do you still expect those links to work? No.
I took a closer look at the current state of the code. It looks like Untag is a shallow operation on a single path (manifestTagPathSpec for reference). For the most part, this should make the delete idempotent. At this point, I think we can ignore the issues with schema1, as they are grouped under this directory anyways.
Note that an implementation may not be able to delete an unreferenced manifest with this approach.
For this to go through, the following must happen:

Update the specification accordingly.
Remove querying to TagStore.All.
Just issue an Untag for the target tag.

@stevvoe I think the issue here is that if I have two soft links to the
same file, I expect to be able to delete a soft link without eliminating
the underlying file.  If however soft links are my primary reference, and
there's NO remaining soft links, then I expect the file to be deleted.
On Tue, Jan 10, 2017 at 11:57 AM, Stephen Day<EMAIL_ADDRESS>wrote:

So if we tag same image as /repo/cool_image:sergeyfd and
/repo/cool_image:stevvoe deleting the first one by me would delete the
second one as well. This could be unexpected to you.
I don't find this unexpected. That is why I am confused. Let's say we each
create a soft link to a common file on a filesystem. If that file gets
deleted, do you still expect those links to work? No.
I took a closer look at the current state of the code. It looks like Untag
is a shallow operation on a single path (manifestTagPathSpec for
reference). For the most part, this should make the delete idempotent. At
this point, I think we can ignore the issues with schema1, as they are
grouped under this directory anyways.
Note that an implementation may not be able to delete an unreferenced
manifest with this approach.
For this to go through, the following must happen:

Update the specification accordingly.
Remove querying to TagStore.All.
Just issue an Untag for the target tag.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/docker/distribution/pull/1956#issuecomment-271680824,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKIcBi4j_bXgxxWFpW2tPhuRl-dIQyhFks5rQ-KvgaJpZM4J6I-O
.

--
Mark Galpin | Senior Solutions Architect | JFrog
270 E Caribbean Drive, Sunnyvale, CA 94089
U.S Toll Free: +1.888.494.2855 <%2B1.888.704.0670> | Tel: +1.408.329.1540
https://goo.gl/gnqeun
This message may contain confidential and/or proprietary information, and
is intended only for the person/entity to whom it was originally
addressed. The content of this message may contain private views and
opinions, which do not constitute a formal disclosure or commitment unless
specifically stated.

@markgalpin We need to separate what would be convenient from what is possible in the data model. The issue is that there is no locking allowing for the target to be collected when there are no more incoming links.

If however soft links are my primary reference, and
there's NO remaining soft links, then I expect the file to be deleted.

The problem is that this assumption is not true. We cannot be sure that the there are no remaining soft links (just like on a file system) so deleting the target file when there are no soft links will result in a race condition and data corruption.

You are right so to some extent. If I delete a target than it'll make your symlink broken but it won't delete it.
I am Ok with your approach but would suggest that we refuse deleting the last tag to avoid creation of unreferenced manifests. Such images will be really hard to deal with cause I don't see how one would get a digest for a such image. So if TagStore.All() returns a  list with just one element than the system can respond with 405 or so.

Such images will be really hard to deal with cause I don't see how one would get a digest for a such image. So if TagStore.All() returns a list with just one element than the system can respond with 405 or so.

And this is what is racy. You can't be sure that there is still one element by the time the delete is issued. If you just allow deleting the items, then this is not a problem.
I don't see any reason this is a problem: if you need list access to repo manifests, then we should probably add it.

Agree that with a list access to repo manifests it's not a problem, otherwise it becomes kind of a hidden image not seen by any client that doesn't have digest for that image retrieved previously.
So having GET /v2//manifests/list which would return a list of known digests makes total sense to me.

So having GET /v2//manifests/list which would return a list of known digests makes total sense to me.

Let's save that for another PR.

Shouldn't manifests without tags get deleted by gc? It's the most natural thing I'd expect to happen.

Shouldn't manifests without tags get deleted by gc? It's the most natural thing I'd expect to happen.

Why is this "the most natural thing"? What if the digest is referenced externally?

Gc deletes unreferenced objects, and this manifest is unreferenced.
If the digest is referenced externally, then people simply shouldn't delete the last tag.

@LEW21 I think you may be oversimplifying the problem or misunderstanding the guarantees provided by digests. The whole point of a digest is that one can use it to ensure that when someone updates a tag, they will continue using the exact version with the digest. If you just delete these, you completely break this functionality.
Before commenting further, I'd recommend you read information on deletes in the road map. There are lots of considerations that need to be made when making changes in this area.

@sergeyfd This looks like a good start. Could you modify the specification to include the changes requested here?

@stevvooe I need to rebase it cause image.go was renamed into manifests.go and I have a bit of problems with that rebase but hope to figure it out over weekend.
Do I need to update both api.md and api.md.tpl? I am a bit confused there.

@sergeyfd You'll have to add a route descriptor in registry/api/v2 and add a section in the template describing the delete methodology. If you can't find the right section, ping me and I'll hunt it down.
Sorry about the move. I had meant to do that a long time ago.

@stevvooe I rebased it but did not update specs. I think that it all has to be done differently. With this implementation it should not be attached to DELETE v2//manifests/ because it actually never deletes a manifest. So the correct route should be DELETE v2//tags/ and this code should actually go into tags.go instead of manifests.go. Do you agree?

Current coverage is 51.20% (diff: 81.81%)

Merging #1956 into master will decrease coverage by 9.98%

@@             master      #1956   diff @@
==========================================
  Files           125        125
  Lines         11433      11454     +21
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
- Hits           6996       5865   -1131
- Misses         3550       4843   +1293
+ Partials        887        746    -141

Powered by Codecov. Last update 7cb0c15...3f450ad

I agree, but there is a design problem that we'll have to tackle.
The route overview is here: https://github.com/docker/distribution/blob/master/docs/spec/api.md#detail.
I do agree that this should only go on tags. Unfortunately, the route for listing tags is /v2/<name>/tags/list, which prevents us from adding the route /v2/<name>/tags/<reference>. (There is history behind this: list helps "affix" the route, ensuring that <name> can be parsed correctly).
A few possibilities here:

Go forward with /v2/<name>/tags/<reference> and disallow list as a tag.
Go forward with /v2/<name>/tags/<reference>, add _list and disallow list as a tag, slowly deprecating usage of /v2/<name>/tags/list for /v2/<name>/tags/_list. Add a redirect, as well.
Allow both routes to exist but do different things for GET and DELETE.
Continue supporting /v2/<name>/tags/list but allow the addition of an Accept header to disambiguate, which is only required for the value list.
Just reserve the tag list and disallow it as a supported tag in the registry going forward.

If you have any other ideas, I'd be interested in hearing them.

I think that the best way would be moving tag list functionality into /v2/<name>/tags/_list. In this case we won't need to make any changes in Docker Engine to disallow any tags. This will also allow us to be consistent withe the future /v2/<name>/manifests/_list route. So this is what should be done from my point of view:

Move /v2/<name>/tags/list to /v2/<name>/tags/_list with a redirect for backward compatibility. That redirect shall be removed later on.
Add new route /v2/<name>/tags/<reference> for a DELETE operation.  This route will support only tag references.
Add new route  /v2/<name>/manifests/_list for GET operation to retrieve a list of digests in a given repo. I am not sure if this route is a best choice, may be adding  /v2/<name>/digests/_list would be a better option.

This work shall be split into several PRs.

In most REST APIs the list would be placed at /v2//tags/, as in https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_Web_services

@LEW21 If you analyze the API appropriately, you'll see why this creates ambiguity. The main issue is that <name> can be an unrestricted number of path components. There is a massive set of test cases showing this in the code base. Having these "affixed tuples" (ie manifest/<reference>, tags/list) avoids this.
@sergeyfd The plan looks good except for this:

That redirect shall be removed later on.

This redirect can never be removed without incrementing the API version. One will never be able to access the tag named list but I don't think proposal calls for that.

I create a new PR #2169 which covers first two steps of the plan.

Closed in favor of #2169


Synchronous CloudBlockBlob UploadFrom... ASP.NET Regression 9.3.3 → 9.4.0+ for files ≥ 256MB

Describe the bug
There is a defect or undocumented regression when migrating from 9.3.3 (NuGet package Microsoft.WindowsAzure.Storage) to 9.4.0+ (NuGet package Microsoft.Azure.Storage.Blob and Microsoft.Azure.Storage.Common).
This involves all of the synchronous upload endpoints as below:

UploadFromStream
UploadFromByteArray
UploadFromFile
UploadFromText

Previously this worked as expected in both console applications and ASP.NET Web API. However, since 9.4.0, calls block endlessly.
This can be circumvented by wrapping in the following code, but should either be documented or fixed.
Task.Run(() => blockBlob.UploadFrom....()).Wait();

Exception or Stack Trace
No stack trace as error not produced, just blocks endlessly.
To Reproduce
Checkout the GitHub repository here and follow the steps to reproduce. It is using .NET 4.6.2 as this is where it was originally discovered.
https://github.com/deenairn/azureblobupload
Code Snippet
Code snippet from above repository. Check repo for more details and contact me if cannot reproduce or compile repo.
            var storageAccount = CloudStorageAccount.Parse(storageAccountName);
            var blobClient = storageAccount.CreateCloudBlobClient();
            var container = blobClient.GetContainerReference(containerName);
            container.CreateIfNotExists();

            var fileName = Path.GetFileNameWithoutExtension(filepath);

            var blockBlob = container.GetBlockBlobReference($"{fileName}-{nameof(UploadFromStream)}-{Guid.NewGuid()}");

            var stream = File.OpenRead(filepath);
            blockBlob.UploadFromStream(stream);

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
N/A
Setup (please complete the following information):

OS: Windows
IDE : Visual Studio 2019
Version of the Library used: .NET Framework 4.6.2, Microsoft.Azure.Storage.Blob 9.4.0+

Additional context
N/A
Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

[x] Bug Description Added
[x] Repro Steps Added
[x] Setup information Added

Thanks, @deenairn.  We'll look into adding a section in the v11 library's readme regarding async deadlocks.
The internal code problem is a sync-over-async situation imposed by the HttpClient.  We've recently uncovered and addressed one class of issues with the recent v11 release (there were some awaits that didn't also use ConfigureAwait(false)).


Import driver import and other minor improvements

Less magic for driver imports
Don't create the sequencer object at import time. This helped fixed some circular imports
Removed some unused globals and commented out code
Remove some broken and unused functions from fixate.core.control

Probably just nitpicking on things but a few things I don't like about what is left. I guess for the point of discussion and practising code review it will still be useful.
def __init__(self, initial_state):
    self._set_point = 0.0
    try:
        self._updated_value = float(initial_state)
    except ValueError as e:
        raise ParameterError(
            "initial_state found {}. Must be a non-zero number".format(
                initial_state
            )
        ) from e

This try except doesn't actually catch when the initial state is zero
def set_point(self, value):
    self._set_point = value

How is this any more useful than setting the value directly? Should this be part of init?
It looks like this was meant to be a standardised method between different controllers but then there is no base "controller" class that they all inherit from.
One thing I liked about converge_amplitude_scalar over converge_scalar was that it raised different exceptions for each reason, rather than just returning True if it succeeded or False if it failed. It makes it kind of annoying to have to open everything up in debug and manually step through the function to see what went wrong, especially because there is a timeout condition
Can also clean up unused imports.

All valid points. I was doing my best to not dig too deep in that corner. I was content to just delete stuff that is no longer being used. I think just deleting cruft is still valuable, because now there is much less distraction when we do come back around to try and improve things. Feel free to raise and issue or a new PR. I'm not planning anything further with this control.py module. Even getting some test coverage on this function would be good.
Possibly you'll have thoughts while continuing to troubleshoot the ELV issues.


Allows collector to log received span/stat packet count

This logs the number of span/stat packets received by the collector every minute.
resolves #5522

Codecov Report

Merging #5528 into 1.8.x will decrease coverage by 0.02%.
The diff coverage is 14.48%.

@@            Coverage Diff            @@
##           1.8.x    #5528      +/-   ##
=========================================
- Coverage   40.6%   40.57%   -0.03%
=========================================
  Files       2653     2662       +9
  Lines      79810    79955     +145
  Branches   10830    10845      +15
=========================================
+ Hits       32404    32442      +38
- Misses     44461    44570     +109
+ Partials    2945     2943       -2

Impacted Files
Coverage Δ

...collector/receiver/ServerRequestPacketCounter.java
0% <0%> (ø)

...ctor/monitor/aggregate/Slf4jAggregateReporter.java
0% <0%> (ø)

...ector/receiver/InetSocketAddressPacketCounter.java
0% <0%> (ø)

...collector/receiver/thrift/SpanDispatchHandler.java
0% <0%> (ø)
:arrow_up:

...collector/receiver/thrift/StatDispatchHandler.java
0% <0%> (ø)
:arrow_up:

...collector/monitor/aggregate/AggregateReporter.java
0% <0%> (ø)

...or/monitor/aggregate/AggregateReportFormatter.java
0% <0%> (ø)

...t/collector/monitor/aggregate/AggregateReport.java
0% <0%> (ø)

...r/monitor/aggregate/CollectorAggregateMonitor.java
0% <0%> (ø)

...ggregate/IpPortPacketCountAggregateDataSource.java
0% <0%> (ø)

... and 22 more

Continue to review full report at Codecov.

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


[Bug]: module 'google.generativeai' has no attribute 'Client'

File Name
intro_gemini_2_0_flash.ipynb
What happened?
client = genai.Client(vertexai=True, project=PROJECT_ID, location=LOCATION)
Error: "module 'google.generativeai' has no attribute 'Client'"

Relevant log output
No response
Code of Conduct

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

intro_gemini_2_0_flash.txt

Looks like this notebook isn't the one being run?
https://github.com/GoogleCloudPlatform/generative-ai/blob/main/gemini/getting-started/intro_gemini_2_0_flash.ipynb
The imports should look like this


MimecastSEG : Enhanced data connector to use existing workspace

Required items, please complete
Change(s):

Enhanced data connector to use existing workspace for ingesting logs.

Reason for Change(s):

In previous , always new workspace will be created.

Version Updated:

3.0.1

Testing Completed:

Yes

Checked that the validations are passing and have addressed any issues that are present:

Yes

Hi @SmitR01, thanks for raising this PR, we will review by 07 Dec 2023.


HttpRequest does not support DELETE method properly

Issue details
When using HttpRequest to send a DELETE with JSON content, it does not work properly and the JSON is ignored
Reproduction steps/code
Try the following code with a proper REST service supporting DELETE command:
         HttpRequest httpGet = new HttpRequest(HttpMethods.DELETE);
         httpGet.setHeader("Content-Type", "application/json");
         httpGet.setHeader("Accept", "application/json");
         httpGet.setUrl("https://myservice.com/main/v1/user/me/achievement");
         httpGet.setContent("{\"achievements\":[{\"achievement\":\"MY_ACHIEVEMENT\"}]}");

         Gdx.net.sendHttpRequest (httpGet, new HttpResponseListener() {

            @Override
            public void handleHttpResponse(HttpResponse httpResponse) {
                try
                {
                    String result = httpResponse.getResultAsString();
                    Json json = new Json();
                    Map<String, Object> test = json.fromJson(parameters.getClass(), result);
                    if (httpResponse.getStatus().getStatusCode()!=HttpStatus.SC_NO_CONTENT)
                    {
                        if (listener!=null)
                            listener.removeAchievementFailed("Status not ok: " + result);
                        return;
                    }
                    if (listener!=null)
                        listener.removeAchievementSucceeded(achievement);
                }
                catch(RuntimeException e)
                {
                    if (listener!=null)
                        listener.removeAchievementFailed("Error parsing httpResponse");
                }
            }

            @Override
            public void failed(Throwable t) {
                if (listener!=null)
                    listener.removeAchievementFailed("Connection failed");

            }

            @Override
            public void cancelled() {
                if (listener!=null)
                    listener.removeAchievementFailed("Connection cancelled");

            }
        });

After analysis the problem come from the com.badlogic.gdx.net.NetJavaImpl class in the method sendHttpRequest.
If you look at the code, the GET, POST and PUT method are taking into account and not the DELETE.
Especially with the doingOutput which should be true for DELETE.
The sending of httpRequest.getContent() is conditionned by this flag so it is not sent for a DELETE.
Version of LibGDX and/or relevant dependencies
Version 1.7.1
Please select the affected platforms

[ ] Android
[ ] iOS (robovm)
[ ] iOS (MOE)
[ ] HTML/GWT
[X] Windows
[ ] Linux
[ ] MacOS

DELETE should not have message bodies, it's supposed to handle things directly by URI.  If you want to have a message body in a request, use POST.  A lot of servers ignore bodies on DELETE requests, and most clients now (including Android) will strip off a body of a DELETE request.  Bodies on deletes, while not explicitly indicated as to not be allowed as part of the spec, are not universally supported and shouldn't be used.
A "proper REST service supporting DELETE command" should be ignoring the message body or returning a 400 when on is present.

Agree but the service I'm using (which is not under my control), expect to receive a body with a DELETE request

@Fumble-eric please submit a PR for this.

It seems it is broken yet in 1.9.6
Facebook API does not receive "access_token"
DELETE https://graph.facebook.com/[{REQUEST_OBJECT_ID}_{USER_ID}]?
access_token=[USER or APP ACCESS TOKEN]


0.10.0 pre release version updates

Update the operator version for release
Update the CAA go modules for pre-release

Check links is failing on multiple PRs with:
### Errors in src/cloud-api-adaptor/test/e2e/README.md

* [429] [https://github.com/confidential-containers/cloud-api-adaptor/commits/main/](https://github.com/confidential-containers/cloud-api-adaptor/commits/main/) | Failed: Network error: Too Many Requests

https://github.com/confidential-containers/cloud-api-adaptor/commits/main/ does still exist, so I think we are getting github rate limited (maybe as we are right at the end of the month?), so I think we are safe to ignore this for now.


QueenAnnotationTypeDeclarationNode.java: Fnish body delcaration, with ...

The puzzle 187393517 originating from #33 has to be resolved:
https://github.com/jvmqueen/queen-of-java/blob/b46e5ecab5f913d9de9936a750377a31a24119d8/src/main/java/org/queenlang/transpiler/nodes/QueenAnnotationTypeDeclarationNode.java#L43-L43
"Fnish body delcaration, with annotation elements.".
The puzzle was created by amihaiemil at 2022-12-13 16:10:00 +0200.
Estimation is 60 minutes.
If you have any technical questions, don't ask me, I won't be able to help. Open new issues instead.

@amihaiemil this is your task now, please go ahead. Deadline (when this ticket should be closed) is 2022-12-23T14:10:25.599093.
Estimation here is 60 minutes, that's how much you will be paid.
Remember, you don't have to solve everything in this ticket - you can solve it partially and leave todo markers in the code, which will become future tasks.
If you have any questions don't ask me, I'm not a technical person. Open new tickets instead.
If you don't have time or simply don't want to work on this, you can always resign.

@amihaiemil Don't forget to close this ticket before the deadline (2022-12-23T14:10:26). You are past the first half of the allowed period.

Puzzle disappeared from the code, that's why I closed this ticket.

@amihaiemil thank you for resolving this ticket. I've just added it to your active invoice. You can always check all your invoices and more on the Contributor Dashboard.


Wrong revision numbers on Fedora

I've tried to use the library under Fedora and ran into a simple Error. Fedora does not recognise the revision number correctly and always shows 0000 in /proc/cpuinfo. This leads to an Error::UnkownModel in any case. Currently, I'm on a 3B and I also tested it on a 2B.
I'm using a small hack in system.rs line 179 to identify the model manually since I know which version I'm using:
"0000" => Model::RaspberryPi3B,

Maybe there could be an option to configure the model manually.
Here's the end of my /proc/cpuinfo (it seems that it also gets the SoC wrong):
Hardware:    BCM2835
Revision:    0000
Serial:      00000000e07fdbcc

If you need more information or any help, I'd be glad to help. Cheers!

Thanks for reporting this issue! /proc/cpuinfo has been less than reliable on Raspbian as well, forcing me to ignore the Hardware field, and now it seems Revision can't be trusted either...
Could you check the output of cat /sys/firmware/devicetree/base/model for me on both your 2B and 3B? I may be able to use that as an alternative when /proc/cpuinfo doesn't provide enough information.

Here you go:
On the 3B:
cat  /sys/firmware/devicetree/base/model
    Raspberry Pi 3 Model B%
cat /sys/firmware/devicetree/base/compatible
    raspberrypi,3-model-bbrcm,bcm2837%

And on the 2B:
cat  /sys/firmware/devicetree/base/model
    Raspberry Pi 2 Model B%
cat /sys/firmware/devicetree/base/compatible
    raspberrypi,2-model-bbrcm,bcm2836%

That looks not that bad does it?

Indeed. That definitely seems like a good alternative, and makes things a bit easier than dealing with manually setting the model. Thanks for the quick reply with the needed info. Time to dig up some earlier models, and make sure they didn't change the format at some point like they did with revisions.
This looks like an easy fix, which I should be able to squeeze into the upcoming 0.7.0 release scheduled for this week.

Sounds great, thanks for your effort!

@KuabeM the latest commit in the master branch should fix this. When you have a chance, could you give it a try on Fedora to make sure it works as expected?

I'll be back at work tomorrow morning, first thing I'll do!

Works like a charm!
Device info on the 3B: Model: Raspberry Pi 3 B (SoC: BCM2837A1)
And on the 2B:  Model: Raspberry Pi 2 B (SoC: BCM2836)
Thanks for the great and fast work :smile:

Awesome! Thanks for testing. 0.7.0 should be available through crates.io later today.

@golemparts @KuabeM (<- as promised) added a tracking ticket for GPIO IRQs not working on Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1597577

@drahnr @KuabeM that's unfortunate. RPPAL's interrupt functionality is based on the gpio sysfs interface as described in the kernel documentation. There are alternative ways to implement support for interrupts on the Pi, but they all require busy waiting which doesn't really make them viable.

@golemparts I am totally with you, thus the above issue. Busy looping is just plain silly in this context.

@drahnr it looks like there actually might be an alternative in the form of the relatively new GPIO character device, but considering the major overhaul that would take, and the sysfs solution working as intended on Raspbian, switching interfaces just for Fedora isn't a priority at the moment. I do plan on researching it more in the future though. Let's hope the Fedora bug you reported is easy to fix.

@KuabeM @drahnr so just for fun, I made a quick proof of concept polling interrupts using the GPIO character device, and added the cdev_gpio_poll_interrupt() method to Gpio to experiment with. It'll block until the interrupt is triggered. Would either of you mind checking if it works on Fedora, or if it's bugged like the sysfs interrupts?
extern crate rppal;

use rppal::gpio::{Gpio, Trigger};

fn main() {
    let gpio = Gpio::new().unwrap();
    println!("{:?}", gpio.cdev_gpio_poll_interrupt(27, Trigger::RisingEdge).unwrap());
}

Wow sure, I'll probably have time for it on Sunday or Monday!

Awesome. While researching alternatives yesterday, I learned that the sysfs gpio interface has been deprecated, so I would have to replace the existing interrupt code at some point anyway. If it's also a workaround for the Fedora bug that would be a nice bonus!
I'll move this to a new issue for more convenient tracking.

@KuabeM if that works we move back to fedora as soon as that got implemented (:

Your prove of concept works just fine on Fedora. I also tried the master branch in our project - no more bugs, everything is work running flawless :fireworks:


Godot Editor Not Updating Exported Properties From C#

Tested versions

Reproducible in: v4.4.dev2.mono.official [97ef3c837] and NOT reproducible in v4.3.stable.mono.official [77dcf97d8]

System information
Godot v4.4.dev2.mono - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; <IP_ADDRESS>09) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)
Issue description
Using the latest v4.4.dev2.mono release, the Godot Editor Inspector is not updating after Exports have been added to a C# file, and the Godot Editor Builds the Project.
Rather, the whole Godot Editor needs to be closed, and relaunch for the properties to be seen.

Steps to reproduce

Launch Godot_v4.4-dev2_mono_win64.exe
Create a new project, named anything you want stored anywhere.
Editor => Editor Settings =>Dotnet => Editor => Visual Studio

External Editor Visual Studio

Click "3D Scene" under Create Root Node
Click Attach a new or existing script to the selected node.
Select Language: C#
Template Node: Default
Save the scene

	[Export]
	public int Foo { get; set; }

In the Godot Editor, click "Build Project"

Minimal reproduction project (MRP)
https://github.com/zachbugay/godot-ui-not-updating-4.4-dev2

This sounds similar to https://github.com/godotengine/godot/issues/97060. And it looks like that issue may be the same as https://github.com/godotengine/godot/issues/96828 which was fixed by https://github.com/godotengine/godot/pull/74830.

I was able to reproduce with 4.4 dev 2 but the issue is now fixed in master. I agree with raulsntos, it's most certainly related to #96828
I'm closing the issue since it's now working in master.


How to add combobox？

I'm meeting a problem. While trying to add a combobox into the gui.py. But the Canvas() seems not include a combobox parameter and ttk not woring with canvas either.
Is there any solution?

Hey sorry but this problem is not related to this repository. You can ask this question on stackOverflow. Thank you.


"bad regex: Out of memory" in logs

I am running OpenWrt 18.06.5 on a Netgear DM200 VDSL modem.
After logging in LuCI, I saw this in logread:
19:33:03 2019 daemon.err uhttpd[936]: luci: accepted login on / for root from XX.XX.XX.XX
19:33:39 2019 daemon.err uhttpd[936]: expr: bad regex '.*nFEC=\([-\.[:alnum:]]*\).*': Out of memory

The device has 64 MB of RAM, so this is a bit surprising, especially because the regex does not look that complex. I'm not sure which part of LuCI triggered this ("FEC" means it is probably related to the DSL status on the home page)
Unfortunately I couldn't reproduce it more than once.

That looks as if it is caused by the dsl_control init script which is periodically invoked. LuCI itself does not contain such a regex

Closing this as it is not related to LuCI


Add optional parameter of product_module_name

This will be forwarded into the xctestrun file in the test name doesn't accurately reflect the module underneath
Mirror of: https://github.com/google/xctestrunner/pull/50

@jerrymarino @gyfelton @thiagohmcruz


MSID: 95151 Version: 1 DOI: 10.1101/2<IP_ADDRESS>9968

MSID: 95151
Version: 1
Preprint DOI: https://doi.org/10.1101/2<IP_ADDRESS>9968
Step 1. Awaiting reviews
Editorial to post reviews via hypothesis
Useful links:

DocMap: https://data-hub-api.elifesciences.org/enhanced-preprints/docmaps/v2/by-publisher/elife/get-by-manuscript-id?manuscript_id=95151
New model tracking: https://docs.google.com/spreadsheets/d/1_fHaoOy7hjyocptKtVJRijeNpUY4hBS7Ck_aVmx6ZJk/
Reviews on sciety: https://sciety.org/articles/activity/10.1101/2<IP_ADDRESS>9968

For trouble shooting (e.g. no Docmaps available):

DocMap issue addressing: https://miro.com/app/board/uXjVNCwK6EI=/
Explore DataHub DocMaps API: https://lookerstudio.google.com/reporting/4c2f0368-babb-4beb-b5b3-497e7e7b0f08/page/ejphD
Unmatched submissions and preprints: https://lookerstudio.google.com/u/0/reporting/9f86204f-3bf7-477c-9b18-5c5ef141bf69/page/p_gxi57ha93c
Unmatched manuscripts spreadsheet: https://docs.google.com/spreadsheets/d/15QcK8w-ssB7109RQEDtFpJPZ0J5HTGxoHa_2TtpMBbg/edit#gid=1336081641

Step 2. Preview reviewed preprint
Production QC content ahead of publication
Instructions:

QC preview: https://prod--epp.elifesciences.org/previews/95151v1
Update ticket with any problems (add blocked label)
When QC OK, add QC OK label to ticket and add publication date and time to https://docs.google.com/spreadsheets/d/1amAlKvdLcaDp5W8Z8g77NmkwbMF5n_u89ArSqPMO8jg
Move card to next column
(At end of the day post link in #enhanced-preprint and ask for PDF to be generated)

Useful links:

Preprint DOI :  https://doi.org/10.1101/2<IP_ADDRESS>9968
Confirm reviews returned by EPP: https://prod--epp.elifesciences.org/api/reviewed-preprints/95151/v1/reviews
To update the MECA path in the docmap: https://docs.google.com/spreadsheets/d/1mctCQuNFBjSn97Lihy7_vBO6z7-N-oqyLv4clyi6zHg

Step 3: Awaiting search reindex
This step adds the reviewed preprint to the homepage: https://elifesciences.org
The search reindex is triggered once an hour. We need the reviewed preprint to be indexed as the search application serves the journal homepage.
Useful links:

Jenkins pipeline to reindex search can be triggered sooner or monitored here: https://alfred.elifesciences.org/job/process/job/process-reindex-reviewed-preprints/

Step 4: Published! PDF requested
Waiting for PDF to be generated
Useful links:

PDF tracking: https://docs.google.com/spreadsheets/d/106_XeDjmuBae7gexOTNzg60lapeqjl2aRn9DzupGyS8/

Step 5: Introduce PDF to data folder and git repo
Upload PDF to relevent folder in git repo https://github.com/elifesciences/enhanced-preprints-data/
Step 6: Done!

[ ] Kettle is on!

(From the authors: I have a grant proposal due by 3/15, it would be very helpful to have our reviewed manuscript posted online at eLife by then.)

Thanks @rkcook312 - I think this one is ready to check now


docs: Corrected naming of RISC-V architecture Update README.md

I noticed that the term "Risc-V" was used instead of the official "RISC-V" in several places, including the title and a section of the documentation.
I've updated these instances to ensure consistency with the official naming convention of the architecture.

Thanks for your PR.  We prefer the non-standard spelling.


namespace-scope configuration of manageJobsWithoutQueueName

What would you like to be added:
Kueue supports a global configuration manageJobsWithoutQueueName.  We would like to be able
to set this configuration flag to be true only for specific namespaces.
Why is this needed:
We would like to be able to use Kueue to manage batch-oriented production clusters where we can
enforce that all workloads submitted in certain namespaces (ie, user namespaces) must be submitted
through a Kueue-managed queue.  Setting manageJobsWithoutQueueName to true globally is not viable
without also disabling the batch/job integration because when it is enabled it interferes with system
operations that create Jobs to perform administrative tasks.
Our workaround in Kueue 0.6 is to not use manageJobsWithoutQueueName and instead use RBACs
to deny users in those namespaces the ability to directly create batchv1.Jobs (forcing them to submit
them via AppWrappers, which can be configured separately from Kueue to act as-if manageJobsWithoutQueueName
were true just for AppWrappers).  This is not optimal, because the extra level of wrapping for a resource type
that Kueue could support natively adds friction to the user experience.
Completion requirements:
It should be possible to provide a list of namespaces where manageJobsWithoutQueueName is true as part
of the Kueue configuration.   Ideally it would be possible to update this list dynamically without needing to
restart the Kueue controller.
This enhancement requires the following artifacts:

[ ] Design doc
[ ] API change
[ ] Docs update

The artifacts should be linked in subsequent comments.

I'm on the fence on this one.
One of the original principles of Kueue was to be lean, which in this topic means not to be a policy enforcer. We provided some basic namespace selectors in the ClusterQueues, but it's preferable not to expand into more policies.
Have you tried implementing this using a native validating admission policy? https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

I think the high-level feedback is that in our usage of Kueue, we've come to realize that a global manageJobsWithoutQueueNames is not useful for us as currently implemented.  Globally enabling suspend-by-default behavior for batch/Jobs breaks too many things (especially on OpenShift).
We can see two possible approaches to making queuing-by-default useful to us:

Using a namespace selector to have finer grained-control on whether manageJobsWithoutQueueNames is true/false as proposed in this issue.
Adding a jobOptions to the Kueue configuration with the same functionality as the existing podOptions to enable finer-grained control over queuing of batch/Jobs.  If we had this capability, then I believe the existing global scope for manageJobsWithoutQueueName could do what we need.

If you think option 2 is a better option for Kueue's design point, I'm happy to pursue that instead.

Have you tried implementing this using a native validating admission policy? https://kubernetes.io/docs/reference/access-authn-authz/validating-admission-policy/

Thanks for the pointer.  This could be useful to us eventually, but we currently need to support Kubernetes versions back to 1.27.

ValidatingAdmissionPolicy is alpha since v1.27 (disabled by default), and beta since v1.28 (enabled by default).
v1.27 end-of-life is a month from now https://kubernetes.io/releases/
So it doesn't feel like it's the right time to implement this functionality in Kueue.
Any chance you can enable the alpha feature in v1.27?

Turing on an alpha feature isn't viable for us.  But, the long term solution should be viable, so we don't have to do something in Kueue.
I guess the key question is do you ever intend to have manageJobsWithoutQueueNames be true and have the batch/jobs integration enabled in Kueue?   Because that combination is broken in subtle and hard to debug ways on clusters where system operations are performed using batch Jobs.

I would be leaning towards option (1.), and say that being able to exclude, by namespace selector, some administrative namespaces from manageJobsWithoutQueueName: true via Kueue API can be handy.

I agree that the functionality is useful. But (1) there is an alternative in 1.28+ and (2) it's hard to say when to stop implementing policies. What might be enough for your use case might not be enough for everyone.
I'm kind of ok with implementing this now, but I just do not want to set a precedent for future feature requests in this area.

I guess the key question is do you ever intend to have manageJobsWithoutQueueNames be true and have the batch/jobs integration enabled in Kueue? Because that combination is broken in subtle and hard to debug ways on clusters where system operations are performed using batch Jobs.

It works for some basic clusters that don't have system operations using jobs. But I'm tempted to remove this functionality altogether once we offer a v1 API.

I have similar use cases. The option (1) allows us to forcefully suspend all Jobs in the arbitrary namespaces (in general, only user namespaces), right?
But, the ValidatingAdmissionPolicy doesn't bring functionality to forcefully suspend Jobs; that just rejects creation.
I guess that the ValidatingAdmissionPolicy could not replace with option (1), maybe the native Kubernetes need to provide MutatingAdmissionPolicy something.
So, I think that providing option (1) is still valid.
@alculquicondor WDYT?

And it's even better for the user, as it provides immediate feedback.

I agree with you. Here, I'm curious about whether we can provide APIs to create ValidatingAdmissionPolicy something like blockJobsWithoutQueuName. Once the feature is enabled, the kueue-manager creates the ValidatingAdmissionPolicy to reject Jobs without queueName.
This has the advantage of easily introducing policies from the batch admins perspective, but it would bring us (kueue upstream) to increase maintenance costs.

My gut would be that Kueue should just document this (possibly with an example) as a way to achieve a particular kind of cluster configuration.  I think it will be easier for the batch admin if the actual creation of the ValidatingAdmissionPolicy is done using "vanilla" Kubernetes concepts and operations (as opposed to needing to know how to configure Kueue to create it).

And it's even better for the user, as it provides immediate feedback.

I agree with you. Here, I'm curious about whether we can provide APIs to create ValidatingAdmissionPolicy something like blockJobsWithoutQueuName. Once the feature is enabled, the kueue-manager creates the ValidatingAdmissionPolicy to reject Jobs without queueName.
This has the advantage of easily introducing policies from the batch admins perspective, but it would bring us (kueue upstream) to increase maintenance costs.

My gut would be that Kueue should just document this (possibly with an example) as a way to achieve a particular kind of cluster configuration. I think it will be easier for the batch admin if the actual creation of the ValidatingAdmissionPolicy is done using "vanilla" Kubernetes concepts and operations (as opposed to needing to know how to configure Kueue to create it).

That makes sense, but even if we don't provide the dedicated API like blockJobsWithoutQueueName, I think that providing the ValidatingAdmissionPolicy and ValidatingAdmissionPolicyRoleBinding would be worth it.
Because batch admins can define Validations using upstream ValidatingAdmissionPolicyRoleBinding for the custom jobs.
Additionally, we (upstream Kueue) provide the validations for native supporting Jobs (batch/job, rayjob...) using ValidatingAdmissionPolicyRoleBinding.

/assign @IrvingMg
Could you create a new task page under https://kueue.sigs.k8s.io/docs/tasks/manage/ explaining how to restrict the creation of jobs without queue name using a ValidatingAdmissionPolicy

As we updated the documentation in https://github.com/kubernetes-sigs/kueue/pull/2507 for this case, is it okay if we close this issue?

/close


Doesn't print all lines of output

Environment
Windows build number: Microsoft Windows NT 10.0.19041.0
Windows Terminal version (if applicable): 1.1.2021.0

Any other software?
PowerShell 7.0.3

Steps to reproduce

Compile this simple C program
MSVC: cl main.c -o main.exe
Zig: zig cc main.c -o main.exe

Run it and hit CTRL-C

#include <stdio.h>

int main() {
    int c;
    int blanks, tabs, nl;

    blanks = tabs = nl = 0;
    while ((c = getchar()) != EOF) {
        if (c == ' ') {
            ++blanks;
        } else if (c == '\t') {
            ++tabs;
        } else if (c == '\n') {
            ++nl;
        }
    }

    printf("Blanks: %d\n", blanks);
    printf("Tabs: %d\n", tabs);
    printf("Newlines: %d\n", nl);
}

Expected behavior

Each time it runs, it should print out the above lines. It works on Command Prompt and PowerShell 7 standalone.
Actual behavior

It only prints one/two of the lines. I've so far been able to print all three once. It fails in the Terminal with PowerShell 7.

Sorry, this is my bad. I should have been using CTRL-Z, Enter to exit the programs. It seems Terminal is just more aggressive at shutting down programs on CTRL-C than the other terminals I tried.


Collection REST Controller for the Document API V2

Implement a V2 version of the CollectionsResource. As with all REST controllers in the new versions, we should:

Have fully reactive implementation
Have retires for GET operations
Have a strong-typed DTO model
Validates DTOs
Have a well document API using the Open API v3

Done in #1722.


Adding keyCertSign parameter to make possible to verify

certificate against itself. It fixes issue #8:
Self-signed certificate has wrong keyUsage - it misses keyCertSign

@rszmigiel Can you rebase with the latest changes from master and verify your fix is still required? One of the other changes we merged in is showing conflict with this PR. Thanks!


Allowing password-less login

This allows one prototype to link to another without the user seeing a password page, it also allows the sending of direct links which will log the user in to the kit.

need to discuss priority of this with @ruthhammond


containers dashboard: ignore metrics with missing fields in heatmaps

Sometimes the metrics dont have all fields filled out so we have to ignore those in heatmaps

@abonas@simon3z Please review
@miq-bot add_label providers/containers, ui, bug

I'm not really sure what this PR does. Does it remove squares from the heatmap when there are no metrics? If yes, why not keep the square instead with a "no data" indication? much more clear to the user and aesthetic as well.

I'm not really sure what this PR does. Does it remove squares from the heatmap when there are no metrics?

yes, usually its one metric for a square on the left and right heatmap charts.
But metrics sometimes dont have all relevant fields filled out. whenever a required field was nil it would cause an exception. Im aiming to fix that in this PR by adding a square to a chart only if the data exists in the metric.

If yes, why not keep the square instead with a "no data" indication? much more clear to the user and aesthetic as well.

Im not sure about a no-data square. IMO it feels misleading to the user if a square exists  with no data on it. theoretically we could have an entire heatmaps chart of no-data squares...

Im not sure about a no-data square. IMO it feels misleading to the user if a square exists with no data on it. theoretically we could have an entire heatmaps chart of no-data squares...

I think it's more misleading to the user seeing a "hole", than having a square in a specific color with a clear "no data" indication (in tooltip, for example)
Also, what would happen if you have a more complex example with multiple "holes" and not just one square missing in the edge of a heatmap?
Lets say you have a 9 squares heatmap, and some metric is missing for 4 squares out of 9, including in the middle of the heatmap (for example - square number 2,4,7,8) - imo it will look really not good with 4 holes.
And if a solution is to "squash" the squares to avoid holes, that can create another confusion because now the squares in heatmap for metric A will not be positioned the same as the squares in heatmap for metric B.
cc @serenamarie125

there wont be a 'hole' scenario. One heatmaps side might just have less squares that is ok because:
we are sorting the heatmaps squares separately anyway- one by memory usage and the other by cpu usage. cpuHeatmap[x1,y1] and memHeatmap[x1,y1] do NOT refer to the same node.

The concerning scenario is that one heatmap would have less squares than the other and square size wont be the same for both charts.
A solution could be skipping a metric entirely if misses either memory or cpu usage.
that way a squares would be added to the heatmaps in together only - so both sides get the same amount.

cpuHeatmap[x1,y1] and memHeatmap[x1,y1] do NOT refer to the same node.

that's too bad, it would be confusing to user

that's too bad, it would be confusing to user

That may be but its the current situation of the dashboard and if it needs changing then it should be in a different PR

I think it's more misleading to the user seeing a "hole", than having a square in a specific color with a clear "no data" indication (in tooltip, for example)

+1 for @abonas suggestion above.
(I understand that we're sorting by metrics values so order of squares don't refer to the same node cpu/memory-wise... but having different number of squares is confusing).

I think it's more misleading to the user seeing a "hole", than having a square in a specific color with a clear "no data" indication (in tooltip, for example)
+1 for @abonas suggestion above.
(I understand that we're sorting by metrics values so order of squares don't refer to the same node cpu/memory-wise... but having different number of squares is confusing).

Done. updated screenshot above.
@simon3z @abonas @himdel Please review

Done. updated screenshot above.
@simon3z @abonas @himdel Please review

don't see any difference in the screenshot above, one has less squares than the other. what am I missing?

don't see any difference in the screenshot above, one has less squares than the other. what am I missing?

Sorry, fixed.

Sorry, fixed.

yes, now I see it. I think that the "usage - unknown in use of unknown" is too long and too cryptic. just "unknown" will be sufficient.

yes, now I see it. I think that the "usage - unknown in use of unknown" is too long and too cryptic. just "unknown" will be sufficient.

Should we show partial data like "usage 87% in use of unknown total" or "usage unknown in use of 8192 total"?

Should we show partial data like "usage 87% in use of unknown total" or "usage unknown in use of 8192 total"?

well, imo usage 87% of unknown is not a useful information. what can user conclude from it?

well, imo "usage 87% of unknown" is not a useful information. what can user conclude from it?

Well i would conclude that its working at 87% of capacity but maybe that isnt right here...

yes, now I see it. I think that the "usage - unknown in use of unknown" is too long and too cryptic. just "unknown" will be sufficient.

Went with this. screenshot and code updated.

This will break if d.percent === 0 (because 0 is falsy). Maybe explicitly (d.percent === null) ? ...?

Done, please have a look.

@himdel Is there anything else needed here?

Well if you're asking for it.. ;) .. the only thing I can see is that those tooltips should probably be translated.. so something along the lines of
      var tooltip = __("Node: ") + d.node + "
 " + __("Provider: ") + d.provider;
      if (d.percent === null || d.total === null) {
        tooltip += "
 " + __("Usage: Unknown");
      } else {
        percent = d.percent;
        tooltip += "
 " + __("Usage: ") + sprintf(__("%d%% in use of %d total"), (percent * 100).toFixed(0), d.total);
      }

would be nice.. :) Apart from that, everything is :+1:

Well if you're asking for it.. ;)

I guess I did :)
All comments addressed, @martinpovolny @dclarizio Please review\merge

@zeari need to address some JS test failures

@zeari need to address some JS test failures

@dclarizio done.


Support wildcard matching of Hostnames

Add a Hostname type, an alias for string, which is used to represent hostnames that we've resolved in the context of a config's namespace and domain. Use that type to implement wildcard based host matching for Gateways.
TODO: the other locations where we want wildcard host matching (which other locations are these?).

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: rshriram
Assign the PR to them by writing /assign @rshriram in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ZackButcher: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
918346cbd220a2832ba9fafe58123e5e3c871f8b
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
918346cbd220a2832ba9fafe58123e5e3c871f8b
link
/test istio-presubmit

prow/istio-unit-tests.sh
918346cbd220a2832ba9fafe58123e5e3c871f8b
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
918346cbd220a2832ba9fafe58123e5e3c871f8b
link
/test istio-presubmit

prow/istio-unit-tests.sh
0565ed6c2d074932d6c40d1528a2f6652371ec0a
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
0565ed6c2d074932d6c40d1528a2f6652371ec0a
link
/test istio-unit-tests

prow/istio-presubmit.sh
0565ed6c2d074932d6c40d1528a2f6652371ec0a
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
0565ed6c2d074932d6c40d1528a2f6652371ec0a
link
/test istio-presubmit

prow/istio-unit-tests.sh
3be7ab10d2c4e51b205e58e7307a1f2b7a340813
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: costinm
Assign the PR to them by writing /assign @costinm in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS
tests/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ZackButcher: PR needs rebase.

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
3be7ab10d2c4e51b205e58e7307a1f2b7a340813
link
/test istio-unit-tests

prow/istio-presubmit.sh
35ee0d418d2aecce8170bb8eff398063105aab70
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
35ee0d418d2aecce8170bb8eff398063105aab70
link
/test istio-presubmit

prow/istio-unit-tests.sh
35ee0d418d2aecce8170bb8eff398063105aab70
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approver: rshriram
Assign the PR to them by writing /assign @rshriram in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

pilot/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
35ee0d418d2aecce8170bb8eff398063105aab70
link
/test istio-presubmit

prow/istio-unit-tests.sh
c11c921f472cc7b4c21eced206023be1b7093626
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-unit-tests.sh
c11c921f472cc7b4c21eced206023be1b7093626
link
/test istio-unit-tests

prow/e2e-bookInfoTests-v1alpha3.sh
c11c921f472cc7b4c21eced206023be1b7093626
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
c11c921f472cc7b4c21eced206023be1b7093626
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-unit-tests.sh
7013455402053e924fe0a0cc1d9d3869e5b6bd0e
link
/test istio-unit-tests

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/e2e-bookInfoTests-v1alpha3.sh
c11c921f472cc7b4c21eced206023be1b7093626
link
/test e2e-bookInfo-envoyv2-v1alpha3

prow/istio-unit-tests.sh
7013455402053e924fe0a0cc1d9d3869e5b6bd0e
link
/test istio-unit-tests

prow/istio-presubmit.sh
7013455402053e924fe0a0cc1d9d3869e5b6bd0e
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@ZackButcher: The following tests failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-pilot-e2e.sh
e872d830e6b0d7b9af86ba1d4235bac3cbea8533
link
/test istio-pilot-e2e

prow/e2e-bookInfoTests-v1alpha3.sh
e872d830e6b0d7b9af86ba1d4235bac3cbea8533
link
/test e2e-bookInfo-envoyv2-v1alpha3

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


ksonnet version displaying badly formatted client-go version

$ kubecfg version
kubecfg version: (dev build)
jsonnet version: v0.9.4
client-go version: v1.6.8-beta.0+$Format:%h$

This is a "feature" of client-go.  In order to get the format to work correctly, it has to be compiled with a git sha, etc provided at link-time.  This didn't make much sense with kubecfg, where a naive version of this would show kubecfg's git sha.  We could theoretically dig out client-go's git version from vendor/vendor.json, but the ROI seemed tiny, just to avoid the above unexpanded format string, so I didn't bother.
I consider this a bug with the upstream client-go version - suggestions welcome for what we can do at our side that makes sense ...


failed el.form access when v-if used on custom directive

see the following url:
https://jsfiddle.net/kazupon/4uv5dg3t/2/

This is because the v-if block is compiled in an off-DOM fragment before being inserted. Unfortunately this is somewhat necessary to ensure correct compilation results. In general, directives should not assume where its el is.
As a workaround, you can wait for a nextTick before trying to access this.el.form. Note this means you will have to do some extra checks in your update function, but it should be ok...

Thanks!!
I understood :)


 This throws error on compilation for me.
This patch updates ethers-rs to version 1.0.x. It also removes patch version from stable crates (serde, serde_json).

shit- my bad, was very tired when merging last time


Metro bundler says that runtypes has require cycle

Metro output:
 WARN  Require cycle: node_modules/runtypes/lib/index.js -> node_modules/runtypes/lib/types/unknown.js -> node_modules/runtypes/lib/runtype.js -> node_modules/runtypes/lib/index.js

Require cycles are allowed, but can result in uninitialized values. Consider refactoring to remove the need for a cycle.

Sorry, essentially it's not possible to remove the cycle. Each runtype such as Unknown needs to use the internal create function defined in runtype.ts, and the create function needs some of those runtypes in order to implement the utility functions like .optional() and .withConstraint(). Actually it might be possible if we put all the codebase in a single bloated file, but absolutely we don't want. I think bundlers have to be completely okay to work with circular imports.
It's a valid semantics in ECMAScript, however, we're currently transpiling only with "module": "commonjs" option. ESM support is definitely what we should add. Also, we can add some auxiliary configurations like "sideEffects": false in package.json, which would help bundlers to work.
Essentially this is a wontfix though, let's leave this issue open until the warning disappears after some configuration. Maybe #243 is also worth tracking.

Thanks for the detailed explanation!
I tried to fix this myself, but understand that it hardly possible.


Tables not deleted after version upgrade

I'm trying to combine two tables into one while upgrading the database. The code looks like this:
db.version(3).stores({
  bookmarks: 'url, title, text, extraData',
  history: 'url, title, color, visitCount, lastVisit, extraData',
  readingList: 'url, time, visitCount, pageHTML, article, extraData',
  settings: 'key, value'
})

db.version(4).stores({
  places: 'url, title, color, visitCount, lastVisit, pageHTML, extractedText, *searchIndex, isBookmarked, extraData',
  readingList: 'url, time, visitCount, pageHTML, article, extraData',
 settings: 'key, value'
})
.upgrade(function(t) {

  t.history.each(function(historyItem) {
    t.places.put({
      url: historyItem.url,
      title: historyItem.title,
      color: historyItem.color,
      visitCount: historyItem.visitCount,
      lastVisit: historyItem.lastVisit,
      //data not stored in the old database schema
      pageHTML: '',
      extractedText: '',
      searchIndex: [],
      //the old history table did not contain bookmarks
      isBookmarked: false,
      extraData: historyItem.extraData
    })
  })

  t.bookmarks.each(function(bookmark) {
    t.places.put({
      url: bookmark.url,
      title: bookmark.title,
      color: '',
      visitCount: 1,
      lastVisit: 0,
      pageHTML: '',
      extractedText: bookmark.text,
      searchIndex: bookmark.text.split(' '),
      isBookmarked: true,
      extraData: bookmark.extraData,
    })
  })
})

The new places table gets created correctly, and contains the items from the history and bookmarks tables. However, the history and bookmarks tables never get deleted, even though they are not included in the new schema. They are still shown in the Chrome devtools, and can still be queried. Is there a way to delete these tables?

See #275

Oh, okay. Thank you!

See new comments in #275 as well. In your case, you should actually add an additional version with the store names set to null. If you had set them to null in the same version that your upgrader is attached to, it wouldn't be possible to read from the stores being deleted.

OK, thanks!


Add additional context to the yaml editor

Describe the enhancement you'd like to see
When navigating through a yaml file for K8s, in many cases there is a need to understand the hierarchy,  and now exactly where you are in the file. Adding the context to the editor can help you edit the yaml file easier
Additional context
Some other editor present a breadcrumb so you know exactly where you are (filename -> spec -> template -> spec).
A more visual component that represented the navigation point could also be good (i.e. a vertical line showing where you are in the file so you can identify things at the same level).
That would complement the capability to show / hide hierarchy levels in the current solution

seems similar to https://github.com/kubeshop/monokle/issues/786

You are right. Closing it


[BUG] having two  in a modal hides top

Ionic version:  (check one with "x")
[ ] 1.x
[x] 2.x
I'm submitting a ...  (check one with "x")
[x] bug report
[ ] feature request
[ ] support request => Please do not submit support requests here, use one of these channels: https://forum.ionicframework.com/ or http://ionicworldwide.herokuapp.com/
Current behavior:
When having two  in a modal, it hides 46 pixels of the first content behind the header
Expected behavior:
Modals to show the content fully
Steps to reproduce:
http://plnkr.co/edit/PNJ3SSe3YD8ITjnkvYZz?p=preview
Other information:
The solution is just to remove the second one.
I just didn't see any documentation saying I am not allowed to have two ion-content, so I think it would be great if you add one

Hello, thanks for using Ionic! It is actually recommended to not have more than one ion-content. What is your use case for having multiple contents?

@jgw96 I have no use case for multiple conents. However, I could not find a place stating "recommended to not have more than one ion-content."
I think it is important it would be documented, as I could not understand my problem for a while.
If it is documented, I probably missed it, and this issue is just wasting your time :)

This issue was moved to driftyco/ionic-site#956

Hey @AmitMY im moving this to the site repo as its a docs issue. We do mention in the docs for the ion-header component that you should only have one ion-content but we don't actually mention that in the docs for the ion-content component itself, which does not make sense (: . Thanks again for bringing this to our attention!


Running fmriprep on M2 chip Mac using Docker

What's the problem?
I am trying to use fmriprep in M2 chip Mac using docker.
I installed fmriprep via
pip install --user --upgrade fmriprep-docker
Than I run
 fmriprep-docker /Users/kanamatsuyanagi/Downloads/cupcake/sub-1301 /Users/kanamatsuyanagi/Downloads/sub-1301/output participant --participant-label 1301 --fs-license-file /Users/kanamatsuyanagi/Downloads/license.txt
but I got this error
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Warning: <8GB of RAM is available within your Docker environment.
Some parts of fMRIPrep may fail to complete.
Continue anyway? [y/N]y
RUNNING: docker run --rm -e DOCKER_VERSION_8395080871=24.0.5 -it -v /Users/kanamatsuyanagi/Downloads/license.txt:/opt/freesurfer/license.txt:ro -v /Users/kanamatsuyanagi/Downloads/cupcake/sub-1301:/data:ro -v /Users/kanamatsuyanagi/Downloads/sub-1301/output:/out nipreps/fmriprep:23.1.4 /data /out participant --participant-label 1301
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Traceback (most recent call last):
  File "/opt/conda/envs/fmriprep/bin/fmriprep", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/cli/run.py", line 43, in main
    parse_args()
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/cli/parser.py", line 786, in parse_args
    config.from_dict({})
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/config.py", line 678, in from_dict
    execution.load(settings, init=initialize('execution'), ignore=ignore)
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/config.py", line 232, in load
    cls.init()
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/config.py", line 476, in init
    cls._layout = BIDSLayout(
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/bids/layout/layout.py", line 135, in __init__
    root, description = validate_root(root, validate)
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/bids/layout/validation.py", line 75, in validate_root
    raise BIDSValidationError(
bids.exceptions.BIDSValidationError: 'dataset_description.json' is missing from project root. Every valid BIDS dataset must have this file.
Example contents of 'dataset_description.json':
{"Name": "Example dataset", "BIDSVersion": "1.0.2"}
fMRIPrep: Please report errors to https://github.com/nipreps/fmriprep/issues

So based on the conversation on #2431, I tried this
git clone https://github.com/nipreps/fmriprep.git
git -C fmriprep fetch origin pull/2435/head
git -C fmriprep checkout FETCH_HEAD

and run again with this
fmriprep-docker /Users/kanamatsuyanagi/Downloads/cupcake/sub-1301 /Users/kanamatsuyanagi/Downloads/sub-1301/output participant --participant-label 1301 --fs-license-file /Users/kanamatsuyanagi/Downloads/license.txt --patch fmriprep=fmriprep/fmriprep
But now I get this error
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
Warning: <8GB of RAM is available within your Docker environment.
Some parts of fMRIPrep may fail to complete.
Continue anyway? [y/N]y
RUNNING: docker run --rm -e DOCKER_VERSION_8395080871=24.0.5 -it -v /Users/kanamatsuyanagi/fmriprep/fmriprep:/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep:ro -v /Users/kanamatsuyanagi/Downloads/license.txt:/opt/freesurfer/license.txt:ro -v /Users/kanamatsuyanagi/Downloads/cupcake/sub-1301:/data:ro -v /Users/kanamatsuyanagi/Downloads/sub-1301/output:/out nipreps/fmriprep:23.1.4 /data /out participant --participant-label 1301
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
/opt/conda/envs/fmriprep/lib/python3.10/site-packages/bids/config.py:38: FutureWarning: Setting 'extension_initial_dot' will be removed in pybids 0.16.
  warnings.warn("Setting 'extension_initial_dot' will be removed in pybids 0.16.",
You are using fMRIPrep-0+unknown, and a newer version of fMRIPrep is available: 23.1.4.
Please check out our documentation about how and when to upgrade:
https://fmriprep.readthedocs.io/en/latest/faq.html#upgrading
/opt/conda/envs/fmriprep/lib/python3.10/site-packages/bids/layout/validation.py:48: UserWarning: The ability to pass arguments to BIDSLayout that control indexing is likely to be removed in future; possibly as early as PyBIDS 0.14. This includes the `config_filename`, `ignore`, `force_index`, and `index_metadata` arguments. The recommended usage pattern is to initialize a new BIDSLayoutIndexer with these arguments, and pass it to the BIDSLayout via the `indexer` argument.
  warnings.warn("The ability to pass arguments to BIDSLayout that control "
Traceback (most recent call last):
  File "/opt/conda/envs/fmriprep/bin/fmriprep", line 8, in <module>
    sys.exit(main())
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/cli/run.py", line 17, in main
    parse_args()
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/cli/parser.py", line 710, in parse_args
    validate_input_dir(
  File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep/utils/bids.py", line 145, in validate_input_dir
    raise RuntimeError(error_msg % ','.join(bad_labels))
RuntimeError: Data for requested participant(s) label(s) not found. Could not find data for participant(s): 1301. Please verify the requested participant labels. This error can be caused by the input data not being accessible inside the singularity container. Please make sure all paths are mapped properly (see https://www.sylabs.io/guides/3.0/user-guide/bind_paths_and_mounts.html)
fMRIPrep: Please report errors to https://github.com/nipreps/fmriprep/issues

In case,,,
when I try this
fmriprep-docker --version
I get this
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested
fMRIPrep v23.1.4

What would be the problem?
(The dataset is from openneuro and is BIDS validated)
What command did you use?
fmriprep-docker /Users/kanamatsuyanagi/Downloads/cupcake/sub-1301 /Users/kanamatsuyanagi/Downloads/sub-1301/output participant --participant-label 1301 --fs-license-file /Users/kanamatsuyanagi/Downloads/license.txt --patch fmriprep=fmriprep/fmriprep
RUNNING: docker run --rm -e DOCKER_VERSION_8395080871=24.0.5 -it -v /Users/kanamatsuyanagi/fmriprep/fmriprep:/opt/conda/envs/fmriprep/lib/python3.10/site-packages/fmriprep:ro -v /Users/kanamatsuyanagi/Downloads/license.txt:/opt/freesurfer/license.txt:ro -v /Users/kanamatsuyanagi/Downloads/cupcake/sub-1301:/data:ro -v /Users/kanamatsuyanagi/Downloads/sub-1301/output:/out nipreps/fmriprep:23.1.4 /data /out participant --participant-label 1301

What version of fMRIPrep are you running?
v23.1.4
How are you running fMRIPrep?
Docker
Is your data BIDS valid?
Yes
Are you reusing any previously computed results?
No
Please copy and paste any relevant log output.
No response
Additional information / screenshots
No response

fmriprep-docker /Users/kanamatsuyanagi/Downloads/cupcake/sub-1301

You are passing an individual subject instead of a dataset.

Thank you @effigies.
I actually uninstalled everything and reinstalled it and tried it again incorporating your point. Now I can run it without having to clone it from GitHub. (Which I am not sure why it got fixed. Anyways, ) So I can start the fmriprep with this code now :) :
fmriprep-docker ~/ds003242 ~/ds003242_preprocessed/sub1 participant --participant-label SAXSISO01b --fs-license-file ~/license.txt -w ~/fmri_working
But after a few hours (3 ~ 8 hrs), I always get this error (I have tried it 4 times and I get approximately similar error messages):
230812-13:29:20,519 nipype.workflow INFO: 	 [Node] Finished "sdc_report", elapsed time 86.041331s. exception calling callback for <Future at 0x40245f6320 state=finished raised BrokenProcessPool> Traceback (most recent call last):   File "/opt/conda/envs/fmriprep/lib/python3.10/concurrent/futures/_base.py", line 342, in _invoke_callbacks     callback(self)   File "/opt/conda/envs/fmriprep/lib/python3.10/site-packages/nipype/pipeline/plugins/multiproc.py", line 159, in _async_callback     result = args.result()   File "/opt/conda/envs/fmriprep/lib/python3.10/concurrent/futures/_base.py", line 451, in result     return self.__get_result()   File "/opt/conda/envs/fmriprep/lib/python3.10/concurrent/futures/_base.py", line 403, in __get_result     raise self._exception concurrent.futures.process.BrokenProcessPool: A process in the process pool was terminated abruptly while the future was running or pending.
According to previous issues, I figured it out to be a memory issue. So I tried adding,
--omp-nthreads 8 --nthreads 8
But I still got the same issue so next I also added,
--mem-mb 30000
But still I get the same issue.
I have allocated 8 CPU, 8GB RAM, and 4GB Swap memory to docker which is all the maximum value I can allocate. Virtual disk limit is set to 216GB. My pc itself has 360.2 GB left in Macintosh HD.
What do you think the problem is?
I was also wondering if this
File "/opt/conda/envs/fmriprep/lib/python3.10/concurrent/futures/_base.py"
would be the problem.
What does
/opt/conda/envs/fmriprep
point to? I don't have such conda environment called fmriprep but would this be related to the error I get?

That's definitely a memory error. If you only have 10GB, I might try running with --nthreads 1, which should let you still run some parallel tasks with --omp-nthreads 8, but will only run one task at a time.

Sorry for the late reply.
Unfortunately, I couldn't run it even with --nthreads 1.
But I tried it with another dataset (lighter one) with --nthreads 1 and it worked! Maybe my PC is not capable of processing a large dataset.
Thank you very much for your help. It helped me very much.


Retain +1 day tables when deleting history

[x] If this pull request closes/resolves/fixes an existing issue, replace the issue number. Closes #.
[x] Update the CHANGES log. No need, not released yet.

Currently when deleting outdated tables, the DAO only filters the tables that are in T - ttl, causing the newly created table for T + 1 is deleted, this makes the table schema for T + 1 incomplete, for example, when 2 (or more) metrics, metrics_1 and metrics_2 are the same function type (metrics_longavg), when deleting history tables for metrics_1, it will delete all tables in the pattern metrics_longavg_\d{8} except for the [T - ttl, T], and a new table metrics_longavg_<T+1> is created, but at the same time when deleting the same for metrics_2, it will delete all tables except for [T - ttl, T], causing the newly created metrics_longavg_<T+1> be deleted, and the data columns for metrics_1 is gone.

So, after the change, are we going to delete the table older than NOW - ttl only. Others are skipped?

So, after the change, are we going to delete the table older than NOW - ttl only. Others are skipped?

Previously, we delete tables that are NOT in range [NOW - ttl, NOW], now, we delete tables that are NOT in range of [NOW - ttl, NOW + 1], that's all in this patch.


Prevent CompatHelper PRs from polluting TagBot entries?

Is it possible to automatically label CompatHelper PRs with the no changelog label so that they don't fill up the TagBot changelog output?

Currently we don’t have that ability. But it would be a cool feature to add. I’d be happy to review a PR that adds this feature to CompatHelper.

https://github.com/JuliaWeb/GitHub.jl/pull/115 might add the option for labeling new PRs.

No, that is just for obtaining labels. You can already add labels, Registrator does it.

Yeah, GitHub.jl already has the ability to add labels to a PR. Someone just has to add the feature to CompatHelper.
I think it should be an opt-in feature. So the default behavior is that no labels are added. And then you can opt in by providing a list of one or more labels that you would like to add.


Update model and fixed default output suffix

Checklist
GitHub

[x] I've given this PR a concise, self-descriptive, and meaningful title
[x] I've linked relevant issues in the PR body
[x] I've applied the relevant labels to this PR
[x] I've applied a release milestone (major, minor, patch) in line with Semantic Versioning guidelines
[x] I've assigned a reviewer

PR contents

[x] I've consulted SCT's internal developer documentation to ensure my contribution is in line with any relevant design decisions
[ ] I've added relevant tests for my contribution
[x] I've updated the relevant documentation for my changes, including argparse descriptions, docstrings, and ReadTheDocs tutorial pages

Description
In this PR:

[x] Correct the parser of sct_deepseg -o regarding the default output suffix
[x] Add a new release of the model_seg_exvivo_gm-wm_t2_unet2d-multichannel-softseg
[x] ONNX instead of PT version in order to speed up segmentation process (see #3309)

Linked issues
Resolves #3278, Resolves #3279, Resolves #3309

@jcohenadad & @joshuacwnewton: PR ready for review
Installation of model:
chgroc@rosenberg:~/spinalcordtoolbox$ sct_deepseg -install-task seg_exvivo_gm-wm_t2

--
Spinal Cord Toolbox (git-cg/i3278_deepseg_output_name-2d533ffc5d722ff951277df673f06154984826a3)

sct_deepseg -install-task seg_exvivo_gm-wm_t2
--

INSTALLING MODEL: model_seg_exvivo_gm-wm_t2_unet2d-multichannel-softseg
Trying URL: https://github.com/ivadomed/model_seg_exvivo_gm-wm_t2_unet2d-multichannel-softseg/archive/r20210331.zip
Downloading: model_seg_exvivo_gm-wm_t2_unet2d-multichannel-softseg-r20210331.zip
Status: 72.9MB [00:06, 12.0MB/s]
Creating temporary folder (/tmp/sct-20210330230855.113934-es10oz8_)
Unzip data to: /tmp/sct-20210330230855.113934-es10oz8_
Removing temporary folders...

At the moment I have an error with the ONNX model:
chgroc@rosenberg:~/spinalcordtoolbox$ sct_deepseg -i ../duke/projects/ivadomed/gm_t2_exvivo/sub-3902top/anat/sub-3902top_T2w.nii.gz -task seg_exvivo_gm-wm_t2

--
Spinal Cord Toolbox (git-cg/i3278_deepseg_output_name-2d533ffc5d722ff951277df673f06154984826a3)

sct_deepseg -i ../duke/projects/ivadomed/gm_t2_exvivo/sub-3902top/anat/sub-3902top_T2w.nii.gz -task seg_exvivo_gm-wm_t2
--

WARNING: fname_roi has not been specified, then the entire volume is processed.

Loaded 512 axial slices.
Traceback (most recent call last):
  File "/home/GRAMES.POLYMTL.CA/chgroc/spinalcordtoolbox/spinalcordtoolbox/scripts/sct_deepseg.py", line 245, in <module>
    main(sys.argv[1:])
  File "/home/GRAMES.POLYMTL.CA/chgroc/spinalcordtoolbox/spinalcordtoolbox/scripts/sct_deepseg.py", line 207, in main
    nii_lst, target_lst = imed_inference.segment_volume(path_model, input_filenames, options=options)
  File "/home/GRAMES.POLYMTL.CA/chgroc/spinalcordtoolbox/python/envs/venv_sct/lib/python3.6/site-packages/ivadomed/inference.py", line 264, in segment_volume
    preds = model(img) if fname_model.endswith('.pt') else onnx_inference(fname_model, img)
  File "/home/GRAMES.POLYMTL.CA/chgroc/spinalcordtoolbox/python/envs/venv_sct/lib/python3.6/site-packages/ivadomed/inference.py", line 377, in onnx_inference
    ort_session = onnxruntime.InferenceSession(model_path)
  File "/home/GRAMES.POLYMTL.CA/chgroc/spinalcordtoolbox/python/envs/venv_sct/lib/python3.6/site-packages/onnxruntime/capi/session.py", line 158, in __init__
    self._load_model(providers or [])
  File "/home/GRAMES.POLYMTL.CA/chgroc/spinalcordtoolbox/python/envs/venv_sct/lib/python3.6/site-packages/onnxruntime/capi/session.py", line 177, in _load_model
    self._sess.load_model(providers)
onnxruntime.capi.onnxruntime_pybind11_state.InvalidGraph: [ONNXRuntimeError] : 10 : INVALID_GRAPH : This is an invalid model. Type Error: Type 'tensor(bool)' of input parameter (281) of operator (ScatterND) in node (ScatterND_160) is invalid.

... which does not happen with the PT version of the model.
@joshuacwnewton : Do you have any idea?
A short term solution would be to use the PT version of the model (even if probably slower, see #3309). @jcohenadad: What do you think?

I've opened an issue for this here ivadomed/ivadomed#749 with the start of an investigation.

Thanks so so much for looking into this @joshuacwnewton !

Is the model definition code hosted anywhere, by chance? (Not sure where I should be looking. 😅)

Of course, thanks for asking! The full config file used for this model can be found here. But essentially, the model architecture is this one.

With @jcohenadad, we agreed (as a short term solution) to replace the onnx model with the pt model, so that our collaborators can use it while we find a solution for the onnx version.
Everything works on my hand. Ready for review!

I'm afraid I have bad news. I tested the latest model on data with the correct orientation, but results are sub-optimal.
95c93564e4a7286af4513bf40c9341859e1ec68d

Now, here are results when data are A-P flipped (which is anatomically incorrect):

Here are the results I obtained in the past from master 999674872b1cdb69cc7125ebfad8533057a79dae (note: the data are also incorrectly A-P flipped, which I had to do in order to get better performance):

As can be seen, the model still performs better when the data are in the incorrect orientation (ie: A-P flipped).
To make it clear what I mean by "A-P" flipped, here is the incorrect orientation:

And here is the correct orientation (but suboptimal segmentation):

I'm afraid the "flipped" was maybe R-L flipped?

@charleygros could you please clarify how the data was flipped? thank you

@charleygros could you please clarify how the data was flipped? thank you

Using "sct_image -i IMAGE.nii.gz -setorient-data PSL -o IMAGE_NEW.nii.gz"

r20210401_v2

yay!!!


CLOUD-401 configurable consul server count with defaults

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/848/

Jenkins build finished, all tests passed.
Refer to this link for build results: http://ci.sequenceiq.com/job/cloudbreak-pull-request/850/