Add method to print 128 bits integers

I can't think of some more unit test fundamentally different from the one I've added.

So anything wrong with this pull request?

It duplicates the previous one, so I think there is no need to have both,


Artifactory Cleanup

From the below link we got an groovy script for artifactory clean up process.
https://github.com/JFrogDev/artifactory-user-plugins/blob/master/cleanup/artifactCleanup.groovy
But the above script takes "repos" input as a array string & not accepting * values.
So that if we try to fetch artifacts like "/libs-releases-local/com/testrepo*" it says not found. But there is the paths available as below.
/libs-releases-local/com/testrepo1
/libs-releases-local/com/testrepo2
/libs-releases-local/com/testrepo3

@vigneshrs  I'm checking the code of this script and doesn't have support for regular expressions:

Your issue has more than 2 years, I can implement this funcionality if you are still interesting.

@elioengcomp - quick question about properties file - when I change something in it, how to apply my change in Artifactory? I assume I should reload plugin, but plugin code is not changed so I cannot reload it without Artifactory restart?

@hamstermaster you can touch the plugin file to change the lastUpdated timestamp and call the reload plugins API.


Add status around PB pools, memory, system and mochiweb [RCS-244]

3rd PR for adding various stats.
This PR adds stats/status for

pools of PB connections
memory
system and
mochiweb TCP sockets

Still auth_bypass_test is failing... :warning:

test
[posted via JIRA by Kota Uenishi]

Fixed failing auth_bypass_test and add one commit of refactoring.
Ready for review now :smile:

@borshop merge

@borshop merge

This is a part of RCS-11 work; release notes will be written there.
[posted via JIRA by Kota Uenishi]


forgot to require path module

main.js: not require path module

client.js: use window.location.hostname to retrieve the host name

fixed it.


Added support for upgrading SharePoint Framework projects to v1.8.0 solving #848

Added support for upgrading SharePoint Framework projects to v1.8.0 solving #848

Coverage remained the same at 100.0% when pulling d5f8c2ade2897a5bb4e64f6fe4f214159d10ec1a on VelinGeorgiev:update-to-v1.8.0 into 33c9780a8664ef0c0a4595ea5ab7db0de8f9e3b0 on pnp:dev.


feat: Add jsrepo

First of all this is super cool I love that it looks just like lucide but with animations!
I am working on a project jsrepo that is really nice for stuff like this where you want to copy paste things into your project (it also does a bunch more than just copy paste).

P.S. Sorry for the size most of it is the manifest

Hey, first of all thank you for the idea and the submission! I am actually currently working on packaging this repo for npm. I totally see the benefit of jsrepo and I am thinking about using it for some project maybe. For these icons though, I am leaning towards a package, because you usually want to use multiple icons throughout your whole project or application. If you used lucide before, you would then be able to just import the same icons from this library instead of lucide. I was also thinking about adding installation possibilities via npx. Curious to hear your opinion on this, especially what the benefit of jsrepo over npx is.

I meant the possibility to add specific icons via npx, just like shadcn

Honestly I would agree with you most of the time you don't want to just install a single icon. I was thinking jsrepo would be a good fit for what this project currently does not necessarily if you want users to be able to use it like lucide.
I still think it may be cool to offer both though! For me I think this would be nice to use but my large svelte project at work already won't build on free runners because of it's size and the amount of dependencies.

I meant the possibility to add specific icons via npx, just like shadcn

If you are looking to build your own shadcn then don't this does it for you and it's better.

For the record jsrepo also lists icons in your repo so you don't have to explicitly provide them:
jsrepo add

This will list all the blocks in your repo

If you have the time you can check out the docs or demos as well that might give you a better picture of what it actually is.
I think if you were looking to build something like shadcn then this would be a shortcut for you!

Curious to hear your opinion on this, especially what the benefit of jsrepo over npx is.

But where would be the difference between adding a bin script to the package and using jsrepo? Both do the same in the end or am I missing something?

You would need to write the bin script yourself. Or do you mean using jsrepo as your bin script?
jsrepo also does a lot more than just adding them into your project if you look at the update or diff command as well as stuff like formatting the code when it comes into your project.

The flow for the user would look something like:
# initialize jsrepo
npx jsrepo init

# add icons through the list
npx jsrepo add

# add icon by name
npx jsrepo add icons/alarm-clock-check

In this case jsrepo is your cli for adding the icons.


Cannot generate config.yml file

I cannot connect to the freshly started docker container using the method outlined in the docs.
user@tc:/userdata/influxdb# docker run -d --restart unless-stopped --name=influxdb -p 8086:8086 -v /userdata/influxdb/data:/var/lib/influxdb2 influxdb:2.6.1 --reporting-disabled
2afc2fb3c3cb1f10cde39d34ec4a09115ab367be4f0de1456c5fc97d81e10523
user@tc:/userdata/influxdb# docker run --rm influxdb:2.6.1 influx server-config > config.yml
Error: failed to retrieve config: Get "http://localhost:8086/api/v2/config": dial tcp <IP_ADDRESS>:8086: connect: connection refused
user@tc:/userdata/influxdb#
Influxdb is running though. Pointing a browser to http://<IP_ADDRESS>:8086 will redirect to /onboarding/0
Relevant URLs

https://docs.influxdata.com/influxdb/v2.6/install/
Provide other relevant URLs (project issues, community threads, etc.)

Pointing a browser to http://<IP_ADDRESS>:8086/api/v2/config will return 401 Unauthorized. Do I need to set up an organization first?

@naymore This endpoint requires authentication (as mentioned in the API documentation. You don't specifically need an organization, but you do need an operator token to authenticate with. The operator token is generated and provided during the initialization process. A default org is also created during the initialization process, but the org isn't required to use the api/v2/config endpoint, just a token is.


toStrictEqual does not consider arrays with objects having undefined values correctly

Summary
Fixes #7937: toStrictEqual does not consider arrays with objects having undefined values correctly
Test plan
Before that change, the following assertion was failing:
expect([{a: undefined}]).not.toStrictEqual([{}]);

Now it passes as expected.

Codecov Report

Merging #7938 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master    #7938   +/-   ##
=======================================
  Coverage   65.33%   65.33%
=======================================
  Files         255      255
  Lines        9941     9941
  Branches     1041     1041
=======================================
  Hits         6495     6495
  Misses       3195     3195
  Partials      251      251

Impacted Files
Coverage Δ

packages/expect/src/utils.js
98.37% <100%> (ø)
:arrow_up:

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 b8a9a71...8274a76. Read the comment docs.

Thanks for the PR! We just merged a migration of expect to TypeScript, sorry about the conflict.

No problem I will rebase asap

@SimenB I rebased locally with no issue, is the migration to Typescript of èxpect on master?

It's on master, yes. You can see GitHub reporting a merge conflict

@SimenB should be rebased now

Thanks a lot for your quick reviews 👍
Following this bug, I wanted to come with some kind of automatic way to detect such regression or bug in the future.
For the moment I commited a draft proposal for such test on my fork: https://github.com/dubzzz/jest/commit/114022fe0a9b19eb7a7c704051c83e292b8bdd84
The test basically checks the following:

Given a and b values such as a different from b
We expect expect(a).not.toStrictEqual(b) to succeed

It caught another bug in toStrictEqual: expect(0).not.toStrictEqual(5e-324) fails
@SimenB, @thymikee,  @pedrottimark, @jeysal:
Any opinion concerning this kind of test?
Do you think it can be useful to have this kind of tests into Jest CI?

@dubzzz I've heard of fast-check (and jsverify) before and I like the idea, could imagine adding them in a separate test file

@jeysal Thanks a lot for your input, I will write a new spec with only properties for matchers. I let you know when I have something ready so that we can iterate on it ;)

I'd be particularly interested to learn how to achieve determinism with this, but let's see when you have prepared a draft and discuss such topics there :)

I clearly get your concerns of potential flakiness added by such test suites.
There are multiple things to keep in mind with property based testing:

runs can be seeded - when seeded no flakyness possible - but I would rather recommend to have a new seed for each run
in case of failure, the seed causing the failure is visible in the logs so that you can reproduce the issue and open a ticket to track it
in case of failure, the final case is the minimal failing case, that is to say: not an ugly random large entry
in case of failure, it means there is a real bug in the code (or in the test if the test is wrong)
the default number of runs is 100 (barely all frameworks do this)

I would say that bug detection is pretty good and stable - I mean it finds bugs consistently.
Justification: integration test and examples of fast-check - executed for all CI runs on node 6, 8 and 10 - check that fast-check properly detects bugs in buggy code. And they are stable. Example: detect a bug occuring only when an object contains a sub-object.
But indeed sometimes bugs are not easy to detect and might be detected a bit later. In a way it is still useful as it means the bug is now known.

I think it detected another bug:
const s1 = new Set([true]);
const s2 = new Set([new Boolean(true)]);

expect(s1).not.toEqual(s2); // success

expect(s2).not.toEqual(s1); // failure
//    expect(received).not.toEqual(expected)
//    Expected: Set {true}
//    Received: Set {{}}

An issue with symmetry of toEqual.

Interesting, thanks for elaborating! As mentioned, I'm in favor of integrating such tests in places where it makes sense, and expect definitely seems like such a case :+1:

I'm very much in favor of adding fuzz testing to expect.
This got me thinking, should we ship fuzz testing as part of jest itself? Might make it a bit more mainstream. Should be enough to just wrap jsverify, fast-check or whatever

As you both agree to add property based testing or fuzzing into the tests of Jest, I am going to open a PR for that purpose.
@SimenB I definitely welcome the idea to wrap property based testing tools directly within Jest. I think it is a great idea: growing the popularity of such approach among JavaScript world would be very nice.
I am obviously a little biased concerning the choice of the framework as I wrote fast-check. In a nutshell when I first wanted to do property based in my company I opted for jsverify but got stuck on some of its limitations (due to initial design choices). So I started to explore how it worked and somehow started fast-check.
Why fast-check?
Maintained, used by awslabs/aws-cdk for instance, multiple unique features: replay, verbose, commands for UI tests, pre-conditions...
More on the read me.
Concerning integration in Jest, I did some wrapper of fast-check for ava. Might give you some ideas: https://github.com/dubzzz/ava-fast-check/

