Move copying of seed conditions to shoots registered as seeds to GCM

How to categorize this PR?
/area control-plane
/kind enhancement
What this PR does / why we need it:
Moves the copying of seed conditions to shoots registered as seeds to GCM, as suggested in #4776. In addition, also adds messages to ManagedSeed conditions to prevent a generic "uninitialized" message from being used.
Which issue(s) this PR fixes:
Fixes #4776
Special notes for your reviewer:
Since I could not find an existing controller / reconciler that would fit well, I added a new ShootConditions reconciler to the shoot controller. It watches seeds that have corresponding shoots, filtering only condition updates and deletions.
Release note:
The copying of seed conditions to shoots registered as seeds has been moved to GCM.

In my opinion, we should rather transfer the logic to GCM instead of dropping it. Personally, I find this quite helpful when operating landscapes/seeds.

In my opinion, we should rather transfer the logic to GCM instead of dropping it. Personally, I find this quite helpful when operating landscapes/seeds.

@rfranzke OK, looking at #4776 it was not clear that there are different opinions from what was proposed as "option 2" by @timebertt .
I agree that copying the conditions is the safer approach and I intend to rework the PR accordingly. @timebertt any objections?

In my opinion, we should rather transfer the logic to GCM instead of dropping it. Personally, I find this quite helpful when operating landscapes/seeds.

I would argue, that it's actually conceptually wrong and plain overhead to copy the conditions. In my opinion, it is just a hack to easily display seed conditions in the dashboard next to the conditions of a shoot, but has no real value from an API perspective (there are also other seeds that are not shoots, but their conditions are not copied anywhere?). One could even argue, that this condition copying is just a workaround for a missing seed dashboard view 😄
However, this is a different discussion.

I agree that copying the conditions is the safer approach and I intend to rework the PR accordingly. @timebertt any objections?

No objections. https://github.com/gardener/gardener/issues/4776 is just about fixing inconsistencies between seed and shoot conditions, so moving the logic to GCM is an adequate solution as well. You can go ahead :)

/invite @rfranzke @timebertt

/cc @timuthy regarding adding messages for ManagedSeed conditions

/squash

Should we use the opportunity to add a new small envtest for the new reconciler?

Yes, that would be a perfect fit for this reconciler.

I'm wondering: did you consider adding a ManagedSeed controller to gcm? It would fit the purpose quite nicely, I think – watches Seeds that are backed by Shoots (via ManagedSeeds) and acts on Shoots accordingly. However, I'm also fine with adding it to the shoot controller.

This was my "first attempt". What I didn't like about it was the boilerplate of adding an entirely new controller to GCM, and only for this single reconciler. Then I realized I can achieve exactly the same by adding a new reconciler to the shoot controller. There are no strong reasons to prefer managed seeds over shoots (or vice versa), both work equally well, however the boilerplate of adding a reconciler to an existing controller is much smaller.

Yes, that would be a perfect fit for this reconciler.

@rfranzke @timebertt I am a bit confused. Looking at the consequences of adding too much envtests in some other projects (e.g. etcd-druid), I am rather wary of having too much of them. Would you care to explain why this particular reonciler would be a fit while others wouldn't be? I could with equal effort add unit tests for this small reconciler - wouldn't that be even better?

Yes, that would be a perfect fit for this reconciler.

@rfranzke @timebertt I am a bit confused. Looking at the consequences of adding too much envtests in some other projects (e.g. etcd-druid), I am rather wary of having too much of them. Would you care to explain why this particular reonciler would be a fit while others wouldn't be? I could with equal effort add unit tests for this small reconciler - wouldn't that be even better?

What were these consequences? I was only aware of CPU-throttling issues, however, I haven't seen them since long in our CI/CD runs and assumed that the test result caching has helped.
Generally, unit tests make sense as well. However, only having them would leave the controller part untested. In this PR, I see that there are some predicates and multiple controller types. I think it's helpful to have some basic envtests to cover these things as well to increase the overall confidence when making changes in the future.

What were these consequences? ...

etcd-druid tests are taking many minutes to complete and are a real pain to maintain (since full test runs take so long). They are sometimes flaky as well.
We already had a discussion about this with @rfranzke and @timebertt. The etcd-druid tests aim to cover every single detail of the controller behavior. In general, envtests should not try to achieve test coverage but to test a few important integration scenarios.
I still have some doubts about how many envtests we could add to g/g  before ending up in a similar situation, but this is not a discussion for this PR. I will add a basic envtest as requested.