As you both agree to add property based testing or fuzzing into the tests of Jest, I am going to open a PR for that purpose.

Awesome!

@SimenB I definitely welcome the idea to wrap property based testing tools directly within Jest. I think it is a great idea: growing the popularity of such approach among JavaScript world would be very nice.

Would you mind opening an RFC for it? It doesn't have to be very detailed, the paragraphs you have above are great.
The only thing I'd like to see in addition is some API proposals of how this would look like if it were built into Jest. Would this live on describe, it and test (like test.each), on expect (like expect.extend, expect.hasAssertions and resolves/rejects) or on jest (like jest.retryTimes and jest.runAllTimers). Immediately, I think this makes sense on expect, like expect.fuzz.blablabla, but I might be wrong 🙂
I'd like to see a separate RFC so it's more visible to other people, instead of being discussed in a merged PR.
Thanks! ❤


Enable the new model serialization for edge order

Contributing to the Azure SDK
Please see our CONTRIBUTING.md if you are not familiar with contributing to this repository or have questions.
For specific information about pull request etiquette and best practices, see this section.

API change check
APIView has identified API level changes in this PR and created following API reviews.
Azure.ResourceManager.EdgeOrder


Package update

Hello, are you planning to update the package? I use it in my project, but the camera version etc. may not compatible with other packages.

please try the updated version


Update the Pydantic home page

It just caught my eye that the home page https://pydantic.dev/#v2 still says that v2 is

In active development now, and due to be released in Spring 2023

This is outdated information and therefore should be updated.
Selected Assignee: @dmontagu

Thanks @nobkd for reporting this 🙏
I've created a PR to fix it

I can't see the PR, because pydantic/pydantic-site isn't public, but thanks :heart:.

Thank you for updating this 👍


[WEB-1143-122] feat: add strategy description

Created new meta for:
-SushiBar and Inverse finance strategy
-LUSD (liquity stability pool) strategy

@FoxTheSin updated some of the wording and ran prettier


Using unowned / weak in then closure capture list

I'm wondering whether it's valid to use unowned self in code like this
class Manager
{
    private func deleteDevice(device: Device) -> Promise<Void>
    {
        httpManager.deleteDevice(device).then({ [unowned self] (_) -> Promise<Void> in
            return self.wipeDeviceFromDatabase(device);
       });
   }

   private func wipeDeviceFromDatabase(device: Device) -> Promise<Void>
   {
        ...
   }
}

As per Apple Docs:

Use a weak reference whenever it is valid for that reference to become nil at some point during its lifetime. Conversely, use an unowned reference when you know that the reference will never be nil once it has been set during initialization.

Lets imagine the instance of Manager can be deallocated at any moment and the promise chain shouldn't continue after that. So I wanted to ask whether it is valid to use unowned self when self is captured inside then closure or it's better to use weak self? The latter case introduces an issue when an optional promise can't be returned from then, e.g.
httpManager.deleteDevice(device).then({ [weak self] (_) -> Promise<Void> in
            return self?.wipeDeviceFromDatabase(device);
       });

Cannot convert value of type '_ -> Promise?' to expected argument type '(Void) -> AnyPromise'

Promises do not create retain cycles, so it's safe to use self in the handlers. Meaning that you won't even need to think about this the majority of the time. In fact, retaining self might even be what you want so to allow the promise to resolve before self is deallocated.
If you reach a situation where you do want self to be allowed to deallocate before your promise resolves then that's when you would employ weak or unowned. I believe the latter will catch in your error handler should it come up nil, but if you go this route I recommend testing. If you decide to use weak then you will need to refactor your promise chain to account for optional promises, which is why your second example did not compile.

thanks @nathanhosselton,

If you reach a situation where you do want self to be allowed to deallocate before your promise resolves then that's when you would employ weak or unowned. I believe the latter will catch in your error handler should it come up nil

I suppose unresolved promise wouldn't reach the error handler and dealloc in case we use unowned, giving the following log: "PromiseKit: Pending Promise deallocated! This is usually a bug".
Anyway, thx for pointing me to the source of truth, closing the issue


Drafts View

Make a request to the server for the view - build in all the functions

[ ] Add Argument to draft
[ ] Add new draft as reason to argument (auto save as new draft)
[ ] Add existing claim as reason to argument
[ ] Delete reason from argument
[ ] Delete argument from draft
[ ] Publish draft

Will need to redo server / DB side of things to simplify drafts and claims. All will be claims, all will be stored in the same place. The difference between draft & published will be a state (may not be binary, need to prep for shared within a team etc).

No longer doing 'drafts'


LittleFS Create Failed

Installing Amulet of Entropy
followed instructions here for Little FS and Arduino says " LittleFS Create Failed!"
I've reset my computer to factory setting
Install Arduino v1
set preference to earlphilhower...
tools - board - raspberry pi pico, set port
continued to follow instruction
for LittleFS install in tools and data
any advise would be appreciated
Thanks

My best advice is to try to use all the exact versions of the IDE and libraries as specified in the setup guide - basically, copy my exact setup. If you did that, and you set up the flash size, then I'm not sure what else to try. Can you upload the full log of what you're seeing, like this?

My best advice is to try to use all the exact versions of the IDE and libraries as specified in the setup guide - basically, copy my exact setup. If you did that, and you set up the flash size, then I'm not sure what else to try. Can you upload the full log of what you're seeing, like this?

with your advise I went throgh the prodcedure agaian an success.  Not such what was wrong all the other times but it works.
Thanks for your reply and this project.


[Dashboard] Deleted map is still listed after deleting associated dataset

Reported by @skgsergio:

If you delete a dataset that is being used in a map it warns you and if you proceed it deletes the map. Ok, deleting the dataset (and therefore the map) triggers a reload of the dataset view but not of the maps view so the map still appears and if you click on it you get a 404 error. Is a bit ugly I think we should reload the map list too.

cc: @alejandraarri

As it is a minor bug, I've fixed it in the PR above ☝


Runtime class seems to be Crystal::Expressions, but crashes because it's Crystal::Nop

Here's the code:
require "compiler/crystal/syntax"

    s = "a = 5; puts a + 3"

    nodes = Crystal::Parser.parse(s)
    puts nodes.class # => Crystal::Expressions
    puts nodes.is_a? Crystal::Expressions # => true
    puts nodes.is_a? Crystal::Nop # => false

    puts nodes.expressions

The last line causes
undefined method 'expressions' for Crystal::Nop (compile-time type is Crystal::ASTNode+)

OS: MacOS 10.14
Compiler version: 0.26.1 (reproducible on all versions from 0.25.0 to 0.26.1 and on master)

undefined method 'expressions' for Crystal::Nop (compile-time type is Crystal::ASTNode+)

The message could be improved. Right now it tells you the first type that doesn't have the method, but in reality many of them don't have it... but I guess the message would be too complex to understand.


Fixes for the internal to external migration process

This is the code that is currently running on QA.

Coverage decreased (-34.1%) to 58.786% when pulling 3572162f7264b58e4d1b76c43772a8aa75cfd973 on fixes4 into c99363811bb36c3208663e20706b6cb675de377d on develop.


Support pushing to docker Hub

Fix #271
Signed-off-by: David Gageot<EMAIL_ADDRESS>

@tuananh Thanks for your help. Should be better now


Unable to tap menu button when set to .normal/.slideAside

First of all, thanks for this great component, saved me a lot of time!
I've encountered a problem when style is set to .normal or .slideAside - I'm unable to tap a button in navigationBar to open the menu again. It works fine with .slideAbove.
I'm using Xcode 13.2 and iOS 15.2.
How to reproduce

Use Example app
Run in Simulator
Change style to normal or slideAside (in the app menu)
Close the menu (tap X)
You're not able to tap button to open the menu again

I guess it could be some layer covering half of the view? Let me know if you need anything to debug (video?), I'm happy to help!

Update: seems to be connected to this line. If the .cornerRadius modifier is removed, it works as expected. Making this modifier conditional should probably fix it.
Using something like this source:
extension View {
    /// Applies the given transform if the given condition evaluates to `true`.
    /// - Parameters:
    ///   - condition: The condition to evaluate.
    ///   - transform: The transform to apply to the source `View`.
    /// - Returns: Either the original `View` or the modified `View` if the condition is `true`.
    @ViewBuilder func `if`<Content: View>(_ condition: Bool, transform: (Self) -> Content) -> some View {
        if condition {
            transform(self)
        } else {
            self
        }
    }
}

And then:
main
    .if((options.show && (options.style == .scale || options.style == .rotate)), transform: { view in
        view.cornerRadius(options.cornerRaduisIfNeeded)
    })

Oh, so you managed to fix that, thanks for the contribution, I'm here if anything is needed 😄


fix(core): broken tests

Tests fail for onDestroy in FullLifecycleDynamicComponent.
Reset of a component is grouped with resets of inputs. Change of bound inputs appears immediately, but dispose of the component will be in ngOnChanges of the directive.  Because of it, the component will be destroyed after inputs will be reset.

You awesome, thanks! 👏 I will release it tomorrow afternoon


update to 4.6.0-0.okd-2021-01-23-132511 fails due to open-vm-tools already absent

Describe the bug

I am using 4.6.0-0.okd-2021-01-17-185703 that I had trouble to install due to the presence of open-vm-tools. Not that I am in that version and try to update to 4.6.0-0.okd-2021-01-23-132511 it fails because open-vm-tools is not installed... And I cannot install it since the files exist in the base FCOS image.
Version

UPI BareMetal update from 4.6.0-0.okd-2021-01-17-185703 to 4.6.0-0.okd-2021-01-23-132511
How reproducible

Install 4.6.0-0.okd-2021-01-17-185703 and try to update to 4.6.0-0.okd-2021-01-23-132511
Log bundle
relevant log:
$ oc -n openshift-machine-config-operator logs -f machine-config-daemon-rzhsl -c machine-config-daemon | head -n100                                                                                1 ↵
I0124 16:45:38.916354  361690 start.go:108] Version: machine-config-daemon-4.6.0-202006240615.p0-378-gead62052-dirty (ead62052138543eb3e19b4de493a94ed7c88b3b9)
I0124 16:45:38.918083  361690 start.go:121] Calling chroot("/rootfs")
I0124 16:45:38.918159  361690 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0124 16:45:38.941196  361690 daemon.go:226] Booted osImageURL: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c ()
I0124 16:45:38.947676  361690 daemon.go:233] Installed Ignition binary version: 2.8.1
I0124 16:45:38.964068  361690 start.go:97] Copied self to /run/bin/machine-config-daemon on host
I0124 16:45:38.966264  361690 metrics.go:106] Registering Prometheus metrics
I0124 16:45:38.966314  361690 metrics.go:111] Starting metrics listener on <IP_ADDRESS>:8797
I0124 16:45:38.967331  361690 update.go:1661] Starting to manage node: okd4-master-25
I0124 16:45:38.969043  361690 rpm-ostree.go:261] Running captured: rpm-ostree status
I0124 16:45:39.060393  361690 daemon.go:862] State: idle
Deployments:
* pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
              CustomOrigin: Managed by machine-config-operator
                 Timestamp: 2021-01-17T11:43:43Z
           LayeredPackages: NetworkManager-ovs glusterfs glusterfs-fuse qemu-guest-agent

  pivot://quay.io/openshift/okd-content@sha256:95034a94e28949af41a53b9efb2fbb0651454a7c37bab002b0646e73c4721829
              CustomOrigin: Managed by machine-config-operator
                 Timestamp: 2020-12-12T05:05:37Z
           LayeredPackages: NetworkManager-ovs glusterfs glusterfs-fuse open-vm-tools
                            qemu-guest-agent
I0124 16:45:39.060414  361690 rpm-ostree.go:261] Running captured: journalctl --list-boots
I0124 16:45:39.133258  361690 daemon.go:869] journalctl --list-boots:
-1 df8f697bbf724d5f90baaab0b3cb67d1 Wed 2021-01-20 01:06:28 UTC—Wed 2021-01-20 21:44:07 UTC
 0 257cb932d75649378301841cc566a856 Wed 2021-01-20 21:45:04 UTC—Sun 2021-01-24 16:45:39 UTC
I0124 16:45:39.133288  361690 rpm-ostree.go:261] Running captured: systemctl list-units --state=failed --no-legend
I0124 16:45:39.141003  361690 daemon.go:884] systemd service state: OK
I0124 16:45:39.141018  361690 daemon.go:616] Starting MachineConfigDaemon
I0124 16:45:39.141078  361690 daemon.go:623] Enabling Kubelet Healthz Monitor
I0124 16:45:39.978541  361690 daemon.go:397] Node okd4-master-25 is part of the control plane
I0124 16:46:02.543922  361690 daemon.go:815] Current config: rendered-master-b1d5a4357e85a929594a1abca7461e3f
I0124 16:46:02.543942  361690 daemon.go:816] Desired config: rendered-master-5cb0b39837ac2039c0b99ecf28f28f66
I0124 16:46:02.551219  361690 daemon.go:1085] Validating against current config rendered-master-b1d5a4357e85a929594a1abca7461e3f
I0124 16:46:02.559145  361690 daemon.go:1093] Validated on-disk state
I0124 16:46:02.559182  361690 update.go:431] Checking Reconcilable for config rendered-master-b1d5a4357e85a929594a1abca7461e3f to rendered-master-5cb0b39837ac2039c0b99ecf28f28f66
I0124 16:46:02.585890  361690 update.go:1661] Starting update from rendered-master-b1d5a4357e85a929594a1abca7461e3f to rendered-master-5cb0b39837ac2039c0b99ecf28f28f66: &{osUpdate:false kargs:false fips:false passwd:false files:false units:false kernelType:false extensions:true}
I0124 16:46:02.587499  361690 update.go:1661] Update prepared; beginning drain
E0124 16:46:03.494607  361690 daemon.go:344] WARNING: ignoring DaemonSet-managed Pods: openshift-cluster-node-tuning-operator/tuned-9jb5f, openshift-controller-manager/controller-manager-h58q4, openshift-dns/dns-default-7r6gh, openshift-image-registry/node-ca-2hcvz, openshift-machine-config-operator/machine-config-daemon-rzhsl, openshift-machine-config-operator/machine-config-server-4c7kn, openshift-monitoring/node-exporter-6pfbc, openshift-multus/multus-admission-controller-xhw7d, openshift-multus/multus-gnqf8, openshift-multus/network-metrics-daemon-m442k, openshift-sdn/ovs-sjwcj, openshift-sdn/sdn-bp7xx, openshift-sdn/sdn-controller-97wfv
I0124 16:46:03.494626  361690 update.go:1661] drain complete
I0124 16:46:03.496523  361690 update.go:167] Successful drain took 0.907432148 seconds
I0124 16:46:03.496561  361690 update.go:1048] Updating files
I0124 16:46:03.507190  361690 update.go:1384] Writing file "/etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt"
I0124 16:46:03.537544  361690 update.go:1384] Writing file "/etc/tmpfiles.d/cleanup-cni.conf"
I0124 16:46:03.582727  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/configmaps/cloud-config/ca-bundle.pem"
I0124 16:46:03.598138  361690 update.go:1384] Writing file "/usr/local/bin/configure-ovs.sh"
I0124 16:46:03.626863  361690 update.go:1384] Writing file "/etc/containers/storage.conf"
I0124 16:46:03.658734  361690 update.go:1384] Writing file "/etc/NetworkManager/dispatcher.d/90-long-hostname"
I0124 16:46:03.690555  361690 update.go:1384] Writing file "/etc/systemd/system.conf.d/10-default-env-godebug.conf"
I0124 16:46:03.716421  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/etcd-member/root-ca.crt"
I0124 16:46:03.742310  361690 update.go:1384] Writing file "/etc/modules-load.d/iptables.conf"
I0124 16:46:03.768196  361690 update.go:1384] Writing file "/etc/kubernetes/kubelet-ca.crt"
I0124 16:46:03.797334  361690 update.go:1384] Writing file "/etc/systemd/system.conf.d/kubelet-cgroups.conf"
I0124 16:46:03.843969  361690 update.go:1384] Writing file "/etc/NetworkManager/conf.d/sdn.conf"
I0124 16:46:03.876697  361690 update.go:1384] Writing file "/var/lib/kubelet/config.json"
I0124 16:46:03.906074  361690 update.go:1384] Writing file "/etc/kubernetes/manifests/recycler-pod.yaml"
I0124 16:46:03.947762  361690 update.go:1384] Writing file "/etc/kubernetes/ca.crt"
I0124 16:46:03.976996  361690 update.go:1384] Writing file "/etc/sysctl.d/forward.conf"
I0124 16:46:04.003028  361690 update.go:1384] Writing file "/etc/sysctl.d/inotify.conf"
I0124 16:46:04.035532  361690 update.go:1384] Writing file "/usr/local/bin/recover-kubeconfig.sh"
I0124 16:46:04.079446  361690 update.go:1384] Writing file "/usr/local/sbin/set-valid-hostname.sh"
I0124 16:46:04.126540  361690 update.go:1384] Writing file "/etc/kubernetes/kubelet-plugins/volume/exec/.dummy"
I0124 16:46:04.187444  361690 update.go:1384] Writing file "/etc/containers/registries.conf"
I0124 16:46:04.231752  361690 update.go:1384] Writing file "/etc/crio/crio.conf.d/00-default"
I0124 16:46:04.264022  361690 update.go:1384] Writing file "/etc/containers/policy.json"
I0124 16:46:04.296120  361690 update.go:1384] Writing file "/etc/kubernetes/cloud.conf"
I0124 16:46:04.341125  361690 update.go:1384] Writing file "/etc/kubernetes/kubelet.conf"
I0124 16:46:04.383008  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/haproxy/haproxy.cfg.tmpl"
I0124 16:46:04.425794  361690 update.go:1384] Writing file "/etc/kubernetes/manifests/haproxy.yaml"
I0124 16:46:04.454560  361690 update.go:1384] Writing file "/etc/kubernetes/manifests/keepalived.yaml"
I0124 16:46:04.485005  361690 update.go:1384] Writing file "/etc/kubernetes/static-pod-resources/keepalived/keepalived.conf.tmpl"
I0124 16:46:04.529204  361690 update.go:1384] Writing file "/etc/haproxy/configuration-date"
I0124 16:46:04.559569  361690 update.go:1307] Writing systemd unit dropin "10-mco-default-env.conf"
I0124 16:46:04.590043  361690 update.go:1307] Writing systemd unit dropin "mco-disabled.conf"
I0124 16:46:04.619947  361690 update.go:1307] Writing systemd unit dropin "10-mco-default-env.conf"
I0124 16:46:04.665629  361690 update.go:1342] Writing systemd unit "kubelet.service"
I0124 16:46:04.694054  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/kubelet.service already exists. Not making a new symlink
I0124 16:46:04.694071  361690 update.go:1342] Writing systemd unit "machine-config-daemon-firstboot.service"
I0124 16:46:04.737305  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/machine-config-daemon-firstboot.service already exists. Not making a new symlink
I0124 16:46:04.737354  361690 update.go:1342] Writing systemd unit "machine-config-daemon-pull.service"
I0124 16:46:04.781140  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/machine-config-daemon-pull.service already exists. Not making a new symlink
I0124 16:46:04.781156  361690 update.go:1342] Writing systemd unit "node-valid-hostname.service"
I0124 16:46:04.810331  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/node-valid-hostname.service already exists. Not making a new symlink
I0124 16:46:04.810347  361690 update.go:1342] Writing systemd unit "nodeip-configuration.service"
I0124 16:46:04.838608  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/nodeip-configuration.service already exists. Not making a new symlink
I0124 16:46:04.838751  361690 update.go:1279] Enabled openvswitch.service
I0124 16:46:04.838774  361690 update.go:1342] Writing systemd unit "ovs-configuration.service"
I0124 16:46:04.866990  361690 update.go:1270] /etc/systemd/system/multi-user.target.wants/ovs-configuration.service already exists. Not making a new symlink
I0124 16:46:04.867008  361690 update.go:1307] Writing systemd unit dropin "10-ovs-vswitchd-restart.conf"
I0124 16:46:04.894980  361690 update.go:1307] Writing systemd unit dropin "10-ovsdb-restart.conf"
I0124 16:46:04.922755  361690 update.go:1279] Enabled ovsdb-server.service
I0124 16:46:04.922769  361690 update.go:1307] Writing systemd unit dropin "10-mco-default-env.conf"
I0124 16:46:04.952292  361690 update.go:1307] Writing systemd unit dropin "mco-controlplane-nice.conf"
I0124 16:46:04.984835  361690 update.go:1307] Writing systemd unit dropin "mco-disabled.conf"
I0124 16:46:05.014445  361690 update.go:1121] Deleting stale data
I0124 16:46:05.024578  361690 update.go:1492] Writing SSHKeys at "/home/core/.ssh/authorized_keys"
I0124 16:46:05.102356  361690 controlplane.go:42] Device /sys/devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/block/sda already uses scheduler bfq
I0124 16:46:05.102418  361690 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-083590241 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0124 16:46:26.979008  361690 update.go:962] Applying extensions : ["update" "--uninstall" "open-vm-tools"]
I0124 16:46:27.010657  361690 update.go:375] Rolling back applied changes to OS due to error: failed to execute rpm-ostree ["update" "--uninstall" "open-vm-tools"] : exit status 1