OK, given that you still have doubts, I'm also fine if we wait until we have our test strategy session in CW48. I think the question "when to introduce an envtest?" is one of those we wanted to clarify in such meeting. So, feel free to first focus on the other feedback of @timebertt here. Introducing an envtest could also be done in a subsequent PR, I don't think it's critical right now.

@timebertt I addressed all your feedback, PTAL.
@rfranzke Thanks, I would indeed prefer to skip the envtest for now, until we have had the discussion. I will add it later if we still think it's a good idea to do so. BTW, I am introducing a similar simple reconciler with #5022, another "good candidate" for envtests I suppose.


Fix get instances for volume-based instances

Summary
Fix the case when the instance is started from a Volume as OpenStack returns an empty-string in this case, instead of a dict with the image details.

Self-merging this as no-one else is around.
I hope @gwarf is ok :)


6gb GPU throws error at CogvideoX_Fun_Pose 5b GGUF, but I2V workflow works.

Changing resolution, VAE tiling and input video node didn't change anything..
Closest bucket size: 672x384
!!! Exception during processing !!! Cannot copy out of meta tensor; no data! Please use torch.nn.Module.to_empty() instead of torch.nn.Module.to() when moving module from meta to a different device.
Traceback (most recent call last):
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\ComfyUI\execution.py", line 317, in execute
    output_data, output_ui, has_subgraph = get_output_data(obj, input_data_all, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
                                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\ComfyUI\execution.py", line 192, in get_output_data
    return_values = _map_node_over_list(obj, input_data_all, obj.FUNCTION, allow_interrupt=True, execution_block_cb=execution_block_cb, pre_execute_cb=pre_execute_cb)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\ComfyUI\execution.py", line 169, in _map_node_over_list
    process_inputs(input_dict, i)
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\ComfyUI\execution.py", line 158, in process_inputs
    results.append(getattr(obj, func)(**inputs))
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\ComfyUI\custom_nodes\ComfyUI-CogVideoXWrapper\nodes.py", line 1325, in encode
    vae.to(offload_device)
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\python_embeded\Lib\site-packages\torch\nn\modules\module.py", line 1174, in to
    return self._apply(convert)
           ^^^^^^^^^^^^^^^^^^^^
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\python_embeded\Lib\site-packages\torch\nn\modules\module.py", line 780, in _apply
    module._apply(fn)
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\python_embeded\Lib\site-packages\torch\nn\modules\module.py", line 780, in _apply
    module._apply(fn)
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\python_embeded\Lib\site-packages\torch\nn\modules\module.py", line 780, in _apply
    module._apply(fn)
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\python_embeded\Lib\site-packages\torch\nn\modules\module.py", line 805, in _apply
    param_applied = fn(param)
                    ^^^^^^^^^
  File "C:\Users\codem\Downloads\ComfyUI_Windows_portable_cu121\ComfyUI_Windows_portable\python_embeded\Lib\site-packages\torch\nn\modules\module.py", line 1167, in convert
    raise NotImplementedError(
NotImplementedError: Cannot copy out of meta tensor; no data! Please use torch.nn.Module.to_empty() instead of torch.nn.Module.to() when moving module from meta to a different device.

Prompt executed in 344.54 seconds

Trying to use p106-100 (GTX 1060 6gb) in a cluster, also is there a chance of 2b GGUF support being implemented?

Looks like something wrong with the VAE model file itself.

Looks like something wrong with the VAE model file itself.

https://github.com/kijai/ComfyUI-CogVideoXWrapper/issues/82#issuecomment-2365224495 - seems really similar to my case though:    ```
raise NotImplementedError(
NotImplementedError: Cannot copy out of meta tensor; no data! Please use torch.nn.Module.to_empty() instead of torch.nn.Module.to() when moving module from meta to a different device.
I also re downloaded models\cogvideox\vae to make sure that the issue is not with the model itself.
Should I try full clean install (comfy+pytorch+cogvideox only)?

Looks like something wrong with the VAE model file itself.

https://github.com/kijai/ComfyUI-CogVideoXWrapper/issues/82#issuecomment-2365224495 - seems really similar to my case though:
 raise NotImplementedError(
NotImplementedError: Cannot copy out of meta tensor; no data! Please use torch.nn.Module.to_empty() instead of torch.nn.Module.to() when moving module from meta to a different device.

I also re downloaded models\cogvideox\vae to make sure that the issue is not with the model itself.
Should I try full clean install (comfy+pytorch+cogvideox only)?

Their issue was using model loader from different node pack, what workflow are you using?

cogvideox_fun_pose_example_01. - this one.
sorry for the confusion, aren't VAE models all the same across? ex - https://huggingface.co/Kijai/CogVideoX-Fun-pruned/tree/main/CogVideoX-Fun-5b-InP/vae or https://huggingface.co/alibaba-pai/CogVideoX-Fun-5b-InP/tree/main/vae
Perhaps I indeed should let Down(Load model) node source all the models..


Update 0128-longest-consecutive-sequence.js

maxScore is not defined. Runtime Error

File(s) Modified: 0128-longest-consecutive-sequence.js
Language(s) Used: javascript
Submission URL: _https://leetcode.com/submissions/detail/1328969318/_

Important
Please make sure the file name is lowercase and a duplicate file does not already exist before merging.

@ermayank I re-ran the solution on leetcode and the solution passed. maxScore is initialized to 0 in the function call


Header inheritance fails if encounters JSR223 sampler with SamplerScript class

Hello Abstracta team,
Here is a Header-is-missing thing I've faced while working with DSL.
Preconditions

at least two header managers at different test plan levels;
at least one JSR223 Sampler with Class as a parameter;
followed by HttpRequest

Results in
Only outermost header is assigned to the request.
The other header is not assigned.
See a sample test below as it may give a better sense of what's going on.
Thoughts
It can be simply me implementing SamplerScript incorrectly. Should I do something with Run method?
If that's the case, I'd be so grateful for guidance.
I also realise, there are workarounds. E.g. I can redesign the test to avoid header inheritance and pull all the headers as HttpRequest direct children (tried, that works). Yet I'd rather avoid the latter as it makes the script overloaded with details. In case of a large script it's easier to figure out a point of header related failure by filtering out the requests with no headers attached directly.
Consider the following sample test:
public class HeaderTest {
   //WireMock set-up omitted for the sake of brevity

    public static class NoAction implements DslJsr223Sampler.SamplerScript {
        @Override
        public void runScript(DslJsr223Sampler.SamplerVars vars) {
            //Nothing happens here
        }
    }

    @Test
    void test() throws IOException {
        testPlan(
                httpHeaders().header("ROOT_LEVEL", "rootLevelHeader"),
                threadGroup(1, 1,
                        transaction("LEVEL_ONE",
                                httpHeaders().header("LEVEL_ONE", "firstLevelHeader"),
                                jsr223Sampler("No action Lambda Sampler", NoAction.class),
                                httpSampler("Request at level one", "http://localhost:8888/one")
                        )
                )
        ).run();

        mockServer.verify(getRequestedFor(urlEqualTo("/one"))
                .withHeader("ROOT_LEVEL", equalTo("rootLevelHeader"))
                .withHeader("LEVEL_ONE", equalTo("firstLevelHeader")));
    }
}

The test results:
expected:
GET
/one
ROOT_LEVEL: rootLevelHeader
LEVEL_ONE: firstLevelHeader

but was:
GET
/one
ROOT_LEVEL: rootLevelHeader

And once again, thank you so much for crafting the DSL project. It makes the testing fun again (:

Hello, this is a very interesting bug that you have found, thank you!
The information you provided allowed us to easily reproduce and then identify the issue.
We have detected the source of the issue and will release a fix in next version.
Stay tuned!

We just released a new version which fixes reported issue. Thank you!

That's amazing news!
Thank you for taking care (:


Update navicat-for-postgresql to 11.2.15

After making all changes to the cask:

[x] brew cask audit --download {{cask_file}} is error-free.
[x] brew cask style --fix {{cask_file}} left no offenses.
[x] The commit message includes the cask’s name and version.

Closes #26320.

All the navicat casks need a version bump. There's a bash script in an older issue if you want that just calls cask repair on each

I am not sure what you mean @adidalal - according to their website version 11.2.15 is the latest?

All done @adidalal.

Thanks!


Minor Bug in the documentation

Under section Scene Map, the second renderScene function is incomplete.
Give code in the documentation:
renderScene = ({ route }) => {
  switch (route.key) {
  case 'first':
    return <FirstRoute />;
  case 'second':
    return <SecondRoute />;
  default:
    return null;
  }

Code that should be in the documentation:
renderScene = ({ route }) => {
  switch (route.key) {
  case 'first':
    return <FirstRoute />;
  case 'second':
    return <SecondRoute />;
  default:
    return null;
  }
};

Note: Missing curly bracket and the semicolon

I have generated a pull requested. Please take a look and feel free to notify me if some problem.

Hey, I just released a new alpha 2.0.0-alpha.0 of the library. It's rewritten using react-native-gesture-handler and react-native-reanimated addresses a many platform specific bugs and performance problems. The documentation is updated as well.
Please try the new version and see if it addresses your issue. If not, please open a new issue following the issue template.


Add more logging to determine cause for failures

Codecov Report

Merging #4939 (d4ca45e) into release-2021.02 (80ed9f6) will decrease coverage by 0%.
The diff coverage is 70%.

@@               Coverage Diff               @@
##           release-2021.02   #4939   +/-   ##
===============================================
- Coverage               73%     73%   -1%
===============================================
  Files                  412     413    +1
  Lines                27029   27064   +35
  Branches              3911    3913    +2
===============================================
+ Hits                 19892   19916   +24
- Misses                5537    5546    +9
- Partials              1600    1602    +2

Impacted Files
Coverage Δ

src/client/common/errors/types.ts
69% <ø> (ø)

src/client/common/installer/productInstaller.ts
55% <0%> (-1%)
:arrow_down:

src/client/telemetry/index.ts
74% <ø> (ø)

src/client/common/errors/index.ts
80% <33%> (-4%)
:arrow_down:

...ent/datascience/jupyter/kernels/kernelExecution.ts
38% <50%> (+<1%)
:arrow_up:

src/client/datascience/telemetry/telemetry.ts
83% <50%> (-2%)
:arrow_down:

src/client/api/pythonApi.ts
66% <65%> (-2%)
:arrow_down:

src/client/common/errors/errors.ts
42% <71%> (-2%)
:arrow_down:

src/client/datascience/constants.ts
99% <100%> (+<1%)
:arrow_up:

...cience/data-viewing/dataViewerDependencyService.ts
86% <100%> (+<1%)
:arrow_up:

... and 10 more


Mail count

How to show inbox count using mailman in rails
eg: Inbox(6)

This is currently not implemented, as emails are directly processed. You probably have a better chance using an Imap library directly.


Help with installing on macOS Ventura 13

Hi,
I am trying to help a student install Corrfunc on their MacBook, which has the latest OS (Ventura 13, I believe). We tried Method 2 (i.e., directly using pip), but ran into the failed building wheel for Corrfunc error. Then we tried Method 1, but unfortunately got the following error after running make CC=gcc-13:
In file included from ../../utils/cpu_features.c:13:

In function 'cpuid',

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:27:5:

../../utils/cpu_features.h:41:4: error: impossible constraint in 'asm'

   41 |    __asm("cpuid" : "=a"(a),"=b"(b),"=c"(c),"=d"(d) : "a"(functionnumber),"c"(0) );

      |    ^~~~~

In function 'cpuid',

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:29:5,

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:19:5:

../../utils/cpu_features.h:41:4: error: impossible constraint in 'asm'

   41 |    __asm("cpuid" : "=a"(a),"=b"(b),"=c"(c),"=d"(d) : "a"(functionnumber),"c"(0) );

      |    ^~~~~

In function 'xgetbv',

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:54:10,

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:19:5:

../../utils/cpu_features.h:69:4: error: impossible constraint in 'asm'

   69 |    __asm("xgetbv" : "=a"(a),"=d"(d) : "c"(ctr) : );

      |    ^~~~~

In function 'cpuid',

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:58:5,

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:19:5:

../../utils/cpu_features.h:41:4: error: impossible constraint in 'asm'

   41 |    __asm("cpuid" : "=a"(a),"=b"(b),"=c"(c),"=d"(d) : "a"(functionnumber),"c"(0) );

      |    ^~~~~

In function 'cpuid',

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:62:5,

    inlined from 'runtime_instrset_detect' at ../../utils/cpu_features.c:19:5:

../../utils/cpu_features.h:41:4: error: impossible constraint in 'asm'

   41 |    __asm("cpuid" : "=a"(a),"=b"(b),"=c"(c),"=d"(d) : "a"(functionnumber),"c"(0) );

      |    ^~~~~

make[2]: *** [../../utils/cpu_features.o] Error 1

make[1]: *** [DD] Error 2

make: *** [theory] Error 2

Do you know what could be going wrong and what else we can try?

@boryanah Thanks for reporting this! Yeah, this is a known issue and we are working towards a fix. In the meantime, please follow the comments/steps in #294 - hopefully that will at least let you compile.

Thanks a lot! We managed to install it following the instructions in that thread.

Ohh great - glad at least you could use the workaround and get Corrfunc running. I am closing this issue but please feel free to reopen if you need additional help.