[root@okd4-compute-201 core]# rpm-ostree "update" "--uninstall" "open-vm-tools"
error: Package/capability 'open-vm-tools' is not currently requested

Check suggestions at https://github.com/openshift/okd/issues/471#issuecomment-766348026?

Check suggestions at https://github.com/openshift/okd/issues/471#issuecomment-766348026?

I had to do something like what the update-{master,worker} scripts do. But it was not a single smooth execution and had to fight a bit to make MCO accept my version... This is because MCO updated the rendered config twice during the update process and the update process did not agree completely with the version of the rendered MachineConfig it wanted... (also rook-ceph did not help due to the PodDisruptionBudget and its heuristic for static placement of pods...).
I guess the process is "documented" in the suggestion.

I had to do something like what the update-{master,worker} scripts do. But it was not a single smooth execution and had to fight a bit to make MCO accept my version... This is because MCO updated the rendered config twice during the update process and the update process did not agree completely with the version of the rendered MachineConfig it wanted... (also rook-ceph did not help due to the PodDisruptionBudget and its heuristic for static placement of pods...).
I guess the process is "documented" in the suggestion.

@vrutkovs
The suggested solution do not work for us. We are in the same situation trying to upgrade from 4.6.0-0.okd-2021-01-17-185703 => 4.6.0-0.okd-2021-01-23-132511.
We had to manually remove the open-vm-tools package previously in order to get to release the given release (as suggested in #471).
Trying to upgrade now we are hitting this error. Trying to uninstall open-vm-tools package says it is not installed. Trying to install it again says it cannot be done due to the hardlinking issue (VGAuthService: File exists).
The I tried to use the suggested update worker/master scripts without success:

as already found out master worker rendered config was messed up in the script
The scripts are not fully working for us, the offending command NODE=$(oc get node -l node-role.kubernetes.io/worker= -o=jsonpath='{.items[*].metadata.name}') is not returning a single result

Then I tried using
# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

and ran into the following error:
[root@okd-pg-w-01 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
[root@okd-pg-w-01 core]# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:43:55.435091  766318 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-296672374 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:44:20.762439  766318 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 06:44:20.864293  766318 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 06:44:22.782012  766318 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...
 We are in the same situation trying to upgrade from 4.6.0-0.okd-2021-01-17-185703 => 4.6.0-0.okd-2021-01-23-132511.
We had to manually remove the open-vm-tools package previously in order to get to release the given release (as suggested in #471).
Trying to upgrade now we are hitting this error. Trying to uninstall open-vm-tools package says it is not installed. Trying to install it again says it cannot be done due to the hardlinking issue (VGAuthService: File exists).
The I tried to use the suggested update worker/master scripts without success:

as already found out master worker rendered config was messed up in the script
The scripts are not fully working for us, the offending command NODE=$(oc get node -l node-role.kubernetes.io/worker= -o=jsonpath='{.items[*].metadata.name}') is not returning a single result

Then I tried using
# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

and ran into the following error:
[root@okd-pg-w-01 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora{,-updates}.repo
[root@okd-pg-w-01 core]# /run/bin/machine-config-daemon pivot quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:43:55.435091  766318 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-296672374 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4
I0125 06:44:20.762439  766318 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 06:44:20.864293  766318 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 06:44:22.782012  766318 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...

Probably my bash-foo is too weak, maybe we should be using sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo && sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo instead?

as already found out master worker rendered config was messed up in the script

Fixed

The scripts are not fully working for us, the offending command NODE=$(oc get node -l node-role.kubernetes.io/worker= -o=jsonpath='{.items[*].metadata.name}') is not returning a single result

Oh, hmm, updated to use hostname -f instead

and ran into the following error:

Check if rpm-ostree cleanup -m cleans up metadata and pivot proceeds?
Probably my bash-foo is too weak, maybe we should be using sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo && sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo instead?

The command rpm-ostree cleanup -m succeeds, still we have no luck. What we have tried now is:
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

giving the following error:
[root@okd-pg-w-03 core]# rpm-ostree cleanup -m
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# /run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
I0125 09:13:29.520866    7856 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-629531133 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:49.599318    7856 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 09:13:49.642793    7856 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:51.572609    7856 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...
I0125 09:13:51.572639    7856 rpm-ostree.go:261] Running captured: ostree refs --repo /run/mco-machine-os-content/os-content-629531133/srv/repo
I0125 09:13:51.609109    7856 rpm-ostree.go:224] Using ref fedora/x86_64/coreos/next-devel
I0125 09:13:51.609163    7856 rpm-ostree.go:261] Running captured: ostree rev-parse --repo /run/mco-machine-os-content/os-content-629531133/srv/repo fedora/x86_64/coreos/next-devel
I0125 09:13:51.633534    7856 rpm-ostree.go:243] Executing rebase from repo path /run/mco-machine-os-content/os-content-629531133/srv/repo with customImageURL pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c and checksum 14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682
I0125 09:13:51.633569    7856 rpm-ostree.go:261] Running captured: rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator
error: No enabled repositories
error: with stdout output: : error running rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator: 0 metadata, 0 content objects imported; 0 bytes content written
Checking out tree 14eea52...done
: exit status 1
[root@okd-pg-w-03 core]# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

We are not quite sure if we are using the correct pivot point "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"

The command rpm-ostree cleanup -m succeeds, still we have no luck. What we have tried now is:
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

giving the following error:
[root@okd-pg-w-03 core]# rpm-ostree cleanup -m
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
[root@okd-pg-w-03 core]# sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo
[root@okd-pg-w-03 core]#
[root@okd-pg-w-03 core]# /run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"
I0125 09:13:29.520866    7856 run.go:18] Running: nice -- ionice -c 3 oc image extract --path /:/run/mco-machine-os-content/os-content-629531133 --registry-config /var/lib/kubelet/config.json quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:49.599318    7856 rpm-ostree.go:261] Running captured: rpm-ostree status --json
I0125 09:13:49.642793    7856 rpm-ostree.go:179] Previous pivot: quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c
I0125 09:13:51.572609    7856 rpm-ostree.go:216] No com.coreos.ostree-commit label found in metadata! Inspecting...
I0125 09:13:51.572639    7856 rpm-ostree.go:261] Running captured: ostree refs --repo /run/mco-machine-os-content/os-content-629531133/srv/repo
I0125 09:13:51.609109    7856 rpm-ostree.go:224] Using ref fedora/x86_64/coreos/next-devel
I0125 09:13:51.609163    7856 rpm-ostree.go:261] Running captured: ostree rev-parse --repo /run/mco-machine-os-content/os-content-629531133/srv/repo fedora/x86_64/coreos/next-devel
I0125 09:13:51.633534    7856 rpm-ostree.go:243] Executing rebase from repo path /run/mco-machine-os-content/os-content-629531133/srv/repo with customImageURL pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c and checksum 14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682
I0125 09:13:51.633569    7856 rpm-ostree.go:261] Running captured: rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator
error: No enabled repositories
error: with stdout output: : error running rpm-ostree rebase --experimental /run/mco-machine-os-content/os-content-629531133/srv/repo:14eea5296ffb7a28aff80a70c03434e8034422b0d11b47475b29530b93ab4682 --custom-origin-url pivot://quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c --custom-origin-description Managed by machine-config-operator: 0 metadata, 0 content objects imported; 0 bytes content written
Checking out tree 14eea52...done
: exit status 1
[root@okd-pg-w-03 core]# sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

We are not quite sure if we are using the correct pivot point "quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c"

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

2fe2f is from previous stable:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-17-185703
quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c

The latest has 64f1..:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-23-132511
quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

#471 is about rpm-ostree unable to install the RPM when the binaries from this RPM are already written to disk (we have to do that so that bootstrap node could have open-vm-tools too).

2fe2f is from previous stable:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-17-185703
quay.io/openshift/okd-content@sha256:2fe2fd4d99c953d5bcf0d53b420a2012aae7fd12986dac8e757ad68f7b97030c

The latest has 64f1..:
$ oc adm release info --image-for=machine-os-content quay.io/openshift/okd:4.6.0-0.okd-2021-01-23-132511
quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4

In my opinion the most easy way would be to somehow force reinstall open-vm-tools so that it can be cleanly removed by the update.

#471 is about rpm-ostree unable to install the RPM when the binaries from this RPM are already written to disk (we have to do that so that bootstrap node could have open-vm-tools too).

We are confused now. We are on the way from 4.6.0-0.okd-2021-01-17-185703 to latest (4.6.0-0.okd-2021-01-23-132511). Its still not working, no matter what pivot we use, the error is always that there are now repos enabled.
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

We are confused now. We are on the way from 4.6.0-0.okd-2021-01-17-185703 to latest (4.6.0-0.okd-2021-01-23-132511). Its still not working, no matter what pivot we use, the error is always that there are now repos enabled.
rpm-ostree cleanup -m

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates-archive.repo
sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-cisco-openh264.repo

/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora{,-updates}.repo

I personnally did not touch the repositories at all and only used the pivot command and some forcing on the MCO part.
With a lot of patience and manual modifications of the Node objets in the API I managed to make MCO accept the new state.
Some bullet points:

ssh to the machine and switch to root
use the machine-config-daemon pivot command to manually apply the new update
reboot the host
during the reboot process force the MCO state of the machine with oc edit node and forcing the current state == desired state (the final state) clean up any error message and set step as "Done"
wait for the machine to reboot and update the MCO state in the Node if it is in degraded try to fix it. Worst case edit the /etc/machine-config-daemon/currentconfig file on the host to reflect the state you actually want

I personnally did not touch the repositories at all and only used the pivot command and some forcing on the MCO part.
With a lot of patience and manual modifications of the Node objets in the API I managed to make MCO accept the new state.
Some bullet points:

ssh to the machine and switch to root
use the machine-config-daemon pivot command to manually apply the new update
reboot the host
during the reboot process force the MCO state of the machine with oc edit node and forcing the current state == desired state (the final state) clean up any error message and set step as "Done"
wait for the machine to reboot and update the MCO state in the Node if it is in degraded try to fix it. Worst case edit the /etc/machine-config-daemon/currentconfig file on the host to reflect the state you actually want

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo

This disables the repo. I think I typo'd in my comment, it should be sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo

sed -i 's;enabled=1;enabled=0;g' /etc/yum.repos.d/fedora-updates.repo

This disables the repo. I think I typo'd in my comment, it should be sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo

So that means we should activate the fedora-updates repo?

So that means we should activate the fedora-updates repo?

temporarily - yes. machine-os-content already has all necessary dependencies, however its pretty tricky to mount it, so for this one time users should enable fedora/fedora-updates to make rpm-ostree happy.
Note, that repos need to be disabled after the node is fixed - it might backfire on cluster upgrades.

temporarily - yes. machine-os-content already has all necessary dependencies, however its pretty tricky to mount it, so for this one time users should enable fedora/fedora-updates to make rpm-ostree happy.
Note, that repos need to be disabled after the node is fixed - it might backfire on cluster upgrades.

Thanks for your help. Could you please provide a clean matrix which repos should be enabled/disabled before/after the pivot call. Something like:
BEFORE
fedora ?enabled?
fedora-updates ?enabled?
[*]

AFTER
fedora ?enabled?
fedora-updates ?disabled?
[*]

Thanks for your help. Could you please provide a clean matrix which repos should be enabled/disabled before/after the pivot call. Something like:
BEFORE
fedora ?enabled?
fedora-updates ?enabled?
[*]

AFTER
fedora ?enabled?
fedora-updates ?disabled?
[*]

For pivot you need fedora and fedora-updates. After pivot its best to probably disable those, unless you're planning to install more RPMs on the host

For pivot you need fedora and fedora-updates. After pivot its best to probably disable those, unless you're planning to install more RPMs on the host

After two days we finally managed to get the update done. The essential point was to overcome the MCO trying to provision a specific pivot point. The procedure itself is very annoying, don't know how this should be done for a large cluster. In the end the last comment from @RyuunoAelia helped us.
So here is our procedure (for each node):

Set machineconfiguration.openshift.io/desiredConfig annotation for the given node to a configuration that does not exist. This will cause MCO to put the node into degraded state doing nothing as it can't reliably determine what should be done
Watch the logs of the corresponding machine-config-daemon-XXX pod until you see the degraded state is recognised
No enter the node via SSH and apply the pivot change suggested by @vrutkovs

rpm-ostree cleanup -m
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo
/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"

This will create a new pivot point on the machine into which you will have to reboot into
Before doing the reboot edit the nodes machineconfiguration.openshift.io/currentConfig annotation and already point it to the configuration you want to switch to
Then we had to overwrite the /etc/machine-config-daemon/currentconfig file (contents where taken from the target machine config) !! Watch out: there different target configs for master and worker nodes
Reboot the node
When its up, fix machineconfiguration.openshift.io/desiredConfig to the valid target config, it should now match with the machineconfiguration.openshift.io/currentConfig value

The machine-config-daemon pod will now pick up the changes. In our case, doing this on the first node, it complained about file content mismatches for some file. We patched them manually to the desired content.
Here is a list of files we had to patch:
/etc/crio/crio.conf.d/00-default
/etc/systemd/system/kubelet.service
/etc/systemd/system/machine-config-daemon-pull.service
/etc/systemd/system/nodeip-configuration.service
/etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf

Then the node got recognised as fully done. We rebooted once again to make sure changes persist - and so they did. We saved the patched files to our bastion and re-used for patching up the other nodes during the procedure what saved a lot of time.

After two days we finally managed to get the update done. The essential point was to overcome the MCO trying to provision a specific pivot point. The procedure itself is very annoying, don't know how this should be done for a large cluster. In the end the last comment from @RyuunoAelia helped us.
So here is our procedure (for each node):

Set machineconfiguration.openshift.io/desiredConfig annotation for the given node to a configuration that does not exist. This will cause MCO to put the node into degraded state doing nothing as it can't reliably determine what should be done
Watch the logs of the corresponding machine-config-daemon-XXX pod until you see the degraded state is recognised
No enter the node via SSH and apply the pivot change suggested by @vrutkovs

rpm-ostree cleanup -m
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora.repo
sed -i 's;enabled=0;enabled=1;g' /etc/yum.repos.d/fedora-updates.repo
/run/bin/machine-config-daemon pivot "quay.io/openshift/okd-content@sha256:64f1cc9663a57d3bb9cc413502c9ccc04097be2033cf726aaf535e0e7ad5b5c4"

This will create a new pivot point on the machine into which you will have to reboot into
Before doing the reboot edit the nodes machineconfiguration.openshift.io/currentConfig annotation and already point it to the configuration you want to switch to
Then we had to overwrite the /etc/machine-config-daemon/currentconfig file (contents where taken from the target machine config) !! Watch out: there different target configs for master and worker nodes
Reboot the node
When its up, fix machineconfiguration.openshift.io/desiredConfig to the valid target config, it should now match with the machineconfiguration.openshift.io/currentConfig value

The machine-config-daemon pod will now pick up the changes. In our case, doing this on the first node, it complained about file content mismatches for some file. We patched them manually to the desired content.
Here is a list of files we had to patch:
/etc/crio/crio.conf.d/00-default
/etc/systemd/system/kubelet.service
/etc/systemd/system/machine-config-daemon-pull.service
/etc/systemd/system/nodeip-configuration.service
/etc/systemd/system/ovs-vswitchd.service.d/10-ovs-vswitchd-restart.conf

Then the node got recognised as fully done. We rebooted once again to make sure changes persist - and so they did. We saved the patched files to our bastion and re-used for patching up the other nodes during the procedure what saved a lot of time.

In the end I have to admit hat this was quite a tough one, especially if you consider that all we would have needed was an rpm-ostree install open-vm-tools **--force**.
Maybe it is also a good idea to make the cluster update a bit more resilient to failures, where it fails uninstalling packages that are already no more present.

In the end I have to admit hat this was quite a tough one, especially if you consider that all we would have needed was an rpm-ostree install open-vm-tools **--force**.
Maybe it is also a good idea to make the cluster update a bit more resilient to failures, where it fails uninstalling packages that are already no more present.

@vrutkovs & @RyuunoAelia still thanks for your help.

@vrutkovs & @RyuunoAelia still thanks for your help.

Maybe it is also a good idea to make the cluster update a bit more resilient to failures, when it fails uninstalling packages that are already no more present.

Yeah, sorry about that, I'm surprised we didn't this on our CI - we'll work on improving that.

Maybe it is also a good idea to make the cluster update a bit more resilient to failures, when it fails uninstalling packages that are already no more present.

Yeah, sorry about that, I'm surprised we didn't this on our CI - we'll work on improving that.


Docs/mermaid

Description
In #953 (see https://github.com/FlexMeasures/flexmeasures/pull/953#discussion_r1479405353) we saw we would like to start using Mermaid in our docs.
I have tried that, following the instructions at https://github.com/mgaitan/sphinxcontrib-mermaid, but I could not get mermaid to build anything (yes, I ran pip install sphinxcontrib-mermaid, and I also tried the simple example diagram from their website).
Look & Feel
Running make update-docs and then going to Concepts -> The FlexMeasures Data Model should show a diagram.
How to test
In addition to the local test above, this should also work on ReadTheDocs.

The current PR description suggests a tech spike with a negative outcome. What's the next decision to be taken to advance the state of this PR?

I don't know. Maybe someone has a bit of knowledge of mermaid and/or Sphinx and wants to pick this up. It would be nice to use mermaid diagrams in our docs, but not a blocker.


Questions regarding 'embedded-hal'

Hi I have a few questions regarding 'embedded-hal'
Afaik I am able to write Rust code and it will work on a Raspberry Pi or an Ardunio, however the machine code will be difference once when compiled. My question is am I able to write exactly the same code for an Arduino and it can easily be ported over to the Raspberry Pi without any changes to the code, for example lets say that I want an LED light bulb to turn on for 4 seconds and then turn off for a 4 seconds and the cycle repeats. Would my Rust code (not the machine code) be the exactly the same for both these two devices?
Is it production ready? Is it stable? Is there a lot of work that needs to be done?
Is it more harder to program using Rust embedded-hall compared to using the Arduino's code?
Am I able to do everything with embedded-hall compared to using Arduino's code?

Kind of a late reply, but hopefully it's still useful
For your first point, the goal is that most of the code should be the same, for example, your blinking LED would look something like this (pseudocode)
fn blink_led<PIN: digital::OutputPin, TIMER: timer::Timer>(pin: PIN, timer: TIMER) -> Result<()> {
    pin.set_high();
    timer.start(4.seconds());
    block!(timer.wait());
    pin.set_low();
    block!(timer.wait());
}

However, because microcontrollers aren't the same everywhere, especially not
when comparing the raspi to an arduino, the setup code for the pin and the
timer would differ.
So generally, you have a lot of generic code that uses the embedded_hal API,
and then some setup and glue code make it all work.

Is it production ready? Is it stable? Is there a lot of work that needs to be done?

I'd say that depends. 1.0 is in alpha, and after the full release of that, I
don't think there will be any API changes. However, not everything is
implemented, so I find that you sometimes have to circumvent the embedded_hal
API and use the HAL implementors directly. So, it depends on what you want to do

Is it more harder to program using Rust embedded-hall compared to using the Arduino's code?

Depends on what you're used to, but in general yes. Rust is a lot more strict
about its types and guarantees which does provide a lot more safety, but also
makes it harder to write the code. You also need a fairly good grasp of
generics.

Am I able to do everything with embedded-hall compared to using Arduino's code?

Not yet, but a lot of it is there

Do you have any further questions or can we close this @Joe23232 ?


Update deps

changesets 対応の間溜まってしまっていたので、styled-components 以外の依存ライブラリをまとめてあげる。
styled-components はメジャーアップデートということもあり、別で対応する。
対応したもの

https://github.com/voyagegroup/ingred-ui/pull/1345
https://github.com/voyagegroup/ingred-ui/pull/1332
https://github.com/voyagegroup/ingred-ui/pull/1328
https://github.com/voyagegroup/ingred-ui/pull/1326
https://github.com/voyagegroup/ingred-ui/pull/1317

手動で対応したもの

storybook のバージョンを上げた
prettier の実行

補足
多分これをマージしたらたくさん新しいプルリクエスト飛んでくるけど（typescript-eslint とか最近見てないし）、それ以降はまた通常通りの運用にする。

package.json で管理されていないものたち
semver
5.7.2 以上になってればいい

https://github.com/voyagegroup/ingred-ui/pull/1328

yarn why semver
yarn why v1.22.19
[1/4] 🤔  Why do we have the module "semver"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found<EMAIL_ADDRESS>info Has been hoisted to "semver"
info Reasons this module exists
   - Hoisted from "make-dir#semver"
   - Hoisted from "@babel#helper-define-polyfill-provider#semver"
   - Hoisted from "@babel#core#semver"
   - Hoisted from "@babel#helper-compilation-targets#semver"
   - Hoisted from "@babel#helper-create-class-features-plugin#semver"
   - Hoisted from "@babel#preset-env#semver"
   - Hoisted from "eslint-plugin-import#semver"
   - Hoisted from "eslint-plugin-jsx-a11y#semver"
   - Hoisted from "eslint-plugin-react#semver"
   - Hoisted from "@babel#helper-create-regexp-features-plugin#semver"
   - Hoisted from "@babel#preset-env#babel-plugin-polyfill-corejs2#semver"
   - Hoisted from "@storybook#react-vite#@vitejs#plugin-react#@babel#core#semver"
   - Hoisted from "@storybook#react-vite#react-docgen#@babel#core#semver"
   - Hoisted from "@babel#preset-env#@babel#plugin-transform-class-properties#@babel#helper-create-class-features-plugin#semver"
   - Hoisted from "@babel#preset-env#@babel#plugin-transform-class-static-block#@babel#helper-create-class-features-plugin#semver"
   - Hoisted from "@babel#preset-env#@babel#plugin-transform-private-methods#@babel#helper-create-class-features-plugin#semver"
   - Hoisted from "@babel#preset-env#@babel#plugin-transform-private-property-in-object#@babel#helper-create-class-features-plugin#semver"
   - Hoisted from "@babel#preset-env#@babel#plugin-transform-named-capturing-groups-regex#@babel#helper-create-regexp-features-plugin#semver"
   - Hoisted from "@babel#preset-env#@babel#plugin-transform-unicode-property-regex#@babel#helper-create-regexp-features-plugin#semver"
   - Hoisted from "@babel#preset-env#@babel#plugin-transform-unicode-sets-regex#@babel#helper-create-regexp-features-plugin#semver"
   - Hoisted from "scaffdog#update-notifier#semver-diff#semver"
   - Hoisted from "scaffdog#update-notifier#latest-version#package-json#semver"
   - Hoisted from "storybook#@storybook#cli#jscodeshift#@babel#core#semver"
   - Hoisted from "jest#@jest#core#@jest#reporters#istanbul-lib-instrument#semver"
   - Hoisted from "storybook#@storybook#cli#@storybook#codemod#@babel#core#semver"
   - Hoisted from "storybook#@storybook#cli#@storybook#codemod#@babel#preset-env#semver"
   - Hoisted from "storybook#@storybook#cli#@storybook#codemod#@babel#core#@babel#helper-compilation-targets#semver"
   - Hoisted from "storybook#@storybook#cli#@storybook#codemod#@babel#preset-env#babel-plugin-polyfill-corejs2#semver"
info Disk size without dependencies: "88KB"
info Disk size with unique dependencies: "88KB"
info Disk size with transitive dependencies: "88KB"
info Number of shared dependencies: 0
=> Found<EMAIL_ADDRESS>info This module exists because "ts-jest" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found "<EMAIL_ADDRESS>info This module exists because "@changesets#cli" depends on it.
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found "<EMAIL_ADDRESS>info This module exists because "@typescript-eslint#eslint-plugin" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found "<EMAIL_ADDRESS>info This module exists because "@changesets#cli#@changesets#apply-release-plan" depends on it.
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found "<EMAIL_ADDRESS>info This module exists because "@changesets#cli#@changesets#assemble-release-plan" depends on it.
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found "<EMAIL_ADDRESS>info This module exists because "@changesets#cli#@changesets#get-dependents-graph" depends on it.
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found<EMAIL_ADDRESS>info This module exists because "scaffdog#update-notifier" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found "<EMAIL_ADDRESS>info This module exists because "storybook#@storybook#cli" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found "<EMAIL_ADDRESS>info This module exists because "@storybook#addon-essentials#@storybook#manager-api" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found "<EMAIL_ADDRESS>info This module exists because "@typescript-eslint#parser#@typescript-eslint#typescript-estree" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found "<EMAIL_ADDRESS>info This module exists because "@typescript-eslint#eslint-plugin#@typescript-eslint#utils" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found<EMAIL_ADDRESS>info This module exists because "@changesets#cli#meow#normalize-package-data" depends on it.
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found "@storybook/cli#<EMAIL_ADDRESS>info This module exists because "storybook#@storybook#cli#@babel#core" depends on it.
=> Found "@storybook/cli#<EMAIL_ADDRESS>info This module exists because "storybook#@storybook#cli#@babel#preset-env" depends on it.
info Disk size without dependencies: "88KB"
info Disk size with unique dependencies: "88KB"
info Disk size with transitive dependencies: "88KB"
info Number of shared dependencies: 0
=> Found<EMAIL_ADDRESS>info This module exists because "jest#@jest#core#jest-snapshot" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found "<EMAIL_ADDRESS>info This module exists because "storybook#@storybook#cli#@storybook#core-server" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found<EMAIL_ADDRESS>info This module exists because "storybook#@storybook#cli#simple-update-notifier" depends on it.
info Disk size without dependencies: "276KB"
info Disk size with unique dependencies: "340KB"
info Disk size with transitive dependencies: "372KB"
info Number of shared dependencies: 2
=> Found<EMAIL_ADDRESS>info Reasons this module exists
   - "rollup-plugin-imagemin#imagemin-gifsicle#execa#cross-spawn" depends on it
   - Hoisted from "rollup-plugin-imagemin#imagemin-gifsicle#execa#cross-spawn#semver"
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found "@storybook/cli#<EMAIL_ADDRESS>info This module exists because "storybook#@storybook#cli#@babel#core#@babel#helper-compilation-targets" depends on it.
info Disk size without dependencies: "88KB"
info Disk size with unique dependencies: "88KB"
info Disk size with transitive dependencies: "88KB"
info Number of shared dependencies: 0
=> Found "<EMAIL_ADDRESS>info This module exists because "storybook#@storybook#cli#@babel#preset-env#babel-plugin-polyfill-corejs2" depends on it.
info Disk size without dependencies: "88KB"
info Disk size with unique dependencies: "88KB"
info Disk size with transitive dependencies: "88KB"
info Number of shared dependencies: 0
=> Found<EMAIL_ADDRESS>info This module exists because "rollup-plugin-imagemin#imagemin-gifsicle#gifsicle#bin-wrapper#bin-version-check" depends on it.
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found "<EMAIL_ADDRESS>info Reasons this module exists
   - "storybook#@storybook#cli#jscodeshift#@babel#register#make-dir" depends on it
   - Hoisted from "storybook#@storybook#cli#jscodeshift#@babel#register#make-dir#semver"
=> Found<EMAIL_ADDRESS>info This module exists because "rollup-plugin-imagemin#imagemin-gifsicle#gifsicle#bin-wrapper#bin-version-check#semver-truncate" depends on it.
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
=> Found<EMAIL_ADDRESS>info Reasons this module exists
   - "rollup-plugin-imagemin#imagemin-gifsicle#gifsicle#bin-wrapper#bin-version-check#bin-version#execa#cross-spawn" depends on it
   - Hoisted from "rollup-plugin-imagemin#imagemin-gifsicle#gifsicle#bin-wrapper#bin-version-check#bin-version#execa#cross-spawn#semver"
info Disk size without dependencies: "80KB"
info Disk size with unique dependencies: "80KB"
info Disk size with transitive dependencies: "80KB"
info Number of shared dependencies: 0
✨  Done in 0.43s.

tough-cookie
4.1.3 以上になってればいい

https://github.com/voyagegroup/ingred-ui/pull/1326

yarn why tough-cookie
yarn why v1.22.19
[1/4] 🤔  Why do we have the module "tough-cookie"...?
[2/4] 🚚  Initialising dependency graph...
[3/4] 🔍  Finding dependency...
[4/4] 🚡  Calculating file sizes...
=> Found<EMAIL_ADDRESS>info Reasons this module exists
   - "jest-environment-jsdom#jsdom" depends on it
   - Hoisted from "jest-environment-jsdom#jsdom#tough-cookie"
info Disk size without dependencies: "160KB"
info Disk size with unique dependencies: "784KB"
info Disk size with transitive dependencies: "828KB"
info Number of shared dependencies: 4
✨  Done in 0.36s.

他は package.json を上げるだけだったので問題ないはず
rollup 上げたけど testEnv でビルド通って dev と preview 両方確認できた


Purifycss choking on inline assets

We have assets urls in CSS converted into data url by url-loader and svg-url-loader. Purifycss is choking on these data urls with message:
Unhandled rejection Error: undefined:2933:467: missing '}'
This seems to be the same thing as https://github.com/purifycss/purifycss/issues/144
Does webpack monitor even need to use purifycss? If the user is not using purifycss in their own setup, why use it when generating stats?

Fair point ... I should set CSS checking as optional, as that and the minify checker are a pretty trivial. Was more a proof of concept thing for more useful evaluation of assets. Will put on the list.

Actually, I figured out it's only checking the purified size for the recommendations page. My workaround was to wrap the purifycss call in a try...catch and display a message that purifycss couldn't parse if it catches. I'll make a PR later today or tomorrow so you can choose between that or another approach.

That would be awesome. Even if we make the recommendations optional, better error handling is still required so what you suggest would be much appreciated. Thank you!


Codinasion Logo for Christmas 🎄

Contribute Codinasion Logo for Christmas 🎄
This LOGO will be used on our website, GitHub, and Twitter on the 24th & 25th of December.

Here is the reference for our previous year's Christmas logo.

See Reference Image

Normal
Christmas 2022

cc/ @codinasion/codinasion @codinasion/program

these snowflakes are pretty hard to see on white background, otherwise, it looks pretty good

that white background looks like a flashbang these days

Hi @harshraj8843,
I wanted to check in and make sure I'm on the right track with the designs. Could you please take a look and let me know if they align with what you had in mind? I'm open to any feedback or adjustments you might have. Looking forward to your thoughts! 🎄✨

But how to create a Christmas-themed logo without a white background?

Perhaps a transparent background, but keeping the Christmas hat, and other aspects

But how to create a Christmas-themed logo without a white background?

Perhaps a transparent background, but keeping the Christmas hat, and other aspects

Hi @isyuricunha! I totally understand your preference for a transparent background. In the current version of the logo, I've utilized a red and green background to highlight the white snow elements. However, this is just for demonstration purposes, and I want to assure you that we can easily make changes to accommodate a transparent background. If you have any specific requests or if there are other aspects you'd like to tweak, feel free to let me know! Your feedback is invaluable, and we can make adjustments to ensure the logo aligns perfectly with your vision. 🎄✨

like

Personally, I don't like to give my opinion or details, as I'm terrible at design, so at most I just say what pleases my eyes.
All the logos you and Haraj have created are beautiful. Congratulations.
I think they'll all look good on the site. But if I were to choose, I'd go for the first image of the red logo with the candy in the middle, but without the background. That way it can or could be used in any, and both dark and white mode, it would look nice and not be disconnected with the design and color change.
Well, that's just my opinion - maybe it's not that relevant.
Translated with DeepL https://www.deepl.com/app/?utm_source=android&utm_medium=app&utm_campaign=share-translation

But how to create a Christmas-themed logo without a white background?

Perhaps a transparent background, but keeping the Christmas hat, and other aspects

Hi @isyuricunha! I totally understand your preference for a transparent background. In the current version of the logo, I've utilized a red and green background to highlight the white snow elements. However, this is just for demonstration purposes, and I want to assure you that we can easily make changes to accommodate a transparent background. If you have any specific requests or if there are other aspects you'd like to tweak, feel free to let me know! Your feedback is invaluable, and we can make adjustments to ensure the logo aligns perfectly with your vision. 🎄✨

Personally, I don't like to give my opinion or details, as I'm terrible at design, so at most I just say what pleases my eyes.
All the logos you and Haraj have created are beautiful. Congratulations.
I think they'll all look good on the site. But if I were to choose, I'd go for the first image of the red logo with the candy in the middle, but without the background. That way it can or could be used in any, and both dark and white mode, it would look nice and not be disconnected with the design and color change.
Well, that's just my opinion - maybe it's not that relevant.

Note: The logos are designed with careful consideration of white snow and other white elements. As such, they may not be best suited for a pure white background to maintain visibility and contrast. The use of a background with a slight tint or transparency is recommended for optimal presentation. Feel free to reach out if you have any specific preferences or if adjustments are needed to better suit your requirements. 🎨❄

That's wonderful to hear, @harshraj8843! I'm thrilled that you like all three designs. If there are any final touches or specific details you'd like to address, or if you have any further feedback, please feel free to let me know. I'm here to make sure the designs align perfectly with your vision. Looking forward to the next steps! 😊🎄✨

@0ME9A , all the logos are amazing!
this is really beautiful.


PublishCodeCoverageResults@1 uploads to the artifacts with spaces which is not supported by deploy stages

Required Information
Question, Bug, or Feature?
Type: Bug
Enter Task Name: PublishCodeCoverageResults@1
Environment

Server - Azure Pipelines
Agent - Hosted Ubuntu 1604

Issue Description
I'm using the new multi stage yaml build configuration and there seems to be an issue with the PublishCodeCoverageResults@1 task because it's uploading the of the code coverage report with a name containing spaces, which is not supported.
Here's the error I'm getting in the deploy task:
Job Job1: Step Download_Code Coverage Report_51440 has an invalid name. Valid names may only contain alphanumeric characters and '_' and may not start with a number.

Troubleshooting
Here's my azure-pipelines.yml file for reference:
trigger:
- master

stages:
- stage: Build
  jobs:
  - job:
    pool:
      vmImage: 'Ubuntu-16.04'
    steps:
    - task: NodeTool@0
      inputs:
        versionSpec: '10.x'
      displayName: 'Install Node.js'

    - script: |
        npm install -g @angular/cli
        npm install
        ng build --prod
      displayName: 'npm install and build'

    - script: |
        ng lint --format stylish
      displayName: 'Lint TypeScript files'

    - script: |
        ng test --watch=false --code-coverage
      displayName: 'Run unit tests with code coverage'

    - task: PublishCodeCoverageResults@1
      displayName: 'Publish code coverage Angular results'
      condition: succeededOrFailed()
      inputs:
        codeCoverageTool: Cobertura
        summaryFileLocation: 'testsResults/unitTests/coverage/cobertura-coverage.xml'
        reportDirectory: 'testsResults/unitTests/coverage/'
        failIfCoverageEmpty: true

    - task: PublishTestResults@2
      displayName: 'Publish unit tests results'
      condition: succeededOrFailed()
      inputs:
        searchFolder: $(System.DefaultWorkingDirectory)
        testRunTitle: MyApp
        testResultsFormat: JUnit
        testResultsFiles: "**/TESTS*.xml"

    - task: CopyFiles@2
      inputs:
        SourceFolder: 'dist/'
        Contents: '**'
        TargetFolder: '$(Build.ArtifactStagingDirectory)'

    - task: PublishBuildArtifacts@1
      inputs:
        ArtifactName: 'MyApp'
      displayName: Publish build artifacts

- stage: Deploy
  jobs:
  - deployment:
    environment: staging
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo Deploying !

I'm seeing a similar error when publishing regular build artifacts that are then downloaded by the Deploy stage: "Job Job1: Step Download_drop.zip0 has an invalid name. Valid names may only contain alphanumeric characters and '_' and may not start with a number."

i have the same issue , but i think its related to deployment job , when i use standard job with the same steps - issue didn't appear. Also i have noticed that my deployment job run on Server agent even if pool: vmImage: ubuntu-latest is configured

@Gimly We were unable to reproduce this issue. It works in normal cases. Even if we have spaces in XML or report directory, still we were able to upload to the artifact and download from there. Can you please mail us the complete logs along with repo at "devops_tools AT microsoft DOT com" so that we can reproduce the scenario at our end.

#10391 (another duplicate)
Here is a github example (with the broken steps commented out)
https://github.com/sevenwestmedia-labs/ScribanExpress
#    - task: PublishCodeCoverageResults@1
#      inputs:
#        codeCoverageTool: 'Cobertura'
#        #summaryFileLocation: '$(Build.SourcesDirectory)\**\coverage.cobertura.xml'
#        summaryFileLocation: '$(Build.SourcesDirectory)/TestResults/Coverage/coverage.cobertura.xml'

@ankit-nitd I can't send you an email because my address isn't on the list of allowed senders (at least that's what I received as an answer from your Office365 organization). I've uploaded a sample Angular CLI app where the issue happens, you can find it here: https://github.com/Gimly/CodeCoveragePipelineFail.
If you send me an email address which works I'll send you the complete logs as well, I don't want to make them public as there are info about our structure in the logs.

@Gimly, We've received your logs. I can confirm that there is an issue on our end. I'm forwarding it to the right team to assist you further.

@ericsciple  On investigating this issue, we found that publish code coverage task is able to generate/publish the code coverage results. Its getting uploaded to the artifactory and we are able to see the code coverage tab as well. However, in the deploy stage, its trying to download the artifacts where this error occurs. Ideally, this should have come in the publish step itself where we try to upload files with invalid names. Can you please look into this?
Here is the repro build: https://dev.azure.com/testPipelineTasks/testPipeline/_build/results?buildId=48&view=results

@ankit-nitd-zz it looks like your build has expired - could you share another repro?

Can anyone confirm this is still an issue? I'm unable to repro on my end.
cc @ankit-nitd-zz


⚠ Hartman Foundation has degraded performance

In e0b0ae5, Hartman Foundation (https://gordonhartman.com/) experienced degraded performance:

HTTP code: 200
Response time: 2558 ms

Resolved: Hartman Foundation performance has improved in f78a557.

Resolved: Hartman Foundation performance has improved in f78a557.


Move RouterHandler typealias to its own file

https://github.com/IBM-Swift/Kitura/tree/develop/Sources/Kitura/RouterElement.swift#L407

Completed in PR #424.


Don’t fail rename if there are multiple index entries for the same USR

The test case that I’m adding right now is that we have a lingering index entry from a file that has been moved on disk. While the proper fix here would be to ignore such an entry from the index, we should also be more resilient and not fail rename altogether just because there are multiple entries for a USR – the chances are very high that they all translate to the same Swift and Objective-C name.
rdar://123937371

@swift-ci Please test

@swift-ci Please test Linux

@swift-ci Please test

@swift-ci Please test Windows


Refresh in Insert Mode

Does anyone know of a way to call the refresh function from my vimrc? Eg;
autocmd CursorHoldI * call s:CursorHoldUpdate()
But of course that doesn't work because the function is scoped to the script with s:.

There is some hacky way to do this:
https://vi.stackexchange.com/questions/17866/are-script-local-functions-sfuncname-unit-testable
But why don't you simply add CursorHoldI event to the existing autocmd plugin line?
autocmd CursorHold,CursorHoldI * silent! call s:CursorHoldUpdate()

Oh interesting! I'll have a play with those SO suggestions, thank you.
But this would autocmd CursorHold,CursorHoldI * silent! call s:CursorHoldUpdate() lives in the plugin code right? And then I would have to maintain my own fork?

Yes, you should edit plugin code.
You don't need your own fork if this is the only change you've made, you can edit plugin source right on local filesystem.

I see yes. That's reasonable, the plugin doesn't change much so there's not much danger of updates generating merge conflicts.


is there any methed make POOL.execute rerute dict?

HI:
Now, I want to write a RESTFUL API with tornado and i want to know is there any methed make POOL.execute rerute dict?
thanks

Pool has connect_kwargs option: https://github.com/PyMySQL/Tornado-MySQL/blob/master/tornado_mysql/pools.py#L33
You can pass cursorclass=DictCursor to connection via it.


Remove RC warning and add link to migration guide

What

Remove 2.0.0 RC warning
Add link to migration guide

Checklist
PR Structure

[x] This PR has a reasonably narrow scope (if not, break it down into smaller PRs).
[x] This PR title and description are clear enough for anyone to review it.
[x] This PR does not mix refactoring changes with feature changes (split into two PRs otherwise).

Thoroughness

[x] This PR adds tests for the new functionality or fixes.
[x] This PR contains the link to the Jira ticket it addresses.

Configs and Secrets

[x] No new CONFIG variables are required -OR- the new required ones were added to the helmchart's values.yaml file.
[x] No new CONFIG variables are required -OR- the new required ones were added to the deployments (pr-preview, dev, demo, prd).
[x] No new SECRETS variables are required -OR- the new required ones were mentioned in the helmchart's values.yaml file.
[x] No new SECRETS variables are required -OR- the new required ones were added to the deployments (pr-preview secrets, dev secrets, demo secrets, prd secrets).

Release

[x] This is not a breaking change.
[x] This is ready for production.. If your PR is not ready for production, please consider opening additional complementary PRs using this one as the base. Only merge this into develop or main after it's ready for production!

Deployment

[ ] Does the deployment work after merging?

stellar-disbursement-platform-backend-preview is available here:SDP:      https://sdp-backend-pr318.previews.kube001.services.stellar-ops.com/healthAP:       https://sdp-ap-pr318.previews.kube001.services.stellar-ops.com/healthFrontend: https://sdp-backend-dashboard-pr318.previews.kube001.services.stellar-ops.com


Switch between pages

Initial support added on https://github.com/valtlfelipe/statuscenter/commit/f66adb558d4a2d803e0e927695f6811dbe07dc83, which allows to select page on login.


Faster TOML parser?

This is just your information, not an actual issue.
The TOML parser from @BurntSushi recently switched to an MIT license:
https://github.com/BurntSushi/toml/issues/183
The previous license kept it from being selected for dep initially.
Hugo switched back to BurntSushi/toml because it is was found to be faster than pelletier/go-toml @pelletier:
https://github.com/gohugoio/hugo/commit/0907a5c1c293755e6bf297246f07888448d81f8b
@carolynvs I'm not suggesting that dep needs to switch -- just ensuring you're all aware.

Thanks for the heads up!

Do you still see the performance issues on that branch https://github.com/pelletier/go-toml/pull/176 ? Performance seems to me on par with BurntSushi's.

@pelletier It may be worth checking with @bep on the Hugo project. Maybe he can share more details regarding his benchmarks.

I have not looked at Hugo's benchmarks in relation to the recent tunings in go-toml: But remember this: Hugo have very different requirements in this area than deps -- handling one TOML file should be really, really fast with both of them -- and functionally both should be equal.

Is dep parsing one TOML file or transitively for each dependency?

Is dep parsing one TOML file or transitively for each dependency?

dep detects if a dependency uses dep as well, and reads in the Gopkg.toml file.

dep detects if a dependency uses dep as well, and reads in the Gopkg.toml file.

Indeed. Though, that operation is likely to get permanently cached at some point, though - #431 -  so still not a terribly big concern.

okay. I'll close this for now.

I was trying to figure out what's the best/canonical Go TOML parser by looking at which one dep uses. Perhaps other people do the same. Then I found this issue. It's something to consider, but being a highly visible project means dep sends validation to whatever dependencies it chooses over others.

@shurcooL yeah, i hear you on that - i'm always cognizant of the signal it sends when dep brings in dependencies.
at the same time, we have to make decisions like everyone else does - weigh the software that exists now in the context of our specific requirements and the tradeoffs that we can accept. we were originally looking at BurntSushi, but as @nathany noted in the OP, licensing issues made that  impossible.
switching is possible now that that's resolved, but the calculus changes, as we have to evaluate whether the effort of doing so is actually worth it for us. my feeling is that, unless and until we encounter some critical problem in @pelletier's implementation (and it's not being actively fixed), the work and risk of change to switch isn't worth it.
note that "critical problem" also covers features that we'd like to add - like, i know i've discussed at least with @carolynvs (though i can't remember where) that it'd be really good if the generator could format lists with one item per line, as that'd help enormously with diffs. but idk if the BurntSushi implementation supports that, either. until i see benchmarks indicating otherwise, i suspect that's much more important for dep than raw TOML in/out performance.

i'm always cognizant of the signal it sends when dep brings in dependencies.

Good to hear. That's all I wanted to bring up.

at the same time, we have to make decisions like everyone else does - weigh the software that exists now in the context of our specific requirements and the tradeoffs that we can accept. we were originally looking at BurntSushi, but as @nathany noted in the OP, licensing issues made that impossible.

That makes sense, I'm in agreement.

switching is possible now that that's resolved, but the calculus changes, as we have to evaluate whether the effort of doing so is actually worth it for us. my feeling is that, unless and until we encounter some critical problem in @pelletier's implementation (and it's not being actively fixed), the work and risk of change to switch isn't worth it.

I don't disagree, but I do wonder. TOML is a well defined specification. Shouldn't it be the contrary—rather easy and safe—to swap out one implementation for another, as long as both are correct? In fact, doing so could serve as a sanity check and provide confidence that there are no unexpected issues, or help catch them otherwise.
I'm thinking this in the context of just trying the change locally and seeing that all tests continue to pass, or someone trying it out locally. You wouldn't need to subject all users to this test.
But I do expect this is likely to be a very low priority for dep.

Shouldn't it be the contrary—rather easy and safe—to swap out one implementation for another, as long as both are correct? In fact, doing so could serve as a sanity check and provide confidence that there are no unexpected issues, or help catch them otherwise.
I'm thinking this in the context of just trying the change locally and seeing that all tests continue to pass, or someone trying it out locally. You wouldn't need to subject all users to this test.

yeah, i had this thought as i was writing my above response 😄 this is exactly the sort of thing for which it should be easy to swap in a new implementation - a well-defined external spec that has a narrow, well-defined interface in the language itself. there should be very little risk there.
it's really just more of an "if it ain't broke, don't fix it" situation. without some specific reason to move, there's little sense in investing the effort. or, in other words:

this is likely to be a very low priority for dep.

😄

I'm currently reworking the parser so that when you use Unmarshal it does
not create the intermediate tree. It should make this kind of operation
significantly faster. Currently it is on par performance-wise with
BurntSushi. If you have any specific benchmark/TOML document that shows
otherwise I'd love to work on it. :)
@sdboyer making the writer output arrays with one item per line is next on
my list if nobody gets to it before.
Thomas Pelletier


My simple workaround

It waits for all function complete process and then shows chart.

Hi,
Thanks for this. What problem is it solving? can you fix the tests?

Charts dont shows if charts init process inits before others libraries.

@brunowebdev Thanks Bruno.
For this to be merged can you:

Please rewrite the commits & PR with more descriptive comments
Fix the failing tests

Thanks.